JP5736056B2 - 情報提供装置、情報提供方法及びプログラム - Google Patents

Description

本発明は、例えばインターネット等のコンピュータネットワークを経由して各種情報を提供するのに好適な情報提供システム、情報提供装置、情報提供方法及び記憶媒体に関する。

従来、ウェブアプリケーションの通信方法では、クライアント端末からサーバにリクエストを送信することで、サーバからウェブページをレスポンスとして受け取り、ウェブページ間での画面遷移を行なっていた。また、ウェブアプリケーションの通信方法では、Ａｊａｘ（エイ・ジャックス：Ａｓｙｎｃｈｒｏｎｏｕｓ ＪａｖａＳｃｒｉｐｔ（登録商標）＋ＸＭＬ）により、画面遷移を伴わない動的なウェブアプリケーションをクライアント側に提供することで、例えば、ウェブ検索においては入力確定後に行なっていた検索を、ユーザがキー入力をする間にバックグラウンドで処理することにより、リアルタイムに検索結果を表示することが可能となっている。また、これらのＡｊａｘの技術はウェブページのみで動作するので、インストール型のソフトウェアに見られるプラグイン機能を必要とせず、既存の技術と組み合わせることができる。

特に、Ａｊａｘによるウェブプログラミングは、この従来のページ遷移のみに頼ったウェブブラウザの使い勝手の悪さに対する不満の解消と、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、ＤＯＭ（Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）などのウェブ関連技術の標準化（通称、ウェブ標準）に伴って、高い機能をクライアント側に提供することができるようになった。

（ＸＭＬに関して）
ＸＭＬとは、個別の目的に応じたマークアップ言語作成のため、汎用的に使うことができる仕様、および仕様により策定される言語の名称である。ＸＭＬの仕様は、Ｗ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）により策定・勧告されており、広く普及している技術である。

（ＤＯＭに関して）
ＤＯＭとは、Ｗ３Ｃから勧告されているＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書やＸＭＬ文書をアプリケーションから利用するためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）である。ＸＭＬを読み込む別のＡＰＩであるＳＡＸ（Ｓｉｍｐｌｅ ＡＰＩ ｆｏｒ ＸＭＬ）と異なり、ＸＭＬデータをツリー構造として扱うことができる。ＤＯＭを実装するためのＸＭＬパーサは各メーカからサポートされている。

（ネイティブアプリケーションとウェブアプリケーション）
さらに、ソーシャルゲーム業界では、複数のユーザが参加可能なソーシャルアプリケーションを用いたゲームが普及してきている。この種のソーシャルアプリケーションは、クライアント端末にダウンロードされ、当該クライアント端末にインストールされて利用されるネイティブアプリケーションと、ウェブサーバ上で動作し、クライアント端末のウェブブラウザに利用されるウェブアプリケーションとに大別できる。

ネイティブアプリケーションは、スマートフォンのｉＰｈｏｎｅ（登録商標）端末やＡｎｄｒｏｉｄ（登録商標）端末といった端末のＯＳに依存するアプリケーションである。例えば、サーバ装置は、Ｏｂｊｅｃｔｉｖｅ−Ｃ言語を搭載したｉＰｈｏｎｅアプリケーション、またはＪａｖａ（登録商標）を搭載したＡｎｄｒｏｉｄアプリケーション等のネイティブアプリケーションをプラットフォームから各クライアント端末に配信している。ユーザは、プラットフォームからクライアント端末に配信されたネイティブアプリケーション（例えばＲＰＧ（Ｒｏｌｅ Ｐｌａｙｉｎｇ Ｇａｍｅ）や、バトル、恋愛等のゲームを含む）を楽しんでいる。

ただし、ネイティブアプリケーションは、現状スマートフォンの主要なＯＳが２系統に分かれるため、ｉＰｈｏｎｅ端末に対応したプログラミング言語「Ｏｂｊｅｃｔｉｖｅ−Ｃ」と、Ａｎｄｒｏｉｄ端末に対応したプログラミング言語「Ｊａｖａ」との２種類で開発する必要がある。このため、ネイティブアプリケーションは、クライアント端末のプラットフォーム特有の言語を使ったコーディング処理を介した後に、公式のマーケットプレイスを通して公開する必要がある。

一方、ウェブアプリケーションは、両プラットフォームに向けてＨＴＭＬ５（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ ５）、ＪａｖａＳｃｒｉｐｔ（登録商標）、ＣＳＳ３（Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔｓ ３）等の言語をベースにしたクロス開発が可能であり、公開に当たって公式のマーケットプレイスを通す必要がない。また、ウェブアプリケーションは、クライアント端末のＯＳに依存しない。

