JP2009508245A - マルチメディアコンテンツを無線通信端末に送信する方法 - Google Patents

Abstract

初期シーンと呼ばれる少なくとも１つのマルチメディアシーンとその初期シーンを動かす一連のコマンドとを含むマルチメディアコンテンツをサーバ１１から無線通信端末１２へ送信する方法が提供される。本方法は、前記コンテンツの初期部分をサーバ１１から端末１２へ送信するステップと、その初期部分を端末１２で記録および再成するステップと、端末１２からのリクエストに応答して、前記コンテンツの少なくとも１つの補完となる部分を端末１２によって既に受信された少なくとも１つの部分の補完の形によってサーバ１１から端末１２へ送信するステップと、前記補完となる部分を記録するステップと、端末１２によって既に受信された部分からリクエストに基づいてアップデートされたマルチメディアシーンを再成するステップとから構成される。

Description

マルチメディアコンテンツを、例えば携帯電話機、ＰＤＡ（携帯情報端末）、ポータブルコンピュータなどのタイプの無線通信端末において復元する技術に関する。

より正確には、本発明は、マルチメディアコンテンツ、このコンテンツの一部、および／または後者を代表するエレメントを、無線通信端末へ送信する技術に関する。

マルチメディアコンテンツとは、マルチメディアシーンとも呼ばれる少なくとも１つの動画グラフィックシーンと、このシーンが１つの状態から別の状態に変化することを可能にする一連のコマンドを含む集合である。マルチメディアシーンは特に時間と空間における１セットのグラフィックスオブジェクトをアレンジしたものの集合にあたり、無線通信端末のユーザはそれと双方向のやり取りをすることができる。

本発明はグラフィックスオブジェクトの時間空間的配置の形の信号の表現をインタラクティブ性と共に要求する全ての分野に適用することが可能である。

特に、本発明は、例えばＭＰＥＧ−４／ＢＩＦＳ（Binary Format Scene）、ＳＶＧ（Scalable Vector Graphics）、ＳＭＩＬ（Synchronized Multimedia Integration Language）、ＸＨＴＭＬ（eXtensible HyperText Markup Language）などの既に知られているグラフィックスシーンの記述フォーマットに適用される。

マルチメディアコンテンツを無線通信端末へ送信する技術は既に知られている。

従来的に、第１の送信技術によれば、サービスのデザイン、すなわち無線通信端末のユーザへの情報の提供は、
・初期コンテンツ（initial content）が端末に送信される；
・ユーザはそれを取り込んでリクエストを作成する；
・次にレスポンスコンテンツが無線通信端末へ送信される、云々といった一連の手続きを実行することから成る。

従ってサービスはインタラクティブリクエストに応答してユーザの端末に送信される一連のコンテンツとして設計される。

例えば、ユーザが気象サービスをリクエストする場合、端末に送信される初期コンテンツはその日の天気予報を含む。

ユーザはそれを取り込んで、つまりその日の天気予報を読み込んで、翌日の天気予報を取得するリクエストを作成する。

新たなレスポンスコンテンツは、翌日の天気予報から成り、次に無線通信端末に送信され、端末のメモリ内の初期コンテンツはこの新たなコンテンツによって置き換えられる。

この第１の送信技術によれば、送られた各レスポンスコンテンツは要求されたコンテンツを代表する全体のシーンを含むが、上記の例のフレームワーク内においては、天気を記述する絵文字のみが変更され、天気予報を提示するマルチメディアシーンを構成する他のグラフィックスオブジェクト（例えばフランスの背景地図）は変わらないままである。

結果的に、先行技術によるこの第１の送信技術の主な不利な点は、ユーザからの１つのリクエストに応答して、初期コンテンツとレスポンスコンテンツとの間に少しの変更部分しかなくても、全体のシーンをダウンロードする必要があるということである。

従ってレスポンスコンテンツをダウンロードすることは少なくも部分的には時間の浪費にあたり、伝送リソースの点から見てコスト高である。このことは、無線通信端末のインタラクティブマルチメディアサービスではモバイルネットワークの最低帯域幅（約毎秒数十キロビット）であることからなおさらそうで、高速インターネットにおいて“インタラクティブ”であるような例では、その煽りを受けることとなる。

加えて、新しいシーンをロードすることにより、使用の好み（プリファレンス）ばかりでなく、ユーザの意識にも中断が生じてしまい、その結果、ローカルにインタラクションしている際の脈絡がわからなくなってしまう。実際、従来のこの技術によれば、初期コンテンツは新しいコンテンツに完全に置き換えられる。

結果的に、通信セッションが途絶し、次にセッションが再確立されるときには、例えばユーザの使用におけるプリファレンス（usage preference）を検索するために初期コンテンツを再度ロードする必要があるかもしれない。

マルチメディアコンテンツを無線通信端末に送信する更に他の技術が存在する。

第２の技術によれば、無線通信端末にプログレッシブに送信されるシーンを生成することを可能にするシーンコマンド（scene commands）が利用される。

斯かるコマンドは特にＢＩＦＳ（Binary Format for Scene）およびＬＡＳｅＲ（Lightweight Application Scene Representation）記述フォーマットにより定義される。斯かる記述フォーマットは、例えばＩＳＯ／ＩＥＣ １４４９６−２０：２００６（２００６年公表）に定義されており、その暫定版はＭＰＥＧ Ｎ７４８０：”Study Text of ISO/IEC 14496-20/FCD”として入手可能である。

