(57)【要約】【課題】データの先行取得に伴う消費電力を削減する。【解決手段】本発明の一態様としての通信装置は、第１取得部と、決定部と、第２取得部を備える。前記第１取得部は、要求元からの第１データの取得要求に応じて、第１の取得先から前記第１データを取得する。前記決定部は、前記第１データに基づき、前記要求元が必要とする他のデータである第２データを決定する。前記第２取得部は、前記要求元からアクセス可能な外部または内部のデータ保持部に前記第２データが保有されていない場合、前記第２データを第２の取得先から取得する。【選択図】図２
2014164698.tif 000002
【特許請求の範囲】
【請求項１】
要求元からの第１データの取得要求に応じて、第１の取得先から前記第１データを取得する第１取得部と、
前記第１データに基づき、前記要求元が必要とする他のデータである第２データを決定する決定部と、
前記要求元からアクセス可能な外部または内部のデータ保持部に前記第２データが保有されていない場合、前記第２データを第２の取得先から取得する第２取得部と
を備えた通信装置。
【請求項２】
前記決定部は、前記第１データにおいて指定されたデータを前記第２データとして決定する
請求項１に記載の通信装置。
【請求項３】
前記第１データにおいてデータの識別情報が指定され、
前記決定部は、前記識別情報のデータを前記第２データとして決定し、
前記決定部は、前記データ保持部に前記識別情報のデータが保有されている場合、前記識別情報のデータが、前記第２の取得先が保有している前記識別情報のデータと異なる可能性を判断し、
前記第２取得部は、前記決定部により異なる可能性があると判断された場合は、前記第２データを前記第２の取得先から取得する
請求項１に記載の通信装置。
【請求項４】
前記第１取得部は、前記第１データを前記要求元に送信し、
前記第２取得部は、前記要求元からの要求に応じて、前記第２データを前記要求元に送信する
請求項１ないし３のいずれか一項に記載の通信装置。
【請求項５】
前記第１取得部は、前記第２取得部により前記第２データの取得が完了した後、前記第１データを前記要求元に送信する
請求項４に記載の通信装置。
【請求項６】
前記第２取得部は、前記第２の取得先から取得した第２データを前記データ保持部に格納する
請求項１ないし３のいずれか一項に記載の通信装置。
【請求項７】
前記決定部は、内部または外部のデータ情報保持部から前記データ保持部に保有されているデータに関する情報を読み出すことにより、前記データ保持部に前記第２データが保有されているかを判断する
請求項１ないし６のいずれか一項に記載の通信装置。
【請求項８】
前記決定部は、内部バスを介して、前記データ情報保持部から前記情報を読み出す
請求項７に記載の通信装置。
【請求項９】
前記データ情報保持部を内部に備えた
請求項７に記載の通信装置。
【請求項１０】
前記データ保持部を内部に備えた
請求項９に記載の通信装置。
【請求項１１】
前記決定部は、前記第１取得部により前記第１データが取得された後、前記要求元に問い合わせることにより、前記データ保持部に前記第２データが保有されているかを判断する
請求項１ないし６のいずれか一項に記載の通信装置。
【請求項１２】
内部バスを介して、前記要求元から前記第１データの取得要求を受信する受信部を含む
請求項１ないし１１のいずれか一項に記載の通信装置。
【請求項１３】
ネットワークインタフェースカード、またはメモリカードである
請求項１ないし１２のいずれか一項に記載の通信装置。
【請求項１４】
前記要求元、前記第１取得部、前記決定部、および前記第２取得部を含む半導体集積回路を備えた
請求項１ないし１１のいずれか一項に記載の通信装置。
【請求項１５】
前記要求元をさらに備え、
前記要求元は、前記第２取得部が前記第２データの取得動作を行っている期間の少なくとも一部は、低消費電力状態に遷移する
請求項１ないし１１、１４のいずれか一項に記載の通信装置。
【請求項１６】
無線または有線のネットワークを介して、前記要求元から前記第１データの取得要求を受信する受信部を含む
請求項１ないし１１のいずれか一項に記載の通信装置。
【請求項１７】
要求元からの第１データの取得要求に応じて、第１の取得先から前記第１データを取得するステップと、
前記第１データに基づき、前記要求元が必要とする他のデータである第２データを決定するステップと、
前記要求元からアクセス可能なデータ保持部に前記第２データが保有されていない場合、前記第２データを第２の取得先から取得するステップと
を備えた通信方法。
【請求項１８】
要求元からの第１データの取得要求に応じて、第１の取得先から前記第１データを取得するステップと、
前記第１データに基づき、前記要求元が必要とする他のデータである第２データを決定するステップと、
前記要求元からアクセス可能なデータ保持部に前記第２データが保有されていない場合、前記第２データを第２の取得先から取得するステップと
をコンピュータに実行させるための通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、通信装置、通信方法および通信プログラムに関する。
【背景技術】
【０００２】
近年、Web技術を代表とするネットワーク技術の普及は目覚ましく、パソコンや携帯電話、スマートフォン、TVやBlu-ray レコーダ、プリンタなど、様々な機器（以後端末と呼ぶ）がネットワークに接続されている。端末はネットワーク上の機器（以後サーバと呼ぶ）からデータを取得し、このデータを処理する。例えば、端末がWebブラウザを有する場合は、HTMLデータをHTTPプロトコルを用いてサーバから取得し、取得したHTMLデータを表示、あるいはこのHTMLデータに含まれるJavaScript(登録商標)プログラムを実行する。サーバが高性能である場合には、端末が行う処理の一部あるいは大部分をサーバに行わせ、その処理結果を端末が受け取る、いわゆるクラウドコンピューティングと呼ばれるシステム形態も現れている。
【０００３】
このように端末がサーバからデータを取得する際に、サーバの負荷分散およびネットワークの負荷分散の観点で、プロキシ技術が知られている。プロキシ技術を用いた場合、端末はプロキシにサーバへのデータ取得要求を送信し、プロキシはその要求されたデータを既に保持している場合には、保持しているデータを端末に送信する。プロキシがその要求されたデータを保持していない場合には、サーバへデータ取得要求を送信し、サーバから取得したデータを端末に送信するとともに、その取得したデータをプロキシは保持する。プロキシを用いることにより、サーバが受信するデータ取得要求が減少するため、端末はデータ取得に要する時間を削減することができる。
【０００４】
プロキシ技術の変形例として、プリフェッチプロキシ技術を挙げることができる。これは、プリフェッチプロキシが端末からデータ取得要求を受信する前に、プリフェッチプロキシがサーバへデータ取得要求を送信してデータを取得し、これを保持する。データ取得要求を送信する際には、プリフェッチプロキシは端末がどのデータを将来取得しようとするかは分からない。そのため、プリフェッチプロキシは、なにかしらの推測を行い、取得するデータを決定する。例えば、端末があるHTMLデータをプリフェッチプロキシに要求した際に、そのHTMLデータが参照しているオブジェクト（リファレンスオブジェクト）を先行取得する方法が知られている。プリフェッチプロキシが既に保持しているオブジェクトを、リファラ・リファレンス対応テーブルに記録し、リファレンスオブジェクトを取得する際に、このテーブルに記載されているオブジェクトの取得を行わない。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開2002-373109号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ここで、プリフェッチプロキシにアクセスする端末の動作を考える。端末は、一度取得したデータをキャッシュする。端末は、あるHTMLデータを取得した際に、これが参照するリファレンスデータの取得も引き続き行おうとする。端末がこれらのリファレンスデータを取得する際には、端末はこれらのリファレンスオブジェクトが、自身の保持するキャッシュに存在するか否かを確認する。もし、キャッシュにデータが存在する場合には、プリフェッチプロキシにデータ取得要求を送信せずに、自身の保持するデータを利用する。
【０００７】
しかしながら、上述したリファラ・リファレンス対応テーブルを用いる方法では、端末のキャッシュに保持するオブジェクトであっても、プリフェッチプロキシはサーバからこれを取得（プリフェッチ）する場合がある。このオブジェクトに対して端末はデータ取得要求を送信することはないため、結果的にプリフェッチプロキシの消費電力が増加するという問題がある。
【０００８】
本発明の実施形態は、データの先行取得に伴う消費電力を削減することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の一態様としての通信装置は、第１取得部と、決定部と、第２取得部を備える。
【００１０】
前記第１取得部は、要求元からの第１データの取得要求に応じて、第１の取得先から前記第１データを取得する。
【００１１】
前記決定部は、前記第１データに基づき、前記要求元が必要とする他のデータである第２データを決定する。
【００１２】
前記第２取得部は、前記要求元からアクセス可能な外部または内部のデータ保持部に前記第２データが保有されていない場合、前記第２データを第２の取得先から取得する。
【図面の簡単な説明】
【００１３】
【図１】第１の実施形態に係る通信システムの全体構成を示す。
【図２】第１の実施形態に係る通信装置を搭載した通信端末の構成を示す。
【図３】保持データ情報を管理するデータ構造の概念を示す。
【図４】データ取得部の動作の流れの例を示す。
【図５】データ取得部の別の動作の流れの例を示す。
【図６】データ先行取得部の動作の流れの例を示す。
【図７】端末における動作シーケンスの例を示す。
【図８】第１の実施形態に係る端末のハードウエア構成の例を示す。
【図９】第２の実施形態に係る通信装置を搭載した端末の構成例を示す。
【図１０】第２の実施形態に係る端末の動作シーケンスの例を示す。
【図１１】第３の実施形態に係る通信システムの全体構成を示す。
【図１２】第３の実施形態に係る端末の構成例を示す。
【図１３】第３の実施形態に係る通信装置を搭載したプリフェッチプロキシの構成例を示す。
【図１４】第４の実施形態に係る端末のハードウエア構成例１を示す。
【図１５】第４の実施形態に係る端末のハードウエア構成例２を示す。
【図１６】第４の実施形態に係る端末のハードウエア構成例３を示す。
【図１７】第４の実施形態に係る端末のハードウエア構成例４を示す。
【図１８】第４の実施形態に係る端末のハードウエア構成例５を示す。
【図１９】第４の実施形態に係る端末のハードウエア構成例６を示す。
【図２０】第４の実施形態に係る端末のハードウエア構成例７を示す。
【発明を実施するための形態】
【００１４】
以下、図面を参照しながら、本発明の実施形態を説明する。
【００１５】
（第１の実施形態）  
Web技術において、URLで識別されるものをオブジェクトと呼ぶ。HTMLやXML等の言語で記述されたオブジェクトの場合、内部にURLを記すことで、他のオブジェクトを参照することができる。例えば、HTMLでは、<a>タグのhref属性にURLを記すことで、他のオブジェクトを参照することができる。同様に<script>タグや<img>タグ、<frame>タグ、<link>タグなどでもURLを記すことで、他のオブジェクトを参照することができる。このようにあるHTMLで記されたオブジェクトが参照しているオブジェクトを“リファレンスオブジェクト”と呼び、逆にリファレンスオブジェクトを参照しているオブジェクトを“リファラオブジェクト”と呼ぶ（リファラオブジェクト --参照-->リファレンスオブジェクト）。オブジェクトは、０以上のリファレンスオブジェクトを有することができ、またオブジェクトは０以上のリファラオブジェクトを有することができる。
【００１６】
図１に本実施形態に係る通信システムの全体構成図を示す。図１では、端末１０１とWebサーバ１０２、１０３、１０４が、無線網１０５と有線網１０６とを介して、通信可能となっている。端末１０１は、例えば、スマートフォンや携帯電話、タブレットPC、ノートPC,小型ブラウザ端末、電子書籍端末等である。Webサーバ１０２〜１０４は、例えば、Apacheなどのソフトウエアを実行しているサーバであり、端末とHTTPプロトコルを用いて通信を行う。Webサーバ１０２〜１０４は、それぞれデータを保有しており、端末にとってデータの取得先となる。無線網１０５は例えば、IEEE802.11規格に従った通信方式や、LTE(Long Term Evolution)などのセルラー通信方式やWiMax通信方式に従った通信網である。有線網１０６は、例えば、光ファイバによって構成された通信網である。
【００１７】
端末１０１は、Webサーバにデータ取得要求を送信する。データ取得要求にはオブジェクト識別子としてURLが記されている。Webサーバは、受信したデータ取得要求に含まれるオブジェクト識別子に対応するオブジェクトを、データ取得応答として端末に送信する。端末は、受信したオブジェクトが、例えば<script>タグや<img>タグ、<frame>タグ、<link>タグなどによって他のオブジェクトを参照している場合、これらのオブジェクトに関するデータ取得要求をWebサーバに送信する。このときのデータ取得要求は、そのオブジェクト識別子で示されているWebサーバに送信することはいうまでもない。
【００１８】
端末はあるオブジェクトを取得した後、そのオブジェクトのリファレンスオブジェクトの中で画面表示に必要なものをすべて取得し、これらのオブジェクトに基づいて画面表示を行う。ここで、すぐには必要としないリファンレスオブジェクトに関しては、これを取得しないことが望ましい。たとえば、<a>タグで指定されたリファレンスオブジェクトのように、画面表示後に該当箇所をマウスクリックなどで指定することで、そのオブジェクトを取得すればよいものがこれに該当する。画面表示には、例えば、端末が備えるWebブラウザを用いる。なお、最初にオブジェクトを取得したWebサーバと、その後にリファレンスオブジェクトを取得したWebサーバは、同じ場合もあれば、異なる場合もある。つまり、第１データの取得先である第１の取得先と、第２データの取得先である第２の取得先とは同じ場合もあれば、異なる場合もある。
【００１９】
図２に、本実施形態に係る通信装置を搭載した通信端末の構成図を示す。図２に示す通信端末（以下単に端末）は、ユーザインタフェース処理部１１、描画データ生成部１２、データ抽出部１３、データ取得部１４、データ保持部１５、データ先行取得部（第１取得部、決定部、第２取得部）１６、通信処理部１７を備える。
【００２０】
（ユーザインタフェース処理部１１）
ユーザインタフェース処理部１１は、描画データ生成部１２より、描画データを受け取り、これに従った画面表示を行う。さらに、マウスクリックのような操作を受けると、このマウス操作が画面上のリンク選択のようにデータ取得を要求するものである場合には、そのURLをデータ取得部１４に送る。
【００２１】
（描画データ生成部１２）
描画データ生成部１２は、データ取得部１４よりオブジェクトデータを受け取り、このデータに従った描画データを生成し、ユーザインタフェース処理部１１に送信する。ここでオブジェクトデータとは、例えばHTMLデータや画像データ、CSSデータである。
【００２２】
（データ抽出部１３）
データ抽出部１３は、オブジェクトデータをデータ取得部１４あるいはデータ先行取得部１６より受け取り、これに含まれるリファンレンスオブジェクトのURLを抽出して、データ取得部１４あるいはデータ先行取得部１６に返す。
【００２３】
（データ取得部１４）
データ取得部１４は、ユーザインタフェース処理部１１から、データ取得を要求するURLを取得すると、このURLに対応するデータを取得する。この取得動作の流れを図４に示す。
【００２４】
まず、データ取得部１４は、データ保持部１５がそのＵＲＬのデータを保持しているか否かを確認し（Ｓ１０１）、データ保持部１５がFreshなデータを保持している場合には（Ｓ１０１のＹＥＳ、Ｓ１０２のＹＥＳ）、そのデータをデータ保持部１５から取得する（Ｓ１０４）。そうでなく、データ保持部１５がそのデータを保持しているが、Staleな状態である場合には（Ｓ１０２のＮＯ）、変更確認付のデータ取得要求を、通信処理部１７を介してWebサーバに送信し、Webサーバからのデータを受信する（Ｓ１０３）。データ保持部１５がそのＵＲＬのデータを保持していない場合は（Ｓ１０１のＮＯ）、データ取得部１４は、通信処理部１７を介してデータ取得要求を送信し、Webサーバからデータを受信する（Ｓ１０５）。データ取得部１４は、Webサーバまたはデータ保持部１５から取得したデータをデータ抽出部１３に渡し、データ抽出部１３から、このデータに含まれるリファンレンスオブジェクトを受け取る。そして、リファレンスオブジェクトに対するデータ取得動作を行う。この取得動作の流れを図５に示す。
【００２５】
まず、データ取得部１４は、データ保持部１５がそのリファレンスオブジェクトのデータを保持しているか否かを確認し（Ｓ２０１）、データ保持部１５がFreshなデータを保持している場合には（Ｓ２０１のＹＥＳ、Ｓ２０２のＹＥＳ）、そのデータをデータ保持部１５から取得する（Ｓ２０３）。データ保持部１５がそのデータを保持していない場合（Ｓ２０１のＮＯ）、あるいはStaleなデータを保持している場合は（Ｓ２０２のＮＯ）、データ取得部１４は、データ先行取得部１６にリファンレンスオブジェクトの取得を要求し（Ｓ２０５）、これに対するデータをデータ先行取得部１６から取得する。以上の処理を、すべてのリファレンスオブジェクトについて行う（Ｓ２０４）。
【００２６】
図４および図５の動作により得られたリファラオブジェクトおよびリファンレンスオブジェクトのデータは、描画データ生成部１３とデータ保持部１５に渡される。
【００２７】
（データ保持部１５）
データ保持部１５は、データ取得部１４からアクセス（読み書き）可能な記憶部である。データ保持部１５は、データ取得部１４からデータを受けると、これを内部に保持する。また、データ保持部１５は、データ取得部１４より、あるURLのデータを保持するか否かの問い合わせを受けた場合には、次の３つの応答のどれか一つをデータ取得部１４に返す。
2014164698.tif 000003
【００２８】
また、データ保持部１５は、データ取得部１４より、あるＵＲＬについてデータ取得要求を受けた場合には、そのURLに対応するデータを内部から取り出してデータ取得部１４に返す。データ先行取得部１６に対しても、データ取得部１４と同様のやりとりを行う。
【００２９】
データ保持部１５は、ユーザインタフェース処理部１１を介して、削除イベントを受けた場合には、保持するデータを削除する機能を有することが望ましい。また、データ保持領域に空きが少なくなってきた場合には、保持するデータの一部を削除することが望ましい。この際、削除データの選択には、取得日時が最も古いものから削除する方法や、直近のアクセス時間が最も古いものから削除する方法など様々あり得る。
【００３０】
データ先行取得部１６は、通信処理部１７よりオブジェクトデータを受けると、これをデータ抽出部１３に送り、データ抽出部１３からリファレンスオブジェクトのURLを受ける。リファンレンスオブジェクトのURLの夫々に対して、データ保持部１５に保持状況を問い合わせ、データを取得する。データの取得動作の流れを図６に示す。
【００３１】
もし、Freshなデータがデータ保持部１５に保持されている場合には（Ｓ３０１のＹＥＳ、Ｓ３０２のＹＥＳ）、取得動作を行わないStaleなデータが保持されている場合には（Ｓ３０２のＮＯ）、変更確認付の取得要求を、通信処理部１７を介してWebサーバに送信し、その応答としてデータを受信する（Ｓ３０５）。一方、データ保持部１５にデータが保持されていない場合には、取得要求を通信処理部１７を介してWebサーバに送信し（Ｓ３０４）、その応答としてデータを受信する。データ先行取得部１６は、Webサーバから受信したデータをデータ取得部１４に送る。
【００３２】
（通信処理部１７）
通信処理部１７は、データ取得部１４あるいはデータ先行取得部１６と、Webサーバとの間で必要となる通信処理を行う。具体的には、TCPのプロトコル処理、IPのプロトコル処理、無線通信のためのプロトコル処理および信号処理を行う
次に、データ保持部１５の動作について詳しく述べる。データ保持部１５は個々のオブジェクトデータに対して、{データ本体、URL、データ生成日時,etag,age,max-age、データ取得日時}の情報（保持データ情報）を保持する。データ保持部１５は、データ取得部１４あるいはデータ先行取得部１６からの問い合わせに効率よく応答するため、URLを検索キーとして保持データ情報を検索できることが望ましい。そのためには、URLをハッシュキーとしたデータ構造を有することが望ましい。保持データ情報に含まれる各要素について説明する。
【００３３】
・データ本体は、オブジェクトデータ、例えばHTMLデータや画像データやJavascriptデータなど、HTTP によって取得したデータである。
・URLは、オブジェクトを識別するための識別情報である。
・データ生成日時は、オブジェクトデータをサーバが生成した日時である。データ生成日時は、データを取得する際にHTTPのDATEヘッダに記載されて、サーバから端末に送られる。このデータ生成日時は、端末の時計ではなく、サーバの時計で測った時刻であることが望ましい。
・etagは、サーバがオブジェクトに与えた識別子である。オブジェクトの内容が変更される毎に、この識別子の値も変更されることが望ましい。この識別子は、データを取得する際にHTTPのEtagヘッダに記載されて、サーバから端末に送られる。
・ageは、オブジェクトが生成されてから経過した時間である。この値は、HTTPのAgeヘッダに記載されて、サーバから端末に送られる。
・max-ageは、オブジェクトが生成されてからmax-ageで記された時間が経過した場合、オブジェクトをStaleとする時間である。この値は、HTTPのCache-Controlヘッダに記載されて、サーバから端末に送られる。
・データ取得日時とは、端末がオブジェクトデータを取得した日時である。この値は、端末の時計で測定された値であることが望ましい。
【００３４】
図３は、保持データ情報を管理するデータ構造の概念図を示す。図３では、データ本体をファイルとして保持しており、データ本体のファイルポインタのアドレスによってデータ本体へ高速なアクセスを実現している。Ageとmax-ageの単位は秒である。
【００３５】
データ保持部１５は、データ保持しているか否かの問い合わせとしてURLを受け取った際に、まず図３のテーブルを検索し、該当するデータを保持しているか否かを判断する。このテーブルの検索には、URLを検索キーとした木構造やハッシュ構造のような様々な検索高速化のための手法が適用し得る。
【００３６】
データを保持している場合には、以下の式が成立していればFresh、そうでなければStaleと判断する。なお「−」は、マイナス演算を表す。
現在日時  −  データ取得日時  ＜  max-age − age
【００３７】
また、図３の第３エントリのようにmax-ageとageの少なくともどちらか一方が保持されていない場合には、以下の式でFresh or Staleを判断する（αは予め定められた閾値である）。
現在日時  −  データ取得日時  ＜  α
【００３８】
Fresh or Stateの判断の方法には様々な変形を考えることができる。例えば以下の式を用いることができる。ここで、ベータは予め定められた閾値である。
現在日時  −  データ取得日時  ＜  max-age − age − β
【００３９】
さらに、βの値をデータの種類、例えばHTMLデータ、CSSデータ、JavaScriptデータによって異なる値を用いることもできる。このデータの種類はデータを取得する際のHTTPのContent-Typeヘッダに含まれる識別子により知ることが望ましい。さらに、βの値として、データを取得したサーバにより異なる値を用いることができる。
【００４０】
次に、データ取得部１４あるいはデータ先行取得部１６が通信処理部１７へ送る、データ取得要求と変更確認付データ取得要求に関して説明を行う。
【００４１】
データ取得要求は、例えば以下の情報を含む
HTTP GET www.toshiba.co.jp/index.html
このデータ取得要求を通信処理部１７が受け取ると、名前（FQDN）www.toshiba.co.jp  をDNSサーバに問い合わせて、対応するIPアドレスを取得し、そのIPアドレスに向かって宛先ポート８０番のTCPコネクションを接続し、以下を含むHTTP要求を送信する。
【００４２】
GET www.toshiba.co.jp/index.html HTTP/1.1
これを受信したWebサーバから、その応答として以下のHTTP応答を通信処理部１７は受信する。ただし、データ本体の記述は省略している。
HTTP/1.1 200 OK
Content-Length:16231
Content-Type:text/html
Date:Mon, 05 Nov 2012 09:10:23 GMT
ETag:"3f67-4cdb3d974e780"
Age:520910
Cache-Control:public, max-age=1209600
【００４３】
上記の応答は、一行目がデータ送信にサーバが送信したことを200という番号で示している。さらに、Contente-Length行の16231が、データのバイト数を示す。Content-Type行のtext/htmlがHTMLデータであることを示す。Date行がデータ生成日時を示す。ETag行がETagの値を示す。Age行がデータ生成時点からの経過時間を示す。Cache-Control行のmax-ageが、データをFreshとみなせる最大経過時間を表す。
【００４４】
変更確認付データ取得要求には、Etagを用いる方法と、データ生成日時を用いる方法の二通りがある。
【００４５】
まずは、データ生成日時を用いる場合、データ取得部１４あるいはデータ先行取得部１６は、以下を含む変更条件付きデータ取得要求を通信処理部１７に送る。
GET www.toshiba.co.jp/index.html HTTP/1.1
If-Modified-Since: Tue, 06 Nov 2012 08:12:31 GMT
【００４６】
通信処理部１７は、データ取得要求を受信した場合と同様に、www.toshiba.co.jpに対するIPアドレスをDNSサーバに問い合わせたのち、得られたIPアドレスに向けて宛先番号８０のTCPコネクションを設定し、HTTP要求を送信する。これを受信した、Webサーバは、要求されたURLのデータがIf-Modified-Since行の日時から変更が無い場合には変更がない旨を応答する。変更がある場合には、データ取得要求を受信した場合と同様の応答を送信する。変更がない旨の応答例を以下に示す。この場合、データ本体の送信をWebサーバは行わない。
HTTP/1.1 304 Not Modified
【００４７】
一方、Etagを用いて変更確認付データ取得要求を送信する場合には、データ取得部１４あるいはデータ先行取得部１６は、以下を含む要求を送信する。
GET www.toshiba.co.jp/index.html HTTP/1.1
If-None-Match:” 686897696a7c876b7e” 
【００４８】
これを受信した、Webサーバは、要求されたURLのデータがIf-None-Match行の識別子と異なる識別子を持つか否かを確認し、変更が無い（同一識別子を有する）場合には変更がない旨を応答する。変更がある場合には、データ取得要求を受信した場合と同様の応答を送信する。変更がない旨の応答例を以下に示す。この場合、データ本体の送信をWebサーバは行わない。
HTTP/1.1 304 Not Modified
【００４９】
上では、変更確認付データ取得要求には、Etagを用いる方法とデータ生成日時のどちらか一方を用いる場合について説明したが、その両方を用いることもできる。この場合は、Webサーバが変更確認を行う際に、Etagとデータ生成日時の好ましい方をWebサーバが選択して使用する。
【００５０】
（端末のシーケンス）
図７に端末における動作シーケンスの例を図７に示す。
【００５１】
この動作例は、マウスクリックイベントにより、URL=A（例えば、HTTP://www.toshiba.co.jp/index.html）のデータを取得する場合のものであり、URL=Aのリファンレンスオブジェクトの識別子がURL=BとURL=CとURL=Dであるとしている。また、データ保持部１５において、URL=Bは既に保持されておりFreshな状態であるとする。
【００５２】
マウスクリックイベントがユーザインタフェース処理部１１に入力され（S11）、URL＝Aがデータ取得部１４に送られる（S12）。データ取得部１４は、URL=Aのデータがデータ保持部１５に保持されているか確認し（S13）、Staleな状態のデータが保持されているとの応答を得る（S14）。データ取得部１４は、URL=Aに対する変更確認付データ取得要求を通信処理部１７を介してWebサーバに送信する（S15、S16）。Webサーバから、URL=Aに対するデータ取得応答（データ本体を含む）が返され、通信処理部１７を介してデータ先行取得部１６に渡される（S17、S18）。
【００５３】
データ先行取得部１６は、データ抽出部１３にURL=Aに対するデータのリファレンスオブジェクトの識別子の抽出を要求し、URL=B、URL=C、URL=Dの識別子が返される（S19、S20）。データ先行取得部１６は、データ保持部１５に対して、URL=B、URL=C、URL=Dのデータを保持しているかを問い合わせる（S21）。データ先行取得部１６は、URL=Bについてはfreshなデータを保持しており、URL=C、URL=Dについてはデータを保持していないとの応答を得る（S22）。データ先行取得部１６は、URL=C、URL=Dに対するデータ取得要求を通信処理部１７を介してWebサーバに送信する（S23、S24）。Webサーバから、URL=CとURL=Dに対するデータ取得応答（データ本体を含む）が返され、通信処理部１７を介してデータ先行取得部１６に渡される（S25、S26）。
【００５４】
データ先行取得部１６は、URL＝Aに対するデータ取得応答（データ本体を含む）をデータ取得部１４に送る（S27）。データ取得部１４は、データ抽出部１３に、URL＝Aに対するデータのリファレンスオブジェクトの識別子の抽出を要求する（S28）。データ抽出部１３は、URL=B、URL=C、URL=Dの識別子を抽出し、データ取得部１４に返す（S29）。
【００５５】
データ取得部１４は、データ保持部１５に対して、URL=B、URL=C、URL=Dのデータを保持しているかを問い合わせる（S30）。データ取得部１４は、URL=Bについてはfreshなデータを保持しており、URL=C、URL=Dについてはデータを保持していないとの応答を得る（S31）。データ取得部１４は、データ先行取得部１６に対し、URL=C、URL=Dに対するデータ取得要求を送る（S32）。データ先行取得部１６は、ステップS26で取得したURL=CとURL=Dに対するデータ取得応答（データ本体を含む）をデータ取得部１４に返す（S33）。またデータ取得部１４は、データ保持部１５からURL＝Bに対するデータを取得する（S34）。データ取得部１４は、URL=A、URL=B、URL=C、URL=Dに対するデータの描画要求を描画データ生成部１２に送る（S35）。描画データ生成部１２は、URL=A、URL=B、URL=C、URL=Dに対するデータを描画し、描画したデータをユーザインタフェース処理部１１に渡す（S36）。
【００５６】
図７のシーケンスで、もしステップS22において、データ保持部１５がURL=CのオブジェクトデータをStale状態で保持していたとする。この場合には、データ先行取得部１６は、URL=Cのオブジェクトに対して、変更確認付データ取得要求を、通信処理部１７を介して、Webサーバに送信することが望ましい。この応答として、Webサーバからデータ本体を受信した場合には、このデータ本体をデータ取得部１４に送ることが望ましい。Webサーバから変更が無い旨の応答を受信した場合には、その旨をデータ取得部１４に通知することが望ましい。この変更がない旨を通知されたデータ取得部１４は、URL＝Cのオブジェクトに対するデータを、データ先行取得部１６からではなく、データ保持部１５から取得することが望ましい。
【００５７】
データ先行取得部１６がWebサーバから受信したデータ（ステップS17、S25参照）を、データ保持部１５に保持することが望ましい。これを実現する形態としては、データ先行取得部１６がデータ保持部１５に保持を要求する方法や、データ先行取得部１６からデータを受信したデータ取得部１４が、データ保持部に保持を要求する方法など様々があり得る。
【００５８】
図７では、データ先行取得部１６は、ステップS26でURL=CとURL=Dの両方のデータを取得したのち、ステップS27でURL＝Aのデータをデータ取得部１４に送っているが、このURL＝Aのデータを送信するタイミングには様々なバリエーションが存在する。
【００５９】
例えば、データ取得部１４が、URL=Aに対するデータ取得要求を送信（ステップS15参照）後、あらかじめ定められた時間経過したという時間イベントによって、データ先行取得部１６からデータ取得部１４にURL=A（すなわちリファラオブジェクト）のデータを送ってもよい。これにより、リファンレスオブジェクトの取得に時間がかかった際にも、URAL=Aの描画を開始することができ、ユーザの描画待ちに伴うイライラ感を軽減することができる。
【００６０】
また、別の例として、リファレンスオブジェクトのデータ種別により、リファレンスオブジェクトの重要度を決め、重要度がある一定以上高いリファンレスオブジェクトの取得が終了した時点でURL=Aのデータを送信してもよい。例えば、リファレンスオブジェクトとして、CSSデータと画像データとJavaScriptデータがある場合に、CSSデータの受信が終了した時点でURL=Aのデータを送信するようにしてもよい。URL=AのHTMLデータとCSSデータを、画像データとJavaScriptデータの取得に先立って、データ取得部に送信することで、特に画像データのように取得に時間のかかるデータ取得を待つことなく描画データ生成部による処理を開始することができ、ユーザが大まかな画面内容を早期に確認できるという利点がある。
このとき、データ種別は、URLから推測することができる。例えば、URLが.cssという識別子で終わる場合にはCSSデータと推測し、.jsの場合はJavaScriptデータと推測できる。
【００６１】
また、URL=A（すなわちリファラオブジェクト）内で、リファレンスオブジェクトが記述されているコンテキストからデータ種別を推測することも可能である。例えば、<link>タグ内に記されているリファレンスオブジェクトはCSSファイルであり、<script>タグ内に示されているリファレンスオブジェクトはスクリプトデータであると推測できる。あるいは、リファレンスオブジェクトのtype属性によってデータ種別の推測を行うことができる。例えば、<script type="text/javascript" src="/javascript/fp.js"></script>という記述がリファラオブジェクトにある場合、そのtype属性の"text/javascript"からリファレンスオブジェクト(/javascript/fp.js)がJavaScriptデータ出ると推測できる。
【００６２】
本実施形態によれば、データ先行取得部１６は、データ保持部１５が保持しているデータの先行取得を行うことが無いため、消費電力の削減が実現できる。
【００６３】
本実施形態では、Webブラウザを有している端末を例に説明を行ったが、他の形態の端末も可能である。たとえば、通信網を介して他の機器から音楽などの音データを取得し、これをスピーカを介して出力する端末でもよい。このとき端末は、音声入力などの画面を介さないユーザ指示を受けることでデータ取得を行ってもよい。
【００６４】
また、オブジェクトの識別子（データの識別情報）としてURLを用いた場合を例に挙げて説明したが、オブジェクトの識別子はURLの他に、UUIDなど様々なものを適用し得る。
【００６５】
（ハードウエア構成）
図８は、本実施形態に係る端末のハードウエア構成の例を示す。
【００６６】
端末は、CPU１１１と、表示ディスプレイ１２１（例えば、LCD（液晶ディスプレイ））と、メインメモリ１３１と、HDD１４１と、無線NIC１５１と、外部入力手段１６１（キーボードやマウス等）を備える。CPU１１１は、一つ以上のCPUコア１１２、１１３と、グラフィックプロセッサ１１４と、USBホストコントローラ１１６と、メモリコントローラ１１７と、バスコントローラ１１８と、SATA（Serial Advanced Technology Attachment）ホストコントローラ１１９を備える。
【００６７】
CPUコア１１２、１１３は、実行命令に基づいて演算を行う。
【００６８】
グラフィックプロセッサは、CPUコアからの描画命令に従い、RGB信号を生成し、これを表示ディスプレイ１２１に出力する。
【００６９】
USBホストコントローラ１１６は、USB（Universal Serial Bus）規格に基づいて、USBデバイスとの情報送受信を行う。
【００７０】
バスコントローラ１１８は、例えば、PCI-Expressなどのバス規格に従って、バス上のデバイスとのデータの送受信を行う。
【００７１】
SATAホストコントローラ１１９は、SATA（Serial Advanced Technology Attachment）規格に従って、SATAケーブルを介してデバイス（HDD１４１）とのデータの送受信を行う。
【００７２】
表示ディスプレイ１２１は、RGB信号を通じて入力した信号を人間の読める形式にして表示する。
【００７３】
メインメモリ１３１は、例えばDRAM(Dynamic Random Access Memory)等のメモリデバイスである。メインメモリ１３１は、例えばDDR3と呼ばれるインタフェース（メモリバス）にてCPU１２１と接続される。メモリコントローラ１１７は、メインメモリ１３１内のデータの読み書きを行う。
【００７４】
HDD１４１は、例えば、TOSHIBA社のMK1059GSMのように、磁気媒体のデジタル情報を記憶する装置である。HDD１４１は、SATAインタフェースにてCPU１１１と接続されている。HDD１４１の代わりにSSDと呼ばれる半導体記憶装置（NAND フラッシュ）であってかまわない。デジタル情報を記憶するための方式は様々であるが、メインメモリよりも大容量であることが望ましい。HDD１４１とCPU１１１との間の接続は、SATA以外にも、SCSIやFiber ChannelやPCI-Expressなどの様々なインタフェースを使用し得る。
【００７５】
無線NIC１５１(Network Interface Card)は、例えばIEEE 802.11の規格に従ってネットワークに対して通信パケットを送受信する通信デバイスである。使用する規格は、IEEE802.11に限るものではなく、LTE(Long Term Evolution)と呼ばれるセルラー通信向きのインタフェースであってもよいし、100Mイーサネットと呼ばれるような有線インタフェースであってもよい。
【００７６】
外部入力手段１６１は、外部から情報を入力するための手段である。外部入力手段１６１は、例えばキーボードやマウス、表示ディスプレイ１２１上のタッチパネルなど、人間による操作を入力するものであってもよい。または、温度センサーなど、人間以外からの情報を入力するものであってもよい。本実施形態ではUSB規格に従って外部入力をCPU１１１にしているが、USB以外の他の規格（例えば、IEEE1394, RS-232C,HDMI）で接続されていてもよい。
【００７７】
図８に示したハードウエア構成の変形として、グラフィックプロセッサ１１４、USBホストコントローラ１１６、バスコントローラ１１８、SATAホストコントローラ１１９のいずれか一つ以上がCPU外に存在する構成もあり得る。また、無線NIC１５１の一部の機能をCPU内に有するなど様々な変形が考え得る。
【００７８】
本実施形態において、図２に示したユーザインタフェース処理部１１は、表示ディスプレイ１２１と外部入力手段１６１とCPU１１１により実現される。描画データ生成部１２は、CPU１１１、とりわけグラフィックプロセッサ１１４によって実現される。通信処理部１７は、Wireless  NICおよびCPUコアおよびメインメモリ１３１によって実現される。データ取得部１４、データ先行取得部１６、データ保持部１５、データ抽出部１３は、CPUコア１１２、１１３およびメインメモリ１３１によって実現される。
【００７９】
ここで、データ取得部１４とデータ先行取得部１６は異なるCPUコアで実行されることが望ましい。さらに、データ先行取得部１６がデータを先行取得している間、データ取得部１４を実行するCPUコアを低消費電力状態にすることが望ましい。これにより一層の消費電力削減を期待できる。
【００８０】
（HTML5のアプリケーションキャッシュへの言及）
これまでは、あるオブジェクトのリファレンスオブジェクトを取得していたが、さらにリファレンスオブジェクトのリファレンスオブジェクトつまり孫リファレンスオブジェクトを取得するようにしてもよい。この説明を、HTML5のアプリケーションキャッシュを例に行う
アプリケーションキャッシュは、オブジェクト内の<html>タグの manifest属性にてマニフェストファイルを指定する。例えば、<html manifest=“test.appcache">と記述した場合、test.appcacheがマニフェストファイル名であり、URLのパス名はオブジェクトのURLのパス名と同じという意味である。マニフェストファイルには、３つのセクションを記述できる。
【００８１】
CACHEセクションには、ゼロ以上のオブジェクトのURLを記述することができ、ここに記したオブジェクトはデータ保持部１５に保持する。また、HTTPプロトコルで指定されたAgeとmax-ageの値に関わらず、保持している期間は常にFreshとして扱う。
【００８２】
NETWORKセクションには、ゼロ以上のオブジェクトのURLを記述することができ、ここに記したオブジェクトはデータ保持部１５に保持しない。
【００８３】
FALLBACKセクションには、ゼロ以上のオブジェクトのURLを記述することができ、ここに記したオブジェクトはデータ保持部１５に保持することになる。
【００８４】
以下、アプリケーションキャッシュを用いた場合の動作について説明する。
【００８５】
データ取得部１４が、データ取得要求を通信処理部１７を介してWebサーバに送信する。そのWebサーバからの応答を、データ先行取得部１６が、通信処理部１７から受けると、データ先行取得部１６はデータ抽出部１３に、これに含まれるリファレンスオブジェクトを問い合わせる。この応答にマニフェストファイルが含まれている場合には、マニフェストファイルに対するデータをデータ保持部１５に問い合わせる。問い合わせに対する応答が、データを保持しないあるいはStaleなデータを保持することを示す場合には、データ先行取得部１６は、マニフェストファイルに対するデータ取得要求あるいは変更確認付データ取得要求を、通信処理部１７を介してWebサーバに送信し、その応答を受信する。
【００８６】
マニフェストファイルのデータ本体が取得できた場合、すなわち  HTTP/1.1 304 Not Modifiedの応答を受信しなかった場合には、データ先行取得部１６は、取得したマニフェストファイルのデータを、データ抽出部１３に渡し、これに含まれるオブジェクトを問い合わせる。問い合わせに対する応答をデータ先行取得部１６が受けると、CACHEセクションに記されているオブジェクトとFALLBACKセクションに記されているオブジェクトに対するデータ取得要求を、通信処理部１７を介してWebサーバに送信する。このとき、データ保持部１５にデータ保持の有無の確認を行わないことが望ましい。それは、アプリケーションキャッシュの仕様においてマニフェストファイルに変更がある場合には、これに記載されているオブジェクトを再取得するよう定められているためである。
【００８７】
データ先行取得部１６が、必要な全てのオブジェクトを取得し終えると、最初のオブジェクトをデータ取得部１４に送る。その後、データ取得部１４からのデータ取得要求の対象オブジェクト（最初のオブジェクトのリファレンスオブジェクトや孫オブジェクト等）が、既にデータ先行取得部１６にて取得済であるならば、これらをデータ先行取得部１６からデータ取得部１４に送る。データ取得部１４からの要求を受けた時点でこれらを送っても良い。取得済みでないオブジェクトがある場合は、Webサーバにそのオブジェクトのデータ取得要求を送信する。
【００８８】
このように、データ先行取得部１６は、オブジェクトに含まれるマニフェストファイル（すなわちリファレンスオブジェクト）を取得し、さらにマニフェストファイルに含まれるオブジェクト（すなわち孫リファレンスオブジェクト）も取得する。
【００８９】
（変更確認付データ取得要求を出さなくて済む方法）
本実施形態において、データをStale状態で保持している場合、データ先行取得部１６は変更確認付データ取得要求を送信している。この応答として  HTTP/1.1 304 Not Modifiedを受信した場合、結果的にはこの変更確認付データ取得要求は無駄である。そこで、さらなる変形例を示す。
【００９０】
Webサーバは、オブジェクトデータを送信する際に、これに記されているリファレンスオブジェクトのデータのバージョン情報を同時にこれに記す。例えば、オブジェクトデータ内で<img src=”http://img.toshiba.co.jp/logo.jpg” etag= “686897696a7c876b7e”>のように、リファレンスオブジェクトのURLに合わせて、Webサーバが保持するデータのetagの値を記す。
【００９１】
データ先行取得部１６は、リファレンスオブジェクトの取得を行う際に、リファラオブジェクトに記された(リファレンスオブジェクトの)etagの値と、データ保持部１５が保持するetagの値を比較する。これらのetagの値が異なっている場合には、そのリファレンスオブジェクトに対するデータ取得要求を送信する。これらのetagの値が同一である場合、すなわちデータ保持部１５の保持するオブジェクトデータとWebサーバが保持するオブジェクトデータが同一である場合には、データ取得要求あるいは変更確認付データ取得要求の送信を行わない。
【００９２】
Webサーバが保持するオブジェクトデータのバージョン情報としてetagを例に挙げたが、Webサーバが保持するオブジェクトデータと端末が保持するオブジェクトデータが同一であるか否かを、端末側で判定できる限り、これに限定されない。たとえば、データ生成日時や、データのハッシュ値なども、バージョン情報として用いることができる。
【００９３】
また、先ほどの例では、リファレンスオブジェクトのURLとそのバージョン情報を、同じタグ内に記述する例を挙げたが、他にも様々な変形があり得る。たとえば、バージョン情報を記したデータを別のリファレンスオブジェクトとして記すことも可能である。
【００９４】
このように、リファレンスオブジェクトのバージョン情報を端末が取得することで、端末の保持するリファンレスオブジェクトのデータと、Webサーバの保持するデータとが同一であるか否かを端末が判断することができる。よって、端末側は変更確認付データ取得要求を送信しなくてもよくなる。これにより、端末の処理量を削減することができるため、消費電力を削減することが可能となる。さらにデータ表示までの所要時間を削減できるため、ユーザのイライラ感を削減することができる。
【００９５】
（補足説明）
本実施形態において、データ先行取得部１６は、取得したオブジェクトのリファレンスオブジェクトの先行取得を行っている。先行取得を行うオブジェクトの決定方法としては、これ以外にも様々な変形が適用しうる。
【００９６】
例えば、リファレンスオブジェクトの中でリファラオブジェクトの表示には不要なものは、先行取得の対象としないとすることもできる。例えば<a>タグで指定されるオブジェクトがこれに該当する。
【００９７】
一方、XMLデータのように画面描画を行わないオブジェクトに対しても、先行取得の対象とすることもできる。すなわち、あるXMLデータをサーバから取得し、このデータ内にURLが記されている場合である。例えば、DLNAの仕様によれば、DMP(Digital Media Player)はSSDPプロトコルによりDMS(Digital Media Server)の属性を記したXMLデータを取得し、これに含まれるURLを用いて、さらに詳細な属性を記したXMLデータを取得することになっている。ここで、このさらに詳細な属性を記したXMLデータを、リファレンスオブジェクトとみなすことで、先行取得の対象とすることも可能である。
【００９８】
また、あるデータを取得する際にこれ以外の別のデータ取得が必要となり、この別のデータを何らかの知識や推論により決定できる場合には、この決定したデータをリファレンスオブジェクトとみなし、先行取得の対象とすることも可能である。
【００９９】
データ先行取得部１６は、先行取得したデータを、データ取得部１４に送った後、これを削除することが望ましい。また、先行取得したデータに対して、データ取得部１４がデータ取得要求を例えばある一定時間送ってこない場合には、データ先行取得部１６はこのデータをデータ保持部１５に送ってもよい。この場合、データ保持部１５は、データ先行取得部１６から送られたデータを保持する。
【０１００】
（第２の実施形態）
本実施形態では、端末におけるプリフェッチプロキシ動作を、サブCPUで実行する場合を示す。
【０１０１】
図９は、本実施形態に係る通信装置を搭載した端末の構成例を表している。本実施形態に係る端末を備えたシステムの全体構成は、第１の実施形態と同様、図１に示される。
【０１０２】
図９おいて、本端末は、第１の構成群Aと、第２の構成群Bとを有する。
【０１０３】
第１の構成群Aは、ユーザインタフェース処理部１１１、描画データ生成部１１２、データ抽出部１、データ取得部１１４、データ保持部１１５を含む。第２の構成群Bは、データ抽出部２、データ先行取得部１１６、データ情報保持部１１８、通信処理部１１７を含む。
【０１０４】
まず第１の構成群Aについて説明する。ユーザインタフェース処理部１１１、描画データ生成部１１２、データ抽出部１、データ保持部１１５は、それぞれ第１の実施形態におけるユーザインタフェース処理部１１、描画データ生成部１２、データ抽出部１３、データ保持部１５と同様である。ただし、本実施形態では、データ保持部１１５は、データ先行取得部からアクセスされない。
【０１０５】
データ取得部１１４は、ユーザインタフェース処理部１１１より取得すべきオブジェクトのURLを受信し、これに対するデータ取得要求を、通信処理部１１７を介してWebサーバへ送信する。このデータ取得要求の応答を受信すると、このデータに含まれるリファレンスオブジェクトの抽出をデータ抽出１に要求し、データ抽出部１で抽出されたリファレンスオブジェクトのURLを受ける。データ抽出部１から受けたリファレンスオブジェクトのデータを保持しているかを、データ保持部１１５に問い合わせる。
【０１０６】
データ取得部１１４は、データ保持部１１５がFreshなデータを保持している場合には、データ保持部１１５からオブジェクトのデータを取得する。
【０１０７】
データ取得部１１４は、データ保持部１１５がStaleなデータを保持している場合には、通信処理部１１７を介してデータ先行取得部１１６に、データ取得要求あるいは変更確認付データ取得要求を送る。
【０１０８】
データ取得部１１４は、データ保持部１１５がデータを保持していない場合には、通信処理部１１７を介してデータ先行取得部１１６にデータ取得要求を送信する。
【０１０９】
次に、第２の構成群Bについて説明する。データ抽出部２は、第１の実施形態とのデータ抽出部１３と同様である。
【０１１０】
データ情報保持部１１８は、データ保持部１１５の保持するオブジェクトデータに関する情報として、{URL,データ生成日時、Etag,Age,Max-age,データ取得日時}（これを“データ情報”と本明細書では称する）を保持する。このデータ情報を用いることで、データ保持部１１５の保持するデータに関して、データ有無の問い合わせに答えることができ、データを保持する場合にはFresh あるいはStaleのどちらであるかに答えることができる。
【０１１１】
データ情報保持部１１８は、データ保持部１１５からデータ情報を取得することが望ましい。取得のタイミングは、第１の構成群Aのいずれかが動作しているときであることが望ましい。例えば、データ保持部１１５が保持するデータを変更するタイミングが挙げられる。また、データ保持部１１５が保持データを変更する度でなくても、予め定められた回数の変更が、データ保持部１１５に保持されるデータにあった場合でも良い。あるいは、前回のデータ情報の取得から予め定められた時間が経過した後、データ保持部１１５で保持されるデータに変更が最初にあったタイミングであってもよい。その他、様々なバリエーションが存在してよい。あるいは、データ先行取得部１１６からオブジェクトのデータを受け、これに基づいて、データ情報保持部１１８に保持されるデータ情報を更新してもよい。
【０１１２】
データ保持部１１５が例えばブラウザプログラムのブラウザキャッシュの機能として実現される場合、ブラウザキャッシュの情報を観察することで、データ保持部１１５からデータ情報を抽出し、データ情報保持部１１８に送信することができる。これには、例えば、ブラウザプログラムにこのデータ情報抽出機能をソフトウエアとして組み込むことができる。あるいは、ブラウザのプラグインとしてこのデータ情報抽出機能を実現することもできる。あるいは、デーモンあるいはOSのサービスとして、ブラウザキャッシュを観察しデータ情報を抽出する機能を実現することもできる。
【０１１３】
データ先行取得部１１６は、通信処理部１１７から取得データを受けると、このデータに含まれるリファレンスオブジェクトの抽出を、データ抽出部２に要求し、その応答としてリファレンスオブジェクトのURLを取得する。これらのオブジェクトのデータがデータ保持部１１５に保持されているかを、データ情報保持部１１８に問い合わせる。
【０１１４】
データ先行取得部１１６は、問い合わせの結果、データ保持部１１５にStaleなデータが保持されている場合には、通信処理部１１７を介して、Webサーバにデータ取得要求あるいは変更確認付データ取得要求を送信する。
【０１１５】
データ先行取得部１１６は、問い合わせの結果、データ保持部１１５にデータが保持されていない場合には、通信処理部１１７を介して、Webサーバにデータ取得要求を送信する。
【０１１６】
データ先行取得部１１６は、リファンレンスオブジェクトのデータをWebサーバから取得し終えると、リファラオブジェクトのデータをデータ取得部１１４に通信処理部１１７を介して送る。また、データ先行取得部１１６は、データ取得部１１４より通信処理部１１７を介してリファレンスオブジェクトの取得を要求されると、既に取得していた当該リファレンスオブジェクトのデータを通信処理部１１７を介してデータ取得部１１４に送る。
【０１１７】
通信処理部１１７は、データ取得部１１４より、データ取得要求を受けると、その宛先のWebサーバに宛先ポート番号８０のTCPコネクションを設定し、HTTPプロトコルに従ってデータ取得要求を送信する。その応答としてWebサーバからデータ取得応答を受信すると、これをデータ先行取得部１１６に渡す。
【０１１８】
通信処理部１１７は、データ先行取得部１１６からリファンレスオブジェクトに関するデータ取得要求を受けると、その宛先Webサーバに宛先ポート番号８０のTCPコネクションを設定し、HTTPプロトコルに従ってデータ取得要求を送信する。通信処理部１１７は、その応答としてWebサーバからデータ取得応答を受信すると、これをデータ先行取得部１１６に送る。
【０１１９】
通信処理部１１７は、データ先行取得部１１６からデータ取得部１１４に宛てたデータ取得応答を受けると、これをデータ取得部１１４に送る。通信処理部１１７は、データ取得部１１４からデータ先行取得部１１６へのデータ取得要求を受け取ると、これをデータ先行取得部１１６に送る。
【０１２０】
（ハードウエア構成）
本実施形態において、第１の構成群Aと第２の構成群Bを動作させるハードウエアを異なるものにすることが望ましい。例えば、第１の構成群Aは図８に示したCPU１１１で動作させ、第２の構成群Bを無線NIC１５１で動作させる形態を挙げることができる。この場合、無線NIC１１５は（図示しない）CPUとOSを備えることが望ましい。
【０１２１】
このようにハードウエアを分割することで、ユーザインタフェース処理部１１１がオブジェクトの取得イベントを受けてから、オブジェクトとそのリファレンスオブジェクトを取得するまでの処理の多くを第２の構成群Bのみで実行することができる。その間、第１の構成群Aを実行するハードウエアの全てあるいは一部をスリープ状態（処理のできない状態）あるいは低消費電力状態（処理の遅い状態）にすることができ、消費電力の削減が期待できる。また、第２の構成群Bを実行するハードウエアは、実行すべき処理量や処理内容に合わせて最適化し、処理中であっても消費電力の低い設計とすることが容易である。
【０１２２】
あるいは、複数のCPUを有する場合には、第１の構成群Aと第２の構成群Bを異なるCPUで実行することもできる。このようにCPUを分割することで、ユーザインタフェース処理部１１１がオブジェクトの取得イベントを受けてから、オブジェクトとそのリファレンスオブジェクトを取得するまでの処理の多くを第２の構成群Bのみで実行することができる。その間、第１の構成群Aを実行するCPUの全てあるいは一部をスリープ状態（処理のできない状態）あるいは低消費電力状態（処理の遅い状態）にすることができ、消費電力の削減が期待できる。また、第２の構成群Bを実行するCPUは、実行すべき処理量や処理内容に合わせて最適化し、処理中であっても消費電力の低い設計とすることが容易である。典型的には第２の構成群Bを実行するCPUの動作クロック数を（第１の構成群Aを実行するCPUより）低くする、リーク電力の少ないトランジスタでCPUを実現する、CPUキャッシュメモリの量を少なくするなどの設計が可能となる。
【０１２３】
あるいは、CPUは一つであっても、その中に複数のCPUコアを有する場合には、第１の構成群Aと第２の構成群Bを異なるCPUコアで実行することもできる。これにより、このように構成群ごとに異なるCPUコアを用いることで、ユーザインタフェース処理部１１１がオブジェクトの取得イベントを受けてから、オブジェクトとそのリファレンスオブジェクトを取得するまでの処理の多くを第２の構成群Bのみで実行することができる。その間、第１の構成群Aを実行するCPUコアの全てあるいは一部をスリープ状態（処理のできない状態）あるいは低消費電力状態（処理の遅い状態）にすることができ、消費電力の削減が期待できる。また、第２の構成群Bを実行するCPUコアは、実行すべき処理量や処理内容に合わせて最適化し、処理中であっても消費電力の低い設計とすることが容易である。典型的には第２の構成群Bを実行するCPUコアの動作クロック数を（第１の構成群Aを実行するCPUコアより）低くする、リーク電力の少ないトランジスタでCPUコアを実現する、CPUコアのキャッシュメモリ量を少なくするなどの設計が可能となる。
【０１２４】
このように、本実施形態によれば、データ先行取得部１１６は、データ保持部１１５がFreshなデータを保持しているオブジェクトデータの取得を行わないため、消費電力の削減が期待できる。特に、リファンレンスオブジェクトの数が多い場合や、ネットワーク遅延が大きくオブジェクトデータの取得に時間を要する場合には、一層その効果を期待できる。また、ネットワークを介してのデータ取得は、データ保持部１１５からのデータ取得に比べて要する時間が大きいため、データ保持部１１５に保持されているオブジェクトデータのデータを、ネットワークを介して取得しないことで、ユーザインタフェース処理部１１１がオブジェクト取得イベントを受けてから描画データ表示を行うまでの時間を短くすることができる。よって、ユーザのイライラ感解消を期待できる。
【０１２５】
図１０に、本実施形態に係るシーケンス図を示す。
【０１２６】
この動作例は、マウスクリックイベントにより、URL=A（例えば、HTTP://www.toshiba.co.jp/index.html）のデータを取得する場合のものであり、URL=Aのリファンレンスオブジェクトの識別子がURL=BとURL=CとURL=Dであるとしている。また、データ保持部１１５において、URL=Bは既に保持されておりFreshな状態であるとする。
【０１２７】
マウスクリックイベントがユーザインタフェース処理部１１１に入力され（S51）、URL＝Aがデータ取得部１１４に送られる（S52）。データ取得部１１４は、URL=Aのデータがデータ保持部１１５に保持されているか確認し（S53）、Staleな状態のデータが保持されているとの応答を得る（S54）。データ取得部１１４は、URL=Aに対する変更確認付データ取得要求を通信処理部１１７を介してWebサーバに送信する（S55、S56）。Webサーバから、URL=Aに対するデータ取得応答（データ本体を含む）が返され、通信処理部１１７を介してデータ先行取得部１１６に渡される（S57、S58）。
【０１２８】
データ先行取得部１１６は、データ抽出部２にURL=Aに対するデータのリファレンスオブジェクトの識別子の抽出を要求し、URL=B、URL=C、URL=Dの識別子が返される（S59、S60）。データ先行取得部１１６は、データ情報保持部１１８に対して、URL=B、URL=C、URL=Dのデータを保持しているかを問い合わせる（S61）。データ先行取得部１１６は、URL=Bについてはfreshなデータを保持しており、URL=C、URL=Dについてはデータを保持していないとの応答を得る（S62）。データ先行取得部１１６は、URL=C、URL=Dに対するデータ取得要求を通信処理部１１７を介してWebサーバに送信する（S63、S64）。Webサーバから、URL=CとURL=Dに対するデータ取得応答（データ本体を含む）が返され、通信処理部１１７を介してデータ先行取得部１１６に渡される（S65、S66）。
【０１２９】
データ先行取得部１１６は、URL＝Aに対するデータ取得応答（データ本体を含む）をデータ取得部１１４に送る（S67）。データ取得部１１４は、データ抽出部１に、URL＝Aに対するデータのリファレンスオブジェクトの識別子の抽出を要求する（S68）。データ抽出部１は、URL=B、URL=C、URL=Dの識別子を抽出し、データ取得部１１４に返す（S69）。
【０１３０】
データ取得部１１４は、データ保持部１１５に対して、URL=B、URL=C、URL=Dのデータを保持しているかを問い合わせる（S70）。データ取得部１１４は、URL=Bについてはfreshなデータを保持しており、URL=C、URL=Dについてはデータを保持していないとの応答を得る（S71）。データ取得部１１４は、データ先行取得部１１６に対し、URL=C、URL=Dに対するデータ取得要求を送る（S72）。データ先行取得部１１６は、ステップS66で取得したURL=CとURL=Dに対するデータ取得応答（データ本体を含む）をデータ取得部１１４に返す（S73）。またデータ取得部１１４は、データ保持部１１５からURL＝Bに対するデータを取得する（S74）。データ取得部１１４は、URL=A、URL=B、URL=C、URL=Dに対するデータの描画要求を描画データ生成部１１２に送る（S75）。描画データ生成部１１２は、URL=A、URL=B、URL=C、URL=Dに対するデータを描画し、描画したデータをユーザインタフェース処理部１１１に渡す（S76）。
【０１３１】
（変形例１：データ情報保持部の保持内容を削減）
上述の実施形態では、データ情報保持部１１８は、データ情報としてデータ保持部１１５が有するオブジェクトデータの{URL,データ生成日時、Etag,Age,Max-age,データ取得日時}を有していたが、オブジェクトデータの{URL}のみを有しても良い。これにより、データ情報保持部１１８の保持するデータ量を減らし、またデータ保持部１１５とデータ情報保持部１１８との間で送受信されるデータ量を減らすことができる。ただし、データ情報として{URL}のみを保持することで、データを保持するか否かの判断はできるが、保持しているデータがFreshかStaleかの判断はできない。このため、データ保持部１１５の保持するデータは全てFreshであるとみなして処理を行う。
【０１３２】
全てFreshであるとみなして処理を行うとは、データ保持部１１５の保持するオブジェクトデータに対しては、データ先行取得部１１６による取得が終わったのち、データ取得部１１４からの要求でこのオブジェクトのデータ取得要求を出すことになる。図１０のシーケンス例では、データ保持部１１５がURL=BのオブジェクトのデータをStale状態で保持していた場合、ステップS72で、データ取得部１１４が、URL=CとURL=Dに加えURL=Bのデータ取得要求を送る。これを受けた通信処理部１１７は、URL=Bのオブジェクトデータをデータ先行取得部１１６が取得していないことから、URL=Bのオブジェクトのデータ取得要求を、データ先行取得部１１６ではなくWebサーバに向けて送信し、その応答をデータ取得部１１４に送る。
【０１３３】
ここでデータ情報保持部１１８には、データ保持部１１４の有するFreshなデータのみに対するデータ情報のみを保持するようにすることが一層望ましい。
【０１３４】
また、{URL}をブルームフィルタと呼ばれるデータ構造で保持することで、データ情報保持部１１８の保持するデータ量を削減することができる。ブルームフィルタのアルゴリズムを簡単に示す。空のブルームフィルタは、全て 0 に設定された m ビットのビット配列である。また、同時に k 個のハッシュ関数が定義されており、それぞれのハッシュ関数が、キー値（すなわちURL）を m 個の配列位置（ビット位置）のいずれかにマッピングする。簡単な例では、各ハッシュ関数の値域は0〜mである。データ情報保持部の保持するそれぞれのURLに対してm個の配列位置へのマッピングを計算し、それらの和をとる。ここで和とは、その配列位置へのマッピングがされたURLが１つでも存在すれば、その配列位置を１とすることをいう（すなわち論理和）。このようにしてブルームフィルタを生成する。データ情報保持部１１８が、あるURLのオブジェクトのデータ保持の有無を問い合わされたときは、そのURLのk個のハッシュ値を計算し、夫々の値に対応する配列位置（ビット位置）が、ブルームフィルタで全て１になっているかを確認する。もし全てが１であるならばデータ保持部１１５は当該データを保持していると判定し、そうでなければデータを保持していない判定する。
【０１３５】
ブルームフィルタを用いた場合、データ保持部１１５がデータを保持していない場合でもデータを保持していると誤判定する可能性がある。この場合は、データ先行取得部１１６による取得が終わったのち、データ取得部１１４からの要求でこのオブジェクトのデータ取得要求を出すことになる。図１０のシーケンス例では、データ保持部１１５がURL=Bのオブジェクトのデータを保持していないのに保有していると誤判定した場合、ステップS72でURL=CとURL=Dに加えURL=Bのデータ取得要求を送信する。これを受けた通信処理部１１７はURL=Bのオブジェクトデータをデータ先行取得部１１６が取得していないことから、URL=Bのオブジェクトのデータ取得要求をデータ先行取得部１１６ではなくWebサーバに向けて送信し、Webサーバからの応答をデータ取得部１１４に送る。
【０１３６】
（変形例２：データ情報保持部を変形）
データ情報保持部１１８はデータ情報を保持するのではなく、データ保持の有無をデータ保持部１１５に問い合わせるよう構成することも可能である。    
あるいは、データ保持部１１５が、URL=AのオブジェクトデータをStale状態で保持している場合、データ取得部１１４はURL=Aのオブジェクトのデータ取得要求を出す際に、URL=Aのリファレンスオブジェクトの抽出をデータ抽出部１に依頼し、得られたリファレンスオブジェクトURL=B, URL=C, URL=Dに対してデータ保持部１１５にデータ情報を問い合わせ、得られたデータ情報をデータ保持部１１５からデータ情報保持部１１８に送るようにすることもできる。これにより、データ情報保持部１１８は、取得しようとするオブジェクトデータのリファレンスオブジェクトのデータ情報のみを保持するだけで良い。よって、データ情報保持部１１８の記憶領域を削減することが可能となる。
【０１３７】
（第３の実施形態）
本実施形態では、プリフェッチプロキシが端末とは異なる装置に設けられる場合を示す。
【０１３８】
図１１に、本実施形態に係る通信システムの全体構成を示す。第１の実施形態との違いは、端末２０１、２０２と、Webサーバ２０３、２０４、２０５との間にプリフェッチプロキシ２０６が置かれていることである。プリフェッチプロキシ２０６は有線網２０８と無線網２０７のどちらに置かれても良い。プリフェッチプロキシ２０６は、１つの端末のみならず、２つ以上の端末を同時に扱うことができる。図示の例では、端末が２つ記述されている。
【０１３９】
図１２は、本実施形態に係る端末の構成例を示す。本端末は、第２の実施形態の第１の構成群Aに相当する構成と、通信処理部とを含む。すなわち、本端末は、ユーザインタフェース処理部２１１、描画データ生成部２１２、データ抽出部２１３、データ取得部２１４、データ保持部２１５および通信処理部２１７を有する。
【０１４０】
ユーザインタフェース処理部２１１、描画データ生成部２１２、データ抽出部２１３、データ保持部２１５は、第２の実施形態のユーザインタフェース処理部１１１、描画データ生成部１１２、データ抽出部１、データ保持部１１５と同様である。通信処理部２１７は、プリフェッチプロキシ２１６の通信処理部３１７と通信する。なお、本実施形態ではプリフェッチプロキシ２０６のデータ情報保持部２１８との情報は、通信網を介するため、通信情報処理部２１７を介して送受信する。
【０１４１】
データ取得部２１４は、ユーザインタフェース処理部２１１より取得すべきオブジェクトのURLを受け、これに対するデータ取得要求を通信処理部２１７を介してWebサーバへ送信する。このデータ取得要求の応答を受信すると、このデータに含まれるリファレンスオブジェクトの抽出をデータ抽出部２１３に送り、抽出されたリファレンスオブジェクトのURLを取得する。取得したリファレンスオブジェクトのデータを保持しているかデータ保持部２１５に問い合わせる。
【０１４２】
データ取得部２１４は、データ保持部２１５がFreshなデータを保持している場合には、データ保持部２１５からオブジェクトのデータを取得する。
【０１４３】
データ取得部２１４は、データ保持部２１５がStaleなデータを保持している場合には、通信処理部２１７を介して、プリフェッチプロキシ２０６のデータ先行取得部２１６にデータ取得要求あるいは変更確認付データ取得要求を送信する。
【０１４４】
データ取得部２１４は、データ保持部２１５がデータを保持していない場合には、通信処理部２１７を介して、プリフェッチプロキシ２０６のデータ先行取得部２１６にデータ取得要求を送信する。
【０１４５】
図１３は、本実施形態に係る通信装置を搭載したプリフェッチプロキシ２０６の構成例を示す。プリフェッチプロキシ２０６は、第２の実施形態の第２の構成群Bに相当する構成を具備する。すなわち、プリフェッチプロキシ２０６は、プリフェッチプロキシ２０６は、データ抽出部３１４、データ先行取得部２１６、データ情報保持部２１８、および通信処理部２１７を有する。
【０１４６】
データ抽出部３１４は、第２の実施形態とのデータ抽出部２と同様である。
【０１４７】
データ先行取得部２１６は、通信処理部３１７から取得データを受けると、このデータに含まれるリファレンスオブジェクトの抽出をデータ抽出部３１４に要求し、その応答としてリファレンスオブジェクトのURLを受ける。データ先行取得部２１６は、これらのオブジェクトのデータを、端末のデータ保持部１１５が保持しているかを、データ情報保持部２１８に問い合わせることにより確認する。
【０１４８】
データ先行取得部２１６は、問い合わせの結果、端末のデータ保持部１１５がStaleなデータを保持している場合には、通信処理部３１７を介してWebサーバにデータ取得要求あるいは変更確認付データ取得要求を送信する。
【０１４９】
データ先行取得部２１６は、問い合わせの結果、端末のデータ保持部１１５がデータを保持していない場合には、通信処理部３１７を介してWebサーバにデータ取得要求を送信する。
【０１５０】
リファンレンスオブジェクトのデータをWebサーバから取得し終えると、リファラオブジェクトのデータを、端末のデータ取得部２１４に通信処理部３１７を介して送信する。また、端末のデータ取得部２１４より通信処理部３１７を介してリファレンスオブジェクトの取得を要求されると、既に取得していた当該リファレンスオブジェクトのデータを通信処理部３１７を介して、端末のデータ取得部２１４に送信する。
【０１５１】
データ情報保持部２１８は、端末のデータ保持部２１５の保持するオブジェクトデータに関する情報として、{URL,データ生成日時、Etag,Age,Max-age,データ取得日時}（前述したように、これをデータ情報と本明細書では称する）を有する。この情報を用いることで、端末のデータ保持部２１５の保持するデータに関してデータ有無の問い合わせに答えることができ、データを保持する場合にはFresh あるいはStaleのどちらであるかに答えることができる。
【０１５２】
データ情報保持部２１８は、端末のデータ保持部２１５からデータ情報を通信処理部３１７を介して受信することが望ましい。このデータ情報受信のタイミングは、第２の実施形態と同様であることが望ましい。例えば、端末のデータ保持部２１５が保持するデータを変更されるタイミングが挙げられる。また、データ保持部２１５が保持するデータが変更される度でなくても、予め定められた回数の変更が、保持されるデータにあった場合でも良い。あるいは、前回のデータ情報の受信から予め定められた時間が経過した後、保持されるデータに変更があった最初のタイミングであってもよい。その他、様々なバリエーションが存在し得る。あるいは、データ先行取得部２１６からオブジェクトのデータを受け、これに基づいて保持するデータ情報を更新してもよい。
【０１５３】
通信処理部３１７は、端末のデータ取得部２１４より、データ取得要求を受けると、その宛先のWebサーバに宛先ポート番号８０のTCPコネクションを設定し、HTTPプロトコルに従ってデータ取得要求を送信する。その応答としてWebサーバからデータ取得応答を受信すると、これをデータ先行取得部２１６に渡す。データ先行取得部２１６からリファンレスオブジェクトに関するデータ取得要求を受信すると、その宛先のWebサーバに宛先ポート番号８０のTCPコネクションを設定し、HTTPプロトコルに従ってデータ取得要求を送信する。その応答としてWebサーバからデータ取得応答を受信すると、これをデータ先行取得部２１６に渡す。データ先行取得部２１６から端末のデータ取得部２１４に宛てたデータ取得応答を受け取ると、これを端末のデータ取得部２１４に送信する。端末のデータ取得部２１４からデータ先行取得部３１７へのデータ取得要求を受信すると、これをデータ先行取得部２１６に送る。
【０１５４】
ここで、データ情報保持部２１８の保持するデータ情報は、各端末の識別情報を含み、端末ごとにデータ情報を管理することが望ましい。例えば、データ情報保持部２１８は、{端末識別子、URL,データ生成日時、Etag,Age,Max-age,データ取得日時}の情報を保持する。ここで端末識別子とは、端末のIPアドレスやMACアドレスなど扱う端末を一意に識別できればいかようなものでも可能である。端末識別子は、端末のデータ取得部２１４からのデータ取得要求にも含めることが望ましい。
【０１５５】
あるいは、一つの端末が複数のブラウザを動作させている場合、すなわち端末が二つ以上のデータ保持部を有する場合には、データ情報保持部２１８は、データ保持部毎にデータ情報を管理することが望ましい。例えば、データ情報保持部２１８は、{端末識別子、データ保持部識別子、URL,データ生成日時、Etag,Age,Max-age,データ取得日時}の情報を保持する。ここでデータ保持部識別子は、各端末の中で一意の識別子であればいかようなものでも適用できる。具体例としては、ブラウザ名やブラウザの起動時刻を用いることができる。ここで、端末識別子とブラウザ識別子は、端末のデータ取得部２１４からのデータ取得要求にも含めることが望ましい。
【０１５６】
（第４の実施形態）
本実施形態では、上述した第２の実施形態に係る端末のハードウエア構成上の各種変形例を示す。以下、第２の実施形態との差分を中心に説明する。
【０１５７】
図１４は、本実施形態に係る端末のハードウエア構成例１を示す。図９と同一または対応する要素には同一の符号を付して重複する説明を省略する（以下同様）。
【０１５８】
図９の通信処理部１１７が、プロトコル処理部２１１と通信インタフェース部１２２に分けられ、通信インタフェース部１２２を第２構成群Bから分離している。プロトコル処理部１２１は、TCP/IPおよびHTTPなどの通信プロトコルの処理を担当する。通信インタフェース部１２２は、MAC層以下の（無線）ネットワーク処理を担当する。第１構成群Aはコア１、第２構成群Bはコア（通信装置）２であり、SoC（System-On-Chip）として、半導体チップ（半導体集積回路）上に構成されている。半導体チップと通信インタフェース部間のバスには、メモリなどのその他のデバイス１２３が存在してもよい。
【０１５９】
図１５は、本実施形態に係る端末のハードウエア構成例２を示す。
【０１６０】
第１構成群Aがチップに形成され、第２構成群Bが、NIC等の通信I/Fモジュール（通信装置）に形成されている。データ保持部１１５が、第１構成群Aから取り出され、通信I/Fモジュールに搭載されている。たとえば通信I/Fモジュール上のNANDフラッシュ等のメモリデバイスがブラウザキャッシュ（データ保持部１１５）となる場合が示される。チップと通信I/Fモジュールは、半導体チップの外部インタフェース部１２４と、通信I/Fモジュールのホストインタフェース部１２５により、内部バスを介して接続されている。
【０１６１】
図１６は、本実施形態に係る端末のハードウエア構成例３を示す。
【０１６２】
本例では第２構成群Bおよびデータ保持部１１５が、SDカードのようなプリフェッチモジュール（通信装置）に搭載された場合が示される。図１５の構成と同様、NANDフラッシュ等のメモリデバイスが、ブラウザキャッシュ（データ保持部１１５）となる。NIC等の通信インタフェース１２７は、半導体チップとプリフェッチモジュール間のバス１２６上に接続されている。
【０１６３】
図１７は、本実施形態に係る端末のハードウエア構成例４を示す。
【０１６４】
図１５の構成と異なる点は、データ保持部１１５が通信I/Fモジュールではなく、半導体チップおよび通信I/Fモジュール間のバス１２６上に配置されていることである。本例は、通信I/Fモジュール上のマイコン（通信装置）でプリフェッチ機能を実行し、データを当該モジュールの外部に蓄積する場合の構成である。通信I/Fモジュールは、ホストインタフェース部１２５を介して、バス１２６上のデータ保持部１１５を参照する機能を有するものとする。
【０１６５】
図１８は、本実施形態に係る端末のハードウエア構成例５を示す。
【０１６６】
本例は、図１７の構成と同様にデータ保持部１１５がバス１２６上に配置され、第２構成群Bを搭載するチップとしてのモジュール（通信装置）が、通信インタフェース（NIC等）１２７と半導体チップの間に配置されている。当該モジュールは、ホストインタフェース部１２５を介して、バス１２６上のデータ保持部１１５を参照し、通信インタフェース部１２２を介して通信インタフェース１２７にアクセスする。
【０１６７】
図１９は、本実施形態に係る端末のハードウエア構成例６を示す。
【０１６８】
図１８の構成と異なる点は、通信インタフェース１２７が、バス１２６上に接続されている点である。それ以外の構成は、図１８と同様である。
【０１６９】
図２０は、本実施形態に係る端末のハードウエア構成例７を示す。
【０１７０】
図１４の構成と異なる点は、データ保持部１１５とデータ情報保持部１１８をそれぞれコア１およびコア２から取り出して、第１構成群A(コア１)および第２構成群B(コア２)が形成された半導体チップとは異なるメモリデバイスに搭載したことである。メモリデバイスと半導体チップはバスを介して接続されている。
【０１７１】
尚、各実施形態の通信装置（端末、チップ、NIC、プロキシ等）は、例えば、汎用のコンピュータ装置を基本ハードウエアとして用いることでも実現することが可能である。すなわち通信装置内の各処理部は、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現することが出来る。このとき、通信装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現してもよいし、CD-ROMなどの記憶媒体に記憶して、あるいはネットワークを介して上記のプログラムを配布して、このプログラムをコンピュータ装置に適宜インストールすることで実現してもよい。また、通信装置内の各記憶部は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはCD-R、CD-RW、DVD-RAM、DVD-R等の記憶媒体などを適宜利用して実現することが出来る。
【０１７２】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【図１】
2014164698.tif 000004
【図２】
2014164698.tif 000005
【図３】
2014164698.tif 000006
【図４】
2014164698.tif 000007
【図５】
2014164698.tif 000008
【図６】
2014164698.tif 000009
【図７】
2014164698.tif 000010
【図８】
2014164698.tif 000011
【図９】
2014164698.tif 000012
【図１０】
2014164698.tif 000013
【図１１】
2014164698.tif 000014
【図１２】
2014164698.tif 000015
【図１３】
2014164698.tif 000016
【図１４】
2014164698.tif 000017
【図１５】
2014164698.tif 000018
【図１６】
2014164698.tif 000019
【図１７】
2014164698.tif 000020
【図１８】
2014164698.tif 000021
【図１９】
2014164698.tif 000022
【図２０】
2014164698.tif 000023