JP2009515456A

JP2009515456A - リッチメディアアプリケーションにおけるリモート対話のためのフィードバック及びフォワード送信を与えるシステム及び方法

Info

Publication number: JP2009515456A
Application number: JP2008539524A
Authority: JP
Inventors: ダイディゾン; ヴィディアセトラー; ラマクリシュナヴェダンタム; ミスカハンヌクセラ; トルガキャピン
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2005-11-08
Filing date: 2006-11-08
Publication date: 2009-04-09
Also published as: KR20080074953A; WO2007054780A2; US20070174474A1; CN101346973A; WO2007054780A3; EP1946525A2; TW200728997A; KR100984694B1

Abstract

リッチメディアクライアントとリッチメディアサーバーとの間の双方向性をサポートするために、フィードバックフォーマット及びトランスポートプロトコル拡張を与えるシステム及び方法。本発明は、ＳＭＳ、ＭＭＳ、ＨＴＴＰ及びＲＴＳＰのようなプロトコルに対してフィードバックフォーマット及びプロトコル拡張を与える。これらのフィードバックフォーマット及びプロトコル拡張は、ダイナミックメニュー、リッチメディアプレーヤ、ユーザボーティング状態、ビデオ／オーディオ選択サービス、リモートユーザインターフェイス、及び他のアプリケーションに使用することができる。
【選択図】図１

Description

本発明は、一般に、スケーラブルビデオグラフィック（ＳＶＧ）のようなリッチメディアの使用に係る。より詳細には、本発明は、リッチメディア共有環境に携わるクライアントとサーバーとの間のリッチメディアに専用の双方向性をサポートするためのフィードバックメカニズムの使用に係る。

リッチメディアコンテンツは、グラフィック的にリッチなダイナミック双方向コンテンツと称される。リッチメディアコンテンツは、グラフィック、イメージ、タイムドテキスト、テキスト、ビデオ及びオーディオを含むコンパウンド又はマルチメディアを収容し、単一インターフェイスを経て配信される。スケーラブルビデオグラフィックは、リッチメディアプレゼンテーションのためのメインコンテナである。最近まで、移動装置のためのアプリケーションは、双方向性が限定されたテキストベースのものであった。しかしながら、より多くのワイヤレス装置に、カラーディスプレイや、より進歩したグラフィックレンダリングライブラリーが装備されるにつれて、消費者は、全てのワイヤレスアプリケーションから、よりリッチな経験を要求している。移動ターミナル、特に、移動ブロードキャスト／マルチキャストサービス、例えば、第３世代パートナーシッププロジェクト（３ＧＰＰ）マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）、３ＧＰＰ２ＢＣＭＣＳ、ＤＶＢ−ＨＩＰＤＣ、移動ストリーミングサービス、例えば、３ＧＰＰＰＳＳ、３ＧＰＰ２ＭＳＳ、等、並びにマルチメディア共有サービス、例えば、マルチメディアメッセージングシステム（ＭＭＳ）の分野では、リアルタイムのリッチメディアコンテンツストリーミングサービスが必須である。

ＳＶＧは、解像度独立の２Ｄベクトルグラフィックを記述するように設計されている。又、ＳＶＧは、ラスタグラフィック、オーディオ、ビデオのような他のメディアをしばしば埋め込む。ＳＶＧは、同期型マルチメディア統合ランゲッジ（ＳＭＩＬ）から借用した事象モデル及びアニメーションコンセプトを使用して双方向性を許す。更に、ＳＶＧは、無限のズーム性も許し、移動装置におけるユーザインターフェイスのパワーを向上させる。その結果、ＳＶＧは、重要性を得、特に、リッチメディアサービス、例えば、モバイルＴＶ、交通情報、天気、ニュース、等のライブ更新に対してマルチメディアプレゼンテーションのコア要素の１つになりつつある。ＳＶＧは、拡張可能なマークアップランゲッジ（ＸＭＬ）ベースのもので、他の既存のウェブ技術との透過的統合を従来のシステム以上に許す。

移動スケーラブルベクターグラフィック（移動ＳＶＧ）は、改良されたグラフィック及びイメージを移動装置へ搬送する際に中枢の役割を演じるために第３世代パートナーシッププロジェクト（３ＧＰＰ）により新規な像形成規格として採用された。最近、３ＧＰＰ及びオープンモバイルアリアンス（ＯＭＡ）は、リッチメディアベースの規格化活動の仕事を開始した。

現在、リッチメディア共有環境に携わっているクライアントとそれに対応するサーバーとの間のリッチメディアに専用の双方向性をサポートするためのフィードバックメカニズムは存在しない。オーディオ及びビデオのようなメディアフォーマットに専用のフィードバック及びフォワード送信のためのメカニズムは幾つかあるが、これらフォーマットは、主として、パケットロス、送信クオリティ及びメディア修理情報の報告に関するものである。

リッチメディアプレゼンテーション中に、ユーザは、しばしば、クライアントと対話して、より多くの情報を要求したり、コンテンツを更新したり、ある情報をサーバーへ返送したりすることができる。このような対話は、間欠的に行うこともできるし、或いはこのような対話は、例えば、データを収集するために後で使用してもよい。現在、オーディオ、ビデオメディアに関連したフィードバックメカニズムは、典型的に、パケットロス、クオリティ尺度、又は制御情報（例えば、再生、休止、記録、等）のレポートを含むことができる。しかしながら、現在、ＳＶＧコンテンツに生じる事象を実際のフィードバック要求及びフォワード送信へマップするための解決策は存在しない。更に、現在、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、等のアプリケーションレベルのプロトコルには、リッチメディアプレゼンテーション中にこのようなＳＶＧベースの情報を小さな遅延で送信するための機能は非常に僅かしか存在しない。

ＳＶＧのようなリッチメディアプレゼンテーションにおいて、ＨＴＴＰＧＥＴ／ＰＯＳＴのように、ローカル（クライアント側）双方向性及びリモート対話に関連した問題に対して多数の部分解決策が存在するが、その各々は、それ自身の欠点を有する。ＳＶＧＴ１．２は、www.w3.org/TR/DOM-Level-3-Events/に述べられたように、ＤＯＭ３事象カテゴリーにおける事象をサポートすると共に、“ConnectionData”、“preload”、“loadprogress”、“postload”のような多数のＳＶＧ特有の事象をサポートする。ＳＶＧコンテンツは、ＳＶＧランゲッジにおける異なる特徴を使用することによって双方向（即ち、ユーザ開始事象に応答する）とすることができる。例えば、キー押圧のようなユーザ開始アクションは、アニメーション及び／又はスクリプトを実行させるか、又はリスナーエレメントでハンドラーエレメントをトリガーさせることができる。ユーザは、特定のグラフィックエレメントをスタイラスでクリックするようなアクションを通じて新たなウェブページへのハイパーリンクを開始することができる。多くの場合に、“ｓｖｇ”エレメントの“ｚｏｏｍＡｎｄＰａｎ”属性の値、及びユーザエージェントの特性に基づいて、ユーザは、ＳＶＧコンテンツへズームし及びその周りをパンすることができる。

