以下、図面に基づいて、本願の開示するアプリ提供システム及びアプリ提供方法の実施例を詳細に説明する。尚、本実施例により、開示技術が限定されるものではない。
図1は、実施例1のWebアプリ提供システム内部の一例を示す機能ブロック図である。図1に示すWebアプリ提供システム1は、PUSHサーバ2と、Webサーバ3と、通信端末4とを有する。尚、PUSHサーバ2、Webサーバ3及び通信端末4は、例えば、無線や有線等の通信網を通じて通信接続する。PUSHサーバ2は、アプリポータルサーバ11と、更新監視部12と、アドレス管理部13と、タイミング監視部14と、PUSH送信部15とを有する。アプリポータルサーバ11は、通信端末4から所望のWebアプリのリソースの取得要求を受け付ける。尚、リソースとは、Webアプリの構成要素、例えば、HTML、CSS及びJavaScriptである。更新監視部12は、各Webサーバ3で管理するWebアプリの更新状況を集中管理するアプリデータベース(以下、単にアプリDBと称する)5にアクセスし、各Webアプリの更新状況を監視する。尚、更新監視部12は、各Webサーバ3にアクセスして各Webサーバ3で管理するWebアプリの更新状況を監視しても良い。
図2は、アドレス管理部13のテーブル内容の一例を示す説明図である。図2に示すアドレス管理部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は、例えば、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とを有する。アプリ管理部21は、格納先アドレス毎にWebアプリのリソース等を格納したアプリパッケージ23を管理する。アプリパッケージ23は、マニフェスト24と、リソース25とを有する。マニフェスト24は、Webアプリのリソースの一覧である。リソース25は、Webアプリに使用するリソース一式である。アプリ提供部22は、通信端末4からのアプリ要求を検出すると、当該アプリ要求に対するWebアプリのマニフェスト24及びリソース25をアプリ管理部21から取得する。更に、アプリ提供部22は、取得されたWebアプリのマニフェスト24及びリソース25を、アプリ要求を実行した通信端末4に提供する。
通信端末4は、通信機能を備えた、例えば、携帯電話機、スマートフォン、パソコンやタブレット端末等に相当する。通信端末4は、通信部31と、操作部32と、表示部33と、メモリ34と、CPU35とを有する。通信部31は、通信網等を通じて他の通信端末4やサーバ等と通信接続する。操作部32は、各種コマンドを入力する。表示部33は、各種情報を表示する。メモリ34は、各種情報等を記憶する。CPU35は、通信端末4全体を制御する。CPU35は、PUSHクライアント36及びWebブラウザ40等のソフトウェア機能を実行する。
また、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とを有する。キャッシュ同期部41は、一時ストレージ53に登録済みのリソースをCPU35が解釈可能なデータ形式に変換し、この変換されたリソースをアプリキャッシュ42にキャッシュする。アプリ実行部43は、アプリキャッシュ42にキャッシュされたリソースに基づき、Webアプリを実行する。尚、キャッシュ同期部41は、Webブラウザ40外にあっても良い。
Webアプリ提供システム1では、PULL方式と、PUSH方式とがある。PULL方式では、通信端末4が所望のWebアプリのリソースの格納先アドレスをPUSHサーバ2内のアプリポータルサーバ11に要求する。そして、通信端末4は、PUSHサーバ2から取得した格納先アドレスに基づき、Webアプリのリソースを取得する。また、前述した通り、PUSH方式では、PUSHサーバ2がWebアプリの提供タイミングに応じてWebアプリのリソースの格納先アドレスを通信端末4に提供する。そして、通信端末4は、PUSHサーバ2から取得した格納先アドレスに基づき、Webアプリのリソースを取得する。
次に、実施例1のWebアプリ提供システム1の動作について説明する。図3は、実施例1のWebアプリ提供システム1の使用形態の一例を示す説明図である。図3に示すWebアプリ提供システム1では、PUSHサーバ2と、Webサーバ3と、通信端末4とを有する。
通信端末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アプリの取得操作を行わなくても、資料閲覧アプリでプレゼン資料を閲覧できる。
図4は、アドレス提供処理に関わるPUSHサーバ2の処理動作の一例を示すフローチャートである。図4に示すアドレス提供処理では、Webアプリの提供タイミングを監視し、当該提供タイミングを検出すると、提供タイミングに対応した通信端末4に提供対象のWebアプリに関わるリソースの格納先アドレスをPUSH送信する処理である。図4に示すPUSHサーバ2のタイミング監視部14は、現在タイミングがアドレス管理部13に管理中の提供タイミングであるか否かを判定する(ステップS11)。タイミング監視部14は、現在タイミングが提供タイミングである場合(ステップS11肯定)、アドレス管理部13から提供タイミングに関わる端末ID13B及び格納先アドレス13Dを特定する(ステップS12)。
PUSHサーバ2のPUSH送信部15は、端末ID13B及び格納先アドレス13Dを特定すると、当該端末ID13Bの通信端末4に対して格納先アドレス13DをPUSH送信し(ステップS13)、図4に示す処理動作を終了する。尚、PUSH送信部15は、当該端末ID13Bの通信端末4に対して通信可能な状態であるか否かを判定し、通信可能な状態である場合、当該通信端末4に対して格納先アドレス13DをPUSH送信する。また、PUSHサーバ2の更新監視部12は、現在タイミングが提供タイミングでない場合(ステップS11否定)、アプリDB5内で各Webアプリの更新状況を監視し(ステップS14)、提供タイミングを監視すべく、ステップS11に移行する。
図4に示すアドレス提供処理では、Webアプリの提供タイミングを監視し、当該提供タイミングを検出すると、提供タイミングに対応した通信端末4に提供対象のWebアプリのリソースの格納先アドレスをPUSH送信する。その結果、通信端末4は、提供タイミングに応じたWebアプリのリソースの格納先アドレスを認識できる。
図5は、Webアプリ取得処理に関わる通信端末4の処理動作の一例を示すフローチャートである。図5に示すWebアプリ取得処理では、PUSHサーバ2から取得した格納先アドレスに基づきWebアプリのリソースをWebサーバ3から取得し、リソースをアプリキャッシュ42にキャッシュする処理である。図5において通信端末4のPUSHクライアント36のPUSH受信部51は、PUSHサーバ2から格納先アドレスを受信したか否かを判定する(ステップS21)。PUSHクライアント36のアプリ取得部52は、格納先アドレスを受信した場合(ステップS21肯定)、格納先アドレスに基づきWebサーバ3に対してWebアプリを要求する(ステップS22)。アプリ取得部52は、Webアプリ要求に対するリソースを取得したか否かを判定する(ステップS23)。
アプリ取得部52は、リソースを取得した場合(ステップS23肯定)、取得されたリソースを一時ストレージ53に登録する(ステップS24)。Webブラウザ40のキャッシュ同期部41は、一時ストレージ53に登録済みのリソースをCPU35側で解釈可能なデータ形式に変換する(ステップS26)。更に、キャッシュ同期部41は、変換されたリソースをアプリキャッシュ42にキャッシュし(ステップS27)、図5に示す処理動作を終了する。
アプリ取得部52は、格納先アドレスを受信していない場合(ステップS21否定)、一時ストレージ53に登録済みのリソースがあるか否かを判定する(ステップS28)。アプリ取得部52は、一時ストレージ53に登録済みのリソースがある場合(ステップS28肯定)、登録済みのリソースを変換すべく、ステップS26に移行する。
また、アプリ取得部52は、一時ストレージ53に登録済みのリソースがない場合(ステップS28否定)、図5に示す処理動作を終了する。
図5に示すWebアプリ取得処理では、PUSHサーバ2から取得した格納先アドレスに基づきWebアプリのリソースをWebサーバ3から取得し、リソースをアプリキャッシュ42にキャッシュする。その結果、通信端末4は、キャッシュされたリソースに基づきWebアプリを実行できる。
Webアプリ取得処理では、Webブラウザ40が起動しているかどうかに関わらず、一時ストレージ53に登録済みのリソースを読み出し、リソースをアプリキャッシュにキャッシュする。その結果、提供タイミングに応じたWebアプリを自動取得できる。
実施例1では、PUSHサーバ2が、Webアプリの提供タイミングを検出した場合、当該提供タイミングに関わる通信端末4に対して、当該提供タイミングに関わるWebアプリのリソースの格納先アドレスを提供する。更に、通信端末4は、格納先アドレスを受信した場合、当該格納先アドレスに基づき、Webアプリのリソースを要求するアプリ要求を実行する。更に、通信端末4は、アプリ要求に応じて提供されたWebアプリのリソースをアプリキャッシュ42にキャッシュし、キャッシュされたWebアプリのリソースに基づき、当該Webアプリを実行する。その結果、通信端末4のユーザは、アプリ取得に関わる要求操作を実行しなくても、必要な時に必要なWebアプリを提供タイミングに応じて自動的に取得できる。
実施例1では、ユーザの操作なしでWebアプリ実行に必要な最新のリソースを取得できる。また、アプリ開発者は、デバイス毎にローカルアプリを開発する必要がなくなり、一つのWebアプリを開発するだけで済むため、開発コストを数分の一に抑制できる。しかも、ユーザは、面倒なインストール作業を一切行う必要がなく、アプリを使用できる。
尚、上記実施例1では、通信端末4、例えば、携帯電話機内にPUSHクライアント36を内蔵したが、通信端末4A、例えば、パソコンに対してPUSHクライアント36をUSB(Universal Serial Bus)で外部接続するようにしても良い。この場合の実施の形態につき、実施例2として説明する。
図6は、実施例2のWebアプリ提供システム1A内部の一例を示すブロック図である。尚、実施例1のWebアプリ提供システムと同一の構成には同一符号を付すことで、その重複する構成及び動作の説明については省略する。
図6に示すWebアプリ提供システム1Aと図1に示すWebアプリ提供システム1とが異なるところは、外部接続機器38内のCPU37上で動作するPUSHクライアント36Aが、例えば、パソコン等の通信端末4Aに対してUSB61で接続した点にある。図6に示す通信端末4Aは、通信部31、操作部32、表示部33、メモリ34及びCPU35を有する。通信端末4Aは、CPU37上で動作するPUSHクライアント36AとUSB61で接続する。更に、PUSHクライアント36Aは、PUSH受信部51、アプリ取得部52及び一時ストレージ53の他に、通信モジュール54を有する。通信モジュール54は、通信端末4Aの電源がOFF状態でも、PUSHサーバ2からのPUSH送信に対して受信可能にするものである。
図7は、実施例2のWebアプリ取得処理に関わる通信端末4A及びPUSHクライアント36Aの処理動作の一例を示すフローチャートである。PUSHサーバ2は、提供タイミングを検出すると、通信端末4Aが電源OFF状態でも、提供タイミングに関わるWebアプリのリソースに関わる格納先アドレスをPUSHクライアント36Aに送信する。
図7においてPUSHクライアント36AのPUSH受信部51は、PUSHサーバ2から格納先アドレスを受信したか否かを判定する(ステップS31)。PUSHクライアント36Aのアプリ取得部52は、格納先アドレスを受信した場合(ステップS31肯定)、格納先アドレスに関わるWebアプリ要求をWebサーバ3に送信する(ステップS32)。アプリ取得部52は、Webアプリ要求に対して、当該格納先アドレスに格納されたWebサーバ3側のWebアプリのリソースを取得したか否かを判定する(ステップS33)。アプリ取得部52は、Webアプリのリソースを取得した場合(ステップS33肯定)、当該リソースを一時ストレージ53に登録する(ステップS34)。
次に、PUSHクライアント36AのCPU37は、リソースを一時ストレージ53に登録すると、通信端末4Aが起動済みであるか否かを判定する(ステップS35)。通信端末4AのWebブラウザ40のキャッシュ同期部41は、通信端末4Aが起動済みである場合(ステップS35肯定)、PUSHクライアント36Aの一時ストレージ53に登録済みのリソースをCPU35で解釈可能なデータ形式に変換する(ステップS36)。更に、キャッシュ同期部41は、変換されたリソースをアプリキャッシュ42にキャッシュする(ステップS37)。その結果、Webブラウザ40のアプリ実行部43は、キャッシュされたリソースに基づき、Webアプリを実行する。
また、アプリ取得部52は、格納先アドレスを受信していない場合(ステップS31否定)、一時ストレージ53に登録済みのリソースがあるか否かを判定する(ステップS38)。アプリ取得部52は、一時ストレージ53に登録済みのリソースがある場合(ステップS38肯定)、通信端末4Aが起動済みであるか否かを判定すべく、ステップS35に移行する。
また、アプリ取得部52は、一時ストレージ53に登録済みのリソースがない場合(ステップS38否定)、図7に示す処理動作を終了する。また、CPU37は、通信端末4Aが起動済みでない場合(ステップS35否定)、通信端末4Aの電源をONにしてWebブラウザ40を起動し(ステップS39)、一時ストレージ53に登録済みのリソースを変換すべく、ステップS36に移行する。
実施例2では、PUSHクライアント36A内に通信モジュール54を備えているため、通信端末4A側の電源がOFF状態でも、PUSHクライアント36AがPUSHサーバ2からの格納先アドレスを受信する。その結果、PUSHクライアント36Aは、通信端末4A側の電源がOFF状態でも、PUSHサーバ2からの格納先アドレスを受信できる。
しかも、実施例2では、Webアプリの提供タイミングを検出すると、提供タイミングに関わるPUSHクライアント36AにWebアプリのリソースに関わる格納先アドレスを送信する。更に、PUSHクライアント36Aは、受信した格納先アドレスに基づきWebサーバ3からWebアプリのリソースを受信する。PUSHクライアント36Aは、リソースをWebブラウザ40のアプリキャッシュ42にキャッシュする。Webブラウザ40のアプリ実行部43は、キャッシュされたリソースに基づき、Webアプリを実行する。その結果、通信端末4Aのユーザは、アプリ取得に関わる要求操作を実行しなくても、必要な時に必要なWebアプリを提供タイミングに応じて自動的に取得できる。
尚、上記実施例のタイミング監視部14では、アドレス管理部13内の端末ID13B毎の提供タイミング13Eに基づき、端末ID13Bで識別する通信端末4A毎の提供タイミングを監視した。しかしながら、タイミング監視部14は、アドレス管理部13内のユーザID13A毎の提供タイミング13Eを監視しても良く、この場合、ユーザID13Aで識別するユーザの各提供タイミングを監視する。
また、上記実施例では、Webアプリのリソースを管理するアプリ管理部21をWebサーバ3側に管理したが、アプリ管理部21をPUSHサーバ2に内蔵しても良い。この場合、PUSHサーバ2のタイミング監視部14は、提供タイミングを検出すると、提供タイミングに関わる端末ID13B及び格納先アドレス13Dを特定する。タイミング監視部14は、格納先アドレス13Dに基づき内部のアプリ管理部21からリソースを取得する。更に、PUSH送信部15は、端末ID13Bの通信端末4に対して、当該提供タイミングのWebアプリのリソースをPUSH送信しても良い。
また、上記実施例では、通信端末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アプリが閲覧できなくなるため、プレゼン資料の機密性を確保できる。
図8は、実施例3のWebアプリ提供システム内部の一例を示す機能ブロック図である。尚、図1に示すWebアプリ提供システム1と同一の構成には同一符号を付すことで、その重複する構成及び動作の説明については省略する。図8に示すWebアプリ提供システム1Bと図1に示すWebアプリ提供システム1とが異なるところは、簡単な操作で、移動元の通信端末4Dで実行中のWebアプリを移動先の通信端末4E側でも実行できる点にある。尚、移動元の通信端末4Dは、Webアプリ実行中の通信端末4である。これに対して、移動先の通信端末4Eは、移動元の通信端末4Dで実行中のWebアプリと同一アプリを実行させる通信端末4である。
図8に示すPUSHサーバ2は、アプリポータルサーバ11、更新監視部12、アドレス管理部13、タイミング監視部14及びPUSH送信部15の他に、イベント受信部16を有する。イベント受信部16は、移動元の通信端末4Dから後述するイベント情報を受信する。また、アドレス管理部13は、アドレス管理テーブル151を管理し、アドレス管理テーブル151のテーブル内容を動的に更新登録する。図9は、アドレス管理テーブル151のテーブル内容の一例を示す説明図である。図9に示すアドレス管理テーブル151は、ユーザID151A、端末ID151B、アプリID151C、格納先アドレス151D及び提供タイミング151Eの他に、タグID151F及びコマンド151Gを対応付けて管理している。タグID151Fは、通信端末4Eに内蔵した後述するRFIDタグ39Bを識別するIDである。コマンド151Gは、格納先アドレス151Dで特定するWebアプリの実行内容である。尚、コマンド151Gには、Webアプリの実行内容、例えば、ダウンロード及び実行、ダウンロードのみ、実行のみ、消去等がある。
移動元の通信端末4Dは、通信部31、操作部32、表示部33、メモリ34及びCPU35の他、RFID(Radio Frequency Identification)リーダライタ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アプリを実行する。
つまり、移動先の通信端末4Eは、移動元の通信端末4Dとのアプリ移動操作に応じて、移動元の通信端末4Dで実行中の同一Webアプリを実行できる。
次に、実施例3のWebアプリ提供システム1Bの動作について説明する。図10は、移動元の通信端末4Dの処理動作の一例を示すフローチャートである。図10において移動元の通信端末4DのRFIDリーダライタ39Aは、移動先の通信端末4Eとのアプリ移動操作に伴う近距離無線通信に応じて移動先の通信端末4EのタグIDを受信したか否かを判定する(ステップS51)。移動元の通信端末4DのCPU35は、タグIDを受信した場合(ステップS51肯定)、タグID、移動イベント、格納先アドレス及びコマンドを含む移動イベント情報をPUSHサーバ2に送信し(ステップS52)、図10に示す処理動作を終了する。また、RFIDリーダライタ39Aは、移動先の通信端末4EのタグIDを受信しなかった場合(ステップS51否定)、図10に示す処理動作を終了する。
また、図11は、アドレス提供処理に関わるPUSHサーバ2の処理動作の一例を示すフローチャートである。図11に示すアドレス提供処理では、現在が提供タイミングの場合、提供タイミングに対応した通信端末4に対して提供対象のWebアプリに関わるリソースの格納先アドレス及びコマンドをPUSH送信する処理である。図11においてPUSHサーバ2のタイミング監視部14は、現在タイミングがアドレス管理部13に管理中の提供タイミングであるか否かを判定する(ステップS61)。尚、タイミング監視部14は、提供タイミングが“即時”の場合、現在タイミングが提供タイミングであると判断する。タイミング監視部14は、現在タイミングが提供タイミングである場合(ステップS61肯定)、アドレス管理部13から提供タイミングに関わる端末ID151B、格納先アドレス151D及びコマンド151Gを特定する(ステップS62)。
PUSHサーバ2のPUSH送信部15は、端末ID151B、格納先アドレス151D及びコマンド151Gを特定すると、当該端末ID151Bの通信端末4に対して格納先アドレス151D及びコマンド151GをPUSH送信する(ステップS63)。そして、図11に示す処理動作を終了する。尚、PUSH送信部15は、当該端末ID151Bの通信端末4に対して通信可能な状態であるか否かを判定し、通信可能な状態である場合、当該通信端末4に対して格納先アドレス151D及びコマンド151GをPUSH送信する。また、PUSHサーバ2の更新監視部12は、現在タイミングが提供タイミングでない場合(ステップS61否定)、アプリDB5内で各Webアプリの更新状況を監視し(ステップS64)、提供タイミングを監視すべく、ステップS61に移行する。
図11に示すアドレス提供処理では、現在が提供タイミングの場合、提供タイミングに対応した移動先の通信端末4Eに対して提供対象のWebアプリのリソースの格納先アドレス及びコマンドをPUSH送信する。その結果、移動先の通信端末4Eは、提供タイミングに応じたWebアプリのリソースの格納先アドレス及びコマンドを取得する。
図12は、移動先の通信端末4Eの処理動作の一例を示すフローチャートである。図12において移動先の通信端末4EのPUSH受信部51は、PUSHサーバ2から格納先アドレス及びコマンドを受信したか否かを判定する(ステップS71)。移動先の通信端末4Eのアプリ取得部52は、格納先アドレス及びコマンドを受信した場合(ステップS71肯定)、格納先アドレスに基づきWebサーバ3からWebアプリのリソースをダウンロードする(ステップS72)。
アプリ取得部52は、Webアプリのリソースの取得が完了したか否かを判定する(ステップS73)。アプリ取得部52は、Webアプリに関わるリソースの取得が完了した場合(ステップS73肯定)、Webアプリのリソースを一時ストレージ53に登録する(ステップS74)。更に、アプリ実行部43は、一時ストレージ53に登録済みのWebアプリのリソースをアプリキャッシュ42にキャッシュし、キャッシュされたWebアプリのリソースを、ステップS71で受信したコマンドに基づき実行する(ステップS75)。そして、図12に示す処理動作を終了する。
また、PUSH受信部51は、PUSHサーバ2から格納先アドレス及びコマンドを受信しなかった場合(ステップS71否定)、図12に示す処理動作を終了する。また、アプリ取得部52は、Webアプリのリソースの取得が完了しなかった場合(ステップS73否定)、ステップS73の監視動作を継続する。
移動先の通信端末4Eは、PUSHサーバ2から格納先アドレス及びコマンドを受信した場合、格納先アドレスに基づきWebアプリを取得すると共に、コマンドに基づき、当該Webアプリを実行する。その結果、移動先の通信端末4Eは、移動元の通信端末4Dで実行中の同一Webアプリ4を実行できる。
図13は、移動元の通信端末4Dと移動先の通信端末4Eとの連動動作の一例を示す説明図である。移動元の通信端末4Dを携帯電話機401、移動先の通信端末4Eをタブレット端末402とする。図13(A)に示す携帯電話機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は、アプリ移動操作に応じて、図13(A)に示す通り、携帯電話機401と同一のWebアプリを実行できる。
また、図13(B)に示すタブレット端末402は、その表示部402Aに動画を使用中に、携帯電話機401をかざした場合、携帯電話機401の表示部401Aに表示中の画面内容をタブレット端末402の表示部402Aに画面表示する。この場合、表示部402Aは、近距離無線通信のリーダ部を含み、表示部402AにRFIDタグをかざすと、RFIDタグと近距離無線通信を行う機能を有する。この際、タブレット端末402の表示部402Aは、使用中の動画画面と、携帯電話機401の表示部401Aの表示画面とに2分割して再レイアウトできる。
尚、上記実施例3では、説明の便宜上、移動元の通信端末4D内にRFIDリーダライタ39A、移動先の通信端末4E内にRFIDタグ39Bを内蔵する態様で説明した。しかしながら、各通信端末4(4D,4E)は、RFIDリーダライタ39A及びRFIDタグ39B両方を内蔵しても良い。
また、上記実施例3では、通信端末4間のアプリ移動操作にRFID通信機能を使用したが、通信端末4間のNFC(Near Field Communication)通信等の近距離無線通信や、通信端末4間で接触センサを使用した接触センサ方式を採用しても良い。
図14は、実施例4のWebアプリ提供システムの使用形態の一例を示す説明図である。尚、実施例3のWebアプリ提供システム1Bと同一の構成には同一符号を付すことで、その重複する構成及び動作の説明については省略する。図14に示す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アプリをキャッシュから消去する。
実施例4では、通信端末4のユーザが会議室に入室した場合、PUSHサーバ2は、提供タイミングと判断し、プレゼン資料閲覧用のWebアプリの格納先アドレス及びコマンドを通信端末4に提供する。そして、会議室内の通信端末4は、格納先アドレスに基づき、プレゼン資料閲覧のWebアプリに関わるリソースを取得してキャッシュし、そのコマンドに基づき、プレゼン資料閲覧用のWebアプリを実行する。
また、実施例4では、通信端末4のユーザが会議室から退室した場合、PUSHサーバ2は、提供タイミングと判断し、プレゼン資料閲覧用のWebアプリの格納先アドレス及びコマンドを通信端末4に提供する。そして、会議室外の通信端末4は、格納先アドレスに基づき、プレゼン資料閲覧のWebアプリに関わるリソースを特定し、コマンドに基づき、プレゼン資料閲覧用のWebアプリをキャッシュから消去する。その結果、通信端末4のユーザは、会議室退室後に資料閲覧のWebアプリが閲覧できなくなるため、プレゼン資料の機密性を確保できる。
図15は、実施例5のWebアプリ提供システム内部の一例を示す機能ブロック図である。尚、図1に示すWebアプリ提供システム1と同一の構成には同一符号を付すことで、その重複する構成及び動作の説明については省略する。図15に示すWebアプリ提供システム1Dと図1に示すWebアプリ提供システム1とが異なるところは、次の点にある。すなわち、ユーザに対する指定Webアプリの送信依頼を検出すると、当該ユーザが所有する複数の通信端末4の内、ユーザが現在使用している可能性の高い特定の通信端末4に指定のWebアプリを提供する点である。
図15に示すPUSHサーバ2は、アプリポータルサーバ11、更新監視部12、アドレス管理部13、タイミング監視部14及びPUSH送信部15の他に、イベント受信部16を有する。イベント受信部16は、通信端末4からイベント情報を受信する。尚、イベント情報は、例えば、ユーザIDと、格納先アドレスと、イベント内容と、コマンドとを有する。尚、ユーザIDは、提供対象のWebアプリを提供するユーザのIDである。格納先アドレスは、提供対象のWebアプリに関わるリソースの格納先である。イベント内容は、Webアプリの送信(提供)依頼に応じたイベントである。コマンドは、提供対象のWebアプリを実行する実行内容である。
また、アドレス管理部13は、アドレス管理テーブル151及びユーザ管理テーブル152を管理し、アドレス管理テーブル151及びユーザ管理テーブル152のテーブル内容を動的に更新登録する。また、アドレス管理部13は、アドレス管理テーブル151及びユーザ管理テーブル152のテーブル内容を参照して各種判定動作を実行するものである。図16は、アドレス管理テーブル151のテーブル内容の一例を示す説明図である。図16に示すアドレス管理テーブル151は、ユーザID151A、端末ID151B、アプリID151C、格納先アドレス151D及び提供タイミング151Eの他に、コマンド151Gを対応付けて管理している。コマンド151Gは、格納先アドレス151Dで特定するWebアプリの実行内容である。
図17は、ユーザ管理テーブル152のテーブル内容の一例を示す説明図である。図17に示すユーザ管理テーブル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のGPS(Global Positioning System)機能や通信モジュールで得られた通信端末4の位置座標や場所名等の位置情報である。通知不可時間帯152Gは、ユーザ設定によるWebアプリの通知不可の時間帯である。尚、図中の「D={0−9,21−24}、W={ST,SU}」の意味は、「毎日0時〜9時、21時〜24時は通信不可、かつ、土曜日及び日曜日は終日通信不可」という意味である。タグID152Hは、通信端末4内蔵のRFIDタグを識別するIDである。
次に実施例5のWebアプリ提供システム1Dの動作について説明する。図18は、ユーザ指定のアドレス提供処理に関わるPUSHサーバ2の処理動作の一例を示すフローチャートである。図18に示すアドレス提供処理は、ユーザに対するWebアプリの送信依頼を検出すると、ユーザ所有の複数の通信端末4の内、ユーザが現在使用中の可能性が高い通信端末4にWebアプリのリソースに関わる格納先アドレス及びコマンドを提供する処理である。
図18においてPUSHサーバ2のアドレス管理部13は、特定ユーザに対するWebアプリの送信依頼を受信した場合、特定ユーザの管理リストをユーザ管理テーブル152から取得する(ステップS81)。アドレス管理部13は、特定ユーザの管理リストを取得すると、管理リスト内の端末種別152Bと、Webアプリの属性情報テーブルとに基づき、指定のWebアプリが端末種別限定のアプリであるか否かを判定する(ステップS82)。尚、端末種別限定のアプリとは、特定の端末種別の通信端末4でしか実行できないWebアプリである。
アドレス管理部13は、指定のWebアプリが端末種別限定のアプリである場合(ステップS82肯定)、管理リスト内の接続状態152Cを参照して、接続状態がオン中の該当の通信端末4があるか否かを判定する(ステップS83)。アドレス管理部13は、接続状態がオン中の該当の通信端末4がある場合(ステップS83肯定)、指定Webアプリを実行可能な通信端末4であると判断する。更に、アドレス管理部13は、管理リストの位置情報152Fと、Webアプリの属性情報テーブルとに基づき、指定のWebアプリが場所限定のアプリであるか否かを判定する(ステップS84)。尚、場所限定のアプリとは、特定の場所でしか実行を許可していないWebアプリである。アドレス管理部13は、指定のWebアプリが場所限定のアプリである場合(ステップS84肯定)、管理リスト内の接続状態152Cを参照して、接続状態がオン中の該当の通信端末4があるか否かを判定する(ステップS85)。
更に、アドレス管理部13は、接続状態がオン中の該当の通信端末4がある場合(ステップS85肯定)、指定Webアプリが実行可能な場所にある通信端末4であると判断する。更に、アドレス管理部13は、指定のWebアプリを提供する該当の通信端末4があるか否かを判定する(ステップS86)。尚、該当の通信端末4には、例えば、通知不可時間帯152Gの条件もクリアにした指定Webアプリが実行可能な通信端末4を含めても良い。アドレス管理部13は、該当の通信端末4がある場合(ステップS86肯定)、管理リスト内の最終使用時刻152Eを参照して、該当の通信端末4の端末IDの内、最新の最終使用時刻の端末IDがあるか否かを判定する(ステップS87)。
アドレス管理部13は、最新の最終使用時刻の端末IDがない場合(ステップS87否定)、管理リスト内の最終通知時刻152Dを参照して、該当の通信端末4の端末IDの内、最新の最終通知時刻の端末IDを取得する(ステップS88)。アドレス管理部13は、最新の最終通知時刻の端末IDを取得すると、該当の端末IDに対応した該当Webアプリに関わる格納先アドレス及びコマンドをアドレス管理テーブル151から取得する(ステップS89)。
PUSH送信部15は、該当の端末IDに対応した該当Webアプリに関わる格納先アドレス及びコマンドを取得すると、格納先アドレス及びコマンドを該当の端末IDに対応した通信端末4に送信する(ステップS90)。PUSH送信部15は、ステップS90に対する格納先アドレス及びコマンドの送信が成功したか否かを判定する(ステップS91)。PUSH送信部15は、格納先アドレス及びコマンドの送信が成功した場合(ステップS91肯定)、図18に示す処理動作を終了する。
アドレス管理部13は、格納先アドレス及びコマンドの送信が成功しなかった場合(ステップS91否定)、該当の通信端末4の内、2番目に新しい次位の最終使用時刻又は最終通知時刻の端末IDを取得する(ステップS92)。更に、アドレス管理部13は、端末IDに対応した格納先アドレス及びコマンドを取得すべく、ステップS89に移行する。
また、アドレス管理部13は、最新の最終使用時刻の端末IDがある場合(ステップS87肯定)、当該端末IDをアドレス管理テーブル151から取得する(ステップS93)。更に、アドレス管理部13は、当該端末IDに対応した格納先アドレス及びコマンドを取得すべく、ステップS89に移行する。
また、アドレス管理部13は、該当の通信端末4がない場合(ステップS86否定)、該当Webアプリに関わる格納先アドレス及びコマンドの送信を保留し(ステップS94)、図18に示す処理動作を終了する。尚、保留の場合、PUSH送信部15は、該当の通信端末4が接続状態になった場合に、当該通信端末4に対してWebアプリに関わる格納先アドレス及びコマンドを再送するものである。また、アドレス管理部13は、指定のWebアプリが端末種別限定のアプリでない場合(ステップS82否定)、場所限定のアプリであるか否かを判定すべく、ステップS84に移行する。
また、アドレス管理部13は、接続状態がオン中の該当の通信端末4がない場合(ステップS83否定、ステップS85否定)、該当Webアプリに関わる格納先アドレス及びコマンドの送信を保留し(ステップS95)、図18に示す処理動作を終了する。尚、保留の場合、PUSH送信部15は、該当の通信端末4が接続状態になった場合に、当該通信端末4に対してWebアプリに関わる格納先アドレス及びコマンドを再送するものである。
図18に示す処理では、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から取得して、コマンドに基づき、取得されたWebアプリを実行する。
実施例5では、PUSHサーバ2がユーザに対する指定Webアプリの送信依頼を受信した場合、指定ユーザ所有の複数の通信端末4の内、指定Webアプリの端末種別限定や場所限定に適用した、現在使用している可能性の高い通信端末4の端末IDを取得する。更に、PUSHサーバ2は、取得された端末IDの通信端末4に対して指定のWebアプリの格納先アドレス及びコマンドを送信する。その結果、PUSHサーバ2は、指定ユーザ所有の複数の通信端末4の内、当該ユーザが現在使用している可能性の高い通信端末4に対して指定のWebアプリに関わる格納先アドレス及びコマンドを通知できる。
例えば、上司が部下の出張申請を承認する場合、通常、上司は、自分の会社のPC等の通信端末4を使用して出張承認用のWebアプリで出張承認することになる。しかしながら、上司が外出先の場合、会社のPCを持参していないため、出張承認ができない。そこで、部下は、上司を指定した出張承認用Webアプリの送信依頼をPUSHサーバ2に送信する。PUSHサーバ2は、送信依頼を受信した場合、上司所有の複数の通信端末4の内、現在使用している可能性の高い通信端末4、すなわち外出先に持参している通信端末4の端末IDを取得する。そして、PUSHサーバ2は、取得された端末IDの通信端末4に対して出張承認用Webアプリの格納先アドレス及びコマンドを送信する。そして、通信端末4は、格納先アドレスに基づき、出張承認用WebアプリのリソースをWebサーバ3から取得し、コマンドに基づき、取得された出張承認用Webアプリを実行する。その結果、上司は、外出先に持参した通信端末4の出張承認用Webアプリを使用して出張承認ができる。
尚、上記実施例5では、端末種別限定アプリ、場所限定種別アプリ、接続状態、最終通知時刻、最終使用時刻、通知不可時間帯の全ての条件をクリアした通信端末4に指定Webアプリの格納先アドレス及びコマンドを送信した。しかしながら、PUSH送信部15は、これら条件の一部をクリアした通信端末4でも、指定Webアプリの格納先アドレス及びコマンドを送信するようにしても良く、その条件は、適宜選択変更可能である。
また、上記実施例5では、PUSHサーバ2がユーザに対する指定Webアプリの送信依頼を受信した場合、指定ユーザ所有の複数の通信端末4の内、現在使用している可能性の高い通信端末4に格納先アドレス及びコマンドを送信した。しかしながら、PUSHサーバ2は、現在使用している可能性の高い通信端末4を1台に限定するものではなく、複数台としても良い。また、PUSHサーバ2は、現在使用している可能性の高い通信端末4に格納先アドレス及びコマンドを送信したが、ユーザ所有の全ての通信端末4に格納先アドレス及びコマンドを送信しても良い。
また、図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
更に、各装置で行われる各種処理機能は、CPU(Central Processing Unit)(又はMPU(Micro Processing Unit)、MCU(Micro Controller Unit)等のマイクロ・コンピュータ)上で、その全部又は任意の一部を実行するようにしても良い。また、各種処理機能は、CPU(又はMPU、MCU等のマイクロ・コンピュータ)で解析実行するプログラム上、又はワイヤードロジックによるハードウェア上で、その全部又は任意の一部を実行するようにしても良いことは言うまでもない。
ところで、本実施例で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図19を用いて、上記の実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図19は、情報処理プログラムを実行するコンピュータを示す説明図である。
図19に示すように、情報処理プログラムとしてのコンピュータ100では、HDD(Hard Disk Drive)110、RAM(Random Access Memory)120、ROM(Read Only Memory)130及びCPU140がバス150を介して接続される。
そして、ROM130若しくはHDD110には、上記の実施例と同様の機能を発揮する情報処理プログラムが予め記憶されている。尚、ROM130及びHDD110ではなく、図示せぬドライブでコンピュータ読取可能な記録媒体に情報処理プログラムが記録されていても良い。また、記録媒体としては、例えば、CD−ROM、DVDディスク、USBメモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリ等でも良い。情報処理プログラムとしては、図19に示すように、検出プログラム131及び提供プログラム132である。尚、プログラム131及び132については、図1に示したPUSHサーバ2の各構成要素と同様、適宜統合又は分散してもよい。
そして、CPU140が、これらのプログラム131及び132をROM130から読み出して実行する。そして、図19に示すように、各プログラム131及び132は、検出プロセス141及び提供プロセス142として機能するようになる。
RAM120は、通信端末4を識別する端末IDと、当該通信端末4に提供するWebアプリのリソースの格納先アドレスと、当該通信端末4に提供するWebアプリの提供タイミングとを対応付けて管理する。CPU140は、RAM120内の提供タイミングを検出する。CPU140は、提供タイミングを検出した場合、提供タイミングに関わる通信端末4に対して、当該提供タイミングに関わるWebアプリのリソースを当該通信端末4に提供すべく、図示せぬ通信部を使用して、当該リソースの格納先アドレスを提供する。その結果、通信端末4のユーザは、アプリ取得に関わる要求操作を実行しなくても、必要な時に必要なWebアプリを提供タイミングに応じて自動的に取得できる。