JP2012216162A - アプリ提供システム、アプリ提供方法及びアプリ提供プログラム - Google Patents

Abstract

【課題】クライアントが、オフライン時でもＷｅｂアプリ実行時に最新の編集コンテンツを取得できる。
【解決手段】通信端末４と、通信端末４に対してＷｅｂアプリのリソースを提供するＷｅｂサーバ３とを有する。Ｗｅｂサーバ３は、通信端末４で実行するＷｅｂアプリで編集したコンテンツを検出した場合、当該Ｗｅｂアプリのリソース内に編集したコンテンツを格納する格納制御部２４を有する。更に、Ｗｅｂサーバ３は、通信端末４からＷｅｂアプリを要求するアプリ要求を検出した場合、当該Ｗｅｂアプリのリソースを、当該アプリ要求を実行した通信端末４に提供するアプリ提供部２２を有する。
【選択図】図１

Description

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

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

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

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

通常、Ｗｅｂブラウザは、Ｗｅｂアプリのリソース一覧を記述したマニフェストファイルを見て、Ｗｅｂサーバ側にあるリソースに更新があれば自動でキャッシュされたリソースも更新するようになっている。一方でマニフェストに記述できないＷｅｂアプリのリソース以外のデータ、例えば、上記クライアントで作成され、Ｗｅｂサーバにアップロードされたコンテンツファイルは自動で更新することができない。そのため、Ｗｅｂアプリを実行したときに、Ｗｅｂサーバから最新コンテンツを取得するようにＷｅｂアプリを記述する方法が一般的に用いられる。

しかしながら、クライアントは、オフライン時にＷｅｂアプリを実行したとしても最新の編集コンテンツを取得できない。例えば、クライアントがＷｅｂアプリを使用してコンテンツを編集した後、他の端末から当該Ｗｅｂアプリを使用して先ほど編集したコンテンツを編集する場合を想定したとする。この場合、他の端末でＷｅｂアプリを使用したクライアントは、オフライン時にＷｅｂアプリを実行したとしても、最新の編集コンテンツを取得できないため、各端末のローカルに格納された編集コンテンツの内容が異なってしまう。その結果、クライアントは、当該最新の編集コンテンツを再編集できないことになる。

一つの側面では、クライアント側がオフライン時でもＷｅｂアプリ実行時に最新の編集コンテンツを取得できるアプリ提供システム、アプリ提供方法及びアプリ提供プログラムを提供することを目的とする。

開示のシステムは、一つの態様において、プロセッサを備えた通信装置と、前記通信装置に対してＷｅｂアプリのリソースを提供する、プロセッサを備えたアプリ提供装置とを有する。前記アプリ提供装置のプロセッサは、前記通信装置で実行する前記Ｗｅｂアプリで編集したコンテンツを検出した場合、当該Ｗｅｂアプリのリソース内に編集したコンテンツを格納する。更に、前記プロセッサは、前記通信装置から前記Ｗｅｂアプリを要求するアプリ要求を検出した場合、当該Ｗｅｂアプリのリソースを、当該アプリ要求を実行した前記通信装置に提供する。更に、前記通信装置のプロセッサは、前記アプリ提供装置から前記Ｗｅｂアプリのリソースを受信した場合、当該リソースを一時保存する。更に、前記通信装置のプロセッサは、保存されたリソースをＷｅｂブラウザのキャッシュに同期させ、当該キャッシュされた前記リソースに基づき、Ｗｅｂアプリを実行する。更に、前記通信装置のプロセッサは、キャッシュされた前記リソースに基づき、リソース内に格納した前記コンテンツを復元する。

開示のシステムでは、クライアント側がオフライン時でもＷｅｂアプリ実行時に最新の編集コンテンツを取得できる。

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

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

本出願人は、ＰＵＳＨ方式のＷｅｂアプリ提供システムを考案している。図２は、Ｗｅｂアプリ提供システムの使用形態の一例を示す説明図である。図２に示すＷｅｂアプリ提供システム１Ａは、ＰＵＳＨサーバ２と、Ｗｅｂサーバ３と、パソコン４Ａと、タブレット端末４Ｂとを有する。尚、パソコン４Ａ及びタブレット端末４Ｂの所有者は、例えば、同一ユーザとする。