これらのシーンコマンドによれば、コマンドが時間を追って順番に送られる場合に、シーンが完全にダウンロードされる前にそのシーンの復元を始めることができるようになる。

しかしながら、この第２の技術の不利な点は、この技術によれば無線通信端末はシーンをダウンロードしている間にそのシーンの復元を始めることができるとしても、この技術もユーザとの双方向のやり取り（interaction）に応答して全体のシーンをフルにロードする必要があるということである。

加えて、図２Ａに示すように、端末によって復元される初期シーン２１_１は、マルチメディアコンテンツが送信された際に、第１のアップデートされたシーン（updated scene）２２_１により置き換えられ、次に第２のアップデートされたシーン２３_１により置き換えられ、続いて第３のアップデートされたシーン２４_１により置き換えられ、・・・以下同様。端末に記憶された最後のシーンは最後のアップデートされたシーン（例えば三番目のアップデートされたシーン２４_１）に相当するので、端末からは初期シーンについての知識が失われる。

このため、この技術の主な不利な点は、伝送がインタラプト（割込）され、その後に再確立される場合には、特にユーザが自分のプリファレンスおよび／またはローカルインタラクションの任意のコンテクストを検索したいと思う場合には、端末は初期シーンを再度、ロードしなければならない。

最後に、無線通信端末へマルチメディアコンテンツを送信する第３の技術を示す。

この技術によれば、メディアプレイヤ（無線通信端末）は、例えばＥＣＭＡＳｃｒｉｐｔまたはＪａｖａ（登録商標）タイプのプログラミング言語インタプリタを有する。シーンは、サーバに接続する複雑なスクリプトを含み、データ交換プロトコルをサーバにおいて実行し（例えば、サーバと交換されたデータがＸＭＬフォーマットであればＸＭＬドキュメントの構文解析）、受信データに基づいてシーンのエレメントを構築する。

この第３の技術はシーンそれ自体のスクリプト内にシーンコマンドの均等物を実装することに戻る。

しかしながら、この技術を実装するのに必要な環境、リソースまたはパフォーマンスを備える端末がほとんど存在しないため、この技術は現行のモバイル端末には適用されない。

加えて、この技術の主な不利な点は、高い実装コストが掛かかり、現行のリソースを考慮すると、それはほとんどの動きのないシンプルなグラフィックスオブジェクトから成るシンプルなシーンにしか適用することができないということである。

従来のこの技術の他の不利な点は更に、コンテンツのサイズの点、コンテンツ生成が複雑なこと、および、コンテンツと同じ種類のデータ交換プロトコルを実装するサーバとの間に相互依存性があることである。

実際、サーバとのデータ交換プロトコルの処理スクリプトを含むコンテンツは最小サイズが約１０００乃至４０,０００オクテット（正確に言えばシーンを除く）である。スクリプトのサイズのばらつきは特に、サイズの点でよりボリュームの大きな“ＸＭＬ”タイプの、またはよりボリュームの小さいバイナリのプロトコルを実装する可能性と、可能な変更コマンドの数の点から見て多かれ少なかれ完全なプロトコルを提供する可能性から来ている。

こうしたことから、従来のこの技術によるコンテンツ生成の複雑さの度合いはシンプルな“パッシブ（passive）”コンテンツ（つまりスクリプトなし）に対する複雑さよりも大きい。

最後に、この第３の技術の別の不利な点は、データを斯かるコンテンツに供給することができるようにするために、サーバは供給しなければならないコンテンツによって使用されるデータ交換プロトコルを実装する必要があるということである。従ってサーバは適用可能な場合には別のデータ交換プロトコルを使用するコンテンツに適応するために修正または別のサーバによって置換されなければならない。

本発明の目標は特に先行技術のこれらの不利な点を克服することにある。

より正確に言えば、本発明の目標はマルチメディアコンテンツを無線通信端末に送信するための技術であって双方向のやり取り（interaction）に応答した全シーンのダウンロードを必要としない技術を提供することにある。

本発明の別の目標は、特に通信セッションにおいて割込が起こる場合に、双方向のやり取りについての応答時間を先行技術と比較して短縮することを可能にする技術を実現することにある。

特に、本発明の目標は、無線通信端末におけるサービスの流動性（操作の軽さ；fluidity）の点でパフォーマンスがより優れた技術を提供することにある。

本発明の更なる目標は、帯域幅の点から見てリソースをあまり必要としない送信技術を提供することにある。

本発明のなお更なる目標は、シンプルでコストが掛からず、大がかりな処理手段、または大がかりなデータ記憶手段を必要としないマルチメディア端末を生み出すことを可能にする技術を提供することにある。

これらの目標ならびに以下の説明により明らかとなる他の目標は、初期シーン（initial scene）と呼ばれる少なくとも１つのマルチメディアシーン（multimedia scene）とその初期シーンを変化させ得る一連のコマンドとを含むマルチメディアコンテンツ（multimedia content）をサーバ（server）から無線通信端末（radiocommunicaton terminal）へ送信する方法を使用したことによって達成される。

