JP2012216163A - アプリ提供システム、アプリ提供方法、情報処理装置及び情報処理プログラム - Google Patents

Abstract

【課題】Ｗｅｂアプリのリソースをクライアントに自動的に提供できる。
【解決手段】通信端末４と、ＷｅｂアプリのリソースをＷｅｂサーバ３と、リソースの格納先アドレスを管理するＰＵＳＨサーバ２とを有し、ＰＵＳＨサーバ２は、端末ＩＤ、格納先アドレス及び提供タイミングを対応付けて管理するアドレス管理部１３を有する。更に、ＰＵＳＨサーバ２は、提供タイミングを監視するタイミング監視部１４を有する。更に、ＰＵＳＨサーバ２は、提供タイミングを検出した場合、当該提供タイミングに関わる通信端末４に提供タイミングのＷｅｂアプリのリソースをキャッシュすべく、通信端末４に対して、当該提供タイミングに関わるＷｅｂアプリのリソースの格納先アドレスを送信するＰＵＳＨ送信部１５を有する。
【選択図】図１

Description

本発明は、アプリ提供システム、アプリ提供方法、情報処理装置及び情報処理プログラムに関する。

近年、Ｗｅｂサーバ上で各種アプリケーションをクライアント側に提供するＷｅｂアプリケーション（以下、単にＷｅｂアプリと称する）が広く知られている。クライアント側は、アプリケーションをインストールしなくても、オンライン上のＷｅｂサーバ側のＷｅｂアプリを利用して各種処理を実行する。

更に、近年、ＨＴＭＬ（Hyper Text Markup Language）５規格には、Ｗｅｂアプリキャッシュ機能がある。Ｗｅｂアプリキャッシュ機能では、クライアント側にＷｅｂアプリの構成要素である全てのリソース、例えばＨＴＭＬ、ＣＳＳ（Cascading Style Sheet）及びＪａｖａＳｃｒｉｐｔ（登録商標）をＷｅｂブラウザ側のアプリキャッシュにキャッシュする。そして、クライアント側は、アプリキャッシュにキャッシュされたリソースに基づき、オフライン状態でもＷｅｂアプリをローカルアプリとして実行できる。

特表２０１０−５０８５８１号公報 特表２００７−５１９０７１号公報 特開２００４−２１３２４３号公報 特開２００５−１０７８４２号公報 特開２００３−３０８２１０号公報

しかしながら、Ｗｅｂアプリキャッシュ機能は、クライアント側の要求操作を起点にＷｅｂアプリに使用するリソースをＷｅｂサーバに要求し、ＷｅｂサーバからＷｅｂアプリのリソースを取得する。そして、クライアント側では、取得されたＷｅｂアプリのリソースをＷｅｂブラウザのアプリキャッシュにキャッシュする。つまり、Ｗｅｂアプリキャッシュ方式では、クライアント側の要求操作がない場合、Ｗｅｂアプリのリソースを取得できない。

一つの側面は、Ｗｅｂアプリのリソースをクライアント側に自動的に提供できるアプリ提供システム、アプリ提供方法、情報処理装置及び情報処理プログラムを提供することを目的とする。

開示のシステムは、一つの態様において、通信装置と、Ｗｅｂアプリのリソース情報の格納先アドレスを管理するアドレス管理装置とを有する。更に、前記アドレス管理装置は、前記通信装置を識別する識別情報と、当該通信装置に提供するＷｅｂアプリに関わるリソース情報の格納先アドレスと、当該通信装置に提供するＷｅｂアプリの提供タイミングとを対応付けて管理するアドレス管理部を有する。更に、前記アドレス管理装置は、現在タイミングが前記提供タイミングであるか否かを監視するタイミング監視部を有する。前記アドレス管理装置は、前記タイミング監視部にて現在タイミングが前記提供タイミングである場合に、当該提供タイミングに関わる前記通信装置に対して、当該提供タイミングに関わる前記Ｗｅｂアプリのリソース情報の格納先アドレスを提供する提供部を有する。更に、前記通信装置は、前記アドレス管理装置から前記格納先アドレスを受信した場合、当該格納先アドレスに基づき、前記Ｗｅｂアプリのリソース情報を要求するアプリ要求を実行する要求部を有する。更に、前記通信装置は、前記アプリ要求に応じて提供された前記Ｗｅｂアプリのリソース情報を一時的に保存する一時ストレージを有する。更に、前記通信装置は、前記アプリ要求に応じて提供されたリソース情報をＷｅｂブラウザのキャッシュに同期させるキャッシュ同期部を有する。更に、前記通信装置は、キャッシュされた前記Ｗｅｂアプリのリソース情報に基づき、当該Ｗｅｂアプリを実行するアプリ実行部を有する。

開示のシステムでは、Ｗｅｂアプリのリソースをクライアント側に自動的に提供できる。

図１は、実施例１のＷｅｂアプリ提供システム内部の一例を示す機能ブロック図である。 図２は、アドレス管理部のテーブル内容の一例を示す説明図である。 図３は、実施例１のＷｅｂアプリ提供システムの使用形態の一例を示す説明図である。 図４は、アドレス提供処理に関わるＰＵＳＨサーバの処理動作の一例を示すフローチャートである。 図５は、Ｗｅｂアプリ取得処理に関わる通信端末の処理動作の一例を示すフローチャートである。 図６は、実施例２のＷｅｂアプリ提供システム内部の一例を示す機能ブロック図である。 図７は、実施例２のＷｅｂアプリ取得処理に関わる通信端末及びＰＵＳＨクライアントの処理動作の一例を示すフローチャートである。 図８は、実施例３のＷｅｂアプリ提供システム内部の一例を示す機能ブロック図である。 図９は、アドレス管理テーブルのテーブル内容の一例を示す説明図である。 図１０は、移動元の通信端末の処理動作の一例を示すフローチャートである。 図１１は、アドレス提供処理に関わるＰＵＳＨサーバの処理動作の一例を示すフローチャートである。 図１２は、移動先の通信端末の処理動作の一例を示すフローチャートである。 図１３は、移動元の通信端末と移動先の通信端末との連動動作の一例を示す説明図である。 図１４は、実施例４のＷｅｂアプリ提供システムの使用形態の一例を示す説明図である。 図１５は、実施例５のＷｅｂアプリ提供システム内部の一例を示す機能ブロック図である。 図１６は、アドレス管理テーブルのテーブル内容の一例を示す説明図である。 図１７は、ユーザ管理テーブルのテーブル内容の一例を示す説明図である。 図１８は、ユーザ指定のアドレス提供処理に関わるＰＵＳＨサーバの処理動作の一例を示すフローチャートである。 図１９は、情報処理プログラムを実行するコンピュータを示す説明図である。

以下、図面に基づいて、本願の開示するアプリ提供システム、アプリ提供方法、情報処理装置及び情報処理プログラムの実施例を詳細に説明する。尚、本実施例により、開示技術が限定されるものではない。

図１は、実施例１のＷｅｂアプリ提供システム内部の一例を示す機能ブロック図である。図１に示すＷｅｂアプリ提供システム１は、ＰＵＳＨサーバ２と、Ｗｅｂサーバ３と、通信端末４とを有する。尚、ＰＵＳＨサーバ２、Ｗｅｂサーバ３及び通信端末４は、例えば、無線や有線等の通信網を通じて通信接続する。ＰＵＳＨサーバ２は、アプリポータルサーバ１１と、更新監視部１２と、アドレス管理部１３と、タイミング監視部１４と、ＰＵＳＨ送信部１５とを有する。アプリポータルサーバ１１は、通信端末４から所望のＷｅｂアプリのリソースの取得要求を受け付ける。尚、リソースとは、Ｗｅｂアプリの構成要素、例えば、ＨＴＭＬ、ＣＳＳ及びＪａｖａＳｃｒｉｐｔである。更新監視部１２は、各Ｗｅｂサーバ３で管理するＷｅｂアプリの更新状況を集中管理するアプリデータベース（以下、単にアプリＤＢと称する）５にアクセスし、各Ｗｅｂアプリの更新状況を監視する。尚、更新監視部１２は、各Ｗｅｂサーバ３にアクセスして各Ｗｅｂサーバ３で管理するＷｅｂアプリの更新状況を監視しても良い。

図２は、アドレス管理部１３のテーブル内容の一例を示す説明図である。図２に示すアドレス管理部１３は、ユーザＩＤ１３Ａと、端末ＩＤ１３Ｂと、アプリＩＤ１３Ｃと、格納先アドレス１３Ｄと、提供タイミング１３Ｅとを対応付けてテーブルの内容を動的に登録更新して管理する。ユーザＩＤ１３Ａは、例えば、Ｗｅｂアプリ提供システム１に登録済みのユーザを識別するＩＤである。端末ＩＤ１３Ｂは、例えば、Ｗｅｂアプリ提供システム１に登録済みのユーザの通信端末４を識別するＩＤである。アプリＩＤ１３Ｃは、通信端末４に提供するＷｅｂアプリを識別するＩＤである。格納先アドレス１３Ｄは、提供するＷｅｂアプリのリソースを管理する格納先のアドレスである。提供タイミング１３Ｅは、当該通信端末４に提供するＷｅｂアプリの格納先アドレスを当該通信端末４にＰＵＳＨ送信する上での条件タイミングである。

尚、提供タイミング１３Ｅの例としては、様々なタイミングが考えられる。提供タイミング１３Ｅは、例えば、Ｗｅｂアプリが飲食店のメニューを提供するメニュー閲覧アプリの場合、例えば、通信端末４が飲食店付近の通信エリア範囲内に進入したタイミングである。また、提供タイミング１３Ｅは、Ｗｅｂアプリが学校の教科書を提供する教科書閲覧アプリの場合、通信端末４が当該学校の敷地内の通信エリア範囲内に進入したタイミングである。また、提供タイミング１３Ｅは、Ｗｅｂアプリが会議の資料を配布する資料配布アプリの場合、通信端末４が当該会議室内の通信エリア範囲に進入したタイミングである。また、提供タイミング１３Ｅは、Ｗｅｂアプリが更新した場合、当該Ｗｅｂアプリを使用する通信端末４が所定の通信エリア範囲内に進入したタイミングである。

