JP2015022539A - 情報端末及びデータ処理プログラム - Google Patents

Abstract

【課題】サーバと情報端末との間の通信量を低減し、効率良く情報を通信することを可能とする。
【解決手段】アプリケーションを実行する情報端末２００であって、ネイティブ部分実行部を実行することによって、ネットワーク２０４を介してサーバ２０２にアクセスして通信を行うプロキシ４２として機能し、ウェブブラウザ４０を実行することによって、プロキシ４２を介してサーバ２０２からダウンロード情報を取得して、ダウンロード情報を出力するブラウザとして機能する情報端末２００とする。
【選択図】図２

Description

本発明は、サーバから情報を取得する情報端末及びその処理を実現するデータ処理プログラムに関する。

近年、スマートフォン等の携帯端末において、端末内の処理部が実行するネイティブ部分実行部と、ネットワークを介して接続されたサーバ側（ウェブ部分実行部）で処理された情報を受信して利用するウェブブラウザと、を組み合わせたアプリケーションを用いた処理が利用されている。

このようなアプリケーションを用いることによって、携帯端末に固有に搭載されている機能をネイティブ部分実行部によって十分に活用できると共に、頻繁に更新される処理はウェブ部分実行部に負担させる等、ネイティブ部分実行部とウェブ部分実行部の両方の利点を得ることができる。

図６は、ネイティブ部分実行部とウェブ部分実行部との処理で実現されるアプリケーションを用いた携帯端末１００とサーバ１０２との情報のやり取りを説明する図である。携帯端末１００は、アプリケーションの実行によって実現されるウェブブラウザ１０に含まれるダウンローダ１０ａを用いて、ネットワーク１０４を介して接続されたサーバ１０２にアクセスする。ダウンローダ１０ａは、例えば、Ｂａｓｅ６４等でエンコードされた情報をサーバ１０２から受信する。サーバ１０２から受信された情報は、携帯端末１００のウェブブラウザ１０からアクセス可能なブラウザキャッシュ１０ｂ、又は、ネイティブ１２側のストレージ１２ａのいずれかに格納及び保持される。このとき、ネイティブ部分実行部の実行によりウェブブラウザ１０から情報を受けてストレージ１２ａにその情報を格納し、ウェブブラウザ１０から情報の要求を受けてストレージ１２ａに保持されている情報をウェブブラウザ１０へ受け渡す処理が実現される。ウェブブラウザ１０とストレージ１２ａとの間においてもＢａｓｅ６４等でエンコードされた情報が受け渡しされ、ストレージ１２ａにはエンコードされた状態で情報が格納される。

また、ウェブブラウザ１０のキャッシュ機能を用いて、サーバ１０２から一度取得したデータをブラウザキャッシュ１０ｂに記憶しておき、ブラウザキャッシュ１０ｂに記憶されているデータについて再度取得する手間を省く処理が知られている。

非特許文献１には、ブラウザキャッシュに記憶するデータの最終更新日とバージョン情報とを関連付けしたハッシュ値等を管理しておくことで、取得しようとするデータがキャッシュに記憶されている場合、通信ネットワークを介してそのデータを取得することなく、キャッシュに記憶されたデータを利用する技術が開示されている。

例えば、ネットワークを介してサーバと接続されている情報端末を利用したゲームにおいて、頻繁に更新されるキャラクタデータを情報端末へ送信する際のサーバと情報端末間での通信負荷を低減するために用いられている。

https://developers.google.com/speed/docs/best-practices/caching

ところで、ネットワークの通信帯域の容量が小さい場合、ネットワークを介して画像データやトゥルータイプフォント（ｔｔｆ）等の容量の大きなアセットデータを送受信する際にタイムアウトを起こしてしまうおそれがある。また、上記のように、ブラウザキャッシュやネイティブ側のストレージを利用したとしても、通信帯域が十分でなくなる場合がある。

このような状況において、情報端末とサーバとの間で情報を効率的に通信可能とする技術が望まれている。

本発明の１つの態様は、内蔵された処理部が実行するネイティブ部分実行部と、ネットワークを介して接続されたサーバから受けた情報の表示処理を行うウェブブラウザと、が組み合わされたアプリケーションを実行する情報端末であって、前記ネイティブ部分実行部を実行することによって、前記ネットワークを介して前記サーバにアクセスして通信を行うプロキシとして機能し、前記ウェブブラウザを実行することによって、前記プロキシを介して前記サーバからダウンロード情報を取得して、前記ダウンロード情報を出力するブラウザとして機能することを特徴とする情報端末である。

ここで、前記プロキシを介して前記サーバから受信した前記ダウンロード情報を記憶する端末記憶部を備えることが好適である。

