JP5657686B2 - ストリーミングメディア受信装置におけるスタンバイ処理のための方法、および装置 - Google Patents

Description

本発明は、広くには、スタンバイモードに関し、より具体的には、ストリーミングメディア受信装置におけるスタンバイモードに関する。

家庭用電化製品の事業においては、電力の消費が大いに注目され、どれだけの電力が消費されるべきかについての指針が導かれている。指針の主役は、装置がスタンバイであるときに使用される電力が１ワット未満であることである。

これらの指針は、インターネットプロトコルテレビジョン（ＩＰＴＶ）用のセットトップボックスなどのストリーミングメディア受信装置にも適用される。１Ｗ未満のスタンバイモードにおいて、ストリーミングメディア受信装置において実行できる機能は最低限である。そのような機能として、赤外線（ＩＲ）の監視（機器のオンモードへの移行を可能にする）、インターネットプロトコル（ＩＰ）ウェイクアップの監視、およびウェイクアップイベントを有するチップを挙げることができる。

テレビ受像機およびセットトップボックスにおいては、２つの異なる種類のスタンバイが存在する。上述の一のスタンバイは、「パッシブスタンバイ」と呼ばれることが多いが、「アクティブスタンバイ」と呼ばれる他のスタンバイが存在する。アクティブスタンバイは、機器の電源がオンであるときの状態によく似ている。アクティブスタンバイと電源オン状態との間の相違は、画面（または、セットトップボックスの場合の表示出力）が動作していない点にある。

本発明の目的は、ストリーミングメディア受信装置のスタンバイモードに関して、柔軟性の向上をもたらすことにある。

本発明の第１の態様においては、ネイティブソフトウェアと、ウェブアプリケーションを実行するためのウェブソフトウェアとを備えるストリーミングメディア受信装置において実行される方法が提示される。この方法は、ウェブソフトウェアにおいて実行されている動作中のウェブアプリケーションにて、ストリーミングメディア受信装置がパッシブスタンバイモードへ移行する旨を知らせるメッセージを受信するステップと、動作中のウェブアプリケーションからアプリケーションサーバへ、保存すべきデータを含むメッセージを送信するステップと、動作中のウェブアプリケーションからネイティブソフトウェアへ、動作中のウェブアプリケーションの再開予定時刻を知らせるメッセージを送信するステップと、ネイティブソフトウェアからタイマを、ウェブアプリケーションの再開予定時刻へ設定するステップと、ストリーミングメディア受信装置をパッシブスタンバイモードに設定するステップと、ネイティブソフトウェアにおいて、タイマが満了した旨の信号を受信するステップと、ストリーミングメディア受信装置をアクティブスタンバイモードに設定するステップと、ネイティブソフトウェアからウェブアプリケーションへ、タイマが満了した旨のメッセージを送信するステップと、動作中のウェブアプリケーションにおいて、保存したデータを含むメッセージをアプリケーションサーバから受信するステップとを含む。

上述の方法は、柔軟でありながら依然としてセキュアであるウェブアプリケーションの一時停止の方法を提供する。さらに、パッシブスタンバイへの移行に先立ってデータをアプリケーションサーバに保存することによって、データがデータの送信元のストリーミングメディア受信装置に縛られることがない。換言すると、ユーザが、第１の受信装置をスタンバイに移行させ、第２の受信装置の電源を投入し、第２の受信装置が第１の受信装置と同じウェブアプリケーションの状態で起動することができる。これは、例えばユーザが或る部屋から次の部屋へ移動する場合に有用となり得る。

この方法は、保存したデータを含むメッセージを受信するステップに先立って、ウェブアプリケーションサーバからアプリケーションサーバへ、保存したデータを送信するようにとの要求を送信するステップをさらに含むことができる。

ネイティブソフトウェアへメッセージを送信するステップは、ウェイクアップ時に辿るべきユニフォームリソースインジケータ（ＵＲＩ）の設定を含むことができる。

ネイティブソフトウェアへメッセージを送信するステップは、動作中のウェブアプリケーションからの補足の情報を含むトークンを設定するステップを含むことができる。換言すると、トークンは、ネイティブアプリケーションによって保存することができる補足の情報を含むデータコンテナであってよい。これを、後に、再開時のウェブアプリケーションによって取り出すことができる。

この方法を、インターネットプロトコルテレビジョン（ＩＰＴＶ）に準拠したストリーミングメディア受信装置において実行することができる。

