JP5607653B2 - ほぼリアルタイムで通信をサポートできる電子メールクライアント、そのアドレス、プロトコル、及び電子メールインフラストラクチュアを用いてほぼリアルタイムで通信をサポートする方法 - Google Patents

Description

本発明は通信に関するものであり、特に、時間ベースメディアのほぼリアルタイムで通信をサポートできる電子メールクライアント、及びそのアドレス、プロトコル、及び電子メールインフラストラクチュアを用いてほぼリアルタイムで通信をサポートする方法に関する。

現在、地球規模で使用されている３つのアドレス指定領域がある。手紙と小包の送達に主に用いられている郵便制度は、住宅の住所、オフィスビルの住所、私書箱などの物理的アドレスの使用に基づいている。手紙又は小包の送達を確実に行うためには、国、州又は地域、市又は町、郵便番号、通りの名前、及び番地を含む受取人の物理的アドレスが提供されてなくてはならない。現存する電話のインフラストラクチュアは、もう一つの地球規模でのアドレス指定領域を規定するものであり、歴史的にほぼリアルタイムでの音声通信に使用されてきた（すなわち、通話）。固定電話及び移動電話は、電話番号を用いてアドレスされ（すなわち、呼び出され）、これは通常、国番号と、所定の国及び／又は地域コード内の特定の電話を認識する様々な数の追加の数字を含む。通話をするパーティ間で回路が接続されると、完全な二重会話を行うことができる。第３の地球規模でアドレスシステムは電子メールである。すべての電子メールアカウントは、唯一の地球規模でのアドレス可能な電子メールアドレスによって認識され、このアドレスはユーザ名とドメイン名を規定している。

電子メールは、通常、送信者から一又はそれ以上の受信者に送られるテキストメッセージである。電子メールは、電子メールクライアントで作成される。良く知られた電子メールクライアントの一つは、Ｍｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋであり、これは、コンピュータ上で電子メールメッセージを作成し、受信し、管理するのに用いられる。代替的に、ユーザは、ウエブページを介してＹａｈｏｏ、Ｇｏｏｇｌｅ、又はＨｏｔｍａｉｌといったフリー電子メールサービスを受けることができる。使用するタイプにかかわらず、電子メールクライアントは、通常、（ｉ）電子メールの主題、電子メールの送信者、電子メールが送信された日付と時間、及び、電子メールのサイズなどその他のあり得る属性を示す電子メールヘッダを伴う受信したすべてのメッセージをリストにするあるいは表示する；（ｉｉ）ユーザがレビューするメッセージを選択できる；（ｉｉｉ）ユーザが新しいメッセージをタイプして受信者に送信して受信した他人の電子メールに応答できるようにする；及び、（ｉｖ）静止画像、文書、あるいはビデオクリップなどのアタッチメントを出て行く電子メールに添付できるようにする。

電子メールメッセージは、送信できるようになる前に、まず全部のメッセージを作らなくてはならない。送信者は、通常、まず受信者の電子メールアドレスを電子メールのヘッダの適宜の「Ｔｏ」領域に入力して、受信者を規定する。次いで、電子メールの本体にテキストメッセージをタイプすると共に、選択的にファイルを添付することもできる。メッセージが完成したら、ユーザはその電子メールを送信する。この送信シーケンスの間、電子メールクライアントは、ネットワーク上に位置する電子メールサーバを用いてセッションを開始する。このセッションは、通常、Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）を用いて行われる。このセッションの間に、電子メールクライアントは、ＳＭＴＰサーバに送信者の電子メールアドレスと、受信者の電子メールアドレスと、アタッチメントと共に電子メール本体を提供する。受信者の電子メールアドレスは、受信者名（例えば、「ｊｓｍｉｔｈ」）とドメイン名（例えば、「ｈｏｔｍａｉｌ．ｃｏｍ」）を含む、二つの部分に分けられている。受信者がＳＭＴＰサーバが支配するドメインにある場合は、サーバが特定の受信者に対する送達指示を実行する。この指示は、通常、同じＳＭＴＰサーバ、又は同じドメインにある別のサーバの受信者に付いている受信箱への当該電子メールの送達である。一方、受信者がそのサーバが支配していないドメインにいる場合は、電子メールサーバは、ＳＭＴＰを用いて当該受信者のドメインを支配しているサーバと通信を行う必要がある。

他のドメインの受信者に電子メールを送信するためには、ＳＭＴＰサーバはＤｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ（ＤＮＳ）と会話を開始して、受信者のドメインのＭａｉｌ ｅＸｃｈａｎｇｅｒ（ＭＸ）記録を求める。ＭＸ記録には、そのドメインに関するＳＭＴＰサーバの優先順位リストが含まれる。次いで、送信者のＳＭＴＰサーバから、応答するＭＸリストの最初のＳＭＴＰサーバへ電子メールが送信される。次いで、最初に応答するサーバが、受信者が最初に応答するサーバが支配するドメイン内にあるかどうかを決定する。このサーバがドメイン内にあれば、受信者の受信箱に電子メールが送達される。このサーバがドメイン内にない場合は、応答するサーバが受信者の受信箱にメッセージを送達できるサーバになるまで上述のプロセスが繰り返される。この送達ルートに沿って設けた各サーバは、「ホップ」と称されることがある。次いで、受信者のコンピュータあるいはインターネット上にある受信者の電子メールクライアントを介してこの電子メールにアクセスする。電子メールが複数パーティに送信される場合は、各受信者に対して上述のプロセスが繰り返される。

上述のシーケンスは、通常、インターネット上で送信された電子メールに対して適用される。同じ私設ネットワーク上の二人のＭｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅユーザ間で送信された電子メールなど、ある種の私設システムでは、電子メールをルーティングするのにＳＭＴＰプロトコルは使用しないが、電子メールアドレスは使用する。この私設プロトコル及びサーバのオペレーションは、基本的にＳＭＴＰと同じである。

現存の電子メールインフラストラクチュアは、ＳＭＴＰに基づいているか、あるいは私設電子メールプロトコルに基づいているかにかかわらず、基本的に、「蓄積転送」メッセージシステムである。電子メールメッセージは、送信できるようにする前に、まず全体を作り上げなくてはならない。ＳＭＴＰ又は送信者の私設メールサーバ、並びに、ＳＭＴＰあるいは受信者の私設メールサーバへの経路に沿って設けた中間電子メールサーバホップでは、電子メールメッセージは、それが送信される前に全部受信されなくてはならない。最後に、受信者がメッセージをレビューする前に、受信者の受信箱に全部の電子メールが受信されていなければならない。

比較すると、Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ（ＰＳＴＮ）を介した電話による通話は通常進行性である。言葉を話すとき、送信者から受信者へ言葉が同時に送信され、言葉をライブで又はほぼリアルタイムで効率よく聞くことができる。この結果、電話による通話は、共通ネットワーク接続（すなわち、回路）を通して、「ライブ」で、あるいはほぼリアルタイムモードで行うことができる。逆に、電子メール通信は、通常、一連の異なる蓄積転送メッセージを通じて生じ、しばしば二又はそれ以上のパーティ間で、異なる時間に、インターネットなどのネットワークを介して往復送信される。

ビデオクリップなどの、時間ベースメディア（すなわち、時間に対して変化するメディア）を含むファイルを電子メールに添付することは良く知られている。しかしながら、電子メールメッセージに添付されたこの時間ベースメディアは、電子メールの蓄積転送特性のため、作成時に受信者が「ライブ」でレビューすることができない。むしろ、電子メールと時間ベースメディアを含むアタッチメントを最初に作成して送信し、ネットワーク上の各電子メールサーバホップで蓄積転送され、次いで、アタッチメントの時間ベースメディアがレビューされる前に受信者に全体が受信されていなくてはならない。従って、メディアの作成時に電子メールメッセージの受信者がほぼリアルタイムでそのメディアをレビューすることは不可能である。

留守番電話システムも知られており、ここでは、ボイスメッセージを作成して、電子メールの形で受信者に送信する。これらのシステムでは、Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ（ＰＳＴＮ）を電子メールと共働させている。使用時に、まず、メッセージの記録を行って、保存し、次いで電子メールによって受信者に送信される。しかしながら、ここでも、受信者が記録したメッセージをレビューすることができるようになる前に、まず、メッセージ全体を受信しなくてはならない。

簡易メッセージあるいはＩＭは、蓄積転送システムのもう一つの例である。上述した電子メールと同様に、メッセージを受信者に送信できるようになる前に、メッセージが完成していなければならない。ＩＭシステムのメッセージは、通常、電子メールを介して送られるメッセージより短い。ＩＭシステムのテキストの各ラインは、蓄積転送方法で送達される別のメッセージである。現存のＩＭシステムは、送信者がメッセージを作成しているときに、段階的かつ同時にそのメッセージをレビューする方法を受信者に提供するものではない。

