JP2014059866A

JP2014059866A - エネルギーを節約しつつデータを連続配信する技術

Info

Publication number: JP2014059866A
Application number: JP2013176695A
Authority: JP
Inventors: B Stanton Kevin; ビー．スタントン、ケビン
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2012-09-14
Filing date: 2013-08-28
Publication date: 2014-04-03
Also published as: US20140082504A1; KR20140035845A; TWI632816B; CN103685229A; EP2709371A1; TW201419900A; KR101521780B1

Abstract

【課題】エネルギーを節約しつつデータを連続配信する技術を提供する。
【解決手段】データは、少なくとも第１の提示レートおよび第２の提示レートを含むそれぞれ異なる提示レートでユーザに提示されてよい。例えばデバイスは、閾値条件に到達するまでは第１の提示レートで、受信したデータを提示して、その後、第２の提示レートで、受信したデータを提示する。一実施形態では、第１の提示レートは、受信した種類のデータについて通常利用される遅いレートであってよく、これを利用することで、デバイスは、デバイスメモリに、受信したデータの一部をバッファリングすることができる。ひとたびバッファリングされたデータ量がメモリの閾値レベルに達すると、デバイスは、レートを第２の提示レートに上げる（たとえば、受信した種類のデータに通常利用する提示レート）。
【選択図】図２

Description

標準的な音声通信をはるかに超える機能をもつ移動デバイスが出現してきている。たとえば一部の移動デバイスは、様々な有線および／または無線通信媒体を利用する情報を送受信することのできる１以上のトランシーバを搭載している。音声、テキスト、データ、マルチメディア等を含む情報を効率よく通信する機能によって、たとえば対人間の通信（たとえば電子メール、メッセージング、ソーシャルメディア等）、商談、生産現場、ゲーム、ショッピング等に関する新たな機能が移動デバイスに組み込まれるようになってきている。この結果、簡単な携帯型のハンドセットが、大きなアプリケーションアレイを実行する能力をもつ、強力且つ多目的な移動プラットフォームへと進化している。

初期のアプリケーションは、電子メール、メッセージング、新たな供給（new feeds）等の基礎的な通信機能に関するものであった。しかし、すぐにアプリケーションは進化して、デバイスに様々な機能を組み込む能力をもった。たとえば、現在のアプリケーションのなかには、データを「ストリーミング」するように構成されているものがある（たとえば、遠隔ソースから実質的に連続してデータを受信する）。ストリーミングされたデータには、たとえば、移動デバイス上で提示するためのビデオおよび／または音声情報等のマルチメディア情報が含まれてよい。この機能を利用すると、移動デバイスのユーザは、音楽を聴いたり、テレビ番組を見たり、映画鑑賞をしたり、講演、会議、会合等を見たり、聞いたり、参加したりすること全てを、自身の移動デバイスで行うことができる。

請求されている主題の様々な実施形態の特徴および利点は、以下の詳細な説明を添付図面とともに読むことで明らかになる。図面において、同様の参照番号は同様の部材を表すこととする。

本開示の少なくとも１つの実施形態において、エネルギーを節約しつつデータを連続配信するシステムの一例を示す。本開示の少なくとも１つの実施形態において、データバッファリングと提示レートとの間の関係を示すチャートの一例を示す。本開示の少なくとも１つの実施形態において図２の関係に対する構成変更の効果を示すチャートの例である。本開示の少なくとも１つの実施形態において、データバッファリングと提示レートとの間の別の関係を示すチャートの一例を示す。本開示の少なくとも１つの実施形態において、エネルギーを節約しつつデータを連続配信する処理の例のフローチャートを示す。

以下の詳細な説明は、例である実施形態を参照しながら行われ、多くの変更例、変形例、および代替例が当業者には明らかであろう。

既存の技術もデータストリーミングを助けてはいるが、あくまで一定の制約下でのサポートである。この点に関しては、受信するとすぐにストリーミングされたデータを初期提示することで、最大パフォーマンスに到達する場合がある（これはたとえば、移動デバイスユーザの最良の体験ともなる）。しかし、このように動作すると、移動デバイスのリソース（たとえばバッテリ電力）に実質的にひずみが生じる場合がある。逆に、提示前にデバイスが少なくともいくつかデータを受信するまで待つとすると（たとえばデータをバッファリングする）、デバイスリソースを節約する助けにはなるかもしれないが、データ提示が送れる。この遅延または待ち時間がデバイスの不具合として見えてしまい、ユーザがデータストリーミングを再開してしようとしたり（たとえばより多くのデバイスリソースが無駄になる）、ユーザがデバイスのパフォーマンスに満足しなかったりする、といったことが起きる。

本開示は、エネルギーを節約しつつデータを連続配信するシステムおよび方法を記載する。最初に、以下の開示における用語を定義しておく。データの「ストリーミング」は、遠隔ソースからデバイス宛てに、データを実質的に連続配信することとして定義されてよい。たとえば制御可能な転送率を有するデバイス内のソース（たとえば、磁気、光学、または固体記憶部品）からのデータを取得することは、本開示ではストリーミングとして考えない。たとえば、Ｉｎｔｅｒ−ＩＣＳｏｕｎｄ（Ｉ^２Ｓ）入力、デジタル・ビジュアル・インタフェース（ＤＶＩ）入力、高精細マルチメディアインタフェース（ＨＤＭＩ（登録商標））入力等を介してデバイスに接続されている外部ソースからデータを受信することは、本開示のストリーミングとして考えられる。デバイスは、インターネットアクセス可能なソースから、有線または無線通信によってデータをストリーミングすることもできる。ストリーミングされたデータは、たとえば、ビデオおよび／またはオーディオコンテンツ等のマルチメディア情報を含む場合がある。したがって、ストリーミングされたマルチメディア情報の「提示」には、ストリーミングされたデータから得たビデオコンテンツを提示したり、および／または、音声コンテンツを再生したりすることが含まれる場合がある。