パソコン４Ａは、Ｗｅｂブラウザを使用してＷｅｂサーバ３とオンライン状態とし、Ｗｅｂサーバ３から、例えば、文書作成ソフトのＷｅｂアプリを取得する。パソコン４Ａは、Ｗｅｂアプリを使用してコンテンツを作成及び編集する（ステップＳ１１）。パソコン４Ａは、その作成及び編集したコンテンツをローカルに格納すると共に、そのコンテンツをＷｅｂサーバ３にアップロードする（ステップＳ１２）。そして、Ｗｅｂサーバ３は、パソコン４Ａからアップロードされたコンテンツを当該Ｗｅｂアプリに対応付けて格納する（ステップＳ１３）。その結果、パソコン４Ａ及びＷｅｂサーバ３には、同一コンテンツが格納されたことになる。

また、ＰＵＳＨサーバ２は、Ｗｅｂアプリの更新、例えば、編集コンテンツの更新を検知すると（ステップＳ１４）、例えば、タブレット端末４Ｂに対して、更新したＷｅｂアプリのリソースに関わる格納先アドレスをＰＵＳＨ送信する（ステップＳ１５）。そして、タブレット端末４Ｂは、格納先アドレスを受信した場合、格納先アドレスに基づき、当該更新したＷｅｂアプリのリソースをＷｅｂサーバ３から取得する（ステップＳ１６）。タブレット端末４Ｂは、Ｗｅｂサーバ３から取得されたＷｅｂアプリのリソースをキャッシュし、キャッシュされたリソースに基づきＷｅｂアプリを実行する（ステップＳ１７）。その結果、タブレット端末４Ｂは、キャッシュされたリソースに基づき、オフラインでもローカルでＷｅｂアプリを実行できる。

更に、タブレット端末４Ｂは、Ｗｅｂサーバ３とオンライン中であれば、Ｗｅｂアプリ実行時に、Ｗｅｂサーバ３に格納された最新の編集コンテンツを取得できる。その結果、パソコン４Ａ及びタブレット端末４Ｂのローカルには、同一コンテンツが格納されたことになる。しかしながら、タブレット端末４Ｂは、Ｗｅｂサーバ３とオンライン時にＷｅｂアプリを実行しないと、Ｗｅｂサーバ３に格納された編集コンテンツを取得できない。その結果、オフライン時には、パソコン４Ａ及びタブレット端末４Ｂのローカルに格納される編集コンテンツが異なる（ステップＳ１８）。従って、タブレット端末４Ｂは、パソコン４Ａ側で作成された編集コンテンツを再編集できない。そこで、本出願人は、オフライン時でもＷｅｂアプリ実行時に最新の編集データを取得できるＷｅｂアプリ提供システムを案出した。

図１は、実施例１のＷｅｂアプリ提供システム内部の一例を示す機能ブロック図である。尚、図２に示すＷｅｂアプリ提供システム１Ａと同一の構成には同一符号を付すことで、その重複する構成及び動作の説明については省略する。図１に示すＷｅｂアプリ提供システム１は、ＰＵＳＨサーバ２と、Ｗｅｂサーバ３と、通信端末４とを有する。尚、ＰＵＳＨサーバ２、Ｗｅｂサーバ３及び通信端末４は、例えば、無線や有線等の通信網を通じて通信接続する。ＰＵＳＨサーバ２は、更新監視部１２と、アドレス管理部１３と、タイミング監視部１４と、ＰＵＳＨ送信部１５とを有する。尚、リソースとは、Ｗｅｂアプリの構成要素、例えばＨＴＭＬ、ＣＳＳ及びＪａｖａＳｃｒｉｐｔである。更新監視部１２は、各Ｗｅｂサーバ３と通信してＷｅｂアプリの更新状況を監視する。尚、Ｗｅｂアプリの更新状況には、Ｗｅｂアプリを使用して編集した編集データの更新も含む。また、更新監視部１２は、各Ｗｅｂサーバ３のＷｅｂアプリの更新状況を集中管理するデータベースにアクセスし、各Ｗｅｂアプリの更新状況を監視しても良い。

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

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

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

