JP2016063423A - 情報処理装置、通信装置、端末、通信処理方法およびコンピュータプログラム - Google Patents

Abstract

【課題】情報の先行取得と低消費電力化とを両立させる。【解決手段】本発明の一態様としての情報処理装置は、先行取得部と制御部とを備える。前記先行取得部は、アプリケーションから要求される可能性がある情報を特定し、前記アプリケーションから前記情報の取得を要求される前に、前記情報をネットワークを介して取得する。前記制御部は、周囲の通信環境を計測したパラメータ値に応じた評価値に基づき、前記先行取得部の動作を制御する。【選択図】図１

Description

本発明の実施形態は、情報処理装置、通信装置、端末、通信処理方法およびコンピュータプログラムに関する。

アプリケーションが発した通信要求を一時的に保存し、当該通信要求を実行可能と判断されたときに、当該通信要求を実行する技術が知られている。また、トラフィックがひっ迫している携帯電話網から、無線ＬＡＮネットワークへのオフローディングを行う際に、無線ＬＡＮによる通信が可能となるまで一定時間待機し、その待機時間に上限を設けることが知られている。また、携帯電話網よりも通信効率がよい無線ＬＡＮ通信が利用できる際に、将来利用が見込まれる情報を先行取得する技術が知られている。

しかしながら、無線ＬＡＮによる通信が可能となるまで一定時間待機させる場合、待機させる時間が明確ではない、もしくは固定値となっており、柔軟な通信可否の判断ができない。例えば、待機中に、通信可能と判断する基準値をわずかに下回る無線ＬＡＮエリアを検出しているにもかかわらず、無線ＬＡＮでの通信を行わず、トラフィックがひっ迫している携帯電話網を使ってデータを送受信してしまう可能性がある。この結果、通信の開始まで長時間待機することとなるとともに、消費エネルギーの増加にもなる。

一方、先行取得する技術に対しては、無線ＬＡＮ通信が安定して利用できる状況であると、情報を際限なく先行取得してしまう恐れがある。その結果、バッテリー駆動の装置の場合、バッテリーに蓄えたエネルギーを必要以上に消費し、駆動時間が短くなってしまう可能性がある。

米国出願公開２０１２／０２１４５２７号明細書

Kyunghan Lee , et al., "Mobile Data Offloading: How Much Can WiFi Deliver?", Co-NEXT '10

本発明の実施形態は、情報の先行取得と、低消費電力化を両立させることを目的とする。

本発明の一態様としての情報処理装置は、先行取得部と制御部とを備える。前記先行取得部は、アプリケーションから要求される可能性がある情報を特定し、前記アプリケーションから前記情報の取得を要求される前に、前記情報をネットワークを介して取得する。前記制御部は、周囲の通信環境を計測したパラメータ値に応じた評価値に基づき、前記先行取得部の動作を制御する。

本発明の実施形態に係る情報処理装置を搭載した通信装置の機能ブロック図。 図１の通信装置にセンサを搭載した機能ブロック図。 第１の実施形態に係る第１の動作例のフローチャートを示す図。 通信装置における先行取得動作の状態遷移図。 第１の実施形態に係る第２の動作例のフローチャートを示す図。 図５の動作に対応する状態遷移図。 先行取得部の動作のフローチャートを示す図。 図７のステップＳ６０２の詳細な動作のフローチャートを示す図。 第１の実施形態の動作の具体例を説明するための図。 第２の実施形態に係る情報処理装置を搭載した通信装置の機能ブロック図。 第２の実施形態の動作の具体例を説明するための図。 第２の実施形態の動作の他の具体例を説明するための図。 第２の実施形態の動作のさらに他の具体例を説明するための図。 第３の実施形態に係る情報処理装置を搭載した通信装置の機能ブロック図。 第５の実施形態に係る情報処理装置を搭載した端末を示す図。

以下、図面を参照しながら、本発明の実施形態について説明する。ここで示す形態は一例であり、本願発明は、必ずしも同一の形態で実施される必要はない。また、図面において、同一の構成要素には同じ番号を付し、説明は適宜省略する。
（第１の実施形態）
図１に本発明の実施形態に係る情報処理装置を搭載した通信装置の機能ブロック図を示す。なお、図１には本願発明の説明に必要な要素のみを記しており、他の要素の存在を排除するものではない。

通信装置１００は、中央処理部１０１、メモリ１０５、ストレージ１０６、および通信Ｉ／Ｆ部１０７を備える。中央処理部１０１は、本実施形態に係る情報処理装置に相当する。

中央処理部（情報処理装置）１０１は、本装置の動作を司る中央処理部であり、アプリ実行部１０２、通信処理部１０３、先行取得部１０４、制御部１０８を備える。

アプリ実行部１０２、通信処理部１０３、先行取得部１０４、制御部１０８は、それぞれ個別のハードウェア要素として構成されてもよいし、ＣＰＵ等のプロセッサの上で動作するソフトウェアによって実現されてもよい。

アプリ実行部１０２は、通信装置１００上で動作するアプリケーション（例えばウェブブラウザ、ニュースアプリ、地図アプリ、動画プレイヤー、音楽プレイヤーなど）の実行を担当する。

通信処理部１０２は、ＴＣＰ／ＩＰなどの通信プロトコルを実行する。アプリ実行部１０１や後述の先行取得部１０３は、通信処理部１０２を用いて、ネットワークを介した情報取得を行う。

先行取得部１０４は、先行取得部１０４は、アプリ実行部１０１で動作するアプリケーションからの指示や、ネットワークを介した外部のサーバからの指示に基づき、将来参照する可能性がある情報（すなわちアプリケーションから将来、取得を要求される可能性がある情報）を取得する。たとえば、アプリ実行部１０１が、自身の要求に応じて取得したＨＴＭＬファイル内に含まれるＵＲＬ等のリンク先を特定し、特定したリンク先の情報の取得の指示を、先行取得部１０４に指示する。当該情報の取得の実際の要求は、例えばユーザ等によりリンクが指定されたときに行われるが、そのような指定を受ける前に事前に取得しておく。先行取得した情報は、後述するようにＵＲＬ等の識別子と関連づけて、メモリ１０５やストレージ１０６に格納しておく。
また、先行取得部１０４は、アプリ実行部１０１で動作するアプリケーションからの要求に応じて取得された情報を独自に解析することにより、将来参照する可能性がある情報を自律的に取得する機能を備えていてもよい。例えば、アプリ実行部１０１からの要求に応じて取得されたＨＴＭＬファイルを受けとってＵＲＬ等のリンク先を特定し、当該リンク先の情報をネットワークを介して取得してもよい。この場合、アプリ実行部１０２は、情報の取得要求を先行取得部１０４に出力するようにし、先行取得部１０４は当該取得要求に応じて取得した情報（ＨＴＭＬファイル等）をアプリ実行部１０２に返すようにしてもよい。先行取得部１０４は、アプリ実行部１０２から要求された情報が、先行取得済みである場合はその情報をメモリ１０５またはストレージ１０６から読み出して返すことができる。

メモリ１０５はＤＲＡＭなどの揮発性メモリや、ＭＲＡＭなどの不揮発性メモリであり、中央処理部１０１で実行されるプログラムや、各種のデータなどを一時的に格納する記憶部である。