本発明の第２の態様は、ネイティブソフトウェアと、ウェブアプリケーションを実行するためのウェブソフトウェアとを備えるストリーミングメディア受信装置のためのコンピュータプログラムである。このコンピュータプログラムは、コンピュータプログラムコードを含んでおり、このコンピュータプログラムコードが、ストリーミングメディア受信装置において実行されるときに、ウェブソフトウェアにおいて実行されている動作中のウェブアプリケーションにて、ストリーミングメディア受信装置がパッシブスタンバイモードへ移行する旨を知らせるメッセージを受信することと、動作中のウェブアプリケーションからアプリケーションサーバへ、保存すべきデータを含むメッセージを送信することと、動作中のウェブアプリケーションからネイティブソフトウェアへ、動作中のウェブアプリケーションの再開予定時刻を知らせるメッセージを送信することと、ネイティブソフトウェアからタイマを、ウェブアプリケーションの再開予定時刻に設定することと、ストリーミングメディア受信装置をパッシブスタンバイモードに設定することと、ネイティブソフトウェアにおいて、タイマが満了した旨の信号を受信することと、ストリーミングメディア受信装置をアクティブスタンバイモードに設定することと、ネイティブソフトウェアからウェブアプリケーションへ、タイマが満了した旨のメッセージを送信することと、動作中のウェブアプリケーションにおいて、保存したデータを含むメッセージをアプリケーションサーバから受信することとを、ストリーミングメディア受信装置に実行させるコンピュータプログラムコードを備える。

本発明の第３の態様は、第３の態様によるコンピュータプログラムと、このコンピュータプログラムが保存されたコンピュータにとって読み取り可能な手段とを含んでいるコンピュータプログラム製品である。

本発明の第４の態様は、ストリーミングメディア受信装置であり、そのようなストリーミングメディア受信装置が、ネイティブソフトウェアと、ウェブアプリケーションを実行するためのウェブソフトウェアと、タイマと、ウェブソフトウェアのウェブアプリケーションに位置し、当該ストリーミングメディア受信装置がパッシブスタンバイモードへ移行する旨を知らせるメッセージを受信するように構成されたモード変更検出部と、ウェブアプリケーションに位置し、動作中のウェブアプリケーションの再開予定時刻を知らせるメッセージをネイティブソフトウェアへ送信するように構成された再開モジュールと、ネイティブソフトウェアに位置し、ウェブアプリケーションの再開予定時刻でタイマを設定するように構成されたタイマ設定部と、当該ストリーミングメディア受信装置をタイマの設定後にパッシブスタンバイモードに設定し、またはタイマの満了後にアクティブスタンバイモードに設定するように構成されたモード変更部と、ネイティブソフトウェアに位置し、タイマが満了した旨の信号を受信するとともに、タイマが満了した旨のメッセージをウェブアプリケーションへ送信するように構成されたタイマハンドラと、ウェブアプリケーションに位置し、パッシブスタンバイモードへの移行に先立って保存すべきデータを含むメッセージをアプリケーションサーバへ送信するとともに、保存したデータを含むメッセージをパッシブスタンバイモードからの離脱後にアプリケーションサーバから受信するように構成されたデータハンドラとを備えている。

第１、第２、第３、および第４の態様のいずれの特徴も、任意の他の態様へ適宜に適用できることに注意すべきである。

一般に、特許請求の範囲において使用されるすべての用語は、本明細書において別の定義が明示的になされていない限り、技術分野における通常の意味に従って解釈されなければならない。「構成要素、装置、部品、手段、工程、など」への言及はすべて、とくにそのようでないと明示的に述べられない限りは、そのような構成要素、装置、部品、手段、工程、などが少なくとも１つ存在することを、他を排除することなく意味するものと解釈されなければならない。本明細書に開示の方法の各段階は、とくに明示されない限り、開示されたとおりの順序で実施される必要はない。

次に、本発明を、添付の図面を参照しつつ、あくまでも実施例として説明する。
一実施形態を適用することができるインターネットプロトコルテレビジョン（ＩＰＴＶ）環境の概要を示す概略図である。 図１のストリーミングメディア受信装置によってもたらされるログイン画面の表示の概略図である。 図１のストリーミングメディア受信装置によってもたらされる録画予約画面の表示の概略図である。 予約録画について使用される本発明の実施形態を説明するシーケンス図である。 サーバからのプッシュによる録画に使用される本発明の実施形態を説明するシーケンス図である。 図１のストリーミングメディア受信装置におけるスタンバイモードを説明する状態図である。 図１のストリーミングメディア受信装置において実行できる方法を説明するフロー図である。 図１のストリーミングメディア受信装置の概略図であり、ストリーミングメディア受信装置の別のモジュールの図を示している。 コンピュータにとって読み取り可能な手段を備えているコンピュータプログラム製品の一実施例を示している。

次に、本発明を、添付の図面を参照しつつ、以下でさらに詳しく説明する。添付の図面には、本発明の特定のいくつかの実施形態が示されているが、本発明は、多数のさまざまな形態にて具現化が可能であり、本明細書に記載の実施形態に限られないと理解されるべきである。むしろ、これらの実施形態は、本明細書の開示が徹底的かつ完結しており、本発明の範囲を当業者に充分に伝えることができるように、あくまでも実施例として提示されている。類似の番号は、説明の全体を通して類似の構成要素を指し示している。

図１が、本発明の一実施形態を適用することができるインターネットプロトコルテレビジョン（ＩＰＴＶ）環境の概要を示す概略図である。ストリーミングメディア受信装置１が、ブラウザ１０、ネイティブソフトウェア１３、およびハードウェア１５を備えている。

