電気通信及びマルチメディア管理方法及び装置
音声及び他のメディア通信をサポートし、ユーザが（ｉ）ライブ電話、電話会議、インスタント音声メッセージ又は、戦術的通信を含む複数の会話モードで参加し、(ｉｉ)ライブモード又はタイムシフトモードのいずれかで会話のメッセージをレビューし、２のモード間で行き来して切れ間なく遷移し、(ｉｉｉ)同時又は漸次的のいずれかで、複数の会話に参加し、(ｉｖ)後にレビュー又は処理するために会話のメッセージを格納し、(ｖ)ユーザの通信デバイス上で生成又は受信されるメディアを持続的に記憶することができるようにする電気通信及びマルチメディア管理装置及び方法。後者の特徴が、ネットワークから切断されているか、又はネットワーク状態が不足しているかのいずれかである場合、ユーザがメディアを生成又はレビューすることができるようにし、ネットワーク状態及び会話に参加するユーザの意向に基づいてネットワークを通じてメディアの送達を最適化できるようになる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信に関し、特に、ユーザにライブモードまたはタイムシフトモードのいずれかのモードで会話のメッセージをレビューしたり、会話を二つのモード間で遷移したり、複数の会話に参加したり、後でレビュー、加工するために会話のメッセージをアーカイブすることを可能にする、通信およびマルチメディアの管理方法および装置に関する。
【背景技術】
【０００２】
音声通信は、慣性の影響を受けるのが現状である。自動切換え、高帯域幅ネットワーク、さらに衛星通信、光ファイバー通信、ＩＰネットワーク通信（ＶｏＩＰ）、無線通信および携帯電話ネットワーク等の技術にもかかわらず、人々の電話の使い方にほとんど変化が見られない。いまだに、電話機を持ち上げ、相手にダイアルし、繋がるまで待ち、挙句にダイアルした相手と同期二重会話を強いられている。もし受信側が応答しなければ、接続はできず、会話も始まらない。
【０００３】
受信側がボイスメールを持っていれば、せいぜい一方通行の非同期の音声メッセージを残せるぐらいである。しかし、ボイスメールをレンダリングする手順は煩わしく時間もかかる。呼出し側は、相手方の電話の呼び出しリンが鳴り止み、ボイスメールシステムに遷移するのを待ち、音声メッセージの挨拶を聞き、それからメッセージを残さなければならない。現在のボイスメールシステムは、受信側にとっても不便である。受信側は、コードにダイアルして音声メールにアクセスし、一連のプロンプトをナビゲートし、待ち行列の中に先着の音声メッセージあればそれを聞き、それからやっと当の送信側のメッセージを聞かなければならない。
【０００４】
典型的なボイスメールシステムの他の短所は、音声メッセージを組織化すなわち永久にアーカイブすることができないことである。ボイスメールシステムの中には、ユーザがメッセージを記憶できるものもあるが、予め決められた時間が経過すると、自動的に削除され永久に失われてしまう。
【０００５】
さらに、現在のボイスメールシステムの別の問題は、メッセージを残す前に呼出し側とボイスメールシステムで接続をしなければならないということである。もし接続ができなければ、呼出し側にとってはメッセージを残す手立てはない。
【０００６】
現在の電話システムは、リアルタイムの通話、バラバラの音声メッセージといった比較的単純な利用パターンに基づいており、それらは、たいていは聞き終われば削除される。これらの音声通信形式は、音声通信で可能な真価を発揮していない、または現在可能なネットワークの速度および回線容量の進歩を活用できていない。また、もし電話回線がダウンしてしまった場合、すなわち利用不能な場合（例えば、携帯電話のユーザがサービス圏外にいる、または悪天候のために電話回線がダウンした）、通信は起こりえない。
【０００７】
一般に、電話ベースの通信はテキストベースの通信の進歩に追いついていない。インスタントメッセージ、Ｅメール、ファックス、グループチャット、テキストメッセージをアーカイブすることなどは、テキストベースの通信ではすべて当前のことである。音声メールのほかには、音声メッセージを管理および／またはアーカイブできる現在利用可能なツールはほとんどない。テキスト通信と比較すると、現在利用できる電話通信を管理するツールはまだ初歩的な段階にある。
【０００８】
企業環境は、現在の音声通信ツールにおける弱点の良い例を示している。今のところ、音声通信を法人資産として管理する統一された方法はない。従業員は普通、自分たちの電話での会話を録音したり永久保存したりすることはない。ビジネス関連の音声通信資産は、ほとんど言葉が話されると同時に即座に消えてしまい、これらの会話の内容を何らかの管理可能な形式で管理または保存する方法はない。
【０００９】
実例として、ある会社の営業幹部の例を考えてみよう。多忙な一日の流れの中で、この幹部はたくさんの電話をかけ、顧客から電話で幾つかの販売契約をとる場合がある。これらの会話を編集、保存、後に検索する手立てがないので、この幹部にとっては、ある取引と他の取引との条件についてのリコール、あるいは先に結んだ販売合意の条件に異議を唱える顧客に対しその根拠の説明を求める、といった後に発生することが予想される問題を解決する方法はない。もしこの幹部が会話を簡単に取出し、レビューすることが可能であれば、このような問題は簡単にかつ良好に解決することができるであろうと思われる。
【００１０】
現在、軍隊、消防、警察、救急医療隊、レスキュー隊、および第一応答者等に使用されている戦術的無線システムも、多くの不便をこうむっている。戦術的無線通信は、ほとんどの場合、メッセージの送信側と受信側の間で「ライブ」の無線接続で行われるに違いない。両者間に無線接続なければ、通信は成り立たつはずがない。もし、送信側または受信側が自分の無線にアクセスできない、あるいは無線回路の接続ができなければ、緊急メッセージを送ることは不可能だ。したがって、戦術的通信は、次のような幾つかの基本的な問題に悩まされている。（ｉ）メッセージが送達される保証がない、（ｉｉ）受信側は、リアルタイムで聞きそこねたメッセージに戻ったり聞いたりできない、（ｉｉｉ）会話参加者の情報粒度をコントロールすることができない、（ｉｖ）ライブ会話を行うための信号品位に欠ける場合、システムは対処できない。もしメッセージをライブで聴けなければ、そのメッセージは失われてしまう。送信側または受信側にとって、以前送られた会話のメッセージを管理する、優先順位をつける、アーカイブする、後で検索する（すなわち、タイムシフトする）のいずれかができるツールはない。
【００１１】
さらに、戦術的無線通信システムに関する別の短所は、１チャンネルにつき一時に一個のメッセージしか送信できないということである。大きなビル火災を例にとって見ると、そこでは、消防士、警察および救急救命士等の複数のチームが同時にビルに取り残された被害者を救助したり、消火活動したり、被害者に医療援護を提供したり、野次馬を整理したりしている。もし、各チームが同じチャンネルを使用しているとしたら、通信は混雑し大混乱に陥るかもしれない。一人以上の人が同時に送信していたら、通信は「踏倒し」がおこる。また、高い優先順位のメッセージと低い優先順位のメッセージとを区別する方法もない。燃え盛るビルの中で消火活動または取り残された被害者の救助活動をしているチームが、当然、野次馬の整理にあたっている他のチームより高い優先順位を持つ。もし、高い優先順位のメッセージが低い優先順位のメッセージによって踏倒されたら、重要な通信が妨害されるだけでなく、ビルの中にいる消防士と被害者の命に危険が及ぶことになる。
【００１２】
メッセージに優先順位をつけることができないことに対する、考えられるひとつの解決策としては、複数のチャンネルを使い、それぞれのチームに異なるチャンネルを割り当てることである。しかしながら、この解決策はそれ自体一連の問題を生じる。また、消防隊長は、どのチャンネルをどの時点で聞けば間に合うのかをどうやって判断するのか。複数のチームの全員がそれぞれ異なるチャンネルと接続していたら、どうやってたがいに通信をかわすのか。一つのチームが緊急援助を求めたとき、他のチームが別のチャンネルを聞いていたら、どうやってそれを知るのか。複数のチャンネルが幾つかの問題を軽く扱った場合、それが混乱を引き起こし、チャンネルが一つのとき以上にさらなる問題を生じる可能性がある。
【００１３】
効果的にメッセージに優先順位をつける、マルチ会話が同時に行える、メッセージのタイムシフトを行い、送達を確実にする、あるいは後の検索・レビューのためにマルチ会話をアーカイブすることをサポートする管理ツールがないことが、戦術的無線の問題に結びついている。軍隊、警察、消防のような第一応答者の立場においては、有効な通信ツールの有無が、文字通り生死、任務の成否を分かつ。上記の燃え盛るビルの例が、戦術的無線通信に係わる現在の幾つかの問題をわかりやすく例示している。戦術的通信を使用する軍隊、警察、第一応答者、その他にも同様な問題が存在する。
【００１４】
パケット方式のネットワークでは、共通に使用されるプロトコルとして、通信制御プロトコル（ＴＰＣ）およびユーザ・データグラム・プロトコル（ＵＤＰ）がある。ＵＤＰは、データの高速送達という利点はあるが、完全性を犠牲にする。パケットがデータ送信中に脱落する可能性があり、またデータを即座に宛先に届けようとする場合は使用できない。ＵＤＰは、幾つかの欠陥があるにもかかわらず、その速度属性のゆえにヴォイス・オーバ・インターネット・プロトコル（Ｖｏｉｃｅ Ｏｖｅｒ Ｉｎｔｅｒｎｅｔ プロトコル：ＶｏＩＰ）通信の標準になっている。一方、ＴＰＣは完全なデータ（すなわち、送信データの正確なコピー）の送達を保証するが、待ち時間を代償とする。どれほど時間がかかろうとも、全てのパケットが送達される。この遅延の問題が、ＴＰＣを「ライブ」通話に適さないものとしている。今のところ、ＴＰＣ、ＵＤＰの両者に機能の進化をもたらし、「十分に良い」メディアの完全なコピーを即座に送信できる、究極の送達が可能なプロトコルは知られていない。ネットワーク上の受信側の存在と、ライブまたはタイムシフトモードでデータを届けようとする意図に基づいて、どれだけの量の情報をネットワークを通じて送るべきか、を判断できるプロトコルはない。さらに、どれだけの量のデータを送信すべきか判断する際に共通に考慮されるその他のファクタとしては、例えば、ネットワーク待ち時間、ネットワークの劣化、パケット損失、パケットダメージ、一般的な回線容量の状態等がある。しかしながら、従来技術のシステムは、受信側のプレゼンスと意図を考慮しない。その結果、データが受信側によってリアルタイムで届けられるということが大前提となる。従来技術のシステムでは、受信側が即座にデータをレンダリングするつもりがなければ、不必要に回線容量を使い、ネットワーク全体のパフォーマンスを引き下げてしまう。
【００１５】
上記の理由により、電話、音声メールおよび戦術的音声通信システムは十分とはいい難い。したがって、音声およびメディア通信の管理システムおよび方法の改良、パケット方式のネットワーク上の音声その他のメディアの改良が必要である。
【発明の概要】
【００１６】
本発明は第１の通信デバイス上で通信するための通信方法に関する。本方法は、ネットワークを通じて１又はそれ以上の参加者との会話のメディアを第１の通信デバイスで受信するステップと、メディアがネットワークを通じて受信される場合、受信メディアを第１の通信デバイス上に記憶するステップとを具える。会話の受信メディアは、ほぼリアルタイムモード、又はタイムシフトモードのいずれかでレンダリングされてもよい。メディアのレンダリングは、記憶されたメディアを取り出し、増加したレンダリング速度で記憶部から取り出されたメディアをレンダリングし、増加した速度で取り出されたメディアのレンダリングが、ネットワークを通じて受信されているときに、会話のメディアをキャッチアップし、かつ、ほぼ同時である場合に、キャッチアップ点を確認し、キャッチアップ点の後に前記ネットワークを通じて受信されているときに、ほぼリアルタイムモードで会話のメディアをレンダリングすることによって、タイムシフトモードからほぼリアルタイムモードに、前記第１の通信デバイス上で遷移されてもよい。
【図面の簡単な説明】
【００１７】
本発明の特定の実施例を示す付属の図面とあわせて以下の説明を読めば、本発明は最良の理解が得られるであろう。
【００１８】
【図１】図１は本発明の通信およびメディア管理システムのアーキテクチャを示す図である。
【図２Ａ】図２Ａは本発明の通信および管理システムのデバイス上で実行するクライアントのブロック図である。
【図２Ｂ】図２Ｂは本発明の通信および管理システムのデバイス上で実行するクライアントのブロック図である。
【図３】図３は本発明の通信および管理システムで使われるサーバのブロック図である。
【図４】図４Ａないし４Ｄは本発明の通信および管理システムで使われるデータペイロードの種々の実施例を示す。
【図５】図５は本発明に係わる共用ＩＰネットワーク上を送信されるデータを示す図である。
【図６】図６は本発明に係わる回路ベースのネットワーク上を送信されるデータを示す図である。
【図７】図７は本発明に係わる、セルラーネットワークおよびインターネットの両者上を送信されるデータを示す図である。
【図８Ａ】図８Ａは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。
【図８Ｂ】図８Ｂは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。
【図８Ｃ】図８Ｃは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。
【図８Ｄ】図８Ｄは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。
【図８Ｅ】図８Ｅは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。
【図８Ｆ】図８Ｆは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。
【図９Ａ】図９Ａはペイロード品質管理部（ＰＱＭ）の動作を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。
【図９Ｂ】図９Ｂはペイロード品質管理部（ＰＱＭ）の動作を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。
【図９Ｃ】図９Ｃはペイロード品質管理部（ＰＱＭ）の動作を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。
【図９Ｄ】図９Ｄはデータ品質管理部（ＤＱＭ）を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。
【図９Ｅ】図９Ｅはデータ品質管理部（ＤＱＭ）を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。
【図９Ｆ】図９Ｆはデータ品質管理部（ＤＱＭ）を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。
【図１０】図１０は本発明のシステムとともに使用されうるグラフィカルユーザインタフェースを有するデバイスの例である。
【図１１Ａ】図１１Ａは本発明の多者間会話管理（ＭＣＭＳ）機能を示す図である。
【図１１Ｂ】図１１Ｂは本発明の多者間会話管理（ＭＣＭＳ）機能を示す図である。
【図１１Ｃ】図１１Ｃは本発明の多者間会話管理（ＭＣＭＳ）機能を示す図である。
【図１１Ｄ】図１１Ｄは本発明の多者間会話管理（ＭＣＭＳ）機能を示す図である。
【図１１Ｅ】図１１Ｅは本発明の多者間会話管理（ＭＣＭＳ）機能を示す図である。
【図１１Ｆ】図１１Ｆは本発明の多者間会話管理（ＭＣＭＳ）機能を示す図である。
【図１２Ａ】図１２Ａは本発明の継続的多者間会話管理システム（ＭＣＭＳ−Ｃ）の機能を示す図である。
【図１２Ｂ】図１２Ｂは本発明の継続的多者間会話管理システム（ＭＣＭＳ−Ｃ）の機能を示す図である。
【図１２Ｃ】図１２Ｃは本発明の継続的多者間会話管理システム（ＭＣＭＳ−Ｃ）の機能を示す図である。
【図１３Ａ】図１３Ａは本発明の動作を詳しく示す一連の図である。
【図１３Ｂ】図１３Ｂは本発明の動作を詳しく示す一連の図である。
【図１３Ｃ】図１３Ｃは本発明の動作を詳しく示す一連の図である。
【図１３Ｄ】図１３Ｄは本発明の動作を詳しく示す一連の図である。
【図１４】図１４Ａ、１４Ｂは本発明のクライアントおよびサーバのアプリケーションを実行させるために使われるハードウェアを示すブロック図である。
【００１９】
図において同じ付番は同じ要素を示すものとする。
【発明を実施するための形態】
【００２０】
付属の図面に示す種々の実施例を参照して本発明を詳細に説明する。以下の説明では、本発明の完全な理解に資するために、特定の実施例について詳細に記載する。しかしながら、当業者にとっては、ここに記載する実施例の幾つかの細部を使用することなく本発明が実施可能であることは明らかである。不要な混乱を避けるために、周知の動作等については詳しい説明を控えたことは、理解できよう。
【００２１】
［Ａ．機能の概要］
本通信メディアの管理方法およびシステムは、音声、ビデオ、テキスト、ロケーション、センサ情報、その他のデータ等の様々なタイプのメディアを使って、音声会話に参加するためのモードをサポートする、および／または多人数による同時会話を管理する新しいモードをサポートする。ユーザは、指定する受信者に音声メッセージを送ることによって会話に加わることができる。受信者は、好みや優先度によってリアルタイムで会話に参加したり、メッセージが検索できることを単に通知だけを受けたりすることもできる。後者の場合は、受信者は都合のよいときに記録されたメッセージを見なおしたり返信したりすることによって、タイムシフトモードで会話に参加する。
【００２２】
ユーザは、次の通信を行う権利を与えられる。すなわち、（ｉ）ほぼ同期性の「ライブ」会話：これは、ユーザに標準的全二重通話と同じ体験をレンダリングする、または（ｉｉ）タイムシフトモード：すなわち、一連の時間差通信。さらに、会話に参加したユーザは、ライブモードからタイムシフトモードに切目なく遷移し、再度ライブモードに戻ることもできる。また、この属性により、ユーザは、会話ごとに優先順位をつけたり二つのモード間を移動したりして、マルチ会話に参加することを可能にする。したがって、このシステム使用する二人の個人は、互いに記録した音声メッセージをやり取りしたり、都合のよいときにそのメッセージをレビューしたりすることができる。また、メッセージをある速度で送り基本的にライブに合流させ、音声同時通話を実現する。この新しい通信の形式は、本発明の目的から、「ヴォクシング：Ｖｏｘｉｎｇ」と呼ばれる。
【００２３】
誰かと「ヴォクス：Ｖｏｘ」すると、その会話は一連の不連続な記録されたメッセージで構成され、沢山のロケーションに記録される。また、「ヴォクス」には、送信側のエンコードデバイス（例えば、電話またはコンピュータ）を含み、ネットワーク上の複数の送信ホップ上のサーバ、さらに受信側のレンダリングデバイスが含まれる。標準的な通話または音声メールとは異なり、このシステムは次のような機能と利点を提供する。（ｉ）会話がライブとタイムシフトまたはその逆を遷移できる。（ｉｉ）会話の不連続なメッセージは、意味論的に束ねられアーカイブされる。（ｉｉｉ）メッセージは記録され後で検索できるから、注意を一時的に会話からそらしても、後で都合のよいときに会話をレビューすることができる。（ｉｖ）会話は数秒、数分、数時間または数日間中座し、そこから再開することができる。（ｖ）進行中の会話に再度加わることができる、見損ねたメッセージを即座にレビューすることができる、または現在のメッセージにキャッチアップすることができる（すなわち、ライブメッセージ）。（ｖｉ）従来の通話のように、会話をするのに特別の回路を必要としない。（ｖｉｉ）個人またはグループに送信するだけで会話が始められる。メッセージを受信していることに気がついたら、相手方の人は、リアルタイムでレビューし会話を行うか、後にレビューか自由に選択することができる。
【００２４】
また、通信メディア管理システムは、ネットワークを通じてのデータ送信を最適化する新しいモードをサポートする。ネットワークの状態が理想より悪い場合は、システムはペイロードを会話に参加している受信側に送達するのをアクティブにリアルタイムで管理する。例えば、ネットワークの状態が悪いときは、システムは送信用のデータの質を、受信側が受け取ったときにレンダリングするのに「十分に良い」レベルまで意図的に引き下げ、リアルタイムの会話に参加できるようにする。また、システムは、メッセージの「正確な」コピーを長い時間をかけて最終的に送達することを保証する。したがって、本システムおよび方法は速度と精度の両方の利点を提供する。受信側の存在および受信側がリアルタイムで即座にメッセージを見る意思があるかどうか、ネットワーク待ち時間、ネットワークの劣化、パケットの損失またはダメージおよび／または現在の回線容量の状態の測定に基づいて適時性とメディアの質との間でトレードオフを行うことによって、ネットワーク回線容量が最適に利用できるようにする。
【００２５】
ここで、会話のメッセージが含むことができるのは、音声のみ、または音声、ビデオおよびセンサ情報、その他のデータである。メッセージがレビューされるとき、メッセージに含まれるメディアのタイプによって、耳で聞かれる、視覚的にレビューされる、または、その組み合わせである。本発明の申請段階では、ほとんどの会話は音声のみであるが、ここに記載する通信システムおよび方法は、例えば、音声およびビデオ等の複数のメディアタイプを含む会話を広く含むことを意図している。
【００２６】
次の特徴や機能のうちの一またはそれ以上を提供する、改良型音声その他のメディア通信、管理システムおよび方法を開示する。
ｉ．ユーザが、ライブ通話、会議通話、音声メッセージ、継続的または同時通信等を含む多くのタイプの会話に参加可能にする。
ｉｉ．ユーザが、会話のメッセージをライブモードまたはタイムシフトモードのどちらかのモードでレビュー可能にする（音声メッセージ）。
ｉｉｉ．ユーザが、同時「ライブ」モードとタイムシフトモードの間で会話を切目なく遷移することを可能にする。
ｉｖ．他の参加者またはネットワークとの接続が確立されるのを待たずにユーザが会話に参加することを可能にする。この属性は、利用できるネットワークがない、ネットワークの質が悪い、他の参加者が参加できない場合でも、ユーザに会話を始める、会話に参加する、以前に受信しタイムシフトされた会話のメッセージをレビューすることを可能にする。
ｖ．システムに、送信側のメディアのペイロードデータの記憶を可能とし、ネットワーク送信後、全ての受信側にメディアのペイロードデータの記憶を可能とする。
ｖｉ．システムに、所定の会話において、各メッセージが識別でき、かつ所定の参加者に結びつけることができる、意味論的に有意味の会話にスレッディングすることによって、メッセージを組織化できるようにする。
ｖｉｉ．ユーザに、一組のユーザコントロール機能を使って、「ライブ」をレビュー、レビューするのに都合がいい時まで会話を休止またはタイムシフトする、様々なモードで再生する（例えば、早送り、ライブにキャッチアップする、会話の頭にジャンプする）、会話を管理する方法（アーカイブする、タグ付けする、検索する、アーカイブから取り出す）等、各会話を管理可能にする。
ｖｉｉｉ．システムに、オンラインの状態、所定のメッセージをライブかタイムシフトモードのどちらかでレビューする意図、メッセージに対する現在の注意、レンダリングの方法、および送信側と受信側の間のネットワークの状態を含む、参加データの管理を可能にし、全ての会話参加者と共有化可能とする。
ｉｘ．下記の場合は、ユーザが、マルチ会話を同時に管理することが可能にする。（ａ）１つの会話を進行、その他の全てを休止とする、（ｂ）戦術的通信のような（これに限らず）マルチ会話を継続してレンダリングする、（ｃ）株取引すなわち取引フロア環境などのマルチ会話は、アクティブかつ同時にレンダリングする。
ｘ．ユーザに、全ての会話を記憶可能にし、望むなら、有形の表現媒体に持続的にアーカイブし、必要に応じ組織化、インデックス付け、検索、転記、翻訳および／またはレビューできる資産をレンダリングする。
ｘｉ．システムが、即座にレンダリングする上で「十分に良い」速度でメッセージを送達するうえで最善のモードを使って、リアルタイム通話機能をレンダリング可能にする（ＵＤＰと同様）。また、もともと記憶された完全なコピーから、紛失あるいは欠陥のあるデータの再送を要求し、最終的にメッセージの完全なコピーの送達を保証する（ＴＰＣと同様）。
ｘｉｉ．受信側のプレセンスおよび意図（すなわち、リアルタイムまたはタイムシフトモードでのメディアのレビュー）を使うと同時にネットワーク待ち時間、ネットワークの劣化、パケットの損失あるいはダメージおよび／または現在の回線容量の状態を測定し、システムに、適時性とメディアの質の間でトレードオフを行いネットワーク回線容量の利用を最適化することを可能とする。
【００２７】
種々の実施例において、上に挙げた様々な特徴や機能の一部又は全部が実施可能である。しかしながら、本発明の別の実施例においては、上に列挙した特徴や機能の全てを組み込む必要がないことは理解できよう。
【００２８】
［Ｂ．用語の解説］
本発明の詳細を説明するに先立ち、本明細書全体を通じて使用される幾つかの用語と略語を定義する。この用語解説は、システム構成、メディア、メディア管理、人と会話管理のグループに分類できる。
【００２９】
［Ｂ．１．システム構成］
クライアント：クライアントは、通信システムの中のユーザアプリケーションを意味し、ユーザインタフェース、持続的データ記憶装置、および「ヴォクシング（Ｖｏｘｉｎｇ）」機能を含む。ユーザは、クライアントアプリケーションと情報のやりとりをし、クライアントアプリケーションは、ネットワークを通じて送受信される全ての通信（メッセージおよび信号）およびペイロード（メディア）転送を管理する。クライアントは、メディアのエンコード（例えば、音声、ビデオまたは他のデータのコンテンツの取得）、メディアのレンダリングをサポートし、セキュリティ、暗号化、認証およびネットワーク上のデータ送信の最適化をサポートする。クライアントは１個ないし複数のユーザ（すなわち、マルチテナント）によって使用することもできる。
【００３０】
デバイス：クライアントアプリケーションを実行する物理的デバイス。ユーザは、一個のデバイスまたは複数のデバイスによって、所定のいずれの時点でもアクティブにログインすることができる。種々の実施例において、デバイスは、汎用コンピュータ、携帯計算機、プログラマブル電話機、プログラマブルラジオまたはその他のどんなプログラマブル通信装置であってもよい。
【００３１】
サーバ：通信ネットワーク上のコンピュータノード。サーバは、ネットワーク上のユーザ間でやり取りされる送信メッセージのルーティングおよびメディアペイロードの持続的記憶とアーカイブの役割を持つ。サーバは、ルーティング、トランスコーディング、セキュリティ、暗号化と認証およびネットワーク上のデータ送信の最適化を提供する。
【００３２】
［Ｂ．２．メディア］
メッセージ：あるユーザから他のユーザへの個々の通信単位。各メッセージは音声またはビデオ等の何らかのメディアからなる。各メッセージは、以下の属性のどれかを割り当てられる。（ｉ）メッセージ送信側のユーザ、（ｉｉ）所属している会話（ｉｉｉ）、オプション、またはユーザ作成の重要タグ、（ｉｖ）タイムスタンプ、（ｖ）メディアペイロード
【００３３】
メディア：音声、ビデオ、テキスト、位置、温度等のセンサの読取り値、その他のデータ。
【００３４】
会話：デバイス上で２人以上のユーザ間の一連の（識別され、持続的に記憶されグループ化され優先順位をつけられた）メッセージ。ユーザは、一般にデバイスを用いてリアルタイムまたはタイムシフトモードでメッセージをレビューするか、望みに応じて会話のメッセージを作成、送信することによって会話に参加する。新しいメッセージを作成すると、新しい会話を定義するか、既存の会話に加えられる。
【００３５】
会話のヘッド：直近の話者によってエンコードされた会話の直近のメッセージ。「ライブ」をレビューするとき、会話においてユーザが存在しているところ、すなわち「ライブへジャンプ」機能を使用する場合、ジャンプするところ。
【００３６】
多者間会話管理システム（ＭＣＭＳ）：クライアントアプリケーションの一部として実行するアプリケーションで、ユーザが様々なタイプのメディアを用いてマルチ会話に参加することを可能にする。現在の会話のメッセージのみがレンダリングされている場合、ユーザはＭＣＭＳアプリケーションを用いて、現時点として、マルチ会話の中から１つの会話を選択することができる。選択された現在の会話については、ユーザはタイムシフトモードでのメッセージの一連のやり取りから、標準的な電話会話と同様のほぼ同期性の「ライブ」モードに遷移でき、またタイムシフトモードに戻ることができる。選択されなかった会話のメッセージは休止状態に置かれる。他の人がまだこれらの会話参加している場合は、選択されなかった会話に関するメッセージは、蓄積されていく。ユーザは、マルチ会話の中から現在の会話に選択的に遷移し、選択された現在の会話の蓄積されたメッセージをレビューすることができる。
【００３７】
継続的多者間会話管理システム（ＭＣＭＳ−Ｃ）：付加されたレンダリング機能によって、システムによって自動的に管理される優先順位とタイムシフトの階層的なシステムを通じて、ＭＣＭＳと同様にユーザにマルチ会話を管理し継続して参加することを可能にする機能。現在選択されている会話メッセージのみをレンダリングできるＭＣＭＳとは異なり、ＭＣＭＳ−Ｃアプリケーションは、継続する会話のメッセージを、優先順位をつけた順序でレンダリングすることができる。ＭＣＭＳ−Ｃは特に次のような状況で利用できる。すなわち、継続する会話のメッセージを、優先順位をつけた順序でレンダリングすることが重要な場合、および／または低い優先順位の会話に属していても、全てのメッセージを受信することがリアルタイムでメッセージを受信するよりも重要な場合。ＭＣＭＳ−Ｃが適する状況の例としては、病院、タクシー全車両管理、戦術的通信などがあるが、これに限定されるものではない。
【００３８】
同時多者間会話管理システム（ＭＣＭＳ−Ｓ）：ＭＣＭＳと同様、選択された現在の会話だけのメッセージがレンダリングされるＭＣＭＳとは対照的に、追加機能によってＭＣＭＳ−Ｓを使って同時レンダリングするマルチ会話を選択可能にする。ＭＣＭＳ−Ｓアプリケーションは、一人のトレーダーが異なる為替について複数のブローカーに聞いており、一人ないし複数のブローカーに取引要請を時折送信しているような、１個のユーザがマルチ会話を同時に聞いている状況に、特に適用できる。また、ＭＣＭＳ−Ｓは戦術的通信にも適している。
【００３９】
優先順位：ユーザがＭＣＭＳ−Ｃに参加しているときに、つぎにどのメッセージをレンダリングするかシステムが決める機構。優先順位はシステムによって自動的に管理される。ユーザは、デフォルトで優先順位を設定できる、または予め決められた一組のシステム優先順位を使うこともできる。衝突が生じた場合、すなわち、１個以上のメッセージが同時にレンダリングされようとしているときは、システムは、少なくとも部分的に優先順位に基づいて衝突を解決し、どのメッセージを即座にレンダリングし、どのメッセージをタイムシフトするか決める。
【００４０】
タグ：ユーザまたはシステムが、会話またはメッセージに割り当てることができる一組の属性で、それによってデータを検索したり組織化したりできる、トピック（会社名）、命令（「動作項目」）、標識（「会話のサマリー」）、その他ラベル等。
【００４１】
重要タグ：他の優先順位の設定にかかわりなく、あるメッセージがレンダリングされるべきときに、送信側に指定可能とする特別のメッセージ属性。例えば、「緊急」の重要タグは、他の優先順位を無効にする。この機能は、戦術的なシステムにとっては重要な意味を持つが、どんなシステムでも、この機能を使えるようにしたり、無効にしたり設定することができる。
【００４２】
パケット：コンピュータネットワークを通じてルートを決めることができるバイナリデータの単位。各パケットは、ヘッダ（メタデータ）およびペイロード（メディアデータ）からなる。インターネットプロトコル（ＩＰ）、ＥｖＤＯ、ＵＭＴＳその他のパケットベースのネットワーク、無線、光ファイバー、有線のいずれかの標準的なパケットプロトコルが含まれるが、これに限定されものではない。
【００４３】
ヘッダまたはパケットヘッダ：パケットを記述するパケットの部分、ペイロードに関するメタデータ、エンコードのタイプおよび宛先。
【００４４】
Ｖｏｘパケット：システムと方法をさらに精緻化し、メッセージメディア、その他の信号情報の送達を最適化することを可能にする専用パケット。
【００４５】
メディアペイロード（またはペイロード）：パケットの実のメディア部分。
【００４６】
［Ｂ．３．メディアの管理］
タイムシフト遅延（ＴＳＤ）：Ｖｏｘパケットの着信とパケットのデバイス上でのレンダリングとの間の時間の量。ＴＳＤは最小タイムシフト遅延を上回らなければならない。ＴＳＤは、主として、受信後のユーザが会話のメッセージをレビュー選択しようとする動作によって決められる。
【００４７】
最小タイムシフト遅延（ＭＴＳＤ）：クライアントによって強制されるタイムシフト遅延で、ジッタバッファ技術を用いてジッタ加工することができるようにする。これは、使用可能なメディアストリーム作るのに適当な数のパケットが到着するまで、システムにレンダリングの遅延を行わせる。システムは、時間の経過に応じてＭＴＳＤを順応的に調節し、主としてネットワークにおける変動条件を補正する。
【００４８】
レンダリング：ユーザの消費に適した形式でユーザにメディアストリームを送達すること（例えば、音声、テキスト、グラフィック表示、ビデオ、またはそれらの組み合わせ）。
【００４９】
ミキシング：一またはそれ以上のメディアストリームをレンダリングすること。例えば、レンダリングするとき、会話の二人の参加者からのメディアストリームをミックスし、複数の人が同時に話しているのと同じ会話感覚をユーザに作ること。
【００５０】
エンコード：ユーザ作成の（音声またはビデオ）メディアか、デバイス上で別途生成される（ＧＰＳまたはその他のセンサデータ）メディアを翻訳し、クライアントによって処理されるようにメディアをデジタルデータに変換するプロセス。
【００５１】
適応ジッタバッファ：ジッタバッファまたはデジッタバッファを使い、ネットワークを切り換えたパケットによって導入されたジッタ（すなわち、シーケンスから外れたパケットの着信またはパケットの遅延着信）に対抗し、ネットワーク上を送信される音声（またはビデオ）信号の連続レンダリングが途切れずに行われるようにする。レンダリングする前に、データはバッファに記憶され、適当なサイズにされたメディアのバッファが着信できるようにする。質と流れのトレードオフを行うことによって、全てのパケットが受信される前にメディアをレンダリングすることができる。適応ジッタバッファは、サイズをダイナミックに変え、遅延−質トレードオフを最適化することができる。
【００５２】
無限連続メッセージバッファ（ＰＩＭＢ）：ＰＩＭＢは、タイムベースのメディアを記憶する記憶部の管理システムであり、「ライブ」データのジッタの削除とアーカイブされたデータの保存と取出しの両方を行う。さらに、ＰＩＭＢは付加的属性として、潜在的に無限にメディアの継続保存をおこなう。ＰＩＭＢは、一部又は全ての参加者のデバイスおよび／またはサーバにて、メッセージと会話のＶｏｘパケットを、「完全な」すなわちフルコピーで維持する。
【００５３】
パケット損失補償または隠蔽（ＰＬＣ）：メディアストリームをレンダリングする間に、ＰＬＣコンポーネントは、紛失パケットの補償を行い、結果を補間し、閲覧者にストリームを提供する。紛失パケットは無音としてレンダリングするか、近接するパケットからの情報を使い、補間した音またはイメージ提供することもできる。使用される個々の方法は、メディア、使用コードおよびその他一般に既知のパラメータによる。
【００５４】
［Ｂ．４．人］
ユーザ：システムを使う権限を与えられた人。
【００５５】
コンタクト：システムのユーザまたは非ユーザの記録。ユーザは、主としてコンタクトのリスト上のメンバーとともに会話に参加する。従来の電話、ラジオ又はその他の非クライアント１２が使用可能なデバイスを使ってシステムにアクセスまたはシステムを使うユーザは、非ユーザである。
【００５６】
グループ：多数のコンタクトの集まり。コンタクトは、グループに選択的に加えられたり、グループから削除したりできる。グループの中で会話が始まれば、グループの全てのメンバーは参加することもしないこともできる。
【００５７】
チャンネル：主として戦術的通信システムに使われる。チャンネルはグループと同様、チャンネルで多数のコンタクトを結び付ける。
【００５８】
参加者：会話のメンバーとして識別される人。ユーザまたは非ユーザが参加者になりうる。
【００５９】
［Ｂ．５．会話の管理］
タイムシフト：タイムシフトは、メッセージを受信した後、ユーザ受信者の判断によって、随時実行できる。タイムシフトによって、ユーザは、メッセージを下記の方法でレビューするこができる。（ｉ）ＭＴＳＤ後、オンデマンドで、即座にレンダリングする、（ｉｉ）ユーザの裁量により、タイムシフトモードでメッセージをレビューする、（ｉｉｉ）古い会話を検索、再構成のためにアーカイブから、（ｉｖ）別の優先順位の高いメッセージ（会話）のレビューに便宜を図るために一定の遅延時間の後、および／または、（ｖ）メッセージを再度聞いたり理解したりすることが必要な場合は繰り返して。言い換えれば、タイムシフトは、システムによってＭＴＳＤが強制された後、ユーザがメッセージを随時レンダリングできることである。
【００６０】
レビュー：メッセージの中のメディアのコンテンツを聞く、見る、読む、または閲覧すること。レビューは、ほぼ同期性のリアルタイム「ライブモード」かタイムシフトモードのいずれかで行うことができる。
【００６１】
意図：以下を把握するユーザ定義の属性；（ｉ）ユーザが会話のメッセージを即座にレビューしたいと望んでいるか、タイムシフトモードでメッセージをレビューしたいと望んでいるか、（ｉｉ）ユーザの動作に含まれている意思、または（ｉ）と（ｉｉ）の組み合わせ。
【００６２】
注意：現瞬間にユーザが所与の会話のメッセージをレビューしているか否かを把握するためのユーザの属性。
【００６３】
ライブにキャッチアップ（ＣＴＬ）：「ライブにキャッチアップ」ために、会話の頭にないユーザが、先行するメッセージをより早くレビューすることができる（すなわち、会話の頭に）、レンダリングモード。ＣＴＬ機能は、メッセージの早送り、メッセージのメディアの中にあるギャップの除去、躊躇粒子の除去等数多くあるキャッチアップ技術のうちどれを使っても良い。ユーザがライブに追いついたらシステムは途切れずにライブ会話に遷移する。これは、会議通話、例えばユーザが出席者の注意を一時的に会話から引き離し、再び戻ったときに全体の会話を聞きたい、といった状況のときに非常に役立つ機能である。
【００６４】
キャッチアップモード：ユーザ設定あるいは予め設定されたモードで、どのようにしてＣＴＬプロセスがキャッチアップするか決める（すなわち、もっと早く実行する、無音、躊躇粒子の除去またはそれらの組み合わせ）。
【００６５】
ライブへジャンプ（ＪＴＬ）：この機能により、ユーザは現在の位置から会話の頭へジャンプすることができる。ユーザが、会話における現在の位置と頭の間にある全てのメッセージをレビューすることを望まないとき主としてこのＪＴＬ機能を使う。ＪＴＬ機能を実行すると、ユーザは途中にある全てのメッセージをスキップし、会話の頭にある「ライブ」メッセージのレンダリングを開始する。
【００６６】
ＭＣＭＳ参加者の属性：所定の会話を行うためにユーザが定義し、ユーザの動作からシステムが解釈する、管理者が割り当てる一組の属性か、または、その組み合わせで受信側の意図、注意、優先順位、レンダリングの好みを定義する。属性には以下のものが含まれるが、これに限定されない。（ｉ）受信側が会話のメッセージに対してレンダリングしたいときの意図。可能性のある意図値には以下のものが含まれる：「今」、「タイムシフト」、「ライブにキャッチアップ」（ＣＴＬ）、「休止」、「決してない」など。（ｉｉ）キャッチアップモード。ＣＴＬプロセスがどのようにして受信側をライブにキャッチアップさせるかを決める設定（すなわち、早く実行する、無音ギャップ又は躊躇をスキップするまたは常用速度で実行する）。（ｉｉｉ）タイムシフト遅延（ＴＳＤ）、会話における受信側の現在位置が会話の頭からどれだけ離れているかを定義する。（ｉｖ）受信側における他の会話に関するメッセージの優先順位。
【００６７】
［Ｃ．システムアーキテクチャ］
図１は、本発明の一実施例に係わる通信とメディアの管理システムのブロック図を示す。システム１０は、デバイス１３１ないし１３ｎ上でそれぞれ動作する複数のクライアント１２１ないし１２ｎを含む。デバイス１３は、一またはそれ以上のサーバ１６を含む通信サービスネットワーク１４上で互いに通信を行う。一またはそれ以上のネットワーク１８１〜１８ｎがレンダリングされて、複数のデバイス１３１ないし１３ｎを通信サービスネットワーク１４に連結する。様々な実施例において、ネットワーク１８は、公衆交換電話網ネットワーク（ＰＳＴＮ）、セルラーネットワークに基づくＣＤＭＡ又はＧＳＭ、例えば、インターネット、戦術的な無線ネットワーク、その他の通信ネットワーク、またはその組み合わせであっても良い。通信サービスネットワーク１４は、いろいろなネットワーク１８１〜１８ｎとの通信のトップあるいはその中のネットワーク層である。様々な実施例においては、ネットワーク層１４は、異機種環境か同機種環境である。クライアント１２１〜１２ｎは、「Ｖｏｘパケット」と呼ばれる以下に詳述する個人メッセージ装置を使って、ネットワーク１８１〜１８ｎ上のサーバ１６、およびネットワーク１４と互いに通信を行う。
【００６８】
［Ｄ．クライアントアーキテクチャ］
図２Ａおよび２Ｂは、デバイス１３上で動作するクライアント１２のブロック図を示す。図２Ａに示すように、クライアント１２は、多者間会話管理システム（ＭＣＭＳ）アプリケーション２０、レンダリング−エンコードモジュール２１およびＭＣＭＳアプリケーションデータベース２２を含む。図２Ｂに示すように、クライアント１２は、永続的無限メッセージバッファ（ＰＩＭＢ）リーダ２６が付いた記憶・ストリーム（ＳＡＳ）モジュール２４、ＰＩＭＢ書込み部２８、ＰＩＭＢデータベース３０、データ・ネットワーク品質（ＤＮＱＳ）記憶部３２およびメディアドライバ・エンコダハードウェア３４をさらに含む。ＭＣＭＳアプリケーション２０と記憶・ストリームモジュール２４は、それぞれメッセージハンドリングモジュール２５ａおよび２５ｂを介して互いに通信を行う。クライアント１２は、さらに、認証−暗号化セキュリティモジュール４０および通信プロトコルモジュール４４を含む。
【００６９】
モジュール４０は、クライアント１２との間で「ヴォクス（Ｖｏｘ）」パケットの送受信を行う間、認証、暗号化およびセキュリティのサービスをレンダリングする。通信プロトコルモジュール４４は、Ｖｏｘパケットを、データを送信するときにクライアント１２を作動させ、データを受信するときにネイティブパケットからＶｏｘパケットをカプセルから取り出すデバイス１３に接続された下層のネットワーク１８によって使われるネイティブパケットにカプセル化する。モジュール４０および４４は、クライアント１２間での、マルチ端末同士の認証、暗号化およびセキュリティをレンダリングする。メッセージは、ネットワーク１８１〜１８ｎとネットワーク１４上で、第一の送信デバイス１３から第二の受信デバイス１３まで、認証され、暗号化され、保全される。
【００７０】
［Ｄ．１．１．ＭＣＭＳデータベース］
データベース２２は、コンタクトおよび参加者、会話およびメッセージ（ライブ、保存済み）、初期設定の優先順位、およびサーバ１６に関する情報を含む、システム１０内の多くの要素のための永続性のメタデータを記憶、管理する。さらに、ＭＣＭＳデータベース２２は、ユーザの会話、プレゼンス、およびステータス等の逐次オペレーションデータやユーザと話をしている全ての参加者、およびユーザのコンタクトリスト上のオペレーションデータなどを記憶する。例えば、会話とメッセージに関しては、データベース２２は、会話のどのメッセージをユーザがレビューしたかまたはしなかったか、クライアント１２が参加者であった会話ごとの優先順位、およびライブ−キャッチアップステータスなどのステータス追跡情報を保持する。それには、プレゼンス、全ての参加者のステータス、および他のネットワークおよびシステムの管理データが含まれる。
【００７１】
［Ｄ．１．２．ＭＣＭＳアプリケーション］
ＭＣＭＳアプリケーション２０は、いろいろなメディアおよびデータタイプ（音声、ビデオ、テキスト、ロケーション、データなど）を用いて、参加している会話および／または管理しているマルチ会話のいろいろなヴォクシングモードサポートする。ユーザは、クライアント１２を可能にしたデバイス１３を使って指定された受信側にメッセージを送信することにより、会話に参加する。好み、優先順位よって、受信側は、リアルタイムでメッセージをレビューする、あるいは単にメッセージがレビューできる状態にあることに気がつく。ユーザは、タイムシフト（音声メッセージ）モードまたはほぼ同期性でレビューした一連のメッセージのやり取りから全二重の会話（標準的な「ライブ」通話と同じ）に遷移し、再び音声メッセージに戻ることができる。ＭＣＭＳアプリケーション２０は、別の進行中の会話の中のどのメッセージも失うことなく、ユーザがリアルタイムで最も重要な会話との相互作用をコントロールできるようにする。例えば、ＭＣＭＳアプリケーション２０は、現在レビューしていない会話の中から、緊急の通信すなわち優先順位の高い通信をユーザに通知する。また、ＭＣＭＳアプリケーション２０は、随時レビューができるように、後の検索のために全ての会話の全てのメッセージを記憶することを可能とする。
【００７２】
種々の実施例によれば、ＭＣＭＳアプリケーション２０には、以下のような幾つかの異なった動作モードがある。すなわち、それぞれメッセージの連続的なレンダリングと同時レンダリングをサポートする、ＭＣＭＳ−継続（ＭＣＭＳ−Ｃ）とＭＣＭＳ−同時（ＭＣＭＳ−Ｓ）である。それぞれの実施例について、以下詳細に説明する。特に断らない限り、用語「ＭＣＭＳ」は、一般に前記異なる２つのモードを含むＭＣＭＳアプリケーション２０を意味する。
【００７３】
ＭＣＭＳアプリケーション２０は、多くのモジュールとサービスを含む多層構造のアーキテクチャである。モジュールとサービスには、以下のものが含まれる。すなわち、ＭＣＭＳデータベースモジュール２０ａ、ＳＡＳサービスモジュール２０ｂ、メッセージ／信号サービスモジュール２０ｃ、ユーザインタフェースアプリケーション・プログラミングインタフェース（ＡＰＩ）２０ｄ、ユーザインタフェースモジュール２０ｅ、会話／メッセージ管理サービス部２０ｆ、優先順位サービス部２０ｇ、コンタクトサービス部２０ｈ、プレゼンス／ステータスサービス部２０ｉ、およびメッセージ／信号サービス２０ｊである。
［Ｄ．１．２．１ ＭＣＭＳデータベースモジュール］
【００７４】
ＭＣＭＳデータベースモジュール２０ａは、ＭＣＭＳアプリケーション２０がＭＣＭＳデータベース２２にアクセスするために必要な全ての機能コールを管理するサービスモジュールである。
【００７５】
［Ｄ．１．２．２ ＳＡＳサービスモジュール］
ＳＡＳサービスモジュール２０ｂは、ＭＣＭＳアプリケーション２０と記憶・ストリームモジュール２４との間の通信と調整を可能にする、それぞれメッセージハンドリングモジュール２５ａ、２５ｂを介してやり取りする一組の機能コールを含む。一組の機能コールは、ＭＣＭＳアプリケーション２０と記憶・ストリームモジュール２４の両者に必要に応じてユーザに呼び出されたときにいろいろなヴォクシング機能を動作させ、および／またはネットワークの状態によって指示されたように実行することを可能にする。ＳＡＳサービスモジュール２０ｂによって実行される機能の中にはメッセージ通信およびメッセージ認識のステータス、メッセージをレンダリングするための命令、およびユーザのステータスとプレゼンスの維持と通信が含まれる。
【００７６】
［Ｄ．１．２．３ メッセージ／信号サービスモジュール］
メッセージ／信号サービスモジュール２０ｃは、クライアント１２とサーバ１６の両者の上で動作し、システム１０のクライアント１２とサーバ１６との間で通信を可能とする。この通信は、メッセージ、データおよびその他の信号を含み、クライアント１２とシステム１０が、通信、ネットワークステータス、ユーザ、およびユーザステータスの追跡と管理ができるようにする。サーバ１６上で動作するクライアント１２とメッセージ／信号サービスモジュール２０ｃの間で送られるメッセージと信号のタイプは、例えば、以下を含む。すなわち、ユーザのネットワーク利用可能性、メッセージ全体またはメッセージの一部が失われていないか判断するためにサーバ１６がクライアント１２に送ったメッセージ（恐らく「高水位マーク」を含む）の追跡（例えば、「作成中の」クライアントによって作成された会話につき参加者当りのシーケンス番号）、ユーザが所定の会話のメッセージを話しているかまたはレビューしているかどうか、どこでユーザが会話の頭に関わっているか、いつ参加者が会話のライブをレビューしていないか、などである。これらは、クライアント１２上のメッセージ／信号サービスモジュールとサーバ１６との間で送られるメッセージと信号の多くのタイプの中の２、３の例であって、本発明はこれに限定されると解釈すべきではない。
【００７７】
［Ｄ．１．２．４ ユーザインタフェースＡＰＩ］
ユーザインタフェースＡＰＩ ２０ｄは、ＭＣＭＳアプリケーション２０のユーザインタフェースモジュール２０ｅと下層サービスとの間のプログラミングインタフェースを定義する、一組の機能コールを定義するモジュールである。ユーザインタフェースＡＰＩ ２０ｄは、ＵＩアプリケーションサポート、ユーザインタフェースがＭＣＭＳアプリケーション２０を作動させるために必要な全ての機能コールなどの汎用的方法サポートする。種々の実施例において、ユーザインタフェースＡＰＩ２０ｄは、クライアント１２が、以下にあげるの広範囲のユーザインタフェースとデバイスタイプをサポートすることを可能とする。すなわち、アドビフラッシュベースのアプリケーションおよび／またはマイクロソフト社のＷｉｎｄｏｗｓ（登録商標）アプリケーション、セルラーまたはモバイルホンデバイス、トーンで駆動されるＰＳＴＮデバイス、音声ユーザインタフェース（ＶＵＩ）、および物理的無線通信インタフェース等。種々の実施例において、ユーザインタフェースＡＰＩモジュール２０ｄは、高度のフレキシビリティと高度に制約されたユーザインタフェースの設計によってＭＣＭＳアプリケーション２０の機能性をサポートすることを可能とする。
【００７８】
［Ｄ．１．２．５ ＭＣＭＳユーザインタフェースモジュール］
ＭＣＭＳユーザインタフェースモジュール２０ｅは、クライアント１２の音声・ビデオユーザインタフェースの動作および機能をサポートする。ユーザインタフェースモジュール２０ｅは、ユーザ相互作用のホストをサポートし、下記のさまざまな相互作用媒体で実現することができる。すなわち、デバイス１３上のグラフィカルユーザインタフェース・スクリーン、音声／ＤＴＭＦインタフェース、音声ユーザインタフェースで、その全てのがユーザに、システム１０とインタフェースで接続することを可能にする。サポートされるユーザ相互作用の一部リストは以下を含む。例えば、機能する；ログインする；会話を管理する、参加する、モニタする；会話のレンダリングをコントロールする；優先順位を管理する；会話をアーカイブしたレビューすることを要求する。このリストは、例示としてあげたものであり、本発明を限定するものと解釈されるべきではない。
【００７９】
［Ｄ．１．２．６．会話／メッセージ管理サービス］
会話／メッセージ管理サービス部２０ｆは、一組の機能を定義するモジュールである。これは、ユーザが会話の参加者間で送受信したメディア（例えば、音声またはビデオコンテンツメッセージ）の受信とレビューを管理するうえで必要とする全ての情報を管理、保持する役目のデータ構造および処理を管理する。メッセージは、会話に組織される。アプリケーション１２を実行しているデバイス１３によって送受信されたメディアは、受信中に即座にレビューすることができる。また、受信メディアは、タイムシフトモードでレビューするため、会話管理、およびアーカイブする目的で、記録される。他の実施例においては、メッセージまたは会話は、希望の保持条件を指定して、オプションとして一時的にマーク付けすることもできる（例えば、一部のメッセージは、即座のレンダリング要求を無視して、保持または記憶されない）。さらに他の実施例においては、メディアはタイムシフトモードだけでレビューする目的でオプションとしてマーク付けされ、受信後即座にレビューすることはできない。
【００８０】
会話／メッセージ管理サービス部２０ｆは、さらにユーザの現在の会話すなわち進行中の会話をそれぞれ随時受信中のクライアント１２にメディアを送信可能にし、受信側の動作に関わらず、受信中のクライアント１２は、これらのメッセージを適当な会話を切れ目なく結び付ける。
【００８１】
会話／メッセージ管理サービス部２０ｆにより、全ての会話は基本的に非同期性となる。もし、二つのユーザが所定の会話にアクティブに加わり、および通信間のユーザ制御の遅延が最小であれば、現在の電話またはＶｏＩＰ会話と同じく、非同期の全二重の会話となる。もし、どちらか一方のユーザの参加が遅れた場合、理由のいかんを問わず、会話は非同期の音声（またはその他のメディア）メッセージにドリフトする。代替的な実施例においては、会話は、非同期のメッセージのみあるいは同期メッセージのみとしてオプション的にタグ付けすることができる。これらのケースのどちらか一方においては、タグ付けがリセットされない限り、会話は二つのモードの間でドリフトすることはできない。タグ付けのリセット後は、会話は、ほぼ同期性（すなわち、ライブまたはリアルタイム）と非同期（すなわち、タイムシフトされたメッセージまたは音声メッセージ）モードの間で再度流れることができる。
【００８２】
会話／メッセージ管理サービス部２０ｆは、漸次メッセージの送受信の処理を行う。送信するとき、メディアが作成されても良く、メッセージは同時にエンコード、記憶され、送信される。すなわち、メッセージの送信は、ユーザによるメディアの生成と同時に（すなわち、デバイス１３に話す間、またはビデオ生成中に）始まっても良い。受信サイドでは、メッセージの受信、記憶およびレンダリングの全てのが漸次行われる。メッセージは、レンダリングされる前は、完全に受信される必要はない。メッセージのレンダリングは、メッセージがＭＴＳＤまで送達されると同時に始まっても良い。さらに、サービス２０ｆは、出力メッセージの送信と入力メッセージのレンダリングを同時に行うことができる。サービス２０ｆの漸次性により、ユーザは後の検索とレビューのために会話のメディアの記憶とストリーム中に、ここに記述するその他機能も同様、ライブ会話に参加することができる。
【００８３】
会話／メッセージ管理サービス部２０ｆによるメッセージのタイムシフトによって、もし、先行するメッセージを逃したときまたは他の会話に加わっていたとき、ユーザは、会話に「ライブにキャッチアップ」することができる。このタイムシフト処理により、ユーザは、グループ全体またはチャンネル全体にメッセージを繰り返してくれるように要求を出す必要がなくなる。古いメッセージは、時間を節約するために、可能性として高速で随時再生することができる。ユーザはメンバーのメッセージや個人のメッセージを簡単に行ったり来たりスキップできる。レビュープロセスは、低い優先順位のメッセージを潜在的にスキップするようにメッセージ優先順位ベースで構成することもできる。
【００８４】
一実施例において、会話／メッセージ管理サービス部２０ｆは、特定の参加者（話者）によってメッセージを識別し、同時に送達された会話のメッセージをデフォルトで混合する（ＭＣＭＳ−Ｓ）。任意の実施例において、ユーザは異なる会話の参加話者の通信を別個にレビューすることもできる。
【００８５】
さらに会話／メッセージ管理モジュール２０ｆは、参加者同士で会話を共有することができ、その参加者をアクティブ会話またはアーカイブの会話に加えることができる。一実施例において、会話に加えられた参加者は、会話へのアクセスが与えられ、その会話の先行のメッセージを取り出しレビューすることができる。他の実施例においては、加えた参加者は、その会話のメッセージに対してのみ、その新しい参加者が加わるポイントからアクセスが与えられ、その会話先行するメッセージに対するアクセスは与えられない。
【００８６】
また、会話／メッセージ管理モジュール２０ｆは、記憶・ストリームモジュール２４によって実行される全てのレンダリングするタスクをコントロールするために使う機能を管理する役割を持つ。これらのタスクには、アプリケーション１２を実行するデバイス１３に適切にメディア（すなわち、音声、ビデオ等）をレンダリングすることが含まれる。これらのレンダリングタスクには以下が含まれるがそれに限定されない。すなわち、ミックスしたメッセージ（すなわち、メッセージのオーバラップ）をレンダリングするとともに、ユーザ定義の基準に従い、早送り、ライブへキャッチアップ、無音の除去、躊躇粒子の除去、周波数シフトをレンダリングすること、およびマルチ会話における個人の送信側に対する独立のゲインコントロール適用すること。
【００８７】
［Ｄ．１．２．７ 優先順位サービス］
優先順位サービス部２０ｇは、一組の機能を定義するモジュールである。この一組の機能は、ユーザが、ユーザが関与する継続する会話（すなわち、ＭＣＭＳ−Ｃ）の優先順位を管理するうえで必要な全ての情報を管理保持する役割を持つデータ構造および処理を管理する。ユーザが継続的な多角ライブ会話に参加するときは、ユーザはその会話に優先順位をつけることを求められる。異なる会話のメッセージが同時にレンダリングできる状態になると、問題が起こる。アルゴリズムを使い、メッセージがレンダリングされる順序を判断し、レンダリングされるメッセージの利用可能性とユーザによってセットされた優先順位を考慮する。アルゴリズムは、最も高い優先順位をもった利用可能なメッセージを決めて最初にレンダリングし、一方、同時に利用可能なメッセージは、自動的にタイムシフトされ、高い優先順位のメッセージレンダリングできるようにする。レンダリングが可能になれば、システムは、タイムシフトされたメッセージを、ユーザの優先順位に従い自動的にレンダリングする。
【００８８】
［Ｄ．１．２．８ コンタクトサービス］
コンタクトサービス部２０ｈは、一組の機能を定義するモジュールである。この一組の機能は、一またはそれ以上のコンタクトを認証し、会話と関連づけるうえで必要な全ての情報を管理、保持する役割のデータ構造および処理を管理する。多数のコンタクトと関連づけられた会話の部分としてメッセージを送信するときは、全てのコンタクトがメッセージを受信する。
【００８９】
［Ｄ．１．２．９ プレゼンス／ステータスサービス］
プレゼンス／ステータスサービス部２０ｉは、一組の機能を定義するモジュールである。この一組の機能は、プレゼンス情報とステータス情報を管理し、システムの特定のユーザおよび／または 非ユーザと共有する役割のデータの構造と処理を維持する。種々の実施例において、プレゼンス情報とステータス情報は、クライアント１２のユーザに関わる会話に参加する全てのユーザと非ユーザ、コンタクトリストの全てのユーザと非ユーザ、または、予め定義するされたドメイン内のユーザ（例えば、会社またはその他の組織のメンバー）のために維持される。これらの例は、単に例示として挙げたものであり、限定と解釈されるべきではない。プレゼンス／ステータスサービス部２０ｉモジュールは、ユーザおよび／または非ユーザの組を定義するプレゼンス情報とステータス情報を管理、共有することもできる。
【００９０】
プレゼンス／ステータスサービス部２０ｉは、他のユーザの意図のステータス、注意、および所定の会話のタイムシフト遅延（すなわち、ライブの会話のメッセージをレビューすることからどれだけ遅れているか）をユーザにモニタすることを可能とする。一実施例において、プレゼンスとデータ状態の利用可能性について、プライバシーコントロールが提供されている。さらにプレゼンス／ステータスサービス部２０ｉは、システム１０が、ユーザの動作と意図にマッチするメッセージを送達することを可能とするデータをコントロールする。例えば、ユーザは、会話のライブをレビューするかしないか意図を指定することによって自分のステータスを示すことができる。応答として、プレゼンス／ステータスサービス部２０ｉは、ユーザの意図に従って、「ライブ」またはタイムシフトでメッセージをレンダリングさせるコマンドを発する。さらに、ユーザの意図は、その会話の他の参加者と共有される。また、サービス２０ｉは、ユーザの動作からその他のステータス値を推論することが可能である。プレゼンス情報およびステータス情報は、以下に詳しく記述するように、ネットワークのトラフィックと帯域幅を最適化する目的で使われる。
【００９１】
［Ｄ．１．２．１０ メッセージ／信号サービス］
メッセージ／信号サービス２０ｊは、一組の機能を定義するモジュールである。この機能は、システム１０のユーザに特別のメッセージまたは聞こえる音を使ってシステム１０のユーザにメッセージと信号を発する役目のデータ構造と処理を管理する。特別のメッセージまたは音は、例えば一個または複数のメッセージがライブかタイムシフトかの指示、どこからのメッセージか、優先度、その他のファクタを含んでも良い。メッセージ／信号サービス２０ｊは、さらに以下の能力を持つ。（ｉ）ネットワーク上にユーザが存在しているか否かを信号で知らせる。またもしユーザがもう会話のメッセージをアクティブにレビューしていないときは、通知することができる。（ｉｉ）ユーザが別の会話に注意を奪われているときまたは自分のデバイス１３に全く注意払っていないとき、「リング」または別の方法で通知する。ｉｉｉ）ユーザがネットワーク１８上にいない場合はメッセージを残し、次回ユーザがネットワーク１８に接続したときに即座にメッセージをレビューすることを促す。（ｉｖ）音響または視覚のフィードバックを生成し、送ったメッセージが受信側に受信されなかったことを送信側に警告する、メッセージが受信側に受信されたときおよび／またはメッセージが受信側に聞かれたときは、確認を生成する。（ｖ）会議または戦術的なコールに加わっている人々が当コールに即座に注意を払う必要がある場合、優先順位スキームを実行する。この表示は、受信側による様々なレベルの緊急性または何らかの確認を伝達しても良い。
【００９２】
［Ｄ．１．２．１１ レンダリング・エンコード］
レンダリング−エンコードモジュール２１は、ＭＣＭＳアプリケーション２０のための全てのレンダリングタスクを実行する役割をもつ。これらのタスクには、アプリケーション１２を実行するデバイス１３に適したレンダリングメディアが含まれる。
【００９３】
［Ｄ．２ 記憶・ストリームモジュール］
記憶・ストリームモジュール２４は、以下に説明するように多くの機能とパフォーマンス属性をサポートする。
【００９４】
記憶・ストリームモジュール２４は、メッセージは基本的に「全二重」で送信され、相手方もメッセージを送信中であっても、また、もし相手が出られないまたは別の通信に加わっていても、何れの当事者にも随時メッセージを送信可能にする。記憶・ストリームモジュールは、ライブのＰＳＴＮまたはＶｏＩＰコールと同じように、メッセージをレンダリングし、タイムシフトメッセージモードのためのメッセージを送達することができる。ユーザの希望に従い、送信を最適化し、レンダリングをコントロールすることができる。
【００９５】
記憶・ストリームモジュール２４は、下層のネットワーク１８上の全てのターゲットの受信側（例えば、サーバ１６、その他のデバイス１３）との接続性を維持し、全てのメッセージ、信号、およびメディアの通信を管理し、ネットワーク１８の送達速度と帯域幅を最適化し、ネットワークの品質と容量を管理しながらユーザの現下のパフォーマンス必要条件を満足する。モジュール２４は、下層のネットワーク１８の質と容量と釣り合いのとれたメディアの送達を調節し、最適化する。下層のネットワークための資源が不十分な場合は、送信するメディアストリームの質を下げることができる。帯域幅の回復しだい、送信するメディアストリームの質を上げることもできる。メディアの質のトレードオフに加え、記憶・ストリームの機能により、以下に記述するように、データをリアルタイムでレンダリングしようとするユーザの意図に基づいて、各パケットで送信するメディアの量をトレードオフすることができる。
【００９６】
下層のネットワーク１８の状態に基づいて、メディアの送達速度を動的にコントロールすることにより、記憶・ストリームモジュール２４は最適化され、受信したときにレンダリングする上で「十分に良い」時間的制約のあるメディアの送達を行い、紛失、質が低い、またはダメージを受けたパケットの再送を要求するバックグラウンドのプロセスを通じて、アーカイブする目的のそのメディアの正確なすなわち完全なコピーが最終的に送達されることを保証する。最低限のメディアの品質レベルを満足するだけのネットワーク資源がある限り、この再送は、ライブコールでのメディアのレンダリングを妨げることはない。このように、システム１０のクライアント１２は、相当な潜在的待ち時間を犠牲にしたメディアの正確なすなわち完全なコピーの送達と完全性の保証はないがメディア素早い送達との間のパフォーマンスギャップを橋渡しするように設計されている。本アプリケーションの文脈において、用語「十分に良い」とは、メディアの質が、レンダリングされたときに理解できる、ということを意味する。したがって、「十分に良い」の概念は主観的なものであって、絶対的な用語として解釈されるべきではない。例えば、あるメディアの十分に良い質のレベルは、メディアのタイプ、状況、その他のファクタによって変わりうる。
【００９７】
さらに、記憶・ストリームモジュール２４は、デバイス１３を使って別途生成された、または、ネットワーク１８上で別のデバイス１３および／またはユーザから受信された全てのメディアを持続的に記憶する。クライアント１２を実行するデバイス１３上でこのメディアを記憶することは幾つかの大きな利点がある。（ｉ）送信側および／または受信側が出られないまたはネットワーク接続性が貧弱である場合でも、ユーザは相手方にメッセージを残すことが可能となる。帯域幅が不十分なケースでは、メッセージは帯域幅が効果的に使える限り早く送信される。接続性が不要のケースでは、メッセージは、送信待ちのキューに並び、ネットワークの接続が使用可能になると即座にタイムシフトの送達がおこなわれる。（ｉｉ）ユーザは、ポーズ、リプレイ、早送り、ライブの進行中の会話にキャッチアップができると同時に、アーカイブされた先行する会話のメッセージを取り出しレビューすることができる。（ｉｉｉ）時々起こるネットワーク回線容量および接続性の問題にたいしてシステム１０上のデータペイロードの最適化とシステムの復元力を向上することが可能となる。
【００９８】
また、記憶・ストリームモジュール２４は、下記の役割をもつ。多数の参加者が話している実際の会話をシミュレートして、メッセージを適切にミキシングし、オーバラップメッセージ（会話における話者等の通常のオーバラップまたはバックグラウンドのノイズで生成される）を作成する、音声メディアの解説または翻訳をレンダリングすること、早送り、発話間の無音ギャップの除去、躊躇粒子の除去、周波数シフトをを含む多数のユーザ定義の基準に従ってメディアのレンダリングを調節すること、マルチ会話における個人の送信側に対する個別のゲインコントロールを適用すること能力を持つこと及び潜在的なレンダリングオプションをもつ。
【００９９】
記憶・ストリームモジュール２４は、それ自身とＭＣＭＳとの間のコントロールおよび情報メッセージを管理する。
【０１００】
［Ｄ．２．１ 永続的無限メッセージバッファ（ＰＩＭＢ）］
永続的無限メッセージバッファ（ＰＩＭＢ）３０は、一組のインデックスされた（すなわち、タイムスタンプ付け、順番に番号付け）メディアペイロードデータの構造、およびその記憶と取出しのためのシステムである。一実施例において、ＰＩＭＢ３０内のデータは、永久にあるいは少なくともシステムの記憶装置がいっぱいになるまで、使用可能であるという意味で、実質的に永続性をもつ。記憶資源を有効利用するために、様々な保持率と方策を採用することができる。ＰＩＭＢ３０の物理的記憶を実施するには下記のような様々な方法があるが、これに限定されない。すなわち、ＲＡＭ、フラッシュメモリ、ハードドライブ、光学メディア、またはその幾つかの組み合わせ。ＰＩＭＢ３０も、ＰＩＭＢ３０に記憶できるデータの量は本質的に限定されないという意味で、サイズ的に「限定」である。この限定がないということは、レンダリング後即座にデータを廃棄する現在のジッタバッファ技術との比較の上でのことである。特定の実施例において、ＰＩＭＢ３０は、持続的記憶用のハードドライブと連結された小さくて比較的早いＲＡＭキャシュメモリを使って実現することもできる。ＰＩＭＢ３０の物理的記憶容量を超えた場合、オンデマンドでの後の検索のために、データはサーバ１６に保持される（以下に記述する）。何れの時点でも、ＰＩＭＢ３０に記憶された実際のデータまたはサーバ１６、またはアーカイブされたデータは、ユーザ基準または「最も古く使われた」、又は、「先入れ後出し」等の入れ替えアルゴリズムを使ってコントロールされる。さらに、ＰＩＭＢ３０は、ファイルシステム保存の属性およびランダムアクセスの属性のレンダリングをおこなう。それぞれのメッセージの期間または数にかかわらず、どんな数の会話でも記憶でき、後で検索してレビューすることができる。さらに、作成源、長さといった、会話のメッセージと関係するメタデータもＰＩＭＢ３０に記憶することができる。他の実施例においては、インデックスかされたメディアペイロードおよび他のデータは、指定の期間（例えば、３０日）記憶することができる。メディアが指定の期間を超えると、ペイロードとデータは廃棄される。別の実施例においては、ペイロードを含むメッセージの送信側および／または受信側、またはペイロードに関わる会話またはメッセージのトピックに基づいてペイロードは廃棄することができる。さらにその他実施例においては、ペイロードおよびデータは一時的にマーク付けされ、メッセージは、即座のレンダリングの要件を超えて、ＰＩＭＢ３０に記憶されない。
【０１０１】
［Ｄ．２．２ データ・ネットワーク品質記憶部］
データ・ネットワーク品質記憶部（ＤＮＱＳ）３２は、ＰＩＭＢ３０から読み取られ、ＰＩＭＢ３０に書き込まれるメディアペイロードとＶｏｘパケットに関する情報を記憶するためのデータ記憶部である。
【０１０２】
［Ｄ．２．３ ＰＩＭＢ書込み部］
ＰＩＭＢ書込み部２８は、二つの基本的目的のためにデータをＰＩＭＢ３０に書込む。ＰＩＭＢ書込み部２８は、クライアント１２を実行するデバイス１３上のメディア取得デバイス（例えば、マイクまたはカメラ）からのデータを書込む（「エンコード受信」）。また、ＰＩＭＢ書込み部２８は、他のクライアント１２からネットワーク１８を通じて受信したデータを書込むＰＩＭＢ３０（「ネット受信」）。
【０１０３】
［Ｄ．２．３．１ エンコード受信］
デバイス１３からメディアを取得するために、ＰＩＭＢ書込み部２８は、エンコーダ受信部２８ａとデータ記憶部２８ｃを含む。例えば、あるユーザがマイクに話かける、あるいは、デバイス１３でビデオメッセージを生成すると、ハードウェア３４生の音声および／またはビデオ信号を受信し、それをインデックスされたメディアペイロードにエンコードするエンコーダ受信部２８ａにレンダリングする（以下、単に「ペイロード」と称する場合もある）。データ記憶部２８ｃはそのペイロードをＰＩＭＢ３０に記憶する。センサデータ等のその他のタイプのメディアは、同様の仕方でペイロードに変換される。
【０１０４】
［Ｄ．２．３．２ ネット受信］
ネットワーク１８を通じて受信メディアをＰＩＭＢ３０に記憶するため、ＰＩＭＢ書込み部２８のネット受信機能は、ネットワーク受信部２８ｄ、データバッファ部２８ｅ、データ記憶部２８ｆ、データ品質管理部２８ｇおよびネットワーク品質管理部２８ｈを含む。ネットワーク受信部２８ｄは、ネットワーク１８を通じてＶｏｘパケットを受信する。データバッファ部２８ｅは、受信したＶｏｘパケットを正しい順序に置き、入ってくるＶｏｘパケットのレンダリングの少なくとも最小タイムシフト遅延（ＭＴＳＤ）を防ぐ。データ記憶部２８ｆは、パケットをインデックスされたメディアペイロードに変換し、インデックスされたメディアペイロードをＰＩＭＢ３０に記憶する。ペイロードが記憶されと、データ品質管理部２８ｇは、紛失パケットあるいは欠陥パケットがないか監視する。もし紛失パケットや欠陥があるがある場合は、ＤＱＭ２８ｇはネットワーク１８を通じて再送要求を予約する。送信側のデバイスは、これに応えて紛失パケットまたは欠陥パケットを再送する。最終的にはこれらのパケットは、インデックスされたメディアペイロードに変換され、ＰＩＭＢ３０に記憶される。紛失パケットまたは欠陥パケットを取出すことによって、送信側のメッセージの「正確な」コピーは最終的にはＰＩＭＢ３０に記憶される。紛失パケットおよび／または欠陥パケットの再送によって、メッセージのリアルタイムのレンダリングに遅延を生じることはなく、送達されレンダリングされたパケットは「十分に良い」品質と量となる。新しい「ライブ」データと再送サポートするだけの十分なネットワーク資源がない場合は、ＤＱＭ２８ｇによって再送要求が遅延される場合もある。
【０１０５】
［Ｄ．２．４ ＰＩＭＢ読取り部］
ＰＩＭＢ読取り部２６は、二つの基本的目的のためにＰＩＭＢ３０からデータを読取る。データがローカルクライアント１２向けにレンダリングされる場合は（「レンダリングする」）、ＰＩＭＢ読取り部２６はＰＩＭＢ３０にアクセスする。データがクライアント１２によってネットワーク１８を通じて送信される場合も（「送信」）、データはＰＩＭＢ３０から読取撮られる。
【０１０６】
［Ｄ．２．４．１ レンダリング］
クライアント１２上のメッセージをレンダリングするために、ＰＩＭＢ読取り部２６は、データ優先順位付与部２６ａ、データ取出し部２６ｂ、パケット損失補償／補間部（「ＰＬＣ／補間部」）２６ｃ、データミックス部２６ｄおよびデータレンダ部２６ｅを含む。データ優先順位付与部２６ａは、レンダリングされるデータに優先順位をつけ、潜在的にレンダリングされる可能性のあるメッセージを順序付けられたキューを作る。これは、ユーザ設定の優先順位を使い、継続会話（ＭＣＭＳ−Ｃ）をレンダリングする。さらに、データ優先順位付与部はメディアデータの利用可能性を使い、ＭＴＳＤ、ユーザの現在の注意、ユーザが定義、含意する意図によって強制される制限内にレンダリングする。データ取出し部２６ｂは、ＰＩＭＢ３０から優先順位付けされたインデックスされたメディアペイロードを取り出す。ＰＬＣ／補間部２６ｃは、既知のパケット損失補償と補間アルゴリズムを使って取り出したペイロードにパケット損失補償および補間を実行する。使われる個々の方法は現在使われているメディアコーデックおよびその他既知のパラメータによる。ミックス部２６ｄは、適切にミックスして一個の会話のなかの多数のメッセージを使って同時データストリームを作るのに使われる。例えば、もし、二人以上の会話参加者が同時に話しているときは、ミックス部２６ｄは、同時に話している参加者の効果も作成してメッセージミックスする。代替的な実施例においては、ユーザは、オプションとして、一人の参加者の多数のストリームを一時にレビューすることもできる。もし、会話の中の一人の参加者のみが話している場合は、ミックス部２６ｄは、ミキシングを行なわずに一個ののメッセージストリームをパスしても良い。レンダ部２６ｅは、ミックス部モジュール２６ｄからデータを取り出し、それをハードウェアドライバ３４に適したフォームに変換する。ハードウェア３４は、メディアのタイプ、作成する音声、ビデオ、その他デバイス１３上の音響および／または視覚警報装置によって、デバイス１３のスピーカーまたはビデオ表示部を駆動する。
【０１０７】
［Ｄ．２．４．２ 送信］
ネットワーク１８を通じてクライアント１２から送信するメッセージを作成するために、ＰＩＭＢ読取り部２６はデータ優先順位付与部２６ｆ、パケット品質管理部（ＰＱＭ）２６ｇ、データ読取り部２６ｈ、パケット部２６ｉ、送信部２６ｊおよび認証部２６ｊを含む。データ優先順位付与部２６ｆは、ネットワーク１８を通じて送信するメッセージに優先順位をつける。優先順位は、送信できるペイロードに関するＭＣＭＳ参加者の属性、ネットワークの接続性と回線容量の状態、およびライブまたはタイムシフトでレンダリングする次のホップの向こう側にいるおよびユーザの意図、そして、幾つかの実施例においては、次の所定のネットワークホップに対する多数のパケットが利用できる場合には、送信組立の可能な最適化、を使って判断される。次に、以下に詳述するように、優先順位をつけられたパケットは、ライブメッセージを行ううえで「十分に良い」品質のデータをタイムリーに送達することを確実にするＰＱＭ２６ｇを使ってリアルタイムの帯域幅を最小化しながら最適化される。データ読取り部２６ｈは、ＰＩＭＢ３０から適切なペイロードを取り出す。パケット部２６ｉは、ペイロードをＶｏｘパケットに組立て、Ｖｏｘパケットは次にネットワーク１８を通じて送信部モジュール２６ｊによって送信される。受信側がＶｏｘパケットを受信すると、ネットワーク１８を通じて認証部２６ｊに確認が送られ、メッセージが宛先に着信したことを送信側のユーザに通知する。
【０１０８】
［Ｄ．２．５ パケット品質管理部］
ＰＱＭ２６ｇには、以下の最適化目標がある。（ｉ）時間的制約のあるメディアの適切なコピー（レンダリングするうえで「即座に、十分に良い」）をタイムリーに送達すること；（ｉｉ）最適な送信周波数、ペイロードの品質、および下層のネットワークのための最適なパケットサイズを使って使用可能な帯域幅を有効に使うこと；および（ｉｉｉ）送信周波数、ペイロードのコンテンツ、ペイロードの品質、パケットのサイズ等をネットワークの状態変化に応じて動的に調節する、または変更すること。
【０１０９】
［Ｄ．２．６ ネットワーク品質管理部］
ネットワーク送信の受信サイドにはネットワーク品質管理部２８ｈ（ＮＱＭ）がある。ＮＱＭは、実際値に対するジッタ、損失、および処理量の期待値を比較して、クライアント１２にメディアを送った各送信側のためのネットワークのパフォーマンスの特定の特性を監視する役割を持つ。全ての送信側のネットワーク品質レート（ＮＱＲ）を計算するために使われる。ＮＱＲは受信側のデバイスのユーザに送信側の利用可能性および会話のライブ度を示すために使われる。
【０１１０】
［Ｄ．２．７ データ品質管理部］
データ品質管理部２８ｇは、パケット損失、ジッタ、処理量を監視して、ネットワークを通じて受信中のデータの品質を測定する。ＤＱＭ２８ｇはこれらの測定値を３つ目的のために使う：（ｉ）送信側に受信レポートを送り返す；（ｉｉ）オプションとして、これらの受信レポートを使って特定のデータの再送を要求する；および（ｉｉｉ）これらの測定値をＮＱＭ２８ｈが利用できるようにする。
【０１１１】
［Ｅ．サーバアーキテクチャ］
図３はサーバ１６上で実行するアプリケーション７８のブロック図である。アプリケーション７８は、多くの点でクライアントアプリケーション１２と同様であり、以下を含む。すなわち、ＭＣＭＳサーバアプリケーション８０、ＭＣＭＳデータベース８２、記憶・ストリームモジュール８４、ＰＩＭＢ８５、データ・ネットワーク品質記憶部（ＤＮＱＳ）８６、ＭＣＭＳサーバアプリケーション８０と記憶・ストリームモジュール８４の間を行き来するメッセージと信号を管理するＭＣＭＳ−ＳＡＳメッセージハンドリングモジュール８７ａ、８７ｂ、アーカイブ／取出し部８８、およびアーカイブ部８９。さらに、アプリケーション７８は、認証−暗号化セキュリティモジュール４０および通信プロトコルモジュール４４を含む。
【０１１２】
ＭＣＭＳサーバアプリケーション８０は多層構造のアーキテクチャであって、以下を含む。すなわち、ＭＣＭＳデータベースモジュール２０ａ、記憶・ストリーム（ＳＡＳ）モジュール２０ｂ、メッセージ・信号モジュール２０ｃ、会話／メッセージ管理サービス部２０ｆ、優先順位サービス部２０ｇ、コンタクト（ユーザと認証を含む）サービス部２０ｈ、プレゼンス／ステータスサービス部２０ｉおよびメッセージ／信号サービス部２０を含む。クライアント１２と同じ参照番号を持つアプリケーション７８の前記モジュールおよびサービス部はクライアント１２の同じ参照番号を持つモジュールおよびサービス部と同様もしくは同じであり、したがって注意すべき例外を除きここでは詳しい記述を省く。種々の実施例において、ＭＣＭＳデータベース８２を含むＭＣＭＳサーバアプリケーション８０および記憶・ストリームモジュール８４は、アプリケーションの一例として、多数のユーザをサポートするように構成されている。さらに、この例は、ユーザのグループとして定義される多数のドメインをサポートするように構成されてもよい（例えば、会社または共通の組織に所属するユーザその他のグループ）。このアーキテクチャは、サーバ１６上の各アプリケーション７８が、各ユーザ（またはドメイン）が他のユーザには見えない多数のユーザ（またはドメイン）に使えるようにしてもよい。この区切り方は「マルチテナント」と呼ばれる。
【０１１３】
記憶・ストリームモジュール８４はネット受信と送信の機能を実行する。ネット受信機能用として、モジュール８４は、ネットワーク受信部２８ｄ、データバッファ部２８ｅ、データ記憶部２８ｆ、データ品質管理部（ＤＱＭ）２８ｇ、およびネットワーク品質管理部２８ｈを含む。送信機能用として、モジュール８４は、データ優先順位付与部２６ｆ、パケット最適化部２６ｇ、データ読取り部２６ｈ、パケット部２６ｉ、送信部２６ｊおよび認証部２６ｊを含む。記憶・ストリームモジュール８４の上記の構成要素は、クライアント１２の同じ参照番号を持つ構成要素と同様又は同じである。したがって、それらの詳しい記述は割愛する。
【０１１４】
サーバ１６はユーザと直接情報のやりとりはしないので、クライアント１２の記憶・ストリームモジュール２４に与えられたエンコードとレンダリング機能は、必要としない。ＭＣＭＳアプリケーション８０は、サーバ１６上で動作するときは、ユーザと直接やり取りはしない。したがって、ユーザインタフェース、および ユーザインタフェースＡＰＩモジュールおよびサービス部２０ｅ、２０ｄは必要ない。
【０１１５】
各サーバ１６上のアプリケーション７８は、潜在的に多数のテナントに関与する。つまり、システム１０の多数のユーザに関与する。サーバアプリケーション７８のＰＩＭＢ８５は、したがって、一個ののユーザのみの生成されたまたは受信したペイロードだけを記憶するために使われるＰＩＭＢ３０とは異なり、相当に大きく、また、多数のユーザのメディアペイロードを記憶するために使われる。記憶・ストリームモジュール８４の主な目的は、クライアント１２によって送信されるメッセージを受信することと他のクライアント１２にメッセージを送信することである。メッセージが受信されると、ＰＩＭＢ８５に記憶されるとともに、目的の受信側またはシステムの構成に直接依存する受信側への経路に沿って、ネットワーク層１４の次のサーバ１６（すなわち、ネット「ホップ」）へ送信される。アーカイブ／取出し部８８は、アーカイブ部８９内のＰＩＭＢ８５に記憶されたメディアのペイロードをアーカイブする役割を持つ。ＰＩＭＢ８５内の物理的スペースがなくなると、ＰＩＭＢ８５内のメディアのペイロードは大量記憶デバイスであるアーカイブ部８９へ移される。種々の実施例においては、ＰＩＭＢ８５に記憶されたペイロードは、ユーザ定義の基準および／または先入れ先出し（ＦＩＦＯ）または最後に使われた（ＬＲＵ）等の既知の入れ替えアルゴリズムに従ってアーカイブされる。解りやすくするために、図１には、一個のサーバ１６のみが示されている。実際の実施例においては、複数のサーバまたは「サーバファーム」は、多数のユーザとのネットワークのために使われる。
【０１１６】
ＰＩＭＢ３０およびＰＩＭＢ８５を記述するために使われる用語「永続性の」と「限定」は、厳密な用語として文字通り解釈すべきではない。ユーザは、重要とおもわれる幾つかのメッセージは、いつまでも記憶したいと望む。二人の友達間の普段のおしゃべり等のその他の状況では、スペースを節約するために、一定の時間が経過したら、メッセージは削除しても良い。本発明の種々の実施例によれば、システム１０によって設定されるかユーザによって設定されるか、異なる保持ポリシが使われても良い。「限定」の用語は、ＰＩＭＢによって強制される時間的区切りがないという意味で使用される。このことは、現在のジッタバッファシステムでは、メディアはレンダリングされた後は、廃棄されるのとは対照的である。「永続性」および「限定」の用語は、したがって、ＰＩＭＢ３０およびＰＩＭＢ８５は、時間の範囲とそこに記憶されるメッセージの量については何ら内的制限がない、ということを意味すると広く解釈されるべきである。
【０１１７】
持続的記憶媒体に会話のメッセージをアーカイブすることには多くの利点がある。音声メッセージおよびその他のメディアは、必要に応じ組織化され、インデックスされ、検索され、転記され、翻訳され、レビューすることができる。音声およびその他のメディアは、したがって、ユーザおよび組織によって管理することのできる資産となる。これらのメディア資産は、軍隊同様、会社、第一応答者、警察および消防署にとっても価値がある。
【０１１８】
［Ｆ．Ｖｏｘプロトコルおよびインデックスメディアペイロード］
上記したように、Ｖｏｘプロトコルは、ペイロードの送信、記憶、および最適化の全ての面をサポートするために、記憶・ストリームモジュール２４によって使われる。Ｖｏｘパケットは、ネットワーク１８の下層の技術における一個または複数の搬送パケットの内部のカプセル化のために設計された構造化されたメッセージフォーマットである。これによりシステム１０の自由度が大きく改善される。搬送パケットの中にＶｏｘパケットを埋め込むことによって、「ヴォクシング（Ｖｏｘｉｎｇ）」アプリケーションのために新しい搬送層を定義するのとは対照的に、システム１０は、現存する通信インフラを通じて動作する通信ネットワークに基づいて現在のパケットを利用する。Ｖｏｘパケットを扱うための新しいネットワークインフラは、したがって、ここに記載するシステムおよび方法の全ての利点を利用する必要はない。
【０１１９】
図４Ａを参照すると、Ｖｏｘパケット９５の一般的なフォーマットの構造が示されている。Ｖｏｘパケット９５のフォーマットは、タイプ、サブタイプ、長さ、およびペイロードを含む。Ｖｏｘパケットの別のタイプは、認証、信号発信、メディアペイロード、メディア多重化（一個のメッセージ）、およびメディア多重化（多数のメッセージ）を含む。サブタイプのフィールドは、異なるタイプの認証、信号発信、メディアタイプメッセージを指定するために使われる。認証メッセージのための可能なサブタイプとしては、キー交換および認証に必要なフィールドが含まれる。信号発信メッセージのための可能なサブタイプとしては、登録、ルーティング、メッセージのセットアップおよびネットワークの管理が含まれる。メディアメッセージのための可能なサブタイプとしては、コーデックの型と異なるペイロード集約技術が含まれる。長さフィールドはペイロードの全長すなわちサイズを定義する。ペイロードフィールドは、パケット９５の実際のペイロードすなわちメディアを含む。
【０１２０】
図４Ｂはネットワーク１８によって使われるカプセル化せれたＶｏｘパケット９５のプロトコルの例を示す図である。この例では、ＵＤＰ、ＩＰおよびイーサネット（登録商標）の搬送パケット９６の下層にそれぞれ埋め込まれたＶｏｘパケット９５を示す。この方法においては、Ｖｏｘパケット９５は、ネットワーク１８の下層のＵＤＰ、ＩＰおよびイーサネット（登録商標）層を通じて搬送できる。これは、パケットネットワークによって使われる標準的なプロトコルカプセル化の技術である。
【０１２１】
図４Ｃは、ＵＤＰ、ＩＰ、およびイーサネット（登録商標）９７内でカプセル化されたメディア多重化Ｖｏｘパケット９５を示す図である。この例では、Ｖｏｘパケット９５は、メディアタイプフィールド、メディアサブタイプフィールド、長さフィールド、メッセージＩＤフィールド、タイムスタンプフィールド、シーケンスＩＤフィールドおよびメディアペイロードフィールドを含む。
【０１２２】
図４Ｄは、インデックスされたメディアペイロード９８のフォーマットを示す。インデックスされたメディアペイロードは、サブタイプフィールド、長さフィールド、メッセージ識別子（ＩＤ）フィールド、タイムスタンプフィールド、シーケンス識別子（ＩＤ）フィールド、およびメディアペイロード用のフィールドを含む。
【０１２３】
Ｖｏｘパケット９５を搬送パケット下層のネットワークのカプセル化することによって、メディア、メッセージおよび会話を多数の属性によってそれぞれ定義することができる。
【０１２４】
メディアがデバイス１３上に作成または生成されると、それは、主としてタイムベースのものとなり、時間経過とともに意味のある形で変化する。ある人が会話に参加すると、例えば、時間の経過とともに、話し言葉はセンテンスまたは発言につなぎ合わされて、結果としてのデータ（ストリームおよびパケット）は、同じ相違を長い時間維持する。同様に、ＧＰＳその他センサデータ同様、ビデオ（スチール写真とは対照的に）は、時間の経過とともに変化する。タイプや生成のされ方にかかわらず、メディアはセグメント化され、複数のＶｏｘパケット９５のペイロード中に置かれる。続いてパケットは記憶され、送信され、受信され、記憶され、送信側と受信側のデバイス１３のそれぞれでストリーム（すなわち、ストリーム中のメディア）にレンダリングされる。各パケット９５は、インデックスされ、タイムスタンプ処理され、シーケンス識別子が付与されているので、個々のパケットは、メッセージにセグメント化することができる。個人のメッセージを順番にスレッディングすることによって会話を構成することができる。
【０１２５】
システム１０の固有の側面として、クライアント１２によって生成されたメディアペイロードは多くのロケーションに記憶されるということである。ペイロードは、生成側のデバイス１３のＰＩＭＢ３０に記憶されるだけでなく、受信側のサーバ１６のＰＩＭＢ８５およびデバイス１３のＰＩＭＢ３０にも記憶される。この基本的な機能によって、Ｖｏｘｉｎｇ機能の多くを可能とし、ネットワークの状態が不良であっても、あるいは会話の参加者がネットワークに接続されていなくても、システム１０に復元力と操作性を提供する。
【０１２６】
［Ｇ．下層通信プロトコルとの相互操作性］
システム１０は、インターネット、固定ＰＳＴＮタイプ回路ネットワーク、およびモバイルまたはセルラーホンネットワークまたはその組み合わせのようないろいろな現存する通信ネットワーク１８を通じて、実行する、あるいはそれらと層化することを意図している。システム１０は、システム１０内の異なるクライアント１２とサーバ１６間を移動する多数の小さな情報の単位（すなわち、Ｖｏｘパケット）のコンセプトの周辺に設計されている。Ｖｏｘパケットは、機能およびペイロードによってサイズは異なるが下層のネットワーク層にとっては、全て同じ種類のデータとして見える。一実施例において、システム１０は、インターネット等のＩＰｖ４ネットワークが設計されて最適化されたものだが、その他のタイプのネットワークもサポートする。本ドキュメントの目的に照らして、用語「ＩＰ」は、ＩＰｖ４、ＩＰｖ６あるいはその他現在または未来に実施されるであろうインターネットプロトコルを意味すると理解されるべきである。
【０１２７】
図５は、デバイス１３上で実行し、共用ＩＰネットワーク１００を通じてサーバ１６と通信するクライアント１２を示す。図に示すように、クライアント１２は、第一のインターネットサーヴィスプロバイダＡを介して共用ＩＰネットワーク１００に連結され、サーバ１６は、第二のインターネットサーヴィスプロバイダＢによって共用ＩＰネットワーク１００と連結されている。通信中に、Ｖｏｘパケット９５（図では「ＶＰ」と表記）はＵＤＰ／ＩＰパケットにカプセル化され、ついで当該技術では周知のように、他のＩＰプロトコルパケットにインタリーブされ、共用ＩＰネットワーク１００を通じてクライアント１２からサーバ１６等へ送信される。周知の如く、低いパケット層はすぐ上の層のパケットの全てをカプセル化する。また、パケットは、同様のやり方で２個のサーバ１６間でやり取りされる。メッセージは、共用ＩＰネットワーク１００を通じてクライアント１２が許可したデバイス１３から他のクライアントへ送られる。Ｖｏｘパケット９５は、ターゲットの宛先に到達するまで各ホップで下層のＩＰプロトコルに埋め込まれ送信される。
【０１２８】
図５は、説明のために、ネットワーク１００接続された一個のクライアント１２とサーバ１６を例示的に示す。実施例における実際のシステム１０は、多くのクライアント１２と一またはそれ以上のサーバ１６が主として共用ＩＰネットワーク１００に接続されている。また、クライアント１２およびサーバ１６は、ＩＰネットワーク１００を排他的に使うものではないことに注意されたい。図示の例では、インターネットプロバイダＡを介してネットワーク１００と連結されたＨＴＴＰクライアントは、ネットワーク１００に連結されたＨＴＴＰサーバとの間で、第３のインターネットプロバイダＣを経由してパケットをやり取りすることができる。システム１０は、ＩＰパケットに埋め込まれたＶＰがネットワーク１００を横断する方法についてコントロールはしない。ネットワーク１００を共有し横断する全てのパケットは、下層の共用ＩＰネットワーク１００の標準的な手順に従って動く。
【０１２９】
図６は、ネットワーク１０４にベースを置くＧＳＭモバイルホンネットワーク等の「回路」を示す。回路ネットワーク１０４は、デバイス１３上で動作するクライアント１２とサーバ１６の間で連結されている。一旦クライアント１２とサーバ１６の間で回路が確立されると、システム１０はネットワーク１０４が使う下層のパケットの上にＶｏｘパケット（ＶＰ１、ＶＰ２、ＶＰ３、ＶＰ４、ＶＰ５等）を積み重ね、「バーチャルＶｏｘ」回路を作りネットワーク１０４を通じてそれらを送信する。Ｖｏｘパケットは、データを送信する技術において知られているように、主として間隔をあけるかデータを形成して回路ネットワークを通じて回路ネットワーク１０４を順番に横断する。さらに、ペイロードのサイズおよび含まれるヘッダフィールドの数等のパケット構成パラメータを使い、パケットごとのオーバヘッドがないことを利用することもでき、またネットワーク１０４を通じてデータを送信する速度および／または効率を向上させることもできる。単純化の目的で、一個のクライアント１２とサーバ１６のみがネットワーク１０４に接続されて示していることに再度注意を促したい。しかしながら、クライアント１２とサーバ１６およびその他のコンポーネントとの間の付加的回路は、ネットワーク１０４を介して一斉に確立することができることについては理解できよう。したがって、ネットワーク１０４は、Ｖｏｘパケットを送信するための専用ではなく、むしろ他のタイプのネットワークトラフィックと共有してもよい。
【０１３０】
図７は、第一のネットワークＡにつながる第一クライアント１２Ａによって動くデバイス１３Ａと第二のネットワークＢにつながる第二のクライアント１２Ｂによって動くデバイス１３Ｂとの間の通信を示す図が示される。さらに、ネットワークＡ、Ｂはそれぞれ、ゲートウェイサーバ１６Ａおよび１６Ｂを含む。ゲートウェイサーバの組１６Ａ、１６Ｂは、二つのネットワークＡ、Ｂ間の通信を促進し、デバイス１３Ａ、１３Ｂに互いに通信を可能にする。種々の実施例において、二つのネットワークＡ、Ｂそれぞれどのようなタイプのネットワークでもよい。例えば、各ネットワークＡおよび／またはＢは、ＩＰネットワーク、回路タイプのネットワーク、無線通信またはセルラーネットワーク（すなわち、ＣＤＭＡ、ＧＳＭ、ＴＤＭＡ等）でもよい。サーバ１６は、二つのネットワーク間のトラフィックのルートを決めたり「ゲート」として機能したりするので、二つのネットワークＡ、Ｂにまたがるゲートウェイサーバとも考えられる。
【０１３１】
システム１０によって、システムのパフォーマンスを最適化するための、いくつかの基本的なネットワークの相互作用に関する考え方がある。これらの考え方には、Ｖｏｘパケット９５が送られる下層のアドレスの分解法、送られたＶｏｘパケットの統合、および所定のネットワークまたはネットワークの組み合わせを通じて送られる一個のメッセージの最大送信単位（ＭＴＵ）の管理などのファクタが含まれる。
【０１３２】
下層のネットワークがＶｏｘパケット９５を正しいロケーションに送達できるように、ターゲットクライアント１２のアドレスを知る必要がある。ＩＰｖ４ネットワークでは、アドレスは主としてＩＰｖ４アドレス、ネットワーク内のホストを一意的に識別する３２ビット数である。別のネットワーク技術においては、アドレスは別のタイプの識別子である場合もある。ＩＰネットワークではドメインネームシステム（ＤＮＳ）を使い、人間が読み取り可能なネームをＩＰアドレスに変換し、アドレス変換プロトコル（ＡＲＰ）でＩＰアドレスを物理アドレスに変換する。下層のネットワーク技術に関わりなく、システム１０は、上記のスキームのうちの一つまたは他の既知のアドレススキームを使ってＶｏｘパケット９５を正しいロケーションに送達する。
【０１３３】
パケットベースの通信システムにおいては、もし、下層のネットワークがＶｏｘパケットがカプセル化されたパケットを送達できなければ、送信されたＶｏｘパケットがアドレスされたロケーションに送達されない場合もある。ほとんどのパケットネットワークは、パケットが欠落しても送信側へ通知しない。これとは逆に、パケットは送信側と受信側に依存し、欠落したパケットを通知し、補正する。システム１０はこれらの受信側の受信レポートメッセージを使いパケット損失管理を調整するように設計されている。もし、下層のネットワークが欠落し紛失パケットを送信側に通知することができれば、システム１０はこの情報をプロトコルの再送信に使用できる。
【０１３４】
ＭＴＵの管理とは、ネットワークを通じて送ることのできる最大送信単位（すなわち、一個のメッセージの最大サイズ）を決定することである。パケット方式のネットワークでは、下層のネットワークがＭＴＵを付与する。回路切り換え型ネットワークでは、ネットワーク効率とパフォーマンスのために、ＭＴＵは調節可能なパラメータである場合もある。このように、多くのケースでは、Ｖｏｘパケット９５が効率的に送信されるように、下層のネットワークがＶｏｘパケット９５の最大サイズを与えたり決めたりする。例えば、ＩＰネットワークでは、ペイロードがＭＴＵを超えた場合は、相当なパフォーマンスを犠牲にして、パケットは細分化ができる。イーサネット（登録商標）ネットワークを通じたＩＰでは、送信側のデバイスは、イーサネット（登録商標）が実行するものとして、１５１８バイトのＭＴＵである。最大ＩＰパケットは、イーサネット（登録商標）ヘッダのための余地を残さなければならない。最大ＵＤＰパケットは、ＩＰとイーサネット（登録商標）のヘッダのための余地を残さなければならない。およびイーサネット（登録商標）で生成される最大Ｖｏｘプロトコルは、例えば、イーサネット（登録商標）ＭＴＵ（１５１８）−ＩＰヘッダ（２０）−ＵＤＰヘッダ（８）＝１４９０バイトである。Ｖｏｘプロトコルは、それ自身のヘッダを持つので、実際のＶｏｘメディアペイロードはイーサネット（登録商標）ネットワーク上では１４９０バイト以下である。ギガバイトイーサネット（登録商標）の場合は、ＭＴＵははるかに大きくてもよいが、同様の計算式を使って判断される。
【０１３５】
純粋にパケットベースネットワークにおいては、ＭＴＵ用に二個の潜在的値、すなわち、ローカルリンクＭＴＵおよび経路ＭＴＵがある。ローカルリンクＭＴＵは、ローカルネットワークインタフェースに効率的に送られるように、Ｖｏｘパケット用に最大サイズが決定する。経路ＭＴＵは、遠隔地のノードまで全行程完全な状態で送られるように最大サイズのＶｏｘパケットを出す。送信側がイーサネット（登録商標）を介して接続されている場合は、小さなＭＴＵで、Ｖｏｘパケットは様々な別のシステムを経由して、受信側までの道順を決められる。宛先までの経路上の最も小さなＭＴＵの場合は、送信側によって決定され通知される必要がある。ＩＰの世界では、「経路ＭＴＵディスカバリ」と呼ばれる最も小さいＭＴＵを見つけるための標準的な手順がある。その他の種類のネットワークには、同様な手順が使われてもよい。改めて言うと、システム１０は、別のネットワークの上に重ねられているので、上記のどのＭＴＵアルゴリズムでも使うことができる。
【０１３６】
［Ｈ．動作フロー図］
［Ｈ．１ 記憶及びストリーム］
図８Ａないし８Ｆは一連のフロー図であり、クライアント１２とサーバ１６上の記憶・ストリームモジュール２４、８４のそれぞれの動作を示す。図８Ａは、第二のクライアント１２２にメッセージを送信する第一のクライアント１２１のための動作シーケンスを示す。図８Ｂと８Ｃは送信側クライアント１２１上のＰＩＭＢ書込み部２８とＰＩＭＢリーダ２８の動作を示す。図８Ｄと８Ｅは、受信側クライアント１２２上のＰＩＭＢ書込み部２８とＰＩＭＢ読取り部２６の動作を示す。図１０Ｆは、サーバ１６上の記憶・ストリームモジュール８４のフロー図を示す。
【０１３７】
図８Ａにおいて、デバイス１３１上で動作するクライアント１２１のユーザが、送信すべきメディアを生成する。メディアは、デバイス１３の側で、ユーザがマイクに話すことによってメディアを作成する、自分のデバイス１３上でビデオコンテンツを作成する等、多くの異なる方法で作ることができる。また、メディアはデバイス１３によってＧＰＳ情報、温度読取り値等の受信側センサデータを受信することによって生成される。メディアがどのように生成されたかにかかわらず、メディアは、ＰＩＭＢ書込み部２８（囲み１３０）によってエンコードされ、ＰＩＭＢ書込み部２８は、メディアをインデックスされたメディアペイロードに変換し、クライアント１２１上のＰＩＭＢ３０（囲み１３２）に記憶する。クライアント１２１上のＰＩＭＢ読取り部２６は、ＰＩＭＢ３０からペイロードを読取り、Ｖｏｘパケットを作成し、ネットワーク１８を通じてパケットを受信側クライアント１２２（囲み１３４）に送信する。経路に沿う送信側クライアント１２１と受信側クライアント１２２の間の各サーバ１６は、送信されたペイロードをＰＩＭＢ８５に記憶し、Ｖｏｘパケットを次のホップ（囲み１３３）に送信する。受信側クライアント１２２にて、ＰＩＭＢ書込み部２８のネット受信機能がＶｏｘパケットをインデックスされたメディアペイロード（囲み１３６）に変換し、ペイロードをクライアント１２２（囲み１３８）のＰＩＭＢ３０に記憶する。クライアント１２２上のＰＩＭＢ読取り部２６のレンダリングモジュールは、ＰＩＭＢ３０から読取ったペイロード情報を音声またはビデオ（囲み１４０）等の媒体にレンダリングする。これらのステップについては、図１０Ｂないし１０Ｅを参照してさらに詳しく記述する。
【０１３８】
図８Ｂに、ＰＩＭＢ書込み部２８（図８Ａのステップ１３０）によって実行されるエンコード受信機能のシーケンスを詳しく示す。最初のステップ１３６１にて、クライアント１２１を操作するデバイス１３のユーザが、送信すべきメディアを生成する。上記したように、メディアは、マイクに話す、カメラを使う、センサデータを受信する、その他メディアを生成するためのコンポーネントによって、得ることができる。次のステップ１３０２にて、エンコードレシーバ２８ａはメディアをエンコードし、インデックスされたメディアペイロード（ステップ１３０３）を作成し、メディアはデータ記憶部２８ｃによってＰＩＭＢ３０（ステップ１３２）に記憶される。
【０１３９】
図８Ｃは、送信側のクライアント１２１のＰＩＭＢ読取り部２６によって実行される送信機能のシーケンスを示す（図８Ａ、ステップ１３４）。決定ループ１３４１において、ＰＩＭＢ読取り部２６の送信機能は、送信されるべきインデックスされたメディアペイロードがＰＩＭＢ３０に書き込まれているか、それは送信可能かどうか常にチェックする。もし、使用可能なペイロードがＰＩＭＢ３０にあれば、データ優先順位付与部２６ｆは、ステップ１３４２に示すように、ＭＣＭＳの参加者属性情報を使って、最初に送るべきペイロードに優先順位をつける。最も高い優先順位のペイロードに関する情報は、図９Ａないし９Ｃに詳述するように、ＰＱＭ（ステップ１３４３）を実行するパケット最適化部２６ｇに渡される。次に、データ読取り部２６ｈによって適切なペイロードがＰＩＭＢ３０から取り出され（ステップ１３４４）、パケット部２６ｉによってＶｏｘパケット９５に変換される（ステップ１３４５）。ついで、Ｖｏｘパケット９５は、送信部２６ｊによって、ネットワーク１８を通じて受信クライアント１２２に送信される（ステップ１３４６）。受信クライアント１２２は、受信したパケットの特性（損失、ジッタ、処理量）を反映した受信レポートを返す。これらの受信レポートは、ＰＱＭが所与の受信側のＭＡＢＲを計算するのに必要な情報を提供する。プロセスは、戻り矢印で示すように、送信ループごとに送信ステップからフロー図のトップに繰り返される。
【０１４０】
上記の実施例では、メディアは、一連の流れの中で、エンコードされ、ＰＩＭＢ３０に記憶され、ネットワーク上に送信される。代替的な実施例においては、エンコードされたメディアは、ＰＩＭＢ３０に記憶されネットワーク上を平行に送信される。すなわち、二つの機能はほぼ同時に起こる。
【０１４１】
図８Ｄは、受信側のクライアント１２２ＰＩＭＢ書込み部２８のネット受信機能（図８Ａ、ステップ１３６）のシーケンスを示す。最初のステップ１３６１で、ネットワーク受信部２８ｄがネットワーク１８を通じてＶｏｘパケット９５を受信する。データ記憶部２８ｆはパケットをインデックスされたメディアペイロードに変換し（ステップ１３６３）、ＰＩＭＢ３０に記憶する（ステップ１３６４）。ペイロードが記憶されると、データ品質管理部（ＤＱＭ）２８ｇが実行される。ＤＱＭ２８ｇは、紛失、壊れたりしたパケットがないかチェックし、送信されたデータの正確なコピーが最終的に記憶されることを確実にする。そして、ネットワークの状態に関する受信レポートを送信側に送信する。ＤＱＭ２８ｇのこれらの機能については、図９Ｄ〜９Ｆを参照してさらに詳しく説明する。
【０１４２】
図８Ｅは、受信側クライアント１２２上のＰＩＭＢ読取り部２６（図８Ａ、囲み１４０）のレンダリング機能のシーケンスを示す。最初のステップ１４０１において、データ優先順位付与部２６ａが、ＭＴＳＤ情報、ユーザステータス、プレゼンス情報を含むユーザの意図および注意のステータスを使って、ＭＣＭＳアプリケーション２０によって、レンダリングすると判断されたインデックスされたメディアペイロードに優先順位をつける。優先順位をつけられたペイロードは、データ取出し部２６ｂによってＰＩＭＢ３０（ステップ１４０２）から読取られる。ＰＬＣ／補間部２６ｃは、どちらのコーデックを使うかによって既知のパケット損失補償および補間アルゴリズムを使って、取り出したペイロードにパケット損失補償および補間（ステップ１４０３）を実行する。次のステップで、二人以上の参加者が同じ会話の中で同時にメディアを生成した場合（例えば、両者が同時に話している）は、ミックス部２６ｄは、会話の多数のメッセージをミックスする（ステップ１４０４）。レンダ部２６ｅは、ミックス部２６ｄからのデータストリームをレンダリングし（ステップ １４０５）、受信側ユーザに音、ビデオ、その他のメディアを生成する（ステップ１４０６）。
【０１４３】
図８Ｆは、サーバ１６が、ネットワーク１８上の前のホップからＶｏｘパケットを受信し、記憶し、アーカイブし、Ｖｏｘパケットを次のホップに送信するシーケンスを示す。最初のステップで、サーバ１６は、ＰＩＭＢ書込み部のネット受信機能を実行し（図８Ｄと同様）、受信したデータのインデックスされたメディアペイロードを、サーバ１６のＰＩＭＢ８５とアーカイブ部８９に保存する。また、サーバ１６は、ＰＩＭＢ書込み部の送信機能を実行し（図８Ｃと同様）、ネットワーク１８上の次のホップに受信したパケットを転送する。この方法においては、送信側クライアント１２１によって生成されたメディアのコピーが、受信側クライアント１２２までの経路に沿って各ホップで受信され、記憶され、送信される。
【０１４４】
上記の実施例においては、受信したインデックスされたメディアの書き込みは、サーバ１６のＰＩＭＢ９１に記憶され、次のホップに連続的に送信される。代替的な実施例においては、受信したインデックスされたメディアペイロードが、ＰＩＭＢ９１に記憶し、ほぼ同時に次のホップに送信される。送信側、受信側両者のデバイス１３のＰＩＭＢ３０にメディアを記憶することにより、メディアの漸次送信とレンダリングが可能となる。送信側においては、送信側のデバイスで生成されたメディアは、それが受信されると、漸次ネットワーク上に送信することができる。種々の実施例においては、エンコードされたメディア（どのように生成されたかにかかわらず）は、ＰＩＭＢ３０に記憶される前、後、またはほぼ同時に漸次送信することができる。また、受信側では、入ってくるメディアは、ネットワークを通じて受信されごとに漸次レンダリングすることもでき、ユーザが望めば、ほぼリアルタイムモードでメディアレビューすることができる。種々の実施例においては、入ってくるメディアは、受信側のデバイス１３のＰＩＭＢ３０に記憶されるごとに、記憶される前、後、またはほぼ同時に漸次レンダリングするこができる。受信メディアをタイムシフトモードでレビューするつもりであれば、後でメディアをＰＩＭＢ３０（または、ローカルＰＩＭＢ３０に置き換えられた場合は、サーバ１６上のＰＩＭＢ８５でも可）から取り出し、ユーザが指定する時にレビューすることもできる。
【０１４５】
本アプリケーションの文脈において、「漸次的」または「漸次」という用語は、広く解釈されることを意図し、一般にデータの利用可能性に基づいてデータストリームを継続加工することを意味する。例えば、メディアが作成またはデバイス１３上で生成されるに従い、メディアが入手可能な限り、メディアの漸次的エンコード、記憶、パッケージ化および送信は継続する。人が話すと、その人が話している間、メディアは、漸次的すなわち継続的にエンコードされ、記憶され、パッケージ化され、送信される。その人がポーズすなわち、話すのを止めると漸次プロセスするメディアはない。その人が再び話すことを再開すれば、メディアの漸次的処理は再開する。また、受信側では、メディアが受信されている限り（すなわち、入手可能な限り）、メディアは、漸次処理される。メディアが受信されると、そのメディアは継続的に記憶される。メディアが受信されている限り、ほぼリアルタイムモードの場合は、継続的にレンダリングされ、タイムシフトモードでは、記憶装置から継続的にレンダリングされる。上記説明は音声の文脈で述べたが、全てのタイプのメディアが同様に漸次処理することができる。また、メディアの漸次的加工は、必ずしも時間でインデックスされた順序で漸次処理される必要はない。むしろ、メディアは受信された順序で処理される。もし、メディアがインデックスの順序から外れて受信されたら、一実施例においては、受信されたメディアは受信された順序で漸次処理される。そして、ＰＩＭＢ３０の中で、インデックスされたシーケンスに組織化される。代替的な実施例においては、受信メディアはインデックスされたシーケンスで組織化され、漸次レンダリングされる。
【０１４６】
［Ｈ．２ ＰＱＭの動作フロー図］
ＰＱＭ２６ｇは、継続的に計算される、送信側と受信側のノードのペアの間の実際の送信容量すなわち帯域幅の近似値（すなわち、所定の時点でのネットワークの能力の測定）、すなわち最大可能ビットレート（ＭＡＢＲ）と呼ばれる計量に依存する。瞬時にネットワークの状態が変化するごとに、ＭＡＢＲは更新される。ネットワークの処理量、パケット損失、およびジッタの定期的測定値が、ＭＡＢＲを計算することによって考慮される。また、他の実施例においては、ＭＡＢＲは、時刻、ネットワークのタイプ、その他の条件またはパラメータに基づいて手動でセットまたは制限してもよい。
【０１４７】
また、ＰＱＭは、受信側の意図を考慮し、時間依存型の送信を最適化する。下記のいずれかの場合、送信は時間依存型であるとみなされる。すなわち、（ｉ）受信側の意図が、送信を「ライブ」すなわちほぼリアルタイムモードでレビューしようとしている、または（ｉｉ）受信側が、なんらかの理由で（例えば、メッセージは先にアーカイブ部８９に保存された）、デバイス１３には現在記憶されていないメッセージを即座にレビューしたいと望んでいる。受信側の意図は、受信側の動作によって推論するか、受信側が自分の意図を設定するか別途指定してもよい。一方、受信側の意図がタイムシフトモードでメッセージをレビューすることであれば、送信は時間依存型でないとみなされる。受信側が、ライブモードかタイムシフトモードかどちらかで送信をレビューしようという意図が、少なくとも部分的には、送信の「適時性要件」を定義する。その他の種々の実施例においては、通信の緊急性または優先順位といったファクタも、送信の適時性要件を定義するときに考慮される。
【０１４８】
送信側と受信側のペアの間のネットワーク経路のノードもまた、受信側の意図のステータスに関して一貫性のあることが必要である。もし、一個のターゲット受信側が適時性を指示したら、すなわち、送信を即座にすなわちライブでレビューしたいと望んだ場合、送信側と受信側の経路に沿うネットワーク上の全ての中間ノードは、その他の受信側要件にもかかわらず、同じ適時性要件を持たなければならない。したがって、各中間ノード適時性要件は、送信が送られた受信側ノードに依存する。この依存性は、ネットワーク送信経路におけるターゲットノードのための「要件の融合」と言われる場合もある。
【０１４９】
さらに、ＰＱＭは、予約されたメッセージペイロードの送信のための理想ビットレート（ＩＢＲ）を考慮する。時間依存型の通信のために、ＩＢＲは、ほぼリアルタイムまたはライブ通信に必要とされるパケット化レート（以下、リアルタイムビットレート（ＲＴＢＲ）という）に基づいて計算される。例えば、音声場合、２０ミリ秒の音声データを含む２０ミリ秒毎のパケット化レートは、ライブ会話を行うための許容ＩＢＲが考慮される。キロバイト毎秒のシステムのためのＲＴＢＲは、１秒の音声ペイロードデータに送信するために生成される全てのネットワークヘッダのサイズを加えたサイズとなる。ビデオメディアまたは音声とビデオの組み合わせのためのＲＴＢＲは、単なる音声よりも実質的に高くなる。センサまたはＧＰＳ位置測定データ等のその他のタイプのメディアのためには、音声よりも低くなると思われる。非時間依存型の通信のためには、ＩＢＲは、ネットワークを通じての通信の使用量すなわち効率を最適化するために最大効率ビットレート（ＭＥＢＲ）に設定される。ＭＥＢＲは、パケット化レートを調節することによって、下層のネットワークのために最大可能な値に計算される。送信側と受信側のペアの間で、多数のメッセージまたはペイロードが送られ場合は、統合ＩＢＲ（ＡＩＢＲ）が送信のために考慮される。
【０１５０】
ＰＱＭは、各送信側と受信側ペアのための一連の送信ループのデータを送信することによって動作する。各送信側と受信側ペア用の送信ループは、単独のものである。ネットワーク上のいかなる送信もその他送信側・受信側ペアのＭＡＢＲに影響を与えうる。従って、ＭＡＢＲは、全ての受信側について継続的に計算されることが望ましい。
【０１５１】
図９Ａないし９Ｃは、一組の送信側と受信側ペアのためのＰＱＭの動作シーケンスを示すフロー図である。図９Ａは、一組の送信側と受信側ペア間のＭＡＢＲを決定するステップを示す。図９Ｂは、一個の送信側と受信側ペアの各送信ループのためのＡＩＢＲを計算するステップを示すフロー図である。図９Ｃは、送信側と受信側ペア間で送信するデータのループ当たりの量を決定するシーケンスを示す。三つの図に示す処理は、以下に詳述するように、同時に実行され互いに情報のやりとりをする。
【０１５２】
図９Ａにおいて、フロー図５０は、送信側と受信側ペア間のネットワークインタフェースのためのＭＡＢＲの計算を示す。最初のステップ５０１において、送信側と受信側のペア間のネットワークインタフェースをモニタする。ステップ５０２で、送信側は、受信側におけるネットワーク接続のステータスに関する情報を含むレポートを定期的に受信する。レポートは、受信側によって観測されたネットワークインタフェースでのデータ処理量５０３、パケット損失５０４、およびジッタ５０５の現在のステータスに関する情報を含む。ステップ５０６で、このレポートに含まれるこれらの観測に基づいて送信側でＭＡＢＲが計算される。これらのレポートのデータをモニタすなわち監視することによって、送信側と受信側のペア間の現在のネットワーク性能または状態に基づいてＭＡＢＲ値が継続的に調節される。ネットワーク性能がデータ送信にとってさらに好適になるので、ＭＡＢＲが向上する。もしネットワーク性能が送信にとって好適以下となれば、ＭＡＢＲが低下し、潜在的に結果としてゼロとなり使用不能なネットワークとなる。このレポートは、ＴＰＣネットワークのノードによって生成されるパケット損失レポートと同様のものであるが、さらに処理量情報とジッタ情報を含む。
【０１５３】
送信側と受信側のペア間に複数のネットワークインタフェースがある場合は、ＭＡＢＲは、受信レポートが受信されるインタフェース毎に計算される。直近にネットワーク上にトラフィックが送られていない場合、または、受信レポートが受信されていない場合は、ＭＡＢＲには現在のネットワークの状態が反映されないことがある。しかしながら、データが送信されているかぎり、受信側によって受信レポートが継続的に生成されるので、送信側のＭＡＢＲ計量はさらに正確な値に速やかに収束する。
【０１５４】
図９Ｂは送信ループのためのＡＩＢＲを計算するステップを示すフロー図５２である。最初のステップ５２１において、メディアを有するメッセージ（メッセージに所属する時間でインデックスされたメディアの部分）が現在のループの送信側と受信側のペア間で送信される準備ができていることが確認される。つぎに、メディアを有するメッセージのリストが、作られる（５２２）。リスト５２３の各メッセージについて、各メッセージの時間的制約すなわち適時性要件が考慮される（５２４）。もし、個々のメッセージに時間的制約がなければ、ＩＢＲは最大効率ビットレート（ＭＥＢＲ）にセットされる（５２５）。一方、メッセージに時間的制約があるばあいは、リアルタイムビットレート（ＲＴＢＲ）にセットされる（５２６）。次のステップ５２７において、リストのメッセージ毎に先に計算されたＩＢＲは、合計されて、送信ループのための統合理想ビットレート（ＡＩＢＲ）５２８となる。戻り矢印５２９にて示すように、上記のプロセスは、送信ループ毎に送信側と受信側のペア間で繰り返される。
【０１５５】
図９Ｃにおいて、フロー図５４は、送信ループ毎に送信側と受信側のペア間で送信するデータのレートを決定するシーケンスを示す。最初のステップ５４１において、ＭＡＢＲ（図９Ａで計算された）は、次の送信のためにＡＩＢＲ（図９Ｂで判断された）と比較される。
【０１５６】
ＭＡＢＲがＡＩＢＲ以下であれば、ループ内の送信の準備ができていると識別されている全てのメッセージが、ＩＢＲレートでパケット化され（５４２）、送信される（５４３）。
【０１５７】
一方、ＭＡＢＲがＡＩＢＲ未満のときは、一連の手順が適用されて、ＰＱＭが以下の目標が満足されるように調節される。すなわち、データの適切なコピーをタイムリーに送達すること、利用可能な帯域幅を有効に使うこと、および／またはペイロードコンテンツおよび現在のネットワーク条件を満足する品質、パケットサイズおよび送信レート。
【０１５８】
最初のステップにおいて、リストのメッセージは、タイム時間的制約がないかレビューされる（５４４）。時間的制約のあるメッセージがなければ、ビットレートは、ＭＡＢＲまで引き下げられて（５４５）、メッセージが送信される（５４３）。
【０１５９】
リストに時間的制約のあるメッセージが含まれる場合は、時間的制約のないメッセージに割り当てられたビットレートは、ＭＡＢＲの制限が満足されるまで引き下げられる（５４６）。ビットレートをゼロになるまで引き下げても、ＭＡＢＲを満足しないときは、これらの時間的制約のないメッセージは、ループに送信されるメッセージのリストから除去される。ビットレートがＭＡＢＲ以下になるまで引き下げられ、残ったメッセージはパケット化され、送信される（５４３）。
【０１６０】
時間的制約のないメッセージを取り除いてもＭＡＢＲを満足しない場合は、残る時間的制約のあるメッセージのために１ないし複数個の低い品質のコーデックの使用を含む別の手順５４７を使う。この送信ループの間により少ないビット送信することによって、できるだけ早くペイロードデータの送信しようとする試みがなされる。言い換えれば、ペイロードの品質を引き下げることによって、送信は所定の時間内により少ないビット送信することになる。種々の実施例において、それぞれ異なるビットレート対品質のトレードオフをもつ異なる１ないし複数個のコーデックを使うこともできる。低い品質の１ないし複数個のコーデックを使って間に合う場合、すなわち、ＭＡＢＲの制限が満たされれば、メッセージは送信される（５４３）。
【０１６１】
低い品質のコーデックを使用しても、ＭＡＢＲがまだ満足されない場合は、時間的制約のあるメッセージのパケット化の間隔を増やす（５４８）。この手順によりヘッダ対ペイロードの比率が上げられ、これにより全体のビットレートが下げられるが、待ち時間（すなわち、受信側への送信の送達遅延）が導入される。この手順によってＡＩＢＲがＭＡＢＲ以下になれば、送信５４３がはじまる。
【０１６２】
もし、パケット化の間隔変更後も、まだＭＡＢＲが満たされない場合は、ビットレートがＭＡＢＲ制限内になるまで漸次引き下げられる（５４９）。この方法でビットレートが引き下げられると、時間的制約のあるメッセージは、ライブ会話の維持ができないレートで送られる。したがって、会話は、「ライブ」から強制的にはずされてしまう。ネットワークがダウンまたは非常に悪い状態のときはデータの送信が始まらない場合もある。再度、上記のシーケンスが送信側と受信側のペア間で送信ループ５４１０毎に繰り返される。
【０１６３】
送信側と受信側のペア間に、多数のネットワークインタフェースがある場合は、図９Ｃを参照して記述したシーケンスが、受信レポートが可能なインタフェース毎に実行される。種々の実施例において、送信側は、多数のインタフェースの中を、送信ロードを送達するためのロジックを含むことができる。別の例においては、ペイロードは、一個のインタフェースにのみ送ることができ、別の実施例においては、幾つかの又は全てのインタフェースを使うことができる。
【０１６４】
上記の説明は、システム１０の送信側と受信側ペアの全てに当てはまる。ほとんどの状況において、送信側と受信側ペアには、クライアント１２、可動デバイス１３およびサーバ１６、二個のサーバ１６、デバイス１３を可動する一個のサーバ１６とクライアント１２または二個のクライアント１２がそれぞれ含まれる。送信側のノードが２つ以上の受信側ノードに同時に送信している場合は、図９Ａないし９Ｃを参照して説明した上記のシーケンスが受信側と送信側ペア毎に一斉に起こる。
【０１６５】
［Ｈ．３ ＤＱＭ動作フロー図］
ＤＱＭ２８ｇは、クライアント１２で受信したデータが壊れているまたはパケットが失われていないか判断する。さらに、受信側クライアント１２のＤＱＭ２８ｇは、受信レポートを生成し、ネットワーク上の送信側ノードに送り返す。また、ＤＱＭ２８ｇは、バックグラウンドの処理を行い、送信されるデータの正確なコピーが最終的に受信され記憶されることを確実にする。これらの機能について、図９Ｄないし９Ｆを参照して説明する。
【０１６６】
図９Ｄは、紛失データおよび／または壊れたデータがないかチェックするＤＱＭ２８ｇの動作を示すフロー図である。最初のステップ５６１にて、ＤＱＭ２８ｇは、ＣＲＣあるいは同様の完全性デェック機構等の既知の技術を使って、壊れたパケットがないかデェックする。もしパケットが壊れていると、紛失したものとみなされる（５６２）。次に、ＤＱＭ２８ｇは、紛失パケットがないか確かめる（５６３）。もし、予め決められた時間が過ぎてもシーケンスのずれたパケットが受信されなければ、それは紛失したものとみなされる。ＤＱＭ２８ｇは、紛失あるいは壊れたパケットをＤＮＱＳ３２にメモする（５６４）。一方、紛失あるいは壊れたパケットが検出されなかった場合、ＤＱＭ２８ｇは、帯域幅をセーブするために、送信側が意図的に受信したデータの品質をひき下げたのかどうか判断する（５６５）。引き下げられた品質は、ＤＮＱＳ３２にメモされる（５６６）。受信したデータの品質が引き下げられたかどうかにかかわらず、データの受信情報（例えば、パケットのシーケンス番号、タイムスタンプ、およびそのパケットが送られるネットワークの次のノードのネットワークアドレス）が、ＤＮＱＳ３２に記憶される（５６７）。上記のプロセスは、フロー図の戻り矢印で示されるように最初から継続的に繰り返される。
【０１６７】
図９Ｄに詳細に示すプロセスの結果、質が引き下げられていないパケットの受信、品質が引き下げられたパケットの欠陥および紛失パケットに関する情報は、全てＤＮＱＳ３２に記憶される。メディアを受信すると、ＤＮＱＳ３２は、メディアのステータスに関する最新情報を維持する。
【０１６８】
図９Ｅは、ＤＱＭ２８ｇの受信レポート生成機能の動作を示すフロー図である。最初のステップにて、ＤＮＱＳ３２は定期的にスキャンされ（５８１）、受信レポートを生成する必要があるメディアかどうか判断される（５８２）。ＮＯの回答の場合、上記のスキャンプロセスが繰り返される。一方、メディアが識別された場合は、プロセスにおいて、そのメディアが、時間的制約があるかどうか、すなわち、ユーザはメディアをライブでレビューしようとしているのか、それともデバイス１３に記憶する必要のない、メディアを即座にレビューしようとしているのか、判断する（５８３）。
【０１６９】
時間的制約がない場合は、受信側は、送信側に再送優先順位を（以下に定義する如く）低にセットするよう通知する（５８４）。時間的制約がある場合は、パケット損失の量が考慮される（５８５）。パケット損失の量が使用可能な品質の範囲を超えていれば、再送優先順位は、高にセットされる（５８６）。上記のようにパケット損失の量が大きすぎる場合は、受信側は、受信と同時にそのメディアをレビューすることはできない。品質が許容範囲内であれば、すなわち、レンダリングしたときに理解可能であれば、受信レポート送信の優先順位が低にセットされる（５８４）。受信側が、受信と同時にレビューしているかどうかにかかわらず、受信レポートが送られ（５８７）、ＤＮＱＳ３２が更新され（５８８）、ネットワーク品質管理部（ＮＱＭ）２８ｈが更新される（５８９）。したがって、ステップ５８４で定義される再送要求は、時間的制約に基づく条件である。ステップ５８６で定義される送信要求は、時間的制約と品質の両方に基づく条件である。
【０１７０】
再送優先順位は、送信側のＰＱＭ２６ｇに、再送が必要なメディアの送信レートに正しく優先順位をつけるように通知する。例えば、再送優先順位が高にセットされると、送信側ＰＱＭ２６ｇは、どの新しいメディアよりも先に再送しなければならない。優先順位が低の場合は、ＰＱＭ２６ｇは、新しいメディアの後に再送信メディアを送信しなければならない。
【０１７１】
上記プロセスは、メディアが受信される毎に受信レポートが生成されるように、継続的に繰り返される。もし、送信側がタイムリーに受信レポートを受信しない場合、送信側のＰＱＭ２６ｇは、送信レートを引き下げ、受信レポートが受信されない場合は、最終的には送信を停止する。
【０１７２】
図９Ｆは、紛失または品質を引き下げられたメディアを要求するシーケンスを示すフロー図である。最初のステップ６０１にて、ＤＮＱＳ３２は紛失メディアまたは品質を引き下げられたメディアがないか、定期的にスキャンされる（６０２）。紛失メディアも品質を引き下げられたメディアもない場合は、上に定義したスキャンが定期的に繰り返される。
【０１７３】
予め決められた閾値の時間が経過しても、シーケンス外のパケットが着信しない場合は、メディアは紛失したものとみなされる（６０３）。パケットが閾値の前に着信すれば、紛失とはみなされない。一方、パケットが閾値を越えても着信しない場合は、そのパケットは紛失したとみなされる。紛失パケットについて、再送を要求する低優先順位が作られ（６０４）、要求の時間がＤＮＱＳ３２にメモされる（６０５）。このプロセスは、紛失パケットが受信されるまで繰り返される。紛失パケットが着信し、ＰＩＭＢ３０の中に対応するメディアがある場合は、紛失メディアのステータスはＤＮＱＳ３２から除去される。したがって、ステップ６０４で定義される再送信要求は、メディアが紛失したかどうかの判断に基づく条件である。
【０１７４】
もし、品質を引き下げられたメディアであれば、ＤＱＭ３２は、そのメディアがライブの会話の一部かどうか判断する（６０６）。品質を引き下げられたメディアでない場合は、品質を引き下げられたメディアの完全な品質のコピーを求める要求が作られ（６０７）、完全な品質のメディアが紛失したと認定され（６０８）、要求した時間がＤＮＱＳ３２にメモされる（６０９）。そのメディアがライブの会話の一部分である場合は、ネットワーク回線容量を残すために、即座には動作はおこなわれない。会話がライブモードから遷移する場合は、６０７ないし６０９のステップが実行され、最終的には品質を引き下げられたメディアの完全な品質のコピー（正確なすなわち完全な）が確実に受信される。受信側クライアント１２のＰＩＭＢ３０にデータが入手可能になると、関係するメディアの品質引き下げのステータスはＤＱＮＳ３２から取り除かれる。ステップ６０７で定義される送信要求は、品質の引き下げとライブ会話の一部でないことの二つに依存する条件である。
【０１７５】
上記のプロセスは、戻り矢印で示すように、フロー図の６０５および６０９からトップの６０１へ、継続的に繰り返される。図９Ｆに示すプロセスを繰り返すことによって、送信される全てのメディアの完全なコピーが、最終的に受信側デバイス１３のＰＩＭＢ３０に記憶される。このように、送信されるメディアの完全なコピーの記憶が受信側デバイス１３で保証される。
【０１７６】
［Ｉ．グラフィカルユーザインタフェース］
図１０は、クライアントアプリケーション１２を実行するデバイス１３の例を示す。デバイス１３は、グラフィカルユーザインタフェースディスプレイ１１０、データ入力ボタン、キー、すなわちキーボード１１２、マイク１１４、および電気信号を音に変換するスピーカー等のトランスデューサー１１６を含む。また、ディスプレイ１１０はタッチスクリーンとして入力を受け付ける。さらに、ディスプレイ１１０とキーボード１１２は、タッチスクリーンインタフェースを用いて連結することもできる。上記のように、デバイス１３は、下記のようないろいろな異なる通信ツールであってもよい。例えば、デスクトップコンピュータ、ラップトップまたはその他のモバイルコンピュータ、パーソナル・デジタル・アシスタンス、プログラマブルの固定またはセルラーホン、プログラマブルラジオ、その他どのようなタイプであれ、プログラマブル通信装置など。図に示すデバイス１３の例は、上に挙げた全ての通信デバイスを代表し、あるいは含む意味で、「一般的」例である。さらに、用語「グラフィカル」ユーザインタフェースは、限定的意味に解釈されるべきではない。デバイス１３上で実現することのできるその他のタイプのユーザインタフェース、以下に説明する多様な機能を実行するために使うことのできる全て、すなわち音声／ＤＴＭＦインタフェース、音声ユーザインタフェース（ＶＵＩ）、無線切り替えインタフェース、あるいはその組み合わせを含む。単純に説明するために、ユーザが情報のやりとりするためのデバイス１３のさまざまなタイプの方法を、一般に「ユーザインタフェース」と称する。
【０１７７】
全てのデバイス１３が、そのタイプにかかわらず、ユーザがシステム１０の中でデバイス１３を操作し、他のユーザのデバイス通信することができるユーザインタフェースを有することが好ましい。ユーザインタフェースは、実質的に限りなく異なる表装、感触をもつように設計されてもよいが、全てのデバイス１３が共通に備えるべき幾つかの機能がある。これらの機能を以下列挙する。
【０１７８】
ユーザインタフェースは、次のようなステータス標識すなわちフラッグを一またはそれ以上含むことが好ましい。すなわち、（ｉ）バッテリ標識、（ｉｉ）接続標識、（ｉｉｉ）時計、（ｉｖ）送信ステータス、（ｖ）通信同期ステータス、（ｖｉ）レビューステータス、（ｖｉｉ）優先順位メッセージを求める注意および（ｖｉｉｉ）失敗メッセージなど。
【０１７９】
ユーザインタフェースは、一個の会話を行い、管理するための次のような機能、フラッグおよびコンポーネントを含むことが望ましい。すなわち、（ｉ）会話の名前および／または参加者のリスト、（ｉｉ）会話のステータス、（ｉｉｉ）会話のタイプ、（ｉｖ）会話の継続時間、（ｖ）会話の頭からの時間、（ｖｉ）人目に付くメッセージ、（ｖｉｉ）参加者のプレゼンス／ステータス、（ｖｉｉｉ）ナビゲーション付きメタデータ、（ｉｉｘ）会話の属性または指示子、（ｉｘ）タイトル、スケジューリング、参加者、会話サマリーを含み、会話のセットアップ、（ｖ）どの参加者がメッセージを投稿したか、だれがメッセージを聞いたか、見たかを示す標識。
【０１８０】
ユーザインタフェースは、また、上に列挙した機能に加え、マルチ会話を行い、管理するための次のような 機能、フラッグおよびコンポーネント含むことが好ましい。すなわち、（ｉ）会話毎の名前／識別子、（ｉｉ）ライブ／アクティブまたはスタンディング／インアクティブ標識、（ｉｉｉ）レビュー位置、頭／タイムシフト、（ｉｖ）優先順位とその他の属性、（ｖ）会話の部分が紛失したかを示す標識。
【０１８１】
ユーザインタフェースは、好ましくは以下の多数のナビゲーション機能を含む。すなわち、（ｉ）会話毎のＤＶＲスタイル早戻し／早送り（ｉｉ）インスタントメッセージングスタイルの個人メッセージナビゲーション（ｉｉｉ）会話時間標識（ｉｖ）タイムスケールシフティング（すなわち、会話のメッセージを通じての後方ズーミングと転送）、（ｖ）会話の優先順位の変更、（ｖｉ）ハングアップおよび（ｖｉｉ）ホームなど。
【０１８２】
前記機能は、いろいろな方法、例えば、タッチスクリーングラフィカルユーザインタフェース１１０またはデータ入力ボタン、キーすなわちキーボード１１２、マウス、音声入力コマンドもしくはその組み合わせ等のその他入力デバイスを使って実現することができる。上記の機能および実現する方法は、全てを網羅的するものではない。使用可能な様々な方法と技術は広範囲にわたるので、その全てをここにリストし議論することは実際的ではない。
【０１８３】
［Ｊ．会話］
ＭＣＭＳアプリケーション２０は、以下のようないろいろな異なるタイプの会話をサポートする。ほぼリアルタイムな、あるいは「ライブ」コール、すなわち、参加者が話したときからまたは第一の参加者の声を聞いた時からの遅延が非常に小さい会話；参加者が交換する音声メッセージで、メッセージ間の遅延が長い会話、多数のユーザが参加する「ライブ」会議通話；定期的に予約した時間に行われるスタンディング会議通話；同時ブリーフィングのような、設定可能な構造化されたコールタイプで、前もってレビューできるように、参加者がそれぞれ予め他者にブリーフィングメッセージを残し、ライブ会議通話に参加する会話。さらに、ＭＣＭＳアプリケーション２０の固有の属性として、異なるタイプの会話の間をユーザが遷移できる。例えば、参加者は音声メッセージモードからライブ通話モードへ切目なく遷移したりまた戻ったりできる。あるいは、ライブ会議通話の参加者が音声メッセージモードに遷移し、会議コールの後に互いに更新事項または行動事項を送信しあう。いくつかの例を説明したが、システム１０は極めてフレキシブルであり、異なるタイプの通話ないし会話間およびマルチ会話間の遷移方法の多くの選択肢を提供できることを理解されたい。メッセージ間の遅延を変えることによって、参加者は自分の要求に最も適した会話のタイプの間を効果的に流れることができる。したがって、上記の例は限定的に解釈されるべきではない。
【０１８４】
上記のように、本来の文脈とシーケンスが維持されたメッセージによって会話が構成されている。送ったメッセージは、現存今ある会話に所属するか、新しい会話をはじめるかどちらかである。典型的な会話は、定義された主題、トピック、時間、グループまたはチャンネルの回りに組織された一組のメッセージを含む。例えば、会話は、人の共通のグループ、たとえばクラブのメンバー同士、会社では各週の販売会議のような定時のスタンディング会話、友達同士であれば、ディナープラン作り等のさまざまなトピックでその場その場の会話などが考えられる。
【０１８５】
それぞれの会話は、名前、参加者のリスト、開始と終了時間、少なくともペンディング、アクティブまたは終了を含む状態を含む一組の属性によって定義される。その他の実施例ではその他の会話状態もありうる。ユーザは各自のデバイス１３上のＭＣＭＳアプリケーション２０を使ってやり取りをする。好適な実施例では、このインタフェースにより、ユーザは様々な属性を使って会話を組織することができるようになる。
【０１８６】
参加者と会話の間の関係にも属性がある。これらの属性には、優先順位、ステータス（会話における参加の状態）などがあるがそれに限定されない。参加者のステータスの値には、アクティブ、一時にひとつの会話以上に参加、タイムシフトモードで会話をレビュー、ライブにキャッチアップ、受動的に参加（すなわち、アクティブにレビューしていないが、高い優先順位のメッセージを受信中）、スタンバイ、もしくは会話を無視（すなわち、会話に参加、記録することに減退）、などがある。
【０１８７】
受信側の視点から、ユーザがメッセージの相対的優先順位を選択または定義することもできる。例えば、ある人のボスからのメッセージは、世間の知人よりも一般に高い優先順位があたえられる。幾つかの実施例においては、ある受信者は自分自身の優先順位を設定することができる。ＭＣＭＳ−Ｃの実施例として、ユーザは、会話を連続してレンダリングできるようにその会話をサブセットすることも選択できる。この場合ユーザは、これらの会話に優先順位をセットする。システムは、このユーザセットした優先順位を使い、レンダリングすべきメッセージに順序をつける。上記のアルゴリズムによって、ユーザによる優先順位およびメッセージデータに関して入手できる情報（ＭＴＳＤを超えて）を使って、レンダリングすべきメッセージを並べかえる。
【０１８８】
戦術的通信のようなその他の実施例では、受信側は優先順位を設定できないか制限される。例えば、消防士は、消防隊長からのメッセージの優先順位を下げることはできない。しかし、送信側のユーザは、緊急メッセージまたは高い重要度のメッセージを送信することができる。メッセージに緊急のタグを付けることによって、受信側の全ての優先順位の設定を無視して、メッセージは受信側で即座にレンダリングされる。多数の緊急メッセージ同士での衝突は、予め決められた優先順位スキームに基づいて解決される。
【０１８９】
［Ｋ．ＭＣＭＳ動作］
図１１Ａは、ＭＣＭＳアプリケーション２０のおもな機能を示す組織図１１００である。主な機能には、アカウント管理１１０２、会話管理１１０４、集合会話リスト管理１１０６、会話参加１１０８、通話管理１１１０、およびコンタクト管理１１１２がある。システム１０に登録しログインした後、ユーザは、以下に詳細に説明する、さまざまな管理機能を実装するデバイス１３のユーザインタフェースを通じて、ナビゲートすることができる。幾つかの実施例では、これらの機能が、大きな自由度を提供する。戦術的な無線または通信無線のような他の実施例では、ユーザインタフェースの実装は、多数のユーザ機能およびデバイスの実用性満を足するために予め設定されたオプションにより拘束を受ける場合もある。ここでの説明は、例示的に挙げるものであって、ＭＣＭＳの機能の包括的な説明を意図したものではなく、ＭＣＭＳの属性の幾つかの概観を提供することを意図したものである。
【０１９０】
［Ｋ．１ アカウント管理］
アカウント管理機能１１０２のもとで、登録ユーザは、一定の設定と好みを変更することができる。ユーザは、自分のＥメールアドレス、パスワード、名前、電話番号、電話パスワード、着呼番号、デフォルトおよび／またはユーザ定義レンダリング速度、タグ、メッセージをレビューするためのゲインまたはボリュームのレベル、ライブモードへキャッチアップなどを変更することができる。これらの変更を行うには、ユーザは、自分のデバイス１３のインタフェース１１０から適切な情報に入る。ＭＣＭＳアプリケーション２０は、ＭＣＭＳデータベース２２に好みの更新を文字書き込みで回答する。
【０１９１】
［Ｋ．２ 会話管理］
図１１Ｂに示すように、会話管理１１０４はユーザが、自分の会話の集合リストを見ること、新しい会話を開設すること、会話の細部を更新すること、会話を削除すること、会話を閉じること、ができるようにする一組の機能である。これらの機能のそれぞれについて以下に説明する。
【０１９２】
会話を見る１１０４ａ−会話毎に、ＭＣＭＳアプリケーション２０は、ユーザに以下の一またはそれ以上の属性を提供することができる：会話の名称、実際の開始時間、最新の活動、タグ、期間および参加者のリスト。各参加者には、名前および／または電話番号、ステータス（ライブ通話、その他のコール、過去、キャッチアップモード、オフライン可、オフライン−使用不能）。
【０１９３】
会話の開設１１０４ｂ−ユーザは、インタフェース１１０を通じて、会話名、コンタクトのリストおよびオプションとして予約した開始時間を入力して会話を開設する。開始時間に指定がなければ、開始時間は即座とみなされる。応答として、ＭＣＭＳアプリケーション２０は、コンタクトリスト上の各参加者の記録関連づけながら、データベース２２の中に新しい会話を開設する。また、ＭＣＭＳアプリケーション２０は、データベース２２の中にコンタクトリスト上のユーザ毎の参加者記録を作成し、呼出し側に、コンタクトリスト上に他者の情報が存在することを受信できるようにする。会話が予約されている場合は、ＭＣＭＳアプリケーション２０は、指定された時間に会話を開始する。そうでない場合は、会話は即座に開始する。
【０１９４】
会話細部の更新１１０４ｃ−ユーザは、ユーザインタフェース１１０を通じて会話に変更を加えることができる。例えば、参加者が加えられたり除去されたりできる。参加者のステータスに変更があれば、ＭＣＭＳデータベース２２の中で更新される。
【０１９５】
会話の削除１１０４ｄ−ユーザは、インタフェース１１０を通じて自分の会話リストから特定の会話を削除することができる。これに応じて、ＭＣＭＳアプリケーション２０は、データベース２２に当該変更を書き込み、会話の削除を指示する。
【０１９６】
会話の終了１１０４ｅ−ユーザは会話の終了を選択することができる。一実施例においては、会話を開設したユーザのみがその会話の終了を選択することができる。
【０１９７】
［Ｋ．３ 集合会話リストの管理］
図１１Ｃに示すように、集合会話リスト管理１１０６は、ユーザにマルチ会話（すなわち、ユーザの集合会話リスト）に参加することを可能にする一組の機能である。集合会話リスト管理機能により、ユーザは、自分のデバイス上のインタフェース１１０を通じて、一方で、タイムシフトモードで別の会話に参加しながら、会話「ライブ」に参加することができる。
【０１９８】
会話の終了１１０６ａ−インタフェース１１０を通じて、ユーザはユーザの集合会話リストの中から一個の会話を選択することができる。現在の会話メッセージは、「ライブ」またはタイムシフトモードでレンダリングすることができる。ユーザは、時々集合会話リストの中の現在の会話を切り替えることができる。
【０１９９】
会話モードの切り替え１１０６ｂ−オプションの実施例において、ユーザは、動作のモードをＭＣＭＳ、ＭＣＭＳ−ＣおよびＭＣＭＳ−Ｓ間で切り替えることができる。
【０２００】
［Ｋ．４ 会話への参加］
図１１Ｄに示すように、会話参加１１０８は、ユーザに会話の開始、会話への参加通知の受信、会話のステータス情報の取得、および会話の終了を可能にする一組の機能である。
【０２０１】
会話の開始１１０８ａ−会話が開かれると、インタフェース１１０を通じてユーザによって、またはＭＣＭＳアプリケーションの中のスケジューラによって各参加者のステータスがチェックされる。もし、誰か参加者がオフラインであると、その人にコンタクトしようとする。もし、誰か参加者がオンラインになってはいるが別の会話に参加している場合は、ＭＣＭＳアプリケーション２０はその参加者に通知する。全てのオンライン参加者のプレゼンスステータスは、データベース２２のなかで更新される。
【０２０２】
受信の通知１１０８ｂ−システムはユーザインタフェース１１０を介してグラフィック表示および／または音響で通知を行い、注意を会話向けることが求められていることをユーザに通知することができる。
【０２０３】
会話ステータス１１０８ｃ−ユーザはデバイス１３のインタフェース１１０を通じて、会話のステータス要求することができる。これに応えて、ＭＣＭＳアプリケーション２０は、データベース２２に記憶されているステータス情報を集め、その情報をユーザに提供する。
【０２０４】
会話のポーズ１１０８ｄ−ユーザインタフェース１１０を通じて、ユーザは、アクティブ会話を終了するか、そこから切り換えて出ることもできる。これに応えて、ＭＣＭＳアプリケーション２０は、データベース２２の中のアクティブ会話のためのユーザの参加者ステータスを更新し、記憶・ストリームモジュール２４にその会話からそのユーザを取り除くよう指示する。
【０２０５】
［Ｋ．５ 会話のコントロール］
図１１Ｅに示すように、会話コントロール１１１０は、ユーザに会話への参加をコントロールかのうにする一組の機能である。これらの機能は、会話のメッセージをレビューするときにユーザに、ライブにキャッチアップ、頭にスキップする、過去のロケーションにジャンプする、ポーズ、早く再生および遅く再生することを可能にする。これらの各機能は、デバイス１３上のインタフェース１１０を通じてユーザによって開始される。
【０２０６】
ライブにキャッチアップ１１１０ａ−ユーザは、「ＣＴＬ」機能を使って進行中のライブ会話にキャッチアップすることができる。この機能が起動されると、ＭＣＭＳアプリケーション２０が、ユーザがレビューした会話の最後のポイントをデェックし、記憶・ストリームモジュール２４に先に聞かれなかったメッセージをユーザが指定するオプションの通常のレンダリングよりも早く再生レンダリングするよう指示する。会話の頭に達したら、ライブモードに途切れ目なく遷移する。
【０２０７】
ヘッドにジャンプ１１１０ｃ−この機能は、ユーザに、会話におけるユーザの現在のポイントと会話の頭間の途中にあるメッセージをスキップし会話の頭へジャンプすることを可能とする。実行されると、ＭＣＭＳアプリケーション２０が、記憶・ストリームモジュールに会話の頭のメッセージを即座にレンダリングするよう指示する（もし、会話の頭が現在のライブ通話であれば、これをライブにジャンプする（ＪＴＬ）という）。
【０２０８】
過去にジャンプする１１１０ｄ−この機能は、ユーザが巻き戻しすなわちリプレイ機能と同様、会話の先行するメッセージまたはポイントにジャンプして戻るのを可能とする。実行されると、ＭＣＭＳアプリケーション２０が記憶・ストリームモジュール２４に、巻き戻しポイントからメディアのレンダリングを開始するよう指示する。
【０２０９】
ポーズ１１１０ｅ−この機能は、ユーザに会話のメッセージのレビューをポーズすることを可能とする。応答として、記憶・ストリームモジュール２４は、別の命令が出されるまでメッセージのレンダリングを停止する。
【０２１０】
早く実行１１１０ｆ−この機能は、ユーザにもっと速くメッセージをレンダリングすることを可能とする。応答として、記憶・ストリームモジュール２４は、通常の速さよりも速くメッセージをレンダリングする。レンダリングの速さは、ユーザが指定するか、初期設定の多数のオプションの中から選択することもできる。
【０２１１】
遅く再生１１１０ｇ−この機能は、ユーザにメッセージをもっとゆっくりレンダリングすることを可能とする。応答として、記憶・ストリームモジュール２４は、通常の速さよりも遅くメッセージをレンダリングする。レンダリングの速さは、ユーザが指定するか、初期設定の多数のオプションの中から選択することもできる。
【０２１２】
［Ｋ．６ コンタクトの管理］
図１１Ｆに示すように、システム１０は、コンタクトリストとユーザグループを管理するためのホスト機能をユーザに提供する。これらの機能には、コンタクトとユーザグループを加える、編集する、削除する、がある。これらの各機能は、デバイス１３のインタフェースを通じて、ユーザによって実現される。ユーザのコンタクトリストまたはグループリストの変更、削除はすべてＭＣＭＳデータベース２２に記憶される。
【０２１３】
コンタクトを加える１１１２ａ−この機能は、ユーザにコンタクトリストに新しいコンタクトを加えることを可能とする。新しいコンタクトは、ユーザか外部のコンタクトに登録される。主に名前、電話番号、番号のタイプ（電話、オフィス、ホーム、コンピュータなど）、Ｅメールアドレス、その他個人情報などがコンタクト記録のために提供される。
【０２１４】
コンタクトの編集１１１２ｂ−この機能は、ユーザに現在のコンタクト記録を編集または更新することを可能とする。
【０２１５】
コンタクトの編集１１１２ｃ−この機能は、ユーザに現在のコンタクト記録を除去または削除することを可能とする。
【０２１６】
コンタクトを検索１１１２ｄ−この機能は、ユーザにコンタクトリストの中の特定のコンタクトを検索することを可能とする。検索は、名前、電話番号、直近にコールした、最も頻繁にコールした、グループなど多くの基準を使って行うことができる。
【０２１７】
参加者リスト入手１１１２ｅ−この機能は、ユーザに、例えば、名前、直近にかけた電話、直近にきた電話、最も頻繁にかけた電話など多くの異なる検索基準を使って、会話の参加者リストを検索、取り出しを可能とする。
【０２１８】
呼出し側にステータスの閲覧を許可１１１２ｆ−この機能は、第一のユーザに、他のユーザに第一のユーザのステータスを閲覧することを許可することを可能とする。権限のないユーザは、第一のユーザのステータスを閲覧することはできない。
【０２１９】
コンタクトのグループを作成１１１２ｇ−この機能は、ユーザに多数のコンタクトを一のグループに関連付けることを可能とする。ユーザがグループを定義すると、そのグループのコンタクトリストはＭＣＭＳデータベース２２に記憶される。
【０２２０】
コンタクトグループを編集する１１１２ｈ−この機能は、ユーザに、グループを編集またはグループのメンバーのためのコンタクト情報を更新することを可能とする。
【０２２１】
コンタクトグループを削除する１１１２ｉ−この機能は、ユーザにグループを削除することを可能とする。
【０２２２】
［Ｌ．ＭＣＭＳの動作］
［Ｌ．１ ＭＣＭＳ−Ｃ］
上記したように、ＭＣＭＳ−Ｃの動作は、ＭＣＭＳと同様に、システムによって自動的に管理される優先順位とメッセージのタイムシフトの階層的なシステムによって、付加的機能によってユーザにマルチ会話に連続して管理し、参加することを可能にする。ＭＣＭＳ−Ｃ機能の実行には、３個の基本的プロセスがある。図１２Ａに示すように、第一のプロセスは、連続的なレンダリングのための一組の会話を定義することである。一旦リストが定義されると、優先順位およびその他ファクタの階層的なセットがその会話のセットと関連するインデックスされたメディアペイロードに適用される。つぎに、インデックスされたメディアペイロードは、順序付けされた順序で配列される。配列された順序でメディアをレンダリングすることによって、会話のセットのメッセージが連続してレンダリングされる。
【０２２３】
図１２Ａは、連続してレンダリングする会話のリストを定義するステップを示すフロー図である。最初のステップ１２０２において、ユーザの会話の集合リストが定義される。次に、ユーザか、または予め設定されたデータ（ステップ１２０４）を使って、連続的なレンダリングを行うための統合リストの中から会話を選択する（ステップ１２０６）。例えば、戦術的な通信システムでは、主として予め設定したデータを使い会話を連続してレンダリングする。非戦術的なアプリケーションでは、ユーザは、継続的にレンダリングする会話を選択する上で、一定の高い自由度が与えられる。
【０２２４】
図１２Ｂは、継続する会話のメッセージをレンダリングする優先順位の階層的なセットを定義するステップを示すフロー図である。最初のステップ（１２０８）で、一組の優先順位のルールが定義され、連続してレンダリングされる会話のリストに適用される（１２０６）。種々の実施例においては、一組の優先順位のルールは、堅固な階層的な通信プロトコルから高い柔軟性をもつ通信プロトコルまであっても良い。例えば、しばしば堅固な階層性が望まれる戦術的な通信システムにおいては、現時点のメッセージがレンダリングされている順序が、優先順位のルールのセットとして与えられることが望ましい。例えば、戦術的なシステムにおいて、消防隊長からのメッセージの第一応答者に最も高い優先順位を与えることができる。次のレベルの優先順位は、燃え盛るビルの内部にいる消防士に与えることができる。次のレベルに、ビルの外側にいる消防士に優先順位を与えることができる。火災との戦いを監督している人の現在のメッセージに堅固な優先順位を定義することにより、重大性が少ない役割についている人に先立って、危険な場所にいる人にレンダリングすることができる。非戦術的通信では、個人的な必要を満たす独自の優先順位スキームを定義するうえでユーザは大きな自由度があたえられてもよい。例えば、営業部長は、最も重要なクライアントから重要度の少ないクライアントを継続する会話をリストして、優先順位のスキームを定義することができる。あるいは、ユーザは家族や友達の中で継続的なメッセージの優先順位をつけることもできる。使うスキームにかかわらず、継続する会話のための優先順位リストをこのプロセスで定義する（ステップ１２１０）。
【０２２５】
図１２ｃは、さまざまな継続する会話から受信したメッセージのキューの構造を示すフロー図である。最初のステップで、レンダリングされないメッセージのインデックスされたメディアペイロード（すなわち、メディアストリーム）の利用可能性が、連続してレンダリングされる会話ごとに継続的に検出される（ステップ１２１２）。使用可能なインデックスされたメディアペイロードストリームに優先順位の階層が適用される（ステップ１２１４）。優先順位の階層および以下に述べる可能な他のパラメータに少なくとも部分的に基づいて、使用可能なインデックスされたメディアペイロードが、シーケンス順序に配列される（ステップ１２１６）。続いて、インデックスされたメディアペイロードは、シーケンスの順序で連続してレンダリングされる（ステップ１２１８）。上記のプロセスを連続的に繰り返すことによって、マルチ会話のメッセージが連続してレンダリングされる。
【０２２６】
一実施例において、順序付けの順序は、部分的ないし全面的に優先順位の階層に基づく。代替的な実施例においては、他のパラメータに加え、階層および利用可能性も考慮されてもよい。例えば、シーケンスの順序は、以下にあげる一またはそれ以上のパラメータを使って定義することもできる。現在レンダリング中のインデックスされたメディアペイロードのストリームを高い優先順位の会話のインデックスされたメディアペイロードによって中断されることと関わる切り替えコスト、インデックスされたメディアペイロードの使用可能なストリームの品質、インデックスされたメディアペイロードが受信された場合の相対的タイム、配置換えの順序またはシステムのコントローラの入力。
【０２２７】
異なる会話のメッセージの間で衝突が起きた場合、シーケンスの順序の最初のインデックスされたメディアペイロードは、その他の使用可能なインデックスされたメディアペイロードのレンダリングが休止または遅延されている間に、レンダリングされる。衝突がない場合は、インデックスされたメディアペイロードは、可能になり次第、即座にレンダリングされる。
【０２２８】
さらに他の実施例においては、連続してレンダリングされる会話のメッセージは、オプションとして、タイムシフトモードでレビューされてもよい。第一の通信デバイスユーザが、連続してレンダリングされる会話に関わるメディアを生成する場合は、メディアはインデックスし、ネットワーク上のサーバ１６のＰＩＭＢ８５とともにデバイスのＰＩＭＢ３０に記憶することもできる。このように、会話がタイムシフトモードでレビューされる場合は、ユーザは、会話に関係する、入ってくるメッセージだけをレビューするか、または会話に関わる第一のユーザが作成したメディアと入ってくるメッセージの両方を、時間でインデックスの順序でレビューするか選択できる。
【０２２９】
［Ｌ．２ ＭＣＭＳ−Ｓの動作］
ＭＣＭＳ−Ｓすなわち同時モードにおいては、デバイス１３を実行するクライアント１２のユーザは、同時レンダリングするための一組の会話を定義することができる。一組の会話が定義されると、その一組の会話に関わるインデックスされたメディアペイロードのストリームが、それらが重複しているかどうかにかかわらずデバイス１３上に同時にレンダリングされる。代替的な実施例においては、オプションとして、ユーザは、メディアストリーム組から別途受信したインデックスされたメディアペイロードをレンダリングすることができる。また、オプションとして、同時会話のインデックスされたメディアペイロードは、ほぼリアルタイムモードまたはタイムシフトモードでレンダリングすることもできる。
【０２３０】
［Ｌ．３ ＭＣＭＳ、ＭＣＭＳ−ＣおよびＭＣＭＳ−Ｓの例］
図１３Ａないし１３Ｄは、ＭＣＭＳ、ＭＣＭＳ−ＣおよびＭＳＭＳ−Ｓの会話の属性と動作を示す一連の図である。
【０２３１】
図１３Ａは、ユーザ「Ｘ」と、「Ｙ」と「Ｚ」で示される他の２個のユーザとの間で行われる、会話「Ａ」のメッセージのインデックスされたメディアペイロードをレンダリングするシーケンスを示すタイム図である。この例では、ｔ１、ｔ５、５６、ｔ７およびｔ９で示されるタイムインターバルの間にユーザＹよって生成されるメディアである。ｔ３、ｔ６およびｔ９ないしｔ１０で示されるタイムインターバルの間にユーザＺによってメディアが生成される。
【０２３２】
ユーザＸのデバイス１３でのレンダリングシーケンスは図の一番下に示される。インターバルｔ１、ｔ５およびｔ７の間には、Ｙから取出したメディアのみレンダリングされる。ｔ３とｔ１０のインターバルの間には、Ｚから取出したメディアのみレンダリングされる。ｔ６およびｔ９のインターバルには、ＹとＺの両者から取出したメディアがレンダリングされる。ｔ２、ｔ４およびｔ８のインターバルには、ユーザＹ、Ｚのどちらもこの間メディアを生成していないので、何もレンダリングされない。ｔ１ないしｔ１０のインターバルは、固定的な時間のインターバルではなく、メディアが生成されている時間を示すだけであることに注意されたい。
【０２３３】
図１３Ａは、会話の属性を良くあらわしている。一個のユーザ（ＹまたはＺ）がメディアを生成していると、そのメディアは、Ｘのデバイス１３で受信され、それはレンダリング可能である。ユーザＸとＹがともにメディアを生成している場合は、どちらのメディアストリームもＸのデバイス１３で受信されミキシングに使用可能である。ユーザＸとＹのどちらもメディアを生成していない場合は、Ｘのデバイス１３ではメディアは何も受信されない。前にも述べたように、ユーザＸは、会話Ａの間に、リアルタイムモードかタイムシフトモードのどちらかで生成されたメディアをレビューするオプションがある。また、ユーザＸは、図に示すように、混合したフォーマットでメディアをレビューするか、ＹとＺからのメディアをタイムシフトモードで別々にレビューできるオプションがある。
【０２３４】
図１３ＢはＭＣＭＳの動作を示す。この例では、ユーザは、Ａ、ＢおよびＣで示す３個の会話に参加している。会話Ａ、Ｂ、およびＣについては、ユーザは、それぞれ（Ａ１、Ａ２、Ａ３、Ａ４）、（Ｂ１、Ｂ２、Ｂ３）および（Ｃ１、Ｃ２）で示すメッセージを生成または受信する。各メッセージのタイミングおよび期間は、時間線に沿う開始点で示す。この例では、メッセージＢ２を除き、全てのメッセージが時間的に重複していることに注意いただきたい。
【０２３５】
ＭＣＭＳアプリケーションを使って、ユーザは現在の一個の会話を選択する。選択された会話については、ユーザは入ってくるメッセージをレビューすることができ、会話の他の参加者に送信するメッセージを生成することができる。この例では、ユーザは、現在の順序で会話Ｂ、ＣおよびＡをそれぞれ選択する。したがって、メッセージのシーケンスは、最初はＢ１、Ｂ２、およびＢ３、Ｃ１、Ｃ２が続き、最後にＡ１ないしＡ４が来る。現在ある会話が選択されている間に、ユーザはほぼリアルタイムモードとタイムシフトモードの間で遷移でき、また戻ることができる。図に示す最終のレンダリングは、上の図に示すように、受信したメッセージのタイミングに対応するものではない。図の下の部分は、ユーザによって選択された会話の順序にに基づく、メッセージのレンダリング順序のみを示す。
【０２３６】
図１３Ｂの例は、ＭＣＭＳアプリケーションの属性を良く表している。ユーザは、現在行われている会話の中から一個を選択する。他の会話は休止する。また、ユーザは随時全ての会話の中を現在の会話を遷移することができる。
【０２３７】
図１３Ｃは、ＭＣＭＳ−Ｃの動作を示す図である。この例では、ユーザは連続する会話Ａ、Ｂに参加している。会話Ａでは、三個のメッセージＡ１、Ａ２、およびＡ３が受信される。会話Ｂでは、三個のメッセージＢ１、Ｂ２およびＢ３が受信される。この例では、メッセージＢ１がメッセージＡ１と衝突することに注目いただきたい。また、会話Ａは会話Ｂよりも高い優先順位が持っている。
【０２３８】
図に縦の破線で示すように、二つの会話の連続的なレンダリングを行う間に、高い優先順位を持つメッセージＡ１およびＡ２が先にほぼリアルタイムでレンダリングされる。メッセージＡ２とＡ３の間には、比較的大きなタイムギャップがあるので、このスペースは、タイムシフトおよびレンダリングメッセージＢ１とＢ２で埋められる。Ａ３が到着すると、それはリアルタイムでレンダリングされ、一方メッセージＢ３は、高い優先順位のメッセージＡ３がレンダリングされた後にのみレンダリングされる。高い優先順位のメッセージの間に低い優先順位メッセージをタイムシフトでレンダリングすることによって、連続的なマルチ会話を管理することができる。この単純な例では、優先順位が、レンダリングするための連続的な順序を決めるために使われる唯一のパラメータであることに注意されたい。上記のように、その他の多くのパラメータを使うこともできる。
【０２３９】
図１３Ｄは、ＭＣＭＳ−Ｓを示す図である。この例では、ユーザは、Ａ、ＢおよびＣに関わっている。図は、会話Ａ、ＢおよびＣ毎に、メッセージＡ１、Ａ２およびＡ３、Ｂ１、Ｂ２及びＢ３、及びＣ１及びＣ２がそれぞれ受信される様子を示す。ＭＣＭＳ−Ｓでは、入ってくるメッセージは、それが受信されるのと平行して受信側デバイス１３でレンダリングされる。したがって、下の図に示すように、三つの会話Ａ、Ｂ及びＣのメッセージのレンダリングシーケンスは、メッセージが受信されたときと同じである。この方法においては、マルチ会話は、同時にレンダリングすることができる。
【０２４０】
上記の例では、ＭＳＭＳ−ＣおよびＭＣＭＳ−Ｓを含むＭＣＭＳアプリケーションのいくつかの変形例について説明した。使われるＭＣＭＳアプリケーションの特定のタイプにかかわらず、それらは全ていくつかの共通の特徴を共有している。何れのケースにおいても、会話は、スレッドされたメッセージのシーケンスすなわち組織によって定義される。メッセージは、メディアの一個のストリームからセグメント化され、各メッセージは所定のシーケンス識別子をもち、メディアが作成された時間でインデックスされている。ＭＣＭＳアプリケーションのバリエーションによって、メッセージは、一またはそれ以上のレンダリングオプションに従ってレンダリングされる。レンダリングオプションには、いずれもゼロから複数の異なる属性を使い、フォーム毎に、メッセージのフィルターリング、グルーピングオーバラップおよび／またはシリーズ化がある。この方法では、それぞれメッセージのストリングを含むマルチ会話を、デバイス１３を動かす一個のクライアント１２上で、行うことができる。最後に、ＭＣＭＳのそれぞれのバリエーションは、同じ方法で割り込みメッセージの受信に対応することができる。割り込みメッセージを受信すると、通常、別の会話所属する他のメッセージがレンダリングされる前に先行する。
【０２４１】
［Ｍ． クライアントおよびサーバハードウェア］
図１４Ａは、クライアントアプリケーション１２を記憶し実行するために使われるデバイス１３のハードウェアを示すブロック図１４０である。ハードウェアは、ＣＰＵ１４２、メインメモリ１４４および大容量記憶装置１４６を有する。技術的には周知のことだが、クライアントアプリケーション１２はメインメモリ１４４と大容量記憶装置１４６に搭載され記憶されて、ＣＰＵ１４２によって実行される。
【０２４２】
図１４Ｂは、サーバアプリケーション７８を記憶し実行するために使われるサーバ１６のハードウェアを示すブロック図１５０である。ハードウェアは、ＣＰＵ１５２、メインメモリ１５４、大容量記憶装置１５６、およびアーカイブ部８９を有する。技術的には周知のことだが、サーバアプリケーション７８は、メインメモリ１５４および大容量記憶装置１５６に搭載、保存されＣＰＵ１５２によって実行される。上記のように、一またはそれ以上のユーザのインデックスされたメディアペイロードは、アーカイブ部８９に保存される。
【０２４３】
便宜上、多くのコンポーネントと処理について一個の事例で記述したが、当業者には正しく理解されるように、多くのコンポーネントと繰り返しの処理をここに説明したシステムおよび方法の技術は実施する上で使用できる。さらに、本発明は、特定の実施例を参照して特別に示し記述したが、当業者には正しく理解されるように、本発明の精神と範囲を超えずに、開示した実施例のフォームおよび細部の変更が可能である。例えば、本発明の実施例は、様々なコンポーネントとともに採用でき、かつ上記のものに限定されない。したがって、本発明は、全ての変形例及び同等物は本発明の精神と範囲に入ると理解されるべきものである。
【技術分野】
【０００１】
本発明は通信に関し、特に、ユーザにライブモードまたはタイムシフトモードのいずれかのモードで会話のメッセージをレビューしたり、会話を二つのモード間で遷移したり、複数の会話に参加したり、後でレビュー、加工するために会話のメッセージをアーカイブすることを可能にする、通信およびマルチメディアの管理方法および装置に関する。
【背景技術】
【０００２】
音声通信は、慣性の影響を受けるのが現状である。自動切換え、高帯域幅ネットワーク、さらに衛星通信、光ファイバー通信、ＩＰネットワーク通信（ＶｏＩＰ）、無線通信および携帯電話ネットワーク等の技術にもかかわらず、人々の電話の使い方にほとんど変化が見られない。いまだに、電話機を持ち上げ、相手にダイアルし、繋がるまで待ち、挙句にダイアルした相手と同期二重会話を強いられている。もし受信側が応答しなければ、接続はできず、会話も始まらない。
【０００３】
受信側がボイスメールを持っていれば、せいぜい一方通行の非同期の音声メッセージを残せるぐらいである。しかし、ボイスメールをレンダリングする手順は煩わしく時間もかかる。呼出し側は、相手方の電話の呼び出しリンが鳴り止み、ボイスメールシステムに遷移するのを待ち、音声メッセージの挨拶を聞き、それからメッセージを残さなければならない。現在のボイスメールシステムは、受信側にとっても不便である。受信側は、コードにダイアルして音声メールにアクセスし、一連のプロンプトをナビゲートし、待ち行列の中に先着の音声メッセージあればそれを聞き、それからやっと当の送信側のメッセージを聞かなければならない。
【０００４】
典型的なボイスメールシステムの他の短所は、音声メッセージを組織化すなわち永久にアーカイブすることができないことである。ボイスメールシステムの中には、ユーザがメッセージを記憶できるものもあるが、予め決められた時間が経過すると、自動的に削除され永久に失われてしまう。
【０００５】
さらに、現在のボイスメールシステムの別の問題は、メッセージを残す前に呼出し側とボイスメールシステムで接続をしなければならないということである。もし接続ができなければ、呼出し側にとってはメッセージを残す手立てはない。
【０００６】
現在の電話システムは、リアルタイムの通話、バラバラの音声メッセージといった比較的単純な利用パターンに基づいており、それらは、たいていは聞き終われば削除される。これらの音声通信形式は、音声通信で可能な真価を発揮していない、または現在可能なネットワークの速度および回線容量の進歩を活用できていない。また、もし電話回線がダウンしてしまった場合、すなわち利用不能な場合（例えば、携帯電話のユーザがサービス圏外にいる、または悪天候のために電話回線がダウンした）、通信は起こりえない。
【０００７】
一般に、電話ベースの通信はテキストベースの通信の進歩に追いついていない。インスタントメッセージ、Ｅメール、ファックス、グループチャット、テキストメッセージをアーカイブすることなどは、テキストベースの通信ではすべて当前のことである。音声メールのほかには、音声メッセージを管理および／またはアーカイブできる現在利用可能なツールはほとんどない。テキスト通信と比較すると、現在利用できる電話通信を管理するツールはまだ初歩的な段階にある。
【０００８】
企業環境は、現在の音声通信ツールにおける弱点の良い例を示している。今のところ、音声通信を法人資産として管理する統一された方法はない。従業員は普通、自分たちの電話での会話を録音したり永久保存したりすることはない。ビジネス関連の音声通信資産は、ほとんど言葉が話されると同時に即座に消えてしまい、これらの会話の内容を何らかの管理可能な形式で管理または保存する方法はない。
【０００９】
実例として、ある会社の営業幹部の例を考えてみよう。多忙な一日の流れの中で、この幹部はたくさんの電話をかけ、顧客から電話で幾つかの販売契約をとる場合がある。これらの会話を編集、保存、後に検索する手立てがないので、この幹部にとっては、ある取引と他の取引との条件についてのリコール、あるいは先に結んだ販売合意の条件に異議を唱える顧客に対しその根拠の説明を求める、といった後に発生することが予想される問題を解決する方法はない。もしこの幹部が会話を簡単に取出し、レビューすることが可能であれば、このような問題は簡単にかつ良好に解決することができるであろうと思われる。
【００１０】
現在、軍隊、消防、警察、救急医療隊、レスキュー隊、および第一応答者等に使用されている戦術的無線システムも、多くの不便をこうむっている。戦術的無線通信は、ほとんどの場合、メッセージの送信側と受信側の間で「ライブ」の無線接続で行われるに違いない。両者間に無線接続なければ、通信は成り立たつはずがない。もし、送信側または受信側が自分の無線にアクセスできない、あるいは無線回路の接続ができなければ、緊急メッセージを送ることは不可能だ。したがって、戦術的通信は、次のような幾つかの基本的な問題に悩まされている。（ｉ）メッセージが送達される保証がない、（ｉｉ）受信側は、リアルタイムで聞きそこねたメッセージに戻ったり聞いたりできない、（ｉｉｉ）会話参加者の情報粒度をコントロールすることができない、（ｉｖ）ライブ会話を行うための信号品位に欠ける場合、システムは対処できない。もしメッセージをライブで聴けなければ、そのメッセージは失われてしまう。送信側または受信側にとって、以前送られた会話のメッセージを管理する、優先順位をつける、アーカイブする、後で検索する（すなわち、タイムシフトする）のいずれかができるツールはない。
【００１１】
さらに、戦術的無線通信システムに関する別の短所は、１チャンネルにつき一時に一個のメッセージしか送信できないということである。大きなビル火災を例にとって見ると、そこでは、消防士、警察および救急救命士等の複数のチームが同時にビルに取り残された被害者を救助したり、消火活動したり、被害者に医療援護を提供したり、野次馬を整理したりしている。もし、各チームが同じチャンネルを使用しているとしたら、通信は混雑し大混乱に陥るかもしれない。一人以上の人が同時に送信していたら、通信は「踏倒し」がおこる。また、高い優先順位のメッセージと低い優先順位のメッセージとを区別する方法もない。燃え盛るビルの中で消火活動または取り残された被害者の救助活動をしているチームが、当然、野次馬の整理にあたっている他のチームより高い優先順位を持つ。もし、高い優先順位のメッセージが低い優先順位のメッセージによって踏倒されたら、重要な通信が妨害されるだけでなく、ビルの中にいる消防士と被害者の命に危険が及ぶことになる。
【００１２】
メッセージに優先順位をつけることができないことに対する、考えられるひとつの解決策としては、複数のチャンネルを使い、それぞれのチームに異なるチャンネルを割り当てることである。しかしながら、この解決策はそれ自体一連の問題を生じる。また、消防隊長は、どのチャンネルをどの時点で聞けば間に合うのかをどうやって判断するのか。複数のチームの全員がそれぞれ異なるチャンネルと接続していたら、どうやってたがいに通信をかわすのか。一つのチームが緊急援助を求めたとき、他のチームが別のチャンネルを聞いていたら、どうやってそれを知るのか。複数のチャンネルが幾つかの問題を軽く扱った場合、それが混乱を引き起こし、チャンネルが一つのとき以上にさらなる問題を生じる可能性がある。
【００１３】
効果的にメッセージに優先順位をつける、マルチ会話が同時に行える、メッセージのタイムシフトを行い、送達を確実にする、あるいは後の検索・レビューのためにマルチ会話をアーカイブすることをサポートする管理ツールがないことが、戦術的無線の問題に結びついている。軍隊、警察、消防のような第一応答者の立場においては、有効な通信ツールの有無が、文字通り生死、任務の成否を分かつ。上記の燃え盛るビルの例が、戦術的無線通信に係わる現在の幾つかの問題をわかりやすく例示している。戦術的通信を使用する軍隊、警察、第一応答者、その他にも同様な問題が存在する。
【００１４】
パケット方式のネットワークでは、共通に使用されるプロトコルとして、通信制御プロトコル（ＴＰＣ）およびユーザ・データグラム・プロトコル（ＵＤＰ）がある。ＵＤＰは、データの高速送達という利点はあるが、完全性を犠牲にする。パケットがデータ送信中に脱落する可能性があり、またデータを即座に宛先に届けようとする場合は使用できない。ＵＤＰは、幾つかの欠陥があるにもかかわらず、その速度属性のゆえにヴォイス・オーバ・インターネット・プロトコル（Ｖｏｉｃｅ Ｏｖｅｒ Ｉｎｔｅｒｎｅｔ プロトコル：ＶｏＩＰ）通信の標準になっている。一方、ＴＰＣは完全なデータ（すなわち、送信データの正確なコピー）の送達を保証するが、待ち時間を代償とする。どれほど時間がかかろうとも、全てのパケットが送達される。この遅延の問題が、ＴＰＣを「ライブ」通話に適さないものとしている。今のところ、ＴＰＣ、ＵＤＰの両者に機能の進化をもたらし、「十分に良い」メディアの完全なコピーを即座に送信できる、究極の送達が可能なプロトコルは知られていない。ネットワーク上の受信側の存在と、ライブまたはタイムシフトモードでデータを届けようとする意図に基づいて、どれだけの量の情報をネットワークを通じて送るべきか、を判断できるプロトコルはない。さらに、どれだけの量のデータを送信すべきか判断する際に共通に考慮されるその他のファクタとしては、例えば、ネットワーク待ち時間、ネットワークの劣化、パケット損失、パケットダメージ、一般的な回線容量の状態等がある。しかしながら、従来技術のシステムは、受信側のプレゼンスと意図を考慮しない。その結果、データが受信側によってリアルタイムで届けられるということが大前提となる。従来技術のシステムでは、受信側が即座にデータをレンダリングするつもりがなければ、不必要に回線容量を使い、ネットワーク全体のパフォーマンスを引き下げてしまう。
【００１５】
上記の理由により、電話、音声メールおよび戦術的音声通信システムは十分とはいい難い。したがって、音声およびメディア通信の管理システムおよび方法の改良、パケット方式のネットワーク上の音声その他のメディアの改良が必要である。
【発明の概要】
【００１６】
本発明は第１の通信デバイス上で通信するための通信方法に関する。本方法は、ネットワークを通じて１又はそれ以上の参加者との会話のメディアを第１の通信デバイスで受信するステップと、メディアがネットワークを通じて受信される場合、受信メディアを第１の通信デバイス上に記憶するステップとを具える。会話の受信メディアは、ほぼリアルタイムモード、又はタイムシフトモードのいずれかでレンダリングされてもよい。メディアのレンダリングは、記憶されたメディアを取り出し、増加したレンダリング速度で記憶部から取り出されたメディアをレンダリングし、増加した速度で取り出されたメディアのレンダリングが、ネットワークを通じて受信されているときに、会話のメディアをキャッチアップし、かつ、ほぼ同時である場合に、キャッチアップ点を確認し、キャッチアップ点の後に前記ネットワークを通じて受信されているときに、ほぼリアルタイムモードで会話のメディアをレンダリングすることによって、タイムシフトモードからほぼリアルタイムモードに、前記第１の通信デバイス上で遷移されてもよい。
【図面の簡単な説明】
【００１７】
本発明の特定の実施例を示す付属の図面とあわせて以下の説明を読めば、本発明は最良の理解が得られるであろう。
【００１８】
【図１】図１は本発明の通信およびメディア管理システムのアーキテクチャを示す図である。
【図２Ａ】図２Ａは本発明の通信および管理システムのデバイス上で実行するクライアントのブロック図である。
【図２Ｂ】図２Ｂは本発明の通信および管理システムのデバイス上で実行するクライアントのブロック図である。
【図３】図３は本発明の通信および管理システムで使われるサーバのブロック図である。
【図４】図４Ａないし４Ｄは本発明の通信および管理システムで使われるデータペイロードの種々の実施例を示す。
【図５】図５は本発明に係わる共用ＩＰネットワーク上を送信されるデータを示す図である。
【図６】図６は本発明に係わる回路ベースのネットワーク上を送信されるデータを示す図である。
【図７】図７は本発明に係わる、セルラーネットワークおよびインターネットの両者上を送信されるデータを示す図である。
【図８Ａ】図８Ａは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。
【図８Ｂ】図８Ｂは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。
【図８Ｃ】図８Ｃは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。
【図８Ｄ】図８Ｄは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。
【図８Ｅ】図８Ｅは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。
【図８Ｆ】図８Ｆは本発明の通信および管理システムの記憶およびストリーミング機能を示す一連のフロー図である。
【図９Ａ】図９Ａはペイロード品質管理部（ＰＱＭ）の動作を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。
【図９Ｂ】図９Ｂはペイロード品質管理部（ＰＱＭ）の動作を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。
【図９Ｃ】図９Ｃはペイロード品質管理部（ＰＱＭ）の動作を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。
【図９Ｄ】図９Ｄはデータ品質管理部（ＤＱＭ）を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。
【図９Ｅ】図９Ｅはデータ品質管理部（ＤＱＭ）を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。
【図９Ｆ】図９Ｆはデータ品質管理部（ＤＱＭ）を示すフロー図であり、本発明のクライアントおよびサーバに使用されるものである。
【図１０】図１０は本発明のシステムとともに使用されうるグラフィカルユーザインタフェースを有するデバイスの例である。
【図１１Ａ】図１１Ａは本発明の多者間会話管理（ＭＣＭＳ）機能を示す図である。
【図１１Ｂ】図１１Ｂは本発明の多者間会話管理（ＭＣＭＳ）機能を示す図である。
【図１１Ｃ】図１１Ｃは本発明の多者間会話管理（ＭＣＭＳ）機能を示す図である。
【図１１Ｄ】図１１Ｄは本発明の多者間会話管理（ＭＣＭＳ）機能を示す図である。
【図１１Ｅ】図１１Ｅは本発明の多者間会話管理（ＭＣＭＳ）機能を示す図である。
【図１１Ｆ】図１１Ｆは本発明の多者間会話管理（ＭＣＭＳ）機能を示す図である。
【図１２Ａ】図１２Ａは本発明の継続的多者間会話管理システム（ＭＣＭＳ−Ｃ）の機能を示す図である。
【図１２Ｂ】図１２Ｂは本発明の継続的多者間会話管理システム（ＭＣＭＳ−Ｃ）の機能を示す図である。
【図１２Ｃ】図１２Ｃは本発明の継続的多者間会話管理システム（ＭＣＭＳ−Ｃ）の機能を示す図である。
【図１３Ａ】図１３Ａは本発明の動作を詳しく示す一連の図である。
【図１３Ｂ】図１３Ｂは本発明の動作を詳しく示す一連の図である。
【図１３Ｃ】図１３Ｃは本発明の動作を詳しく示す一連の図である。
【図１３Ｄ】図１３Ｄは本発明の動作を詳しく示す一連の図である。
【図１４】図１４Ａ、１４Ｂは本発明のクライアントおよびサーバのアプリケーションを実行させるために使われるハードウェアを示すブロック図である。
【００１９】
図において同じ付番は同じ要素を示すものとする。
【発明を実施するための形態】
【００２０】
付属の図面に示す種々の実施例を参照して本発明を詳細に説明する。以下の説明では、本発明の完全な理解に資するために、特定の実施例について詳細に記載する。しかしながら、当業者にとっては、ここに記載する実施例の幾つかの細部を使用することなく本発明が実施可能であることは明らかである。不要な混乱を避けるために、周知の動作等については詳しい説明を控えたことは、理解できよう。
【００２１】
［Ａ．機能の概要］
本通信メディアの管理方法およびシステムは、音声、ビデオ、テキスト、ロケーション、センサ情報、その他のデータ等の様々なタイプのメディアを使って、音声会話に参加するためのモードをサポートする、および／または多人数による同時会話を管理する新しいモードをサポートする。ユーザは、指定する受信者に音声メッセージを送ることによって会話に加わることができる。受信者は、好みや優先度によってリアルタイムで会話に参加したり、メッセージが検索できることを単に通知だけを受けたりすることもできる。後者の場合は、受信者は都合のよいときに記録されたメッセージを見なおしたり返信したりすることによって、タイムシフトモードで会話に参加する。
【００２２】
ユーザは、次の通信を行う権利を与えられる。すなわち、（ｉ）ほぼ同期性の「ライブ」会話：これは、ユーザに標準的全二重通話と同じ体験をレンダリングする、または（ｉｉ）タイムシフトモード：すなわち、一連の時間差通信。さらに、会話に参加したユーザは、ライブモードからタイムシフトモードに切目なく遷移し、再度ライブモードに戻ることもできる。また、この属性により、ユーザは、会話ごとに優先順位をつけたり二つのモード間を移動したりして、マルチ会話に参加することを可能にする。したがって、このシステム使用する二人の個人は、互いに記録した音声メッセージをやり取りしたり、都合のよいときにそのメッセージをレビューしたりすることができる。また、メッセージをある速度で送り基本的にライブに合流させ、音声同時通話を実現する。この新しい通信の形式は、本発明の目的から、「ヴォクシング：Ｖｏｘｉｎｇ」と呼ばれる。
【００２３】
誰かと「ヴォクス：Ｖｏｘ」すると、その会話は一連の不連続な記録されたメッセージで構成され、沢山のロケーションに記録される。また、「ヴォクス」には、送信側のエンコードデバイス（例えば、電話またはコンピュータ）を含み、ネットワーク上の複数の送信ホップ上のサーバ、さらに受信側のレンダリングデバイスが含まれる。標準的な通話または音声メールとは異なり、このシステムは次のような機能と利点を提供する。（ｉ）会話がライブとタイムシフトまたはその逆を遷移できる。（ｉｉ）会話の不連続なメッセージは、意味論的に束ねられアーカイブされる。（ｉｉｉ）メッセージは記録され後で検索できるから、注意を一時的に会話からそらしても、後で都合のよいときに会話をレビューすることができる。（ｉｖ）会話は数秒、数分、数時間または数日間中座し、そこから再開することができる。（ｖ）進行中の会話に再度加わることができる、見損ねたメッセージを即座にレビューすることができる、または現在のメッセージにキャッチアップすることができる（すなわち、ライブメッセージ）。（ｖｉ）従来の通話のように、会話をするのに特別の回路を必要としない。（ｖｉｉ）個人またはグループに送信するだけで会話が始められる。メッセージを受信していることに気がついたら、相手方の人は、リアルタイムでレビューし会話を行うか、後にレビューか自由に選択することができる。
【００２４】
また、通信メディア管理システムは、ネットワークを通じてのデータ送信を最適化する新しいモードをサポートする。ネットワークの状態が理想より悪い場合は、システムはペイロードを会話に参加している受信側に送達するのをアクティブにリアルタイムで管理する。例えば、ネットワークの状態が悪いときは、システムは送信用のデータの質を、受信側が受け取ったときにレンダリングするのに「十分に良い」レベルまで意図的に引き下げ、リアルタイムの会話に参加できるようにする。また、システムは、メッセージの「正確な」コピーを長い時間をかけて最終的に送達することを保証する。したがって、本システムおよび方法は速度と精度の両方の利点を提供する。受信側の存在および受信側がリアルタイムで即座にメッセージを見る意思があるかどうか、ネットワーク待ち時間、ネットワークの劣化、パケットの損失またはダメージおよび／または現在の回線容量の状態の測定に基づいて適時性とメディアの質との間でトレードオフを行うことによって、ネットワーク回線容量が最適に利用できるようにする。
【００２５】
ここで、会話のメッセージが含むことができるのは、音声のみ、または音声、ビデオおよびセンサ情報、その他のデータである。メッセージがレビューされるとき、メッセージに含まれるメディアのタイプによって、耳で聞かれる、視覚的にレビューされる、または、その組み合わせである。本発明の申請段階では、ほとんどの会話は音声のみであるが、ここに記載する通信システムおよび方法は、例えば、音声およびビデオ等の複数のメディアタイプを含む会話を広く含むことを意図している。
【００２６】
次の特徴や機能のうちの一またはそれ以上を提供する、改良型音声その他のメディア通信、管理システムおよび方法を開示する。
ｉ．ユーザが、ライブ通話、会議通話、音声メッセージ、継続的または同時通信等を含む多くのタイプの会話に参加可能にする。
ｉｉ．ユーザが、会話のメッセージをライブモードまたはタイムシフトモードのどちらかのモードでレビュー可能にする（音声メッセージ）。
ｉｉｉ．ユーザが、同時「ライブ」モードとタイムシフトモードの間で会話を切目なく遷移することを可能にする。
ｉｖ．他の参加者またはネットワークとの接続が確立されるのを待たずにユーザが会話に参加することを可能にする。この属性は、利用できるネットワークがない、ネットワークの質が悪い、他の参加者が参加できない場合でも、ユーザに会話を始める、会話に参加する、以前に受信しタイムシフトされた会話のメッセージをレビューすることを可能にする。
ｖ．システムに、送信側のメディアのペイロードデータの記憶を可能とし、ネットワーク送信後、全ての受信側にメディアのペイロードデータの記憶を可能とする。
ｖｉ．システムに、所定の会話において、各メッセージが識別でき、かつ所定の参加者に結びつけることができる、意味論的に有意味の会話にスレッディングすることによって、メッセージを組織化できるようにする。
ｖｉｉ．ユーザに、一組のユーザコントロール機能を使って、「ライブ」をレビュー、レビューするのに都合がいい時まで会話を休止またはタイムシフトする、様々なモードで再生する（例えば、早送り、ライブにキャッチアップする、会話の頭にジャンプする）、会話を管理する方法（アーカイブする、タグ付けする、検索する、アーカイブから取り出す）等、各会話を管理可能にする。
ｖｉｉｉ．システムに、オンラインの状態、所定のメッセージをライブかタイムシフトモードのどちらかでレビューする意図、メッセージに対する現在の注意、レンダリングの方法、および送信側と受信側の間のネットワークの状態を含む、参加データの管理を可能にし、全ての会話参加者と共有化可能とする。
ｉｘ．下記の場合は、ユーザが、マルチ会話を同時に管理することが可能にする。（ａ）１つの会話を進行、その他の全てを休止とする、（ｂ）戦術的通信のような（これに限らず）マルチ会話を継続してレンダリングする、（ｃ）株取引すなわち取引フロア環境などのマルチ会話は、アクティブかつ同時にレンダリングする。
ｘ．ユーザに、全ての会話を記憶可能にし、望むなら、有形の表現媒体に持続的にアーカイブし、必要に応じ組織化、インデックス付け、検索、転記、翻訳および／またはレビューできる資産をレンダリングする。
ｘｉ．システムが、即座にレンダリングする上で「十分に良い」速度でメッセージを送達するうえで最善のモードを使って、リアルタイム通話機能をレンダリング可能にする（ＵＤＰと同様）。また、もともと記憶された完全なコピーから、紛失あるいは欠陥のあるデータの再送を要求し、最終的にメッセージの完全なコピーの送達を保証する（ＴＰＣと同様）。
ｘｉｉ．受信側のプレセンスおよび意図（すなわち、リアルタイムまたはタイムシフトモードでのメディアのレビュー）を使うと同時にネットワーク待ち時間、ネットワークの劣化、パケットの損失あるいはダメージおよび／または現在の回線容量の状態を測定し、システムに、適時性とメディアの質の間でトレードオフを行いネットワーク回線容量の利用を最適化することを可能とする。
【００２７】
種々の実施例において、上に挙げた様々な特徴や機能の一部又は全部が実施可能である。しかしながら、本発明の別の実施例においては、上に列挙した特徴や機能の全てを組み込む必要がないことは理解できよう。
【００２８】
［Ｂ．用語の解説］
本発明の詳細を説明するに先立ち、本明細書全体を通じて使用される幾つかの用語と略語を定義する。この用語解説は、システム構成、メディア、メディア管理、人と会話管理のグループに分類できる。
【００２９】
［Ｂ．１．システム構成］
クライアント：クライアントは、通信システムの中のユーザアプリケーションを意味し、ユーザインタフェース、持続的データ記憶装置、および「ヴォクシング（Ｖｏｘｉｎｇ）」機能を含む。ユーザは、クライアントアプリケーションと情報のやりとりをし、クライアントアプリケーションは、ネットワークを通じて送受信される全ての通信（メッセージおよび信号）およびペイロード（メディア）転送を管理する。クライアントは、メディアのエンコード（例えば、音声、ビデオまたは他のデータのコンテンツの取得）、メディアのレンダリングをサポートし、セキュリティ、暗号化、認証およびネットワーク上のデータ送信の最適化をサポートする。クライアントは１個ないし複数のユーザ（すなわち、マルチテナント）によって使用することもできる。
【００３０】
デバイス：クライアントアプリケーションを実行する物理的デバイス。ユーザは、一個のデバイスまたは複数のデバイスによって、所定のいずれの時点でもアクティブにログインすることができる。種々の実施例において、デバイスは、汎用コンピュータ、携帯計算機、プログラマブル電話機、プログラマブルラジオまたはその他のどんなプログラマブル通信装置であってもよい。
【００３１】
サーバ：通信ネットワーク上のコンピュータノード。サーバは、ネットワーク上のユーザ間でやり取りされる送信メッセージのルーティングおよびメディアペイロードの持続的記憶とアーカイブの役割を持つ。サーバは、ルーティング、トランスコーディング、セキュリティ、暗号化と認証およびネットワーク上のデータ送信の最適化を提供する。
【００３２】
［Ｂ．２．メディア］
メッセージ：あるユーザから他のユーザへの個々の通信単位。各メッセージは音声またはビデオ等の何らかのメディアからなる。各メッセージは、以下の属性のどれかを割り当てられる。（ｉ）メッセージ送信側のユーザ、（ｉｉ）所属している会話（ｉｉｉ）、オプション、またはユーザ作成の重要タグ、（ｉｖ）タイムスタンプ、（ｖ）メディアペイロード
【００３３】
メディア：音声、ビデオ、テキスト、位置、温度等のセンサの読取り値、その他のデータ。
【００３４】
会話：デバイス上で２人以上のユーザ間の一連の（識別され、持続的に記憶されグループ化され優先順位をつけられた）メッセージ。ユーザは、一般にデバイスを用いてリアルタイムまたはタイムシフトモードでメッセージをレビューするか、望みに応じて会話のメッセージを作成、送信することによって会話に参加する。新しいメッセージを作成すると、新しい会話を定義するか、既存の会話に加えられる。
【００３５】
会話のヘッド：直近の話者によってエンコードされた会話の直近のメッセージ。「ライブ」をレビューするとき、会話においてユーザが存在しているところ、すなわち「ライブへジャンプ」機能を使用する場合、ジャンプするところ。
【００３６】
多者間会話管理システム（ＭＣＭＳ）：クライアントアプリケーションの一部として実行するアプリケーションで、ユーザが様々なタイプのメディアを用いてマルチ会話に参加することを可能にする。現在の会話のメッセージのみがレンダリングされている場合、ユーザはＭＣＭＳアプリケーションを用いて、現時点として、マルチ会話の中から１つの会話を選択することができる。選択された現在の会話については、ユーザはタイムシフトモードでのメッセージの一連のやり取りから、標準的な電話会話と同様のほぼ同期性の「ライブ」モードに遷移でき、またタイムシフトモードに戻ることができる。選択されなかった会話のメッセージは休止状態に置かれる。他の人がまだこれらの会話参加している場合は、選択されなかった会話に関するメッセージは、蓄積されていく。ユーザは、マルチ会話の中から現在の会話に選択的に遷移し、選択された現在の会話の蓄積されたメッセージをレビューすることができる。
【００３７】
継続的多者間会話管理システム（ＭＣＭＳ−Ｃ）：付加されたレンダリング機能によって、システムによって自動的に管理される優先順位とタイムシフトの階層的なシステムを通じて、ＭＣＭＳと同様にユーザにマルチ会話を管理し継続して参加することを可能にする機能。現在選択されている会話メッセージのみをレンダリングできるＭＣＭＳとは異なり、ＭＣＭＳ−Ｃアプリケーションは、継続する会話のメッセージを、優先順位をつけた順序でレンダリングすることができる。ＭＣＭＳ−Ｃは特に次のような状況で利用できる。すなわち、継続する会話のメッセージを、優先順位をつけた順序でレンダリングすることが重要な場合、および／または低い優先順位の会話に属していても、全てのメッセージを受信することがリアルタイムでメッセージを受信するよりも重要な場合。ＭＣＭＳ−Ｃが適する状況の例としては、病院、タクシー全車両管理、戦術的通信などがあるが、これに限定されるものではない。
【００３８】
同時多者間会話管理システム（ＭＣＭＳ−Ｓ）：ＭＣＭＳと同様、選択された現在の会話だけのメッセージがレンダリングされるＭＣＭＳとは対照的に、追加機能によってＭＣＭＳ−Ｓを使って同時レンダリングするマルチ会話を選択可能にする。ＭＣＭＳ−Ｓアプリケーションは、一人のトレーダーが異なる為替について複数のブローカーに聞いており、一人ないし複数のブローカーに取引要請を時折送信しているような、１個のユーザがマルチ会話を同時に聞いている状況に、特に適用できる。また、ＭＣＭＳ−Ｓは戦術的通信にも適している。
【００３９】
優先順位：ユーザがＭＣＭＳ−Ｃに参加しているときに、つぎにどのメッセージをレンダリングするかシステムが決める機構。優先順位はシステムによって自動的に管理される。ユーザは、デフォルトで優先順位を設定できる、または予め決められた一組のシステム優先順位を使うこともできる。衝突が生じた場合、すなわち、１個以上のメッセージが同時にレンダリングされようとしているときは、システムは、少なくとも部分的に優先順位に基づいて衝突を解決し、どのメッセージを即座にレンダリングし、どのメッセージをタイムシフトするか決める。
【００４０】
タグ：ユーザまたはシステムが、会話またはメッセージに割り当てることができる一組の属性で、それによってデータを検索したり組織化したりできる、トピック（会社名）、命令（「動作項目」）、標識（「会話のサマリー」）、その他ラベル等。
【００４１】
重要タグ：他の優先順位の設定にかかわりなく、あるメッセージがレンダリングされるべきときに、送信側に指定可能とする特別のメッセージ属性。例えば、「緊急」の重要タグは、他の優先順位を無効にする。この機能は、戦術的なシステムにとっては重要な意味を持つが、どんなシステムでも、この機能を使えるようにしたり、無効にしたり設定することができる。
【００４２】
パケット：コンピュータネットワークを通じてルートを決めることができるバイナリデータの単位。各パケットは、ヘッダ（メタデータ）およびペイロード（メディアデータ）からなる。インターネットプロトコル（ＩＰ）、ＥｖＤＯ、ＵＭＴＳその他のパケットベースのネットワーク、無線、光ファイバー、有線のいずれかの標準的なパケットプロトコルが含まれるが、これに限定されものではない。
【００４３】
ヘッダまたはパケットヘッダ：パケットを記述するパケットの部分、ペイロードに関するメタデータ、エンコードのタイプおよび宛先。
【００４４】
Ｖｏｘパケット：システムと方法をさらに精緻化し、メッセージメディア、その他の信号情報の送達を最適化することを可能にする専用パケット。
【００４５】
メディアペイロード（またはペイロード）：パケットの実のメディア部分。
【００４６】
［Ｂ．３．メディアの管理］
タイムシフト遅延（ＴＳＤ）：Ｖｏｘパケットの着信とパケットのデバイス上でのレンダリングとの間の時間の量。ＴＳＤは最小タイムシフト遅延を上回らなければならない。ＴＳＤは、主として、受信後のユーザが会話のメッセージをレビュー選択しようとする動作によって決められる。
【００４７】
最小タイムシフト遅延（ＭＴＳＤ）：クライアントによって強制されるタイムシフト遅延で、ジッタバッファ技術を用いてジッタ加工することができるようにする。これは、使用可能なメディアストリーム作るのに適当な数のパケットが到着するまで、システムにレンダリングの遅延を行わせる。システムは、時間の経過に応じてＭＴＳＤを順応的に調節し、主としてネットワークにおける変動条件を補正する。
【００４８】
レンダリング：ユーザの消費に適した形式でユーザにメディアストリームを送達すること（例えば、音声、テキスト、グラフィック表示、ビデオ、またはそれらの組み合わせ）。
【００４９】
ミキシング：一またはそれ以上のメディアストリームをレンダリングすること。例えば、レンダリングするとき、会話の二人の参加者からのメディアストリームをミックスし、複数の人が同時に話しているのと同じ会話感覚をユーザに作ること。
【００５０】
エンコード：ユーザ作成の（音声またはビデオ）メディアか、デバイス上で別途生成される（ＧＰＳまたはその他のセンサデータ）メディアを翻訳し、クライアントによって処理されるようにメディアをデジタルデータに変換するプロセス。
【００５１】
適応ジッタバッファ：ジッタバッファまたはデジッタバッファを使い、ネットワークを切り換えたパケットによって導入されたジッタ（すなわち、シーケンスから外れたパケットの着信またはパケットの遅延着信）に対抗し、ネットワーク上を送信される音声（またはビデオ）信号の連続レンダリングが途切れずに行われるようにする。レンダリングする前に、データはバッファに記憶され、適当なサイズにされたメディアのバッファが着信できるようにする。質と流れのトレードオフを行うことによって、全てのパケットが受信される前にメディアをレンダリングすることができる。適応ジッタバッファは、サイズをダイナミックに変え、遅延−質トレードオフを最適化することができる。
【００５２】
無限連続メッセージバッファ（ＰＩＭＢ）：ＰＩＭＢは、タイムベースのメディアを記憶する記憶部の管理システムであり、「ライブ」データのジッタの削除とアーカイブされたデータの保存と取出しの両方を行う。さらに、ＰＩＭＢは付加的属性として、潜在的に無限にメディアの継続保存をおこなう。ＰＩＭＢは、一部又は全ての参加者のデバイスおよび／またはサーバにて、メッセージと会話のＶｏｘパケットを、「完全な」すなわちフルコピーで維持する。
【００５３】
パケット損失補償または隠蔽（ＰＬＣ）：メディアストリームをレンダリングする間に、ＰＬＣコンポーネントは、紛失パケットの補償を行い、結果を補間し、閲覧者にストリームを提供する。紛失パケットは無音としてレンダリングするか、近接するパケットからの情報を使い、補間した音またはイメージ提供することもできる。使用される個々の方法は、メディア、使用コードおよびその他一般に既知のパラメータによる。
【００５４】
［Ｂ．４．人］
ユーザ：システムを使う権限を与えられた人。
【００５５】
コンタクト：システムのユーザまたは非ユーザの記録。ユーザは、主としてコンタクトのリスト上のメンバーとともに会話に参加する。従来の電話、ラジオ又はその他の非クライアント１２が使用可能なデバイスを使ってシステムにアクセスまたはシステムを使うユーザは、非ユーザである。
【００５６】
グループ：多数のコンタクトの集まり。コンタクトは、グループに選択的に加えられたり、グループから削除したりできる。グループの中で会話が始まれば、グループの全てのメンバーは参加することもしないこともできる。
【００５７】
チャンネル：主として戦術的通信システムに使われる。チャンネルはグループと同様、チャンネルで多数のコンタクトを結び付ける。
【００５８】
参加者：会話のメンバーとして識別される人。ユーザまたは非ユーザが参加者になりうる。
【００５９】
［Ｂ．５．会話の管理］
タイムシフト：タイムシフトは、メッセージを受信した後、ユーザ受信者の判断によって、随時実行できる。タイムシフトによって、ユーザは、メッセージを下記の方法でレビューするこができる。（ｉ）ＭＴＳＤ後、オンデマンドで、即座にレンダリングする、（ｉｉ）ユーザの裁量により、タイムシフトモードでメッセージをレビューする、（ｉｉｉ）古い会話を検索、再構成のためにアーカイブから、（ｉｖ）別の優先順位の高いメッセージ（会話）のレビューに便宜を図るために一定の遅延時間の後、および／または、（ｖ）メッセージを再度聞いたり理解したりすることが必要な場合は繰り返して。言い換えれば、タイムシフトは、システムによってＭＴＳＤが強制された後、ユーザがメッセージを随時レンダリングできることである。
【００６０】
レビュー：メッセージの中のメディアのコンテンツを聞く、見る、読む、または閲覧すること。レビューは、ほぼ同期性のリアルタイム「ライブモード」かタイムシフトモードのいずれかで行うことができる。
【００６１】
意図：以下を把握するユーザ定義の属性；（ｉ）ユーザが会話のメッセージを即座にレビューしたいと望んでいるか、タイムシフトモードでメッセージをレビューしたいと望んでいるか、（ｉｉ）ユーザの動作に含まれている意思、または（ｉ）と（ｉｉ）の組み合わせ。
【００６２】
注意：現瞬間にユーザが所与の会話のメッセージをレビューしているか否かを把握するためのユーザの属性。
【００６３】
ライブにキャッチアップ（ＣＴＬ）：「ライブにキャッチアップ」ために、会話の頭にないユーザが、先行するメッセージをより早くレビューすることができる（すなわち、会話の頭に）、レンダリングモード。ＣＴＬ機能は、メッセージの早送り、メッセージのメディアの中にあるギャップの除去、躊躇粒子の除去等数多くあるキャッチアップ技術のうちどれを使っても良い。ユーザがライブに追いついたらシステムは途切れずにライブ会話に遷移する。これは、会議通話、例えばユーザが出席者の注意を一時的に会話から引き離し、再び戻ったときに全体の会話を聞きたい、といった状況のときに非常に役立つ機能である。
【００６４】
キャッチアップモード：ユーザ設定あるいは予め設定されたモードで、どのようにしてＣＴＬプロセスがキャッチアップするか決める（すなわち、もっと早く実行する、無音、躊躇粒子の除去またはそれらの組み合わせ）。
【００６５】
ライブへジャンプ（ＪＴＬ）：この機能により、ユーザは現在の位置から会話の頭へジャンプすることができる。ユーザが、会話における現在の位置と頭の間にある全てのメッセージをレビューすることを望まないとき主としてこのＪＴＬ機能を使う。ＪＴＬ機能を実行すると、ユーザは途中にある全てのメッセージをスキップし、会話の頭にある「ライブ」メッセージのレンダリングを開始する。
【００６６】
ＭＣＭＳ参加者の属性：所定の会話を行うためにユーザが定義し、ユーザの動作からシステムが解釈する、管理者が割り当てる一組の属性か、または、その組み合わせで受信側の意図、注意、優先順位、レンダリングの好みを定義する。属性には以下のものが含まれるが、これに限定されない。（ｉ）受信側が会話のメッセージに対してレンダリングしたいときの意図。可能性のある意図値には以下のものが含まれる：「今」、「タイムシフト」、「ライブにキャッチアップ」（ＣＴＬ）、「休止」、「決してない」など。（ｉｉ）キャッチアップモード。ＣＴＬプロセスがどのようにして受信側をライブにキャッチアップさせるかを決める設定（すなわち、早く実行する、無音ギャップ又は躊躇をスキップするまたは常用速度で実行する）。（ｉｉｉ）タイムシフト遅延（ＴＳＤ）、会話における受信側の現在位置が会話の頭からどれだけ離れているかを定義する。（ｉｖ）受信側における他の会話に関するメッセージの優先順位。
【００６７】
［Ｃ．システムアーキテクチャ］
図１は、本発明の一実施例に係わる通信とメディアの管理システムのブロック図を示す。システム１０は、デバイス１３１ないし１３ｎ上でそれぞれ動作する複数のクライアント１２１ないし１２ｎを含む。デバイス１３は、一またはそれ以上のサーバ１６を含む通信サービスネットワーク１４上で互いに通信を行う。一またはそれ以上のネットワーク１８１〜１８ｎがレンダリングされて、複数のデバイス１３１ないし１３ｎを通信サービスネットワーク１４に連結する。様々な実施例において、ネットワーク１８は、公衆交換電話網ネットワーク（ＰＳＴＮ）、セルラーネットワークに基づくＣＤＭＡ又はＧＳＭ、例えば、インターネット、戦術的な無線ネットワーク、その他の通信ネットワーク、またはその組み合わせであっても良い。通信サービスネットワーク１４は、いろいろなネットワーク１８１〜１８ｎとの通信のトップあるいはその中のネットワーク層である。様々な実施例においては、ネットワーク層１４は、異機種環境か同機種環境である。クライアント１２１〜１２ｎは、「Ｖｏｘパケット」と呼ばれる以下に詳述する個人メッセージ装置を使って、ネットワーク１８１〜１８ｎ上のサーバ１６、およびネットワーク１４と互いに通信を行う。
【００６８】
［Ｄ．クライアントアーキテクチャ］
図２Ａおよび２Ｂは、デバイス１３上で動作するクライアント１２のブロック図を示す。図２Ａに示すように、クライアント１２は、多者間会話管理システム（ＭＣＭＳ）アプリケーション２０、レンダリング−エンコードモジュール２１およびＭＣＭＳアプリケーションデータベース２２を含む。図２Ｂに示すように、クライアント１２は、永続的無限メッセージバッファ（ＰＩＭＢ）リーダ２６が付いた記憶・ストリーム（ＳＡＳ）モジュール２４、ＰＩＭＢ書込み部２８、ＰＩＭＢデータベース３０、データ・ネットワーク品質（ＤＮＱＳ）記憶部３２およびメディアドライバ・エンコダハードウェア３４をさらに含む。ＭＣＭＳアプリケーション２０と記憶・ストリームモジュール２４は、それぞれメッセージハンドリングモジュール２５ａおよび２５ｂを介して互いに通信を行う。クライアント１２は、さらに、認証−暗号化セキュリティモジュール４０および通信プロトコルモジュール４４を含む。
【００６９】
モジュール４０は、クライアント１２との間で「ヴォクス（Ｖｏｘ）」パケットの送受信を行う間、認証、暗号化およびセキュリティのサービスをレンダリングする。通信プロトコルモジュール４４は、Ｖｏｘパケットを、データを送信するときにクライアント１２を作動させ、データを受信するときにネイティブパケットからＶｏｘパケットをカプセルから取り出すデバイス１３に接続された下層のネットワーク１８によって使われるネイティブパケットにカプセル化する。モジュール４０および４４は、クライアント１２間での、マルチ端末同士の認証、暗号化およびセキュリティをレンダリングする。メッセージは、ネットワーク１８１〜１８ｎとネットワーク１４上で、第一の送信デバイス１３から第二の受信デバイス１３まで、認証され、暗号化され、保全される。
【００７０】
［Ｄ．１．１．ＭＣＭＳデータベース］
データベース２２は、コンタクトおよび参加者、会話およびメッセージ（ライブ、保存済み）、初期設定の優先順位、およびサーバ１６に関する情報を含む、システム１０内の多くの要素のための永続性のメタデータを記憶、管理する。さらに、ＭＣＭＳデータベース２２は、ユーザの会話、プレゼンス、およびステータス等の逐次オペレーションデータやユーザと話をしている全ての参加者、およびユーザのコンタクトリスト上のオペレーションデータなどを記憶する。例えば、会話とメッセージに関しては、データベース２２は、会話のどのメッセージをユーザがレビューしたかまたはしなかったか、クライアント１２が参加者であった会話ごとの優先順位、およびライブ−キャッチアップステータスなどのステータス追跡情報を保持する。それには、プレゼンス、全ての参加者のステータス、および他のネットワークおよびシステムの管理データが含まれる。
【００７１】
［Ｄ．１．２．ＭＣＭＳアプリケーション］
ＭＣＭＳアプリケーション２０は、いろいろなメディアおよびデータタイプ（音声、ビデオ、テキスト、ロケーション、データなど）を用いて、参加している会話および／または管理しているマルチ会話のいろいろなヴォクシングモードサポートする。ユーザは、クライアント１２を可能にしたデバイス１３を使って指定された受信側にメッセージを送信することにより、会話に参加する。好み、優先順位よって、受信側は、リアルタイムでメッセージをレビューする、あるいは単にメッセージがレビューできる状態にあることに気がつく。ユーザは、タイムシフト（音声メッセージ）モードまたはほぼ同期性でレビューした一連のメッセージのやり取りから全二重の会話（標準的な「ライブ」通話と同じ）に遷移し、再び音声メッセージに戻ることができる。ＭＣＭＳアプリケーション２０は、別の進行中の会話の中のどのメッセージも失うことなく、ユーザがリアルタイムで最も重要な会話との相互作用をコントロールできるようにする。例えば、ＭＣＭＳアプリケーション２０は、現在レビューしていない会話の中から、緊急の通信すなわち優先順位の高い通信をユーザに通知する。また、ＭＣＭＳアプリケーション２０は、随時レビューができるように、後の検索のために全ての会話の全てのメッセージを記憶することを可能とする。
【００７２】
種々の実施例によれば、ＭＣＭＳアプリケーション２０には、以下のような幾つかの異なった動作モードがある。すなわち、それぞれメッセージの連続的なレンダリングと同時レンダリングをサポートする、ＭＣＭＳ−継続（ＭＣＭＳ−Ｃ）とＭＣＭＳ−同時（ＭＣＭＳ−Ｓ）である。それぞれの実施例について、以下詳細に説明する。特に断らない限り、用語「ＭＣＭＳ」は、一般に前記異なる２つのモードを含むＭＣＭＳアプリケーション２０を意味する。
【００７３】
ＭＣＭＳアプリケーション２０は、多くのモジュールとサービスを含む多層構造のアーキテクチャである。モジュールとサービスには、以下のものが含まれる。すなわち、ＭＣＭＳデータベースモジュール２０ａ、ＳＡＳサービスモジュール２０ｂ、メッセージ／信号サービスモジュール２０ｃ、ユーザインタフェースアプリケーション・プログラミングインタフェース（ＡＰＩ）２０ｄ、ユーザインタフェースモジュール２０ｅ、会話／メッセージ管理サービス部２０ｆ、優先順位サービス部２０ｇ、コンタクトサービス部２０ｈ、プレゼンス／ステータスサービス部２０ｉ、およびメッセージ／信号サービス２０ｊである。
［Ｄ．１．２．１ ＭＣＭＳデータベースモジュール］
【００７４】
ＭＣＭＳデータベースモジュール２０ａは、ＭＣＭＳアプリケーション２０がＭＣＭＳデータベース２２にアクセスするために必要な全ての機能コールを管理するサービスモジュールである。
【００７５】
［Ｄ．１．２．２ ＳＡＳサービスモジュール］
ＳＡＳサービスモジュール２０ｂは、ＭＣＭＳアプリケーション２０と記憶・ストリームモジュール２４との間の通信と調整を可能にする、それぞれメッセージハンドリングモジュール２５ａ、２５ｂを介してやり取りする一組の機能コールを含む。一組の機能コールは、ＭＣＭＳアプリケーション２０と記憶・ストリームモジュール２４の両者に必要に応じてユーザに呼び出されたときにいろいろなヴォクシング機能を動作させ、および／またはネットワークの状態によって指示されたように実行することを可能にする。ＳＡＳサービスモジュール２０ｂによって実行される機能の中にはメッセージ通信およびメッセージ認識のステータス、メッセージをレンダリングするための命令、およびユーザのステータスとプレゼンスの維持と通信が含まれる。
【００７６】
［Ｄ．１．２．３ メッセージ／信号サービスモジュール］
メッセージ／信号サービスモジュール２０ｃは、クライアント１２とサーバ１６の両者の上で動作し、システム１０のクライアント１２とサーバ１６との間で通信を可能とする。この通信は、メッセージ、データおよびその他の信号を含み、クライアント１２とシステム１０が、通信、ネットワークステータス、ユーザ、およびユーザステータスの追跡と管理ができるようにする。サーバ１６上で動作するクライアント１２とメッセージ／信号サービスモジュール２０ｃの間で送られるメッセージと信号のタイプは、例えば、以下を含む。すなわち、ユーザのネットワーク利用可能性、メッセージ全体またはメッセージの一部が失われていないか判断するためにサーバ１６がクライアント１２に送ったメッセージ（恐らく「高水位マーク」を含む）の追跡（例えば、「作成中の」クライアントによって作成された会話につき参加者当りのシーケンス番号）、ユーザが所定の会話のメッセージを話しているかまたはレビューしているかどうか、どこでユーザが会話の頭に関わっているか、いつ参加者が会話のライブをレビューしていないか、などである。これらは、クライアント１２上のメッセージ／信号サービスモジュールとサーバ１６との間で送られるメッセージと信号の多くのタイプの中の２、３の例であって、本発明はこれに限定されると解釈すべきではない。
【００７７】
［Ｄ．１．２．４ ユーザインタフェースＡＰＩ］
ユーザインタフェースＡＰＩ ２０ｄは、ＭＣＭＳアプリケーション２０のユーザインタフェースモジュール２０ｅと下層サービスとの間のプログラミングインタフェースを定義する、一組の機能コールを定義するモジュールである。ユーザインタフェースＡＰＩ ２０ｄは、ＵＩアプリケーションサポート、ユーザインタフェースがＭＣＭＳアプリケーション２０を作動させるために必要な全ての機能コールなどの汎用的方法サポートする。種々の実施例において、ユーザインタフェースＡＰＩ２０ｄは、クライアント１２が、以下にあげるの広範囲のユーザインタフェースとデバイスタイプをサポートすることを可能とする。すなわち、アドビフラッシュベースのアプリケーションおよび／またはマイクロソフト社のＷｉｎｄｏｗｓ（登録商標）アプリケーション、セルラーまたはモバイルホンデバイス、トーンで駆動されるＰＳＴＮデバイス、音声ユーザインタフェース（ＶＵＩ）、および物理的無線通信インタフェース等。種々の実施例において、ユーザインタフェースＡＰＩモジュール２０ｄは、高度のフレキシビリティと高度に制約されたユーザインタフェースの設計によってＭＣＭＳアプリケーション２０の機能性をサポートすることを可能とする。
【００７８】
［Ｄ．１．２．５ ＭＣＭＳユーザインタフェースモジュール］
ＭＣＭＳユーザインタフェースモジュール２０ｅは、クライアント１２の音声・ビデオユーザインタフェースの動作および機能をサポートする。ユーザインタフェースモジュール２０ｅは、ユーザ相互作用のホストをサポートし、下記のさまざまな相互作用媒体で実現することができる。すなわち、デバイス１３上のグラフィカルユーザインタフェース・スクリーン、音声／ＤＴＭＦインタフェース、音声ユーザインタフェースで、その全てのがユーザに、システム１０とインタフェースで接続することを可能にする。サポートされるユーザ相互作用の一部リストは以下を含む。例えば、機能する；ログインする；会話を管理する、参加する、モニタする；会話のレンダリングをコントロールする；優先順位を管理する；会話をアーカイブしたレビューすることを要求する。このリストは、例示としてあげたものであり、本発明を限定するものと解釈されるべきではない。
【００７９】
［Ｄ．１．２．６．会話／メッセージ管理サービス］
会話／メッセージ管理サービス部２０ｆは、一組の機能を定義するモジュールである。これは、ユーザが会話の参加者間で送受信したメディア（例えば、音声またはビデオコンテンツメッセージ）の受信とレビューを管理するうえで必要とする全ての情報を管理、保持する役目のデータ構造および処理を管理する。メッセージは、会話に組織される。アプリケーション１２を実行しているデバイス１３によって送受信されたメディアは、受信中に即座にレビューすることができる。また、受信メディアは、タイムシフトモードでレビューするため、会話管理、およびアーカイブする目的で、記録される。他の実施例においては、メッセージまたは会話は、希望の保持条件を指定して、オプションとして一時的にマーク付けすることもできる（例えば、一部のメッセージは、即座のレンダリング要求を無視して、保持または記憶されない）。さらに他の実施例においては、メディアはタイムシフトモードだけでレビューする目的でオプションとしてマーク付けされ、受信後即座にレビューすることはできない。
【００８０】
会話／メッセージ管理サービス部２０ｆは、さらにユーザの現在の会話すなわち進行中の会話をそれぞれ随時受信中のクライアント１２にメディアを送信可能にし、受信側の動作に関わらず、受信中のクライアント１２は、これらのメッセージを適当な会話を切れ目なく結び付ける。
【００８１】
会話／メッセージ管理サービス部２０ｆにより、全ての会話は基本的に非同期性となる。もし、二つのユーザが所定の会話にアクティブに加わり、および通信間のユーザ制御の遅延が最小であれば、現在の電話またはＶｏＩＰ会話と同じく、非同期の全二重の会話となる。もし、どちらか一方のユーザの参加が遅れた場合、理由のいかんを問わず、会話は非同期の音声（またはその他のメディア）メッセージにドリフトする。代替的な実施例においては、会話は、非同期のメッセージのみあるいは同期メッセージのみとしてオプション的にタグ付けすることができる。これらのケースのどちらか一方においては、タグ付けがリセットされない限り、会話は二つのモードの間でドリフトすることはできない。タグ付けのリセット後は、会話は、ほぼ同期性（すなわち、ライブまたはリアルタイム）と非同期（すなわち、タイムシフトされたメッセージまたは音声メッセージ）モードの間で再度流れることができる。
【００８２】
会話／メッセージ管理サービス部２０ｆは、漸次メッセージの送受信の処理を行う。送信するとき、メディアが作成されても良く、メッセージは同時にエンコード、記憶され、送信される。すなわち、メッセージの送信は、ユーザによるメディアの生成と同時に（すなわち、デバイス１３に話す間、またはビデオ生成中に）始まっても良い。受信サイドでは、メッセージの受信、記憶およびレンダリングの全てのが漸次行われる。メッセージは、レンダリングされる前は、完全に受信される必要はない。メッセージのレンダリングは、メッセージがＭＴＳＤまで送達されると同時に始まっても良い。さらに、サービス２０ｆは、出力メッセージの送信と入力メッセージのレンダリングを同時に行うことができる。サービス２０ｆの漸次性により、ユーザは後の検索とレビューのために会話のメディアの記憶とストリーム中に、ここに記述するその他機能も同様、ライブ会話に参加することができる。
【００８３】
会話／メッセージ管理サービス部２０ｆによるメッセージのタイムシフトによって、もし、先行するメッセージを逃したときまたは他の会話に加わっていたとき、ユーザは、会話に「ライブにキャッチアップ」することができる。このタイムシフト処理により、ユーザは、グループ全体またはチャンネル全体にメッセージを繰り返してくれるように要求を出す必要がなくなる。古いメッセージは、時間を節約するために、可能性として高速で随時再生することができる。ユーザはメンバーのメッセージや個人のメッセージを簡単に行ったり来たりスキップできる。レビュープロセスは、低い優先順位のメッセージを潜在的にスキップするようにメッセージ優先順位ベースで構成することもできる。
【００８４】
一実施例において、会話／メッセージ管理サービス部２０ｆは、特定の参加者（話者）によってメッセージを識別し、同時に送達された会話のメッセージをデフォルトで混合する（ＭＣＭＳ−Ｓ）。任意の実施例において、ユーザは異なる会話の参加話者の通信を別個にレビューすることもできる。
【００８５】
さらに会話／メッセージ管理モジュール２０ｆは、参加者同士で会話を共有することができ、その参加者をアクティブ会話またはアーカイブの会話に加えることができる。一実施例において、会話に加えられた参加者は、会話へのアクセスが与えられ、その会話の先行のメッセージを取り出しレビューすることができる。他の実施例においては、加えた参加者は、その会話のメッセージに対してのみ、その新しい参加者が加わるポイントからアクセスが与えられ、その会話先行するメッセージに対するアクセスは与えられない。
【００８６】
また、会話／メッセージ管理モジュール２０ｆは、記憶・ストリームモジュール２４によって実行される全てのレンダリングするタスクをコントロールするために使う機能を管理する役割を持つ。これらのタスクには、アプリケーション１２を実行するデバイス１３に適切にメディア（すなわち、音声、ビデオ等）をレンダリングすることが含まれる。これらのレンダリングタスクには以下が含まれるがそれに限定されない。すなわち、ミックスしたメッセージ（すなわち、メッセージのオーバラップ）をレンダリングするとともに、ユーザ定義の基準に従い、早送り、ライブへキャッチアップ、無音の除去、躊躇粒子の除去、周波数シフトをレンダリングすること、およびマルチ会話における個人の送信側に対する独立のゲインコントロール適用すること。
【００８７】
［Ｄ．１．２．７ 優先順位サービス］
優先順位サービス部２０ｇは、一組の機能を定義するモジュールである。この一組の機能は、ユーザが、ユーザが関与する継続する会話（すなわち、ＭＣＭＳ−Ｃ）の優先順位を管理するうえで必要な全ての情報を管理保持する役割を持つデータ構造および処理を管理する。ユーザが継続的な多角ライブ会話に参加するときは、ユーザはその会話に優先順位をつけることを求められる。異なる会話のメッセージが同時にレンダリングできる状態になると、問題が起こる。アルゴリズムを使い、メッセージがレンダリングされる順序を判断し、レンダリングされるメッセージの利用可能性とユーザによってセットされた優先順位を考慮する。アルゴリズムは、最も高い優先順位をもった利用可能なメッセージを決めて最初にレンダリングし、一方、同時に利用可能なメッセージは、自動的にタイムシフトされ、高い優先順位のメッセージレンダリングできるようにする。レンダリングが可能になれば、システムは、タイムシフトされたメッセージを、ユーザの優先順位に従い自動的にレンダリングする。
【００８８】
［Ｄ．１．２．８ コンタクトサービス］
コンタクトサービス部２０ｈは、一組の機能を定義するモジュールである。この一組の機能は、一またはそれ以上のコンタクトを認証し、会話と関連づけるうえで必要な全ての情報を管理、保持する役割のデータ構造および処理を管理する。多数のコンタクトと関連づけられた会話の部分としてメッセージを送信するときは、全てのコンタクトがメッセージを受信する。
【００８９】
［Ｄ．１．２．９ プレゼンス／ステータスサービス］
プレゼンス／ステータスサービス部２０ｉは、一組の機能を定義するモジュールである。この一組の機能は、プレゼンス情報とステータス情報を管理し、システムの特定のユーザおよび／または 非ユーザと共有する役割のデータの構造と処理を維持する。種々の実施例において、プレゼンス情報とステータス情報は、クライアント１２のユーザに関わる会話に参加する全てのユーザと非ユーザ、コンタクトリストの全てのユーザと非ユーザ、または、予め定義するされたドメイン内のユーザ（例えば、会社またはその他の組織のメンバー）のために維持される。これらの例は、単に例示として挙げたものであり、限定と解釈されるべきではない。プレゼンス／ステータスサービス部２０ｉモジュールは、ユーザおよび／または非ユーザの組を定義するプレゼンス情報とステータス情報を管理、共有することもできる。
【００９０】
プレゼンス／ステータスサービス部２０ｉは、他のユーザの意図のステータス、注意、および所定の会話のタイムシフト遅延（すなわち、ライブの会話のメッセージをレビューすることからどれだけ遅れているか）をユーザにモニタすることを可能とする。一実施例において、プレゼンスとデータ状態の利用可能性について、プライバシーコントロールが提供されている。さらにプレゼンス／ステータスサービス部２０ｉは、システム１０が、ユーザの動作と意図にマッチするメッセージを送達することを可能とするデータをコントロールする。例えば、ユーザは、会話のライブをレビューするかしないか意図を指定することによって自分のステータスを示すことができる。応答として、プレゼンス／ステータスサービス部２０ｉは、ユーザの意図に従って、「ライブ」またはタイムシフトでメッセージをレンダリングさせるコマンドを発する。さらに、ユーザの意図は、その会話の他の参加者と共有される。また、サービス２０ｉは、ユーザの動作からその他のステータス値を推論することが可能である。プレゼンス情報およびステータス情報は、以下に詳しく記述するように、ネットワークのトラフィックと帯域幅を最適化する目的で使われる。
【００９１】
［Ｄ．１．２．１０ メッセージ／信号サービス］
メッセージ／信号サービス２０ｊは、一組の機能を定義するモジュールである。この機能は、システム１０のユーザに特別のメッセージまたは聞こえる音を使ってシステム１０のユーザにメッセージと信号を発する役目のデータ構造と処理を管理する。特別のメッセージまたは音は、例えば一個または複数のメッセージがライブかタイムシフトかの指示、どこからのメッセージか、優先度、その他のファクタを含んでも良い。メッセージ／信号サービス２０ｊは、さらに以下の能力を持つ。（ｉ）ネットワーク上にユーザが存在しているか否かを信号で知らせる。またもしユーザがもう会話のメッセージをアクティブにレビューしていないときは、通知することができる。（ｉｉ）ユーザが別の会話に注意を奪われているときまたは自分のデバイス１３に全く注意払っていないとき、「リング」または別の方法で通知する。ｉｉｉ）ユーザがネットワーク１８上にいない場合はメッセージを残し、次回ユーザがネットワーク１８に接続したときに即座にメッセージをレビューすることを促す。（ｉｖ）音響または視覚のフィードバックを生成し、送ったメッセージが受信側に受信されなかったことを送信側に警告する、メッセージが受信側に受信されたときおよび／またはメッセージが受信側に聞かれたときは、確認を生成する。（ｖ）会議または戦術的なコールに加わっている人々が当コールに即座に注意を払う必要がある場合、優先順位スキームを実行する。この表示は、受信側による様々なレベルの緊急性または何らかの確認を伝達しても良い。
【００９２】
［Ｄ．１．２．１１ レンダリング・エンコード］
レンダリング−エンコードモジュール２１は、ＭＣＭＳアプリケーション２０のための全てのレンダリングタスクを実行する役割をもつ。これらのタスクには、アプリケーション１２を実行するデバイス１３に適したレンダリングメディアが含まれる。
【００９３】
［Ｄ．２ 記憶・ストリームモジュール］
記憶・ストリームモジュール２４は、以下に説明するように多くの機能とパフォーマンス属性をサポートする。
【００９４】
記憶・ストリームモジュール２４は、メッセージは基本的に「全二重」で送信され、相手方もメッセージを送信中であっても、また、もし相手が出られないまたは別の通信に加わっていても、何れの当事者にも随時メッセージを送信可能にする。記憶・ストリームモジュールは、ライブのＰＳＴＮまたはＶｏＩＰコールと同じように、メッセージをレンダリングし、タイムシフトメッセージモードのためのメッセージを送達することができる。ユーザの希望に従い、送信を最適化し、レンダリングをコントロールすることができる。
【００９５】
記憶・ストリームモジュール２４は、下層のネットワーク１８上の全てのターゲットの受信側（例えば、サーバ１６、その他のデバイス１３）との接続性を維持し、全てのメッセージ、信号、およびメディアの通信を管理し、ネットワーク１８の送達速度と帯域幅を最適化し、ネットワークの品質と容量を管理しながらユーザの現下のパフォーマンス必要条件を満足する。モジュール２４は、下層のネットワーク１８の質と容量と釣り合いのとれたメディアの送達を調節し、最適化する。下層のネットワークための資源が不十分な場合は、送信するメディアストリームの質を下げることができる。帯域幅の回復しだい、送信するメディアストリームの質を上げることもできる。メディアの質のトレードオフに加え、記憶・ストリームの機能により、以下に記述するように、データをリアルタイムでレンダリングしようとするユーザの意図に基づいて、各パケットで送信するメディアの量をトレードオフすることができる。
【００９６】
下層のネットワーク１８の状態に基づいて、メディアの送達速度を動的にコントロールすることにより、記憶・ストリームモジュール２４は最適化され、受信したときにレンダリングする上で「十分に良い」時間的制約のあるメディアの送達を行い、紛失、質が低い、またはダメージを受けたパケットの再送を要求するバックグラウンドのプロセスを通じて、アーカイブする目的のそのメディアの正確なすなわち完全なコピーが最終的に送達されることを保証する。最低限のメディアの品質レベルを満足するだけのネットワーク資源がある限り、この再送は、ライブコールでのメディアのレンダリングを妨げることはない。このように、システム１０のクライアント１２は、相当な潜在的待ち時間を犠牲にしたメディアの正確なすなわち完全なコピーの送達と完全性の保証はないがメディア素早い送達との間のパフォーマンスギャップを橋渡しするように設計されている。本アプリケーションの文脈において、用語「十分に良い」とは、メディアの質が、レンダリングされたときに理解できる、ということを意味する。したがって、「十分に良い」の概念は主観的なものであって、絶対的な用語として解釈されるべきではない。例えば、あるメディアの十分に良い質のレベルは、メディアのタイプ、状況、その他のファクタによって変わりうる。
【００９７】
さらに、記憶・ストリームモジュール２４は、デバイス１３を使って別途生成された、または、ネットワーク１８上で別のデバイス１３および／またはユーザから受信された全てのメディアを持続的に記憶する。クライアント１２を実行するデバイス１３上でこのメディアを記憶することは幾つかの大きな利点がある。（ｉ）送信側および／または受信側が出られないまたはネットワーク接続性が貧弱である場合でも、ユーザは相手方にメッセージを残すことが可能となる。帯域幅が不十分なケースでは、メッセージは帯域幅が効果的に使える限り早く送信される。接続性が不要のケースでは、メッセージは、送信待ちのキューに並び、ネットワークの接続が使用可能になると即座にタイムシフトの送達がおこなわれる。（ｉｉ）ユーザは、ポーズ、リプレイ、早送り、ライブの進行中の会話にキャッチアップができると同時に、アーカイブされた先行する会話のメッセージを取り出しレビューすることができる。（ｉｉｉ）時々起こるネットワーク回線容量および接続性の問題にたいしてシステム１０上のデータペイロードの最適化とシステムの復元力を向上することが可能となる。
【００９８】
また、記憶・ストリームモジュール２４は、下記の役割をもつ。多数の参加者が話している実際の会話をシミュレートして、メッセージを適切にミキシングし、オーバラップメッセージ（会話における話者等の通常のオーバラップまたはバックグラウンドのノイズで生成される）を作成する、音声メディアの解説または翻訳をレンダリングすること、早送り、発話間の無音ギャップの除去、躊躇粒子の除去、周波数シフトをを含む多数のユーザ定義の基準に従ってメディアのレンダリングを調節すること、マルチ会話における個人の送信側に対する個別のゲインコントロールを適用すること能力を持つこと及び潜在的なレンダリングオプションをもつ。
【００９９】
記憶・ストリームモジュール２４は、それ自身とＭＣＭＳとの間のコントロールおよび情報メッセージを管理する。
【０１００】
［Ｄ．２．１ 永続的無限メッセージバッファ（ＰＩＭＢ）］
永続的無限メッセージバッファ（ＰＩＭＢ）３０は、一組のインデックスされた（すなわち、タイムスタンプ付け、順番に番号付け）メディアペイロードデータの構造、およびその記憶と取出しのためのシステムである。一実施例において、ＰＩＭＢ３０内のデータは、永久にあるいは少なくともシステムの記憶装置がいっぱいになるまで、使用可能であるという意味で、実質的に永続性をもつ。記憶資源を有効利用するために、様々な保持率と方策を採用することができる。ＰＩＭＢ３０の物理的記憶を実施するには下記のような様々な方法があるが、これに限定されない。すなわち、ＲＡＭ、フラッシュメモリ、ハードドライブ、光学メディア、またはその幾つかの組み合わせ。ＰＩＭＢ３０も、ＰＩＭＢ３０に記憶できるデータの量は本質的に限定されないという意味で、サイズ的に「限定」である。この限定がないということは、レンダリング後即座にデータを廃棄する現在のジッタバッファ技術との比較の上でのことである。特定の実施例において、ＰＩＭＢ３０は、持続的記憶用のハードドライブと連結された小さくて比較的早いＲＡＭキャシュメモリを使って実現することもできる。ＰＩＭＢ３０の物理的記憶容量を超えた場合、オンデマンドでの後の検索のために、データはサーバ１６に保持される（以下に記述する）。何れの時点でも、ＰＩＭＢ３０に記憶された実際のデータまたはサーバ１６、またはアーカイブされたデータは、ユーザ基準または「最も古く使われた」、又は、「先入れ後出し」等の入れ替えアルゴリズムを使ってコントロールされる。さらに、ＰＩＭＢ３０は、ファイルシステム保存の属性およびランダムアクセスの属性のレンダリングをおこなう。それぞれのメッセージの期間または数にかかわらず、どんな数の会話でも記憶でき、後で検索してレビューすることができる。さらに、作成源、長さといった、会話のメッセージと関係するメタデータもＰＩＭＢ３０に記憶することができる。他の実施例においては、インデックスかされたメディアペイロードおよび他のデータは、指定の期間（例えば、３０日）記憶することができる。メディアが指定の期間を超えると、ペイロードとデータは廃棄される。別の実施例においては、ペイロードを含むメッセージの送信側および／または受信側、またはペイロードに関わる会話またはメッセージのトピックに基づいてペイロードは廃棄することができる。さらにその他実施例においては、ペイロードおよびデータは一時的にマーク付けされ、メッセージは、即座のレンダリングの要件を超えて、ＰＩＭＢ３０に記憶されない。
【０１０１】
［Ｄ．２．２ データ・ネットワーク品質記憶部］
データ・ネットワーク品質記憶部（ＤＮＱＳ）３２は、ＰＩＭＢ３０から読み取られ、ＰＩＭＢ３０に書き込まれるメディアペイロードとＶｏｘパケットに関する情報を記憶するためのデータ記憶部である。
【０１０２】
［Ｄ．２．３ ＰＩＭＢ書込み部］
ＰＩＭＢ書込み部２８は、二つの基本的目的のためにデータをＰＩＭＢ３０に書込む。ＰＩＭＢ書込み部２８は、クライアント１２を実行するデバイス１３上のメディア取得デバイス（例えば、マイクまたはカメラ）からのデータを書込む（「エンコード受信」）。また、ＰＩＭＢ書込み部２８は、他のクライアント１２からネットワーク１８を通じて受信したデータを書込むＰＩＭＢ３０（「ネット受信」）。
【０１０３】
［Ｄ．２．３．１ エンコード受信］
デバイス１３からメディアを取得するために、ＰＩＭＢ書込み部２８は、エンコーダ受信部２８ａとデータ記憶部２８ｃを含む。例えば、あるユーザがマイクに話かける、あるいは、デバイス１３でビデオメッセージを生成すると、ハードウェア３４生の音声および／またはビデオ信号を受信し、それをインデックスされたメディアペイロードにエンコードするエンコーダ受信部２８ａにレンダリングする（以下、単に「ペイロード」と称する場合もある）。データ記憶部２８ｃはそのペイロードをＰＩＭＢ３０に記憶する。センサデータ等のその他のタイプのメディアは、同様の仕方でペイロードに変換される。
【０１０４】
［Ｄ．２．３．２ ネット受信］
ネットワーク１８を通じて受信メディアをＰＩＭＢ３０に記憶するため、ＰＩＭＢ書込み部２８のネット受信機能は、ネットワーク受信部２８ｄ、データバッファ部２８ｅ、データ記憶部２８ｆ、データ品質管理部２８ｇおよびネットワーク品質管理部２８ｈを含む。ネットワーク受信部２８ｄは、ネットワーク１８を通じてＶｏｘパケットを受信する。データバッファ部２８ｅは、受信したＶｏｘパケットを正しい順序に置き、入ってくるＶｏｘパケットのレンダリングの少なくとも最小タイムシフト遅延（ＭＴＳＤ）を防ぐ。データ記憶部２８ｆは、パケットをインデックスされたメディアペイロードに変換し、インデックスされたメディアペイロードをＰＩＭＢ３０に記憶する。ペイロードが記憶されと、データ品質管理部２８ｇは、紛失パケットあるいは欠陥パケットがないか監視する。もし紛失パケットや欠陥があるがある場合は、ＤＱＭ２８ｇはネットワーク１８を通じて再送要求を予約する。送信側のデバイスは、これに応えて紛失パケットまたは欠陥パケットを再送する。最終的にはこれらのパケットは、インデックスされたメディアペイロードに変換され、ＰＩＭＢ３０に記憶される。紛失パケットまたは欠陥パケットを取出すことによって、送信側のメッセージの「正確な」コピーは最終的にはＰＩＭＢ３０に記憶される。紛失パケットおよび／または欠陥パケットの再送によって、メッセージのリアルタイムのレンダリングに遅延を生じることはなく、送達されレンダリングされたパケットは「十分に良い」品質と量となる。新しい「ライブ」データと再送サポートするだけの十分なネットワーク資源がない場合は、ＤＱＭ２８ｇによって再送要求が遅延される場合もある。
【０１０５】
［Ｄ．２．４ ＰＩＭＢ読取り部］
ＰＩＭＢ読取り部２６は、二つの基本的目的のためにＰＩＭＢ３０からデータを読取る。データがローカルクライアント１２向けにレンダリングされる場合は（「レンダリングする」）、ＰＩＭＢ読取り部２６はＰＩＭＢ３０にアクセスする。データがクライアント１２によってネットワーク１８を通じて送信される場合も（「送信」）、データはＰＩＭＢ３０から読取撮られる。
【０１０６】
［Ｄ．２．４．１ レンダリング］
クライアント１２上のメッセージをレンダリングするために、ＰＩＭＢ読取り部２６は、データ優先順位付与部２６ａ、データ取出し部２６ｂ、パケット損失補償／補間部（「ＰＬＣ／補間部」）２６ｃ、データミックス部２６ｄおよびデータレンダ部２６ｅを含む。データ優先順位付与部２６ａは、レンダリングされるデータに優先順位をつけ、潜在的にレンダリングされる可能性のあるメッセージを順序付けられたキューを作る。これは、ユーザ設定の優先順位を使い、継続会話（ＭＣＭＳ−Ｃ）をレンダリングする。さらに、データ優先順位付与部はメディアデータの利用可能性を使い、ＭＴＳＤ、ユーザの現在の注意、ユーザが定義、含意する意図によって強制される制限内にレンダリングする。データ取出し部２６ｂは、ＰＩＭＢ３０から優先順位付けされたインデックスされたメディアペイロードを取り出す。ＰＬＣ／補間部２６ｃは、既知のパケット損失補償と補間アルゴリズムを使って取り出したペイロードにパケット損失補償および補間を実行する。使われる個々の方法は現在使われているメディアコーデックおよびその他既知のパラメータによる。ミックス部２６ｄは、適切にミックスして一個の会話のなかの多数のメッセージを使って同時データストリームを作るのに使われる。例えば、もし、二人以上の会話参加者が同時に話しているときは、ミックス部２６ｄは、同時に話している参加者の効果も作成してメッセージミックスする。代替的な実施例においては、ユーザは、オプションとして、一人の参加者の多数のストリームを一時にレビューすることもできる。もし、会話の中の一人の参加者のみが話している場合は、ミックス部２６ｄは、ミキシングを行なわずに一個ののメッセージストリームをパスしても良い。レンダ部２６ｅは、ミックス部モジュール２６ｄからデータを取り出し、それをハードウェアドライバ３４に適したフォームに変換する。ハードウェア３４は、メディアのタイプ、作成する音声、ビデオ、その他デバイス１３上の音響および／または視覚警報装置によって、デバイス１３のスピーカーまたはビデオ表示部を駆動する。
【０１０７】
［Ｄ．２．４．２ 送信］
ネットワーク１８を通じてクライアント１２から送信するメッセージを作成するために、ＰＩＭＢ読取り部２６はデータ優先順位付与部２６ｆ、パケット品質管理部（ＰＱＭ）２６ｇ、データ読取り部２６ｈ、パケット部２６ｉ、送信部２６ｊおよび認証部２６ｊを含む。データ優先順位付与部２６ｆは、ネットワーク１８を通じて送信するメッセージに優先順位をつける。優先順位は、送信できるペイロードに関するＭＣＭＳ参加者の属性、ネットワークの接続性と回線容量の状態、およびライブまたはタイムシフトでレンダリングする次のホップの向こう側にいるおよびユーザの意図、そして、幾つかの実施例においては、次の所定のネットワークホップに対する多数のパケットが利用できる場合には、送信組立の可能な最適化、を使って判断される。次に、以下に詳述するように、優先順位をつけられたパケットは、ライブメッセージを行ううえで「十分に良い」品質のデータをタイムリーに送達することを確実にするＰＱＭ２６ｇを使ってリアルタイムの帯域幅を最小化しながら最適化される。データ読取り部２６ｈは、ＰＩＭＢ３０から適切なペイロードを取り出す。パケット部２６ｉは、ペイロードをＶｏｘパケットに組立て、Ｖｏｘパケットは次にネットワーク１８を通じて送信部モジュール２６ｊによって送信される。受信側がＶｏｘパケットを受信すると、ネットワーク１８を通じて認証部２６ｊに確認が送られ、メッセージが宛先に着信したことを送信側のユーザに通知する。
【０１０８】
［Ｄ．２．５ パケット品質管理部］
ＰＱＭ２６ｇには、以下の最適化目標がある。（ｉ）時間的制約のあるメディアの適切なコピー（レンダリングするうえで「即座に、十分に良い」）をタイムリーに送達すること；（ｉｉ）最適な送信周波数、ペイロードの品質、および下層のネットワークのための最適なパケットサイズを使って使用可能な帯域幅を有効に使うこと；および（ｉｉｉ）送信周波数、ペイロードのコンテンツ、ペイロードの品質、パケットのサイズ等をネットワークの状態変化に応じて動的に調節する、または変更すること。
【０１０９】
［Ｄ．２．６ ネットワーク品質管理部］
ネットワーク送信の受信サイドにはネットワーク品質管理部２８ｈ（ＮＱＭ）がある。ＮＱＭは、実際値に対するジッタ、損失、および処理量の期待値を比較して、クライアント１２にメディアを送った各送信側のためのネットワークのパフォーマンスの特定の特性を監視する役割を持つ。全ての送信側のネットワーク品質レート（ＮＱＲ）を計算するために使われる。ＮＱＲは受信側のデバイスのユーザに送信側の利用可能性および会話のライブ度を示すために使われる。
【０１１０】
［Ｄ．２．７ データ品質管理部］
データ品質管理部２８ｇは、パケット損失、ジッタ、処理量を監視して、ネットワークを通じて受信中のデータの品質を測定する。ＤＱＭ２８ｇはこれらの測定値を３つ目的のために使う：（ｉ）送信側に受信レポートを送り返す；（ｉｉ）オプションとして、これらの受信レポートを使って特定のデータの再送を要求する；および（ｉｉｉ）これらの測定値をＮＱＭ２８ｈが利用できるようにする。
【０１１１】
［Ｅ．サーバアーキテクチャ］
図３はサーバ１６上で実行するアプリケーション７８のブロック図である。アプリケーション７８は、多くの点でクライアントアプリケーション１２と同様であり、以下を含む。すなわち、ＭＣＭＳサーバアプリケーション８０、ＭＣＭＳデータベース８２、記憶・ストリームモジュール８４、ＰＩＭＢ８５、データ・ネットワーク品質記憶部（ＤＮＱＳ）８６、ＭＣＭＳサーバアプリケーション８０と記憶・ストリームモジュール８４の間を行き来するメッセージと信号を管理するＭＣＭＳ−ＳＡＳメッセージハンドリングモジュール８７ａ、８７ｂ、アーカイブ／取出し部８８、およびアーカイブ部８９。さらに、アプリケーション７８は、認証−暗号化セキュリティモジュール４０および通信プロトコルモジュール４４を含む。
【０１１２】
ＭＣＭＳサーバアプリケーション８０は多層構造のアーキテクチャであって、以下を含む。すなわち、ＭＣＭＳデータベースモジュール２０ａ、記憶・ストリーム（ＳＡＳ）モジュール２０ｂ、メッセージ・信号モジュール２０ｃ、会話／メッセージ管理サービス部２０ｆ、優先順位サービス部２０ｇ、コンタクト（ユーザと認証を含む）サービス部２０ｈ、プレゼンス／ステータスサービス部２０ｉおよびメッセージ／信号サービス部２０を含む。クライアント１２と同じ参照番号を持つアプリケーション７８の前記モジュールおよびサービス部はクライアント１２の同じ参照番号を持つモジュールおよびサービス部と同様もしくは同じであり、したがって注意すべき例外を除きここでは詳しい記述を省く。種々の実施例において、ＭＣＭＳデータベース８２を含むＭＣＭＳサーバアプリケーション８０および記憶・ストリームモジュール８４は、アプリケーションの一例として、多数のユーザをサポートするように構成されている。さらに、この例は、ユーザのグループとして定義される多数のドメインをサポートするように構成されてもよい（例えば、会社または共通の組織に所属するユーザその他のグループ）。このアーキテクチャは、サーバ１６上の各アプリケーション７８が、各ユーザ（またはドメイン）が他のユーザには見えない多数のユーザ（またはドメイン）に使えるようにしてもよい。この区切り方は「マルチテナント」と呼ばれる。
【０１１３】
記憶・ストリームモジュール８４はネット受信と送信の機能を実行する。ネット受信機能用として、モジュール８４は、ネットワーク受信部２８ｄ、データバッファ部２８ｅ、データ記憶部２８ｆ、データ品質管理部（ＤＱＭ）２８ｇ、およびネットワーク品質管理部２８ｈを含む。送信機能用として、モジュール８４は、データ優先順位付与部２６ｆ、パケット最適化部２６ｇ、データ読取り部２６ｈ、パケット部２６ｉ、送信部２６ｊおよび認証部２６ｊを含む。記憶・ストリームモジュール８４の上記の構成要素は、クライアント１２の同じ参照番号を持つ構成要素と同様又は同じである。したがって、それらの詳しい記述は割愛する。
【０１１４】
サーバ１６はユーザと直接情報のやりとりはしないので、クライアント１２の記憶・ストリームモジュール２４に与えられたエンコードとレンダリング機能は、必要としない。ＭＣＭＳアプリケーション８０は、サーバ１６上で動作するときは、ユーザと直接やり取りはしない。したがって、ユーザインタフェース、および ユーザインタフェースＡＰＩモジュールおよびサービス部２０ｅ、２０ｄは必要ない。
【０１１５】
各サーバ１６上のアプリケーション７８は、潜在的に多数のテナントに関与する。つまり、システム１０の多数のユーザに関与する。サーバアプリケーション７８のＰＩＭＢ８５は、したがって、一個ののユーザのみの生成されたまたは受信したペイロードだけを記憶するために使われるＰＩＭＢ３０とは異なり、相当に大きく、また、多数のユーザのメディアペイロードを記憶するために使われる。記憶・ストリームモジュール８４の主な目的は、クライアント１２によって送信されるメッセージを受信することと他のクライアント１２にメッセージを送信することである。メッセージが受信されると、ＰＩＭＢ８５に記憶されるとともに、目的の受信側またはシステムの構成に直接依存する受信側への経路に沿って、ネットワーク層１４の次のサーバ１６（すなわち、ネット「ホップ」）へ送信される。アーカイブ／取出し部８８は、アーカイブ部８９内のＰＩＭＢ８５に記憶されたメディアのペイロードをアーカイブする役割を持つ。ＰＩＭＢ８５内の物理的スペースがなくなると、ＰＩＭＢ８５内のメディアのペイロードは大量記憶デバイスであるアーカイブ部８９へ移される。種々の実施例においては、ＰＩＭＢ８５に記憶されたペイロードは、ユーザ定義の基準および／または先入れ先出し（ＦＩＦＯ）または最後に使われた（ＬＲＵ）等の既知の入れ替えアルゴリズムに従ってアーカイブされる。解りやすくするために、図１には、一個のサーバ１６のみが示されている。実際の実施例においては、複数のサーバまたは「サーバファーム」は、多数のユーザとのネットワークのために使われる。
【０１１６】
ＰＩＭＢ３０およびＰＩＭＢ８５を記述するために使われる用語「永続性の」と「限定」は、厳密な用語として文字通り解釈すべきではない。ユーザは、重要とおもわれる幾つかのメッセージは、いつまでも記憶したいと望む。二人の友達間の普段のおしゃべり等のその他の状況では、スペースを節約するために、一定の時間が経過したら、メッセージは削除しても良い。本発明の種々の実施例によれば、システム１０によって設定されるかユーザによって設定されるか、異なる保持ポリシが使われても良い。「限定」の用語は、ＰＩＭＢによって強制される時間的区切りがないという意味で使用される。このことは、現在のジッタバッファシステムでは、メディアはレンダリングされた後は、廃棄されるのとは対照的である。「永続性」および「限定」の用語は、したがって、ＰＩＭＢ３０およびＰＩＭＢ８５は、時間の範囲とそこに記憶されるメッセージの量については何ら内的制限がない、ということを意味すると広く解釈されるべきである。
【０１１７】
持続的記憶媒体に会話のメッセージをアーカイブすることには多くの利点がある。音声メッセージおよびその他のメディアは、必要に応じ組織化され、インデックスされ、検索され、転記され、翻訳され、レビューすることができる。音声およびその他のメディアは、したがって、ユーザおよび組織によって管理することのできる資産となる。これらのメディア資産は、軍隊同様、会社、第一応答者、警察および消防署にとっても価値がある。
【０１１８】
［Ｆ．Ｖｏｘプロトコルおよびインデックスメディアペイロード］
上記したように、Ｖｏｘプロトコルは、ペイロードの送信、記憶、および最適化の全ての面をサポートするために、記憶・ストリームモジュール２４によって使われる。Ｖｏｘパケットは、ネットワーク１８の下層の技術における一個または複数の搬送パケットの内部のカプセル化のために設計された構造化されたメッセージフォーマットである。これによりシステム１０の自由度が大きく改善される。搬送パケットの中にＶｏｘパケットを埋め込むことによって、「ヴォクシング（Ｖｏｘｉｎｇ）」アプリケーションのために新しい搬送層を定義するのとは対照的に、システム１０は、現存する通信インフラを通じて動作する通信ネットワークに基づいて現在のパケットを利用する。Ｖｏｘパケットを扱うための新しいネットワークインフラは、したがって、ここに記載するシステムおよび方法の全ての利点を利用する必要はない。
【０１１９】
図４Ａを参照すると、Ｖｏｘパケット９５の一般的なフォーマットの構造が示されている。Ｖｏｘパケット９５のフォーマットは、タイプ、サブタイプ、長さ、およびペイロードを含む。Ｖｏｘパケットの別のタイプは、認証、信号発信、メディアペイロード、メディア多重化（一個のメッセージ）、およびメディア多重化（多数のメッセージ）を含む。サブタイプのフィールドは、異なるタイプの認証、信号発信、メディアタイプメッセージを指定するために使われる。認証メッセージのための可能なサブタイプとしては、キー交換および認証に必要なフィールドが含まれる。信号発信メッセージのための可能なサブタイプとしては、登録、ルーティング、メッセージのセットアップおよびネットワークの管理が含まれる。メディアメッセージのための可能なサブタイプとしては、コーデックの型と異なるペイロード集約技術が含まれる。長さフィールドはペイロードの全長すなわちサイズを定義する。ペイロードフィールドは、パケット９５の実際のペイロードすなわちメディアを含む。
【０１２０】
図４Ｂはネットワーク１８によって使われるカプセル化せれたＶｏｘパケット９５のプロトコルの例を示す図である。この例では、ＵＤＰ、ＩＰおよびイーサネット（登録商標）の搬送パケット９６の下層にそれぞれ埋め込まれたＶｏｘパケット９５を示す。この方法においては、Ｖｏｘパケット９５は、ネットワーク１８の下層のＵＤＰ、ＩＰおよびイーサネット（登録商標）層を通じて搬送できる。これは、パケットネットワークによって使われる標準的なプロトコルカプセル化の技術である。
【０１２１】
図４Ｃは、ＵＤＰ、ＩＰ、およびイーサネット（登録商標）９７内でカプセル化されたメディア多重化Ｖｏｘパケット９５を示す図である。この例では、Ｖｏｘパケット９５は、メディアタイプフィールド、メディアサブタイプフィールド、長さフィールド、メッセージＩＤフィールド、タイムスタンプフィールド、シーケンスＩＤフィールドおよびメディアペイロードフィールドを含む。
【０１２２】
図４Ｄは、インデックスされたメディアペイロード９８のフォーマットを示す。インデックスされたメディアペイロードは、サブタイプフィールド、長さフィールド、メッセージ識別子（ＩＤ）フィールド、タイムスタンプフィールド、シーケンス識別子（ＩＤ）フィールド、およびメディアペイロード用のフィールドを含む。
【０１２３】
Ｖｏｘパケット９５を搬送パケット下層のネットワークのカプセル化することによって、メディア、メッセージおよび会話を多数の属性によってそれぞれ定義することができる。
【０１２４】
メディアがデバイス１３上に作成または生成されると、それは、主としてタイムベースのものとなり、時間経過とともに意味のある形で変化する。ある人が会話に参加すると、例えば、時間の経過とともに、話し言葉はセンテンスまたは発言につなぎ合わされて、結果としてのデータ（ストリームおよびパケット）は、同じ相違を長い時間維持する。同様に、ＧＰＳその他センサデータ同様、ビデオ（スチール写真とは対照的に）は、時間の経過とともに変化する。タイプや生成のされ方にかかわらず、メディアはセグメント化され、複数のＶｏｘパケット９５のペイロード中に置かれる。続いてパケットは記憶され、送信され、受信され、記憶され、送信側と受信側のデバイス１３のそれぞれでストリーム（すなわち、ストリーム中のメディア）にレンダリングされる。各パケット９５は、インデックスされ、タイムスタンプ処理され、シーケンス識別子が付与されているので、個々のパケットは、メッセージにセグメント化することができる。個人のメッセージを順番にスレッディングすることによって会話を構成することができる。
【０１２５】
システム１０の固有の側面として、クライアント１２によって生成されたメディアペイロードは多くのロケーションに記憶されるということである。ペイロードは、生成側のデバイス１３のＰＩＭＢ３０に記憶されるだけでなく、受信側のサーバ１６のＰＩＭＢ８５およびデバイス１３のＰＩＭＢ３０にも記憶される。この基本的な機能によって、Ｖｏｘｉｎｇ機能の多くを可能とし、ネットワークの状態が不良であっても、あるいは会話の参加者がネットワークに接続されていなくても、システム１０に復元力と操作性を提供する。
【０１２６】
［Ｇ．下層通信プロトコルとの相互操作性］
システム１０は、インターネット、固定ＰＳＴＮタイプ回路ネットワーク、およびモバイルまたはセルラーホンネットワークまたはその組み合わせのようないろいろな現存する通信ネットワーク１８を通じて、実行する、あるいはそれらと層化することを意図している。システム１０は、システム１０内の異なるクライアント１２とサーバ１６間を移動する多数の小さな情報の単位（すなわち、Ｖｏｘパケット）のコンセプトの周辺に設計されている。Ｖｏｘパケットは、機能およびペイロードによってサイズは異なるが下層のネットワーク層にとっては、全て同じ種類のデータとして見える。一実施例において、システム１０は、インターネット等のＩＰｖ４ネットワークが設計されて最適化されたものだが、その他のタイプのネットワークもサポートする。本ドキュメントの目的に照らして、用語「ＩＰ」は、ＩＰｖ４、ＩＰｖ６あるいはその他現在または未来に実施されるであろうインターネットプロトコルを意味すると理解されるべきである。
【０１２７】
図５は、デバイス１３上で実行し、共用ＩＰネットワーク１００を通じてサーバ１６と通信するクライアント１２を示す。図に示すように、クライアント１２は、第一のインターネットサーヴィスプロバイダＡを介して共用ＩＰネットワーク１００に連結され、サーバ１６は、第二のインターネットサーヴィスプロバイダＢによって共用ＩＰネットワーク１００と連結されている。通信中に、Ｖｏｘパケット９５（図では「ＶＰ」と表記）はＵＤＰ／ＩＰパケットにカプセル化され、ついで当該技術では周知のように、他のＩＰプロトコルパケットにインタリーブされ、共用ＩＰネットワーク１００を通じてクライアント１２からサーバ１６等へ送信される。周知の如く、低いパケット層はすぐ上の層のパケットの全てをカプセル化する。また、パケットは、同様のやり方で２個のサーバ１６間でやり取りされる。メッセージは、共用ＩＰネットワーク１００を通じてクライアント１２が許可したデバイス１３から他のクライアントへ送られる。Ｖｏｘパケット９５は、ターゲットの宛先に到達するまで各ホップで下層のＩＰプロトコルに埋め込まれ送信される。
【０１２８】
図５は、説明のために、ネットワーク１００接続された一個のクライアント１２とサーバ１６を例示的に示す。実施例における実際のシステム１０は、多くのクライアント１２と一またはそれ以上のサーバ１６が主として共用ＩＰネットワーク１００に接続されている。また、クライアント１２およびサーバ１６は、ＩＰネットワーク１００を排他的に使うものではないことに注意されたい。図示の例では、インターネットプロバイダＡを介してネットワーク１００と連結されたＨＴＴＰクライアントは、ネットワーク１００に連結されたＨＴＴＰサーバとの間で、第３のインターネットプロバイダＣを経由してパケットをやり取りすることができる。システム１０は、ＩＰパケットに埋め込まれたＶＰがネットワーク１００を横断する方法についてコントロールはしない。ネットワーク１００を共有し横断する全てのパケットは、下層の共用ＩＰネットワーク１００の標準的な手順に従って動く。
【０１２９】
図６は、ネットワーク１０４にベースを置くＧＳＭモバイルホンネットワーク等の「回路」を示す。回路ネットワーク１０４は、デバイス１３上で動作するクライアント１２とサーバ１６の間で連結されている。一旦クライアント１２とサーバ１６の間で回路が確立されると、システム１０はネットワーク１０４が使う下層のパケットの上にＶｏｘパケット（ＶＰ１、ＶＰ２、ＶＰ３、ＶＰ４、ＶＰ５等）を積み重ね、「バーチャルＶｏｘ」回路を作りネットワーク１０４を通じてそれらを送信する。Ｖｏｘパケットは、データを送信する技術において知られているように、主として間隔をあけるかデータを形成して回路ネットワークを通じて回路ネットワーク１０４を順番に横断する。さらに、ペイロードのサイズおよび含まれるヘッダフィールドの数等のパケット構成パラメータを使い、パケットごとのオーバヘッドがないことを利用することもでき、またネットワーク１０４を通じてデータを送信する速度および／または効率を向上させることもできる。単純化の目的で、一個のクライアント１２とサーバ１６のみがネットワーク１０４に接続されて示していることに再度注意を促したい。しかしながら、クライアント１２とサーバ１６およびその他のコンポーネントとの間の付加的回路は、ネットワーク１０４を介して一斉に確立することができることについては理解できよう。したがって、ネットワーク１０４は、Ｖｏｘパケットを送信するための専用ではなく、むしろ他のタイプのネットワークトラフィックと共有してもよい。
【０１３０】
図７は、第一のネットワークＡにつながる第一クライアント１２Ａによって動くデバイス１３Ａと第二のネットワークＢにつながる第二のクライアント１２Ｂによって動くデバイス１３Ｂとの間の通信を示す図が示される。さらに、ネットワークＡ、Ｂはそれぞれ、ゲートウェイサーバ１６Ａおよび１６Ｂを含む。ゲートウェイサーバの組１６Ａ、１６Ｂは、二つのネットワークＡ、Ｂ間の通信を促進し、デバイス１３Ａ、１３Ｂに互いに通信を可能にする。種々の実施例において、二つのネットワークＡ、Ｂそれぞれどのようなタイプのネットワークでもよい。例えば、各ネットワークＡおよび／またはＢは、ＩＰネットワーク、回路タイプのネットワーク、無線通信またはセルラーネットワーク（すなわち、ＣＤＭＡ、ＧＳＭ、ＴＤＭＡ等）でもよい。サーバ１６は、二つのネットワーク間のトラフィックのルートを決めたり「ゲート」として機能したりするので、二つのネットワークＡ、Ｂにまたがるゲートウェイサーバとも考えられる。
【０１３１】
システム１０によって、システムのパフォーマンスを最適化するための、いくつかの基本的なネットワークの相互作用に関する考え方がある。これらの考え方には、Ｖｏｘパケット９５が送られる下層のアドレスの分解法、送られたＶｏｘパケットの統合、および所定のネットワークまたはネットワークの組み合わせを通じて送られる一個のメッセージの最大送信単位（ＭＴＵ）の管理などのファクタが含まれる。
【０１３２】
下層のネットワークがＶｏｘパケット９５を正しいロケーションに送達できるように、ターゲットクライアント１２のアドレスを知る必要がある。ＩＰｖ４ネットワークでは、アドレスは主としてＩＰｖ４アドレス、ネットワーク内のホストを一意的に識別する３２ビット数である。別のネットワーク技術においては、アドレスは別のタイプの識別子である場合もある。ＩＰネットワークではドメインネームシステム（ＤＮＳ）を使い、人間が読み取り可能なネームをＩＰアドレスに変換し、アドレス変換プロトコル（ＡＲＰ）でＩＰアドレスを物理アドレスに変換する。下層のネットワーク技術に関わりなく、システム１０は、上記のスキームのうちの一つまたは他の既知のアドレススキームを使ってＶｏｘパケット９５を正しいロケーションに送達する。
【０１３３】
パケットベースの通信システムにおいては、もし、下層のネットワークがＶｏｘパケットがカプセル化されたパケットを送達できなければ、送信されたＶｏｘパケットがアドレスされたロケーションに送達されない場合もある。ほとんどのパケットネットワークは、パケットが欠落しても送信側へ通知しない。これとは逆に、パケットは送信側と受信側に依存し、欠落したパケットを通知し、補正する。システム１０はこれらの受信側の受信レポートメッセージを使いパケット損失管理を調整するように設計されている。もし、下層のネットワークが欠落し紛失パケットを送信側に通知することができれば、システム１０はこの情報をプロトコルの再送信に使用できる。
【０１３４】
ＭＴＵの管理とは、ネットワークを通じて送ることのできる最大送信単位（すなわち、一個のメッセージの最大サイズ）を決定することである。パケット方式のネットワークでは、下層のネットワークがＭＴＵを付与する。回路切り換え型ネットワークでは、ネットワーク効率とパフォーマンスのために、ＭＴＵは調節可能なパラメータである場合もある。このように、多くのケースでは、Ｖｏｘパケット９５が効率的に送信されるように、下層のネットワークがＶｏｘパケット９５の最大サイズを与えたり決めたりする。例えば、ＩＰネットワークでは、ペイロードがＭＴＵを超えた場合は、相当なパフォーマンスを犠牲にして、パケットは細分化ができる。イーサネット（登録商標）ネットワークを通じたＩＰでは、送信側のデバイスは、イーサネット（登録商標）が実行するものとして、１５１８バイトのＭＴＵである。最大ＩＰパケットは、イーサネット（登録商標）ヘッダのための余地を残さなければならない。最大ＵＤＰパケットは、ＩＰとイーサネット（登録商標）のヘッダのための余地を残さなければならない。およびイーサネット（登録商標）で生成される最大Ｖｏｘプロトコルは、例えば、イーサネット（登録商標）ＭＴＵ（１５１８）−ＩＰヘッダ（２０）−ＵＤＰヘッダ（８）＝１４９０バイトである。Ｖｏｘプロトコルは、それ自身のヘッダを持つので、実際のＶｏｘメディアペイロードはイーサネット（登録商標）ネットワーク上では１４９０バイト以下である。ギガバイトイーサネット（登録商標）の場合は、ＭＴＵははるかに大きくてもよいが、同様の計算式を使って判断される。
【０１３５】
純粋にパケットベースネットワークにおいては、ＭＴＵ用に二個の潜在的値、すなわち、ローカルリンクＭＴＵおよび経路ＭＴＵがある。ローカルリンクＭＴＵは、ローカルネットワークインタフェースに効率的に送られるように、Ｖｏｘパケット用に最大サイズが決定する。経路ＭＴＵは、遠隔地のノードまで全行程完全な状態で送られるように最大サイズのＶｏｘパケットを出す。送信側がイーサネット（登録商標）を介して接続されている場合は、小さなＭＴＵで、Ｖｏｘパケットは様々な別のシステムを経由して、受信側までの道順を決められる。宛先までの経路上の最も小さなＭＴＵの場合は、送信側によって決定され通知される必要がある。ＩＰの世界では、「経路ＭＴＵディスカバリ」と呼ばれる最も小さいＭＴＵを見つけるための標準的な手順がある。その他の種類のネットワークには、同様な手順が使われてもよい。改めて言うと、システム１０は、別のネットワークの上に重ねられているので、上記のどのＭＴＵアルゴリズムでも使うことができる。
【０１３６】
［Ｈ．動作フロー図］
［Ｈ．１ 記憶及びストリーム］
図８Ａないし８Ｆは一連のフロー図であり、クライアント１２とサーバ１６上の記憶・ストリームモジュール２４、８４のそれぞれの動作を示す。図８Ａは、第二のクライアント１２２にメッセージを送信する第一のクライアント１２１のための動作シーケンスを示す。図８Ｂと８Ｃは送信側クライアント１２１上のＰＩＭＢ書込み部２８とＰＩＭＢリーダ２８の動作を示す。図８Ｄと８Ｅは、受信側クライアント１２２上のＰＩＭＢ書込み部２８とＰＩＭＢ読取り部２６の動作を示す。図１０Ｆは、サーバ１６上の記憶・ストリームモジュール８４のフロー図を示す。
【０１３７】
図８Ａにおいて、デバイス１３１上で動作するクライアント１２１のユーザが、送信すべきメディアを生成する。メディアは、デバイス１３の側で、ユーザがマイクに話すことによってメディアを作成する、自分のデバイス１３上でビデオコンテンツを作成する等、多くの異なる方法で作ることができる。また、メディアはデバイス１３によってＧＰＳ情報、温度読取り値等の受信側センサデータを受信することによって生成される。メディアがどのように生成されたかにかかわらず、メディアは、ＰＩＭＢ書込み部２８（囲み１３０）によってエンコードされ、ＰＩＭＢ書込み部２８は、メディアをインデックスされたメディアペイロードに変換し、クライアント１２１上のＰＩＭＢ３０（囲み１３２）に記憶する。クライアント１２１上のＰＩＭＢ読取り部２６は、ＰＩＭＢ３０からペイロードを読取り、Ｖｏｘパケットを作成し、ネットワーク１８を通じてパケットを受信側クライアント１２２（囲み１３４）に送信する。経路に沿う送信側クライアント１２１と受信側クライアント１２２の間の各サーバ１６は、送信されたペイロードをＰＩＭＢ８５に記憶し、Ｖｏｘパケットを次のホップ（囲み１３３）に送信する。受信側クライアント１２２にて、ＰＩＭＢ書込み部２８のネット受信機能がＶｏｘパケットをインデックスされたメディアペイロード（囲み１３６）に変換し、ペイロードをクライアント１２２（囲み１３８）のＰＩＭＢ３０に記憶する。クライアント１２２上のＰＩＭＢ読取り部２６のレンダリングモジュールは、ＰＩＭＢ３０から読取ったペイロード情報を音声またはビデオ（囲み１４０）等の媒体にレンダリングする。これらのステップについては、図１０Ｂないし１０Ｅを参照してさらに詳しく記述する。
【０１３８】
図８Ｂに、ＰＩＭＢ書込み部２８（図８Ａのステップ１３０）によって実行されるエンコード受信機能のシーケンスを詳しく示す。最初のステップ１３６１にて、クライアント１２１を操作するデバイス１３のユーザが、送信すべきメディアを生成する。上記したように、メディアは、マイクに話す、カメラを使う、センサデータを受信する、その他メディアを生成するためのコンポーネントによって、得ることができる。次のステップ１３０２にて、エンコードレシーバ２８ａはメディアをエンコードし、インデックスされたメディアペイロード（ステップ１３０３）を作成し、メディアはデータ記憶部２８ｃによってＰＩＭＢ３０（ステップ１３２）に記憶される。
【０１３９】
図８Ｃは、送信側のクライアント１２１のＰＩＭＢ読取り部２６によって実行される送信機能のシーケンスを示す（図８Ａ、ステップ１３４）。決定ループ１３４１において、ＰＩＭＢ読取り部２６の送信機能は、送信されるべきインデックスされたメディアペイロードがＰＩＭＢ３０に書き込まれているか、それは送信可能かどうか常にチェックする。もし、使用可能なペイロードがＰＩＭＢ３０にあれば、データ優先順位付与部２６ｆは、ステップ１３４２に示すように、ＭＣＭＳの参加者属性情報を使って、最初に送るべきペイロードに優先順位をつける。最も高い優先順位のペイロードに関する情報は、図９Ａないし９Ｃに詳述するように、ＰＱＭ（ステップ１３４３）を実行するパケット最適化部２６ｇに渡される。次に、データ読取り部２６ｈによって適切なペイロードがＰＩＭＢ３０から取り出され（ステップ１３４４）、パケット部２６ｉによってＶｏｘパケット９５に変換される（ステップ１３４５）。ついで、Ｖｏｘパケット９５は、送信部２６ｊによって、ネットワーク１８を通じて受信クライアント１２２に送信される（ステップ１３４６）。受信クライアント１２２は、受信したパケットの特性（損失、ジッタ、処理量）を反映した受信レポートを返す。これらの受信レポートは、ＰＱＭが所与の受信側のＭＡＢＲを計算するのに必要な情報を提供する。プロセスは、戻り矢印で示すように、送信ループごとに送信ステップからフロー図のトップに繰り返される。
【０１４０】
上記の実施例では、メディアは、一連の流れの中で、エンコードされ、ＰＩＭＢ３０に記憶され、ネットワーク上に送信される。代替的な実施例においては、エンコードされたメディアは、ＰＩＭＢ３０に記憶されネットワーク上を平行に送信される。すなわち、二つの機能はほぼ同時に起こる。
【０１４１】
図８Ｄは、受信側のクライアント１２２ＰＩＭＢ書込み部２８のネット受信機能（図８Ａ、ステップ１３６）のシーケンスを示す。最初のステップ１３６１で、ネットワーク受信部２８ｄがネットワーク１８を通じてＶｏｘパケット９５を受信する。データ記憶部２８ｆはパケットをインデックスされたメディアペイロードに変換し（ステップ１３６３）、ＰＩＭＢ３０に記憶する（ステップ１３６４）。ペイロードが記憶されると、データ品質管理部（ＤＱＭ）２８ｇが実行される。ＤＱＭ２８ｇは、紛失、壊れたりしたパケットがないかチェックし、送信されたデータの正確なコピーが最終的に記憶されることを確実にする。そして、ネットワークの状態に関する受信レポートを送信側に送信する。ＤＱＭ２８ｇのこれらの機能については、図９Ｄ〜９Ｆを参照してさらに詳しく説明する。
【０１４２】
図８Ｅは、受信側クライアント１２２上のＰＩＭＢ読取り部２６（図８Ａ、囲み１４０）のレンダリング機能のシーケンスを示す。最初のステップ１４０１において、データ優先順位付与部２６ａが、ＭＴＳＤ情報、ユーザステータス、プレゼンス情報を含むユーザの意図および注意のステータスを使って、ＭＣＭＳアプリケーション２０によって、レンダリングすると判断されたインデックスされたメディアペイロードに優先順位をつける。優先順位をつけられたペイロードは、データ取出し部２６ｂによってＰＩＭＢ３０（ステップ１４０２）から読取られる。ＰＬＣ／補間部２６ｃは、どちらのコーデックを使うかによって既知のパケット損失補償および補間アルゴリズムを使って、取り出したペイロードにパケット損失補償および補間（ステップ１４０３）を実行する。次のステップで、二人以上の参加者が同じ会話の中で同時にメディアを生成した場合（例えば、両者が同時に話している）は、ミックス部２６ｄは、会話の多数のメッセージをミックスする（ステップ１４０４）。レンダ部２６ｅは、ミックス部２６ｄからのデータストリームをレンダリングし（ステップ １４０５）、受信側ユーザに音、ビデオ、その他のメディアを生成する（ステップ１４０６）。
【０１４３】
図８Ｆは、サーバ１６が、ネットワーク１８上の前のホップからＶｏｘパケットを受信し、記憶し、アーカイブし、Ｖｏｘパケットを次のホップに送信するシーケンスを示す。最初のステップで、サーバ１６は、ＰＩＭＢ書込み部のネット受信機能を実行し（図８Ｄと同様）、受信したデータのインデックスされたメディアペイロードを、サーバ１６のＰＩＭＢ８５とアーカイブ部８９に保存する。また、サーバ１６は、ＰＩＭＢ書込み部の送信機能を実行し（図８Ｃと同様）、ネットワーク１８上の次のホップに受信したパケットを転送する。この方法においては、送信側クライアント１２１によって生成されたメディアのコピーが、受信側クライアント１２２までの経路に沿って各ホップで受信され、記憶され、送信される。
【０１４４】
上記の実施例においては、受信したインデックスされたメディアの書き込みは、サーバ１６のＰＩＭＢ９１に記憶され、次のホップに連続的に送信される。代替的な実施例においては、受信したインデックスされたメディアペイロードが、ＰＩＭＢ９１に記憶し、ほぼ同時に次のホップに送信される。送信側、受信側両者のデバイス１３のＰＩＭＢ３０にメディアを記憶することにより、メディアの漸次送信とレンダリングが可能となる。送信側においては、送信側のデバイスで生成されたメディアは、それが受信されると、漸次ネットワーク上に送信することができる。種々の実施例においては、エンコードされたメディア（どのように生成されたかにかかわらず）は、ＰＩＭＢ３０に記憶される前、後、またはほぼ同時に漸次送信することができる。また、受信側では、入ってくるメディアは、ネットワークを通じて受信されごとに漸次レンダリングすることもでき、ユーザが望めば、ほぼリアルタイムモードでメディアレビューすることができる。種々の実施例においては、入ってくるメディアは、受信側のデバイス１３のＰＩＭＢ３０に記憶されるごとに、記憶される前、後、またはほぼ同時に漸次レンダリングするこができる。受信メディアをタイムシフトモードでレビューするつもりであれば、後でメディアをＰＩＭＢ３０（または、ローカルＰＩＭＢ３０に置き換えられた場合は、サーバ１６上のＰＩＭＢ８５でも可）から取り出し、ユーザが指定する時にレビューすることもできる。
【０１４５】
本アプリケーションの文脈において、「漸次的」または「漸次」という用語は、広く解釈されることを意図し、一般にデータの利用可能性に基づいてデータストリームを継続加工することを意味する。例えば、メディアが作成またはデバイス１３上で生成されるに従い、メディアが入手可能な限り、メディアの漸次的エンコード、記憶、パッケージ化および送信は継続する。人が話すと、その人が話している間、メディアは、漸次的すなわち継続的にエンコードされ、記憶され、パッケージ化され、送信される。その人がポーズすなわち、話すのを止めると漸次プロセスするメディアはない。その人が再び話すことを再開すれば、メディアの漸次的処理は再開する。また、受信側では、メディアが受信されている限り（すなわち、入手可能な限り）、メディアは、漸次処理される。メディアが受信されると、そのメディアは継続的に記憶される。メディアが受信されている限り、ほぼリアルタイムモードの場合は、継続的にレンダリングされ、タイムシフトモードでは、記憶装置から継続的にレンダリングされる。上記説明は音声の文脈で述べたが、全てのタイプのメディアが同様に漸次処理することができる。また、メディアの漸次的加工は、必ずしも時間でインデックスされた順序で漸次処理される必要はない。むしろ、メディアは受信された順序で処理される。もし、メディアがインデックスの順序から外れて受信されたら、一実施例においては、受信されたメディアは受信された順序で漸次処理される。そして、ＰＩＭＢ３０の中で、インデックスされたシーケンスに組織化される。代替的な実施例においては、受信メディアはインデックスされたシーケンスで組織化され、漸次レンダリングされる。
【０１４６】
［Ｈ．２ ＰＱＭの動作フロー図］
ＰＱＭ２６ｇは、継続的に計算される、送信側と受信側のノードのペアの間の実際の送信容量すなわち帯域幅の近似値（すなわち、所定の時点でのネットワークの能力の測定）、すなわち最大可能ビットレート（ＭＡＢＲ）と呼ばれる計量に依存する。瞬時にネットワークの状態が変化するごとに、ＭＡＢＲは更新される。ネットワークの処理量、パケット損失、およびジッタの定期的測定値が、ＭＡＢＲを計算することによって考慮される。また、他の実施例においては、ＭＡＢＲは、時刻、ネットワークのタイプ、その他の条件またはパラメータに基づいて手動でセットまたは制限してもよい。
【０１４７】
また、ＰＱＭは、受信側の意図を考慮し、時間依存型の送信を最適化する。下記のいずれかの場合、送信は時間依存型であるとみなされる。すなわち、（ｉ）受信側の意図が、送信を「ライブ」すなわちほぼリアルタイムモードでレビューしようとしている、または（ｉｉ）受信側が、なんらかの理由で（例えば、メッセージは先にアーカイブ部８９に保存された）、デバイス１３には現在記憶されていないメッセージを即座にレビューしたいと望んでいる。受信側の意図は、受信側の動作によって推論するか、受信側が自分の意図を設定するか別途指定してもよい。一方、受信側の意図がタイムシフトモードでメッセージをレビューすることであれば、送信は時間依存型でないとみなされる。受信側が、ライブモードかタイムシフトモードかどちらかで送信をレビューしようという意図が、少なくとも部分的には、送信の「適時性要件」を定義する。その他の種々の実施例においては、通信の緊急性または優先順位といったファクタも、送信の適時性要件を定義するときに考慮される。
【０１４８】
送信側と受信側のペアの間のネットワーク経路のノードもまた、受信側の意図のステータスに関して一貫性のあることが必要である。もし、一個のターゲット受信側が適時性を指示したら、すなわち、送信を即座にすなわちライブでレビューしたいと望んだ場合、送信側と受信側の経路に沿うネットワーク上の全ての中間ノードは、その他の受信側要件にもかかわらず、同じ適時性要件を持たなければならない。したがって、各中間ノード適時性要件は、送信が送られた受信側ノードに依存する。この依存性は、ネットワーク送信経路におけるターゲットノードのための「要件の融合」と言われる場合もある。
【０１４９】
さらに、ＰＱＭは、予約されたメッセージペイロードの送信のための理想ビットレート（ＩＢＲ）を考慮する。時間依存型の通信のために、ＩＢＲは、ほぼリアルタイムまたはライブ通信に必要とされるパケット化レート（以下、リアルタイムビットレート（ＲＴＢＲ）という）に基づいて計算される。例えば、音声場合、２０ミリ秒の音声データを含む２０ミリ秒毎のパケット化レートは、ライブ会話を行うための許容ＩＢＲが考慮される。キロバイト毎秒のシステムのためのＲＴＢＲは、１秒の音声ペイロードデータに送信するために生成される全てのネットワークヘッダのサイズを加えたサイズとなる。ビデオメディアまたは音声とビデオの組み合わせのためのＲＴＢＲは、単なる音声よりも実質的に高くなる。センサまたはＧＰＳ位置測定データ等のその他のタイプのメディアのためには、音声よりも低くなると思われる。非時間依存型の通信のためには、ＩＢＲは、ネットワークを通じての通信の使用量すなわち効率を最適化するために最大効率ビットレート（ＭＥＢＲ）に設定される。ＭＥＢＲは、パケット化レートを調節することによって、下層のネットワークのために最大可能な値に計算される。送信側と受信側のペアの間で、多数のメッセージまたはペイロードが送られ場合は、統合ＩＢＲ（ＡＩＢＲ）が送信のために考慮される。
【０１５０】
ＰＱＭは、各送信側と受信側ペアのための一連の送信ループのデータを送信することによって動作する。各送信側と受信側ペア用の送信ループは、単独のものである。ネットワーク上のいかなる送信もその他送信側・受信側ペアのＭＡＢＲに影響を与えうる。従って、ＭＡＢＲは、全ての受信側について継続的に計算されることが望ましい。
【０１５１】
図９Ａないし９Ｃは、一組の送信側と受信側ペアのためのＰＱＭの動作シーケンスを示すフロー図である。図９Ａは、一組の送信側と受信側ペア間のＭＡＢＲを決定するステップを示す。図９Ｂは、一個の送信側と受信側ペアの各送信ループのためのＡＩＢＲを計算するステップを示すフロー図である。図９Ｃは、送信側と受信側ペア間で送信するデータのループ当たりの量を決定するシーケンスを示す。三つの図に示す処理は、以下に詳述するように、同時に実行され互いに情報のやりとりをする。
【０１５２】
図９Ａにおいて、フロー図５０は、送信側と受信側ペア間のネットワークインタフェースのためのＭＡＢＲの計算を示す。最初のステップ５０１において、送信側と受信側のペア間のネットワークインタフェースをモニタする。ステップ５０２で、送信側は、受信側におけるネットワーク接続のステータスに関する情報を含むレポートを定期的に受信する。レポートは、受信側によって観測されたネットワークインタフェースでのデータ処理量５０３、パケット損失５０４、およびジッタ５０５の現在のステータスに関する情報を含む。ステップ５０６で、このレポートに含まれるこれらの観測に基づいて送信側でＭＡＢＲが計算される。これらのレポートのデータをモニタすなわち監視することによって、送信側と受信側のペア間の現在のネットワーク性能または状態に基づいてＭＡＢＲ値が継続的に調節される。ネットワーク性能がデータ送信にとってさらに好適になるので、ＭＡＢＲが向上する。もしネットワーク性能が送信にとって好適以下となれば、ＭＡＢＲが低下し、潜在的に結果としてゼロとなり使用不能なネットワークとなる。このレポートは、ＴＰＣネットワークのノードによって生成されるパケット損失レポートと同様のものであるが、さらに処理量情報とジッタ情報を含む。
【０１５３】
送信側と受信側のペア間に複数のネットワークインタフェースがある場合は、ＭＡＢＲは、受信レポートが受信されるインタフェース毎に計算される。直近にネットワーク上にトラフィックが送られていない場合、または、受信レポートが受信されていない場合は、ＭＡＢＲには現在のネットワークの状態が反映されないことがある。しかしながら、データが送信されているかぎり、受信側によって受信レポートが継続的に生成されるので、送信側のＭＡＢＲ計量はさらに正確な値に速やかに収束する。
【０１５４】
図９Ｂは送信ループのためのＡＩＢＲを計算するステップを示すフロー図５２である。最初のステップ５２１において、メディアを有するメッセージ（メッセージに所属する時間でインデックスされたメディアの部分）が現在のループの送信側と受信側のペア間で送信される準備ができていることが確認される。つぎに、メディアを有するメッセージのリストが、作られる（５２２）。リスト５２３の各メッセージについて、各メッセージの時間的制約すなわち適時性要件が考慮される（５２４）。もし、個々のメッセージに時間的制約がなければ、ＩＢＲは最大効率ビットレート（ＭＥＢＲ）にセットされる（５２５）。一方、メッセージに時間的制約があるばあいは、リアルタイムビットレート（ＲＴＢＲ）にセットされる（５２６）。次のステップ５２７において、リストのメッセージ毎に先に計算されたＩＢＲは、合計されて、送信ループのための統合理想ビットレート（ＡＩＢＲ）５２８となる。戻り矢印５２９にて示すように、上記のプロセスは、送信ループ毎に送信側と受信側のペア間で繰り返される。
【０１５５】
図９Ｃにおいて、フロー図５４は、送信ループ毎に送信側と受信側のペア間で送信するデータのレートを決定するシーケンスを示す。最初のステップ５４１において、ＭＡＢＲ（図９Ａで計算された）は、次の送信のためにＡＩＢＲ（図９Ｂで判断された）と比較される。
【０１５６】
ＭＡＢＲがＡＩＢＲ以下であれば、ループ内の送信の準備ができていると識別されている全てのメッセージが、ＩＢＲレートでパケット化され（５４２）、送信される（５４３）。
【０１５７】
一方、ＭＡＢＲがＡＩＢＲ未満のときは、一連の手順が適用されて、ＰＱＭが以下の目標が満足されるように調節される。すなわち、データの適切なコピーをタイムリーに送達すること、利用可能な帯域幅を有効に使うこと、および／またはペイロードコンテンツおよび現在のネットワーク条件を満足する品質、パケットサイズおよび送信レート。
【０１５８】
最初のステップにおいて、リストのメッセージは、タイム時間的制約がないかレビューされる（５４４）。時間的制約のあるメッセージがなければ、ビットレートは、ＭＡＢＲまで引き下げられて（５４５）、メッセージが送信される（５４３）。
【０１５９】
リストに時間的制約のあるメッセージが含まれる場合は、時間的制約のないメッセージに割り当てられたビットレートは、ＭＡＢＲの制限が満足されるまで引き下げられる（５４６）。ビットレートをゼロになるまで引き下げても、ＭＡＢＲを満足しないときは、これらの時間的制約のないメッセージは、ループに送信されるメッセージのリストから除去される。ビットレートがＭＡＢＲ以下になるまで引き下げられ、残ったメッセージはパケット化され、送信される（５４３）。
【０１６０】
時間的制約のないメッセージを取り除いてもＭＡＢＲを満足しない場合は、残る時間的制約のあるメッセージのために１ないし複数個の低い品質のコーデックの使用を含む別の手順５４７を使う。この送信ループの間により少ないビット送信することによって、できるだけ早くペイロードデータの送信しようとする試みがなされる。言い換えれば、ペイロードの品質を引き下げることによって、送信は所定の時間内により少ないビット送信することになる。種々の実施例において、それぞれ異なるビットレート対品質のトレードオフをもつ異なる１ないし複数個のコーデックを使うこともできる。低い品質の１ないし複数個のコーデックを使って間に合う場合、すなわち、ＭＡＢＲの制限が満たされれば、メッセージは送信される（５４３）。
【０１６１】
低い品質のコーデックを使用しても、ＭＡＢＲがまだ満足されない場合は、時間的制約のあるメッセージのパケット化の間隔を増やす（５４８）。この手順によりヘッダ対ペイロードの比率が上げられ、これにより全体のビットレートが下げられるが、待ち時間（すなわち、受信側への送信の送達遅延）が導入される。この手順によってＡＩＢＲがＭＡＢＲ以下になれば、送信５４３がはじまる。
【０１６２】
もし、パケット化の間隔変更後も、まだＭＡＢＲが満たされない場合は、ビットレートがＭＡＢＲ制限内になるまで漸次引き下げられる（５４９）。この方法でビットレートが引き下げられると、時間的制約のあるメッセージは、ライブ会話の維持ができないレートで送られる。したがって、会話は、「ライブ」から強制的にはずされてしまう。ネットワークがダウンまたは非常に悪い状態のときはデータの送信が始まらない場合もある。再度、上記のシーケンスが送信側と受信側のペア間で送信ループ５４１０毎に繰り返される。
【０１６３】
送信側と受信側のペア間に、多数のネットワークインタフェースがある場合は、図９Ｃを参照して記述したシーケンスが、受信レポートが可能なインタフェース毎に実行される。種々の実施例において、送信側は、多数のインタフェースの中を、送信ロードを送達するためのロジックを含むことができる。別の例においては、ペイロードは、一個のインタフェースにのみ送ることができ、別の実施例においては、幾つかの又は全てのインタフェースを使うことができる。
【０１６４】
上記の説明は、システム１０の送信側と受信側ペアの全てに当てはまる。ほとんどの状況において、送信側と受信側ペアには、クライアント１２、可動デバイス１３およびサーバ１６、二個のサーバ１６、デバイス１３を可動する一個のサーバ１６とクライアント１２または二個のクライアント１２がそれぞれ含まれる。送信側のノードが２つ以上の受信側ノードに同時に送信している場合は、図９Ａないし９Ｃを参照して説明した上記のシーケンスが受信側と送信側ペア毎に一斉に起こる。
【０１６５】
［Ｈ．３ ＤＱＭ動作フロー図］
ＤＱＭ２８ｇは、クライアント１２で受信したデータが壊れているまたはパケットが失われていないか判断する。さらに、受信側クライアント１２のＤＱＭ２８ｇは、受信レポートを生成し、ネットワーク上の送信側ノードに送り返す。また、ＤＱＭ２８ｇは、バックグラウンドの処理を行い、送信されるデータの正確なコピーが最終的に受信され記憶されることを確実にする。これらの機能について、図９Ｄないし９Ｆを参照して説明する。
【０１６６】
図９Ｄは、紛失データおよび／または壊れたデータがないかチェックするＤＱＭ２８ｇの動作を示すフロー図である。最初のステップ５６１にて、ＤＱＭ２８ｇは、ＣＲＣあるいは同様の完全性デェック機構等の既知の技術を使って、壊れたパケットがないかデェックする。もしパケットが壊れていると、紛失したものとみなされる（５６２）。次に、ＤＱＭ２８ｇは、紛失パケットがないか確かめる（５６３）。もし、予め決められた時間が過ぎてもシーケンスのずれたパケットが受信されなければ、それは紛失したものとみなされる。ＤＱＭ２８ｇは、紛失あるいは壊れたパケットをＤＮＱＳ３２にメモする（５６４）。一方、紛失あるいは壊れたパケットが検出されなかった場合、ＤＱＭ２８ｇは、帯域幅をセーブするために、送信側が意図的に受信したデータの品質をひき下げたのかどうか判断する（５６５）。引き下げられた品質は、ＤＮＱＳ３２にメモされる（５６６）。受信したデータの品質が引き下げられたかどうかにかかわらず、データの受信情報（例えば、パケットのシーケンス番号、タイムスタンプ、およびそのパケットが送られるネットワークの次のノードのネットワークアドレス）が、ＤＮＱＳ３２に記憶される（５６７）。上記のプロセスは、フロー図の戻り矢印で示されるように最初から継続的に繰り返される。
【０１６７】
図９Ｄに詳細に示すプロセスの結果、質が引き下げられていないパケットの受信、品質が引き下げられたパケットの欠陥および紛失パケットに関する情報は、全てＤＮＱＳ３２に記憶される。メディアを受信すると、ＤＮＱＳ３２は、メディアのステータスに関する最新情報を維持する。
【０１６８】
図９Ｅは、ＤＱＭ２８ｇの受信レポート生成機能の動作を示すフロー図である。最初のステップにて、ＤＮＱＳ３２は定期的にスキャンされ（５８１）、受信レポートを生成する必要があるメディアかどうか判断される（５８２）。ＮＯの回答の場合、上記のスキャンプロセスが繰り返される。一方、メディアが識別された場合は、プロセスにおいて、そのメディアが、時間的制約があるかどうか、すなわち、ユーザはメディアをライブでレビューしようとしているのか、それともデバイス１３に記憶する必要のない、メディアを即座にレビューしようとしているのか、判断する（５８３）。
【０１６９】
時間的制約がない場合は、受信側は、送信側に再送優先順位を（以下に定義する如く）低にセットするよう通知する（５８４）。時間的制約がある場合は、パケット損失の量が考慮される（５８５）。パケット損失の量が使用可能な品質の範囲を超えていれば、再送優先順位は、高にセットされる（５８６）。上記のようにパケット損失の量が大きすぎる場合は、受信側は、受信と同時にそのメディアをレビューすることはできない。品質が許容範囲内であれば、すなわち、レンダリングしたときに理解可能であれば、受信レポート送信の優先順位が低にセットされる（５８４）。受信側が、受信と同時にレビューしているかどうかにかかわらず、受信レポートが送られ（５８７）、ＤＮＱＳ３２が更新され（５８８）、ネットワーク品質管理部（ＮＱＭ）２８ｈが更新される（５８９）。したがって、ステップ５８４で定義される再送要求は、時間的制約に基づく条件である。ステップ５８６で定義される送信要求は、時間的制約と品質の両方に基づく条件である。
【０１７０】
再送優先順位は、送信側のＰＱＭ２６ｇに、再送が必要なメディアの送信レートに正しく優先順位をつけるように通知する。例えば、再送優先順位が高にセットされると、送信側ＰＱＭ２６ｇは、どの新しいメディアよりも先に再送しなければならない。優先順位が低の場合は、ＰＱＭ２６ｇは、新しいメディアの後に再送信メディアを送信しなければならない。
【０１７１】
上記プロセスは、メディアが受信される毎に受信レポートが生成されるように、継続的に繰り返される。もし、送信側がタイムリーに受信レポートを受信しない場合、送信側のＰＱＭ２６ｇは、送信レートを引き下げ、受信レポートが受信されない場合は、最終的には送信を停止する。
【０１７２】
図９Ｆは、紛失または品質を引き下げられたメディアを要求するシーケンスを示すフロー図である。最初のステップ６０１にて、ＤＮＱＳ３２は紛失メディアまたは品質を引き下げられたメディアがないか、定期的にスキャンされる（６０２）。紛失メディアも品質を引き下げられたメディアもない場合は、上に定義したスキャンが定期的に繰り返される。
【０１７３】
予め決められた閾値の時間が経過しても、シーケンス外のパケットが着信しない場合は、メディアは紛失したものとみなされる（６０３）。パケットが閾値の前に着信すれば、紛失とはみなされない。一方、パケットが閾値を越えても着信しない場合は、そのパケットは紛失したとみなされる。紛失パケットについて、再送を要求する低優先順位が作られ（６０４）、要求の時間がＤＮＱＳ３２にメモされる（６０５）。このプロセスは、紛失パケットが受信されるまで繰り返される。紛失パケットが着信し、ＰＩＭＢ３０の中に対応するメディアがある場合は、紛失メディアのステータスはＤＮＱＳ３２から除去される。したがって、ステップ６０４で定義される再送信要求は、メディアが紛失したかどうかの判断に基づく条件である。
【０１７４】
もし、品質を引き下げられたメディアであれば、ＤＱＭ３２は、そのメディアがライブの会話の一部かどうか判断する（６０６）。品質を引き下げられたメディアでない場合は、品質を引き下げられたメディアの完全な品質のコピーを求める要求が作られ（６０７）、完全な品質のメディアが紛失したと認定され（６０８）、要求した時間がＤＮＱＳ３２にメモされる（６０９）。そのメディアがライブの会話の一部分である場合は、ネットワーク回線容量を残すために、即座には動作はおこなわれない。会話がライブモードから遷移する場合は、６０７ないし６０９のステップが実行され、最終的には品質を引き下げられたメディアの完全な品質のコピー（正確なすなわち完全な）が確実に受信される。受信側クライアント１２のＰＩＭＢ３０にデータが入手可能になると、関係するメディアの品質引き下げのステータスはＤＱＮＳ３２から取り除かれる。ステップ６０７で定義される送信要求は、品質の引き下げとライブ会話の一部でないことの二つに依存する条件である。
【０１７５】
上記のプロセスは、戻り矢印で示すように、フロー図の６０５および６０９からトップの６０１へ、継続的に繰り返される。図９Ｆに示すプロセスを繰り返すことによって、送信される全てのメディアの完全なコピーが、最終的に受信側デバイス１３のＰＩＭＢ３０に記憶される。このように、送信されるメディアの完全なコピーの記憶が受信側デバイス１３で保証される。
【０１７６】
［Ｉ．グラフィカルユーザインタフェース］
図１０は、クライアントアプリケーション１２を実行するデバイス１３の例を示す。デバイス１３は、グラフィカルユーザインタフェースディスプレイ１１０、データ入力ボタン、キー、すなわちキーボード１１２、マイク１１４、および電気信号を音に変換するスピーカー等のトランスデューサー１１６を含む。また、ディスプレイ１１０はタッチスクリーンとして入力を受け付ける。さらに、ディスプレイ１１０とキーボード１１２は、タッチスクリーンインタフェースを用いて連結することもできる。上記のように、デバイス１３は、下記のようないろいろな異なる通信ツールであってもよい。例えば、デスクトップコンピュータ、ラップトップまたはその他のモバイルコンピュータ、パーソナル・デジタル・アシスタンス、プログラマブルの固定またはセルラーホン、プログラマブルラジオ、その他どのようなタイプであれ、プログラマブル通信装置など。図に示すデバイス１３の例は、上に挙げた全ての通信デバイスを代表し、あるいは含む意味で、「一般的」例である。さらに、用語「グラフィカル」ユーザインタフェースは、限定的意味に解釈されるべきではない。デバイス１３上で実現することのできるその他のタイプのユーザインタフェース、以下に説明する多様な機能を実行するために使うことのできる全て、すなわち音声／ＤＴＭＦインタフェース、音声ユーザインタフェース（ＶＵＩ）、無線切り替えインタフェース、あるいはその組み合わせを含む。単純に説明するために、ユーザが情報のやりとりするためのデバイス１３のさまざまなタイプの方法を、一般に「ユーザインタフェース」と称する。
【０１７７】
全てのデバイス１３が、そのタイプにかかわらず、ユーザがシステム１０の中でデバイス１３を操作し、他のユーザのデバイス通信することができるユーザインタフェースを有することが好ましい。ユーザインタフェースは、実質的に限りなく異なる表装、感触をもつように設計されてもよいが、全てのデバイス１３が共通に備えるべき幾つかの機能がある。これらの機能を以下列挙する。
【０１７８】
ユーザインタフェースは、次のようなステータス標識すなわちフラッグを一またはそれ以上含むことが好ましい。すなわち、（ｉ）バッテリ標識、（ｉｉ）接続標識、（ｉｉｉ）時計、（ｉｖ）送信ステータス、（ｖ）通信同期ステータス、（ｖｉ）レビューステータス、（ｖｉｉ）優先順位メッセージを求める注意および（ｖｉｉｉ）失敗メッセージなど。
【０１７９】
ユーザインタフェースは、一個の会話を行い、管理するための次のような機能、フラッグおよびコンポーネントを含むことが望ましい。すなわち、（ｉ）会話の名前および／または参加者のリスト、（ｉｉ）会話のステータス、（ｉｉｉ）会話のタイプ、（ｉｖ）会話の継続時間、（ｖ）会話の頭からの時間、（ｖｉ）人目に付くメッセージ、（ｖｉｉ）参加者のプレゼンス／ステータス、（ｖｉｉｉ）ナビゲーション付きメタデータ、（ｉｉｘ）会話の属性または指示子、（ｉｘ）タイトル、スケジューリング、参加者、会話サマリーを含み、会話のセットアップ、（ｖ）どの参加者がメッセージを投稿したか、だれがメッセージを聞いたか、見たかを示す標識。
【０１８０】
ユーザインタフェースは、また、上に列挙した機能に加え、マルチ会話を行い、管理するための次のような 機能、フラッグおよびコンポーネント含むことが好ましい。すなわち、（ｉ）会話毎の名前／識別子、（ｉｉ）ライブ／アクティブまたはスタンディング／インアクティブ標識、（ｉｉｉ）レビュー位置、頭／タイムシフト、（ｉｖ）優先順位とその他の属性、（ｖ）会話の部分が紛失したかを示す標識。
【０１８１】
ユーザインタフェースは、好ましくは以下の多数のナビゲーション機能を含む。すなわち、（ｉ）会話毎のＤＶＲスタイル早戻し／早送り（ｉｉ）インスタントメッセージングスタイルの個人メッセージナビゲーション（ｉｉｉ）会話時間標識（ｉｖ）タイムスケールシフティング（すなわち、会話のメッセージを通じての後方ズーミングと転送）、（ｖ）会話の優先順位の変更、（ｖｉ）ハングアップおよび（ｖｉｉ）ホームなど。
【０１８２】
前記機能は、いろいろな方法、例えば、タッチスクリーングラフィカルユーザインタフェース１１０またはデータ入力ボタン、キーすなわちキーボード１１２、マウス、音声入力コマンドもしくはその組み合わせ等のその他入力デバイスを使って実現することができる。上記の機能および実現する方法は、全てを網羅的するものではない。使用可能な様々な方法と技術は広範囲にわたるので、その全てをここにリストし議論することは実際的ではない。
【０１８３】
［Ｊ．会話］
ＭＣＭＳアプリケーション２０は、以下のようないろいろな異なるタイプの会話をサポートする。ほぼリアルタイムな、あるいは「ライブ」コール、すなわち、参加者が話したときからまたは第一の参加者の声を聞いた時からの遅延が非常に小さい会話；参加者が交換する音声メッセージで、メッセージ間の遅延が長い会話、多数のユーザが参加する「ライブ」会議通話；定期的に予約した時間に行われるスタンディング会議通話；同時ブリーフィングのような、設定可能な構造化されたコールタイプで、前もってレビューできるように、参加者がそれぞれ予め他者にブリーフィングメッセージを残し、ライブ会議通話に参加する会話。さらに、ＭＣＭＳアプリケーション２０の固有の属性として、異なるタイプの会話の間をユーザが遷移できる。例えば、参加者は音声メッセージモードからライブ通話モードへ切目なく遷移したりまた戻ったりできる。あるいは、ライブ会議通話の参加者が音声メッセージモードに遷移し、会議コールの後に互いに更新事項または行動事項を送信しあう。いくつかの例を説明したが、システム１０は極めてフレキシブルであり、異なるタイプの通話ないし会話間およびマルチ会話間の遷移方法の多くの選択肢を提供できることを理解されたい。メッセージ間の遅延を変えることによって、参加者は自分の要求に最も適した会話のタイプの間を効果的に流れることができる。したがって、上記の例は限定的に解釈されるべきではない。
【０１８４】
上記のように、本来の文脈とシーケンスが維持されたメッセージによって会話が構成されている。送ったメッセージは、現存今ある会話に所属するか、新しい会話をはじめるかどちらかである。典型的な会話は、定義された主題、トピック、時間、グループまたはチャンネルの回りに組織された一組のメッセージを含む。例えば、会話は、人の共通のグループ、たとえばクラブのメンバー同士、会社では各週の販売会議のような定時のスタンディング会話、友達同士であれば、ディナープラン作り等のさまざまなトピックでその場その場の会話などが考えられる。
【０１８５】
それぞれの会話は、名前、参加者のリスト、開始と終了時間、少なくともペンディング、アクティブまたは終了を含む状態を含む一組の属性によって定義される。その他の実施例ではその他の会話状態もありうる。ユーザは各自のデバイス１３上のＭＣＭＳアプリケーション２０を使ってやり取りをする。好適な実施例では、このインタフェースにより、ユーザは様々な属性を使って会話を組織することができるようになる。
【０１８６】
参加者と会話の間の関係にも属性がある。これらの属性には、優先順位、ステータス（会話における参加の状態）などがあるがそれに限定されない。参加者のステータスの値には、アクティブ、一時にひとつの会話以上に参加、タイムシフトモードで会話をレビュー、ライブにキャッチアップ、受動的に参加（すなわち、アクティブにレビューしていないが、高い優先順位のメッセージを受信中）、スタンバイ、もしくは会話を無視（すなわち、会話に参加、記録することに減退）、などがある。
【０１８７】
受信側の視点から、ユーザがメッセージの相対的優先順位を選択または定義することもできる。例えば、ある人のボスからのメッセージは、世間の知人よりも一般に高い優先順位があたえられる。幾つかの実施例においては、ある受信者は自分自身の優先順位を設定することができる。ＭＣＭＳ−Ｃの実施例として、ユーザは、会話を連続してレンダリングできるようにその会話をサブセットすることも選択できる。この場合ユーザは、これらの会話に優先順位をセットする。システムは、このユーザセットした優先順位を使い、レンダリングすべきメッセージに順序をつける。上記のアルゴリズムによって、ユーザによる優先順位およびメッセージデータに関して入手できる情報（ＭＴＳＤを超えて）を使って、レンダリングすべきメッセージを並べかえる。
【０１８８】
戦術的通信のようなその他の実施例では、受信側は優先順位を設定できないか制限される。例えば、消防士は、消防隊長からのメッセージの優先順位を下げることはできない。しかし、送信側のユーザは、緊急メッセージまたは高い重要度のメッセージを送信することができる。メッセージに緊急のタグを付けることによって、受信側の全ての優先順位の設定を無視して、メッセージは受信側で即座にレンダリングされる。多数の緊急メッセージ同士での衝突は、予め決められた優先順位スキームに基づいて解決される。
【０１８９】
［Ｋ．ＭＣＭＳ動作］
図１１Ａは、ＭＣＭＳアプリケーション２０のおもな機能を示す組織図１１００である。主な機能には、アカウント管理１１０２、会話管理１１０４、集合会話リスト管理１１０６、会話参加１１０８、通話管理１１１０、およびコンタクト管理１１１２がある。システム１０に登録しログインした後、ユーザは、以下に詳細に説明する、さまざまな管理機能を実装するデバイス１３のユーザインタフェースを通じて、ナビゲートすることができる。幾つかの実施例では、これらの機能が、大きな自由度を提供する。戦術的な無線または通信無線のような他の実施例では、ユーザインタフェースの実装は、多数のユーザ機能およびデバイスの実用性満を足するために予め設定されたオプションにより拘束を受ける場合もある。ここでの説明は、例示的に挙げるものであって、ＭＣＭＳの機能の包括的な説明を意図したものではなく、ＭＣＭＳの属性の幾つかの概観を提供することを意図したものである。
【０１９０】
［Ｋ．１ アカウント管理］
アカウント管理機能１１０２のもとで、登録ユーザは、一定の設定と好みを変更することができる。ユーザは、自分のＥメールアドレス、パスワード、名前、電話番号、電話パスワード、着呼番号、デフォルトおよび／またはユーザ定義レンダリング速度、タグ、メッセージをレビューするためのゲインまたはボリュームのレベル、ライブモードへキャッチアップなどを変更することができる。これらの変更を行うには、ユーザは、自分のデバイス１３のインタフェース１１０から適切な情報に入る。ＭＣＭＳアプリケーション２０は、ＭＣＭＳデータベース２２に好みの更新を文字書き込みで回答する。
【０１９１】
［Ｋ．２ 会話管理］
図１１Ｂに示すように、会話管理１１０４はユーザが、自分の会話の集合リストを見ること、新しい会話を開設すること、会話の細部を更新すること、会話を削除すること、会話を閉じること、ができるようにする一組の機能である。これらの機能のそれぞれについて以下に説明する。
【０１９２】
会話を見る１１０４ａ−会話毎に、ＭＣＭＳアプリケーション２０は、ユーザに以下の一またはそれ以上の属性を提供することができる：会話の名称、実際の開始時間、最新の活動、タグ、期間および参加者のリスト。各参加者には、名前および／または電話番号、ステータス（ライブ通話、その他のコール、過去、キャッチアップモード、オフライン可、オフライン−使用不能）。
【０１９３】
会話の開設１１０４ｂ−ユーザは、インタフェース１１０を通じて、会話名、コンタクトのリストおよびオプションとして予約した開始時間を入力して会話を開設する。開始時間に指定がなければ、開始時間は即座とみなされる。応答として、ＭＣＭＳアプリケーション２０は、コンタクトリスト上の各参加者の記録関連づけながら、データベース２２の中に新しい会話を開設する。また、ＭＣＭＳアプリケーション２０は、データベース２２の中にコンタクトリスト上のユーザ毎の参加者記録を作成し、呼出し側に、コンタクトリスト上に他者の情報が存在することを受信できるようにする。会話が予約されている場合は、ＭＣＭＳアプリケーション２０は、指定された時間に会話を開始する。そうでない場合は、会話は即座に開始する。
【０１９４】
会話細部の更新１１０４ｃ−ユーザは、ユーザインタフェース１１０を通じて会話に変更を加えることができる。例えば、参加者が加えられたり除去されたりできる。参加者のステータスに変更があれば、ＭＣＭＳデータベース２２の中で更新される。
【０１９５】
会話の削除１１０４ｄ−ユーザは、インタフェース１１０を通じて自分の会話リストから特定の会話を削除することができる。これに応じて、ＭＣＭＳアプリケーション２０は、データベース２２に当該変更を書き込み、会話の削除を指示する。
【０１９６】
会話の終了１１０４ｅ−ユーザは会話の終了を選択することができる。一実施例においては、会話を開設したユーザのみがその会話の終了を選択することができる。
【０１９７】
［Ｋ．３ 集合会話リストの管理］
図１１Ｃに示すように、集合会話リスト管理１１０６は、ユーザにマルチ会話（すなわち、ユーザの集合会話リスト）に参加することを可能にする一組の機能である。集合会話リスト管理機能により、ユーザは、自分のデバイス上のインタフェース１１０を通じて、一方で、タイムシフトモードで別の会話に参加しながら、会話「ライブ」に参加することができる。
【０１９８】
会話の終了１１０６ａ−インタフェース１１０を通じて、ユーザはユーザの集合会話リストの中から一個の会話を選択することができる。現在の会話メッセージは、「ライブ」またはタイムシフトモードでレンダリングすることができる。ユーザは、時々集合会話リストの中の現在の会話を切り替えることができる。
【０１９９】
会話モードの切り替え１１０６ｂ−オプションの実施例において、ユーザは、動作のモードをＭＣＭＳ、ＭＣＭＳ−ＣおよびＭＣＭＳ−Ｓ間で切り替えることができる。
【０２００】
［Ｋ．４ 会話への参加］
図１１Ｄに示すように、会話参加１１０８は、ユーザに会話の開始、会話への参加通知の受信、会話のステータス情報の取得、および会話の終了を可能にする一組の機能である。
【０２０１】
会話の開始１１０８ａ−会話が開かれると、インタフェース１１０を通じてユーザによって、またはＭＣＭＳアプリケーションの中のスケジューラによって各参加者のステータスがチェックされる。もし、誰か参加者がオフラインであると、その人にコンタクトしようとする。もし、誰か参加者がオンラインになってはいるが別の会話に参加している場合は、ＭＣＭＳアプリケーション２０はその参加者に通知する。全てのオンライン参加者のプレゼンスステータスは、データベース２２のなかで更新される。
【０２０２】
受信の通知１１０８ｂ−システムはユーザインタフェース１１０を介してグラフィック表示および／または音響で通知を行い、注意を会話向けることが求められていることをユーザに通知することができる。
【０２０３】
会話ステータス１１０８ｃ−ユーザはデバイス１３のインタフェース１１０を通じて、会話のステータス要求することができる。これに応えて、ＭＣＭＳアプリケーション２０は、データベース２２に記憶されているステータス情報を集め、その情報をユーザに提供する。
【０２０４】
会話のポーズ１１０８ｄ−ユーザインタフェース１１０を通じて、ユーザは、アクティブ会話を終了するか、そこから切り換えて出ることもできる。これに応えて、ＭＣＭＳアプリケーション２０は、データベース２２の中のアクティブ会話のためのユーザの参加者ステータスを更新し、記憶・ストリームモジュール２４にその会話からそのユーザを取り除くよう指示する。
【０２０５】
［Ｋ．５ 会話のコントロール］
図１１Ｅに示すように、会話コントロール１１１０は、ユーザに会話への参加をコントロールかのうにする一組の機能である。これらの機能は、会話のメッセージをレビューするときにユーザに、ライブにキャッチアップ、頭にスキップする、過去のロケーションにジャンプする、ポーズ、早く再生および遅く再生することを可能にする。これらの各機能は、デバイス１３上のインタフェース１１０を通じてユーザによって開始される。
【０２０６】
ライブにキャッチアップ１１１０ａ−ユーザは、「ＣＴＬ」機能を使って進行中のライブ会話にキャッチアップすることができる。この機能が起動されると、ＭＣＭＳアプリケーション２０が、ユーザがレビューした会話の最後のポイントをデェックし、記憶・ストリームモジュール２４に先に聞かれなかったメッセージをユーザが指定するオプションの通常のレンダリングよりも早く再生レンダリングするよう指示する。会話の頭に達したら、ライブモードに途切れ目なく遷移する。
【０２０７】
ヘッドにジャンプ１１１０ｃ−この機能は、ユーザに、会話におけるユーザの現在のポイントと会話の頭間の途中にあるメッセージをスキップし会話の頭へジャンプすることを可能とする。実行されると、ＭＣＭＳアプリケーション２０が、記憶・ストリームモジュールに会話の頭のメッセージを即座にレンダリングするよう指示する（もし、会話の頭が現在のライブ通話であれば、これをライブにジャンプする（ＪＴＬ）という）。
【０２０８】
過去にジャンプする１１１０ｄ−この機能は、ユーザが巻き戻しすなわちリプレイ機能と同様、会話の先行するメッセージまたはポイントにジャンプして戻るのを可能とする。実行されると、ＭＣＭＳアプリケーション２０が記憶・ストリームモジュール２４に、巻き戻しポイントからメディアのレンダリングを開始するよう指示する。
【０２０９】
ポーズ１１１０ｅ−この機能は、ユーザに会話のメッセージのレビューをポーズすることを可能とする。応答として、記憶・ストリームモジュール２４は、別の命令が出されるまでメッセージのレンダリングを停止する。
【０２１０】
早く実行１１１０ｆ−この機能は、ユーザにもっと速くメッセージをレンダリングすることを可能とする。応答として、記憶・ストリームモジュール２４は、通常の速さよりも速くメッセージをレンダリングする。レンダリングの速さは、ユーザが指定するか、初期設定の多数のオプションの中から選択することもできる。
【０２１１】
遅く再生１１１０ｇ−この機能は、ユーザにメッセージをもっとゆっくりレンダリングすることを可能とする。応答として、記憶・ストリームモジュール２４は、通常の速さよりも遅くメッセージをレンダリングする。レンダリングの速さは、ユーザが指定するか、初期設定の多数のオプションの中から選択することもできる。
【０２１２】
［Ｋ．６ コンタクトの管理］
図１１Ｆに示すように、システム１０は、コンタクトリストとユーザグループを管理するためのホスト機能をユーザに提供する。これらの機能には、コンタクトとユーザグループを加える、編集する、削除する、がある。これらの各機能は、デバイス１３のインタフェースを通じて、ユーザによって実現される。ユーザのコンタクトリストまたはグループリストの変更、削除はすべてＭＣＭＳデータベース２２に記憶される。
【０２１３】
コンタクトを加える１１１２ａ−この機能は、ユーザにコンタクトリストに新しいコンタクトを加えることを可能とする。新しいコンタクトは、ユーザか外部のコンタクトに登録される。主に名前、電話番号、番号のタイプ（電話、オフィス、ホーム、コンピュータなど）、Ｅメールアドレス、その他個人情報などがコンタクト記録のために提供される。
【０２１４】
コンタクトの編集１１１２ｂ−この機能は、ユーザに現在のコンタクト記録を編集または更新することを可能とする。
【０２１５】
コンタクトの編集１１１２ｃ−この機能は、ユーザに現在のコンタクト記録を除去または削除することを可能とする。
【０２１６】
コンタクトを検索１１１２ｄ−この機能は、ユーザにコンタクトリストの中の特定のコンタクトを検索することを可能とする。検索は、名前、電話番号、直近にコールした、最も頻繁にコールした、グループなど多くの基準を使って行うことができる。
【０２１７】
参加者リスト入手１１１２ｅ−この機能は、ユーザに、例えば、名前、直近にかけた電話、直近にきた電話、最も頻繁にかけた電話など多くの異なる検索基準を使って、会話の参加者リストを検索、取り出しを可能とする。
【０２１８】
呼出し側にステータスの閲覧を許可１１１２ｆ−この機能は、第一のユーザに、他のユーザに第一のユーザのステータスを閲覧することを許可することを可能とする。権限のないユーザは、第一のユーザのステータスを閲覧することはできない。
【０２１９】
コンタクトのグループを作成１１１２ｇ−この機能は、ユーザに多数のコンタクトを一のグループに関連付けることを可能とする。ユーザがグループを定義すると、そのグループのコンタクトリストはＭＣＭＳデータベース２２に記憶される。
【０２２０】
コンタクトグループを編集する１１１２ｈ−この機能は、ユーザに、グループを編集またはグループのメンバーのためのコンタクト情報を更新することを可能とする。
【０２２１】
コンタクトグループを削除する１１１２ｉ−この機能は、ユーザにグループを削除することを可能とする。
【０２２２】
［Ｌ．ＭＣＭＳの動作］
［Ｌ．１ ＭＣＭＳ−Ｃ］
上記したように、ＭＣＭＳ−Ｃの動作は、ＭＣＭＳと同様に、システムによって自動的に管理される優先順位とメッセージのタイムシフトの階層的なシステムによって、付加的機能によってユーザにマルチ会話に連続して管理し、参加することを可能にする。ＭＣＭＳ−Ｃ機能の実行には、３個の基本的プロセスがある。図１２Ａに示すように、第一のプロセスは、連続的なレンダリングのための一組の会話を定義することである。一旦リストが定義されると、優先順位およびその他ファクタの階層的なセットがその会話のセットと関連するインデックスされたメディアペイロードに適用される。つぎに、インデックスされたメディアペイロードは、順序付けされた順序で配列される。配列された順序でメディアをレンダリングすることによって、会話のセットのメッセージが連続してレンダリングされる。
【０２２３】
図１２Ａは、連続してレンダリングする会話のリストを定義するステップを示すフロー図である。最初のステップ１２０２において、ユーザの会話の集合リストが定義される。次に、ユーザか、または予め設定されたデータ（ステップ１２０４）を使って、連続的なレンダリングを行うための統合リストの中から会話を選択する（ステップ１２０６）。例えば、戦術的な通信システムでは、主として予め設定したデータを使い会話を連続してレンダリングする。非戦術的なアプリケーションでは、ユーザは、継続的にレンダリングする会話を選択する上で、一定の高い自由度が与えられる。
【０２２４】
図１２Ｂは、継続する会話のメッセージをレンダリングする優先順位の階層的なセットを定義するステップを示すフロー図である。最初のステップ（１２０８）で、一組の優先順位のルールが定義され、連続してレンダリングされる会話のリストに適用される（１２０６）。種々の実施例においては、一組の優先順位のルールは、堅固な階層的な通信プロトコルから高い柔軟性をもつ通信プロトコルまであっても良い。例えば、しばしば堅固な階層性が望まれる戦術的な通信システムにおいては、現時点のメッセージがレンダリングされている順序が、優先順位のルールのセットとして与えられることが望ましい。例えば、戦術的なシステムにおいて、消防隊長からのメッセージの第一応答者に最も高い優先順位を与えることができる。次のレベルの優先順位は、燃え盛るビルの内部にいる消防士に与えることができる。次のレベルに、ビルの外側にいる消防士に優先順位を与えることができる。火災との戦いを監督している人の現在のメッセージに堅固な優先順位を定義することにより、重大性が少ない役割についている人に先立って、危険な場所にいる人にレンダリングすることができる。非戦術的通信では、個人的な必要を満たす独自の優先順位スキームを定義するうえでユーザは大きな自由度があたえられてもよい。例えば、営業部長は、最も重要なクライアントから重要度の少ないクライアントを継続する会話をリストして、優先順位のスキームを定義することができる。あるいは、ユーザは家族や友達の中で継続的なメッセージの優先順位をつけることもできる。使うスキームにかかわらず、継続する会話のための優先順位リストをこのプロセスで定義する（ステップ１２１０）。
【０２２５】
図１２ｃは、さまざまな継続する会話から受信したメッセージのキューの構造を示すフロー図である。最初のステップで、レンダリングされないメッセージのインデックスされたメディアペイロード（すなわち、メディアストリーム）の利用可能性が、連続してレンダリングされる会話ごとに継続的に検出される（ステップ１２１２）。使用可能なインデックスされたメディアペイロードストリームに優先順位の階層が適用される（ステップ１２１４）。優先順位の階層および以下に述べる可能な他のパラメータに少なくとも部分的に基づいて、使用可能なインデックスされたメディアペイロードが、シーケンス順序に配列される（ステップ１２１６）。続いて、インデックスされたメディアペイロードは、シーケンスの順序で連続してレンダリングされる（ステップ１２１８）。上記のプロセスを連続的に繰り返すことによって、マルチ会話のメッセージが連続してレンダリングされる。
【０２２６】
一実施例において、順序付けの順序は、部分的ないし全面的に優先順位の階層に基づく。代替的な実施例においては、他のパラメータに加え、階層および利用可能性も考慮されてもよい。例えば、シーケンスの順序は、以下にあげる一またはそれ以上のパラメータを使って定義することもできる。現在レンダリング中のインデックスされたメディアペイロードのストリームを高い優先順位の会話のインデックスされたメディアペイロードによって中断されることと関わる切り替えコスト、インデックスされたメディアペイロードの使用可能なストリームの品質、インデックスされたメディアペイロードが受信された場合の相対的タイム、配置換えの順序またはシステムのコントローラの入力。
【０２２７】
異なる会話のメッセージの間で衝突が起きた場合、シーケンスの順序の最初のインデックスされたメディアペイロードは、その他の使用可能なインデックスされたメディアペイロードのレンダリングが休止または遅延されている間に、レンダリングされる。衝突がない場合は、インデックスされたメディアペイロードは、可能になり次第、即座にレンダリングされる。
【０２２８】
さらに他の実施例においては、連続してレンダリングされる会話のメッセージは、オプションとして、タイムシフトモードでレビューされてもよい。第一の通信デバイスユーザが、連続してレンダリングされる会話に関わるメディアを生成する場合は、メディアはインデックスし、ネットワーク上のサーバ１６のＰＩＭＢ８５とともにデバイスのＰＩＭＢ３０に記憶することもできる。このように、会話がタイムシフトモードでレビューされる場合は、ユーザは、会話に関係する、入ってくるメッセージだけをレビューするか、または会話に関わる第一のユーザが作成したメディアと入ってくるメッセージの両方を、時間でインデックスの順序でレビューするか選択できる。
【０２２９】
［Ｌ．２ ＭＣＭＳ−Ｓの動作］
ＭＣＭＳ−Ｓすなわち同時モードにおいては、デバイス１３を実行するクライアント１２のユーザは、同時レンダリングするための一組の会話を定義することができる。一組の会話が定義されると、その一組の会話に関わるインデックスされたメディアペイロードのストリームが、それらが重複しているかどうかにかかわらずデバイス１３上に同時にレンダリングされる。代替的な実施例においては、オプションとして、ユーザは、メディアストリーム組から別途受信したインデックスされたメディアペイロードをレンダリングすることができる。また、オプションとして、同時会話のインデックスされたメディアペイロードは、ほぼリアルタイムモードまたはタイムシフトモードでレンダリングすることもできる。
【０２３０】
［Ｌ．３ ＭＣＭＳ、ＭＣＭＳ−ＣおよびＭＣＭＳ−Ｓの例］
図１３Ａないし１３Ｄは、ＭＣＭＳ、ＭＣＭＳ−ＣおよびＭＳＭＳ−Ｓの会話の属性と動作を示す一連の図である。
【０２３１】
図１３Ａは、ユーザ「Ｘ」と、「Ｙ」と「Ｚ」で示される他の２個のユーザとの間で行われる、会話「Ａ」のメッセージのインデックスされたメディアペイロードをレンダリングするシーケンスを示すタイム図である。この例では、ｔ１、ｔ５、５６、ｔ７およびｔ９で示されるタイムインターバルの間にユーザＹよって生成されるメディアである。ｔ３、ｔ６およびｔ９ないしｔ１０で示されるタイムインターバルの間にユーザＺによってメディアが生成される。
【０２３２】
ユーザＸのデバイス１３でのレンダリングシーケンスは図の一番下に示される。インターバルｔ１、ｔ５およびｔ７の間には、Ｙから取出したメディアのみレンダリングされる。ｔ３とｔ１０のインターバルの間には、Ｚから取出したメディアのみレンダリングされる。ｔ６およびｔ９のインターバルには、ＹとＺの両者から取出したメディアがレンダリングされる。ｔ２、ｔ４およびｔ８のインターバルには、ユーザＹ、Ｚのどちらもこの間メディアを生成していないので、何もレンダリングされない。ｔ１ないしｔ１０のインターバルは、固定的な時間のインターバルではなく、メディアが生成されている時間を示すだけであることに注意されたい。
【０２３３】
図１３Ａは、会話の属性を良くあらわしている。一個のユーザ（ＹまたはＺ）がメディアを生成していると、そのメディアは、Ｘのデバイス１３で受信され、それはレンダリング可能である。ユーザＸとＹがともにメディアを生成している場合は、どちらのメディアストリームもＸのデバイス１３で受信されミキシングに使用可能である。ユーザＸとＹのどちらもメディアを生成していない場合は、Ｘのデバイス１３ではメディアは何も受信されない。前にも述べたように、ユーザＸは、会話Ａの間に、リアルタイムモードかタイムシフトモードのどちらかで生成されたメディアをレビューするオプションがある。また、ユーザＸは、図に示すように、混合したフォーマットでメディアをレビューするか、ＹとＺからのメディアをタイムシフトモードで別々にレビューできるオプションがある。
【０２３４】
図１３ＢはＭＣＭＳの動作を示す。この例では、ユーザは、Ａ、ＢおよびＣで示す３個の会話に参加している。会話Ａ、Ｂ、およびＣについては、ユーザは、それぞれ（Ａ１、Ａ２、Ａ３、Ａ４）、（Ｂ１、Ｂ２、Ｂ３）および（Ｃ１、Ｃ２）で示すメッセージを生成または受信する。各メッセージのタイミングおよび期間は、時間線に沿う開始点で示す。この例では、メッセージＢ２を除き、全てのメッセージが時間的に重複していることに注意いただきたい。
【０２３５】
ＭＣＭＳアプリケーションを使って、ユーザは現在の一個の会話を選択する。選択された会話については、ユーザは入ってくるメッセージをレビューすることができ、会話の他の参加者に送信するメッセージを生成することができる。この例では、ユーザは、現在の順序で会話Ｂ、ＣおよびＡをそれぞれ選択する。したがって、メッセージのシーケンスは、最初はＢ１、Ｂ２、およびＢ３、Ｃ１、Ｃ２が続き、最後にＡ１ないしＡ４が来る。現在ある会話が選択されている間に、ユーザはほぼリアルタイムモードとタイムシフトモードの間で遷移でき、また戻ることができる。図に示す最終のレンダリングは、上の図に示すように、受信したメッセージのタイミングに対応するものではない。図の下の部分は、ユーザによって選択された会話の順序にに基づく、メッセージのレンダリング順序のみを示す。
【０２３６】
図１３Ｂの例は、ＭＣＭＳアプリケーションの属性を良く表している。ユーザは、現在行われている会話の中から一個を選択する。他の会話は休止する。また、ユーザは随時全ての会話の中を現在の会話を遷移することができる。
【０２３７】
図１３Ｃは、ＭＣＭＳ−Ｃの動作を示す図である。この例では、ユーザは連続する会話Ａ、Ｂに参加している。会話Ａでは、三個のメッセージＡ１、Ａ２、およびＡ３が受信される。会話Ｂでは、三個のメッセージＢ１、Ｂ２およびＢ３が受信される。この例では、メッセージＢ１がメッセージＡ１と衝突することに注目いただきたい。また、会話Ａは会話Ｂよりも高い優先順位が持っている。
【０２３８】
図に縦の破線で示すように、二つの会話の連続的なレンダリングを行う間に、高い優先順位を持つメッセージＡ１およびＡ２が先にほぼリアルタイムでレンダリングされる。メッセージＡ２とＡ３の間には、比較的大きなタイムギャップがあるので、このスペースは、タイムシフトおよびレンダリングメッセージＢ１とＢ２で埋められる。Ａ３が到着すると、それはリアルタイムでレンダリングされ、一方メッセージＢ３は、高い優先順位のメッセージＡ３がレンダリングされた後にのみレンダリングされる。高い優先順位のメッセージの間に低い優先順位メッセージをタイムシフトでレンダリングすることによって、連続的なマルチ会話を管理することができる。この単純な例では、優先順位が、レンダリングするための連続的な順序を決めるために使われる唯一のパラメータであることに注意されたい。上記のように、その他の多くのパラメータを使うこともできる。
【０２３９】
図１３Ｄは、ＭＣＭＳ−Ｓを示す図である。この例では、ユーザは、Ａ、ＢおよびＣに関わっている。図は、会話Ａ、ＢおよびＣ毎に、メッセージＡ１、Ａ２およびＡ３、Ｂ１、Ｂ２及びＢ３、及びＣ１及びＣ２がそれぞれ受信される様子を示す。ＭＣＭＳ−Ｓでは、入ってくるメッセージは、それが受信されるのと平行して受信側デバイス１３でレンダリングされる。したがって、下の図に示すように、三つの会話Ａ、Ｂ及びＣのメッセージのレンダリングシーケンスは、メッセージが受信されたときと同じである。この方法においては、マルチ会話は、同時にレンダリングすることができる。
【０２４０】
上記の例では、ＭＳＭＳ−ＣおよびＭＣＭＳ−Ｓを含むＭＣＭＳアプリケーションのいくつかの変形例について説明した。使われるＭＣＭＳアプリケーションの特定のタイプにかかわらず、それらは全ていくつかの共通の特徴を共有している。何れのケースにおいても、会話は、スレッドされたメッセージのシーケンスすなわち組織によって定義される。メッセージは、メディアの一個のストリームからセグメント化され、各メッセージは所定のシーケンス識別子をもち、メディアが作成された時間でインデックスされている。ＭＣＭＳアプリケーションのバリエーションによって、メッセージは、一またはそれ以上のレンダリングオプションに従ってレンダリングされる。レンダリングオプションには、いずれもゼロから複数の異なる属性を使い、フォーム毎に、メッセージのフィルターリング、グルーピングオーバラップおよび／またはシリーズ化がある。この方法では、それぞれメッセージのストリングを含むマルチ会話を、デバイス１３を動かす一個のクライアント１２上で、行うことができる。最後に、ＭＣＭＳのそれぞれのバリエーションは、同じ方法で割り込みメッセージの受信に対応することができる。割り込みメッセージを受信すると、通常、別の会話所属する他のメッセージがレンダリングされる前に先行する。
【０２４１】
［Ｍ． クライアントおよびサーバハードウェア］
図１４Ａは、クライアントアプリケーション１２を記憶し実行するために使われるデバイス１３のハードウェアを示すブロック図１４０である。ハードウェアは、ＣＰＵ１４２、メインメモリ１４４および大容量記憶装置１４６を有する。技術的には周知のことだが、クライアントアプリケーション１２はメインメモリ１４４と大容量記憶装置１４６に搭載され記憶されて、ＣＰＵ１４２によって実行される。
【０２４２】
図１４Ｂは、サーバアプリケーション７８を記憶し実行するために使われるサーバ１６のハードウェアを示すブロック図１５０である。ハードウェアは、ＣＰＵ１５２、メインメモリ１５４、大容量記憶装置１５６、およびアーカイブ部８９を有する。技術的には周知のことだが、サーバアプリケーション７８は、メインメモリ１５４および大容量記憶装置１５６に搭載、保存されＣＰＵ１５２によって実行される。上記のように、一またはそれ以上のユーザのインデックスされたメディアペイロードは、アーカイブ部８９に保存される。
【０２４３】
便宜上、多くのコンポーネントと処理について一個の事例で記述したが、当業者には正しく理解されるように、多くのコンポーネントと繰り返しの処理をここに説明したシステムおよび方法の技術は実施する上で使用できる。さらに、本発明は、特定の実施例を参照して特別に示し記述したが、当業者には正しく理解されるように、本発明の精神と範囲を超えずに、開示した実施例のフォームおよび細部の変更が可能である。例えば、本発明の実施例は、様々なコンポーネントとともに採用でき、かつ上記のものに限定されない。したがって、本発明は、全ての変形例及び同等物は本発明の精神と範囲に入ると理解されるべきものである。
【特許請求の範囲】
【請求項１】
会話を構成し、行うための方法であって、
ネットワークを通じて１又はそれ以上の参加者との会話のメディアを第１の通信デバイスで受信するステップと、
前記メディアが前記ネットワークを通じて受信される場合、前記受信メディアを前記第１の通信デバイス上に記憶するステップと、
ほぼリアルタイムモード、又はタイムシフトモードのいずれかで前記会話の受信メディアを前記第１の通信デバイス上でレンダリングするステップと、
前記会話と関連づけて前記第１の通信デバイス上にメディアを生成するステップと、
前記第１の通信デバイス上に生成された前記メディアを記憶するステップと、
前記会話の１又はそれ以上の参加者に対し前記第１の通信デバイス上に生成されたメディアを、前記ネットワークを通じて送信するステップと、
生成及び受信された前記メディアを関連づけるステップと、
関連づけられた前記生成及び受信されたメディアから前記会話を構成するステップと、
を具えることを特徴とする方法。
【請求項２】
請求項１の通信方法において、前記受信メディアが前記ネットワークを通じて受信される場合に、前記ほぼリアルタイムモードで前記会話の受信メディアを、前記第１の通信デバイス上にレンダリングするステップが、前記受信メディアを漸次レンダリングするステップを更に具えることを特徴とする方法。
【請求項３】
請求項１の通信方法において、前記タイムシフトモードで前記会話の受信メディアを、前記第１の通信デバイス上にレンダリングするステップが、記憶部又はメモリから前記受信メディアを取り出し、漸次レンダリングするステップを更に具えることを特徴とする方法。
【請求項４】
請求項１に記載の方法が、前記第１の通信デバイス上で前記ほぼリアルタイムモードと前記タイムシフトモードとの間を行き来して、前記受信メディアのレンダリングを遷移する能力を提供するステップを更に具えることを特徴とする方法。
【請求項５】
請求項１に記載の方法が、前記タイムシフトモードにある場合に、前記会話の受信メディアをレンダリングすべく任意の遅延を第１の通信デバイス上で選択する能力を提供するステップを更に具え、前記任意の遅延が前記第１の通信デバイスのユーザによって規定された期間を有することを特徴とする方法。
【請求項６】
第１の通信デバイス上で通信するための通信方法であって、
ネットワークを通じて１又はそれ以上の参加者との会話のメディアを、前記第１の通信デバイスで受信するステップと、
前記メディアが前記ネットワークを通じて受信される場合、前記受信メディアを前記第１の通信デバイス上に記憶するステップと、
ほぼリアルタイムモード、又はタイムシフトモードのいずれかで前記会話の受信メディアを前記第１の通信デバイス上でレンダリングするステップと、
記憶された前記メディアを取り出し、
増加したレンダリング速度で記憶部から取り出された前記メディアをレンダリングし、
増加した前記速度で取り出されたメディアのレンダリングが、前記ネットワークを通じて受信されているときに、前記会話のメディアをキャッチアップし、かつ、ほぼ同時である場合に、キャッチアップ点を確認し、
前記キャッチアップ点の後に前記ネットワークを通じて受信されているときに、前記ほぼリアルタイムモードで前記会話のメディアをレンダリングする、
ことによって、前記タイムシフトモードから前記ほぼリアルタイムモードに、前記第１の通信デバイス上で前記会話のメディアのレンダリングを遷移するステップと、
を具えることを特徴とする方法。
【請求項７】
請求項６に記載の方法において、前記記憶されたメディアを取り出すステップが、前記会話中に選択された過去の時点から前記記憶されたメディアを取り出すステップを更に具えることを特徴とする方法。
【請求項８】
請求項７に記載の方法において、前記記憶部から取り出されたメディアをレンダリングするステップが、前記会話中に選択された過去の時点から前記記憶されたメディアをレンダリングするステップを更に具えることを特徴とする方法。
【請求項９】
請求項６に記載の方法において、前記増加したレンダリング速度で前記記憶部から取り出されたメディアをレンダリングするステップが、前記メディアが最初にエンコードされたよりも速いレンダリング速度で、前記取り出されたメディアをレンダリングするステップを更に具えることを特徴とする方法。
【請求項１０】
請求項６に記載の方法において、前記タイムシフトモードで前記会話の受信メディアをレンダリングするステップが、
遅延後に記憶部又はメモリから取り出された前記メディアを取り出すステップと、
前記遅延後に前記記憶部又はメモリから取り出されたメディアをレンダリングするステップと、
を更に具えることを特徴とする方法。
【請求項１１】
請求項６に記載の方法において、前記第１の通信デバイス上でレンダリングするステップが、前記ほぼリアルタイムモードと、前記タイムシフトモードとの間で選択的に遷移できることを特徴とする方法。
【請求項１２】
請求項６に記載の方法が、
前記第１の通信デバイス上でメディアを生成するステップであって、生成された前記メディアが前記会話と関連づけられるステップと、
前記生成されたメディアを記憶するステップと、
前記ネットワークを通じて前記会話の１又はそれ以上の参加者に、前記生成されたメディアを送信するステップと、
を更に具えることを特徴とする方法。
【請求項１３】
第１の通信デバイス上での通信用の通信方法であって、
前記第１の通信デバイス上でメディアを生成するステップと、
前記第１の通信デバイス上に生成された前記メディアをネットワークを通じて送信するステップと、
送信した前記メディアと関連づけられるメディアを、前記第１の通信デバイスで前記ネットワークを通じて受信するステップであって、関連づけられ、かつ、送受信された前記メディアが、前記ネットワークを通じて前記受信メディアを送信する、前記第１の通信デバイスと１又はそれ以上の参加者との間の会話を構成するステップと、
前記会話と関連づけられる前記送受信されたメディアを前記第１の通信デバイス上に記憶するステップと、
ほぼリアルタイムモード又はタイムシフトモードのいずれかで前記会話の受信メディアをレンダリングするために前記第１の通信デバイス上にレンダリングオプションを提供するステップであって、前記第１の通信デバイスが、
（ａ）前記ほぼリアルタイムモードにある間に、前記メディアが前記ネットワークを通じて受信される場合、前記会話の受信メディアをレンダリングし、
あるいは、
（ｂ）前記メディアが前記タイムシフトモードで前記ネットワークを通じて受信される場合、前記会話のメディアをレンダリングしない、
ステップと、
前記タイムシフトモードを選択することによって、前記ほぼリアルタイムモードで、前記会話のメディアのレンダリングをポーズするステップと、
前記会話をポーズした後に、前記会話のメディアのレンダリングを再開するステップと、
を具えることを特徴とする方法。
【請求項１４】
請求項１３に記載の方法において、前記会話のメディアのレンダリングを再開するステップが、
前記会話がポーズされた間に受信及び記憶された前記会話のメディアを最初にレビューするステップと、
前記会話がポーズする間に受信される前記メディアがレビューされた後に、前記ほぼリアルタイムモードで前記会話のメディアをレンダリングするステップを再開するステップと、
を更に具えることを特徴とする方法。
【請求項１５】
請求項１３に記載の方法において、前記会話のメディアのレンダリングを再開するステップが、前記会話がポーズされた間に受信及び記憶された前記会話のメディアを最初にレビューすることなく、前記会話がポーズした後に前記ほぼリアルタイムモードで前記会話のメディアをレンダリングするステップを即時に再開するステップを更に具えることを特徴とする方法。
【請求項１６】
請求項１３に記載の方法が、
前記会話の過去の時点を選択し、
記憶部から選択された前記過去の時点から前記会話のメディアを取り出し、
前記第１の通信デバイス上で取り出された前記メディアをレンダリングする、
ことによって、前記会話のメディアを前記タイムシフトモードでレビューするステップを更に具えることを特徴とする方法。
【請求項１７】
請求項１５に記載の方法が、
記憶部から取り出された前記メディアが、前記ネットワークを通じて前記第１の通信デバイスで受信又は送信されているときに、レンダリングされ、かつ、前記会話のメディアと同時となる場合、前記タイムシフトモードから前記ほぼリアルタイムモードに遷移するステップ、
を更に具えることを特徴とする方法。
【請求項１８】
第１の通信デバイス上での通信用の通信方法であって、
前記第１の通信デバイス上でメディアを生成するステップと、
前記第１の通信デバイス上に生成された前記メディアをネットワークを通じて送信するステップと、
送信した前記メディアと関連づけられるメディアを、前記第１の通信デバイスで前記ネットワークを通じて受信するステップであって、関連づけられ、かつ、送受信された前記メディアが、前記ネットワークを通じて前記受信メディアを送信する、前記第１の通信デバイスと１又はそれ以上の参加者との間の会話を構成するステップと、
前記会話と関連づけられる前記送受信されたメディアを前記第１の通信デバイス上に記憶するステップと、
ほぼリアルタイムモード又はタイムシフトモードのいずれかで前記会話の受信メディアをレンダリングするために前記第１の通信デバイス上にレンダリングオプションを提供するステップであって、前記第１の通信デバイスが、
（ａ）前記ほぼリアルタイムモードにある間に、前記メディアが前記ネットワークを通じて受信される場合、前記会話の受信メディアをレンダリングし、
あるいは、
（ｂ）前記メディアが前記タイムシフトモードで前記ネットワークを通じて受信される場合、前記会話のメディアをレンダリングしない、
ステップと、
前記会話のメディアのレンダリングが、前記ほぼリアルタイムモードと、前記タイムシフトモードとの間で行き来して遷移するのを可能にするステップと、
を具えることを特徴とする方法。
【請求項１９】
請求項１８に記載の方法が、
記憶部から取り出された前記メディアが、前記ネットワークを通じて前記第１の通信デバイスで受信又は送信されているときに、レンダリングされ、かつ、前記会話のメディアと同時となる場合、前記タイムシフトモードから前記ほぼリアルタイムモードに遷移するステップ、
を更に具えることを特徴とする方法。
【請求項２０】
請求項１８に記載の方法が、前記タイムシフトモードにある間に受信及び記憶された、いずれのメディアも最初にレビューすることなく、前記ネットワークを通じて受信されるように、前記受信メディアを即時にレビューすることによって、前記タイムシフトモードから前記ほぼリアルタイムモードに遷移するステップを更に具えることを特徴とする方法。
【請求項２１】
請求項１、６、１３、又は１８に記載の方法において、前記会話が前記参加者間の送受信されたメディアの交換を更に含むことを特徴とする方法。
【請求項２２】
請求項２１に記載の方法において、前記会話が１又はそれ以上の文脈属性によって特徴づけられることを特徴とする方法。
【請求項２３】
請求項２２に記載の方法において、前記会話を特徴づける前記１又はそれ以上の文脈属性が、会話のトピック、会話の名称、前記会話中の前記参加者の１又はそれ以上の名前、又は開始時間のうちの１又はそれ以上を含むことを特徴とする方法。
【請求項２４】
請求項１、６、１３、又は１８に記載の方法において、メディアを受信するステップが、メッセージにセグメント化されたメディアを受信するステップを更に具えることを特徴とする方法。
【請求項２５】
請求項１、６、１３、又は１８に記載の方法が、前記生成されたメディアをメッセージにセグメント化するステップを更に具えることを特徴とする方法。
【請求項２６】
請求項２４又は２５に記載の方法が、前記メッセージを前記会話と関連づけるステップを更に具えることを特徴とする方法。
【請求項２７】
請求項１、１２、１３、及び１８に記載の方法において、前記会話の受信メディアを前記タイムシフトモードでレビューするステップが、
前記会話の１の参加者を選択するステップと、
選択された前記参加者と関連づけられた前記メディアを、記憶部又はメモリから取り出すステップと、
前記選択された参加者と関連づけられた前記メディアを、別個にレンダリングするステップと、
を更に具えることを特徴とする方法。
【請求項２８】
請求項１、１２、１３、及び１８に記載の方法において、前記会話の受信メディアを前記タイムシフトモードでレビューするステップが、
前記会話の２又はそれ以上の参加者を選択するステップと、
選択された前記２又はそれ以上の参加者と関連づけられた前記メディアを、記憶部又はメモリから取り出すステップと、
前記選択された２又はそれ以上の参加者と関連づけられた前記メディアのレンダリングを混合するステップと、
を更に具えることを特徴とする方法。
【請求項２９】
請求項１、１２、１３、及び１８に記載の方法において、前記会話の生成及び受信されたメディアがインデックスされたメディアペイロードを含み、当該インデックスされたメディアペイロードの各々が、関連づけられた時間及びシーケンス情報を有することを特徴とする方法。
【請求項３０】
請求項２９に記載の方法において、生成及び受信された前記インデックスされたメディアペイロードが記憶され、時間及びシーケンス順に記憶部又はメモリから取り出し可能となることを特徴とする方法。
【請求項３１】
請求項２９に記載の方法において、時間でインデックスされた前記メディアペイロードがストリーミングされることを特徴とする方法。
【請求項３２】
請求項１、６、１３、又は１８に記載の方法が、前記メディアをレンダリングするための複数のレンダリングオプションを提供するステップを更に具え、前記レンダリングオプションが、ポーズ、リプレイ、早くプレイ、ゆっくりプレイ、後方にジャンプ、前方にジャンプ、直近の受信メディアにキャッチアップ又は直近の受信メディアにジャンプのうちの１又はそれ以上を含むことを特徴とする方法。
【請求項３３】
請求項１、６、１３、又は１８に記載の方法が、増加したレンダリング速度で、記憶部又はメモリから取り出された前記メディアを選択的にレンダリングするステップを更に具え、前記メディアが最初にエンコードされた速度に、前記増加したレンダリング速度が比例することを特徴とする方法。
【請求項３４】
請求項１、１２、１３、又は１８に記載の方法が、
前記メディアを送信する前に前記メディアが生成されているときに、前記メディアを漸次記憶するステップ、
を更に具えることを特徴とする方法。
【請求項３５】
請求項１、１２、１３、又は１８に記載の方法が、
前記メディアが記憶される前に前記メディアが生成されているときに、前記メディアを漸次送信するステップ、
を更に具えることを特徴とする方法。
【請求項３６】
請求項１、１２、１３、又は１８に記載の方法が、
前記メディアが生成されているときに、前記メディアを同時及び漸次送信し、かつ記憶するステップ、
を更に具えることを特徴とする方法。
【請求項３７】
請求項１、６、１３、又は１８に記載の方法が、
前記ほぼリアルタイムモードで前記受信メディアをレンダリングする前に、前記メディアが受信されているときに、前記受信メディアを漸次記憶するステップ、
を更に具えることを特徴とする方法。
【請求項３８】
請求項１、６、１３、又は１８に記載の方法が、
前記受信メディアが記憶される前に前記メディアが受信されているときに、前記受信メディアを漸次レンダリングするステップ、
を更に具えることを特徴とする方法。
【請求項３９】
請求項１、６、１３、又は１８に記載の方法が、
前記メディアが受信されているときに、前記受信メディアを同時及び漸次レンダリングし、かつ記憶するステップ、
を更に具えることを特徴とする方法。
【請求項４０】
請求項１、１２、１３、又は１８に記載の方法において、前記第１の通信デバイス上に生成された前記メディアを前記ネットワークを通じて送信するステップが、
前記メディアが生成される場合、前記第１の通信デバイスが前記ネットワークに接続されているかどうかを確認するステップと、
前記第１の通信デバイスが前記ネットワークに接続された場合、前記メディアを漸次送信するステップと、
を更に具え、前記ネットワークへ接続されているかは、前記第１の通信デバイスと、前記ネットワークとの間でデータを転送可能な否かで規定されることを特徴とする方法。
【請求項４１】
請求項４０に記載の方法が、
前記メディアが生成されているときに、前記ネットワークと前記第１の通信デバイスとの間の接続の帯域幅レートを確認するステップと、
確認された前記帯域幅レートで前記生成されたメディアを漸次送信するステップと、
を更に具えることを特徴とする方法。
【請求項４２】
請求項１、１２、１３、又は１８に記載の方法において、前記第１の通信デバイス上に生成された前記メディアを前記ネットワークを通じて送信するステップが、
前記メディアが生成される場合、前記第１の通信デバイスが前記ネットワークから切断されたかどうかを確認するステップと、
前記第１の通信デバイスが前記ネットワークに再接続されるときを検出するステップと、
前記第１の通信デバイスが前記ネットワークに再接続された後に、記憶部又はメモリから前記生成されたメディアを送信するステップと、
を更に具え、前記ネットワークへ接続及び切断がされたかはそれぞれ、前記第１の通信デバイスと、前記ネットワークとの間でデータを転送可能か否か又は転送不可能か否かとして規定されることを特徴とする方法。
【請求項４３】
請求項１、１２、１３、又は１８に記載の方法において、前記第１の通信デバイス上に生成された前記メディアを前記ネットワークを通じて送信するステップが、
前記メディアが生成される場合、ネットワーク状態が送信を防ぐほどに十分に不足しているかどうかを確認するステップと、
ネットワーク状態が前記送信を可能にするほどに十分に改善されるときを検出するステップと、
前記ネットワーク状態が十分に改善したときを検出した後で、記憶部又はメモリから前記生成されたメディアを送信するステップと、
を更に具えることを特徴とする方法。
【請求項４４】
請求項１、６、１３、又は１８に記載の方法において、前記メディアが、音声、ビデオ、テキスト、センサデータ、無線信号、位置又はＧＰＳ情報、あるいはその組合せのうちの１又はそれ以上を含むことを特徴とする方法。
【請求項４５】
請求項１、６、１３、又は１８に記載の方法において、前記第１の通信デバイスが、固定電話、ワイヤレス又はセルラーホン、コンピュータ、無線、衛星電話、衛星無線、あるいは戦術的無線又は電話のうちの１つを具えることを特徴とする方法。
【請求項４６】
請求項１、６、１３、又は１８に記載の方法において、前記ネットワークが、パケットベースのネットワーク、回路ベースのネットワーク、セルラーネットワーク、ワイヤレスネットワーク、有線ネットワーク、無線ネットワーク、衛星ネットワーク、又はその組合せを具えることを特徴とする方法。
【請求項４７】
請求項１、６、１３、又は１８に記載の方法が、前記ほぼリアルタイムモードでレンダリングする場合に、前記会話の１又はそれ以上の参加者からの前記メディアを混合するステップを更に具えることを特徴とする方法。
【請求項４８】
請求項１、６、１３、又は１８に記載の方法が、タイム遅延モードでレンダリングする場合に、前記会話の１又はそれ以上の参加者からの前記メディアを混合するステップを更に具えることを特徴とする方法。
【請求項４９】
請求項１、６、１３、又は１８に記載の方法が、
前記会話の各参加者からの前記受信メディアが、前記第１の通信デバイス上で別個にレンダリングされるように、前記会話の１又はそれ以上の参加者からの前記受信メディアを分離するステップ、
を更に具えることを特徴とする方法。
【請求項５０】
請求項１、６、１３、又は１８に記載の方法が、
遅延後に記憶部又はメモリから、前記取り出されたメディアを取り出し、
前記遅延後に、記憶部又はメモリから取り出された前記メディアをレンダリングする、
ことによって前記タイムシフトモードで前記会話の受信メディアをレンダリングするステップを更に具え、前記遅延が前記第１の通信デバイスのユーザにより規定される期間を有することを特徴とする方法。
【請求項５１】
請求項１、６、１３、又は１８に記載の方法において、前記会話の受信メディアを前記第１の通信デバイス上でレンダリングするステップが、
前記会話と関連づけられた複数の参加者から前記第１の通信デバイスで、複数のメディアストリームを受信するステップであって、前記複数のメディアストリームの各々が時間でインデックスされたメディアペイロードを含むステップと、
時間によって参加者ごとに、前記インデックスされたメディアペイロードを重ねることによって、前記複数のメディアストリームをレンダリングするステップと、
を更に具えることを特徴とする方法。
【請求項１】
会話を構成し、行うための方法であって、
ネットワークを通じて１又はそれ以上の参加者との会話のメディアを第１の通信デバイスで受信するステップと、
前記メディアが前記ネットワークを通じて受信される場合、前記受信メディアを前記第１の通信デバイス上に記憶するステップと、
ほぼリアルタイムモード、又はタイムシフトモードのいずれかで前記会話の受信メディアを前記第１の通信デバイス上でレンダリングするステップと、
前記会話と関連づけて前記第１の通信デバイス上にメディアを生成するステップと、
前記第１の通信デバイス上に生成された前記メディアを記憶するステップと、
前記会話の１又はそれ以上の参加者に対し前記第１の通信デバイス上に生成されたメディアを、前記ネットワークを通じて送信するステップと、
生成及び受信された前記メディアを関連づけるステップと、
関連づけられた前記生成及び受信されたメディアから前記会話を構成するステップと、
を具えることを特徴とする方法。
【請求項２】
請求項１の通信方法において、前記受信メディアが前記ネットワークを通じて受信される場合に、前記ほぼリアルタイムモードで前記会話の受信メディアを、前記第１の通信デバイス上にレンダリングするステップが、前記受信メディアを漸次レンダリングするステップを更に具えることを特徴とする方法。
【請求項３】
請求項１の通信方法において、前記タイムシフトモードで前記会話の受信メディアを、前記第１の通信デバイス上にレンダリングするステップが、記憶部又はメモリから前記受信メディアを取り出し、漸次レンダリングするステップを更に具えることを特徴とする方法。
【請求項４】
請求項１に記載の方法が、前記第１の通信デバイス上で前記ほぼリアルタイムモードと前記タイムシフトモードとの間を行き来して、前記受信メディアのレンダリングを遷移する能力を提供するステップを更に具えることを特徴とする方法。
【請求項５】
請求項１に記載の方法が、前記タイムシフトモードにある場合に、前記会話の受信メディアをレンダリングすべく任意の遅延を第１の通信デバイス上で選択する能力を提供するステップを更に具え、前記任意の遅延が前記第１の通信デバイスのユーザによって規定された期間を有することを特徴とする方法。
【請求項６】
第１の通信デバイス上で通信するための通信方法であって、
ネットワークを通じて１又はそれ以上の参加者との会話のメディアを、前記第１の通信デバイスで受信するステップと、
前記メディアが前記ネットワークを通じて受信される場合、前記受信メディアを前記第１の通信デバイス上に記憶するステップと、
ほぼリアルタイムモード、又はタイムシフトモードのいずれかで前記会話の受信メディアを前記第１の通信デバイス上でレンダリングするステップと、
記憶された前記メディアを取り出し、
増加したレンダリング速度で記憶部から取り出された前記メディアをレンダリングし、
増加した前記速度で取り出されたメディアのレンダリングが、前記ネットワークを通じて受信されているときに、前記会話のメディアをキャッチアップし、かつ、ほぼ同時である場合に、キャッチアップ点を確認し、
前記キャッチアップ点の後に前記ネットワークを通じて受信されているときに、前記ほぼリアルタイムモードで前記会話のメディアをレンダリングする、
ことによって、前記タイムシフトモードから前記ほぼリアルタイムモードに、前記第１の通信デバイス上で前記会話のメディアのレンダリングを遷移するステップと、
を具えることを特徴とする方法。
【請求項７】
請求項６に記載の方法において、前記記憶されたメディアを取り出すステップが、前記会話中に選択された過去の時点から前記記憶されたメディアを取り出すステップを更に具えることを特徴とする方法。
【請求項８】
請求項７に記載の方法において、前記記憶部から取り出されたメディアをレンダリングするステップが、前記会話中に選択された過去の時点から前記記憶されたメディアをレンダリングするステップを更に具えることを特徴とする方法。
【請求項９】
請求項６に記載の方法において、前記増加したレンダリング速度で前記記憶部から取り出されたメディアをレンダリングするステップが、前記メディアが最初にエンコードされたよりも速いレンダリング速度で、前記取り出されたメディアをレンダリングするステップを更に具えることを特徴とする方法。
【請求項１０】
請求項６に記載の方法において、前記タイムシフトモードで前記会話の受信メディアをレンダリングするステップが、
遅延後に記憶部又はメモリから取り出された前記メディアを取り出すステップと、
前記遅延後に前記記憶部又はメモリから取り出されたメディアをレンダリングするステップと、
を更に具えることを特徴とする方法。
【請求項１１】
請求項６に記載の方法において、前記第１の通信デバイス上でレンダリングするステップが、前記ほぼリアルタイムモードと、前記タイムシフトモードとの間で選択的に遷移できることを特徴とする方法。
【請求項１２】
請求項６に記載の方法が、
前記第１の通信デバイス上でメディアを生成するステップであって、生成された前記メディアが前記会話と関連づけられるステップと、
前記生成されたメディアを記憶するステップと、
前記ネットワークを通じて前記会話の１又はそれ以上の参加者に、前記生成されたメディアを送信するステップと、
を更に具えることを特徴とする方法。
【請求項１３】
第１の通信デバイス上での通信用の通信方法であって、
前記第１の通信デバイス上でメディアを生成するステップと、
前記第１の通信デバイス上に生成された前記メディアをネットワークを通じて送信するステップと、
送信した前記メディアと関連づけられるメディアを、前記第１の通信デバイスで前記ネットワークを通じて受信するステップであって、関連づけられ、かつ、送受信された前記メディアが、前記ネットワークを通じて前記受信メディアを送信する、前記第１の通信デバイスと１又はそれ以上の参加者との間の会話を構成するステップと、
前記会話と関連づけられる前記送受信されたメディアを前記第１の通信デバイス上に記憶するステップと、
ほぼリアルタイムモード又はタイムシフトモードのいずれかで前記会話の受信メディアをレンダリングするために前記第１の通信デバイス上にレンダリングオプションを提供するステップであって、前記第１の通信デバイスが、
（ａ）前記ほぼリアルタイムモードにある間に、前記メディアが前記ネットワークを通じて受信される場合、前記会話の受信メディアをレンダリングし、
あるいは、
（ｂ）前記メディアが前記タイムシフトモードで前記ネットワークを通じて受信される場合、前記会話のメディアをレンダリングしない、
ステップと、
前記タイムシフトモードを選択することによって、前記ほぼリアルタイムモードで、前記会話のメディアのレンダリングをポーズするステップと、
前記会話をポーズした後に、前記会話のメディアのレンダリングを再開するステップと、
を具えることを特徴とする方法。
【請求項１４】
請求項１３に記載の方法において、前記会話のメディアのレンダリングを再開するステップが、
前記会話がポーズされた間に受信及び記憶された前記会話のメディアを最初にレビューするステップと、
前記会話がポーズする間に受信される前記メディアがレビューされた後に、前記ほぼリアルタイムモードで前記会話のメディアをレンダリングするステップを再開するステップと、
を更に具えることを特徴とする方法。
【請求項１５】
請求項１３に記載の方法において、前記会話のメディアのレンダリングを再開するステップが、前記会話がポーズされた間に受信及び記憶された前記会話のメディアを最初にレビューすることなく、前記会話がポーズした後に前記ほぼリアルタイムモードで前記会話のメディアをレンダリングするステップを即時に再開するステップを更に具えることを特徴とする方法。
【請求項１６】
請求項１３に記載の方法が、
前記会話の過去の時点を選択し、
記憶部から選択された前記過去の時点から前記会話のメディアを取り出し、
前記第１の通信デバイス上で取り出された前記メディアをレンダリングする、
ことによって、前記会話のメディアを前記タイムシフトモードでレビューするステップを更に具えることを特徴とする方法。
【請求項１７】
請求項１５に記載の方法が、
記憶部から取り出された前記メディアが、前記ネットワークを通じて前記第１の通信デバイスで受信又は送信されているときに、レンダリングされ、かつ、前記会話のメディアと同時となる場合、前記タイムシフトモードから前記ほぼリアルタイムモードに遷移するステップ、
を更に具えることを特徴とする方法。
【請求項１８】
第１の通信デバイス上での通信用の通信方法であって、
前記第１の通信デバイス上でメディアを生成するステップと、
前記第１の通信デバイス上に生成された前記メディアをネットワークを通じて送信するステップと、
送信した前記メディアと関連づけられるメディアを、前記第１の通信デバイスで前記ネットワークを通じて受信するステップであって、関連づけられ、かつ、送受信された前記メディアが、前記ネットワークを通じて前記受信メディアを送信する、前記第１の通信デバイスと１又はそれ以上の参加者との間の会話を構成するステップと、
前記会話と関連づけられる前記送受信されたメディアを前記第１の通信デバイス上に記憶するステップと、
ほぼリアルタイムモード又はタイムシフトモードのいずれかで前記会話の受信メディアをレンダリングするために前記第１の通信デバイス上にレンダリングオプションを提供するステップであって、前記第１の通信デバイスが、
（ａ）前記ほぼリアルタイムモードにある間に、前記メディアが前記ネットワークを通じて受信される場合、前記会話の受信メディアをレンダリングし、
あるいは、
（ｂ）前記メディアが前記タイムシフトモードで前記ネットワークを通じて受信される場合、前記会話のメディアをレンダリングしない、
ステップと、
前記会話のメディアのレンダリングが、前記ほぼリアルタイムモードと、前記タイムシフトモードとの間で行き来して遷移するのを可能にするステップと、
を具えることを特徴とする方法。
【請求項１９】
請求項１８に記載の方法が、
記憶部から取り出された前記メディアが、前記ネットワークを通じて前記第１の通信デバイスで受信又は送信されているときに、レンダリングされ、かつ、前記会話のメディアと同時となる場合、前記タイムシフトモードから前記ほぼリアルタイムモードに遷移するステップ、
を更に具えることを特徴とする方法。
【請求項２０】
請求項１８に記載の方法が、前記タイムシフトモードにある間に受信及び記憶された、いずれのメディアも最初にレビューすることなく、前記ネットワークを通じて受信されるように、前記受信メディアを即時にレビューすることによって、前記タイムシフトモードから前記ほぼリアルタイムモードに遷移するステップを更に具えることを特徴とする方法。
【請求項２１】
請求項１、６、１３、又は１８に記載の方法において、前記会話が前記参加者間の送受信されたメディアの交換を更に含むことを特徴とする方法。
【請求項２２】
請求項２１に記載の方法において、前記会話が１又はそれ以上の文脈属性によって特徴づけられることを特徴とする方法。
【請求項２３】
請求項２２に記載の方法において、前記会話を特徴づける前記１又はそれ以上の文脈属性が、会話のトピック、会話の名称、前記会話中の前記参加者の１又はそれ以上の名前、又は開始時間のうちの１又はそれ以上を含むことを特徴とする方法。
【請求項２４】
請求項１、６、１３、又は１８に記載の方法において、メディアを受信するステップが、メッセージにセグメント化されたメディアを受信するステップを更に具えることを特徴とする方法。
【請求項２５】
請求項１、６、１３、又は１８に記載の方法が、前記生成されたメディアをメッセージにセグメント化するステップを更に具えることを特徴とする方法。
【請求項２６】
請求項２４又は２５に記載の方法が、前記メッセージを前記会話と関連づけるステップを更に具えることを特徴とする方法。
【請求項２７】
請求項１、１２、１３、及び１８に記載の方法において、前記会話の受信メディアを前記タイムシフトモードでレビューするステップが、
前記会話の１の参加者を選択するステップと、
選択された前記参加者と関連づけられた前記メディアを、記憶部又はメモリから取り出すステップと、
前記選択された参加者と関連づけられた前記メディアを、別個にレンダリングするステップと、
を更に具えることを特徴とする方法。
【請求項２８】
請求項１、１２、１３、及び１８に記載の方法において、前記会話の受信メディアを前記タイムシフトモードでレビューするステップが、
前記会話の２又はそれ以上の参加者を選択するステップと、
選択された前記２又はそれ以上の参加者と関連づけられた前記メディアを、記憶部又はメモリから取り出すステップと、
前記選択された２又はそれ以上の参加者と関連づけられた前記メディアのレンダリングを混合するステップと、
を更に具えることを特徴とする方法。
【請求項２９】
請求項１、１２、１３、及び１８に記載の方法において、前記会話の生成及び受信されたメディアがインデックスされたメディアペイロードを含み、当該インデックスされたメディアペイロードの各々が、関連づけられた時間及びシーケンス情報を有することを特徴とする方法。
【請求項３０】
請求項２９に記載の方法において、生成及び受信された前記インデックスされたメディアペイロードが記憶され、時間及びシーケンス順に記憶部又はメモリから取り出し可能となることを特徴とする方法。
【請求項３１】
請求項２９に記載の方法において、時間でインデックスされた前記メディアペイロードがストリーミングされることを特徴とする方法。
【請求項３２】
請求項１、６、１３、又は１８に記載の方法が、前記メディアをレンダリングするための複数のレンダリングオプションを提供するステップを更に具え、前記レンダリングオプションが、ポーズ、リプレイ、早くプレイ、ゆっくりプレイ、後方にジャンプ、前方にジャンプ、直近の受信メディアにキャッチアップ又は直近の受信メディアにジャンプのうちの１又はそれ以上を含むことを特徴とする方法。
【請求項３３】
請求項１、６、１３、又は１８に記載の方法が、増加したレンダリング速度で、記憶部又はメモリから取り出された前記メディアを選択的にレンダリングするステップを更に具え、前記メディアが最初にエンコードされた速度に、前記増加したレンダリング速度が比例することを特徴とする方法。
【請求項３４】
請求項１、１２、１３、又は１８に記載の方法が、
前記メディアを送信する前に前記メディアが生成されているときに、前記メディアを漸次記憶するステップ、
を更に具えることを特徴とする方法。
【請求項３５】
請求項１、１２、１３、又は１８に記載の方法が、
前記メディアが記憶される前に前記メディアが生成されているときに、前記メディアを漸次送信するステップ、
を更に具えることを特徴とする方法。
【請求項３６】
請求項１、１２、１３、又は１８に記載の方法が、
前記メディアが生成されているときに、前記メディアを同時及び漸次送信し、かつ記憶するステップ、
を更に具えることを特徴とする方法。
【請求項３７】
請求項１、６、１３、又は１８に記載の方法が、
前記ほぼリアルタイムモードで前記受信メディアをレンダリングする前に、前記メディアが受信されているときに、前記受信メディアを漸次記憶するステップ、
を更に具えることを特徴とする方法。
【請求項３８】
請求項１、６、１３、又は１８に記載の方法が、
前記受信メディアが記憶される前に前記メディアが受信されているときに、前記受信メディアを漸次レンダリングするステップ、
を更に具えることを特徴とする方法。
【請求項３９】
請求項１、６、１３、又は１８に記載の方法が、
前記メディアが受信されているときに、前記受信メディアを同時及び漸次レンダリングし、かつ記憶するステップ、
を更に具えることを特徴とする方法。
【請求項４０】
請求項１、１２、１３、又は１８に記載の方法において、前記第１の通信デバイス上に生成された前記メディアを前記ネットワークを通じて送信するステップが、
前記メディアが生成される場合、前記第１の通信デバイスが前記ネットワークに接続されているかどうかを確認するステップと、
前記第１の通信デバイスが前記ネットワークに接続された場合、前記メディアを漸次送信するステップと、
を更に具え、前記ネットワークへ接続されているかは、前記第１の通信デバイスと、前記ネットワークとの間でデータを転送可能な否かで規定されることを特徴とする方法。
【請求項４１】
請求項４０に記載の方法が、
前記メディアが生成されているときに、前記ネットワークと前記第１の通信デバイスとの間の接続の帯域幅レートを確認するステップと、
確認された前記帯域幅レートで前記生成されたメディアを漸次送信するステップと、
を更に具えることを特徴とする方法。
【請求項４２】
請求項１、１２、１３、又は１８に記載の方法において、前記第１の通信デバイス上に生成された前記メディアを前記ネットワークを通じて送信するステップが、
前記メディアが生成される場合、前記第１の通信デバイスが前記ネットワークから切断されたかどうかを確認するステップと、
前記第１の通信デバイスが前記ネットワークに再接続されるときを検出するステップと、
前記第１の通信デバイスが前記ネットワークに再接続された後に、記憶部又はメモリから前記生成されたメディアを送信するステップと、
を更に具え、前記ネットワークへ接続及び切断がされたかはそれぞれ、前記第１の通信デバイスと、前記ネットワークとの間でデータを転送可能か否か又は転送不可能か否かとして規定されることを特徴とする方法。
【請求項４３】
請求項１、１２、１３、又は１８に記載の方法において、前記第１の通信デバイス上に生成された前記メディアを前記ネットワークを通じて送信するステップが、
前記メディアが生成される場合、ネットワーク状態が送信を防ぐほどに十分に不足しているかどうかを確認するステップと、
ネットワーク状態が前記送信を可能にするほどに十分に改善されるときを検出するステップと、
前記ネットワーク状態が十分に改善したときを検出した後で、記憶部又はメモリから前記生成されたメディアを送信するステップと、
を更に具えることを特徴とする方法。
【請求項４４】
請求項１、６、１３、又は１８に記載の方法において、前記メディアが、音声、ビデオ、テキスト、センサデータ、無線信号、位置又はＧＰＳ情報、あるいはその組合せのうちの１又はそれ以上を含むことを特徴とする方法。
【請求項４５】
請求項１、６、１３、又は１８に記載の方法において、前記第１の通信デバイスが、固定電話、ワイヤレス又はセルラーホン、コンピュータ、無線、衛星電話、衛星無線、あるいは戦術的無線又は電話のうちの１つを具えることを特徴とする方法。
【請求項４６】
請求項１、６、１３、又は１８に記載の方法において、前記ネットワークが、パケットベースのネットワーク、回路ベースのネットワーク、セルラーネットワーク、ワイヤレスネットワーク、有線ネットワーク、無線ネットワーク、衛星ネットワーク、又はその組合せを具えることを特徴とする方法。
【請求項４７】
請求項１、６、１３、又は１８に記載の方法が、前記ほぼリアルタイムモードでレンダリングする場合に、前記会話の１又はそれ以上の参加者からの前記メディアを混合するステップを更に具えることを特徴とする方法。
【請求項４８】
請求項１、６、１３、又は１８に記載の方法が、タイム遅延モードでレンダリングする場合に、前記会話の１又はそれ以上の参加者からの前記メディアを混合するステップを更に具えることを特徴とする方法。
【請求項４９】
請求項１、６、１３、又は１８に記載の方法が、
前記会話の各参加者からの前記受信メディアが、前記第１の通信デバイス上で別個にレンダリングされるように、前記会話の１又はそれ以上の参加者からの前記受信メディアを分離するステップ、
を更に具えることを特徴とする方法。
【請求項５０】
請求項１、６、１３、又は１８に記載の方法が、
遅延後に記憶部又はメモリから、前記取り出されたメディアを取り出し、
前記遅延後に、記憶部又はメモリから取り出された前記メディアをレンダリングする、
ことによって前記タイムシフトモードで前記会話の受信メディアをレンダリングするステップを更に具え、前記遅延が前記第１の通信デバイスのユーザにより規定される期間を有することを特徴とする方法。
【請求項５１】
請求項１、６、１３、又は１８に記載の方法において、前記会話の受信メディアを前記第１の通信デバイス上でレンダリングするステップが、
前記会話と関連づけられた複数の参加者から前記第１の通信デバイスで、複数のメディアストリームを受信するステップであって、前記複数のメディアストリームの各々が時間でインデックスされたメディアペイロードを含むステップと、
時間によって参加者ごとに、前記インデックスされたメディアペイロードを重ねることによって、前記複数のメディアストリームをレンダリングするステップと、
を更に具えることを特徴とする方法。
【図１】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８Ａ】
【図８Ｂ】
【図８Ｃ】
【図８Ｄ】
【図８Ｅ】
【図８Ｆ】
【図９Ａ】
【図９Ｂ】
【図９Ｃ】
【図９Ｄ】
【図９Ｅ】
【図９Ｆ】
【図１０】
【図１１Ａ】
【図１１Ｂ】
【図１１Ｃ】
【図１１Ｄ】
【図１１Ｅ】
【図１１Ｆ】
【図１２Ａ】
【図１２Ｂ】
【図１２Ｃ】
【図１３Ａ】
【図１３Ｂ】
【図１３Ｃ】
【図１３Ｄ】
【図１４】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８Ａ】
【図８Ｂ】
【図８Ｃ】
【図８Ｄ】
【図８Ｅ】
【図８Ｆ】
【図９Ａ】
【図９Ｂ】
【図９Ｃ】
【図９Ｄ】
【図９Ｅ】
【図９Ｆ】
【図１０】
【図１１Ａ】
【図１１Ｂ】
【図１１Ｃ】
【図１１Ｄ】
【図１１Ｅ】
【図１１Ｆ】
【図１２Ａ】
【図１２Ｂ】
【図１２Ｃ】
【図１３Ａ】
【図１３Ｂ】
【図１３Ｃ】
【図１３Ｄ】
【図１４】
【公表番号】特表２０１０−５３３３９４（Ｐ２０１０−５３３３９４Ａ）
【公表日】平成２２年１０月２１日（２０１０．１０．２１）
【国際特許分類】
【出願番号】特願２０１０−５１４８９６（Ｐ２０１０−５１４８９６）
【出願日】平成２０年４月３０日（２００８．４．３０）
【国際出願番号】ＰＣＴ／ＵＳ２００８／０６２０４９
【国際公開番号】ＷＯ２００９／００５８８５
【国際公開日】平成２１年１月８日（２００９．１．８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５０９２６１２８９）レベルヴォックス，エルエルシー (9)
【Ｆターム（参考）】
【公表日】平成２２年１０月２１日（２０１０．１０．２１）
【国際特許分類】
【出願日】平成２０年４月３０日（２００８．４．３０）
【国際出願番号】ＰＣＴ／ＵＳ２００８／０６２０４９
【国際公開番号】ＷＯ２００９／００５８８５
【国際公開日】平成２１年１月８日（２００９．１．８）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５０９２６１２８９）レベルヴォックス，エルエルシー (9)
【Ｆターム（参考）】
[ Back to top ]