ストレージ１０６は、中央処理部１０１で実行されるプログラムや、各種のデータを、永続的に保存する記憶部である。ストレージ１０６は、例えば、ＨＤＤ（ハードディスクドライブ）やＳＳＤ（ソリッドステートドライブ）で構成される。

通信Ｉ／Ｆ部１０７は、通信処理部１０３で実行される通信プロトコル（例えばＴＣＰ／ＩＰなどの）に従って構成された情報列を、ネットワークとの間で交換するインタフェースである。ネットワークの例としてはＬＴＥ、ＣＤＭＡやＧＳＭ、ＷｉＭＡＸなどのセルラー通信技術、ＩＥＥＥ ８０２．１１に準拠する無線ＬＡＮなどである。

制御部１０８は、大きく二つの機能を具備する。

第一に、制御部１０８は、先行取得部１０４が先行取得を行うか否かを判断するための条件を制御（変更）する。

第二に、制御部１０８は、周囲の通信環境の把握、および通信装置の現在の状態（装置状態）の把握との少なくとも一方を行い、通信環境および現在の状態の少なくとも一方に基づいて先行取得の可否を判断する。通信環境の把握は、通信Ｉ／Ｆ部１０７を用いてＲＳＳＩやＳＮ比等のパラメータ値を測定することで可能である。センサを用いた通信環境の把握も可能である。この場合、図２に示すように、センサ１０９を通信装置１００に搭載すればよい。センサ１０９は、加速度、音、照度、磁気、電流・電圧などのセンサである。センサ１０９は、中央処理部１０１によって動作が制御されることができる。また、装置状態は、センサ１０９を用いて把握できる。例えばセンサ１０９を用いて、バッテリーなどの一時的な電源手段から給電されているか、ＡＣアダプタ等の恒久的な電源手段から給電されているかを、判断することもできる。

図３に、第１の実施形態に係る第１の動作例のフローチャートを示す。前提として、このフローチャートの処理は、先行取得部１０４による先行取得処理とは、同時並行的に（時分割を含む）実行されるものとする。ここでは、通信環境および装置状態のうち、通信環境のみ把握する場合を想定する。最初に通信環境Ｅ_ｉを把握（通信環境のパラメータ値を測定）する（Ｓ２０１）。そして、把握した現在の通信環境Ｅ_ｉに基づき、現在の通信環境の評価値を計算する。通信環境Ｅ_ｉの値（パラメータの測定値）そのものを評価値として扱ってもよいし、所定の値域（０〜１００の範囲など）内の値に変換したものを評価値としてもよい。評価値を計算したら、当該計算した評価値と、過去に計算された評価値を用いて、短期総合評価値および長期総合評価値を計算する。

すなわち、短期的な変化に基づく総合評価関数Ｅｖａｌ_{ｓｈｏｒｔ}（）と長期的な変化に基づく総合評価関数Ｅｖａｌ_ｌｏｎｇ（）を計算する。これら２つの関数は、現在および過去の通信環境の評価値に基づき、現状が通信にどの程度適しているかを表す短期総合評価値および長期総合評価値（例えば０〜１００の間の整数で、値が大きい方が適している）を出力するものである。短期と長期の違いは、例えば参照する過去のデータ数であり、短期の評価関数は、長期の評価関数よりも少ないデータ数を用いる。短期の評価関数Ｅｖａｌ_{ｓｈｏｒｔ}（）の出力値を短期総合評価値Ｒ_ｓ、長期の評価関数Ｅｖａｌ_ｌｏｎｇ（）の出力値を長期総合評価値Ｒ_Ｌとする。

例えば、短期の評価関数の場合はＥｊ（ｊ＝ｉ、ｉ−１、…、ｉ−４）を使用して、過去５回の移動平均を短期総合評価値Ｒ_ｓとして算出し、長期の評価関数の場合はＥｊ（ｊ＝ｉ、ｉ−１、…、ｉ−１９）を使用して、過去２０回の移動平均を長期総合評価値Ｒ_Ｌとして算出する。移動平均を求める際に関数の入力（評価値）に適切に重みづけを行ってもよく、加重移動平均や指数移動平均などの形で使用してもよい。

評価関数Ｅｖａｌ_{ｓｈｏｒｔ}（）とＥｖａｌ_ｌｏｎｇ（）の具体例を示す。通信環境Ｅ_ｉが無線ＬＡＮアクセスポイントから受信する電波の強度（ＲＳＳＩ）の場合を考える。この場合、通信できなくなる下限の強度を０とし、想定される最大の強度を１００とする評価値を通信環境Ｅ_ｉの値から計算し、それらの現在および過去の評価値の平均を出力する評価関数が設計できる。通信環境Ｅ_ｉが複数のパラメータからなる場合も同様である。例えば、受信電波強度（ＲＳＳＩ）と信号対雑音比（ＳＮＲ）で規定されている場合、各々に対して０〜１００のスコアをつけ、それらの平均値を評価値とするなどとすればよい。他にも、使用する通信・符号化方式（２５６ＱＡＭや６４ＱＡＭなど）ごとにＲＳＳＩとＳＮＲの組み合わせに対して事前にスコアを決めておき、それらの平均値を評価値とすることもできる。

フローチャートの説明に戻る。Ｓ２０４にて先行取得部１０４が先行取得動作中か否かを判断する。先行取得動作中だった場合（Ｓ２０４−ＹＥＳ）、ステップＳ２０５に進む。Ｓ２０５では短期および長期の総合評価値に基づき、先行取得の可否の判断を行う。短期総合評価値Ｒ_Ｓが基準値（閾値）Ｖｓｈｏｒｔ以上であり、かつ長期総合評価値が基準値（閾値）Ｖｌｏｎｇ未満である場合（Ｓ２０５−ＹＥＳ）、先行取得を許可する。すなわち、現在の先行取得動作の現状維持を判断し、一定時間待機（Ｓ２０７）した後、最初のステップＳ２０１に戻る。

ここで、短期総合評価値Ｒ_Ｓが基準値Ｖｓｈｏｒｔ以上の場合、通信環境は、短期的な視点で通信に適した状態にあると言える。短期総合評価値Ｒ_Ｓが基準値Ｖｓｈｏｒｔ未満の場合、通信環境は、短期的な視点で通信に適していない状態にあるといえる。長期総合評価値が基準値Ｖｌｏｎｇ以上の場合、通信環境は、長期的な視点で通信に適した状態にあると言える。長期総合評価値が基準値Ｖｌｏｎｇ未満の場合、通信環境は、長期的な視点で通信に適していない状態にあると言える。ここでは、短期および長期とも総合評価値が閾値（基準値）以上の場合に通信に適した状態と判断したが、測定する通信環境のパラメータ値によっては閾値未満の場合に通信に適した状態と判断する構成も可能である。例えば、通信環境として環境ノイズを測定する場合に、環境ノイズの値に応じた評価値群から計算する短期および長期の総合評価値が閾値未満の場合に、それぞれ通信に適した状態と判断してもよい。