概してデバイスは、受信したデータを、受信したデータで通常利用されるレートより遅い提示レートで提示してから、受信したデータの少なくともいくつかがメモリに格納されたところで、より速い提示レートに遷移するよう構成することができる。たとえば、ビデオおよび／またはオーディオコンテンツを含むマルチメディア情報をストリーミングするアプリケーションがデバイス内で起動されると、すぐに、通常よりもすこし遅いレートでビデオおよび／またはオーディオコンテンツを提示し始めて、情報の少なくとも一部がデバイスにバッファリングされるのを待つ。このようにすることで、ストリーミング機能が起動された直後にデータ提示が開始されるが、起動時に同時に開始されるバッファリングに基づいてデバイスの電力も節約されるために、受信したデータの提示遅延が最小限に抑えられる。特に、データストリーミングが起動されてからのデータのバッファリングによって、より多くのデータ量を一度に処理することができるようになり、デバイス処理リソースが迅速に動作して、節電モードでより長時間動作することができ、データストリーミング中のデバイスの電力消費全体を抑えることができるようになる。

一実施形態では、デバイスはたとえば、通信モジュール、メモリモジュール、およびデータ提示モジュールを少なくとも含んでよい。通信モジュールは、実質的に連続してデータを受信して（たとえば有線または無線通信によって遠隔ソースから）、次いで、メモリモジュールに、受信したデータを格納するよう構成されていてよい。データ提示モジュールは、１を超える数の提示レート（たとえば再生レート）を用いて、格納されているデータを提示することができてよい。データが第１の提示レートまたは第２の提示レートを用いて提示される場合には、データを第１の提示レートまたは第２の提示レートのいずれで提示するかは、たとえば、閾値条件によって決定してよい。一実施形態では、データ提示モジュールが、閾値条件に達するまでは、第１の提示レートでデータを提示して、閾値条件が生じた後には、第２の提示レートでデータを提示するよう構成されていてよい。

同じまたは別の実施形態では、閾値条件は、メモリモジュールに格納されているデータ量であってよい。閾値条件はさらに、データがデバイスに受信される接続の品質に基づいて決定してもよい。たとえば、データ提示モジュールは、第２の提示レートより小さい（遅い）第１の提示レートでデータを提示するよう構成されていてよい。データを第１の提示レートで提示すると、メモリモジュールにデータを蓄積することができる（たとえばバッファリングする）。十分なデータがバッファリングされると（たとえば閾値条件に基づいて）、データの提示を、第２の提示レートにまで上げる。データを低い提示レートで提示することで、メモリモジュールにいくつかデータをバッファリングさせつつ、待ち時間を少なくすることができるようになる（たとえば、データストリーミング起動直後にもデータを提示することができることから）。たとえば、受信したデータの第１の提示レートでの提示と、受信したデータの第２の提示レートでの提示との間の差は、プレゼンテーションを聞いている、見ている、または観察しているデバイスのユーザには認知できない。

一実施形態では、受信したデータを提示するレートは、デバイスハードウェアに（たとえばデバイスの処理モジュールに）組み込まれている機能により制御することができるようにしてもよい。このような構成では、提示モジュールは、少なくとも一部を、たとえば閾値条件に達することに基づいて第１の提示レートまたは第２の提示レートで、受信したデータをデバイスハードウェアに提示させるよう構成されたソフトウェアとして実装することができる。または、上述した提示レートの制御を全体的にソフトウェアで調整するようにしてもよい。

図１は、本開示の少なくとも１つの実施形態において、エネルギーを節約しつつデータを連続配信するシステム１００の一例を示す。システム１００はたとえば、デバイス１０２およびデータソース１２０を含んでよい。デバイス１０２の例は、これらに限られはしないが、Ａｎｄｒｏｉｄ（登録商標）オペレーティングシステム（ＯＳ）、ｉＯＳ（登録商標）、Ｂｌａｃｋｂｅｒｒｙ（登録商標）ＯＳ，Ｐａｌｍ（登録商標）ＯＳ、Ｓｙｍｂｉａｎ（登録商標）ＯＳ等に基づく携帯ハンドセットまたはスマートフォン等の移動通信デバイス、ｉＰａｄ（登録商標）、ＧａｌａｘｙＴａｂ（登録商標）、ＫｉｎｄｌｅＦｉｒｅ（登録商標）、ＭｉｃｒｏｓｏｆｔＳｕｒｆａｃｅ（登録商標）等、ＩｎｔｅｌＣｏｒｐｏｒａｔｉｏｎ社製の低電力チップセットを含むＵｌｔｒａｂｏｏｋ（登録商標）等のタブレット型コンピュータ、ネットブック、ノートブックコンピュータ、ラップトップコンピュータなどの移動コンピューティングデバイス、デスクトップコンピュータ等の通常は固定型のコンピューティングデバイス等を含んでよい。デバイス１０２には、ホスト１０４、通信モジュール１１４、およびデータ提示モジュール１１８が含まれてよい。通信モジュール１１４およびデータ提示モジュール１１８は、ホスト１０４とは別個ではあるが、連結されているものとして示されているが、これらモジュールのいずれかまたは両方がホスト１０４内に含まれていてもよい。システム１００では、デバイス１０２が、有線または無線通信によって（たとえば通信モジュール１１４によって）少なくともデータソース１２０と相互作用するよう構成されていてよい。データソース１２０は、実質的に連続してデータをデバイス１０２に提供するよう構成された少なくとも１つの遠隔に位置するデバイスを含んでもよい。たとえばデータソース１２０は、有線または無線通信によってデバイス１０２にデータ（たとえば、ビデオおよび／オーディオ情報を含むマルチメディア情報）を提供するよう構成されたインターネットによってアクセス可能な少なくとも１つのサーバであってよい。