また、前記ダウンロード情報は、アセットデータ、アセットデータの識別情報及びアセットデータのバージョン情報を含み、前記プロキシは、前記ウェブブラウザからアセットデータの要求を受けると、アセットデータを前記サーバから受信する前に、受信対象となるアセットデータの識別情報及び当該アセットデータに対するバージョン情報とを前記サーバから受信し、受信したバージョン情報が前記端末記憶部に記憶されているかを判別し、受信したバージョン情報が前記端末記憶部に記憶されていないときに、当該バージョン情報に対応するアセットデータの送信を前記サーバに要求し、受信したバージョン情報が前記端末記憶部に記憶されているときに、当該バージョン情報に対応するアセットデータの送信を前記サーバに要求しない、ことが好適である。

また、前記端末記憶部に、前記ダウンロード情報をバイナリ情報として記憶することが好適である。

また、前記ブラウザは、ｈｔｔｐにより前記プロキシから前記ダウンロード情報を取得することが好適である。

上記情報端末は、以下のデータ処理プログラムにより実現することができる。すなわち、コンピュータ端末内の処理部が実行するネイティブ部分実行部と、前記コンピュータ端末とネットワークを介して接続されたサーバから受けた情報の表示処理を行うウェブブラウザと、が組み合わされたアプリケーションを含むデータ処理プログラムであって、前記コンピュータ端末を、前記ネイティブ部分実行部を実行することによって、前記ネットワークを介して前記サーバにアクセスして通信を行うプロキシとして機能させ、前記ウェブブラウザを実行することによって、前記プロキシを介して前記サーバからダウンロード情報を取得して、前記ダウンロード情報を出力するブラウザとして機能させることを特徴とするデータ処理プログラムである。

ここで、前記ダウンロード情報は、アセットデータ、アセットデータの識別情報及びアセットデータのバージョン情報を含み、前記プロキシは、前記ウェブブラウザからアセットデータの要求を受けると、アセットデータを前記サーバから受信する前に、受信対象となるアセットデータの識別情報及び当該アセットデータに対するバージョン情報とを前記サーバから受信し、受信したバージョン情報が端末記憶部に記憶されているかを判別し、受信したバージョン情報が前記端末記憶部に記憶されていないときに、当該バージョン情報に対応するアセットデータの送信を前記サーバに要求し、受信したバージョン情報が前記端末記憶部に記憶されているときに、当該バージョン情報に対応するアセットデータの送信を前記サーバに要求しない、ことが好適である。

本発明によれば、アプリケーションにプロキシ機能を組み込むことによって、サーバと情報端末との間の通信量を低減し、効率良く情報を通信することが可能となる。

本発明の実施の形態におけるデータ処理システムの構成を示す図である。 本発明の実施の形態におけるデータ処理システムの機能ブロックを示す図である。 本発明の実施の形態におけるデータの送受信を説明するフローチャートである。 ページの切り替えを説明する図である。 本発明の実施の形態におけるデータ処理システムの別例の機能ブロックを示す図である。 従来のデータ処理システムの機能ブロックを示す図である。

以下、本発明の実施形態について、図面に基づいて説明する。

＜システムの全体構成＞
図１は、本実施形態に係るデータ処理システムの概略構成を示すブロック図である。サーバ２０２は、ネットワーク２０４に接続されており、このネットワーク２０４に情報端末２００が接続されている。情報端末２００は、ネットワーク２０４を介し、必要なデータをサーバ２０２から入手してゲーム等の処理を実行する。

なお、本実施の形態では、情報端末２００においてゲームを実行する例について説明するが、本発明の適用範囲はこれに限定されるものでなく、サーバ２０２と情報端末２００との間で随時更新されるデータの通信を行う態様であれば適用範囲となる。
＜サーバの構成及び機能＞
サーバ２０２は、コンピュータであり、各種のデータ処理機能、通信機能、記憶機能を備えている。サーバ２０２には、ゲームロジック、およびそのゲームを実行する際に使用されるユーザデータ、およびアセットデータが記憶される。

アセットデータは、たとえば、画像データ、動画（アニメーションデータ）、文字情報（トゥルータイプフォント：ｔｔｆ）などを含む。アセットデータは、これらのデータに限定されるものではないが、文書データ等よりもデータ容量が大きいデータである場合に本発明の効果がより顕著となる。