本発明によれば、本方法は、
前記マルチメディアコンテンツの初期部分（initial portion）は少なくとも前記初期シーンを含んでおり、その初期部分を前記サーバから前記端末へ送信する送信ステップと、
前記初期部分を前記端末に記憶する記憶ステップの後に、前記初期部分を前記端末上において復元する復元ステップと、
前記端末から到来するリクエストに応答して、前記マルチメディアコンテンツの補完となる部分（コンプリメンタリ部分；complementary portion）を、前記端末によって既に受信された少なくとも１つの部分の補完（complement）の形によって、前記サーバから前記端末へ送信する少なくとも１回の送信ステップと、
前記補完となる部分を記憶する記憶ステップの後に、前記既に受信された部分を用いて、前記端末が前記リクエストに基づくアップデートされたマルチメディアシーンを復元する復元ステップとから構成される。

このように、本発明は、マルチメディアコンテンツの初期部分の送信と、続いて端末からのリクエストの後の、端末が既に受信している１つまたは複数の部分（例えば初期部分）の間のコンプリメンツ（complements）または差分（differences）に相当する、そのコンテンツの補完となる部分の送信とに基づく、無線通信端末にマルチメディアコンテンツを送信する完全に新規で独創的なアプローチを提案する。

このアプローチでは、無線通信端末は、補完を初期シーンもしくは既にアップデートされたマルチメディアシーンと組み合わせることによって、アップデートされたマルチメディアシーンを復元することができる。

特に、補完となる部分を送信および記憶するステップと、アップデートされたマルチメディアシーンを端末によって復元するステップは、必要な回数だけ、そしてリクエストの数だけ、従ってコンテンツの補完となる部分の数だけ、繰り返すことが可能である。

特に、前記初期部分は前記一連のコマンドの少なくとも１つのコマンドをさらに含む。

従って本発明は無線通信端末に送信されるサービスを代表するマルチメディアコンテンツを、少なくとも初期シーンとできれば初期シーンの更新コマンドを含む、コンテンツの初期部分が最初に端末に送信される形によって、構造化することを可能にする。次に、第１のリクエストに応答して、補完となる部分が、そのリクエストに応答してアップデートされたマルチメディアシーンを復元することができるように、初期部分の補完（complement）の形によって端末に送信される。新たなリクエストがサーバに発行された場合、別の補完となる部分が、その新たなリクエストに応答してアップデートされたマルチメディアシーンを復元することができるように、端末によって既に受信された少なくとも１つの部分の補完の形によって、端末に送信される。以下同様。

このようにサービスをコンテンツの連続する部分の形に構造化することによって、先行技術と比べてサイズが削減された一連のインクリメンタル部分（徐々に増やしていく部分）が送信される。これによりモバイルサービスの応答時間を短縮することが可能となる。

従って無線通信端末へのフローは、マルチメディアシーンの連続する状態の間の一連の補完となる部分（complements）、または差分（differences）から構成される。このフローは本発明によればコンテンツの異なる部分に分割される。

従って本発明による技術は、より少ないデータをダウンロードすることによって同じ結果（同じコンテンツ）が得られることから、双方向のやり取り（interactions）についての応答時間の利得と、ユーザおよびオペレータに対するサービスの効率性の利得を獲得することを可能にする。

本発明によればサービスはマルチメディアシーンの連続的な変更という形により設計されているので、本発明はサービスの連続性と流動性の印象を与える。このほかに本発明は、現在のコンテンツの変更部分のみが端末に送信されることから、時間の大きな節約も実現する。

加えて、サーバに接続する複雑なスクリプトを使用することに基づいており、例えばＥＣＭＡＳｃｒｉｐｔまたはＪａｖａ（登録商標）タイプのプログラミング言語インタプリタの使用を要求する技術と比べて、本発明は、あまりリソースを必要とせず、従ってあまりコストがかからない例えば電話機などの通信端末において利用可能なメディアプレイヤを使用することを可能にする。

さらに、マルチメディアコンテンツの一部分は先行技術と比べて、よりシンプルで、サイズも小さいので、それを生成するためのコストと伝送時間もあまり掛からない。

最後に、ＥＣＭＡＳｃｒｉｐｔタイプの先行技術によれば、サーバとマルチメディアコンテンツのスクリプトは必ずしも同じデータ伝送プロトコルを実装する必要はないが、本発明は全てのサーバとコンテンツとの間の相互運用性を考慮に入れている。

また、補完となる部分において送信される“補完（complement）”は端末から到来するリクエストに基づいて現在のシーンをアップデートされたシーンに変更することを可能にするシーン変更コマンドを含むと考える。

こうして、端末は、初期シーンとこの初期シーンを変化させる（または変更する）ことを可能にする任意のコマンドとを含む初期部分をローカルコンテクスト（local context）に格納し、更に様々ないくつかある補完となる部分（complements）もそれらがサーバから端末に送られたときに格納することができる。従ってローカルコンテクストは補完となる部分において送られた様々なコマンドによってインクリメント（追加）される。

結果、図２Ａに示したような先行技術によれば初期シーンは、端末のメモリにおいて、ユーザの様々なリクエストに応答してサーバによって様々なアップデートが送信されるごとに更新されるが、それに対して本発明による端末は、初期シーンと、利用可能なマルチメディアシーンのアップデートを可能にするコマンドを、ローカルコンテクストに常に保持する。

結果、通信セッションが切断され、その後に再確立される場合、サーバは初期シーンおよび／または変更コマンドを端末に再送する必要はない。

特に、このソリューションは、情報を全く損失することなくユーザが切断と再接続を行うことができるという意味で、“オフライン（off-line）”ワークを可能にする。