前述の条件を満たしていない場合（Ｓ２０５−ＮＯ）、すなわち短期総合評価値Ｒ_Ｓが基準値Ｖｓｈｏｒｔ未満、または長期総合評価値が基準値Ｖｌｏｎｇ以上である場合には、先行取得を許可しないと判断し、先行取得を停止する（Ｓ２０６）。そして、一定時間待機（Ｓ２０７）した後、最初のステップ（Ｓ２０１）に戻る。

先行取得中ではない場合（Ｓ２０４−ＮＯ）、Ｓ２０８に進む。Ｓ２０８では、Ｓ２０５と同様の判断を行う。上述の条件が満たされる場合（Ｓ２０８−ＹＥＳ）先行取得を開始し（Ｓ２０９）、一定時間待機（２０７）した後、最初のステップＳ２０１に戻る。条件が満たされない場合（Ｓ２０８−ＮＯ）、現状維持と判断され、一定時間待機（Ｓ２０７）した後、最初のステップＳ２０１に戻る。

一連の説明にて「先行取得を開始」（Ｓ２０９）もしくは「先行取得を停止」（Ｓ２０６）という表現を用いたが、先行取得処理の過程のどの箇所で実際に先行取得の実行と停止を行うかは、実装依存である。先に述べた通り、先行取得処理と、開始または停止の判断処理とは、独立して動作するため、「開始」と「停止」の処理は、例えばソフトウェアによる実装であれば、プロセスもしくはスレッドの起動と停止と、実行中の先行取得プロセスもしくはスレッドとの間に確立されたプロセス間通信などによる制御メッセージの交換（実行指示、停止指示）といった形で実現される。先行取得処理を行うプロセスもしくはスレッドを、どのステップで停止するかは実装依存である。同様に、ハードウェアで実装されている場合には、Ｅｎａｂｌｅ／Ｄｉｓａｂｌｅ信号の設定や、動作クロックの投入と停止などの形で実現できるが、その方法は実装依存である。

図４に、図３のフローチャートに基づく通信装置１００における先行取得動作の状態遷移図を示す。長期的な視点で通信に適した状態Ｓ１と、短期的な視点で通信に適した状態Ｓ２とが存在し、これらの状態間の遷移が示される。なお、この図では、短期総合評価値または長期総合評価値が基準値以上であることをＧ、基準値より小さいことをＢ、どちらでもよいことを＊と記す。また、各遷移に付された（Ｘ、Ｙ）は、短期総合評価値がＸ、長期総合評価値がＹであることを示す。

図４に示すように、短期的な視点で通信に適した状態Ｓ２に遷移したら、先行取得を開始し、長期的な視点で通信に適した状態Ｓ１が継続している場合には、先行取得を停止する。このように制御することにより、無線ＬＡＮアクセスポイントのそばから移動しない状況など、通信環境が安定した状態で必要以上に多くの情報を先行取得することを防止できる。その結果、ネットワークを流れるトラフィックを抑制でき、送受信に要するエネルギー消費を抑制できる。

図３のフローチャートの動作例では、通信環境および装置状態のうち通信環境のみを用いて評価を行ったが、以下では、通信環境および装置状態の両方を用いて評価を行う場合を示す。前提として、制御部１０９は、電源の供給状態を把握することができ、この機能を用いて、商用電源（ＡＣアダプタ）等の連続的な電源供給がなされている場合と、バッテリー等の一時的な電源供給がなされている場合とで、通信装置の装置状態を区別する。

図５に、第２の動作例のフローチャートを示す。変更点は、ステップＳ２０２、Ｓ４０１およびＳ４０２である。ステップＳ２０２では、通信装置１００の装置状態Ｓ_ｉを把握する。

ステップＳ４０１にて電源の供給状態に基づく判断を行う。商用電源等の連続供給可能な電源から供給されていれば（Ｓ４０１−ＹＥＳ）、ステップＳ４０２に進む。バッテリー等の連続供給できない電源の場合（Ｓ４０１−ＮＯ）には、ステップＳ２０５に進む。ステップＳ２０５に進んだ後の処理は、図３の動作と同じであるため省略する。

ステップＳ４０２では短期総合評価値Ｒｓが、基準値Ｖｓｈｏｒｔ以上であるか否かを判断する。基準値Ｖｓｈｏｒｔ以上であれば（Ｓ４０２−ＹＥＳ）、現状維持（先行取得継続）と判断され、一定時間待機（Ｓ２０７）した後、最初のステップＳ２０１に戻る。基準値Ｖｓｈｏｒｔに達しない場合（Ｓ４０２−ＮＯ）、先行取得を停止し（Ｓ２０６）、一定時間待機（Ｓ２０７）した後、最初のステップＳ２０１に戻る。

図６に、図５の動作に対応する状態遷移図を示す。図４と異なり、長期的な視点で通信に適した状態Ｓ１と、短期的な視点で通信に適した状態Ｓ２とを含む状態遷移図が２つ存在し、連続的な電源供給があるか否かの装置状態に応じて、これら２つの状態遷移図が切り換えられる。

以上に述べたように、第２の動作例に従えば、バッテリー等の連続供給できない電源から電力が供給されている場合は、短期的な視点で通信に適した状態に遷移したら、先行取得を開始し、長期的な視点で通信に適した状態が継続している場合には、先行取得を停止する。このように制御することにより、無線ＬＡＮアクセスポイントのそばから移動しない状況など、通信環境が安定した状態で、必要以上に多くの情報を先行取得することを防止できる。その結果、先行取得に要するエネルギー消費を抑制できる。また、商用電源等の連続供給できる電源から電力が供給されている場合には、通信環境が安定してよい場合には先行取得を継続することができ、より多くの情報をストレージ１０６に保存しておくことができる。

前述した図３の第１の動作例、および図５の第２の動作例では、総合評価値（短期および長期）を算出する際、通信環境のみを用いたが、装置状態を追加で用いて、総合評価値を算出してもよい。例えば、装置状態として加速度センサを用いて加速度を計算し、過去複数回（短期、長期）の加速度からの変化からユーザの歩行状態（歩いている、静止している、走っている等）を判断し、判断結果に応じて、通信環境から計算したスコアを調整した値を、総合評価値としてもよい。例えば走っているときは、現在の通信環境が変化する可能性が高いとして、通信環境から計算したスコア（例えば０〜１００の範囲内の値）を小さく調整し、これを総合評価値としてもよい。

（先行取得処理の詳細）
以下、通信装置１００の先行取得部１０４の動作について、詳細に説明する。先行取得部１０４は、先に述べた通り、アプリ実行部１０２で実行されるアプリケーションからの指示（先行取得指示）、もしくは通信Ｉ／Ｆ部１０７を介して接続するネットワーク上の通信相手装置からの指示（先行取得指示）に基づいて実行される。または、先行取得部１０４は、アプリ実行部１０１で動作するアプリケーションからの要求に応じて取得された情報を解析することにより、アプリ実行部１０１から指示を受けることなく、将来参照する可能性がある情報を自律的に取得してもよい。

ここで先行取得指示とは、（１）ネットワーク上の情報を特定する識別子（ＵＲＬ）が格納されたメモリ領域に関する情報を通知することによる指示、（２）当該ＵＲＬが格納されたファイルに関する情報を通知することによる指示、（３）ＩＰパケット群などからなるメッセージを通知することによる指示、（４）ファイルのＵＲＬを通知することによる指示などである。