ブラウザ１０は、ダイナミックＨＴＭＬをサポートし、すなわちＨＴＭＬ、ならびにＪａｖａＳｃｒｉｐｔなどのクライアント側のスクリプティング、ＣＳＳなどのプレゼンテーション定義言語、およびドキュメントオブジェクトモデルをサポートするウェブブラウザであってよい。これに代え、あるいはこれに加えて、ブラウザは、Ａｄｏｂｅ ｆｌａｓｈ、ＳＶＧ（スケーラブルベクターグラフィクス）、などといった他の種類のコンテンツをサポートすることができる。ブラウザは、ストリーミングメディア受信装置１における１つまたは複数のウェブアプリケーション１１の実行を可能にし、それによってウェブアプリケーション１１が、それ自身は当技術分野おいて知られているとおり、ＩＰ（インターネットプロトコル）ネットワークを介してアプリケーションサーバ２とやり取りをすることができる。このようにして、ストリーミングメディア受信装置１は、オープンＩＰＴＶ端末機能（ＯＩＴＦ）を動作させる宣言型アプリケーション環境（ＤＡＥ）に従う。

アプリケーションサーバ２は、ウェブサーバなど、ウェブアプリケーション１１をサポートするコンテンツサーバである。アプリケーションサーバ２は、サーバ側のコードを使用し、例えばＰＨＰ（Ｈｙｐｅｒｔｅｘｔ Ｐｒｅｐｒｏｃｅｓｓｏｒ）、Ｊａｖａ Ｐｌａｔｆｏｒｍ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ、Ｍｉｃｒｏｓｏｆｔ．ＮＥＴ Ｆｒａｍｅｗｏｒｋ、などを使用して、ブラウザへコンテンツを動的に供給する能力を有している。アプリケーションサーバは、１つまたは複数のＣＰＵ（中央演算ユニット）と、ハードドライブなどの永続的な記憶装置と、ＲＡＭ（図示されていない）などの内部メモリとを備える。

コンテンツサーバ４は、ここではＩＧＭＰ（インターネットグループ管理プロトコル）コマンドのためのサーバを集合的に代表し、ＩＰネットワークを介してストリーミングメディア受信装置１へ実際のメディアストリーミングをもたらす。コンテンツサーバの機能を、随意により協働するいくつかのサーバによって提供してもよい。

メディアストリーミング受信装置１は、テレビ受像機５へ接続される。これは、ストリーミングメディア受信装置１を使用してコンテンツサーバ４からのコンテンツを視聴することを可能にするだけでなく、ストリーミングメディア受信装置１が自身のユーザインターフェイスのための表示装置としてテレビ受像機５を使用することも可能にする。メディアストリーミング受信装置１からの音声を、テレビ受像機５へ出力することができ、または随意による増幅器（図示されていない）へ出力することができる。

ストリーミングメディア受信装置のネイティブソフトウェア１３は、ＩＰを介してコンテンツサーバ４とやり取りをするためのＩＧＭＰモジュール１４を備えている。さらに、ネイティブソフトウェアは、ハードウェアタイマ１８とのやり取りのためのソフトウェアを含んでいる。

ストリーミングメディア受信装置１のハードウェア１５は、ＣＰＵ１６と、ＩＲ受信器１７と、タイマ１８と、ハードドライブあるいは他の永続的な磁気、光、および／または半導体記憶装置１９と、ＲＡＭ（ランダム・アクセス・メモリ）などの内部メモリ２０とを備えている。タイマ１８は、別個のハードウェアユニットであってよく、または他の適切な低消費電力の素子を使用して実現されてもよい。

ストリーミングメディア受信装置１がパッシブスタンバイモードにあるとき、ブラウザ１０、ネイティブソフトウェア１３、ハードドライブ１９、およびＣＰＵ１６は、いずれも動作していない。ストリーミングメディア受信装置１がアクティブスタンバイモードにあるとき、ストリーミングメディア受信装置の図１に示したすべての構成要素は、動作中である。

ストリーミングメディア受信装置１は、別個の装置であってよく、またはセットトップボックスまたはテレビ受像機５に一体化されてもよい。代案として、ストリーミングメディア受信装置１を、パーソナルコンピュータなどの汎用のコンピュータや、メディア再生機またはゲーム機などのよりメディアに関係したデバイスを使用して実現してもよい。

図２ａが、図１のストリーミングメディア受信装置によってもたらされるログイン画面３０の表示の概略図である。このログイン画面は、ストリーミングメディア受信装置のユーザがユーザ名およびパスワードを入力することができる単純なユーザの認証を示している。

図２ｂは、図１のストリーミングメディア受信装置によってもたらされる録画予約画面の表示３１の概略図である。画面の表示３１を、図１のテレビ受像機５において目にすることができる。画面の表示３１は、チャンネルが縦に示され、時間が横に示されている行列タイプの配置の概略の電子番組ガイド（ＥＰＧ）を示している。暗くされた長方形３２が、チャンネル２を９〜１０の間について録画すべきであることを示しており、これを図３ａに関して説明されるウェイクアップの仕組みを使用して達成することができる。