一般的に、ソーシャルゲームでは、ゲームを実行するためのゲームロジックは基本的に変更が頻繁でないが、画像データ、動画（アニメーションデータ）などのアセットデータは随時変更される。すなわち、アセットデータは開発者等によって随時変更され、メモリ２０内の既存のアセットデータが新規のアセットデータによって随時書き換えられ、更新される。このように変更を受けたアセットデータを情報端末２００で実行中のゲームにも反映するために、サーバ２０２から情報端末２００へアセットデータを送信する必要がある。

なお、開発者のコンピュータは、ネットワーク２０４を介しサーバ２０２に接続してもよいが、内部ＬＡＮ、無線通信など他の通信回線を介しサーバ２０２に接続してもよい。

サーバ２０２は、図２の機能ブロック図に示すように、データ更新部２２を有し、このデータ更新部２２がメモリ２０内のデータの更新を管理する。すなわち、データ更新部２２は、更新データを受け取った場合に、メモリ２０内のデータを更新する。ここで、このデータ更新は、基本的にアセットデータの更新を前提としている。ここで、アセットデータは、１つの画像、１つの動画等を１単位として、それぞれ１つのファイルとして記憶されており、各ファイルにはファイル名の他、更新時刻、ファイル容量などの属性情報が付与されている。すなわち、既存のアセットデータと新規のアセットデータとは、この属性情報に基づいて対応付けすることが可能である。たとえば、メモリ２０に記憶されているアセットデータを更新する際には、古いアセットデータを新しいアセットデータで更新し、新しいアセットデータに更新された古いアセットデータと同一のファイル名を付与することにより対応付けが行われる。

サーバ２０２は、データを送信する場合に、その送信データについて、ファイル毎にハッシュ値を計算し、計算結果のハッシュ値をファイルとともに送信する。

データ更新部２２は、ファイルのデータ自体や属性情報からハッシュ値を計算し、これをファイルと関連づけて送信する。なお、ハッシュ値は、そのファイルに含まれるアセットデータ（画像データ、動画データ等）又はそれに関する属性情報から算出されればよいが、アセットデータ自体から算出することが好適である。すなわち、アセットデータが更新されると、アセットデータ自体から算出されたハッシュ値は更新前のアセットデータ自体から算出されたハッシュ値とは異なる値となり、ハッシュ値はアセットデータ自体のバージョンを示すバージョン情報となる。このハッシュ値を比較することにより、アセットデータが更新されたか否かを確実に把握することができる。

ここで、ファイルが更新される度に、当該ファイルのハッシュ値を計算して、ファイルと対応付けてメモリ２０に記憶することも好適である。こうすることによって、ファイルの送信要求が生じた場合に、すでに記憶されているハッシュ値を送信することもできる。また、一定周期毎に、メモリ２０内のファイルのハッシュ値を計算して更新してもよく、さらにファイルを送信したときに再計算したハッシュ値をファイルに対応付けて更新してもよい。

なお、本実施の形態では、１つのファイルを単位データとして処理する例を示すが、複数ファイルを含む単位データとして当該単位データ毎にハッシュ値を算出して処理してもよい。

また、本実施形態では、バージョン情報としてハッシュ値を適用したが、変更されたアセットデータ（ファイル）に応じて変更されるバージョン情報としてもよい。たとえば、バージョン情報として、チェックサム、チェックディジット、フィンガープリント等としてもよい。

アセットデータの作成者は、例えば、自己のコンピュータをサーバ２０２に接続し、メモリ２０内のデータを随時書き換える。データ更新部２２は、情報端末２００からデータの提供を要求された際に、送信対象となるファイルを含む単位データに基づきそのハッシュ値を計算して、情報端末２００に送信する。

たとえば、データ更新部２２に下記のようなＡＰＩを用意しておく。
＿ｇｅｔ＿ｂｕｎｄｌｅ？ｐａｔｈｓ＝ａ，ｂ，ｃ，ｄ −−−＞ ｛ａ： ｛ｈａｓｈ： ｍｄ５， ｂｏｄｙ： ｂａｓｅ６４｝ ．．．｝
情報端末２００からのアクセスによって、このＡＰＩが呼ばれた時にハッシュ値ｍｄ５を計算してファイルａのバージョン情報とする。このようにすることで、ファイルａが差し替えられた場合には、その後に該当ファイルをユーザに送信すると、その送信データに対応するハッシュ値ｍｄ５値が情報端末２００に送信され、情報端末２００において記憶される。

＜情報端末の構成及び機能＞
情報端末２００は、携帯電話、スマートフォン、タブレット等のコンピュータを含む端末装置である。情報端末２００は、図１に示すように、ＣＰＵを含む処理部３０が基本的なデータ処理を行う。また、情報端末２００には、入力部３２、表示部３４が設けられ、必要なデータ入力、各種表示を行う。たとえば、表示部３４は液晶や有機ＥＬパネルであり、入力部３２は表示部３４と共に設けられたタッチパネルとすることができる。また、情報端末２００には、記憶部３６が設けられる。記憶部３６は、半導体メモリやフラッシュメモリ等を含み、情報端末２００によって処理される情報（アセットデータを含む）を格納及び保持する。記憶部３６は、後述するブラウザキャッシュやネイティブキャッシュとして利用される。