上記の（１）と（２）の先行取得指示は、アプリ実行部１０２からメモリ１０５もしくはストレージ１０６を介して先行取得部１０４に通知することによって行うものである。すなわち、アプリ実行部１０２がメモリ１０５上にバッファを確保し、そのバッファ内に将来アクセスが発生すると予想されるＵＲＬを格納していき、そのバッファの位置（ポインタ）を先行取得部１０４に通知するなどの方法が考えられる。同様に、アプリ実行部１０２がストレージ１０６上にファイルを作成して、そのファイルにＵＲＬを格納していき、ファイル名やファイルディスクリプタ、ファイルクラスのインスタンスなどの形で先行取得部１０４に通知する。

（３）と（４）の先行取得指示は、ネットワークを介して受け取る指示であり、基本的には、（１）と（２）と同様である。すなわち、（３）の指示は、（１）、（２）で示したような形式の情報が、ＩＰパケットに分割されてネットワークから伝えられることによって、先行取得指示を受信する方法である。（４）の指示は、前述のファイルと同様の形式で記載されたファイルを特定するＵＲＬを、ネットワークを介して受信し、通信装置１００が該ＵＲＬからファイルを取得することによって、先行取得指示を入手する方法である。

なお、取得すべき情報のＵＲＬが記載されたファイルは、通信装置１００にて利用できるフォーマットであれば、どのようなフォーマットであってもよい。例えば、テキストファイル（１行に１つのＵＲＬを記載したもの、ＣＳＶフォーマット、ＨＴＭＬフォーマット、ＸＭＬフォーマット、ＣＳＳフォーマット、など）や、それに所定の操作（圧縮や暗号化など）を施したバイナリファイルなどが考えられる。

図７は、先行取得部１０４の動作のフローチャートである。これまでに述べた何らかの方法で先行取得指示を入手すると（Ｓ６０１−ＹＥＳ）、先行取得部１０４は当該指示を解析する（Ｓ６０２）。ここで解析とは、取得すべき情報を特定する処理であり、例えば、ＨＴＭＬフォーマットに従ったテキストファイルからリンク（ＵＲＬ）を抽出し、リンク先の情報を、取得すべき情報として特定する。メモリ１０５上に格納される形で、先行取得指示を受信している場合には、解析済みの情報（リンク）が渡されている可能性がある。その場合には、解析処理はスキップしてよい。いずれにせよ、情報を取得すべきＵＲＬを抽出し、メモリ１０５もしくはストレージ１０６に保存しておく（Ｓ６０２）。なお、先行取得指示が無い場合は（Ｓ６０１−ＮＯ）、引き続き待機して、先行取得指示が来るまで待つ（Ｓ６０３）。

この情報を先行取得すべきＵＲＬの指示は、先行取得を実行中も追加できるようにしてもよい。これにはメモリ１０５にＦＩＦＯキュー形式で、抽出したＵＲＬを格納しておくことで対応が可能である。もしくはストレージ１０６上のファイルに対して、ＵＲＬを追記していくことで対応可能である。

図８は、図７のステップＳ６０２の詳細な動作のフローチャートである。先行取得処理は、情報を取得すべきＵＲＬが、メモリ１０５もしくはストレージ１０６に保存されているかを判断する（Ｓ６１１）。ＵＲＬが保存されていない場合は、一定時間待機して（Ｓ６２０）、ステップＳ６１１に戻る。一方、ＵＲＬが保存されている場合には、アプリ実行部１０２の動作とは独立して実行される（Ｓ６１１−ＹＥＳ）。

先行取得部１０４は格納されているＵＲＬを、メモリ１０５もしくはストレージ１０６から読み出し（Ｓ６１２）、ＨＴＴＰなどＵＲＬで指定された通信プロトコルに従って取得要求メッセージを生成（Ｓ６１３）した後、ＴＣＰ／ＩＰ処理を実行するために通信処理部１０３に処理を依頼する（Ｓ６１４）。この依頼は、例えば、ＳｏｃｋｅｔＡＰＩを介したメッセージと制御情報の交換と捉えることができ、ｓｅｎｄ（）などのＡＰＩを実行することで、取得要求メッセージを所定のサーバに送信する。

通信処理部１０３は受けとった取得要求メッセージを、ＴＣＰ／ＩＰに従って適切に処理した後、通信Ｉ／Ｆ部１０７を介して所定のサーバに送信する。その後、サーバは要求した情報を送り返し、通信Ｉ／Ｆ部１０７と通信処理部１０３を介して、先行取得部１０４に応答が届く（Ｓ６１５、Ｓ６１６、Ｓ６１７、Ｓ６１８）。先行取得部１０４は取得した応答内のデータを、情報を識別する識別子（ＵＲＬなど）と関連づけた状態で、メモリ１０５もしくはストレージ１０６に保存しておく（Ｓ６１９）。

以上の処理を、抽出したＵＲＬに対して繰り返し実行することで、先行取得が可能となる。

（先行取得処理の実行と、制御部１０８による取得可否判断の関係）
一連の先行取得処理（図７、図８の処理）は、制御部１０８による取得可否判断（図３、図５の動作）により、実行の制約を受ける。先に述べた通り先行取得処理と取得可否判断（図３、図５の動作）とは、独立に実行されるため、先行取得処理がソフトウェアで実現されているのであれば、実装上の都合がよい箇所にて、先行取得の実行を中断することができる。

例えば、取得すべきＵＲＬを読み出すステップ（Ｓ６１２）の実行タイミングにて、取得可否判断の結果を参照し、取得不可であれば、以降の処理を実行しないようにすればよい（Ｓ６１２の前に判断処理を加え、先行取得が許可されていなければステップＳ６２０に遷移して、一定時間待機するようにすればよい）。この方法を採用した場合、先行取得部１０４の内部で処理の実行と停止が実現できる。ただし、制御できる通信は先行取得部１０４で行う通信のみとなる。

一方、発行された取得要求メッセージが、ネットワークに送信されないように制御するという実装にすることもできる。この場合、通信処理部１０３に手を加え、通信Ｉ／Ｆ部１０７に送信される直前、もしくは通信プロトコル処理のいずれかのステップで、取得可否判断の結果を参照し、以降の処理を実行しないようにすればよい（Ｓ６１４の部分）。この方法を採用した場合、通信プロトコル処理の改変を伴うため実装が難しくなると考えられるが、汎用的に通信を制御することができると考えられる。

なお、先に述べた通り、実行と停止の実現方法は、ソフトウェアであればプロセスもしくはスレッドの起動と停止、プロセスもしくはスレッドの停止状態への遷移と復帰などで実現でき、ハードウェアであればクロックの投入と停止、電源の投入と停止などにより実現できる。

（補足説明：短期総合評価値と長期総合評価値および基準値の扱いについて）
第１の実施形態に関する一連の説明において、通信環境Ｅ_ｉおよび装置状態Ｓ_ｉの少なくとも一方と、評価関数Ｅｖａｌ_{ｓｈｏｒｔ}（）、Ｅｖａｌ_ｌｏｎｇ（）を使って短期総合評価値および長期総合評価値を得るとの説明をした。この部分について、図９を使ってより直感的に説明する。