ライブテキストシステムは、ダム端末インターフェースと共に初期のユニックスシステムで主に使用されていたが、よく知られている。ライブテキストシステムでは、送信者がキーを押すとすぐに受信者に個別のキーストロークが送信される。これらのシステムはテキスト用のみであるが、メッセージの作成時に、受信者が順次そのメッセージをレビューすることができる。

現在のところ、電子メールアドレスを用いて、送信者と受信者の間で、ライブであるいはほぼリアルタイムで時間ベースメディアの通信をサポートするように、電子メールの地球規模でのアドレッシング及びルーティングインフラストラクチュアを拡張するシステムや方法は知られていない。

時間ベースメディアのリアルタイムでの通信をサポートできる電子メールクライアントが開示されている。この電子メールクライアントは、あるドメイン内の受信者にアドレスする電子メールアドレスが規定されると、サーバを用いてセッションを作成するように構成されたセッションエレメントを具えている。この電子メールアドレスが規定されると直ちに、電子メールクライアントの送信エレメントは、時間ベースメディアが作成されると、その電子メールアドレスのドメインのルックアップによって少なくとも部分的に見つけられたルートを介して、時間ベースメディアを受信者へ段階的かつ同時に送信するように構成される。受信者の電子メールアドレスが規定されるとすぐに受信者へのルートを少なくとも部分的に見つけることによって、送信エレメントが時間ベースメディアを受信者へ段階的に送達することができる。

本発明は、本発明の特定の実施例を示す添付図面と共に、以下の記載を参照することによって最も良く理解することができる。
図１は、ユーザ間で時間ベースメディアのライブであるいはほぼリアルタイムでの通信をサポートできる本発明によるネットワークを示す図である。 図２は、本発明の一実施例による通信デバイスを示す図である。 図３は、本発明の別の実施例による通信デバイスを示す図である。 図４Ａ及び４Ｂは、本発明の通信デバイス上の電子メールヘッダを作成するシーケンスを示すフローチャートである。 図５Ａは、本発明によるネットワーク上で通信を行うシーケンスを示すフローチャートである。 図５Ｂは、本発明によるネットワーク上で通信を行うシーケンスを示すフローチャートである。 図５Ｃは、本発明によるネットワーク上で通信を行うシーケンスを示すフローチャートである。 図５Ｄは、本発明によるネットワーク上で通信を行うシーケンスを示すフローチャートである。 図６は、本発明による電子メールへのメディアファイルのアタッチメントを示すフローチャートである。 図７は、本発明の別の実施例によるネットワーク上での時間ベースメディアの送達を示す図である。 図８は、従来技術による従来の電子メールの構造を示す図である。 図９は、本発明による段階的電子メールの構造を示す図である。

図において同じエレメントには同じ符号が付されている。

添付図面に示す様々な実施例を参照して本発明の詳細を以下に説明する。以下の説明において、発明を全体的に理解してもらうための、特定の詳細が設定されている。しかしながら、ここに設定した実装の詳細を用いることなく本発明を実行できることは当業者には自明である。なお、発明を不必要に分かりにくくしないようにするために、公知のオペレーションは詳細に説明していない。

本出願は、（ｉ）電子メールと、時間ベースメディアを含むが、当該メディアの実際の送達にはほぼリアルタイムで通信プロトコルを用いるメッセージ送達用のルーティングを規定するＤＮＳインフラストラクチュアの使用；（ｉｉ）電子メールアドレスとＤＮＳを用いた時間ベースメディアを含むメッセージの様々な送達オプション；（ｉｉｉ）時間ベースメディアを含む「段階的」電子メールの送信をサポートするＳＭＴＰあるいはその他の私設電子メールプロトコルの改変；（ｉｖ）音声又はその他の時間ベースメディアのほぼリアルタイムの通信用の受信者電子メールアドレスの事後接続；及び（ｖ）地球規模でアドレス可能な電子メールアドレスとＤＮＳを使用した、時間メディアを含むメッセージ又は段階的電子メールのルーティングによる、ほぼリアルタイムでの会話の実行；を含む多くの実施例を対象としている。これらの各態様を以下に詳細に述べる。

Ｉ．電子メールと、メディアの実際の送達用のほぼリアルタイムでの通信プロトコルを用いて、時間ベースメディアを含むメッセージ送達用のルーティングを規定するＤＮＳインフラストラクチュアの使用
図１を参照すると、（ｉ）時間ベースメディアの「ライブ」又はほぼリアルタイムでの通信をサポートすることができる、及び（ｉｉ）本発明による電子メールとＤＮＳのインフラストラクチュアを使用したルーティングを行うことができるネットワークシステムの図が示されている。システム１０は、ネットワーク１２を具えており、このネットワークは通信デバイス１４Ａ、１４Ｂ、１４Ｃ、及び１４Ｄを使用しているユーザＡ、Ｂ、Ｃ、及びＤと、ネットワーク１２に配置したサーバ１６Ａ、１６Ｂ、１６Ｃ、及び１６Ｄを伴っている。ネットワーク１２は更に、ＤＮＳサーバ１８を具える。様々な実施例では、ネットワーク１２は、インターネット、イントラネット、移動ＩＰネットワーク、あるいはインターネットプロトコル及び／又はＤＮＳに基づくその他のタイプのネットワーク、又はこれらの組み合わせを具えていてもよい。ユーザＡ、Ｂ、及びＣは、それぞれ、サーバ１６Ａ乃至１６Ｄによって、それぞれ地球規模でアドレス可能な電子メールアドレス「ＵｓｅｒＡ＠Ｄｏｍａｉｎ Ａ」、「ＵｓｅｒＢ＠Ｄｏｍａｉｎ Ｂ」、「ＵｓｅｒＣ＠Ｄｏｍａｉｎ Ｃ」を用いてアドレスすることができる。ユーザＤは、以下の理由で、地球規模でアドレス可能な電子メールアドレスによっては、ネットワーク１２上で意図的に同定されない。

サーバ１６Ａ、１６Ｂ、１６Ｃ、及び１６Ｄは、それぞれ、ユーザＡ、Ｂ、Ｃ、及びＤに一又はそれ以上のサービスを提供するように構成されている。この例では、サーバＡが、ドメインＡを規定しており、ユーザＡにＳＭＴＰ（又は同様の私設サービス）とＭＸ ＤＮＳレコード（以下、「ＭＸ」という）を用いて標準的な電子メール送達サービスを提供している。サーバＡは、更に、ユーザＡにリアルタイム通信サービス（以下、「ＲＶＸ」という）を提供している。サーバ１６ＢはドメインＢを規定しており、ユーザＢにリアルタイム通信サービスＲＶＸを提供しているが、電子メールサービスＭＸは提供していない。サーバ１６ＣはドメインＣを規定しており、ユーザＣに電子メールサービスＭＸを提供しているが、リアルタイム通信サービスＲＶＸは提供していない。サーバ１６Ｄは、ユーザＤに対してリアルタイム通信サービスＲＶＸも電子メールドメインＭＸサービスも提供していないが、同定されていないその他のサービスは関係がないので提供する。

一実施例では、リアルタイム通信サービスＲＶＸは、ユーザがほぼリアルタイムで時間ベースメディアを通信できる通信プロトコルに基づいているが、受信者には、ほぼリアルタイムモードで時間ベースメディアをレビューすることを要求しない。このような特性を有する公知のプロトコルには、米国特許出願第１２／０２８，４００号及び第１２／１９２，８９０号に詳細に記載されているＣｏｏｐｅｒａｔｉｖｅ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ（ＣＴＰ）、あるいは米国特許出願第１２／２５３，８１６号、第１２／２５３，８３３号、及び第１２／２５３，８４２号に記載されている音声あるいはその他の時間ベースメディアのほぼリアルタイムの同期プロトコルが含まれる。上記の米国出願は、本発明の譲受人に譲渡されており、全目的についてここに引用されている。

代替の実施例では、ＲＶＸサービスは、ＳＩＰ、ＲＴＰ、スカイプ、ＶｏＩＰ、その他といったほぼリアルタイムの通信を提供するその他の通信プロトコルを、個別にあるいは組み合わせて、使用している。