ＳＶＧの多数の異なる観点が事象によって影響される。例えば、ＳＶＧｕＤＯＭは、事象リスナーを登録するためのスクリプトをイネーブルし、所与の事象が発生したときにスクリプトを呼び出せるようにする。更に、「ハンドラー」エレメントの事象属性は、どの事象をハンドラーがトリガーすべきか指定する。更に、ＳＶＧのＳＭＩＬアニメーションエレメント及びメディアエレメントは、事象に基づいて開始又は終了するように定義することができる。

www.w3.org/TR/SVGMobile12/script.htmlにおいて詳細に論じられているＳＶＧ事象モデルは、www.w3.org/TR/xml-events/に述べられたＸＭＬ事象モデルをベースとする。ＳＶＧＴｉｎｙは、ＸＭＬ事象を使用して、カスタム事象を聴取する能力を与えると共に、グラフィックコンテンツから事象リスナーを別々に指定する。

宣言型アニメーションのＳＶＧ内蔵メカニズムを使用して、あるレベルの双方向性を与えることはできるが、スクリプトの使用は、例えば、双方向クロックのための現在システム時間を得るといった新たな形式の機能を追加することにより幾つかの効果を発揮し、そしてＳＶＧアニメーション機能を更に拡張することができる。ＳＶＧは、特定のスクリプトランゲッジのサポートを必要としないが、ＥＣＭＡＳｃｒｉｐｔ（www.w3.org/TR/SVGMobile12/script.htmlにおいて論じられている）は、スクリプトＳＶＧのために最も頻繁に使用される。又、ＥＣＭＡＳｃｒｉｐｔは、ＮｅｔｓｃａｐｅのＪａｖａ（登録商標）Ｓｃｒｉｐｔから開発された標準化ランゲッジである。しかしながら、ＳＶＧにより与えられる現在の機能は、主として、宣言的アニメーション及びスクリプトを経てクライアント側のローカル双方向性に関連している。リモート対話のための機能は、ＨＴＴＰＧＥＴ／ＰＯＳＴコマンドを呼び出すためのハイパーリンクの使用で著しく制限される。

www.mpeg-laser.org/documents/LASeRStudyOfFCDBusan.pdfにおいて論じられているライトウェイトアプリケーションズシーンレプレゼンテーション（ＬＡＳｅＲ）システムは、ＨＴＴＰＧＥＴ要求及びハイパーリンクによりフィードバックデータを送信するためのメカニズムを定義している。例えば、オリジナルコンテンツ（サーブレットによりサービスされる）のＵＲＬがwww.example.org/serviceである場合には、ＨＴＴＰＧＥＴ／ＰＯＳＴを送信する方法が多数ある。１つの方法は、回答を伴わずに簡単な情報を送信することを含む（例えば、www.example.org/service?answer1=yes）。別の方法は、回答と共に簡単な情報を送信することを含む。この場合、サーブレットは、新たなシーン又は更新を送信する（例えば、アペンディックスにパッケージされて）ことにより回答する。第３の方法は、既存のｕｒｌにシーン情報を追加する追加コマンドを伴うスクリプトを使用して複雑な情報を送信することを含む。例えば、地下鉄の駅が選択され、駅の名前が次のように存在する。

不都合なことに、この解決策は、ストリーミングアプリケーションではなく、実際にはＰｔＰアプリケーションに専用であるＨＴＴＰベースの接続に制限される。それ故、このようなフィードバックの範囲及び多様性は、非常に限定される。

ハイパーテキスト転送プロトコル（ＨＴＴＰ）は、分散協力型ハイパーメディア情報システムのためのアプリケーションレベルプロトコルである。ＨＴＴＰは、ネームサーバー及び分散型オブジェクトマネージメントシステムのように、ハイパーテキストに対する使用を越えた多数のタスクに使用できる一般的で且つステートレスなプロトコルである。これらのタスクは、その要求方法、エラーコード及びヘッダの拡張を通して実施することができる。ＨＴＴＰの特徴は、データ表現の形式及びネゴシエーションであり、転送されるデータとは独立してシステムを構築できることである。ＨＴＴＰは、１９９０年以来、ワールドワイドウェブグローバル情報構想により使用されている。

リアルタイムストリーミングプロトコル（ＲＴＳＰ）は、リアルタイム特性をもつデータの配信を制御するためのアプリケーションレベルのプロトコルである。ＲＴＳＰは、オーディオ及びビデオのようなリアルタイムデータの制御されたオンデマンド配信を可能にするための拡張性フレームワークを与える。データのソースは、ライブデータフィード及び記憶されたクリップの両方を含むことができる。このプロトコルは、多数のデータ配信セッションを制御し、ユーザデータプロトコル（ＵＤＰ）、マルチキャストＵＤＰ及び送信制御プロトコル（ＴＣＰ）のような配信チャンネルを選択するメカニズムを与え、そしてリアルタイムトランスポートプロトコル（ＲＴＰ）に基づいて配信メカニズムを選択するシステムを与えるように意図されている。ＲＴＳＰは、ＨＴＴＰと機能的に若干オーバーラップする。しかしながら、ＲＴＳＰは、データ配信が異なるプロトコルでは帯域ずれして行われるという点で、ＨＴＴＰとは機能的に相違する。ＨＴＴＰは、クライアントが要求を発し、サーバーが応答するという非対称的プロトコルである。ＲＴＳＰでは、メディアクライアント及びメディアサーバーの両方が要求を発することができる。又、ＲＴＳＰの要求は、ステートレスでない。ＲＴＳＰは、シンタックス及びオペレーションがＨＴＴＰ／１．１と同様であり、従って、ＨＴＴＰに対する拡張メカニズムをほとんどの場合にＲＴＳＰに追加することができる。

米国特許出願公告第２００５／０２０４２９６号には、ブラウザコンテクストにおけるハイパーメディアドキュメントプレゼンテーションを少なくとも２人のクライアント間で共有する方法が開示されている。この方法は、連続的な対話事象をクライアント間で交換し、事象を整合し、そして整合された対話事象を共有プレゼンテーションのレプリカにおいてエミュレーションするためのメカニズムを含む。しかしながら、この方法は、非リアルタイム及びリアルタイムフィードバックシナリオ並びにフォワード送信において埋設メディアを伴うＳＶＧコンテナフォーマットに適用することができない。更に、このシステムは、ＳＶＧ側の事象スクリプトをフィードバック要求へとマップするための解決策も、ＳＶＧコンテンツのダイナミックな更新も与えるものではない。