図９は第１の実施形態の動作の具体例を説明するための図である。図９には各評価のタイミングで取得した生データ（評価値）の系列（７００）、過去５回の生データから得た移動平均（短期総合評価値）の系列（７０１）、過去２０回の生データから得た移動平均（長期総合評価値）の系列（７０２）、基準値（７０３）が示されている。図９の下側の「短期」と「長期」の行は、基準値に対する状態（Ｇが上回っている、Ｂが下回っていることを示す）を示す。ここでは、基準値は、短期と長期で共通としている（Ｖｓｈｏｒｔ＝Ｖｌｏｎｇ）

既に述べたように、第１の実施形態では、図４もしくは図６に述べたような、状態遷移を行う。図９に記載のように、基準値に対する総合評価値（長期、短期）の上下関係が分かっているとき、図４もしくは図６の状態遷移図に従えば、先行取得機能の実行状態は、図９の下側の「先行取得」の行のようになる（ただし図９は図４の状態遷移図に基づいている）。

最初、長期および短期とも総合評価値が低く、先行取得を停止しており（区間７０４）、この後、短期の総合評価値が高くなったため、通信環境がある程度安定したと判断されて、先行取得が開始される（区間７０５）。その後、短期および長期とも総合評価値が高くなり、通信環境が長時間安定していることが確認できたと判断されて、先行取得は停止する（区間７０６）。その後、通信環境が短期的に悪化し（短期の総合評価値が低くなり）、さらに長期的にも悪化し（長期の総合評価値も低くなり）、先行取得は停止したままである（区間７０７、７０８）。その後、短期的に総合評価値が高くなったとき、長期の総合評価値が低くても、通信環境がある程度安定したと判断されて、先行取得が開始されるが（区間７０９）、その後、再び、短期の総合評価値が低くなったため、通信環境が悪化したと判断されて、先行取得は停止される（区間７１０）。なお、移動平均として考慮する区間の長さを変えることによって、ごく短時間の改善（短時間のみ総合評価値がよくなる状態）は、無視するように調整することもできる。

以上、第１の実施形態によれば、ネットワークを介して情報を取得する通信装置は、先行取得の機能によるメリットを享受しながら、安定的に通信が継続できる環境を検出することができ、結果的に情報を無制限に取得し続けることが避けられる。また、バッテリーのように一時的な電源供給手段を利用している際には、エネルギー消費と先行取得によるメリットとを両立できる。

（第２の実施形態）
第１の実施形態では、通信環境Ｅｉと装置状態Ｓｉの少なくとも一方を取得して総合評価値を計算し、先行取得の可否を判断していた。これに対して、本実施形態では、先行取得済みのデータ量も用いて、先行取得の可否を判断する。

図１０に、第２の実施形態に係る情報処理装置を搭載した通信装置の機能ブロック図を示す。図１と同じ名称の要素には、同一の符号を付してある。図１で示した通信装置の中央処理部１０１に、情報管理部１１０が追加されている。他の部分は、以下に述べる事項を除き、第１の実施形態と同じ動作をする。

情報管理部１１０は、先行取得した情報に関する統計情報を管理する。例えば、先行取得部１０４によって先行取得されてメモリ１０５もしくはストレージ１０６に保存されている情報の数やサイズ、アプリ実行部１０２から先行取得指示された回数やサイズや割合、アプリ実行部１０２によって参照され且つメモリ１０５もしくはストレージ１０６の情報を使ってアプリ実行部１０２に応答できた回数やサイズや割合、先行取得したが参照されていない情報のサイズや割合などがある。先行取得部１０４およびアプリ実行部１０２からメモリ１０５もしくはストレージ１０６に格納する／された情報へのアクセスを、情報管理部１１０経由で行うことで、一時管理情報管理部１０９は、これらの管理情報を管理できる。

なお、アプリ実行部１０２が要求したサイズのうち、メモリ１０５もしくはストレージ１０６から取得できなかった情報のサイズは、別途アプリ実行部１０２から通知されると仮定する。なお、メモリ１０５およびストレージ１０６から取得できなかった情報の取得については、アプリ実行部１０２で実行されるアプリケーションの一部動作を情報管理部１１０が肩代わりするように実装し、情報管理部１１０が通信相手から当該情報を取得することも可能である。この場合、アプリ実行部１０２が要求したサイズのうち、情報管理部１１０は、メモリ１０５もしくはストレージ１０６から取得できなかった情報のサイズを自ら把握できるようになる。

以下、情報管理部１１０が、先行取得部１０４が先行取得した情報のサイズおよびアプリ実行部１０２が要求したサイズ、ならびに、実際にメモリ１０５もしくはストレージ１０６から読み出されたサイズを管理しているものとして説明する。

この仮定のもと、図１１を用いて、第２の実施形態の動作の具体例を説明する。以下の説明では、「情報管理部１１０に『アプリ要求された情報の２倍まで先行取得許可、それ以上は不許可』と制御するルールが設定されている」と仮定する。

図１１に３つのグラフが示される。横軸が経過時間、縦軸がサイズである。グラフ９００は、先行取得部１０４がこれまで（原点を起点とした場合）取得した情報の合計サイズを表し、グラフ９０１はアプリ実行部１０２がこれまでに要求した情報の合計サイズを表し、グラフ９０２は、アプリ実行部１０２の要求に対して、メモリ１０５およびストレージ１０６からこれまでに読み出された情報の合計サイズを表す。

経過時間の軸の下に、各時間における先行取得の許可・不許可の判断結果を示す区間９０３−１〜９０３−３を表示している。区間９０３−１〜９０３−３の判断結果は、制御部１０８の判断結果であり、第１の実施形態で述べた環境および装置状態の少なくとも一方から、判断されたものである。また、この図では、常に（先行取得した合計サイズ）＞（要求した合計サイズ）＞（読み出した合計サイズ）の関係が成り立っており、先行取得した情報が読み出されているものの、一部は通信相手から直接、情報を取得している状態であることが分かる。この図は一例であり、この関係とは異なる関係になっていてもよい（例えば、先行取得した情報量以上にアプリ実行部１０２からの要求がある場合、など）。さらに図１１おける各グラフの増加率（＝合計サイズ／経過時間）についても一例であり、実際にはネットワークの状態変動や、アプリ実行部１０２で発生する要求の頻度などにより増加率は変化し、実装した場合には、階段状（不連続）に変化することもあると考えられる。

区間９０３−１では制御部１０８により先行取得が許可されており、グラフ９００で示すように先行取得した合計サイズが増加している。区間９０３−２に入った段階で先行取得が制御部１０８により不許可になり、グラフ９００は変化しない。途中でアプリケーション（アプリ実行部１０２）からの要求が発生し、グラフ９０１とグラフ９０２が増加していく。ここではアプリ実行部１０２から要求されたデータの一部がメモリ１０５およびストレージ１０６のいずれかから読み出せた場合を想定している。アプリ実行部１０２の当該要求の実行が完了し、その後、新たに要求も発生しなくなると、グラフ９０１とグラフ９０２の変化も止まる。