情報端末２００では、アプリケーションが実行され、ネットワーク２０４を介したサーバ２０２へのアクセスや情報端末２００での情報処理が行われる。例えば、情報端末２００のユーザがゲームを開始する場合には、ＵＲＬを特定してそのゲームプログラムの提供先であるサーバ２０２にアクセスし、ここからゲームプログラムを格納するアプリケーションをダウンロードする。本実施の形態では、アプリケーションによりゲームの処理が行われる。

ここで、アプリケーションとは、情報端末２００に内蔵された処理部３０が実行して情報端末２００において情報の処理を行わせるネイティブ部分実行部と、サーバ２０２からネットワーク２０４を介して受信された情報を処理するウェブブラウザと、を組み合わせて機能させるものである。例えば、ネイティブ部分実行部の中に簡易ウェブブラウザであるＷｅｂＶｉｅｗを組み込み、情報端末２００での画像表示の一部をウェブブラウザの機能を用いて行うようなアプリケーションである。

アプリケーションであるゲームプログラムは、記憶部３６のネイティブキャッシュ（ネイティブストレージ）３８に記憶され、処理部３０がゲームプログラムを実行することで、ウェブブラウザ４０、プロキシ４２及びダウンローダ４４の機能が実現される。情報端末２００は、これらの機能によってサーバ２０２と通信し、必要な画像、動画などのアセットデータを取得し、表示部３４に表示しつつゲームを進行させる。

プロキシ４２及びダウンローダ４４は、アプリケーションのうちネイティブ部分実行部を実行することによって実現される。これにより、プロキシ４２及びダウンローダ４４は、情報端末２００に固有に設けられている機能を利用することができる。例えば、情報端末２００に固有のネットワークインターフェース等の機能を利用したり、情報端末２００の端末情報等のネイティブ部分実行部のみから利用可能な情報を用いて処理したりすることができる。

ウェブブラウザ４０は、ネットワーク２０４を介してサーバ２０２から得られた情報等を表示部３４に画像表示する等の各種の機能を実現する。また、ウェブブラウザ４０にはブラウザキャッシュ（ブラウザ記憶部）４０ａが設けられている。ブラウザキャッシュ４０ａは、ウェブブラウザ４０が各種処理を実行する際に使用される情報の記憶に利用される。ブラウザキャッシュ４０ａには、更新が頻繁に行われない情報を記憶しておくことが好適である。

情報端末２００は、サーバ２０２から情報を受信する際に、プロキシ４２を介してサーバ２０２へアクセスする。すなわち、ネイティブ部分実行部の実行に必要な情報をサーバ２０２から取得する場合、及び、ウェブブラウザ４０での処理に必要な情報をサーバ２０２から取得する場合のいずれにおいても、アプリケーションに含まれるネイティブ部分実行部によって実現されるプロキシ４２を介して行われる。

ウェブブラウザ４０は、情報端末２００での表示処理の負荷を低減するために、ネイティブキャッシュ３８に記憶されているファイルの一部又は全部をブラウザキャッシュ４０ａに記憶しておくことができる。ウェブブラウザ４０は、まずブラウザキャッシュ４０ａに必要な情報が記憶されているか否かを調べ、記憶されていればその情報を読み出して表示等の処理を行う。ブラウザキャッシュ４０ａに情報が記憶されていなければ、ウェブブラウザ４０は、プロキシ４２に情報を要求する。プロキシ４２は、サーバ２０２に情報を要求する前にネイティブキャッシュ３８に要求された情報が記憶されているか否かを確認し、記憶されていればその情報を読み出してウェブブラウザ４０に受け渡す。ネイティブキャッシュ３８に情報が記憶されていなければ、プロキシ４２は、ダウンローダ４４によってサーバ２０２にその情報を要求する。

ここで、上述したようにサーバ２０２は、アセットデータを含むファイルとそのファイルに対して算出されたハッシュ値を対応付けて記憶しており、情報端末２００からアセットデータの要求を受けると、要求されたアセットデータを含むファイルを送る際に対応付けられたハッシュ値をメタデータとして付加して送信する。