タイミング監視部１４は、アドレス管理部１３内の提供タイミング１３Ｅに基づき、現在タイミングが提供タイミング１３Ｅであるか否かを判定する。タイミング監視部１４は、現在タイミングが提供タイミング１３Ｅである場合、当該提供タイミング１３Ｅに対応したユーザＩＤ１３Ａ、端末ＩＤ１３Ｂ及び格納先アドレス１３Ｄをアドレス管理部１３から取得する。タイミング監視部１４は、取得された端末ＩＤ１３Ｂに基づき、当該提供タイミングの通信端末４を特定する。更に、タイミング監視部１４は、取得された格納先アドレス１３Ｄに基づき、当該提供タイミングの通信端末４に提供するＷｅｂアプリのリソースの格納先を特定する。ＰＵＳＨ送信部１５は、タイミング監視部１４にて特定された通信端末４へのＰＵＳＨ送信が可能な場合、当該通信端末４に対して、格納先アドレスをＰＵＳＨ送信する。

各Ｗｅｂサーバ３は、アプリ管理部２１と、アプリ提供部２２とを有する。アプリ管理部２１は、格納先アドレス毎にＷｅｂアプリのリソース等を格納したアプリパッケージ２３を管理する。アプリパッケージ２３は、マニフェスト２４と、リソース２５とを有する。マニフェスト２４は、Ｗｅｂアプリのリソースの一覧である。リソース２５は、Ｗｅｂアプリに使用するリソース一式である。アプリ提供部２２は、通信端末４からのアプリ要求を検出すると、当該アプリ要求に対するＷｅｂアプリのマニフェスト２４及びリソース２５をアプリ管理部２１から取得する。更に、アプリ提供部２２は、取得されたＷｅｂアプリのマニフェスト２４及びリソース２５を、アプリ要求を実行した通信端末４に提供する。

通信端末４は、通信機能を備えた、例えば、携帯電話機、スマートフォン、パソコンやタブレット端末等に相当する。通信端末４は、通信部３１と、操作部３２と、表示部３３と、メモリ３４と、ＣＰＵ３５とを有する。通信部３１は、通信網等を通じて他の通信端末４やサーバ等と通信接続する。操作部３２は、各種コマンドを入力する。表示部３３は、各種情報を表示する。メモリ３４は、各種情報等を記憶する。ＣＰＵ３５は、通信端末４全体を制御する。ＣＰＵ３５は、ＰＵＳＨクライアント３６及びＷｅｂブラウザ４０等のソフトウェア機能を実行する。

また、ＰＵＳＨクライアント３６は、ＰＵＳＨ受信部５１と、アプリ取得部５２と、一時ストレージ５３とを有する。ＰＵＳＨ受信部５１は、ＰＵＳＨサーバ２から提供タイミングに関わるＷｅｂアプリのリソースを格納する格納先アドレスを受信する。アプリ取得部５２は、ＰＵＳＨ受信部５１にて受信された格納先アドレスに基づき当該ＷｅｂアプリのリソースをＷｅｂサーバ３に要求する。アプリ取得部５２は、Ｗｅｂサーバ３からＷｅｂアプリのリソースを取得すると、当該Ｗｅｂアプリのリソースを一時ストレージ５３に登録する。

Ｗｅｂブラウザ４０は、キャッシュ同期部４１と、アプリキャッシュ４２と、アプリ実行部４３とを有する。キャッシュ同期部４１は、一時ストレージ５３に登録済みのリソースをＣＰＵ３５が解釈可能なデータ形式に変換し、この変換されたリソースをアプリキャッシュ４２にキャッシュする。アプリ実行部４３は、アプリキャッシュ４２にキャッシュされたリソースに基づき、Ｗｅｂアプリを実行する。尚、キャッシュ同期部４１は、Ｗｅｂブラウザ４０外にあっても良い。

Ｗｅｂアプリ提供システム１では、ＰＵＬＬ方式と、ＰＵＳＨ方式とがある。ＰＵＬＬ方式では、通信端末４が所望のＷｅｂアプリのリソースの格納先アドレスをＰＵＳＨサーバ２内のアプリポータルサーバ１１に要求する。そして、通信端末４は、ＰＵＳＨサーバ２から取得した格納先アドレスに基づき、Ｗｅｂアプリのリソースを取得する。また、前述した通り、ＰＵＳＨ方式では、ＰＵＳＨサーバ２がＷｅｂアプリの提供タイミングに応じてＷｅｂアプリのリソースの格納先アドレスを通信端末４に提供する。そして、通信端末４は、ＰＵＳＨサーバ２から取得した格納先アドレスに基づき、Ｗｅｂアプリのリソースを取得する。

次に、実施例１のＷｅｂアプリ提供システム１の動作について説明する。図３は、実施例１のＷｅｂアプリ提供システム１の使用形態の一例を示す説明図である。図３に示すＷｅｂアプリ提供システム１では、ＰＵＳＨサーバ２と、Ｗｅｂサーバ３と、通信端末４とを有する。

通信端末４のユーザが美術館に入館した場合、ＰＵＳＨサーバ２は、提供タイミングと判断し、美術館の案内ナビのＷｅｂアプリのリソースに関わる格納先アドレスを通信端末４にＰＵＳＨ送信する。そして、通信端末４は、ＰＵＳＨサーバ２から受信した格納先アドレスのＷｅｂサーバ３から美術館の案内ナビのＷｅｂアプリのリソースを取得してキャッシュする。そして、通信端末４は、キャッシュされたリソースに基づき、案内ナビのＷｅｂアプリを実行する。その結果、ユーザは、案内ナビのＷｅｂアプリの取得操作を行わなくても、案内ナビアプリで美術館内の案内を受けることができる。

また、通信端末４のユーザが飲食店付近に来た場合、ＰＵＳＨサーバ２は、提供タイミングと判断し、飲食店のメニュー閲覧のＷｅｂアプリのリソースに関わる格納先アドレスを通信端末４にＰＵＳＨ送信する。そして、通信端末４は、ＰＵＳＨサーバ２から受信した格納先アドレスのＷｅｂサーバ３からメニュー閲覧のＷｅｂアプリのリソースを取得してキャッシュする。そして、通信端末４は、キャッシュされたリソースに基づき、メニュー閲覧のＷｅｂアプリを実行する。その結果、ユーザは、メニュー閲覧のＷｅｂアプリの取得操作を行わなくても、メニュー閲覧アプリで飲食店のメニューを閲覧できる。

また、通信端末４のユーザが学校に来た場合、ＰＵＳＨサーバ２は、提供タイミングと判断し、教科書閲覧のＷｅｂアプリのリソースに関わる格納先アドレスを通信端末４にＰＵＳＨ送信する。そして、通信端末４は、ＰＵＳＨサーバ２から受信した格納先アドレスのＷｅｂサーバ３から教科書閲覧のＷｅｂアプリのリソースを取得してキャッシュする。そして、通信端末４は、キャッシュされたリソースに基づき、教科書閲覧のＷｅｂアプリを実行する。その結果、ユーザは、教科書閲覧のＷｅｂアプリの取得操作を行わなくても、教科書閲覧アプリで学校の教科書を閲覧できる。

また、通信端末４のユーザが会議室に入室した場合、ＰＵＳＨサーバ２は、提供タイミングと判断し、プレゼンの資料閲覧のＷｅｂアプリに関わる格納先アドレスを通信端末４にＰＵＳＨ送信する。そして、通信端末４は、ＰＵＳＨサーバ２から受信した格納先アドレスのＷｅｂサーバ３から資料閲覧のＷｅｂアプリのリソースを取得してキャッシュする。そして、通信端末４は、キャッシュされたリソースに基づき、資料閲覧のＷｅｂアプリを実行する。その結果、ユーザは、資料閲覧のＷｅｂアプリの取得操作を行わなくても、資料閲覧アプリでプレゼン資料を閲覧できる。

図４は、アドレス提供処理に関わるＰＵＳＨサーバ２の処理動作の一例を示すフローチャートである。図４に示すアドレス提供処理では、Ｗｅｂアプリの提供タイミングを監視し、当該提供タイミングを検出すると、提供タイミングに対応した通信端末４に提供対象のＷｅｂアプリに関わるリソースの格納先アドレスをＰＵＳＨ送信する処理である。図４に示すＰＵＳＨサーバ２のタイミング監視部１４は、現在タイミングがアドレス管理部１３に管理中の提供タイミングであるか否かを判定する（ステップＳ１１）。タイミング監視部１４は、現在タイミングが提供タイミングである場合（ステップＳ１１肯定）、アドレス管理部１３から提供タイミングに関わる端末ＩＤ１３Ｂ及び格納先アドレス１３Ｄを特定する（ステップＳ１２）。

ＰＵＳＨサーバ２のＰＵＳＨ送信部１５は、端末ＩＤ１３Ｂ及び格納先アドレス１３Ｄを特定すると、当該端末ＩＤ１３Ｂの通信端末４に対して格納先アドレス１３ＤをＰＵＳＨ送信し（ステップＳ１３）、図４に示す処理動作を終了する。尚、ＰＵＳＨ送信部１５は、当該端末ＩＤ１３Ｂの通信端末４に対して通信可能な状態であるか否かを判定し、通信可能な状態である場合、当該通信端末４に対して格納先アドレス１３ＤをＰＵＳＨ送信する。また、ＰＵＳＨサーバ２の更新監視部１２は、現在タイミングが提供タイミングでない場合（ステップＳ１１否定）、アプリＤＢ５内で各Ｗｅｂアプリの更新状況を監視し（ステップＳ１４）、提供タイミングを監視すべく、ステップＳ１１に移行する。

図４に示すアドレス提供処理では、Ｗｅｂアプリの提供タイミングを監視し、当該提供タイミングを検出すると、提供タイミングに対応した通信端末４に提供対象のＷｅｂアプリのリソースの格納先アドレスをＰＵＳＨ送信する。その結果、通信端末４は、提供タイミングに応じたＷｅｂアプリのリソースの格納先アドレスを認識できる。