区間９０３−３に入り再び制御部１０８により先行取得が許可されると、グラフ９００の値が増加する。途中、アプリ実行部１０２の要求が発生して、グラフ９０１とグラフ９０２が一時的に増加する。一方、グラフ９００は、経過時間９０４にて、変化が止まっている。これは本実施形態における情報管理部１１０の制御により、先行取得が不許可に変化したためである（先の仮定通り、先行取得した情報のサイズ（双方向矢印付きの線９０５の部分）が、アプリ実行部１０２が要求した情報の合計サイズ（双方向矢印付きの線９０６の部分）の２倍に達している）。つまり、制御部１０８により先行取得が許可されていても、情報管理部１１０により不許可と判断されたため、全体の判断結果として、先行取得は不許可とされる。なお、双方向矢印付きの線９０７は、アプリ実行部１０２が要求した合計サイズと、メモリ１０５およびストレージ１０６から読み出した合計サイズとの差を示している。

このように第２の実施形態では、第１の実施形態での先行取得の許可・不許可の判断に加え、先行取得した情報のサイズなどに関する統計情報をさらに使って、先行取得の許可・不許可の判断を行い、これらの両方の判断結果を利用する。両方の判断結果が許可の場合のみ、先行取得を許可する。いずれか一方が不許可の場合に、先行取得を許可しない。このようにすることで、より直感的に先行取得する情報量を制御でき、ひいては消費エネルギーの削減につながる。また、ある程度の先行取得は行うため、利便性との両立も可能である。なお、ここで述べた条件は一例であり、『２倍』には限定されないし、『先行取得した情報の合計サイズと要求した情報の合計サイズの関係』にも限定されない。関係としては『先行取得した情報の合計サイズと読み出された情報の合計サイズ』や『要求した情報の合計サイズと読み出された情報の合計サイズ』でもよい。また、サイズではなく回数や個数、割合（先行取得情報に対する読み出し割合、など）であってもよい。

ただし、先行取得した情報に対する読み出し率は、先行取得を行うほど低下するので、当該読み出し率を条件として先行取得の許可・不許可の判断を行う場合には、先行取得量に対する読み出し率の予測値が必要となる。すなわち、合計Ｘバイトの先行取得を行った際に確率αを乗じて得られるαＸバイトが、将来読み出されるなどの仮定をおいたうえで、全体の予想読み出しサイズを決定して、先行取得の許可・不許可を判断する必要がある。図１２は、第２の実施形態の動作の他の具体例として、その様子を模式的に示したものである。先行取得済みの合計サイズを表すグラフ１０００と、アプリ実行部の要求サイズの合計を表すグラフ１００１と、読み出されたサイズの合計を表すグラフ１００２が記載されている。区間１０１１では制御部１０８により先行取得が不許可と判断されており、区間１０１２では制御部１０８により許可と判断されている。

図１２では、区間１０１２が始まるタイミングで先行取得が開始され、取得済みサイズの合計を表すグラフ１０００の値が増加している。一方、アプリ実行部１０２からの要求が発生していないため、要求サイズの合計を表すグラフ１００１の値は変化していない。当然、読み出しサイズの合計を表すグラフ１００２の値も変化しないが、確率αで読み出されると仮定して、将来の読み出しサイズを求める。点線のグラフ１００４は、当該将来の読み出しサイズを表している。この将来の読み出しサイズが、所定のサイズ（ここではαｓ）に達した段階（経過時間１００５）で、先行取得を終了する。制御部１０８では先行取得は許可されたままであるが、情報管理部１１０の判断により、停止される。

一連の説明は情報管理部１１０の判断により先行取得を停止する場合を述べたが、情報管理部１１０の判断により先行取得を開始することも可能である。例えば、アプリケーションから要求された情報を先行取得していない状況で、アプリケーションからの要求に応答した場合『先行取得した情報による応答率』が低下する。この値が、ある閾値を下回った場合に、情報管理部１１０は、先行取得を許可するよう制御してもよい。

図１３を用いて、第２の実施形態の動作のさらに他の具体例を説明する。情報管理部１１０が、アプリ実行部１０２の要求に対して先行取得した情報で応答ができた割合を管理している場合に、閾値である下限Ｐ_Ｌと上限Ｐ_Ｈを用いて、先行取得の実行と停止を制御する例を説明する図である。Ｐ_ＬとＰ_Ｈの決定方法は任意でよいが、例えば、前述した応答率や、読み出し率などが考えられる。図１３の上には、先行取得済みサイズの合計を表すグラフ１１００と、アプリ実行部１０２から要求されたサイズの合計を表すグラフ１１０１を示し、図１３の下には、応答率のグラフ１１０２を示す。

区間１１０１では制御部１０８の判断により先行取得が不許可であり、区間１１０２以降は許可されている。区間１１０２は先行取得が許可されているが、まだ実行されていない。これは、情報管理部１１０により先行取得の再開が保留（停止）されているためである。この段階では、先行取得した合計サイズに対する応答率Ｐが下限閾値Ｐ_Ｌ以上であり、先行取得の効果があると見なされるので、先行取得を再開しない。一方、アプリ実行部１０２により要求されてデータが読み出されたとする。この時、先行取得したデータからはあまり読み出すことができず、ネットワークを介して直接取得するサイズが多かったと仮定すると、応答率が低下していく。最終的に、区間１１０２と区間１１０３の境目で、応答率が下限Ｐ_Ｌに達している。これを契機に、区間１１０３〜区間１１０４では、情報管理部１１０による先行取得の保留が解除され、先行取得が実行される。先行取得を行うことで、応答できる可能性がある情報が増えるため、応答率が徐々に回復すると考えられる。最終的に、区間１１０４と区間１１０５の間で上限値Ｐ_Ｈに到達したため、先行取得を終了する。

以上、第２の実施形態によれば、情報管理部１１０の管理によって、先行取得の実行と停止が管理される。情報管理部１１０にて、情報の先行取得や読み出しを管理するため、先行取得したデータ量や、先行取得した情報による応答率などを考慮した制御が可能となる。このため、第１の実施形態よりも、細かい制御が実現でき、効率よくエネルギーの削減と、利便性の両立が実現できる。

（第３の実施形態）
図１４に、第３の実施形態に係る情報処理装置を搭載した通信装置の機能ブロック図を示す。これまでの実施形態とは異なり、通信装置には通信モジュール２００が搭載されている。通信処理部、メモリおよびストレージは、中央処理部１０１側（ホスト側）と通信モジュール２００側の双方に存在するので、それぞれ「第１」および「第２」を付けて呼ぶことにする。すなわち、ホスト側を第１通信処理部１０３Ａ、第１メモリ１０５Ａ、第１ストレージ１０６Ａ、通信モジュール側を第２通信処理部１０３Ｂ、第２メモリ１０５Ｂ、第２ストレージ１０６Ｂと呼ぶ。第１及び第２の実施形態で述べた先行取得部１０４および制御部１０８は、通信モジュール２００に備えられている。また、第１及び第２の実施形態で述べた通信処理部、メモリおよびストレージの機能は、第３の実施形態では、主に第２通信処理部１０３Ｂ、第２メモリ１０５Ｂおよび第２ストレージ１０６Ｂにて実現される。