一例として、例えば“情報（Information）”タブ、“映画（Cinema）”タブ、“ミュージック（Music）”タブといった複数のタブによって構成された初期シーンをとって説明すると、端末のユーザは例えば“映画”タブを選ぶことができ、その結果、その週の映画プログラムが表示される。コンテンツが端末のディスプレイ（例えばスクリーン）上において復元されると、ユーザ（または直接的には端末）は、ユーザがプログラムを閲覧する間、切断（つまり“オフライン”モードへの切替）を選ぶことができる。

従って本発明によるローカルコンテクストは、初期シーンと、表示されたタブを“映画”に変更するコマンドとを含む。

次にユーザは“情報”タブを選択することによってその日のニュースを見たいと思っていると考える。この際、端末は接続モード（connected mode）と呼ばれる“オンライン（on-line）”モードに戻る。ローカルコンテクストは、初期シーン、“映画”と表示されたタブを変更するコマンド、“映画”タブを“情報”タブに変更するコマンドを含む。

先行技術によれば、端末は“映画”タブを選択する際にそのメモリにおいて初期シーンをアップデートし、それをその週の映画プログラムにより置き換える。それ故、端末はサーバへリクエストを送信して、サーバに初期シーンを再送してもらう。従ってローカルインタラクション（local interaction）のコンテクストは失われる。

本発明によれば、端末はメモリにまだローカルコンテクストを格納しており、従って初期シーンから、切断する前に復元された最終シーンに切り替えることを可能にする異なるコマンドを迅速に見つけ出すことができる。

それ故、端末からのリクエストの後に、サーバは初期シーンを再送する必要はない。サーバは補完となる部分を、マルチメディアシーンをアップデートすることを可能にする初期部分の補完の形によって、端末に送信すれば十分である。特に、これらのコンプリメンツは作成者またはサービスプログラムによって事前に定義され、サーバによって計算されない。

続いて端末はアップデートされたマルチメディアシーンをユーザのリクエストに基づいて復元する、すなわち初期部分と補完となる部分（および場合によっては端末によって既に受信された他の補完となる部分）を用いて、“情報”タブを生成することができる。

特に、接続モード／切断モードからの切替の関心事は迅速性と数が増大したリクエストの同時処理にある。実際、全てのユーザがサーバとの接続をコンスタントに維持する場合、すなわちサービスが１つの一意に決まるシーン（unique scene）としてサービスの最初から最後まで時間を追って変更部分（modifications）を受信するように設計される場合、サーバがサービスすることができるクライアントの制限数はＮである。しかしながら、ユーザがサーバから各レスポンスを受信した後に接続を切断し、サーバから次のレスポンスを受信するために接続を再確立する場合、サーバはＮ個の同時のリクエストに制限されるだけである。

特に、端末から到来するリクエストは端末のユーザからのリクエスト、またはアップデートされたマルチメディアシーンを復元した後のリクエストである。

こうして、これらのリクエストに応答したコンプリメンツは、マルチメディアコンテンツを生成または保存する際に、シーンを復元した後のリクエストのフレームワーク内において事前に定義することができる。例えば、ユーザが“明日の天気”タブをクリックする場合、翌日の天気が復元されたときに“今日の天気”ボタンが現れる。

リクエストはユーザからも到来する可能性があり、その結果、端末に送信されるコンプリメンツの動的なセクショニングがもたらされる。

本発明の代替態様として、本発明の送信方法は、コンテンツの異なる部分に対して、少なくとも２つの区別可能な送信チャネル、または異なるトランスポートセッション（異なるトランスポートプロトコルも伴う）を実装する。

これにより、送信される補完はシンプルであり、少ない伝送リソースしか必要としないで、補完となる部分は低速ネットワークによって送信することが可能である。

特に、コンテンツの初期部分は高速チャネルを使用して（例えばインタネットネットワークによって）送信され、かつ／または端末に事前に格納される。

本発明の代替形態様して、前記部分（初期部分および／または補完となる部分）はサーバ上の別々のドキュメントに含まれる。

例えば、これらのドキュメントは“Ｗｅｂ”ページタイプであり、または“ストリーミング”もしくは“ブロードキャスト”タイプのジェネリックコンテンツである。

例えば、作成者（またはサービスプログラム）は“コンテンツＡ”を直接作成し、次に別のドキュメント“コンテンツＣ”を、この“コンテンツＣ”が“コンテンツＢ”と“コンテンツＡ”との間の差分（コンテンツＣ＝コンテンツＢ−コンテンツＡ）として定義されるように作成する。

本発明のこの態様によれば、コンテンツＢをそのメモリに復元するのは端末である。このようにコンテンツＢはサーバには保存されない。

特に、これらの別々のドキュメントは、データトランスポートの異なる手段によって受信することが可能な区別可能なアドレスによって参照される。

ある特定の態様として、サーバは端末に“ＬＡＳｅＲ”フォーマットにおける“Ａｐｐｅｎｄ”タイプのマルチメディアシーンの設定信号も送信する。

この信号は端末に、この端末に送信されたコマンドはシーンの要素を変更するコマンドであり、シーン全体をダウンロードする必要がないことを特に通知することを可能にする。

シーンを変更することを可能にするコマンドは、本発明のこの特定の態様によれば、“ＬＡＳｅＲコマンド”というシーンコマンドである。