本発明は、リッチメディアクライアントとサーバーとの間のリッチメディアに専用のリモート双方向性をサポートするために、ＳＭＳ、ＭＭＳ、ＨＴＴＰ及びＲＴＳＰに対するフィードバックフォーマット及びトランスポートプロトコル拡張を与えるシステム及び方法を提供する。本発明は、リッチメディアベースのＳＶＧプレゼンテーションにおいてサーバーからクライアントへのフォワード送信及びクライアントからサーバーへのフィードバックに対する技術的解決策を提供する。本発明は、ＳＶＧとのクライアント側スクリプト対話をフィードバック及び要求へとマッピングし、このようなフィードバックメカニズムを分類し、そして追加される機能に対する新たなシンタックスを定義するための適当な方法を規定する。アプリケーション及びＵＥ能力の要件に基づいて、フィードバックに対して異なるトランスポートメカニズムを使用することができる。これらのメカニズムは、ＳＭＳ／ＭＭＳ（限定されたテキスト長さでテキストを送信するための）、ＨＴＴＰ、ＲＴＳＰ、ＲＴＰ制御プロトコル（ＲＴＣＰ）（ＲＴＰ／ＡＶＰＦ）、一方向性トランスポート（ＦＬＵＴＥ）を経てのファイル配信、及び他のトランスポートメカニズムを含んでもよい。又、ＭＭＳは、連続メディア（例えば、ビデオ、オーディオ）及び個別メディア（例えば、イメージ）を搬送することができるが、このようなメディアを合体するための判断は、アプリケーション特有である。更に、このようなメディアのサイズ及び時間的特性が、ＭＭＳを経てフィードバックメッセージを搬送するのに適当でないことがある。しかしながら、アプリケーションにより、メディアをＭＭＳフィードバックデータに合体するように選択してもよい。又、本発明は、パケット交換ストリーミングサービス（ＰＳＳ）及びＭＢＭＳのようなサービスに使用することもできる。

本発明のこれら及び他の効果並びに特徴は、その構成及び動作の仕方と共に、多数の図面にわたり同じ要素が同じ番号で示された添付図面を参照した以下の詳細な説明から明らかとなろう。

図１は、本発明によるリッチメディア共有環境に存在し又は存在し得る装置の簡単な図である。本発明によれば、リッチメディアクライアント１００は、リッチメディアサーバーと通信する。リッチメディアクライアント及びリッチメディアサーバーは、本発明によれば、ＳＭＳ／ＭＭＳ、ＨＴＴＰ／ＲＴＰ（ＲＴＣＰ）のようなシステムを使用し、及び他の通信方法を介して、情報を通信することができる。リッチメディアサーバー１１０は、データベース１２０、ＨＴＴＰ、ＦＴＰ及び／又はＲＴＰサービス１３０、又は他のサービス１４０のような装置からリッチメディアクライアント１００へ送信するためのリッチメディアコンテンツを得ることができる。

本発明は、リッチメディアクライアントとサーバーとの間のリッチメディアに専用のリモート双方向性をサポートするために、ＳＭＳ、ＭＭＳ、ＨＴＴＰ及びＲＴＳＰに対するフィードバックフォーマット及びトランスポートプロトコル拡張を与えるシステム及び方法を提供する。双方向リッチメディアサービスを利用するケースは多数ある。幾つかの例を以下に示す。

ダイナミックメニュー：ダイナミックドロップダウンメニューとしても知られているダイナミックメニューは、サーバーからクライアントへ送信された情報に基づいてオンザフライでダイナミックに生成することができる。又、このようなメニューは、サーバーからの付加的な情報の要求を導くことのできるメニューのアイテムをクリックすることにより生成されてもよい。又、これらの方法の組み合せも可能である。

ＤＶＤ状の機能を伴うリッチメディアプレーヤ：本発明は、ＤＶＤ状チャプター機能を移動装置のリッチメディアプレーヤへ拡張するのに使用できる。ＤＶＤにおけるＶＯＢチャプターファイルと同様に、多数のメディアストリーム（ビデオ、オーディオ、ＳＶＧベースのサブタイトル、等）を一緒にマルチプレクスして、リッチメディアシーン又はシーン更新を形成することができる。ユーザが特定のチャプターをフィードバックとして要求するときには、それに対応するシーン又はシーン更新をプレーヤにストリーミングすることができる。

ユーザボーティング(voting)：ユーザは、非リアルタイムフィードバックをサーバーに返送することができ、これは、統計学的情報を収集するために後で使用することができる。例えば、ユーザは、調査を実行して、データを、後で使用すべくサーバーへ送信することができる。

ビデオ／歌の選択サービス：本発明は、ユーザが選択した歌や映画をユーザがサーバーからリアルタイムで選択／要求するのを許すように使用でき、コンテンツの更新は、どちらのクライアントが早く要求を出したかに依存し、又は各クライアントに指定されたプライオリティに基づく。

リモートユーザインターフェイス（ＲＵＩ）：リモートＵＩは、ユーザインターフェイスを、アプリケーションロジックを実行しているものではない装置においてレンダリングできるようにするメカニズムである。製造者は、ある環境に著しく適した装置を現在生成している。装置は、多様な範囲の目的に意図されているので、それらのＵＩ能力は、著しく変化し、スクリーンサイズ及び比、カラー深度、種々の部品セットを伴うウインドウシステム、入力方法、等は、環境を著しく異なるものにする。同時に、アプリケーション開発者及びＵＩ設計者は、各々のアプリケーションの学習及び使用を容易にすることによりユーザ経験が改善されるように、レンダリングプラットホームに著しく適したユーザインターフェイスの生成を試みている。このようなリモートＵＩが、アプリケーションロジックを実行しているものではない別の装置においてレンダリングされるときには、ユーザがＵＩをローカルアプリケーションとして認知でき、それを直感的に使用できるように、プロビジョニングする必要がある。

前記ケースでは、アプリケーションは、ブロードキャスト／マルチキャスト指向でもよいし、ＰｔＰ指向でもよい。対応的に、ＳＭＳ、ＭＭＳ、ＴＣＰ／ＩＰ及びＵＤＰ／ＩＰを順方向及び逆方向送信の両方に使用できる。ここでは、フィードバックデータを与える方法しか説明しない。又、サーバーへフィードバックを与えることができるように、ＳＭＳ、ＭＭＳ、ＨＴＴＰ及びＲＴＳＰを拡張するための技術及びシンタックスを説明する。次いで、各メカニズムの能力をリストし、種々の使用ケースへとマッピングする。

