(57)【要約】本発明は、モバイル通信システムにおいてストリーミングサーバ１００からモバイルクライアント１０１にＲＴＰプロトコルを使用して書式設定済みテキストを送信する方法に関する。書式設定済みテキストは、関連付けられるテキストサンプル書式記述を有する少なくとも１つのテキストサンプルを含んでいる。さらに、本発明は、書式設定済みテキストを送信するストリーミングサーバ１００と、ストリーミングされた書式設定済みテキストを受信するモバイルクライアント１０１と、ストリーミングシステムとに関する。ＵＭＴＳなどの無線通信システムにおいて、ストリーミングテキストを、ＲＴＰを使用して送信するときの従来のシステムの送信オーバーヘッドを低減するため、ストリーミングサーバ１００は、送信するテキストサンプルの処理時に、以前のテキストサンプル用にモバイルクライアント１０１にまだ提供されていないテキストサンプル書式記述のみを送信する。サーバは、どのテキストサンプル書式記述がすでに提供されたかを判断する目的で、クライアントに送信されたテキストサンプル書式記述についての情報を維持する。
2007520914.tif 000002
【特許請求の範囲】
【請求項１】
モバイル通信システム（１０２）において、ストリーミングサーバ（１００）からモバイルクライアント（１０１）に、関連付けられるテキストサンプル書式記述を有する少なくとも１つのテキストサンプルを含む書式設定済みテキストを、ＲＴＰプロトコルを使用して送信する方法であって、前記ストリーミングサーバ（１００）によって実行される前記方法は、
送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にすでに提供されたか否かを判断するステップと、
すでに提供されていた場合、前記送信するテキストサンプルを、送信する少なくとも１つのデータパケットに追加するステップと、
提供されていない場合、前記送信するテキストサンプルと、その関連付けられるテキストサンプル書式記述とを、送信する少なくとも１つのデータパケットに追加するステップと、
前記少なくとも１つのデータパケットを前記モバイルクライアント（１０１）に送信するステップと、
を含む方法。
【請求項２】
前記すでに提供されたテキストサンプル書式記述は、以前のデータパケットにおいて前記モバイルクライアント（１０１）にすでに送信されている、請求項１記載の方法。
【請求項３】
前記すでに提供されたテキストサンプル書式記述は、前記以前のテキストサンプルの処理時に前記少なくとも１つのデータパケットにすでに追加されている、請求項１または請求項２に記載の方法。
【請求項４】
前記送信するテキストサンプルを少なくとも１つのデータパケットに追加する前記ステップは、前記少なくとも１つのデータパケットにおけるテキストサンプル書式記述とそれに関連付けられるテキストサンプルとの間のマッピングを提供する少なくとも１つのサンプル識別子を前記少なくとも１つのデータパケットに追加するステップをさらに含む、請求項１乃至請求項３のいずれかに記載の方法。
【請求項５】
前記送信されたデータパケットにおいて前記モバイルクライアント（１０１）に提供されたテキストサンプル書式記述についての情報を維持するステップをさらに含む、請求項１乃至請求項４のいずれかに記載の方法。
【請求項６】
前記維持される情報は、前記提供されたテキストサンプル書式記述についてのデータと、前記テキストサンプル書式記述が送信された前記少なくとも１つのデータパケットについてのデータと、前記少なくとも１つの識別子とを含む、請求項５記載の方法。
【請求項７】
送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にすでに提供されたと判断された場合に、前記テキストサンプル書式記述が前記モバイルクライアント（１０１）に送信された前記少なくとも１つの送信されたデータパケットを、前記維持されている情報に基づいて判断するステップをさらに含む、請求項１乃至請求項６のいずれかに記載の方法。
【請求項８】
前記判断された少なくとも１つのデータパケットに対して前記モバイルクライアント（１０１）によって肯定応答が返されたか否かを判断するステップと、
肯定応答が返されていた場合、前記判断された少なくとも１つのデータパケットにおいて使用された前記サンプル識別子を、前記送信するテキストサンプルを提供されたテキストサンプル書式記述にマッピングする目的で再び使用するステップと、
をさらに含む請求項７記載の方法。
【請求項９】
前記判断された少なくとも１つのデータパケットに対して前記モバイルクライアント（１０１）によって肯定応答が返されていないと判断された場合、前記送信するテキストサンプルとその関連付けられるテキストサンプル書式記述とが、前記少なくとも１つのデータパケットに追加される、請求項８記載の方法。
【請求項１０】
前記少なくとも１つのデータパケットは、ヘッダとペイロードセクションとを含み、
送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にすでに提供されたと判断された場合、データパケットの前記ヘッダは、前記再び使用される識別子を含む、
請求項８または請求項９に記載の方法。
【請求項１１】
前記少なくとも１つのデータパケットは、複数のテキストサンプルとテキストサンプル書式記述とを含む、請求項１乃至請求項１０のいずれかに記載の方法。
【請求項１２】
送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にまだ提供されていないと判断された場合、データパケットの前記ヘッダは、少なくとも１つのサンプル識別子と少なくとも１つのテキストサンプル書式記述とを含む、請求項１乃至請求項１１のいずれかに記載の方法。
【請求項１３】
送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にすでに提供されたと判断された場合、データパケットの前記ヘッダは、少なくとも１つのサンプル識別子を含む、請求項１乃至請求項１１のいずれかに記載の方法。
【請求項１４】
前記少なくとも１つのデータパケットは、ヘッダとペイロードセクションとを含む、請求項１乃至請求項１１のいずれかに記載の方法。
【請求項１５】
前記ペイロードセクションは、少なくとも１つのサンプル識別子と少なくとも１つのテキストサンプルとを含む、請求項１４記載の方法。
【請求項１６】
送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にすでに提供されたか否かを判断する前記ステップは、前記維持されている情報に基づく、請求項５乃至請求項１５のいずれかに記載の方法。
【請求項１７】
所定の数の識別子が使用されており、
送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にまだ提供されていないと判断され、かつ、利用可能な識別子のすべてが、テキストサンプルをテキストサンプル書式記述にマッピングする目的で使用されている場合に、新しいテキストサンプル書式記述と前記対応するテキストサンプルとを前記モバイルクライアント（１０１）に提供する目的でサンプル識別子が再び使用される、請求項１６記載の方法。
【請求項１８】
提供されたテキストサンプル書式記述についての前記維持されている情報は、識別子が再び使用された時点で更新される、請求項１７記載の方法。
【請求項１９】
前記維持されている情報は、送信されたデータパケットへの前記サンプル識別子の最後の挿入を示す、前記サンプル識別子それぞれのタイムスタンプをさらに含む、請求項１７または請求項１８に記載の方法。
【請求項２０】
最も早いタイムスタンプを有する前記サンプル識別子を、新しいテキストサンプル書式記述を前記モバイルクライアント（１０１）に送信する目的で再び使用するステップ、をさらに含む、請求項１９に記載の方法。
【請求項２１】
前記少なくとも１つのデータパケットは、少なくとも１つのテキストサンプル書式記述のみを含む、請求項１乃至請求項１９のいずれかに記載の方法。
【請求項２２】
関連付けられるテキストサンプル書式記述を有する少なくとも１つのテキストサンプルを含む書式設定済みテキストを、モバイル通信システム（１０２）を介してＲＴＰプロトコルを使用してモバイルクライアント（１０１）に送信するストリーミングサーバ（１００）であって、前記ストリーミングサーバ（１００）は、
少なくとも１つのデータパケットを形成するパケット形成手段と、
送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にすでに提供されたか否かを判断する処理手段と、
前記少なくとも１つのデータパケットを前記モバイルクライアント（１０１）に送信する送信手段と、を備え、
前記パケット形成手段は、送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にすでに提供されたと前記処理手段が判断した場合に、送信する前記テキストサンプルを、送信する少なくとも１つのデータパケットに追加するように構成されており、
前記パケット形成手段は、送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にまだ提供されていないと前記処理手段が判断した場合に、送信する前記テキストサンプルと、その関連付けられるテキストサンプル書式記述とを、送信する少なくとも１つのデータパケットに追加するように構成されている、ストリーミングサーバ（１００）。
【請求項２３】
請求項１乃至請求項２１のいずれかに記載の方法を実行するように構成されている、請求項２２記載のストリーミングサーバ（１００）。
【請求項２４】
モバイル通信システム（１０２）におけるモバイルクライアント（１０１）を、ストリーミングサーバ（１００）からの、関連付けられるテキストサンプル書式記述を有する少なくとも１つのテキストサンプルを含む書式設定済みテキストを、ＲＴＰプロトコルを使用して受信するように動作させる方法であって、前記方法は、
前記ストリーミングサーバ（１００）からの、少なくとも１つのテキストサンプルを含む少なくとも１つのデータパケットを受信するステップと、
前記少なくとも１つのデータパケットが、前記少なくとも１つのテキストサンプルのそれぞれに対する少なくとも１つの関連付けられるテキストサンプル書式記述をさらに含んでいるか否かを判断するステップと、
含んでいる場合、前記少なくとも１つのデータパケットに含まれている前記テキストサンプルのそれぞれの前記関連付けられるテキストサンプル書式記述を選択するステップと、
含んでいない場合、前記テキストサンプルのそれぞれのテキストサンプル書式記述を、前記モバイルクライアント（１０１）においてすでに利用可能であるテキストサンプル書式記述から選択するステップと、
前記テキストサンプルのそれぞれを、前記選択したテキストサンプル書式記述を使用して書式設定するステップと、
を含む方法。
【請求項２５】
前記少なくとも１つのデータパケットは、少なくとも１つのテキストサンプルをその関連付けられるテキストサンプル書式記述にマッピングする少なくとも１つのサンプル識別子をさらに含む、請求項２４記載の方法。
【請求項２６】
受信されたデータパケットにおいて提供された前記テキストサンプル書式記述についての情報を維持するステップをさらに含む、請求項２５記載の方法。
【請求項２７】
前記維持される情報は、前記提供された少なくとも１つのテキストサンプル書式記述についてのデータと、その少なくとも１つの識別子とを含む、請求項２６記載の方法。
【請求項２８】
テキストサンプルの前記関連付けられるテキストサンプル書式記述を選択する前記ステップは、前記テキストサンプルに関連付けられている前記サンプル識別子を使用して、前記少なくとも１つのデータパケットから、または前記モバイルクライアント（１０１）においてすでに利用可能であるテキストサンプル書式記述から、前記関連付けられるテキストサンプル書式記述を識別（および選択）する、請求項２４乃至請求項２７のいずれかに記載の方法。
【請求項２９】
前記少なくとも１つのデータパケットが、前記維持されている情報の中の別のテキストサンプル書式記述にすでに関連付けられているサンプル識別子に関連付けられている新しいテキストサンプル書式記述を含む場合に、前記維持されている情報を前記新しいテキストサンプル書式記述に基づいて更新するステップをさらに含む、請求項２４乃至請求項２８のいずれかに記載の方法。
【請求項３０】
前記少なくとも１つの受信したデータパケットに対する肯定応答を前記ストリーミングサーバ（１００）に送信するステップをさらに含む、請求項２４乃至請求項３０のいずれかに記載の方法。
【請求項３１】
前記モバイルクライアント（１０１）によって受信されるデータパケットは、少なくとも１つのテキストサンプル書式記述のみを含み、
前記方法は、前記受信した少なくとも１つのテキストサンプル書式記述を格納するステップをさらに含む、請求項２４乃至請求項３０のいずれかに記載の方法。
【請求項３２】
ストリーミングサーバ（１００）からの、関連付けられるテキストサンプル書式記述を有する少なくとも１つのテキストサンプルを含む書式設定済みテキストを、ＲＴＰプロトコルを使用して受信するモバイルクライアント（１０１）であって、前記モバイルクライアント（１０１）は、
前記ストリーミングサーバ（１００）からの、少なくとも１つのテキストサンプルを含む少なくとも１つのデータパケットを受信する受信手段と、
前記少なくとも１つのデータパケットが、前記少なくとも１つのテキストサンプルのそれぞれに対する少なくとも１つの関連付けられるテキストサンプル書式記述をさらに含んでいるか否かを判断する処理手段と、
前記テキストサンプルのそれぞれを前記選択したテキストサンプル書式記述を使用して書式設定するテキスト書式設定手段と、を備え、
前記選択手段は、前記少なくとも１つのデータパケットが前記少なくとも１つのテキストサンプルのそれぞれに対する少なくとも１つの関連付けられるテキストサンプル書式記述をさらに含んでいると判断される場合に、前記少なくとも１つのデータパケットに含まれている前記テキストサンプルのそれぞれの前記関連付けられるテキストサンプル書式記述を選択するように構成されており、
前記選択手段は、前記少なくとも１つのデータパケットが前記少なくとも１つのテキストサンプルのそれぞれに対する少なくとも１つの関連付けられるテキストサンプル書式記述を含んでいないと判断される場合に、前記テキストサンプルのそれぞれのテキストサンプル書式記述を、前記モバイルクライアント（１０１）においてすでに利用可能であるテキストサンプル書式記述から選択するように構成されている、モバイルクライアント（１０１）。
【請求項３３】
前記モバイルクライアント（１０１）は、請求項２４乃至請求項３１のいずれかに記載の方法を実行するように構成されている、請求項３２記載のモバイルクライアント（１０１）。
【請求項３４】
請求項２２乃至請求項２３のいずれかに記載の少なくとも１つのストリーミングサーバ（１００）と、請求項３２乃至請求項３３のいずれかに記載の少なくとも１つのモバイルクライアント（１０１）とを備えているストリーミングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モバイル通信システムにおいてストリーミングサーバからモバイルクライアントにＲＴＰプロトコルを使用して書式設定済みテキストを送信する方法に関する。書式設定済みテキストは、関連付けられるテキストサンプル書式記述を有する少なくとも１つのテキストサンプルを含みうる。さらに、本発明は、書式設定済みテキストを送信するストリーミングサーバと、ストリーミングされた書式設定済みテキストを受信するモバイルクライアントと、このストリーミングサーバおよびこのモバイルクライアントを備えているシステムとに関する。
【背景技術】
【０００２】
３ＧＰＰ（3rd Generation Partnership Project）では、メディアを符号化するＡＭＲ（Adaptive Multi-Rate）やＨ．２６４（MPEG 4 part 10)などの伝送およびパケット交換コーデックに、ＲＴＰ、ＵＤＰ、ＩＰなどのＩＥＴＦ（Internet Engineering Task Force)標準プロトコルを採用している。３ＧＰＰパケット交換ストリーミングサービス（非特許文献１を参照）では、音声／映像／テキストメディアをストリーミングするのにＲＴＰ／ＵＤＰプロトコルスタックを使用している。
【０００３】
ＲＴＰは、リアルタイムトランスポートプロトコル（非特許文献２を参照）であり、このプロトコルは、主としてリアルタイム通信、またはほぼリアルタイムの通信、すなわち遅延制約が柔軟な通信に使用されている。ＲＴＰは、伝送するメディアのタイミングについての情報を提供し、受信側において順序を入れ替えたり再構築することもできる。
【０００４】
ＲＴＣＰ（Real Time Control Protocol）は、このプロトコルの統合部分であり、最小限の受信情報と柔軟なグループメンバーシップとを提供する。ＲＴＰは、一般的には、ＲＴＰ／ＡＶＰプロファイル（非特許文献３）と組み合わせて使用され、このＲＴＰ／ＡＶＰプロファイルは、ＲＴＰヘッダフィールドの使用と、ペイロードタイプのマッピングテーブル、さらには単純なＲＴＣＰフィードバックタイミング規則を定義する。
【０００５】
ＵＤＰ（非特許文献４）は、ＲＴＰパケットを伝送する目的で使用されるユーザデータグラムプロトコルである。ＵＤＰは、一般に、ストリーミングアプリケーションの場合など、メディアの通信の信頼性が低くてもよいときに使用される。プロトコルスタックＲＴＰ／ＵＤＰが使用されるのは、メディアのタイミング制約によって、例えばＴＣＰ（Transmission Control Protocol）の使用による信頼性の高い通信を通常では行うことができないためである。
【０００６】
ＲＴＰでは、既存のメディア書式（コーデック）に対するパケット化方式（ペイロード書式）が、Internet Engineering Task Force Audio/Video Transport Working Group（IETF AVT WG)において指定されている。これによれば、例えば、ＡＭＲ方式で符号化される音声データ用のペイロード書式と、Ｈ．２６４映像用の別の書式とが存在する。
【０００７】
非特許文献５に定義されているペイロード書式は、会話テキストを送信する目的に使用することができるが、テキスト文字の装飾に関する追加情報を伝えることができない。この場合の装飾とは、例えば、使用されるフォント、背景色、スクロール、またはカラオケ処理などである。この書式では、例えば映像シーケンスにサブタイトルを付けるのに必要となる場合など、他のメディアとの空間的な同期を行うことができない。要約すれば、３ＧＰＰの時刻指定型テキスト（3GPP TS 26.234、特にAppendix D.8aを参照）では、他の標準コーデックではサポートされていないようなかなり広い範囲の機能が提供される。
【０００８】
非特許文献６には、ＲＴＰを使用して時刻指定型テキストを送信するためのペイロード書式が提案されている。しかしながら、このペイロード書式は、サンプル記述情報を帯域外送信する手段を提供するのみであり、サンプル記述情報の帯域内送信の問題について詳細には対処していない。Ｒｅｙらによって提案されているこのサンプル記述の帯域内送信では、各サンプル記述と、それに関連付けられるテキストサンプルとを一緒に送信する必要があり、したがって、以下に概説する問題を解決することができない。
【０００９】
本発明においては、帯域内は、信号チャネルとの関連で理解することができる。サンプル記述は、一般的には、純粋な信号情報またはメタデータを表す。テキストは、実際のデータとみなすことができる。したがって、帯域内とは、信号、すなわちサンプル記述が、データ、すなわちテキストサンプルと同じセッションにおいて送信されることを意味する。なお、テキストサンプルにはＳＰＬＤＥＳＣ、ＴＨＤＲ、あるいはＦＨＤＲヘッダは含まれず、テキスト文字列および修飾子ボックス（modifier box）（3GPP TS 26.234参照）のみが送信されることに留意されたい。したがって、帯域外信号は、データ、例えばＳＤＰを送信するのに使用するセッションまたはプロトコルとは別のセッションまたはプロトコルを使用してサンプル記述を送信することと理解することができる。
【００１０】
３ＧＰＰ時刻指定型テキストをストリーミングするときには、一般に、ストリーミングされるテキストサンプルは同一のサンプル記述エントリを参照する。所定の時間の後には、使用され得るサンプル記述すべてが少なくとも１回はすでに送信されている。送信側は受信側がどのパケットを受信したかを認識していないので、テキストサンプルは、これらのサンプル記述を繰り返し参照し、したがって、サンプル記述を送信側から受信側に何度も繰り返して送信しなければならない。さらに、3GPP TS 26.234と、Ｒｅｙらの非特許文献６に提案された方法のいずれにおいても、各テキストサンプルと、それに関連付けられるサンプル記述とを必ず一緒に送信する必要がある。したがって、従来のシステムにおいては、３ＧＰＰファイルのサンプル記述すべてを送信することによる送信オーバーヘッドが大きい。さらに、このオーバーヘッドは、特に、リソースの乏しい無線リンクを通じてモバイルクライアントにストリーミングを提供する場合には望ましくない。
【非特許文献１】「Universal Mobile Telecommunications System (UMTS) ; Transparent end-to-end streaming service ; Protocols and codecs」、3GPP TS 26.234 version 5.6.0 Release 5、２００３年９月、http://www.3gpp.orgからアクセス可能
【非特許文献２】「RTP : A Transport Protocol for Real-Time Applications」、Ｓｃｈｕｌｚｒｉｎｎｅら、RFC 3550、２００３年７月、すべてのＲＦＣはhttp://www.ietf.orgからアクセス可能
【非特許文献３】「RTP Profile for Audio and Video Conferences with Minimal Control」、Ｓｃｈｕｌｚｒｉｎｎｅら、RFC 3551、２００３年７月
【非特許文献４】Ｐｏｓｔｅｌ、「User Datagram Protocol」、RFC 768、１９８０年８月
【非特許文献５】「RTP Payload for Text Conversation」、Ｈｅｌｌｓｔｒｏｍ、RFC 2793、２０００年５月
【非特許文献６】「RTP Payload Format for 3GPP Timed Text」、Ｒｅｙら、draft-ray-avt-3gpp-tt-01. txt、IETF AVT WG、２００３年９月、http://www. ietf.orgからアクセス可能
【発明の開示】
【００１１】
（発明の概要）
したがって、本発明の目的は、ＵＭＴＳなどの無線通信システムにおいてストリーミングサーバからモバイル端末またはモバイルクライアントにストリーミングテキストを、ＲＴＰを使用して送信するときの、従来のシステムの送信オーバーヘッドを低減することである。
【００１２】
本発明のこの目的は、独立請求項の主題によって解決される。本発明の好ましい実施形態は、従属請求項の主題である。
【００１３】
本発明の第１の実施形態によると、無線通信システムにおいてストリーミングサーバからモバイルクライアントにＲＴＰプロトコルを使用して書式設定済みテキストを送信する方法が提供される。この書式設定済みテキストは、関連付けられるテキストサンプル書式記述を有する少なくとも１つのテキストサンプルを含みうる。このストリーミングサーバは、送信するテキストサンプルのテキストサンプル書式記述が、以前のテキストサンプル用にすでに提供されたか否かを判断することができる。すでに提供されている場合、送信するテキストサンプルのみを、送信する少なくとも１つのデータパケットに追加することができる。提供されていない場合、送信するテキストサンプルと、これに関連付けられるテキストサンプル書式記述とを、送信する少なくとも１つのデータパケットに追加することができる。そして、この少なくとも１つのデータパケットを、モバイルクライアントに送信することができる。
【００１４】
この実施形態によると、例えば３ＧＰＰファイルから書式設定済みテキストを作成するストリーミングサーバは、送信の前に、さまざまなテキストサンプルのテキストサンプル書式記述を分析することができる。この処理において、ストリーミングサーバは、どのサンプル記述がすでにクライアントに送信されたか、あるいは、クライアントに送信する（１つ以上の）ＲＴＰパケットにどのサンプル記述がすでに追加されたかを判断することができる。この判断プロセスに応じて、ストリーミングサーバは、テキストサンプル書式記述がすでに提供されていた場合、その記述をデータパケットに含める必要がない。したがって、重複する情報の（再）送信を防止することができ、送信オーバーヘッドを低減できる。
【００１５】
さらに、データパケットが少なくとも１つのテキストサンプル書式記述のみを含んでいることも可能であることに留意されたい。例えば、含まれている少なくとも１つのテキストサンプル書式記述によって、１つのデータパケットの最大サイズにすでに達する場合、それ以上のテキストサンプルをデータパケットに含めなくてよい。したがって、以下の段落において概説する本発明の別の実施形態は、データパケットがテキストサンプル書式記述のみを含んでいる場合にも適用することができる。
【００１６】
ストリーミングサーバが、送信するテキストサンプルのテキストサンプル書式記述を送信しなくてもよい場合は２つある。すなわち、テキストサンプル書式記述が以前のデータパケットにおいてモバイルクライアントに送信されたことによって提供済みである、または、以前のテキストサンプルの処理時にテキストサンプル書式記述が少なくとも１つのデータパケットにすでに追加されたことによって提供済みである、のいずれかである。
【００１７】
ストリーミングサーバは、送信するテキストサンプルを少なくとも１つのデータパケットに追加するときに、それら少なくとも１つのデータパケットに少なくとも１つのサンプル識別子をさらに追加することができる。このサンプル識別子は、少なくとも１つのデータパケットの中のテキストサンプル書式記述と、これに関連付けられるテキストサンプルとの間のマッピングを提供することができる。したがって、この識別子を使用することによって、各テキストサンプルをテキストサンプル書式記述に関係付けることができる。
【００１８】
本発明のさらなる実施形態によると、ストリーミングサーバは、送信されたデータパケットにおいてモバイルクライアントに提供されたテキストサンプル書式記述についての情報を維持することができる。維持される情報は、提供されたテキストサンプル書式記述についてのデータと、そのテキストサンプル書式記述が送信された少なくとも１つのデータパケットについてのデータと、少なくとも１つの識別子と、を含んでいることができる。
【００１９】
送信するテキストサンプルのテキストサンプル書式記述が、以前のテキストサンプル用にすでに提供されていると判断された場合、クライアントに送信されたどのデータパケットがそのテキストサンプル書式記述を含んでいたかを判断する必要がある。ストリーミングサーバに維持されている情報を使用することにより、該当する少なくとも１つの送信済みデータパケットを判断することができる。なぜなら、維持されている情報には、送信されたテキストサンプル書式記述についての情報と、そのテキストサンプル書式記述が送信された、または送信される１つ以上のデータパケットについての情報とを含めることができるからである。
【００２０】
ストリーミングサーバが、送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にすでに提供された、すなわち、この場合にはクライアントにすでに送信されたと判断した場合、そのテキストサンプル書式記述を含んでいた少なくとも１つのデータパケットに対してモバイルクライアントによって肯定応答が返されたか否かを調べることが望ましい。肯定応答が返されていた場合、サンプル識別子を再び使用することができる。サンプル識別子は、送信するテキストサンプルを提供されたテキストサンプル書式記述にマッピングするために、判断された少なくとも１つのデータパケットにおいて使用される。すなわち、すでに送信されたテキストサンプル書式記述に使用されたサンプル識別子を、送信するテキストサンプルに関連付けることができ、送信するテキストサンプルが含まれる少なくとも１つのデータパケットに含めることができる。
【００２１】
判断された少なくとも１つのデータパケットに対してモバイルクライアントによって肯定応答が返されていないと判断された場合、送信するテキストサンプルとその関連付けられるテキストサンプル書式記述の両方を、この少なくとも１つのデータパケットに追加することができる。なぜなら、モバイルクライアントが、以前に送信された１つ以上のデータパケットの中の必要なテキストサンプル書式記述を正常に受信したことが確実ではないからである。
【００２２】
さらに、この少なくとも１つのデータパケットは、ヘッダとペイロードセクションとを含みうる。送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にすでに提供されたと判断された場合、データパケットのヘッダに、再び使用された識別子を含めることができる。本発明のこの好ましい実施形態においては、ＲＴＰパケットのヘッダには、テキストサンプル書式記述が再び使用されることを受信クライアントに示す目的で、そのテキストサンプル書式記述に使用されているサンプル識別子を含めることができる。さらに、テキストサンプル書式記述に指定されている書式を必要とするテキストサンプルを、同じ識別子に関連付けることができる。これにより、クライアントは、そのテキストサンプルを関連付けられるテキストサンプル書式記述にマッピングすることができる。
【００２３】
さらに、少なくとも１つのデータパケットは、複数のテキストサンプルと複数のテキストサンプル書式記述とを含みうることに留意されたい。さらに、１つのデータパケットは、１つのテキストサンプル、および／または、１つのテキストサンプル書式記述もしくはその断片のみを含みうることを理解されたい。同様に、１つのデータパケットは、複数のテキストサンプル、および／または複数のテキストサンプル書式記述を含みうる。
【００２４】
送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にまだ提供されていないと判断された場合、データパケットのヘッダには、少なくとも１つのサンプル識別子と少なくとも１つのテキストサンプル書式記述とを含めることができる。
【００２５】
別の場合においては、データパケットのヘッダに、少なくとも１つのサンプル識別子を含めることができる。なぜなら、テキストサンプル書式記述が以前にクライアントに提供されていたときにはそれを省略できるためである。
【００２６】
上述したように、少なくとも１つのデータパケットは、ヘッダとペイロードセクションとを含んでいる。さらに、このペイロードセクションは、少なくとも１つのサンプル識別子と少なくとも１つのテキストサンプルとを含みうる。したがって、ペイロードセクションのサンプル識別子とテキストサンプルとを関連付けて、このサンプル識別子をテキストサンプル書式記述に対して使用することによって、クライアントはマッピングを実行してテキストサンプルを正しく書式設定することができる。
【００２７】
送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にすでに提供されたかの判断は、例えば、上述の維持されている情報に基づくことができる。
【００２８】
本発明の別の実施形態は、クライアントにおいてサンプル記述情報をキャッシュ処理する目的で、キャッシュ処理に必要なメモリサイズを制御するメモリ管理を提供する。必要なメモリのサイズを低減するため、所定の数の識別子のみが使用される。したがって、送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にまだ提供されていないと判断され、利用可能な識別子すべてがテキストサンプルをテキストサンプル書式記述にマッピングする目的に使用されている場合、新しいテキストサンプル書式記述および対応するテキストサンプルをモバイルクライアントに提供するために、サンプル識別子を再び使用することができる。
【００２９】
したがって、提供されたテキストサンプル書式記述についての維持されている情報を、識別子を再使用した時点で更新することは有利である。
【００３０】
どのサンプル識別子を再び使用すべきかを決定する目的で、維持されている情報は、送信されたデータパケットへのサンプル識別子の最後の挿入を示す各サンプル識別子のタイムスタンプをさらに含みうる。したがって、本発明の別の実施形態によると、新しいテキストサンプル書式記述をモバイルクライアントに送信する目的で、最も早いタイムスタンプを有するサンプル識別子を再び使用することができる。
【００３１】
さらに、少なくとも１つのデータパケットは、少なくとも１つのテキストサンプル書式記述のみを含みうることに留意されたい。
【００３２】
別の実施形態においては、本発明は、書式設定済みテキストを、ＲＴＰプロトコルを使用してモバイルクライアントに送信する、モバイル通信システムにおけるストリーミングサーバを提供する。書式設定済みテキストは、関連付けられるテキストサンプル書式記述を有する少なくとも１つのテキストサンプルを含みうる。このストリーミングサーバは、少なくとも１つのデータパケットを形成するパケット形成手段と、送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にすでに提供されたかを判断する処理手段と、少なくとも１つのデータパケットをモバイルクライアントに送信する送信手段と、を備えることができる。
【００３３】
上記パケット形成手段は、送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にすでに提供されたと上記処理手段が判断した場合に、送信するテキストサンプルを、送信する少なくとも１つのデータパケットに追加するように構成することができる。さらに、上記パケット形成手段は、送信するテキストサンプルのテキストサンプル書式記述が以前のテキストサンプル用にまだ提供されていないと上記処理手段が判断した場合に、送信するテキストサンプルと、その関連付けられるテキストサンプル書式記述とを、送信する少なくとも１つのデータパケットに追加するように構成することができる。
【００３４】
さらに、上記ストリーミングサーバは、上述したさまざまな実施形態による方法を実行するように構成することができる。
【００３５】
本発明のさらなる実施形態においては、モバイル通信システムにおけるモバイルクライアントを、ストリーミングサーバからの書式設定済みテキストを、ＲＴＰプロトコルを使用して受信するように動作させる方法が提供される。この場合も、書式設定済みテキストは、関連付けられるテキストサンプル書式記述を有する少なくとも１つのテキストサンプルを含みうる。モバイルクライアントは、ストリーミングサーバからの少なくとも１つのデータパケットを受信することができ、この少なくとも１つのデータパケットは、少なくとも１つのテキストサンプルを含みうる。次に、クライアントは、この少なくとも１つのデータパケットが、少なくとも１つのテキストサンプルのそれぞれに対する少なくとも１つの関連付けられるテキストサンプル書式記述をさらに含んでいるかを判断することができる。
【００３６】
含んでいる場合、クライアントは、少なくとも１つのデータパケットに含まれているテキストサンプルのそれぞれの関連付けられるテキストサンプル書式記述を、データパケットから直接的に選択することができる。含んでいない場合、必要なサンプル記述はクライアントに以前にすでに提供されていると想定されている、またはそのことがクライアントに示されるので、テキストサンプルのそれぞれのテキストサンプル書式記述を、モバイルクライアントにおいてすでに利用可能であるテキストサンプル書式記述から選択することができる。適切な書式、すなわちテキストサンプル書式記述を選択した時点で、テキストサンプルのそれぞれを、選択したテキストサンプル書式記述を使用して書式設定することができる。
【００３７】
さらなる実施形態によると、少なくとも１つのデータパケットは、少なくとも１つのテキストサンプルをその関連付けられるテキストサンプル書式記述にマッピングする少なくとも１つのサンプル識別子をさらに含んでいる。
【００３８】
テキストサンプルと（以前に受信した）テキストサンプル書式記述との適切なマッピングを提供できるようにする目的で、クライアントは、受信したデータパケットにおいて提供されたテキストサンプル書式記述についての情報を維持することができる。したがって、維持される情報は、提供された少なくとも１つのテキストサンプル書式記述についてのデータと、テキストサンプルへのマッピングを実行できるようにする少なくとも１つのサンプル識別子とを含みうる。
【００３９】
テキストサンプルに関連付けられるテキストサンプル書式記述を選択するときには、テキストサンプルに関連付けられているサンプル識別子を使用して、少なくとも１つのデータパケットの中の関連付けられるテキストサンプル書式記述、またはモバイルクライアントにおいてすでに利用可能である関連付けられるテキストサンプル書式記述、を識別することができる。
【００４０】
クライアントが、維持されている情報の中の別のテキストサンプル書式記述にすでに関連付けられているサンプル識別子に関連付けられる新しいテキストサンプル書式記述を受信する場合、この維持されている情報は、新しいテキストサンプル書式記述に基づいて更新されうる。
【００４１】
テキストサンプル書式記述がモバイルクライアントによって正常に受信されたかをストリーミングサーバが判断できるようにする目的で、モバイルクライアントは、少なくとも１つの受信したデータパケットに対して肯定応答を返すことができる。
【００４２】
さらに、モバイルクライアントによって受信されるデータパケットは、少なくとも１つのテキストサンプル書式記述のみを含んでいることができ、モバイルクライアントは、受信した少なくとも１つのテキストサンプル書式記述を格納することができる。したがって、サンプル記述のみを含んでいるパケットを送受信して、関連付けられるテキストサンプルを書式設定するときにあとから使用する目的でサンプル記述を格納しておくことも可能である。
【００４３】
本発明の別の実施形態は、ストリーミングサーバからの書式設定済みテキストを、ＲＴＰプロトコルを使用して受信するモバイルクライアントに関する。このモバイルクライアントは、ストリーミングサーバからの少なくとも１つのテキストサンプルを含む少なくとも１つのデータパケットを受信する受信手段と、少なくとも１つのデータパケットが少なくとも１つのテキストサンプルのそれぞれに対する少なくとも１つの関連付けられるテキストサンプル書式記述をさらに含んでいるか否かを判断する処理手段と、それぞれのテキストサンプルを選択したテキストサンプル書式記述を使用して書式設定するテキスト書式設定手段と、を備えている。
【００４４】
選択手段は、少なくとも１つのデータパケットが少なくとも１つのテキストサンプルのそれぞれに対する少なくとも１つの関連付けられるテキストサンプル書式記述をさらに含んでいると判断される場合に、少なくとも１つのデータパケットに含まれているテキストサンプルのそれぞれに関連付けられるテキストサンプル書式記述を選択するように構成することができる。さらに、この選択手段は、少なくとも１つのデータパケットが少なくとも１つのテキストサンプルのそれぞれに対する少なくとも１つの関連付けられるテキストサンプル書式記述を含んでいないと判断される場合に、テキストサンプルのそれぞれのテキストサンプル書式記述を、モバイルクライアントにおいてすでに利用可能であるテキストサンプル書式記述から選択するように構成することができる。
【００４５】
さらに、このモバイルクライアントは、上述した方法のさまざまな実施形態を実行するように構成することができる。
【００４６】
さらなる実施形態によると、本発明は、少なくとも１つのストリーミングサーバと少なくとも１つのモバイルクライアントとを備えているストリーミングシステムを提供する。
【００４７】
以下では、本発明について添付の図面を参照しながら詳しく説明する。図面における類似する部分および対応する部分は、同じ参照数字によって表してある。
【００４８】
（詳細な説明）
以下では、主として３ＧＰＰ時刻指定型テキストストリーミングに関連して説明しているが、本発明の基礎をなす原理は、テキストおよびその書式記述がストリーミングされるモバイル通信システムにおける別のテキストストリーミングシステムにも、容易に適用できることに留意されたい。
【００４９】
図１は、本発明の実施形態によるシステムの構成の概観を示している。ストリーミングサーバ１００は、ストリーミングされる書式設定済みテキストをモバイルクライアント１０１に提供する。図示した好ましい構成においては、ストリーミングデータは、ＵＭＴＳ１０２などの無線ネットワークに入る前に、インターネットを経由して、すなわちＩＰベースのネットワーク（インターネット）を介して渡される。図示した例においては、ＧＧＳＮ（Gateway GPRS Support Node）１０５は、ＵＭＴＳコアネットワーク（ＣＮ）１０３をインターネットに接続するゲートウェイを表している。データは、（Serving GPRS Support Node（ＳＧＳＮ）１０６を介して）ＣＮ１０３を経由し、アクセスネットワーク、この場合にはＵＴＲＡＮ１０４を経由し、エアインタフェースを介してモバイルクライアント１０１に渡される。図における点線は、ストリーミングデータが、ＣＮ１０３とＵＴＲＡＮ１０４とを経由してモバイルクライアント１０１に配信される経路を示している。なお、本発明は、図１に示した実施形態には制限されないことに留意されたい。ストリーミングサーバは、例えば、ＵＭＴＳネットワーク１０２の中に位置していることもでき、データは必ずしもＩＰベースのネットワークを介して配信する必要はなく、あるいは、ＵＭＴＳ以外のモバイル通信システムを使用することもできる。
【００５０】
本発明の１つの態様によると、ストリーミングサーバ１００は、送信されたパケットと、各ＲＴＰパケットにおいて送信されたサンプル記述情報エントリの何らかのレコードのリスト（例：各パケットにおいて送信されたＳＩＤＸ値のリスト）を維持することができる。維持されるこの情報が利用可能であるとき、ストリーミングサーバ１００は、現在送信のための処理が行われているテキストサンプルのサンプル記述と、送信されたデータパケットに含まれていたサンプル記述とを比較することができる。クライアントは、サンプル書式記述の再送信を回避するために、データパケットに関するフィードバックをサーバに提供することができる。さらに、クライアントは、受信したサンプル記述エントリのリストを調べて、それらの対応するサンプル記述値を格納することができる。この受信したサンプルエントリのレコードは、ストリーミングセッションの持続時間に等しい最小限の寿命を持つことができる。
【００５１】
次の表は、サンプル識別子ＳＩＤＸと、サンプル記述と、サンプル記述を送信する、またはすでに送信されたデータパケットとの間の関連付けを判断する目的で、ストリーミングサーバ１００によって維持されるリストまたは情報の例を示している。
【００５２】
【表１】
2007520914.tif 000003
【００５３】
ストリーミングサーバ１００によって集められる、提供されるサンプル記述についての情報は、サンプル記述と、サンプル記述がモバイルクライアント１０１にすでに送信された、または送信されるＲＴＰパケットとを含みうる。さらに、この情報は、サンプル記述とテキストサンプルとの間のマッピングを容易にするサンプル識別子をさらに含みうる。さらに、本発明の別の実施形態においては、維持される情報は、サンプル記述を伝えるＲＴＰパケットのすべてが送信された（ＴＸ）か、あるいは、それらＲＴＰパケットが送信待ち状態である、すなわち現在送信のための準備が行われているかを、さらに示すことができる。さらに、サンプル記述が送信されたデータパケットの肯定応答ステータス（ＡＣＫ）も示すことができる。
【００５４】
上の表に示した例は、例えば、サンプル記述ＳＰＬＡＴＴＲ＃１にはサンプル識別子ＳＩＤＸ＃１が関連付けられていることを示している。さらに、このサンプル記述は、例えばシーケンス番号ＳＮ＃１によって識別される１つのＲＴＰパケットにおいてクライアントに送信されている。肯定応答ステータスによると、データパケットＳＮ＃１は、すでに送信され、クライアントによって正常に受信されている。したがって、ストリーミングサーバ１００によって送信される新しいテキストサンプルのサンプル記述のうち、ＳＰＬＡＴＴＲ＃１と同じサンプル記述は、サーバによりもう一度送信される必要がない。
【００５５】
次のサンプル記述ＳＰＬＡＴＴＲ＃２およびＳＰＬＡＴＴＲ＃３を例にとって考えると、これらは１つのＲＴＰデータパケット（ＳＮ＃２）において送信されている。さらに、このデータパケットもすでに送信され、クライアントによって肯定応答が返されている。この例は、１つのＲＴＰデータパケットにおいて複数のサンプル記述を送信することもできることを示している。
【００５６】
次に、サンプル記述ＳＰＬＡＴＴＲ＃４は、１つのデータパケット（ＳＮ＃３）において送信されたが、このパケットに対してクライアントによってまだ肯定応答が返されていない。送信する新しいテキストサンプル用に、ＳＰＬＡＴＴＲ＃４と等しいサンプル記述を提供する場合、ストリーミングサーバ１００は、そのサンプル記述をもう一度（再）送信することができる。なぜなら、このサンプル記述がクライアントに送信されたデータパケットに対して肯定応答が返されていないからである。
【００５７】
これに代えて、本発明の別の実施形態によると、すべてのパケットがクライアントによって正常に受信される、すなわち、ＳＮ＃３によって識別されるＲＴＰパケットも正常に受信されると想定するならば、ストリーミングサーバ１００は、このサンプル記述をもう一度再送信しなくてもよい。しかしながら、インターネットなどのパケット交換網においてデータストリームを配信するときには、データパケットは、必ずしもサーバによって送信された順序でクライアントに到着しないことに留意されたい。したがって、この実施形態においては、あるサンプル記述が、そのサンプル記述を使用するテキストサンプルより前に送信されても、理論上では、そのテキストサンプルよりも後に受信クライアントに到着することがある。
【００５８】
サンプル記述ＳＰＬＡＴＴＲ＃５について考えると、上の表は、このサンプル記述は２つのデータパケットＳＮ＃３およびＳＮ＃４に分割されて送信されたことを示している。これらＲＴＰパケットはいずれも送信済みであるが、少なくともパケットＳＮ＃３に対して肯定応答が返されていないため、サーバはこのサンプル記述が利用可能であるとみなすことができない。
【００５９】
さらに、サンプル記述ＳＰＬＡＴＴＲ＃Ｘについて考えると、この記述はサンプル識別子ＳＩＤＸ＃Ｘによって識別されていることに留意されたい。さらに、このサンプル記述が含まれているデータパケットＳＮ＃Ｙは、現在送信待ちである（ＰＥＮＤＩＮＧ）。したがって、このＲＴＰパケットは、サーバによって送信待ち行列に加えられたパケットであるか、あるいは、現在ストリーミングサーバ１００によって作成中のＲＴＰパケット、すなわち現在情報を書き込み中のデータパケットである。
【００６０】
データパケットＳＮ＃Ｙがすでに構築されたが依然として送信待ちである場合、ストリーミングサーバ１００が行うことのできる処理は２つある。すなわち、データパケットＳＮ＃Ｙが正常に受信されるものと想定して、同じサンプル記述を使用する新しいテキストサンプルについては、そのサンプル記述の送信を省略するか、あるいは、記述ＳＰＬＡＴＴＲ＃Ｘがテキストサンプルに再び使用されるとき、新しいＲＴＰパケットにそのサンプル記述をもう一度追加することができる。サンプル記述ＳＰＬＡＴＴＲ＃Ｘが、送信しようとしている新しいサンプル記述と同じＲＴＰパケットに含まれているならば、新しいテキストサンプルについてはそのサンプル記述の（再）送信を省略することができる。
【００６１】
モバイルクライアント１０１は、受信したテキストサンプルを正しく書式設定する目的で、上の表の最初の２つの列のデータを含んでいる類似するリストを維持することができる。サンプル識別子および関連付けられるサンプル記述についての情報を維持することによって、クライアントは、受信したテキストサンプルと適切なサンプル記述とのマッピングを行うことができる。このことが可能であるのは、ＲＴＰパケットのペイロードにおいて受信される各テキストサンプルに、受信されるテキストサンプルを関連付けられるサンプル記述にマッピングするサンプル識別子を含めることができるからである。
【００６２】
本発明のさらなる実施形態によると、ストリーミングサーバ１００と受信クライアントとの両方は、例えば、いずれもhttp://www.ietf.orgからアクセス可能なＯｔｔらの「Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)」（draft-ietf-avt-rtcp-feedback-07. txt, IETF AVT WG、２００３年６月）、あるいは、Ｆｒｉｅｄｍａｎらの「RTP Control Protocol Extended Reports」（draft-ietf-avt-rtcp-report-extns-06. txt, IETF AVT WG、２００３年５月）に記載されているような、高度なフィードバック機能を実装することができる。特に、Ｆｒｉｅｄｍａｎの草案の第４．１節における消失ＲＬＥレポートブロック（Loss RLE Report Block）と、Ｏｔｔの草案のACK/NACKメッセーシ゛(ACK/NACK Messages)は、データパケットの消失および受信の正確なトレース、すなわちどのデータパケットが受信された、または消失したかをサーバに知らせる目的に使用することができる。一般的なＲＴＰプロトコルに対するこれらの「拡張機能」を使用することによって、個々のパケットに対して肯定応答を返すことができる。これにより、肯定応答を受信したサーバは、上述したようなサーバによって維持されるリストを使用して、クライアントに送信されたサンプル記述（テキストサンプル書式記述）を追跡することができる。
【００６３】
したがって、クライアントにおいて正常に受信されたデータパケットについてのフィードバックが提供される場合、ストリーミングサーバ１００は、新しいＲＴＰパケットにおける冗長な情報を抑制することができる。ストリーミングサーバ１００は、サンプル記述情報をＲＴＰパケットに含める前に、そのサンプル記述が以前のＲＴＰパケットにおいて送信されたか、または、ストリーミングサーバ１００が送信しようとしているＲＴＰパケットにすでに追加されたかを調べることができる。以前のＲＴＰパケットにおいて送信されたサンプル記述がクライアントによってすでに受信されたことを確認する目的で、ストリーミングサーバ１００は、そのようなエントリを伝えるＲＴＰパケットに対してクライアントによって肯定応答が返されたかをさらに調べることができる。肯定応答が返されていた場合、そのエントリを新しいＲＴＰパケットに含めることは冗長であるので、これを回避することができる。肯定応答が返されていない場合、Ｒｅｙらによる草案「RTP Payload Format for 3GPP Timed Text」に提案されているように、サンプル記述情報エントリを含めることができる。
【００６４】
以下では、ＲＴＰの新しいペイロードヘッダにおいてテキストサンプル書式記述を送信するための好ましい書式について、図２を参照しながら説明する。図２は、本発明の実施形態による、ＲＴＰのＳＰＬＤＥＳＣ（ＳａｍＰＬｅＤＥＳＣｒｉｐｔｉｏｎ）ペイロードヘッダを示している。このヘッダは、最初のエントリカウント（ｅｎｔｒｙ  ｃｏｕｎｔ）フィールドの後ろに、サンプル識別子ＳＩＤＸおよびサンプル属性ＳＰＬＡＴＴＲの複数の対が続いている。したがって、このヘッダを使用して、テキストサンプルのテキストサンプル書式記述を受信クライアントに送信することができる。このヘッダを含んでいるＲＴＰパケットのペイロードセクションは、オプションとして少なくとも１つのテキストサンプルを含みうる。このテキストサンプルには、サンプル識別子ＳＩＤＸとして、そのＳＩＤＸを有する特定のサンプル記述にこのテキストサンプルをマッピングするサンプル識別子ＳＩＤＸを関連付けることができる。
【００６５】
エントリカウント（ｅｎｔｒｙ  ｃｏｕｎｔ）は、ヘッダ内のエントリの数を示す最初のビット列とすることができる。図示した例においては、ヘッダに２つ（０ｘ０２）のエントリを含めることができる（図３参照）。エントリは、ＳＩＤＸフィールドとＳＰＬＡＴＴＲフィールドとを含んだ対として定義することができる。これらのエントリは、クライアントに送信される特定のテキストサンプルに対応させることができる。
【００６６】
ＳＩＤＸは、ＳＰＬＡＴＴＲフィールド内のサンプル属性を１つ以上のテキストサンプルにマッピングするために使用されるサンプル記述インデックスまたはサンプル識別子を表す。このＳＰＬＡＴＴＲフィールドは、ＳＰＬＤＥＳＣヘッダにおいて送信されるサンプル記述属性を含みうる。このフィールドは、例えば3GPP TS 26.234のAnnex D. 8a. 16のサンプルエントリ「ｔｘ３ｇ」に示されているような、テキストサンプルのデフォルト属性を含みうる。このフィールドの長さは可変とすることができる。
【００６７】
さらに、このフィールドは、１ビットのフラグ群を持つ最初のバイトを含みうる。各フラグは、対応するフィールドが以降のビットに存在するかを示す。すべてのフラグがセットされたＳＰＬＡＴＴＲフィールドの一例を、図３に実例として示す。Ｒ（１ビット）は、予約ビットを示し、Ｄ（１ビット）がｄｉｓｐｌａｙＦｌａｇｓフラグ、Ｈ（１ビット）が水平整列（ｈｏｒｉｚｏｎｔａｌ  ｊｕｓｔｉｆｉｃａｔｉｏｎ）フラグ、Ｖ（１ビット）が垂直整列（ｖｅｒｔｉｃａｌ  ｊｕｓｔｉｆｉｃａｔｉｏｎ）フラグ、Ｂ（１ビット）がＲＧＢＡ背景色（ｂａｃｋｇｒｏｕｎｄ  ｃｏｌｏｒ）フラグ、Ｔ（１ビット）がデフォルトテキストボックス（ｄｅｆａｕｌｔ  ｔｅｘｔ  ｂｏｘ）フラグ、Ｓ（１ビット）がデフォルトスタイル（ｄｅｆａｕｌｔ  ｓｔｙｌｅ）フラグ、Ｆ（１ビット）がフォントテーブル（ｆｏｎｔ  ｔａｂｌｅ）フラグをそれぞれ示している。
【００６８】
「ｄｉｓｐｌａｙＦｌａｇｓ（表示フラグ）」フィールド（例えば１６ビット）の値は、テキストの表示オプションとして、スクロールイン／アウト、スクロール方向、カラオケテキストまたは垂直テキストを示すことができる。Ｈ（Ｖ）ビットが設定されている場合、ＳＰＬＡＴＴＲフィールドの中に水平（垂直）整列フィールド（８ビット）が存在する。さらに、Ｂビットが設定されている場合に、例えば４つのオクテット（３２ビット）がＲＧＢＡ背景色を示すことができる。これらのオクテットの順序は、赤、緑、青、アルファ（透明）とすることができる。
【００６９】
Ｔビットが設定されている場合、デフォルトテキストボックスフィールド（例えば６４ビット）が存在する。このフィールドには、テキスト領域の原点に対するピクセル単位のテキストボックスの位置を定義する４つの１６ビット値（上、左、下、右）を含めることができる。フィールドに設定されたＳビットは、デフォルトスタイルボックスフィールドの存在を示す。どのフィールドが存在しているかを示すため、フラグの追加のバイト（前出の図を参照）を使用することができる。
【００７０】
Ｆビットが設定されている場合、フォントテーブル（サイズは可変、この例においては１０バイト）が存在する。このフォントテーブルには、エントリカウントフィールド（１６ビット）と、その後ろの複数のフォントエントリとを含めることができる。フォントエントリには、フォントテーブルからのフォント識別子であるフォントＩＤ（１６ビット）と、フォント名の長さをバイト単位で示すフォント名長さ（８ビット）と、例えば８ビットのＵＴＦ−８文字列として表されたフォント名とを含めることができる。この文字列は、代替フォントとして使用するフォント名を優先順にコンマで区切ったリストとすることができる。
【００７１】
３ＧＰＰ時刻指定型テキストセッションに関して前述したように、一般的に、ストリーミングサーバ１００は、クライアントによって受信されたパケットを認識していない。しかしながら、上述した追加のフィードバック機能をクライアントが実装しているならば、これは当てはまらない。これらの高度なフィードバック機能により、クライアントは、受信したすべてのパケットについてサーバに知らせることができる。この情報と、サーバが維持している、各パケットにおいて送信したＳＩＤＸ値のリストとによって、受信したパケットを受信したＳＩＤＸにマッピングすることが可能である。これにより、サーバは、まだ受信されていないサンプル記述のみを新しいデータパケットに含めることができる。したがって、テキストサンプル書式記述を送信するときのオーバーヘッドを大幅に低減することができる。受信側クライアントがサンプル書式の属性をすでに受信したことをそのクライアントに示す目的で、サンプル記述（またはＳＩＤＸ値）について、ＳＰＬＤＥＳＣペイロードヘッダのＳＰＬＡＴＴＲフィールド内のフラグバイトをすべてゼロに設定することができる。書式の設定の例を図４に示す。説明を分かり易くするため、ＳＩＤＸフィールド長さとエントリカウントフィールドのサイズとして８ビットを使用していることに留意されたい。
【００７２】
このエントリカウントフィールドは、２つのエントリ、すなわち２つのＳＩＤＸ−ＳＰＬＡＴＴＲフィールド対がヘッダに含まれていることを示す。ＳＩＤＸ＃１フィールドは、すでに受信されたかまたはデフォルトと相違しない、サンプル識別子０ｘ０１を持つサンプル記述に関連している。このことは、ＳＰＬＡＴＴＲフィールドを所定のビット組合せに設定する、例えば、このフィールドのすべてのビットを０に設定する（ＳＰＬＡＴＴＲ＃１＝０ｘ００）ことによって示されている。ＳＩＤＸ＃２フィールドは、例えば、水平整列値および垂直整列値がデフォルトとは異なる、インデックス値０ｘ０２を持つサンプル記述を識別している（ＳＰＬＡＴＴＲ＃１＝０ｘ１８＝００１１００００２）。その後ろの２つのオクテット（０ｘ００，０ｘ００）は０に設定されており、左上整列を示している（図３も参照）。
【００７３】
さらに、テキストサンプル記述を帯域内送信する場合、以下の規則、すなわちＲＴＰペイロードのテキストサンプルの中に存在するＳＩＤＸ値は同じパケットのＳＰＬＤＥＳＣヘッダに含めることができる、という規則を、フィールドの符号化に適用することができる。したがって、この場合、ＲＴＰパケットには、テキスト書式属性のみならず、それらの属性が属しているテキストサンプルも含まれる。なお、ペイロードの中の２つ以上のテキストサンプルをヘッダ内のＳＩＤＸ値に関連付けることもできることに留意されたい。テキストサンプルの対応する書式、すなわちＳＰＬＡＴＴＲフィールドの内容は、クライアントが該当するＳＩＤＸに対するＳＰＬＡＴＴＲ内容を格納していない限りは存在することができる。格納している場合、ＳＩＤＸとＳＰＬＡＴＴＲの両方を省略することができる。なぜなら、拡張フィードバックを使用することによって、ストリーミングサーバ１００は、どのＲＴＰパケットがクライアントによって受信されたか、またこれによりどのテキストサンプル書式記述がモバイルクライアント１０１において利用可能であるかを判断することができるからである。
【００７４】
ＲＴＰパケットのＳＰＬＤＥＳＣヘッダ内に存在するすべてのＳＩＤＸ値は、ペイロード内の少なくとも１つのテキストサンプルの中に存在することができる。
【００７５】
さらに、ＲＴＰパケットは、テキストサンプルなしにサンプル記述のみを伝えることができる。図５は、その場合に上と同じ値を使用するときのＳＰＬＤＥＳＣヘッダの下位互換性の構造を示している。
【００７６】
エントリカウントは、図示したように７ビットを含んでいることができる。新しいＦビットは、ＲＴＰパケットがサンプル記述情報のみを伝え、それに続くテキストサンプルがない場合、１に設定することができる。このエントリカウントは、ビットＦが０に設定される場合には図３に示したものと同じとなるので、ＲＴＰパケットは、上記の規則に従って、サンプル記述およびそれに関連付けられるテキストサンプルの両方を含みうる。
【００７７】
既存のサンプル記述送信メカニズムのこのような最適化は、スリーミングクライアントがすでに保持しており再び送信する必要がないという情報をストリーミングサーバ１００に知らせることによって、ＲＴＰパケット送信のオーバーヘッドを低減する可能性を提供する。
【００７８】
また、この最適化では、関連付けられるテキストサンプルを含める必要なしに、サンプル記述情報のみを送信することができる。これにより、さらに、サーバは、Ｒｏｓｅｎｂｅｒｇらの「An RTP Payload Format for Generic Forward Error Correction」、RFC 2733、１９９９年１２月に記載されている反復方式あるいは前方誤り訂正手法を使用して、そのような重要な情報の受信を特に保護する、あるいは確実に受信されるようにすることができる。
【００７９】
本発明のさらなる態様によると、所定の数のサンプル識別子のみを使用することができる。これにより、モバイルクライアント１０１におけるサンプル記述用のバッファのサイズを大幅に低減することができる。このことは、例えば、ストリーミングテキストにおいてさまざまな種類のテキストサンプル書式記述が使用されている場合に関連を有する。そのような場合、クライアントは、上述した方法を使用するときにはサンプル記述のすべてを格納しなければならない。送信オーバーヘッドの低減と、サンプル記述の格納に必要なメモリの増大との間でバランスをとるために、利用可能なＳＩＤＸ値の数を制限することによって、クライアントにおけるサンプル記述に必要なストレージ容量を制限することが考えられる。
【００８０】
本発明のさらなる実施形態によると、ストリーミングサーバ１００は、サンプル記述を関連付けられるテキストサンプルにマッピングするためのサンプル識別子として、所定の数のみの識別子を使用することができる。いま、Ｎ個のサンプル識別子が利用可能であるとすると、ストリーミングサーバ１００は、Ｎ＋１番目のサンプル記述に関連付けられる新しいテキストサンプルを処理するときにサンプル識別子のいずれかを再び使用する必要がある。この場合、ストリーミングサーバ１００は、再び使用するサンプル識別子を選択するのにさまざまな方式を使用することができる。最も単純な方式は、利用可能なサンプル識別子を循環的に再使用することであろう。例えば、サンプル識別子ＳＩＤＸ＃１〜ＳＩＤＸ＃Ｎを使用している場合、利用可能な識別子すべてがサンプル記述に関連付けられた時点で、サンプル記述子ＳＩＤＸ＃１のサンプル記述を上書きする、すなわち再び使用することができる。
【００８１】
これに代えて、ストリーミングサーバ１００は、サンプル記述、すなわちサンプル識別子の最後の使用についての情報を維持することができ、例えば、長期間にわたり使用されていないサンプル識別子を再び使用することができる。したがって、ストリーミングサーバ１００は、以下に示すような情報のリストを維持することができる。
【００８２】
【表２】
2007520914.tif 000004
【００８３】
上の表は、大部分は前のセクションにおいて示した表に一致している。したがって、対応する要素の説明については省略する。上の例において、Ｘは所定の値である。
【００８４】
この表には、テキストサンプルの最後の使用をタイムスタンプによって示す列が追加されている。いま、リストにおいてＴＳ＃２が最も早いタイムスタンプであるとすると、ストリーミングサーバ１００は、利用可能な「空の」ＳＩＤＸ識別子が他にない場合、新しいサンプル記述に対してＳＩＤＸ＃２を再び使用することができ、ＳＰＬＡＴＴＲ＃２フィールドをその新しいサンプル記述によって更新することができる。
【００８５】
サンプル識別子の再使用は、例えば、単純に、すでに使用されているＳＩＤＸ識別子を使用して新しいサンプル記述を送信する、すなわちサンプル識別子を新しい記述に関連付けることによって、実現することができる。再び使用するサンプル識別子の選択基準として、再び使用するサンプル識別子に関連付けられており、その識別子の再使用の前に送信されたテキストサンプルを、クライアントが「古い」サンプル記述を使用して書式設定する必要があるかがさらに考えられる。したがって、上述したタイムスタンプ基準は、これらの状況の良好な測度として使用することができる。
【００８６】
さらに、クライアントはサンプル識別子の再使用基準を認識している必要がないことに留意されたい。クライアントがサンプル記述および関連付けられる識別子を受信した時点で、クライアントに維持されている情報をただちに更新する、すなわち、そのサンプル識別子がすでに使用されているか否かに関係なく、識別子および対応するサンプル記述を格納することができる。
【図面の簡単な説明】
【００８７】
【図１】本発明の１つの実施形態によるストリーミングシステムの構成の概観を示す図
【図２】本発明の１つの実施形態によるＲＴＰペイロードヘッダの書式を示す図
【図３】本発明の１つの実施形態による図２に示したペイロードヘッダのサンプル記述フィールドを示す図
【図４】本発明の１つの実施形態による再使用されるテキストサンプル書式記述とヘッダに含まれているテキストサンプル書式記述とを有する図２のＲＴＰペイロードヘッダの書式を示す図
【図５】本発明の１つの実施形態による、図３に示したＲＴＰペイロードヘッダの書式の強化バージョンを示す図
【図１】
2007520914.tif 000005
【図２】
2007520914.tif 000006
【図３】
2007520914.tif 000007
【図４】
2007520914.tif 000008
【図５】
2007520914.tif 000009
【国際調査報告】
2007520914.tif 000010
2007520914.tif 000011