たとえばホスト１０４は、処理モジュール１０６、メモリモジュール１０８、電力モジュール１１０、通信インタフェースモジュール１１２（通信モジュール１１４と相互作用するように構成されていてよい）、およびユーザインタフェースモジュール１１６（データ提示モジュール１１８と相互作用するよう構成されていてよい）を含んでよい。たとえば処理モジュール１０６は、１以上のプロセッサをそれぞれ別のコンポーネントに含んでもよく、または、１以上の処理コアが１つのコンポーネント（たとえばシステムオンチップ（ＳＯＣ：system-on-a-chip）構成）および任意のプロセッサ関連のサポート回路（たとえばブリッジインタフェースなど）に具現化されていてもよい。プロセッサの例には、ＩｎｔｅｌＣｏｒｐｏｒａｔｉｏｎから入手可能な様々なｘ８６ベースのマイクロプロセッサ（Ｐｅｎｔｉｕｍ（登録商標）、Ｘｅｏｎ、Ｉｔａｎｉｕｍ、Ｃｅｌｅｒｏｎ、Ａｔｏｍ、Ｃｏｒｅｉシリーズプロダクトシリーズのものを含む）が含まれてよい。サポート回路の例には、処理モジュール１０６が、異なる速度で、異なるバス等で、デバイス１０２で動作していてよい他のシステムコンポーネントと相互作用することができるインタフェースを提供することができるチップセット（たとえばＩｎｔｅｌＣｏｒｐｏｒａｔｉｏｎから入手可能なノースブリッジ、サウスブリッジ等）が含まれてよい。サポート回路と通常関連付けられている機能の一部または全ては、ＳＯＣアーキテクチャ（たとえばＩｎｔｅｌＣｏｒｐｏｒａｔｉｏｎから入手可能なＳａｎｄｙＢｒｉｄｇｅＳＯＣ集積回路など）等にみられるようなプロセッサと同じ物理的なパッケージに含められてもよい。

処理モジュール１０６は、デバイス１０２内で命令を実行するよう構成されてよい。命令には、処理モジュール１０６に、データ読み出し、データ書き込み、データ処理、データフォーマッティング、データ変換（converting data, transforming data）等に関する処理を実行させるプログラムコードが含まれてよい。情報（たとえば命令、データ等）が、メモリモジュール１０８に格納されてよい。たとえば、少なくとも１つの実施形態では、処理モジュール１０６は、受信したデータを提示するレート（たとえば提示レート（rendering speed））を制御するための命令で構成されてよい。メモリモジュール１０８は、固定された形態または取り外し可能な形態の、ランダムアクセスメモリ（ＲＡＭ）および／または読み出し専用メモリ（ＲＯＭ）を含んでよい。ＲＡＭは、スタティックＲＡＭ（ＳＲＡＭ）またはダイナミックＲＡＭ（ＤＲＡＭ）等のデバイス１０２の動作中に情報を保持するよう構成されているメモリを含んでよい。ＲＯＭは、デバイス１０２の起動時に命令を提供するよう構成されているｂｉｏｓメモリ、ＥＰＲＯＭＳ（electronic programmable ROMs）、Ｆｌａｓｈ等のプログラム可能なメモリを含んでよい。他の固定および／または取り外し可能なメモリは、フロッピー（登録商標）ディスク、ハードディスク等の磁気メモリ、固体フラッシュメモリ（ｅＭＭＣ等）等の電子メモリ、取り外し可能メモリカードまたはメモリスティック（たとえばｕＳＤ、ＵＳＢ等）、ＣＤ−ＲＯＭ等の光学メモリ等を含んでよい。メモリモジュール１０８は、処理モジュール１０６が行う処理によって、または直接モジュール内相互作用によって、アクセス可能であってよい（たとえば、データがメモリモジュール１０８から読み取り、または、メモリモジュール１０８に書き込みをされる）。たとえば、直接メモリアクセス（ＤＭＡ）は、デバイス１０２の他のモジュール（たとえばモジュール１１０から１１８）が、メモリモジュール１０８に対して直接読み取りおよび／または書き込みをすることができるという技術である。

電力モジュール１１０は、内部電源（たとえばバッテリ）および／または外部電源（たとえばパワーグリッド、電気機械的または太陽光発電機）、および、作動に必要な電力をデバイス１０２に供給するよう構成されている関連回路を含んでよい。通信インタフェースモジュール１１２は、通信モジュール１１４のパケットルーティングその他の制御機能を処理するよう構成されていてよく、これには、有線および／または無線通信をサポートするよう構成されているリソースが含まれてよい。有線通信は、たとえばイーサネット（登録商標）、ユニバーサルシリアルバス（ＵＳＢ）、Ｆｉｒｅｗｉｒｅ、Ｉ^２Ｓ、ＤＶＩ，ＨＤＭＩ（登録商標）（登録商標）等のシリアルおよびパラレル有線媒体を含んでよい。無線通信には、たとえば、近接近無線媒体（たとえば、ＲＦＩＤ等の無線周波数（ＲＦ）、または近距離無線通信（ＮＦＣ）規格、赤外線（ＩＲ）、ＯＣＲ（光学文字認識）、磁気文字認識）、短距離無線媒体（たとえばＢｌｕｅｔｏｏｔｈ（登録商標）、無線ローカルエリアネットワーキング（ＷＬＡＮ）、Ｗｉ−Ｆｉ等）、および、長距離無線媒体（たとえばセルラー式、衛星等）が含まれてよい。一実施形態では、通信インタフェースモジュール１１２が、通信モジュール１１４で起動している無線通信が互いに干渉しあわないようにするよう構成されてよい。この機能を実行するために、通信インタフェースモジュール１１２は、通信モジュール１１４の動作を、たとえば送信を待っているメッセージの相対優先度に基づいてスケジューリングしてよい。