情報端末２００の処理部３０は、受信したファイル（アセットデータ）およびハッシュ値をファイル名に関連付けてデータテーブル等としてネイティブキャッシュ３８に記憶させる。アセットデータは、Ｂａｓｅ６４等によりエンコードされてなくてもよく、バイナリのデータとして扱うことができる。

＜データ取得手順＞
以下、図３のフローチャートを参照して、ネットワーク２０４を介して情報端末２００がサーバ２０２からアセットデータを取得する処理について説明する。本実施形態においては、ゲームで表示されるページ毎にウェブブラウザ４０がサーバ２０２にアクセスし、ページを表示するためのアセットデータを取得するものとして説明を行う。

情報端末２００においてゲームのアプリケーションが実行されると、ネットワーク２０４を介して情報端末２００とサーバ２０２とが相互に情報の送受信が可能となるように接続される。ここで、図４に示すように、１つのページが情報端末２００おいて表示されている状態から次のページの表示に移る際に、ウェブブラウザ４０において新たな情報がウェブブラウザ４０にて必要となる。

まず、ウェブブラウザ４０は、画面表示等に必要なアセットデータがブラウザキャッシュ４０ａに記憶されているか否かを確認する。ブラウザキャッシュ４０ａには、更新がないアセットデータ等が記憶されており、必要なアセットデータがブラウザキャッシュ４０ａに記憶されていれば読み出して利用する。

ブラウザキャッシュ４０ａに必要なアセットデータが記憶されていなければ、ウェブブラウザ４０は、プロキシ４２にそのアセットデータを要求する。ウェブブラウザ４０とプロキシ４２との間では、情報はハイパー・テキスト・トランスファー・プロトコル（ｈｔｔｐ）に則って行うことができる。

プロキシ４２は、ネイティブ部分実行部によって実現されるダウンローダ４４を用いて、要求されたアセットデータをさらにサーバ２０２に要求する。

サーバ２０２は、要求を受けたアセットデータを含むファイルのファイル名（file1, file2, ...）と対応するハッシュ値（バージョン情報）とを関連付けて情報端末２００に送信する。たとえば、ファイル名"file1"とそれに対応付けられたハッシュ値hash1、ファイル名"file2"とそれに対応付けられたハッシュ値hash2、を含む場合、（<html> file1 hash, file2 hash, ...）のようなデータが送信される。

このとき、送信時にファイルのハッシュ値を計算し、算出されたハッシュ値をファイル名と対にして送信することが好適である。これにより、送信時において最新のアセットデータに基づいて算出されたハッシュ値を確実に送信することができる。一方、ある程度のタイムラグが許容される場合、予めハッシュ値を算出し、メモリ２０にファイルとハッシュ値とを関連付けてメモリ２０に記憶しておき、送信時にはファイル名と対応するハッシュ値とを読み出して送信してもよい。この場合、サーバ２０２において送信毎にハッシュ値を算出する必要がなくなり、サーバ２０２の演算処理の負荷を低減することができる。

このように、次ページの表示に必要なアセットデータのファイルを送信する前に、ファイルの本体（内容）となるアセットデータは送信せず、ファイルに固有の識別情報であるファイル名と、そのバージョン情報であるハッシュ値が送信される。これが、プロキシ４２において取得される。

プロキシ４２は、受け取ったハッシュ値と同一のハッシュ値がネイティブキャッシュ３８に記憶されているかを判定する。この判定結果において、同一のハッシュ値が記憶されていれば、そのハッシュ値に関連付けられたファイル名を有するファイルについては既に最新のアセットデータがネイティブキャッシュ３８に記憶されていると判断できる。この場合、そのファイルのアセットデータはサーバ２０２から改めて取得する必要はない。そこで、プロキシ４２は、サーバ２０２から該当するファイルを取得することなく、ネイティブキャッシュ３８から該当ファイルのアセットデータを読み出し、読み出したアセットデータをウェブブラウザ４０へ受け渡す。ウェブブラウザ４０は、受け取ったアセットデータを用いて画像表示等の処理を行う。

なお、ハッシュ値の同一性を判定する際に、ファイル名の同一性も同時に判定してもよい。すなわち、プロキシ４２は、受け取ったファイル名とハッシュ値との組と同一のファイル名とハッシュ値との組がネイティブキャッシュ３８に記憶されているかを判定してよい。これにより、ファイル名で特定された同一のファイルのアセットデータについてハッシュ値を用いてデータの同一性を確認することができ、より確実に最新のアセットデータであるか否かを判定することができる。

図３の例は、ファイルfile3については同一のハッシュ値を有するファイルが既に登録されており、ファイルfile1, file2については同一のハッシュ値を有するファイルがなかった場合を示している。この場合、プロキシ４２は、ダウンローダ４４を用いて２つのファイルfile1, file2のみを取得するリクエストをサーバ２０２へ送信する。この例では、ＡＪＡＸ（Asynchronous JavaScript + XML）を用い、_get bundle file1, file2 のようなリクエストをサーバ２０２に送っている。