図５は、Ｗｅｂアプリ取得処理に関わる通信端末４の処理動作の一例を示すフローチャートである。図５に示すＷｅｂアプリ取得処理では、ＰＵＳＨサーバ２から取得した格納先アドレスに基づきＷｅｂアプリのリソースをＷｅｂサーバ３から取得し、リソースをアプリキャッシュ４２にキャッシュする処理である。図５において通信端末４のＰＵＳＨクライアント３６のＰＵＳＨ受信部５１は、ＰＵＳＨサーバ２から格納先アドレスを受信したか否かを判定する（ステップＳ２１）。ＰＵＳＨクライアント３６のアプリ取得部５２は、格納先アドレスを受信した場合（ステップＳ２１肯定）、格納先アドレスに基づきＷｅｂサーバ３に対してＷｅｂアプリを要求する（ステップＳ２２）。アプリ取得部５２は、Ｗｅｂアプリ要求に対するリソースを取得したか否かを判定する（ステップＳ２３）。

アプリ取得部５２は、リソースを取得した場合（ステップＳ２３肯定）、取得されたリソースを一時ストレージ５３に登録する（ステップＳ２４）。Ｗｅｂブラウザ４０のキャッシュ同期部４１は、一時ストレージ５３に登録済みのリソースをＣＰＵ３５側で解釈可能なデータ形式に変換する（ステップＳ２６）。更に、キャッシュ同期部４１は、変換されたリソースをアプリキャッシュ４２にキャッシュし（ステップＳ２７）、図５に示す処理動作を終了する。

アプリ取得部５２は、格納先アドレスを受信していない場合（ステップＳ２１否定）、一時ストレージ５３に登録済みのリソースがあるか否かを判定する（ステップＳ２８）。アプリ取得部５２は、一時ストレージ５３に登録済みのリソースがある場合（ステップＳ２８肯定）、登録済みのリソースを変換すべく、ステップＳ２６に移行する。

また、アプリ取得部５２は、一時ストレージ５３に登録済みのリソースがない場合（ステップＳ２８否定）、図５に示す処理動作を終了する。

図５に示すＷｅｂアプリ取得処理では、ＰＵＳＨサーバ２から取得した格納先アドレスに基づきＷｅｂアプリのリソースをＷｅｂサーバ３から取得し、リソースをアプリキャッシュ４２にキャッシュする。その結果、通信端末４は、キャッシュされたリソースに基づきＷｅｂアプリを実行できる。

Ｗｅｂアプリ取得処理では、Ｗｅｂブラウザ４０が起動しているかどうかに関わらず、一時ストレージ５３に登録済みのリソースを読み出し、リソースをアプリキャッシュにキャッシュする。その結果、提供タイミングに応じたＷｅｂアプリを自動取得できる。

実施例１では、ＰＵＳＨサーバ２が、Ｗｅｂアプリの提供タイミングを検出した場合、当該提供タイミングに関わる通信端末４に対して、当該提供タイミングに関わるＷｅｂアプリのリソースの格納先アドレスを提供する。更に、通信端末４は、格納先アドレスを受信した場合、当該格納先アドレスに基づき、Ｗｅｂアプリのリソースを要求するアプリ要求を実行する。更に、通信端末４は、アプリ要求に応じて提供されたＷｅｂアプリのリソースをアプリキャッシュ４２にキャッシュし、キャッシュされたＷｅｂアプリのリソースに基づき、当該Ｗｅｂアプリを実行する。その結果、通信端末４のユーザは、アプリ取得に関わる要求操作を実行しなくても、必要な時に必要なＷｅｂアプリを提供タイミングに応じて自動的に取得できる。

実施例１では、ユーザの操作なしでＷｅｂアプリ実行に必要な最新のリソースを取得できる。また、アプリ開発者は、デバイス毎にローカルアプリを開発する必要がなくなり、一つのＷｅｂアプリを開発するだけで済むため、開発コストを数分の一に抑制できる。しかも、ユーザは、面倒なインストール作業を一切行う必要がなく、アプリを使用できる。

尚、上記実施例１では、通信端末４、例えば、携帯電話機内にＰＵＳＨクライアント３６を内蔵したが、通信端末４Ａ、例えば、パソコンに対してＰＵＳＨクライアント３６をＵＳＢ（Universal Serial Bus）で外部接続するようにしても良い。この場合の実施の形態につき、実施例２として説明する。

図６は、実施例２のＷｅｂアプリ提供システム１Ａ内部の一例を示すブロック図である。尚、実施例１のＷｅｂアプリ提供システムと同一の構成には同一符号を付すことで、その重複する構成及び動作の説明については省略する。

図６に示すＷｅｂアプリ提供システム１Ａと図１に示すＷｅｂアプリ提供システム１とが異なるところは、外部接続機器３８内のＣＰＵ３７上で動作するＰＵＳＨクライアント３６Ａが、例えば、パソコン等の通信端末４Ａに対してＵＳＢ６１で接続した点にある。図６に示す通信端末４Ａは、通信部３１、操作部３２、表示部３３、メモリ３４及びＣＰＵ３５を有する。通信端末４Ａは、ＣＰＵ３７上で動作するＰＵＳＨクライアント３６ＡとＵＳＢ６１で接続する。更に、ＰＵＳＨクライアント３６Ａは、ＰＵＳＨ受信部５１、アプリ取得部５２及び一時ストレージ５３の他に、通信モジュール５４を有する。通信モジュール５４は、通信端末４Ａの電源がＯＦＦ状態でも、ＰＵＳＨサーバ２からのＰＵＳＨ送信に対して受信可能にするものである。

図７は、実施例２のＷｅｂアプリ取得処理に関わる通信端末４Ａ及びＰＵＳＨクライアント３６Ａの処理動作の一例を示すフローチャートである。ＰＵＳＨサーバ２は、提供タイミングを検出すると、通信端末４Ａが電源ＯＦＦ状態でも、提供タイミングに関わるＷｅｂアプリのリソースに関わる格納先アドレスをＰＵＳＨクライアント３６Ａに送信する。

図７においてＰＵＳＨクライアント３６ＡのＰＵＳＨ受信部５１は、ＰＵＳＨサーバ２から格納先アドレスを受信したか否かを判定する（ステップＳ３１）。ＰＵＳＨクライアント３６Ａのアプリ取得部５２は、格納先アドレスを受信した場合（ステップＳ３１肯定）、格納先アドレスに関わるＷｅｂアプリ要求をＷｅｂサーバ３に送信する（ステップＳ３２）。アプリ取得部５２は、Ｗｅｂアプリ要求に対して、当該格納先アドレスに格納されたＷｅｂサーバ３側のＷｅｂアプリのリソースを取得したか否かを判定する（ステップＳ３３）。アプリ取得部５２は、Ｗｅｂアプリのリソースを取得した場合（ステップＳ３３肯定）、当該リソースを一時ストレージ５３に登録する（ステップＳ３４）。

次に、ＰＵＳＨクライアント３６ＡのＣＰＵ３７は、リソースを一時ストレージ５３に登録すると、通信端末４Ａが起動済みであるか否かを判定する（ステップＳ３５）。通信端末４ＡのＷｅｂブラウザ４０のキャッシュ同期部４１は、通信端末４Ａが起動済みである場合（ステップＳ３５肯定）、ＰＵＳＨクライアント３６Ａの一時ストレージ５３に登録済みのリソースをＣＰＵ３５で解釈可能なデータ形式に変換する（ステップＳ３６）。更に、キャッシュ同期部４１は、変換されたリソースをアプリキャッシュ４２にキャッシュする（ステップＳ３７）。その結果、Ｗｅｂブラウザ４０のアプリ実行部４３は、キャッシュされたリソースに基づき、Ｗｅｂアプリを実行する。

また、アプリ取得部５２は、格納先アドレスを受信していない場合（ステップＳ３１否定）、一時ストレージ５３に登録済みのリソースがあるか否かを判定する（ステップＳ３８）。アプリ取得部５２は、一時ストレージ５３に登録済みのリソースがある場合（ステップＳ３８肯定）、通信端末４Ａが起動済みであるか否かを判定すべく、ステップＳ３５に移行する。

また、アプリ取得部５２は、一時ストレージ５３に登録済みのリソースがない場合（ステップＳ３８否定）、図７に示す処理動作を終了する。また、ＣＰＵ３７は、通信端末４Ａが起動済みでない場合（ステップＳ３５否定）、通信端末４Ａの電源をＯＮにしてＷｅｂブラウザ４０を起動し（ステップＳ３９）、一時ストレージ５３に登録済みのリソースを変換すべく、ステップＳ３６に移行する。

実施例２では、ＰＵＳＨクライアント３６Ａ内に通信モジュール５４を備えているため、通信端末４Ａ側の電源がＯＦＦ状態でも、ＰＵＳＨクライアント３６ＡがＰＵＳＨサーバ２からの格納先アドレスを受信する。その結果、ＰＵＳＨクライアント３６Ａは、通信端末４Ａ側の電源がＯＦＦ状態でも、ＰＵＳＨサーバ２からの格納先アドレスを受信できる。

しかも、実施例２では、Ｗｅｂアプリの提供タイミングを検出すると、提供タイミングに関わるＰＵＳＨクライアント３６ＡにＷｅｂアプリのリソースに関わる格納先アドレスを送信する。更に、ＰＵＳＨクライアント３６Ａは、受信した格納先アドレスに基づきＷｅｂサーバ３からＷｅｂアプリのリソースを受信する。ＰＵＳＨクライアント３６Ａは、リソースをＷｅｂブラウザ４０のアプリキャッシュ４２にキャッシュする。Ｗｅｂブラウザ４０のアプリ実行部４３は、キャッシュされたリソースに基づき、Ｗｅｂアプリを実行する。その結果、通信端末４Ａのユーザは、アプリ取得に関わる要求操作を実行しなくても、必要な時に必要なＷｅｂアプリを提供タイミングに応じて自動的に取得できる。