各Ｗｅｂサーバ３は、アプリ管理部２１と、アプリ提供部２２と、コンテンツ格納部２３と、格納制御部２４と、コンテンツ取得部２５とを有する。尚、アプリ提供部２２、格納制御部２４及びコンテンツ取得部２５等は、Ｗｅｂサーバ３内の図示せぬプロセッサで実行する。アプリ管理部２１は、格納先アドレス毎にＷｅｂアプリのリソース及びマニフェスト等を格納したアプリパッケージ２１Ａを管理する。アプリパッケージ２１Ａは、マニフェスト２１０と、リソース２２０とを有する。図４は、マニフェスト２１０及びリソース２２０の一例を示す説明図である。マニフェスト２１０は、Ｗｅｂアプリのリソース２２０のリスト一覧である。マニフェスト２１０は、トップページを示すＩｎｄｅｘ．ｈｔｍｌ２１１と、復元プログラムを示すＲｅｓｔｏｒｅ．ｊｓ２１２と、画像ファイルを示すａａａ．Ｊｐｇ２１３と、コンテンツを格納したコンテナファイルを示すＤａｔａ．ｊｓｏｎ２１４とを有する。

リソース２２０は、Ｗｅｂアプリに使用するリソースの内容である。リソース２２０には、トップページ自体であるＩｎｄｅｘ．ｈｔｍｌ２２１と、復元プログラム自体であるＲｅｓｔｏｒｅ．ｊｓ２２２とを有する。また、リソース２２０には、画像ファイル自体であるａａａ．Ｊｐｇ２２３と、コンテンツを含むコンテナファイルであるＤａｔａ．ｊｓｏｎ２２４とを有する。尚、ｊｓｏｎ（JavaScript Object Notation）ファイルは、Ｗｅｂブラウザ上で実行されるＪａｖａＳｃｒｉｐｔプログラムが解釈可能なデータ形式をもつデータファイルである。また、復元プログラムは、Ｄａｔａ．Ｊｓｏｎファイルからコンテンツを抽出し、ローカルストレージ内にコンテンツを復元するプログラムである。また、Ｄａｔａ．ｊｓｏｎ２２４は、格納されたコンテンツの属性情報及び、変換されたコンテンツのデータを含む。

コンテンツ取得部２５は、通信端末４側のＷｅｂアプリを使用して編集したコンテンツのアップロードに応じて、編集コンテンツを取得する。更に、コンテンツ格納部２３は、コンテンツ取得部２５にて取得されたＷｅｂアプリの編集コンテンツをコンテンツファイル形式で格納する。格納制御部２４は、変換部２４Ａと、格納部２４Ｂとを有する。変換部２４Ａは、コンテンツ格納部２３にて格納された編集コンテンツをリソース内の復元プログラムが解釈可能なデータ形式、例えば、ＪＳＯＮ形式に変換する。格納部２４Ｂは、ＪＳＯＮ形式に変換されたデータをリソース内のコンテナファイル、例えばＤａｔａ．Ｊｓｏｎファイル内に格納する。アプリ提供部２２は、通信端末４からのアプリ要求を検出すると、当該アプリ要求に対するＷｅｂアプリのマニフェスト２１０及びリソース２２０をアプリ管理部２１から取得する。更に、アプリ提供部２２は、取得されたＷｅｂアプリのマニフェスト２１０及びリソース２２０を、アプリ要求を実行した通信端末４に提供する。

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

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

Ｗｅｂブラウザ４０は、キャッシュ同期部４１と、アプリキャッシュ４２と、アプリ実行部４３と、ローカルストレージ４５とを有する。キャッシュ同期部４１は、一時ストレージ５３に登録済みのリソースをＷｅｂブラウザが解釈可能なデータ形式に変換し、アプリキャッシュ４２にキャッシュする。アプリ実行部４３は、アプリキャッシュ４２にキャッシュされたリソースに基づき、Ｗｅｂアプリを実行する。更に、アプリ実行部４３は、アプリキャッシュ４２にキャッシュされたリソースの復元プログラム（Ｒｅｓｔｏｒｅ．ｊｓ）を実行する。アプリ実行部４３は、復元プログラムを実行することで、リソース内のＤａｔａ．ｊｓｏｎファイル内に格納されたコンテンツを復元し、復元されたコンテンツをローカルストレージ４５内に格納する。尚、キャッシュ同期部４１は、Ｗｅｂブラウザ外にあっても良い。

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

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

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

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

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

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