ユーザインタフェースモジュール１１６は、ユーザに、たとえば様々な入力機構（たとえばマイクロフォン、スイッチ、ボタン、ノブ、キーボード、スピーカ、接触式表面、画像を取得したり、および／または、近接度、距離、動き、ジェスチャー等を検知したりするよう構成されている１以上のセンサ）、および、出力機構（たとえば、スピーカ、ディスプレイ、光／フラッシュインジケータ、振動、動きのための電気機械コンポーネント）等のデバイス１０２と相互作用させるよう構成されている回路を含んでよい。ユーザインタフェースモジュール１１６は、データ提示モジュール１１８と相互作用したり、または、データ提示モジュール１１８を含んだりしてよい。データ提示モジュール１１８は、メモリモジュール１０８から（プロセッサ１０６によって、またはＤＭＡ等の技術によりメモリモジュール１０８と直接作用することで）、データを受信して、データを、ユーザインタフェースモジュール１１６で利用可能なリソースによって、デバイス１０２のユーザに提示してよい。たとえば、データ提示モジュール１１８は、デバイス１０２に、データソース１２０からのデータ受信を開始させる少なくとも１つのアプリケーションを含んでよく、このデータには、ビデオおよび／またはオーディオコンテンツ等のマルチメディア情報が含まれてよい。データは、実質的に連続して受信されてよい。データ提示モジュール１１８は、その後、マルチメディア情報を、デバイス１０２のユーザに、ユーザインタフェースモジュール１１６の１以上のエレメントによって提示させてよい（たとえばビデオは、デバイスのディスプレイに提示されてよく、オーディオは、デバイススピーカまたはデバイス１０２に接続されている別のオーディオ再生装置によって再生されてよい）。マルチメディア情報をユーザに提示するために、データ提示モジュール１１８は、コンテンツを提示する速度（レート）、オーディオの音量、および、提示の様々な他の特徴を制御してよい。たとえば処理モジュール１０６がデータ提示レート制御機能を含む、または含むよう構成されていてよい実施形態では、データ提示モジュール１１８の一部または全部が、処理モジュール１０６に、第１の提示レートまたは第２の提示レートで、受信したデータを提示させるよう構成されているソフトウェア（たとえばアプリケーションの一部）として実装されてよい。

図２は、本開示の少なくとも１つの実施形態において、データバッファリングと提示率との間の関係を示すチャート２００の一例を示す。たとえば、チャート２００は、水平軸に時間を示し、左の垂直軸にバッファリングされたデータ量（たとえばメモリモジュール１０８に格納されているデータ）を示し、右の垂直軸にデータを提示する（たとえばデータ提示モジュール１１８によって）レートを示している。破線および点線が混じっている（「破線‐点線」）線は、バッファリングされているデータ量に対応しており、提示レートは点線で示されている。ここで、チャート２００では、バッファリングされたデータおよび提示レートを示す線が、実際の縮尺に即して描かれてはおらず、本開示の少なくとも１つの実施形態に則った、バッファリングされたデータおよび提示レートの間の相対的なパターン（behavior）を示す例としてのみ提供されている点に留意されたい。

データ受信がデバイス１０２で開始されると（たとえば時間０）、受信したデータが、「通常」レート（たとえば、受信した種類のコンテンツが提示される通常のレートのこと）未満である第１の提示レート２０２で提示されてよい。たとえば、ビデオを受信した場合であれば、ビデオのレンダーリング・レートを、通常のビデオレンダーリング・レートより５パーセント（５％）減らしてよい。ビデオレンダーリング・レートは、別のレートで低下させてもよい（たとえば、実際のレート低下量を、受信するデータの種類に対応させたり、受信したデータの利用法に対応させたりしてもよい）。たとえば、レート低減の目的は、実質的にユーザに対する視覚体験、および／または、聴覚体験は変更されることなく、デバイスの節電を行うことができるようにすることとしてよい。通常、少々提示レートを下げたくらいではユーザにはわからない。

提示レート２０２を下げた結果、バッファリングされたデータが蓄積されはじめ、予め定められた閾値条件レベル２０４に到達してよい。閾値条件レベル２０４は、たとえば、第１の提示レートで提供されるパフォーマンスの低下と、受信したデータをバッファリングすることで節約されるエネルギー量との間のトレードオフに基づき決定されてよい。しかし、閾値条件レベル２０４は、この目的のみに制約はされず、本開示の他の実施形態では、他の基準に基づく閾値が含まれてもよい。閾値条件レベル２０４は、たとえばデバイス１０２、ストリーミングデータ等の条件に応じた変数であってもよい。たとえば閾値は、データを受信する接続の不安定さ（たとえばジッタ）に基づき設定されてもよい。データ提示に対する不安定さの影響を最小限に抑えるために、閾値条件レベル２０４は、接続の不安定さが治まるまでまたは解消されるまでは、提示レートを低く抑えるように（たとえば第１の提示レート）設定することもできる。３Ｇ／４Ｇ無線リンクでストリーミングする場合、閾値条件レベル２０４は、さらに、最初の提示レートおよび／または将来のコンテンツ受信の不確かさ、および／または、将来のコンテンツを提供するレートに基づいて決定されてもよい。「アンダーフロー」する確率（たとえば、提示レート未満のレートでデータが受信されることによって）は、コンテンツの最初の提示が、ストリーミングされたデータの受信直後に行われれば、より高くなる可能性がある。ネットワークリンクの損失が非常に大きい（very lossy）場合に（たとえば一部の無線接続）は、最初の提示レートを低下させて、適量のデータがバッファリングされたら提示レートを上げることでアンダーフローの確率を下げて、生じうるネットワーク問題に対処すると好適であろう。

