JP6088853B2 - 通信装置、通信方法および通信プログラム - Google Patents

通信装置、通信方法および通信プログラム Download PDF

Info

Publication number
JP6088853B2
JP6088853B2 JP2013037696A JP2013037696A JP6088853B2 JP 6088853 B2 JP6088853 B2 JP 6088853B2 JP 2013037696 A JP2013037696 A JP 2013037696A JP 2013037696 A JP2013037696 A JP 2013037696A JP 6088853 B2 JP6088853 B2 JP 6088853B2
Authority
JP
Japan
Prior art keywords
data
unit
url
holding unit
acquisition
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2013037696A
Other languages
English (en)
Other versions
JP2014164698A (ja
Inventor
瀬 恒太郎 伊
瀬 恒太郎 伊
原 丈 士 石
原 丈 士 石
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2013037696A priority Critical patent/JP6088853B2/ja
Priority to US14/187,735 priority patent/US20140244790A1/en
Publication of JP2014164698A publication Critical patent/JP2014164698A/ja
Application granted granted Critical
Publication of JP6088853B2 publication Critical patent/JP6088853B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明の実施形態は、通信装置、通信方法および通信プログラムに関する。
近年、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のデータを保持するか否かの問い合わせを受けた場合には、次の３つの応答のどれか一つをデータ取得部１４に返す。
Figure 0006088853
また、データ保持部１５は、データ取得部１４より、あるＵＲＬについてデータ取得要求を受けた場合には、その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等の記憶媒体などを適宜利用して実現することが出来る。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

Claims (9)

  1. 要求元からの第１データの取得要求に応じて、第１の取得先から前記第１データを取得する第１取得部と、
    前記第１データに基づき、前記要求元が必要とする他のデータである第２データを決定する決定部と、
    前記要求元からアクセス可能な外部または内部のデータ保持部に保有されているデータに関する情報を、内部または外部のデータ情報保持部から読み出し、読み出した情報に基づき、前記第２データが前記データ保持部に保有されていない場合、前記第２データを第２の取得先から取得する第２取得部と、
    を備えた通信装置。
  2. 前記データ情報保持部をさらに備えた請求項１に記載の通信装置。
  3. 前記データ保持部をさらに備えた請求項２に記載の通信装置。
  4. 要求元からの第１データの取得要求に応じて、第１の取得先から前記第１データを取得する第１取得部と、
    前記第１データに基づき、前記要求元が必要とする他のデータである第２データを決定する決定部と、
    前記第１取得部により前記第１データが取得された後、前記要求元からアクセス可能な外部または内部のデータ保持部に問い合わせることにより、前記第２データが前記データ保持部に保有されていない場合、前記第２データを第２の取得先から取得する第２取得部と
    を備えた通信装置。
  5. 前記データ保持部をさらに備えた請求項４に記載の通信装置。
  6. 要求元からの第１データの取得要求に応じて、第１の取得先から前記第１データを取得するステップと、
    前記第１データに基づき、前記要求元が必要とする他のデータである第２データを決定するステップと、
    前記要求元からアクセス可能な外部または内部のデータ保持部に保有されているデータに関する情報を、内部または外部のデータ情報保持部から読み出すステップと、
    読み出した情報に基づき、前記第２データが前記データ保持部に保有されていない場合、前記第２データを第２の取得先から取得するステップと、
    を備えた通信方法。
  7. 要求元からの第１データの取得要求に応じて、第１の取得先から前記第１データを取得するステップと、
    前記第１データに基づき、前記要求元が必要とする他のデータである第２データを決定するステップと、
    前記要求元からアクセス可能な外部または内部のデータ保持部に保有されているデータに関する情報を、内部または外部のデータ情報保持部から読み出すステップと、
    読み出した情報に基づき、前記第２データが前記データ保持部に保有されていない場合、前記第２データを第２の取得先から取得するステップと、
    をコンピュータに実行させるための通信プログラム。
  8. 要求元からの第１データの取得要求に応じて、第１の取得先から前記第１データを取得するステップと、
    前記第１データに基づき、前記要求元が必要とする他のデータである第２データを決定するステップと、
    前記第１データが取得された後、前記要求元からアクセス可能な外部または内部のデータ保持部に問い合わせることにより、前記第２データが前記データ保持部に保有されていない場合、前記第２データを第２の取得先から取得するステップと
    を備えた通信方法。
  9. 要求元からの第１データの取得要求に応じて、第１の取得先から前記第１データを取得するステップと、
    前記第１データに基づき、前記要求元が必要とする他のデータである第２データを決定するステップと、
    前記第１データが取得された後、前記要求元からアクセス可能な外部または内部のデータ保持部に問い合わせることにより、前記第２データが前記データ保持部に保有されていない場合、前記第２データを第２の取得先から取得するステップと
    をコンピュータに実行させるための通信プログラム。
JP2013037696A 2013-02-27 2013-02-27 通信装置、通信方法および通信プログラム Active JP6088853B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2013037696A JP6088853B2 (ja) 2013-02-27 2013-02-27 通信装置、通信方法および通信プログラム
US14/187,735 US20140244790A1 (en) 2013-02-27 2014-02-24 Communication apparatus, communication method and non-transitory computer readable medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013037696A JP6088853B2 (ja) 2013-02-27 2013-02-27 通信装置、通信方法および通信プログラム

Publications (2)

Publication Number Publication Date
JP2014164698A JP2014164698A (ja) 2014-09-08
JP6088853B2 true JP6088853B2 (ja) 2017-03-01

Family

ID=51389361

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013037696A Active JP6088853B2 (ja) 2013-02-27 2013-02-27 通信装置、通信方法および通信プログラム

Country Status (2)

Country Link
US (1) US20140244790A1 (ja)
JP (1) JP6088853B2 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5749658B2 (ja) 2009-03-04 2015-07-15 マシモ・コーポレイション 医療監視システム
US9323894B2 (en) 2011-08-19 2016-04-26 Masimo Corporation Health care sanitation monitoring system
US9634992B1 (en) * 2015-02-28 2017-04-25 Palo Alto Networks, Inc. Probabilistic duplicate detection
US11809378B2 (en) 2021-10-15 2023-11-07 Morgan Stanley Services Group Inc. Network file deduplication using decaying bloom filters
CN115065557B (zh) * 2022-08-05 2022-11-04 国网浙江省电力有限公司 适用于多系统间的数据安全交互方法

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5878213A (en) * 1996-02-15 1999-03-02 International Business Machines Corporation Methods, systems and computer program products for the synchronization of time coherent caching system
US5754774A (en) * 1996-02-15 1998-05-19 International Business Machine Corp. Client/server communication system
US5933593A (en) * 1997-01-22 1999-08-03 Oracle Corporation Method for writing modified data from a main memory of a computer back to a database
US6343083B1 (en) * 1998-04-09 2002-01-29 Alcatel Usa Sourcing, L.P. Method and apparatus for supporting a connectionless communication protocol over an ATM network
JP3833409B2 (ja) * 1999-02-05 2006-10-11 株式会社日立製作所 通信プロキシ装置
US6938096B1 (en) * 1999-04-12 2005-08-30 Softricity, Inc. Method and system for remote networking using port proxying by detecting if the designated port on a client computer is blocked, then encapsulating the communications in a different format and redirecting to an open port
JP4202534B2 (ja) * 1999-06-25 2008-12-24 株式会社東芝 Ｗｅｂデータのキャッシュ更新方法およびキャッシュ更新システム
US6785704B1 (en) * 1999-12-20 2004-08-31 Fastforward Networks Content distribution system for operation over an internetwork including content peering arrangements
JP3534027B2 (ja) * 1999-12-01 2004-06-07 日本電気株式会社 コンテンツ提供装置及びプログラムを記録した機械読み取り可能な記録媒体
US6622168B1 (en) * 2000-04-10 2003-09-16 Chutney Technologies, Inc. Dynamic page generation acceleration using component-level caching
US7003555B1 (en) * 2000-06-23 2006-02-21 Cloudshield Technologies, Inc. Apparatus and method for domain name resolution
US8204082B2 (en) * 2000-06-23 2012-06-19 Cloudshield Technologies, Inc. Transparent provisioning of services over a network
US7124173B2 (en) * 2001-04-30 2006-10-17 Moriarty Kathleen M Method and apparatus for intercepting performance metric packets for improved security and intrusion detection
US6601142B2 (en) * 2001-09-21 2003-07-29 International Business Machines Corporation Enhanced fragment cache
US7330880B1 (en) * 2002-04-22 2008-02-12 Network Appliance, Inc. Method and apparatus for reliable download to a network cache while limiting origin server load
JP2007128371A (ja) * 2005-11-04 2007-05-24 Fujitsu Ltd コンテンツ検索システム
US9071506B2 (en) * 2006-07-31 2015-06-30 Hewlett-Packard Development Company, L.P. Accessing web services using network management information
US20100211605A1 (en) * 2009-02-17 2010-08-19 Subhankar Ray Apparatus and method for unified web-search, selective broadcasting, natural language processing utilities, analysis, synthesis, and other applications for text, images, audios and videos, initiated by one or more interactions from users
US8209699B2 (en) * 2009-07-10 2012-06-26 Teradata Us, Inc. System and method for subunit operations in a database
US8447875B2 (en) * 2010-03-10 2013-05-21 Thomson Licensing Unified cache and peer-to-peer method and apparatus for streaming media in wireless mesh networks
WO2011139305A1 (en) * 2010-05-04 2011-11-10 Azuki Systems, Inc. Method and apparatus for carrier controlled dynamic rate adaptation and client playout rate reduction
US8463846B2 (en) * 2010-05-06 2013-06-11 Cdnetworks Co., Ltd. File bundling for cache servers of content delivery networks
US9230006B2 (en) * 2010-09-30 2016-01-05 Bullhorn, Inc. Remote access to tracking system contact information
US8880589B2 (en) * 2010-12-29 2014-11-04 Environmental Systems Research Institute, Inc. Signature based map caching
WO2011120450A2 (zh) * 2011-04-28 2011-10-06 华为终端有限公司 基于http的内容获取方法及客户端
US20130179489A1 (en) * 2012-01-10 2013-07-11 Marcus Isaac Daley Accelerating web services applications through caching
US9055118B2 (en) * 2012-07-13 2015-06-09 International Business Machines Corporation Edge caching using HTTP headers
US10108987B2 (en) * 2013-06-21 2018-10-23 Iheartmedia Management Services, Inc. E-mail based dynamic advertising
US9209974B1 (en) * 2015-05-03 2015-12-08 Zeutro, Llc Functional encryption key management

Also Published As

Publication number Publication date
US20140244790A1 (en) 2014-08-28
JP2014164698A (ja) 2014-09-08

Similar Documents

Publication Publication Date Title
US20210044662A1 (en) Server side data cache system
CN104866383B (zh) 一种接口调用方法、装置及终端
US20120317153A1 (en) Caching responses for scoped and non-scoped domain name system queries
JP6088853B2 (ja) 通信装置、通信方法および通信プログラム
US9426200B2 (en) Updating dynamic content in cached resources
WO2017114206A1 (zh) 短链接处理方法、装置及短链接服务器
US20130227047A1 (en) Methods for managing content stored in cloud-based storages
US10057368B1 (en) Method and system for incremental cache lookup and insertion
JP2011108102A (ja) ウェブサーバ、ウェブブラウザおよびウェブシステム
JP2012518225A (ja) ドメインにわたりクッキーを処理する方法およびシステム
EP2947582A1 (en) Computing device and method for executing database operation command
CN104636464B (zh) 访问文件的方法和装置
CN108536617A (zh) 缓存管理方法、介质、系统和电子设备
CN107015978B (zh) 一种网页资源处理方法以及装置
CN105701233B (zh) 一种优化服务器缓存管理的方法
CN105988941B (zh) 缓存数据处理方法和装置
CN105915619A (zh) 顾及访问热度的网络空间信息服务高性能内存缓存方法
US9836491B1 (en) Method and apparatus for hardware-implemented AVL tree updates
US8112495B2 (en) Transmitting information about distributed group memberships
WO2014190700A1 (zh) 一种内存访问的方法、缓冲调度器和内存模块
CN105491082B (zh) 远程资源访问方法和交换设备
US20140331117A1 (en) Application-based dependency graph
US9787755B2 (en) Method and device for browsing network data, and storage medium
JP5809099B2 (ja) Ｗｅｂ閲覧画面サムネイル生成システム
CN109002495A (zh) 数据存储方法和装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150914

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160713

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160715

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160913

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161007

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161206

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170106

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170206

R151 Written notification of patent or utility model registration

Ref document number: 6088853

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151