尚、上記実施例のタイミング監視部１４では、アドレス管理部１３内の端末ＩＤ１３Ｂ毎の提供タイミング１３Ｅに基づき、端末ＩＤ１３Ｂで識別する通信端末４Ａ毎の提供タイミングを監視した。しかしながら、タイミング監視部１４は、アドレス管理部１３内のユーザＩＤ１３Ａ毎の提供タイミング１３Ｅを監視しても良く、この場合、ユーザＩＤ１３Ａで識別するユーザの各提供タイミングを監視する。

また、上記実施例では、Ｗｅｂアプリのリソースを管理するアプリ管理部２１をＷｅｂサーバ３側に管理したが、アプリ管理部２１をＰＵＳＨサーバ２に内蔵しても良い。この場合、ＰＵＳＨサーバ２のタイミング監視部１４は、提供タイミングを検出すると、提供タイミングに関わる端末ＩＤ１３Ｂ及び格納先アドレス１３Ｄを特定する。タイミング監視部１４は、格納先アドレス１３Ｄに基づき内部のアプリ管理部２１からリソースを取得する。更に、ＰＵＳＨ送信部１５は、端末ＩＤ１３Ｂの通信端末４に対して、当該提供タイミングのＷｅｂアプリのリソースをＰＵＳＨ送信しても良い。

また、上記実施例では、通信端末４のユーザが会議室に入室した場合、ＰＵＳＨサーバ２は、提供タイミングと判断し、当該提供タイミングに応じて、プレゼンの資料閲覧のＷｅｂアプリに関わるリソースの格納先アドレスを通信端末４に提供する。そして、通信端末４は、格納先アドレスに基づき、プレゼンの資料閲覧のＷｅｂアプリに関わるリソースを取得してキャッシュした。この際、プレゼン資料の機密性を考慮した場合、会議室の退出後は、プレゼン資料閲覧のＷｅｂアプリを使用不可にすることが望ましい。そこで、ＰＵＳＨサーバ２は、使用不可対象のＷｅｂアプリを提供した通信端末４の端末ＩＤと、使用不可対象のＷｅｂアプリを識別するアプリＩＤと、使用不可のＷｅｂアプリの使用不可タイミングとを対応付けて管理する管理部を備えるようにしても良い。

この場合、ＰＵＳＨサーバ２のタイミング監視部１４は、通信端末４のユーザが会議室を退室した場合、使用不可タイミングと判断する。タイミング監視部１４は、当該使用不可タイミングに応じて、当該使用不可タイミングの端末ＩＤ及びアプリＩＤを管理部から取得する。タイミング監視部１４は、取得された端末ＩＤに基づき使用不可対象の通信端末４を特定すると共に、取得されたアプリＩＤに基づき使用不可の通信端末４のＷｅｂアプリを特定する。ＰＵＳＨ送信部１５は、使用不可のＷｅｂアプリ、例えば、プレゼン資料閲覧のＷｅｂアプリの使用不可要求を通信端末４に通知する。通信端末４は、使用不可要求を受信すると、キャッシュされた当該プレゼン資料閲覧のＷｅｂアプリのリソースを消去することで、当該Ｗｅｂアプリを実行できなくする。その結果、通信端末４のユーザは、会議室退室後に資料閲覧のＷｅｂアプリが閲覧できなくなるため、プレゼン資料の機密性を確保できる。

図８は、実施例３のＷｅｂアプリ提供システム内部の一例を示す機能ブロック図である。尚、図１に示すＷｅｂアプリ提供システム１と同一の構成には同一符号を付すことで、その重複する構成及び動作の説明については省略する。図８に示すＷｅｂアプリ提供システム１Ｂと図１に示すＷｅｂアプリ提供システム１とが異なるところは、簡単な操作で、移動元の通信端末４Ｄで実行中のＷｅｂアプリを移動先の通信端末４Ｅ側でも実行できる点にある。尚、移動元の通信端末４Ｄは、Ｗｅｂアプリ実行中の通信端末４である。これに対して、移動先の通信端末４Ｅは、移動元の通信端末４Ｄで実行中のＷｅｂアプリと同一アプリを実行させる通信端末４である。

図８に示すＰＵＳＨサーバ２は、アプリポータルサーバ１１、更新監視部１２、アドレス管理部１３、タイミング監視部１４及びＰＵＳＨ送信部１５の他に、イベント受信部１６を有する。イベント受信部１６は、移動元の通信端末４Ｄから後述するイベント情報を受信する。また、アドレス管理部１３は、アドレス管理テーブル１５１を管理し、アドレス管理テーブル１５１のテーブル内容を動的に更新登録する。図９は、アドレス管理テーブル１５１のテーブル内容の一例を示す説明図である。図９に示すアドレス管理テーブル１５１は、ユーザＩＤ１５１Ａ、端末ＩＤ１５１Ｂ、アプリＩＤ１５１Ｃ、格納先アドレス１５１Ｄ及び提供タイミング１５１Ｅの他に、タグＩＤ１５１Ｆ及びコマンド１５１Ｇを対応付けて管理している。タグＩＤ１５１Ｆは、通信端末４Ｅに内蔵した後述するＲＦＩＤタグ３９Ｂを識別するＩＤである。コマンド１５１Ｇは、格納先アドレス１５１Ｄで特定するＷｅｂアプリの実行内容である。尚、コマンド１５１Ｇには、Ｗｅｂアプリの実行内容、例えば、ダウンロード及び実行、ダウンロードのみ、実行のみ、消去等がある。

移動元の通信端末４Ｄは、通信部３１、操作部３２、表示部３３、メモリ３４及びＣＰＵ３５の他、ＲＦＩＤ（Radio Frequency Identification）リーダライタ３９Ａを有する。更に、移動先の通信端末４Ｅは、通信部３１、操作部３２、表示部３３、メモリ３４及びＣＰＵ３５の他、ＲＦＩＤタグ３９Ｂを有する。ＲＦＩＤリーダライタ３９Ａは、ＲＦＩＤタグ３９Ｂと所定通信距離内での近距離無線通信を実行する。

移動元の通信端末４ＤのＲＦＩＤリーダライタ３９Ａは、移動先の通信端末４Ｅのアプリ移動操作に応じてＲＦＩＤタグ３９Ｂと近距離無線通信を開始する。尚、アプリ移動操作は、ＲＦＩＤリーダライタ３９Ａに対するＲＦＩＤタグ３９Ｂのかざし操作及び、表示部３３又は操作部３２の特定操作の二重操作とすることで誤操作を防止できる。ＣＰＵ３５は、ＲＦＩＤリーダライタ３９Ａを通じてＲＦＩＤタグ３９ＢのタグＩＤを取得すると、タグＩＤを含む移動イベント情報を生成する。

尚、移動イベント情報は、タグＩＤと、格納先アドレスと、イベント内容と、コマンドとを有する。タグＩＤは、移動先の通信端末４Ｅ側のＲＦＩＤタグ３９Ｂを識別するＩＤである。格納先アドレスは、移動元の通信端末４Ｄ側で実行中の移動先の通信端末４Ｅでも実行するＷｅｂアプリに関わるリソースの格納先アドレスである。イベント内容は、移動元の通信端末４Ｄで実行中の同一Ｗｅｂアプリを移動先の通信端末４Ｅでも実行させる移動イベントである。コマンドは、移動先の通信端末４Ｅで実行するＷｅｂアプリの実行内容、例えば、ダウンロード及び実行、ダウンロードのみ、実行のみ、消去等の実行内容である。

移動元の通信端末４Ｄの通信部３１は、生成した移動イベント情報をＰＵＳＨサーバ２に送信する。ＰＵＳＨサーバ２のイベント受信部１６は、移動元の通信端末４Ｄから移動イベント情報を受信する。ＰＵＳＨサーバ２のアドレス管理部１３は、移動イベント情報を受信した場合、移動イベント情報内のタグＩＤ１５１Ｆに関わる端末ＩＤ１５１Ｂに対応した提供タイミング１５１Ｅを“即時”としてアドレス管理テーブル１５１内に更新する。更に、アドレス管理部１３は、移動イベント情報内のコマンドを端末ＩＤ１５１Ｂに対応したコマンド１５１Ｇとしてアドレス管理テーブル１５１内に更新する。

タイミング監視部１４は、アドレス管理部１３の提供タイミング１５１Ｅを参照し、現在タイミングが提供タイミング１５１Ｅであるか否かを監視する。アドレス管理部１３は、提供タイミング１５１Ｅが“即時”の場合、即時にアドレス管理テーブル１５１から提供タイミング１５１Ｅに関わる端末ＩＤ１５１Ｂ、格納先アドレス１５１Ｄ及びコマンド１５１Ｇを特定する。尚、アドレス管理部１３は、例えば、端末種別毎のＷｅｂアプリのリソースに関わる格納先アドレスを管理するテーブルを備え、端末ＩＤ１５１Ｂの端末種別を特定する。そして、アドレス管理部１３は、端末ＩＤ１５１Ｂの端末種別を特定すると、格納先アドレスのＷｅｂアプリが通知先の通信端末４の端末種別に合致するか否かを判定する。そして、アドレス管理部１３は、端末種別に合致しなかった場合、合致する端末種別に適用した格納先アドレス１５１Ｄを特定する。

ＰＵＳＨ送信部１５は、端末ＩＤ１５１Ｂ、格納先アドレス１５１Ｄ及びコマンド１５１Ｇを特定すると、端末ＩＤ１５１Ｂの移動先の通信端末４Ｅに対してＰＵＳＨ送信可能な状況であるか否かを判定する。ＰＵＳＨ送信部１５は、ＰＵＳＨ送信可能な状況の場合、端末ＩＤ１５１Ｂの移動先の通信端末４Ｅに対して格納先アドレス１５１Ｄ及びコマンド１５１ＧをＰＵＳＨ送信する。