バッファのデータ量が閾値条件レベル２０４に達すると（時間インスタンス２０６に対応する）、提示レートは徐々に上がり始めるだろう。提示レートは、継時的に徐々に上げることで、ユーザが認識する第１および第２の提示レートの差を最小限に抑えることができる。提示レートは、時間インスタンス２０６から徐々に上がり始め、これによって、格納されているデータがメモリから消費されるレートも同様に上昇しはじめ、この結果、データがバッファリングされるレートが、時間インスタンス２０６から徐々に下がり始めてよい。時間インスタンス２０８においては、提示レートが第２の提示レート２１０になって、ここで「通常」提示レート（たとえば、受信した種類のコンテンツが提示される通常のレートのこと）になってよい。バッファリングデータ量は、２１２で実質的にコンスタントなレベルに維持することで、処理モジュール１０６をアクティブモードに入らせ、提示を準備するために大量のデータを処理し、その後、節電モードに戻らせてよく、これによりデバイス１０２の節電が助けられる。提示モジュール１１８は、処理されたデータを（ＤＭＡ経由でメモリモジュール１０８から直接）取得してよく、第２の提示レート２１０でユーザインタフェースモジュール１１６のリソースを利用してデータを提示してよい。

場合によっては、提示は、受信したデータに基づいてより正確に行うことが望ましいので（たとえばユーザが節電よりも「高品質」な提示を一時的に望む場合もある）、マルチメディア情報の種類に自動的に基づき（ユーザ構成に基づき）、提示レート低減が限られたものとなる場合もある。一例は、提示レート低減が限られていており、提示レートがわずかにしか降下していない、図３に示す例に表されている（たとえば３０２に示す実線）。たとえば、音楽演奏が歌手、楽器等による伴奏のためにストリ−ミングされると、レート低減量を制限して、演奏を高品質で提示して、レートの低減量を制限すると好適であると思われる。レートを低減すると、ストリーミングされる演奏のピッチ、イントネーション等もわずかに変わることがあり、これにより伴奏者の学習プロセスおよび／または実際の演奏に悪影響がでる場合がある。別の例では、デバイス１０２が、受信したデータをバッファリングするために利用可能なリソースを限られた量しかもたない場合がある（たとえば、メモリモジュール１０８のフリーメモリ）。この結果、提示レートの低下量を制限することで、提示の安定性に影響が出る場合があるが（たとえばネットワーク遅延またはジッタによって、提示が中断される等）、デバイス１０２の利用可能なリソースを圧倒（overwhelm）しないようにすることも必要だろう。

提示レート低減量を制限する理由が何であれ、３０４の実線が示すデータバッファリング変化には、提示レート低減を制限したことの効果が示されている。提示レートが高くなると、より多くの受信データが消費されるために、データはよりゆっくりバッファリングされるようになるだろう。たとえば提示レートは、より長い期間低下を続け（たとえば時間インスタンス３０６まで）、ここからは通常の提示レートにまで上昇してよい（たとえば時間インスタンス３０８）。このように動作すると提示精度が高くなるが、提示の安定性は、より長い期間、ネットワーク接続問題に対して脆弱になる可能性がある（たとえば、時間インスタンス３０８でバッファがコンスタントなレベル２１２に達するまで）。

本開示においては、提示レートの第１の提示レート２０２から第２の提示レート２１０への増加は、他の方法で達成されてもよい。図４には別の提示レートの上昇の一例が示されている。一実施形態では、デバイス１０２でデータ受信が始まった直後に、提示レートが第１の提示レート２０２（放物線状の増加レート）から、第２の提示レート２１０（たとえば通常の提示レート）に増加を始める（４０２）。同様に、データがバッファリングされるレートは、最初は高いが、４０２でバッファリングデータがコンスタントなレベル２１２に達するまで、提示レートの関数で低下し続けてよい。図４に示すような放物線状の増加レートにする利点は、提示レートの変化がコンスタントでスムーズなので、提示を見ているユーザが、これら変化を察知することが難しくなる、ということである。

図２は示していないが、一実施形態では、２を超える数の提示レートが存在してよい。たとえば、提示レートは、システム１００の構成に基づいて、当初の最低速度から最高速度（たとえば通常速度）までの任意の数の提示レートを経る（traverse）ことができてよい。２を超える数のレートを含めるか否かは、たとえばデバイス１０２の機能による。２を超える数の提示レートを利用すると、たとえばデータ提示の制御に、より柔軟性をもたせることができるようになり、たとえばデータストリーム条件の不安定性を解決して、増加率をより緩やかにして、ユーザが認識する提示における変化を最小限に抑えることができるようになる。加えて、提示レートは、第２の提示レート（たとえば通常の提示レート）に増加した後で低下してよい。たとえば、１つの種類のネットワークリンクが別のものに変更され（たとえば３ＧからＷＬＡＮ）、ネットワークリンクの不安定性を検知すると、バッファリングされたデータ量を、アンダーフローの可能性に対応できるように増加させるよう決定される（dictate）。この結果、デバイス１０２でバッファリングされるデータ量を増加させるために提示レートは低減されてよい。こうすることで、デバイス１０２は、データのアンダーフローが生じたとしても提示を続けることができる（既存のデバイスであれば、提示を停止して、「バッファリング中」の待ちスクリーンを提示する）。これに加えて、提示レートを変更することで、デバイスがネットワーク安定性、条件等の変化を検知して、通常の提示レートと、より低い提示レートとの間を移動することができるようになる。

一実施形態では、提示レートの低減は、アルゴリズム処理を利用することで最小限に抑えられてよい。たとえば信号処理アルゴリズムを利用することで、オーディオ情報のピッチに影響を与えずに、オーディオ情報の「テンポ」を変更することができる。現在利用されているアルゴリズムの一例が、「ＡｍａｚｉｎｇＳｌｏｗＤｏｗｎｅｒ」である。この技術は、提示レートの低減の影響をマスキングして、提示品質に実質的な影響を与えずにデータのバッファリングを行わせることができる技術である。この結果、受信したデータから得られるマルチメディアコンテンツが、実際には通常レートより遅いレートで提示されているにも関わらず、ユーザには完全に通常に見える。