図３ａが、予約録画について使用される本発明の実施形態を説明するシーケンス図である。このシーケンスの開始時に、ウェブアプリケーション１１およびアプリケーションサーバ２を使用する従来からのユーザインターフェイス（ＵＩ）４０が有効である。この従来からのＵＩによって、ユーザは、例えば選局の制御、ＥＰＧの閲覧、録画の予約、などを行なうことができる。随意により、従来からのユーザインターフェイス４０の図２ａに示したユーザ認証の証明書などが、ウェブブラウザ１０またはネイティブソフトウェア１３に保存される。

最初に、ストリーミングメディア受信装置１のユーザが、例えばストリーミングメディア受信装置１のリモコン（図示されていない）のスタンバイキーを押すことによって、ストリーミングメディア受信装置をスタンバイモードにするように指示する。この信号が、ＩＲ受信器１７によって受信され、ＩＲ受信器が、ストリーミングメディア受信装置１がパッシブスタンバイモードに移行しつつあることを知らせる信号４１を、ネイティブソフトウェア１３へ送信する。次いで、ネイティブソフトウェア１３が、動作中のウェブアプリケーション１１に対して、ストリーミングメディア受信装置１がパッシブスタンバイモードに移行しつつある旨の通知４２を行なう。以下では、分かりやすくするために、ただ１つのウェブアプリケーションについての処理が開示される。２つ以上のウェブアプリケーションが存在する場合には、それらのウェブアプリケーションの各々が、本明細書に開示の内容に従って自身の処理を実行する。

動作中のウェブアプリケーション１１は、この情報に対してすばやく働くことによって応答する。動作中のウェブアプリケーション１１は、随意により、保存すべきデータ４３を伴うメッセージをアプリケーションサーバへ送信することができる。例えば、ユーザのナビゲーションの状態などの現在の状態、あるいはウェブアプリケーションの現在のデータまたは設定データなどを、このやり方で保存することができる。アプリケーションサーバ２がメッセージを受信し、データの保存７０を適切に行なう。しかしながら、データ４３の送信およびアプリケーションサーバ２によるデータの保存の実行について待ち時間が存在し得るがゆえに、保存７０が完了するときまでに、ストリーミングメディア受信装置１がすでにパッシブスタンバイモードとなっている可能性がある。したがって、ストリーミングメディア受信装置１は、時間を節約するために、アプリケーションサーバ２からの確認の応答を待つ必要がない。

また、動作中のウェブアプリケーション１１は、ウェイクアップの準備のためにネイティブソフトウェア１３へメッセージ４４を送信する。このメッセージ４４は、ウェブアプリケーション１１の再開予定時刻を含み、随意によりウェブアプリケーション１１を再開すべきＵＲＩ（ユニフォームリソースインジケータ）を含む。随意により、ＵＲＩは、呼び出し元のウェブアプリケーション１１と同じドメインを有するＵＲＩなど、呼び出し元のウェブアプリケーション１１に対応するパターンに一致しなければならない。これは、悪意のあるコードによって望ましくない出所からのコードが実行すべきコードとして計画されることを防止することによって、セキュリティを向上させる。随意により、メッセージ４４は、ウェブアプリケーション１１の再開時にウェブアプリケーションにとって利用可能であることが望まれる任意のさらなるデータを含むデータコンテナであるトークンを含む。

次いで、ネイティブソフトウェア１３は、タイマ１８へタイマ設定メッセージ４５を送信し、ウェブアプリケーション１１からのウェイクアップ準備メッセー４４から決定される時刻に信号を送信するようにタイマを設定する。

次いで、ストリーミング・メディア・サーバが、パッシブスタンバイモード４６へ移行する。これを、例えば５００ミリ秒など、スタンバイメッセージ４１の受信からの特定の時間で生じさせることができる。他の適切な時間を、処理時間の要件とユーザへの高速な応答の提供とのバランスを念頭に、自由に選択することができる。これに代え、あるいはこれに加えて、パッシブスタンバイ４６を、タイマ設定メッセージ４５の送信後に生じさせてもよい。これら２つの選択肢が組み合わせられる場合には、パッシブスタンバイモードへの最初のトリガによって、パッシブスタンバイモードを達成することができる。

タイマ設定メッセージ４５によって示された時刻において、タイマ１８が、ネイティブソフトウェアへウェイクアップ信号４７を送信する。ネイティブソフトウェア１３が、ストリーミングメディア受信装置１をアクティブスタンバイ状態にし、例えばウェイクアップ準備メッセージ４４によって供給されたＵＲＩを使用することによって、ウェブアプリケーション１１へウェイクアップメッセージ４８を送信する。ウェブアプリケーション１１は、再開後に、パッシブスタンバイ４６への移行前に保存したデータを取得すべく、アプリケーションサーバ２へメッセージ６３を送信する。応答として、アプリケーションサーバ２が、要求されたデータ６４を送信する。

随意により、ウェブアプリケーションは、ネイティブソフトウェア１３へクリア・トークン・メッセージ４９を送信することによってトークンを要求し、ネイティブソフトウェア１３が、応答において、トークン５０をウェブアプリケーション１１へ送信し、トークンをネイティブソフトウェア１３から削除する。随意により、トークンを、トークンがウェブアプリケーション１１へ送信された旨を示す（さらに随意により、トークンがいつウェブアプリケーション１１へ送信されたかを示す）フラグを添えて、ネイティブソフトウェアに保持してもよい。一実施形態においては、トークンが、プロセスをより効率的にするためにウェイクアップメッセージ４８に含まれる。