通信デバイス１４Ａ乃至１４Ｄは、固定電話、ＶｏＩＰ電話、セルラーラジオ、衛星通信ラジオ、軍事又は第１応答者ラジオ、移動インターネットデバイス、又はその他のタイプのほとんどすべての通信デバイスなど、どのような通信デバイスでもよい。更に、所定のユーザが、複数通信デバイス１４を有していても良い。例えば、ユーザは、ホームコンピュータ、職場コンピュータ、押して話すラジオ、移動電話、あるいはパーソナルデジタルアシスタント（ＰＤＡ）のうちの一又はそれ以上を有していても良い。ユーザＡ、Ｂ、Ｃ、及びＤが持っている通信デバイス１４の数に関係なく、各ユーザは、ほぼ同じ操作を行って、ここにそれぞれ述べたようにサーバ１６Ａ、１６Ｂ、１６Ｃ、及び１６Ｄによって提供されるサービスを受ける。

なお、図に示すシステム１０は、実際に実施例に実装される典型的なものに比べて、非常に単純化されている。説明のために、上述したユーザＡ、Ｂ、Ｃ及びＤに提供されている（あるいはされていない）ＲＶＸサービス及びＭＸサービスは、本発明の様々な特徴と態様を強調し説明するために、目的に応じて選択されている。しかしながら、実際の例では非常に多数のユーザがあり、各々、一又はそれ以上の通信デバイス１４と関連するネットワーク１２上のサーバを有しており、各ユーザに様々なサービスを提供している。更に、単一サーバからサーバ組１６にわたるあらゆる組み合わせがネットワーク１２に含まれており、一乃至複数のユーザにそれぞれＲＶＸ及び／又はＭＸを提供している。また、通信デバイス１４Ａ、１４Ｂ、及び１４Ｃとサーバ１６Ａ、１６Ｂ及び１６Ｃは、ＤＮＳ、ＳＭＴＰ、あるいはその他の私設電子メールプロトコルを用いて上述した方法と同じ方法で互いに通信することができ、ネットワーク１２上の一又はそれ以上のホップにわたるルートを発見する。同じドメイン内の受信者へのメッセージ送達ルートは、通常は、同じサーバ１６又は同じドメイン内の関連するサーバの受信箱に送達される。別のドメインの受信者に送られたメッセージは、通常、ネットワーク１２上の一又はそれ以上のホップを介して受信者の電子メールサーバへ送信される。ＩＰネットワーク上でのほぼリアルタイムでの電子メール及びメディアのルーティングはこの分野で公知であるので、ここでは詳細な説明は行わない。

図２を参照すると、本発明の一実施例による通信デバイス１４の図が示されている。この実施例では、通信デバイス１４が、移動電話又はＰＴＴラジオなど、ネットワーク１２を用いてワイヤレスで通信できる移動デバイス２０である。移動デバイス２０は、選択的に、キーパッド２２、ディスプレイ２４、スピーカ２６、マイクロホン２８、音量コントロール３０、静止画像及び／又は動画を生成できるカメラ３２、ディスプレイコントロールエレメント３４、開始機能エレメント３６、及び終了機能エレメント３８の一又はそれ以上を具えている。様々な実施例では、デバイス２０は、（ｉ）ＩＰベース、すなわち、インターネットプロトコルを用いてネットワーク１２上で通信するように設計されており、（ｉｉ）上述したプロトコルあるいはその他のほぼリアルタイムの通信プロトコルを含む、一又はそれ以上のＲＶＸプロトコルを稼働している。更に、デバイス２０は、選択的にまた局所的に電子メールクライアントを稼働して、ネットワーク１２に配置された一のサーバ１６にある電子メールクライアントにアクセスすることができる、あるいは、ネットワーク上で電子メールクライアントの稼働とアクセスの両方を行うことができる。

図３を参照すると、本発明の別の実施例による通信デバイスの図が示されている。この実施例では、通信デバイス１４はネットワーク１２に有線又は無線（図示せず）で接続されているコンピュータ４０である。コンピュータ４０は、選択的に、キーボード４２、ディスプレイ４４、スピーカ４６、マイクロホン４８、静止画像又は動画を生成できるカメラ５０、マウス５２、開始機能エレメント５４、及び、終了機能エレメント５６の一又はそれ以上を具える。コンピュータ４０は、電子メールクライアントを稼働させること、ネットワーク１２にある電子メールクライアントにアクセスすること、あるいはその両方を行うことができる。様々な実施例では、コンピュータ４０は、（ｉ）ＩＰベース、すなわち、インターネットプロトコルを用いてネットワーク１２上で通信するように設計されており、（ｉｉ）上述したプロトコルあるいはその他のほぼリアルタイムの通信プロトコルを含む、一又はそれ以上のＲＶＸプロトコルを稼働している。更に、コンピュータ４０は、ラップトップ又はパーソナルデジタルアシスタントといったポータブルコンピュータであっても良く、図に示すようなデスクトップコンピュータに限定されない。更に、デバイス４０は、選択的にまた局所的に電子メールクライアントを稼働して、ネットワーク１２にある一のサーバ１６に配置された電子メールクライアントにアクセスすることができる、あるいは、ネットワーク上の電子メールクライアントの稼働とアクセスの両方を行うことができる。

移動デバイス２０とコンピュータ４０の開始機能エレメント３６／５４と終了機能エレメント３８／５６は、それぞれの機能を象徴するものである。移動デバイス２０、コンピュータ４０、あるいはその他のタイプの通信デバイス１４は、物理的に開始及び終了ボタン自体を具えている必要はない。むしろ、これらの各機能エレメントは、例えば、音声コマンド、あらかじめ決められたキーストローク、あるいはタッチスクリーン又はマウス、スタイラス、ポインタその他の入力デバイスを用いたコマンドを入力することによって、実装することができると解するべきである。

ネットワーク１２は、受信者ユーザの地球規模で認識可能な電子メールアドレスとルート発見用ＤＮＳを含む既存の電子メールインフラストラクチュアを使用することができる。一方、ほぼリアルタイムでのＲＶＸプロトコルを使用してルートが発見されると、アドレスされた受信者へ時間ベースメディアを含むメッセージを実際に送信することができる。従来の電子メールと同様に、各メッセージは、とりわけ、ルーティング用の一又はそれ以上の受信者の地球規模でアドレス可能な電子メールアドレスを規定するヘッダを用いている。しかしながら、従来の蓄積転送型電子メールと異なり、メッセージの時間ベースメディアは、ほぼリアルタイムのＲＶＸプロトコルを用いて送信される。この結果、時間ベースメディアは、送信者がこのメディアを作成すると、ネットワーク１２に同時に段階的に送信される。更に、時間ベースメディアがネットワークを介して受信されると、受信者は、選択的に、時間ベースメディアを同時かつ段階的に表示することができる。二又はそれ以上のパーティが同時に会話をする場合（例えば、時間ベースメディアを生成し、レビューする）、ネットワーク１２は、既存の電子メールインフラストラクチュアとルーティング用ＤＮＳを使用しながら、メディア送達用のＲＶＸプロトコルを用いてほぼリアルタイムでの通信をサポートしている。

図４Ａを参照すると、通信デバイス１４でメッセージに関連する時間ベースメディアを作成して送信するシーケンスのフローチャートが示されている。通信デバイス１４のユーザが特定の受信者と通信したい場合、ユーザはその連絡先リストから受信者を選択するか、意図した受信者からすでに受け取ったメッセージに応答する。意図した受信者からのメッセージを応答用に入手できない場合、あるいは、意図した受信者が連絡先リストにすでにない場合は、その受信者の地球規模でアドレス可能な電子メールアドレスをデバイス１４に手動で入力する。

上述のいずれかに応じて、「Ｔｏ」ヘッダに受信者の地球規模でアドレス可能な電子メールアドレスを含むメッセージヘッダを作成する（ステップ６２）。受信者の地球規模でアドレス可能な電子メールアドレスが規定されるやいなや、ＤＮＳルックアップが行われ、そのメッセージに関連するメディアを、地球規模でアドレスされた受信者へ送達するルートが直ちに発見される。その後、ユーザは開始機能３６／５４を起動して、例えばマイクロホンに向かって話す、ビデオを生成する、又は両方を行うことによって、時間ベースメディアの作成を開始できる（ステップ６４）。次いで、時間ベースメディアは段階的及び同時にエンコードされ（ステップ６６）、発見された送達ルートを用いて、ＲＶＸプロトコルでネットワーク１２上を送信され（ステップ６８）、選択的に、デバイス１４に持続的に保存される（ステップ７０）。なお、ステップ６２乃至７０はあるシーケンスで図に示されているが、実際はほぼ同時に生じる。ユーザは、連絡先リストから受信者を選択して、開始機能３６／５４を起動し、次いで直ちに話し始めることができる。メディアが作成されると、ＲＶＸプロトコルは、ＤＮＳルックアップを用いて明らかな遅れを生じることなく送信ユーザへのルートを探し、ネットワーク１２を介して、段階的かつ同時にそのメディアを受信者に送信する。