本発明は、通信ネットワークからダウンロードすることが可能であり、かつ／またはコンピュータによる読取りが可能な媒体に格納されており、かつ／またはマイクロプロセッサによって実行することが可能なコンピュータソフトウェア製品も提供する。本コンピュータソフトウェア製品は、マルチメディアコンテンツを送信する上記方法を実行するプログラムコード命令を含む。

本発明は更に、初期シーンと呼ばれる少なくとも１つのマルチメディアシーンとその初期シーンを変化させ得る一連のコマンドとを含むマルチメディアコンテンツをサーバから無線通信端末へ送信する信号も提供する。本送信信号は、初期部分と少なくとも１つの補完となる部分とを含むコンテンツの少なくとも２つの部分を含んでおり、ここで、前記補完となる部分は、前記端末から到来するリクエストに応答して、前記端末によって既に受信された少なくとも１つの部分の補完の形によって前記端末へ送信される部分である。

別の態様においては、初期部分と補完となる部分は、それぞれ独立に、例えば別々のプロトコルに基づいて別々のチャネルによって送信することができることに留意する。

本発明は、初期シーンと呼ばれる少なくとも１つのマルチメディアシーンとその初期シーンを変化させ得る一連のコマンドとを含む、サーバによってブロードキャストされたマルチメディアコンテンツを受信することを目的とする無線通信端末も提供する。本無線通信端末は、少なくとも前記初期シーンを含む、前記コンテンツの初期部分と、前記端末から到来するリクエストに応答して、前記端末によって既に受信された少なくとも１つの部分の補完の形によって受信された、前記コンテンツの少なくとも１つの補完となる部分とを受信する手段と、
前記初期部分と前記補完となる部分とを記憶する手段と、
前記既に受信された部分を使用して、前記初期部分と前記リクエストに基づいてアップデートされたマルチメディアシーンを復元する手段とを具備する。

特に、本無線通信端末の受信手段は、少なくとも２つの別々の伝送チャネルによって送信されたコンテンツの複数の部分を受信することが可能である。

本発明は更に、初期シーンと呼ばれる少なくとも１つのマルチメディアシーンとその初期シーンを変化させ得る一連のコマンドとを含むマルチメディアコンテンツを無線通信端末において復元する方法も提供する。本方法は、
少なくとも１つの初期シーンの集合を記憶する記憶ステップを含み、少なくとも１回以上繰り返す一連のステップとして、
マルチメディアコンテンツのブローキャストサーバにリクエストを送信するステップと、
前記リクエストの応答として、前記端末によって復元されるマルチメディアシーンの補完を受信するステップと、
前記初期シーンまたは既にアップデートされたマルチメディアシーンを表現するデータと、前記補完とを組み合わせて、アップデートされたマルチメディアシーンを前記端末が決定するステップとを更に含む。

最後に、本発明は、初期シーンと呼ばれる少なくとも１つのマルチメディアシーンとその初期シーンを変化させ得る一連のコマンドとを含むマルチメディアコンテンツを、少なくとも１つの無線通信端末にブロードキャストするブロードキャストサーバも提供する。本サーバは、
少なくとも前記初期シーンを含む、前記マルチメディアコンテンツの初期部分を送信する手段と、
リクエストを処理する手段と、
前記端末から到来するリクエストに応答して、前記マルチメディアコンテンツの補完となる部分を、前記端末によって既に受信された少なくとも１つの部分の補完の形によって、当該サーバから前記端末へ送信する手段とを具備する。

本発明の他の特徴及び効果は、単一の非限定的かつ例示的な実施例として示された、本発明の好ましい実施形態の以下の説明を読めば、および添付図面からより明白になる。

本発明の一般原理は、少なくとも１つのマルチメディアシーンと、このシーンを少なくとも２つの部分（初期部分と補完となる部分）において変化させ得る一連のコマンドとを含む、マルチメディアコンテンツの分割（partitioning）に基づくものである。

初期部分（最初の部分）と呼ばれる、コンテンツの第１の部分は、最初に無線通信端末に送信される。次に、コンプリメンタリ（補完的）と呼ばれる部分は無線通信端末から到来するリクエストに応答してその端末に送信される。

本発明は、端末によってダウンロードされるデータ量を減らすと同時に、サービスの流動性の印象を与えるインタラクティブマルチメディアシーンを再構築することを可能にする。

送信されるマルチメディアコンテンツをいくつかのインクリメンタルシーン（増分のシーン；incremental scenes）に分割することによって、サーバに関してかなりの節約を実現することが可能である。

実際には、サーバは通常、同時処理できるクラアント数をＮに制限される。Ｎは、マシンのパワーと、サービスの複雑さなどに依存する数である。

全てのユーザがサーバとの接続をコンスタントに維持する場合、すなわちサービスが１つの一意に決まるシーン（unique scene）としてサービスの最初から最後まで時間を追って変更部分（modifications）を受信するように設計される場合、サーバがサービスすることができるクライアントの制限数はＮである。

しかしながら、ユーザがサーバから受信した各レスポンス後に接続を切断し、サーバから次のレスポンスを受信するために接続を再確立する場合、サーバはＮ個の同時リクエストに制限されるだけである。このときサーバによってサービスされるクライアントの数はもっと大きく、そのファクタは補完となる部分の送信時間の間の関係とユーザインタラクションの間の平均時間にリンクし、比率は１００を超える。

より正確には、本発明の特定の実施形態によれば、送信される補完となる部分は、“ＬＡＳｅＲ”フォーマットにおけるシーンの少なくとも１つのエレメントの変更コマンド（“LASeR Commands”）から成るグローバルシーン変更コマンドの形によって、補完（complement）を含む。