ユーザ事象を処理するのに使用されるアプリケーションスクリプトは、ＵＥ側又はサーバー側のいずれかにセーブすることができる。対応的に、ユーザエージェントは、異なる対話モードを使用してフィードバックデータを与えることができる。ここに述べる対話は、２つのモード、即ちローカル処理モード及びリモート処理モードに分類される。ＸＭＬをベースとするローカル処理モード及びリモート処理モードのシンタックスがここに説明され、前記トランスポートメカニズムへとマップされる。

ＳＭＳ、ＭＭＳ、ＨＴＴＰ、及びＲＴＳＰは、フィードバックデータを送信するための４つの考えられる方法である。しかしながら、他のトランスポートメカニズムも使用できることを理解されたい。これらシステムの各々において、リッチメディア対話の効率的な能力を与えるために、種々の関連プロトコルに基づいて、新たな拡張及びシンタックスを定義することができる。

ローカル及びリモート処理事象：対話中に、ユーザ対話を処理するのに使用されるアプリケーションスクリプトは、クライアント／ＵＥ側、又はサーバー側のいずれかにセーブすることができ、選択は、アプリケーション特有である。しかしながら、構成の性質に基づき、フィードバックデータを与えるための適切なトランスポートメカニズムを選択することもできる。

ローカル処理事象は、クライアント側で最初に処理されて、必要に応じて、ＵＥからサーバーへ送信されるアプリケーションスクリプトである。あるアプリケーションについては、スクリプトは、ＵＥ側にセーブされてもよい。これは、サーバーの負担を著しく減少し、ローカル対話を容易にすることができる。例えば、ｉＴＶ対話では、ユーザインターフェイスへの操作をＵＥ側で直ちに実現することができ、そしてある形式のデータをサーバーへ送信することができる。このシナリオでは、ユーザは、チャンネルを選択することができ、スクリプトは、この事象を処理して、ＰＬＡＹ要求をサーバーへ送信する。この要求は、選択されたチャンネルに関する情報を含む。このような情報に基づき、サーバーは、要求されたメディアデータを送信するための新たなブロードキャスティング又はダウンロードセッションをスタートすることができる。

リモート処理事象は、サーバー側で直接処理されるアプリケーションスクリプトである。このようなケースでは、ユーザ事象は、初期処理を行わずにＵＥからサーバーへ直接送信される。ユーザ事象をサーバー側にセーブする１つの考えられる理由は、セキュリティを伴うことである。サーバーは、エンドユーザから各々の詳細を隠し、従って、クライアントは、ユーザがどのボタンキーをクリックしたか、ユーザがどのテキストを入力したか、等の情報をレポートするだけでよい。

一般的フィードバックペイロードフォーマット：ＳＶＧコンテンツに専用のフィードバック情報は、テキスト＋オクテットペイロードの形態で表わすことができる。このペイロードは、２つの部分を有する。第１部分は、ＥＶＥＮＴ＿ＩＤ、ＥＬＥＭＥＮＴ＿ＩＤ、及びＥＶＥＮＴを含む。ＥＶＥＮＴ＿ＩＤは、クライアントからフィードバックメッセージを識別する独特の識別子である。ＥＬＥＭＥＮＴ＿ＩＤは、事象をトリガーするＳＶＧＤＯＭにおけるソースエレメントのＩＤである。ＥＶＥＮＴは、ＳＶＧ事象、又はユーザ定義事象である。全フォーマットは、次のように表わすことができる。

実際のフィードバックデータは、第１部分の後に一連のオクテットとして記憶される。このデータは、www.w3.org/TR/2004/WD-SVG12-20041027/eventlist.htmlを参照したＳＶＧ事象自身の属性を含むことができる。例えば、ボタンがクリックされたＸ及びＹ位置は、サーバーへ直接送信することができ、そしてサーバーは、フィードバックをリモート処理することができる。Ｘ及びＹの値の各々が、２つのオクテットを伴うバイナリーフォーマットで表現されると仮定すれば、オクテットシリーズの合計長さは、２＋２＝４オクテットとなる。Ｙ値は、Ｘ値の直後に記憶される。

前記例は、ＳＶＧシーンを、映画を選択するためのボタンのセットと共に含む。ボタンの１つをクリックすると、クライアントは、ボタンがクリックされたＸ及びＹ位置を記憶する。この情報は、サーバーへのリモート処理フィードバックメッセージへと公式化される。この例では、４つのオクテットを使用してこの情報を記憶する。

又、実際のフィードバックデータは、ユーザがどの映画を選択したか、等の処理情報を含むこともできる。このケースでは、オクテットは、“movieSelected= Lord of the Rings”のような情報を含んでもよい。これは、ローカル処理事象の例である。それ故、シーンにおいてボタンの１つをクリックすると、スクリプトが、movieSelectedと称されるフィールドにこの値を記憶する。この情報は、サーバーへのローカル処理フィードバックメッセージへと公式化される。

ＳＭＳ又はＭＭＳのようなプロトコルの場合、ペイロードの最初の３つのアイテムは、テキストベースのフォーマットで明確に指定され、そして第４フィールドは、一般的に、一連のオクテットとみなされる。ＨＴＴＰＰＯＳＴ／ＰＵＴの場合、メタ情報は、エンティティヘッダに記憶され、一方、それに続く４つのテキストベースのフィールドと、実際のフィードバック情報を記憶する一連のオクテットとは、一緒に、エンティティ本体に順次に記憶される。

フィードバックのためのトランスポートシステム：異なるトランスポートシステムは、異なる能力を有し、そしてそれらの使い方は、リッチメディアアプリケーションの性質に依存する。ＭＭＳ、ＴＣＰ及びＵＤＰのような多数の方法を使用して、リッチメディアデータを配信することができる。特定アプリケーションの需要に基づいて、フォワード送信及びフィードバック送信の両方に異なる方法を使用することができる。フィードバックチャンネルに使用される方法は、フォワードチャンネルに使用される方法と必ずしも同じでないことに注意されたい。それ故、フィードバックデータを与える方法のみをここで説明する。リッチメディアベースのフィードバックを容易にするために、通常使用される標準的なプロトコル、例えば、ＳＭＳ、ＨＴＴＰ、ＭＭＳ及びＲＴＳＰに対して幾つかの拡張を以下にテーブル１に示す。

テーブル１

ＳＭＳ及び／又はＭＭＳによるフィードバック：ＳＭＳ及びＭＭＳは、両方とも、テキストベースのフィードバック情報を搬送できるが、ＳＭＳは、１４０オクテットの限定長さのテキストしか搬送できない。ＳＭＳの場合、フィードバックメッセージの長さ制限が与えられると、テキストベースのデータは、送信中に小さなチャンクへとセグメント化する必要がある。パケットを識別するために、次の形態で各パケットのヘッドにメタデータを使用してもよい。
現在セグメントのＩＤ／合計セグメント数／データフォーマット／ペイロードの長さ／キャラクタセット