選択的に、送信するメッセージの時間ベースメディアは、多くの理由で送信通信デバイス１４に持続的に保存される。例えば、送達ルートが発見される前にメッセージの時間ベースメディアが作成される場合は、時間ベースメディアは送達ルートが見つかったときにストレージから送信することができる。時間ベースメディアがルートが見つかった後に作成されつつある場合は、時間ベースメディアが作成されているときに、段階的かつ同時に送信される。代替的に、時間ベースメディアのストレージを用いて、送信者はその後任意の遅い時間に保存されているメッセージをレビューすることができる。通信デバイス１４がネットワーク１２に接続されていないときにメッセージを作成して保存することもできる。この場合、接続は、ネットワーク上にメッセージを送信できることとして規定され、非接続は、ネットワーク上にメッセージを送信できないこととして規定される。デバイス１４がその後接続されると、ＲＶＸプロトコル又は電子メールのアタッチメントのいずれかを用いて、ストレージから意図した受信者へメッセージを送信できる。

図４Ｂを参照すると、メッセージヘッダを作成するシーケンスのフローチャート１００が示されている（図４Ａのステップ６２）。ステップ６２ａでは、送信者の地球規模でアドレス可能な電子メールアドレスが、メッセージヘッダの「Ｆｒｏｍ」領域に提供されている。ステップ６２ｂで、受信者の地球規模でアドレス可能な電子メールアドレスが、メッセージヘッダの「Ｔｏ」領域に入力される。複数の受信者がいる場合は、各受信者の電子メールアドレスが「Ｔｏ」領域に入力される。更なる実施例では、一又はすべての受信者用に「ＣＣ」又は「ＢＣＣ」領域を用いている。ステップ６２ｃでは、地球規模で唯一のメッセージＩＤ又は番号がそのメッセージに割り当てられる。ステップ６２ｄでは、会話名、メッセージの主題、といったその他の情報がヘッダに提供される。ステップ６２ｅでは、メッセージが作成された開始日／時間と、おそらくメッセージが終了する日／時間をヘッダに含めることができる。一の実施例では、ステップ６２ａ乃至６２ｅは、終了日／時間を規定することの可能性を除いて、一般的に、すべてほぼ同じ時間に生じる。その他の実施例では、ステップ６２ａ乃至６２ｅは、どの順序で生じても良い。

開始及び終了日／時間は、通常、送信デバイス１４における開始機能３６／５４と終了機能３８／５６の実行にそれぞれ一致している。しかしながら、送信者は、所定のメッセージに対して終了機能３８／５６を常に実行するわけではない。終了機能が生じると、送信者はメッセージに関連する時間ベースメディアの作成と送信を簡単に停止することができる。従って、このメッセージは、規定された終了時間／日なしで、「無期限」のままでもよい。

所定の実施例では、ステップ６２ａ乃至６２ｅは、送信通信デバイス１４で実行することができる。別の実施例では、送信通信デバイスは、メッセージヘッダ情報の一部あるいは全部をサーバ１６に送信し、このサーバでステップ６２ａ乃至６２ｅを実行している。メッセージの時間ベースメディアも、送信ユーザによるその後のレビュー用に、あるいは受信者への送信用に、サーバ１６に選択的に保存することができる。

上述した実施例には、Ｔｏ、Ｆｒｏｍ、メッセージＩＤ番号、会話名、及びメッセージ開始及び終了時間を含む様々な領域を有するメッセージヘッダが提供されている。なお、これらの領域のすべてが必要なわけではなく、又、その他の領域を具えていても良い。必須の情報は、受信者の地球規模でアドレス可能な電子メールアドレスを規定しているＴｏ、ＣＣ、又はＢＣＣ領域の一つに特定された少なくとも一の受信者である。その他の領域はすべて任意的なものである。

メッセージヘッダのフォーマットも可変である。一の実施例では、メッセージヘッダの構造は、従来の電子メールに使用されているもの、あるいは電子メールと共に使用されている表書きと同様である。別の実施例では、メッセージヘッダの構造は、受信者の地球規模でアドレス可能な電子メールアドレスを、おそらくその他のヘッダ情報と共に、ネットワーク１２に送信するのに適したものであればどのような形のものであっても良い。受信者を特定するための特定の電子メールヘッダ領域が議論されているが、受信者のアドレス情報を含む実際のヘッダ領域は、必ずしも、受信者自身の地球規模でアドレス可能な電子メールアドレスを含んでいなくともよい。この分野では良く知られているように、「表書き受信者」は、この表書き受信者が電子メールヘッダに挙げられている受信者と異なっていても、受信者の電子メールアドレスを特定するのに用いることができる。従って、ここに使用されているように、期間メッセージヘッダは、表書き情報と従来のメッセージあるいは、限定するものではないが、ＲＦＣ８２２又は５３２２に特定されたものなど、任意数の領域を含む電子メールヘッダの両方を含むように、広く解釈するべきである。更に、「アドレス」あるいは「地球規模でアドレス可能な電子メールアドレス」の用語の使用は、従来のメッセージあるいは電子メールヘッダ又はメッセージ表書きにおける使用を含めて、あらゆるアドレス方法を含むように広く解釈するよう意図されている。

所定の状況下では、ネットワーク１２は、時間ベースメディアを含むメッセージを送達することができ、これは、（ｉ）ネットワーク１２を介して受信者へ同時かつ段階的に送信することができ、（ｉｉ）時間ベースメディアが作成されて、送信ユーザによって送信されているときに、アドレスされた受信者はほぼリアルタイムでレビューすることができる。その他の状況では、メッセージはリアルタイムで送達することができない。ほぼリアルタイムでのシナリオとリアルタイムでないシナリオについて、図５Ａ乃至５Ｃをそれぞれ参照して、以下に述べる。

図５Ａを参照すると、ネットワーク１２を介して地球規模でアドレス可能な電子メールアドレスを用いて、時間ベースメディアを含むメッセージをでほぼリアルタイムで通信することができるシーケンスのフローチャート８０が示されている。このシーケンスは、ほぼリアルタイムのＲＶＸプロトコルを用いてユーザＡがユーザＢへメッセージを送っているコンテキストにおいて書かれている。上述したように、サーバ１６Ｂは、ユーザＢにＲＶＸサービスを提供しているが、ＭＸサービスは提供していない。

開始ステップ８２において、サーバ１６Ａは、時間ベースメディアを通信デバイス１４Ａによって段階的かつ同時に作成して送信されると、ほぼ同時にメッセージヘッダ（又はステップ６２ａ乃至６２ｅの一部又は全部をサーバに実行させるヘッダ情報）と、送信されるメッセージの時間ベースメディアを受信する。メッセージヘッダは、「Ｔｏ」、「ＣＣ」、又は「ＢＣＣ」領域にユーザＢの地球規模でアドレス可能な電子メールアドレス（ｕｓｅｒＢ＠ＤｏｍａｉｎＢ）を具えているので、サーバ１６Ａは、ＤＮＳプロトコルを用いてＤＮＳサーバ１８のドメインＢのＲＶＸについてルックアップを要求する（ステップ８４）。ドメインＢにＲＶＸが存在する（決定８６）ので、ルックアップ結果はポジティブである。次いで、送信者に関連するサーバ１６Ａから受信者に関連するサーバ１６Ｂへ，ＲＶＸプロトコルを用いて、時間ベースメディアが段階的かつ同時に送信される。時間ベースメディアは、２台のサーバ１６Ａと１６Ｂ間の一又はそれ以上のホップを介して送信される。各ホップで、ＤＮＳルックアップを実行して、次のホップへの送達ルートを発見し、一方で、ＲＶＸプロトコルを用いて時間ベースメディアを次のホップへ送達する。

一の実施例では、時間ベースメディアがサーバ１６Ｂに到達するときに、メディアが受信者の通信デバイス１４Ｂに同時かつ段階的に送信される。受信者は、メッセージが入ったことの通知を受け、これに応答してメッセージのメディアを段階的に受信したときにほぼリアルタイムモードでメディアの同時レビューを選択することができる。

代替の実施例では、選択的にメッセージのメディアは受信箱におかれ、受信者のデバイス１４Ｂに持続的に保存される。メッセージの持続的な保存に伴って、受信者は、メディアを受信した時あるいは保存した後の任意の時間に、メディアをほぼリアルタイムモードでレビューするという選択肢を有する。