このリクエストに応じて、サーバ２０２は、該当するファイルfile1, file2をメモリ２０から読み出し、これらファイルを情報端末２００へ送信する。このときは、読み出したファイルに対してハッシュ値を計算して、ファイルと対応ハッシュ値をセットにして情報端末２００のプロキシ４２に提供する。すなわち、ファイルfile1, file2について、それぞれのハッシュ値hashと、ファイルの本体（内容）となるアセットデータbodyを含めてプロキシ４２に送信する。このとき、アセットデータbodyは、Ｂａｓｅ６４等に則ってエンコードされていてもよいし、エンコードされていないバイナリデータとしてもよい。

ここで、サーバ２０２のデータ更新部２２は、送信する段階でハッシュ値を計算して、その計算で得られたハッシュ値を送信することが好適である。これにより、送信されるハッシュ値はその時点の最新のアセットデータに対するハッシュ値となる。したがって、情報端末２００において、記憶されるハッシュ値が最新のバージョンのアセットデータに対応したものであることが担保される。

一方、ある程度のタイムラグが許容される場合、予めハッシュ値を算出し、メモリ２０にアセットデータとハッシュ値とを関連付けてメモリ２０に記憶しておき、送信時にはアセットデータを含むファイルと対応するハッシュ値とを読み出して送信してもよい。この場合、サーバ２０２において送信毎にハッシュ値を算出する必要がなくなり、サーバ２０２の演算処理の負荷を低減することができる。

プロキシ４２は、ファイル名、ファイル本体、ハッシュ値のうち少なくともファイル本体をウェブブラウザ４０へ転送する。このとき、プロキシ４２において、受信したアセットデータのコンテンツ変換等の処理を行ってもよい。例えば、ウェブブラウザ４０でサポートされているデータ形式等に変換する処理を行ってもよい。プロキシ４２は、ネイティブ部分によって実現されているので、情報端末２００の記憶部３６の容量、表示部３４の画面の解像度、情報端末２００の処理部３０の処理速度や利用できるデータ形式等の情報を情報端末２００から得ることが容易であり、これらの情報に基づいて情報端末２００毎に応じた処理を適用できる利点がある。

ウェブブラウザ４０は、受け取ったアセットデータを用いて画像表示等の処理を行う。また、ウェブブラウザ４０は、必要に応じて受け取ったアセットデータをブラウザキャッシュ４０ａに記憶（キャッシング）させる。

また、プロキシ４２は、ファイル名、ファイル本体、ハッシュ値をネイティブキャッシュ３８に記憶させる。このような処理を行い、プロキシ４２は、ネイティブキャッシュ３８の記憶完了を受け、サーバ２０２に受け取り通知を送信する。

このように、ユーザが情報端末２００を使用してゲームについての一定の操作を行う都度、情報端末２００で実行されるアプリケーションに応じてプロキシ４２（ダウンローダ４４）を用いてウェブブラウザ４０で使用されるアセットデータをサーバ２０２から取得することができる。

このとき、サーバ２０２からページの表示に必要なファイルのデータがそのまま送られて来るのではなく、ファイル名とそのハッシュ値がまず送られてくる。そこで、そのハッシュ値を利用して、当該ファイル（ファイル本体）がネイティブキャッシュ３８に記憶されているものかを判定し、記憶されている場合にはサーバ２０２に、ファイル本体の送信を要求しない。これによって、通信するデータ量を大幅に削減することができ、通信の効率を高めることができる。したがって、ネットワーク２０４の通信容量が十分でない場合であっても必要なデータのみを通信するようにすることができる。

また、ファイルの本体であるアセットデータ自体はプロキシ４２からアクセスされるネイティブキャッシュ３８に記憶することで、ブラウザキャッシュ４０ａのみを用いる場合に比して、データ容量を気にせずにファイルをキャッシュすることができる。一般的に、ウェブブラウザ４０からアクセス可能なブラウザキャッシュ４０ａは容量が小さく、アセットデータ、特に画像データやトゥルータイプフォント（ｔｔｆ）等の容量の大きなアセットデータのキャッシングには適していない。一方、ネイティブキャッシュ３８は、ネイティブアプリケーションによって実現されるプロキシ４２からアクセス可能であり、情報端末２００の記憶部３６の容量等に応じて比較的自由に容量を設定できるので、画像データやトゥルータイプフォント（ｔｔｆ）等の容量の大きなアセットデータのキャッシングには適している。