ここで、ＪａｖａＳｃｒｉｐｔとは、オブジェクト指向スクリプト言語である。主にウェブブラウザなどのクライアントサイドで実装され、動的なウェブサイトの構築や、ＲＩＡ（Ｒｉｃｈ Ｉｎｔｅｒｎｅｔ Ａｐｐｌｉｃａｔｉｏｎ）などの高度なユーザインタフェースの開発に用いられる。ＪａｖａＳｃｒｉｐｔはプロトタイプベースのオブジェクト指向プログラミング言語である。

上記ＪａｖａＳｃｒｉｐｔは、多くの場合、Ｃ言語に似た手続き型言語のようなスタイルで記述されるが、第一級関数をサポートしている（関数を第一級オブジェクトとして扱える）など、関数型言語の性質も持ち合わせるように設計されている。ＪａｖａＳｃｒｉｐｔは、そのような柔軟な設計から、いくつかのアプリケーションではマクロ言語としても採用されている。また、マークアップ言語（例：ＨＴＭＬ、ＰＨＰ（Ｈｙｐｅｒｔｅｘｔ Ｐｒｅｐｒｏｃｅｓｓｏｒ））での通信方式は、リクエスト＆レスポンス方式を採用している。

一方で、上述したネイティブアプリケーションを開発するために、ソフトウェア開発キット（以下「ＳＤＫ（Ｓｏｆｔｗａｒｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ）」と称する）がソフトウェア開発者に提供されている。このＳＤＫは、あるテクノロジー（プログラミング言語やＡＰＩなど）を利用してソフトウェアを開発する際に必要なツールのセットである。特に、ソフトウェア開発者は、特定のソフトウェアパッケージやソフトウェアフレームワーク、ハードウェアプラットホーム、コンピュータシステム、ゲーム機、またはＯＳなどのためのアプリケーションソフトウェアを作成する際に、上記ＳＤＫを使用する。

このＳＤＫは、情報機器やＯＳなどのメーカが、自社製品向けのソフトウェアの開発を促すべく用意するツールキットであり、開発者向けに無料で配布されることが多い。（例えば、非特許文献１）

"http://microsoft.com/en-us/download/details.aspx?id=8442"（平成２４年 ６月 ７日)

しかしながら、従来の技術にあっては、下記のような課題があった。
＜ＸＭＬの課題＞
（１）ＸＭＬ文書で記述されたマークアップ言語は、ＸＭＬ文書に記述されたヘッダ情報、コンテンツ情報、フッタ情報を全て読み込んでからレンダリング処理を行なうことから、レンダリング処理までの動作速度が遅かったり、メモリの使用量が大きくなる欠点もあった。

（２）Ａｊａｘの基本技術を用いて画面遷移にかかるＸＭＬ文書をサーバに格納した場合、リッチなＵＩ（ユーザインターフェース）をクライアント側に提供したいと考えたとき、サーバとクライアント側で膨大な通信量が発生してしまい、結果的にクライアント側にリッチなＵＩを提供することができなかった。 ＜ＤＯＭの課題＞
（３）また、マークアップ言語で記述されたＸＭＬ文書でなく、ＤＯＭで実装しようとする場合には、ＤＯＭを実装したＸＭＬパーサが各メーカから提供されているため、ＤＯＭを使用するための条件として各メーカに依存してしまうという欠点があった。

＜ウェブアプリケーションとネイティブアプリケーションの課題＞
（４）従来のウェブアプリケーションでは、クライアントとサーバ間でその都度必要なプログラムファイルをダウンロードするため、どうしても表示までに要する時間が通信トラフィックに依存する、そのため、従来のウェブアプリケーションは、一般に多く普及している既存の携帯機器用のＯＳ、例えばｉＯＳ、Ａｎｄｒｏｉｄ等の上で動作するネイティブアプリケーションに比べて表示速度が劣るという欠点がある。

そこで、本発明は、上記のような実情に鑑みてなされたもので、その目的とするところは、マークアップ言語で記述されたウェブアプリケーションでも、既存のネイティブアプリケーションと同等の表示スピードを実現することが可能な情報提供システム、情報提供装置、情報提供方法及び記憶媒体を提供することにある。