随意により、ウェブアプリケーションの認証５１が、ウェブブラウザを使用し、例えば保存された信用証明物を使用して、アプリケーションサーバ２によって行なわれる。換言すると、ウェブアプリケーションが自らの真正を証明するのではなく、ウェブアプリケーションの真正が、ウェブブラウザまたはネイティブソフトウェアによって確認される。これは、アクティブスタンバイ状態においてはいかなるＵＩも利用可能でなく、したがってウェブアプリケーションがユーザから信用証明物を受け取ることができないため、有益である。

上記開示の各ステップは、すべてのアプリケーションについて共通である。次に、予約録画の開始のためにさらなる処理が使用されるシナリオを説明する。ここで、ウェブアプリケーションが、アプリケーションサーバへＳＩＰ（セッション開始プロトコル）ＩＮＶＩＴＥメッセージ５２を送信し、すべてがＯＫである場合の応答が、ＳＩＰ ＯＫメッセージ５３である。ウェブアプリケーションが動作中であり、ＳＩＰが使用されているため、ポリシーサーバ（図示されていない）を使用して、この特定のメディアストリーミング受信装置１についてメディアの受信が許されていること、および 受信するのに充分な帯域幅が存在することを確認することができる。

次いで、ウェブアプリケーション１１が、ネイティブソフトウェア１３へ録画メッセージ５４を送信する。次いで、ネイティブソフトウェア１３（より具体的には、ＩＧＭＰモジュール１４）が、コンテンツサーバ４へＩＧＭＰ ＪＯＩＮメッセージ５５を送信する。コンテンツサーバ４が、実際のコンテンツをマルチキャストストリーム５６にてネイティブソフトウェア１３へ送信することによって応答する。ネイティブソフトウェア１３は、停止メッセージ５８がウェブアプリケーション１１からネイティブソフトウェアへ送信されるまで、ストリームのメディアの録画５７を行なう。随意により、上述の録画メッセージ５４が停止時刻を含み、その場合には、停止メッセージ５８の送信は不要である。

録画を停止させる場合、ネイティブソフトウェア１３は、メディアストリームを停止させるべくＩＧＭＰ ＬＥＡＶＥメッセージ５９を送信する。随意により、データの保存、ウェイクアップの準備、およびタイマの設定のための新たなメッセージ４３、４４、４５が、例えば今まさに終了した録画の後の新たな録画を予約するために再び送信される。

ひとたびタイマが設定されると、ネイティブソフトウェア１３は、ストリーミングメディア受信装置を再びパッシブスタンバイ４６に設定することができる。

このようにして、ストリーミングメディア受信装置１は、パッシブスタンバイからアクティブスタンバイへウェイクアップし、アクティブスタンバイの際、計画されたウェブアプリケーション１１を実行することができる。これは、先行技術において可能な柔軟性と比べてさらに顕著な柔軟性を可能にする。

図３ｂが、サーバからのプッシュによる録画に使用される本発明の実施形態を説明するシーケンス図である。

メッセージおよび信号４０〜５１および６３、６４は、図１において説明したメッセージおよび信号に相当する。この例では、ウェイクアップが、例えば１時間ごとなど、定期的な間隔にもとづく時刻に生じるように計画されている。他の間隔も、本発明の範囲において同じように可能である。

随意による認証５１の後で、ウェブアプリケーション１１が、録画の予約に更新がないかどうかを尋ねるメッセージ６０をアプリケーションサーバへ送信する。次いで、アプリケーションサーバ２が、次の録画予約６１を送信することによって応答する。これは、例えばユーザが自宅を離れているときに録画を予約するために任意のウェブブラウザを使用してアプリケーションサーバ２とやり取りをすることを可能にする。換言すると、ユーザが、携帯電話機またはインターネットに接続された任意のコンピュータのウェブブラウザを使用してアプリケーションサーバ２とやり取りし、ユーザの自宅のストリーミングメディア受信装置について録画を予約することができる。この例による定期的なポーリングにおいて、そのような録画は、ユーザのストリーミングメディア受信装置１を使用して達成される。

ウェブアプリケーション１１は、録画予約６１を受信すると、ウェイクアップ準備メッセージ４４およびウェイクアップ準備メッセージから得られるタイマ設定メッセージ４５を使用し、受信した録画予約メッセージ６１に従って録画が生じるように設定する。

録画予約メッセージが空である場合、ウェブアプリケーションは、新たなウェイクアップを定期的な間隔（例えば、１時間ごとなど）にもとづく時刻に生じるように計画する。

