"プロセッサを備えた通信装置と、前記通信装置に対してWebアプリのリソースを提供する、プロセッサを備えたアプリ提供装置とを有し、前記アプリ提供装置のプロセッサは、前記通信装置で実行する前記Webアプリで編集したコンテンツを検出した場合、当該Webアプリのリソース内に編集したコンテンツを格納し、前記通信装置から前記Webアプリを要求するアプリ要求を検出した場合、当該Webアプリのリソースを、当該アプリ要求を実行した前記通信装置に提供する各処理を実行し、前記通信装置のプロセッサは、前記アプリ提供装置から前記Webアプリのリソースを受信した場合、当該リソースを一時保存し、保存されたリソースをWebブラウザのキャッシュに同期させ、当該キャッシュされた前記リソースに基づき、Webアプリを実行すると共に、キャッシュされた前記リソースに基づき、リソース内に格納した前記コンテンツを復元する各処理を実行することを特徴とするアプリ提供システム。前記アプリ提供装置の前記プロセッサは、前記リソース内に編集したコンテンツを格納する処理において、前記編集したコンテンツを転送ファイルに変換し、前記転送ファイルに変換された前記コンテンツを当該Webアプリのリソース情報内に格納する各処理を実行することを特徴とする請求項1に記載のアプリ提供システム。前記通信装置のプロセッサは、前記Webアプリのコンテンツ更新に応じて当該コンテンツ更新に関わるWebアプリの格納先アドレスを受信した場合、当該格納先アドレスに基づき、当該格納先アドレスの前記Webアプリのリソースを要求する前記アプリ要求を実行することを特徴とする請求項1又は2に記載のアプリ提供システム。前記通信装置のプロセッサは、当該通信装置に対する前記Webアプリの送信依頼に応じて当該Webアプリの格納先アドレス及びコマンドを受信した場合、当該格納先アドレスに基づき、当該格納先アドレスの前記Webアプリのリソースを要求する前記アプリ要求を実行し、前記アプリ提供装置から前記Webアプリのリソースを受信した場合、当該リソースを一時保存し、保存されたリソースをWebブラウザのキャッシュに同期させ、当該キャッシュされた前記リソース及び前記コマンドに基づき、Webアプリを実行すると共に、キャッシュされた前記リソースに基づき、リソース内に格納した前記コンテンツを復元することを特徴とする請求項1又は2に記載のアプリ提供システム。通信装置と、前記通信装置に対してWebアプリのリソースを提供するアプリ提供装置とを有するアプリ提供システムのアプリ提供方法であって、前記アプリ提供装置は、前記通信装置で実行する前記Webアプリで編集したコンテンツを検出した場合、当該Webアプリのリソース内に編集したコンテンツを格納し、前記通信装置からWebアプリを要求するアプリ要求を検出した場合、当該Webアプリのリソースを、当該アプリ要求を実行した前記通信装置に提供し、前記通信装置は、前記アプリ提供装置から前記Webアプリのリソースを受信した場合、当該リソースを一時保存し、保存されたリソースをWebブラウザのキャッシュに同期させ、当該キャッシュされた前記リソースに基づき、Webアプリを実行すると共に、キャッシュされた前記リソースに基づき、リソース内に格納した前記コンテンツを復元する各処理を実行することを特徴とするアプリ提供方法。コンピュータに、通信装置で実行するWebアプリで編集したコンテンツを検出した場合、当該Webアプリのリソース内に編集したコンテンツを格納し、前記通信装置からWebアプリを要求するアプリ要求を検出した場合、当該Webアプリのリソースを、当該アプリ要求を実行した前記通信装置に提供する処理を実行させることを特徴とするアプリ提供プログラム。通常、Webブラウザは、Webアプリのリソース一覧を記述したマニフェストファイルを見て、Webサーバ側にあるリソースに更新があれば自動でキャッシュされたリソースも更新するようになっている。一方でマニフェストに記述できないWebアプリのリソース以外のデータ、例えば、上記クライアントで作成され、Webサーバにアップロードされたコンテンツファイルは自動で更新することができない。そのため、Webアプリを実行したときに、Webサーバから最新コンテンツを取得するようにWebアプリを記述する方法が一般的に用いられる。しかしながら、クライアントは、オフライン時にWebアプリを実行したとしても最新の編集コンテンツを取得できない。例えば、クライアントがWebアプリを使用してコンテンツを編集した後、他の端末から当該Webアプリを使用して先ほど編集したコンテンツを編集する場合を想定したとする。この場合、他の端末でWebアプリを使用したクライアントは、オフライン時にWebアプリを実行したとしても、最新の編集コンテンツを取得できないため、各端末のローカルに格納された編集コンテンツの内容が異なってしまう。その結果、クライアントは、当該最新の編集コンテンツを再編集できないことになる。一つの側面では、クライアント側がオフライン時でもWebアプリ実行時に最新の編集コンテンツを取得できるアプリ提供システム、アプリ提供方法及びアプリ提供プログラムを提供することを目的とする。開示のシステムは、一つの態様において、プロセッサを備えた通信装置と、前記通信装置に対してWebアプリのリソースを提供する、プロセッサを備えたアプリ提供装置とを有する。前記アプリ提供装置のプロセッサは、前記通信装置で実行する前記Webアプリで編集したコンテンツを検出した場合、当該Webアプリのリソース内に編集したコンテンツを格納する。更に、前記プロセッサは、前記通信装置から前記Webアプリを要求するアプリ要求を検出した場合、当該Webアプリのリソースを、当該アプリ要求を実行した前記通信装置に提供する。更に、前記通信装置のプロセッサは、前記アプリ提供装置から前記Webアプリのリソースを受信した場合、当該リソースを一時保存する。更に、前記通信装置のプロセッサは、保存されたリソースをWebブラウザのキャッシュに同期させ、当該キャッシュされた前記リソースに基づき、Webアプリを実行する。更に、前記通信装置のプロセッサは、キャッシュされた前記リソースに基づき、リソース内に格納した前記コンテンツを復元する。開示のシステムでは、クライアント側がオフライン時でもWebアプリ実行時に最新の編集コンテンツを取得できる。以下、図面に基づいて、本願の開示するアプリ提供システム、アプリ提供方法及びアプリ提供プログラムの実施例を詳細に説明する。尚、本実施例により、開示技術が限定されるものではない。本出願人は、PUSH方式のWebアプリ提供システムを考案している。図2は、Webアプリ提供システムの使用形態の一例を示す説明図である。図2に示すWebアプリ提供システム1Aは、PUSHサーバ2と、Webサーバ3と、パソコン4Aと、タブレット端末4Bとを有する。尚、パソコン4A及びタブレット端末4Bの所有者は、例えば、同一ユーザとする。パソコン4Aは、Webブラウザを使用してWebサーバ3とオンライン状態とし、Webサーバ3から、例えば、文書作成ソフトのWebアプリを取得する。パソコン4Aは、Webアプリを使用してコンテンツを作成及び編集するステップS11。パソコン4Aは、その作成及び編集したコンテンツをローカルに格納すると共に、そのコンテンツをWebサーバ3にアップロードするステップS12。そして、Webサーバ3は、パソコン4Aからアップロードされたコンテンツを当該Webアプリに対応付けて格納するステップS13。その結果、パソコン4A及びWebサーバ3には、同一コンテンツが格納されたことになる。また、PUSHサーバ2は、Webアプリの更新、例えば、編集コンテンツの更新を検知するとステップS14、例えば、タブレット端末4Bに対して、更新したWebアプリのリソースに関わる格納先アドレスをPUSH送信するステップS15。そして、タブレット端末4Bは、格納先アドレスを受信した場合、格納先アドレスに基づき、当該更新したWebアプリのリソースをWebサーバ3から取得するステップS16。タブレット端末4Bは、Webサーバ3から取得されたWebアプリのリソースをキャッシュし、キャッシュされたリソースに基づきWebアプリを実行するステップS17。その結果、タブレット端末4Bは、キャッシュされたリソースに基づき、オフラインでもローカルでWebアプリを実行できる。更に、タブレット端末4Bは、Webサーバ3とオンライン中であれば、Webアプリ実行時に、Webサーバ3に格納された最新の編集コンテンツを取得できる。その結果、パソコン4A及びタブレット端末4Bのローカルには、同一コンテンツが格納されたことになる。しかしながら、タブレット端末4Bは、Webサーバ3とオンライン時にWebアプリを実行しないと、Webサーバ3に格納された編集コンテンツを取得できない。その結果、オフライン時には、パソコン4A及びタブレット端末4Bのローカルに格納される編集コンテンツが異なるステップS18。従って、タブレット端末4Bは、パソコン4A側で作成された編集コンテンツを再編集できない。そこで、本出願人は、オフライン時でもWebアプリ実行時に最新の編集データを取得できるWebアプリ提供システムを案出した。図1は、実施例1のWebアプリ提供システム内部の一例を示す機能ブロック図である。尚、図2に示すWebアプリ提供システム1Aと同一の構成には同一符号を付すことで、その重複する構成及び動作の説明については省略する。図1に示すWebアプリ提供システム1は、PUSHサーバ2と、Webサーバ3と、通信端末4とを有する。尚、PUSHサーバ2、Webサーバ3及び通信端末4は、例えば、無線や有線等の通信網を通じて通信接続する。PUSHサーバ2は、更新監視部12と、アドレス管理部13と、タイミング監視部14と、PUSH送信部15とを有する。尚、リソースとは、Webアプリの構成要素、例えばHTML、CSS及びJavaScriptである。更新監視部12は、各Webサーバ3と通信してWebアプリの更新状況を監視する。尚、Webアプリの更新状況には、Webアプリを使用して編集した編集データの更新も含む。また、更新監視部12は、各Webサーバ3のWebアプリの更新状況を集中管理するデータベースにアクセスし、各Webアプリの更新状況を監視しても良い。図3は、アドレス管理部13のテーブル内容の一例を示す説明図である。図3に示すアドレス管理部13は、ユーザID13Aと、端末ID13Bと、アプリID13Cと、格納先アドレス13Dと、提供タイミング13Eとを対応付けてテーブルの内容を動的に登録更新して管理する。ユーザID13Aは、例えば、Webアプリ提供システム1に登録済みのユーザを識別するIDである。端末ID13Bは、例えば、Webアプリ提供システム1に登録済みのユーザの通信端末4を識別するIDである。アプリID13Cは、通信端末4に提供するWebアプリを識別するIDである。格納先アドレス13Dは、提供するWebアプリのリソースを管理する格納先のアドレスである。提供タイミング13Eは、当該通信端末4に提供するWebアプリの格納先アドレスを当該通信端末4にPUSH送信する上での条件タイミングである。尚、提供タイミング13Eの例としては、様々なタイミングが考えられる。提供タイミング13Eは、例えば、更新監視部12でWebアプリの更新を検知したタイミングである。尚、Webアプリの更新としては、Webアプリ自体のプログラムの更新は勿論のこと、当該Webアプリを使用してコンテンツを編集したコンテンツ更新も含むものである。また、提供タイミング13Eは、例えば、Webアプリが飲食店のメニューを提供するメニュー閲覧アプリの場合、例えば、通信端末4が飲食店付近の通信エリア範囲内に進入したタイミングである。また、提供タイミング13Eは、Webアプリが学校の教科書を提供する教科書閲覧アプリの場合、通信端末4が当該学校の敷地内の通信エリア範囲内に進入したタイミングである。また、提供タイミング13Eは、Webアプリが会議の資料を配布する資料配布アプリの場合、通信端末4が当該会議室内の通信エリア範囲に進入したタイミングである。また、提供タイミング13Eは、Webアプリが更新した場合、当該Webアプリを使用する通信端末4が所定の通信エリア範囲内に進入したタイミングである。タイミング監視部14は、アドレス管理部13内の提供タイミング13Eに基づき、現在タイミングが提供タイミング13Eであるか否かを判定する。タイミング監視部14は、現在タイミングが提供タイミング13Eである場合、当該提供タイミング13Eに対応したユーザID13A、端末ID13B及び格納先アドレス13Dをアドレス管理部13から取得する。タイミング監視部14は、取得された端末ID13Bに基づき、当該提供タイミングの通信端末4を特定する。更に、タイミング監視部14は、取得された格納先アドレス13Dに基づき、当該提供タイミングの通信端末4に提供するWebアプリのリソースの格納先を特定する。PUSH送信部15は、タイミング監視部14にて特定された通信端末4へのPUSH送信が可能な場合、当該通信端末4に対して、格納先アドレスをPUSH送信する。各Webサーバ3は、アプリ管理部21と、アプリ提供部22と、コンテンツ格納部23と、格納制御部24と、コンテンツ取得部25とを有する。尚、アプリ提供部22、格納制御部24及びコンテンツ取得部25等は、Webサーバ3内の図示せぬプロセッサで実行する。アプリ管理部21は、格納先アドレス毎にWebアプリのリソース及びマニフェスト等を格納したアプリパッケージ21Aを管理する。アプリパッケージ21Aは、マニフェスト210と、リソース220とを有する。図4は、マニフェスト210及びリソース220の一例を示す説明図である。マニフェスト210は、Webアプリのリソース220のリスト一覧である。マニフェスト210は、トップページを示すIndex.html211と、復元プログラムを示すRestore.js212と、画像ファイルを示すaaa.Jpg213と、コンテンツを格納したコンテナファイルを示すData.json214とを有する。リソース220は、Webアプリに使用するリソースの内容である。リソース220には、トップページ自体であるIndex.html221と、復元プログラム自体であるRestore.js222とを有する。また、リソース220には、画像ファイル自体であるaaa.Jpg223と、コンテンツを含むコンテナファイルであるData.json224とを有する。尚、jsonJavaScriptObjectNotationファイルは、Webブラウザ上で実行されるJavaScriptプログラムが解釈可能なデータ形式をもつデータファイルである。また、復元プログラムは、Data.Jsonファイルからコンテンツを抽出し、ローカルストレージ内にコンテンツを復元するプログラムである。また、Data.json224は、格納されたコンテンツの属性情報及び、変換されたコンテンツのデータを含む。コンテンツ取得部25は、通信端末4側のWebアプリを使用して編集したコンテンツのアップロードに応じて、編集コンテンツを取得する。更に、コンテンツ格納部23は、コンテンツ取得部25にて取得されたWebアプリの編集コンテンツをコンテンツファイル形式で格納する。格納制御部24は、変換部24Aと、格納部24Bとを有する。変換部24Aは、コンテンツ格納部23にて格納された編集コンテンツをリソース内の復元プログラムが解釈可能なデータ形式、例えば、JSON形式に変換する。格納部24Bは、JSON形式に変換されたデータをリソース内のコンテナファイル、例えばData.Jsonファイル内に格納する。アプリ提供部22は、通信端末4からのアプリ要求を検出すると、当該アプリ要求に対するWebアプリのマニフェスト210及びリソース220をアプリ管理部21から取得する。更に、アプリ提供部22は、取得されたWebアプリのマニフェスト210及びリソース220を、アプリ要求を実行した通信端末4に提供する。通信端末4は、通信機能を備えた、例えば、携帯電話機、スマートフォン、パソコンやタブレット端末等に相当する。通信端末4は、通信部31と、操作部32と、表示部33と、メモリ34と、プロセッサ等のCPU35とを有する。通信部31は、通信網等を通じて他の通信端末4やサーバ等と通信接続する。操作部32は、各種コマンドを入力する。表示部33は、各種情報を表示する。メモリ34は、各種情報等を記憶する。CPU35は、通信端末4全体を制御する。CPU35は、Webブラウザ40及びPUSHクライアント36等のソフトウェア機能を実行する。尚、Webブラウザ40とPUSHクライアント36とは、異なるCPU上で実行されても良い。また、PUSHクライアント36は、PUSH受信部51と、アプリ取得部52と、一時ストレージ53とを有する。PUSH受信部51は、PUSHサーバ2から提供タイミングに関わるWebアプリのリソースを格納した格納先アドレスを受信する。アプリ取得部52は、PUSH受信部51にて受信された格納先アドレスに基づき当該WebアプリのリソースをWebサーバ3に要求する。アプリ取得部52は、Webサーバ3からWebアプリのリソースを取得すると、当該Webアプリのリソースを一時ストレージ53に登録する。Webブラウザ40は、キャッシュ同期部41と、アプリキャッシュ42と、アプリ実行部43と、ローカルストレージ45とを有する。キャッシュ同期部41は、一時ストレージ53に登録済みのリソースをWebブラウザが解釈可能なデータ形式に変換し、アプリキャッシュ42にキャッシュする。アプリ実行部43は、アプリキャッシュ42にキャッシュされたリソースに基づき、Webアプリを実行する。更に、アプリ実行部43は、アプリキャッシュ42にキャッシュされたリソースの復元プログラムRestore.jsを実行する。アプリ実行部43は、復元プログラムを実行することで、リソース内のData.jsonファイル内に格納されたコンテンツを復元し、復元されたコンテンツをローカルストレージ45内に格納する。尚、キャッシュ同期部41は、Webブラウザ外にあっても良い。また、Webアプリ提供システム1では、PULL方式と、PUSH方式とがある。PULL方式では、通信端末4が所望のWebアプリのリソースの格納先アドレスをPUSHサーバ2に要求する。そして、通信端末4は、PUSHサーバ2から取得した格納先アドレスに基づき、Webアプリのリソースを取得する。また、前述した通り、PUSH方式では、PUSHサーバ2がWebアプリの提供タイミングに応じてWebアプリのリソースの格納先アドレスを通信端末4に提供する。次に、本実施例のWebアプリ提供システム1の動作について説明する。図5は、実施例1のWebアプリ提供システム1の使用形態の一例を示す説明図である。図5に示すWebアプリ提供システム1では、PUSHサーバ2と、Webサーバ3と、通信端末4とを有する。図5に示すように、通信端末4のユーザが美術館に入館した場合、PUSHサーバ2は、提供タイミングと判断し、美術館の案内ナビのWebアプリに関わるリソースの格納先アドレスを通信端末4にPUSH送信する。そして、通信端末4は、PUSHサーバ2から受信した格納先アドレスのWebサーバ3から美術館の案内ナビのWebアプリに関わるリソースを取得してキャッシュする。そして、通信端末4は、キャッシュされたリソースに基づき、案内ナビのWebアプリを実行する。その結果、ユーザは、案内ナビのWebアプリの取得操作を行わなくても、案内ナビアプリで美術館内の案内を受けることができる。また、通信端末4のユーザが飲食店付近に来た場合、PUSHサーバ2は、提供タイミングと判断し、飲食店のメニュー閲覧のWebアプリに関わるリソースの格納先アドレスを通信端末4にPUSH送信する。そして、通信端末4は、PUSHサーバ2から受信した格納先アドレスのWebサーバ3からメニュー閲覧のWebアプリに関わるリソースを取得してキャッシュする。そして、通信端末4は、キャッシュされたリソースに基づき、メニュー閲覧のWebアプリを実行する。その結果、ユーザは、メニュー閲覧のWebアプリの取得操作を行わなくても、メニュー閲覧アプリで飲食店のメニューを閲覧できる。また、通信端末4のユーザが学校に来た場合、PUSHサーバ2は、提供タイミングと判断し、教科書閲覧のWebアプリに関わる格納先アドレスを通信端末4にPUSH送信する。そして、通信端末4は、PUSHサーバ2から受信した格納先アドレスのWebサーバ3から教科書閲覧のWebアプリに関わるリソースを取得してキャッシュする。そして、通信端末4は、キャッシュされたリソースに基づき、教科書閲覧のWebアプリを実行する。その結果、ユーザは、教科書閲覧のWebアプリの取得操作を行わなくても、教科書閲覧アプリで学校の教科書を閲覧できる。また、通信端末4のユーザが会議室に入室した場合、PUSHサーバ2は、提供タイミングと判断し、プレゼンの資料閲覧のWebアプリのリソースに関わる格納先アドレスを通信端末4にPUSH送信する。そして、通信端末4は、PUSHサーバ2から受信した格納先アドレスのWebサーバ3から資料閲覧のWebアプリのリソースを取得してキャッシュする。そして、通信端末4は、キャッシュされたリソースに基づき、資料閲覧のWebアプリを実行する。その結果、ユーザは、資料閲覧のWebアプリの取得操作を行わなくても、資料閲覧アプリでプレゼン資料を閲覧できる。図6は、コンテンツ更新処理に関わるWebサーバ3の処理動作の一例を示すフローチャートである。図6に示すコンテンツ更新処理では、Webアプリで編集したコンテンツを通信端末4から取得した場合、編集したコンテンツを当該Webアプリのリソースのコンテナ内に格納することでコンテンツを更新する処理である。図6においてWebサーバ3のコンテンツ取得部25は、通信端末4からWebアプリで編集したコンテンツを取得するステップS21。Webサーバ3のコンテンツ格納部23は、編集したコンテンツを取得すると、当該Webアプリの端末ID又はユーザID毎に編集コンテンツを格納するステップS22。Webサーバ3の格納制御部24の変換部24Aは、格納されたコンテンツを復元プログラムが解釈可能なデータ形式、例えばJSON形式のデータに変換するステップS23。更に、格納制御部24内の格納部24Bは、JSON形式データに変換されたコンテンツをリソース内のコンテナファイルであるData.jsonファイルに格納するステップS24。格納部24Bは、リソースのコンテナファイルを上記作成した新しいコンテナファイルData.jsonに置き換えることでステップS25、図6に示す処理動作を終了する。その結果、PUSHサーバ2は、Data.jsonファイルの更新日付情報が変わったことでデータ更新を認識することになる。図6に示すコンテンツ更新処理では、Webサーバ3は、Webアプリで編集したコンテンツを通信端末4から取得した場合、取得されたコンテンツを特定のデータ形式でWebアプリのリソース内にあるData.Jsonファイルに格納する。そして、コンテナファイルが新しいものに置き換わるとデータの更新日付情報が変わることにより、Webアプリのデータ更新があったことが認識される。図7は、アドレス提供処理に関わるPUSHサーバ2の処理動作の一例を示すフローチャートである。図7に示すアドレス提供処理では、Webアプリの提供タイミングを監視し、当該提供タイミングを検出すると、提供タイミングに対応した通信端末4に提供対象のWebアプリに関わるリソースの格納先アドレスをPUSH送信する処理である。図7に示すPUSHサーバ2のタイミング監視部14は、現在タイミングがアドレス管理部13に管理中の提供タイミングであるか否かを判定するステップS31。タイミング監視部14は、現在タイミングが提供タイミングである場合ステップS31肯定、アドレス管理部13から提供タイミングに関わる端末ID13B及び格納先アドレス13Dを特定するステップS32。PUSHサーバ2のPUSH送信部15は、端末ID13B及び格納先アドレス13Dを特定すると、当該端末ID13Bの通信端末4に対して格納先アドレス13DをPUSH送信しステップS33、図7に示す処理動作を終了する。尚、PUSH送信部15は、当該端末ID13Bの通信端末4に対して通信可能な状態であるか否かを判定し、通信可能な状態である場合、当該通信端末4に対して格納先アドレス13DをPUSH送信する。また、PUSHサーバ2の更新監視部12は、現在タイミングが提供タイミングでない場合ステップS31否定、各Webサーバ3のWebアプリの更新状況を監視しステップS34、提供タイミングを監視すべく、ステップS31に移行する。図7に示すアドレス提供処理では、Webアプリの提供タイミングを監視し、当該提供タイミングを検出すると、提供タイミングに対応した通信端末4に提供対象のWebアプリのリソースの格納先アドレスをPUSH送信する。その結果、通信端末4は、例えば、Webアプリのデータ更新の提供タイミングに応じたWebアプリのリソースの格納先アドレスを認識できる。図8は、Webアプリ取得処理に関わる通信端末4の処理動作の一例を示すフローチャートである。図8に示すWebアプリ取得処理では、PUSHサーバ2から取得した格納先アドレスに基づきWebアプリのリソースをWebサーバ3から取得し、リソースをアプリキャッシュ42にキャッシュする処理である。図8において通信端末4のPUSHクライアント36のPUSH受信部51は、PUSHサーバ2から格納先アドレス13Dを受信したか否かを判定するステップS41。PUSHクライアント36のアプリ取得部52は、格納先アドレスを受信した場合ステップS41肯定、格納先アドレスに基づきWebサーバ3に対してWebアプリを要求するステップS42。アプリ取得部52は、Webアプリ要求に対するリソースを取得したか否かを判定するステップS43。アプリ取得部52は、リソースを取得した場合ステップS43肯定、取得されたリソースを一時ストレージ53に登録するステップS44。Webブラウザ40のキャッシュ同期部41は、一時ストレージ53に登録済みのリソースをWebブラウザ40が解釈可能なデータ形式に変換するステップS45。更に、キャッシュ同期部41は、変換されたリソースをアプリキャッシュ42にキャッシュするステップS46。通信端末4のCPU35は、Webブラウザ40が起動済みであるか否かを判定するステップS47。Webブラウザ40のアプリ実行部43は、Webブラウザ40が起動済みの場合ステップS47肯定、アプリキャッシュ42にキャッシュされたリソースに基づきWebアプリを実行するステップS48。更に、Webブラウザ40上で実行される復元プログラムは、リソースのコンテナ内にコンテンツがあるか否かを判定するステップS49。復元プログラムは、リソースのコンテナ内にコンテンツがある場合ステップS49肯定、リソース内のData.Jsonファイルからコンテンツを復元するステップS50。復元プログラムは、復元されたコンテンツをローカルストレージ45内に格納することでコンテンツ更新しステップS51、図8に示す処理動作を終了する。アプリ取得部52は、格納先アドレスを受信していない場合ステップS41否定、一時ストレージ53に登録済みのリソースがあるか否かを判定するステップS53。アプリ取得部52は、一時ストレージ53に登録済みのリソースがある場合ステップS53肯定、リソースを変換すべく、ステップS45に移行する。また、アプリ取得部52は、一時ストレージ53に登録済みのリソースがない場合ステップS53否定、図8に示す処理動作を終了する。また、復元プログラムは、リソースのコンテナ内にコンテンツがない場合ステップS49否定、図8に示す処理動作を終了する。また、アプリ取得部52は、リソースを取得しなかった場合ステップS43否定、リソースを取得したか否かを判定すべく、ステップS43に移行する。また、CPU35は、Webブラウザ40が起動済みでない場合ステップS47否定、Webブラウザ40を起動しステップS52、ステップS48に移行する。図8に示すWebアプリ取得処理では、PUSHサーバ2から取得した格納先アドレスに基づきWebアプリのリソースをWebサーバ3から取得し、リソースをアプリキャッシュ42にキャッシュする。その結果、通信端末4は、オフライン時でも、キャッシュされたリソースに基づきWebアプリを実行できる。Webアプリ取得処理では、Webブラウザ40が起動済みでなくても、Webアプリのリソースを一時ストレージ53に登録できる。その結果、Webブラウザ40が起動しなくても、提供タイミングに応じたWebアプリを自動取得できる。Webアプリ取得処理では、一時ストレージ53に登録済みのリソースを読み出し、リソースをアプリキャッシュ42にキャッシュする。その結果、提供タイミングに応じたWebアプリを自動取得できる。更に、Webアプリ取得処理では、アプリキャッシュ42にキャッシュされたリソースのコンテナ内にコンテンツがある場合、リソース内の復元プログラムに基づきコンテンツを復元し、復元されたコンテンツをローカルストレージ45に格納する。その結果、クライアントは、オフラインでも、Webアプリ実行時に最新のコンテンツを取得できる。次に、通信端末4のWebブラウザ40がWebサーバ3に対してWebアプリのリソースを取得する際の動作について説明する。図9は、Webブラウザ40及びWebサーバ3間のリソース取得に関わる処理動作の一例を示す説明図である。図9に示す通信端末4のWebブラウザ40は、リンク先のエントリページ取得リクエストをWebサーバ3に送信するステップS62。Webサーバ3は、エントリページ取得リクエストを検出すると、エントリページをWebブラウザ40に送信するステップS63。Webブラウザ40は、エントリページを取得すると、エントリページ内のマニフェストを検出するステップS64。Webブラウザ40は、マニフェストに基づきマニフェスト取得リクエストをWebサーバ3に送信するステップS65。Webサーバ3は、マニフェスト取得リクエストを検出すると、Webアプリのアプリパッケージ21A内のマニフェスト210をWebブラウザ40に送信するステップS66。Webブラウザ40は、マニフェスト210を取得すると、マニフェスト210を解析し、取得すべきWebアプリのリソース一覧を抽出するステップS67。Webブラウザ40は、リソース一覧を抽出すると、マニフェストに記述されたHTMLファイルの取得リクエストをWebサーバ3に送信するステップS68。更に、Webサーバ3は、マニフェストに記述されたリソースの取得リクエストに応じて、リソースをWebブラウザ40に送信するステップS69。尚、Webサーバ3は、WebアプリのリソースをWebブラウザ40に送信したが、2回目以降は更新されたファイル、例えば、コンテンツを送信しても良い。Webブラウザ40は、リソースを取得すると、取得されたリソースをアプリキャッシュ42にキャッシュするステップS70。Webブラウザ40は、キャッシュされたリソースに基づき、Webアプリを実行するステップS71。図10は、実施例1のWebアプリ提供システム1の使用形態の一例を示す説明図である。尚、図10の通信端末4としてのパソコン4A及びタブレット端末4Bは同一ユーザである。図10に示すパソコン4Aは、Webブラウザを使用してWebサーバ3とオンライン状態とし、Webサーバ3から、例えば、文書作成ソフトのWebアプリを取得する。パソコン4Aは、Webアプリを使用してコンテンツを作成及び編集するステップS81。パソコン4Aは、その作成及び編集したコンテンツをローカルストレージ45に格納すると共に、Webサーバ3にアップロードするステップS82。Webサーバ3は、パソコン4Aからアップロードされたコンテンツを当該Webアプリに対応付けてコンテンツ格納部23に格納するステップS83。そして、Webサーバ3は、Webアプリのリソースのコンテナ内にコンテンツを格納する。尚、この際、Webサーバ3とパソコン4Aとは、同一コンテンツが格納されたことになる。また、PUSHサーバ2は、Webアプリの更新、例えば、編集コンテンツの更新を検知するとステップS84、例えば、タブレット端末4Bに対して、更新したWebアプリのリソースに関わる格納先アドレスをPUSH送信するステップS85。そして、タブレット端末4Bは、格納先アドレスを受信した場合、格納先アドレスに基づき、当該更新したWebアプリのリソースをWebサーバ3から取得するステップS86。この際、Webアプリのリソースのコンテナ内には、編集コンテンツが格納されている。タブレット端末4Bは、Webサーバ3から取得されたWebアプリのリソースをキャッシュし、キャッシュされたリソースに基づきWebアプリを実行するステップS87。更に、タブレット端末4Bは、キャッシュされたリソース内の復元プログラムでコンテナ内に格納された編集コンテンツを復元するステップS87。つまり、パソコン4A及びタブレット端末4Bのローカルストレージ45には、同一の最新の編集データが格納されることになるステップS88。その結果、タブレット端末4Bは、キャッシュされたリソースに基づき、オフラインでもローカルでWebアプリを実行できると共に、このWebアプリで最新の編集コンテンツを編集できる。本実施例では、Webアプリのリソースに編集コンテンツを格納し、Webアプリのコンテンツ更新があったタイミングでリソースをクライアント側の通信端末4に提供する。通信端末4は、提供されたリソースをキャッシュし、キャッシュされたリソースに基づきWebアプリを実行すると共に、そのリソース内に格納された編集コンテンツを復元する。その結果、クライアントは、オフライン時でもWebアプリ実行した場合には最新の編集コンテンツを取得できる。また、当該Webアプリを使用する通信端末4のローカルストレージ45に格納されたコンテンツは同一の最新コンテンツであるため、各通信端末4は、ローカルストレージ45に格納された最新の編集コンテンツを編集できる。また、本実施例では、Webアプリで編集したコンテンツの更新に応じてクライアント側の通信端末4に編集コンテンツが格納されたリソースを提供できる。また、本実施例では、Webアプリだけでなく、動的に作成したコンテンツも同時に取得できることは勿論のこと、当該コンテンツをWebアプリのダウンロードの枠内で取得できるため、Webアプリ配信の利用範囲が拡大する。また、本実施例では、リソースのコンテナ内にコンテンツを格納するだけで良く、リソース一覧を示すマニフェストの記述を変更せず、そのまま、使用できるので、使い勝手が良い。尚、上記実施例では、Webアプリのリソース内に編集コンテンツを格納する際、編集コンテンツをJSON形式のデータに変換してData.jsonファイルに格納するようにした。しかしながら、JSON形式、およびData.Jsonファイルに限定されるものではなく、他のデータ形式、および格納ファイルであっても良い。また、上記実施例のタイミング監視部14では、アドレス管理部13内の端末ID13B毎の提供タイミング13Eに基づき、端末ID13Bで識別する通信端末4毎の提供タイミングを監視した。しかしながら、タイミング監視部14は、アドレス管理部13内のユーザID13A毎の提供タイミング13Eを監視しても良く、この場合、ユーザID13Aで識別するユーザの各提供タイミング13Eを監視する。また、上記実施例では、通信端末4のユーザが会議室に入室した場合、PUSHサーバ2は、提供タイミングと判断し、当該提供タイミングに応じて、プレゼンの資料閲覧のWebアプリに関わるリソースの格納先アドレスを通信端末4に提供する。そして、通信端末4は、格納先アドレスに基づき、プレゼンの資料閲覧のWebアプリに関わるリソースを取得してキャッシュした。この際、プレゼン資料の機密性を考慮した場合、会議室の退出後は、プレゼン資料閲覧のWebアプリを使用不可にすることが望ましい。そこで、PUSHサーバ2は、使用不可対象のWebアプリを提供した通信端末4の端末IDと、使用不可対象のWebアプリを識別するアプリIDと、使用不可のWebアプリの使用不可タイミングとを対応付けて管理する管理部を備えるようにしても良い。この場合、PUSHサーバ2のタイミング監視部14は、通信端末4のユーザが会議室を退室した場合、使用不可タイミングと判断する。タイミング監視部14は、当該使用不可タイミングに応じて、当該使用不可タイミングの端末ID及びアプリIDを管理部から取得する。タイミング監視部14は、取得された端末IDに基づき使用不可対象の通信端末4を特定すると共に、取得されたアプリIDに基づき使用不可の通信端末4のWebアプリを特定する。PUSH送信部15は、使用不可のWebアプリ、例えば、プレゼン資料閲覧のWebアプリの使用不可要求を通信端末4に通知する。通信端末4は、使用不可要求を受信すると、キャッシュされた当該プレゼン資料閲覧のWebアプリのリソースを消去することで、当該Webアプリを実行できなくする。その結果、通信端末4のユーザは、会議室退室後に資料閲覧のWebアプリが閲覧できなくなるため、プレゼン資料の機密性を確保できる。また、上記実施例では、Webブラウザ40及びPUSHクライアント36を同一のCPU35上で実行するようにしたが、異なるCPU上で実行するようにしても良い。また、上記実施例では、通信端末4を、例えば、携帯電話機やタブレット端末等としてCPU35を常時通電状態としている。しかしながら、通信端末4がパソコン等の場合、PUSHクライアント36は、Webブラウザ40側が起動していない場合や、CPU35側の電源が起動していない場合でも、常時電源をON状態とし、PUSHサーバ2からの情報が受信可能な状態にあるようにしても良い。図11は、実施例2のWebアプリ提供システム内部の一例を示す機能ブロック図である。尚、図1に示すWebアプリ提供システム1と同一の構成には同一符号を付すことで、その重複する構成及び動作の説明については省略する。図11に示すWebアプリ提供システム1Bと図1に示すWebアプリ提供システム1とが異なるところは、簡単な操作で、移動元の通信端末4Dで実行中のWebアプリを移動先の通信端末4E側でも実行できる点にある。尚、移動元の通信端末4Dは、Webアプリ実行中の通信端末4である。これに対して、移動先の通信端末4Eは、移動元の通信端末4Dで実行中のWebアプリと同一アプリを実行させる通信端末4である。図11に示すPUSHサーバ2は、更新監視部12、アドレス管理部13、タイミング監視部14及びPUSH送信部15の他に、イベント受信部16を有する。イベント受信部16は、移動元の通信端末4Dから後述するイベント情報を受信する。また、アドレス管理部13は、アドレス管理テーブル151を管理し、アドレス管理テーブル151のテーブル内容を動的に更新登録する。図12は、アドレス管理テーブル151のテーブル内容の一例を示す説明図である。図12に示すアドレス管理テーブル151は、ユーザID151A、端末ID151B、アプリID151C、格納先アドレス151D及び提供タイミング151Eの他に、タグID151F及びコマンド151Gを対応付けて管理している。タグID151Fは、通信端末4Eに内蔵した後述するRFIDタグ39Bを識別するIDである。コマンド151Gは、格納先アドレス151Dで特定するWebアプリの実行内容である。尚、コマンド151Gには、Webアプリの実行内容、例えば、ダウンロード及び実行、ダウンロードのみ、実行のみ、消去等がある。移動元の通信端末4Dは、通信部31、操作部32、表示部33、メモリ34及びCPU35の他、RFIDRadioFrequencyIdentificationリーダライタ39Aを有する。更に、移動先の通信端末4Eは、通信部31、操作部32、表示部33、メモリ34及びCPU35の他、RFIDタグ39Bを有する。RFIDリーダライタ39Aは、RFIDタグ39Bと所定通信距離内での近距離無線通信を実行する。移動元の通信端末4DのRFIDリーダライタ39Aは、移動先の通信端末4Eのアプリ移動操作に応じてRFIDタグ39Bと近距離無線通信を開始する。尚、アプリ移動操作は、RFIDリーダライタ39Aに対するRFIDタグ39Bのかざし操作及び、表示部33又は操作部32の特定操作の二重操作とすることで誤操作を防止できる。CPU35は、RFIDリーダライタ39Aを通じてRFIDタグ39BのタグIDを取得すると、タグIDを含む移動イベント情報を生成する。尚、移動イベント情報は、タグIDと、格納先アドレスと、イベント内容と、コマンドとを有する。タグIDは、移動先の通信端末4E側のRFIDタグ39Bを識別するIDである。格納先アドレスは、移動元の通信端末4D側で実行中の移動先の通信端末4Eでも実行するWebアプリに関わるリソースの格納先アドレスである。イベント内容は、移動元の通信端末4Dで実行中の同一Webアプリを移動先の通信端末4Eでも実行させる移動イベントである。コマンドは、移動先の通信端末4Eで実行するWebアプリの実行内容、例えば、ダウンロード及び実行、ダウンロードのみ、実行のみ、消去等の実行内容である。移動元の通信端末4Dの通信部31は、生成した移動イベント情報をPUSHサーバ2に送信する。PUSHサーバ2のイベント受信部16は、移動元の通信端末4Dから移動イベント情報を受信する。PUSHサーバ2のアドレス管理部13は、移動イベント情報を受信した場合、移動イベント情報内のタグID151Fに関わる端末ID151Bに対応した提供タイミング151Eを即時としてアドレス管理テーブル151内に更新する。更に、アドレス管理部13は、移動イベント情報内のコマンドを端末ID151Bに対応したコマンド151Gとしてアドレス管理テーブル151内に更新する。タイミング監視部14は、アドレス管理部13の提供タイミング151Eを参照し、現在タイミングが提供タイミング151Eであるか否かを監視する。アドレス管理部13は、提供タイミング151Eが即時の場合、即時にアドレス管理テーブル151から提供タイミング151Eに関わる端末ID151B、格納先アドレス151D及びコマンド151Gを特定する。尚、アドレス管理部13は、例えば、端末種別毎のWebアプリのリソースに関わる格納先アドレスを管理するテーブルを備え、端末ID151Bの端末種別を特定する。そして、アドレス管理部13は、端末ID151Bの端末種別を特定すると、格納先アドレスのWebアプリが通知先の通信端末4の端末種別に合致するか否かを判定する。そして、アドレス管理部13は、端末種別に合致しなかった場合、合致する端末種別に適用した格納先アドレス151Dを特定する。PUSH送信部15は、端末ID151B、格納先アドレス151D及びコマンド151Gを特定すると、端末ID151Bの移動先の通信端末4Eに対してPUSH送信可能な状況であるか否かを判定する。PUSH送信部15は、PUSH送信可能な状況の場合、端末ID151Bの移動先の通信端末4Eに対して格納先アドレス151D及びコマンド151GをPUSH送信する。移動先の通信端末4EのPUSH受信部51は、PUSHサーバ2から格納先アドレス及びコマンドを受信した場合、格納先アドレスに基づきWebサーバ3に対してWebアプリを要求する。アプリ取得部52は、Webアプリ要求に対するリソースを取得した場合、取得されたリソースを一時ストレージ53に登録する。更に、キャッシュ同期部41は、一時ストレージ53に登録済みのリソースをCPU35側で解釈可能なデータ形式に変換する。更に、キャッシュ同期部41は、変換されたリソースをアプリキャッシュ42にキャッシュする。更に、アプリ実行部43は、PUSHサーバ2から受信したコマンドに基づき、アプリキャッシュ42にキャッシュされたWebアプリを実行する。更に、アプリ実行部43は、アプリキャッシュ42にキャッシュされたリソースの復元プログラムRestore.jsを実行する。アプリ実行部43は、復元プログラムを実行することで、リソース内のData.jsonファイル内に格納されたコンテンツを復元し、復元されたコンテンツをローカルストレージ45内に格納する。尚、キャッシュ同期部41は、Webブラウザ外にあっても良い。つまり、移動先の通信端末4Eは、移動元の通信端末4Dとのアプリ移動操作に応じて、移動元の通信端末4Dで実行中の同一Webアプリを実行できる。次に、実施例2のWebアプリ提供システム1Bの動作について説明する。図13は、移動元の通信端末4Dの処理動作の一例を示すフローチャートである。図13において移動元の通信端末4DのRFIDリーダライタ39Aは、移動先の通信端末4Eとのアプリ移動操作に伴う近距離無線通信に応じて移動先の通信端末4EのタグIDを受信したか否かを判定するステップS151。移動元の通信端末4DのCPU35は、タグIDを受信した場合ステップS151肯定、タグID、移動イベント、格納先アドレス及びコマンドを含む移動イベント情報をPUSHサーバ2に送信しステップS152、図13に示す処理動作を終了する。また、RFIDリーダライタ39Aは、移動先の通信端末4EのタグIDを受信しなかった場合ステップS151否定、図13に示す処理動作を終了する。また、図14は、アドレス提供処理に関わるPUSHサーバ2の処理動作の一例を示すフローチャートである。図14に示すアドレス提供処理では、現在が提供タイミングの場合、提供タイミングに対応した通信端末4に対して提供対象のWebアプリに関わるリソースの格納先アドレス及びコマンドをPUSH送信する処理である。図14においてPUSHサーバ2のタイミング監視部14は、現在タイミングがアドレス管理部13に管理中の提供タイミングであるか否かを判定するステップS161。尚、タイミング監視部14は、提供タイミングが即時の場合、現在タイミングが提供タイミングであると判断する。タイミング監視部14は、現在タイミングが提供タイミングである場合ステップS161肯定、アドレス管理部13から提供タイミングに関わる端末ID151B、格納先アドレス151D及びコマンド151Gを特定するステップS162。PUSHサーバ2のPUSH送信部15は、端末ID151B、格納先アドレス151D及びコマンド151Gを特定すると、当該端末ID151Bの通信端末4に対して格納先アドレス151D及びコマンド151GをPUSH送信するステップS163。そして、図14に示す処理動作を終了する。尚、PUSH送信部15は、当該端末ID151Bの通信端末4に対して通信可能な状態であるか否かを判定し、通信可能な状態である場合、当該通信端末4に対して格納先アドレス151D及びコマンド151GをPUSH送信する。また、PUSHサーバ2の更新監視部12は、現在タイミングが提供タイミングでない場合ステップS161否定、各Webアプリの更新状況を監視しステップS164、提供タイミングを監視すべく、ステップS161に移行する。図14に示すアドレス提供処理では、現在が提供タイミングの場合、提供タイミングに対応した移動先の通信端末4Eに対して提供対象のWebアプリのリソースの格納先アドレス及びコマンドをPUSH送信する。その結果、移動先の通信端末4Eは、提供タイミングに応じたWebアプリのリソースの格納先アドレス及びコマンドを取得する。図15は、移動先の通信端末4Eの処理動作の一例を示すフローチャートである。図15において移動先の通信端末4EのPUSH受信部51は、PUSHサーバ2から格納先アドレス及びコマンドを受信したか否かを判定するステップS171。移動先の通信端末4Eのアプリ取得部52は、格納先アドレス及びコマンドを受信した場合ステップS171肯定、格納先アドレスに基づきWebサーバ3からWebアプリのリソースをダウンロードするステップS172。アプリ取得部52は、Webアプリのリソースの取得が完了したか否かを判定するステップS173。アプリ取得部52は、Webアプリに関わるリソースの取得が完了した場合ステップS173肯定、Webアプリのリソースを一時ストレージ53に登録するステップS174。更に、アプリ実行部43は、一時ストレージ53に登録済みのWebアプリのリソースをアプリキャッシュ42にキャッシュし、キャッシュされたWebアプリのリソースを、ステップS171で受信したコマンドに基づき実行するステップS175。そして、図15に示す処理動作を終了する。尚、アプリ実行部43は、アプリキャッシュ42にキャッシュされたリソースの復元プログラムを実行する。アプリ実行部43は、復元プログラムを実行することでリソース内のData.jsonファイル内に格納されたコンテンツを復元し、復元されたコンテンツをローカルストレージ45内に格納する。また、PUSH受信部51は、PUSHサーバ2から格納先アドレス及びコマンドを受信しなかった場合ステップS171否定、図15に示す処理動作を終了する。また、アプリ取得部52は、Webアプリのリソースの取得が完了しなかった場合ステップS173否定、ステップS173の監視動作を継続する。移動先の通信端末4Eは、PUSHサーバ2から格納先アドレス及びコマンドを受信した場合、格納先アドレスに基づきWebアプリ及びコンテンツを取得すると共に、コマンドに基づき、当該Webアプリを実行する。その結果、移動先の通信端末4Eは、移動元の通信端末4Dで実行中の同一Webアプリ4を実行できる。図16は、移動元の通信端末4Dと移動先の通信端末4Eとの連動動作の一例を示す説明図である。移動元の通信端末4Dを携帯電話機401、移動先の通信端末4Eをタブレット端末402とする。図16Aに示す携帯電話機401は、Webアプリを実行することで、表示部401AにWebアプリの実行画面を表示している。そして、携帯電話機401に対するタブレット端末402とのアプリ移動操作に応じて、携帯電話機401のRFIDリーダライタ39Aは、タブレット端末402のタグIDを取得する。更に、携帯電話機401は、取得されたタグIDと、携帯電話機401で実行中のWebアプリのリソースの格納先アドレス、移動イベント、Webアプリのダウンロード及び実行のコマンドを含む移動イベント情報をPUSHサーバ2に送信する。PUSHサーバ2のアドレス管理部13は、移動イベント情報を受信した場合、移動イベント情報内のタグID、移動イベント、格納先アドレス及びコマンドに基づき、端末IDに対応した提供タイミングを即時としてアドレス管理テーブル151を更新する。更に、アドレス管理部13は、取得したコマンドを端末IDに対応したコマンドとしてアドレス管理テーブル151を更新する。PUSHサーバ2のアドレス管理部13は、提供タイミングが即時のため、提供タイミングの端末ID、格納先アドレス及びコマンドをアドレス管理テーブル151から特定する。PUSHサーバ2のPUSH送信部15は、端末IDのタブレット端末402に対して格納先アドレス及びコマンドをPUSH送信する。そして、タブレット端末402は、格納先アドレスに基づき、携帯電話機401で実行中のWebアプリ及びコンテンツをWebサーバ3から取得し、コマンドに基づき、取得したWebアプリを実行して、Webアプリの実行画面を表示部402Aに表示する。その結果、タブレット端末402は、アプリ移動操作に応じて、図16Aに示す通り、携帯電話機401と同一のWebアプリを実行できることは勿論のこと、同一コンテンツも取得できる。また、図16Bに示すタブレット端末402は、その表示部402Aに動画を使用中に、携帯電話機401をかざした場合、携帯電話機401の表示部401Aに表示中の画面内容をタブレット端末402の表示部402Aに画面表示する。この際、タブレット端末402の表示部402Aは、使用中の動画画面と、携帯電話機401の表示部401Aの表示画面とに2分割して再レイアウトできる。尚、上記実施例2では、説明の便宜上、移動元の通信端末4D内にRFIDリーダライタ39A、移動先の通信端末4E内にRFIDタグ39Bを内蔵する態様で説明した。しかしながら、各通信端末44D,4Eは、RFIDリーダライタ39A及びRFIDタグ39B両方を内蔵しても良い。また、上記実施例2では、通信端末4間のアプリ移動操作にRFID通信機能を使用したが、通信端末4間のNFCNearFieldCommunication通信等の近距離無線通信や、通信端末4間で接触センサを使用した接触センサ方式を採用しても良い。図17は、実施例3のWebアプリ提供システムの使用形態の一例を示す説明図である。尚、実施例2のWebアプリ提供システム1Bと同一の構成には同一符号を付すことで、その重複する構成及び動作の説明については省略する。図17に示すWebアプリ提供システム1Cは、例えば、会議室で使用するWebアプリ提供システムを想定する。アドレス管理部13は、通信端末4の端末ID151Bに対応する提供タイミング151Eが通信端末4の保有者による会議室の入室タイミング、コマンド151GがWebアプリのダウンロード及び実行とする。尚、入室タイミングとは、例えば、会議室の入口に配置した入室監視装置の通信範囲内への通信端末4の進入による、入室監視装置と通信端末4との通信動作に応じて、通信端末4保有者の会議室への入室を検知したタイミングである。Webアプリは、プレゼン資料閲覧用のWebアプリである。コマンドは、プレゼン資料閲覧用のWebアプリのダウンロード及び実行である。また、アドレス管理部13は、通信端末4の識別情報に対応する提供タイミング151Eが通信端末4の保有者による会議室の退室タイミング、コマンド151GがWebアプリの消去とする。尚、退室タイミングは、入室監視装置の通信範囲内への通信端末4の再進入による、入室監視装置と通信端末4との通信動作に応じて、通信端末4保有者の会議室からの退室を検知したタイミングである。Webアプリは、プレゼン資料閲覧用のWebアプリである。コマンドは、プレゼン資料閲覧用のWebアプリの消去である。PUSHサーバ2のアドレス管理部13は、通信端末4の会議室の入室タイミングを検出した場合、この通信端末4の端末ID151B、格納先アドレス151D及びコマンド151Gをアドレス管理テーブル151から特定する。更に、PUSHサーバ2のPUSH送信部15は、特定された格納先アドレス及びコマンドを通信端末4に送信する。そして、会議室内の通信端末4は、格納先アドレスに基づき、Webサーバ3からプレゼン資料閲覧用のWebアプリのリソースを取得してキャッシュする。そして、通信端末4は、コマンド内容に基づき、プレゼン資料閲覧用のWebアプリを実行すると共に、キャッシュされたリソース内からコンテンツを取得できる。また、PUSHサーバ2のタイミング監視部14は、通信端末4の会議室の退室タイミングを検出した場合、この通信端末4の端末ID151B、格納先アドレス151D及びコマンド151Gをアドレス管理テーブル151から特定する。更に、PUSHサーバ2のPUSH送信部15は、特定された格納先アドレス及びコマンドを通信端末4に送信する。そして、会議室外の通信端末4は、格納先アドレスに基づきプレゼン資料閲覧用のWebアプリを特定し、コマンド内容に基づき、特定されたWebアプリ及びコンテンツをキャッシュから消去する。実施例3では、通信端末4のユーザが会議室に入室した場合、PUSHサーバ2は、提供タイミングと判断し、プレゼン資料閲覧用のWebアプリの格納先アドレス及びコマンドを通信端末4に提供する。そして、会議室内の通信端末4は、格納先アドレスに基づき、プレゼン資料閲覧のWebアプリに関わるリソースを取得してキャッシュし、そのコマンドに基づき、プレゼン資料閲覧用のWebアプリを実行すると共に、コンテンツを取得できる。また、実施例3では、通信端末4のユーザが会議室から退室した場合、PUSHサーバ2は、提供タイミングと判断し、プレゼン資料閲覧用のWebアプリの格納先アドレス及びコマンドを通信端末4に提供する。そして、会議室外の通信端末4は、格納先アドレスに基づき、プレゼン資料閲覧のWebアプリに関わるリソースを特定し、コマンドに基づき、プレゼン資料閲覧用のWebアプリ及びコンテンツをキャッシュから消去する。その結果、通信端末4のユーザは、会議室退室後に資料閲覧のWebアプリ及びコンテンツが閲覧できなくなるため、プレゼン資料の機密性を確保できる。図18は、実施例4のWebアプリ提供システム内部の一例を示す機能ブロック図である。尚、図1に示すWebアプリ提供システム1と同一の構成には同一符号を付すことで、その重複する構成及び動作の説明については省略する。図18に示すWebアプリ提供システム1Dと図1に示すWebアプリ提供システム1とが異なるところは、次の点にある。すなわち、ユーザに対する指定Webアプリの送信依頼を検出すると、当該ユーザが所有する複数の通信端末4の内、ユーザが現在使用している可能性の高い特定の通信端末4に指定のWebアプリ及びコンテンツを提供する点である。図18に示すPUSHサーバ2は、更新監視部12、アドレス管理部13、タイミング監視部14及びPUSH送信部15の他に、イベント受信部16を有する。イベント受信部16は、通信端末4からイベント情報を受信する。尚、イベント情報は、例えば、ユーザIDと、格納先アドレスと、イベント内容と、コマンドとを有する。尚、ユーザIDは、提供対象のWebアプリを提供するユーザのIDである。格納先アドレスは、提供対象のWebアプリに関わるリソースの格納先である。イベント内容は、Webアプリの送信提供依頼に応じたイベントである。コマンドは、提供対象のWebアプリを実行する実行内容である。また、アドレス管理部13は、アドレス管理テーブル151及びユーザ管理テーブル152を管理し、アドレス管理テーブル151及びユーザ管理テーブル152のテーブル内容を動的に更新登録する。また、アドレス管理部13は、アドレス管理テーブル151及びユーザ管理テーブル152のテーブル内容を参照して各種判定動作を実行するものである。図19は、アドレス管理テーブル151のテーブル内容の一例を示す説明図である。図19に示すアドレス管理テーブル151は、ユーザID151A、端末ID151B、アプリID151C、格納先アドレス151D及び提供タイミング151Eの他に、コマンド151Gを対応付けて管理している。コマンド151Gは、格納先アドレス151Dで特定するWebアプリの実行内容である。図20は、ユーザ管理テーブル152のテーブル内容の一例を示す説明図である。図20に示すユーザ管理テーブル152は、ユーザ毎に、所有の通信端末4に関わる管理リストを管理する。管理リストは、端末ID152Aと、端末種別152Bと、接続状態152Cと、最終通知時刻152Dと、最終使用時刻152Eと、位置情報152Fと、通知不可時間帯152Gと、タグID152Hとを対応付けている。端末ID152Aは、通信端末4を識別するIDである。端末種別152Bは、例えば、PC、携帯電話機やタブレット端末等の通信端末4の種別である。接続状態152Cは、通信端末4がPUSHサーバ2と通信可能な状態であるか否かを示すものである。接続状態152Cがオンの場合、通信端末4はPUSHサーバ2と通信可能な状態にある。接続状態152Cがオフの場合、通信端末4はPUSHサーバ2と通信不可の状態にある。また、アドレス管理部13は、各Webアプリの属性情報を格納する図示せぬ属性情報テーブルを管理し、属性情報テーブルを参照して、各Webアプリが対応している端末種別や場所、更には、そのWebアプリに関わるリソースの格納先アドレスを認識するものである。最終通知時刻152Dは、PUSHサーバ2が当該通信端末4に最後に通信した時刻である。最終使用時刻152Eは、当該通信端末4をユーザが最後に使用した時刻である。尚、最終使用時刻152Eは、ネットワーク状態の検知以外に、通信端末4の各種デバイスに備えたセンサや外部センサの情報に基づき判断するものである。例えば、通信端末4がPCの場合、PUSHサーバ2側でPCのキーボード入力を検知して、その時刻を最終使用時刻とする。また、例えば、通信端末4が携帯電話機の場合、PUSHサーバ2側で、携帯電話機内部の振動センサや加速度センサ等で得た情報を収集し、その収集結果に基づき携帯電話機の使用時刻を最終使用時刻とする。尚、最終使用時刻を決定する方法は適宜変更可能である。位置情報152Fは、通信端末4のGPSGlobalPositioningSystem機能や通信モジュールで得られた通信端末4の位置座標や場所名等の位置情報である。通知不可時間帯152Gは、ユーザ設定によるWebアプリの通知不可の時間帯である。尚、図中のD={0-9,21-24}、W={ST,SU}の意味は、毎日0時~9時、21時~24時は通信不可、かつ、土曜日及び日曜日は終日通信不可という意味である。タグID152Hは、通信端末4内蔵のRFIDタグを識別するIDである。次に実施例4のWebアプリ提供システム1Dの動作について説明する。図21は、ユーザ指定のアドレス提供処理に関わるPUSHサーバ2の処理動作の一例を示すフローチャートである。図21に示すアドレス提供処理は、ユーザに対するWebアプリの送信依頼を検出すると、ユーザ所有の複数の通信端末4の内、ユーザが現在使用中の可能性が高い通信端末4にWebアプリのリソースに関わる格納先アドレス及びコマンドを提供する処理である。図21においてPUSHサーバ2のアドレス管理部13は、特定ユーザに対するWebアプリの送信依頼を受信した場合、特定ユーザの管理リストをユーザ管理テーブル152から取得するステップS181。アドレス管理部13は、特定ユーザの管理リストを取得すると、管理リスト内の端末種別152Bと、Webアプリの属性情報テーブルとに基づき、指定のWebアプリが端末種別限定のアプリであるか否かを判定するステップS182。尚、端末種別限定のアプリとは、特定の端末種別の通信端末4でしか実行できないWebアプリである。アドレス管理部13は、指定のWebアプリが端末種別限定のアプリである場合ステップS182肯定、管理リスト内の接続状態152Cを参照して、接続状態がオン中の該当の通信端末4があるか否かを判定するステップS183。アドレス管理部13は、接続状態がオン中の該当の通信端末4がある場合ステップS183肯定、指定Webアプリを実行可能な通信端末4であると判断する。更に、アドレス管理部13は、管理リストの位置情報152Fと、Webアプリの属性情報テーブルとに基づき、指定のWebアプリが場所限定のアプリであるか否かを判定するステップS184。尚、場所限定のアプリとは、特定の場所でしか実行を許可していないWebアプリである。アドレス管理部13は、指定のWebアプリが場所限定のアプリである場合ステップS184肯定、管理リスト内の接続状態152Cを参照して、接続状態がオン中の該当の通信端末4があるか否かを判定するステップS185。更に、アドレス管理部13は、接続状態がオン中の該当の通信端末4がある場合ステップS185肯定、指定Webアプリが実行可能な場所にある通信端末4であると判断する。更に、アドレス管理部13は、指定のWebアプリを提供する該当の通信端末4があるか否かを判定するステップS186。尚、該当の通信端末4には、例えば、通知不可時間帯152Gの条件もクリアにした指定Webアプリが実行可能な通信端末4を含めても良い。アドレス管理部13は、該当の通信端末4がある場合ステップS186肯定、管理リスト内の最終使用時刻152Eを参照して、該当の通信端末4の端末IDの内、最新の最終使用時刻の端末IDがあるか否かを判定するステップS187。アドレス管理部13は、最新の最終使用時刻の端末IDがない場合ステップS187否定、管理リスト内の最終通知時刻152Dを参照して、該当の通信端末4の端末IDの内、最新の最終通知時刻の端末IDを取得するステップS188。アドレス管理部13は、最新の最終通知時刻の端末IDを取得すると、該当の端末IDに対応した該当Webアプリに関わる格納先アドレス及びコマンドをアドレス管理テーブル151から取得するステップS189。PUSH送信部15は、該当の端末IDに対応した該当Webアプリに関わる格納先アドレス及びコマンドを取得すると、格納先アドレス及びコマンドを該当の端末IDに対応した通信端末4に送信するステップS190。PUSH送信部15は、ステップS190に対する格納先アドレス及びコマンドの送信が成功したか否かを判定するステップS191。PUSH送信部15は、格納先アドレス及びコマンドの送信が成功した場合ステップS191肯定、図21に示す処理動作を終了する。アドレス管理部13は、格納先アドレス及びコマンドの送信が成功しなかった場合ステップS191否定、該当の通信端末4の内、2番目に新しい次位の最終使用時刻又は最終通知時刻の端末IDを取得するステップS192。更に、アドレス管理部13は、端末IDに対応した格納先アドレス及びコマンドを取得すべく、ステップS189に移行する。また、アドレス管理部13は、最新の最終使用時刻の端末IDがある場合ステップS187肯定、当該端末IDをアドレス管理テーブル151から取得するステップS193。更に、アドレス管理部13は、当該端末IDに対応した格納先アドレス及びコマンドを取得すべく、ステップS189に移行する。また、アドレス管理部13は、該当の通信端末4がない場合ステップS186否定、該当Webアプリに関わる格納先アドレス及びコマンドの送信を保留しステップS194、図21に示す処理動作を終了する。尚、保留の場合、PUSH送信部15は、該当の通信端末4が接続状態になった場合に、当該通信端末4に対してWebアプリに関わる格納先アドレス及びコマンドを再送するものである。また、アドレス管理部13は、指定のWebアプリが端末種別限定のアプリでない場合ステップS182否定、場所限定のアプリであるか否かを判定すべく、ステップS184に移行する。また、アドレス管理部13は、接続状態がオン中の該当の通信端末4がない場合ステップS183否定、ステップS185否定、該当Webアプリに関わる格納先アドレス及びコマンドの送信を保留しステップS195、図21に示す処理動作を終了する。尚、保留の場合、PUSH送信部15は、該当の通信端末4が接続状態になった場合に、当該通信端末4に対してWebアプリに関わる格納先アドレス及びコマンドを再送するものである。図21に示す処理では、PUSHサーバ2がユーザに対する指定Webアプリの送信依頼を受信した場合、指定ユーザ所有の複数の通信端末4の内、指定Webアプリに適用した現在使用している可能性の高い通信端末4の端末IDを取得する。更に、PUSHサーバ2は、取得した端末IDの通信端末4に対して指定のWebアプリに関わる格納先アドレス及びコマンドを送信する。その結果、PUSHサーバ2は、指定ユーザ所有の複数の通信端末4の内、当該ユーザが現在使用している可能性の高い通信端末4に対して指定のWebアプリに関わる格納先アドレス及びコマンドを通知できる。また、PUSHサーバ2は、指定ユーザ所有の複数の通信端末4の内、端末種別限定のアプリに対応した現在使用している可能性の高い通信端末4に対して指定のWebアプリに関わる格納先アドレス及びコマンドを送信する。PUSHサーバ2では、携帯電話機限定のアプリであるにも関わらず、現在使用している可能性の高い通信端末4がPCの場合に、当該PCに対して携帯電話機限定のアプリの格納先アドレスを送信してしまうような事態を回避できる。また、PUSHサーバ2は、指定ユーザ所有の複数の通信端末4の内、場所限定のアプリに対応した現在使用している可能性の高い通信端末4に対して指定のWebアプリに関わる格納先アドレス及びコマンドを送信する。PUSHサーバ2では、会社内限定の機密書類閲覧に関わるWebアプリであるにも関わらず、現在使用している可能性が高い通信端末4が社外である自宅のPCに対して機密書類閲覧のアプリの格納先アドレスを送信してしまうような事態を回避できる。そして、通信端末4は、PUSHサーバ2から格納先アドレス及びコマンドを受信した場合、格納先アドレスで指定のWebアプリのリソースをWebサーバ3から取得して、リソースをアプリキャッシュ42にキャッシュする。更に、通信端末4は、PUSHサーバ2から受信したコマンドに基づき、アプリキャッシュ42にキャッシュされたWebアプリを実行する。更に、通信端末4は、アプリキャッシュ42にキャッシュされたリソースの復元プログラムを実行することでコンテンツを復元し、そのコンテンツをローカルストレージ45内に格納する。その結果、通信端末4のユーザは、コンテンツも含めて指定Webアプリを取得できる。実施例4では、PUSHサーバ2がユーザに対する指定Webアプリの送信依頼を受信した場合、指定ユーザ所有の複数の通信端末4の内、指定Webアプリの端末種別限定や場所限定に適用した、現在使用している可能性の高い通信端末4の端末IDを取得する。更に、PUSHサーバ2は、取得された端末IDの通信端末4に対して指定のWebアプリの格納先アドレス及びコマンドを送信する。その結果、PUSHサーバ2は、指定ユーザ所有の複数の通信端末4の内、当該ユーザが現在使用している可能性の高い通信端末4に対して指定のWebアプリに関わる格納先アドレス及びコマンドを通知できる。例えば、各ユーザが、稟議書承認用のWebアプリを使用して、自分の通信端末4で、そのコンテンツである稟議書の内容を確認して稟議書の内容を承認するシステムを想定する。この場合、各ユーザの通信端末4には、稟議書承認用のWebアプリは勿論のこと、そのコンテンツである稟議書の内容が必要となる。そこで、各ユーザは、指定した稟議書承認用Webアプリの送信依頼をPUSHサーバ2に送信する。PUSHサーバ2は、送信依頼を受信した場合、ユーザ所有の複数の通信端末4の内、現在使用している可能性の高い通信端末4の端末IDを取得する。そして、PUSHサーバ2は、取得された端末IDの通信端末4に対して稟議書承認用Webアプリの格納先アドレス及びコマンドを送信する。尚、Webサーバ3の格納先アドレスには、稟議書承認用Webアプリのリソース内に稟議書の内容であるコンテンツも格納されている。従って、通信端末4は、格納先アドレスに基づき、稟議書承認用WebアプリのリソースをWebサーバ3から取得し、コマンドに基づき、取得された稟議書承認用Webアプリを実行すると共に、そのコンテンツも取得する。その結果、各ユーザは、自分の通信端末4の稟議書承認用Webアプリを使用して稟議書の内容を確認して承認できる。尚、上記実施例4では、端末種別限定アプリ、場所限定種別アプリ、接続状態、最終通知時刻、最終使用時刻、通知不可時間帯の全ての条件をクリアした通信端末4に指定Webアプリの格納先アドレス及びコマンドを送信した。しかしながら、PUSH送信部15は、これら条件の一部をクリアした通信端末4でも、指定Webアプリの格納先アドレス及びコマンドを送信するようにしても良く、その条件は、適宜選択変更可能である。また、上記実施例4では、PUSHサーバ2がユーザに対する指定Webアプリの送信依頼を受信した場合、指定ユーザ所有の複数の通信端末4の内、現在使用している可能性の高い通信端末4に格納先アドレス及びコマンドを送信した。しかしながら、PUSHサーバ2は、現在使用している可能性の高い通信端末4を1台に限定するものではなく、複数台としても良い。また、PUSHサーバ2は、現在使用している可能性の高い通信端末4に格納先アドレス及びコマンドを送信したが、ユーザ所有の全ての通信端末4に格納先アドレス及びコマンドを送信しても良い。また、図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散統合して構成することができる。更に、各装置で行われる各種処理機能は、CPUCentralProcessingUnit又はMPUMicroProcessingUnit、MCUMicroControllerUnit等のマイクロコンピュータ上で、その全部又は任意の一部を実行するようにしても良い。また、各種処理機能は、CPU又はMPU、MCU等のマイクロコンピュータで解析実行するプログラム上、又はワイヤードロジックによるハードウェア上で、その全部又は任意の一部を実行するようにしても良いことは言うまでもない。ところで、本実施例で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図22を用いて、上記の実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図22は、アプリ提供プログラムを実行するコンピュータを示す説明図である。図22に示すように、アプリ提供プログラムとしてのコンピュータ100では、HDDHardDiskDrive110、RAMRandomAccessMemory120、ROMReadOnlyMemory130及びCPU140がバス150を介して接続される。そして、ROM130若しくはHDD110には、上記の実施例と同様の機能を発揮するアプリ提供プログラムが予め記憶されている。尚、ROM130及びHDD110ではなく、図示せぬドライブでコンピュータ読取可能な記録媒体にアプリ提供プログラムが記録されていても良い。また、記録媒体としては、例えば、CD-ROM、DVDディスク、USBメモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリ等でも良い。アプリ提供プログラムとしては、図22に示すように、格納プログラム131及び提供プログラム132である。尚、格納プログラム131及び提供プログラム132については、図1に示したWebサーバ3の各構成要素と同様、適宜統合又は分散してもよい。そして、CPU140が、これらの格納プログラム131及び提供プログラム132をROM130から読み出して実行する。そして、図22に示すように、各プログラム131及び132は、格納プロセス141及び提供プロセス142として機能するようになる。CPU140は、通信端末4で実行するWebアプリで編集したコンテンツを検出した場合、当該Webアプリのリソース内に編集したコンテンツを格納する。CPU140は、通信端末4からWebアプリを要求するアプリ要求を検出した場合、当該Webアプリのリソースを、当該アプリ要求を実行した通信端末4に提供する。その結果、通信端末4、すなわちクライアント側では、オフライン時でもWebアプリ実行時に最新の編集コンテンツを取得できる。以上、本実施例を含む実施の形態に関し、更に以下の付記を開示する。付記1プロセッサを備えた通信装置と、前記通信装置に対してWebアプリのリソースを提供する、プロセッサを備えたアプリ提供装置とを有し、前記アプリ提供装置のプロセッサは、前記通信装置で実行する前記Webアプリで編集したコンテンツを検出した場合、当該Webアプリのリソース内に編集したコンテンツを格納し、前記通信装置から前記Webアプリを要求するアプリ要求を検出した場合、当該Webアプリのリソースを、当該アプリ要求を実行した前記通信装置に提供する各処理を実行し、前記通信装置のプロセッサは、前記アプリ提供装置から前記Webアプリのリソースを受信した場合、当該リソースを一時保存し、保存されたリソースをWebブラウザのキャッシュに同期させ、当該キャッシュされた前記リソースに基づき、Webアプリを実行すると共に、キャッシュされた前記リソースに基づき、リソース内に格納した前記コンテンツを復元する各処理を実行することを特徴とするアプリ提供システム。付記2前記アプリ提供装置の前記プロセッサは、前記リソース内に編集したコンテンツを格納する処理において、前記編集したコンテンツを転送ファイルに変換し、前記転送ファイルに変換された前記コンテンツを当該Webアプリのリソース情報内に格納する各処理を実行することを特徴とする付記1に記載のアプリ提供システム。付記3前記通信装置のプロセッサは、前記Webアプリのコンテンツ更新に応じて当該コンテンツ更新に関わるWebアプリの格納先アドレスを受信した場合、当該格納先アドレスに基づき、当該格納先アドレスの前記Webアプリのリソースを要求する前記アプリ要求を実行することを特徴とする付記1又は2に記載のアプリ提供システム。付記4前記通信装置のプロセッサは、当該通信装置に対する前記Webアプリの送信依頼に応じて当該Webアプリの格納先アドレス及びコマンドを受信した場合、当該格納先アドレスに基づき、当該格納先アドレスの前記Webアプリのリソースを要求する前記アプリ要求を実行し、前記アプリ提供装置から前記Webアプリのリソースを受信した場合、当該リソースを一時保存し、保存されたリソースをWebブラウザのキャッシュに同期させ、当該キャッシュされた前記リソース及び前記コマンドに基づき、Webアプリを実行すると共に、キャッシュされた前記リソースに基づき、リソース内に格納した前記コンテンツを復元することを特徴とする付記1又は2に記載のアプリ提供システム。付記5通信装置と、前記通信装置に対してWebアプリのリソースを提供するアプリ提供装置とを有するアプリ提供システムのアプリ提供方法であって、前記アプリ提供装置は、前記通信装置で実行する前記Webアプリで編集したコンテンツを検出した場合、当該Webアプリのリソース内に編集したコンテンツを格納し、前記通信装置からWebアプリを要求するアプリ要求を検出した場合、当該Webアプリのリソースを、当該アプリ要求を実行した前記通信装置に提供し、前記通信装置は、前記アプリ提供装置から前記Webアプリのリソースを受信した場合、当該リソースを一時保存し、保存されたリソースをWebブラウザのキャッシュに同期させ、当該キャッシュされた前記リソースに基づき、Webアプリを実行すると共に、キャッシュされた前記リソースに基づき、リソース内に格納した前記コンテンツを復元する各処理を実行することを特徴とするアプリ提供方法。付記6コンピュータに、通信装置で実行するWebアプリで編集したコンテンツを検出した場合、当該Webアプリのリソース内に編集したコンテンツを格納し、前記通信装置からWebアプリを要求するアプリ要求を検出した場合、当該Webアプリのリソースを、当該アプリ要求を実行した前記通信装置に提供する処理を実行させることを特徴とするアプリ提供プログラム。付記7通信装置で実行するWebアプリで編集したコンテンツを検出した場合、当該Webアプリのリソース内に編集したコンテンツを格納する格納制御部と、前記通信装置からWebアプリを要求するアプリ要求を検出した場合、当該Webアプリのリソースを、当該アプリ要求を実行した前記通信装置に提供する提供部とを有することを特徴とするアプリ提供装置。付記8Webアプリのリソースを提供するアプリ提供装置から前記Webアプリのリソースを受信した場合に、当該リソースをキャッシュするキャッシュと、前記キャッシュにキャッシュされた前記リソースに基づき、Webアプリを実行すると共に、前記キャッシュにキャッシュされた前記リソースに基づき、当該リソース内に格納されたコンテンツを復元するアプリ実行部と、を有することを特徴とする通信装置。"