本発明の一態様は、提供される情報を出力するためのディレクトリ構成及びファイル構成を少なくとも記述したファイルを上記ファイルの識別情報と共に記憶する記憶部を具備する情報提供装置において使用されるプログラムにおいて、上記プログラムは、上記情報提供装置に、予め設定された条件に従い、サーバ装置に対して上記ファイルの識別情報を付加して当該ファイルの更新を要求させ、上記要求に応じてサーバ装置から送られてくるファイルを受信させ、上記記憶部に記憶されたファイルの配列の数と、上記受信したファイルの配列の数とが一致しない場合に、上記記憶部に記憶されたファイルを上記受信したファイルに更新させる、プログラムである。

本発明によれば、クライアントとサーバ間のディレクトリ構成及びファイル構成を自動的に同期させるため、マークアップ言語等の言語で記述されたウェブアプリケーションでも、既存のネイティブアプリケーションと同等の表示スピードを実現することが可能となる。

図１は、一実施形態に係る情報提供システムの使用環境を説明する図である。 図２は、同実施形態に係るリソース用サーバ装置の構成を示すブロック図である。 図３は、同実施形態に係るカタログファイル更新プログラムの機能構成を示す図である。 図４は、同実施形態に係るクライアント／サーバ間でのカタログファイル更新処理の内容を示すフローチャートである。 図５は、同実施形態に係るクライアント端末でのコンテンツデータの同期処理の内容を示すサブルーチンのフローチャートである。 図６は、同実施形態に係るカタログファイルの具体的な構成例を示す図である。 図７Ａは、同実施形態に係る新規受信のカタログファイルの具体的な構成例を示す図である。 図７Ｂは、同実施形態に係る受信前に記憶していたカタログファイルの具体的な構成例を示す図である。 図８Ａは、同実施形態に係る新規受信のカタログファイルの具体的な構成例を示す図である。 図８Ｂは、同実施形態に係る受信前に記憶していたカタログファイルの具体的な構成例を示す図である。 図９Ａは、同実施形態に係るカタログファイル更新時のクライアント側での表示画面の遷移状態を示す図である。 図９Ｂは、同実施形態に係るカタログファイル更新時のクライアント側での表示画面の遷移状態を示す図である。 図９Ｃは、同実施形態に係るカタログファイル更新時のクライアント側での表示画面の遷移状態を示す図である。 図９Ｄは、同実施形態に係るカタログファイル更新時のクライアント側での表示画面の遷移状態を示す図である。

以下、図面を参照して本発明の一実施形態に係る情報提供システムについて説明する。

図１は、同実施形態に係る情報提供システムが使用される環境を説明する図である。同図で、インターネットなどのネットワーク１に対して、リソース用サーバ装置２、ＡＰＩ用サーバ装置３が接続されると共に、本システムでユーザが使用するクライアント装置となるコンピュータ４及び携帯電話５がアクセスポイント（ＡＰ）６あるいは基地局７を介して接続される。

リソース用サーバ装置２及びＡＰＩ用サーバ装置３は、本実施形態に係る情報提供システムを実現するためのコンピュータであり、実際には１つのコンピュータで実現されても良い。

ここでは、リソース用サーバ装置２がコンピュータ４、携帯電話５との窓口となって処理を実行する一方で、ＡＰＩ用サーバ装置３側に、提供される情報を出力するためのディレクトリ構成及びファイル構成を記述したカタログファイル（Ｃａｔａｌｏｇ．ｆｉｌｅ）を格納したデータベース（ＤＢ）を設けるものとしている。また、後述でカタログファイルの詳細説明を行なうが、カタログファイルのデータ構成はＪＳＯＮ型の構成となっており、オブジェクトＯ、配列ＡＲ１〜ＡＲ３、プロパティＰで１つのカタログファイルが構成されている。

このようにリソース用サーバ装置２とＡＰＩ用サーバ装置３とで役割を分担して処理を実行することで、個々のサーバ装置の負担を低減できる。

また、リソース用サーバ装置２を複数台、例えば２台のリソース用サーバ装置２Ａ，２Ｂに分け、後述するカタログファイルの更新動作に関する処理を分担して実行するようにしても良い。こうすることで、窓口となるリソース用サーバ装置２の負担を分散して処理でき、さらに安定したシステム構成を構築できる。

またリソース用サーバ装置２及びＡＰＩ用サーバ装置３について、さらにその機能毎に、例えば、ウェブサーバ、処理サーバ、データベースサーバなどの複数のコンピュータで構成されてもよく、本発明の実施の形態においては、その構成は問わない。