第３フィールドは、データフォーマット、即ちデータがテキストであるか、バイナリーであるか又はユニコードであるか（テキスト−１、バイナリー−２、ユニコード−３）を表わす。第４フィールドは、オクテットでカウントされたペイロードデータの長さである。オプションの第５フィールドは、ユニコードが使用されたときのキャラクタセットの名前である。第５フィールドは、第３フィールドの値が３であるときだけ存在する。例えば、１／３／３／１００／ＩＳＯ−８８５９−７では、ユーザフィードバックが３つのセグメントに分割される。現在ＳＭＳメッセージは、第１セグメントを搬送する。このセグメントは、長さが１００オクテットである。ユニコードは、それをエンコードし、キャラクタセットは、ＩＳＯ−８８５９−７である。より正式には、このメタデータは、次のように表わすことができる。

この形態において、１＊ＤＩＧＩＴは、１つのデジットが存在することを示し、“／”は、キャラクタ“／”であり、ｎ＊ＤＩＧＩＴは、１つ以上のデジットが存在し得ることを示し、ｎ＊ＣＨＡＲは、１つ以上のキャラクタが存在し得ることを示し、そしてＳＰは、ホワイトスペースを示す。フィードバックのＳＭＳモードは、高い遅延を伴うフィードバックに対して理想的である。というのは、ＳＭＳの待ち時間が、ＨＴＴＰ及びＲＴＳＰ要求より比較的大きいからである。

ＭＭＳの場合、メタデータは、次のフォーマットである。即ち、データフォーマット／ペイロードの長さ／キャラクタセット。このフォーマットにおいて、第１フィールドは、データのフォーマット、即ちデータがテキストであるか、バイナリーであるか又はユニコードであるか（テキスト−１、バイナリー−２、ユニコード−３）を表わす。第２フィールドは、オクテットでカウントされたペイロードデータの長さである。オプションの第３フィールドは、ユニコードが使用されたときのキャラクタセットの名前である。第３フィールドは、第１フィールドの値が３であるときだけ存在する。フォーマットは、例えば、３／１００／ＩＳＯ−８８５９−７として実施される。より正式には、このメタデータは、次のように表わすことができる。

この例では、１＊ＤＩＧＩＴは、１つのデジットが存在することを示し、“／”は、キャラクタ“／”であり、ｎ＊ＤＩＧＩＴは、１つ以上のデジットが存在し得ることを示し、ｎ＊ＣＨＡＲは、１つ以上のキャラクタが存在し得ることを示し、そしてＳＰは、ホワイトスペースを示す。

ＨＴＴＰによるフィードバック：ＨＴＴＰは、アプリケーションレイヤプロトコルである。ＨＴＴＰは、通常、ＴＣＰ接続にわたって実行されるが、ＵＤＰのような他のトランスポートプロトコルにも適用できる。ＨＴＴＰは、ＰｔＰ接続をベースとする対話に適している。ＴＣＰは、データパケットの配信を固有に保証する。しかしながら、ＴＣＰは、付加的な遅延も導入する。それ故、このようなシステムは、フィードバックデータに対して強力な保証を必要とするチャンネル選択やＳＶＧベースのゲームのような低遅延のフィードバックにより適している。更に、ＨＴＴＰは、セッションを確立するのに１つ以上のＨＴＴＰＧＥＴ要求が使用される進行性ダウンロードシナリオに適したものである。

次の部分では、フィードバックデータを搬送するために、ＧＥＴ、ＰＯＳＴ及びＰＵＴ方法が拡張される。

ＧＥＴ方法メカニズムは、どんな情報が要求−ＵＲＩにより識別されたかを検索する。レンジ及びコンテンツレンジは、データの範囲を指し、レンジは、クライアントからサーバーへのデータ（フィードバック）を指し、そしてコンテンツレンジは、サーバーからクライアントへのデータ（例えば、フォワード送信）を指す。ＧＥＴ方法のセマンティックは、要求メッセージがレンジヘッダフィールドを含む場合に「部分ＧＥＴ」へ変化する。このような種類の要求を受け取った後に、サーバーは、「コンテンツレンジ」と称されるフィールドを含む２０６又は４１６メッセージを使用して、ＧＥＴ要求に応答する。

現在のＨＴＴＰ仕様では、レンジ及びコンテンツレンジは、バイトに基づいて指定されるだけである。しかしながら、ＳＶＧコンテンツは、オーディオ及びビデオのようにバイトに基づくものではなく、ＨＴＴＰは、典型的に、全てのデータを簡単なバイナリーフォーマットとして処理する。ＳＶＧは、潜在的に、バイナリーフォーマット、例えば、バイナリーＸＭＬへ圧縮することができるが、全てのＳＶＧシーン及びシーン更新コンテンツは、必ずしもバイナリーフォーマットへ圧縮されなくてよい。更に、ＩＳＯベースメディアファイルフォーマットでは、ＳＶＧシーン及びシーン更新は、同期サンプル(syncsample)により編成され参照される。ＳＶＧにおける全ての同期サンプルは、ＳＶＧシーンであるが、全てのＳＶＧシーンは、必ずしも同期サンプルでなくてもよい。バイトに基づくものでもフレームに基づくものでもない非圧縮ＳＶＧのプレゼンテーションを容易にするために、ＨＴＴＰＧＥＴ方法は、フィードバックの精度を高めるべく、ミリ秒（ミリセコンド）又は同期サンプルに基づくように拡張される。

レンジに対してミリ秒を使用するためのシンタックス及び例の両方を以下に示す。
シンタックス：

レンジに対し同期サンプルを使用するためのシンタックス及び例の両方を以下に示す。
シンタックス：

コンテンツレンジに対してミリ秒を使用するためのシンタックス及び例の両方を以下に示す。
シンタックス：

コンテンツレンジに対し同期サンプル使用するためのシンタックス及び例の両方を以下に示す。
シンタックス：

ＰＯＳＴ方法は、要求に含まれたエンティティを、要求−ラインにおいて要求−ＵＲＩにより識別されたリソースの新たな従属物として受け容れるようにサーバーに要求するのに使用される。ＰＯＳＴは、均一の方法が既存のリソースのアノテーションをカバーするのを許すように設計され、即ちブルテンボード、ニュースグループ、メールリスト、又は同様の記事グループへのメッセージのポスティング；フォームを提示した結果のようなデータのブロックをデータハンドリングプロセスに供すること；及び付随オペレーションによるデータベースの拡張、をカバーするのを許すように設計される。ＰＯＳＴ方法により実行される実際の機能は、サーバーにより決定され、通常は、要求−ＵＲＩに依存する。