本発明の実施形態を適用することができる別の例は、購読ダウンロードサービスである。一例において、ユーザが、例えばデイサービスの映画など、日ごとにダウンロードされるコンテンツを購読する。ネットワークを混雑させることがないように、このダウンロードを、例えば毎晩の午前２時など、夜間に生じるように計画することができる。そのような条件は、ユーザがサービスを契約するときに了解しなければならない契約条件の一部であってよい。結果として、本発明の実施形態によれば、そのようなダウンロードが、ウェブアプリケーションを使用して充分にサポートされ、ネットワークの混雑という影響が最小限である。

本発明の実施形態を適用することができる別の例は、電子番組スケジュールに時間の変更が存在する場合である。録画のためのウェブアプリケーション１１が、ウェイクアップ時に、予約済みの録画に遅れが存在しないかどうかをアプリケーションサーバ２に照会し、そのような場合に、ウェブアプリケーション１１が、録画を新たな開始予定時刻へ予約し直す。随意により、キャンセルされた番組はまったく録画されず、ハードドライブ上の記憶スペースが無駄に消費されることを防止する。

図４が、図１のストリーミングメディア受信装置１におけるスタンバイモードを説明する状態図である。上述の内容に対応する３つの状態、すなわちオン状態７０、パッシブスタンバイ状態７１、およびアクティブスタンバイ７２が存在する。オン状態７０は、ストリーミングメディア受信装置１が、完全なＵＩも含めて完全に機能している状態である。パッシブスタンバイ状態７１は、例えば消費が１ワット以下であるように、最小限の構成要素だけが動作している状態である。アクティブスタンバイ状態７２は、ユーザインターフェイスの構成要素を除くすべての構成要素が動作している状態である。

ストリーミングメディア受信装置１は、上述のように、ユーザがリモコン（または、ストリーミングメディア受信装置１の本体）のスタンバイボタンを押したときに、オン７０からパッシブスタンバイ７１への移行７５を行なう。同様に、ストリーミングメディア受信装置１は、ユーザがリモコン（または、ストリーミングメディア受信装置１の本体）の電源オンボタンを押したときに、パッシブスタンバイ７１からオン７０への移行７６を行なう。

ストリーミングメディア受信装置１は、例えばタイマの時間に達したとき、パッシブスタンバイ７１からアクティブスタンバイ７２への移行７８を行なう。例えば録画またはダウンロードの終了など、ひとたびアクティブスタンバイでの処理が終わると、ストリーミングメディア受信装置１は、再びパッシブスタンバイ７１へ移行する。

パッシブスタンバイ７１とオン７０との間の対話と同様に、ストリーミングメディア受信装置１は、スタンバイ／電源オンボタンを使用して、オン７０とアクティブスタンバイ７２との間の移行７９、８０を行なうことができる。

オン状態７０にあるとき、予約録画、ダウンロード、または他の予約済みの処理を開始でき、それによって、スタンバイボタンが押されることで、ストリーミングメディア受信装置１のそれまでの状態にかかわらず、オン７０からアクティブスタンバイ７２への移行８０が生じることに、注意すべきである。同様に、すでに実行中の予約録画または他の予約による処理が、ストリーミングメディア受信装置１がオン状態７０にあるときに終了する可能性が考えられる。この場合、スタンバイボタンを押すことで、ストリーミングメディア受信装置１のそれまでの状態にかかわらず、オン７０からパッシブスタンバイ７２への移行７５が生じる。

他の状態（図示されていない）は、オフ状態である。そのような状態においては、メディアストリーミング受信装置１へ電力が供給されず、それによってウェイクアップ機能またはＩＲによる指令は動作することができない。オフ状態への移行は、プラグが抜かれた場合や停電時など、電力がストリーミングメディア受信装置から完全に切り離された場合に生じる。ウェブアプリケーションの適切な処理を可能にするために、ウェブアプリケーションを、随意によりメディアストリーミング受信装置１に再び電力が供給されたときに起動するように登録することができる。そのような登録は、図３ａおよび図３ｂのウェイクアップ準備メッセージ４４と同様のやり方で、ＵＲＩおよび随意によるトークンを含むことができる。このようにして、電源の投入時に、ネイティブソフトウェア１３が登録済みのウェブアプリケーションを起動する。

図５は、図１のストリーミングメディア受信装置において実行できる方法を説明するフロー図である。このフロー図は、図３ａおよび図３ｂにおいてストリーミングメディア受信装置がとるステップと同等である。

パッシブスタンバイメッセージの受信８２において、動作中のウェブアプリケーション１１が、ネイティブソフトウェアから、ストリーミングメディア受信装置１がパッシブスタンバイへ移行する旨を知らせるメッセージを受信する。これは、ストリーミングメディア受信装置１がパッシブスタンバイへ移行する旨を知らせる、ユーザ制御装置からの指令（例えば、ＩＲ、ＲＦ（無線周波数）、またはＩＰネットワークを使用する）に応答したものであってよい。

次いで、動作中のウェブアプリケーションは、データ保存メッセージ送信ステップ８３において、ストリーミングメディア受信装置１から離れた場所にデータを保存するように、アプリケーションサーバ２へメッセージを送信する。これは、保存されたデータを、例えば同じユーザ／購読者が、例えば同じ家庭内の別のストリーミングメディア受信装置１から使用することを可能にする。