一方、クライアント側のコンピュータ４は、一般的なデスクトップ型、あるいはノートブック型のパーソナルコンピュータの他、モバイルコンピュータ、ラップトップコンピュータ、タブレット型端末などを含む。

携帯電話５は、スマートフォン、フィーチャー・フォン（ｆｅａｔｕｒｅ ｐｈｏｎｅ）などを含み、例えば、Ａｎｄｒｏｉｄ、ｉＯＳなどのＯＳ上で動作する携帯電話である。

コンピュータ４及び携帯電話５それぞれの各ハードウェア回路の構成自体は、きわめて一般的で周知であるものとして、その記載及び説明を省略する。

図２は、上記リソース用サーバ装置２の構成を示すブロック図である。
同図に示す如くリソース用サーバ装置２は、バス１１にＣＰＵ１２、通信部１３、メモリ１４、入力部１５及び記憶装置１６を接続して構成される。

ＣＰＵ１２は、記憶装置１６に記憶したカタログファイル更新プログラム１６Ｂと協働してコンピュータ４、携帯電話５におけるカタログファイルの更新処理を行なう他、リソース用サーバ装置２全体の制御を司る。

通信部１３は、ネットワーク１を介したＡＰＩ用サーバ装置３、クライアントとなるコンピュータ４、携帯電話５などの外部装置との通信の制御を司る。

メモリ１４は、カタログファイル更新プログラム１６Ｂを実行する際に必要とされるワークエリアなどとして使用される。

入力部１５は、カタログファイル更新処理を行なう際に必要とされるデータなどを入力するためのインターフェイスであり、例えば、キーボード、タッチパネルなどを含む。

記憶装置１６は、カタログファイル更新に必要とされるプログラム、データを格納するためのものであり、例えば、ハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）、光ディスクドライブ、ＤＶＤ、ＭＯなどの大容量記憶装置である。

この記憶装置１６には、ＯＳ（オペレーティングシステム）１６Ａ、カタログファイル更新プログラム１６Ｂを含むプログラムや固定データ等が格納されている。

ＯＳ１６Ａは、リソース用サーバ装置２の基本的な機能を実現するためのプログラムである。

カタログファイル更新プログラム１６Ｂは、ＯＳ１６Ａ上で動作するアプリケーションプログラムであり、ＣＰＵ１２と協働し、コンピュータ４、携帯電話５が保持するカタログファイルを更新設定するものであって、主に以下の図４に示すフローチャートの処理を実現する。

図３は、上記カタログファイル更新プログラム１６Ｂの機能構成を示す図である。図示する如くカタログファイル更新プログラム１６Ｂは、オーセンティコード部Ｂ１、ＨＴＭＬ部Ｂ２、ＣＤＮ（Ｃｏｎｔｅｎｔｓ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ）部Ｂ３、及びＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）サーバ部Ｂ４を有する。

オーセンティコード部Ｂ１は、上記コンピュータ４または携帯電話５からのカタログファイルの更新要求を受け付けるとともに、その時点でコンピュータ４または携帯電話５等が有するカタログファイルの検証を行なう。

ＨＴＭＬ部Ｂ２は、ＳＮＳのサイトでカタログファイルの更新要求を含んだインデックスページ（Ｉｎｄｅｘ．ｈｔｍｌ／Ｉｎｄｅｘ．ｈｔｍ）を提供する。

ＣＤＮ部Ｂ３は、ＪａｖａＳｃｒｉｐｔ（ＪＳ）技術及びＣＳＳ技術により上記ＡＰＩ用サーバ装置３から必要なコンテンツを引き出す。後述するが、このＣＤＮ部Ｂ３の内容、具体的にはディレクトリ構成を含めたコンテンツの格納状態が、クライアント側の機器でも同期される。

ＳＮＳサーバ部Ｂ４は、ＡＰＩ技術を用い、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（以下「ＪＳＯＮ」と称する）で記述されたカタログファイルの更新を実行する。

なおここで上記ＪＳＯＮとＸＨＲ（ＸＭＬ Ｈｔｔｐ Ｒｅｑｕｅｓｔ）の技術についても説明しておく。
上記ＪＳＯＮは、ＪａｖａＳｃｒｉｐｔにおけるオブジェクトの表記法をベースとした軽量なデータ記述言語である。ＪａｖａＳｃｒｉｐｔという名前がついているものの、ＪＳＯＮはＪａｖａＳｃｒｉｐｔ専用のデータ形式ではなく、様々なソフトウェアやプログラミング言語間におけるデータの受け渡しに使えるように設計されている。