図５は、本開示の少なくとも１つの実施形態において、エネルギーを節約しつつデータを連続配信する動作の例のフローチャートを示す。動作５００で、データ受信が開示されてよい。たとえば、実質的に連続してデータを受信して、その後、受信したデータをデバイスのユーザに提示するよう構成されたアプリケーション（たとえば、ビデオおよび／またはオーディオコンテンツを含むマルチメディア情報をストリーミングするアプリケーション）がデバイスで起動されてよい。デバイスは、最初に、受信したデータを第１の提示レートで提示するよう構成されていてよい（動作５０２）。たとえば第１の提示レートは、受信したデータの少なくとも一部をデバイスのメモリにバッファリングすることができるように低減された提示レートであってよい。動作５０４では、この決定は、バッファリングされたデータが閾値条件を満たすかについて行うことができる。たとえば決定は、バッファリングされたデータ量が予め定められたレベルに達したかについて行ってよい。バッファリングされたデータが閾値条件を満たさないと判断された場合には、受信したデータは、第１の提示レートで提示され続けてよい。他方で、バッファリングされたデータが閾値条件を持たしていると判断された場合には、動作５０６で、受信したデータを第２の提示レートで提示してよい。たとえば、第２の提示レートは、受信した種類のデータがデバイスに通常提示される提示レートであってよい。

図５は一実施形態における様々な処理を示しているが、図５に示すすべての動作が他の実施形態でも必要というわけではない点を理解されたい。実際、ここでは本開示の他の実施形態において、図５に示す動作および／またはここで説明する他の動作を、図面のいずれかに具体的に示されていないが、本開示と完全に合致するように組み合わせてもよい。したがって、１つの図面には正確には示されていない特徴および／または動作に対する請求項が、本開示の範囲および内容の範囲に含まれるものとする。

本明細書のいずれの実施形態においても、「モジュール」という用語は、上述した動作のいずれかを実行するよう構成された、ソフトウェア、ファームウェア、および／または、回路を示してよい。ソフトウェアは、持続性コンピュータ可読記憶媒体に格納されているソフトウェアパッケージ、コード、命令、命令セット、および／またはデータとして具現化されてよい。ファームウェアは、メモリデバイスにハードコードされている（たとえば不揮発性）コード、命令、または命令セットおよび／またはデータとして具現化されてよい。本明細書にずれかの実施形態で利用される「回路」は、たとえば単独または組み合わせで、ハードワイヤ回路、プログラマブル回路（たとえば１以上の個々の命令処理コア、状態マシン回路、および／または、プログラマブル回路が実行する命令を格納するファームウェアを含むコンピュータプロセッサ等）を含んでよい。モジュールは、集合的またはここに、より大きなシステム（たとえば集積回路（ＩＣ）、システムオンチップ（ＳｏＣ）、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、サーバ、スマートフォン等）の一部を形成する回路として具現化されてよい。

ここに記載した動作はいずれも、個々にまたは組み合わせで、１以上のプロセッサにより実装されると方法を実行する命令が格納されている１以上の格納媒体を含むシステムに実装されてよい。ここでプロセッサには、たとえば、サーバＣＰＵ、移動デバイスＣＰＵ、および／または、他のプログラム可能回路が含まれてよい。さらに、ここに記載されている処理は、１を超える数の異なる物理的位置の処理構造等の複数の物理デバイスにわたり分散されてよい。記憶媒体は、フロッピー（登録商標）ディスク、光学ディスク、ＣＤ−ＲＯＭ，ＣＤ−ＲＷ、および光磁気ディスクを含む任意の種類のディスク、ＲＯＭ、ダイナミックおよびスタティックＲＡＭ等のＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、固体ディスク（ＳＳＤ）、エンベデッドマルチメディアカード（ｅＭＭＣ）、セキュアなデジタル入出力（ＳＤＩＯ）カード、磁気カードまたは光カード等の半導体素子などの任意の種類の有形の媒体、または、電子命令を格納するのに適した任意の種類の媒体を含んでよい。他の実施形態は、プログラマブル制御デバイスが実行するソフトウェアモジュールとして実装されてよい。

したがって、本開示は、エネルギーを節約しつつデータを連続配信するシステムおよび方法を提供する。デバイスは、実質的に連続してデータを受信して、ユーザにそのデータを提示するよう構成されていてよい。データは、少なくとも第１の提示レートおよび第２の提示レートを含むそれぞれ異なる提示レートでユーザに提示されてよい。例えば、デバイスは、閾値条件が満たされるまでは第１の提示レートでデータを提示して、その後、第２の提示レートでデータを提示するよう構成されていてよい。一実施形態では、第１の提示レートは、受信した種類のデータについて通常利用される遅いレートであってよく、これを利用することで、デバイスは、デバイスメモリに、受信したデータの一部をバッファリングすることができる。ひとたびバッファリングされたデータ量がメモリの閾値レベルに達すると、デバイスは、レートを第２の提示レートに上げる（たとえば、受信した種類のデータに通常利用する提示レート）。

以下の例は、さらなる実施形態に関している。一実施形態では、デバイスが提供される。デバイスは、データを少なくとも受信するよう構成されている通信モジュール、受信したデータをバッファリングするよう構成されているメモリモジュール、および、受信したデータを、少なくとも第１の提示レートおよび第２の提示レートを含むそれぞれ異なる提示レートで提示するよう構成されているデータ提示モジュールを含んでよい。

受信したデータがマルチメディアコンテンツを含み、受信したデータの提示が、ビデオコンテンツの提示またはオーディオコンテンツの再生の少なくとも１つを含む、上述した例のデバイスも構成可能である。