ＰＵＴ方法は、含まれたエンティティが、供給された要求−ＵＲＩのもとで記憶されることを要求する。要求−ＵＲＩが既存のリソースを指す場合には、含まれたエンティティは、原点サーバーに存在するリソースの変更バージョンとみなされねばならない。要求−ＵＲＩが既存のリソースを指さず、そしてＵＲＩが要求側ユーザエージェントにより新たなリソースとして定義され得る場合には、原点サーバーは、そのＵＲＩとのリソースを生成することができる。

ＰＯＳＴ及びＰＵＴの両要求は、要求方法又は応答状態コードによって何ら制限されない場合には、エンティティを転送することができる。エンティティは、エンティティ−ヘッダフィールド及びエンティティ−本体を含む。エンティティ−ヘッダフィールドは、エンティティ−本体に記憶されたフィードバックに関するメタ情報を定義し、或いは本体が存在しない場合には、要求により識別されるリソースに関するメタ情報を定義する。ＨＴＴＰ要求又は応答と共に送信されるエンティティ−本体がもしあれば、それは、実際のフィードバックデータを含むエンティティ−ヘッダフィールドにより定義されたフォーマットにあり、エンコーディングされる。定義されたＳＶＧフィードバックデータは、実際には、エンティティ−本体に記憶されて送信される。エンティティ−本体については、長さ制限がない。大きなフィードバックデータのセグメント化又は断片化を取り扱うのは、下位レイヤ（例えば、ＴＣＰ）の役割である。エンティティ−ヘッダフィールド及びエンティティ−本体の一例は、次の通りである。

ＰＯＳＴ要求とＰＵＴ要求との間の基本的な相違は、要求−ＵＲＩの異なる意味において反映される。ＰＯＳＴ要求のＵＲＩは、含まれたエンティティを取り扱うリソースを識別する。このリソースは、データ受け容れプロセス、他の何らかのプロセスへのゲートウェイ、又はアノテーションを受け容れる個別のエンティティを備えてもよい。対照的に、ＰＵＴ要求のＵＲＩは、要求と共に含まれたエンティティを識別し、ユーザエージェントは、どんなＵＲＩが意図されたかを知り、そしてサーバーは、要求を他のリソースへ適用するよう試みてはならない。それ故、アプリケーションの需要に基づいて、ＳＶＧフィードバックは、ＰＵＴ又はＰＯＳＴを各々経て送信することができる。例えば、フィードバックデータがボーティングアプリケーションに対するユーザ結果である場合には、ユーザエージェントは、サーバーがそれをどこにセーブし処理したかについて関心を持たない。このようなケースでは、このフィードバックデータは、ＰＯＳＴを経て送信される。別の例として、ユーザエージェントがサーバーにおけるユーザ情報のアップグレードを試み、そしてスクリプトが、新たなデータをどこに記憶すべきか知っている場合は、ＰＵＴ要求を使用して、フィードバックデータが送信される。

ＲＴＳＰによるフィードバック：ＲＴＳＰは、リアルタイム特性をもつデータの配信を制御するためのアプリケーションレベルプロトコルである。このプロトコルは、多数のデータ配信セッションを制御し、ＵＤＰ、マルチキャストＵＤＰ及びＴＣＰのような配信チャンネルを選択するメカニズムを与え、そしてＲＴＰに基づいて配信メカニズムを選択する方法を与えるように意図される。それ故、ＲＴＳＰは、アプリケーションをブロードキャスティングするために低遅延でフィードバックを与えるのに適している。

ＲＴＳＰは、ＨＴＴＰに本来適合する。それ故、フィードバックデータを与えるために、ＰＯＳＴ／ＰＵＴにおいて拡張されたものをＲＴＳＰに適用することができる。更に、ＰＬＡＹ方法は、レンジを同期サンプルによって指定できるように拡張される。ＰＬＡＹ方法は、データ送信をスタートするようにサーバーに知らせる。ＰＬＡＹ方法は、通常のプレイ時間を、指定されたレンジの始めに位置させ、そしてレンジの終りに到達するまでストリームデータを配信する。このようなインストラクションの一例を以下に示す。
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 835
セッション: 12345678
レンジ: npt=10-15

レンジヘッダは、時間パラメータを含んでもよい。このパラメータは、再生をスタートしなければならないＵＴＣの時間を指定する。オンデマンドストリームの場合、サーバーは、再生される実際のレンジで応答する。これは、要求されたレンジと有効フレーム境界との整列がメディアソースに対して必要とされる場合には、その要求されたレンジと相違してもよい。リッチメディアアプリケーションを容易にするために、上述したようにＨＴＴＰにおいてなされた拡張と同様に、同期サンプル及びミリ秒でレンジを指定するのを許すように、ＰＬＡＹコマンドを拡張することができる。次の例は、第２０番目の同期サンプルからスタートして終了に至るまでの全表現を再生する。
C->S: PLAY rtsp://svg.example.com/presentation.svg RTSP/1.0
CSeq: 833
セッション: 12345678
レンジ: syncsample=20-

S->C: RTSP/1.0 200 OK
CSeq: 833
日付: 23 Jan 2005 15:35:06 GMT
レンジ: syncsample=20-

次の例は、第２０番目の同期サンプルからスタートして第４０番目の同期サンプルで終了する表現を示す。
C->S: PLAY rtsp://svg.example.com/presentation.svg RTSP/1.0
CSeq: 834
セッション: 12345679
レンジ: syncsample=20-40

S->C: RTSP/1.0 200 OK
CSeq: 834
日付: 23 Jan 2005 15:37:06 GMT
レンジ: syncsample=20-40

レンジをミリ秒で指定するために、シンタックスは、次のようにすることができる。
C->S: PLAY rtsp://svg.example.com/presentation.svg RTSP/1.0
CSeq: 834
セッション: 12345679
レンジ: millisecond=3000-20000

S->C: RTSP/1.0 200 OK
CSeq: 834
日付: 23 Jan 2005 15:37:06 GMT
レンジ: millisecond=3000-20000

本発明の幾つかの別の実施形態を以下に説明する。しかしながら、種々様々な他の実施も考えられることを理解されたい。このような１つの実施形態において、一般的なフィードバックペイロードフォーマットの場合に、フィードバックペイロードフォーマットのフィールドは、オプションであってもよいし、又はアプリケーション及び／又はクライアントの能力、サーバー及びネットワーク条件に基づいて無視することもできる。別の実施形態において、これも、一般的なフィードバックペイロードフォーマットの場合に、フィードバックペイロードフォーマットにおけるフィールドの連続順序及び名前を変更してもよい。更に、ＳＭＳ及びＭＭＳのフィードバックフォーマットにおけるフィールドの連続順序及び名前を変更しながら、同じ機能を遂行することもできる。