移動先の通信端末４ＥのＰＵＳＨ受信部５１は、ＰＵＳＨサーバ２から格納先アドレス及びコマンドを受信した場合、格納先アドレスに基づきＷｅｂサーバ３に対してＷｅｂアプリを要求する。アプリ取得部５２は、Ｗｅｂアプリ要求に対するリソースを取得した場合、取得されたリソースを一時ストレージ５３に登録する。更に、キャッシュ同期部４１は、一時ストレージ５３に登録済みのリソースをＣＰＵ３５側で解釈可能なデータ形式に変換する。更に、キャッシュ同期部４１は、変換されたリソースをアプリキャッシュ４２にキャッシュする。更に、アプリ実行部４３は、ＰＵＳＨサーバ２から受信したコマンドに基づき、アプリキャッシュ４２にキャッシュされたＷｅｂアプリを実行する。

つまり、移動先の通信端末４Ｅは、移動元の通信端末４Ｄとのアプリ移動操作に応じて、移動元の通信端末４Ｄで実行中の同一Ｗｅｂアプリを実行できる。

次に、実施例３のＷｅｂアプリ提供システム１Ｂの動作について説明する。図１０は、移動元の通信端末４Ｄの処理動作の一例を示すフローチャートである。図１０において移動元の通信端末４ＤのＲＦＩＤリーダライタ３９Ａは、移動先の通信端末４Ｅとのアプリ移動操作に伴う近距離無線通信に応じて移動先の通信端末４ＥのタグＩＤを受信したか否かを判定する（ステップＳ５１）。移動元の通信端末４ＤのＣＰＵ３５は、タグＩＤを受信した場合（ステップＳ５１肯定）、タグＩＤ、移動イベント、格納先アドレス及びコマンドを含む移動イベント情報をＰＵＳＨサーバ２に送信し（ステップＳ５２）、図１０に示す処理動作を終了する。また、ＲＦＩＤリーダライタ３９Ａは、移動先の通信端末４ＥのタグＩＤを受信しなかった場合（ステップＳ５１否定）、図１０に示す処理動作を終了する。

また、図１１は、アドレス提供処理に関わるＰＵＳＨサーバ２の処理動作の一例を示すフローチャートである。図１１に示すアドレス提供処理では、現在が提供タイミングの場合、提供タイミングに対応した通信端末４に対して提供対象のＷｅｂアプリに関わるリソースの格納先アドレス及びコマンドをＰＵＳＨ送信する処理である。図１１においてＰＵＳＨサーバ２のタイミング監視部１４は、現在タイミングがアドレス管理部１３に管理中の提供タイミングであるか否かを判定する（ステップＳ６１）。尚、タイミング監視部１４は、提供タイミングが“即時”の場合、現在タイミングが提供タイミングであると判断する。タイミング監視部１４は、現在タイミングが提供タイミングである場合（ステップＳ６１肯定）、アドレス管理部１３から提供タイミングに関わる端末ＩＤ１５１Ｂ、格納先アドレス１５１Ｄ及びコマンド１５１Ｇを特定する（ステップＳ６２）。

ＰＵＳＨサーバ２のＰＵＳＨ送信部１５は、端末ＩＤ１５１Ｂ、格納先アドレス１５１Ｄ及びコマンド１５１Ｇを特定すると、当該端末ＩＤ１５１Ｂの通信端末４に対して格納先アドレス１５１Ｄ及びコマンド１５１ＧをＰＵＳＨ送信する（ステップＳ６３）。そして、図１１に示す処理動作を終了する。尚、ＰＵＳＨ送信部１５は、当該端末ＩＤ１５１Ｂの通信端末４に対して通信可能な状態であるか否かを判定し、通信可能な状態である場合、当該通信端末４に対して格納先アドレス１５１Ｄ及びコマンド１５１ＧをＰＵＳＨ送信する。また、ＰＵＳＨサーバ２の更新監視部１２は、現在タイミングが提供タイミングでない場合（ステップＳ６１否定）、アプリＤＢ５内で各Ｗｅｂアプリの更新状況を監視し（ステップＳ６４）、提供タイミングを監視すべく、ステップＳ６１に移行する。

図１１に示すアドレス提供処理では、現在が提供タイミングの場合、提供タイミングに対応した移動先の通信端末４Ｅに対して提供対象のＷｅｂアプリのリソースの格納先アドレス及びコマンドをＰＵＳＨ送信する。その結果、移動先の通信端末４Ｅは、提供タイミングに応じたＷｅｂアプリのリソースの格納先アドレス及びコマンドを取得する。

図１２は、移動先の通信端末４Ｅの処理動作の一例を示すフローチャートである。図１２において移動先の通信端末４ＥのＰＵＳＨ受信部５１は、ＰＵＳＨサーバ２から格納先アドレス及びコマンドを受信したか否かを判定する（ステップＳ７１）。移動先の通信端末４Ｅのアプリ取得部５２は、格納先アドレス及びコマンドを受信した場合（ステップＳ７１肯定）、格納先アドレスに基づきＷｅｂサーバ３からＷｅｂアプリのリソースをダウンロードする（ステップＳ７２）。

アプリ取得部５２は、Ｗｅｂアプリのリソースの取得が完了したか否かを判定する（ステップＳ７３）。アプリ取得部５２は、Ｗｅｂアプリに関わるリソースの取得が完了した場合（ステップＳ７３肯定）、Ｗｅｂアプリのリソースを一時ストレージ５３に登録する（ステップＳ７４）。更に、アプリ実行部４３は、一時ストレージ５３に登録済みのＷｅｂアプリのリソースをアプリキャッシュ４２にキャッシュし、キャッシュされたＷｅｂアプリのリソースを、ステップＳ７１で受信したコマンドに基づき実行する（ステップＳ７５）。そして、図１２に示す処理動作を終了する。

また、ＰＵＳＨ受信部５１は、ＰＵＳＨサーバ２から格納先アドレス及びコマンドを受信しなかった場合（ステップＳ７１否定）、図１２に示す処理動作を終了する。また、アプリ取得部５２は、Ｗｅｂアプリのリソースの取得が完了しなかった場合（ステップＳ７３否定）、ステップＳ７３の監視動作を継続する。

移動先の通信端末４Ｅは、ＰＵＳＨサーバ２から格納先アドレス及びコマンドを受信した場合、格納先アドレスに基づきＷｅｂアプリを取得すると共に、コマンドに基づき、当該Ｗｅｂアプリを実行する。その結果、移動先の通信端末４Ｅは、移動元の通信端末４Ｄで実行中の同一Ｗｅｂアプリ４を実行できる。

図１３は、移動元の通信端末４Ｄと移動先の通信端末４Ｅとの連動動作の一例を示す説明図である。移動元の通信端末４Ｄを携帯電話機４０１、移動先の通信端末４Ｅをタブレット端末４０２とする。図１３（Ａ）に示す携帯電話機４０１は、Ｗｅｂアプリを実行することで、表示部４０１ＡにＷｅｂアプリの実行画面を表示している。そして、携帯電話機４０１に対するタブレット端末４０２とのアプリ移動操作に応じて、携帯電話機４０１のＲＦＩＤリーダライタ３９Ａは、タブレット端末４０２のタグＩＤを取得する。更に、携帯電話機４０１は、取得されたタグＩＤと、携帯電話機４０１で実行中のＷｅｂアプリのリソースの格納先アドレス、移動イベント、Ｗｅｂアプリのダウンロード及び実行のコマンドを含む移動イベント情報をＰＵＳＨサーバ２に送信する。

ＰＵＳＨサーバ２のアドレス管理部１３は、移動イベント情報を受信した場合、移動イベント情報内のタグＩＤ、移動イベント、格納先アドレス及びコマンドに基づき、端末ＩＤに対応した提供タイミングを“即時”としてアドレス管理テーブル１５１を更新する。更に、アドレス管理部１３は、取得したコマンドを端末ＩＤに対応したコマンドとしてアドレス管理テーブル１５１を更新する。

ＰＵＳＨサーバ２のアドレス管理部１３は、提供タイミングが“即時”のため、提供タイミングの端末ＩＤ、格納先アドレス及びコマンドをアドレス管理テーブル１５１から特定する。ＰＵＳＨサーバ２のＰＵＳＨ送信部１５は、端末ＩＤのタブレット端末４０２に対して格納先アドレス及びコマンドをＰＵＳＨ送信する。そして、タブレット端末４０２は、格納先アドレスに基づき、携帯電話機４０１で実行中のＷｅｂアプリをＷｅｂサーバ３から取得し、コマンドに基づき、取得したＷｅｂアプリを実行して、Ｗｅｂアプリの実行画面を表示部４０２Ａに表示する。その結果、タブレット端末４０２は、アプリ移動操作に応じて、図１３（Ａ）に示す通り、携帯電話機４０１と同一のＷｅｂアプリを実行できる。

また、図１３（Ｂ）に示すタブレット端末４０２は、その表示部４０２Ａに動画を使用中に、携帯電話機４０１をかざした場合、携帯電話機４０１の表示部４０１Ａに表示中の画面内容をタブレット端末４０２の表示部４０２Ａに画面表示する。この場合、表示部４０２Ａは、近距離無線通信のリーダ部を含み、表示部４０２ＡにＲＦＩＤタグをかざすと、ＲＦＩＤタグと近距離無線通信を行う機能を有する。この際、タブレット端末４０２の表示部４０２Ａは、使用中の動画画面と、携帯電話機４０１の表示部４０１Ａの表示画面とに２分割して再レイアウトできる。

尚、上記実施例３では、説明の便宜上、移動元の通信端末４Ｄ内にＲＦＩＤリーダライタ３９Ａ、移動先の通信端末４Ｅ内にＲＦＩＤタグ３９Ｂを内蔵する態様で説明した。しかしながら、各通信端末４（４Ｄ，４Ｅ）は、ＲＦＩＤリーダライタ３９Ａ及びＲＦＩＤタグ３９Ｂ両方を内蔵しても良い。

また、上記実施例３では、通信端末４間のアプリ移動操作にＲＦＩＤ通信機能を使用したが、通信端末４間のＮＦＣ（Near Field Communication）通信等の近距離無線通信や、通信端末４間で接触センサを使用した接触センサ方式を採用しても良い。