またＸＨＲは、ＪａｖａＳｃｒｉｐｔなどのウェブブラウザ搭載のスクリプト言語でサーバとのＨＴＴＰ通信を行うための、組み込みオブジェクト（ＡＰＩ）である。すでに読み込んだページからさらにＨＴＴＰリクエストを発することができ、ページ遷移することなしにデータを送受信できるＡｊａｘの基幹技術である。

次に上記実施形態の動作について説明する。
図４は、クライアント側のコンピュータ４または携帯電話５が、リソース用サーバ装置２の提供する所定のＳＮＳのサイトにアクセスしている状態で、コンピュータ４または携帯電話５とリソース用サーバ装置２との間で実行されるカタログファイルの更新処理の内容を示す。クライアント側のコンピュータ４または携帯電話５においては、機器内のＣＰＵがプログラム用メモリに記憶されている動作プログラムに従って下記の動作を実行する。リソース用サーバ装置２においては、ＣＰＵ１２が記憶装置１６のカタログファイル更新プログラム１６Ｂに基づいて下記の動作を実行する。

クライアント側の機器においては、まず過去のカタログファイルが端末内に存在するか否かを判断する（ステップＣ０１）。
ここで過去のカタログファイルが存在しないと判断した場合、クライアント側の機器では、ＣＰＵがカタログファイルのデータを新規に要求する信号を、ネットワーク１を介してリソース用サーバ装置２に送信する（ステップＣ０２）。

上記ステップＣ０１で過去のカタログファイルが存在すると判断した場合、ＣＰＵは次いでユーザによる手動の更新要求操作がなされたか否かを判断する（ステップＣ０３）。

図９Ａ〜図９Ｄは、ウェブアプリケーションとしてゲームソフトを選択する場合の携帯電話５での表示画面の遷移状態を示す図である。図９Ａは、ＳＮＳのゲームメニュー画面を例示している。このとき、「トップ」「カテゴリ」「新着」「検索」のボタンからなるメニューバーをゆっくり手指先端で下側にスライド操作することで、図示する如くカタログファイルを更新させるためのプルダウンメニューＰＤが表示されるものとする。ここでプルダウンメニューＰＤでは、一定量の下方向へのスライド操作を指示するべく、「引き下げて更新」のガイドメッセージを表示するとともに、前回のカタログファイルの更新日時の情報を表示する。

図９Ｂは、上記一定量の下方向へのスライド操作が実行され、更新を開始しようとしている状態を示す。ここでは同プルダウンメニューＰＤにより「指を離して更新」のガイドメッセージが表示されている。

上記のような手動による更新要求がなされた場合、ＣＰＵは上記ステップＣ０３で手動の更新要求操作がなされたものと判断し、その時点で記憶している、バージョン（ｖｅｒ．）情報を含むカタログファイルのデータを更新要求の信号に付加し、ネットワーク１を介してリソース用サーバ装置２に送信する（ステップＣ０５）。

また、上記ステップＣ０３で手動による更新要求がなされていないと判断した場合、クライアント機器のＣＰＵはさらに、アクセス状態で予め設定されたカタログファイルの更新タイミング、例えば５分が経過したか否かにより、自動で更新を実行するタイミングとなったか否かを判断する（ステップＣ０４）。

ここで自動で更新を実行するタイミングとはなっていないと判断した場合、クライアント機器のＣＰＵは、再び上記ステップＣ０１からの処理に戻る。

また上記ステップＣ０４で自動で更新を実行するタイミングとなったと判断した場合、クライアント機器のＣＰＵは、その時点で記憶している、バージョン情報を含むカタログファイルのデータを更新要求の信号に付加し、ネットワーク１を介してリソース用サーバ装置２に送信する（ステップＣ０５）。

図６は、上記ステップＣ０５において、クライアント側の機器、例えば携帯電話５が保持し、リソース用サーバ装置２に送信するカタログファイルのデータ構成を例示する図である。カタログファイルはテキスト情報で構成され、ファイルの先頭に位置するオブジェクトＯ、同末尾に位置するプロパティＰに挟まれて、少なくとも１つ（ここでは３つ）の配列ＡＲ１〜ＡＲ３が配置される。

配列ＡＲ１〜ＡＲ３内にはバージョン（ｖｅｒｓｉｏｎ）情報、コミット（ｃｏｍｍｉｔ）情報、及びパス（ｐａｔｈ）情報が含まれる。