更に別の実施例では、ユーザＢに関連するサーバ１６Ｂにある受信箱にメッセージを保存することもできる。このように、デバイス１４Ｂのユーザは、その後の任意の時間にサーバ１６Ｂの受信箱からメッセージにアクセスすることができる。更に、サーバ１６Ｂは、メッセージをファイルにカプセル化して電子メールに添付することができる。上述したように、ユーザＢにはＭＸサービスが提供されないので、ユーザＢはこのような電子メールを受信できない。しかし、ユーザが電子メールを受信できる場合は、メッセージをアタッチメントの形で送信することができる。

更に別の実施例では、ユーザの送信通信デバイス１４あるいは送信者に関連するサーバ１６Ａに配置されている送信ユーザの送信箱にメッセージのメディアを保存することができる。

図５Ｂを参照すると、ユーザＡとユーザＣ間の通信を示すフローチャート８０が再び提供されている。上述したように、サーバ１６Ｃは、ユーザＣにＭＸサービスを提供しているが、リアルタイムのＲＶＸサービスは提供していない。ユーザＡがユーザＣと通信したい場合、初期シーケンスは上述ものと基本的に同じである。サーバ１６Ａは、まず、ユーザＣの地球規模でアドレス可能な電子メールアドレス（ｕｓｅｒＣ＠ＤｏｍａｉｎＣ）が付いたメッセージヘッダ（あるいは、ステップ６２ａ乃至６２ｅを選択的に実行するのに必要なヘッダ情報）と、ユーザＡによる時間ベースメディアの段階的かつ同時送信を受信する（ステップ８２）。ＲＶＸルックアップの結果（決定８６）がネガティブであるので、サーバ１６Ａは、次に、ＤＮＳプロトコルを用いて、ドメインＣについてＤＮＳサーバ１８のＭＸルックアップをリクエストする（ステップ９０）。ポジティブな結果が出た場合（決定９２）、サーバ１６Ａは、サーバ１６Ｃにアタッチメントとしてのカプセル化した時間ベースメディアが付いた通常の電子メールを送信する（ステップ９６）。サーバ１６Ｃで、この電子メールが受信者の受信箱に入る。この電子メールは、通信デバイス１４Ｃの受信箱にも送られる。このように、受信者がＲＶＸサービスを受けていない場合は、メッセージの時間ベースメディアは、サーバ１６Ａによってネットワーク１２を介してサーバ１６Ｃに、また、場合によってはＳＭＴＰの蓄積転送手順あるいは同様の私設電子メールシステムを用いて通信デバイス１４Ｃに送信される。

図５Ｃを参照すると、ユーザＡとユーザＤ間の通信の試みを示すフローチャート８０が示されている。上述した通り、ユーザＤには、電子メールＭＸサービスも、ほぼリアルタイムのＲＶＸサービスも提供されていない。ユーザＡがユーザＤと通信したい場合、初期シーケンスは上述のものと本質的に同じである。サーバ１６Ａは、ユーザＤの地球規模でアドレス可能な電子メールアドレス（ｕｓｅｒＤ＠ＤｏｍａｉｎＤ）が付いたメッセージヘッダ（あるいは、ステップ６２ａ乃至６２ｅを選択的に実行するのに必要なヘッダ情報）と、ユーザＡによる時間ベースメディアの段階的かつ同時送信を受信する（ステップ８２）。ＲＶＸルックアップ（決定８６）とドメインＤについてのＭＸルックアップ（ダイヤモンド９２）が両方ともネガティブであるので、エラーメッセージが生成され（ステップ９４）、メッセージを送達できない（ステップ９６）。様々な実施例で、メッセージの時間ベースメディアが、送信通信デバイス１４Ａ、サーバ１６Ａ、あるいは両方に保存されている。このメッセージは後に、ＲＶＸ及び／又はＭＸサービスがユーザＤに提供されたときに送信することができる。

図５Ｃに関して述べたシナリオは、通常、間違った電子メールドメイン名が受信者に提供された場合に生じる。送信者が無効の地球規模でアドレス可能な電子メールドメイン名を用いてメッセージを送信しようとすると、エラーメッセージが生じる（ステップ９４）。電子メールアドレス中の正しいドメイン名が提供されている場合は、次いで、ＲＶＸプロトコル又は、ＭＸサービスを用いた電子メールのアタッチメントを用いて、メッセージを送信することができる。

代替の実施例では、通信デバイス１４Ａ乃至１４Ｃは、ピアツーピア（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）構造に構成することができる。この構成によれば、少なくとも送信通信デバイス１４は、ルックアップ機能を実行するのに中間サーバ１６の助けを借りることなく、ＤＮＳサーバ１８上で直接ＲＶＸ及び／又はＭＸルックアップを実行することができる。通信デバイス１４は、メッセージのメディアを他の通信デバイスに直接通信することもできる。受信者がＲＶＸ及び／又はＭＸドメインのメンバーであるかないかによって、送信通信デバイス１４Ａは、（ｉ）メッセージの時間ベースメディアをネットワーク１２を介して受信者に段階的かつ同時に送信する；（ｉｉ）メッセージの時間ベースメディアをファイルにカプセル化して、ＳＭＴＰ又は同様の私設プロトコルにアタッチメントとしてファイルを含む電子メールを受信者に送信する；あるいは（ｉｉｉ）無効の地球規模でアドレス可能なユーザ名又はドメイン名を電子メールアドレスに使用した場合、及び／又は、受信者にＭＸサービスが提供されない場合に、エラーメッセージを受信する。

図５Ｄを参照すると、ピアツーピアの実施例を示すフローチャート１００が示されている。開始ステップ１０１では、送信通信デバイス１４が「受信通信デバイス１４と通信したい旨を表示している。決定ダイアモンド１０２において、送信者の通信デバイス１４が、受信者の地球規模でアドレス可能な電子メールのＤＮＳルックアップを実行して、ピア受信者がＲＶＸサービスを受けているかどうかを決定する。ルックアップの結果がポジティブである場合に、送信通信デバイス１４を用いて作成した時間ベースメディア（ステップ１０３）が、ＲＶＸルックアップによって規定された送達ルートを用いて受信者に段階的かつ同時に送信される（ステップ１０４）。決定ダイアモンド１０５においては、リアルタイム通信が設定されているかどうかを決定する。設定されている場合は、メディアを受信した（ボックス１０６）ときに受信者の通信デバイス１４に、送信されたメディアが段階的かつ同時に表示される。ほぼリアルタイムの通信が設定されていない場合は、メッセージのメディアは、受信者のデバイス１４、受信者に関連するサーバ１６、あるいはおそらくその両方にある受信者の受信箱（ボックス１０７）におかれる。受信者が通信できない、ネットワークの範囲外である、あるいはほぼリアルタイムモードでメッセージをレビューしたくないことを表示している、といったいくつかの理由で、ほぼリアルタイムの通信は受信者には生じない。

一方で、受信者がＲＶＸサービスを受けていない場合（決定１０２）、受信者がＭＸドメインサービスを受けていれば、メッセージのメディアは電子メールへのアタッチメントの形で送達される。時間ベースメディアはファイルにカプセル化されて、電子メールに添付される（ステップ１０８）。メッセージが完成したら、ＭＸルックアップ結果によって決まったルートを使用して電子メールが送信される（ステップ１０９）。一の実施例では、送信通信デバイス１４が電子メールクライアントを局所的に稼働している場合、この電子メールを送信ピアから直接送信することができる。電子メールクライアントが稼働している場合は、受信者ピアデバイス１４で、受信者のために電子メールクライアントが稼働しているサーバ１６で、あるいは受信ピア１４とサーバ１６の両方で、この電子メールを受信することができる。両方のピアが電子メールクライアントを稼働している場合は、送信通信デバイス１４から受信通信デバイス１４へ電子メールのアタッチメントという形でメディアを送信することができる。これは、送信者ピアとは対照的にサーバが受信者にボイスメッセージを電子メールで送る公知の留守番電話メッセージシステムと異なる。所定の実施例では、以下に詳細に述べるように、時間ベースメディアを含むウエブページにリンクすることによってアタッチメントを差し替える又は増やすことができる。

図４Ａ、４Ｂ及び５Ａ乃至５Ｃを参照して上述した議論は、本発明の所定の態様を説明するために簡略化されている。実際には様々な方法で実装を変更できると解される。例えば、サーバ１６Ａが電子メールアドレスを受信するたびに、サーバ１６Ａは、まず受信者のドメイン（すなわち、ドメインＡ、ドメインＢ、又はドメインＣ）がサーバ１６Ａの一又はそれ以上のローカルドメイン内にあるかどうかを決定する。ローカルドメイン内にない場合は、図５Ａ、５Ｂ、及び５Ｃについて上述した手順をそれぞれ実行する。一方、受信者のドメインがサーバ１６Ａのローカルドメイン内にある場合は、サーバ１６Ａはメッセージを、（ｉ）受信者がリアルタイムの通信サービスを受けている場合はリアルタイムで、あるいは（ｉｉ）受信者がＭＸサービスを受けている場合は電子メールのアタッチメントとして、リアルタイムサービスではなく送達する。更に、サーバ１６Ａは、どんな場合でもＤＮＳルックアップを実行する必要がない。良く知られているように、以前のＤＮＳルックアップ結果をキャッシュに入れておいて、新しいＤＮＳルックアップを実行するときではなく、むしろ、受信者の電子メールアドレスを受信するたびにそれを使用することができる。