図１４は、実施例４のＷｅｂアプリ提供システムの使用形態の一例を示す説明図である。尚、実施例３のＷｅｂアプリ提供システム１Ｂと同一の構成には同一符号を付すことで、その重複する構成及び動作の説明については省略する。図１４に示すＷｅｂアプリ提供システム１Ｃは、例えば、会議室で使用するＷｅｂアプリ提供システムを想定する。

アドレス管理部１３は、通信端末４の端末ＩＤ１５１Ｂに対応する提供タイミング１５１Ｅが通信端末４の保有者による会議室の入室タイミング、コマンド１５１ＧがＷｅｂアプリのダウンロード及び実行とする。尚、入室タイミングとは、例えば、会議室の入口に配置した入室監視装置の通信範囲内への通信端末４の進入による、入室監視装置と通信端末４との通信動作に応じて、通信端末４保有者の会議室への入室を検知したタイミングである。Ｗｅｂアプリは、プレゼン資料閲覧用のＷｅｂアプリである。コマンドは、プレゼン資料閲覧用のＷｅｂアプリのダウンロード及び実行である。

また、アドレス管理部１３は、通信端末４の識別情報に対応する提供タイミング１５１Ｅが通信端末４の保有者による会議室の退室タイミング、コマンド１５１ＧがＷｅｂアプリの消去とする。尚、退室タイミングは、入室監視装置の通信範囲内への通信端末４の再進入による、入室監視装置と通信端末４との通信動作に応じて、通信端末４保有者の会議室からの退室を検知したタイミングである。Ｗｅｂアプリは、プレゼン資料閲覧用のＷｅｂアプリである。コマンドは、プレゼン資料閲覧用のＷｅｂアプリの消去である。

ＰＵＳＨサーバ２のアドレス管理部１３は、通信端末４の会議室の入室タイミングを検出した場合、この通信端末４の端末ＩＤ１５１Ｂ、格納先アドレス１５１Ｄ及びコマンド１５１Ｇをアドレス管理テーブル１５１から特定する。更に、ＰＵＳＨサーバ２のＰＵＳＨ送信部１５は、特定された格納先アドレス及びコマンドを通信端末４に送信する。そして、会議室内の通信端末４は、格納先アドレスに基づき、Ｗｅｂサーバ３からプレゼン資料閲覧用のＷｅｂアプリのリソースを取得してキャッシュする。そして、通信端末４は、コマンド内容に基づき、プレゼン資料閲覧用のＷｅｂアプリを実行する。

また、ＰＵＳＨサーバ２のタイミング監視部１４は、通信端末４の会議室の退室タイミングを検出した場合、この通信端末４の端末ＩＤ１５１Ｂ、格納先アドレス１５１Ｄ及びコマンド１５１Ｇをアドレス管理テーブル１５１から特定する。更に、ＰＵＳＨサーバ２のＰＵＳＨ送信部１５は、特定された格納先アドレス及びコマンドを通信端末４に送信する。そして、会議室外の通信端末４は、格納先アドレスに基づきプレゼン資料閲覧用のＷｅｂアプリを特定し、コマンド内容に基づき、特定されたＷｅｂアプリをキャッシュから消去する。

実施例４では、通信端末４のユーザが会議室に入室した場合、ＰＵＳＨサーバ２は、提供タイミングと判断し、プレゼン資料閲覧用のＷｅｂアプリの格納先アドレス及びコマンドを通信端末４に提供する。そして、会議室内の通信端末４は、格納先アドレスに基づき、プレゼン資料閲覧のＷｅｂアプリに関わるリソースを取得してキャッシュし、そのコマンドに基づき、プレゼン資料閲覧用のＷｅｂアプリを実行する。

また、実施例４では、通信端末４のユーザが会議室から退室した場合、ＰＵＳＨサーバ２は、提供タイミングと判断し、プレゼン資料閲覧用のＷｅｂアプリの格納先アドレス及びコマンドを通信端末４に提供する。そして、会議室外の通信端末４は、格納先アドレスに基づき、プレゼン資料閲覧のＷｅｂアプリに関わるリソースを特定し、コマンドに基づき、プレゼン資料閲覧用のＷｅｂアプリをキャッシュから消去する。その結果、通信端末４のユーザは、会議室退室後に資料閲覧のＷｅｂアプリが閲覧できなくなるため、プレゼン資料の機密性を確保できる。

図１５は、実施例５のＷｅｂアプリ提供システム内部の一例を示す機能ブロック図である。尚、図１に示すＷｅｂアプリ提供システム１と同一の構成には同一符号を付すことで、その重複する構成及び動作の説明については省略する。図１５に示すＷｅｂアプリ提供システム１Ｄと図１に示すＷｅｂアプリ提供システム１とが異なるところは、次の点にある。すなわち、ユーザに対する指定Ｗｅｂアプリの送信依頼を検出すると、当該ユーザが所有する複数の通信端末４の内、ユーザが現在使用している可能性の高い特定の通信端末４に指定のＷｅｂアプリを提供する点である。

図１５に示すＰＵＳＨサーバ２は、アプリポータルサーバ１１、更新監視部１２、アドレス管理部１３、タイミング監視部１４及びＰＵＳＨ送信部１５の他に、イベント受信部１６を有する。イベント受信部１６は、通信端末４からイベント情報を受信する。尚、イベント情報は、例えば、ユーザＩＤと、格納先アドレスと、イベント内容と、コマンドとを有する。尚、ユーザＩＤは、提供対象のＷｅｂアプリを提供するユーザのＩＤである。格納先アドレスは、提供対象のＷｅｂアプリに関わるリソースの格納先である。イベント内容は、Ｗｅｂアプリの送信（提供）依頼に応じたイベントである。コマンドは、提供対象のＷｅｂアプリを実行する実行内容である。

また、アドレス管理部１３は、アドレス管理テーブル１５１及びユーザ管理テーブル１５２を管理し、アドレス管理テーブル１５１及びユーザ管理テーブル１５２のテーブル内容を動的に更新登録する。また、アドレス管理部１３は、アドレス管理テーブル１５１及びユーザ管理テーブル１５２のテーブル内容を参照して各種判定動作を実行するものである。図１６は、アドレス管理テーブル１５１のテーブル内容の一例を示す説明図である。図１６に示すアドレス管理テーブル１５１は、ユーザＩＤ１５１Ａ、端末ＩＤ１５１Ｂ、アプリＩＤ１５１Ｃ、格納先アドレス１５１Ｄ及び提供タイミング１５１Ｅの他に、コマンド１５１Ｇを対応付けて管理している。コマンド１５１Ｇは、格納先アドレス１５１Ｄで特定するＷｅｂアプリの実行内容である。

図１７は、ユーザ管理テーブル１５２のテーブル内容の一例を示す説明図である。図１７に示すユーザ管理テーブル１５２は、ユーザ毎に、所有の通信端末４に関わる管理リストを管理する。管理リストは、端末ＩＤ１５２Ａと、端末種別１５２Ｂと、接続状態１５２Ｃと、最終通知時刻１５２Ｄと、最終使用時刻１５２Ｅと、位置情報１５２Ｆと、通知不可時間帯１５２Ｇと、タグＩＤ１５２Ｈとを対応付けている。端末ＩＤ１５２Ａは、通信端末４を識別するＩＤである。端末種別１５２Ｂは、例えば、ＰＣ、携帯電話機やタブレット端末等の通信端末４の種別である。接続状態１５２Ｃは、通信端末４がＰＵＳＨサーバ２と通信可能な状態であるか否かを示すものである。接続状態１５２Ｃが“オン”の場合、通信端末４はＰＵＳＨサーバ２と通信可能な状態にある。接続状態１５２Ｃが“オフ”の場合、通信端末４はＰＵＳＨサーバ２と通信不可の状態にある。

また、アドレス管理部１３は、各Ｗｅｂアプリの属性情報を格納する図示せぬ属性情報テーブルを管理し、属性情報テーブルを参照して、各Ｗｅｂアプリが対応している端末種別や場所、更には、そのＷｅｂアプリに関わるリソースの格納先アドレスを認識するものである。

最終通知時刻１５２Ｄは、ＰＵＳＨサーバ２が当該通信端末４に最後に通信した時刻である。最終使用時刻１５２Ｅは、当該通信端末４をユーザが最後に使用した時刻である。尚、最終使用時刻１５２Ｅは、ネットワーク状態の検知以外に、通信端末４の各種デバイスに備えたセンサや外部センサの情報に基づき判断するものである。例えば、通信端末４がＰＣの場合、ＰＵＳＨサーバ２側でＰＣのキーボード入力を検知して、その時刻を最終使用時刻とする。また、例えば、通信端末４が携帯電話機の場合、ＰＵＳＨサーバ２側で、携帯電話機内部の振動センサや加速度センサ等で得た情報を収集し、その収集結果に基づき携帯電話機の使用時刻を最終使用時刻とする。尚、最終使用時刻を決定する方法は適宜変更可能である。

位置情報１５２Ｆは、通信端末４のＧＰＳ（Global Positioning System）機能や通信モジュールで得られた通信端末４の位置座標や場所名等の位置情報である。通知不可時間帯１５２Ｇは、ユーザ設定によるＷｅｂアプリの通知不可の時間帯である。尚、図中の「Ｄ＝｛０−９，２１−２４｝、Ｗ＝｛ＳＴ，ＳＵ｝」の意味は、「毎日０時〜９時、２１時〜２４時は通信不可、かつ、土曜日及び日曜日は終日通信不可」という意味である。タグＩＤ１５２Ｈは、通信端末４内蔵のＲＦＩＤタグを識別するＩＤである。

次に実施例５のＷｅｂアプリ提供システム１Ｄの動作について説明する。図１８は、ユーザ指定のアドレス提供処理に関わるＰＵＳＨサーバ２の処理動作の一例を示すフローチャートである。図１８に示すアドレス提供処理は、ユーザに対するＷｅｂアプリの送信依頼を検出すると、ユーザ所有の複数の通信端末４の内、ユーザが現在使用中の可能性が高い通信端末４にＷｅｂアプリのリソースに関わる格納先アドレス及びコマンドを提供する処理である。