また、ウェブブラウザ４０からみれば、従来のようにサーバ２０２にアクセスするのと同様にプロキシ４２にアクセスすることによってアセットデータを取得することができる。プロキシ４２では、ネイティブキャッシュ３８のアクセスが許容され、ネイティブキャッシュ３８に記憶されたデータについて破損がないか等のチェックをウェブブラウザ４０から独立して実行すること等が可能であり、その他の利用も可能となる。

さらに、アプリケーションにプロキシ４２及びダウンローダ４４の機能を実現するネイティブ部分実行部を組み込むことによって、アプリケーションによる処理が終了した時点でプロキシ４２及びダウンローダ４４の機能も終了させることができる。これにより、ゲーム等の処理を終了させた時点でプロキシ４２やダウンローダ４４の処理も終了させることができ、情報端末２００のリソースを開放して他のアプリケーションでの利用を可能としたり、情報端末２００のバッテリの消耗を低減させたりすることができる。

なお、本実施の形態では、１ページの表示毎にアセットデータを要求する例について説明したが、これに限定されるものでなく、複数のページの表示に必要なアセットデータを一度に纏めて取得してもよい。

また、情報端末２００からのアクセス時において、それがそのゲームについての初回のアクセスであることを判定する手段を有すれば、その最初の応答では、送信すべきデータをＪＳＯＮ（JavaScript Object Notation）化してハッシュ値とデータを一度に転送してもよい。

また、サーバ２０２において、ハッシュ値を算出中にクエリがあると、サーバ２０２は、古いハッシュ値を返す場合があることも想定される。たとえば、ファイルのバージョンについて、ファイルシステムに依存しないフィンガープリントを用いているならば、
（１）準備用ディレクトリーツリーに新規ファイルを置く
（２）追加ファイルのハッシュ値を算出する
（３）ハッシュ値が算出できたところで、リリース用ディレクトリーツリーに置く
こととしてもよい。

また、複数ファイルを不可分に更新する場合への対応として上記のような対応をすることも可能である。

さらに、上記処理の中で、ブラウザキャッシュ４０ａに記憶するデータと、ネイティブキャッシュ３８に記憶するデータを最適化してもよい。

＜変形例＞
上記実施の形態では、情報端末２００はネットワーク２０４を介してサーバ２０２から情報を直接受信する態様としたが、これに限定されるものではない。本変形例では、情報端末２００は、コンテンツ・デリバリ・ネットワーク（ＣＤＮ）２０６を介してサーバ２０２から情報を受信する。ＣＤＮ２０６は、コンテンツ配信などを行うサイト運営側がエンドユーザーに対して効率よく安定して提供するネットワークであり、アクセス集中等によるサーバ２０２の負担を軽減することを可能とする。

ＣＤＮ２０６は、サーバ２０２のアセットデータと同期をとっているサーバ（以下、キャッシュサーバ）を複数台接続し、情報端末２００からのアクセスをキャッシュサーバに振り分ける構成とされる。これにより、サーバ２０２へのアクセスを分散させることができる。ＣＤＮ２０６で構成されたサイトへアクセスする場合、情報端末２００は初めにサーバ２０２にアクセスする。しかしながら、そこでデータのやり取りは行われず、サーバ２０２が情報端末２００から最も近くにあるＣＤＮ２０６のキャッシュサーバにアクセスを振り分ける。情報端末２００からのこれ以降のアクセスは、振り分けられたキャッシュサーバに対して行われるように設定され、データの要求に対するレスポンスも良くなり、サーバ２０２の負荷も軽減される。

＜実施形態の効果＞
このように、本実施形態では、以下のような効果が得られる。
・ネイティブキャッシュ３８においてファイルの本体であるアセットデータを記憶できるため、ブラウザキャッシュ４０ａの容量が小さくても問題が少ない。
・ブラウザキャッシュ４０ａはウェブブラウザ４０により利用されるものであり、ウェブブラウザ４０の外にある処理部３０などによっては制御が難しい。本実施形態では、ネイティブ部分実行部ではネイティブキャッシュ３８に記憶されているアセットデータを用いることができるので、アプリケーションからブラウザキャッシュ４０ａに記憶されているデータを扱う必要がなくなり、そのような問題は生じない。ウェブブラウザ４０からはプロキシ４２を介してネイティブキャッシュ３８に記憶されているデータを用いることができるので効率的な処理が行え、サーバ２０２との間で無駄な通信が発生することを防止できる。
・ゲーム等のアプリケーション起動時は、アプリのダウンロードだけを必要とし、大きな容量のデータのダウンロードなど特別な処理を必要とせず、起動時間を短縮できる。
・アプリケーション起動中でも、アセットデータなどのアップデートが可能であり、ユーザが必要とする時点での最新データを供給できる。
・アプリケーションによる処理を終了させた時点でプロキシ４２やダウンローダ４４の処理も終了させることができ、情報端末２００のリソースを開放して他のアプリケーションでの利用を可能としたり、情報端末２００のバッテリの消耗を低減させたりすることができる。