この実施形態の代替として、グローバルシーン変更コマンドは“Append”タイプのシーン設定信号（scene configuration signal）をも含む。この“Append”モードは、通常、現在のシーンが初期シーンを含まないが、端末に既にロードされたシーンに適用する一連のコマンドのみを含むことを示すために、ＬＡＳｅＲ標準において定義される。

サーバは“Append”モード（本発明によればこのモードは、現在のシーンにレスポンスが追加されなければならないことを警告することを可能にする）を有していることからユーザはサーバとの接続を切断することができる。

さらに、サーバはクライアントセッションを無期限にオープンに維持することができないので、それらは通常、サイレントなクライアント（何のリクエストもサーバ宛に発行していないもの）が所定の期間が経過した後に自動的に切断されると考えることが強制される。

本発明によれば、送信すべきマルチメディアコンテンツをインクリメンタルシーンに分割することで、サーバは接続を直ぐに切断して、任意に長い期間が経過した後に接続を再確立することができる。

図示されていないが、本発明のある特定の実施形態によれば、送信される補完となる部分は、“ＬＡＳｅＲ”フォーマットにおける、シーンの少なくとも１つのエレメントの変更コマンド（“LASeR Commands”）から成る、グローバルシーン変更コマンドを含む。

シーンコマンドは、シーンのエレメントに対する変更コマンドとも呼ばれ、シーンの変更、すなわち端末上において以前復元されたシーンの補完を表現することを可能にする。

図１に本発明の１つの特定の実施形態を示す。本実施形態によれば、サーバ１１は無線通信端末１２にサービスを提供する。

サービスは、ユーザの端末に特にインタラクティブリクエスト（interactive requests）に応答して送信される、コンテンツ、またはコンテンツの複数の部分から成るシーケンスとして設計されていることを思い起こす。

本発明によれば、無線通信端末１２に送信されるマルチメディアコンテンツは、少なくとも１つのマルチメディアシーンと、そのマルチメディアシーンを変化させ得る一連のコマンドとを含む。

サーバ１１は最初に送信ステップ１３において、初期部分と呼ばれる第１の部分を、無線通信端末１２に送信する。

サーバ１１は次に送信ステップ１４において、端末から到来するリクエストに応答して、ＬＡＳｅＲシーンコマンドを含む補完となる部分を端末１２に送信する。

図５に示すように、ステップ５２において、端末１２は、ローカルコンテクスト（local context）に、ステップ５１においてサーバ１１によって送信された初期部分を記憶する。

続いて端末１２はステップ５３において初期シーンを復元する。

サーバ１１は次に、補完となる部分の送信ステップ５４において、端末から到来するリクエストに応答して、補完となる部分を、初期シーンの補完および／または既に受信された補完となる部分の形によって送信する。端末はステップ５５において、初期部分も含むローカルコンテクスト（local context）に、その補完となる部分を記憶する、またはこの補完となる部分に対応するシーンのための変更コマンドを直に記憶する。

次に端末は、ステップ５６において、記憶された初期部分と補完となる部分とを使用して、アップデートされたシーン（updated scene）を復元する。

ステップ５４、ステップ５５およびステップ５６は必要な回数だけ、特に端末から到来するリクエストの数だけ、繰り返すことができる。

次に図３Ａ、図３Ｂおよび図３Ｃを参照して、気象サービスを無線通信端末１２に送信するシナリオにおける本発明の実施形態の一例を簡単に説明する。

特に本例においては、図３Ａは初期マルチメディアシーンに相当し、その日のフランス全土の天気予報を示していると考える。

無線通信端末１２のユーザが気象サービスを利用したいと思えば、ユーザはまずサーバ１１にリクエストを送信する。

続いてサーバ１１はユーザに初期部分に相当するその日の天気図を送信する。

特に、初期部分はボリュームがあり、そのためダウンロードするのに長時間かかるときは、初期部分は双方向のやり取りの段階（interactive phase）の間は送信されないと考えることができる。これとは対照的に、この初期部分は例えば端末１２に事前にロードしておくことができる、あるいはマルチブロードキャストチャネル（例えばＤＶＢＨ”Digital Video Broadcasting Handheld”、ＤＭＢ”Digital Multimedia Broadcast”またはマルチキャストタイプ）において送信することができる。従ってそのサイズはあまり重要ではない。

端末１２のユーザが翌日の天気図を見たい思う場合、ユーザはサーバ１１にリクエストを送信して、サーバ１１に図３Ｂに示すような翌日の天気図を返信してもらうようにしなければならない。

先行技術によれば、その日の天気図（図３Ａ）と翌日の天気図（図３Ｂ）の違いが例え小さくとも、サーバ１１は図３Ｂにおける天気図をまるごと再送する。

これらの変更部分を図３Ｃに示す。点線は初期部分に相当し、実線は補完となる部分に相当する。

従ってサーバ１１はこの補完となる部分をＬＡＳｅＲフォーマットシーンコマンドを使用して追加シーンの形によって無線通信端末１２へ送信する。

ユーザは他のリクエストを作成（formulate）することができる。

ユーザからのリクエストと端末１２におけるレスポンスの到達との間の時間からサーバ１１がレスポンスを生成するのに要する時間を差し引いた値は、レスポンスの規模に比例し、帯域幅に反比例する。このため、レスポンスのサイズに関して少しでも増加すると、レスポンス時間が非常に大きく増加するという影響が出るため、最終的に双方向のやり取りに影響する。