図１８においてＰＵＳＨサーバ２のアドレス管理部１３は、特定ユーザに対するＷｅｂアプリの送信依頼を受信した場合、特定ユーザの管理リストをユーザ管理テーブル１５２から取得する（ステップＳ８１）。アドレス管理部１３は、特定ユーザの管理リストを取得すると、管理リスト内の端末種別１５２Ｂと、Ｗｅｂアプリの属性情報テーブルとに基づき、指定のＷｅｂアプリが端末種別限定のアプリであるか否かを判定する（ステップＳ８２）。尚、端末種別限定のアプリとは、特定の端末種別の通信端末４でしか実行できないＷｅｂアプリである。

アドレス管理部１３は、指定のＷｅｂアプリが端末種別限定のアプリである場合（ステップＳ８２肯定）、管理リスト内の接続状態１５２Ｃを参照して、接続状態がオン中の該当の通信端末４があるか否かを判定する（ステップＳ８３）。アドレス管理部１３は、接続状態がオン中の該当の通信端末４がある場合（ステップＳ８３肯定）、指定Ｗｅｂアプリを実行可能な通信端末４であると判断する。更に、アドレス管理部１３は、管理リストの位置情報１５２Ｆと、Ｗｅｂアプリの属性情報テーブルとに基づき、指定のＷｅｂアプリが場所限定のアプリであるか否かを判定する（ステップＳ８４）。尚、場所限定のアプリとは、特定の場所でしか実行を許可していないＷｅｂアプリである。アドレス管理部１３は、指定のＷｅｂアプリが場所限定のアプリである場合（ステップＳ８４肯定）、管理リスト内の接続状態１５２Ｃを参照して、接続状態がオン中の該当の通信端末４があるか否かを判定する（ステップＳ８５）。

更に、アドレス管理部１３は、接続状態がオン中の該当の通信端末４がある場合（ステップＳ８５肯定）、指定Ｗｅｂアプリが実行可能な場所にある通信端末４であると判断する。更に、アドレス管理部１３は、指定のＷｅｂアプリを提供する該当の通信端末４があるか否かを判定する（ステップＳ８６）。尚、該当の通信端末４には、例えば、通知不可時間帯１５２Ｇの条件もクリアにした指定Ｗｅｂアプリが実行可能な通信端末４を含めても良い。アドレス管理部１３は、該当の通信端末４がある場合（ステップＳ８６肯定）、管理リスト内の最終使用時刻１５２Ｅを参照して、該当の通信端末４の端末ＩＤの内、最新の最終使用時刻の端末ＩＤがあるか否かを判定する（ステップＳ８７）。

アドレス管理部１３は、最新の最終使用時刻の端末ＩＤがない場合（ステップＳ８７否定）、管理リスト内の最終通知時刻１５２Ｄを参照して、該当の通信端末４の端末ＩＤの内、最新の最終通知時刻の端末ＩＤを取得する（ステップＳ８８）。アドレス管理部１３は、最新の最終通知時刻の端末ＩＤを取得すると、該当の端末ＩＤに対応した該当Ｗｅｂアプリに関わる格納先アドレス及びコマンドをアドレス管理テーブル１５１から取得する（ステップＳ８９）。

ＰＵＳＨ送信部１５は、該当の端末ＩＤに対応した該当Ｗｅｂアプリに関わる格納先アドレス及びコマンドを取得すると、格納先アドレス及びコマンドを該当の端末ＩＤに対応した通信端末４に送信する（ステップＳ９０）。ＰＵＳＨ送信部１５は、ステップＳ９０に対する格納先アドレス及びコマンドの送信が成功したか否かを判定する（ステップＳ９１）。ＰＵＳＨ送信部１５は、格納先アドレス及びコマンドの送信が成功した場合（ステップＳ９１肯定）、図１８に示す処理動作を終了する。

アドレス管理部１３は、格納先アドレス及びコマンドの送信が成功しなかった場合（ステップＳ９１否定）、該当の通信端末４の内、２番目に新しい次位の最終使用時刻又は最終通知時刻の端末ＩＤを取得する（ステップＳ９２）。更に、アドレス管理部１３は、端末ＩＤに対応した格納先アドレス及びコマンドを取得すべく、ステップＳ８９に移行する。

また、アドレス管理部１３は、最新の最終使用時刻の端末ＩＤがある場合（ステップＳ８７肯定）、当該端末ＩＤをアドレス管理テーブル１５１から取得する（ステップＳ９３）。更に、アドレス管理部１３は、当該端末ＩＤに対応した格納先アドレス及びコマンドを取得すべく、ステップＳ８９に移行する。

また、アドレス管理部１３は、該当の通信端末４がない場合（ステップＳ８６否定）、該当Ｗｅｂアプリに関わる格納先アドレス及びコマンドの送信を保留し（ステップＳ９４）、図１８に示す処理動作を終了する。尚、保留の場合、ＰＵＳＨ送信部１５は、該当の通信端末４が接続状態になった場合に、当該通信端末４に対してＷｅｂアプリに関わる格納先アドレス及びコマンドを再送するものである。また、アドレス管理部１３は、指定のＷｅｂアプリが端末種別限定のアプリでない場合（ステップＳ８２否定）、場所限定のアプリであるか否かを判定すべく、ステップＳ８４に移行する。

また、アドレス管理部１３は、接続状態がオン中の該当の通信端末４がない場合（ステップＳ８３否定、ステップＳ８５否定）、該当Ｗｅｂアプリに関わる格納先アドレス及びコマンドの送信を保留し（ステップＳ９５）、図１８に示す処理動作を終了する。尚、保留の場合、ＰＵＳＨ送信部１５は、該当の通信端末４が接続状態になった場合に、当該通信端末４に対してＷｅｂアプリに関わる格納先アドレス及びコマンドを再送するものである。

図１８に示す処理では、ＰＵＳＨサーバ２がユーザに対する指定Ｗｅｂアプリの送信依頼を受信した場合、指定ユーザ所有の複数の通信端末４の内、指定Ｗｅｂアプリに適用した現在使用している可能性の高い通信端末４の端末ＩＤを取得する。更に、ＰＵＳＨサーバ２は、取得した端末ＩＤの通信端末４に対して指定のＷｅｂアプリに関わる格納先アドレス及びコマンドを送信する。その結果、ＰＵＳＨサーバ２は、指定ユーザ所有の複数の通信端末４の内、当該ユーザが現在使用している可能性の高い通信端末４に対して指定のＷｅｂアプリに関わる格納先アドレス及びコマンドを通知できる。

また、ＰＵＳＨサーバ２は、指定ユーザ所有の複数の通信端末４の内、端末種別限定のアプリに対応した現在使用している可能性の高い通信端末４に対して指定のＷｅｂアプリに関わる格納先アドレス及びコマンドを送信する。ＰＵＳＨサーバ２では、携帯電話機限定のアプリであるにも関わらず、現在使用している可能性の高い通信端末４がＰＣの場合に、当該ＰＣに対して携帯電話機限定のアプリの格納先アドレスを送信してしまうような事態を回避できる。

また、ＰＵＳＨサーバ２は、指定ユーザ所有の複数の通信端末４の内、場所限定のアプリに対応した現在使用している可能性の高い通信端末４に対して指定のＷｅｂアプリに関わる格納先アドレス及びコマンドを送信する。ＰＵＳＨサーバ２では、会社内限定の機密書類閲覧に関わるＷｅｂアプリであるにも関わらず、現在使用している可能性が高い通信端末４が社外である自宅のＰＣに対して機密書類閲覧のアプリの格納先アドレスを送信してしまうような事態を回避できる。

そして、通信端末４は、ＰＵＳＨサーバ２から格納先アドレス及びコマンドを受信した場合、格納先アドレスで指定のＷｅｂアプリのリソースをＷｅｂサーバ３から取得して、コマンドに基づき、取得されたＷｅｂアプリを実行する。

実施例５では、ＰＵＳＨサーバ２がユーザに対する指定Ｗｅｂアプリの送信依頼を受信した場合、指定ユーザ所有の複数の通信端末４の内、指定Ｗｅｂアプリの端末種別限定や場所限定に適用した、現在使用している可能性の高い通信端末４の端末ＩＤを取得する。更に、ＰＵＳＨサーバ２は、取得された端末ＩＤの通信端末４に対して指定のＷｅｂアプリの格納先アドレス及びコマンドを送信する。その結果、ＰＵＳＨサーバ２は、指定ユーザ所有の複数の通信端末４の内、当該ユーザが現在使用している可能性の高い通信端末４に対して指定のＷｅｂアプリに関わる格納先アドレス及びコマンドを通知できる。

例えば、上司が部下の出張申請を承認する場合、通常、上司は、自分の会社のＰＣ等の通信端末４を使用して出張承認用のＷｅｂアプリで出張承認することになる。しかしながら、上司が外出先の場合、会社のＰＣを持参していないため、出張承認ができない。そこで、部下は、上司を指定した出張承認用Ｗｅｂアプリの送信依頼をＰＵＳＨサーバ２に送信する。ＰＵＳＨサーバ２は、送信依頼を受信した場合、上司所有の複数の通信端末４の内、現在使用している可能性の高い通信端末４、すなわち外出先に持参している通信端末４の端末ＩＤを取得する。そして、ＰＵＳＨサーバ２は、取得された端末ＩＤの通信端末４に対して出張承認用Ｗｅｂアプリの格納先アドレス及びコマンドを送信する。そして、通信端末４は、格納先アドレスに基づき、出張承認用ＷｅｂアプリのリソースをＷｅｂサーバ３から取得し、コマンドに基づき、取得された出張承認用Ｗｅｂアプリを実行する。その結果、上司は、外出先に持参した通信端末４の出張承認用Ｗｅｂアプリを使用して出張承認ができる。