１０ ウェブブラウザ、１０ａ ダウンローダ、１０ｂ ブラウザキャッシュ、１２ ネイティブ、１２ａ ストレージ、２０ メモリ、２２ データ更新部、３０ 処理部、３２ 入力部、３４ 表示部、３６ 記憶部、３８ ネイティブキャッシュ、４０ ウェブブラウザ、４０ａ ブラウザキャッシュ、４２ プロキシ、４４ ダウンローダ、１００ 携帯端末、１０２ サーバ、１０４ ネットワーク、２００ 情報端末、２０２ サーバ、２０４ ネットワーク。

Claims (7)

1. 内蔵された処理部が実行するネイティブ部分実行部と、
   ネットワークを介して接続されたサーバから受けた情報の表示処理を行うウェブブラウザと、
   が組み合わされたアプリケーションを実行する情報端末であって、
   前記ネイティブ部分実行部を実行することによって、前記ネットワークを介して前記サーバにアクセスして通信を行うプロキシとして機能し、
   前記ウェブブラウザを実行することによって、前記プロキシを介して前記サーバからダウンロード情報を取得して、前記ダウンロード情報を出力するブラウザとして機能する
   ことを特徴とする情報端末。
2. 請求項１に記載の情報端末であって、
   前記プロキシを介して前記サーバから受信した前記ダウンロード情報を記憶する端末記憶部を備えることを特徴とする情報端末。
3. 請求項２に記載の情報端末であって、
   前記ダウンロード情報は、アセットデータ、アセットデータの識別情報及びアセットデータのバージョン情報を含み、
   前記プロキシは、前記ウェブブラウザからアセットデータの要求を受けると、アセットデータを前記サーバから受信する前に、受信対象となるアセットデータの識別情報及び当該アセットデータに対するバージョン情報とを前記サーバから受信し、
   受信したバージョン情報が前記端末記憶部に記憶されているかを判別し、
   受信したバージョン情報が前記端末記憶部に記憶されていないときに、当該バージョン情報に対応するアセットデータの送信を前記サーバに要求し、
   受信したバージョン情報が前記端末記憶部に記憶されているときに、当該バージョン情報に対応するアセットデータの送信を前記サーバに要求しない、
   ことを特徴とする情報端末。
4. 請求項２又３に記載の情報端末であって、
   前記端末記憶部に、前記ダウンロード情報をバイナリ情報として記憶することを特徴とする情報端末。
5. 請求項１〜４のいずれか１項に記載の情報端末であって、
   前記ブラウザは、ｈｔｔｐにより前記プロキシから前記ダウンロード情報を取得することを特徴とする情報端末。
6. コンピュータ端末内の処理部が実行するネイティブ部分実行部と、
   前記コンピュータ端末とネットワークを介して接続されたサーバから受けた情報の表示処理を行うウェブブラウザと、
   が組み合わされたアプリケーションを含むデータ処理プログラムであって、
   前記コンピュータ端末を、
   前記ネイティブ部分実行部を実行することによって、前記ネットワークを介して前記サーバにアクセスして通信を行うプロキシとして機能させ、
   前記ウェブブラウザを実行することによって、前記プロキシを介して前記サーバからダウンロード情報を取得して、前記ダウンロード情報を出力するブラウザとして機能させる
   ことを特徴とするデータ処理プログラム。
7. 請求項６に記載のデータ処理プログラムであって、
   前記ダウンロード情報は、アセットデータ、アセットデータの識別情報及びアセットデータのバージョン情報を含み、
   前記プロキシは、前記ウェブブラウザからアセットデータの要求を受けると、アセットデータを前記サーバから受信する前に、受信対象となるアセットデータの識別情報及び当該アセットデータに対するバージョン情報とを前記サーバから受信し、
   受信したバージョン情報が端末記憶部に記憶されているかを判別し、
   受信したバージョン情報が前記端末記憶部に記憶されていないときに、当該バージョン情報に対応するアセットデータの送信を前記サーバに要求し、
   受信したバージョン情報が前記端末記憶部に記憶されているときに、当該バージョン情報に対応するアセットデータの送信を前記サーバに要求しない、
   ことを特徴とするデータ処理プログラム。

Images