図６を参照すると、サーバ１６Ａ（図５Ｂのボックス９８）で電子メールのアタッチメントにカプセル化した、あるいは送信デバイス１４Ａ（図５Ｄのボックス１０７）からの、時間ベースメディアを送信するシーケンスを示すフローチャート１１０が示されている。いずれの場合も、ユーザＡが生成した時間ベースメディアはファイルにカプセル化され（ステップ１１２）、例えば、終了機能３８／５６が実行されて、メッセージが完成したときに、電子メールに添付される（ステップ１１４）。終了機能３８／５６が実行されない場合は、所定の時間経過後、新たに時間ベースメディアを作成することなく、メッセージの終端にデフォルトの宣言がなされる。メッセージの時間ベースメディアが完成すると、終了機能３８／５６を実行することによって、あるいはデフォルトによって、アタッチメントの電子メールがサーバ１６Ａによって、あるいは通信デバイス１４Ａによって、従来の電子メールと同様にＳＭＴＰ又は同様の私設プロトコルを用いてネットワーク１２を介して受信者のＭＸルックアップ結果へ送信される（ステップ１１６）。

サーバ又は上述のピアツーピアモデルのいずれかによって、まずＲＶＸルックアップ結果を用いて時間ベースメディアを送達する。ＲＶＸの試みが失敗した場合、ＭＸ結果をバクアップとして用いる。この構成によれば、アタッチメント及び／又はウエブリンクに含まれる時間ベースメディアを有する従来の電子メールを用いて、受信者にＲＶＸサービスが提供されていない状況で、メディアを送達できる。電子メールは、サーバ、あるいは送信デバイスのいずれかで作成することができる。

ＩＩ．送達オプション
図７を参照すると、本発明の別の実施例によるネットワーク１２を介した時間ベースメディアを送達する図が示されている。この実施例によれば、ネットワーク１２は、少なくとも一の例外を除いて、図１に関して上述したものと基本的に同じである。サーバ１６Ａ乃至１６Ｃの一又はそれ以上は、上述のＲＶＸ及び／又はＭＸサービスを提供することに加えて、ウエブサーバとして構成されている。この実施例では、メッセージがユーザに送信されると、ユーザはＵＲＬリンクを含む電子メールを各サーバ１６から受信する。ユーザの通信デバイス１４上で稼働しているウエブブラウザを介してユーザがリンクを選択する場合は、適宜のウエブサーバ１６がウエブページを提供して、受信者がメッセージにアクセスしてレビューできるようにする。また、提供されたウエブページは、リアルタイムで又は録画モードでメッセージのメディアをレビューする、ライブに追いつく、ライブの会話を止める、会話の頭にジャンプする、会話の以前のある時点にジャンプする、より早い表示、より遅い表示、別の会話間のジャンプ、その他といった、様々な表示オプションを提供することができる。図中、ウエブサーバ機能は、サーバ１６Ａ、１６Ｂ及び１６Ｃによって提供されるサービスの一つとして示されている。代替の実施例では、１６Ａ、１６Ｂ、又は１６Ｃ以外のネットワーク１２上の一又はそれ以上の別のサーバ（図示せず）を用いてウエブサーバ機能を実装することができる。

ＩＩＩ．電子メールプロトコルの変更及び段階的電子メール
上述したメッセージは、地球規模でアドレス可能な電子メールアドレスと、送達ルートを決めるＤＮＳインフラストラクチュアを用いてルーティングを行っており、一方で、ＲＶＸプロトコルを使用してほぼリアルタイムでの時間ベースメディアを実際に送達している。現在規定されており、使用されているＳＭＴＰ標準やその他の私設電子メールプロトコルは蓄積転送プロトコルであるが、ある種の改変を行って、ＳＭＴＰとその他の私設電子メールプロトコルをＲＶＸメッセージプロトコルとして用いて本出願で意図している時間ベースメディアをほぼリアルタイムで送達することができる。従来の電子メールでは、電子メールを送信する前に、メディアコンテンツが完全でありパッケージングされていなければならない。受信側では、受信者がレビューする前に、電子メールが全部受信されていなければならない。以下に詳細に説明するように、ＳＭＴＰ、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ又はその他の私設電子メールプロトコルを使用して、メディアをほぼリアルタイムで送信できる「段階的」電子メールを作成することができる。

現存の電子メールインフラストラクチュアは、ＳＭＴＰ、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅあるいはその他の私設電子メールプロトコル（以下、一般的に、電子メールプロトコル又はプロトコルという）を送信側で使用する方法を変更すること、及び、電子メールが受信側のサーバから取り出される方法を変更することによって、時間ベースメディアのほぼリアルタイムで送信をサポートするのに使用できる。現在の電子メールプロトコルは、電子メールプロトコルの通常の使い方であるにもかかわらず、送達が開始される前に、メッセージ全体が送信可能であることをそれほど厳しく要求していない。従って、標準ＳＭＴＰ、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅあるいはその他の私設電子メールプロトコルを用いて、メディアが作成されるときに、時間ベースメディアを段階的に送達することができる。

電子メールは、通常、ＰＯＰ又はＩＭＡＰのようなアクセスプロトコルを介してユーザのデバイスに送達される。これらのプロトコルは、メッセージが到達しているときのメッセージの段階的な送達をサポートするものではない。しかしながら、これらのアクセスプロトコルに簡単な改変を行うことにより、メッセージのメディアがネットワークを介して到達しているときに受信者に段階的にメッセージを送達することができる。このような改変は、クライアントがメッセージをダウンロードできるようになる前に、現在のフルサイズの電子メールメッセージを電子メールサーバが知る必要性を取り除くことを含む。この制限を除くことによって、電子メールメッセージの時間ベースメディアがネットワークを介してサーバで受信されるときに、クライアントは電子メールメッセージの時間ベースメディアのダウンロードを開始することができるようになる。

図８を参照すると、上述した電子メールプロトコルのいずれかを用いた従来技術の電子メール１２０の構造が示されている。電子メール１２０は、ヘッダ１２２と本体１２４を具える。ヘッダは、「Ｔｏ」（あるいは、ＣＣ及び／又はＢＣＣ）領域と、「Ｆｒｏｍ」領域、独自の地球規模のＩＤ番号、主題領域、選択的アタッチメント、及び日付／時間スタンプを具えている。電子メールの本体１２４は、送信するべきメディアを具えており、これは、通常、タイプしたメッセージ、場合によっては、添付ファイル（例えば、文書又は写真）である。完成すると、電子メールが送信される。ＤＮＳルックアップを行って、電子メールが受信者にルーティングされる。従来の電子メールは「静的」である、すなわち、アタッチメントを含む電子メール本体が、送信が開始すると固定される。メディアが作成されているときに、従来の電子メールで時間ベースメディアを段階的及び同時に送信する方法はない。従来技術の電子メール１２０は、従って、ほぼリアルタイムでの通信をサポートすることができない。

図９を参照すると、本発明による電子メール構造１３０が示されている。電子メールメッセージ１３０は、ほぼリアルタイムでの通信に使用されている。電子メール１３０は、「Ｔｏ」領域（場合によっては、ＣＣ及び／又はＢＣＣ領域）を含むヘッダ１３２と本体１３４を具えている。しかしながら、電子メール１３０の構造は、少なくとも二つの点で従来技術の電子メール１２０と異なる。まず、ヘッダ１３２は、電子メールの開始日／時間と終了日／時間を具える。電子メール１２０が送信される日／時間を単にスタンプすることと反対に、開始及び終了時間を電子メール１３０に関連付けることで、第２の差異を認識することができる。電子メール１３０が作成され、送信者が受信者の地球規模でアドレス可能な電子メールアドレスを規定した後、ルーティング用のＤＮＳルックアップがすぐに実行される。ほぼ同時に、時間ベースメディアが作成される。時間ベースメディアが作成されると、ＳＭＴＰ、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ又はその他のタイプの電子メールプロトコルのストリーム特性を用いて、ホップからホップへと、このメディアがＤＮＳルックアップ結果へ段階的かつ同時に送信される。従って、電子メール１３０の本体１３４は「段階的」である。電子メール１３０に関連する時間ベースメディアは動的に作成されるので、時間ベースメディアは、必要に応じてネットワーク上でホップからホップへと、受信者の電子メールサーバへ同時かつ段階的に送信される。電子メール１３０が複数受信者に送信される場合は、Ｔｏ、ＣＣ、又はＢＣＣ領域で認識されるかどうかにかかわらず、上述のプロセスが各々の受信者について繰り返される。