ウェブアプリケーション再開時刻メッセージ送信ステップ８４において、ウェブアプリケーションは、ウェブアプリケーションの再開予定時刻を示すメッセージを、ネイティブソフトウェアへ送信する。

タイマ設定ステップ８５において、ネイティブソフトウェアが、先のステップにおいて示された時刻に満了するようにタイマを設定する。時刻は、タイマの満了の時刻として設定しても、タイマの満了後の継続時間として設定してもよい。いずれにせよ、満了の時刻は、先のステップにおける時刻に対応する。

受信装置のパッシブスタンバイモードへの設定８６において、受信装置がパッシブスタンバイモードになるように設定される。

タイマ満了信号受信ステップ８７において、タイマが満了した旨の信号が、タイマから受信される。換言すると、設定された時刻に達している。

ストリーミングメディア受信装置をアクティブスタンバイモードに設定するステップ８８において、受信装置が、アクティブスタンバイモードになるように設定される。ユーザの行為が存在していないため、ストリーミングメディア受信装置１は、完全なオンモードに設定されるのではなく、むしろアクティブスタンバイモードに設定される。

タイマ満了メッセージをウェブアプリケーションへ送信するステップ８９において、ネイティブソフトウェアからウェブアプリケーションへ、タイマが満了した旨のメッセージが送信される。

保存済みデータの要求の送信ステップ９０において、ウェブアプリケーションが、データ保存メッセージ送信ステップ８３において保存されたデータを取り出すための要求を、アプリケーションサーバへ送信する。

次いで、アプリケーションサーバにすでに保存済みのデータが、保存済みデータ受信ステップ９１において読み出される。

図６は、図１のストリーミングメディア受信装置の概略図であり、ストリーミングメディア受信装置の別のモジュールの図を示している。詳しくは、ウェブアプリケーション１１およびネイティブソフトウェア１３のいくつかのモジュールが示されている。これらのモジュールを、ストリーミングメディア受信装置１において実行されるコンピュータプログラムなどのソフトウェアを使用して実現することができる。すべてのモジュールは、コントローラ１６、メモリ２０、およびＩ／Ｏインターフェイスを利用する実行環境（図１を参照）に依存する。実際においては、モジュールを所望に応じて結合させてもよいことに注意すべきである。

ウェブアプリケーション１１は、モード変更検出部６、再開モジュール７、およびデータハンドラ２２を備える。モード変更検出部６は、ストリーミングメディア受信装置１がパッシブスタンバイモード７１に移行する旨を示すメッセージを受信するように構成される。再開モジュール７は、動作中のウェブアプリケーションの再開予定時刻を示すメッセージをネイティブソフトウェアへ送信するように構成される。データハンドラ２２は、パッシブスタンバイモードへの移行に先立ってアプリケーションサーバへ保存すべきデータを含むメッセージを送信するとともに、パッシブスタンバイモードから離れた後にアプリケーションサーバから保存済みのデータを含むメッセージを受信するように構成される。

ネイティブソフトウェアは、タイマ設定部８、モード変更部９、およびタイマハンドラ２１を備える。タイマ設定部８は、ウェブアプリケーションの再開予定時刻にてタイマを設定するように構成される。モード変更部９は、ストリーミングメディア受信装置１をタイマの設定後にパッシブスタンバイモード７１に設定し、またはタイマの満了後にアクティブスタンバイモードに設定するように構成される。タイマハンドラ２１は、タイマが満了した旨の信号を受信するとともに、タイマが満了した旨のメッセージをウェブアプリケーションへ送信するように構成される。

図７が、コンピュータにとって読み取り可能な手段を備えているコンピュータプログラム製品９５の一例を示している。このコンピュータにとって読み取り可能な手段に、コンピュータプログラム９６を保存することができ、このコンピュータプログラムが、コントローラに本明細書に記載の実施形態による方法を実行させることができる。では、コンピュータプログラム製品が、ＣＤ（コンパクトディスク）、またはＤＶＤ（デジタル多用途ディスク）、またはブルーレイディスクなどの光ディスクである。上述のように、コンピュータプログラム製品を、ストリーミングメディア受信装置１のメモリ２０など、装置のメモリとして具現化することも可能である。ここでは、コンピュータプログラム１０１が、図示の光ディスク上のトラックとして概念的に示されているが、コンピュータプログラムを、コンピュータプログラム製品に適した任意のやり方で保存することができる。

本発明を、主にいくつかの実施形態を参照して上述した。しかしながら、当業者であれば容易に理解されるとおり、上記開示の実施形態以外の実施形態も、添付の特許請求の範囲によって定められる本発明の範囲において、同様に可能である。

Claims (8)