図６は、コンテンツ更新処理に関わるＷｅｂサーバ３の処理動作の一例を示すフローチャートである。図６に示すコンテンツ更新処理では、Ｗｅｂアプリで編集したコンテンツを通信端末４から取得した場合、編集したコンテンツを当該Ｗｅｂアプリのリソースのコンテナ内に格納することでコンテンツを更新する処理である。図６においてＷｅｂサーバ３のコンテンツ取得部２５は、通信端末４からＷｅｂアプリで編集したコンテンツを取得する（ステップＳ２１）。Ｗｅｂサーバ３のコンテンツ格納部２３は、編集したコンテンツを取得すると、当該Ｗｅｂアプリの端末ＩＤ又はユーザＩＤ毎に編集コンテンツを格納する（ステップＳ２２）。Ｗｅｂサーバ３の格納制御部２４の変換部２４Ａは、格納されたコンテンツを復元プログラムが解釈可能なデータ形式、例えばＪＳＯＮ形式のデータに変換する（ステップＳ２３）。

更に、格納制御部２４内の格納部２４Ｂは、ＪＳＯＮ形式データに変換されたコンテンツをリソース内のコンテナファイルであるＤａｔａ．ｊｓｏｎファイルに格納する（ステップＳ２４）。格納部２４Ｂは、リソースのコンテナファイルを上記作成した新しいコンテナファイルＤａｔａ．ｊｓｏｎに置き換えることで（ステップＳ２５）、図６に示す処理動作を終了する。その結果、ＰＵＳＨサーバ２は、Ｄａｔａ．ｊｓｏｎファイルの更新日付情報が変わったことでデータ更新を認識することになる。

図６に示すコンテンツ更新処理では、Ｗｅｂサーバ３は、Ｗｅｂアプリで編集したコンテンツを通信端末４から取得した場合、取得されたコンテンツを特定のデータ形式でＷｅｂアプリのリソース内にあるＤａｔａ．Ｊｓｏｎファイルに格納する。そして、コンテナファイルが新しいものに置き換わるとデータの更新日付情報が変わることにより、Ｗｅｂアプリのデータ更新があったことが認識される。

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

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

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

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

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

Ｗｅｂブラウザ４０のアプリ実行部４３は、Ｗｅｂブラウザ４０が起動済みの場合（ステップＳ４７肯定）、アプリキャッシュ４２にキャッシュされたリソースに基づきＷｅｂアプリを実行する（ステップＳ４８）。更に、Ｗｅｂブラウザ４０上で実行される復元プログラムは、リソースのコンテナ内にコンテンツがあるか否かを判定する（ステップＳ４９）。復元プログラムは、リソースのコンテナ内にコンテンツがある場合（ステップＳ４９肯定）、リソース内のＤａｔａ．Ｊｓｏｎファイルからコンテンツを復元する（ステップＳ５０）。復元プログラムは、復元されたコンテンツをローカルストレージ４５内に格納することでコンテンツ更新し（ステップＳ５１）、図８に示す処理動作を終了する。

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

また、アプリ取得部５２は、一時ストレージ５３に登録済みのリソースがない場合（ステップＳ５３否定）、図８に示す処理動作を終了する。また、復元プログラムは、リソースのコンテナ内にコンテンツがない場合（ステップＳ４９否定）、図８に示す処理動作を終了する。また、アプリ取得部５２は、リソースを取得しなかった場合（ステップＳ４３否定）、リソースを取得したか否かを判定すべく、ステップＳ４３に移行する。また、ＣＰＵ３５は、Ｗｅｂブラウザ４０が起動済みでない場合（ステップＳ４７否定）、Ｗｅｂブラウザ４０を起動し（ステップＳ５２）、ステップＳ４８に移行する。

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

Ｗｅｂアプリ取得処理では、Ｗｅｂブラウザ４０が起動済みでなくても、Ｗｅｂアプリのリソースを一時ストレージ５３に登録できる。その結果、Ｗｅｂブラウザ４０が起動しなくても、提供タイミングに応じたＷｅｂアプリを自動取得できる。

