(57)【要約】【課題】受信装置において、相手装置からのプッシュによって取得したデータを特定のアプリケーションが利用可能となるまでの時間を短縮すること。【解決手段】他の装置からプッシュ配信されたデータを受信する受信装置は、プッシュ配信されるデータを所定のアプリケーションが利用可能とするための所定の関数を登録するか否かを、そのデータの情報に基づいて判定し、登録すると判定された所定の関数を登録し、プッシュ配信されたデータを受信した際に、そのデータに関して所定の関数が登録されている場合に、その所定の関数を実行する。【選択図】図７
2020140393.tif 000002
【特許請求の範囲】
【請求項１】
他の装置からプッシュ配信されたデータを受信する受信装置であって、
前記プッシュ配信されるデータを所定のアプリケーションが利用可能とするための所定の関数を登録するか否かを、当該データの情報に基づいて判定する判定手段と、
前記判定手段において登録すると判定された所定の関数を登録する登録手段と、
前記プッシュ配信されたデータを受信した際に、当該データに関して前記登録手段によって前記所定の関数が登録されている場合に、当該所定の関数を実行する実行手段と、
を有することを特徴とする受信装置。
【請求項２】
前記所定のアプリケーションが前記所定の関数の登録を要求し、
前記判定手段は、前記要求において指定された情報が、前記他の装置から受信された前記プッシュ配信の予告に含まれる情報と対応する場合に、当該プッシュ配信されるデータに関して前記所定の関数を登録すると判定する、
ことを特徴とする請求項１に記載の受信装置。
【請求項３】
前記判定手段は、前記要求において指定された、前記プッシュ配信されるデータのパス情報が、前記予告に含まれる、当該プッシュ配信されるデータのパス情報と一致する場合に、当該プッシュ配信されるデータに関して前記所定の関数を登録すると判定する、
ことを特徴とする請求項２に記載の受信装置。
【請求項４】
前記判定手段は、前記要求において指定された、前記プッシュ配信されるデータの識別子が、前記予告に含まれる、当該プッシュ配信されるデータの識別子と一致する場合に、当該プッシュ配信されるデータに関して前記所定の関数を登録すると判定する、
ことを特徴とする請求項２に記載の受信装置。
【請求項５】
前記他の装置に対して前記プッシュ配信によるデータの送信を指示する指示手段をさらに有し、
前記指示手段は、前記指示に前記識別子を含めて前記他の装置へ送信し、
前記予告は、前記指示に応じて前記他の装置から送信される、
ことを特徴とする請求項４に記載の受信装置。
【請求項６】
前記指示は、ＭＰＥＧ−ＤＡＳＨ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ−Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）  ｐａｒｔ  ６の、Ｐｕｓｈ  Ｄｉｒｅｃｔｉｖｅを用いて行われる、
ことを特徴とする請求項５に記載の受信装置。
【請求項７】
前記予告は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）／２のＰＵＳＨ＿ＰＲＯＭＩＳＥによって行われる、
ことを特徴とする請求項２から６のいずれか１項に記載の受信装置。
【請求項８】
前記プッシュ配信は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）／２のサーバプッシュによって行われる、
ことを特徴とする請求項１から７のいずれか１項に記載の受信装置。
【請求項９】
前記所定の関数が実行されることにより、前記所定のアプリケーションが前記プッシュ配信されたデータを取得するための情報が、当該所定のアプリケーションへ通知される、
ことを特徴とする請求項１から８のいずれか１項に記載の受信装置。
【請求項１０】
他の装置からプッシュ配信されたデータを受信する受信装置によって実行される制御方法であって、
前記プッシュ配信されるデータを所定のアプリケーションが利用可能とするための所定の関数を登録するか否かを、当該データの情報に基づいて判定する判定工程と、
前記判定工程において登録すると判定された所定の関数を登録する登録工程と、
前記プッシュ配信されたデータを受信した際に、当該データに関して前記登録工程において前記所定の関数が登録されている場合に、当該所定の関数を実行する実行工程と、
を有することを特徴とする制御方法。
【請求項１１】
コンピュータを、請求項１から９のいずれか１項に記載の受信装置が有する各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プッシュ配信されたデータの利用制御技術に関する。
【背景技術】
【０００２】
近年、ＷｅｂサーバやＷｅｂブラウザにおいてＨＴＴＰ／２のサポートが進み、徐々に普及が進んでいる。ＨＴＴＰ／２は、ＨＴＴＰ１．１に対してパフォーマンスを向上する様々な機能が追加されている。その機能の１つであるサーバプッシュは、クライアントからのリクエストが来る前にサーバ側からスクリプトや、画像データ、スタイルシート等を送信する。これにより、Ｗｅｂブラウザは、Ｗｅｂページの表示を早くすることができる。
【０００３】
映像データをＨＴＴＰでストリーミング配信する技術として、ＩＳＯで標準化されたＭＰＥＧ−ＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ：ＩＳＯ／ＩＥＣ  ２３００９−１）が普及している。そして、近年、ＨＴＴＰ／２のサーバプッシュ機能やＷｅｂＳｏｃｋｅｔを利用してスループットの向上や遅延を削減する技術がＭＰＥＧ−ＤＡＳＨ  ｐａｒｔ６（ＩＳＯ／ＩＥＣ  ２３００９−６）として規格化されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特表２００５−５１９４０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＭＰＥＧ−ＤＡＳＨのクライアントは、ＪａｖａＳｃｒｉｐｔ（登録商標）等で作成され、Ｗｅｂブラウザ上で動作するＷｅｂアプリであることが一般的である。プッシュされたセグメントは、Ｗｅｂブラウザのキャッシュに保管される。このため、Ｗｅｂアプリは、ＨＴＴＰのＧＥＴメソッドでＷｅｂブラウザのキャッシュからそのセグメントを取得する必要がある。すなわち、プッシュされたセグメントは、Ｗｅｂアプリが直接受信するのではなく、まずＷｅｂブラウザのキャッシュに保管される。このため、セグメントがキャッシュに保管されてからＷｅｂアプリがＧＥＴメソッドで所望のセグメントを取得するまでの時間はＷｅｂブラウザのキャッシュでセグメントが滞留することとなる。
【０００６】
特許文献１には、ＷｅｂブラウザがＷｅｂサーバからのプッシュメッセージを取得し、それに応じてＷｅｂブラウザ上のユーザインタフェースを変化させることが記載されている。しかしながら、特許文献１に記載の技術は、ユーザに対してメッセージがプッシュされたことを通知するのみであり、特定のアプリケーションがＷｅｂブラウザのキャッシュに保管されたデータを早期に利用可能とする仕組みについては検討されていない。
【０００７】
本発明は、受信装置において、相手装置からのプッシュによって取得したデータを特定のアプリケーションが利用可能となるまでの時間を短縮する技術を提供する。
【課題を解決するための手段】
【０００８】
本発明の一態様による受信装置は、他の装置からプッシュ配信されたデータを受信する受信装置であって、前記プッシュ配信されるデータを所定のアプリケーションが利用可能とするための所定の関数を登録するか否かを、当該データの情報に基づいて判定する判定手段と、前記判定手段において登録すると判定された所定の関数を登録する登録手段と、前記プッシュ配信されたデータを受信した際に、当該データに関して前記登録手段によって前記所定の関数が登録されている場合に、当該所定の関数を実行する実行手段と、を有する。
【発明の効果】
【０００９】
本発明によれば、受信装置において、相手装置からのプッシュによって取得したデータを特定のアプリケーションが利用可能となるまでの時間を短縮することができる。
【図面の簡単な説明】
【００１０】
【図１】システムの構成例を示す図である。
【図２】受信装置のハードウェア構成例を示す図である。
【図３】受信装置の機能構成例を示す図である。
【図４】セグメントの生成と取得との時間差を説明するための図である。
【図５】セグメントの生成と取得との時間差を説明するための図である
【図６】受信装置の処理内容を概説する図である。
【図７】受信装置によって実行されるコールバック許可判定の流れの例を示す図である。
【図８】プッシュ指示のリクエストとＷｅｂサーバによるレスポンスの例を示す図である。
【図９】プッシュ指示のリクエストとＷｅｂサーバによるレスポンスの別の例を示す図である。
【発明を実施するための形態】
【００１１】
以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものでない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。
【００１２】
（システム構成）
図１に、本実施形態におけるコンテンツ配信システムの構成例を示す。本システムでは、映像コンテンツや音声コンテンツ等のメディアコンテンツが配信されるシステムであり、メディアコンテンツを配信する送信装置２００と、そのメディアコンテンツを受信する受信装置１００とを含んで構成される。受信装置１００は、一例において、通信網３００を介して、送信装置２００と通信可能に構成される。なお、図１の例では、１つの受信装置１００と１つの送信装置２００とが示されているが、これらの装置の少なくともいずれかが複数存在してもよい。
【００１３】
受信装置１００は、コンテンツの再生・表示機能、通信機能、及びユーザからの入力を受け付ける機能を有し、例えば、スマートフォン、ＰＣ、テレビ、携帯電話等の任意の電子機器でありうる。送信装置２００は、例えば、カメラ、ビデオカメラ、スマートフォン、ＰＣ（パーソナルコンピュータ）、携帯電話などの任意の電子機器であってもよい。通信網３００は、例えば有線と無線とを問わない任意の通信ネットワークでありうる。通信ネットワークは、インターネット／イントラネット、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）／ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等の各種ネットワークのいずれかでありうる。また、有線通信インタフェースは、Ｅｔｈｅｒｎｅｔ（登録商標）規格に従うインタフェースでありうるが、他のインタフェースが用いられてもよい。無線通信インタフェースは、ＩＥＥＥ８０２．１１規格シリーズに準拠した無線ＬＡＮ規格に準拠したインタフェースであってもよいし、３Ｇ／４Ｇ／ＬＴＥ等のＷＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の規格に準拠するインタフェースが用いられてもよい。なお、無線接続形態として、インフラストラクチャネットワークでの接続が用いられてもよいし、アドホックネットワークでの接続が用いられてもよい。また、通信網３００は、有線通信路と無線通信路との組み合わせによって構成されてもよい。すなわち、受信装置１００と送信装置２００との間で接続が確立されて通信が行われる限りにおいて、通信網３００は任意の形式を有してもよい。
【００１４】
（受信装置の構成）
図２に、本実施形態に係る受信装置１００のハードウェア構成を示す。受信装置１００は、そのハードウェア構成として、例えば、記憶部１２１、制御部１２２、機能部１２３、入力部１２４、出力部１２５、及び通信部１２６を有する。なお、図２の構成は一例であり、受信装置１００は、図２に示す構成の一部のみを有してもよいし、図２に示される以外の構成を有してもよい。
【００１５】
記憶部１２１は、ＲＯＭ、ＲＡＭの両方、または、いずれか一方の、１以上のメモリにより構成され、後述する各種動作を行うためのプログラムや、無線通信のための通信パラメータ等の各種情報を記憶する。ここで、ＲＯＭはＲｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙの略であり、ＲＡＭはＲａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙの略である。なお、記憶部１２１として、ＲＯＭ、ＲＡＭ等のメモリの他に、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＤＶＤなどの記憶媒体が用いられてもよい。
【００１６】
制御部１２２は、例えば、ＣＰＵやＭＰＵ等の１つ以上のプロセッサ、ＡＳＩＣ（特定用途向け集積回路）、ＤＳＰ（デジタルシグナルプロセッサ）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）等により構成される。ここで、ＣＰＵはＣｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔの、ＭＰＵは、Ｍｉｃｒｏ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔの頭字語である。制御部１２２は、記憶部１２１に記憶されたプログラムを実行することにより受信装置１００の全体を制御する。なお、制御部１２２は、記憶部１２１に記憶されたプログラムとＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）との協働により受信装置１００の全体を制御するようにしてもよい。
【００１７】
また、制御部１２２は、機能部１２３を制御して、撮像や印刷、投影等の所定の処理を実行する。機能部１２３は、受信装置１００が所定の処理を実行するためのハードウェアである。例えば、受信装置１００がカメラである場合、機能部１２３は撮像部であり、撮像処理を行う。機能部１２３が処理するデータは、記憶部１２１に記憶されているデータであってもよいし、後述する通信部１２６を介してＳＴＡと通信したデータであってもよい。
【００１８】
入力部１２４は、ユーザからの各種操作の受付を行う。出力部１２５は、ユーザに対して各種出力を行う。ここで、出力部１２５による出力とは、画面上への表示や、スピーカによる音声出力、振動出力等の少なくとも１つを含む。なお、タッチパネルのように入力部１２４と出力部１２５の両方を１つのモジュールで実現するようにしてもよい。
【００１９】
通信部１２６は、有線通信又は無線通信の制御や、ＩＰ通信の制御を行う。受信装置１００は通信部１２６を介して、映像データや音声データ等のメディアコンテンツを他の通信装置（送信装置２００）と通信する。
【００２０】
図３は、受信装置１００の機能構成例を示す図である。受信装置１００は、一例において、ブラウザＵＩ部１４１、ブラウザエンジン部１４２、コンポーネント部１４３を含んで構成される。ブラウザＵＩ部１４１は、アドレスバー、進む／戻るボタン、ブックマークメニューなど、ブラウジングのために必要なユーザインタフェースを提供する。ブラウザエンジン部１４２は、例えば、解析エンジン部１４４、レンダリングエンジン部１４５、コールバック部１４６、及びコールバック許可判定部１４７を含んで構成される。解析エンジン部１４４は、ＨＴＭＬやスタイルシート等の解析を行う。レンダリングエンジン部１４５は、解析エンジン部１４４の解析結果に基づいて、コンポーネント部１４３の機能を利用してＨＴＭＬを構成する各パーツをレンダリングし、レイアウト表示する機能を有する。コールバック部１４６は、受信装置１００が所定のデータを受信した際に、登録された所定の関数をコールバック実行する。コールバック許可判定部１４７は、コールバック部１４６で実行する関数の登録を許可するか否かを判定する。コンポーネント部１４３は、ネットワーク部１４８、ＪａｖａＳｃｒｉｐｔインタープリタ部１４９、ストレージ部１５０、ＭＳＥ部１５１、フォント部１５２、グラフィック部１５３等の機能モジュールを含んで構成される。ネットワーク部１４８は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）リクエストの送信や、サーバからのコンテンツ受信等のネットワークアクセスに関する処理を実行する。ＪａｖａＳｃｒｉｐｔインタープリタ部１４９は、ＪａｖａＳｃｒｉｐｔを解析して実行する。ストレージ部１５０は、サーバから受信したデータを半永続的に保管するキャッシュ機能を提供する。ＭＳＥ部１５１は、受信した映像データや音声データをデコードして、再生／表示する。なお、ＭＳＥは、ＨＴＴＰでストリーミング再生するために作られたＪａｖａＳｃｒｉｐｔ用のＡＰＩである、Ｍｅｄｉａ  Ｓｏｕｒｃｅ  Ｅｘｔｅｎｓｉｏｎの頭字語である。フォント部１５２とグラフィック部１５３は、各々、テキストフォントと画像データを表示用にレンダリングする機能を提供する。なお、図３に示す各機能部は、ＡＳＩＣ等の専用のハードウェア又はソフトウェアとして受信装置に実装されうる。ハードウェアとして実装される場合は、各機能部それぞれ又はいくつかをまとめた専用のハードウェアモジュールとして実装可能である。ソフトウェアとして実装される場合には、各機能部を実行するためのプログラムが前述の送信装置の記憶部１２１に記憶され、制御部１２２のプロセッサにより適宜読み出されて実行される。
【００２１】
（セグメントの生成と取得までの時間差）
続いて、Ｗｅｂサーバにおいてセグメントが生成されてから、受信装置のアプリケーションにおいてそのセグメントが取得されるまでの時間差について、サーバプッシュを利用しない場合とサーバプッシュを利用する場合とについて概説する。
【００２２】
図４は、ＭＰＥＧ−ＤＡＳＨにおいてサーバプッシュを利用しない従来技術の処理内容を例示するシーケンス図である。なお、ＭＰＥＧ−ＤＡＳＨは、Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ−Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰの頭字語である。ＭＰＥＧ−ＤＡＳＨでは、映像データが所定時間長のセグメントに分割され、各セグメントを取得するためのＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）が、プレイリストと呼ばれるファイルに記述される。クライアントは、初めにこのプレイリストを取得し、プレイリストに記述されている情報を用いて、所望のセグメントを送信装置へ要求することにより、そのセグメントを取得する。例えば、解像度やビットレート等が異なる複数のセグメントの取得情報がプレイリストに記載され、クライアントは、欲しいセグメントをサーバに要求する。
【００２３】
図４において、Ｗｅｂサーバは、ＭＰＥＧ−ＤＡＳＨによるメディアデータの配信機能を持ち、Ｗｅｂブラウザは、図３のような構成を有する受信装置１００において動作するＷｅｂブラウザである。図４のシーケンス４０１において、Ｗｅｂブラウザは、まずＷｅｂサーバからＨＴＭＬを取得して解析し、ページの表示に必要なＪａｖａＳｃｒｉｐｔであるｄａｓｈ．ｊｓをＷｅｂサーバから取得する。ここで、ｄａｓｈ．ｊｓは、ＭＰＥＧ−ＤＡＳＨのクライアントとして機能するＷｅｂアプリである。次に、ｄａｓｈ．ｊｓがＷｅｂブラウザ上で実行されると、シーケンス４０２において、ｄａｓｈ．ｊｓが、ＭＰＥＧ−ＤＡＳＨのプレイリストであるＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）をＷｅｂサーバから取得する。そして、ｄａｓｈ．ｊｓは、セグメントのデコードに必要な情報である初期化セグメントを取得する。そして、ｄａｓｈ．ｊｓは、シーケンス４０３において、Ｎ番目のセグメントであるセグメントＮを取得し、続いてセグメントＮ＋１、Ｎ＋２・・を順に取得する。なお、図４のシーケンスでは、Ｎ番目のセグメントから映像表示が開始される。受信装置１００は、このようにして取得したセグメントについて、順次、ＭＳＥ部１１１の機能を利用して再生処理を行うことにより、メディアデータのストリーミング再生を実行することができる。なお、図４の４０４によって示される経過時間は、Ｗｅｂサーバ側におけるセグメントＮ＋１の生成完了から、そのセグメントをｄａｓｈ．ｊｓが取得するまでの時間を示している。
【００２４】
次に、ＭＰＥＧ−ＤＡＳＨ  ｐａｒｔ６として規格化されたＨＴＴＰ／２を利用したストリーミング配信について、図５を用いて説明する。上述のように、ＭＰＥＧ−ＤＡＳＨでは、例えば解像度やビットレート等が異なる複数のセグメントの取得情報がプレイリストに記載され、クライアントは、欲しいセグメントをサーバに要求する。その一方で、サーバプッシュでは、Ｗｅｂサーバがプッシュするデータを決定するのが一般的である。このため、ＭＰＥＧ−ＤＡＳＨ  ｐａｒｔ６では、プッシュして欲しいセグメントの情報をクライアントからサーバに通知する仕組みが規定されている。
【００２５】
図５は、ＭＰＥＧ−ＤＡＳＨにおいて、サーバプッシュを利用する処理内容を例示するシーケンス図である。図５において、初期化セグメントの取得までは、図４の処理内容（シーケンス４０１及び４０２）と同様である。シーケンス５０１において、ｄａｓｈ．ｊｓは、Ｗｅｂサーバに対してセグメントＮの取得要求を行うと共に、ＭＰＥＧ−ＤＡＳＨ  ｐａｒｔ６で定義されたＰｕｓｈ  Ｄｉｒｅｃｔｉｖｅ（プッシュ指示）により、続くセグメントのプッシュを指示する。図５の記載例では、ａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙヘッダによってプッシュ指示が示されており、セグメントＮに続く３つのセグメントのプッシュ配信が指示される。Ｗｅｂサーバは、セグメントのプッシュ指示を受信し、指示を実行可能である場合には、ＨＴＴＰ／２で定義されたＰＵＳＨ＿ＰＲＯＭＩＳＥフレームにより、セグメントＮ＋１、セグメントＮ＋２とセグメントＮ＋３の送信を予告する。そして、Ｗｅｂサーバは、ＭＰＥＧ−ＤＡＳＨ  ｐａｒｔ６で定義されたＰｕｓｈ  Ｄｉｒｅｃｔｉｖｅへの返答（ｐｕｓｈ−ｐｏｌｉｃｙヘッダ）をＷｅｂブラウザへ返信し、その際に、セグメントＮを送信する。
【００２６】
シーケンス５０２において、Ｗｅｂサーバは、セグメントＮ＋１の生成を完了し次第、Ｗｅｂブラウザにそのセグメントのプッシュ配信を行う。この場合、配信されたセグメントＮ＋１は、Ｗｅｂブラウザのキャッシュに保管される。ｄａｓｈ．ｊｓは、この後に、ＧＥＴメソッドによってセグメントＮ＋１を要求することにより、セグメントＮ＋１をＷｅｂブラウザのキャッシュから取得することができる。図５では、５０３によって、ＷｅｂサーバにおいてセグメントＮ＋１の生成が完了してから、ｄａｓｈ．ｊｓがそのセグメントを取得するまでの経過時間が示されている。図５の手順によれば、図４における経過時間４０４と比較すると、Ｗｅｂサーバまで取得要求が届くまでの時間と、要求したデータがＷｅｂサーバから到着するまでの時間を合わせた伝送にかかる時間が削減される。その一方で、ｄａｓｈ．ｊｓが実際にデータを取得することができるタイミングは、プッシュされたデータを、ｄａｓｈ．ｊｓがＧＥＴメソッドにより取得するタイミングとなる。このため、ＧＥＴメソッドのタイミングが遅れれば、その分、図５の５０３に示す経過時間も大きくなってしまう。
【００２７】
なお、ｄａｓｈ．ｊｓは、ＭＰＤに記載された時刻情報に基づいて、各セグメントの取得可能時刻を計算してセグメントを取得しうるが、ｄａｓｈ．ｊｓが動作するＷｅｂブラウザの動作環境によっては、セグメントを取得するタイミングがずれてしまいうる。その結果、特に長時間ストリーミング再生を行う場合に、セグメント生成からｄａｓｈ．ｊｓがセグメントを取得するまでの時間差が大きくなってしまうこともある。
【００２８】
（処理の概要）
続いて、上述のような時間差を削減する方法の例について、説明する。図６は、本実施形態における受信装置の処理内容を示したシーケンス図である。図６においても、初期化セグメントの取得までは、図４のシーケンス４０１及び４０２の処理内容と同様である。シーケンス６０１において、ｄａｓｈ．ｊｓは、セグメントＮ＋１〜Ｎ＋３についてのプッシュ指示を行うと共に、６０３に示すように、Ｗｅｂブラウザに対してコールバック登録要求を発行する。このコールバック機能は、登録が許可された場合にコールバック部１４６で実行されるもので、プッシュ指示したセグメントを受信したタイミングで、登録された所定の関数を実行するものである。Ｗｅｂブラウザは、例えば、ＷｅｂサーバからＰＵＳＨ＿ＰＲＯＭＩＳＥフレームによりプッシュ配信の予告が通知されると、図６の６０４において、コールバック許可判定部１４７によりコールバック登録を許可するか否かを判定する。本実施形態では、コールバック登録が許可された場合のみ、コールバック関数が実行される。コールバック登録の判定結果は、６０５に示されるように、ｄａｓｈ．ｊｓへ、戻り値として通知されうる。その後のＰｕｓｈ  Ｄｉｒｅｃｔｉｖｅの返答とセグメントＮの送信・取得は、図５と同様である。
【００２９】
続いて、図６のシーケンス６０２において、Ｗｅｂサーバは、セグメントＮ＋１を、生成し次第、Ｗｅｂブラウザへ送信する。この場合、図６の６０６に示すように、Ｗｅｂブラウザは、登録された所定の関数を実行する。Ｗｅｂブラウザにおいて所定の関数が実行されることにより、ｄａｓｈ．ｊｓは、例えばセグメントＮ＋１が保管された位置とサイズの情報を知ることができる。ｄａｓｈ．ｊｓは、この情報によって、セグメントＮ＋１を取得することができる。この時、セグメントＮ＋１は、ｄａｓｈ．ｊｓからアクセス可能な領域に保管される。ただし、これに限られず、ｄａｓｈ．ｊｓからアクセスできない領域に、セグメントＮ＋１が保管されてもよい。セグメントＮ＋１がｄａｓｈ．ｊｓからアクセスできない領域に保管されている場合、ｄａｓｈ．ｊｓは、例えばＷｅｂブラウザが提供するＡＰＩ等により、アクセス可能な領域にセグメントＮ＋１を移動させる処理を実行しうる。以降、セグメントＮ＋２とセグメントＮ＋３についても同様に、セグメントが生成され次第、Ｗｅｂサーバから送信され、Ｗｅｂブラウザは、そのセグメントを受信するとコールバック登録された所定の関数を実行する。これにより、ｄａｓｈ．ｊｓは、セグメントをＷｅｂブラウザに滞留させることなく、再生処理を開始することができる。
【００３０】
（処理の流れ）
次に、本実施形態における受信装置１００のコールバック許可判定部１４７の処理内容について、図７および図８を用いて説明する。図７に、本実施形態における受信装置１００のコールバック許可判定の流れの例を示す。図７のフローチャートに示す各ステップは、例えば、受信装置の制御部１２２が記憶部１２１に記憶されたプログラムを読み出して実行することにより実施される。図８は、本実施形態におけるプッシュ指示のリクエストと、Ｗｅｂサーバによるレスポンスの一例を説明するための図である。図７では、まず、ｄａｓｈ．ｊｓは、ＭＰＤを取得し（Ｓ７０１）、ＷｅｂサーバにＰｕｓｈ  Ｄｉｒｅｃｔｉｖｅを通知することによってプッシュ指示を行う（Ｓ７０２）。そして、ｄａｓｈ．ｊｓは、コールバック関数の登録をＷｅｂブラウザに要求する（Ｓ７０３）。
【００３１】
ここで、Ｓ７０２及びＳ７０３の処理に関して図８を用いて説明する。まず、Ｓ７０２では、ｄａｓｈ．ｊｓは、図８の８０１の「：ｐａｔｈ」ヘッダの記述によって、セグメント１を要求する。また、ｄａｓｈ．ｊｓは、「ａｃｃｅｐｔ−ｐｕｓｈ−ｐｏｌｉｃｙ」ヘッダにおいて、要求したセグメント１に続く２つのセグメント（セグメント２〜３）のプッシュ配信を指示する。Ｓ７０３では、ｄａｓｈ．ｊｓは、プッシュ指示したセグメントを受信した際に呼び出すべきコールバック関数の登録を要求する。ｄａｓｈ．ｊｓは、図８の８０２に示すように、セグメント２とセグメント３を受信した時に呼び出されるコールバック関数１、２のそれぞれについて、セグメント２とセグメント３のそれぞれのパス情報をＷｅｂブラウザに通知する。
【００３２】
一方、Ｗｅｂサーバは、セグメントのプッシュ指示を受け付けると、図７のＳ７０４において、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームを通知して、プッシュ配信の予告を行う。この時のＰＵＳＨ＿ＰＲＯＭＩＳＥフレームには、図８の８０３と８０４に示すように、プッシュされるデータのパス情報が含まれる。Ｗｅｂブラウザは、Ｓ７０５において、Ｓ７０３のコールバック関数の登録要求の際に通知されたパス情報と、Ｓ７０４で受信したＰＵＳＨ＿ＰＲＯＭＩＳＥフレーム内のパス情報が一致するかを判定する。図８の例では、これらのパス情報が、それぞれ「／ｅｘａｍｐｌｅ／ｃｏｎｔｅｎｔｓ／ｓｅｇｍｅｎｔ２」と「／ｅｘａｍｐｌｅ／ｃｏｎｔｅｎｔｓ／ｓｅｇｍｅｎｔ３」であり、一致している。Ｗｅｂブラウザは、これらのパスが一致する場合、Ｓ７０６において要求されたコールバック関数を登録する。そして、Ｗｅｂブラウザは、図８の８０５、８０６に示すように、セグメント２及びセグメント３を受信したことに応じて、対応するコールバック関数１、２をそれぞれ実行する。なお、Ｗｅｂブラウザは、例えば、Ｗｅｂサーバから別のプッシュ配信の予告を受信した場合、そのプッシュ配信の予告に含まれるデータのパス情報が、ｄａｓｈ．ｊｓから通知されたパス情報と一致しない。このため、Ｗｅｂブラウザは、この（パス情報の一致しない）プッシュ配信に対しては、コールバック関数を実行しない。これにより、Ｗｅｂブラウザは、プッシュ配信されたデータを受信した際に、アプリケーションから事前に要求されたデータについてのみ、そのアプリケーションがそのデータを利用可能とするための所定の関数を自動で実行することができる。したがって、例えばＭＰＥＧ−ＤＡＳＨで要求するデータ以外のデータを受信した場合に、ｄａｓｈ．ｊｓにそのデータに関する情報を提供するなどの不必要な処理が行われることを防ぐことができる。
【００３３】
なお、図８のプッシュ指示のリクエストと、Ｗｅｂサーバによるレスポンスの例は一例に過ぎず、これら以外の形式が用いられてもよい。図９は、プッシュ指示のリクエストと、Ｗｅｂサーバによるレスポンスの別の例である。図９の例では、プッシュ指示とＰＵＳＨ＿ＰＲＯＭＩＳＥとの関連を明示的に示すことでセキュリティの向上を図ることができる。
【００３４】
図８の例では、コールバック関数の登録を許可するか否かを判定する条件として、パスが一致するか否かを比較する方法について説明した。一方、ＭＰＥＧ−ＤＡＳＨのように、クライアント側からの指示でデータをプッシュする仕組みが用いられる場合、プッシュ指示とＰＵＳＨ＿ＰＲＯＭＩＳＥの関連を明示することにより、セキュリティの向上を図ることができる。図９の例では、９０１に示すように、プッシュ指示を識別するための識別子として、例えば「Ｘ−ＲｅｑｕｅｓｔＩＤ」という任意のヘッダを追加して、この識別子をＷｅｂサーバへ通知する。また、図９の９０２に示すように、コールバック関数の登録要求においても、パス情報と共にこの識別子を指定する。
【００３５】
一方、Ｗｅｂサーバは、図９の９０３に示すように、ＰＵＳＨ＿ＰＲＯＭＩＳＥフレームに、例えば「Ｘ−ＲｅｓｐｏｎｓｅＩＤ」という任意のヘッダを追加し、プッシュ指示で通知された識別子を記載する。これにより、プッシュ指示とＰＵＳＨ＿ＰＲＯＭＩＳＥとが関連付けられる。また、Ｗｅｂブラウザは、コールバック関数の登録許可判断において、図９の９０２で示される識別子と、９０３で示されるＰＵＳＨ＿ＰＲＯＭＩＳＥフレームに記載された識別子とが一致する事を判断条件として用いる。この条件は、上述のパスの一致に加えて用いられてもよいし、パスの一致の代わりに用いられてもよい。これにより、ＰＵＳＨ＿ＰＲＯＭＩＳＥがプッシュ指示によるものであることを、より明確にすることができる。プッシュ指示を識別するための識別子は、プッシュ指示ごとに異なるものが用いられうる。これによれば、プッシュ指示と、本来対応しないＰＵＳＨ＿ＰＲＯＭＩＳＥとが関連付けられることを防ぐことができる。
【００３６】
なお、図９では、プッシュ指示とプッシュ予告に任意の識別子を付加して比較する例について説明したが、ＰＵＳＨ＿ＰＲＯＭＩＳＥがプッシュ指示によるものであることを明確にできる他の情報が用いられてもよい。例えば、識別子やパス情報に対して所定の計算処理を施して得られるハッシュ値による比較や、認証トークン情報などの付加によって、ＰＵＳＨ＿ＰＲＯＭＩＳＥがプッシュ指示によるものであることを特定可能としてもよい。すなわち、ｄａｓｈ．ｊｓからのコールバック関数の登録要求によって指定される情報と、ＰＵＳＨ＿ＰＲＯＭＩＳＥに含まれる情報は、対応関係が一意に特定できる限りにおいて、必ずしも一致する関係になくてもよい。
【００３７】
なお、本実施形態では、コールバック許可判定部１４７が許可した所定の関数のみが、コールバック実行される。このため、Ｗｅｂブラウザが取得した、メディアデータと関係しないデータに起因して、何らかの関数がコールバック実行されることを防ぐことができる。このため、不必要な関数の実行により、不必要なデータがアプリに取り込まれることを防ぎ、アプリが必要なデータを遅滞なく取得することができるようになる。
【００３８】
なお、上述の例では、ＨＴＴＰ／２によるサーバプッシュ機能を利用してＭＰＥＧ−ＤＡＳＨに基づいてメディアデータを取得する場合に関して説明したが、これらは一例であり、説明した規格以外の方式が使用されてもよい。すなわち、受信装置が、データを指定してプッシュ配信を要求し、その要求に従って配信されたデータがアプリケーション以外によって取得され、そのデータをアプリケーションが利用することができる限り、任意の方式が利用されうる。例えば、プッシュ配信がＨＴＴＰ／２以外の規格に従って実行されてもよいし、配信データの要求がＭＰＥＧ−ＤＡＳＨ以外の規格に従って行われてもよい。どのような規格が用いられたとしても、受信装置は、プッシュ配信されるデータの受信に基づいて、事前に登録した所定の関数を実行して、アプリケーションがそのデータを利用することができるようにする。このとき、受信装置は、所定の関数の登録要求時に取得する情報と、データの配信元の装置（例えばＷｅｂサーバ）から取得した情報（例えばプッシュ配信の予告）とに基づいて、所定の関数を登録するか否かを決定する。例えば、受信装置は、所定のアプリケーションから事前に通知された情報（例えばパス情報や識別子）が、データの配信元の装置から取得した情報に含まれている場合に、所定の関数を登録することを決定する。
【００３９】
＜その他の実施形態＞
以上、実施形態例を詳述したが、本発明は例えば、システム、装置、方法、プログラム、または、記録媒体（記憶媒体）等としての実施態様をとることが可能である。具体的には、複数の機器（例えば、ホストコンピュータ、インタフェース機器、撮像装置、ｗｅｂアプリケーション等）から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。
【００４０】
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００４１】
本発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。
【符号の説明】
【００４２】
１００：受信装置、１４２：ブラウザエンジン部、１４６：コールバック部、１４７：コールバック許可判定部、２００：送信装置
【図１】
2020140393.tif 000003
【図２】
2020140393.tif 000004
【図３】
2020140393.tif 000005
【図４】
2020140393.tif 000006
【図５】
2020140393.tif 000007
【図６】
2020140393.tif 000008
【図７】
2020140393.tif 000009
【図８】
2020140393.tif 000010
【図９】
2020140393.tif 000011