(57)【要約】【課題】複数の端末装置で実行されるアプリケーションプログラムの管理を容易に行うことができる情報処理システム等を提供する。【解決手段】各々アプリケーションプログラムを実行する複数の端末装置と、アプリケーションプログラムと当該アプリケーションを実行すべき端末装置とを対応付ける情報を保持する対応情報保持手段と、当該対応情報保持手段に保持されている情報に基づいてアプリケーションプログラムに対応する前記端末装置に通知を送信する通知手段と、前記端末装置からの要求に応じてアプリケーションプログラムを提供する提供手段とを有する管理装置とを備え、前記端末装置は、前記通知に応じて前記提供手段に前記アプリケーションプログラムを要求する。【選択図】図１
2017224058.tif 000002
【特許請求の範囲】
【請求項１】
各々アプリケーションプログラムを実行する複数の端末装置と、
アプリケーションプログラムと当該アプリケーションを実行すべき端末装置とを対応付ける情報を保持する対応情報保持手段と、当該対応情報保持手段に保持されている情報に基づいてアプリケーションプログラムに対応する前記端末装置に通知を送信する通知手段と、前記端末装置からの要求に応じてアプリケーションプログラムを提供する提供手段とを有する管理装置とを備え、
前記端末装置は、前記通知に応じて前記提供手段に前記アプリケーションプログラムを要求する
ことを特徴とする情報処理システム。
【請求項２】
前記通知は、前記アプリケーションの実行・停止・更新・切り戻しを指示する指示情報とアプリケーションを特定する特定情報とを含み、
前記端末装置は、前記通知中の指示情報に応じて前記アプリケーションの管理を行う管理手段を備えることを特徴とする請求項１記載の情報処理システム。
【請求項３】
前記アプリケーションプログラムは、プログラム本体と実行環境を含むことを特徴とする請求項１又は２に記載の情報処理システム。
【請求項４】
アプリケーションプログラムと当該アプリケーションを実行すべき端末装置とを対応付ける情報を保持する対応情報保持手段と、
当該対応情報保持手段に保持されている情報に基づいてアプリケーションプログラムに対応する前記端末装置に通知を送信する通知手段と、
前記通知を受信した端装置からの要求に応じてアプリケーションプログラムを提供する提供手段と
を備えることを特徴とする管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の端末装置で実行されるアプリケーションプログラムを一括管理する情報処理システム及び管理装置に関する。
【背景技術】
【０００２】
通信回線を経由して遠隔地にある情報処理装置のプログラムの更新を行う技術が知られている（例えば特許文献１及び特許文献２）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１３−３９３５号公報
【特許文献２】特開２０１１−１６４８４５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上述の技術では、ネットワークで接続された情報処理装置のプログラムを一時に更新したい場合に、情報処理装置の数が多くなると管理の負担が増加してしまう。
【０００５】
このため、本発明は、複数の端末装置で実行されるアプリケーションプログラムの管理を容易に行うことができる情報処理システム及び管理装置を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上述の課題を解決するために、本発明の情報処理システムは、各々アプリケーションプログラムを実行する複数の端末装置と、アプリケーションプログラムと当該アプリケーションを実行すべき端末装置とを対応付ける情報を保持する対応情報保持手段と、当該対応情報保持手段に保持されている情報に基づいてアプリケーションプログラムに対応する前記端末装置に通知を送信する通知手段と、前記端末装置からの要求に応じてアプリケーションプログラムを提供する提供手段とを有する管理装置とを備え、前記端末装置は、前記通知に応じて前記提供手段に前記アプリケーションプログラムを要求する。
【発明の効果】
【０００７】
本発明に係る情報処理システムでは、
管理装置の通知手段が、対応情報保持手段に保持されている情報に基づいてアプリケーションプログラムに対応する端末装置に通知を送信し、端末装置が、通知手段からの通知に応じて提供手段にアプリケーションプログラムを要求し、管理装置の提供手段が、端末装置からの要求に応じてアプリケーションプログラムを提供することにより、複数の端末装置で実行されるプログラムの管理を容易に行うことができる。
【図面の簡単な説明】
【０００８】
【図１】本発明を適用した実施形態に係るデータ収集システムの構成を示す図である。
【図２】端末装置１０で実行されるプログラムの構成を示す図である。
【図３】リポジトリ（管理データ）の例を示す図である。
【図４】バージョン管理データの例を示す図である。
【図５】バージョン管理処理を示す概念図である。
【図６】ユーザデータの例を示す図である。
【図７】メッセージの配信管理データの例を示す図である。
【図８】Ａｐｐの実行／停止の処理を示すフローチャートである。
【図９】通信の概要を示すタイミング図である。
【図１０】端末装置１０側のＡｐｐの状態を示す概念図である。
【図１１】Ａｐｐの更新／切り戻しのフローチャートである。
【図１２】Ａｐｐの生成／削除のフローチャートである。
【発明を実施するための形態】
【０００９】
以下、本発明を、例えば複数の端末装置で測定したデータを収集するデータ収集システムに適用した実施形態について説明する。
（全体構成）
このデータ収集システムは、例えば図１に示すように、異なる場所に設置され、センサからのデータを測定する複数の端末装置１０と、端末装置１０で実行するアプリケーションプログラム（以下、Ａｐｐという。）の管理を行う管理サーバ（管理装置）２０と、管理サーバ２０に指示を入力する管理端末３０と、端末装置１０で測定したデータを収集する情報収集サーバ４０とを備えている。端末装置１０、管理サーバ２０、管理端末３０、情報収集サーバ４０は、ネットワーク１を介して接続ざれている。
【００１０】
各端末装置１０は、例えばＣＰＵ、ＲＯＭ、ＲＡＭ等のメモリ、通信インタフェース等を備えるシングルボードコンピュータ（ＳＢＣ）から構成されている。各端末装置１０は、メモリに格納された制御プログラムを実行することにより、例えば管理サーバ２０からの通知（コマンド）を受信する通知受信部１１と、管理サーバ２０からＡｐｐを取得する取得部１２と、取得したＡｐｐを記憶するＡｐｐ記憶部１３等として機能する。また、端末装置１０は、Ａｐｐの実行により、例えばセンサ１４が取得したデータを情報収集サーバ４０に送信するデータ送信部１５等として機能する。また、各端末装置１０には各々固有のデバイスＩＤ（ＤＩＤ）が割り当てられている。
【００１１】
センサ１４として、例えば端末装置１０の周囲の温度を測定する温度センサ、明るさを測定する照度センサ、音を測定する音センサ、画像を測定するイメージセンサ等を用いることができるが、これらに限定されるものではない。
【００１２】
管理サーバ２０は、例えばＣＰＵ、ＲＯＭ、ＲＡＭ等のメモリ、ＨＤＤ、ＳＳＤ等のストレージ装置、通信インタフェース等を備えるサーバ装置から構成されている。管理サーバ２０は、管理サーバ２０全体の動作を制御する制御部２１と、Ａｐｐの動作を検証する動作検証部２２と、動作検証されたＡｐｐを格納するＡｐｐ格納部２３と、端末装置１０にＡｐｐの実行・停止・更新・切り戻し等の通知を送信する通知送信部２４と、端末装置１０からの要求に応じてＡｐｐを送信するＡｐｐ送信部２５とを備えている。制御部２１は、管理端末３０を介して提供されるユーザの指示・プログラムのソースコード等に基づいて、Ａｐｐの作成・バージョン等の管理を行う。なお、制御部２１は、フロントエンドとしてＨＴＴＰサーバを備え、管理端末３０を介してユーザからの指示を入力する。
【００１３】
なお、管理サーバ２０の各構成を単一の装置で実現する必要はなく、通知送信部２４を、例えば外部のＭＱＴＴサーバ等によって実現してもよい。通知送信部２４をＭＱＴＴサーバにより実現した場合、端末装置１０がローカルネットワークに接続されており、グローバルＩＰアドレスが割り当てられていない場合でも端末装置１０と通知送信部２４の間にコネクションが接続されていれば、通知送信部２４から端末装置１０に対する通知が可能になる。また、制御部２１によるＡｐｐの管理とＡｐｐ送信部２５によるＡｐｐの提供等の機能を、例えば外部のＧｉｔサーバ等によって実現してもよい。Ｇｉｔサーバを用いることにより、Ａｐｐのバージョン管理が容易になる。
【００１４】
管理端末３０は、例えばＣＰＵ、ＲＯＭ、ＲＡＭ等のメモリ、ＨＤＤ、ＳＳＤ等のストレージ装置、通信インタフェース等を備えるパーソナルコンピュータ等で構成されている。なお、この管理端末３０は、少なくとも、Ｗｅｂブラウザ等を介して管理サーバ２０の制御部２１にユーザからの指示を送信する機能があればよい。
【００１５】
情報収集サーバ４０は、例えばＣＰＵ、ＲＯＭ、ＲＡＭ等のメモリ、ＨＤＤ、ＳＳＤ等のストレージ装置、通信インタフェース等を備えるサーバ装置から構成されている。情報収集サーバ４０は、端末装置１０からのデータを受信するデータ受信部４１と、データ受信部４１が受信したデータを格納するハードディスクドライブ（ＨＤＤ）等のストレージ装置からなるデータ格納部４２とを備えている。
【００１６】
端末装置１０で実行されるプログラムは、例えば図２に示すように、端末装置１０のハードウェア（Ｈ／Ｗ）全体の制御を行うＯＳと、Ａｐｐの管理を行うＡｐｐ管理部１６と、このＡｐｐ管理部１６による管理下で実行されるＡｐｐ（Ａｐｐ．Ａ、Ａｐｐ．Ｂ、Ａｐｐ．Ｃ）とで階層的に構成されている。上述の通知受信部１１、Ａｐｐ取得部１２はこのＡｐｐ管理部１６の機能として実装されている。また、このデータ収集システムでは、各Ａｐｐは、プログラム本体Ｃ１と、プログラム本体Ｃ１を実行する言語処理系及びＨ／Ｗのドライバ等の実行環境Ｃ２とを有するコンテナＣから構成されている。
【００１７】
また、端末装置１０では、ＯＳでの管理下、プログラムを、他のユーザが実行中のプロセス（実行中のプログラムの単位）の閲覧・実行制御等が可能な特権ユーザモードと、他のユーザが実行中のプロセスを閲覧・実行制御等が不可能な一般ユーザモードで実行させることができるようになっている。Ａｐｐ管理部１６は、端末装置１０から取得したＡｐｐを一般ユーザモードで実行させるようになっている。これにより、他のＡｐｐあるいは端末装置１０の構成等についての閲覧・干渉等を防止することができ、セキュリティの向上に寄与することができる。
【００１８】
また、Ａｐｐ管理部１６がコネクションを接続するアクセス先は、予め決められた管理サーバ２０の通知送信部２４のアドレスのみとなっている。このため、通知受信部１１が受信する通知は通知送信部２４からの通知のみになっている。これにより、他のアドレスから通知が届いても通知受信部１１は受信しない。これにより、セキュリティの向上に寄与することができる。
【００１９】
図３は、管理サーバ２０側で、Ａｐｐを管理するための管理データ（リポジトリ）２１１、２１２の例を示している。各々のＡｐｐ（プロジェクト）には、固有のプロジェクトＩＤ（ＰＩＤ）が割り当てられている。リポジトリ２１１、２１２には、このＰＩＤと、Ａｐｐのプログラム本体のソースコードのファイル名と、プログラム本体を実行する際の実行環境が対応付けられて記録されている。例えばリポジトリ２１１には、ＰＩＤ“ｘｘｘｘｘｘ”に対応付けられて、プログラム本体のファイル名“file11.js”及び“file12.js”と、実行環境を示す処理系を示す名称“ＪＶＭ”及びドライバのファイル名“sensor.drv”とが対応付けられて記録されている。
【００２０】
また、リポジトリには、バージョンを示す文字２１１ａと日付を示す文字２１１ｂが含まれている。管理サーバ装置２０の制御部２１は、このようなリポジトリを用いて、プログラム本体、実行環境のバージョン管理を行っている。具体的には、制御部２１は、例えば図４に示す管理データを用いて、ＰＩＤ毎に複数のバージョン（例えば、少なくとも、最新のバージョンと１つ前のバージョン）のリポジトリを管理する。制御部２１は、この管理データに応じて、例えば図５に示すように、各バージョン毎のプログラム本体、実行環境の対応付けを行う。これにより、複数のバージョンのＡｐｐを提供可能になり、例えば、不具合が生じた際に１つ前のバージョンに戻す、といった処理が可能になる。
なお、バージョン毎にＡｐｐ格納部２３の異なる領域にファイルを格納するようにしておき、同一の内容のファイルについてはエイリアスとしておくことにより、同じファイル名のファイルについてのバージョン管理も可能になる。なお、Ｇｉｔサーバを用いたバージョン管理を行う場合には、これらの処理はＧｉｔサーバによって行う。この場合、ＰＩＤは個々のＡｐｐを識別する「タグ」に相当する。
【００２１】
図６は、管理サーバ２０の制御部２１がＡｐｐの管理に用いるユーザデータの例を示している。このユーザデータには、個々のユーザ毎に固有のユーザＩＤ（ＵＩＤ）と、上述のＡｐｐのＰＩＤ、当該Ａｐｐを実行する端末装置１０のＤＩＤとが対応付けられて記録されている。管理サーバ２０の制御部２１は、このようなユーザデータを用いて、ユーザ毎のＡｐｐの管理を行っている。また、制御部２１は、ユーザデータから各ＰＩＤに対応するＡｐｐを実行すべき端末装置１０のＤＩＤを通知送信部２４に供給する。
【００２２】
通知送信部２４は、制御部２１から供給されたＰＩＤとＤＩＤを、例えば図７に示すように対応付けて保持しておき、メッセージを送信する端末装置１０を選択する。
端末装置１０に送信されるメッセージには、例えばＡｐｐの実行を指示する実行（ｓｔａｒｔ）、Ａｐｐの停止を指示する停止（ｓｔｏｐ）、Ａｐｐの更新を指示する更新（ｕｐｄａｔｅ）、Ａｐｐを１つ前のバージョンに戻す指示である切り戻し（ｆａｌｌｂａｃｋ）がある。
また、メッセージには、メッセージの種類を示す文字（ｓｔａｒｔ／ｓｔｏｐ／ｕｐｄａｔｅ／ｆａｌｌｂａｃｋ）と対象となるＡｐｐを示すＰＩＤが含まれる。
具体的には、開始のメッセージであれば、［ｓｔａｒｔ  ａｐｐ｜Ａ｜］  （｜Ａ｜は上述のＰＩＤ）のようになる。
【００２３】
（動作）
以上のように構成されたデータ収集システムでは、端末装置１０は、起動すると、まず、管理サーバ２０の通知送信部２４との間にＴＣＰ／ＩＰのコネクションを接続し、管理サーバ２０の通知送信部２４からの通知［メッセージ］を待機する。メッセージを受信すると、端末装置１０は、後述のように、メッセージの種類に応じた処理を実行する。
なお、コネクションを接続する際に、端末装置１０から管理サーバ２０の通知送信部２４に当該端末装置１０のＤＩＤが通知される。また、コネクションを接続する際に、ＳＳＬで暗号化した通信を行い、ユーザ名、パスワードでログインした後コネクションを設定するようにしてもよい。これによりセキュリティを向上させることができる。
【００２４】
管理サーバ２０側では、管理端末３０を介したユーザからの指示に応じて、端末装置１０に送信するメッセージを生成する。具体的には、制御部２１はユーザからの指示に応じて、ＰＩＤとメッセージの種類（ｓｔａｒｔ／ｓｔｏｐ／ｕｐｄａｔｅ／ｆａｌｌｂａｃｋ）を通知送信部２４に指示する。通知送信部２４は、上述の図７に示す管理データに応じて、制御部２１から指示されたＰＩＤに対応するＤＩＤを取得し、ＤＩＤに対応する端末装置１０に対してメッセージを配信する。
【００２５】
以下、メッセージの種類毎に具体的な動作を説明する。
［実行／停止］
図８は、端末装置１０にＡｐｐを実行あるいは停止させる処理を示すフローチャートである。
まず、管理サーバ２０の制御部２１は、例えば管理端末３０を介して入力されるユーザからの指示を取得する（Ｓ１）。制御部２１は、ユーザからの指示が「Ａｐｐの実行」であるか否かを確認し（Ｓ２）、「Ａｐｐの実行」であれば、動作検証部２２に、仮想環境（端末装置１０のエミュレーション環境）でＡｐｐをビルドさせる（Ｓ４）。さらに、制御部２１は、動作検証部２２に、Ａｐｐを構成するプログラム本体、実行環境等の依存関係を検証させる（Ｓ５）。検証の結果、問題がなければ、制御部２１は、通知送信部２４に、当該ＡｐｐのＰＩＤに対応する端末装置１０に対して「Ａｐｐの実行」を指示する通知を送信させる（Ｓ６）。検証の結果、問題がある場合には、制御部２１は、Ｓ１に戻り、ユーザからの指示を待機する。
【００２６】
Ｓ２において、ユーザからの指示が「Ａｐｐの実行」ではない場合、制御部２１は、ユーザからの指示が「Ａｐｐの停止」であるか否かを確認し（Ｓ３）、「Ａｐｐの停止」であれば、当該ＡｐｐのＰＩＤに対応する端末装置１０に対して「Ａｐｐの停止」を指示する通知を送信させる（Ｓ６）。ユーザからの指示が「Ａｐｐの停止」ではない場合、制御部２１は、Ｓ１に戻り、ユーザからの指示を待機する。
【００２７】
端末装置１０の通知受信部１１は、通知送信部２４からの通知を待機しており（Ｓ７）、通知送信部２４からの通知を受信すると、通知の内容が「Ａｐｐの実行」であるか否かを確認する（Ｓ８）。「Ａｐｐの実行」であれば、Ａｐｐ取得部１２は、当該通知で指定されたＰＩＤに対応するＡｐｐをＡｐｐ送信部２５から取得し（Ｓ９）、Ａｐｐ管理部１６は、取得したＡｐｐを実行させる（Ｓ１０）。Ｓ８において、通知の内容が「Ａｐｐの実行」でない場合、通知受信部１１は、通知の内容が「Ａｐｐの停止」であるか否かを確認する（Ｓ１１）。「Ａｐｐの停止」であれば、Ａｐｐ管理部１６は、当該通知で指定されたＰＩＤに対応するＡｐｐの実行を停止させる（Ｓ１２）。さらに、Ａｐｐ管理部１６は、Ａｐｐが停止したか否かを確認し（Ｓ１３）、停止を確認した上で処理を終了する。
【００２８】
図９は、上述の実行／停止処理における通信の概要を示すタイミング図である。
端末装置１０は、予め管理サーバ２０の通知送信部２４との間にコネクションを接続しておく（Ｓ２０）。
ユーザが管理端末３０を操作して所定のＡｐｐ（Ａｐｐ．Ａ）の実行を指示すると（Ｓ２１）、制御部２１は、上述のように、動作検証部２２に当該Ａｐｐのビルド（Ｓ２２）と検証（Ｓ２３）を指示した後、通知送信部２４に当該Ａｐｐの実行を指示する通知を、当該ＡｐｐのＰＩＤに対応付けられた全ての端末装置１０に対して送信させる（Ｓ２４）。
【００２９】
この通知を受信した端末装置１０は、各々当該ＡｐｐをＡｐｐ送信部２５に要求し（Ｓ２５）、Ａｐｐが提供されると（Ｓ２６）、当該Ａｐｐの実行を開始し（Ｓ２７）、例えば所定時間毎にセンサ１４で測定したデータを情報収集サーバ４０宛に送信する（Ｓ２８、Ｓ２９、Ｓ３０）。なお、Ｓ２５において、Ａｐｐ取得部１２がＡｐｐ送信部２５にＡｐｐを要求する際に、当該端末装置１０のＤＩＤを通知するようにしてもよい。Ａｐｐ送信部２５は、上述の図６に示すユーザデータを参照し、端末装置１０から通知されたＤＩＤが、要求されたＡｐｐのＰＩＤに対応するＤＩＤである場合には要求されたＡｐｐを送信し、対応するＤＩＤでない場合には当該Ａｐｐの送信を行わないようにしてもよい。
【００３０】
ユーザが管理端末３０を操作して所定のＡｐｐ（Ａｐｐ．Ａ）の停止を指示すると（Ｓ３１）、制御部２１は、上述のように、通知送信部２４に当該Ａｐｐの停止を指示する通知を、当該ＡｐｐのＰＩＤに対応付けられた全ての端末装置１０に対して送信させる（Ｓ３２）。この通知を受信した端末装置１０は、当該Ａｐｐを停止させる（Ｓ２７）。
これにより、このデータ収集システムでは、上述のように、複数の端末装置１０におけるＡｐｐの実行／停止を一括して制御することができる。
【００３１】
なお、端末装置１０において実行させるＡｐｐは１つに限らず、複数のＡｐｐを実行させることもできる。この場合、Ａｐｐ毎に上述の「実行」を指示する通知を送信する。これにより、例えば図１０に示すように、複数のＡｐｐを端末装置１０において実行させることができる。また、上述のユーザデータにおいてＰＩＤに対応する端末装置１０のＤＩＤを定義しておけば、Ａｐｐ毎に実行させる端末装置１０を任意に選択することができる。
【００３２】
［更新／きり戻し］
図１１は、端末装置１０にＡｐｐを更新あるいは切り戻しさせる処理を示すフローチャートである。
まず、管理サーバ２０の制御部２１は、例えば管理端末３０を介して入力されるユーザからの指示を取得する（Ｓ４１）。制御部２１は、ユーザからの指示が「Ａｐｐの更新」であるか否かを確認し（Ｓ４２）、「Ａｐｐの更新」であれば、動作検証部２２に、仮想環境（端末装置１０のエミュレーション環境）でＡｐｐをビルドさせる（Ｓ４４）。さらに、制御部２１は、動作検証部２２に、Ａｐｐを構成するプログラム本体、実行環境等の依存関係を検証させる（Ｓ４５）。検証の結果、問題がなければ、制御部２１は、通知送信部２４に、当該ＡｐｐのＰＩＤに対応する端末装置１０に対して「Ａｐｐの更新」を指示する通知を送信させる（Ｓ４６）。検証の結果、問題がある場合には、制御部２１は、Ｓ４１に戻り、ユーザからの指示を待機する。
【００３３】
Ｓ４２において、ユーザからの指示が「Ａｐｐの更新」ではない場合、制御部２１は、ユーザからの指示が「Ａｐｐの切り戻し」であるか否かを確認し（Ｓ４３）、「Ａｐｐの切り戻し」であれば、当該ＡｐｐのＰＩＤに対応する端末装置１０に対して「Ａｐｐの切り戻し」を指示する通知を送信させる（Ｓ４６）。ユーザからの指示が「Ａｐｐの切り戻し」ではない場合、制御部２１は、Ｓ４１に戻り、ユーザからの指示を待機する。
【００３４】
端末装置１０の通知受信部１１は、通知送信部２４からの通知を待機しており（Ｓ４７）、通知送信部２４からの通知を受信すると、通知の内容が「Ａｐｐの更新」であるか否かを確認する（Ｓ４８）。「Ａｐｐの更新」であれば、Ａｐｐ管理部１６は、当該通知で指定されたＰＩＤに対応するＡｐｐを停止させる（Ｓ４９）。この後、Ａｐｐ取得部１２は、当該ＰＩＤに対応する新たなバージョンのＡｐｐをＡｐｐ送信部２５から取得する（Ｓ５０）。
【００３５】
なお、Ｓ５０において、管理サーバ２０から更新後のＡｐｐを取得する際に、Ａｐｐ取得部１２は、現在Ａｐｐ記憶部１３に格納されているＡｐｐと新たなバージョン（更新後）のＡｐｐを比較し、差分のみを取得する。
具体的には、Ａｐｐ取得部１２は、まず、Ａｐｐ送信部２５に、新たなバージョンのＡｐｐのリポジトリを要求する。さらに、Ａｐｐ取得部１２は、取得した新たなリポジトリと現在のリポジトリとを比較し、差分をＡｐｐ送信部２５に要求する。あるいは、Ａｐｐ取得部１２側で差分を検出せず、Ａｐｐ送信部２５に差分のみの送信を要求するコマンドを送信し、Ａｐｐ送信部２５側で新たなバージョンのリポジトリと比較して差分のみを送信するようにしてもよい。
【００３６】
Ｓ４８において、通知の内容が「Ａｐｐの更新」でない場合、通知受信部１１は、通知の内容が「Ａｐｐの切り戻し」であるか否かを確認する（Ｓ５２）。「Ａｐｐの切り戻し」であれば、Ａｐｐ管理部１６は、当該通知で指定されたＰＩＤに対応するＡｐｐの実行を停止させる（Ｓ５３）。この後、Ａｐｐ取得部１２は、当該ＰＩＤに対応する１つ前のバージョンのＡｐｐをＡｐｐ送信部２５から取得する（Ｓ５４）。
【００３７】
Ｓ５４において、管理サーバ２０から更新後のＡｐｐを取得する際に、Ａｐｐ取得部１２は、現在Ａｐｐ記憶部１３に格納されているＡｐｐと１つ前のバージョン（切り戻し後）のＡｐｐを比較し、差分のみを取得する。
具体的には、Ａｐｐ取得部１２は、まず、Ａｐｐ送信部２５に、１つ前のバージョンのＡｐｐのリポジトリを要求する。さらに、Ａｐｐ取得部１２は、取得した１つ前のリポジトリと現在のリポジトリとを比較し、差分をＡｐｐ送信部２５に要求する。あるいは、Ａｐｐ取得部１２側で差分を検出せず、Ａｐｐ送信部２５に差分のみの送信を要求するコマンドを送信し、Ａｐｐ送信部２５側で１つ前のバージョンのリポジトリと比較して差分のみを送信するようにしてもよい。
【００３８】
上述のように、Ａｐｐの更新あるいは切り戻しが終了すると、Ａｐｐ管理部１６は、Ｓ５１において、Ａｐｐを実行させ、通知送信部２４からの通知を待機する。
【００３９】
［作成／削除］
図１２は、端末装置１０にＡｐｐを更新あるいは切り戻しさせる処理を示すフローチャートである。
まず、管理サーバ２０の制御部２１は、例えば管理端末３０を介して入力されるユーザからの指示を取得する（Ｓ６１）。制御部２１は、ユーザからの指示が「Ａｐｐの作成」であるか否かを確認し（Ｓ６２）、「Ａｐｐの作成」であれば、当該Ａｐｐのリポジトリを作成し（Ｓ６３）、Ａｐｐ送信部２５に通知する（Ｓ６６）。さらに、制御部２１は、上述のユーザデータに当該ＡｐｐのＰＩＤ、対応する端末装置１０のＤＩＤ等を登録して、ユーザデータを更新する（Ｓ６７）。
【００４０】
Ｓ６２において、ユーザからの指示が「Ａｐｐの作成」ではない場合、制御部２１は、ユーザからの指示が「Ａｐｐの削除」であるか否かを確認し（Ｓ６４）、「Ａｐｐの削除」であれば、当該Ａｐｐのリポジトリを削除し（Ｓ６５）、Ａｐｐ送信部２５に通知する（Ｓ６６）。さらに、制御部２１は、上述のユーザデータから当該ＡｐｐのＰＩＤ、対応する端末装置１０のＤＩＤ等を削除して、ユーザデータを更新する（Ｓ６７）。
【００４１】
（効果）
上述のように、このデータ収集システムでは、複数の端末装置で実行されるアプリケーションプログラム（Ａｐｐ）の管理を容易に行うことができる。
また、このデータ収集システムでは、アプリケーションプログラムの管理を容易に行うことができるため、アプリケーションプログラムを適宜変更して、情報収集サーバ４０に送信するデータの取得間隔、取得精度等の動作の変更を容易に行うことができる。
【符号の説明】
【００４２】
１  ネットワーク、１０  端末装置、２０  管理サーバ、３０  管理端末、４０  情報収集サーバ 
【図１】
2017224058.tif 000003
【図２】
2017224058.tif 000004
【図３】
2017224058.tif 000005
【図４】
2017224058.tif 000006
【図５】
2017224058.tif 000007
【図６】
2017224058.tif 000008
【図７】
2017224058.tif 000009
【図８】
2017224058.tif 000010
【図９】
2017224058.tif 000011
【図１０】
2017224058.tif 000012
【図１１】
2017224058.tif 000013
【図１２】
2017224058.tif 000014