Ｗｅｂアプリ取得処理では、一時ストレージ５３に登録済みのリソースを読み出し、リソースをアプリキャッシュ４２にキャッシュする。その結果、提供タイミングに応じたＷｅｂアプリを自動取得できる。

更に、Ｗｅｂアプリ取得処理では、アプリキャッシュ４２にキャッシュされたリソースのコンテナ内にコンテンツがある場合、リソース内の復元プログラムに基づきコンテンツを復元し、復元されたコンテンツをローカルストレージ４５に格納する。その結果、クライアントは、オフラインでも、Ｗｅｂアプリ実行時に最新のコンテンツを取得できる。

次に、通信端末４のＷｅｂブラウザ４０がＷｅｂサーバ３に対してＷｅｂアプリのリソースを取得する際の動作について説明する。図９は、Ｗｅｂブラウザ４０及びＷｅｂサーバ３間のリソース取得に関わる処理動作の一例を示す説明図である。図９に示す通信端末４のＷｅｂブラウザ４０は、リンク先のエントリページ取得リクエストをＷｅｂサーバ３に送信する（ステップＳ６２）。Ｗｅｂサーバ３は、エントリページ取得リクエストを検出すると、エントリページをＷｅｂブラウザ４０に送信する（ステップＳ６３）。Ｗｅｂブラウザ４０は、エントリページを取得すると、エントリページ内のマニフェストを検出する（ステップＳ６４）。Ｗｅｂブラウザ４０は、マニフェストに基づきマニフェスト取得リクエストをＷｅｂサーバ３に送信する（ステップＳ６５）。

Ｗｅｂサーバ３は、マニフェスト取得リクエストを検出すると、Ｗｅｂアプリのアプリパッケージ２１Ａ内のマニフェスト２１０をＷｅｂブラウザ４０に送信する（ステップＳ６６）。Ｗｅｂブラウザ４０は、マニフェスト２１０を取得すると、マニフェスト２１０を解析し、取得すべきＷｅｂアプリのリソース一覧を抽出する（ステップＳ６７）。Ｗｅｂブラウザ４０は、リソース一覧を抽出すると、マニフェストに記述されたＨＴＭＬファイルの取得リクエストをＷｅｂサーバ３に送信する（ステップＳ６８）。更に、Ｗｅｂサーバ３は、マニフェストに記述されたリソースの取得リクエストに応じて、リソースをＷｅｂブラウザ４０に送信する（ステップＳ６９）。尚、Ｗｅｂサーバ３は、ＷｅｂアプリのリソースをＷｅｂブラウザ４０に送信したが、２回目以降は更新されたファイル、例えば、コンテンツを送信しても良い。Ｗｅｂブラウザ４０は、リソースを取得すると、取得されたリソースをアプリキャッシュ４２にキャッシュする（ステップＳ７０）。Ｗｅｂブラウザ４０は、キャッシュされたリソースに基づき、Ｗｅｂアプリを実行する（ステップＳ７１）。

図１０は、実施例１のＷｅｂアプリ提供システム１の使用形態の一例を示す説明図である。尚、図１０の通信端末４としてのパソコン４Ａ及びタブレット端末４Ｂは同一ユーザである。図１０に示すパソコン４Ａは、Ｗｅｂブラウザを使用してＷｅｂサーバ３とオンライン状態とし、Ｗｅｂサーバ３から、例えば、文書作成ソフトのＷｅｂアプリを取得する。パソコン４Ａは、Ｗｅｂアプリを使用してコンテンツを作成及び編集する（ステップＳ８１）。パソコン４Ａは、その作成及び編集したコンテンツをローカルストレージ４５に格納すると共に、Ｗｅｂサーバ３にアップロードする（ステップＳ８２）。Ｗｅｂサーバ３は、パソコン４Ａからアップロードされたコンテンツを当該Ｗｅｂアプリに対応付けてコンテンツ格納部２３に格納する（ステップＳ８３）。そして、Ｗｅｂサーバ３は、Ｗｅｂアプリのリソースのコンテナ内にコンテンツを格納する。尚、この際、Ｗｅｂサーバ３とパソコン４Ａとは、同一コンテンツが格納されたことになる。