ＨＴＴＰによりフィードバックするためのＰＯＳＴ／ＰＵＳＨ方法への拡張に対して、ＰＯＳＴ又はＰＵＴメッセージに含まれたレンジ又はコンテンツレンジにおけるフィールドの連続順序及び名前を変更しながら、同じ機能を遂行することもできる。更に、ＰＯＳＴ及びＰＵＴは、異なる目的のためのデータを含むが、ＰＯＳＴ要求に含まれたデータをＰＵＴ要求によって送信することもでき、或いはその逆もできることに注意されたい。

ＲＴＳＰによるフィードバックの場合に、ＰＬＡＹメッセージに含まれるレンジにおけるフィールドの連続順序及び名前を変更しながら、同じ機能を遂行することもできる。更に、サーバーからクライアントへの応答メッセージは、対応するＰＬＡＹ要求により要求されたレンジと同じレンジを必ずしも含まない。

最後に、レンジが利用可能なサンプルの合計数を含むようなシンタックスのオプションも存在し得ることに注意されたい。例えば、シンタックスは、全部で６０個のサンプルがあると仮定すれば、“Range: syncsample=20-40/60”を指示することができる。

図２は、ネットワークを通して通信できる多数の通信装置を備えた、本発明を利用できるシステム１０を示す。このシステム１０は、移動電話ネットワーク、ワイヤレスローカルエリアネットワーク（ＬＡＮ）、ブルーツースパーソナルエリアネットワーク、イーサネット（登録商標）ＬＡＮ、トークンリングＬＡＮ、ワイドエリアネットワーク、インターネット、等を含む（これらに限定されないが）ワイヤード又はワイヤレスネットワークの組み合せで構成することができる。システム１０は、ワイヤード及びワイヤレスの両通信装置を含んでもよい。

例示のために、図２に示されたシステム１０は、移動電話ネットワーク１１及びインターネット２８を備えている。インターネット２８への接続は、長距離ワイヤレス接続、短距離ワイヤレス接続、及び種々のワイヤード接続を含み（これらに限定されないが）、このワイヤード接続は、電話線、ケーブルライン、電力ライン、等を含む（これらに限定されないが）。

システム１０の例示的通信装置は、移動電話１２、ＰＤＡ及び移動電話の組合せ１４、ＰＤＡ１６、一体化メッセージング装置（ＩＭＤ）１８、デスクトップコンピュータ２０、及びノートブックコンピュータ２２を含む（これらに限定されないが）。通信装置は、固定でもよいし、又は移動中の個人により携帯されるときには移動でもよい。又、通信装置は、自動車、トラック、タクシー、バス、ボート、航空機、自転車、オートバイ、等を含む（これらに限定されないが）輸送のモードに配置されてもよい。通信装置の幾つか又は全部がコール及びメッセージを送受信でき、そしてベースステーション２４へのワイヤレス接続２５を経てサービスプロバイダーと通信してもよい。ベースステーション２４は、移動電話ネットワーク１１とインターネット２８との間の通信を許すネットワークサーバー２６に接続することができる。システム１０は、付加的な通信装置、及び異なる形式の通信装置を含んでもよい。

通信装置は、コード分割多重アクセス（ＣＤＭＡ）、移動通信用のグローバルシステム（ＧＳＭ）、ユニバーサル移動テレコミュニケーションシステム（ＵＭＴＳ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、送信制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、ショートメッセージサービス（ＳＭＳ）、マルチメディアメッセージングサービス（ＭＭＳ）、ｅメール、インスタントメッセージングサービス（ＩＭＳ）、ブルーツース、ＩＥＥＥ８０２．１１、等を含む（これらに限定されないが）種々の送信技術を使用して通信することができる。又、通信装置は、無線、赤外線、レーザー、ケーブル接続、等を含む（これらに限定されないが）種々のメディアを使用して通信することができる。

図３及び４は、本発明を実施できる１つの代表的な移動電話１２を示す。しかしながら、本発明は、１つの特定形式の移動電話１２又は他の電子装置に限定されないことを理解されたい。図３及び４の移動電話１２は、ハウジング３０、液晶ディスプレイの形態のディスプレイ３２、キーパッド３４、マイクロホン３６、イヤホン３８、バッテリ４０、赤外線ポート４２、アンテナ４４、本発明の一実施形態によるＵＩＣＣの形態のスマートカード４６、カードリーダー４８、無線インターフェイス回路５２、コーデック回路５４、コントローラ５６、及びメモリ５８を含む。個々の回路及びエレメントは、全て、例えば、ノキアの範囲の移動電話においてこの技術で良く知られた形式のものである。

本発明は、ネットワーク環境内でコンピュータにより実行されるプログラムコードのようなコンピュータ実行可能なインストラクションを含むプログラム製品により一実施形態で具現化される方法ステップの一般的状況において説明された。

一般に、プログラムモジュールは、特定のタスクを実行するか又は特定のアブストラクトデータ形式を具現化するルーチン、プログラム、オブジェクト、コンポーネント、データ構造、等を含む。コンピュータ実行可能なインストラクション、関連データ構造、及びプログラムモジュールは、ここに開示する方法のステップを実行するためのプログラムコードの例を表わす。このような実行可能なインストラクション又は関連データ構造の特定シーケンスは、このようなステップにおいて説明されるファンクションを具現化するための対応するアクションの例を示す。

本発明のソフトウェア及びウェブの具現化は、種々のデータベースサーチステップ、相関ステップ、比較ステップ、及び判断ステップを実行するためのルールベースのロジック及び他のロジックを伴う標準的なプログラミング技術で達成することができる。又、この説明及び特許請求の範囲で使用する「コンポーネント」及び「モジュール」という語は、１行以上のソフトウェアコードを使用する具現化、及び／又はハードウェア具現化、及び／又は手動入力を受け取るための装置を包含することに注意されたい。

本発明の実施形態の以上の説明は、例示及び説明のためのものである。これは、本発明を余すところなく説明するものでもないし、又、ここに開示した正確な形態に制限するものでもなく、前記教示に鑑み又は本発明を実施することから、種々の変更や修正が可能であろう。前記実施形態は、本発明の原理及びその実際の応用を説明するために選択され、記述されたもので、当業者であれば、種々の実施形態において本発明を利用し、且つ意図された特定の用途に適するように種々の変更をなすことができるであろう。

リッチメディア環境においてサーバーとクライアントとの間でフィードバックメッセージを送信する方法を示す図である。本発明を実施できるシステムを示す図である。本発明を実施するのに使用できる移動電話の斜視図である。図３の移動電話の電話回路を示す回路図である。

Claims