ＤＮＳルックアップは、送信者に関連する電子メールサーバによって電子メールプロトコルセッションを開始することによって、受信者の電子メールアドレスが決定されると直ちに実行される。このことは、従来の電子メール１２０と異なっている。従来の電子メールでは、電子メールプロトコルセッションは、通常、電子メールが全部構成されて送信者が「送信」機能を実行した後にのみ開始するからである。この結果、時間ベースメディアが作成されているときに、時間ベースメディアの段階的かつ同時送信の前にあるいは同時に、送達ルートが発見される。セッションが設定される前に時間ベースメディアが作成される場合は、メディアが作成されているときに、時間ベースメディアを一次的に又は連続的に保存することができる。次いで、電子メールサーバでプロトコルセッションが一旦設定されると、この保存されたメディアをストレージから段階的に送信することができる。

電子メール１３０の終了日／時間は、規定されていても良いし、無期限であっても良い。送信者が終了機能３８／５６を通信デバイス１４で実行すると、電子メール１３０の終了時間が決まる。終了機能３８／５６が実行されないと、次いで、電子メール１３０の期間が「無期限」となり、規定された終了日／時間を有する必要がなくなる。従って、無期限の電子メール１３０は、通常、メディアが作成されていない所定の時間経過後に、デフォルトによって終了する。

要約すると、段階的電子メール１３０は、ＳＭＴＰ、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ又はその他の私設電子メールプロトコルを用いて、上述の改変を実行することによって送信することができる。同様に、受信者は、ＰＯＰ、ＩＭＡＣその他といったアクセスプロトコルを改変することによって、段階的電子メール１３０の時間ベースメディアを同時かつ段階的にレビューすることができる。合わせて、これらの改変によって、電子メールアドレス、電子メールプロトコル、ＤＮＳ、及び時間ベースメディアのリアルタイムでの通信をサポートする現存の電子メールインフラストラクチュアを使用することができる。

ＩＶ．リアルタイムの音声及びその他の時間ベースメディアのための受信者アドレスの事後接続
通信のコンテキストにおいて、受信者アドレスは、そのアドレスについてのネットワークを介した有効送達経路が決まると、「接続した」と記載される。ＰＳＴＮを介する従来の電話は、ダイアルした電話番号、すなわち、本件の場合は「受信者アドレス」を用いて、メディアを受信者に送信することができる前に受信者に対してアクティブ経路を（すなわち、回路接続）を設定するので、「初期接続」を使用しているといえる。この接続がなされた後にのみ、発呼側は話すことができ、メディアを送信することができる。呼び出しが一又はそれ以上の電話番号になされているかどうかにかかわらず、あるいはその発呼が留守番電話システムに送信されているかどうかにかかわらず、通常、接続は何らかの言葉が送信される前に生じる。受信者のアドレスのネットワーク上のアクティブな送信先への接続は、メディアを送信する前に生じるので、「初期」接続と呼ばれる。反対に、電子メールは「遅延」接続を使用するといわれている。人は、電子メールメッセージを書いて、そのメッセージを受信者が使い切るであろうデバイスに接続させることなく、ネットワークを介してそのメッセージを送信する。これに代えて、電子メールが作成された後、受信者の電子メールアドレスを用いて受信者へその電子メールをルーティングして、受信者が選択したデバイスで選択した時にレビューを行うようにする。

メッセージ（図４Ａ、４Ｂ、及び５Ａ乃至５Ｄについて述べたような）又は上述した電子メール１３０を用いて、ユーザは、地球規模でアドレス可能な電子メールアドレスを用いて受信者にアドレスし、次いで、直ちに話し始める、あるいは時間ベースメディアを作り始める。上述した通り、受信者の電子メールアドレスが決定されるやいなや、送達ルートを規定するＤＮＳルックアップが直ちに行われる。ほぼ同時に、入手可能な時間ベースメディアを、ネットワーク１２を介して受信者に段階的かつ同時に送信する。従って、アクティブな送達ルートの発見と、時間ベースメディアの段階的かつ同時作成、送信、及び送達は、時間ベースメディアが作成されるのとほぼ同時に行われる。時間ベースメディアの作成開始後に実際の送達ルートが発見される場合は、このメディアを一次的かつ継続的に保存しておくことができ、アクティブ送達ルートが決まったらストレージから送信するようにしても良い。ユーザが会話を始める前には、ネットワーク接続あるいは回路を設定する必要がない。従って、ＤＮＳと電子メールのインフラストラクチュアを用いた時間ベースメディアを連続的かつ同時に送信する能力によって、以前は不可能であった態様で、音声とその他の時間ベースメディアに関して、受信者アドレスの遅延接続が可能となる。

Ｖ．会話
上述のメッセージ通信方法及びシステム（図１乃至３、４Ａ乃至４Ｂ、及び５Ａ乃至５Ｄ）は、送信ユーザと受信ユーザとの間の会話をサポートすることができる。二又はそれ以上のパーティが、ＶｏＩｐ、ＳＩＰ、ＲＴＰ、あるいはスカイプなど上述したＲＶＸプロトコルを用いて往復会話を行う時に、この会話はライブで、ほぼリアルタイムモードで行うことができる。ＲＶＸプロトコルによって、ユーザは時間ベースメディアをほぼリアルタイムで通信できるが、受信者には、上述したＣＴＰ又は同期プロトコルを用いるなどして時間ベースメディアをほぼリアルタイムでレビューすることを要求しない場合は、会話は（ｉ）ほぼリアルタイムモードで；（ｉｉ）時間シフトモードで；又は（ｉｉｉ）これらの二つのモード間を継ぎ目なく移行させて、行うことができる。

応答メッセージは、様々な方法でルーティングすることができる。例えば、ＣＴＰ及び同期プロトコルを用いて、参加者の地球規模でアドレス可能な電子メールアドレスを、ＤＮＳルーティング情報と共に、ストリーミングメディアに埋め込むようにしても良い。応答が送信される場合、埋め込まれたアドレスとルーティング情報が応答メッセージ用に使用される。代替的に、会話ＩＤ又は、参加者の地球規模で認識可能な電子メールアドレスをＤＮＳルーティング情報と共に示しているストリーミングメディアに含まれるその他のポインタを使用して、メッセージをルーティングすることができる。更に別の代替例では、参加者が明確にアドレスされることができ、応答メッセージにはＤＮＳルックアップが行われる。

上述した段階的電子メール１３０の実施例は、会話を実行するのにも使用することができる。会話が開始されると、電子メールクライアントが稼働していれば送信通信デバイス１４で、送信者のために電子メールクライアントが稼働していればネットワーク上のメールサーバで、送信者によって電子メール１３０が作成される。段階的電子メール１３０のメディアが作成されると、ＤＮＳによって規定されたルートを用いて、このメディアが受信者へ段階的に送信される。応答するには、受信者のデバイス１４で、あるいは、受信者のために電子メールクライアントを稼働しているサーバで、受信者のために段階的電子メール１３０が作成される。元の送信者の電子メールアドレスは、返信電子メール１３０の「Ｔｏ」領域（あるいは、ＣＣ及び／又はＢＣＣ領域）に自動的に挿入され、ＤＮＳルックアップが行われる。返信電子メールに関連するメディアは、メディアが作成されるとすぐに、ＳＭＴＰ、Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｈａｎｇｅ又はその他の私設電子メールプロトコルのストリーミングを用いて送信することができる。時間ベースメディアが電子メールクライアントで段階的に受信されると、受信者はほぼリアルタイムで時間ベースのメディアを同時にレビューすることができる。

実施例に関係なく、「応答」機能は、様々な方法で実装することができる。例えば、受信者は、例えば、あらかじめ決められた音声又はキーストロークコマンドを用いる、あるいはタッチスクリーンを介してコマンドを入力するなどして、受信者の通信デバイス１４に明確な応答コマンドを入力することができる。代替的に、応答メッセージ又は電子メールは、入ってくるメッセージ又は電子メール１３０に応答して受信者が話し始めるあるいは別の時間ベースメディアを生成し始めたときに、自動的に生成することができる。応答メッセージが自動的に作成される場合は、入ってきたメッセージから元の送信者の電子メールアドレスが抽出され、応答メッセージのアドレッシングに使用される。