また、ＰＵＳＨサーバ２は、Ｗｅｂアプリの更新、例えば、編集コンテンツの更新を検知すると（ステップＳ８４）、例えば、タブレット端末４Ｂに対して、更新したＷｅｂアプリのリソースに関わる格納先アドレスをＰＵＳＨ送信する（ステップＳ８５）。そして、タブレット端末４Ｂは、格納先アドレスを受信した場合、格納先アドレスに基づき、当該更新したＷｅｂアプリのリソースをＷｅｂサーバ３から取得する（ステップＳ８６）。この際、Ｗｅｂアプリのリソースのコンテナ内には、編集コンテンツが格納されている。

タブレット端末４Ｂは、Ｗｅｂサーバ３から取得されたＷｅｂアプリのリソースをキャッシュし、キャッシュされたリソースに基づきＷｅｂアプリを実行する（ステップＳ８７）。更に、タブレット端末４Ｂは、キャッシュされたリソース内の復元プログラムでコンテナ内に格納された編集コンテンツを復元する（ステップＳ８７）。つまり、パソコン４Ａ及びタブレット端末４Ｂのローカルストレージ４５には、同一の最新の編集データが格納されることになる（ステップＳ８８）。その結果、タブレット端末４Ｂは、キャッシュされたリソースに基づき、オフラインでもローカルでＷｅｂアプリを実行できると共に、このＷｅｂアプリで最新の編集コンテンツを編集できる。

本実施例では、Ｗｅｂアプリのリソースに編集コンテンツを格納し、Ｗｅｂアプリのコンテンツ更新があったタイミングでリソースをクライアント側の通信端末４に提供する。通信端末４は、提供されたリソースをキャッシュし、キャッシュされたリソースに基づきＷｅｂアプリを実行すると共に、そのリソース内に格納された編集コンテンツを復元する。その結果、クライアントは、オフライン時でもＷｅｂアプリ実行した場合には最新の編集コンテンツを取得できる。また、当該Ｗｅｂアプリを使用する通信端末４のローカルストレージ４５に格納されたコンテンツは同一の最新コンテンツであるため、各通信端末４は、ローカルストレージ４５に格納された最新の編集コンテンツを編集できる。

また、本実施例では、Ｗｅｂアプリで編集したコンテンツの更新に応じてクライアント側の通信端末４に編集コンテンツが格納されたリソースを提供できる。

また、本実施例では、Ｗｅｂアプリだけでなく、動的に作成したコンテンツも同時に取得できることは勿論のこと、当該コンテンツをＷｅｂアプリのダウンロードの枠内で取得できるため、Ｗｅｂアプリ配信の利用範囲が拡大する。

また、本実施例では、リソースのコンテナ内にコンテンツを格納するだけで良く、リソース一覧を示すマニフェストの記述を変更せず、そのまま、使用できるので、使い勝手が良い。

尚、上記実施例では、Ｗｅｂアプリのリソース内に編集コンテンツを格納する際、編集コンテンツをＪＳＯＮ形式のデータに変換してＤａｔａ．ｊｓｏｎファイルに格納するようにした。しかしながら、ＪＳＯＮ形式、およびＤａｔａ．Ｊｓｏｎファイルに限定されるものではなく、他のデータ形式、および格納ファイルであっても良い。

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

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

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

また、上記実施例では、Ｗｅｂブラウザ４０及びＰＵＳＨクライアント３６を同一のＣＰＵ３５上で実行するようにしたが、異なるＣＰＵ上で実行するようにしても良い。

また、上記実施例では、通信端末４を、例えば、携帯電話機やタブレット端末等としてＣＰＵ３５を常時通電状態としている。しかしながら、通信端末４がパソコン等の場合、ＰＵＳＨクライアント３６は、Ｗｅｂブラウザ４０側が起動していない場合や、ＣＰＵ３５側の電源が起動していない場合でも、常時電源をＯＮ状態とし、ＰＵＳＨサーバ２からの情報が受信可能な状態にあるようにしても良い。

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

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

移動元の通信端末４Ｄは、通信部３１、操作部３２、表示部３３、メモリ３４及びＣＰＵ３５の他、ＲＦＩＤ（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 (6)

