JP2010507967A - リッチ・メディア・ストリームの管理 - Google Patents

リッチ・メディア・ストリームの管理 Download PDF

Info

Publication number
JP2010507967A
JP2010507967A JP2009534537A JP2009534537A JP2010507967A JP 2010507967 A JP2010507967 A JP 2010507967A JP 2009534537 A JP2009534537 A JP 2009534537A JP 2009534537 A JP2009534537 A JP 2009534537A JP 2010507967 A JP2010507967 A JP 2010507967A
Authority
JP
Japan
Prior art keywords
scene
rich media
random access
access data
packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2009534537A
Other languages
English (en)
Other versions
JP5237292B2 (ja
Inventor
クリントン プリドル，
ペル フレジディ，
Original Assignee
テレフオンアクチーボラゲット エル エム エリクソン（パブル）
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エル エム エリクソン（パブル） filed Critical テレフオンアクチーボラゲット エル エム エリクソン（パブル）
Publication of JP2010507967A publication Critical patent/JP2010507967A/ja
Application granted granted Critical
Publication of JP5237292B2 publication Critical patent/JP5237292B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/015—High-definition television systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234318—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into objects, e.g. MPEG-4 objects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/431—Generation of visual interfaces for content selection or interaction; Content or additional data rendering
    • H04N21/4312—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations
    • H04N21/4316—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations for displaying supplemental content in a region of the screen, e.g. an advertisement in a separate window
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44012—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving rendering scenes according to scene graphs, e.g. MPEG-4 scene graphs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/4425—Monitoring of client processing errors or hardware failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47205—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for manipulating displayed content, e.g. interacting with MPEG-4 objects, editing locally
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/08—Systems for the simultaneous or sequential transmission of more than one television signal, e.g. additional information signals, the signals occupying wholly or partially the same frequency band, e.g. by time division

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Marketing (AREA)
  • General Engineering & Computer Science (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)

Abstract

本発明は一次ストリーム（１０）またはリッチ・メディア・パケット（１１、１２、１３）により表現できるシーン（３０）の一部分（３４）のシーン状態を定義するリッチ・メディア・パケット（２１、２２、２３）の二次ストリーム（２０）を供給する。処理する場合シーン部分（３２、３６）のシーン状態に影響を及ぼすことなくシーンの一部分（３４）の開始状態の作成を可能にする命令を定義するローカル・ランダム・アクセス・データを供給する。ローカル・ランダム・アクセス・データを少なくとも１つのリッチ・メディア・パケット（２１、２３）に詰め、パケット（２１、２３）を二次ストリーム（２０）に挿入し、少なくとも１つのユーザ端末（３００）に送信する。ローカル・ランダム・アクセス・データは端末（３００）により使用し、二次ストリーム（２０）に同調するおよび／または二次ストリーム（２０）に関する誤りを回復することができる。

Description

本発明は広くリッチメディアの管理に関し、特にリッチ・メディア・パケットの一次ストリームに関連する二次ストリームにおけるランダム・アクセス・ポイントの生成および使用に関する。
スケーラブル・ベクトル・グラフィックス（ＳＶＧ、Ｓｃａｌａｂｌｅ Ｖｅｃｔｏｒ
Ｇｒａｐｈｉｃｓ）は静的および動的ベクトルグラフィックスを表現する拡張可能言語（ＸＭＬ、Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）に基づく言語である。ＳＶＧはベクトルベースであり、これはコンテンツをあるスクリーン解像度に対して作成するのではなく、容易に尺度を変えることができることを意味する。ＳＶＣはワールド・ワイド・ウェブ・コンソーシアム（Ｗ３Ｃ、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）により標準化される。ＳＶＧバージョン１．１のモバイル用プロファイルは３ＧＰＰリリース５が採択しており、今日おおよそ一億の携帯ハンドセットがサポートしている。
ＳＶＧ Ｔｉｎｙ１．２［１］は特に携帯デバイスおよび端末向けに設計されたＳＶＧのより強力なバージョンである。これは現在Ｗ３Ｃ勧告候補であり、３ＧＰＰレリース６が採択している。マイクロ・ドキュメント・オブジェクト・モデル（μＤＯＭ、ｍｉｃｒｏ Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）および記述と共にオーディオおよびビデオの完全制御を含む多様な新規マルチメディアの特徴のサポートを含む。
ベクトルグラフィックスのメディアタイプであることに加えて、ＳＶＧはまたシーン(scene)記述言語としても使用することができ、ここでシーンは時間的ならびに空間的に構成することができる。実際、動的および相互作用的マルチメディアシーン（ＤＩＭＳ、Ｄｙｎａｍｉｃ ａｎｄ Ｉｎｔｅｒａｃｔｉｖｅ Ｍｕｌｔｉｍｅｄｉａ Ｓｃｅｎｅｓ）に関する３ＧＰＰ作業項目ならびにリッチ−メディア環境（ＲＭＥ、Ｒｉｃｈ Ｍｅｄｉａ Ｅｎｖｉｒｏｎｍｅｎｔ）に関するオープンモバイルアライアンス（ＯＭＡ、Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）作業項目の提示フォーマットとして、ＳＶＧ Ｔｉｎｙ１．２を採択している。ＤＩＭＳ標準化は３ＧＰＰリリース７において終了しており、ここでＯＭＡはＲＭＥの仕上げに関してなお作業している。ＤＩＭＳ（およびＲＭＥも）に対する主要な競合提案は、Ｗ３ＣおよびＭＰＥＧで標準化された軽量アプリケーションシーン表現（ＬＡＳｅＲ、Ｌｉｇｈｔｗｅｉｇｈｔ Ａｐｐｌｉｃａｔｉｏｎ Ｓｃｅｎｅ Ｒｅｐｒｅｓｅｎｎｔａｔｉｏｎ）［３］の技術で構築するモバイル・オープン・リッチ・メディア環境（ＭＯＲＥ、Ｍｏｂｉｌｅ Ｏｐｅｎ Ｒｉｃｈ ｍｅｄｉａ Ｅｎｖｉｒｏｎｍｅｎｎｔ）［２］であった。両者は基盤としてＳＶＧ Ｔｉｎｙ１．２を使用する。
純粋なＳＶＧコンテンツとは対照的に、ＤＩＭＳ（ＲＭＥ）コンテンツは、実時間伝送プロトコル（ＲＴＰ、Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）［４］を使用してストリーム化することができる。レンダリングしたＳＶＧドキュメントをＳＶＧシーンと呼び、通常は、より小さなシーンの更新により更新されることになろう。ＭＯＲＥおよびＬＡＳｅＲはＳＶＧシーンをＲＴＰにより伝送することができる方法を指定する。シーン更新機構は同一ではないとしても概念的に類似である。ＬＡＳｅＲはそれ自体の機構を指定し、一方ＭＯＲＥはＷ３ＣによるＸＭＬのための遠隔イベント（ＲＥＸ、Ｒｅｍｏｔｅ Ｅｖｅｎｔｓ ｆｏｒ ＸＭＬ）［５］を使用する。
同調能力および同調による誤り回復能力は特にＲＴＰのような信頼性のないプロトコルを使用する場合ＤＩＭＳにおいて非常に重要である。誤りが生じると、処理端末は、次のいわゆるランダム・アクセス・ポイント（ＲＡＰ、ｒａｎｄｏｍ ａｃｃｅｓｓ ｐｏｉｎｔ）を使用して誤りを回復することができる。端末が初めて同調を試行した場合と同様にこのＲＡＰをデコードし、古いシーンから全てを削除し、新たに同調を実行する。
ＤＩＭＳの別の重要な特徴は異なるソースから異なるプロトコルにより送信するストリームをも結合する能力である。一次ストリームのＤＩＭＳシーンは二次ストリームを生じさせることができ、二次ストリームは元のシーンを修正することができる。
今日二次ストリームにおける同調ポイント（ＲＡＰ）は全シーンに関する情報を含まなければならない。特に、一次ストリームを高い信頼性で配信し、二次ストリームを低い信頼性で配信する場合、これは非常に非効率である。これは、このような従来技術のＲＡＰでは、高い信頼性で受信したシーンの部分をも二次ストリームの同調ポイントにおいて再送することになろうことを意味する。
スケーラブル・ベクトル・グラフィックス（ＳＶＧ）Ｔｉｎｙ １．２仕様書−Ｗ３Ｃ勧告候補、２００６年８月１０日 ３ＧＰＰ Ｓ４−ＡＨＰ２５５、「動的および相互作用的マルチメディアシーン（ＤＩＭＳ）のためのＭＯＲＥ技術提案」 ＩＳＯ／ＩＥＣ １４４９６−２０、「情報技術−オーディオ−ビジュアルオブジェクトのコーディング−パート２０：ＬＡＳｅＲ（軽量アプリケーションシーン表現） ＩＥＴＦ ＲＦＣ３５５０、「ＲＴＰ：実時間アプリケーションのための伝送プロトコル」
従来技術の解決策は幾つかの不都合により問題を生じる。第１に、二次ストリーム内において誤りが生じる場合、以前に高い信頼性で送信した一次ストリームのメディアを信頼性のない配信プロトコルにより恐らく再送信しなければならない。第２に、二次ストリームを供給するサーバは二次ストリームを使用するであろうシーンに関する情報を持たねばならない。従ってサーバは一次ストリームにアクセスしなければならない。その結果、幾人かのユーザが彼らのアプリケーションに同一シーン状態を持てば、それらユーザは同じ二次ストリームを申し込むことのみができる。その上、各ユーザは二次ストリームの異なる時間に同調しうるので、ユーザが一次シーンをダウンロードし、二次同報送信ストリームに同調することは今日では不可能である。
本発明は従来技術の装置のこれら欠点およびその他の欠点を克服する。
リッチ・メディア・パケットの管理を提供することが本発明の一般的目的である。
二次または補助的リッチ・メディア・パケット・ストリームにおける誤り回復または同調またはその両方の可能性をもたらすリッチ・メディア・パケットの管理を提供することが本発明の特別の目的である。
これらおよびその他の目的を添付する特許請求の範囲により定義するように本発明により満たす。
端的には、本発明は、シーンを定義するリッチ・メディア・パケットの一次即ち主ストリームと関連して使用する二次即ち補助ストリームのリッチ・メディア・パケットの供給および処理を含む。二次ストリームのリッチメディアはシーン状態を定義し、シーンの一部分を制御する。ローカル・ランダム・アクセス・データは二次ストリームに供給される。このローカル・ランダム・アクセス・データは、処理時にはシーンの一部分の開始状態の作成を可能にする、全命令セットを定義する。開始状態はその上その他のシーン部分のシーン状態に影響を及ぼすことなく入手可能である。従って、本発明のローカル・ランダム・アクセス・データはローカル即ち部分的シーンのリフレッシュを達成し、全シーンのリフレッシュの生成および新規シーンの生成を行わない。その結果、二次ストリームにより定義するシーンの一部分のみに影響を及ぼし、シーンの一部分のみを本発明のローカル・ランダム・アクセス・データを使用して開始状態に設定することになろう。
供給したデータはリッチ・メディア・パケットに含まれ、このパケットは二次ストリームに挿入される。次いで、パケットは、二次ストリームの他の（シーン更新）パケットと共に、レンダリングするためにユーザ端末に伝送できる。
二次ストリームへの同調の際、または、二次・ストリームのリッチ・メディア・パケットの受信または処理において生じる誤り回復の際に、本発明のローカル・ランダム・アクセス・データを端末により使用することができる。
一次ストリームのリッチ・メディア・パケットにより表現できるシーンのレンダリングを含む進行中のメディアセッションの最中に二次ストリームに同調する場合、端末は二次ストリームのパケットを搬送するチャネルの聴取を開始する。端末は、通常はヘッダ情報の調査により、パケットの１つをローカル・ランダム・アクセス・データを搬送するものと特定する。一度特定すると、ローカル・ランダム・アクセス・データの処理により同調を実行し、シーンの一部分の開始状態をその他のシーン部分に影響を及ぼすことなく作成する。端末は次いで二次ストリームのリッチ・メディア・パケットの受信および処理を継続し、それによりその他のシーン部分に加えてシーンの一部分の状態を更新することができる。
二次ストリームの誤り回復の場合、端末は誤りパケットに続く二次ストリームの受信したリッチ・メディア・パケットを検索する。端末は本発明のローカル・ランダム・アクセス・データを含む当該リッチ・メディア・パケットを特定する。誤り回復は、特定したローカル・ランダム・アクセス・データを処理し、シーンの一部分の開始状態をその他のシーン部分のシーン状態に影響を及ぼすことなく作成することを含む。端末は二次ストリームのシーン更新パケットの受信および処理を継続し、シーンの一部分の状態を更新する。
本発明はまた二次ストリームを供給するメディアサーバ、そのような二次ストリームおよび一次および二次ストリームのリッチ・メディア・データを処理するユーザ端末に関係する。
添付する図面と共に行う以下の説明を参照することにより、本発明をそのさらなる目的および利点と共に最も良く理解できよう。
本発明の実施形態によるリッチ・メディア・パケットの二次ストリームを供給する方法を示すフローチャートである。 リッチ・メディア・パケットの一次および二次ストリームの概要概観図である。 種々のシーン部分を持つリッチメディアシーンの概観図である。 ツリー構造のシーン要素の構成を示す。 図１の供給方法の追加ステップを示すフローチャートである。 図１の供給方法の追加ステップを示すフローチャートである。 本発明によるメディアサーバを含む通信ネットワークの一部の概要概観図である。 本発明によるメディアサーバを含む通信ネットワークの別部の概要概観図である。 本発明の実施形態によるメディアサーバの概要ブロック図である。 本発明の実施形態による誤り回復方法のフローチャートである。 本発明の実施形態による図１０のフローチャートの状態作成ステップを示すフローチャートである。 本発明の実施形態によるリッチ・メディア・セッションの最中における二次ストリームへの同調方法を示すフローチャートである。 本発明の実施形態によるユーザ端末の概要ブロック図である。
図面を通して、対応するかまたは類似の要素に同じ参照文字を使用することにする。
本発明は広くリッチメディアの管理に関し、特にリッチ・メディア・パケットの一次ストリームに関連する二次ストリームにおけるランダム・アクセス・ポイントの生成および使用に関する。
当技術において周知のように、ＤＩＭＳは動的、相互作用的なシーンベースのメディアシステムであり、本システムはオーディオ、ビデオ、グラフィックス、イメージおよびテキストなどのマルチメディア即ちメディアデータの表示およびその相互作用的な制御を可能にする。本発明によれば、リッチメディアはメディアおよびマルチメディアコンテンツに関係し、本コンテンツを処理し、レンダリングし、レンダリング端末の表示スクリーンにおいて種々のシーンを形成することができる。そのようなリッチ・メディア・コンテンツはグラフィックス、特にベクトルグラフィックスおよびスケーラブル・ベクトル・グラフィックス（ＳＶＧ）、静的メディアコンテンツまたは連続メディアコンテンツまたはその両方を含む。静的コンテンツの例はイメージおよびテキストを含むが、ビデオおよびオーディオは連続メディアと見做される。このように、リッチ・メディア・パケットは、端末において処理する場合、リッチメディアシーンのレンダリングおよびそのようなシーンの更新を許容するデータおよび命令を含む。
シーンは、異なる一部分に分割されていると見做すことができる。一部分とは例えば、処理時には表示スクリーンの異なる部分を占める。そのような場合、これら一部分に関係するシーンデータはリッチ・メディア・パケットの異なるストリームから発生し、このストリームにより搬送することができる。一般に、一次ストリームは全シーンツリーを定義するストリームまたはファイルを参照し、全（ＤＩＭＳ）シーンの構築を許容する。この一次ストリームは１つまたは複数の関連する二次ストリームを持つことができ、二次ストリームは、シーンツリーの特定部分を管理するだけである。
一次および少なくとも１つの二次ストリームを同じプロトコル、また異なるプロトコルを経ても送信することができる。例えば、一次シーンのリッチ・メディア・パケットをダウンローディングにより高い信頼性で送信することができるが、二次ストリームはＲＴＰなど信頼性の劣るプロトコルを使用して送信しうる。
従来技術の一次および二次ストリームは基本的に２つの異なるクラスのリッチ・メディア・パケットを含む。まず、データパケットはいわゆるランダム・アクセス・ポイント（ＲＡＰ）即ち全シーンを含むことができる。ＲＡＰパケット（単数または複数）のコンテンツはシーン要素の空間構成、シーン要素の時間構成、同期情報および要素間の任意の相互作用を記述する。従ってこの情報は以前のリッチ・メディア・パケットに関する情報を使用しなくても全シーンのレンダリングに十分である。これは、クライアントがリッチメディアの提示および設計を開始するためにシーンを含むパケットを使用することができることを意味する。従来技術では、メディアのレンダリング開始および以前の受信ならびにデコード誤りの回復は、これらのいわゆるＲＡＰに制限される。一次および二次ストリーム双方はＲＡＰを含む。従来技術では一次ストリームのＲＡＰと比較して二次ストリームで搬送されるＲＡＰの処理に直接的な相違は存在しないが、これは両ＲＡＰが、完全なシーンのリフレッシュ即ちシーンの開始および完全なシーンツリーのリフレッシュを引き起こすことになるからである。従ってシーンの全部分を開始状態あるいは新規シーンにリセットすることになろう。
大多数のパケットストリームは以前のＲＡＰまたは以前のＲＡＰのレンダリングにより表現できるシーンおよび幾つかの以前のシーン更新パケットにより定義されるシーンに対する更新の増分を含むシーン更新パケットを含む。シーン更新パケットはシーン要素の追加、シーン要素の削除、シーン要素の置換、シーン要素属性の更新および新規シーン操作などの操作を定義する。当技術では、二次ストリームのシーン更新は一般に二次ストリームにより定義するシーンの一部分またはシーンツリーの一部分のみに適用可能である。
時にシーン表示およびシーン更新に表現完全拡張マークアップ言語（ＸＭＬ）ドキュメントおよびＸＭＬドキュメント更新がそれぞれ使用される。以下のアプリケーションでは、表現シーンおよびシーン更新を一貫して使用することにする。しかしながら、これは完全ＸＭＬドキュメントおよびドキュメント更新などの代替表記を含む。ＲＡＰ、シーンおよびシーン更新は、しかしながら必ずしもＸＭＬに基づかなくてもよい。非ＸＭＬベースのシーン記述子の例はフラッシュである。ＸＭＬドキュメント（単数または複数）を平文コンテキストで、またはバイナリ化して送信することができる。そのようなバイナリ化方法の例はｇｚｉｐ（ＧＮＵ ｚｉｐ）、圧縮、ＬＡＳｅＲバイナリおよびＢｉＭ（ＸＭＬのバイナリＭＰＥＧフォーマット）を含む。
従来技術との明確な対比では、本発明は特定の二次ストリームなど所与のストリームのみに適用できる新しいタイプのランダム・アクセス・データを供給する。これは、当該ローカル・ランダム・アクセス・データの処理が特定の二次ストリームにより定義されるシーン全体の一部分のみに影響を及ぼす部分的シーンリフレッシュを引き起すであろうことを意味する。残りのシーン部分は影響を受けずに残るであろう。これは、新規シーンへの完全なシーンリフレッシュをもたらす従来技術による一次ストリームのＲＡＰまたは二次ストリームのＲＡＰと比較されるべきである。
本発明の新しいローカル・ランダム・アクセス・データの基本的考え方は、ローカル・ランダム・アクセス・データを搬送する二次ストリームに関連するこれらシーンおよびシーンツリー部のみに影響を及ぼし、リフレッシュすることである。
図１は本発明によるリッチ・メディア・パケットの二次ストリームを供給する方法を示すフローチャートである。二次ストリームのパケットはリッチ・メディア・パケットの関連する一次ストリームにより表現できる全シーンの一部分のシーン状態を定義する。本方法はステップＳ１で始まり、ここでローカル・ランダム・アクセス・データを供給する。このローカル・ランダム・アクセス・データはユーザ端末で処理する場合二次ストリームにより定義するかまたは二次ストリームに関連するシーンの一部分の開始状態の作成を可能にする全命令セットを定義する。その上開始状態へのこの部分的シーンリフレッシュはシーンのその他の部分のシーン状態に影響を及ぼすことなく実行することができる。ローカル・ランダム・アクセス・データは、二次ストリームまたは実際には一次ストリーム若しくは別の二次ストリームの以前の他のリッチ・メディア・パケットに含まれるいかなる命令も使用することなく開始状態を作成し、また部分的シーンリフレッシュをするのための、完全で十分な命令セットを定義する。
次ステップＳ２は、供給されたローカル・ランダム・アクセス・データに基づきリッチ・メディア・パケットを生成する。従って供給されたローカル・ランダム・アクセス・データは１つまたは複数（即ち少なくとも２つ）のリッチ・メディア・パケットに含まれる。ローカル・ランダム・アクセス・ポイント（ＬＲＡＰ、ｌｏｃａｌ ｒａｎｄｏｍ ａｃｃｅｓｓ ｐｏｉｎｔ）・データを含む少なくとも１つのパケットをＳ３で二次ストリームに挿入し、次いでＳ４で１つまたは複数の要求元ユーザ端末に送信することができる。パケットストリームの送信を当技術で既知のあらゆる伝送プロトコルおよび機構により実行することができる。例えば、パケットを１つまたは複数のユーザ端末にダウンロードするか、またはストリーミングすることができる。あるいは通信ネットワークにおける複数端末への同報送信即ちマルチキャスト送信が可能でありうる。またユニキャストベースの伝送プロトコルも本発明のリッチ・メディア・パケットに使用することができる。本方法は次いで終了する。
図２はリッチ・メディア・パケット１１、１２、１３の一次ストリーム１０を概略的に示す。ストリームはパケット１１、１３を含むＲＡＰを含み、ＲＡＰは処理する場合新たなシーンへの全シーンリフレッシュを引起し、全シーン部分および全シーンツリーに影響を及ぼすであろう。一次ストリーム１０に結合即ち同調する場合、これらＲＡＰ１１、１３をユーザ端末により使用することができる。従って同調に関連する処理はこのようなＲＡＰ１１、３に関連してのみ開始することができる。当技術において周知のごとく、ＲＡＰはまたシーン更新パケット１２の１つの受信、デコードまたは誤り処理に関しても使用する。
一次シーン１０は、図２ではリッチ・メディア・パケット２１、２２、２３、２４を含む二次ストリーム２０に関連する。この二次ストリーム２０は少なくとも１つ、好ましくは複数の本発明によるＬＲＡＰ２１、２３を含む。従ってこれらＬＲＡＰ２１、２３は処理する場合他のシーン（ツリー）部に影響を及ぼすことなくシーン部分即ちシーンツリーの一部分のローカル／部分的リフレッシュを提供する。これらＬＲＡＰ２１、２３は一次ストリーム１０のＲＡＰ１１、１３と同様に使用することができる。従ってＬＲＡＰ２１、２３を、二次ストリーム２０への同調、または、二次ストリーム２０のシーン更新パケット２４の１つを受信、処理またはデコードする場合の誤り回復、またはその両方に使用する。
図３は表示スクリーンにおいてレンダリングするシーン３０を概略的に示す。シーン３０は異なるシーン部分３２、３４、３６を含む。図では、主シーン部分３２はＴＶチャネルのビデオデータを表示する。関連シーン部分３４、３６は、例えば天気予報、および株式交換価格を示す。このような設定では、それぞれＴＶチャネルのシーン部分を定義するリッチ・メディア・データを搬送し、全シーン３０、即ちまたシーンの一部分３４、３６にも影響を及ぼすＲＡＰを搬送する一次ストリームに関連する別二次ストリームにより、これら関連シーンの一部分３４、３６を管理することができよう。
従って従来技術による一次ストリームのＲＡＰおよび二次ストリームのＲＡＰは新しいシーン３０および全てのシーン部分３２、３４、３６のリフレッシュに繋がることになろう。明確に対比すれば、本発明のＬＲＡＰはＬＲＡＰを搬送する二次ストリームに関連するシーンの一部分３４または３６の開始状態を定義するのみであり、その他のシーン部分３２および３６または３２および３４をＬＲＡＰにより影響を及ぼさずに残すであろう。
二次ストリームの全てのＲＡＰを含むパケット２１、２３は好ましくは本発明のローカル・ランダム・アクセス・データを含むが、本発明はまた従来技術の全ランダム・アクセス・データを含むリッチ・メディア・パケットおよびシーン更新を含むパケットに加えて本発明のローカル・ランダム・アクセス・データを含むその他のリッチ・メディア・パケットを有する二次ストリームと関連しても使用することができる。
図４に示すように、シーンは本技術ではシーンツリーにより表すことが多い。そのようなシーンツリー４０は種々のオブジェクトおよび全てのシーン部分を定義する複数のツリーノード４１乃至４７を含む。従来技術による一次ストリームのＲＡＰおよび二次ストリームのＲＡＰはツリー４０の全てのノード４１乃至４７の完全なリフレッシュを引起すことになろう。本発明のＬＲＡＰは、しかしながらツリー４０の一部分４８をリフレッシュするのみであり、それ故ツリー４０の１つまたは複数のノード４２、４３にのみ影響を及ぼすが、その他のツリーノード４１、４４、４５、４６、４７には影響を及ぼさないであろう。
図５は図１のストリーム供給方法の追加ステップを示すフローチャートである。本方法は図１のステップＳ２から継続する。次ステップＳ１０で、シーン更新データを供給する。このシーン更新データはローカル・ランダム・アクセス・データにより定義される開始状態に適用でき、開始状態を二次ストリームに関連するシーンの一部分のシーン状態に「移動」させる。ＬＲＡＰにより定義する開始状態に適用できるこのシーン更新データを別のシーン更新パケット（パケット２１がＬＲＡＰを含めば図２のパケット２２）で送信することができる。とはいえ別の実施形態では、シーン更新データをステップ１０でローカル・ランダム・アクセス・データと共に同じリッチ・メディア・パケットに含めることができる。そのような場合、リッチ・メディア・パケットを受信するユーザ端末はローカル・ランダム・アクセス・データおよびリッチ・メディア・パケットに含まれるシーン更新データの双方を処理することができよう。とはいえその他の場合、ローカル・ランダム・アクセス・データは冗長と見做すことができよう。これは、リッチ・メディア・パケットを受信するユーザ端末がローカル・ランダム・アクセス・データの処理をするか否かを決定することができることを意味する。一般にＬＲＡＰはその場合二次ストリームに同調するユーザ端末または以前の二次ストリームの前のリッチ・メディア・パケットにおいて誤りを経験したユーザ端末によってのみ利用する。その他の端末はＬＲＡＰの処理／レンダリングを省略し、含まれるシーン更新情報のみを処理することができる。
リッチ・メディア・パケットは以下の部分を含むことができよう。
＜ＬＲＡＰ−特定＞
…
シーンの一部分のための開始状態への部分的シーンリフレッシュ
…
＜／ＬＲＡＰ−特定＞
＜更新＞
…
更新情報
…
＜／更新＞
好ましい実施形態では、本方法はステップ１１へ継続し、ここでリッチ・メディア・パケットのヘッダマーカを挿入するか、またはパケットがＬＲＡＰを含むことを通知する事前定義値に設定する。マーカは、二次ストリームへの同調を望む端末若しくは二次ストリームの以前のリッチ・メディア・パケット（シーン更新パケット即ちＬＲＡＰパケット）の受信またはデコード誤りを経験した端末にとり貴重な情報ソースである。これらの端末は受信パケットのヘッダ部を単に調べ、次のＬＲＡＰを含むパケットを特定しよう。
ヘッダマーカは包含するローカル・ランダム・アクセス・データが必須であることを示す値を持ちえよう。これは、特定の二次ストリームを聴取する全ての端末がパケットのランダム・アクセス・データを処理すべきであり、これは同調または誤り回復端末だけでないことを意味する。対応して、ヘッダマーカは冗長ＬＲＡＰを表す値を持つことができる。そのような場合、包含するローカル・ランダム・アクセス・データはストリームに同調するか、または以前のパケット誤りを回復する端末によってのみ処理する必要がある。ヘッダマーカはまたさらに、特にＬＲＡＰを冗長であるとして通知するのであれば、リッチ・メディア・パケットが本発明のＬＲＡＰに加えてシーン更新情報を含むことも通知することができる。
図５のヘッダマーカの挿入／設定ステップをシーン更新データの供給の有無とは独立に実行することができる。そのような場合、ステップＳ１０を全く省略することができ、ステップＳ１１のみを実行する。いずれの場合にも、本方法は次いでステップＳ３へ継続し、ここでＬＲＡＰ、ヘッダマーカおよびオプションとしてシーン更新データを含むリッチ・メディア・パケットを生成する。
本発明のローカル・ランダム・アクセス・データは好ましくは二次ストリームに関連するシーンの一部分の開始状態の供給を許容する全命令セットを含む。二次ストリームの以前のリッチ・メディア・パケットを失ったか、または二次ストリームに初めて同調するかに関わらず、ローカル・ランダム・アクセス・データは好ましくは開始状態の供給を許容する。ローカル・ランダム・アクセス・データに含む命令は二次ストリームが制御する特定のリッチ・メディア・パケットに依存しうる。ありうる部分的シーンリフレッシュの典型的な例はシーンの一部分からシーン要素の除去を引起す命令およびシーン要素の正しいバージョンの一部分への挿入を引起し、開始状態を形成する別のコマンドの包含でありえよう。二次ストリームに同調する端末は勿論未だ除去する二次ストリームのシーン要素を持たない。これらの端末は単にシーン要素の参照バージョンを考慮するシーンの一部分に挿入する。誤り回復の場合、誤りシーン要素を除去し、正しいバージョンを正しいシーンの一部分に挿入する。
ＲＥＸ（ＸＭＬのための遠隔イベント）を使用する当該ＬＲＡＰ命令の例は以下でありえよう。
＜dims:LRAP＞
＜rex xmlns='http://www.w3.org/ns/rex#'＞
＜event target='id("advertisement-node001")'name='DOMNodeRemoved'／＞
＜g xml:id='advertisement-node001'／＞
＜／rex＞
＜／dims:LRAP＞
＜rex xmlns='http://www.w3.org/ns/rex#'＞
＜event target='id("advertisement-node001")'name='DOMNodeInserted'／＞
＜／event＞
＜／rex＞
第１の命令はノード識別子のadvertisement-node001を持つシーン要素を除去する。第２の命令は次いでシーン要素の正しいバージョンを挿入する。この説明例から分かりうるように、種々のシーン要素は好ましくは関連する識別子を持つ。そのような場合、これらの識別子を使用してローカル・ランダム・アクセス・データによる影響を受けるであろうシーンの一部分を特定することができる。簡単に図４およびシーンツリー４０に戻ると、ツリー４０の各ノード４１乃至４７は関連するノード識別子を持つことができる。特定ノード４２を特定することにより、そのノード４２の下流のノードもまたＬＲＡＰにより影響を受けるであろう。
本発明に従い使用することができるその他の可能なＬＲＡＰ命令はシーンの一部分に関連する属性値の設定または再設定である。例えば、二次ストリームにより制御するシーンの一部分は現時間を告げる時計の表示でありえよう。ＬＲＡＰ命令は次いで現時計時間の再設定でありえよう。類似のシナリオはおそらく現外部温度を告げる温度計に対するものである。
先に検討したように、ＬＲＡＰは二次ストリームの以前のリッチ・メディア・パケットに含む命令を必要とすることなくシーンの一部分の開始状態を達成するのに必要な全命令セットを含む。従って、属性値に対し数値Ｎの加算を定義する命令は適切なＬＲＡＰ命令ではない。それというのは、属性値に別の値を設定する、以前のシーン更新パケットを端末が失くすことで、属性値は実際には誤りかもしれないからである。明らかに対照的に、本発明のＬＲＡＰ命令は、その場合属性値をある数に設定しよう。図２を参照すると、本発明のＬＲＡＰ２３は好ましくは一般的であるので、不正確に受信したのが以前のＬＲＡＰパケット２１か又はシーン更新パケット２２、２４の何れかに関わらず、ＬＲＡＰ２３を使用してシーンの一部分の開始状態を達成することができる。従ってＬＲＡＰパケット２３を第１のシーン更新パケット２２を不正確に受信した第１の端末により使用することができよう。同じＬＲＡＰパケット２３もまた第２の以前のシーン更新パケット２４を不正確に受信した第２の端末により使用することができる。
端末により正確に受信または処理しなかったかのが現ストリームの以前のどのリッチ・メディア・パケットかに関わらず、ＬＲＡＰ命令セットは好ましくは開始状態の供給の許容に十分一般的であるが、本発明はまた端末要求に基づきＬＲＡＰを生成することもできる。そのような手順を図６に示す。本方法はステップＳ２０で始まり、ここでローカル・ランダム・アクセス・データの端末特定要求を受信する。この要求は二次ストリームの以前のリッチ・メディア・パケットを正確に受信または処理しなかった端末により生成する。当技術において周知のように、データパケットは一般に割当てパケット識別子を持っている、例えばパケットヘッダに含む。そのような場合、ＬＲＡＰ要求は不正確に受信／処理したリッチ・メディア・パケット識別子を含むことがあり、その識別子をステップＳ２１で取出す。本方法は次いで図１のステップＳ１に継続し、ここでＬＲＡＰ要求に基づきローカル・ランダム・アクセス・データを供給する。この実施形態は特定ＬＲＡＰの生成を許容するが、これは特定ＬＲＡＰを使用して特定のリッチ・メディア・パケットの以前の誤りに対処することを意味する。結果として二次ストリームの何処でパケット誤りが生じたかに関わらず使用することが考えられる汎用ＬＲＡＰと比較して、より多くの特定命令をＬＲＡＰに含みうる。
本発明による二次ストリームにおけるローカル・ランダム・アクセス・ポイントの使用は一次ストリームと二次ストリームの有効な送信の分離を可能にする。その上高い信頼性で取得した（一次ストリームの）データは二次ストリームのＬＲＡＰで再送信する必要はない。本発明はまたシーンの静的部分のダウンロードも許容するが、二次ストリーム（単数または複数）により定義する動的部分はＲＴＰを経て更新する。
その上シーン（ツリー）の一部分に適用できる命令のみを含むことにより、本発明のＬＲＡＰを含む二次ストリームのリッチ・メディア・パケットは従来技術のＲＡＰを含むパケットより遥かに小さくなりうる。
二次ストリームのＬＲＡＰ処理は残りのシーンに影響を及ぼさない。これは、相互作用が失われず、再生に損壊がなく、従来技術におけるように全ＤＯＭ再構築による複雑な処理コストがないことを意味する。
図７は本発明によるメディアサーバ１００を収容する通信ネットワーク１の一部の概要概観図である。この実施形態では、ここでインフラストラクチャ、即ち移動ネットワーク１の基地局４００、４１０を使用して，１つの同じメディアサーバ１００が一次ストリーム１０および関連する二次ストリームの双方を供給し、双方を異なるユーザ端末３００に転送する。とはいえ図８に示すように、本発明を有利にはネットワーク１およびメディアサーバの構成と関連して使用することができる。この図で、第１のメディアサーバ１００は一次ストリーム１０を供給し、ストリーム１０をユーザ端末３００に転送する。ここで第１のメディアサーバ１００と同じか、または異なる基地局４００、４１０に接続する別のメディアサーバ２００により、二次ストリーム２０を供給する。二次ストリーム２０のＬＲＡＰは二次ストリーム２０のリッチメディアにより扱うシーン（ツリー）のこれら部分のみに影響を及ぼすので、第２のサーバ２００は二次ストリーム２０を使用するはずのシーンに関する知識を持つ必要はない。従って二次ストリーム２０を供給し、送信する場合、第２のサーバ２００は一次ストリーム１０の情報を持つ必要はない。これは、第２のサーバ２００が同じ二次ストリーム２０を異なる基本シーンを持つ多くの異なるユーザ端末３００に供給することを可能にする。また一時に２つ以上の二次ストリーム２０の適用を可能にする。その上一次ストリーム１０の同報通信を経る送信を必要とせず、例えば（ポイント・ツー・ポイントまたはポイントツー多）ダウンロードにより、二次ストリーム２０を基地局４１０により同報通信することができる。
図９は本発明によるメディアサーバ１００を概略的に示す。メディアサーバ１００は本発明によるローカル・ランダム・アクセス・データを供給するデータプロバイダ１１０を含み、このデータは二次ストリームにより定義するシーンの一部分の開始状態の作成を可能にする全命令セットを定義する。この作成は恐らく、リッチ・メディア・パケットの一次ストリームにより表現できる他のシーン部分のシーン状態に影響を及ぼすことのないデータの処理の最中である。データプロバイダ１１０は、当該ＬＲＡＰデータを蓄積する接続されたデータメモリ１６０からローカル・ランダム・アクセス・データを供給するようにできる。メモリ１６０は次いで事前定義命令を含むことができようし、この事前定義命令からデータプロバイダ１１０はＬＲＡＰデータとして使用する適切な命令セットを選択する。加えてメモリ１６０は二次ストリームが管理する特定ノードまたはシーンの一部分の識別子（単数または複数）を含むことができる。あるいはメディアサーバ１００は、要求に応じてＬＲＡＰデータを生成するデータエンジン１７０を含むか、またはデータエンジン１７０に接続する。次いでＬＲＡＰデータの作成に使用する関係命令および識別子をエンジン１７０により生成し、データプロバイダ１１０に転送する。
メディアサーバ１００はオプションとしてＬＲＡＰの端末特定要求を受信するようにする受信機１５０を含むことができる。受信機１５０は要求をデータプロバイダ１１０に転送し、データプロバイダ１１０は要求を処理する。プロバイダ１１０は好ましくは要求に含むパケット識別子に基づくなど、少なくとも部分的に要求に基づいてメモリ１６０またはエンジンまたはその両方からＬＲＡＰデータを供給する。
供給されるローカル・ランダム・アクセス・データはデータプロバイダ１１０からパケットジェネレータ１２０に転送される。ジェネレータ１２０は、受信ＬＲＡＰデータを含むひとつのリッチ・メディア・パケットまたは複数の当該パケットを作成する。パケットジェネレータ１２０は任意の更新データプロバイダ１８０に接続することができる。この更新データプロバイダ１８０はデータプロバイダ１１０からのローカル・ランダム・アクセス・データにより表現できる開始シーン状態に適用できるシーン更新情報を供給する。パケットジェネレータ１２０はまたこのシーン更新データを同じリッチ・メディア・パケットまたは後続のシーン更新パケットに挿入することもできる。
オプションのヘッダプロセッサ１９０はパケットジェネレータ１２０に接続される。プロセッサ１９０は、リッチ・メディア・パケットがＬＲＡＰを含むか、およびＬＲＡＰが冗長かそれとも必須か、およびパケットがまたシーン更新データも含むか、のうち少なくともひとつを通知する事前定義値によりリッチ・メディア・パケットのヘッダマーカを設定する。
リッチ・メディア・パケットは、ジェネレータ１２０から二次ストリームを生成するようにするストリームジェネレータ１３０に転送される。ストリームジェネレータ１３０は受信したリッチ・メディア・パケットを二次ストリームに挿入し、受信したリッチ・メディア・パケットを送信機１４０に転送し、送信機１４０は二次ストリームの受信したリッチ・メディア・パケットおよびその他のパケットを聴取するユーザ端末（単数または複数）に送信する。
メディアサーバ１００は選択肢としてまた一次ストリームのリッチ・メディア・パケットを供給することができる。そのような場合、サーバ１００は一次ストリームに適用できるランダム・アクセス・データおよびシーン更新データを供給するデータプロバイダ２１０を含む。供給されるランダム・アクセス・データは、処理時には完全な新しいシーンの作成を可能にし、それによりシーン（ツリー）の全部に影響を及ぼす。パケットジェネレータ２２０はデータプロバイダ２１０からのデータをリッチ・メディア・パケットにパケット化するようにし、リッチ・メディア・パケットをストリームジェネレータ２３０により一次ストリームに挿入する。一次ストリームのパケットは送信機１４０または専用の一次ストリーム送信機により送信する。
メディアサーバ１００のユニット１１０乃至１５０、１７０乃至１９０および２１０乃至２３０をソフトウェア、ハードウェアまたは以上の組合せとして提供することができる。メディアサーバ１００を移動通信ネットワークなどの通信ネットワークのネットワークノードに配置することができる。分散実装も可能であり、分散実装の場合メディアサーバ１００のユニットを２つ以上のネットワークノードに実装する。
先に考察したように、二次ストリームのローカル・ランダム・アクセス・データを誤り回復または二次ストリームへの同調またはその両方の場合に使用することができる。図１０は二次ストリームのリッチ・メディア・パケットにおける誤りの処理または受信からの回復方法を示すフローチャートである。本方法はステップＳ３０で始まり、ここで処理端末は端末により正確に受信しなかった、または端末により正確に処理できなかった、またはその両方の二次ストリームのリッチ・メディア・パケットを特定する。端末は次いで二次ストリームのリッチ・メディアの誤り回復手順を開始しなければならない。この手順は二次ストリームにおける本発明のＬＲＡＰを含む次リッチ・メディア・パケットの待機を含む。一次および二次ストリーム（単数または複数）の受信パケットの中のパケットの特定は以前に説明したように少なくとも部分的にパケットヘッダマーカに基づき実行する。従って次ステップＳ３１はローカル・ランダム・アクセス・データを含む二次ストリームのリッチ・メディア・パケットを受信、特定するステップを含む。このローカル・ランダム・アクセス・データを、ステップＳ３２で、（関連する一次ストリームのリッチメディアにより定義する）レンダリングするシーンの一部分の開始状態を作成するために処理するが、その他のシーン部分のシーン状態に影響を及ぼすことはない。従ってローカル・ランダム・アクセス・データの処理はシーンの一部分のみの部分的リフレッシュを起動し、それにより以前の誤りの受信／処理を訂正する。リッチ・メディア・パケットの受信および処理は次いで以前のように二次ストリームおよび一次ストリームの後続のリッチ・メディア・パケットにより継続することができる。本方法は次いで終了する。
図２を参照して、ユーザ端末が一次１０および二次２０のストリーム双方のリッチ・メディア・パケット１１、１２、２１、２２を現在受信中であると想定しよう。とはいえ二次ストリーム２０の１つのパケット２４を正確に受信または処理しなかった。端末は二次ストリーム（および勿論一次ストリーム）のリッチ・メディア・パケットを受信、調査し、次のＬＲＡＰを搬送するパケット２３を特定する。一度そのパケット２３を受信、処理すると、二次ストリーム２０により定義するシーンの一部分のシーン状態を訂正することができ、レンダリングは一次ストリームおよび二次ストリームの後続パケットにより継続する。このコンテキストにおいて、ＬＲＡＰの処理により達成するシーンの一部分の開始状態は誤りパケット２４を代わって正確に処理／受信したとすれば、取得したであろうの一部分の状態に対応する。従ってＬＲＡＰの後続の処理のために、二次ストリーム２０の全ての前パケットが正しかった場合の状況と比較して好ましくはシーン状態に相違はない。
図１１は図１０の状態作成ステップの実施形態をより詳細に示すフローチャートである。本方法は図１０のステップＳ３１から継続する。次ステップＳ４０で、端末はローカル・ランダム・アクセス・データおよびそれに含む命令を処理し、パケットの受信または処理における以前の誤りによる正確でないシーン要素またはシーンツリーノードを除去する。従ってこのデータは除去命令を含み、その上除去命令を適用すべきシーン要素またはノードの識別子を含む。命令は好ましくはまたステップＳ４１で使用する再挿入コマンドも含む。再挿入コマンドはアドレスなどの識別子に関連し、不正確なものに代わり使用するシーン要素またはノードの正しいバージョンの特定および引出しを許容する。レンダリングなどの処理により、シーン要素、シーンの一部分の正しい開始状態を取得し、本方法は終了する。
別の可能な状態作成実施形態は前に言及したようにシーンの一部分に関連する属性値に適用する再設定コマンドを利用するものでありうる。コマンドはその上属性値が持つべき実際値の情報を伴う。
図１２は本発明のローカル・ランダム・アクセス・データの別の使用を示すフローチャートである。この図は、一次ストリームのリッチ・メディア・パケットにより表現できるシーンのレンダリングを含む進行中のメディアセッションの最中における端末のためのリッチ・メディア・パケットの二次ストリームへの同調方法を示す。端末は二次ストリームのリッチ・メディア・パケットの伝送に使用するチャネルの聴取を開始する。パケットに含むヘッダマーカを好ましくはステップＳ５０で使用して二次ストリームにおけるパケットの１つをＬＲＡＰ搬送パケットとして特定する。端末は次いで特定したパケットのローカル・ランダム・アクセス・データの処理により二次ストリームに同調し、それによりその他のシーン部分のシーン状態に影響を及ぼすことなくシーンの一部分の開始状態を作成することができる。
一度シーンの一部分の開始状態を入手すると、端末は一次および二次ストリーム双方のリッチ・メディア・パケットの受信および処理により継続することができる。これら後続パケットの大部分は全シーンまたは一部のシーンのみに適用できるシーン更新を含むであろう。これら後続パケットの処理はシーンおよびシーンの一部分の種々の更新状態を作成するであろう。
以上の本発明では一次ストリームに関連する１つの二次ストリームにおけるＬＲＡＰの使用に関して主として考察した。しかしながら本発明の教示を同じまたは異なる一次ストリーム（単数または複数）に関連する複数の二次ストリームに関して使用することができる。好ましくは全ての二次ストリームの全ＲＡＰは本発明によるローカル・ランダム・アクセス・ポイントである。
図１３は本発明によるユーザ端末３００の概要ブロック図である。このユーザ端末３００は図では単一ユニットとして概略的に示す送信機および受信機即ち送受信機３１０を含む。ユニット３１０は変調器／復調器、など従来の送信機／受信機機能を含む。ユニット３１０の受信機部は特に本発明による一次ストリームおよび二次ストリームのリッチ・メディア・パケットを受信するようにする。
端末３００はまた受信機３１０により受信するストリームのリッチ・メディア・パケットを一時的に蓄積するメディアバッファ３５０も含む。このバッファ３５０はネットワークを経てメディアパケットを送信する場合に生じるジッタに対処するために主として使用する。
リッチ・メディア・プロセッサ３２０は、専用デコーダ３２５をオプションとして使用してデコードし、メディアバッファ３５０から引き出すリッチメディアをレンダリングするようにする。レンダリングしたメディアを接続する表示スクリーン３６０に表示し、おそらくは拡声器３７０で再生する。
誤り検出器３３０は、メディアプロセッサ３２０の受信機３１０またはデコーダ３２５またはその両方に接続されるようにする。この検出器３３０は、リッチ・メディア・パケットを受信機３１０により不正確に受信するか、メディアデコーダ３２５により正確にデコードできないか、またはプロセッサ３２０により処理できないか、の少なくともいずれであるかを調べる。そのような場合、検出器３３０は好ましくはパケット特定要求をユーザ端末３００に配置するパケット特定器３４０に転送する。
パケット特定器３４０は受信機３１０により以前に受信した、本発明によるローカル・ランダム・アクセス・データを含むリッチ・メディア・パケットを、メディアバッファ３５０において特定する。特定器３４０は、好ましくは以前に受信したメディアパケットをバッファ３５０において検索し、誤りパケットが属す二次ストリームに属すＬＲＡＰ搬送パケットを特定する。特定器３４０は、好ましくはパケットのヘッダデータをバッファ３５０において検索し、ＬＲＡＰに対応する定義値を持つヘッダマーカを見つける。バッファ３５０に蓄積する幾つかのそのようなＬＲＡＰ搬送パケットの場合、特定器３４０は好ましくはストリームの正確でないリッチ・メディア・パケットに最も接近して続くＬＲＡＰパケットを特定し、選択する。しかしながらローカル・ランダム・アクセス・データが好ましくは十分汎用的であれば、ローカル・ランダム・アクセス・データを使用して以前の誤りに対処することができる。
一度パケット特定器３４０がＬＲＡＰパケットを特定すると、プロセッサ３２０はＬＲＡＰパケットの中のデータを処理し、その他のシーン部分に影響を及ぼすことなくスクリーン３６０に表示するシーンの一部分の開始状態を作成する。
プロセッサ３３０は例えばＬＲＡＰパケットの除去命令を使用し、シーン要素またはシーンツリーノード（単数または複数）を除去し、シーン要素またはツリーノード（単数または複数）を正しいバージョンにより置換することができよう。それに代えて、あるいは追加して、再設定命令を使用して、属性を正確な現行値に設定することができる。
一次ストリームおよび選択肢として少なくとも１つのその他の二次ストリームのリッチ・メディア・パケットの受信を含む進行中のメディアセッションの最中において二次ストリームに同調する場合、受信機３１０は二次ストリームのリッチ・メディア・パケットを受信し、それをメディアバッファ３５０に一時的に蓄積する。パケット特定器はこれら二次ストリームパケットを検索し、好ましくはヘッダ情報に基づきＬＲＡＰ搬送パケットを特定する。一度そのようなリッチ・メディア・パケットを特定すると、メディアプロセッサ３２０はリッチ・メディア・パケットの中のローカル・ランダム・アクセス・データを処理し、その他のシーン部分のシーン状態に影響を及ぼすことなく表示スクリーン３６０に提示するシーンの一部分の開始状態を作成する。
メディアプロセッサ３２０は次いで一次ストリームおよび選択肢として少なくとも１つのその他の二次ストリームのリッチ・メディア・パケットの処理に加えて二次ストリームのシーン更新パケットの処理により継続する。
ユーザ端末３００のユニット３１０乃至３４０はソフトウェア、ハードウェアまたは以上の組合せとして提供することができる。
添付する特許請求の範囲により定義する本発明の範囲を逸脱することなく種々の修正および変更を本発明になすことができることを当業者は理解するであろう。

Claims (30)

  1. リッチ・メディア・パケットの一次ストリームにより表現できるシーンの一部分のシーン状態を定義するリッチ・メディア・パケットの二次ストリームを供給する方法であって、
    前記シーンの一部分の開始状態を作成することを処理時に可能とする全命令セットを定義するローカル・ランダム・アクセス・データを、前記シーンのその他の部分のシーン状態に影響を及ぼすことなく供給するステップと、
    前記ローカル・ランダム・アクセス・データを含むリッチ・メディア・パケットを生成するステップと、
    前記生成したリッチ・メディア・パケットを前記二次ストリームに挿入するステップと
    を含む方法。
  2. 前記ローカル・ランダム・アクセス・データは、前記二次ストリームの以前のリッチ・メディア・パケットに含まれる命令を使用することなく前記開始状態を作成することを処理時に可能とする請求項１に記載の方法。
  3. 前記開始状態に適用でき、処理時に前記シーンの一部分のシーン状態を得るシーン更新情報を供給するステップをさらに含み、
    前記生成するステップが前記ローカル・ランダム・アクセス・データおよび前記シーン更新情報を含む前記リッチ・メディア・パケットを生成するステップを含む請求項１または請求項２に記載の方法。
  4. 前記リッチ・メディア・パケットがランダム・アクセス・データを含むことを通知する事前定義値に、前記リッチ・メディア・パケットのヘッダマーカを設定するステップをさらに含む請求項１乃至請求項３のいずれか一項に記載の方法。
  5. 前記二次ストリームのリッチ・メディア・パケットを少なくとも１つのユーザ端末に送信するステップをさらに含む請求項１乃至請求項４のいずれか一項に記載の方法。
  6. 前記供給するステップが、（ｉ）前記シーンの一部分からのシーン要素の除去および、（ｉｉ）前記シーン要素の正しいバージョンを前記シーンの一部分に再挿入して前記開始状態の形成、を定義するローカル・ランダム・アクセス・データを供給するステップを含む請求項１乃至請求項５のいずれか一項に記載の方法。
  7. 前記供給するステップが前記シーンの一部分に関連する属性値の再設定を定義するローカル・ランダム・アクセス・データを供給するステップを含む請求項１乃至請求項５のいずれか一項に記載の方法。
  8. ローカル・ランダム・アクセス・データの端末特定要求を受信するステップをさらに含み、
    前記供給するステップを前記端末特定要求に基づき実行する請求項１乃至請求項７のいずれか一項に記載の方法。
  9. 前記供給するステップが、前記端末特定要求に含まれた、ユーザ端末により不正確に処理された前記二次ストリームの以前のリッチ・メディア・パケットに対応するリッチ・メディア・パケット識別子に基づき、前記ローカル・ランダム・アクセス・データを供給するステップを含む請求項８に記載の方法。
  10. リッチ・メディア・パケットの二次ストリームにより定義するシーンの一部分の開始状態を作成することを処理時に可能とする全命令セットを定義するローカル・ランダム・アクセス・データを、リッチ・メディア・パケットの一次ストリームにより表現できる前記シーンのその他の部分のシーン状態に影響を及ぼすことなく供給するデータプロバイダと、
    前記ローカル・ランダム・アクセス・データを含むリッチ・メディア・パケットを生成するパケット生成器と、
    前記生成したリッチ・メディア・パケットを前記二次ストリームに挿入するストリーム生成器と
    を含むメディアサーバ。
  11. 前記開始状態に適用でき、処理時に前記シーンの一部分のシーン状態を得るシーン更新情報を供給する更新プロバイダをさらに含み、
    前記パケット生成器が前記ローカル・ランダム・アクセス・データおよび前記シーン更新情報を含む前記リッチ・メディア・パケットを生成する請求項１０に記載のメディアサーバ。
  12. 前記リッチ・メディア・パケットがランダム・アクセス・データを含むことを通知する事前定義値に、前記リッチ・メディア・パケットのヘッダマーカを設定するヘッダプロセッサをさらに含む請求項１０または請求項１１に記載のメディアサーバ。
  13. 前記二次ストリームのリッチ・メディア・パケットを少なくとも一つのユーザ端末に送信する前記ストリーム生成器に接続する送信機をさらに含む請求項１０乃至請求項１２のいずれか一項に記載のメディアサーバ。
  14. ローカル・ランダム・アクセス・データの端末特定要求を受信する受信機をさらに含み、
    前記データプロバイダを、前記端末特定要求に基づき前記ローカル・ランダム・アクセス・データを供給する前記受信機に接続する請求項１０乃至請求項１３のいずれか一項に記載のメディアサーバ。
  15. シーンを定義するリッチ・メディア・パケットの一次ストリームを供給する第１のメディアサーバと、
    前記シーンの一部分を定義するリッチ・メディア・パケットの二次ストリームを供給する請求項１０乃至請求項１４のいずれか一項に記載の第２のメディアサーバと
    を含むメディアシステム。
  16. リッチ・メディア・パケットの一次ストリームにより表現できるシーンの一部分を定義するリッチ・メディア・パケットの二次ストリームであって、
    前記シーンの一部分の状態を更新するシーン更新を含む複数のリッチ・メディア・パケットと、
    前記シーンのその他の部分のシーン状態に影響を及ぼすことなく、前記シーン更新を適用することができる前記シーンの一部分の開始状態を作成することを処理時に可能とする全命令セットを定義するローカル・ランダム・アクセス・データを含む少なくとも１つのリッチ・メディア・パケットと
    を含む二次ストリーム。
  17. リッチ・メディア・パケットの一次ストリームにより表現できるシーンの一部分を定義するリッチ・メディア・パケットの二次ストリームのリッチメディアの処理誤りからの回復方法であって、
    前記二次ストリームの不正確に処理したリッチ・メディア・パケットを特定するステップと、
    ローカル・ランダム・アクセス・データを含む前記二次ストリームのリッチ・メディア・パケットを受信するステップと、
    前記シーンのその他の部分のシーン状態に影響を及ぼすことなく、前記ローカル・ランダム・アクセス・データに基づき前記シーンの一部分の開始状態を作成するステップと
    を含む方法。
  18. 前記開始状態が、前記特定したリッチ・メディア・パケットを正確に処理していれば達成できるであろう前記シーンの一部分の状態に対応する請求項１７に記載の方法。
  19. 前記作成するステップが、
    前記ローカル・ランダム・アクセス・データに基づき前記シーンの一部分からシーン要素を除去するステップと、
    前記ローカル・ランダム・アクセス・データに基づき前記シーン要素の正しいバージョンを前記シーンの一部分に再挿入し、前記開始状態を形成するステップと
    を含む請求項１７または請求項１８に記載の方法。
  20. 前記作成するステップが前記ローカル・ランダム・アクセス・データに基づき前記シーンの一部分に関連する属性値を再設定するステップを含む請求項１７または請求項１８に記載の方法。
  21. 一次ストリームのリッチ・メディア・パケットにより表現できるシーンのレンダリングを含む進行中のメディアセッションの最中におけるリッチ・メディア・パケットの二次ストリームに同調する方法であって、前記二次ストリームのリッチ・メディア・パケットが前記シーンの一部分を表し、前記方法が、
    前記二次ストリームにおけるローカル・ランダム・アクセス・データを含むリッチ・メディア・パケットを特定するステップと、
    前記ローカル・ランダム・アクセス・データの処理により前記二次ストリームに同調し、前記シーンのその他の部分のシーン状態に影響を及ぼすことなく前記シーンの一部分の開始状態を作成するステップと
    を含む方法。
  22. 前記ローカル・ランダム・アクセス・データに関係する前記リッチ・メディア・パケットに含むシーン更新情報を処理し、前記シーンの一部分の更新状態を作成するステップをさらに含む請求項１７乃至請求項２１のいずれかに記載の方法。
  23. 前記リッチ・メディア・パケットに含むヘッダマーカに基づき前記ローカル・ランダム・アクセス・データを含む前記リッチ・メディア・パケットを特定するステップをさらに含む請求項１７乃至請求項２２のいずれかに記載の方法。
  24. シーンを表す一次ストリームのリッチ・メディア・パケットおよび前記シーンの一部分を定義する二次ストリームのリッチ・メディア・パケットを受信する受信機と、
    前記受信機により不正確に受信するか、または前記ユーザ端末のデコーダにより不正確にデコードする前記二次ストリームのリッチ・メディア・パケットを特定する誤り検出器と、
    前記受信機により受信する前記二次ストリームのリッチ・メディア・パケットにおけるローカル・ランダム・アクセス・データに基づき、前記シーンのその他の部分のシーン状態に影響を及ぼすことなく前記シーンの一部分の開始状態を作成するプロセッサと
    を含むユーザ端末。
  25. 前記リッチ・メディア・パケットに含むヘッダマーカに基づき前記ローカル・ランダム・アクセス・データを含む前記リッチ・メディア・パケットを特定するパケット特定器をさらに含む請求項２４に記載のユーザ端末。
  26. 前記プロセッサが、（ｉ）前記ローカル・ランダム・アクセス・データに基づき前記シーンの一部分からシーン要素を除去し、（ｉｉ）前記ローカル・ランダム・アクセス・データに基づき前記シーン要素の正しいバージョンを前記シーンの一部分に再挿入して前記開始状態を形成する、請求項２４または請求項２５に記載のユーザ端末。
  27. 前記プロセッサが前記ローカル・ランダム・アクセス・データに基づき前記シーンの一部分に関連する属性値を再設定する請求項２４または請求項２５に記載のユーザ端末。
  28. シーンを表す一次ストリームのリッチ・メディア・パケットを受信する受信機と、
    前記シーンの一部分を定義するリッチ・メディア・パケットの二次ストリームにおけるローカル・ランダム・アクセス・データを含むリッチ・メディア・パケットを特定するパケット特定器と、
    前記ローカル・ランダム・アクセス・データを処理し、前記シーンのその他の部分のシーン状態に影響を及ぼすことなくシーンの前記の一部分の開始状態を作成し、前記二次ストリームに同調することを可能にするプロセッサと
    を含むユーザ端末。
  29. 前記パケット特定器が前記リッチ・メディア・パケットに含むヘッダマーカに基づき前記ローカル・ランダム・アクセス・データを含む前記リッチ・メディア・パケットを特定する請求項２８に記載のユーザ端末。
  30. 前記リッチ・メディア・パケットがまた前記開始状態に適用できるシーン更新情報も含み、
    前記プロセッサが前記ローカル・ランダム・アクセス・データに関係する前記シーン情報の処理により前記シーンの一部分の更新状態を作成する請求項２４乃至請求項２９のいずれか一項に記載のユーザ端末。
JP2009534537A 2006-10-25 2007-10-10 リッチ・メディア・ストリームの管理 Active JP5237292B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US85410006P 2006-10-25 2006-10-25
US60/854,100 2006-10-25
PCT/SE2007/000893 WO2008051136A1 (en) 2006-10-25 2007-10-10 Rich media stream management

Publications (2)

Publication Number Publication Date
JP2010507967A true JP2010507967A (ja) 2010-03-11
JP5237292B2 JP5237292B2 (ja) 2013-07-17

Family

ID=38824971

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009534537A Active JP5237292B2 (ja) 2006-10-25 2007-10-10 リッチ・メディア・ストリームの管理

Country Status (9)

Country Link
US (1) US9219941B2 (ja)
EP (1) EP2084895A1 (ja)
JP (1) JP5237292B2 (ja)
KR (1) KR101503082B1 (ja)
CN (1) CN101529885B (ja)
AU (1) AU2007309759B2 (ja)
MY (1) MY147046A (ja)
RU (1) RU2467506C2 (ja)
WO (1) WO2008051136A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014534695A (ja) * 2011-10-13 2014-12-18 サムスン エレクトロニクス カンパニー リミテッド コンテンツディスプレイ方法、コンテンツ同期化方法、放送コンテンツディスプレイ方法及びディスプレイ装置

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2114076B1 (en) * 2008-04-21 2013-09-11 Samsung Electronics Co., Ltd. Apparatus and method for composing scenes using rich media contents
JP2011087194A (ja) * 2009-10-16 2011-04-28 Sony Corp 画像処理装置および画像処理方法
KR20120138604A (ko) 2011-06-14 2012-12-26 삼성전자주식회사 멀티미디어 시스템에서 복합 미디어 컨텐츠를 송수신하는 방법 및 장치
US9549024B2 (en) 2012-12-07 2017-01-17 Remote Media, Llc Routing and synchronization system, method, and manager

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005065232A (ja) * 2003-07-25 2005-03-10 Victor Co Of Japan Ltd ストリームデータの記録再生方法
WO2005071969A1 (en) * 2004-01-14 2005-08-04 Sony Ericsson Mobile Communications Ab Multimedia distributing and/or playing systems and methods using separate resolution-enhancing supplemental data

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5696500A (en) 1995-08-18 1997-12-09 Motorola, Inc. Multi-media receiver and system therefor
US7778877B2 (en) * 2001-07-09 2010-08-17 Linkshare Corporation Enhanced network based promotional tracking system
CA2319820A1 (en) 1998-01-30 1999-08-05 The Trustees Of Columbia University In The City Of New York Method and system for client-server interaction in interactive communications
US7000180B2 (en) 2000-06-29 2006-02-14 Balthaser Online, Inc. Methods, systems, and processes for the design and creation of rich-media applications via the internet
KR100798201B1 (ko) 2000-09-01 2008-01-24 마츠시타 덴끼 산교 가부시키가이샤 광디스크 매체, 광디스크 재생 장치, 재생 방법 및 기록 방법
KR20020085985A (ko) 2001-05-10 2002-11-18 권형우 리치 미디어의 실시간 전송 시스템
KR100476781B1 (ko) * 2001-12-28 2005-03-16 삼성전자주식회사 캐싱기법을 이용한 ｍｐｅｇ-4 시스템 단말의 제어방법
EP1403778A1 (en) * 2002-09-27 2004-03-31 Sony International (Europe) GmbH Adaptive multimedia integration language (AMIL) for adaptive multimedia applications and presentations
US7012606B2 (en) * 2003-10-23 2006-03-14 Microsoft Corporation System and method for a unified composition engine in a graphics processing system
KR100695126B1 (ko) 2003-12-02 2007-03-14 삼성전자주식회사 그래픽 데이터 압축에 관한 메타표현을 이용한 입력파일생성 방법 및 시스템과, ａｆｘ부호화 방법 및 장치
DE602005007653D1 (de) 2004-04-12 2008-08-07 Ind Academic Coop Verfahren, Vorrichtungen und Speichermedien zur Bereitstellung von Multimedia-Diensten unter Berücksichtung der Endeinrichtungsfähigkeiten

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005065232A (ja) * 2003-07-25 2005-03-10 Victor Co Of Japan Ltd ストリームデータの記録再生方法
WO2005071969A1 (en) * 2004-01-14 2005-08-04 Sony Ericsson Mobile Communications Ab Multimedia distributing and/or playing systems and methods using separate resolution-enhancing supplemental data

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
JPN6012025294; Ｖｉｄｙａ　Ｓｅｔｌｕｒ，　Ｔｏｌｇａ　Ｃａｐｉｎ，　Ｓｕｒｅｓｈ　Ｃｈｉｔｔｕｒｉ，　Ｒａｍａｋｒｉｓｈｎａ　Ｖｅｄａｎｔｈａｍ，　Ｍｉｃｈａｅｌ　Ｉｎｇｒａｓｓｉａ: 'Ｍｏｒｅ：　Ａ　Ｍｏｂｉｌｅ　Ｏｐｅｎ　Ｒｉｃｈ　Ｍｅｄｉａ　Ｅｎｖｉｒｏｎｍｅｎｔ' ２００６　ＩＥＥＥ　Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｃｏｎｆｅｒｅｎｃｅ　ｏｎ　Ｍｕｌｔｉｍｅｄｉａ　ａｎｄ　Ｅｘｐｏ , 20060709, ｐｐ．２０２９-２０３２ *
JPN6012062565; 'Ｄｉｓｔｒｉｂｕｔｅｄ　Ｒａｎｄｏｍ　Ａｃｃｅｓｓ　Ｐｏｉｎｔｓ　（ＤＲＡＰ）' ３ＧＰＰ　ＴＳＧ　ＳＡ　ＷＧ４　＃４０　Ｔｄｏｃ　Ｓ４-０６０４５８ , 20060828, ｐｐ．１-１０ *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014534695A (ja) * 2011-10-13 2014-12-18 サムスン エレクトロニクス カンパニー リミテッド コンテンツディスプレイ方法、コンテンツ同期化方法、放送コンテンツディスプレイ方法及びディスプレイ装置

Also Published As

Publication number Publication date
CN101529885A (zh) 2009-09-09
MY147046A (en) 2012-10-15
US20100142557A1 (en) 2010-06-10
AU2007309759B2 (en) 2011-04-07
KR101503082B1 (ko) 2015-03-16
RU2009119437A (ru) 2010-11-27
CN101529885B (zh) 2012-05-16
KR20090073241A (ko) 2009-07-02
EP2084895A1 (en) 2009-08-05
JP5237292B2 (ja) 2013-07-17
AU2007309759A1 (en) 2008-05-02
RU2467506C2 (ru) 2012-11-20
WO2008051136A1 (en) 2008-05-02
US9219941B2 (en) 2015-12-22

Similar Documents

Publication Publication Date Title
JP5493627B2 (ja) 情報処理装置、データ管理方法、およびプログラム
US20090313293A1 (en) Method to embedding svg content into an iso base media file format for progressive downloading and streaming of rich media content
US20180288468A1 (en) Reception apparatus, transmission apparatus, and data processing method
US8533358B2 (en) Methods and apparatus for fragmenting system information messages in wireless networks
Lim et al. New MPEG transport standard for next generation hybrid broadcasting system with IP
JP5590881B2 (ja) メディア表現からメディアを再構成する方法及び装置
CN107534793B (zh) 接收装置、传输装置以及数据处理方法
JP5237292B2 (ja) リッチ・メディア・ストリームの管理
JP5117574B2 (ja) 放送受信装置
EP2081360B1 (en) Method for transmitting and receiving notification message and apparatus thereof
CN101616168A (zh) 流媒体互动信息的处理方法、装置及系统
US8578228B2 (en) Error recovery for rich media
CN107534792B (zh) 接收设备、发送设备以及数据处理方法
JP6185959B2 (ja) 情報処理装置、情報処理方法、およびプログラム
JP2014135756A (ja) 情報処理装置、データ管理方法、およびプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100910

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120518

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120807

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121203

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130213

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130315

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130328

R150 Certificate of patent or registration of utility model

Ref document number: 5237292

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160405

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250