言い換えると、ユーザのリクエストに応答して端末に送信されるコンテンツまたはマルチメディアコンテンツの部分のサイズを削減するため、かつサービスの流動感（動作の軽さ）を増やすため、レスポンスコンテンツはユーザがリクエストを送ったシーンへの変更部分と見なされる。

これらの変更部分はシーンコマンドのリストの形によって送信される。少なくとも１つのマルチメディアシーンとそのシーンの挿入コマンドを含む、初期部分の構造の一例を以下に示す。この構造は、
・サービスの発信源に関する様々な追加情報を含むフランス全土の背景地図；
・フォント、スタイル、色および配置に関する全ての情報を含めた、テキストＴ０：“今日の天気”；
・地図の５つのポイントにおける“１５℃”タイプの温度を表し、その関連するフォント、スタイル、色および配置の情報を含めた、５つのテキストＴ１乃至Ｔ５；
・明日および明後日以降の天気を取得するための１セットのリンクまたはボタン、から成る。

補完となる部分は、インクリメンタルシーン（incremental scene）に相当し、本発明によれば次のような構造を有する：
・本実施形態の代替形態に存在するがオプションである、“Append”タイプの設定信号；
・文字列Ｔ０を“明日の天気”に変更するコマンド；
・温度を表現する文字列Ｔ１乃至Ｔ５を変更する５つのコマンド；
・“明日”ボタンまたはリンクを“今日”ボタンまたはリンクによって置き換えるコマンド。

本発明の特定の実施形態によれば、インクリメンタルシーンは“明日”ボタンまたはリンクの使用に応答して、つまりユーザからのリクエストに応答して生成される。特に本例によれば、文字列のみが置き換えられ、それらのフォント、スタイル、色および配置は置き換えられない。

“Append”モードにおけるシーン設定信号を含むこのグローバル変更コマンドとシーンの少なくとも１つのエレメントの変更コマンド（“LASeR Commands”）はマルチメディアシーンの全ての記述フォーマットに潜在的に適用可能である。ＢＩＦＳフォーマットは“LASeR Commands”に類似の“BIFS Commands”を既に定義している。同様に、“LASeR Commands”はＳＶＧフォーマットを修正することなく適用することが可能である。

加えて、これらの機能は既に電話機に効果的に実装されており、従って本発明を現行の端末、その中でも比較的限定されたものに実装することが可能である。

このように、無線通信端末に送信されるマルチメディアコンテンツを構造化することによって、完全なレスポンスコンテンツの代替として現在のコンテンツの補完のみが端末に送られることから、本発明は、そのコンテンツの端末に送らなければならない部分のサイズを小さくすることが可能で、これにより帯域幅を消費することを抑制することができ、レスポンス時間も改善され、そして端末におけるサービスの連続性と流動性を確保することができる。

加えて、図２Ｂに示すように、端末によって記憶されたローカルコンテクストが補完となる部分を受信する毎にインクリメントされることによって、初期部分は順次変更を受け続けることができる。こうして、初期シーン２１_２のアップデート３（２４_２）の後に端末がサーバとの接続を切断する場合、アップデート３（図２Ａ参照）を記憶していただけの先行技術とは対照的に、端末は、アップデート１（２２_２）、アップデート２（２３_２）およびアップデート（２４_２）に対応するシーンを変更するための異なるコマンドを記憶している。次の接続の際、端末はローカルコンテクストと補完となる部分を使用してアップデートされたシーンを復元することができる。

図４に本発明のこの特定の実施形態による端末の構造の一部を示す。この端末はメモリ４１を使用して、サーバから受信した初期部分にリンクしたローカルコンテクスト（local context）を記憶し、それを利用してサーバを介して受信した補完となる部分を記憶することができる。

マイクロプロセッサ４２はローカルコンテクストと各補完となる部分を使用してアップデートされたシーンを再編し、それをそのアップデートされたシーンを復元するディスプレイモジュール４３に送る。

本発明の一般原理を説明するための図である。それによれば、無線通信端末に送信されるマルチメディアコンテンツは、初期部分と少なくとも１つの補完となる部分とを含む少なくとも２つの部分に分けられる。初期部分は最初に端末に送信される部分であり、補完となる部分はその後に端末から到来するリクエストに応答して端末に送信される部分である。 先行技術による初期シーンとその更新の手続きを説明するための図である。 本発明の実施形態による初期シーンとその更新の手続きを説明するための図である。 それぞれ、初期シーン（今日の天気図）、リクエストの後に端末で復元される初期シーンのアップデート（翌日の天気図）、図１の手続きに従って前記リクエストに応答してサーバによって送信される補完となる部分を示す図である。 本発明の特定の実施形態による端末の構造の一部を示す図である。

Claims (13)

