モバイルメッセージングシステムおよび方法
モバイル装置を用いたメッセージングのためのシステムおよび方法、より具体的には、モバイル装置を用いて複数のメディアをメッセージングするためのシステムおよび方法が提供される。一つの側面において、マルチメディアメッセージングＭＭＳ（たとえば、テキスト、画像、ビデオ、および／または音声を用いたメッセージング）を通して、モバイルユーザが進行中の方法で他の装置のユーザと共働することを可能にするシステムおよび方法が提供される。メッセージが、メタ情報に基づいてたとえば検索および／または格納されることと、マルチメディアコンテンツの将来の参照、改定、および／または再利用のためにアクセスされることが可能になる。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の引用）
本出願は、２００４年９月２１日に出願された米国仮特許出願第６０／６１１，７４６号、および２００５年５月２６日に出願された米国仮特許出願第６０／６８５，３０４号の利益を主張するものであり、参照によりその全体が本明細書に援用されている。
【０００２】
（発明の分野）
本発明の実施形態は、モバイル装置（たとえば携帯電話およびＰＤＡ（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ））を用いたメッセージングのためのシステムおよび方法に関し、より具体的には、モバイル装置を用いてマルチメディアをメッセージングするためのシステムおよび方法に関する。
【背景技術】
【０００３】
従来、モバイル装置を用いてマルチメディア（たとえばテキスト、画像、ビデオ、および音声）をメッセージングすることは扱いにくく、多くの場合は不可能である。たとえば、ショートメッセージサービス（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）（ＳＭＳ）は、１６０文字以内のテキストメッセージの送信に限定される。マルチメディアメッセージングサービス（Ｍｕｌｔｉｍｅｄｉａ Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅ）（ＭＭＳ）はテキストならびに他のメディアの送信を可能にする一方で、ＭＭＳは、メッセージが受信者に配信された後における送信者および受信者からの遠隔によるメッセージの格納である持続性に欠けている。特に、メッセージがＭＭＳを介して配信された後、配信を担うサーバは、たとえばマルチメディアコンテンツの後日の参照または再利用のためのメッセージのコピーを保持しない。結果的に、モバイルユーザがＭＭＳの使用を通して進行中の方法で互いに共働する能力は、著しく限定される。さらに、インターネットプロトコル（ＩＰ）チャネルを介して（たとえばＩＰマルチメディアサブシステム（ＩＭＳ）を介して、またはモバイル装置上で稼動するブラウザを通して）モバイル装置にマルチメディアを配信するための従来のアプローチは、配信時間およびネットワーキング信頼性の両方について大いに改善されることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
したがって、モバイル装置を用いてメディアをメッセージングするための従来のシステムのこれらや他の欠点を対処するモバイルメッセージングシステムおよび方法を提供することが望ましくあり得る。
【課題を解決するための手段】
【０００５】
（発明の要旨）
本発明の実施形態は、モバイル装置を用いて複数のメディアをメッセージングするための改善されたシステムおよび方法に関する。モバイルユーザに提供されるメッセージング経験は、マルチメディア共働を容易にすること、コンテンツ配信および／またはネットワーキング信頼性を向上させること、および／またはエンドユーザ機能を強化することによって改善される。たとえば、モバイルユーザのメッセージング経験は、従来は使いやすさおよび機能の両方の点でモバイル装置のメッセージング経験に勝っていたデスクトップおよび非モバイル装置に提供されるメッセージング経験に匹敵するかまたは勝るようにされることができる。
【０００６】
一つの側面において、マルチメディアメッセージング（たとえば、テキスト、画像、ビデオ、および／または音声を用いたメッセージング）を通して、モバイルユーザが他の装置のユーザと進行中の方法で共働することを可能にするシステムおよび方法が提供される。たとえば、一実施形態において、メッセージの送信者および受信者から遠隔でメッセージおよび関連メタ情報を「ドキュメント」（あるいはドキュメントの部分）として存続する（すなわち格納する）前に、モバイルおよび非モバイル装置によって生成されたマルチメディアメッセージは、識別するメタ情報（たとえば、作者、日付、時間、および／または場所）によってタグがつけられる。ドキュメントは、メッセージが受信者に通信された後でさえも、遠隔記憶装置において保持される。このことは、メッセージが、メタ情報に基づいてたとえば検索および／または格納されることと、マルチメディアコンテンツの将来の参照、改訂、および／または再利用のためにアクセスされることを可能にする。さらに、送信者および受信者は、ドキュメント参加者として指定され得、これによって参加者間のメッセージングコミュニティを作り上げる関連性を確立する。同じコミュニティのメンバー（すなわち同じドキュメントへの参加者）は、たとえば、コミュニティの他のメンバーとリアルタイム通信を開始する能力（たとえば両方のユーザが参加するドキュメントへの参加者のリストから他のユーザのオンラインＩＤを選択するユーザ）、コミュニティのすべての他のメンバーにメッセージを送信する能力、およびどのコミュニティメンバーがコミュニティの基盤を形成するドキュメントに現在アクセスしているかを判断する能力など、そのコミュニティに特有の種々の機能を提供され得る。したがって、複数のドキュメントに参加するユーザは、複数のメッセージングコミュニティのメンバーであり得る。
【０００７】
本明細書で使用されているように、一つのドキュメントは、送信者と受信者との間で通信される、および通信後に送信者および受信者から遠隔で格納される、一つ以上の種類のマルチメディア（およびオプションとして関連するメタ情報）を含む。ドキュメントは、単一の場所において遠隔で、分散型配置において、または任意の他の適切なアプローチにおいて、格納され得る。好ましい一実施形態において、各ドキュメントは「フラグメント」と呼ばれる一つ以上の関連するメッセージを含む（たとえば、送信者から一人以上の受信者へのマルチメディアメッセージと、送信者を識別するメタ情報とを含む第１のフラグメント、および受信者からのマルチメディア応答と、受信者を識別する情報とを含む追加のフラグメント）。同じドキュメントのフラグメントが遠隔サイトに存続させられた順番は、フラグメントについてのメタ情報内にキャプチャされ得る。このメタ情報（たとえば時間スタンプ）は、たとえば、対話が生じた順番またはユーザが定義した順番においてドキュメント参加者間のマルチメディア対話を再生するために使用され得る。オプションとして、ドキュメントへのアクセス権を有するユーザによる選択が可能な履歴ファイルもまた提供され得る。履歴ファイルは、たとえばフラグメントが遠隔サイトに対して存続させられた順番において、（たとえば関連メタ情報によって）ドキュメントのフラグメントを識別するコンテンツの表を含み得る。ユーザは、ドキュメントにおける対応するフラグメントにナビゲート（ｎａｖｉｇａｔｅ）するために、コンテンツの表からエントリを選択し得る。
【０００８】
別の実施形態において、格納されたドキュメントに異なる装置のユーザが同時に書込み（たとえば追加または変更）をすることを可能にする単一付加機能が提供される（たとえば装置から遠隔に格納されたドキュメントに対してフラグメントを存続させる）。これは、所定の時間において単一のユーザのみが格納されたドキュメントへのアクセス／変更ができて、コンテンツへの書込みアクセスをリクエストする次のユーザが待ち行列に追加されるという、格納されたコンテンツへの許可を与えるためのロッキングメカニズムを使用する従来のアプローチとは対照的である。
【０００９】
別の実施形態において、ドキュメントへの参加者に関連するパーティ（たとえばドキュメント参加者の「友人」または「友人の友人」）がドキュメントおよびそれに関連するマルチメディアコンテンツ（およびオプションとしてメタ情報）にアクセスすることを可能にするソーシャルネットワーキングプロトコルが提供される。そのようなパーティもまた、ドキュメントに付加された応答をパーティがメッセージとして送るとき、ドキュメント参加者になり得る。
【００１０】
別の実施形態において、マルチメディアメッセージのモバイル装置への配信を容易にするシステムおよび方法が提供される。たとえば、一実施形態において、ＸＭＬベースのマルチメディアメッセージは、メッセージのサイズを低減させるＸＭＬ「ショートコード（ｓｈｏｒｔ ｃｏｄｅ）」を用いて符号化される。それによって、メッセージを受信者に通信するために必要とされる、送信側機器によるＸＭＬ符号化の量および受信側機器によるＸＭＬ復号化の量の両方を低減させる。特に、メッセージにおけるＸＭＬツリーまたはサブツリーの構造がデフォルト構造に従う（ａｄｈｅｒｅ）とき（たとえば、メッセージの再生を担い、受信者の装置上で稼動するクライアントアプリケーションが、メッセージからメッセージへと静的に留まるツールバーまたはグラフィカルユーザインタフェース（ＧＵＩ）の側面を含むとき）、ツリーまたはサブツリーの構造を定義するメッセージの符号化部分は、構造を表す短縮されたコードによって置換されることができる。ショートコードが定義される特定のツリーまたはサブツリーは、メッセージフローに先立ってまたはその最中に決定され得る。たとえば、クライアント装置上にインストールされたクライアントアプリケーションは、インストレーション時にショートコード定義をすでに含み得るかまたは獲得し得る。代替的にまたは追加的に、ショートコードは、メッセージングフロー内に現れるツリーまたはサブツリーについてオンザフライ（ｏｎ−ｔｈｅ−ｆｌｙ）で定義され得る（たとえば、サブツリーが１回などの閾値回数よりも多くメッセージフロー内に現れたという判断に呼応して、サブツリーについてのショートコードを定義すること）。ショートコードを定義するとすぐに、ドキュメント参加者のメッセージング機器に対して、および／またはメッセージの遠隔格納を担うサーバに対して、ショートコード定義が提供され得る。好ましい一実施形態において、ＸＭＬショートコードはネトマティックマーク付け言語（ｎｍｌ）ショートコードであって、ｎｍｌは、２００２年１１月２８日に公開された、タイトルが「Ｓｈａｒｉｎｇ，Ｍａｎａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｏｖｅｒ ａ Ｃｏｍｐｕｔｅｒ Ｎｅｔｗｏｒｋ」の、本明細書において全体が参照により援用されている米国特許出願公開第２００２０１７８１６４号に記載されたＸＭＬ準拠言語である。
【００１１】
別の実施形態において、コンテンツの部分のみが所定の時間においてモバイル装置に通信される。たとえば、通信ネットワークの帯域幅および／または待ち時間、および／またはモバイル装置の処理能力および／または記憶能力に基づいて、ドキュメントの一つ以上のフラグメントがモバイル装置に通信され得る。それに続く送信において、ドキュメントの別の一つ以上のフラグメントがモバイル装置に通信され得る。フラグメントは、ドキュメントを再組み立てするためにモバイル装置によって必要とされる情報のすべてを含むという点で、「自己認識（ｓｅｌｆ ａｗａｒｅ）」し得る。
【００１２】
さらに別の実施形態において、メッセージの非テキストマルチメディアは、メッセージのテキスト部分が装置に通信されるのと同時に、インラインＡＳＣＩＩ符号化バイナリーアセットとしてモバイル装置に通信される。ＡＳＣＩＩ符号化アセットは、メッセージサイズを低減するために圧縮され得る。対照的に、マルチメディアメッセージをモバイル装置に配信するための従来のアプローチは、メッセージのテキスト部分を装置に配信することを伴い、テキスト部分は非テキストメディアへの一連の参照を含む。そこで、非テキストメディアの各断片（ｐｉｅｃｅ）は、装置からのメディアについての別のリクエストに応答して、モバイル装置に配信される。情報についての複数のリクエストは、一つ以上のリクエストがサーバによって受信されないことに起因して、またはモバイル装置によって受信されるコンテンツ内の送信エラーに起因して、結果としてエラーになり得る。情報についての複数のリクエストは、ネットワーク遅延（すなわち待ち時間）をも増加させる。
【００１３】
別の実施形態において、モバイル装置は、「レイジーな（ｌａｚｙ）」プッシュ（ｐｕｓｈ）またはプル（ｐｕｌｌ）通知プロトコルを通してマルチメディアサーバと通信し得、そこではモバイル装置およびマルチメディアサーバは装置またはサーバが状態の変化を経験するときにのみ通信する。たとえば、モバイル装置の起動状態が変化する（たとえば装置が「オンライン」または「オフライン」になる）とき、この起動状態（および「使用中」、「不在」、「タイプ中」、「アイドル」などの他の「存在」情報）を示す１バイト通知を、装置はサーバに送信（プッシュ）し得る。通知は、他のモバイルユーザ（たとえばモバイルユーザの友人リストに列挙されたユーザ）の存在についてのリクエストなどの、サーバからのメッセージおよび／または他のアップデートについてのリクエスト（プル）としての役割も果たし得る。別の例において、サーバは、アップデートに関する警告を、そのようなアップデートが利用可能になったときに、モバイル装置に送信（プッシュ）し得る。このレイジーなプッシュおよび／またはプルプロトコルは、モバイル装置を用いたメッセージングのために必要とされるネットワークトラフィックの量を最小限にし、したがってたとえばネットワーク待ち時間を低減させる。
【００１４】
さらに別の実施形態において、モバイル装置は、単一の呼び出しにおいて情報についての複数のリクエストをサーバに対して行ない得る。たとえば、単一の呼び出しは、存在インタフェースからの存在情報についての第１のリクエスト、および定期購読（ｓｕｂｓｃｒｉｐｔｉｏｎ）インタフェースからのシンジケートされた（ｓｙｎｄｉｃａｔｅｄ）コンテンツについての第２のリクエストを含み得る。対照的に、従来の方法は、リクエストごとに一つの別々の呼び出しを発行する。レイジーなプッシュおよび／またはプルプロトコルと同様に、これもまたモバイル装置を用いたメッセージングのために必要とされるネットワークトラフィックの量を最小限にする。
【００１５】
別の実施形態において、シンジケートされたコンテンツ（たとえばニュース供給）は、媒介サーバを経由して、シンジケートされたコンテンツサーバからモバイル装置へと通信される。モバイル装置がシンジケートされたコンテンツをリクエストするとき、媒介サーバは、シンジケートされたコンテンツが格納されているメモリ（媒介サーバの、またはサードパーティコンテンツプロバイダによってホストされる（ｈｏｓｔｅｄ）サーバなどの他のメモリ）における場所への参照（リンク）を、装置に送信する。たとえば、その結果、装置は、コンテンツ自身をダウンロードおよび格納することなく、参照を追うことによって、コンテンツにアクセスすることができる。このようにして、シンジケートされたコンテンツサーバからの重複したコンテンツの格納およびコンテンツの検索は回避され、ネットワークトラフィックは低減される。これは、各ユーザの装置がコンテンツサーバからコンテンツを直接にアクセスおよびダウンロードすることを必要とする従来のアプローチと対照的である。
【００１６】
別の側面において、モバイル装置のユーザに提供される機能を強化する種々の機能が提供される。この機能は、エンドユーザによって装置が購入される時においてインターネットからダウンロードされてモバイル装置にインストールされ得るかまたはモバイル装置上のメモリに常駐し得るクライアントアプリケーションによって少なくとも部分的に提供され得る。別の例において、メッセージング機能は、専用クライアントアプリケーション以外のモバイル装置の資源（たとえばブラウザおよび／またはメディアプレイヤー）によるクライアントレスアプローチにおいて提供され得る。
【００１７】
一実施形態において、たとえば、ドキュメントがレビュー用に利用可能かどうか、ドキュメントが変化したかどうか、誰がドキュメントに対してアクセスまたは作業をしているか、および／またはドキュメントが最後にアップデートされたのはいつか、を示すドキュメントレベルの存在情報が（ユーザ存在情報への代替または追加として）提供され得る。たとえば、モバイルユーザがクライアントアプリケーションを起動するとき、ユーザは、ちょうど記述したドキュメント中心の特徴の一つ以上とともに、ユーザが参加者であるかまたはユーザが参加するように送信勧誘された一つ以上のドキュメントを要約する表示を提示され得る。
【００１８】
別の実施形態において、ユーザがメッセージおよびメッセージスレッドを記録、再生、および編集することを可能にする機能が提供され得る。たとえば、遠隔サイトにおいて格納されたマルチメディアコンテンツについてのメタ情報に基づいて、ユーザはメッセージコンテンツを検索するオプションを提示され得る。加えて、メタ情報は、メッセージの再生、たとえばユーザが時間、日付、および／または場所に基づいてメッセージをフィルタリングすることができる選択的再生を可能にする。
【００１９】
別の実施形態において、現在オフラインであるユーザにメッセージを送信するため、特定の日時、時間、および／または地理的場所についてのメッセージの配信をスケジュールするため、および／またはユーザがメッセージを検索するときにそのユーザ（およびゼロ以上の他のユーザ）と接続するための、「プッシュトゥメッセージ（ｐｕｓｈ−ｔｏ−ｍｅｓｓａｇｅ）」機能が提供され得る。
【００２０】
本発明の実施形態の上述の特徴はモバイル装置のコンテキストにおいて主に記述される一方で、これらの特徴は非モバイル装置（たとえばデスクトップコンピュータ）を用いたメッセージングにも適用され得る。
【００２１】
本発明のより良き理解のために、添付の図面とともに以下の記述に参照がなされ、全体にわたって同様の参照文字は同様の部分を参照する。
【発明を実施するための最良の形態】
【００２２】
本発明の実施形態は、ユーザがモバイル装置、デスクトップ装置、セットトップ装置または他の装置からメッセージを送るかにかかわらず、エンドユーザにシームレスな経験を提供する、装置およびネットワークにとらわれないマルチメディアメッセージング環境に関する。この環境の範囲内において、たとえばウェブ（ＨＴＴＰ）、ＳＭＴＰ／ＰＯＰ／ＩＭＡＰ、ＳＩＰ、ＣＤＭＡおよびＧＳＭ（ＧＰＲＳ、ＥＤＧＥ）などの異なるネットワークおよび／またはプロトコルにわたって、装置は互いにメッセージを送ることができる。
【００２３】
図１は、サーバ１０２（それぞれが一つ以上のサーバインタフェース１０４およびメモリ１０６を備えている）、たとえば携帯電話およびＰＤＡ（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）などの一つ以上のモバイル装置、および／またはデスクトップコンピュータなどの一つ以上の非モバイル装置などのユーザ機器１０８を含むシステム１００の実施形態を示す。システム１００はさらに、ゲートウェイ１１０と、レンダリングエンジン１１２と、ＨＴＴＰ／ｅメールサービス１１４と、ロードバランサー１１６と、サードパーティゲートウェイ１１８とを備える。たとえば、本発明の実施形態は、モバイル装置または非モバイル装置のユーザが、モバイルユーザの起動状況（たとえばオンライン、オフライン、使用中、不在、タイプ中、アイドルなど）を決定するためにモバイルユーザについての存在情報を見ることと、モバイルユーザをテキスト、画像、音声、ビデオなどの複数メディアに関連するコミュニケーションに携わらせることとを可能にし得る。ユーザ機器１０８（および随意にメッセージに関連したメタ情報）の間で通信されるメッセージは、たとえば将来のメッセージにおけるマルチメディアコンテンツの後日の参照および／または再利用のために、メモリ１０６におけるドキュメント（またはドキュメントの部分）としてサーバ１０４によって持続される（格納される）。システム１００におけるドキュメントがｎｍｌベースのドキュメントである場合、システム１００は、そのさまざまな構成要素において、「ネトマット（ｎｅｔｏｍａｔ）」変更子を用いてラベルされ得る（たとえばネトマットサーバ１０２）。
【００２４】
モバイル装置および非モバイル装置は、クライアントアプローチまたはクライアントレス（ｃｌｉｅｎｔｌｅｓｓ）アプローチを用いることによって、システム１００にネットワーク接続され得る。前者の場合、たとえば装置のユーザがインターネットからクライアントをダウンロードするのに続き、クライアントアプリケーションが装置にインストールされ得る。たとえば、モバイル装置に対するクライアントは、Ｊａｖａ（登録商標）で書かれた小さなフットプリントアプリケーションであり得る（すなわちモバイル装置がｊａｖａ（登録商標）使用可能な装置である場合）。一実施形態において、そのようなアプリケーションは、ＭＭＡＰＩ（マルチメディアＡＰＩ）およびＷＭＡ（ワイヤレスメッセージングＡＰＩ）サポートを用いたＭＩＤＰ １．０プラットフォームをも含み得るＪ２ＭＥ ＭＩＤＰ ２．０プラットフォームを使用して作成され得る。たとえば、クライアントがインストールされる特定のモバイル装置に依存して、クライアントは５０ｋ〜１５０ｋの範囲のサイズであり得る。もう一つの実施形態において、モバイルクライアントはＸＨＴＭＬユーザコンテンツ管理インタフェースであり得る。非モバイル装置に対するクライアントアプリケーションの例は、Ｊａｖａ（登録商標）１．４アプリケーション、Ｊａｖａ（登録商標）１．１アプレット、マクロメディアフラッシュ（Ｍａｃｒｏｍｅｄｉａ Ｆｌａｓｈ）６．０アプレット、またはＸＨＴＭＬユーザコンテンツ管理インタフェースを含む。クライアントレス装置は、装置に常駐する専用クライアントアプリケーション以外のリソース（たとえばブラウザ、テキストメッセージングおよび／またはメディアプレイヤー）の使用によって、システム１００にネットワーク接続され得る。一般的に、マルチメディアメッセージングのためのクライアントアプリケーションをインストールされた装置は、クライアントレス装置と比較して、増加したメッセージング能力を有し得る。たとえば、クライアントレス装置は、ＸＭＬ「ショートコード」およびインライン圧縮ＡＳＣＩＩ符号化バイナリーアセットを考え得る例外として、本明細書に記載される機能のすべてをサポートし得る。
【００２５】
サーバ１０２は、すべての入ってくるリクエストおよび出ていくリクエスト（たとえば更新のリクエストあるいはモバイルユーザ１０８へのまたはモバイルユーザ１０８からのメッセージを通信するリクエスト）を担い、メモリ１０６とインタフェースをとり、サーバインタフェース１０４を提供する。一実施形態において、サーバ１０２はＪ２ＥＥアプリケーションサーバである。
【００２６】
サーバインタフェース１０４は、変化する情報をモバイルまたは非モバイル装置に対して提供し得、統一された方法で装置１０８がサーバ１０２に接続することを可能にし得る。たとえば、インタフェース１０４は、以下のインタフェースのうち一つ以上を含み得る。アップロードアセットインタフェース（ＵＡＩ）、管理アセットインタフェース（ＭＡＩ）、バージョニングインタフェース（ＶＩ）（ｖｅｒｓｉｏｎｉｎｇ ｉｎｔｅｒｆａｃｅ）、通知インタフェース（ＮＩ）、存在インタフェース（ＰＩ）、定期購読インタフェース（ＳＵＩ）、許可およびチケッティングインタフェース（ＰＴＩ）、送信勧誘インタフェース（ｉｎｖｉｔｅ ｉｎｔｅｒｆａｃｅ）（ＩＩ）、ユーザデータ管理インタフェース（ＵＤＭＩ）、アクセス管理インタフェース（ＡＭＩ）、検索インタフェース（ＳＩ）、およびウェブサービスインタフェース（ＷＳＩ）。
【００２７】
ＵＡＩは、すべてのテキストおよびバイナリーアセットをサーバにアップロードすることを担い得る。ＭＡＩインタフェースは、たとえば、遠隔サイトにおいて存続するフラグメントにアクセスし、新しいドキュメントにおけるフラグメントを参照することによって、マルチメディアコンテンツを再利用することなどの、ユーザのアセットの遠隔管理することを担い得る。ＶＩは、すべての更新のバージョニングをして、ドキュメントのフラグメントについて履歴ファイルを生成することを担い得る。ＮＩは、ユーザのスペース（ドキュメントにおいてユーザが単なる参加者であるユーザに由来するドキュメント（たとえばメッセージスレッド）をも含む）への更新をユーザに通知することを担い得る。ＰＩは、たとえば、追加の存在情報のみならず、ユーザの友人リストに列挙されたパーティのそれぞれの起動状態を示す情報などの存在情報を担い得る。ＳＵＩは、コンテンツのシンジケーション（ｓｙｎｄｉｃａｔｉｏｎ）を担い得る。ＰＴＩは、ユーザのコンテンツに対する読取りおよび書込みのアクセスについての許可を設定および取得することを担い得る。ＩＩは、ユーザのスペースに対するワンタイム送信勧誘を担い得、ＰＴＩと異なる許可設定を設定し得る。ＵＤＭＩは、プロファイルおよびアドレス帳などのユーザデータを管理することを担い得る。ＡＭＩは、ユーザのコンテンツのパスワード保護およびパスワード管理を担い得る。ＳＩは、ユーザデータおよびユーザコンテンツを照会すること（たとえばシステム１００のすべてのユーザにとって公に利用可能な情報およびコンテンツの検索、またはドキュメント参加者のみに利用可能な情報などの個人情報の検索）を担い得る。ＷＳＩは、ユーザ機器１０８上で可動するクライアントアプリケーションにウェブサービスを統合することを担い得る。たとえば、ＷＳＩは通信のためにシンプルオブジェクトアクセスプロトコル（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）（ＳＯＡＰ）を使用し得、ウェブサービス記述言語（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）（ＷＳＤＬ）についての組込みサポートを有し得る。
【００２８】
ゲートウェイ１１０は、本発明の実施形態のマルチメディアメッセージングシステムと他の通信システムとの間にブリッジを生成するサーバ側アプリケーションである。たとえば、ゲートウェイ１１０は以下のゲートウェイのうちの一つ以上を含み得る。ＳＭＳ／ＭＭＳゲートウェイ（ＳＭＳＧ）、電子メール（ｅメール）ゲートウェイ（ｅＭａｉｌＧ）、存在ゲートウェイ（ＰｒｅｓｅｎｃｅＧ）、インスタントメッセージングゲートウェイ（ＩＭＧ）、コンテンツストリーミングゲートウェイ（ＣＳＧ）、および検索ゲートウェイ（ＳＧ）。ＳＭＳＧは、装置１０８からのＳＭＳメッセージおよびＭＭＳメッセージをサーバ１０２によってメモリ１０６に対するフラグメントとして存続されることを可能にする。ｅＭａｉｌＧは、テキストベースのｅメールメッセージと、メモリ１０６に対して存続されるドキュメントへの添付のあるｅメールメッセージとの統合を可能にする。ＰｒｅｓｅｎｃｅＧは、プリム（ｐｒｉｍ）および／またはシンプル（ｓｉｍｐｌｅ）なＪａｂｂｅｒまたはＷｉｒｅｌｅｓｓ Ｖｉｌｌａｇｅなどの他の存在ベースのシステム（およびしたがってこれらのシステムからの存在情報の使用）との統合を可能にする。ＩＭＧは、Ｊａｂｂｅｒ、ＡＩＭ、Ｗｉｒｅｌｅｓｓ ＶｉｌｌａｇｅおよびＩＣＱなどのインスタントメッセージベースのシステムとの統合を可能にする。ＣＳＧは、ストリーミング技術（たとえばストリーミング音声およびビデオについて）との統合を可能にする。ＳＧは、ＧｏｏｇｌｅおよびＭＳＭ検索などの既存の検索技術との統合を可能にする。たとえば、ユーザ機器１０８上に表示されたグラフィカルユーザインタフェース（ＧＵＩ）（たとえば機器１０８上で稼動するクライアントアプリケーションによって関連させられるＧＵＩ）に入力される検索語は、ＳＧによって検索技術に認識可能なフォーマットに変換され得、次に検索技術に提供され得る。検索技術によって返された検索結果は、ユーザ機器１０８に結果を表示させる前に、適切なフォーマット（たとえばＸＭＬ準拠言語ｎｍｌ）に変換され得、メタ情報（たとえば検索技術による検索結果を備えたメタ情報および／または検索のために使用された検索技術を示すソース情報）によってタグをつけられ得る。
【００２９】
サーバ１０２は、たとえばネトマットメッセージまたはアップデートが利用可能であること（たとえば存在情報および／またはシンジケートされたコンテンツに対するアップデート）を機器に警告するために、ＳＭＳ（テキスト）またはインターネットプロトコル（ＩＰ）パケット通知をユーザ機器１０８に典型的に送信する。ＳＭＳメッセージに関して、メッセージの特定の形式およびコンテンツは、通知がアドレス指定される装置がクライアント装置であるかクライアントレス装置であるかに依存して変化し得る。その目的のために、ネトマットサーバ１０２は、クライアントがインストールされた装置（モバイル装置など）のリストをメモリ１０６に格納し得るか、またはさもなければリストへのアクセスを有し得る。
【００３０】
たとえば、モバイル装置１０８がクライアントレス装置であることを決定するサーバ１０２に応答して、サーバ１０２はＳＭＳを介して装置に通知を送信し得る。ここでＳＭＳ通知は、新しいメッセージおよび／またはアップデート情報がサーバ１０２から利用可能であることを示す。ＳＭＳ通知は、たとえば、ドキュメント（またはドキュメントの部分）への外部リンク、またはメモリ１０６においてサーバ１０２によって存続させられるシンジケートされたコンテンツなどの他のコンテンツへの外部リンクを含み得る。ワイヤレスアプリケーションプロトコル（ＷＡＰ）プッシュメッセージ（たとえば）の形式における通知を受信するとすぐに自動的に、またはユーザがリンクを選択することに応答して、クライアントレスモバイル装置のブラウザは、ユーザのためにドキュメントまたはシンジケートされたコンテンツのアクセスおよび再生を行い得る（たとえばモバイル装置のディスプレイ領域におけるビデオ、テキストまたは画像の表示、モバイル装置のスピーカを介する音声の送信、またはこれらの組み合わせ）。応答をメッセージングするためにユーザがテキストを入力および提出できる一つ以上のフィールドも表示され得る。もう一つの例において、システム１００は、メモリ１０６においてテキストフラグメントとしてサーバ１０２によって存続され得るＳＭＳメッセージを用いた通知に対して、クライアントレスモバイル装置のユーザが応答することを可能にし得る。
【００３１】
代替的に、モバイル装置１０９にマルチメディアメッセージングのためのアプリケーションがインストールされていることを決定するサーバ１０２に応答して、サーバ１０２は通知ヘッダにおけるクライアントアプリケーションについてのポート番号を含むＳＭＳ通知を装置に対して送信し得る。これは、モバイル装置によってメッセージが受信されるとすぐにクライアントアプリケーションの自動的起動を引き起こし得る。ひとたび起動されると、クライアントアプリケーションは、サーバ１０２によってメモリ１０６に対して存続させられるドキュメント（ＳＭＳ通知において提供され得るリンク）にアクセスし得、ユーザがマルチメディアメッセージ応答を発行することを可能にし得る。さらに、クライアントアプリケーションが起動状態にある場合、メッセージまたはアップデートの通知は、ＳＭＳ経由ではなく、ＩＰチャネルを通してサーバ１０２によって送信され得る。その目的のために、サーバ１０２は、クライアントがインストールされたどのモバイル装置が起動状態にあるかを示すデータを格納し得るか、またはさもなければデータへのアクセスを有し得る。モバイル装置１０８上で稼動するクライアントアプリケーションが起動状態にあるかどうかをサーバ１０２によって決定することに関する追加の詳細は、１バイトの「レイジーな」プッシュまたはプル通知の記述と関連して以下に提供される。
【００３２】
システム１００におけるレンダリングエンジン１１２は、ユーザ機器１０８によってシステムにおいてメッセージを送られるマルチメディアコンテンツおよび／または他のコンテンツ（たとえばシンジケートされたコンテンツ）の表示および／または操作をするソフトウェアモジュールであり得る。たとえば、レンダリングエンジン１１２は、コンサートアリーナにおける電子ビルボードまたは映写などの、物理的スペースにおける公共ディスプレイを生成し得る。代替的にまたは追加的に、レンダリングエンジン１１２は、インターネットページ（たとえばワールドワイドウェブページ）上にコンテンツを公開し得る。コンテンツの公開および処理は、モバイル装置およびデスクトップ装置からの投票またはポーリングなどのように、リアルタイムで生じ得る。レンダリングエンジンはフラグメントが遠隔サイトに対して存続させられる順番において自動的にドキュメントのフラグメントを再生し得るという意味において、レンダリングエンジンはユーザの静的なインプットから動画の映画のような経験をも生成し得る。
【００３３】
図２Ａは、本発明に従ったたとえばデスクトップ装置に表示されたマルチメディアクライアントアプリケーションによって提供される説明的なディスプレイのスクリーンショットである。図２Ａにおいて、サーバ１０２によってメモリ１０６に対して存続させられるドキュメントがユーザのために表示される。より具体的には、図２Ａはユーザのスペースの概要を提供する。ユーザのスペースは、ユーザがドキュメントの参加者であるドキュメントのセットとして概念化され得る（すなわち、ユーザがオーサリング権を有するドキュメントのセット）。示されるように、タイトルが「ＭＩＫＥ’Ｓ ２５ＴＨ」の２０２がディスプレイの範囲内で現在選択されている。したがって、ドキュメント２０２のフラグメント２０４、２０６および２０８はユーザのために表示され、各フラグメントは、テキスト、画像および対応するメタ情報（たとえば作者および日時）を含む複数メディアを含む。ディスプレイは、さまざまな選択可能なオプションをも含み得る。オプション２１０、２１２および２１４もまた、ユーザがドキュメント「ＩＴ’Ｓ Ａ ＧＩＲＬ」、「ＨＡＰＰＹ ＢＩ．．．」および「ＤＥＣＥＭＢＥ．．．」をそれぞれ表示のために選択することを可能にするために提供される。オプション２１６は、ユーザが新しいドキュメントを作成することを可能にするために提供され得る。返信フィールド２１８は、ユーザが現在のドキュメント２０２における参加者への通信のためにマルチメディア応答を提出することを可能にし得る。示されるように、マルチメディア（たとえば画像）は、装置（「Ｍｙ Ｃｏｍｐｕｔｅｒ」オプション２２０）の局部記憶装置からの応答、またはユーザ指定のコンテンツ（「Ｍｙ Ｇａｌｌｅｒｙ」オプション２２２）の記憶装置に専用のメモリ１０６におけるような遠隔記憶装置における割当てからの応答に含まれるように選択され得る。「Ｆｕｎ Ｓｔｕｆｆ」オプション２２６は、ユーザが遠隔記憶装置からサードパーティマルチメディアコンテンツ（たとえばシンジケートされたコンテンツ）にアクセスすることを可能にし得る。プレビューウィンドウ２２４は、マルチメディアメッセージを送信する前にユーザが画像をプレビューすることを可能にし得る。オプション２２８は、ドキュメントに参加する２つの新しい送信勧誘がユーザにとって利用可能であることを示し得る。オプション２１８の選択は、ユーザが送信勧誘の送信者に関する送信勧誘および／またはプロファイル情報をレビューすることを可能にし得る。送信勧誘を受け入れることを選択することは、対応するドキュメントおよびそれに関連した情報をディスプレイに出現させ得る。
【００３４】
図２Ｂは、本発明の実施形態に従ったモバイル装置上で稼動するマルチメディアコンテンツアプリケーションによって表示されるような、図２Ａに示されるものと同じドキュメント２０２のスクリーンショットである。モバイルユーザにとって利用可能なオプションは、図２Ａの例においてユーザに提示されるオプションと同様かまたは同一であり得る。しかし、モバイル装置のより小さなディスプレイに起因して、ユーザは、オプションにアクセスするために表示をたとえばスクロールさせることが要求され得る。
【００３５】
図３は、本発明に従ったメッセージングメディアに関係する説明的なステージのフローチャート３００である。ステージ３０２において、サーバ１０２は、ユーザ機器１０８（たとえばモバイルユーザ機器）から、一つ以上の受信者（たとえばモバイルユーザ機器のもう一つのインストレーション）に対する通信を対象としたメディアメッセージを受信し得る。ステージ３０４において、サーバ１０２はメディアメッセージをメモリ１０６内のドキュメントとして格納し得る（たとえば一つ以上の受信者およびメディアメッセージの送信者から遠隔に）。ステージ３０６において、サーバ１０２は、一つ以上のメッセージ受信者に対して通信し得る。たとえば、サーバ１０２は、ドキュメント送信勧誘または他の通知を受信者に送信することによって受信者にメッセージを通知し得、受信者が送信勧誘を受け入れたことに応じて受信者にメッセージを通信し得る。受信者にメッセージを通信することは、遠隔に格納されたメッセージへのリンクを送信すること、および／またはメッセージのすべてまたは部分を受信者装置に送信することを含む。好ましい一実施形態において、メッセージからのマルチメディアコンテンツは、図５および６に関連して以下に記述する圧縮されたＡＳＣＩＩバイナリー符号化アセットとして受信者に好ましくは通信される。ステージ３０８において、サーバ３０６は、一つ以上の受信者に対してドキュメントを通信することに続き、遠隔記憶装置においてドキュメントを保持し得る。このことは、将来のメッセージにおいてドキュメント（およびそのマルチメディアコンテンツ）が参照および／または再利用されることを可能にし得る。一実施形態において、サーバ１０２は、ドキュメントに参加する送信勧誘を受け入れたユーザ、またはメッセージをフラグメントとしてドキュメントに付加したユーザを、ドキュメントへの参加者として指定し得、これによってユーザ間の関連性を作成する。この関連性はユーザのコミュニティを確立し得、ユーザはそのコミュニティに特定の機能を提供され得る。
【００３６】
本発明の側面において、マルチメディアメッセージング（たとえばテキスト、画像、ビデオ、および／または音声を用いたメッセージング）を通した進行中の方法で、モバイルユーザ１０８が他の装置のユーザと共働することを可能にするシステムおよび方法が提供される。たとえば、サーバ１０２がメッセージおよび関連するメタ情報をドキュメント（たとえばまたはドキュメントのフラグメント）として存続させるのに先立って、モバイル装置および非モバイル装置１０８によって生成されるマルチメディアメッセージは、メッセージの送信者および受信者から遠隔にメモリ１０６において識別用メタ情報（たとえば作者、日時、時間、および／または場所）によって自動的にタグをつけられ得る。別の例として、格納されたドキュメントに対して、異なる装置１０８のユーザが同時に書込む（たとえば追加または変更する）ことを可能にする単一付加機能が提供され得る（たとえば装置から遠隔に格納されたドキュメントに対してフラグメントを存続させる）。さらに別の例として、格納されたドキュメントおよびそれに関連したマルチメディアコンテンツ（および随意にメタ情報）を元来のメッセージ受信者以外のパーティによってアクセスされることを可能にするソーシャルネットワーキングプロトコル（ｓｏｃｉａｌ ｎｅｔｗｏｒｋｉｎｇ ｐｒｏｔｏｃｏｌ）が提供され得る（たとえば「友人の友人」プロトコル）。以下にこれらの特徴をより詳細に記述する。
【００３７】
（メッセージされたコンテンツの自動メタ情報タグつけ）
ウェブ資源は、作者、リンク、キーワード、および記述に関する情報を提供するメタタグを含む。この情報は、ドキュメントの検索および機械処理のために有用である。これの一つの現在の方法は、ＲＤＦ、すなわちＸＭＬの拡張であり、他の機械によって効率的に処理されることができる機械生成のメタデータのオーサリング、操作、および検索のためのツールをフレームワークに提供する。
【００３８】
現在、ＲＤＦタグなどの方法を通してメタデータを供給することは、いくらかの人間のインプットを必要とする（たとえば、情報を明確にサポートすること、またはタグを入力すること）。しかし、通信システムにおいて作成されるドキュメントの量を記述するためには、自動的にタグを挿入することが必要であり、特に、マルチメディアメッセージングシステムがフラグメント付加操作を通して同時アップデートを可能にする本発明の実施形態においては必要である（以下により詳細に記述する）。
【００３９】
一実施形態において、本発明は、各ドキュメントまたはその部分を記述するために自動メタ情報タグつけを使用する。たとえば、すべてのドキュメントが一つ以上のフラグメントを含む好ましい一実施形態において、ドキュメントの範囲内の各フラグメントは、フラグメントの作成場所、日付、および作者を示すメタ情報によってタグをつけられ得る。モバイル装置に関して、場所情報は、グローバルポジショニングシステム（ＧＰＳ）によって測定されるようなモバイル装置の地球規模の場所についての識別、モバイル装置についての識別（たとえば携帯ＩＤ）に基づいて、および／またはユーザからのインプット（たとえばユーザがニューヨーク州の範囲内にいるというユーザからの指摘）に基づいて生成され得る。非モバイル装置についての場所情報は、ＧＰＳに基づき得るか、またはユーザインプット（たとえばユーザの装置が存在するところの郵便番号をユーザが述べたユーザのユーザプロファイル）に応じ得る。メタ情報に基づいて、フラグメントおよびドキュメントは検索、編集、および編成されることができ、これらの変更は他者によって見られることができる。
【００４０】
自動メタ情報タグつけは、アップデートされた情報がさらなる使用のために適切にタグつけされることを確実にするのに役立つ。一実施形態において、ユーザ機器１０８上で稼動するクライアントアプリケーションは、メッセージがサーバ１０２に送信される前に、作者、日付、時間、および場所（これらのすべては送信装置の機能である）によって，新しいメッセージにタグをつけ得る。別の実施形態において（たとえばメッセージがクライアント装置から送信される場合）、サーバ１０２は、メモリ１０６においてメッセージを存続させる前に、またはコンテンツを分散型配置におけるもう一つのサーバに送信する前に、メタ情報によってメッセージにタグをつけ得る。図４は、本発明の実施形態に従うドキュメント作成時間におけるメタ情報の挿入を示す。特に、ドキュメントのフラグメントは、以下のようにタグをつけられる。フラグメント名＝「ｆｒａｇｍｅｎｔ」、作者名＝「Ｍａｃｉｅｊ」、日時「２７−Ｊｕｌ−０４ １６：２１ＰＭ ＭＳＴ」、および場所情報＝「Ｐａｒｉｓ」ならびに「：：：Ｌａｔｉｔｕｄｅ：１９ｄｅｇｒｅｓｓ−４５ｍｉｎｕｔｅｓ−３２．４ｓｅｃｏｎｄｓ− ｎｏｒｔｈ：：：Ｌｏｎｇｉｔｕｄｅ：１５５ｄｅｇｒｅｅｓ−２７ｍｉｎｔｕｅｓ−２２．８ｓｅｃｏｎｄｓ−ｗｅｓｔ：：：Ａｌｔｉｔｕｄｅ：２３００ｆｅｅｔ」。次にフラグメントがドキュメントに付加され、ドキュメントは他のフラグメントの形式において一つ以上の以前の関連するメッセージを含む。
【００４１】
（単一付加操作を用いたグローバルユーザ管理ファイルシステム）
システム１００は、任意の装置１０８から地球規模でアクセス可能なコンテンツ管理システムを提供し得、マルチメディアアセットの検索、分類、送信、削除、共有、および再利用の能力を提供し得る。対照的に、従来のファイルシステムは、読込み中またはアップデート中のファイルに対するアクセスを「ロック」し、これらのファイルについての追加リクエストがキューに追加される。アクセスをロックすることは、追加の処理時間およびサーバメモリを必要とし、アップデートが損失されることと、実際に保存されていなかったデータへの変更がアップロードされることと、アップデートされたファイルを再読取りする問題とを生じ得る。
【００４２】
システム１００によって提供されるグローバルファイルシステムは、ファイルをアップデートする単純かつ効率的な方法を提供し、上述の問題を回避する。好ましい一実施形態において、既存のフラグメントに上書きすることによってではなく、新しいフラグメントを付加することによってすべてのドキュメントが変更されることができるので、ドキュメントの範囲内のランダム書込みは実質的に存在しない。したがって、ひとたび書込まれれば、ドキュメントの範囲内のフラグメントは読取り専用であり、ほとんどの部分にわたって順次読取られる。グローバルファイルシステムは、ディレクトリにおいて階層的にファイルを編成し、ドメインにおいて以下のようなパスのパス名によってファイルを識別する、ドメインベースのシステムであり得る。
／ｍ／ａ／ｃ／ｉｅｊ／ｔｒａｖｅｌ／ｉｎｄｅｘ．ｖ４５．ｎｍｌ
これは次のドメインに位置付けられ得る。
ｈｔｔｐ：／／ｗｗｗ．ｎｅｔｏｍａｔ．ｎｅｔ
グローバルファイルシステムは、標準的な開く（ｏｐｅｎ）、閉じる（ｃｌｏｓｅ）、作成する（ｃｒｅａｔｅ）、削除する（ｄｅｌｅｔｅ）、読取る（ｒｅａｄ）、および書込む（ｗｒｉｔｅ）の操作、ならびに各装置の付加の統合性を保証しながら複数の装置１０８が一つのドキュメントに同時にフラグメントを付加することを可能にするフラグメント付加（ｆｒａｇｍｅｎｔ ａｐｐｅｎｄ）をサポートする。
【００４３】
フラグメントアプローチは、従来の分散ファイルシステムよりも著しくより単純であり、したがって縮小することがより簡単であり、エラーに対してよりトレラントである。フラグメントアプローチは、異なるエンドユーザ装置間のデータ同期の必要性を排除することにも役立つ。これらの問題のそれぞれは、ロッキングメカニズム（ｌｏｃｋｉｎｇ ｍｅｃｈａｎｉｓｍ）の使用を通してユーザがウェブ資源を共働で編集、公開、および管理することを可能にするＷｅｂＤＡＶなどの現在のウェブベースのプロトコルにおける問題であるが、スケーラビリティの問題をも生じやすかったものであり、フラグメント付加機能を提供しない。
【００４４】
（メッセージングフローおよびプロトコルレイヤに組み込まれたソーシャルネットワーキングプロトコル）
現在のソーシャルネットワーキングアプリケーションは、ユーザがソーシャルネットワークを形成することを奨励する特徴を提供するとともに、ユーザ間のやり取りまたは関係を認識するための多くの方法を提供する。一実施形態において、本発明は、インタラクションパターンのより細分な（ｇｒａｎｕｌａｒ）研究を通して、ソーシャルネットワーキングを容易にする。
【００４５】
本発明は、モバイル装置の所定のセットについて、装置間の実際のインタラクションに基づいて、ときどき社会契約と呼ばれる適切な社会規則を定義する自動的な方法を提供する。たとえば、ユーザが作成したドキュメントは、互いに知っている人々のみまたは互いに紹介された人々のみがメッセージの送信および受信をすることを可能にする「友人の友人」プロトコルを使用してリンクされることができる。そのメッセージはそこでフラグメントとしてドキュメントに付加され得る。
【００４６】
たとえば、友人のドキュメントは、メッセージが受信パーティによって受け入れられた場合に作成され得（すなわち、無視されるかまたは削除されるのではなく、受信パーティによってアクセスされ得）、それによって送信パーティおよび受信パーティの間の「信頼のリンク」を作成する。一般的に、信頼のリンクはインスタントドキュメントの目的のみに有効であることになる。すなわち、送信者が参加する他の個人的なドキュメントに対するアクセスを受信パーティに与えることにはならないという意味であり、逆もまた同じである。このようにして、友人の友人のネットワークは、ユーザ間の進行中の通信／共働の範囲内から有機的に成長されることができる。
【００４７】
別の例として、ときどきバディーリスト（ｂｕｄｄｙ ｌｉｓｔ）と呼ばれる友人のリストは、ユーザによって作成されるか、またはサーバインタフェース１０４の送信勧誘、定期購読、および通知の処理の結果として自動的に生成されることができる。
【００４８】
ユーザ自身を表現および記述するためにユーザによって作成されるユーザデータの収集であるプロファイルもまた提供され得る。しかし、ユーザはユーザのプロファイルを隠すかまたはプロファイルに対するアクセスを制限することが許可され得る。プロファイルはネットワークの範囲内のユーザを識別するために使用される。システム１００は、マルチメディアプロファイルならびに一定の通信の間のプロファイルの「反対のルックアップ（ｒｅｖｅｒｓｅ ｌｏｏｋｕｐ）」をサポートし得る。すなわち、（たとえば）メッセージの受信者は、送信者からのメッセージを受け入れる前に、メッセージの送信者のプロファイルをレビューすることができるという意味である。プロファイルはユーザの公開プロファイルである。
【００４９】
変化する信頼度は、異なる社会的なつながりに起因し得る。たとえば、最大の信頼度は、友人のリストのメンバー間で示され得る。この変化する信頼、および／または他のユーザのプリファランスは、システム１００がユーザに配信されることを可能にするソーシャルネットワークに参加するための送信勧誘の種類をフィルターにかけるために使用され得る。たとえば、システム１００は、たとえば配布リストまたはサブジェクトタグ（ｅメール用のＳＰＡＭブロッキングと同様）の属性に基づいてメッセージが好ましくないと決定されない場合は、パーティ送信勧誘がユーザに配信されることを許可する。
【００５０】
システム１００は、ソーシャルプロトコルを作成するプロセスを自動化する。システム上の各メッセージは、メタタグがつけられ、格納され（ユーザがそれを削除しない場合）、後日の使用のために検索可能であるので、システム１００はネットワーク内に生ずる任意のソーシャルタイ（ｓｏｃｉａｌ ｔｉｅ）を追跡することができる。この能力は、メッセージフラグメント間のリンク、およびメッセージがどのようにアクセスされるかのみに適用され得るものであり、メッセージの内容には適用され得ないことに留意することは重要である。
【００５１】
本発明の別の側面において、マルチメディアメッセージのモバイル装置への配信を容易にするシステムおよび方法が提供される。たとえば、ＸＭＬベースのマルチメディアメッセージは、送信者によるＸＭＬ符号化の量および受信者によるＸＭＬ符号化の量の両方を削減するＸＭＬ「ショートコード」を用いて符号化され得るものであり、これはメッセージを受信者に通信するために必要とされる。別の実施形態において、たとえば通信ネットワークの帯域幅および／または待ち時間、および／またはモバイル装置の処理能力および／または格納能力に依存して、ドキュメントの一部のみが所定の（ｇｉｖｅ）時間においてモバイル（または非モバイル）装置に通信され得る。さらに別の実施形態において、メッセージのテキスト部分が装置に通信されるのと同時に、メッセージの非テキストマルチメディアは、インラインＡＳＣＩＩ符号化バイナリーアセットとしてモバイル装置に通信され得る。別の実施形態において、モバイル装置１０８およびサーバ１０２が装置またはサーバが状態の変化を経験するときのみに通信をする「レイジーな」プッシュおよび／またはプル通知プロトコルを通して、モバイルユーザ１０８はサーバ１０２と通信し得る。さらに別の実施形態において、モバイル装置１０８は、単一のリクエストにおいて複数のサーバインタフェース１０４に対する情報のために複数の呼び出しを行ない得る。別の実施形態において、サーバ１０２は、（たとえばニュース供給を提供する）シンジケートされたコンテンツサーバと一つ以上のモバイル装置１０８との間の媒介として機能し得る。これは、コンテンツ格納の重複を回避し得、ネットワークトラフィックを低減し得る。以下にこれらの特徴をより詳細に記述する。
【００５２】
（短縮された符号化−ＸＭＬショートコード）
本発明の実施形態は、特にワイヤレスネットワークにわたって、ＸＭＬベースのドキュメントをより効率的に送信する方法を提供する。送信のサイズを低減することは、すべての通信方法にとっての目標である一方で、低い帯域幅および高いオーバヘッドによって効率性が影響を受ける携帯電話などの資源の限定された装置に関する主要な懸念である。本発明は、追加の符号化ソフトウェアを必要とすることなく、ドキュメントサイズを低減させることにより、送信サイズを低減させ、ドキュメントの符号化および復号化の計算負担を排除する。
【００５３】
既存のメッセージングシステムは、ネットワークにわたるより効率的な送信のためにデータを符号化するための２つの方法に頼る。これらの方法は、バイナリー符号化および圧縮である。両方のアプローチは、符号化された送信を解釈するために必要とされるオーバヘッドに関して効率性の影響を有する。
【００５４】
バイナリー形式でファイルを符号化するＷＢＸＭＬ（ワイヤレスバイナリーＸＭＬ）などのバイナリー符号化方法。バイナリー符号化の欠点は、符号化および復号化、および符号化／復号化ソフトウェアのための追加のメモリに関連する、ユーザ機器およびマルチメディアサーバの両方におけるオーバヘッドを処理することを含む。
【００５５】
データ圧縮は、ドキュメントを格納および送信するために必要とされるオーバヘッドおよびネットワーク帯域幅を低減するための他の従来のアプローチである。バイナリー符号化と同様に、データ圧縮は解釈を必要とすることによって、各装置上に圧縮／解凍ソフトウェアを必要とし、ならびに圧縮／解凍に起因する送信／レンダリングのプロセスに待ち時間を導入する。
【００５６】
一実施形態において、本発明は、再利用可能なマーク付け言語を特定し、その言語のためのショートコードで代替することによって、ＸＭＬ符号化についての必要性を排除する第３の解決法を提供する。たいていの場合、これはバイナリー符号化およびデータ圧縮よりも効率的である。本発明は、ドキュメントサイズを削減し、ネットワーク帯域幅を節約し、追加のソフトウェアを必要としないことによって、装置上のメモリを節約し、オーバヘッド処理を排除する。システム１００がｎｍｌ（ネトマティックマーク付け言語）（ｎｅｔｏｍａｔｉｃ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）ベースのドキュメントを送信する好ましい一実施形態において、ショートコードは（ｎｍｌ）ショートコードである。ｎｍｌは、上記の援用されている米国特許出願公開第２００２０１７８１６４号に記載されたＸＭＬ準拠言語である。
【００５７】
一つのｎｍｌショートコードは、一つまたは多くのｎｍｌコード要素を表す。ショートコードは、ｎｍｌ要素の基礎をなす構造を、単一のコード要素へと崩壊させる（ｃｏｌｌａｐｓｅ）。ショートコードは、任意のｎｍｌツリー／サブツリーについて代替されることができる。アプリケーションがｎｍｌ要素のデフォルト値を認識する場合、およびこれらの値がｎｍｌアプリケーションのライフサイクルの間に一定に留まる場合、ショートコードは挿入される。ショートコードは、追加の前前処理なしに複雑なドキュメントがより効率的に処理されることを可能にする既存の構文解析系およびインタプリタによって処理される。
【００５８】
たとえば、ｎｍｌ＜ｔｏｏｌｂａｒ＞要素は、ｎｍｌアプリケーションのユーザインタフェースを定義する要素および属性を含む。すなわち、レイアウト、ルックアンドフィール、および機能などの属性である。子供の要素および属性を有する＜ｔｏｏｌｂａｒ＞定義の例を以下に示す。
＜ｔｏｏｌｂａｒ ｔｙｐｅ＝“ａｌｌ”＞
＜ｆｏｒｍＣｏｎｔａｉｎｅｒ ｎａｍｅ＝“ＡｄｄＩｍａｇｅ” ｉｄ＝“００３”＞
＜ｓｕｂｍｉｔ ａｃｔｉｏｎ“ｈｔｔｐ：／／ｍｏｂｉｌｅ．ｎｅｔｏｍａｔ．ｎｅｔ／ａｃｃｏｕｎｔ／ａｄｄＩｍａｇｅ．ｊｓｐ
“ｔａｒｇｅｔ＝“ＩｍａｇｅＦｏｒｍ”ｍｅｔｈｏｄ＝“ＧＥＴ” ｉｄ＝“０１” ｎａｍｅ＝“Ａｄｄ Ｉｍａｇｅ”＞
＜／ｓｕｂｍｉｔ＞
＜／ｆｏｒｍＣｏｎｔａｉｎｅｒ＞
＜／ｔｏｏｌｂａｒ＞
たとえば、上記のコーディングについてのツリー構造は、以下のように表現され得る。
【００５９】
【化１】
したがって、毎回ユーザインタフェースが必要とされるたびに（上記のツリーによって図示されるような）この構造の全体の＜ｔｏｏｌｂａｒ＞定義を送信するのではなく、ショートコードが送信される。
【００６０】
この場合に使用されるショートコードは以下のようであり得る。
＜ｔｏｏｌｂａｒ ｔｙｐｅ＝“ａｌｌ”／＞
＜ｔｏｏｌｂａｒ＞ショートコードは、レイアウト、ルックアンドフィール、および機能を定義する属性を隠す。ツールバー要素の最初の送信において「ｔｙｐｅ＝ａｌｌ」の属性値を提供することによって、その要素に属するサブツリーはショートコードに適格であるとしてマークされる。この次にアプリケーションが上記におけるような「ｔｙｐｅ＝ａｌｌ」の属性を有する＜ｔｏｏｌｂａｒ＞要素を受信するとき、アプリケーションは＜ｔｏｏｌｂａｒ＞をショートコードとして認識する。
【００６１】
別の例において、画像のシーケンスを生成するために、以下のサンプルコードに示すようにショートコード「＜ｓｌｉｄｅｓｈｏｗ＞」が使用され得る。画面に対して画像のシーケンスをどのようにレンダーするかは、クライアントアプリケーションに委ねられ得ることに留意すべきである。たとえば、一つの画像を次の画像で置き換えることによって画像はプレロードおよび循環させられ得るか、またはアイテムが一旦選択されると画像はスクロール可能な領域において連続して表示され得る。
【００６２】
【化２】
したがって、繰り返される符合は識別用属性によってマークされ、冗長符号は次の通信において再送信されない。このアプローチを使用すると、メッセージ交換の大きなチャンクはショートコードであることができ、ネットワークにわたって送信されるファイルのサイズを効率的に低減させる。場合によっては、所定のショートコードを通したメッセージ交換の前に、ショートコードは示されることができる。クライアントアプリケーションがショートコードを認識しない場合、クライアントアプリケーションはメッセージをサーバ１０２に送信することができるので、繰り返される符合は全体として送信されることになる。
【００６３】
（マルチメディアメッセージおよび任意の長さのメッセージスレッドの配信）
別の実施形態において、本発明は、帯域幅および高い待ち時間を限定された記憶装置を有する装置に限定してきたネットワークにわたって大きなファイルおよび任意の長さのメッセージを配信することに関連する問題を排除する。たとえば、ＸＭＬフラグメントをドキュメントに組み立てるためのＸＭＬフラグメント仕様などのより複雑なアプローチの代わりになるものとして、ＸＭＬおよびより具体的にＸＭＬ準拠言語であるｎｍｌは、「チャンク可能な」ドキュメントを作成するための単純な解決法を提供する。
【００６４】
ｎｍｌを用いれば、ドキュメントに関するサイズの制限はない。ｎｍｌフラグメントは、チャンクにおけるドキュメントを配信するための柔軟性を提供する。すなわち、完全なドキュメントとは対照的に、データチャンクはより大きなドキュメントに属する。
【００６５】
フラグメントはドキュメントの一部であり、たとえば限定された記憶装置および処理能力を有し得るモバイル装置１０８に配信されることができるほど十分に小さい。一度に配信されるフラグメントの数は、ネットワークスループットおよび装置能力に基づき得る。システム１００は、ネットワークにわたって次のフラグメントをロードし得るので、ドキュメントが局所的にスクロールされているという外観を与える。
【００６６】
一実施形態において、本発明は、ネットワーク帯域幅および装置１０８に基づいて、必要に応じて１〜ｎ個のフラグメントを配信する能力を提供する。送信されることができるフラグメントの数には上限がない。送信されるフラグメントのデフォルト数は、ユーザプリファランスとして動的に無効にされることができる。
【００６７】
ｎｍｌフラグメントは、ゼロまたは多くのｎｍｌオブジェクト（要素）を含むことができる。ｎｍｌオブジェクトは、時間および空間におけるオブジェクトとして定義される。すなわち、ｎｍｌオブジェクトは、作者、最後に変更された日付／時間のスタンプ、および利用可能な場合はその地理的場所として定義される属性（前述のメタ情報）を含むという意味である。ｎｍｌフラグメントは、図４に示される。
【００６８】
このメタ情報は、ｎｍｌオブジェクトを「自己認識」させる。すなわち、ドキュメントを再組み立てするために必要とされる情報は、フラグメント自身の範囲内に含まれるという意味である。フラグメントは、フラグメントの外部の規則または知識を必要としない。この自己認識に基づいて、任意の２つのｎｍｌフラグメントが分類されることができる。
【００６９】
（インライン圧縮ＡＳＣＩＩ符号化バイナリーアセット）
モバイルネットワークが拡大するにつれて、小さな画面によって特徴づけられ、信頼性のないネットワーク接続性および低い帯域幅になりやすい装置に対して、フォーマットされたマルチメディアプレゼンテーションを配信する、より速く、より効率的で、ユーザフレンドリな方法に対するニーズも拡大する。モバイルおよび固定ネットワークにわたるメッセージにおいてマルチメディアを交換する既存の方法は、本発明と比較すると、指数関数的に高い数のクライアント／サーバの呼び出し／応答を必要とする。したがって、ネットワークにより高い要求を課し、送信セッションをネットワーク障害にさらし、ユーザをより長い待ち時間にさらす。
【００７０】
電話ブラウザ（ｐｈｏｎｅ ｂｒｏｗｓｅｒ）などの従来のモバイルアプリケーションは、画像を含むＨＴＭＬまたはＸＨＴＭＬなどのマルチメディアファイルをロードするために以下のステップを必要とする。最初に、ＨＴＭＬファイルについてのユーザからのリクエストに応じて、ＨＴＭＬファイルがロードされなければならない。次に、ＨＴＭＬファイルにおける各埋め込み画像がロードされなければならない。ここで、各埋め込み画像は別々のユーザリクエストを必要とする。ＭＭＳおよび他のメッセージングシステムによって同様の戦略が採用される。一つ以上の呼び出しがサーバによって受信されないことに起因して、またはモバイル装置によって受信されたコンテンツにおける送信エラーに起因して、情報についての複数の呼び出しが結果としてエラーになり得る。
【００７１】
一実施形態において、従来のシステムとは異なり、システム１００は、複数の呼び出しを排除し、メッセージサイズを低減することによって、マルチメディアコンテンツをモバイル装置１０８に効率的に配信する。特に、モバイル装置１０８からの単一の呼び出しは、サーバ１０２に、ＡＳＣＩＩ符号化されたおよび圧縮された（たとえばサーバ１０２によって圧縮され符号化された）マルチメディアアセットを含むｎｍｌファイルを送信させる。圧縮されると、ＡＳＣＩＩ符号化されて圧縮されたファイルは１２パーセント〜３０パーセント小さい。すべてのＴＣＰ／ＩＰ接続のために必要とされるオーバヘッドを低減することにより（すなわち呼び出し／応答の数を低減させることにより）、追加の１０パーセントの利点が達成される。一つのメッセージに複数のアセットを含むメッセージを配信する能力は、結果としてより速い配信になり、著しく改善されたユーザ経験を実現させる。システム１００はモバイル環境に比類なく適切である。システム１００は、サーバが応答しなければならない呼び出しの回数を限定することによって、サーバ１０２の資源をも保護する。たとえば、図５はモバイル装置の表示画面のスクリーンショットであり、ここでは、サーバ１０２（図１）への単一の呼び出しに応答して、７つの画像５０２〜５１４（および関連テキスト）がモバイル装置に送信される。
【００７２】
図６は、インライン圧縮ＡＳＣＩＩ符号化バイナリーアセットとしての５つの画像（サイズは合計５０ｋ）を含むコンテンツを、マルチメディアクライアントアプリケーションがインストールされた（さらにメッセージがｎｍｌメッセージである）モバイル装置に配信するために必要とされる配信時間に対して、同じコンテンツを（ＡＳＣＩＩ符号化バイナリーアセットのインライン圧縮を用いない）モバイル装置のＨＴＭＬブラウザに送信するために必要とされる配信時間を示すグラフである。より詳しくは、２８．８ｋｂｐｓラインにわたる配信について、圧縮ＡＳＣＩＩ符号化バイナリーアセットは４８．４秒で配信されたのに対して、ＨＴＭＬブラウザへの同じコンテンツの送信は６６．５秒を必要とした。
【００７３】
以下は、３つの画像を含むｎｍｌファイルについての説明的なコードを示す。この例において、インラインメッセージは、ＬＺ７７アルゴリズムおよびＨｕｆｆｍａｎ符号化の組み合わせを含む標準的なデータ圧縮アルゴリズムを用いて圧縮され、Ｂａｓｅ６４として符号化される。インライン画像（たとえば１２７２バイト）は、ＪＰＧ形式におけるもともとの画像（たとえば１５６４バイト）よりも小さい。
【００７４】
【化３】
【００７５】
【化４】
【００７６】
【化５】
【００７７】
【化６】
以下は、３つの画像への参照を含むＨＴＭＬファイルについての説明的なコードを示す。各画像のサイズは１５６４バイトであり、サーバへの別々の呼び出しを必要とする。したがって、このドキュメントを表示するためには、サーバへの４つの呼び出しが必要とされる（すなわち、テキストをリクエストするための一つと、各画像についてひとつずつで３つの追加リクエストである）。
【００７８】
【化７】
（１バイト「レイジーな」プッシュまたはプル通知）
モバイル装置の使用の拡大は、モバイルおよび固定ネットワークにわたってインプリメントされるメッセージングシステムに対する需要をますます増加させ続ける。現在のネットワークは、帯域幅および接続信頼性の点で著しい限界を有しており、そのことはしばしば結果として失われたまたは損なわれたメッセージとなる。現在のメッセージングシステムは、帯域幅およびネットワーク信頼性に起因する問題に直面している。
【００７９】
一実施形態において、本発明は、メッセージの交換において必要とされるネットワークトラフィックの量を最小限にすることによって、モバイルおよび固定ネットワークのためにより速くより柔軟なメッセージングシステムを提供する。本発明は、ユーザが自分の装置にダウンロードする情報をユーザが選択することを可能にする一方で、帯域幅および記憶装置などのネットワーク資源および装置資源を最大限にする。
【００８０】
具体的には、本発明はメッセージおよびデータの交換を制御する通知方法に関する。本発明は、ユーザ状態、アップデート、メッセージ、および／または他の情報を集約する（ｃｏｎｓｏｌｉｄａｔｅ）配信メカニズム（たとえば１バイト配信メカニズム）を提供する。１バイト通知は、装置状態情報を、装置とサーバ１０２との間のコンテンツおよびメッセージの配信を制御する情報とひとまとめにすることによって、ネットワークトラフィックを最小限にする。対照的に、従来のメッセージングシステムは、装置における変化の信号を送るためと、データにおける変化の信号を送るために、別々の通知を必要とする。従来のメッセージングシステムにおいては、１バイト通知方法とは対照的に、トラフィックは１キロバイトにおいて測定される。
【００８１】
図７は、本発明の一実施形態に従った１バイト通知のフローダイヤグラムを示す。ステージＡにおいて、ユーザ機器は、サーバに命令（たとえばエンドユーザによって定義された命令）を送信し、たとえばドキュメントがいつ変更またはアップデートされるかをユーザ機器に通知されるべきこと（たとえばシンジケートされたコンテンツに対するアップデートがいつ利用可能であるか、またはユーザが参加するドキュメントに対してユーザがいつ応答を持続したかなど）を指定する。ユーザ機器は、アップデートが利用可能である場合、アップデートの１バイト通知、アップデートの要約、または実際のアップデート自身
を受信することになるかどうかをも指定する。ステージＢにおいて、サーバは命令を受信する。ステージＣにおいて、グローバルファイルシステム（および存在インタフェースなどの他の機器）は、ユーザのプリファランスに関係するアップデートを含むアップデートをサーバに提供する。ステージＤにおいて、ユーザのプリファランスに基づいて、サーバはユーザ機器に対して、ユーザに対するアップデートの１バイト通知（警告）、アップデートの要約、または実際のアップデート自身のいずれかを「プッシュ」し、ステージＥにおいてユーザはそれを受信する。警告または要約について、エンドユーザはステージＦにおいてアップデートを無視またはダウンロードすることを選択することができる。アップデートをダウンロードするリクエストに応答して、サーバはステージＧにおいてユーザ機器に対してプッシュし、ユーザ機器はステージＨにおいてコンテンツを受信する。別の実施形態において、ユーザ機器は「プル」通知の手順を実行し得る。その手順において、ユーザ機器は、たとえばサーバからアップデートをリクエストするために「ｎ」秒ごとにサーバに照会する（たとえばユーザ機器の状態についてサーバに警告することに加えて）。
【００８２】
本発明に従った１バイト通知は、種々の形態を取り得る。たとえば、一実施形態において、Ｙ、Ｎ、Ｓ、またはＰなどの一つのＡＳＣＩＩ文字を格納するために、８ビット（１バイト）通知が使用され得る。ここで、各文字は、特定のコンテンツ（たとえばシンジケートされたコンテンツのみに関する通知など）の通知（またはリクエスト）または任意の／すべてのアップデートコンテンツ（たとえばアップデートの種類を指定することなくアップデートが利用可能であるという通知を表す「Ｙ」文字）を表し得る。別の実施形態において、存在についての状態情報（たとえば利用可能または使用中）を表す０〜９９、ドキュメントについての状態情報を表す１００〜１９９、およびエラーコードを表す２００〜２５５などの特定の情報を表す状態コードを表すために、８ビットが使用され得る。別の実施形態において、ドキュメントの満了日における変化などの変化の種類（たとえば４ビット）、ならびに変更が緊急であるかまたは変更の確認あるいは他のアクションが必要とされるという指示などの変化（４ビット）に関連する属性を定義するために８ビットが使用されることができる。
【００８３】
（サーバインタフェースの動的連結）
サーバへのリクエストは、サーバがリクエストを読むことと応答をフォーマットすることができるように、適切にフォーマットされなければならない。クライアントアプリケーションがインストールされたモバイル装置１０８は、単一の呼び出しを使用して種々のサーバインタフェース１０４から情報をリクエストすることができる。別の実施形態において、サーバは、そのような連結された呼び出しを送信するオプションを有するクライアントレス装置を提供することができる。ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）およびＨＴＴＰなどの従来の方法を用いると、そのようなリクエストは、各インタフェースについて一つの、複数の呼び出しに分離させられる。対照的に、本発明に従ったクライアントアプリケーションは、たとえば存在インタフェースおよびユーザ検索用インタフェースの両方から情報をリクエストする呼び出しを生成し得る。単一の呼び出しは一連の従来のＨＴＴＰ呼び出しを含み、そのそれぞれはサーバにＨＴＴＰ呼び出しを同時に処理させるように変更された引き数を有する。本発明は、より効率的な方法において標準およびプロトコル（ＨＴＴＰ）を使用する。サーバは、リクエストされたコンテンツのすべてを、リクエストする装置に送信する単一の応答に集約することができる。
【００８４】
ＨＴＴＰは、データをサーバに書き込む（ｐｏｓｔ）ＨＴＴＰＰＯＳＴ、および応答をリクエストするＨＴＴＰＧＥＴなどの、いくつかの有用なクライアント／サーバ呼び出しを提供する。複雑なシステムは、より複雑なリクエストを送信するために効率的な方法を必要とする。ウェブアプリケーションは、通常いくつかのＨＴＴＰＰＯＳＴリクエストおよびＨＴＴＰＧＥＴリクエストから成る。たとえば、一つのＨＴＴＰＰＯＳＴリクエストはユーザデータをサーバに提出するために使用されることができ、もう一つのＨＴＴＰＰＯＳＴリクエストは任意のユーザを登録するユーザであることができる。
【００８５】
そのようなリクエストを送信するために、クライアントアプリケーションは、各インタフェース１０４に別々のリクエストを送信するのではなく、異なるリクエストおよび応答を自動的に連結する。インタフェースは、クライアントおよびサーバが情報を交換できるようにクライアントとサーバとの間に接続が作られる点である。各インタフェースは階層の一部であり、階層においてインタフェースはより上位のインタフェースの特性を引き継ぐ。これらのインタフェースは単一のリクエストの間により多くの情報をサーバに渡すことができるので、この継承は、複数のインタフェースの機能を組み合わせることによって、サーバインタフェース１０４の能力を拡張する。たとえば、サーバ１０２に対する単一のリクエストにおいて、ユーザ状態および新しいユーザデータを受け取る。
【００８６】
たとえば、図８は、本発明の実施形態に従ったサーバインタフェースの動的連結を示す。示されるように、第１のモバイル装置は、サーバ１０２に対する単一の統合された呼び出しにおいて、存在、バージョニング、および通知のインタフェースにアクセスし得る。第２のモバイル装置は、サーバ１０２のインタフェースに対して、別々の連続した呼び出しを実行し得る。非モバイル装置は、定期購読および検索のインタフェースに対する単一の統合された呼び出しと、アセット管理インタフェースに対する別の呼び出しとを実行し得る。
【００８７】
別の例として、システム１００における存在は、ドキュメントと密接に結合される。一人の人間は、特定のドキュメントまたはドキュメントの収集の範囲内において、グローバルな存在を有すること、および存在することの両方ができる。存在を有するネトマットドキュメントは、ライブの（ｌｉｖｅ）共働環境になる。図１と関連して記述されたように、存在インタフェース（ＰＩ）は、ユーザの存在および利用可能性を担う。通知インタフェース（ＮＩ）は、ユーザのスペースおよびユーザが参加するスペースへのアップデートをユーザに通知することを担う。ユーザ通知は、ＰＵＬＬまたはＰＵＳＨメカニズムにいずれかを使用することができる。コンタクトリストは、送信勧誘、定期購読、および通知のインタフェースを通して自動的に作成および管理される。ＰＩインタフェースは、以下の構造を有し得る。
【００８８】
【化８】
ＮＩインタフェースは、以下の構造を有し得る。
【００８９】
【化９】
以下は、連結された存在および通知のインタフェースとともに、コモンゲートウェイインタフェース（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）を使用した、サンプルのＨＴＴＰＧＥＴリクエストおよびサーバ応答である。通知インタフェースは、存在インタフェースから受け継ぎ、ドキュメントリスナー（ＤｏｃｕｍｅｎｔＬｉｓｔｎｅｒ）インタフェースをインプリメントする。
【００９０】
【化１０】
【００９１】
【化１１】
サーバ応答は、最後の変更されたストリングならびにドキュメントに束縛された存在情報の両方を返す。「ｂｒ」は、ユーザがブラウザを使用していることを示す。
【００９２】
（配信されたコンテンツシンジケーション対媒介サーバ）
コンテンツシンジケーションは、コンテンツ消費者がコンテンツ生産者の供給を定期購読することを可能にする技術を参照する。クライアント／サーバ環境においてシンジケートされたコンテンツを配信するための多くのフォーマットがあり、ＲＳＳ（Ｒｅａｌｌｙ Ｓｉｍｐｌｅ Ｓｙｎｄｉｃａｔｉｏｎ）およびＩＣＥ（Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｃｏｎｔｅｎｔ Ｅｘｃｈａｎｇｅ）を含む。これらのフォーマットは、同様の方法で定期購読者にコンテンツを配信し、それによってコンテンツはすべてのユーザのためにコンテンツサーバからダウンロードされなければならない。コンテンツ定期購読者の膨大な数を考慮すると、この配信方法は、通信ネットワークに多大な負荷をかけ、ボトルネックを生じ、記憶装置のための要求を増加させる。
【００９３】
一実施形態において、本発明は、ネットワークトラフィックを最小限にし、コンテンツの重複を排除し、スケーラブルなコンテンツ共有メカニズムを提供する方法で、シンジケートされたコンテンツを無数のユーザに容易に配信する方法を提供する。
【００９４】
本発明は、従来のアプローチと区別される方法で、シンジケートされたコンテンツの配信をインプリメントする。第一に、シンジケートされたコンテンツサーバからのすべての新しいニュース供給は、装置１０８に対するアップデートのスケジューリングおよび配信のための媒介として作用するサーバ１０２に集約される。図９は、定期購読シナリオを図示する。すべての供給をサーバ１０２に集約することによって、定期購読者はもともとの供給からデカップルされ（ｄｅｃｏｕｐｌｅｄ）、それによって同時のダウンロードリクエストによって生じ得るボトルネックを排除する。サーバ１０２はトラフィックを制御し、装置１０８を過剰なネットワークトラフィックおよびボトルネックから絶縁する。
【００９５】
第二に、シンジケートされたコンテンツは、サーバ１０２に留まり、そこで要求側装置によって共有され、ネットワークトラフィック、潜在的なボトルネック、および記憶装置要求をさらに低減させる。サーバ１０２は、一つ以上のシンジケーションサーバからコンテンツを定期的にダウンロードし、シンジケートされたコンテンツを定期購読するクライアントアプリケーションによって装置１０８に警告する。クライアントはアップデートを選択的にリクエストでき、サーバはクライアントへの配信のためにアップデートを最適化する。クライアントがコンテンツをリクエストする場合、サーバ１０２は、コンテンツへの参照（リンク）をクライアントのネトマットスペース（たとえばシンジケートされたコンテンツに関連するドキュメントに対するフラグメントとして）にコピーするが、実際のコンテンツをサーバ上に残す。
【００９６】
さらに、一人のユーザは、シンジケートされたコンテンツを他のユーザと容易に共有できる。たとえば、ユーザがシンジケートされたコンテンツを選択すると、コンテンツはメッセージフローの中に挿入されて他のユーザと共有される。したがって、（たとえば）ニュース供給は、追加の転送メカニズムを用いることなく、進行中の会話の中に動的に挿入されることができ、ただちに他のユーザと共有されることができる。ユーザは、任意の他のユーザがシンジケートされたコンテンツ供給を共有するように送信勧誘することができる。図１０は、コンテンツがどのように共有されるかを図示する。送信勧誘された人は、ニュース供給への次のアップデートが通知され、アップデートは無視またはダウンロードされ得る。
【００９７】
ユーザはグループの範囲内でコメントを書き込む（ｐｏｓｔ）ことができる。それによって、会話の開始、および／または共働ドキュメントの形成をする。定期購読される供給をグループのメンバーが受信すると、グループのすべてのメンバーも供給の通知を受信する。個々のグループメンバーは供給を受信または無視することを選択し得、グループの社会的性質をさらに強化する。コンテンツ配信およびコンテンツのメッセージへの自動的挿入に関連する低いオーバヘッドに起因して、グループはたとえばほぼ数百万程度の人々を容易に収容することができる。
【００９８】
本発明の別の側面において、モバイルメッセージングに関してモバイルユーザの能力を増強する種々の機能が提供される。この機能は、モバイル装置上で稼動するクライアントアプリケーションによって少なくとも部分的に提供され得る。たとえば、そのようなクライアントは、エンドユーザによる購入時に、インターネットからダウンロードされてモバイル装置にインストールされ得るか、またはモバイル装置上のメモリに常駐し得る。別の例において、メッセージング機能は、専用クライアントアプリケーション以外の資源（たとえばブラウザおよび／またはメディアプレイヤー）によるクライアントレスアプローチにおいて提供され得る。一実施形態において、たとえば、ドキュメントがレビュー用に利用可能であるか、ドキュメントは変化したか、誰がドキュメントに対するアクセスまたは作業をしているか、および／またはドキュメントが最後にアップデートされたのはいつかを示す、ドキュメントレベルの存在情報が提供され得る。別の実施形態において、ユーザがメッセージおよびメッセージスレッドを記録、再生、および編集することを可能にする機能が提供され得る。たとえば、ユーザは、遠隔サイトに格納されたメッセージをそのコンテンツについて格納されたメタ情報に基づいて検索するオプションを提示され得る。別の実施形態において、指定された日付、時間、および／または地理的場所についてのメッセージの配信をスケジューリングするために、および／またはユーザがメッセージを受信するときにユーザ（およびゼロ以上の他のユーザ）と接続するために、現在オフラインであるユーザに対してメッセージを送信するための「プッシュトゥメッセージ」機能が提供され得る。以下にこれらの特徴をさらに詳細に記述する。
【００９９】
（ネットワーク、存在、および場所を認識するドキュメント）
存在は、通信ネットワークにおけるユーザのオンラインまたはオフライン状態として典型的に理解される。従来の存在の例は、ＡＯＬのインスタントメッセージングシステムおよび「バディーリスト」などのインスタントメッセージングであって、サーバは、ユーザがオンラインまたはオフラインであるかを認識しており、使用中、不在、タイプ中、およびアイドルなどのより細分な存在の状態を追跡することもできる。このシステムにおいて、焦点はユーザに当てられる。
【０１００】
一実施形態において、本発明は、ドキュメントレベルの存在と呼ばれる新しい種類の存在を導入する。ユーザに関する存在情報に対する代替または追加として、本発明は、システム１００のユーザがドキュメントを位置付けることおよびドキュメントについて共働することを可能にする。ドキュメント存在は、ドキュメントの状態、場所、およびネットワークアウェアネス（ｎｅｔｗｏｒｋ ａｗａｒｅｎｅｓｓ）に関して、有意義な情報をユーザに提供する。適切な許可を有するユーザは、ドキュメントがレビュー用に利用可能か、ドキュメントが変化したか、誰が所定のドキュメントに対してアクセスまたは作業をしているか、誰がオンライン会話（メッセージスレッド）内に存在しているか、およびドキュメントが最後にアップデートされたのはいつか、を理解することができる。
【０１０１】
上述のように、サーバ１０２に知られ、ユーザによって照会されることのできる、作者、場所、および日時スタンプなどのメタ情報を、ｎｍｌドキュメントは含み得る。ドキュメント存在は、たとえばドキュメントの信号を送ること、および異なる参加者によってなされる増分変化を管理することなどの共働環境において重要である。グローバルポジショニングシステム（ＧＰＳ）データによって提示されるような場所アウェアネスは、ドキュメントがどこで作成されたかに関する情報を提供する。ネットワークアウェアネスは、ドキュメントオブジェクトに、それらがどこに発送され（ｓｈｉｐｐｅｄ）つつあるか、およびドキュメント存在の状態に基づいて、調整する能力を与える。すなわち、ドキュメントは、ネットワーク状態によって決定されるような一つ以上のフラグメントを配信または添付することができる。たとえば、モバイル装置上にインストールされたクライアントアプリケーションが、（たとえばネットワーク帯域幅に基づいて）クライアントがデータパケットを落とすかまたは落としそうであると判断する場合、クライアントはサーバに対して、所定の時間においてより少ないフラグメントを送信するようにリクエストし得る。クライアントレスアプリケーションについては、サーバは、所定の時間においてデフォルト数のフラグメント（たとえば１フラグメント）を送信し得る。
【０１０２】
ドキュメントの任意の部分が作業中である場合、システムはドキュメントの存在および場所を知っている。その情報は、許可を有するユーザによって照会されることができる。たとえば、ユーザは、特定の時間においてコンテンツを誰が見て誰が変更したかを照会することができる。ドキュメントは、時間および空間における自己管理オブジェクトである。ドキュメントレベルの存在は、何がドキュメントを構成するか、およびドキュメントがどのように処理されるかについて、細分性のもう一つのレベルを追加する。
【０１０３】
（メッセージおよびメッセージスレッドの記録機能および再生機能）
ウェブサイト、写真、およびストリーミングメディアファイルなどの従来のマルチメディアは、ユーザが送信されたドキュメントを編集することを可能にせず、所望の情報のフィルタリングまたは識別のため、および再生のための、限定されたオプションを可能にするのみである。
【０１０４】
再生、すなわちドキュメントにおける情報が現れる動画化されたシーケンスは、メッセージングスレッドおよび掲示板などの時間ベースでないメディアとは対照的に、秒あたりのフレームにおいて表示するビデオまたはスピーチなどの時間ベースのメディアにとって、より重要な問題として通常理解される。しかし、アクセス情報および注文情報は、時間ベースのメディアおよび時間ベースでないメディアの両方にとって重要である。
【０１０５】
一実施形態において、本発明は、任意のメッセージ交換または共働が選択的に記録されて選択的に再生されることを可能にする。本発明は、検索機能および選択機能を提供するので、ユーザは所望の再生情報を位置付けることおよび選択することができる。たとえば、本明細書に記述されているようにメディアのフラグメントがサーバ１０２によってメモリ１０６に対して存続させられた順番を定義するメタ情報に基づいて、ユーザはドキュメント全体を始めから終わりまで再生し得る。別の例として、ドキュメントの任意の点において発生し得るユーザ編集に基づいて、再生の順番は、変更、停止、および開始されることができる。
【０１０６】
選択的な記録／再生機能は、ドキュメントの根底にある構造、すなわちフラグメントの収集に起因して可能である。記録された会話は、小さなサイズのフラグメントの収集から成り、フラグメントのそれぞれはメタ情報として自動的にタグつけされている。フラグメントに組み込まれているメタ情報ならびに所定の設定にフィルターを適用することによって、メッセージ交換は選択的に記録されることができる（たとえば、所定の作者によって、特定の日付において、特定の場所において、および／または特定の時間の間に生成されたフラグメントのみを再生すること）。
【０１０７】
再生機能は、定義された順番でフラグメントをロードおよび表示することによって可能にされる。再生の順番およびコンテンツは、異なるフィルターおよび分類アルゴリズムをメッセージに適用することによって、リアルタイムで定義および再定義されることができる。それによって、ドキュメントの範囲内のどこからでも再生が始まることを可能にする。
【０１０８】
（プッシュトゥメッセージ機能）
プッシュトゥメッセージ機能は、以下のように提供され得る。
【０１０９】
警告およびメッセージ（Ａｌｅｒｔ−ａｎｄ−ｍｅｓｓａｇｅ）は、ユーザがオフラインであるときに、ネトマットユーザが他のネトマットユーザにインスタントメッセージを送信することを可能にする。ユーザがオフラインである場合、ユーザのモバイル装置上のネトマットアプリケーションが自動的に起動し、メッセージのユーザに警告する。現在のモバイルメッセージングシステムは、プッシュレジストリ（ｐｕｓｈ ｒｅｇｉｓｔｒｙ）機能を使用することによって、装置上のアプリケーションを「目覚めさせる」することができる。同様に、技術革新は、ネトマットアプリケーションを「目覚めさせる」こと、または後日の配信のためにメッセージをシステム上にロードすることができる。アプリケーションを目覚めさせることは、任意の時間についてスケジュールされることができる。たとえば、ただちに、２時間以内に、または２ヶ月以内に。警告およびメッセージのメタ情報は、ネットワーク機能であるのではなく、ドキュメント自身の中に組み込まれる。このことは、この情報を検索可能にし、配信問題に対してより脆弱ではなくする。
【０１１０】
配信するスケジュール（Ｓｃｈｅｄｕｌｅ−ｔｏ−ｄｅｌｉｖｅｒ）は、ネトマットユーザがメッセージ配信についての時間および地理的場所を指定することを可能にする。たとえば、ネトマットユーザは、「２０１０年１０月１日」などの特定の日付において、および「シカゴのオヘア空港」などの特定の場所において他のネトマットユーザに配信されるメッセージを作成することができる。ユーザは、設定された時間においてメッセージが削除されるようにスケジュールすることもできる。配信するスケジュールのメタ情報は、ネットワーク機能であるのではなく、ドキュメント自身に組み込まれる。これは、この情報を検索可能にし、配信問題に対してより脆弱ではなくする。
【０１１１】
配信時接続（Ｃｏｎｎｅｃｔ−ｏｎ−ｄｅｌｉｖｅｒｙ）は、ユーザおよび他の選択されたユーザが受信側ユーザに接続することを可能にし、このときメッセージは首尾よく配信される。たとえば、ネトマットユーザは、誕生日において祝辞を述べる別のユーザにメッセージを送信し得る。誕生日ユーザがメッセージを受け入れると、誕生日ユーザに祝辞を述べるために数人の他のユーザが同時に接続される。配信時接続のメタ情報は、ネットワーク機能であるのではなく、ドキュメント自身に組み込まれる。これは、この情報を検索可能にし、配信問題に対してより脆弱ではなくする。
【０１１２】
このようにして、モバイル装置を用いたマルチメディアメッセージングのために方法およびシステムが提供されることが理解される。本明細書において特定の実施形態が詳細に開示されたが、説明の目的のみのための例示を目的としてなされたものであり、以下の添付の特許請求の範囲について限定するように意図されるものではない。特に、特許請求の範囲によって定義される本発明の精神および範囲から逸脱することなく、種々の置換え、変更、および修正がなされ得ることは、本発明者によって予期される。他の側面、利点、および修正は、以下の特許請求の範囲の範囲内にあると考えられる。提示される特許請求の範囲は、本明細書に開示される本発明を代表するものである。他の、特許請求の範囲でない発明もまた予期される。本発明者は、後の特許請求の範囲において、そのような発明を追求する権利を保留する。
【図面の簡単な説明】
【０１１３】
【図１】図１は、本発明の一実施形態に従ったマルチメディアメッセージングシステムの図である。
【図２Ａ】図２Ａは、本発明の一実施形態に従った非モバイル装置上で稼動するマルチメディアクライアントアプリケーションによって提供される説明的な表示のスクリーンショットであり、サーバによってメモリに存続させられるドキュメントが表示される。
【図２Ｂ】図２Ｂは、本発明の一実施形態に従ったモバイル装置上で稼動するマルチメディアコンテンツアプリケーションによって表示されるような、図２Ａに示されるものと同じドキュメントのスクリーンショットである。
【図３】図３は、本発明に従ったメッセージングメディアに関わる説明的な段階のフローチャートである。
【図４】図４は、本発明の一実施形態に従ったドキュメント作成時におけるメタ情報の挿入を示す。
【図５】図５は、モバイル装置の表示画面のスクリーンショットであり、マルチメディアサーバに対する単一の呼び出しに応答して、７つの画像がモバイル装置に送信される。
【図６】図６は、マルチメディアクライアントアプリケーションがインストールされたモバイル装置へのインライン圧縮ＡＳＣＩＩ符号化バイナリーアセットとしてのマルチメディアコンテンツの配信時間に対して、同じメッセージをＨＴＭＬブラウザに通信するために必要とされる配信時間との比較を示す。
【図７】図７は、本発明の一実施形態に従った１バイト通知のフロー図である。
【図８】図８は、本発明の一実施形態に従ったクライアントサーバインタフェースの動的連結を示す。
【図９】図９は、本発明の一実施形態に従った媒介サーバを介したコンテンツシンジケーションの配信を示す。
【図１０】図１０は、本発明の一実施形態に従った媒介サーバを介したコンテンツシンジケーションの配信を示す。
【技術分野】
【０００１】
（関連出願の引用）
本出願は、２００４年９月２１日に出願された米国仮特許出願第６０／６１１，７４６号、および２００５年５月２６日に出願された米国仮特許出願第６０／６８５，３０４号の利益を主張するものであり、参照によりその全体が本明細書に援用されている。
【０００２】
（発明の分野）
本発明の実施形態は、モバイル装置（たとえば携帯電話およびＰＤＡ（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ））を用いたメッセージングのためのシステムおよび方法に関し、より具体的には、モバイル装置を用いてマルチメディアをメッセージングするためのシステムおよび方法に関する。
【背景技術】
【０００３】
従来、モバイル装置を用いてマルチメディア（たとえばテキスト、画像、ビデオ、および音声）をメッセージングすることは扱いにくく、多くの場合は不可能である。たとえば、ショートメッセージサービス（Ｓｈｏｒｔ Ｍｅｓｓａｇｅ Ｓｅｒｖｉｃｅ）（ＳＭＳ）は、１６０文字以内のテキストメッセージの送信に限定される。マルチメディアメッセージングサービス（Ｍｕｌｔｉｍｅｄｉａ Ｍｅｓｓａｇｉｎｇ Ｓｅｒｖｉｃｅ）（ＭＭＳ）はテキストならびに他のメディアの送信を可能にする一方で、ＭＭＳは、メッセージが受信者に配信された後における送信者および受信者からの遠隔によるメッセージの格納である持続性に欠けている。特に、メッセージがＭＭＳを介して配信された後、配信を担うサーバは、たとえばマルチメディアコンテンツの後日の参照または再利用のためのメッセージのコピーを保持しない。結果的に、モバイルユーザがＭＭＳの使用を通して進行中の方法で互いに共働する能力は、著しく限定される。さらに、インターネットプロトコル（ＩＰ）チャネルを介して（たとえばＩＰマルチメディアサブシステム（ＩＭＳ）を介して、またはモバイル装置上で稼動するブラウザを通して）モバイル装置にマルチメディアを配信するための従来のアプローチは、配信時間およびネットワーキング信頼性の両方について大いに改善されることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
したがって、モバイル装置を用いてメディアをメッセージングするための従来のシステムのこれらや他の欠点を対処するモバイルメッセージングシステムおよび方法を提供することが望ましくあり得る。
【課題を解決するための手段】
【０００５】
（発明の要旨）
本発明の実施形態は、モバイル装置を用いて複数のメディアをメッセージングするための改善されたシステムおよび方法に関する。モバイルユーザに提供されるメッセージング経験は、マルチメディア共働を容易にすること、コンテンツ配信および／またはネットワーキング信頼性を向上させること、および／またはエンドユーザ機能を強化することによって改善される。たとえば、モバイルユーザのメッセージング経験は、従来は使いやすさおよび機能の両方の点でモバイル装置のメッセージング経験に勝っていたデスクトップおよび非モバイル装置に提供されるメッセージング経験に匹敵するかまたは勝るようにされることができる。
【０００６】
一つの側面において、マルチメディアメッセージング（たとえば、テキスト、画像、ビデオ、および／または音声を用いたメッセージング）を通して、モバイルユーザが他の装置のユーザと進行中の方法で共働することを可能にするシステムおよび方法が提供される。たとえば、一実施形態において、メッセージの送信者および受信者から遠隔でメッセージおよび関連メタ情報を「ドキュメント」（あるいはドキュメントの部分）として存続する（すなわち格納する）前に、モバイルおよび非モバイル装置によって生成されたマルチメディアメッセージは、識別するメタ情報（たとえば、作者、日付、時間、および／または場所）によってタグがつけられる。ドキュメントは、メッセージが受信者に通信された後でさえも、遠隔記憶装置において保持される。このことは、メッセージが、メタ情報に基づいてたとえば検索および／または格納されることと、マルチメディアコンテンツの将来の参照、改訂、および／または再利用のためにアクセスされることを可能にする。さらに、送信者および受信者は、ドキュメント参加者として指定され得、これによって参加者間のメッセージングコミュニティを作り上げる関連性を確立する。同じコミュニティのメンバー（すなわち同じドキュメントへの参加者）は、たとえば、コミュニティの他のメンバーとリアルタイム通信を開始する能力（たとえば両方のユーザが参加するドキュメントへの参加者のリストから他のユーザのオンラインＩＤを選択するユーザ）、コミュニティのすべての他のメンバーにメッセージを送信する能力、およびどのコミュニティメンバーがコミュニティの基盤を形成するドキュメントに現在アクセスしているかを判断する能力など、そのコミュニティに特有の種々の機能を提供され得る。したがって、複数のドキュメントに参加するユーザは、複数のメッセージングコミュニティのメンバーであり得る。
【０００７】
本明細書で使用されているように、一つのドキュメントは、送信者と受信者との間で通信される、および通信後に送信者および受信者から遠隔で格納される、一つ以上の種類のマルチメディア（およびオプションとして関連するメタ情報）を含む。ドキュメントは、単一の場所において遠隔で、分散型配置において、または任意の他の適切なアプローチにおいて、格納され得る。好ましい一実施形態において、各ドキュメントは「フラグメント」と呼ばれる一つ以上の関連するメッセージを含む（たとえば、送信者から一人以上の受信者へのマルチメディアメッセージと、送信者を識別するメタ情報とを含む第１のフラグメント、および受信者からのマルチメディア応答と、受信者を識別する情報とを含む追加のフラグメント）。同じドキュメントのフラグメントが遠隔サイトに存続させられた順番は、フラグメントについてのメタ情報内にキャプチャされ得る。このメタ情報（たとえば時間スタンプ）は、たとえば、対話が生じた順番またはユーザが定義した順番においてドキュメント参加者間のマルチメディア対話を再生するために使用され得る。オプションとして、ドキュメントへのアクセス権を有するユーザによる選択が可能な履歴ファイルもまた提供され得る。履歴ファイルは、たとえばフラグメントが遠隔サイトに対して存続させられた順番において、（たとえば関連メタ情報によって）ドキュメントのフラグメントを識別するコンテンツの表を含み得る。ユーザは、ドキュメントにおける対応するフラグメントにナビゲート（ｎａｖｉｇａｔｅ）するために、コンテンツの表からエントリを選択し得る。
【０００８】
別の実施形態において、格納されたドキュメントに異なる装置のユーザが同時に書込み（たとえば追加または変更）をすることを可能にする単一付加機能が提供される（たとえば装置から遠隔に格納されたドキュメントに対してフラグメントを存続させる）。これは、所定の時間において単一のユーザのみが格納されたドキュメントへのアクセス／変更ができて、コンテンツへの書込みアクセスをリクエストする次のユーザが待ち行列に追加されるという、格納されたコンテンツへの許可を与えるためのロッキングメカニズムを使用する従来のアプローチとは対照的である。
【０００９】
別の実施形態において、ドキュメントへの参加者に関連するパーティ（たとえばドキュメント参加者の「友人」または「友人の友人」）がドキュメントおよびそれに関連するマルチメディアコンテンツ（およびオプションとしてメタ情報）にアクセスすることを可能にするソーシャルネットワーキングプロトコルが提供される。そのようなパーティもまた、ドキュメントに付加された応答をパーティがメッセージとして送るとき、ドキュメント参加者になり得る。
【００１０】
別の実施形態において、マルチメディアメッセージのモバイル装置への配信を容易にするシステムおよび方法が提供される。たとえば、一実施形態において、ＸＭＬベースのマルチメディアメッセージは、メッセージのサイズを低減させるＸＭＬ「ショートコード（ｓｈｏｒｔ ｃｏｄｅ）」を用いて符号化される。それによって、メッセージを受信者に通信するために必要とされる、送信側機器によるＸＭＬ符号化の量および受信側機器によるＸＭＬ復号化の量の両方を低減させる。特に、メッセージにおけるＸＭＬツリーまたはサブツリーの構造がデフォルト構造に従う（ａｄｈｅｒｅ）とき（たとえば、メッセージの再生を担い、受信者の装置上で稼動するクライアントアプリケーションが、メッセージからメッセージへと静的に留まるツールバーまたはグラフィカルユーザインタフェース（ＧＵＩ）の側面を含むとき）、ツリーまたはサブツリーの構造を定義するメッセージの符号化部分は、構造を表す短縮されたコードによって置換されることができる。ショートコードが定義される特定のツリーまたはサブツリーは、メッセージフローに先立ってまたはその最中に決定され得る。たとえば、クライアント装置上にインストールされたクライアントアプリケーションは、インストレーション時にショートコード定義をすでに含み得るかまたは獲得し得る。代替的にまたは追加的に、ショートコードは、メッセージングフロー内に現れるツリーまたはサブツリーについてオンザフライ（ｏｎ−ｔｈｅ−ｆｌｙ）で定義され得る（たとえば、サブツリーが１回などの閾値回数よりも多くメッセージフロー内に現れたという判断に呼応して、サブツリーについてのショートコードを定義すること）。ショートコードを定義するとすぐに、ドキュメント参加者のメッセージング機器に対して、および／またはメッセージの遠隔格納を担うサーバに対して、ショートコード定義が提供され得る。好ましい一実施形態において、ＸＭＬショートコードはネトマティックマーク付け言語（ｎｍｌ）ショートコードであって、ｎｍｌは、２００２年１１月２８日に公開された、タイトルが「Ｓｈａｒｉｎｇ，Ｍａｎａｇｉｎｇ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｏｖｅｒ ａ Ｃｏｍｐｕｔｅｒ Ｎｅｔｗｏｒｋ」の、本明細書において全体が参照により援用されている米国特許出願公開第２００２０１７８１６４号に記載されたＸＭＬ準拠言語である。
【００１１】
別の実施形態において、コンテンツの部分のみが所定の時間においてモバイル装置に通信される。たとえば、通信ネットワークの帯域幅および／または待ち時間、および／またはモバイル装置の処理能力および／または記憶能力に基づいて、ドキュメントの一つ以上のフラグメントがモバイル装置に通信され得る。それに続く送信において、ドキュメントの別の一つ以上のフラグメントがモバイル装置に通信され得る。フラグメントは、ドキュメントを再組み立てするためにモバイル装置によって必要とされる情報のすべてを含むという点で、「自己認識（ｓｅｌｆ ａｗａｒｅ）」し得る。
【００１２】
さらに別の実施形態において、メッセージの非テキストマルチメディアは、メッセージのテキスト部分が装置に通信されるのと同時に、インラインＡＳＣＩＩ符号化バイナリーアセットとしてモバイル装置に通信される。ＡＳＣＩＩ符号化アセットは、メッセージサイズを低減するために圧縮され得る。対照的に、マルチメディアメッセージをモバイル装置に配信するための従来のアプローチは、メッセージのテキスト部分を装置に配信することを伴い、テキスト部分は非テキストメディアへの一連の参照を含む。そこで、非テキストメディアの各断片（ｐｉｅｃｅ）は、装置からのメディアについての別のリクエストに応答して、モバイル装置に配信される。情報についての複数のリクエストは、一つ以上のリクエストがサーバによって受信されないことに起因して、またはモバイル装置によって受信されるコンテンツ内の送信エラーに起因して、結果としてエラーになり得る。情報についての複数のリクエストは、ネットワーク遅延（すなわち待ち時間）をも増加させる。
【００１３】
別の実施形態において、モバイル装置は、「レイジーな（ｌａｚｙ）」プッシュ（ｐｕｓｈ）またはプル（ｐｕｌｌ）通知プロトコルを通してマルチメディアサーバと通信し得、そこではモバイル装置およびマルチメディアサーバは装置またはサーバが状態の変化を経験するときにのみ通信する。たとえば、モバイル装置の起動状態が変化する（たとえば装置が「オンライン」または「オフライン」になる）とき、この起動状態（および「使用中」、「不在」、「タイプ中」、「アイドル」などの他の「存在」情報）を示す１バイト通知を、装置はサーバに送信（プッシュ）し得る。通知は、他のモバイルユーザ（たとえばモバイルユーザの友人リストに列挙されたユーザ）の存在についてのリクエストなどの、サーバからのメッセージおよび／または他のアップデートについてのリクエスト（プル）としての役割も果たし得る。別の例において、サーバは、アップデートに関する警告を、そのようなアップデートが利用可能になったときに、モバイル装置に送信（プッシュ）し得る。このレイジーなプッシュおよび／またはプルプロトコルは、モバイル装置を用いたメッセージングのために必要とされるネットワークトラフィックの量を最小限にし、したがってたとえばネットワーク待ち時間を低減させる。
【００１４】
さらに別の実施形態において、モバイル装置は、単一の呼び出しにおいて情報についての複数のリクエストをサーバに対して行ない得る。たとえば、単一の呼び出しは、存在インタフェースからの存在情報についての第１のリクエスト、および定期購読（ｓｕｂｓｃｒｉｐｔｉｏｎ）インタフェースからのシンジケートされた（ｓｙｎｄｉｃａｔｅｄ）コンテンツについての第２のリクエストを含み得る。対照的に、従来の方法は、リクエストごとに一つの別々の呼び出しを発行する。レイジーなプッシュおよび／またはプルプロトコルと同様に、これもまたモバイル装置を用いたメッセージングのために必要とされるネットワークトラフィックの量を最小限にする。
【００１５】
別の実施形態において、シンジケートされたコンテンツ（たとえばニュース供給）は、媒介サーバを経由して、シンジケートされたコンテンツサーバからモバイル装置へと通信される。モバイル装置がシンジケートされたコンテンツをリクエストするとき、媒介サーバは、シンジケートされたコンテンツが格納されているメモリ（媒介サーバの、またはサードパーティコンテンツプロバイダによってホストされる（ｈｏｓｔｅｄ）サーバなどの他のメモリ）における場所への参照（リンク）を、装置に送信する。たとえば、その結果、装置は、コンテンツ自身をダウンロードおよび格納することなく、参照を追うことによって、コンテンツにアクセスすることができる。このようにして、シンジケートされたコンテンツサーバからの重複したコンテンツの格納およびコンテンツの検索は回避され、ネットワークトラフィックは低減される。これは、各ユーザの装置がコンテンツサーバからコンテンツを直接にアクセスおよびダウンロードすることを必要とする従来のアプローチと対照的である。
【００１６】
別の側面において、モバイル装置のユーザに提供される機能を強化する種々の機能が提供される。この機能は、エンドユーザによって装置が購入される時においてインターネットからダウンロードされてモバイル装置にインストールされ得るかまたはモバイル装置上のメモリに常駐し得るクライアントアプリケーションによって少なくとも部分的に提供され得る。別の例において、メッセージング機能は、専用クライアントアプリケーション以外のモバイル装置の資源（たとえばブラウザおよび／またはメディアプレイヤー）によるクライアントレスアプローチにおいて提供され得る。
【００１７】
一実施形態において、たとえば、ドキュメントがレビュー用に利用可能かどうか、ドキュメントが変化したかどうか、誰がドキュメントに対してアクセスまたは作業をしているか、および／またはドキュメントが最後にアップデートされたのはいつか、を示すドキュメントレベルの存在情報が（ユーザ存在情報への代替または追加として）提供され得る。たとえば、モバイルユーザがクライアントアプリケーションを起動するとき、ユーザは、ちょうど記述したドキュメント中心の特徴の一つ以上とともに、ユーザが参加者であるかまたはユーザが参加するように送信勧誘された一つ以上のドキュメントを要約する表示を提示され得る。
【００１８】
別の実施形態において、ユーザがメッセージおよびメッセージスレッドを記録、再生、および編集することを可能にする機能が提供され得る。たとえば、遠隔サイトにおいて格納されたマルチメディアコンテンツについてのメタ情報に基づいて、ユーザはメッセージコンテンツを検索するオプションを提示され得る。加えて、メタ情報は、メッセージの再生、たとえばユーザが時間、日付、および／または場所に基づいてメッセージをフィルタリングすることができる選択的再生を可能にする。
【００１９】
別の実施形態において、現在オフラインであるユーザにメッセージを送信するため、特定の日時、時間、および／または地理的場所についてのメッセージの配信をスケジュールするため、および／またはユーザがメッセージを検索するときにそのユーザ（およびゼロ以上の他のユーザ）と接続するための、「プッシュトゥメッセージ（ｐｕｓｈ−ｔｏ−ｍｅｓｓａｇｅ）」機能が提供され得る。
【００２０】
本発明の実施形態の上述の特徴はモバイル装置のコンテキストにおいて主に記述される一方で、これらの特徴は非モバイル装置（たとえばデスクトップコンピュータ）を用いたメッセージングにも適用され得る。
【００２１】
本発明のより良き理解のために、添付の図面とともに以下の記述に参照がなされ、全体にわたって同様の参照文字は同様の部分を参照する。
【発明を実施するための最良の形態】
【００２２】
本発明の実施形態は、ユーザがモバイル装置、デスクトップ装置、セットトップ装置または他の装置からメッセージを送るかにかかわらず、エンドユーザにシームレスな経験を提供する、装置およびネットワークにとらわれないマルチメディアメッセージング環境に関する。この環境の範囲内において、たとえばウェブ（ＨＴＴＰ）、ＳＭＴＰ／ＰＯＰ／ＩＭＡＰ、ＳＩＰ、ＣＤＭＡおよびＧＳＭ（ＧＰＲＳ、ＥＤＧＥ）などの異なるネットワークおよび／またはプロトコルにわたって、装置は互いにメッセージを送ることができる。
【００２３】
図１は、サーバ１０２（それぞれが一つ以上のサーバインタフェース１０４およびメモリ１０６を備えている）、たとえば携帯電話およびＰＤＡ（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）などの一つ以上のモバイル装置、および／またはデスクトップコンピュータなどの一つ以上の非モバイル装置などのユーザ機器１０８を含むシステム１００の実施形態を示す。システム１００はさらに、ゲートウェイ１１０と、レンダリングエンジン１１２と、ＨＴＴＰ／ｅメールサービス１１４と、ロードバランサー１１６と、サードパーティゲートウェイ１１８とを備える。たとえば、本発明の実施形態は、モバイル装置または非モバイル装置のユーザが、モバイルユーザの起動状況（たとえばオンライン、オフライン、使用中、不在、タイプ中、アイドルなど）を決定するためにモバイルユーザについての存在情報を見ることと、モバイルユーザをテキスト、画像、音声、ビデオなどの複数メディアに関連するコミュニケーションに携わらせることとを可能にし得る。ユーザ機器１０８（および随意にメッセージに関連したメタ情報）の間で通信されるメッセージは、たとえば将来のメッセージにおけるマルチメディアコンテンツの後日の参照および／または再利用のために、メモリ１０６におけるドキュメント（またはドキュメントの部分）としてサーバ１０４によって持続される（格納される）。システム１００におけるドキュメントがｎｍｌベースのドキュメントである場合、システム１００は、そのさまざまな構成要素において、「ネトマット（ｎｅｔｏｍａｔ）」変更子を用いてラベルされ得る（たとえばネトマットサーバ１０２）。
【００２４】
モバイル装置および非モバイル装置は、クライアントアプローチまたはクライアントレス（ｃｌｉｅｎｔｌｅｓｓ）アプローチを用いることによって、システム１００にネットワーク接続され得る。前者の場合、たとえば装置のユーザがインターネットからクライアントをダウンロードするのに続き、クライアントアプリケーションが装置にインストールされ得る。たとえば、モバイル装置に対するクライアントは、Ｊａｖａ（登録商標）で書かれた小さなフットプリントアプリケーションであり得る（すなわちモバイル装置がｊａｖａ（登録商標）使用可能な装置である場合）。一実施形態において、そのようなアプリケーションは、ＭＭＡＰＩ（マルチメディアＡＰＩ）およびＷＭＡ（ワイヤレスメッセージングＡＰＩ）サポートを用いたＭＩＤＰ １．０プラットフォームをも含み得るＪ２ＭＥ ＭＩＤＰ ２．０プラットフォームを使用して作成され得る。たとえば、クライアントがインストールされる特定のモバイル装置に依存して、クライアントは５０ｋ〜１５０ｋの範囲のサイズであり得る。もう一つの実施形態において、モバイルクライアントはＸＨＴＭＬユーザコンテンツ管理インタフェースであり得る。非モバイル装置に対するクライアントアプリケーションの例は、Ｊａｖａ（登録商標）１．４アプリケーション、Ｊａｖａ（登録商標）１．１アプレット、マクロメディアフラッシュ（Ｍａｃｒｏｍｅｄｉａ Ｆｌａｓｈ）６．０アプレット、またはＸＨＴＭＬユーザコンテンツ管理インタフェースを含む。クライアントレス装置は、装置に常駐する専用クライアントアプリケーション以外のリソース（たとえばブラウザ、テキストメッセージングおよび／またはメディアプレイヤー）の使用によって、システム１００にネットワーク接続され得る。一般的に、マルチメディアメッセージングのためのクライアントアプリケーションをインストールされた装置は、クライアントレス装置と比較して、増加したメッセージング能力を有し得る。たとえば、クライアントレス装置は、ＸＭＬ「ショートコード」およびインライン圧縮ＡＳＣＩＩ符号化バイナリーアセットを考え得る例外として、本明細書に記載される機能のすべてをサポートし得る。
【００２５】
サーバ１０２は、すべての入ってくるリクエストおよび出ていくリクエスト（たとえば更新のリクエストあるいはモバイルユーザ１０８へのまたはモバイルユーザ１０８からのメッセージを通信するリクエスト）を担い、メモリ１０６とインタフェースをとり、サーバインタフェース１０４を提供する。一実施形態において、サーバ１０２はＪ２ＥＥアプリケーションサーバである。
【００２６】
サーバインタフェース１０４は、変化する情報をモバイルまたは非モバイル装置に対して提供し得、統一された方法で装置１０８がサーバ１０２に接続することを可能にし得る。たとえば、インタフェース１０４は、以下のインタフェースのうち一つ以上を含み得る。アップロードアセットインタフェース（ＵＡＩ）、管理アセットインタフェース（ＭＡＩ）、バージョニングインタフェース（ＶＩ）（ｖｅｒｓｉｏｎｉｎｇ ｉｎｔｅｒｆａｃｅ）、通知インタフェース（ＮＩ）、存在インタフェース（ＰＩ）、定期購読インタフェース（ＳＵＩ）、許可およびチケッティングインタフェース（ＰＴＩ）、送信勧誘インタフェース（ｉｎｖｉｔｅ ｉｎｔｅｒｆａｃｅ）（ＩＩ）、ユーザデータ管理インタフェース（ＵＤＭＩ）、アクセス管理インタフェース（ＡＭＩ）、検索インタフェース（ＳＩ）、およびウェブサービスインタフェース（ＷＳＩ）。
【００２７】
ＵＡＩは、すべてのテキストおよびバイナリーアセットをサーバにアップロードすることを担い得る。ＭＡＩインタフェースは、たとえば、遠隔サイトにおいて存続するフラグメントにアクセスし、新しいドキュメントにおけるフラグメントを参照することによって、マルチメディアコンテンツを再利用することなどの、ユーザのアセットの遠隔管理することを担い得る。ＶＩは、すべての更新のバージョニングをして、ドキュメントのフラグメントについて履歴ファイルを生成することを担い得る。ＮＩは、ユーザのスペース（ドキュメントにおいてユーザが単なる参加者であるユーザに由来するドキュメント（たとえばメッセージスレッド）をも含む）への更新をユーザに通知することを担い得る。ＰＩは、たとえば、追加の存在情報のみならず、ユーザの友人リストに列挙されたパーティのそれぞれの起動状態を示す情報などの存在情報を担い得る。ＳＵＩは、コンテンツのシンジケーション（ｓｙｎｄｉｃａｔｉｏｎ）を担い得る。ＰＴＩは、ユーザのコンテンツに対する読取りおよび書込みのアクセスについての許可を設定および取得することを担い得る。ＩＩは、ユーザのスペースに対するワンタイム送信勧誘を担い得、ＰＴＩと異なる許可設定を設定し得る。ＵＤＭＩは、プロファイルおよびアドレス帳などのユーザデータを管理することを担い得る。ＡＭＩは、ユーザのコンテンツのパスワード保護およびパスワード管理を担い得る。ＳＩは、ユーザデータおよびユーザコンテンツを照会すること（たとえばシステム１００のすべてのユーザにとって公に利用可能な情報およびコンテンツの検索、またはドキュメント参加者のみに利用可能な情報などの個人情報の検索）を担い得る。ＷＳＩは、ユーザ機器１０８上で可動するクライアントアプリケーションにウェブサービスを統合することを担い得る。たとえば、ＷＳＩは通信のためにシンプルオブジェクトアクセスプロトコル（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）（ＳＯＡＰ）を使用し得、ウェブサービス記述言語（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）（ＷＳＤＬ）についての組込みサポートを有し得る。
【００２８】
ゲートウェイ１１０は、本発明の実施形態のマルチメディアメッセージングシステムと他の通信システムとの間にブリッジを生成するサーバ側アプリケーションである。たとえば、ゲートウェイ１１０は以下のゲートウェイのうちの一つ以上を含み得る。ＳＭＳ／ＭＭＳゲートウェイ（ＳＭＳＧ）、電子メール（ｅメール）ゲートウェイ（ｅＭａｉｌＧ）、存在ゲートウェイ（ＰｒｅｓｅｎｃｅＧ）、インスタントメッセージングゲートウェイ（ＩＭＧ）、コンテンツストリーミングゲートウェイ（ＣＳＧ）、および検索ゲートウェイ（ＳＧ）。ＳＭＳＧは、装置１０８からのＳＭＳメッセージおよびＭＭＳメッセージをサーバ１０２によってメモリ１０６に対するフラグメントとして存続されることを可能にする。ｅＭａｉｌＧは、テキストベースのｅメールメッセージと、メモリ１０６に対して存続されるドキュメントへの添付のあるｅメールメッセージとの統合を可能にする。ＰｒｅｓｅｎｃｅＧは、プリム（ｐｒｉｍ）および／またはシンプル（ｓｉｍｐｌｅ）なＪａｂｂｅｒまたはＷｉｒｅｌｅｓｓ Ｖｉｌｌａｇｅなどの他の存在ベースのシステム（およびしたがってこれらのシステムからの存在情報の使用）との統合を可能にする。ＩＭＧは、Ｊａｂｂｅｒ、ＡＩＭ、Ｗｉｒｅｌｅｓｓ ＶｉｌｌａｇｅおよびＩＣＱなどのインスタントメッセージベースのシステムとの統合を可能にする。ＣＳＧは、ストリーミング技術（たとえばストリーミング音声およびビデオについて）との統合を可能にする。ＳＧは、ＧｏｏｇｌｅおよびＭＳＭ検索などの既存の検索技術との統合を可能にする。たとえば、ユーザ機器１０８上に表示されたグラフィカルユーザインタフェース（ＧＵＩ）（たとえば機器１０８上で稼動するクライアントアプリケーションによって関連させられるＧＵＩ）に入力される検索語は、ＳＧによって検索技術に認識可能なフォーマットに変換され得、次に検索技術に提供され得る。検索技術によって返された検索結果は、ユーザ機器１０８に結果を表示させる前に、適切なフォーマット（たとえばＸＭＬ準拠言語ｎｍｌ）に変換され得、メタ情報（たとえば検索技術による検索結果を備えたメタ情報および／または検索のために使用された検索技術を示すソース情報）によってタグをつけられ得る。
【００２９】
サーバ１０２は、たとえばネトマットメッセージまたはアップデートが利用可能であること（たとえば存在情報および／またはシンジケートされたコンテンツに対するアップデート）を機器に警告するために、ＳＭＳ（テキスト）またはインターネットプロトコル（ＩＰ）パケット通知をユーザ機器１０８に典型的に送信する。ＳＭＳメッセージに関して、メッセージの特定の形式およびコンテンツは、通知がアドレス指定される装置がクライアント装置であるかクライアントレス装置であるかに依存して変化し得る。その目的のために、ネトマットサーバ１０２は、クライアントがインストールされた装置（モバイル装置など）のリストをメモリ１０６に格納し得るか、またはさもなければリストへのアクセスを有し得る。
【００３０】
たとえば、モバイル装置１０８がクライアントレス装置であることを決定するサーバ１０２に応答して、サーバ１０２はＳＭＳを介して装置に通知を送信し得る。ここでＳＭＳ通知は、新しいメッセージおよび／またはアップデート情報がサーバ１０２から利用可能であることを示す。ＳＭＳ通知は、たとえば、ドキュメント（またはドキュメントの部分）への外部リンク、またはメモリ１０６においてサーバ１０２によって存続させられるシンジケートされたコンテンツなどの他のコンテンツへの外部リンクを含み得る。ワイヤレスアプリケーションプロトコル（ＷＡＰ）プッシュメッセージ（たとえば）の形式における通知を受信するとすぐに自動的に、またはユーザがリンクを選択することに応答して、クライアントレスモバイル装置のブラウザは、ユーザのためにドキュメントまたはシンジケートされたコンテンツのアクセスおよび再生を行い得る（たとえばモバイル装置のディスプレイ領域におけるビデオ、テキストまたは画像の表示、モバイル装置のスピーカを介する音声の送信、またはこれらの組み合わせ）。応答をメッセージングするためにユーザがテキストを入力および提出できる一つ以上のフィールドも表示され得る。もう一つの例において、システム１００は、メモリ１０６においてテキストフラグメントとしてサーバ１０２によって存続され得るＳＭＳメッセージを用いた通知に対して、クライアントレスモバイル装置のユーザが応答することを可能にし得る。
【００３１】
代替的に、モバイル装置１０９にマルチメディアメッセージングのためのアプリケーションがインストールされていることを決定するサーバ１０２に応答して、サーバ１０２は通知ヘッダにおけるクライアントアプリケーションについてのポート番号を含むＳＭＳ通知を装置に対して送信し得る。これは、モバイル装置によってメッセージが受信されるとすぐにクライアントアプリケーションの自動的起動を引き起こし得る。ひとたび起動されると、クライアントアプリケーションは、サーバ１０２によってメモリ１０６に対して存続させられるドキュメント（ＳＭＳ通知において提供され得るリンク）にアクセスし得、ユーザがマルチメディアメッセージ応答を発行することを可能にし得る。さらに、クライアントアプリケーションが起動状態にある場合、メッセージまたはアップデートの通知は、ＳＭＳ経由ではなく、ＩＰチャネルを通してサーバ１０２によって送信され得る。その目的のために、サーバ１０２は、クライアントがインストールされたどのモバイル装置が起動状態にあるかを示すデータを格納し得るか、またはさもなければデータへのアクセスを有し得る。モバイル装置１０８上で稼動するクライアントアプリケーションが起動状態にあるかどうかをサーバ１０２によって決定することに関する追加の詳細は、１バイトの「レイジーな」プッシュまたはプル通知の記述と関連して以下に提供される。
【００３２】
システム１００におけるレンダリングエンジン１１２は、ユーザ機器１０８によってシステムにおいてメッセージを送られるマルチメディアコンテンツおよび／または他のコンテンツ（たとえばシンジケートされたコンテンツ）の表示および／または操作をするソフトウェアモジュールであり得る。たとえば、レンダリングエンジン１１２は、コンサートアリーナにおける電子ビルボードまたは映写などの、物理的スペースにおける公共ディスプレイを生成し得る。代替的にまたは追加的に、レンダリングエンジン１１２は、インターネットページ（たとえばワールドワイドウェブページ）上にコンテンツを公開し得る。コンテンツの公開および処理は、モバイル装置およびデスクトップ装置からの投票またはポーリングなどのように、リアルタイムで生じ得る。レンダリングエンジンはフラグメントが遠隔サイトに対して存続させられる順番において自動的にドキュメントのフラグメントを再生し得るという意味において、レンダリングエンジンはユーザの静的なインプットから動画の映画のような経験をも生成し得る。
【００３３】
図２Ａは、本発明に従ったたとえばデスクトップ装置に表示されたマルチメディアクライアントアプリケーションによって提供される説明的なディスプレイのスクリーンショットである。図２Ａにおいて、サーバ１０２によってメモリ１０６に対して存続させられるドキュメントがユーザのために表示される。より具体的には、図２Ａはユーザのスペースの概要を提供する。ユーザのスペースは、ユーザがドキュメントの参加者であるドキュメントのセットとして概念化され得る（すなわち、ユーザがオーサリング権を有するドキュメントのセット）。示されるように、タイトルが「ＭＩＫＥ’Ｓ ２５ＴＨ」の２０２がディスプレイの範囲内で現在選択されている。したがって、ドキュメント２０２のフラグメント２０４、２０６および２０８はユーザのために表示され、各フラグメントは、テキスト、画像および対応するメタ情報（たとえば作者および日時）を含む複数メディアを含む。ディスプレイは、さまざまな選択可能なオプションをも含み得る。オプション２１０、２１２および２１４もまた、ユーザがドキュメント「ＩＴ’Ｓ Ａ ＧＩＲＬ」、「ＨＡＰＰＹ ＢＩ．．．」および「ＤＥＣＥＭＢＥ．．．」をそれぞれ表示のために選択することを可能にするために提供される。オプション２１６は、ユーザが新しいドキュメントを作成することを可能にするために提供され得る。返信フィールド２１８は、ユーザが現在のドキュメント２０２における参加者への通信のためにマルチメディア応答を提出することを可能にし得る。示されるように、マルチメディア（たとえば画像）は、装置（「Ｍｙ Ｃｏｍｐｕｔｅｒ」オプション２２０）の局部記憶装置からの応答、またはユーザ指定のコンテンツ（「Ｍｙ Ｇａｌｌｅｒｙ」オプション２２２）の記憶装置に専用のメモリ１０６におけるような遠隔記憶装置における割当てからの応答に含まれるように選択され得る。「Ｆｕｎ Ｓｔｕｆｆ」オプション２２６は、ユーザが遠隔記憶装置からサードパーティマルチメディアコンテンツ（たとえばシンジケートされたコンテンツ）にアクセスすることを可能にし得る。プレビューウィンドウ２２４は、マルチメディアメッセージを送信する前にユーザが画像をプレビューすることを可能にし得る。オプション２２８は、ドキュメントに参加する２つの新しい送信勧誘がユーザにとって利用可能であることを示し得る。オプション２１８の選択は、ユーザが送信勧誘の送信者に関する送信勧誘および／またはプロファイル情報をレビューすることを可能にし得る。送信勧誘を受け入れることを選択することは、対応するドキュメントおよびそれに関連した情報をディスプレイに出現させ得る。
【００３４】
図２Ｂは、本発明の実施形態に従ったモバイル装置上で稼動するマルチメディアコンテンツアプリケーションによって表示されるような、図２Ａに示されるものと同じドキュメント２０２のスクリーンショットである。モバイルユーザにとって利用可能なオプションは、図２Ａの例においてユーザに提示されるオプションと同様かまたは同一であり得る。しかし、モバイル装置のより小さなディスプレイに起因して、ユーザは、オプションにアクセスするために表示をたとえばスクロールさせることが要求され得る。
【００３５】
図３は、本発明に従ったメッセージングメディアに関係する説明的なステージのフローチャート３００である。ステージ３０２において、サーバ１０２は、ユーザ機器１０８（たとえばモバイルユーザ機器）から、一つ以上の受信者（たとえばモバイルユーザ機器のもう一つのインストレーション）に対する通信を対象としたメディアメッセージを受信し得る。ステージ３０４において、サーバ１０２はメディアメッセージをメモリ１０６内のドキュメントとして格納し得る（たとえば一つ以上の受信者およびメディアメッセージの送信者から遠隔に）。ステージ３０６において、サーバ１０２は、一つ以上のメッセージ受信者に対して通信し得る。たとえば、サーバ１０２は、ドキュメント送信勧誘または他の通知を受信者に送信することによって受信者にメッセージを通知し得、受信者が送信勧誘を受け入れたことに応じて受信者にメッセージを通信し得る。受信者にメッセージを通信することは、遠隔に格納されたメッセージへのリンクを送信すること、および／またはメッセージのすべてまたは部分を受信者装置に送信することを含む。好ましい一実施形態において、メッセージからのマルチメディアコンテンツは、図５および６に関連して以下に記述する圧縮されたＡＳＣＩＩバイナリー符号化アセットとして受信者に好ましくは通信される。ステージ３０８において、サーバ３０６は、一つ以上の受信者に対してドキュメントを通信することに続き、遠隔記憶装置においてドキュメントを保持し得る。このことは、将来のメッセージにおいてドキュメント（およびそのマルチメディアコンテンツ）が参照および／または再利用されることを可能にし得る。一実施形態において、サーバ１０２は、ドキュメントに参加する送信勧誘を受け入れたユーザ、またはメッセージをフラグメントとしてドキュメントに付加したユーザを、ドキュメントへの参加者として指定し得、これによってユーザ間の関連性を作成する。この関連性はユーザのコミュニティを確立し得、ユーザはそのコミュニティに特定の機能を提供され得る。
【００３６】
本発明の側面において、マルチメディアメッセージング（たとえばテキスト、画像、ビデオ、および／または音声を用いたメッセージング）を通した進行中の方法で、モバイルユーザ１０８が他の装置のユーザと共働することを可能にするシステムおよび方法が提供される。たとえば、サーバ１０２がメッセージおよび関連するメタ情報をドキュメント（たとえばまたはドキュメントのフラグメント）として存続させるのに先立って、モバイル装置および非モバイル装置１０８によって生成されるマルチメディアメッセージは、メッセージの送信者および受信者から遠隔にメモリ１０６において識別用メタ情報（たとえば作者、日時、時間、および／または場所）によって自動的にタグをつけられ得る。別の例として、格納されたドキュメントに対して、異なる装置１０８のユーザが同時に書込む（たとえば追加または変更する）ことを可能にする単一付加機能が提供され得る（たとえば装置から遠隔に格納されたドキュメントに対してフラグメントを存続させる）。さらに別の例として、格納されたドキュメントおよびそれに関連したマルチメディアコンテンツ（および随意にメタ情報）を元来のメッセージ受信者以外のパーティによってアクセスされることを可能にするソーシャルネットワーキングプロトコル（ｓｏｃｉａｌ ｎｅｔｗｏｒｋｉｎｇ ｐｒｏｔｏｃｏｌ）が提供され得る（たとえば「友人の友人」プロトコル）。以下にこれらの特徴をより詳細に記述する。
【００３７】
（メッセージされたコンテンツの自動メタ情報タグつけ）
ウェブ資源は、作者、リンク、キーワード、および記述に関する情報を提供するメタタグを含む。この情報は、ドキュメントの検索および機械処理のために有用である。これの一つの現在の方法は、ＲＤＦ、すなわちＸＭＬの拡張であり、他の機械によって効率的に処理されることができる機械生成のメタデータのオーサリング、操作、および検索のためのツールをフレームワークに提供する。
【００３８】
現在、ＲＤＦタグなどの方法を通してメタデータを供給することは、いくらかの人間のインプットを必要とする（たとえば、情報を明確にサポートすること、またはタグを入力すること）。しかし、通信システムにおいて作成されるドキュメントの量を記述するためには、自動的にタグを挿入することが必要であり、特に、マルチメディアメッセージングシステムがフラグメント付加操作を通して同時アップデートを可能にする本発明の実施形態においては必要である（以下により詳細に記述する）。
【００３９】
一実施形態において、本発明は、各ドキュメントまたはその部分を記述するために自動メタ情報タグつけを使用する。たとえば、すべてのドキュメントが一つ以上のフラグメントを含む好ましい一実施形態において、ドキュメントの範囲内の各フラグメントは、フラグメントの作成場所、日付、および作者を示すメタ情報によってタグをつけられ得る。モバイル装置に関して、場所情報は、グローバルポジショニングシステム（ＧＰＳ）によって測定されるようなモバイル装置の地球規模の場所についての識別、モバイル装置についての識別（たとえば携帯ＩＤ）に基づいて、および／またはユーザからのインプット（たとえばユーザがニューヨーク州の範囲内にいるというユーザからの指摘）に基づいて生成され得る。非モバイル装置についての場所情報は、ＧＰＳに基づき得るか、またはユーザインプット（たとえばユーザの装置が存在するところの郵便番号をユーザが述べたユーザのユーザプロファイル）に応じ得る。メタ情報に基づいて、フラグメントおよびドキュメントは検索、編集、および編成されることができ、これらの変更は他者によって見られることができる。
【００４０】
自動メタ情報タグつけは、アップデートされた情報がさらなる使用のために適切にタグつけされることを確実にするのに役立つ。一実施形態において、ユーザ機器１０８上で稼動するクライアントアプリケーションは、メッセージがサーバ１０２に送信される前に、作者、日付、時間、および場所（これらのすべては送信装置の機能である）によって，新しいメッセージにタグをつけ得る。別の実施形態において（たとえばメッセージがクライアント装置から送信される場合）、サーバ１０２は、メモリ１０６においてメッセージを存続させる前に、またはコンテンツを分散型配置におけるもう一つのサーバに送信する前に、メタ情報によってメッセージにタグをつけ得る。図４は、本発明の実施形態に従うドキュメント作成時間におけるメタ情報の挿入を示す。特に、ドキュメントのフラグメントは、以下のようにタグをつけられる。フラグメント名＝「ｆｒａｇｍｅｎｔ」、作者名＝「Ｍａｃｉｅｊ」、日時「２７−Ｊｕｌ−０４ １６：２１ＰＭ ＭＳＴ」、および場所情報＝「Ｐａｒｉｓ」ならびに「：：：Ｌａｔｉｔｕｄｅ：１９ｄｅｇｒｅｓｓ−４５ｍｉｎｕｔｅｓ−３２．４ｓｅｃｏｎｄｓ− ｎｏｒｔｈ：：：Ｌｏｎｇｉｔｕｄｅ：１５５ｄｅｇｒｅｅｓ−２７ｍｉｎｔｕｅｓ−２２．８ｓｅｃｏｎｄｓ−ｗｅｓｔ：：：Ａｌｔｉｔｕｄｅ：２３００ｆｅｅｔ」。次にフラグメントがドキュメントに付加され、ドキュメントは他のフラグメントの形式において一つ以上の以前の関連するメッセージを含む。
【００４１】
（単一付加操作を用いたグローバルユーザ管理ファイルシステム）
システム１００は、任意の装置１０８から地球規模でアクセス可能なコンテンツ管理システムを提供し得、マルチメディアアセットの検索、分類、送信、削除、共有、および再利用の能力を提供し得る。対照的に、従来のファイルシステムは、読込み中またはアップデート中のファイルに対するアクセスを「ロック」し、これらのファイルについての追加リクエストがキューに追加される。アクセスをロックすることは、追加の処理時間およびサーバメモリを必要とし、アップデートが損失されることと、実際に保存されていなかったデータへの変更がアップロードされることと、アップデートされたファイルを再読取りする問題とを生じ得る。
【００４２】
システム１００によって提供されるグローバルファイルシステムは、ファイルをアップデートする単純かつ効率的な方法を提供し、上述の問題を回避する。好ましい一実施形態において、既存のフラグメントに上書きすることによってではなく、新しいフラグメントを付加することによってすべてのドキュメントが変更されることができるので、ドキュメントの範囲内のランダム書込みは実質的に存在しない。したがって、ひとたび書込まれれば、ドキュメントの範囲内のフラグメントは読取り専用であり、ほとんどの部分にわたって順次読取られる。グローバルファイルシステムは、ディレクトリにおいて階層的にファイルを編成し、ドメインにおいて以下のようなパスのパス名によってファイルを識別する、ドメインベースのシステムであり得る。
／ｍ／ａ／ｃ／ｉｅｊ／ｔｒａｖｅｌ／ｉｎｄｅｘ．ｖ４５．ｎｍｌ
これは次のドメインに位置付けられ得る。
ｈｔｔｐ：／／ｗｗｗ．ｎｅｔｏｍａｔ．ｎｅｔ
グローバルファイルシステムは、標準的な開く（ｏｐｅｎ）、閉じる（ｃｌｏｓｅ）、作成する（ｃｒｅａｔｅ）、削除する（ｄｅｌｅｔｅ）、読取る（ｒｅａｄ）、および書込む（ｗｒｉｔｅ）の操作、ならびに各装置の付加の統合性を保証しながら複数の装置１０８が一つのドキュメントに同時にフラグメントを付加することを可能にするフラグメント付加（ｆｒａｇｍｅｎｔ ａｐｐｅｎｄ）をサポートする。
【００４３】
フラグメントアプローチは、従来の分散ファイルシステムよりも著しくより単純であり、したがって縮小することがより簡単であり、エラーに対してよりトレラントである。フラグメントアプローチは、異なるエンドユーザ装置間のデータ同期の必要性を排除することにも役立つ。これらの問題のそれぞれは、ロッキングメカニズム（ｌｏｃｋｉｎｇ ｍｅｃｈａｎｉｓｍ）の使用を通してユーザがウェブ資源を共働で編集、公開、および管理することを可能にするＷｅｂＤＡＶなどの現在のウェブベースのプロトコルにおける問題であるが、スケーラビリティの問題をも生じやすかったものであり、フラグメント付加機能を提供しない。
【００４４】
（メッセージングフローおよびプロトコルレイヤに組み込まれたソーシャルネットワーキングプロトコル）
現在のソーシャルネットワーキングアプリケーションは、ユーザがソーシャルネットワークを形成することを奨励する特徴を提供するとともに、ユーザ間のやり取りまたは関係を認識するための多くの方法を提供する。一実施形態において、本発明は、インタラクションパターンのより細分な（ｇｒａｎｕｌａｒ）研究を通して、ソーシャルネットワーキングを容易にする。
【００４５】
本発明は、モバイル装置の所定のセットについて、装置間の実際のインタラクションに基づいて、ときどき社会契約と呼ばれる適切な社会規則を定義する自動的な方法を提供する。たとえば、ユーザが作成したドキュメントは、互いに知っている人々のみまたは互いに紹介された人々のみがメッセージの送信および受信をすることを可能にする「友人の友人」プロトコルを使用してリンクされることができる。そのメッセージはそこでフラグメントとしてドキュメントに付加され得る。
【００４６】
たとえば、友人のドキュメントは、メッセージが受信パーティによって受け入れられた場合に作成され得（すなわち、無視されるかまたは削除されるのではなく、受信パーティによってアクセスされ得）、それによって送信パーティおよび受信パーティの間の「信頼のリンク」を作成する。一般的に、信頼のリンクはインスタントドキュメントの目的のみに有効であることになる。すなわち、送信者が参加する他の個人的なドキュメントに対するアクセスを受信パーティに与えることにはならないという意味であり、逆もまた同じである。このようにして、友人の友人のネットワークは、ユーザ間の進行中の通信／共働の範囲内から有機的に成長されることができる。
【００４７】
別の例として、ときどきバディーリスト（ｂｕｄｄｙ ｌｉｓｔ）と呼ばれる友人のリストは、ユーザによって作成されるか、またはサーバインタフェース１０４の送信勧誘、定期購読、および通知の処理の結果として自動的に生成されることができる。
【００４８】
ユーザ自身を表現および記述するためにユーザによって作成されるユーザデータの収集であるプロファイルもまた提供され得る。しかし、ユーザはユーザのプロファイルを隠すかまたはプロファイルに対するアクセスを制限することが許可され得る。プロファイルはネットワークの範囲内のユーザを識別するために使用される。システム１００は、マルチメディアプロファイルならびに一定の通信の間のプロファイルの「反対のルックアップ（ｒｅｖｅｒｓｅ ｌｏｏｋｕｐ）」をサポートし得る。すなわち、（たとえば）メッセージの受信者は、送信者からのメッセージを受け入れる前に、メッセージの送信者のプロファイルをレビューすることができるという意味である。プロファイルはユーザの公開プロファイルである。
【００４９】
変化する信頼度は、異なる社会的なつながりに起因し得る。たとえば、最大の信頼度は、友人のリストのメンバー間で示され得る。この変化する信頼、および／または他のユーザのプリファランスは、システム１００がユーザに配信されることを可能にするソーシャルネットワークに参加するための送信勧誘の種類をフィルターにかけるために使用され得る。たとえば、システム１００は、たとえば配布リストまたはサブジェクトタグ（ｅメール用のＳＰＡＭブロッキングと同様）の属性に基づいてメッセージが好ましくないと決定されない場合は、パーティ送信勧誘がユーザに配信されることを許可する。
【００５０】
システム１００は、ソーシャルプロトコルを作成するプロセスを自動化する。システム上の各メッセージは、メタタグがつけられ、格納され（ユーザがそれを削除しない場合）、後日の使用のために検索可能であるので、システム１００はネットワーク内に生ずる任意のソーシャルタイ（ｓｏｃｉａｌ ｔｉｅ）を追跡することができる。この能力は、メッセージフラグメント間のリンク、およびメッセージがどのようにアクセスされるかのみに適用され得るものであり、メッセージの内容には適用され得ないことに留意することは重要である。
【００５１】
本発明の別の側面において、マルチメディアメッセージのモバイル装置への配信を容易にするシステムおよび方法が提供される。たとえば、ＸＭＬベースのマルチメディアメッセージは、送信者によるＸＭＬ符号化の量および受信者によるＸＭＬ符号化の量の両方を削減するＸＭＬ「ショートコード」を用いて符号化され得るものであり、これはメッセージを受信者に通信するために必要とされる。別の実施形態において、たとえば通信ネットワークの帯域幅および／または待ち時間、および／またはモバイル装置の処理能力および／または格納能力に依存して、ドキュメントの一部のみが所定の（ｇｉｖｅ）時間においてモバイル（または非モバイル）装置に通信され得る。さらに別の実施形態において、メッセージのテキスト部分が装置に通信されるのと同時に、メッセージの非テキストマルチメディアは、インラインＡＳＣＩＩ符号化バイナリーアセットとしてモバイル装置に通信され得る。別の実施形態において、モバイル装置１０８およびサーバ１０２が装置またはサーバが状態の変化を経験するときのみに通信をする「レイジーな」プッシュおよび／またはプル通知プロトコルを通して、モバイルユーザ１０８はサーバ１０２と通信し得る。さらに別の実施形態において、モバイル装置１０８は、単一のリクエストにおいて複数のサーバインタフェース１０４に対する情報のために複数の呼び出しを行ない得る。別の実施形態において、サーバ１０２は、（たとえばニュース供給を提供する）シンジケートされたコンテンツサーバと一つ以上のモバイル装置１０８との間の媒介として機能し得る。これは、コンテンツ格納の重複を回避し得、ネットワークトラフィックを低減し得る。以下にこれらの特徴をより詳細に記述する。
【００５２】
（短縮された符号化−ＸＭＬショートコード）
本発明の実施形態は、特にワイヤレスネットワークにわたって、ＸＭＬベースのドキュメントをより効率的に送信する方法を提供する。送信のサイズを低減することは、すべての通信方法にとっての目標である一方で、低い帯域幅および高いオーバヘッドによって効率性が影響を受ける携帯電話などの資源の限定された装置に関する主要な懸念である。本発明は、追加の符号化ソフトウェアを必要とすることなく、ドキュメントサイズを低減させることにより、送信サイズを低減させ、ドキュメントの符号化および復号化の計算負担を排除する。
【００５３】
既存のメッセージングシステムは、ネットワークにわたるより効率的な送信のためにデータを符号化するための２つの方法に頼る。これらの方法は、バイナリー符号化および圧縮である。両方のアプローチは、符号化された送信を解釈するために必要とされるオーバヘッドに関して効率性の影響を有する。
【００５４】
バイナリー形式でファイルを符号化するＷＢＸＭＬ（ワイヤレスバイナリーＸＭＬ）などのバイナリー符号化方法。バイナリー符号化の欠点は、符号化および復号化、および符号化／復号化ソフトウェアのための追加のメモリに関連する、ユーザ機器およびマルチメディアサーバの両方におけるオーバヘッドを処理することを含む。
【００５５】
データ圧縮は、ドキュメントを格納および送信するために必要とされるオーバヘッドおよびネットワーク帯域幅を低減するための他の従来のアプローチである。バイナリー符号化と同様に、データ圧縮は解釈を必要とすることによって、各装置上に圧縮／解凍ソフトウェアを必要とし、ならびに圧縮／解凍に起因する送信／レンダリングのプロセスに待ち時間を導入する。
【００５６】
一実施形態において、本発明は、再利用可能なマーク付け言語を特定し、その言語のためのショートコードで代替することによって、ＸＭＬ符号化についての必要性を排除する第３の解決法を提供する。たいていの場合、これはバイナリー符号化およびデータ圧縮よりも効率的である。本発明は、ドキュメントサイズを削減し、ネットワーク帯域幅を節約し、追加のソフトウェアを必要としないことによって、装置上のメモリを節約し、オーバヘッド処理を排除する。システム１００がｎｍｌ（ネトマティックマーク付け言語）（ｎｅｔｏｍａｔｉｃ ｍａｒｋｕｐ ｌａｎｇｕａｇｅ）ベースのドキュメントを送信する好ましい一実施形態において、ショートコードは（ｎｍｌ）ショートコードである。ｎｍｌは、上記の援用されている米国特許出願公開第２００２０１７８１６４号に記載されたＸＭＬ準拠言語である。
【００５７】
一つのｎｍｌショートコードは、一つまたは多くのｎｍｌコード要素を表す。ショートコードは、ｎｍｌ要素の基礎をなす構造を、単一のコード要素へと崩壊させる（ｃｏｌｌａｐｓｅ）。ショートコードは、任意のｎｍｌツリー／サブツリーについて代替されることができる。アプリケーションがｎｍｌ要素のデフォルト値を認識する場合、およびこれらの値がｎｍｌアプリケーションのライフサイクルの間に一定に留まる場合、ショートコードは挿入される。ショートコードは、追加の前前処理なしに複雑なドキュメントがより効率的に処理されることを可能にする既存の構文解析系およびインタプリタによって処理される。
【００５８】
たとえば、ｎｍｌ＜ｔｏｏｌｂａｒ＞要素は、ｎｍｌアプリケーションのユーザインタフェースを定義する要素および属性を含む。すなわち、レイアウト、ルックアンドフィール、および機能などの属性である。子供の要素および属性を有する＜ｔｏｏｌｂａｒ＞定義の例を以下に示す。
＜ｔｏｏｌｂａｒ ｔｙｐｅ＝“ａｌｌ”＞
＜ｆｏｒｍＣｏｎｔａｉｎｅｒ ｎａｍｅ＝“ＡｄｄＩｍａｇｅ” ｉｄ＝“００３”＞
＜ｓｕｂｍｉｔ ａｃｔｉｏｎ“ｈｔｔｐ：／／ｍｏｂｉｌｅ．ｎｅｔｏｍａｔ．ｎｅｔ／ａｃｃｏｕｎｔ／ａｄｄＩｍａｇｅ．ｊｓｐ
“ｔａｒｇｅｔ＝“ＩｍａｇｅＦｏｒｍ”ｍｅｔｈｏｄ＝“ＧＥＴ” ｉｄ＝“０１” ｎａｍｅ＝“Ａｄｄ Ｉｍａｇｅ”＞
＜／ｓｕｂｍｉｔ＞
＜／ｆｏｒｍＣｏｎｔａｉｎｅｒ＞
＜／ｔｏｏｌｂａｒ＞
たとえば、上記のコーディングについてのツリー構造は、以下のように表現され得る。
【００５９】
【化１】
したがって、毎回ユーザインタフェースが必要とされるたびに（上記のツリーによって図示されるような）この構造の全体の＜ｔｏｏｌｂａｒ＞定義を送信するのではなく、ショートコードが送信される。
【００６０】
この場合に使用されるショートコードは以下のようであり得る。
＜ｔｏｏｌｂａｒ ｔｙｐｅ＝“ａｌｌ”／＞
＜ｔｏｏｌｂａｒ＞ショートコードは、レイアウト、ルックアンドフィール、および機能を定義する属性を隠す。ツールバー要素の最初の送信において「ｔｙｐｅ＝ａｌｌ」の属性値を提供することによって、その要素に属するサブツリーはショートコードに適格であるとしてマークされる。この次にアプリケーションが上記におけるような「ｔｙｐｅ＝ａｌｌ」の属性を有する＜ｔｏｏｌｂａｒ＞要素を受信するとき、アプリケーションは＜ｔｏｏｌｂａｒ＞をショートコードとして認識する。
【００６１】
別の例において、画像のシーケンスを生成するために、以下のサンプルコードに示すようにショートコード「＜ｓｌｉｄｅｓｈｏｗ＞」が使用され得る。画面に対して画像のシーケンスをどのようにレンダーするかは、クライアントアプリケーションに委ねられ得ることに留意すべきである。たとえば、一つの画像を次の画像で置き換えることによって画像はプレロードおよび循環させられ得るか、またはアイテムが一旦選択されると画像はスクロール可能な領域において連続して表示され得る。
【００６２】
【化２】
したがって、繰り返される符合は識別用属性によってマークされ、冗長符号は次の通信において再送信されない。このアプローチを使用すると、メッセージ交換の大きなチャンクはショートコードであることができ、ネットワークにわたって送信されるファイルのサイズを効率的に低減させる。場合によっては、所定のショートコードを通したメッセージ交換の前に、ショートコードは示されることができる。クライアントアプリケーションがショートコードを認識しない場合、クライアントアプリケーションはメッセージをサーバ１０２に送信することができるので、繰り返される符合は全体として送信されることになる。
【００６３】
（マルチメディアメッセージおよび任意の長さのメッセージスレッドの配信）
別の実施形態において、本発明は、帯域幅および高い待ち時間を限定された記憶装置を有する装置に限定してきたネットワークにわたって大きなファイルおよび任意の長さのメッセージを配信することに関連する問題を排除する。たとえば、ＸＭＬフラグメントをドキュメントに組み立てるためのＸＭＬフラグメント仕様などのより複雑なアプローチの代わりになるものとして、ＸＭＬおよびより具体的にＸＭＬ準拠言語であるｎｍｌは、「チャンク可能な」ドキュメントを作成するための単純な解決法を提供する。
【００６４】
ｎｍｌを用いれば、ドキュメントに関するサイズの制限はない。ｎｍｌフラグメントは、チャンクにおけるドキュメントを配信するための柔軟性を提供する。すなわち、完全なドキュメントとは対照的に、データチャンクはより大きなドキュメントに属する。
【００６５】
フラグメントはドキュメントの一部であり、たとえば限定された記憶装置および処理能力を有し得るモバイル装置１０８に配信されることができるほど十分に小さい。一度に配信されるフラグメントの数は、ネットワークスループットおよび装置能力に基づき得る。システム１００は、ネットワークにわたって次のフラグメントをロードし得るので、ドキュメントが局所的にスクロールされているという外観を与える。
【００６６】
一実施形態において、本発明は、ネットワーク帯域幅および装置１０８に基づいて、必要に応じて１〜ｎ個のフラグメントを配信する能力を提供する。送信されることができるフラグメントの数には上限がない。送信されるフラグメントのデフォルト数は、ユーザプリファランスとして動的に無効にされることができる。
【００６７】
ｎｍｌフラグメントは、ゼロまたは多くのｎｍｌオブジェクト（要素）を含むことができる。ｎｍｌオブジェクトは、時間および空間におけるオブジェクトとして定義される。すなわち、ｎｍｌオブジェクトは、作者、最後に変更された日付／時間のスタンプ、および利用可能な場合はその地理的場所として定義される属性（前述のメタ情報）を含むという意味である。ｎｍｌフラグメントは、図４に示される。
【００６８】
このメタ情報は、ｎｍｌオブジェクトを「自己認識」させる。すなわち、ドキュメントを再組み立てするために必要とされる情報は、フラグメント自身の範囲内に含まれるという意味である。フラグメントは、フラグメントの外部の規則または知識を必要としない。この自己認識に基づいて、任意の２つのｎｍｌフラグメントが分類されることができる。
【００６９】
（インライン圧縮ＡＳＣＩＩ符号化バイナリーアセット）
モバイルネットワークが拡大するにつれて、小さな画面によって特徴づけられ、信頼性のないネットワーク接続性および低い帯域幅になりやすい装置に対して、フォーマットされたマルチメディアプレゼンテーションを配信する、より速く、より効率的で、ユーザフレンドリな方法に対するニーズも拡大する。モバイルおよび固定ネットワークにわたるメッセージにおいてマルチメディアを交換する既存の方法は、本発明と比較すると、指数関数的に高い数のクライアント／サーバの呼び出し／応答を必要とする。したがって、ネットワークにより高い要求を課し、送信セッションをネットワーク障害にさらし、ユーザをより長い待ち時間にさらす。
【００７０】
電話ブラウザ（ｐｈｏｎｅ ｂｒｏｗｓｅｒ）などの従来のモバイルアプリケーションは、画像を含むＨＴＭＬまたはＸＨＴＭＬなどのマルチメディアファイルをロードするために以下のステップを必要とする。最初に、ＨＴＭＬファイルについてのユーザからのリクエストに応じて、ＨＴＭＬファイルがロードされなければならない。次に、ＨＴＭＬファイルにおける各埋め込み画像がロードされなければならない。ここで、各埋め込み画像は別々のユーザリクエストを必要とする。ＭＭＳおよび他のメッセージングシステムによって同様の戦略が採用される。一つ以上の呼び出しがサーバによって受信されないことに起因して、またはモバイル装置によって受信されたコンテンツにおける送信エラーに起因して、情報についての複数の呼び出しが結果としてエラーになり得る。
【００７１】
一実施形態において、従来のシステムとは異なり、システム１００は、複数の呼び出しを排除し、メッセージサイズを低減することによって、マルチメディアコンテンツをモバイル装置１０８に効率的に配信する。特に、モバイル装置１０８からの単一の呼び出しは、サーバ１０２に、ＡＳＣＩＩ符号化されたおよび圧縮された（たとえばサーバ１０２によって圧縮され符号化された）マルチメディアアセットを含むｎｍｌファイルを送信させる。圧縮されると、ＡＳＣＩＩ符号化されて圧縮されたファイルは１２パーセント〜３０パーセント小さい。すべてのＴＣＰ／ＩＰ接続のために必要とされるオーバヘッドを低減することにより（すなわち呼び出し／応答の数を低減させることにより）、追加の１０パーセントの利点が達成される。一つのメッセージに複数のアセットを含むメッセージを配信する能力は、結果としてより速い配信になり、著しく改善されたユーザ経験を実現させる。システム１００はモバイル環境に比類なく適切である。システム１００は、サーバが応答しなければならない呼び出しの回数を限定することによって、サーバ１０２の資源をも保護する。たとえば、図５はモバイル装置の表示画面のスクリーンショットであり、ここでは、サーバ１０２（図１）への単一の呼び出しに応答して、７つの画像５０２〜５１４（および関連テキスト）がモバイル装置に送信される。
【００７２】
図６は、インライン圧縮ＡＳＣＩＩ符号化バイナリーアセットとしての５つの画像（サイズは合計５０ｋ）を含むコンテンツを、マルチメディアクライアントアプリケーションがインストールされた（さらにメッセージがｎｍｌメッセージである）モバイル装置に配信するために必要とされる配信時間に対して、同じコンテンツを（ＡＳＣＩＩ符号化バイナリーアセットのインライン圧縮を用いない）モバイル装置のＨＴＭＬブラウザに送信するために必要とされる配信時間を示すグラフである。より詳しくは、２８．８ｋｂｐｓラインにわたる配信について、圧縮ＡＳＣＩＩ符号化バイナリーアセットは４８．４秒で配信されたのに対して、ＨＴＭＬブラウザへの同じコンテンツの送信は６６．５秒を必要とした。
【００７３】
以下は、３つの画像を含むｎｍｌファイルについての説明的なコードを示す。この例において、インラインメッセージは、ＬＺ７７アルゴリズムおよびＨｕｆｆｍａｎ符号化の組み合わせを含む標準的なデータ圧縮アルゴリズムを用いて圧縮され、Ｂａｓｅ６４として符号化される。インライン画像（たとえば１２７２バイト）は、ＪＰＧ形式におけるもともとの画像（たとえば１５６４バイト）よりも小さい。
【００７４】
【化３】
【００７５】
【化４】
【００７６】
【化５】
【００７７】
【化６】
以下は、３つの画像への参照を含むＨＴＭＬファイルについての説明的なコードを示す。各画像のサイズは１５６４バイトであり、サーバへの別々の呼び出しを必要とする。したがって、このドキュメントを表示するためには、サーバへの４つの呼び出しが必要とされる（すなわち、テキストをリクエストするための一つと、各画像についてひとつずつで３つの追加リクエストである）。
【００７８】
【化７】
（１バイト「レイジーな」プッシュまたはプル通知）
モバイル装置の使用の拡大は、モバイルおよび固定ネットワークにわたってインプリメントされるメッセージングシステムに対する需要をますます増加させ続ける。現在のネットワークは、帯域幅および接続信頼性の点で著しい限界を有しており、そのことはしばしば結果として失われたまたは損なわれたメッセージとなる。現在のメッセージングシステムは、帯域幅およびネットワーク信頼性に起因する問題に直面している。
【００７９】
一実施形態において、本発明は、メッセージの交換において必要とされるネットワークトラフィックの量を最小限にすることによって、モバイルおよび固定ネットワークのためにより速くより柔軟なメッセージングシステムを提供する。本発明は、ユーザが自分の装置にダウンロードする情報をユーザが選択することを可能にする一方で、帯域幅および記憶装置などのネットワーク資源および装置資源を最大限にする。
【００８０】
具体的には、本発明はメッセージおよびデータの交換を制御する通知方法に関する。本発明は、ユーザ状態、アップデート、メッセージ、および／または他の情報を集約する（ｃｏｎｓｏｌｉｄａｔｅ）配信メカニズム（たとえば１バイト配信メカニズム）を提供する。１バイト通知は、装置状態情報を、装置とサーバ１０２との間のコンテンツおよびメッセージの配信を制御する情報とひとまとめにすることによって、ネットワークトラフィックを最小限にする。対照的に、従来のメッセージングシステムは、装置における変化の信号を送るためと、データにおける変化の信号を送るために、別々の通知を必要とする。従来のメッセージングシステムにおいては、１バイト通知方法とは対照的に、トラフィックは１キロバイトにおいて測定される。
【００８１】
図７は、本発明の一実施形態に従った１バイト通知のフローダイヤグラムを示す。ステージＡにおいて、ユーザ機器は、サーバに命令（たとえばエンドユーザによって定義された命令）を送信し、たとえばドキュメントがいつ変更またはアップデートされるかをユーザ機器に通知されるべきこと（たとえばシンジケートされたコンテンツに対するアップデートがいつ利用可能であるか、またはユーザが参加するドキュメントに対してユーザがいつ応答を持続したかなど）を指定する。ユーザ機器は、アップデートが利用可能である場合、アップデートの１バイト通知、アップデートの要約、または実際のアップデート自身
を受信することになるかどうかをも指定する。ステージＢにおいて、サーバは命令を受信する。ステージＣにおいて、グローバルファイルシステム（および存在インタフェースなどの他の機器）は、ユーザのプリファランスに関係するアップデートを含むアップデートをサーバに提供する。ステージＤにおいて、ユーザのプリファランスに基づいて、サーバはユーザ機器に対して、ユーザに対するアップデートの１バイト通知（警告）、アップデートの要約、または実際のアップデート自身のいずれかを「プッシュ」し、ステージＥにおいてユーザはそれを受信する。警告または要約について、エンドユーザはステージＦにおいてアップデートを無視またはダウンロードすることを選択することができる。アップデートをダウンロードするリクエストに応答して、サーバはステージＧにおいてユーザ機器に対してプッシュし、ユーザ機器はステージＨにおいてコンテンツを受信する。別の実施形態において、ユーザ機器は「プル」通知の手順を実行し得る。その手順において、ユーザ機器は、たとえばサーバからアップデートをリクエストするために「ｎ」秒ごとにサーバに照会する（たとえばユーザ機器の状態についてサーバに警告することに加えて）。
【００８２】
本発明に従った１バイト通知は、種々の形態を取り得る。たとえば、一実施形態において、Ｙ、Ｎ、Ｓ、またはＰなどの一つのＡＳＣＩＩ文字を格納するために、８ビット（１バイト）通知が使用され得る。ここで、各文字は、特定のコンテンツ（たとえばシンジケートされたコンテンツのみに関する通知など）の通知（またはリクエスト）または任意の／すべてのアップデートコンテンツ（たとえばアップデートの種類を指定することなくアップデートが利用可能であるという通知を表す「Ｙ」文字）を表し得る。別の実施形態において、存在についての状態情報（たとえば利用可能または使用中）を表す０〜９９、ドキュメントについての状態情報を表す１００〜１９９、およびエラーコードを表す２００〜２５５などの特定の情報を表す状態コードを表すために、８ビットが使用され得る。別の実施形態において、ドキュメントの満了日における変化などの変化の種類（たとえば４ビット）、ならびに変更が緊急であるかまたは変更の確認あるいは他のアクションが必要とされるという指示などの変化（４ビット）に関連する属性を定義するために８ビットが使用されることができる。
【００８３】
（サーバインタフェースの動的連結）
サーバへのリクエストは、サーバがリクエストを読むことと応答をフォーマットすることができるように、適切にフォーマットされなければならない。クライアントアプリケーションがインストールされたモバイル装置１０８は、単一の呼び出しを使用して種々のサーバインタフェース１０４から情報をリクエストすることができる。別の実施形態において、サーバは、そのような連結された呼び出しを送信するオプションを有するクライアントレス装置を提供することができる。ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）およびＨＴＴＰなどの従来の方法を用いると、そのようなリクエストは、各インタフェースについて一つの、複数の呼び出しに分離させられる。対照的に、本発明に従ったクライアントアプリケーションは、たとえば存在インタフェースおよびユーザ検索用インタフェースの両方から情報をリクエストする呼び出しを生成し得る。単一の呼び出しは一連の従来のＨＴＴＰ呼び出しを含み、そのそれぞれはサーバにＨＴＴＰ呼び出しを同時に処理させるように変更された引き数を有する。本発明は、より効率的な方法において標準およびプロトコル（ＨＴＴＰ）を使用する。サーバは、リクエストされたコンテンツのすべてを、リクエストする装置に送信する単一の応答に集約することができる。
【００８４】
ＨＴＴＰは、データをサーバに書き込む（ｐｏｓｔ）ＨＴＴＰＰＯＳＴ、および応答をリクエストするＨＴＴＰＧＥＴなどの、いくつかの有用なクライアント／サーバ呼び出しを提供する。複雑なシステムは、より複雑なリクエストを送信するために効率的な方法を必要とする。ウェブアプリケーションは、通常いくつかのＨＴＴＰＰＯＳＴリクエストおよびＨＴＴＰＧＥＴリクエストから成る。たとえば、一つのＨＴＴＰＰＯＳＴリクエストはユーザデータをサーバに提出するために使用されることができ、もう一つのＨＴＴＰＰＯＳＴリクエストは任意のユーザを登録するユーザであることができる。
【００８５】
そのようなリクエストを送信するために、クライアントアプリケーションは、各インタフェース１０４に別々のリクエストを送信するのではなく、異なるリクエストおよび応答を自動的に連結する。インタフェースは、クライアントおよびサーバが情報を交換できるようにクライアントとサーバとの間に接続が作られる点である。各インタフェースは階層の一部であり、階層においてインタフェースはより上位のインタフェースの特性を引き継ぐ。これらのインタフェースは単一のリクエストの間により多くの情報をサーバに渡すことができるので、この継承は、複数のインタフェースの機能を組み合わせることによって、サーバインタフェース１０４の能力を拡張する。たとえば、サーバ１０２に対する単一のリクエストにおいて、ユーザ状態および新しいユーザデータを受け取る。
【００８６】
たとえば、図８は、本発明の実施形態に従ったサーバインタフェースの動的連結を示す。示されるように、第１のモバイル装置は、サーバ１０２に対する単一の統合された呼び出しにおいて、存在、バージョニング、および通知のインタフェースにアクセスし得る。第２のモバイル装置は、サーバ１０２のインタフェースに対して、別々の連続した呼び出しを実行し得る。非モバイル装置は、定期購読および検索のインタフェースに対する単一の統合された呼び出しと、アセット管理インタフェースに対する別の呼び出しとを実行し得る。
【００８７】
別の例として、システム１００における存在は、ドキュメントと密接に結合される。一人の人間は、特定のドキュメントまたはドキュメントの収集の範囲内において、グローバルな存在を有すること、および存在することの両方ができる。存在を有するネトマットドキュメントは、ライブの（ｌｉｖｅ）共働環境になる。図１と関連して記述されたように、存在インタフェース（ＰＩ）は、ユーザの存在および利用可能性を担う。通知インタフェース（ＮＩ）は、ユーザのスペースおよびユーザが参加するスペースへのアップデートをユーザに通知することを担う。ユーザ通知は、ＰＵＬＬまたはＰＵＳＨメカニズムにいずれかを使用することができる。コンタクトリストは、送信勧誘、定期購読、および通知のインタフェースを通して自動的に作成および管理される。ＰＩインタフェースは、以下の構造を有し得る。
【００８８】
【化８】
ＮＩインタフェースは、以下の構造を有し得る。
【００８９】
【化９】
以下は、連結された存在および通知のインタフェースとともに、コモンゲートウェイインタフェース（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）を使用した、サンプルのＨＴＴＰＧＥＴリクエストおよびサーバ応答である。通知インタフェースは、存在インタフェースから受け継ぎ、ドキュメントリスナー（ＤｏｃｕｍｅｎｔＬｉｓｔｎｅｒ）インタフェースをインプリメントする。
【００９０】
【化１０】
【００９１】
【化１１】
サーバ応答は、最後の変更されたストリングならびにドキュメントに束縛された存在情報の両方を返す。「ｂｒ」は、ユーザがブラウザを使用していることを示す。
【００９２】
（配信されたコンテンツシンジケーション対媒介サーバ）
コンテンツシンジケーションは、コンテンツ消費者がコンテンツ生産者の供給を定期購読することを可能にする技術を参照する。クライアント／サーバ環境においてシンジケートされたコンテンツを配信するための多くのフォーマットがあり、ＲＳＳ（Ｒｅａｌｌｙ Ｓｉｍｐｌｅ Ｓｙｎｄｉｃａｔｉｏｎ）およびＩＣＥ（Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｃｏｎｔｅｎｔ Ｅｘｃｈａｎｇｅ）を含む。これらのフォーマットは、同様の方法で定期購読者にコンテンツを配信し、それによってコンテンツはすべてのユーザのためにコンテンツサーバからダウンロードされなければならない。コンテンツ定期購読者の膨大な数を考慮すると、この配信方法は、通信ネットワークに多大な負荷をかけ、ボトルネックを生じ、記憶装置のための要求を増加させる。
【００９３】
一実施形態において、本発明は、ネットワークトラフィックを最小限にし、コンテンツの重複を排除し、スケーラブルなコンテンツ共有メカニズムを提供する方法で、シンジケートされたコンテンツを無数のユーザに容易に配信する方法を提供する。
【００９４】
本発明は、従来のアプローチと区別される方法で、シンジケートされたコンテンツの配信をインプリメントする。第一に、シンジケートされたコンテンツサーバからのすべての新しいニュース供給は、装置１０８に対するアップデートのスケジューリングおよび配信のための媒介として作用するサーバ１０２に集約される。図９は、定期購読シナリオを図示する。すべての供給をサーバ１０２に集約することによって、定期購読者はもともとの供給からデカップルされ（ｄｅｃｏｕｐｌｅｄ）、それによって同時のダウンロードリクエストによって生じ得るボトルネックを排除する。サーバ１０２はトラフィックを制御し、装置１０８を過剰なネットワークトラフィックおよびボトルネックから絶縁する。
【００９５】
第二に、シンジケートされたコンテンツは、サーバ１０２に留まり、そこで要求側装置によって共有され、ネットワークトラフィック、潜在的なボトルネック、および記憶装置要求をさらに低減させる。サーバ１０２は、一つ以上のシンジケーションサーバからコンテンツを定期的にダウンロードし、シンジケートされたコンテンツを定期購読するクライアントアプリケーションによって装置１０８に警告する。クライアントはアップデートを選択的にリクエストでき、サーバはクライアントへの配信のためにアップデートを最適化する。クライアントがコンテンツをリクエストする場合、サーバ１０２は、コンテンツへの参照（リンク）をクライアントのネトマットスペース（たとえばシンジケートされたコンテンツに関連するドキュメントに対するフラグメントとして）にコピーするが、実際のコンテンツをサーバ上に残す。
【００９６】
さらに、一人のユーザは、シンジケートされたコンテンツを他のユーザと容易に共有できる。たとえば、ユーザがシンジケートされたコンテンツを選択すると、コンテンツはメッセージフローの中に挿入されて他のユーザと共有される。したがって、（たとえば）ニュース供給は、追加の転送メカニズムを用いることなく、進行中の会話の中に動的に挿入されることができ、ただちに他のユーザと共有されることができる。ユーザは、任意の他のユーザがシンジケートされたコンテンツ供給を共有するように送信勧誘することができる。図１０は、コンテンツがどのように共有されるかを図示する。送信勧誘された人は、ニュース供給への次のアップデートが通知され、アップデートは無視またはダウンロードされ得る。
【００９７】
ユーザはグループの範囲内でコメントを書き込む（ｐｏｓｔ）ことができる。それによって、会話の開始、および／または共働ドキュメントの形成をする。定期購読される供給をグループのメンバーが受信すると、グループのすべてのメンバーも供給の通知を受信する。個々のグループメンバーは供給を受信または無視することを選択し得、グループの社会的性質をさらに強化する。コンテンツ配信およびコンテンツのメッセージへの自動的挿入に関連する低いオーバヘッドに起因して、グループはたとえばほぼ数百万程度の人々を容易に収容することができる。
【００９８】
本発明の別の側面において、モバイルメッセージングに関してモバイルユーザの能力を増強する種々の機能が提供される。この機能は、モバイル装置上で稼動するクライアントアプリケーションによって少なくとも部分的に提供され得る。たとえば、そのようなクライアントは、エンドユーザによる購入時に、インターネットからダウンロードされてモバイル装置にインストールされ得るか、またはモバイル装置上のメモリに常駐し得る。別の例において、メッセージング機能は、専用クライアントアプリケーション以外の資源（たとえばブラウザおよび／またはメディアプレイヤー）によるクライアントレスアプローチにおいて提供され得る。一実施形態において、たとえば、ドキュメントがレビュー用に利用可能であるか、ドキュメントは変化したか、誰がドキュメントに対するアクセスまたは作業をしているか、および／またはドキュメントが最後にアップデートされたのはいつかを示す、ドキュメントレベルの存在情報が提供され得る。別の実施形態において、ユーザがメッセージおよびメッセージスレッドを記録、再生、および編集することを可能にする機能が提供され得る。たとえば、ユーザは、遠隔サイトに格納されたメッセージをそのコンテンツについて格納されたメタ情報に基づいて検索するオプションを提示され得る。別の実施形態において、指定された日付、時間、および／または地理的場所についてのメッセージの配信をスケジューリングするために、および／またはユーザがメッセージを受信するときにユーザ（およびゼロ以上の他のユーザ）と接続するために、現在オフラインであるユーザに対してメッセージを送信するための「プッシュトゥメッセージ」機能が提供され得る。以下にこれらの特徴をさらに詳細に記述する。
【００９９】
（ネットワーク、存在、および場所を認識するドキュメント）
存在は、通信ネットワークにおけるユーザのオンラインまたはオフライン状態として典型的に理解される。従来の存在の例は、ＡＯＬのインスタントメッセージングシステムおよび「バディーリスト」などのインスタントメッセージングであって、サーバは、ユーザがオンラインまたはオフラインであるかを認識しており、使用中、不在、タイプ中、およびアイドルなどのより細分な存在の状態を追跡することもできる。このシステムにおいて、焦点はユーザに当てられる。
【０１００】
一実施形態において、本発明は、ドキュメントレベルの存在と呼ばれる新しい種類の存在を導入する。ユーザに関する存在情報に対する代替または追加として、本発明は、システム１００のユーザがドキュメントを位置付けることおよびドキュメントについて共働することを可能にする。ドキュメント存在は、ドキュメントの状態、場所、およびネットワークアウェアネス（ｎｅｔｗｏｒｋ ａｗａｒｅｎｅｓｓ）に関して、有意義な情報をユーザに提供する。適切な許可を有するユーザは、ドキュメントがレビュー用に利用可能か、ドキュメントが変化したか、誰が所定のドキュメントに対してアクセスまたは作業をしているか、誰がオンライン会話（メッセージスレッド）内に存在しているか、およびドキュメントが最後にアップデートされたのはいつか、を理解することができる。
【０１０１】
上述のように、サーバ１０２に知られ、ユーザによって照会されることのできる、作者、場所、および日時スタンプなどのメタ情報を、ｎｍｌドキュメントは含み得る。ドキュメント存在は、たとえばドキュメントの信号を送ること、および異なる参加者によってなされる増分変化を管理することなどの共働環境において重要である。グローバルポジショニングシステム（ＧＰＳ）データによって提示されるような場所アウェアネスは、ドキュメントがどこで作成されたかに関する情報を提供する。ネットワークアウェアネスは、ドキュメントオブジェクトに、それらがどこに発送され（ｓｈｉｐｐｅｄ）つつあるか、およびドキュメント存在の状態に基づいて、調整する能力を与える。すなわち、ドキュメントは、ネットワーク状態によって決定されるような一つ以上のフラグメントを配信または添付することができる。たとえば、モバイル装置上にインストールされたクライアントアプリケーションが、（たとえばネットワーク帯域幅に基づいて）クライアントがデータパケットを落とすかまたは落としそうであると判断する場合、クライアントはサーバに対して、所定の時間においてより少ないフラグメントを送信するようにリクエストし得る。クライアントレスアプリケーションについては、サーバは、所定の時間においてデフォルト数のフラグメント（たとえば１フラグメント）を送信し得る。
【０１０２】
ドキュメントの任意の部分が作業中である場合、システムはドキュメントの存在および場所を知っている。その情報は、許可を有するユーザによって照会されることができる。たとえば、ユーザは、特定の時間においてコンテンツを誰が見て誰が変更したかを照会することができる。ドキュメントは、時間および空間における自己管理オブジェクトである。ドキュメントレベルの存在は、何がドキュメントを構成するか、およびドキュメントがどのように処理されるかについて、細分性のもう一つのレベルを追加する。
【０１０３】
（メッセージおよびメッセージスレッドの記録機能および再生機能）
ウェブサイト、写真、およびストリーミングメディアファイルなどの従来のマルチメディアは、ユーザが送信されたドキュメントを編集することを可能にせず、所望の情報のフィルタリングまたは識別のため、および再生のための、限定されたオプションを可能にするのみである。
【０１０４】
再生、すなわちドキュメントにおける情報が現れる動画化されたシーケンスは、メッセージングスレッドおよび掲示板などの時間ベースでないメディアとは対照的に、秒あたりのフレームにおいて表示するビデオまたはスピーチなどの時間ベースのメディアにとって、より重要な問題として通常理解される。しかし、アクセス情報および注文情報は、時間ベースのメディアおよび時間ベースでないメディアの両方にとって重要である。
【０１０５】
一実施形態において、本発明は、任意のメッセージ交換または共働が選択的に記録されて選択的に再生されることを可能にする。本発明は、検索機能および選択機能を提供するので、ユーザは所望の再生情報を位置付けることおよび選択することができる。たとえば、本明細書に記述されているようにメディアのフラグメントがサーバ１０２によってメモリ１０６に対して存続させられた順番を定義するメタ情報に基づいて、ユーザはドキュメント全体を始めから終わりまで再生し得る。別の例として、ドキュメントの任意の点において発生し得るユーザ編集に基づいて、再生の順番は、変更、停止、および開始されることができる。
【０１０６】
選択的な記録／再生機能は、ドキュメントの根底にある構造、すなわちフラグメントの収集に起因して可能である。記録された会話は、小さなサイズのフラグメントの収集から成り、フラグメントのそれぞれはメタ情報として自動的にタグつけされている。フラグメントに組み込まれているメタ情報ならびに所定の設定にフィルターを適用することによって、メッセージ交換は選択的に記録されることができる（たとえば、所定の作者によって、特定の日付において、特定の場所において、および／または特定の時間の間に生成されたフラグメントのみを再生すること）。
【０１０７】
再生機能は、定義された順番でフラグメントをロードおよび表示することによって可能にされる。再生の順番およびコンテンツは、異なるフィルターおよび分類アルゴリズムをメッセージに適用することによって、リアルタイムで定義および再定義されることができる。それによって、ドキュメントの範囲内のどこからでも再生が始まることを可能にする。
【０１０８】
（プッシュトゥメッセージ機能）
プッシュトゥメッセージ機能は、以下のように提供され得る。
【０１０９】
警告およびメッセージ（Ａｌｅｒｔ−ａｎｄ−ｍｅｓｓａｇｅ）は、ユーザがオフラインであるときに、ネトマットユーザが他のネトマットユーザにインスタントメッセージを送信することを可能にする。ユーザがオフラインである場合、ユーザのモバイル装置上のネトマットアプリケーションが自動的に起動し、メッセージのユーザに警告する。現在のモバイルメッセージングシステムは、プッシュレジストリ（ｐｕｓｈ ｒｅｇｉｓｔｒｙ）機能を使用することによって、装置上のアプリケーションを「目覚めさせる」することができる。同様に、技術革新は、ネトマットアプリケーションを「目覚めさせる」こと、または後日の配信のためにメッセージをシステム上にロードすることができる。アプリケーションを目覚めさせることは、任意の時間についてスケジュールされることができる。たとえば、ただちに、２時間以内に、または２ヶ月以内に。警告およびメッセージのメタ情報は、ネットワーク機能であるのではなく、ドキュメント自身の中に組み込まれる。このことは、この情報を検索可能にし、配信問題に対してより脆弱ではなくする。
【０１１０】
配信するスケジュール（Ｓｃｈｅｄｕｌｅ−ｔｏ−ｄｅｌｉｖｅｒ）は、ネトマットユーザがメッセージ配信についての時間および地理的場所を指定することを可能にする。たとえば、ネトマットユーザは、「２０１０年１０月１日」などの特定の日付において、および「シカゴのオヘア空港」などの特定の場所において他のネトマットユーザに配信されるメッセージを作成することができる。ユーザは、設定された時間においてメッセージが削除されるようにスケジュールすることもできる。配信するスケジュールのメタ情報は、ネットワーク機能であるのではなく、ドキュメント自身に組み込まれる。これは、この情報を検索可能にし、配信問題に対してより脆弱ではなくする。
【０１１１】
配信時接続（Ｃｏｎｎｅｃｔ−ｏｎ−ｄｅｌｉｖｅｒｙ）は、ユーザおよび他の選択されたユーザが受信側ユーザに接続することを可能にし、このときメッセージは首尾よく配信される。たとえば、ネトマットユーザは、誕生日において祝辞を述べる別のユーザにメッセージを送信し得る。誕生日ユーザがメッセージを受け入れると、誕生日ユーザに祝辞を述べるために数人の他のユーザが同時に接続される。配信時接続のメタ情報は、ネットワーク機能であるのではなく、ドキュメント自身に組み込まれる。これは、この情報を検索可能にし、配信問題に対してより脆弱ではなくする。
【０１１２】
このようにして、モバイル装置を用いたマルチメディアメッセージングのために方法およびシステムが提供されることが理解される。本明細書において特定の実施形態が詳細に開示されたが、説明の目的のみのための例示を目的としてなされたものであり、以下の添付の特許請求の範囲について限定するように意図されるものではない。特に、特許請求の範囲によって定義される本発明の精神および範囲から逸脱することなく、種々の置換え、変更、および修正がなされ得ることは、本発明者によって予期される。他の側面、利点、および修正は、以下の特許請求の範囲の範囲内にあると考えられる。提示される特許請求の範囲は、本明細書に開示される本発明を代表するものである。他の、特許請求の範囲でない発明もまた予期される。本発明者は、後の特許請求の範囲において、そのような発明を追求する権利を保留する。
【図面の簡単な説明】
【０１１３】
【図１】図１は、本発明の一実施形態に従ったマルチメディアメッセージングシステムの図である。
【図２Ａ】図２Ａは、本発明の一実施形態に従った非モバイル装置上で稼動するマルチメディアクライアントアプリケーションによって提供される説明的な表示のスクリーンショットであり、サーバによってメモリに存続させられるドキュメントが表示される。
【図２Ｂ】図２Ｂは、本発明の一実施形態に従ったモバイル装置上で稼動するマルチメディアコンテンツアプリケーションによって表示されるような、図２Ａに示されるものと同じドキュメントのスクリーンショットである。
【図３】図３は、本発明に従ったメッセージングメディアに関わる説明的な段階のフローチャートである。
【図４】図４は、本発明の一実施形態に従ったドキュメント作成時におけるメタ情報の挿入を示す。
【図５】図５は、モバイル装置の表示画面のスクリーンショットであり、マルチメディアサーバに対する単一の呼び出しに応答して、７つの画像がモバイル装置に送信される。
【図６】図６は、マルチメディアクライアントアプリケーションがインストールされたモバイル装置へのインライン圧縮ＡＳＣＩＩ符号化バイナリーアセットとしてのマルチメディアコンテンツの配信時間に対して、同じメッセージをＨＴＭＬブラウザに通信するために必要とされる配信時間との比較を示す。
【図７】図７は、本発明の一実施形態に従った１バイト通知のフロー図である。
【図８】図８は、本発明の一実施形態に従ったクライアントサーバインタフェースの動的連結を示す。
【図９】図９は、本発明の一実施形態に従った媒介サーバを介したコンテンツシンジケーションの配信を示す。
【図１０】図１０は、本発明の一実施形態に従った媒介サーバを介したコンテンツシンジケーションの配信を示す。
【特許請求の範囲】
【請求項１】
送信者と一つ以上の受信者との間でメディアをメッセージングするための方法であって、該方法は、
該一つ以上の受信者への通信のために意図されたメディアメッセージを受信することと、
該送信者および該一つ以上の受信者のユーザ機器から遠隔に該メディアメッセージをドキュメントとして格納することと、
該メディアメッセージを該一つ以上の受信者に通信することと、
該通信することの後に該遠隔格納において該ドキュメントを保持することと
を包含する、方法。
【請求項２】
前記送信者および前記一つ以上の受信者を前記ドキュメントにおける参加者として指定し、それによって該送信者と該一つ以上の受信者との間に関係を作り出すことをさらに包含する、請求項１に記載の方法。
【請求項３】
前記メディアメッセージを前記受信することは、テキスト、画像、音声、およびビデオから成るメディアタイプのグループから選択される二つ以上のメディアタイプを包含するメディアメッセージを受信することを包含する、請求項１に記載の方法。
【請求項４】
前記送信者および前記一つ以上の受信者のうちの少なくとも一つの前記ユーザ機器はモバイル装置である、請求項１に記載の方法。
【請求項５】
ドキュメント参加者に前記ドキュメントへのアクセスを提供することと、
該ドキュメント参加者からのリクエストに応答して、該アクセスされるドキュメントを変更すること、または該アクセスされるドキュメントからのマルチメディアコンテンツを包含する新しいドキュメントを遠隔に格納することと
をさらに包含する、請求項１に記載の方法。
【請求項６】
能力を提供することによって第１のドキュメント参加者が応答を提出することによって前記ドキュメントに書き込むことができることと、
能力を提供することによって第２のドキュメント参加者が応答を提出することによって該ドキュメントに同時に書き込むことができることと
をさらに包含する、請求項１に記載の方法。
【請求項７】
所定の基準に基づいてユーザの部分集合に前記ドキュメントへのアクセス権を与えることをさらに包含する、請求項１に記載の方法。
【請求項８】
前記受信されたメッセージおよび前記通信されたメッセージのうちの少なくとも一つが、符号化されたツリーまたはサブツリーの符号化構造を短縮するショートコードを包含する、請求項１に記載の方法。
【請求項９】
前記ショートコードを定義することをさらに包含する、請求項８に記載の方法。
【請求項１０】
ドキュメント参加者からの前記ドキュメントについてのリクエストを受信することであって、該ドキュメントは複数のフラグメントを包含する、ことと、
該リクエストに応答して該ドキュメント参加者に該フラグメントの一部分のみを送信することと
をさらに包含する、請求項１に記載の方法。
【請求項１１】
前記メッセージを前記一つ以上の受信者に通信することは該メッセージをインライン圧縮ＡＳＣＩＩ符号化バイナリーアセットとして配信することを包含する、請求項１に記載の方法。
【請求項１２】
前記メッセージを前記一つ以上の受信者に通信することは、
該メッセージを受信する前に該受信者とのアイドル通信状態を保持することと、
該メッセージを受信することに応答して該メッセージの使用可能度を示す通知を該受信者に送信することと、
該受信者からの該メッセージについてのリクエストを受信することに応答して該メッセージを該受信者に通信することと
を包含する、請求項１に記載の方法。
【請求項１３】
ドキュメント参加者から前記ドキュメントに関連する情報に対するアップデートについてのリクエストを受信することをさらに包含し、該リクエストは同一の呼び出しにおいて一つ以上の追加リクエストと同時に受信される、請求項１に記載の方法。
【請求項１４】
シンジケートされたコンテンツサーバからシンジケートされたコンテンツを受信することと、
前記ドキュメント参加者から遠隔に該シンジケートされたコンテンツを格納することと、
該ドキュメント参加者のうちの少なくとも一つに該シンジケートされたコンテンツを提供することと
をさらに包含する、請求項１に記載の方法。
【請求項１５】
前記ドキュメントが変化したかどうかを示す情報および該ドキュメントに現在アクセスしているドキュメント参加者を識別する情報から成るドキュメントレベルの存在情報のグループから選択されるドキュメントレベルの存在情報をドキュメント参加者に提供することをさらに包含する、請求項１に記載の方法。
【請求項１６】
前記メッセージを（メタ情報とともに）格納する前に該メッセージに該メタ情報によってタグをつけることと、
該メタ情報に基づいてドキュメント参加者が遠隔に格納されたドキュメントを検索することを可能にすることと
をさらに包含する、請求項１に記載の方法。
【請求項１７】
現在オフラインである別のドキュメント参加者にメッセージを送信することと、特定の日付、時間、および／または地理的場所についてのメッセージの配信をスケジュールすることと、該別のドキュメント参加者がメッセージを検索するときにリアルタイム環境において該別のドキュメント参加者に接続することと、から成る機能のグループから選択される、プッシュトゥメッセージ機能を、ドキュメント参加者に提供することをさらに包含する、請求項１に記載の方法。
【請求項１８】
送信者と受信者との間でメディアをメッセージングするための方法であって、該方法は、
該受信者への通信のために意図されたメディアメッセージを受信することであって、該受信者のユーザ機器はモバイル装置であり、該メディアメッセージは非テキストメディアを包含する、ことと、
該メディアメッセージを該一つ以上の受信者に通信することであって、該非テキストメディアは一つ以上のインラインＡＳＣＩＩ符号化バイナリーアセットとして該受信者に通信される、ことと
を包含する、方法。
【請求項１９】
送信者と一つ以上の受信者との間のメディアのメッセージングを容易にするためのサーバであって、該サーバは、
該一つ以上の受信者への通信のために意図されたメディアメッセージを受信し、
該送信者および該一つ以上の受信者のユーザ機器から遠隔に該メディアメッセージをドキュメントとして格納し、
該メディアメッセージを該一つ以上の受信者に通信し、
該通信することの後に該遠隔格納において該ドキュメントを保持する
ように構成されている、サーバ。
【請求項２０】
ローカルメモリに常駐するクライアントアプリケーションを有するユーザ機器であって、該クライアントアプリケーションは、
一つ以上の受信者への通信のために意図されたメディアメッセージを生成する能力をユーザに提供し、
該メディアメッセージをサーバに送信する
ように構成され、該メディアメッセージが該一つ以上の受信者に通信された後で該メディアメッセージは該ユーザ機器および該一つ以上の受信者のユーザ機器から遠隔に格納され該遠隔格納において保持される、ユーザ機器。
【請求項２１】
コンピュータ実行可能なプログラムコードが記録されたコンピュータ読取り可能なメディアであって、該コンピュータ読取り可能なメディアは、
一つ以上の受信者への通信のために意図されたメディアメッセージを受信することと、
該メディアメッセージの送信者および該一つ以上の受信者から遠隔で該メディアメッセージをドキュメントとして格納することと、
該メディアメッセージを該一つ以上の受信者に通信することと、
該通信することの後に該ドキュメントを該遠隔格納内に保持することと
を包含する方法を実行する、コンピュータ読取り可能なメディア。
【請求項１】
送信者と一つ以上の受信者との間でメディアをメッセージングするための方法であって、該方法は、
該一つ以上の受信者への通信のために意図されたメディアメッセージを受信することと、
該送信者および該一つ以上の受信者のユーザ機器から遠隔に該メディアメッセージをドキュメントとして格納することと、
該メディアメッセージを該一つ以上の受信者に通信することと、
該通信することの後に該遠隔格納において該ドキュメントを保持することと
を包含する、方法。
【請求項２】
前記送信者および前記一つ以上の受信者を前記ドキュメントにおける参加者として指定し、それによって該送信者と該一つ以上の受信者との間に関係を作り出すことをさらに包含する、請求項１に記載の方法。
【請求項３】
前記メディアメッセージを前記受信することは、テキスト、画像、音声、およびビデオから成るメディアタイプのグループから選択される二つ以上のメディアタイプを包含するメディアメッセージを受信することを包含する、請求項１に記載の方法。
【請求項４】
前記送信者および前記一つ以上の受信者のうちの少なくとも一つの前記ユーザ機器はモバイル装置である、請求項１に記載の方法。
【請求項５】
ドキュメント参加者に前記ドキュメントへのアクセスを提供することと、
該ドキュメント参加者からのリクエストに応答して、該アクセスされるドキュメントを変更すること、または該アクセスされるドキュメントからのマルチメディアコンテンツを包含する新しいドキュメントを遠隔に格納することと
をさらに包含する、請求項１に記載の方法。
【請求項６】
能力を提供することによって第１のドキュメント参加者が応答を提出することによって前記ドキュメントに書き込むことができることと、
能力を提供することによって第２のドキュメント参加者が応答を提出することによって該ドキュメントに同時に書き込むことができることと
をさらに包含する、請求項１に記載の方法。
【請求項７】
所定の基準に基づいてユーザの部分集合に前記ドキュメントへのアクセス権を与えることをさらに包含する、請求項１に記載の方法。
【請求項８】
前記受信されたメッセージおよび前記通信されたメッセージのうちの少なくとも一つが、符号化されたツリーまたはサブツリーの符号化構造を短縮するショートコードを包含する、請求項１に記載の方法。
【請求項９】
前記ショートコードを定義することをさらに包含する、請求項８に記載の方法。
【請求項１０】
ドキュメント参加者からの前記ドキュメントについてのリクエストを受信することであって、該ドキュメントは複数のフラグメントを包含する、ことと、
該リクエストに応答して該ドキュメント参加者に該フラグメントの一部分のみを送信することと
をさらに包含する、請求項１に記載の方法。
【請求項１１】
前記メッセージを前記一つ以上の受信者に通信することは該メッセージをインライン圧縮ＡＳＣＩＩ符号化バイナリーアセットとして配信することを包含する、請求項１に記載の方法。
【請求項１２】
前記メッセージを前記一つ以上の受信者に通信することは、
該メッセージを受信する前に該受信者とのアイドル通信状態を保持することと、
該メッセージを受信することに応答して該メッセージの使用可能度を示す通知を該受信者に送信することと、
該受信者からの該メッセージについてのリクエストを受信することに応答して該メッセージを該受信者に通信することと
を包含する、請求項１に記載の方法。
【請求項１３】
ドキュメント参加者から前記ドキュメントに関連する情報に対するアップデートについてのリクエストを受信することをさらに包含し、該リクエストは同一の呼び出しにおいて一つ以上の追加リクエストと同時に受信される、請求項１に記載の方法。
【請求項１４】
シンジケートされたコンテンツサーバからシンジケートされたコンテンツを受信することと、
前記ドキュメント参加者から遠隔に該シンジケートされたコンテンツを格納することと、
該ドキュメント参加者のうちの少なくとも一つに該シンジケートされたコンテンツを提供することと
をさらに包含する、請求項１に記載の方法。
【請求項１５】
前記ドキュメントが変化したかどうかを示す情報および該ドキュメントに現在アクセスしているドキュメント参加者を識別する情報から成るドキュメントレベルの存在情報のグループから選択されるドキュメントレベルの存在情報をドキュメント参加者に提供することをさらに包含する、請求項１に記載の方法。
【請求項１６】
前記メッセージを（メタ情報とともに）格納する前に該メッセージに該メタ情報によってタグをつけることと、
該メタ情報に基づいてドキュメント参加者が遠隔に格納されたドキュメントを検索することを可能にすることと
をさらに包含する、請求項１に記載の方法。
【請求項１７】
現在オフラインである別のドキュメント参加者にメッセージを送信することと、特定の日付、時間、および／または地理的場所についてのメッセージの配信をスケジュールすることと、該別のドキュメント参加者がメッセージを検索するときにリアルタイム環境において該別のドキュメント参加者に接続することと、から成る機能のグループから選択される、プッシュトゥメッセージ機能を、ドキュメント参加者に提供することをさらに包含する、請求項１に記載の方法。
【請求項１８】
送信者と受信者との間でメディアをメッセージングするための方法であって、該方法は、
該受信者への通信のために意図されたメディアメッセージを受信することであって、該受信者のユーザ機器はモバイル装置であり、該メディアメッセージは非テキストメディアを包含する、ことと、
該メディアメッセージを該一つ以上の受信者に通信することであって、該非テキストメディアは一つ以上のインラインＡＳＣＩＩ符号化バイナリーアセットとして該受信者に通信される、ことと
を包含する、方法。
【請求項１９】
送信者と一つ以上の受信者との間のメディアのメッセージングを容易にするためのサーバであって、該サーバは、
該一つ以上の受信者への通信のために意図されたメディアメッセージを受信し、
該送信者および該一つ以上の受信者のユーザ機器から遠隔に該メディアメッセージをドキュメントとして格納し、
該メディアメッセージを該一つ以上の受信者に通信し、
該通信することの後に該遠隔格納において該ドキュメントを保持する
ように構成されている、サーバ。
【請求項２０】
ローカルメモリに常駐するクライアントアプリケーションを有するユーザ機器であって、該クライアントアプリケーションは、
一つ以上の受信者への通信のために意図されたメディアメッセージを生成する能力をユーザに提供し、
該メディアメッセージをサーバに送信する
ように構成され、該メディアメッセージが該一つ以上の受信者に通信された後で該メディアメッセージは該ユーザ機器および該一つ以上の受信者のユーザ機器から遠隔に格納され該遠隔格納において保持される、ユーザ機器。
【請求項２１】
コンピュータ実行可能なプログラムコードが記録されたコンピュータ読取り可能なメディアであって、該コンピュータ読取り可能なメディアは、
一つ以上の受信者への通信のために意図されたメディアメッセージを受信することと、
該メディアメッセージの送信者および該一つ以上の受信者から遠隔で該メディアメッセージをドキュメントとして格納することと、
該メディアメッセージを該一つ以上の受信者に通信することと、
該通信することの後に該ドキュメントを該遠隔格納内に保持することと
を包含する方法を実行する、コンピュータ読取り可能なメディア。
【図１】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公表番号】特表２００８−５１３８９７（Ｐ２００８−５１３８９７Ａ）
【公表日】平成２０年５月１日（２００８．５．１）
【国際特許分類】
【出願番号】特願２００７−５３２６６０（Ｐ２００７−５３２６６０）
【出願日】平成１７年９月２１日（２００５．９．２１）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０３３９３６
【国際公開番号】ＷＯ２００６／０３４３８４
【国際公開日】平成１８年３月３０日（２００６．３．３０）
【出願人】（５０３３３７７０４）ネトマット， インコーポレイテッド (2)
【Ｆターム（参考）】
【公表日】平成２０年５月１日（２００８．５．１）
【国際特許分類】
【出願日】平成１７年９月２１日（２００５．９．２１）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０３３９３６
【国際公開番号】ＷＯ２００６／０３４３８４
【国際公開日】平成１８年３月３０日（２００６．３．３０）
【出願人】（５０３３３７７０４）ネトマット， インコーポレイテッド (2)
【Ｆターム（参考）】
[ Back to top ]