データが通信モジュールで実質的に連続して受信される、上述した例のデバイスも構成可能である。

データ提示モジュールが、閾値条件に到達するまでは第１の提示レートで、受信したデータを提示して、その後、第２の提示レートで、受信したデータを提示する、上述した例のデバイスも構成可能である。上述した例のデバイスのこの構成では、さらに、閾値条件が、メモリモジュールで受信したデータ量であってもよい。上述した例のデバイスのこの構成では、さらに、閾値条件が、通信モジュールがデータを受信する接続の品質に基づいていてもよい。

上述した例のデバイスでは、さらに、第１の提示レートが第２の提示レート未満であってもよい。この構成では、上述した例のデバイスにおいてさらに、受信したデータの第１の提示レートでの提示と、受信したデータの第２の提示レートでの提示との差が、提示を見ているデバイスのユーザには実質的に認知できなくてよい。

上述した例のデバイスにおいては、さらに処理モジュールを含んでよく、データ提示モジュールは、処理モジュールに、受信したデータを第１の提示レートで提示させ、次いで、第２の提示レートで提示させるよう構成されていてよい。

別の例の実施形態では、方法が提供される。方法は、デバイスでデータを受信する段階と、デバイスメモリに、受信したデータを格納する段階と、受信したデータを、少なくとも第１の提示レートおよび第２の提示レートを含むそれぞれ異なる提示レートで提示する段階とを含んでよい。

受信したデータがマルチメディアコンテンツを含み、受信したデータの提示が、ビデオコンテンツの提示またはオーディオコンテンツの再生の少なくとも１つを含む、上述した例の方法も構成可能である。

データが通信モジュールで実質的に連続して受信される、上述した例の方法も構成可能である。

データ提示モジュールが、閾値条件に到達するまでは第１の提示レートで、受信したデータを提示して、その後、第２の提示レートで、受信したデータを提示する、上述した例の方法も構成可能である。上述した例の方法のこの構成では、さらに、閾値条件が、デバイスメモリで受信したデータ量であってもよい。上述した例の方法の構成では、さらに、閾値条件が、デバイスがデータを受信する接続の品質に基づいていてもよい。

上述した例の方法では、さらに、第１の提示レートが第２の提示レート未満であってもよい。この構成では、上述した例の方法においてさらに、受信したデータの第１の提示レートでの提示と、受信したデータの第２の提示レートでの提示との差が、提示を見ているデバイスのユーザには実質的に認知できなくてよい。

別の実施形態として、少なくともデバイスとデータソースとを含み、上述した例の方法を実行するシステムが提示される。

別の実施形態として、上述した例の方法を実行するチップセットが提示される。

別の実施形態として、コンピューティングデバイス上で実行されると、コンピューティングデバイスに、上述した例の方法のうちのいずれかの方法を実行させる複数の命令を含む少なくとも１つの機械可読媒体が提示される。

別の実施形態として、上述した例の方法のうちのいずれかの方法を実行する、エネルギーを節約しつつデータを連続配信するデバイスが提示される。

別の実施形態として、個々に、または組み合わせで、１以上のプロセッサにより実行されると、システムが上述した例の方法のいずれかを実行するような命令を格納している少なくとも１つの機械可読記憶媒体を含むシステムを提供する。

別の実施形態では、デバイスが提示される。デバイスは、データを少なくとも受信するよう構成されている通信モジュール、受信したデータをバッファリングするよう構成されているメモリモジュール、および、受信したデータを、少なくとも第１の提示レートおよび第２の提示レートを含むそれぞれ異なる提示レートで提示するよう構成されているデータ提示モジュールを含んでよい。

上述した例のデバイスでは、第１の提示レートが第２の提示レート未満であってもよく、受信したデータの第１の提示レートでの提示と、受信したデータの第２の提示レートでの提示との差が、提示を見ているデバイスのユーザには実質的に認知できなくてよい。

別の実施形態では、方法が提供される。方法は、デバイスでデータを受信する段階と、デバイスメモリに、受信したデータを格納する段階と、受信したデータを、少なくとも第１の提示レートおよび第２の提示レートを含むそれぞれ異なる提示レートで提示する段階とを含んでよい。

閾値条件に到達するまでは第１の提示レートで、受信したデータを提示して、その後、第２の提示レートで、受信したデータを提示する、上述した例の方法も構成可能である。上述した例の方法のこの構成では、さらに、閾値条件が、デバイスメモリで受信したデータ量であってもよい。上述した例の方法のこの構成では、さらに、閾値条件が、通信モジュールがデータを受信する接続の品質に基づいていてもよい。

上述した例の方法では、第１の提示レートが第２の提示レート未満であってもよく、受信したデータの第１の提示レートでの提示と、受信したデータの第２の提示レートでの提示との差が、提示を見ているデバイスのユーザには実質的に認知できなくてよい

別の例の実施形態では、デバイスが提供される。デバイスは、データを少なくとも受信するよう構成されている通信モジュール、受信したデータをバッファリングするよう構成されているメモリモジュール、および、受信したデータを、少なくとも第１の提示レートおよび第２の提示レートを含むそれぞれ異なる提示レートで提示するよう構成されているデータ提示モジュールを含んでよい。

閾値条件に到達するまでは第１の提示レートで、受信したデータを提示して、その後、第２の提示レートで、受信したデータを提示する、上述した例の方法も構成可能である。上述した例の方法のこの構成では、さらに、閾値条件が、デバイスメモリで受信したデータ量であってもよい。上述した例の方法のこの構成では、さらに、閾値条件が、デバイスがデータを受信する接続の品質に基づいていてもよい。

別の実施形態では、システムが提示される。システムは、デバイスでデータを受信する手段と、デバイスメモリに、受信したデータを格納する手段と、受信したデータを、少なくとも第１の提示レートおよび第２の提示レートを含むそれぞれ異なる提示レートで提示する手段とを含んでよい。