配列ＡＲ１〜ＡＲ３内のバージョン情報は、対応するパス情報が示すファイル（以下「コンテンツファイル」と称する）のバージョンを示す。コミット情報は、バージョンを管理するリソース用サーバ装置２での管理番号である。

また、プロパティＰ内にもバージョン情報（例えば「１３３７３２９２７１」）があり、このバージョン情報がカタログファイル自体のバージョンを示す。

リソース用サーバ装置２側では、常時クライアント側からカタログファイルの送信要求の信号が送られてくるのを待機している（ステップＳ０１）。

クライアント側の機器からカタログファイルの送信要求の信号を受信したと判断すると、リソース用サーバ装置２のＣＰＵ１２は、自機が保持するカタログファイルのバージョン情報と、送信要求の信号に付加されてきたカタログファイルのバージョン情報とをチェックし（ステップＳ０２）、それら２つのバージョン情報が一致するか否かにより、カタログファイルの更新が必要であるか否かを判断する（ステップＳ０３）。

ここでクライアント側から送信されてきたカタログファイルのバージョン情報が自機の保持するカタログファイルのバージョン情報と一致した場合、更新の必要はないと判断し、ＣＰＵ１２はそのまま上記ステップＳ０１からの処理に戻り、再びクライアント側からカタログファイルが送信されてくるのを待機する。

なお上記ステップＣ０２の処理により、クライアント側の機器からカタログファイルの新規の送信要求の信号が受信された場合、当然ながらカタログファイルのバージョン情報は付加されていないため、リソース用サーバ装置２のＣＰＵ１２は両バージョン情報が不一致と判断する。

このように上記ステップＳ０３でクライアント側から送信してきたカタログファイルのバージョン情報が自機の保持するカタログファイルのバージョン情報と一致しないと判断した場合、ＣＰＵ１２はカタログファイルの更新の必要があると判断し、データベースであるＡＰＩ用サーバ装置３との通信によりクライアント機器用の最新のカタログファイルを生成して送信し（ステップＳ０４）、以上で一連の更新処理を終了して、再び上記ステップＳ０１からの処理に戻る。

クライアント側の機器では、ＣＰＵが上記ステップＣ０２またはステップＣ０５での送信要求の信号を送信した後に一定時間、例えば１分が経過したか否かを判断する（ステップＣ０６）。

ここで一定時間が経過したと判断した場合、ＣＰＵは送信要求に対するリソース用サーバ装置２側からの応答がなかったものとして、送信要求の信号を再度送信するべく、上記ステップＣ０１からの処理に戻る。

また上記ステップＣ０６で一定時間が経過していないと判断した場合、ＣＰＵはさらにリソース用サーバ装置２側から新しいバージョンのカタログファイルを受信したか否かを判断する（ステップＣ０７）。

ここで新しいバージョンのカタログファイルを受信したと判断した場合、ＣＰＵは受信したカタログファイルを一旦保存する（ステップＣ０８）。
その上でＣＰＵは、保存したカタログファイルに基づき、クライアント側の機器に保持しているコンテンツデータと上記リソース用サーバ装置２のＣＤＮ部Ｂ３に記憶されているコンテンツデータとの同期処理を実行する（ステップＣ０９）。

図５は、上記ステップＣ０９でのコンテンツデータの同期処理の内容を示すサブルーチンのフローチャートである。
その処理当初にクライアント側の機器では、ＣＰＵが上記カタログファイルをリソース用サーバ装置２から受信する前に記憶していたカタログファイル中の配列ＡＲの数ｎと、あらたに受信したカタログファイル中の配列ＡＲの数Ｍとをチェックする（ステップＣ２１）。

ここでＣＰＵは、あらたなカタログファイルの配列ＡＲの数Ｍが、それまでのカタログファイルの配列ＡＲの数ｎと一致するか否かにより、自端末内でカタログファイルの更新が必要であるか否かを判断する（ステップＣ２２）。

図７Ａ及び図７Ｂは、あらたなカタログファイル中の配列ＡＲの数Ｍが「４」、それまでのカタログファイル中の配列ＡＲの数ｎが「４」で、等しい場合を例示している。

このように新旧のテンプレートＴＰの数Ｍとｎとが一致した場合、ＣＰＵは更新の必要はないと判断し、そのまま上記図４のメインルーチンに戻り、クライアント側のサイト画面の再構築処理を実行した上で（ステップＣ１０）、再び上記ステップＣ０１からの処理に戻る。