1. プロセッサを備えた通信装置と、前記通信装置に対してＷｅｂアプリのリソースを提供する、プロセッサを備えたアプリ提供装置とを有し、
   前記アプリ提供装置のプロセッサは、
   前記通信装置で実行する前記Ｗｅｂアプリで編集したコンテンツを検出した場合、当該Ｗｅｂアプリのリソース内に編集したコンテンツを格納し、前記通信装置から前記Ｗｅｂアプリを要求するアプリ要求を検出した場合、当該Ｗｅｂアプリのリソースを、当該アプリ要求を実行した前記通信装置に提供する
   各処理を実行し、
   前記通信装置のプロセッサは、
   前記アプリ提供装置から前記Ｗｅｂアプリのリソースを受信した場合、当該リソースを一時保存し、保存されたリソースをＷｅｂブラウザのキャッシュに同期させ、当該キャッシュされた前記リソースに基づき、Ｗｅｂアプリを実行すると共に、キャッシュされた前記リソースに基づき、リソース内に格納した前記コンテンツを復元する
   各処理を実行することを特徴とするアプリ提供システム。
2. 前記アプリ提供装置の前記プロセッサは、
   前記リソース内に編集したコンテンツを格納する処理において、前記編集したコンテンツを転送ファイルに変換し、前記転送ファイルに変換された前記コンテンツを当該Ｗｅｂアプリのリソース情報内に格納する
   各処理を実行することを特徴とする請求項１に記載のアプリ提供システム。
3. 前記通信装置のプロセッサは、
   前記Ｗｅｂアプリのコンテンツ更新に応じて当該コンテンツ更新に関わるＷｅｂアプリの格納先アドレスを受信した場合、当該格納先アドレスに基づき、当該格納先アドレスの前記Ｗｅｂアプリのリソースを要求する前記アプリ要求を実行することを特徴とする請求項１又は２に記載のアプリ提供システム。
4. 前記通信装置のプロセッサは、
   当該通信装置に対する前記Ｗｅｂアプリの送信依頼に応じて当該Ｗｅｂアプリの格納先アドレス及びコマンドを受信した場合、当該格納先アドレスに基づき、当該格納先アドレスの前記Ｗｅｂアプリのリソースを要求する前記アプリ要求を実行し、
   前記アプリ提供装置から前記Ｗｅｂアプリのリソースを受信した場合、当該リソースを一時保存し、保存されたリソースをＷｅｂブラウザのキャッシュに同期させ、当該キャッシュされた前記リソース及び前記コマンドに基づき、Ｗｅｂアプリを実行すると共に、キャッシュされた前記リソースに基づき、リソース内に格納した前記コンテンツを復元することを特徴とする請求項１又は２に記載のアプリ提供システム。
5. 通信装置と、前記通信装置に対してＷｅｂアプリのリソースを提供するアプリ提供装置とを有するアプリ提供システムのアプリ提供方法であって、
   前記アプリ提供装置は、
   前記通信装置で実行する前記Ｗｅｂアプリで編集したコンテンツを検出した場合、当該Ｗｅｂアプリのリソース内に編集したコンテンツを格納し、前記通信装置からＷｅｂアプリを要求するアプリ要求を検出した場合、当該Ｗｅｂアプリのリソースを、当該アプリ要求を実行した前記通信装置に提供し、
   前記通信装置は、
   前記アプリ提供装置から前記Ｗｅｂアプリのリソースを受信した場合、当該リソースを一時保存し、保存されたリソースをＷｅｂブラウザのキャッシュに同期させ、当該キャッシュされた前記リソースに基づき、Ｗｅｂアプリを実行すると共に、キャッシュされた前記リソースに基づき、リソース内に格納した前記コンテンツを復元する
   各処理を実行することを特徴とするアプリ提供方法。
6. コンピュータに、
   通信装置で実行するＷｅｂアプリで編集したコンテンツを検出した場合、当該Ｗｅｂアプリのリソース内に編集したコンテンツを格納し、
   前記通信装置からＷｅｂアプリを要求するアプリ要求を検出した場合、当該Ｗｅｂアプリのリソースを、当該アプリ要求を実行した前記通信装置に提供する
   処理を実行させることを特徴とするアプリ提供プログラム。

Images