中央処理部１０１は、アプリ実行部１０２および第１通信処理部１０３Ａに加え、第１オフロード部１３１を備える。第１オフロード部１３１は、アプリ実行部１０２で実行されるアプリケーションや、第１通信処理部１０３Ａで実行される通信処理の全部もしくは一部を、通信モジュール２００にオフロード（委任）するための事前処理・事後処理を担当する。

例えば、アプリ実行部１０２でウェブブラウザやＲＳＳリーダなどＨＴＴＰを使って情報を取得する通信アプリケーションが稼働する場合、取得に伴う通信プロトコルの処理やＴＣＰ／ＩＰによる通信そのものを、通信モジュール２００にオフロードできる。これらをオフロードするために、アプリ実行部１０２は、情報の取得要求をオフロード部１３２に通知する。オフロード部１３２は、通信モジュール２００に追加された第２オフロード部１３２との間で事前に定められた形式にしたがって、アプリケーションの処理や通信処理をオフロードする。

通信モジュール２００は、第２メモリ１０５Ｂ、第２ストレージ１０６Ｂおよび通信Ｉ／Ｆ部１０７に加えて、モジュール処理部１２１を備える。モジュール処理部１２１は、第２通信処理部１０３Ｂ、先行取得部１０４、制御部１０８に加えて、第２オフロード部１３２を備える。第２オフロード部１３２は、第１オフロード部１３１からオフロードする処理の内容の通知を受け取り、その通知にしたがって、先行取得部１０４もしくは第２通信処理部１０３Ｂに指示を出す。具体的には、先に述べたような、ＨＴＴＰを用いた情報の取得要求であれば、先行取得部１０４に指示を出し、単なる通信処理の要求であれば、第２通信処理部１０３Ｂに指示を出す。なお、第１通信処理部１０３Ａと第２通信処理部１０３Ｂとの間で機能的に重複する処理があってもよく、第１通信処理部１０３Ａで実行した処理は、第２通信処理部１０３Ｂでは行わなければよい。例えば、ＩＰヘッダまで第１通信処理部１０３Ａで生成されているのであれば、第２通信処理部１０３Ｂでは、対応するルーティング処理とレイヤー２以下の処理を実行する。第１通信処理部１０３Ａでレイヤー３までのすべての処理が完了しているのであれば、第２通信処理部１０３Ｂは、そのまま通信Ｉ／Ｆ部１０７に転送するだけという事もありうる。

第２オフロード部１３２を介して先行取得部１０４に通知された処理は、第１もしくは第２の実施形態で述べた通り処理される。その結果、第２メモリ１０５Ｂもしくは第２ストレージ１０６Ｂに、取得した情報が蓄積される。この情報は、先行取得部１０４の処理結果を応答として、第２オフロード部１３２を介して中央処理部１０１に返す際に、当該情報と合わせて、第１メモリ１０５Ａもしくは第１ストレージ１０６Ａにコピー、もしくは移動するようにしてもよい。それらの作業の代わりに、第２メモリ１０５Ｂもしくは第２ストレージ１０６Ｂに記録された情報へのアクセス手段（例えば、ファイル名やセクタ位置、アドレスなど第２メモリ１０５Ｂまたはストレージ１０６Ｂにて保存された情報の場所や長さを特定できる情報）を、処理結果の応答と合わせて、返すようにしてもよい。この場合、中央処理部１０１は、適切な手段を通じて通信モジュール２００上の第２メモリ１０５Ｂもしくは第２ストレージ１０６Ｂ上の情報にアクセスする。

なお、図１４では、中央処理部１０１に第１通信処理部１０３Ａが存在する形で記載したが、この第１通信処理部が無い構成も可能である。その場合、中央処理部１０１では、通信処理を行わず、情報の取得処理の要求を第１オフロード処理部１３１に指示し、その応答を第１オフロード処理部１３１から受け取る形にすればよい。

さらに図１４では、第１オフロード処理部１３１と第２オフロード処理部１３２が互いに連携して、先行取得やオフロード処理に伴う指示や応答に関する情報を交換するとした。変形例として、第１オフロード処理部１３１と第２オフロード処理部１３２を省略した構成も可能である。その場合、第１通信処理部１０３Ａが送受信するパケットを、通信モジュール２００上で（例えば第２通信処理部１０３Ｂが）取得し、内部を解析して、情報の取得要求を検出し、先行取得部１０４に転送すればよい。この時、先行取得部１０４が、例えば、透過型プロキシサーバのように振る舞うことで、中央処理部１０１で動作するアプリケーションに影響を与えることなく動作できるようになる。先行取得部１０４は、情報の取得要求に対して、先行取得済みの情報があればそれを返し、無ければ新たに取得するよう動作すればよい。その際、関連する情報を新たに先行取得すれば、第１及び第２の実施形態と同様の動作が実現できる。

以上、第３の実施形態によれば、中央処理部１０１とは独立した通信モジュールに先行取得部や制御部を実行することにより、先行取得機能を独立して実現することができ、中央処理部１０１の負荷を低減して、中央処理部で動作する従来のアプリケーションなどの影響を最小限に抑えることができる。また、既存の装置に、モジュール的にハードウェアを追加して、ソフトウェアをインストールすることで、先行取得機能が利用できるようになる。

（第４の実施形態）
本実施形態では、通信装置内の各部を、使用されないときには電源をオフにするもしくは低消費電力な状態に遷移させる形態を示す。ここでは第３の実施形態の通信装置を例に述べるが、第１および第２の実施形態の通信装置でも、同様に実施可能である。

先に述べたように第３の実施形態では、原則として、第１オフロード部１３１と第２オフロード部１３２の間で、指示と応答を交換する。この動作の前後に、通信モジュール２００もしくは中央処理部１００や、中央処理部１００を含むホスト部の動作状態を変更するような信号を追加することで、動作状態の変更が実現できる。これにより、通信モジュール２００は、通信時および先行取得時のみ通電され、もしくは動作状態となり、それらの動作が終了したら、電源オフもしくは低消費電力な状態に遷移するように、通信装置全体を構成できる。なお、電源オフもしくは低消費電力な状態への遷移は、通信モジュール２００自身が判断して自発的に遷移してもよいし、ホスト側の中央処理部１０１が応答の受信を完了したことを検出して、通信モジュール２００に状態遷移するように指示してもよい。

同様に、中央処理部１０１、もしくは中央処理部１０１、第１メモリ、第１ストレージ１０６Ａを含むホスト部も、通信モジュール２００が動作している状態（例えば先行取得中）には、電源オフもしくは低消費電力な状態に遷移し、通信モジュール２００の動作が完了した場合に、電源オンもしくは動作状態に遷移するようにすることもできる。通信モジュール２００からの復帰信号には、何らかのハードウェア割り込み信号を用いるのが一般的であるが、通信モジュール２００の処理が終了する時間を想定して、その時間の値を事前に設定されたタイマーを利用して復帰するようにしてもよい。あるいは、固定値が設定されたタイマーなど他の手段を利用して復帰するようにしてもよい。

以上、第４の実施形態によれば、中央処理部１０１、中央処理部１０１等を含むホスト部、または通信モジュール２００が動作していない間に、低消費電力な状態へと遷移させることによって、装置全体の消費電力をさらに下げることができる。