1. ストリーミングメディア受信装置（１）において実行する方法であって、
   ストリーミングメディア受信装置が、ネイティブソフトウェア（１３）と、ウェブアプリケーション（１１）を実行するためのウェブソフトウェア（１０）とを備え、
   ウェブソフトウェア（１０）において動作中のウェブアプリケーション（１１）において、ストリーミングメディア受信装置がパッシブスタンバイモード（７１）へ移行する旨を知らせるメッセージを受信するステップ（８２）と、
   動作中のウェブアプリケーションからアプリケーションサーバへ、保存すべきデータを含むメッセージを送信するステップ（８３）と、
   動作中のウェブアプリケーションからネイティブソフトウェアへ、動作中のウェブアプリケーションの再開予定時刻を知らせるメッセージを送信するステップ（８４）と、
   ネイティブソフトウェアから、ウェブアプリケーションの再開予定時刻へ、タイマを設定するステップ（８５）と、
   ストリーミングメディア受信装置をパッシブスタンバイモードに設定するステップ（８６）と、
   ネイティブソフトウェアにおいて、タイマが満了した旨の信号を受信するステップ（８７）と、
   ストリーミングメディア受信装置をアクティブスタンバイモードに設定するステップ（８８）と、
   ネイティブソフトウェアからウェブアプリケーションへ、タイマが満了した旨のメッセージを送信するステップ（８９）と、
   動作中のウェブアプリケーションにおいて、保存したデータを含むメッセージをアプリケーションサーバから受信するステップ（９１）と
   を含む方法。
2. 保存したデータを含むメッセージを受信するステップに先立って、ウェブアプリケーションサーバからアプリケーションサーバへ、保存したデータを送信するように要求を送信するステップ（９０）をさらに含む請求項１に記載の方法。
3. ネイティブソフトウェアへメッセージを送信するステップ（８４）が、ウェイクアップ時に辿るべきユニフォームリソースインジケータ（ＵＲＩ）を設定することを含む請求項１または２に記載の方法。
4. ネイティブソフトウェアへメッセージを送信するステップ（８４）において送信されるメッセージが、動作中のウェブアプリケーションからの補足の情報を含むトークンを含む請求項１〜３のいずれか１項に記載の方法。
5. インターネットプロトコルテレビジョン（ＩＰＴＶ）に準拠したストリーミングメディア受信装置において実行する請求項１〜４のいずれか１項に記載の方法。
6. ストリーミングメディア受信装置のためのコンピュータプログラムであって、
   ストリーミングメディア受信装置が、ネイティブソフトウェアと、ウェブアプリケーションを実行するためのウェブソフトウェアとを備え、ストリーミングメディア受信装置においてコンピュータプログラムを実行中に、
   ウェブソフトウェアで動作中のウェブアプリケーションにおいて、ストリーミングメディア受信装置がパッシブスタンバイモードへ移行する旨を知らせるメッセージを受信することと、
   動作中のウェブアプリケーションからアプリケーションサーバへ、保存すべきデータを含むメッセージを送信することと、
   動作中のウェブアプリケーションからネイティブソフトウェアへ、動作中のウェブアプリケーションの再開予定時刻を知らせるメッセージを送信することと、
   ネイティブソフトウェアからタイマを、ウェブアプリケーションの再開予定時刻に設定することと、
   ストリーミングメディア受信装置をパッシブスタンバイモードに設定することと、
   ネイティブソフトウェアにおいて、タイマが満了した旨の信号を受信することと、
   ストリーミングメディア受信装置をアクティブスタンバイモードに設定することと、
   ネイティブソフトウェアからウェブアプリケーションへ、タイマが満了した旨のメッセージを送信することと、
   動作中のウェブアプリケーションにおいて、アプリケーションサーバから保存したデータを含むメッセージを受信することと
   をストリーミングメディア受信装置に実行させるコンピュータプログラムコードを含むコンピュータプログラム。
7. ストリーミングメディア受信装置（１）であって、
   ネイティブソフトウェア（１３）と、
   ウェブアプリケーション（１１）を実行するためのウェブソフトウェア（１０）と、
   タイマ（１８）と、
   ウェブアプリケーション（１１）に位置し、ストリーミングメディア受信装置（１）がパッシブスタンバイモード（７１）へ移行する旨を知らせるメッセージを受信するモード変更検出部（６）と、
   ウェブアプリケーションに位置し、動作中のウェブアプリケーションの再開予定時刻を知らせるメッセージをネイティブソフトウェアへ送信する再開モジュール（７）と、
   ネイティブソフトウェア（１３）に位置し、ウェブアプリケーションの再開予定時刻でタイマを設定するタイマ設定部（８）と、
   ストリーミングメディア受信装置（１）をタイマの設定後にパッシブスタンバイモード（７１）に設定し、またはタイマの満了後にアクティブスタンバイモードに設定するように構成されたモード変更部（９）と、
   ネイティブソフトウェアに位置し、タイマが満了した旨の信号を受信し、タイマが満了した旨のメッセージをウェブアプリケーションへ送信するタイマハンドラ（２１）と、
   ウェブアプリケーションに位置し、パッシブスタンバイモードへの移行に先立って保存すべきデータを含むメッセージをアプリケーションサーバへ送信し、保存したデータを含むメッセージをパッシブスタンバイモードからの離脱後にアプリケーションサーバから受信するデータハンドラ（２２）と
   を備えるストリーミングメディア受信装置（１）。
8. インターネットプロトコルテレビジョン（ＩＰＴＶ）に準拠した請求項７に記載のストリーミングメディア受信装置（１）。

Images