更に別の実施例では、参加者間の会話のメッセージを送信及び受信するのに使用するＲＶＸプロトコルが同じものである必要はない。例えば、あるタイプの共通する会話識別子が使用されていれば、一方の参加者がＣＴＰ、同期、段階的電子メール、ＶｏＩＰ 、ＳＩＰ、ＲＴＰ又はスカイププロトコルの一つを用いてメッセージを送信し、他方の参加者がここに挙げたプロトコルと異なるプロトコルを使用することができる。送信に使用するプロトコルに関係なく、独自の会話識別子を用いて、メッセージを互いにリンクさせる、あるいはスレッドさせることができる。

更なる様々な実施例では、様々な基準を用いて会話を規定することができる。例えば、会話は、人の名前（例えば、ｍｏｍ、ｓｐｏｕｓｅ、ｂｏｓｓ、 など）、あるいは人々の共通グループ（例えば、バスケットボールチーム、セールスチーム、ポーカー仲間、その他）によって規定することができる。また、会話は、ファンタジィフットボールリーグ、ＡＣＭＥコーポレートアカウント、又は「ｓｋｕｎｋ ｗｏｒｋｓ」プロジェクトといった、トピックで規定することもできる。会話を規定するのに使用した文脈上の属性に関係なく、特定の会話のメッセージを互いにリンクするあるいは組織化する能力が、持続的なあるいは進行中の会話の観念を作成する。従来の電話コールでは、通常パーティが受話器を切ることで会話が終了する。ここには、同じパーティ間での複数の電話による会話で話した言葉を文脈上リンクさせる、組織化する、あるいは保存する方法はない。これと反対に、ここで規定されている会話は、共通の属性によって互いにリンクされた共通のメッセージセットである。メッセージが会話に加わる限り、会話が続く、あるいは進行する。この属性によって、参加者は任意の時間に会話に参加することができるようになる。例えば、ユーザは、会話リストの中から一の会話を選択して、選択した会話にいつでもメッセージを寄与することができる。次いで、このメッセージをすべての会話参加者に送信する。従って、メッセージは、会話が最初に始まったときに、あるいは入ってくるメッセージに応答して送信される必要はない。

ＶＩ．実装に関する実施例
図１乃至３、４Ａ乃至４Ｂ、及び５Ａ乃至５Ｄを参照して説明したメッセージング方法と、段階的電子メール１３０は、様々な方法で実装することができる。例えば、携帯電話及びその他の移動通信サービスプロバイダは、メッセージ及び／又は段階的電子メール１３０のいずれかを用いて動作するピアツーピア移動通信デバイスをユーザに提供する。更に、これらのサービスプロバイダは、非ピアツーピア通信デバイスからメッセージ及び／又は電子メール１３０を受信するサーバ１６のネットワーク１２を維持して、メッセージを作り、ＤＮＳルックアップ動作を実行し、可能な複数ＲＶＸプロトコルのいずれか一つを用いてメッセージの時間ベースメディアをルーティングする。更に別の実施例では、メッセージング及び段階的電子メール１３０の方法は、従来の電話、移動電話又は携帯電話、ラジオ、移動型、デスクトップ型、及びラップトップ型コンピュータに装填し、これで実行するように意図されたソフトウエアアプリケーションに埋め込むことができる。これらの場合、アプリケーションによって、デバイスがここに述べたようなメッセージと段階的電子メール１３０を送信し、受信し、処理することが可能となる。更に別の実装例では、電子メールクライアントを、段階的電子メール１３０を作り、受信し、処理するように改変する事ができる。電子メールクライアントは、代替的に、インターネット又はその他のネットワーク上のサーバに、送信あるいは受信デバイスに、あるいは両方に、あってもよい。

上述した電子メール方法は、一般的には、単一送信者と単一受信者（図４Ａ乃至４Ｂ及び５Ａ乃至５Ｄ）あるいは単一受信者への電子メール１３０のコンテキストで説明しているが、メッセージ及び／又は電子メール１３０は、複数パーティへ同時に送信できると解するべきである。各受信者は、上述したように、そのステータスによって、メッセージ又は電子メールを受信したり、しなかったりする。上述の米国出願により詳細に記載しているように、メディアは、ライブについてゆく、ライブの会話を休止する、会話の頭にジャンプする、会話の中の以前のある時点にジャンプする、より速く表示する、より遅く表示する、異なる会話の間にジャンプする、その他といった、様々な表示オプションを用いて表示することができる。メッセージ及び／又は電子メールに交換された時間ベースメディアは、音声あるいは画像だけに限定されない。更に、時間ベースメディアは、メディアを作ったものと違う形式で受信者に送達するようにしても良い。例えば、ボイスメッセージをテキストファイルに変更することができるし、英語で書かれたメッセージを受信者に送達する前に別の言語に翻訳することもできる。センサデータ、ＧＰＳ、あるいは位置情報など、時間によって変化するメディアを送信することができる。本発明は、特定の実施例を参照して特別に示す説明したが、当業者は開示した実施例の形式及び詳細の変更を発明の精神又は範囲から外れることなく行うことができると解される。従って、本発明は、特許請求の範囲に記載されているように、本発明の真の精神と範囲内にあるすべての変形及び均等物を含むと解されることを意図している。

Claims (8)

1. 通信ネットワーク上のノードを介して時間ベースのメディアを含むメッセージを受信者に順次送信するように構成した通信デバイス上で行われる方法において：
   前記通信デバイスでメッセージを作成するステップであって、当該メッセージがメッセージの受信者に関連する識別子を含むメッセージヘッダと、前記メッセージに関連する時間ベースのメディアを搬送するメッセージ本体とを有するステップと；
   前記識別子が規定されると、前記メッセージヘッダを前記通信ネットワーク上のノードに順次送信するステップであって、当該ネットワーク上のノードが前記識別子を用いて前記メッセージを前記通信ネットワークで前記受信者へ送達するための少なくとも部分的な送達ルートを発見する、ステップと；
   前記時間ベースのメディアが生成されて、前記メッセージ本体に動的に加えられ、前記メッセージが完成する前に、前記通信ネットワーク上のノードに前記メッセージ本体を順次送信して、前記ノードが前記少なくとも部分的に発見した送達ルートを通って前記受信者へ前記メッセージを順次送信することができるステップと；
   を具えることを特徴とする方法。
2. 請求項１に記載の方法において、前記受信者への送達ルートが、前記受信者に関連する一又はそれ以上の通信デバイスへの送達ルートであることを特徴とする方法。
3. 請求項１に記載の方法が更に、前記通信ネットワーク上の前記通信デバイスで、前記受信者によって生成及び送信された時間ベースのメディアを含む入力メッセージを順次受信するステップを具えることを特徴とする方法。
4. 請求項３に記載の方法が更に、前記入力メッセージの時間ベースのメディアが順次受信されると、前記入力メッセージの時間ベースのメディアを順次保存するステップを具えることを特徴とする方法。
5. 請求項３に記載の方法が更に：
   （ｉ）前記入力メッセージの時間ベースのメディアが順次受信されるときのほぼリアルタイムモード；及び
   （ｉｉ）前記入力メッセージの時間ベースのメディアをストレージから取り出してレンダリングすることによる時間シフトモード；
   の両方で前記入力メッセージの時間ベースのメディアを選択的にレンダリングするステップを具えることを特徴とする方法。
6. 請求項１に記載の方法が更に、前記通信デバイスと前記受信者との間でリアルタイム通信を可能とするステップを具えることを特徴とする方法。
7. 請求項１に記載の方法が更に、前記通信デバイスを用いて、以下のタイプの通信：
   （ｉ）全二重通信；
   （ｉｉ）半二重通信；
   （ｉｉｉ）時間シフト音声メッセージ；及び
   （ｉｖ）リアルタイム音声通信；
   を可能にするステップを具えることを特徴とする方法。
8. 通信ネットワークを操作する方法において：
   送信者からのメッセージをサーバで順次受信するステップであって、このメッセージが、当該メッセージの受信者に関連する識別子を含むメッセージヘッダと、時間ベースのメディアを含むメッセージ本体を有するステップと；
   前記メッセージヘッダがサーバで受信されるときに、前記メッセージヘッダに含まれる前記識別子のルックアップ結果を用いて、前記受信者への少なくとも部分的な送達ルートを発見するステップと；
   前記時間ベースのメディアが前記サーバで受信され、前記通信ネットワーク上の少なくとも部分的に発見された前記受信者への送達ルートが発見されると、前記メッセージ本体に含まれる時間ベースのメディアを順次送信するステップと；
   を具え、前記メッセージの時間ベースのメディアが全部受信される前に、前記受信したメッセージの時間ベースのメディアの順次送信が開始することを特徴とする方法。

Images