（第５の実施形態）
図１５に、第５の実施形態に係る情報処理装置を搭載した端末を示す。この端末は、第１の実施形態に係る通信装置に、入力インタフェース１４１と表示装置１４２を追加したものである。入力インタフェース１４１は、ユーザ入力用のインタフェースであり、キーボードやマウス、タッチパネル等がある。表示装置１４２は、メモリ１０５に格納されたデータを画像で表示する。表示装置１４２は、例えば液晶表示パネル、ＣＲＴパネル、有機ＥＬパネル、電子ペーパーなど、画像表示できる装置であれば、何でもかまわない。その他、ハードディスクやＳＳＤなどの補助記憶装置が、追加で接続されてもよい。図１５の端末は、パーソナルコンピュータ（ＰＣ）、ノート型ＰＣ、タブレット端末、スマートフォン、ウェアラブル装置、カメラなど、通信機能を搭載する任意の装置でよい。第２〜第４の実施形態に対しても同様に、入力インタフェースおよび表示装置を追加して、端末を構成することも可能である。

尚、各実施形態に係る情報処理装置および通信装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現可能である。すなわち、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現出来る。このとき、情報処理装置および通信装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現することや、各種の記憶媒体に記憶、あるいはネットワークを介して上記のプログラムを配布、このプログラムをコンピュータ装置に適宜インストールすることで実現が出来る。また、情報処理装置および通信装置内の各記憶部は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。

本発明は上記実施形態そのままに限定されず、実施段階では要旨を逸脱しない範囲で構成要素を変形し具体化出来る。上記実施形態に開示されている複数の構成要素の適宜な組み合わせで、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除出来、異なる実施形態に渡る要素を適宜組み合わせることも出来る。

１００：通信装置
１０１：中央処理部
１０２：アプリ実行部
１０３、１０３Ａ、１０３Ｂ：通信処理部
１０４：先行取得部
１０５、１０５Ａ、１０５Ｂ：メモリ
１０６、１０６Ａ、１０６Ｂ：ストレージ
１０７：通信Ｉ／Ｆ部
１０８：制御部
１０９：センサ
１１０：情報管理部
１２１：モジュール処理部
１３１：第１オフロード部
１３２：第２オフロード部
１４１：入力インタフェース
１４２：表示装置

Claims (14)

1. アプリケーションから要求される可能性がある情報を特定し、前記アプリケーションから前記情報の取得を要求される前に、前記情報をネットワークを介して取得する先行取得部と、
   周囲の通信環境を計測したパラメータ値に応じた評価値に基づき、前記先行取得部の動作を制御する制御部と
   を備えた情報処理装置。
2. 前記制御部は、前記評価値に基づき、前記周囲の通信環境が通信に適した環境か否かを判断し、前記通信に適した環境が一定時間続いたときは、前記先行取得部の動作を停止させる
   請求項１に記載の情報処理装置。
3. 前記制御部は、前記周囲の通信環境が通信に適さない環境から前記通信に適した環境に遷移した後、第１の時間長の間、前記通信に適した環境にあるときは、前記先行取得部を動作させ、前記一定時間として前記第１の時間長より長い第２の時間長の間、前記周囲の通信環境が前記通信に適した環境にあるときは、前記先行取得部の動作を停止させる
   請求項２に記載の情報処理装置。
4. 前記第１の時間長の時間の間に取得された評価値の平均が閾値以上または以下のときは、前記周囲の通信環境が、前記第１の時間長の間、前記通信に適した環境にあると判断し、
   前記第２の時間長の時間の間に取得された評価値の平均が前記閾値以上または以下のときは、前記周囲の通信環境が、前記第２の時間長の間、前記通信に適した環境にあると判断する
   請求項３に記載の情報処理装置。
5. 前記制御部は、第１の電源および前記第１の電源よりも長い時間電力を供給可能な第２の電源のいずれから電力の供給を受けているかを判断し、前記第２の電源から電力の供給を受けている場合は、前記通信に適した環境が前記一定時間続いても、前記先行取得部の動作を停止させない
   請求項２ないし４のいずれか一項に記載の情報処理装置。
6. 前記先行取得部により取得される複数の情報に関する統計情報を管理する情報管理部を備え、
   前記情報管理部は、前記統計情報に基づき前記先行取得部の動作を許可するか否かを判断し、
   前記制御部は、前記評価値に基づき、前記先行取得部の動作を許可するか否かを判断し、
   前記情報管理部の判断結果と、前記制御部の判断結果に基づいて、前記先行取得部の動作を制御する
   請求項１ないし５のいずれか一項に記載の情報処理装置。
7. 前記統計情報は、
   （１）前記先行取得部によって取得された情報の数、または前記情報のサイズ、
   （２）前記先行取得部が前記アプリケーションから先行取得を指示される場合に前記アプリケーションから先行取得を指示された回数またはサイズ、
   （３）前記アプリケーションによって取得要求された際に前記記先行取得部によって取得済みの情報を使って応答できた回数またはサイズまたは割合
   （４）前記先行取得部によって取得した情報のうち前記アプリケーションから取得要求がされていない情報の数、サイズまたは割合
   の少なくとも１つを含む、請求項６に記載の情報処理装置。
8. 前記情報管理部は、前記統計情報に基づく値を、前記統計情報に対応して予め与えられた閾値と比較することにより、前記先行取得部の動作を許可するか否かを判断する
   請求項７に記載の情報処理装置。
9. 前記情報管理部は、前記（１）〜（４）の項目のうち少なくとも２つの項目に関する値の関係に基づいて、前記先行取得部の動作を許可するか否かを判断する
   請求項７に記載の情報処理装置。
10. 前記先行取得部は、前記制御部と前記情報管理部の両方により許可された場合のみ、前記情報の取得を行う
    請求項６ないし９のいずれか一項に記載の情報処理装置。
11. 請求項１ないし１０のいずれか一項に記載の情報処理装置と、
    前記ネットワークと無線通信を行う通信インタフェース部と、
    を備えた通信装置。
12. 請求項１ないし１０のいずれか一項に記載の情報処理装置と、
    前記ネットワークと無線通信を行う通信インタフェース部と、
    前記先行取得部で取得されたデータを格納するメモリと、
    前記情報処理装置に対して指示を行うユーザ入力用の入力インタフェースと、
    前記メモリ内のデータを画像表示する表示装置と
    を備えた端末。
13. アプリケーションから要求される可能性がある情報を特定し、前記アプリケーションから前記情報の取得を要求される前に、前記情報をネットワークを介して取得する先行取得ステップと、
    周囲の通信環境を計測したパラメータ値に応じた評価値に基づき、前記先行取得部の動作を制御する制御ステップと
    をコンピュータが実行する情報処理方法。
14. アプリケーションから要求される可能性がある情報を特定し、前記アプリケーションから前記情報の取得を要求される前に、前記情報をネットワークを介して取得する先行取得ステップと、
    周囲の通信環境を計測したパラメータ値に応じた評価値に基づき、前記先行取得部の動作を制御する制御ステップと
    をコンピュータに実行させるためのコンピュータプログラム。

Images