また図８Ａ及び図８Ｂは、あらたなカタログファイル中の配列ＡＲの数Ｍが「４」、それまでのカタログファイル中の配列ＡＲの数ｎが「３」で、「Ｍ＞ｎ」となる場合を例示している。
このような場合、クライアント側の機器のＣＰＵでは、あらたに受信したカタログファイルに基づき、クライアント側の機器に保持しているコンテンツデータとリソース用サーバ装置２のＣＤＮ部Ｂ３に記憶されているコンテンツデータとの同期処理を実行する（ステップＣ２３）。そして、同期処理による更新が終了したと判断した時点で（ステップＣ２４）、あらためてその時点で最新のカタログファイルとしてセットして（ステップＣ２５）、以上で一連のサブルーチンの処理を終了して、図４のメインルーチンに復帰する。

こうして新規のカタログファイルをセットした場合、図４のメインルーチンでクライアント機器側のＣＰＵは、新規のカタログファイル中に記述されているコンテンツまでのパス情報を用いて記憶しているコンテンツを読出し、ディスプレイで表示するサイト画面の再構築処理を実行した上で（ステップＣ１０）、再び上記ステップＣ０１からの処理に戻る。

上記のように、提供される情報を出力するためのファイル構成を記述したカタログファイルを常に最新の状態に維持しながら保持しておくため、例えばＰＨＰやＨＴＭＬ等の言語で記述されたウェブアプリケーションを実行する場合でも、表示画面の遷移などで処理時間を大幅に短縮して、ユーザにストレスを与えることのない利用環境を実現できる。

図９Ｃは、上記図９Ｂの状態からカタログファイルの更新が実行され、画面が更新された状態を示す。このようなゲームソフトの総合メニューからある１つの分野、例えば「ＲＰＧ」を選択した場合、本実施形態であればクライアント側からサーバ側へ画面表示の要求を送信し、それに応答してサーバ側から表示の配列を指示する、数ＫＢ乃至数十ＫＢ程度のデータのみを返すことで、即時、図９Ｃに示す表示画面から図９Ｄに示す表示画面に遷移することができる。

なお、上記ステップＣ０７で新しいバージョンのカタログファイルを受信しなかったと判断した場合、ＣＰＵはその時点でセットされているカタログファイルを参照し、当該カタログファイルでクライアント側の機器に保持しているコンテンツデータと上記リソース用サーバ装置２のＣＤＮ部Ｂ３に記憶されているコンテンツデータとの同期処理を実行する（ステップＣ１１）。

そして、上記同期処理に基づいてカタログファイル中に記述されているコンテンツまでのパス情報を用いて記憶しているコンテンツを読出し、ディスプレイで表示するサイト画面の再構築処理を実行した上で（ステップＣ１２）、再び上記ステップＣ０１からの処理に戻る。

上記したような本実施形態で説明したカタログファイルの更新処理を実行せず、ウェブアプリケーション上でその都度表示に要する全データの送受を行なうものとした場合、そのデータ容量は数百ＫＢ程度となり、上記図９Ｃに示した表示画面から上記図９Ｄに示した表示画面に移行する間、例えば数秒単位で画面全面が一時的に全く何も表示しない真っ白な状態になることが容易に考えられる。

したがって、ユーザによってはいらだちや不安を生じるなど、なんらかのストレスを与える可能性が高く、ウェブアプリケーションとしての商品力、訴求力が著しく低下することにもなりかねない。

その点で、本実施形態のようにユーザが認識しない状態で常時定期的に、あるいはユーザが簡易な操作で任意に手動でファイル構成を記述したカタログファイルの更新処理を実行して、クライアント側とリソース用サーバ装置２側とで同期をとるものとすれば、ユーザはストレスフリーでウェブアプリケーションを利用できる。

上述した如くカタログファイルは、クライアント側で保存されているコンテンツまでのパス情報、すなわち記憶しているコンテンツがどのディレクトリ構成の位置にあるかを示す場所を記述しているのみである。

したがって、クライアント側に最新のカタログファイルがなかった場合には、リソース用サーバ装置２から最新のカタログファイルをダウンロードし、コンテンツデータを同期させることにより、この最新のカタログファイルを参照することで、クライアント側に保存しているコンテンツデータと照らし合わせて表示を行なうことができる。

つまり、クライアント側のデータとレンダリング処理されたリソース用サーバ装置２側のＣＤＮ部Ｂ３上のデータとを同期できるので、レンダリング処理の時間を短縮でき、クライアント側の端末に画面を高速で表示させることができる。