受信したデータがマルチメディアコンテンツを含み、受信したデータの提示が、ビデオコンテンツの提示またはオーディオコンテンツの再生の少なくとも１つを含む、上述した例のシステムも構成可能である。

上述した例のシステムは、実質的に連続してデータを受信するよう構成することもできる。

閾値条件に到達するまでは第１の提示レートで、受信したデータを提示して、その後、第２の提示レートで、受信したデータを提示する、上述した例のシステムも構成可能である。上述した例のシステムの構成では、さらに、閾値条件が、メモリモジュールで受信したデータ量であってもよい。上述した例のシステムのこの構成では、さらに、閾値条件が、デバイスがデータを受信する接続の品質に基づいていてもよい。

上述した例のシステムでは、さらに、第１の提示レートが第２の提示レート未満であってもよい。この構成では、上述した例のシステムにおいてさらに、受信したデータの第１の提示レートでの提示と、受信したデータの第２の提示レートでの提示との差が、提示を見ているデバイスのユーザには実質的に認知できなくてよい。

本明細書で利用してきた用語および言い回しは、記載のために利用されており限定を意図しておらず、用語および言い回しの利用には、示され記載されている特徴の均等物（またはその部分）を排除する意図はなく、様々な変形例が請求項の範囲に含まれる。したがって請求項はこれら均等物すべてを含むことを意図している。

Claims

データを少なくとも受信するよう構成されている通信モジュールと、
受信した前記データをバッファリングするよう構成されているメモリモジュールと、
受信した前記データを、少なくとも第１の提示レートおよび第２の提示レートを含むそれぞれ異なる提示レートで提示するよう構成されているデータ提示モジュールと
を備えるデバイス。
受信した前記データがマルチメディアコンテンツを含み、受信した前記データの提示が、ビデオコンテンツの提示またはオーディオコンテンツの再生の少なくとも１つを含む、請求項１に記載のデバイス。
前記データが前記通信モジュールで実質的に連続して受信される、請求項１または２に記載のデバイス。
前記データ提示モジュールが、さらに、閾値条件に到達するまでは前記第１の提示レートで、受信した前記データを提示して、その後、前記第２の提示レートで、受信した前記データを提示する、請求項１から３のいずれか一項に記載のデバイス。
前記閾値条件が、前記メモリモジュールで受信したデータ量である、請求項４に記載のデバイス。
前記閾値条件が、前記通信モジュールが前記データを受信する接続の品質に基づいている、請求項４に記載のデバイス。
前記第１の提示レートが前記第２の提示レート未満である、請求項１から６のいずれか一項に記載のデバイス。
受信した前記データの前記第１の提示レートでの提示と、受信した前記データの前記第２の提示レートでの提示との差が、前記提示を見ている前記デバイスのユーザには実質的に認知できない、請求項７に記載のデバイス。
さらに処理モジュールを含み、前記データ提示モジュールは、前記処理モジュールに、受信した前記データを第１の提示レートで提示させ、次いで、第２の提示レートで提示させる、請求項１から８のいずれか一項に記載のデバイス。
デバイスでデータを受信する段階と、
デバイスメモリに、受信した前記データを格納する段階と、
受信した前記データを、少なくとも第１の提示レートおよび第２の提示レートを含むそれぞれ異なる提示レートで提示する段階と
を備える方法。
受信した前記データがマルチメディアコンテンツを含み、受信した前記データの提示が、ビデオコンテンツの提示またはオーディオコンテンツの再生の少なくとも１つを含む、請求項１０に記載の方法。
前記データが実質的に連続して受信される、請求項１０または１１に記載の方法。
閾値条件に到達するまでは前記第１の提示レートで、受信した前記データを提示して、その後、前記第２の提示レートで提示する、請求項１０から１２のいずれか一項に記載の方法。
前記閾値条件が、前記デバイスメモリで受信したデータ量である、請求項１３に記載の方法。
前記閾値条件が、前記デバイスが前記データを受信する接続の品質に基づいている、請求項１３に記載の方法。
前記第１の提示レートが前記第２の提示レート未満である、請求項１０から１５のいずれか一項に記載の方法。
受信した前記データの前記第１の提示レートでの提示と、受信した前記データの前記第２の提示レートでの提示との差が、前記提示を見ている前記デバイスのユーザには実質的に認知できない、請求項１６に記載の方法。
個々に、または組み合わせで、１以上のプロセッサにより実行されると、段階を実行するような命令を格納している少なくとも１つの機械可読記憶媒体を含むシステムであって、
前記段階は、
デバイスでデータを受信する段階と、
デバイスメモリに、受信した前記データを格納する段階と、
受信した前記データを、少なくとも第１の提示レートおよび第２の提示レートを含むそれぞれ異なる提示レートで提示する段階と
を含む、システム。
受信した前記データがマルチメディアコンテンツを含み、受信した前記データの提示が、ビデオコンテンツの提示またはオーディオコンテンツの再生の少なくとも１つを含む、請求項１８に記載のシステム。
前記データが実質的に連続して受信される、請求項１８または１９に記載のシステム。
閾値条件に到達するまでは前記第１の提示レートで、受信した前記データを提示して、その後、前記第２の提示レートで提示する、請求項１８から２０のいずれか一項に記載のシステム。
前記閾値条件が、前記デバイスメモリで受信したデータ量である、請求項２１に記載のシステム。
前記閾値条件が、前記デバイスが前記データを受信する接続の品質に基づいている、請求項２１に記載のシステム。
前記第１の提示レートが前記第２の提示レート未満である、請求項１８から２３のいずれか一項に記載のシステム。
受信した前記データの前記第１の提示レートでの提示と、受信した前記データの前記第２の提示レートでの提示との差が、前記提示を見ている前記デバイスのユーザには実質的に認知できない、請求項２４に記載のシステム。