リッチメディアクライアントとリッチメディアサーバーとの間で送信するためのリッチメディアコンテンツに関する情報を与える方法において、
事象、事象識別子及びエレメント識別子を有する第１部分、並びに送信のためのデータを含む第２部分を備えた情報のテキスト＋オクテットペイロードを準備するステップと、
所定のプロトコルを使用して前記リッチメディアクライアントとリッチメディアサーバーとの間で前記準備されたテキスト＋オクテットペイロードを送信するステップと、
を備えた方法。
前記情報は、フィードバック情報を含む、請求項１に記載の方法。
前記情報は、フィードフォワード送信情報を含む、請求項１に記載の方法。
前記データは、一連のオクテットとして記憶される、請求項１に記載の方法。
前記データは、事象の属性を含む、請求項１に記載の方法。
前記データは、前記リッチメディアクライアントからの処理された情報を含む、請求項１に記載の方法。
前記事象は、ＳＶＧ事象を含む、請求項１に記載の方法。
前記事象は、ユーザ定義事象を含む、請求項１に記載の方法。
前記事象識別子は、前記リッチメディアクライアントからのフィードバックメッセージを識別するのに使用される独特の識別子である、請求項１に記載の方法。
前記エレメント識別子は、事象をトリガーするソースエレメントの識別子である、請求項１に記載の方法。
前記所定のプロトコルは、マルチメディアメッセージングシステムを含む、請求項１に記載の方法。
前記所定のプロトコルは、ショートメッセージングシステムを含む、請求項１に記載の方法。
前記所定のプロトコルは、ハイパーテキスト転送プロトコルを含む、請求項１に記載の方法。
前記テキスト＋オクテットペイロードは、ＨＴＴＰＧＥＴ要求によって搬送される、請求項１３に記載の方法。
前記テキスト＋オクテットペイロードは、ＨＴＴＰＧＥＴ要求をミリ秒に基づくように拡張するための情報を含む、請求項１４に記載の方法。
前記テキスト＋オクテットペイロードは、ＨＴＴＰＧＥＴ要求を同期サンプルに基づくように拡張するための情報を含む、請求項１４に記載の方法。
前記テキスト＋オクテットペイロードは、ＨＴＴＰＰＯＳＴ要求により搬送される、請求項１３に記載の方法。
前記テキスト＋オクテットペイロードは、ＨＴＴＰＰＵＴ要求により搬送される、請求項１３に記載の方法。
前記所定のプロトコルは、リアルタイムストリーミングプロトコルを含む、請求項１に記載の方法。
前記テキスト＋オクテットペイロードは、ＰＬＡＹ要求により搬送される、請求項１に記載の方法。
前記テキスト＋オクテットペイロードにおける事象は、前記リッチメディアクライアントにより処理される、請求項１に記載の方法。
前記テキスト＋オクテットペイロードにおける事象は、前記リッチメディアサーバーにより処理される、請求項１に記載の方法。
前記テキスト＋オクテットペイロードは、複数のセグメントを含み、これら複数のセグメントの各々は、メタデータを含み、このメタデータは、各セグメントのアイデンティティ、セグメントの合計数、送信されるデータのフォーマット、及びテキスト＋オクテットペイロードの長さの指示を含む、請求項１に記載の方法。
前記複数のセグメント各々のメタデータは、更に、使用されるキャラクタセットの名前を含む、請求項２４に記載の方法。
前記テキスト＋オクテットペイロードは、送信されるデータのフォーマット、テキスト＋オクテットペイロードの長さ、及び使用されるキャラクタセットの名前を含むメタデータを備えた、請求項１に記載の方法。
前記リッチメディアコンテンツは、ＳＶＧコンテンツ、オーディオコンテンツ、ビデオコンテンツ、イメージ、テキスト、及びその組み合せより成るグループから選択される、請求項１に記載の方法。
リッチメディアクライアントとリッチメディアサーバーとの間で送信するためのリッチメディアコンテンツに関する情報を与えるコンピュータプログラム製品において、
事象、事象識別子及びエレメント識別子を有する第１部分、並びに送信のためのデータを含む第２部分を備えた情報のテキスト＋オクテットペイロードを準備するためのコンピュータコードと、
所定のプロトコルを使用して前記リッチメディアクライアントとリッチメディアサーバーとの間で前記準備されたテキスト＋オクテットペイロードを送信するためのコンピュータコードと、
を備えたコンピュータプログラム製品。
前記所定のプロトコルは、マルチメディアメッセージングシステムを含む、請求項２７に記載のコンピュータプログラム製品。
前記所定のプロトコルは、ショートメッセージングシステムを含む、請求項２７に記載のコンピュータプログラム製品。
前記所定のプロトコルは、ハイパーテキスト転送プロトコルを含む、請求項２７に記載のコンピュータプログラム製品。
前記所定のプロトコルは、リアルタイムストリーミングプロトコルを含む、請求項２７に記載のコンピュータプログラム製品。
前記情報は、フィードバック情報を含む、請求項２７に記載のコンピュータプログラム製品。
前記情報は、フィードフォワード送信情報を含む、請求項２７に記載のコンピュータプログラム製品。
前記リッチメディアコンテンツは、ＳＶＧコンテンツ、オーディオコンテンツ、ビデオコンテンツ、イメージ、テキスト、及びその組み合せより成るグループから選択される、請求項２７に記載のコンピュータプログラム製品。
プロセッサと、
前記プロセッサに作動的に接続されたメモリユニットであって、電子装置とリモート装置との間で送信するためのリッチメディアコンテンツに関する情報を与えるコンピュータプログラム製品を含むメモリユニットと、
を備え、前記コンピュータプログラム製品は、
事象、事象識別子及びエレメント識別子を有する第１部分、並びに送信のためのデータを含む第２部分を備えた情報のテキスト＋オクテットペイロードを準備するためのコンピュータコードと、
所定のプロトコルを使用して電子装置とリモート装置との間で前記準備されたテキスト＋オクテットペイロードを送信するためのコンピュータコードと、
を備えたものである、電子装置。
前記所定のプロトコルは、マルチメディアメッセージングシステムを含む、請求項３５に記載の電子装置。
前記所定のプロトコルは、ショートメッセージングシステムを含む、請求項３５に記載の電子装置。
前記所定のプロトコルは、ハイパーテキスト転送プロトコルを含む、請求項３５に記載の電子装置。
前記所定のプロトコルは、リアルタイムストリーミングプロトコルを含む、請求項３５に記載の電子装置。
前記情報は、フィードバック情報を含む、請求項３５に記載の電子装置。
前記情報は、フィードフォワード送信情報を含む、請求項３５に記載の電子装置。
前記リッチメディアコンテンツは、ＳＶＧコンテンツ、オーディオコンテンツ、ビデオコンテンツ、イメージ、テキスト、及びその組み合せより成るグループから選択される、請求項３５に記載の電子装置。
前記リモート装置は、リッチメディアサーバーを含む、請求項３５に記載の電子装置。