以上詳述した如く本実施形態によれば、クライアントとサーバ間のディレクトリ構成及びファイル構成を同期させるため、例えばＰＨＰやＨＴＭＬ等のマークアップ言語で記述されたウェブアプリケーションでも、既存のネイティブアプリケーションと同等の表示スピードを実現することが可能となる。

なお上記実施形態では、カタログファイルのバージョン情報に応じて更新設定の判断を行なうものとして説明したが、例えばファイルのバージョン情報ではなく、タイムスタンプなどの更新日時を示す情報によってクライアントとサーバとの間のファイルの同期を行なうものとしてもよい。たとえば、期間限定のイベント情報をＳＮＳサイト内に表示する際、期間限定のイベント情報をカタログファイルの更新情報から省くようにすれば、期限が過ぎてしまったＳＮＳサイト内の情報をクライアント側に表示することがなく、クライアントとサーバとの間で不必要な更新作業を省くこともできる。

また上記実施形態では、ウェブアプリケーションとしてゲームソフトを選択する場合について説明したが、本発明はウェブアプリケーションの種類等を限定するものではなく、各種ウェブアプリケーションに対応可能であることは勿論である。

その他、本発明は上述した実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、上述した実施形態で実行される機能は可能な限り適宜組み合わせて実施しても良い。上述した実施形態には種々の段階が含まれており、開示される複数の構成要件による適宜の組み合せにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、効果が得られるのであれば、この構成要件が削除された構成が発明として抽出され得る。

１…（インターネットなどの）ネットワーク、２，２Ａ，２Ｂ…リソース用サーバ装置、３…ＡＰＩ用サーバ装置、４…コンピュータ、５…携帯電話、６…アクセスポイント（ＡＰ）、７…基地局、１１…バス、１２…ＣＰＵ、１３…通信部、１４…メモリ、１５…入力部、１６…記憶装置、１６Ａ…ＯＳ、１６Ｂ…カタログファイル更新プログラム、ＡＲ，ＡＲ１〜ＡＲ３…配列、Ｂ１…オーセンティコード部、Ｂ２…ＨＴＭＬ部、Ｂ３…ＣＤＮ部、Ｂ４…ＳＮＳサーバ部、Ｏ…オブジェクト、Ｐ…プロパティ、ＰＤ…プルダウンメニュー。

Claims (4)

1. 提供される情報を出力するためのディレクトリ構成及びファイル構成を少なくとも記述したファイルを上記ファイルの識別情報と共に記憶する記憶部を具備する情報提供装置において使用されるプログラムにおいて、
   上記プログラムは、上記情報提供装置に、
   予め設定された条件に従い、サーバ装置に対して上記ファイルの識別情報を付加して当該ファイルの更新を要求させ、
   上記要求に応じてサーバ装置から送られてくるファイルを受信させ、
   上記記憶部に記憶されたファイルの配列の数と、上記受信したファイルの配列の数とが一致しない場合に、上記記憶部に記憶されたファイルを上記受信したファイルに更新させる、プログラム。
2. 上記ファイルは、オブジェクト、プロパティ、及び配列の各情報を含むＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）言語で記述されたデータであり、該配列の情報には、ファイルのバージョン情報または更新日時情報と、ファイルの格納先を示すパス情報とが少なくとも記述されていることを特徴とする請求項１記載のプログラム。
3. 提供される情報を出力するためのディレクトリ構成及びファイル構成を少なくとも記述したファイルを上記ファイルの識別情報と共に記憶する記憶部を具備する情報提供装置において使用される情報提供方法において、
   予め設定された条件に従い、サーバ装置に対して上記ファイルの識別情報を付加して当該ファイルの更新を要求し、
   上記要求に応じてサーバ装置から送られてくるファイルを受信し、
   上記記憶部に記憶されたファイルの配列の数と、上記受信したファイルの配列の数とが一致しない場合に、上記記憶部に記憶されたファイルを上記受信したファイルに更新する、
   情報提供方法。
4. 提供される情報を出力するためのディレクトリ構成及びファイル構成を少なくとも記述したファイルを上記ファイルの識別情報と共に記憶する記憶部と、
   予め設定された条件に従い、サーバ装置に対して上記ファイルの識別情報を付加して当該ファイルの更新を要求する手段と、
   上記要求に応じてサーバ装置から送られてくるファイルを受信する手段と、
   上記記憶部に記憶されたファイルの配列の数と、上記受信したファイルの配列の数とが一致しない場合に、上記記憶部に記憶されたファイルを上記受信したファイルに更新する手段と
   を具備する情報提供装置。

Images