1. 初期シーンと呼ばれる少なくとも１つのマルチメディアシーンとその初期シーンを変化させ得る一連のコマンドとを含むマルチメディアコンテンツをサーバ（１１）から無線通信端末（１２）へ送信する方法であって、
   前記マルチメディアコンテンツの初期部分が少なくとも前記初期シーンを含んでおり、その初期部分を前記サーバ（１１）から前記端末（１２）へ送信する送信ステップと、
   前記初期部分を前記端末（１２）に記憶する記憶ステップの後に、前記初期部分を前記端末（１２）上において復元する復元ステップと、
   前記端末（１２）から到来するリクエストに応答して、前記マルチメディアコンテンツの補完となる部分を、前記端末（１２）によって既に受信された少なくとも１つの部分に対する補完の形によって前記サーバ（１１）から前記端末（１２）へ送信する少なくとも１回の送信ステップと、
   前記補完となる部分を記憶する記憶ステップの後に、前記既に受信された部分を用いて、前記端末（１２）が前記リクエストに基づくアップデートされたマルチメディアシーンを復元する復元ステップと
   を含んでなるマルチメディアコンテンツの送信方法。
2. 前記初期部分が前記一連のコマンドのうちの少なくとも１つのコマンドをさらに含む、請求項１に記載のマルチメディアコンテンツの送信方法。
3. 前記リクエストは、前記端末（１２）のユーザのリクエスト、または前記アップデートされたマルチメディアシーンを復元した後のリクエストである、請求項１および２に記載のマルチメディアコンテンツの送信方法。
4. コンテンツの異なる部分に対する少なくとも２つの区別可能な送信チャネルを実装している請求項１乃至３のいずれか１項に記載のマルチメディアコンテンツの送信方法。
5. 前記マルチメディアコンテンツの前記初期部分が高速チャネルを用いて送信される、かつ／または、前記端末（１２）に事前に格納される、請求項４に記載のマルチメディアコンテンツの送信方法。
6. 前記部分が前記サーバ上の別々のドキュメントに含まれる請求項１乃至５のいずれか１項に記載のマルチメディアコンテンツの送信方法。
7. 前記別々のドキュメントが区別可能なアドレスによって参照される請求項６に記載のマルチメディアコンテンツの送信方法。
8. 前記サーバ（１１）が前記端末（１２）に“ＬＡＳｅＲ”フォーマットにおける“Ａｐｐｅｎｄ”タイプのマルチメディアシーンの設定信号も送信する請求項１乃至６のいずれか１項に記載のマルチメディアコンテンツの送信方法。
9. 通信ネットワークからダウンロードすることが可能であり、かつ／またはコンピュータによる読取りが可能な媒体に格納されており、かつ／またはマイクロプロセッサによって実行することが可能なコンピュータソフトウェア製品であって、マルチメディアコンテンツを送信する請求項１乃至８のいずれか１項に記載された方法を実行するプログラムコード命令を含むコンピュータソフトウェア製品。
10. 初期シーンと呼ばれる少なくとも１つのマルチメディアシーンとその初期シーンを変化させ得る一連のコマンドとを含むマルチメディアコンテンツをサーバ（１１）から無線通信端末（１２）へ送信する信号であって、初期部分と少なくとも１つの補完となる部分とを含む、コンテンツの少なくとも２つの部分を含み、前記補完となる部分は、前記端末（１２）から到来するリクエストに応答して、前記端末によって既に受信された少なくとも１つの部分の補完の形によって前記端末へ送信される部分である、マルチメディアコンテンツの送信信号。
11. 初期シーンと呼ばれる少なくとも１つのマルチメディアシーンとその初期シーンを変化させ得る一連のコマンドとを含む、サーバ（１１）によってブロードキャストされたマルチメディアコンテンツを受信することを目的とする無線通信端末（１２）であって、
    少なくとも前記初期シーンを含む、前記コンテンツの初期部分と、前記端末（１２）から到来するリクエストに応答して、前記端末（１２）によって既に受信された少なくとも１つの部分の補完の形によって受信された、前記コンテンツの少なくとも１つの補完となる部分とを受信する手段と、
    前記初期部分と前記補完となる部分とを記憶する手段と、
    前記既に受信された部分を使用して、前記初期部分と前記リクエストに基づいてアップデートされたマルチメディアシーンを復元する手段と
    を具備してなる無線通信端末（１２）。
12. 初期シーンと呼ばれる少なくとも１つのマルチメディアシーンとその初期シーンを変化させ得る一連のコマンドとを含むマルチメディアコンテンツを無線通信端末（１２）において復元する方法であって、
    少なくとも１つの初期シーンの集合を記憶する記憶ステップを含み、少なくとも１回以上繰り返す一連のステップとして、
    マルチメディアコンテンツのブロードキャストサーバにリクエストを送信するステップと、
    前記リクエストの応答として、前記端末によって復元されるマルチメディアシーンの補完となる部分を受信するステップと、
    前記初期シーンまたは既にアップデートされたマルチメディアシーンを表現するデータと、前記補完となる部分とを組み合わせて、アップデートされたマルチメディアシーンを前記端末が決定するステップと
    を更に含む、マルチメディアコンテンツの復元方法。
13. 初期シーンと呼ばれる少なくとも１つのマルチメディアシーンとその初期シーンを変化させ得る一連のコマンドとを含むマルチメディアコンテンツを、少なくとも１つの無線通信端末（１２）にブロードキャストするブロードキャストサーバ（１１）であって、
    少なくとも前記初期シーンを含む、前記マルチメディアコンテンツの初期部分を送信する手段と、
    リクエストを処理する手段と、
    前記端末（１２）から到来するリクエストに応答して、前記マルチメディアコンテンツの補完となる部分を、前記端末（１２）によって既に受信された少なくとも１つの部分の補完の形によって、当該サーバ（１１）から前記端末（１２）へ送信する手段と
    を具備してなるブロードキャストサーバ（１１）。

Images