尚、上記実施例５では、端末種別限定アプリ、場所限定種別アプリ、接続状態、最終通知時刻、最終使用時刻、通知不可時間帯の全ての条件をクリアした通信端末４に指定Ｗｅｂアプリの格納先アドレス及びコマンドを送信した。しかしながら、ＰＵＳＨ送信部１５は、これら条件の一部をクリアした通信端末４でも、指定Ｗｅｂアプリの格納先アドレス及びコマンドを送信するようにしても良く、その条件は、適宜選択変更可能である。

また、上記実施例５では、ＰＵＳＨサーバ２がユーザに対する指定Ｗｅｂアプリの送信依頼を受信した場合、指定ユーザ所有の複数の通信端末４の内、現在使用している可能性の高い通信端末４に格納先アドレス及びコマンドを送信した。しかしながら、ＰＵＳＨサーバ２は、現在使用している可能性の高い通信端末４を１台に限定するものではなく、複数台としても良い。また、ＰＵＳＨサーバ２は、現在使用している可能性の高い通信端末４に格納先アドレス及びコマンドを送信したが、ユーザ所有の全ての通信端末４に格納先アドレス及びコマンドを送信しても良い。

また、図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

更に、各装置で行われる各種処理機能は、ＣＰＵ（Central Processing Unit）（又はＭＰＵ（Micro Processing Unit）、ＭＣＵ（Micro Controller Unit）等のマイクロ・コンピュータ）上で、その全部又は任意の一部を実行するようにしても良い。また、各種処理機能は、ＣＰＵ（又はＭＰＵ、ＭＣＵ等のマイクロ・コンピュータ）で解析実行するプログラム上、又はワイヤードロジックによるハードウェア上で、その全部又は任意の一部を実行するようにしても良いことは言うまでもない。

ところで、本実施例で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図１９を用いて、上記の実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図１９は、情報処理プログラムを実行するコンピュータを示す説明図である。

図１９に示すように、情報処理プログラムとしてのコンピュータ１００では、ＨＤＤ（Hard Disk Drive）１１０、ＲＡＭ(Random Access Memory)１２０、ＲＯＭ（Read Only Memory）１３０及びＣＰＵ１４０がバス１５０を介して接続される。

そして、ＲＯＭ１３０若しくはＨＤＤ１１０には、上記の実施例と同様の機能を発揮する情報処理プログラムが予め記憶されている。尚、ＲＯＭ１３０及びＨＤＤ１１０ではなく、図示せぬドライブでコンピュータ読取可能な記録媒体に情報処理プログラムが記録されていても良い。また、記録媒体としては、例えば、ＣＤ−ＲＯＭ、ＤＶＤディスク、ＵＳＢメモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリ等でも良い。情報処理プログラムとしては、図１９に示すように、検出プログラム１３１及び提供プログラム１３２である。尚、プログラム１３１及び１３２については、図１に示したＰＵＳＨサーバ２の各構成要素と同様、適宜統合又は分散してもよい。

そして、ＣＰＵ１４０が、これらのプログラム１３１及び１３２をＲＯＭ１３０から読み出して実行する。そして、図１９に示すように、各プログラム１３１及び１３２は、検出プロセス１４１及び提供プロセス１４２として機能するようになる。

ＲＡＭ１２０は、通信端末４を識別する端末ＩＤと、当該通信端末４に提供するＷｅｂアプリのリソースの格納先アドレスと、当該通信端末４に提供するＷｅｂアプリの提供タイミングとを対応付けて管理する。ＣＰＵ１４０は、ＲＡＭ１２０内の提供タイミングを検出する。ＣＰＵ１４０は、提供タイミングを検出した場合、提供タイミングに関わる通信端末４に対して、当該提供タイミングに関わるＷｅｂアプリのリソースを当該通信端末４に提供すべく、図示せぬ通信部を使用して、当該リソースの格納先アドレスを提供する。その結果、通信端末４のユーザは、アプリ取得に関わる要求操作を実行しなくても、必要な時に必要なＷｅｂアプリを提供タイミングに応じて自動的に取得できる。

１ Ｗｅｂアプリ提供システム
２ ＰＵＳＨサーバ
３ Ｗｅｂサーバ
４ 通信端末
１３ アドレス管理部
１４ タイミング監視部
１５ ＰＵＳＨ送信部
１６ イベント受信部
２１ アプリ管理部
２２ アプリ提供部
４２ アプリキャッシュ
４３ アプリ実行部
５１ ＰＵＳＨ受信部
５２ アプリ取得部
１５１ アドレス管理テーブル
１５２ ユーザ管理テーブル

Claims (7)

1. 通信装置と、Ｗｅｂアプリのリソース情報の格納先アドレスを管理するアドレス管理装置とを有し、
   前記アドレス管理装置は、
   前記通信装置を識別する識別情報と、当該通信装置に提供するＷｅｂアプリに関わるリソース情報の格納先アドレスと、当該通信装置に提供するＷｅｂアプリの提供タイミングとを対応付けて管理するアドレス管理部と、
   現在タイミングが前記提供タイミングであるか否かを監視するタイミング監視部と、
   前記タイミング監視部にて現在タイミングが前記提供タイミングである場合に、当該提供タイミングに関わる前記通信装置に対して、当該提供タイミングに関わる前記Ｗｅｂアプリのリソース情報の格納先アドレスを提供する提供部と
   を有し、
   前記通信装置は、
   前記アドレス管理装置から前記格納先アドレスを受信した場合、当該格納先アドレスに基づき、前記Ｗｅｂアプリのリソース情報を要求するアプリ要求を実行する要求部と、
   前記アプリ要求に応じて提供された前記Ｗｅｂアプリのリソース情報を一時的に保存する一時ストレージと、
   前記一時ストレージに保存されたリソース情報をＷｅｂブラウザのキャッシュに同期させるキャッシュ同期部と、
   キャッシュに保存されたリソース情報に基づき、当該Ｗｅｂアプリを実行可能なアプリ実行部と
   を有することを特徴とするアプリ提供システム。
2. 前記アドレス管理部は、
   前記通信装置に対するＷｅｂアプリの送信依頼を受信した場合、当該通信装置の前記識別情報及び、当該送信依頼のＷｅｂアプリに関わるリソース情報の格納先アドレスを対応付けて、当該通信装置に対して前記格納先アドレスを即時提供する前記提供タイミングを管理することを特徴とする請求項１に記載のアプリ提供システム。
3. 前記アドレス管理部は、
   前記識別情報、前記格納先アドレス及び前記提供タイミングに対応付けて、当該Ｗｅｂアプリに関わるコマンドを管理しておき、
   前記提供部は、
   前記タイミング監視部にて現在タイミングが前記提供タイミングである場合に、当該提供タイミングに関わる前記通信装置に対して、当該提供タイミングに関わる前記Ｗｅｂアプリの前記格納先アドレス及び前記コマンドを提供し、
   前記アプリ実行部は、
   前記アドレス管理装置から受信した前記コマンドに基づき、当該Ｗｅｂアプリを実行することを特徴とする請求項１又は２に記載のアプリ提供システム。
4. 前記アドレス管理部は、
   前記識別情報、前記格納先アドレス及び前記提供タイミングを対応付けて、当該通信装置を所有する所有者を識別する所有者識別情報を管理しておき、
   前記タイミング監視部は、
   特定の所有者の通信装置に対するＷｅｂアプリの送信依頼を受信した場合、当該所有者を識別する前記所有者識別情報に対応した前記識別情報の内、所定条件を満たした識別情報を特定し、現在タイミングが、特定された識別情報に対応する提供タイミングであるか否かを監視することを特徴とする請求項１〜３の何れか一つに記載のアプリ提供システム。
5. 通信装置と、Ｗｅｂアプリのリソース情報の格納先アドレスを管理するアドレス管理装置とを有するアプリ提供システムのアプリ提供方法であって、
   前記アドレス管理装置は、
   前記通信装置を識別する識別情報と、当該通信装置に提供するＷｅｂアプリに関わるリソース情報の格納先アドレスと、当該通信装置に提供するＷｅｂアプリの提供タイミングとを対応付けたアドレス管理部を参照して、現在タイミングが前記提供タイミングであるか否かを監視し、現在タイミングが前記提供タイミングである場合に、当該提供タイミングに関わる前記通信装置に対して、当該提供タイミングに関わる前記Ｗｅｂアプリのリソース情報の格納先アドレスを提供し、
   前記通信装置は、
   前記アドレス管理装置から前記格納先アドレスを受信した場合、当該格納先アドレスに基づき、前記Ｗｅｂアプリのリソース情報を要求するアプリ要求を実行し、前記アプリ要求に応じて提供された前記Ｗｅｂアプリのリソース情報を一時保存し、保存されたリソース情報をＷｅｂブラウザのキャッシュに同期させ、当該キャッシュされた前記Ｗｅｂアプリのリソース情報に基づき、当該Ｗｅｂアプリを実行する
   各処理を実行することを特徴とするアプリ提供方法。
6. 通信装置を識別する識別情報と、当該通信装置に提供するＷｅｂアプリのリソース情報の格納先アドレスと、当該通信装置に提供するＷｅｂアプリの提供タイミングとを対応付けたアドレス管理部と、
   現在タイミングが前記提供タイミングであるか否かを監視するタイミング監視部と、
   前記タイミング監視部にて現在タイミングが前記提供タイミングである場合に、当該提供タイミングに関わる前記通信装置に対して、当該提供タイミングに関わる前記Ｗｅｂアプリのリソース情報を当該通信装置に提供すべく、当該リソース情報の格納先アドレスを提供するアドレス提供部と
   を有することを特徴とする情報処理装置。
7. コンピュータに、
   通信装置を識別する識別情報と、当該通信装置に提供するＷｅｂアプリのリソース情報の格納先アドレスと、当該通信装置に提供するＷｅｂアプリの提供タイミングとを対応付けたアドレス管理部を参照して、現在タイミングが前記提供タイミングであるか否かを監視し、
   現在タイミングが前記提供タイミングである場合に、当該提供タイミングに関わる前記通信装置に対して、当該提供タイミングに関わる前記Ｗｅｂアプリのリソース情報を当該通信装置に提供すべく、当該リソース情報の格納先アドレスを提供する
   処理を実行させることを特徴とする情報処理プログラム。

Images