端末装置、設定報知システム、報知方法
【課題】端末のキッティングの状態を、モバイル端末の外見から知ることができるようにすることを目的とする。
【解決手段】端末装置は、あるアプリケーションをインストールする毎に、インストールの状態を示す状態情報と報知方法を示す確認情報とを対応付けて記憶し、端末装置自身の状態の報知を要求する指示を外部から取得すると、端末装置自身の状態を検出して、検出した端末装置自身の状態に応じて、前記確認情報に基づいて報知を行う。
【解決手段】端末装置は、あるアプリケーションをインストールする毎に、インストールの状態を示す状態情報と報知方法を示す確認情報とを対応付けて記憶し、端末装置自身の状態の報知を要求する指示を外部から取得すると、端末装置自身の状態を検出して、検出した端末装置自身の状態に応じて、前記確認情報に基づいて報知を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、装置に設定されている内容を、装置の外見によって判断することを容易にする技術に関する。
【背景技術】
【０００２】
ノートパソコン、スマートフォン又はＰＤＡ（Personal Digital Assistants）等のモバイル端末は、その使用目的に応じて、アプリケーションを事前にインストール又は各種設定を行っておく必要があるものがある。
【０００３】
モバイル端末を実用段階にまで持っていく為のこのような作業、いわゆる、キッティング作業は、基本的には、１台ずつ行う。例えば、モバイル端末とキッティング作業用の端末をＵＳＢ（Universal Serial Bus）ケーブルで1台ずつ接続して、インストール作業などを行うことが一般的に行われている。
【０００４】
また、こういったキッティング作業は、例えば、顧客に納品するときに、工場出荷時の状態で各端末が同じ状態のものを扱う場合は大きな問題にならないが、引き続き、保守作業を行っていく中で、さまざまな端末を扱っていく途中で、端末によってインストールするアプリや設定が異なる状況が発生する。そうなると、キッティング作業を開始するときに、作業者はこれからキッティング作業を行う端末がどれかを正しく確認してから、作業を行わないと、端末へのアプリインストールや、設定変更の結果が想定した結果を整合しない結果となるおそれがある。
【０００５】
従って、キッティング作業を行う必要があるモバイル端末の台数が数台である場合はよいが、数十台〜数百台のモバイル端末にキッティングを行う必要がある場合は、正しくキッティングが行われたか否かを確かめるのには手間がかかる。
【０００６】
なぜなら、例えば、あるアプリケーションのインストールが成功したか失敗したかを確かめるためには、確認のための操作を一台一台に行う必要があるからである。
【０００７】
そこで、インストールを実行する際に、インストールの各ステップが正常に実行されたか否かを、インストールが実行されている装置が備えるインストールフィードバックライトを作動させることでインストールの状態を知らせる技術が提案されている（特許文献１参照）。
【０００８】
この技術によれば、キッティング作業者は、インストールを行ったモバイル端末のインストールフィードバックライトを見ることにより、インストールが成功したか失敗したかを知ることができる。すなわち、１台１台に確認の操作、例えば、所定のコマンドの入力を行うなどしてインストールが成功しているかを確認する必要が無くなる。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０００−９９４２３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、この技術では、あるアプリケーションのインストールが成功したのか失敗したのかはモバイル端末の外見から知ることはできるが、どのアプリケーションがインストールされたのか等はモバイル端末の外見からは知ることはできない。
【００１１】
数多くのモバイル端末にキッティング作業を行う場合は、モバイル端末によってインストールするアプリケーションが異なる場合も多い。また、キッティングするモバイル端末の数が多ければ、キッティング作業が複数日に及ぶことがあり、この場合、キッティング済みのモバイル端末と未だキッティングされていないモバイル端末とが混在することとなる。
【００１２】
このような場合、モバイル端末のキッティングの状態、例えば、インストールされているアプリケーション等を、モバイル端末の外見から知ることができれば、一台一台手作業で確かめることなくキッティング作業を迅速に行うことができるようになる。
【００１３】
そこで、本発明は、モバイル端末等の装置の様々なキッティングの状態を、モバイル端末の外見から知ることができるようにすることを目的とする。
【課題を解決するための手段】
【００１４】
本発明の１形態に係る設定報知システムの端末装置は、自装置を所定の状態にしようとする毎に、自装置の状態を示す状態情報と報知方法を示す確認情報とを対応付けて記憶する記憶手段と、自装置の状態の報知を要求する指示を、外部から取得する要求取得手段と、自装置の状態を検出する検出手段と、前記要求取得手段で前記指示を取得した場合に、前記検出手段で検出した自装置の状態に応じて、前記確認情報に基づいて報知を行う報知手段と、を有する。
【発明の効果】
【００１５】
上記構成の設定報知システムの端末装置は、装置自身の様々なキッティングの状態を、端末の外見によって知らせることができる。
【図面の簡単な説明】
【００１６】
【図１】実施形態１の状態報知システムの構成例を示す図である。
【図２】携帯端末がキッティングの状態を報知する例を示す図である。
【図３】携帯端末及びキッティング装置の機能的構成の例を示すブロック図である。
【図４】確認データ管理テーブルの構成及び内容の例を示す図である。
【図５】アプリ別管理テーブルの構成及び内容の例を示す図である。
【図６】確認データの構成及び内容の例を示す図である。
【図７】インストールログの構成及び内容の例を示す図である。
【図８】キッティング処理及びキッティング確認処理を示すフローチャートである。
【図９】実施形態２の状態報知システムの構成例を示す図である。
【図１０】管理サーバ、携帯端末及びキッティング装置の機能的構成の例を示すブロック図である。
【図１１】端末別管理テーブルの構成及び内容の例を示す図である。
【図１２】キッティング確認処理を示すフローチャートである。
【図１３】相違度判定処理を示すフローチャートである。
【発明を実施するための形態】
【００１７】
＜実施形態１＞
図１は、実施形態１の状態報知システム１００の構成例を示す図である。
【００１８】
状態報知システム１００は、キッティングの対象である携帯端末１０００Ａ、携帯端末１０００Ｂ、携帯端末１０００Ｃ、携帯端末１０００Ｄ及びキッティング装置２０００を有する。
【００１９】
携帯端末１０００Ａ〜Ｄとキッティング装置２０００とは、無線ＬＡＮ（Local Area Network）やＢｌｕｅｔｏｏｔｈ（登録商標、以下同様）などの無線通信により通信する。
【００２０】
図１では、説明の便宜上、キッティング対象の携帯端末１０００Ａ〜Ｄの４台を記載している。また、携帯端末１０００Ａ〜Ｄは、それぞれ同様の外観と機能とを有する。
【００２１】
以下、携帯端末１０００Ａ〜Ｄは、携帯端末１０００と総称するものとし、携帯端末１０００Ａは携帯端末Ａ、携帯端末１０００Ｂは携帯端末Ｂ、携帯端末１０００Ｃは携帯端末Ｃ、携帯端末１０００Ｄは携帯端末Ｄというものとする。
【００２２】
携帯端末１０００は、携帯電話機、スマートフォン、ＰＤＡ又はノートパソコン等の情報機器であり、パワーインジケータ等として使用されるＬＥＤ（Light Emitting Diode）ランプ１４００を備えている。拡大図１００１Ｂは消灯しているＬＥＤランプ１４００を示し、拡大図１００１Ａは、点灯しているＬＥＤランプ１４００を示す。
【００２３】
状態報知システム１００の携帯端末１０００は、このＬＥＤランプ１４００を用いてキッティングの状態を報知する。
【００２４】
キッティング装置２０００は、各携帯端末１０００にアプリケーションをインストールし、必要な環境設定等を行う装置である。実施形態１では、ノートパソコンとする。
【００２５】
ここで、図２を用いて、状態報知システム１００の携帯端末１０００がキッティングの状態を報知する例を説明する。
【００２６】
３日に分けて、携帯端末Ａ〜Ｄのキッティング作業を行った場合を例に説明する。
【００２７】
図２において、矩形１０は、ＬＥＤランプ１４００が点滅していることを表すものであり、ＬＥＤランプ１４００の様子の遷移を示している。矩形１１は、矩形１０と同様にＬＥＤランプ１４００が点滅していることを表すものであるが、色が異なるＬＥＤランプ１４００の様子の遷移を示している。矩形１０等に示されているＬＥＤランプ１４００の間隔が広いほど、点滅の間隔が長いものとする。
【００２８】
キッティング作業者は、キッティング作業として、４台の携帯端末１０００のうち、３台にメーラ（mailer）をインストールし、１台にＶＰＮ（Virtual Private Network）ソフトをインストールするものとする。
【００２９】
まず、４月１日に、携帯端末Ｃにメーラをインストールし、携帯端末ＤにＶＰＮソフトをインストールした。
【００３０】
次に、４月１５日に、携帯端末Ａと携帯端末Ｂとにメーラをインストールしようとする。この際、どの携帯端末１０００にメーラ又はＶＰＮソフトを４月１日にインストールしたかは、その外観からでは判別がつかない。
【００３１】
そこで、キッティング作業者はキッティング装置２０００を操作して、各携帯端末１０００に対して、どのようなキッティングがなされているかを報知させる確認コマンドを送信する。
【００３２】
確認コマンドを受信した携帯端末Ｃは、メーラがインストールされている旨を示す態様、すなわち青色及び所定の点滅間隔でＬＥＤランプ１４００を点滅させる（矩形１０参照）。
【００３３】
また、確認コマンドを受信した携帯端末Ｄは、ＶＰＮソフトがインストールされている旨を示す態様、すなわち緑色及び所定の点滅間隔でＬＥＤランプ１４００を点滅させる（矩形１１参照）。
【００３４】
このＬＥＤランプの点滅を視認することで、キッティング作業者は、携帯端末Ａ及び携帯端末Ｂには、まだアプリケーションがインストールされていないことがわかるので、携帯端末Ａ及び携帯端末Ｂにメーラをインストールする。
【００３５】
次に、４月１日にインストールしたメーラ及びＶＰＮソフトのバージョンを変更するする必要が生じ、５月１日にその変更を行うものとする。
【００３６】
この場合、キッティング作業者はキッティング装置２０００を操作して、各端末装置１０００に対して確認コマンドを送信する。
【００３７】
携帯端末Ａ、Ｂは、メーラがインストールされている旨を示す態様、すなわち青色及び所定の点滅間隔でＬＥＤランプ１４００を点滅させる（矩形１２参照）。
【００３８】
携帯端末Ｃも、メーラがインストールされている旨を示す態様、すなわち青色でＬＥＤランプ１４００を点滅させる。ただし、その点滅の間隔は携帯端末ＡのＬＥＤランプ１４００の点滅間隔より長い間隔で点滅する（矩形１３参照）。
【００３９】
点滅間隔は、携帯端末１０００にアプリケーションがインストールされたときから確認コマンドを受信したときまでの時間に応じて決められ、その時間が長いほど点滅間隔は長くなる。
【００４０】
携帯端末Ｄも、ＶＰＮソフトがインストールされている旨を示す態様、すなわち緑色でＬＥＤランプ１４００を点滅させる。その点滅の間隔は携帯端末Ｃと同じ間隔である。
【００４１】
キッティング作業者は、長い間隔でＬＥＤランプ１４００が青色で点滅している携帯端末Ｃに、新しいバージョンのメーラをインストールする。また、長い間隔でＬＥＤランプ１４００が緑色で点滅している携帯端末Ｄに、新しいバージョンのＶＰＮソフトをインストールする。
【００４２】
すなわち、状態報知システム１００の携帯端末１０００は、ＬＥＤランプ１４００を用いて、インストールされたアプリケーションがなんであるかを示すだけでなく、携帯端末１０００にアプリケーションがいつごろインストールされたかを示すことができる。
【００４３】
このように、携帯端末１０００は、インストールされているアプリケーションとそのインストール時期とをＬＥＤランプ１４００を点滅させることによって報知することで、キッティング作業者に、携帯端末１０００の外観によってキッティングの状態を知らせることができる。従って、キッティング作業者は、一台ずつキッティングの状態を調べることなく次に行うべき作業、例えば、バージョンアップを行う又は各種設定等を行うなどの作業を速やかに実行することができる。
【００４４】
図では、インストールに成功してインストールされている場合を説明したが、インストールに失敗している場合は、例えば、赤色でＬＥＤランプ１４００を点滅させるものとしてもよい。キッティング作業者は、インストールに失敗した携帯端末１０００、すなわち、ＬＥＤランプ１４００が赤色で点滅している携帯端末１０００を即座に知ることができ、その携帯端末１０００にインストールすべきアプリケーションをインストールすることができる。
【００４５】
以下、状態報知システム１００について図を用いて説明する。
【００４６】
＜機能＞
図３は、携帯端末１０００及びキッティング装置２０００の機能的構成の例を示すブロック図である。
【００４７】
携帯端末１０００は、制御部１１００、通信部１２００、設定処理部１３００、ＬＥＤランプ１４００、報知処理部１５００、点滅間隔決定部１６００、アプリケーション記憶部１７００、インストールログ記憶部１８００及び確認データ記憶部１９００を有する。
【００４８】
制御部１１００は、端末装置１０００が基本的に有している機能、例えば、携帯端末１０００が携帯電話機であれば通話機能などの機能のほか、状態報知システム１００の携帯端末として他の機能部を制御する機能等を有する。
【００４９】
通信部１２００は、キッティング装置２０００と無線で通信を行う機能を有する。
【００５０】
設定処理部１３００は、キッティング装置２０００から受信したアプリケーション及び確認データ等を自装置である携帯端末１０００にキッティングする機能を有する。詳細には、キッティング装置２０００から、インストールしようとするアプリケーションのインストーラを受信し、受信したインストーラを起動する。起動されたインストーラは、アプリケーションの実行ファイル及びアプリケーションで使用するデータ等をキッティング装置２０００から受信してアプリケーション記憶部１７００に記憶させ、必要な設定等を行う。また、キッティング装置２０００から受信した確認データを確認データ記憶部１９００に記憶させる。
【００５１】
ＬＥＤランプ１４００は、半導体素子を用いたランプである。
【００５２】
報知処理部１５００は、キッティングの状態を報知する処理を行う機能を有する。具体的には、確認データ記憶部１９００に記憶されている確認データに基づいて報知する。例えば、確認データで示される報知方法がＬＥＤを用いる方法である場合は、確認データで示されている色と、アプリケーションがインストールされたときから報知するときまでの経過時間に応じた点滅間隔とでＬＥＤランプ１４００を点滅させる。
【００５３】
点滅間隔決定部１６００は、報知処理部１５００から依頼を受け、ＬＥＤランプ１４００の点滅間隔を求める機能を有する。具体的には、インストールログを参照して取得したインストールされたときから依頼を受けたときまでの経過時間を求め、経過時間を基に点滅間隔を求める。
【００５４】
例えば、点滅間隔の初期値が５００ｍｓｅｃ（ミリ秒）であり、インストールされたときから１日経過するごとに１００ｍｓｅｃ長くなる等である。３０日経過したときの点滅間隔は、５００（ｍｓｅｃ）＋１００（ｍｓｅｃ）＊３０（日）＝３５００（ｍｓｅｃ）となる。
【００５５】
アプリケーション記憶部１７００は、インストールされたアプリケーションの実行ファイル及びアプリケーションが使用するデータ等を記憶しておく機能を有する。
【００５６】
インストールログ記憶部１８００は、携帯端末１０００にインストールされたアプリケーションのインストールのログを記憶しておく機能を有する。アプリケーションがインストールされる毎に１つのインストールログが追加される。
【００５７】
確認データ記憶部１９００は、インストールされたアプリケーションと対応付けられた確認データを記憶しておく機能を有する。確認データは、アプリケーションの種類毎に異なる。また、この確認データ記憶部１９００には、直近にインストールの処理がなされたアプリケーションの確認データのみが記憶されている。
【００５８】
次に、キッティング装置２０００は、制御部２１００、通信部２２００、操作部２３００、キッティング処理部２４００、確認要求部２５００、アプリケーション記憶部２６００及びアプリ別確認データ記憶部２７００を有する。
【００５９】
制御部２１００は、いわゆるノートパソコンであるキッティング装置２０００に必要な一般的なパソコンの機能のほか、状態報知システム１００のキッティング装置として他の機能部を制御する機能等を有する。
【００６０】
通信部２２００は、携帯端末１０００と無線で通信を行う機能を有する。実施形態１では、携帯端末１０００にアプリケーションをインストールする場合及び各種設定をする場合は、無線ＬＡＮで携帯端末１０００と接続して通信を行う。また、確認コマンドを送信する場合は、無線で送信するものとする。
【００６１】
操作部２３００は、テンキー等を含み、ユーザからの操作、例えば、キーの押下等を検出する機能を有する。
【００６２】
キッティング処理部２４００は、アプリケーションを携帯端末１０００にインストール等する機能を有する。実施形態１では、インストールするアプリケーションのインストーラ、アプリケーションの実行ファイル、アプリケーションが使用するデータ及びアプリケーションに対応した確認データを、通信部２２００を介して携帯端末１０００に送信する機能を有する。
【００６３】
確認要求部２５００は、確認コマンドを生成して、携帯端末１０００に対して送信する機能を有する。
【００６４】
アプリケーション記憶部２６００は、各種アプリケーションの実行ファイル、各アプリケーションが使用するデータ、各アプリケーションのインストーラ等を記憶しておく機能を有する。
【００６５】
アプリ別確認データ記憶部２７００は、アプリケーション記憶部２６００に記憶されているアプリケーション毎の確認データを記憶しておく機能を有する。
【００６６】
上述した機能の全部または一部は、携帯端末１０００及びキッティング装置２０００の有するそれぞれのＣＰＵが、携帯端末１０００及びキッティング装置２０００それぞれのメモリ等に記録されているプログラムを実行することにより実現される。
【００６７】
＜データ＞
次に、状態報知システム１００で用いるデータについて図４〜図７を用いて説明する。
【００６８】
図４は、確認データ管理テーブル２７１０の構成及び内容の例を示す図であり、図５は、アプリ別管理テーブル２７２０の構成及び内容の例を示す図である。
【００６９】
この確認データ管理テーブル２７１０及びアプリ別管理テーブル２７２０は、キッティング作業者によって、予め、キッティング装置２０００のアプリ別確認データ記憶部２７００に記憶されているものである。
【００７０】
確認データ管理テーブル２７１０は、確認データ番号２７１１、状態２７１２、タイプ２７１３及び動作２７１４を有する。
【００７１】
確認データ番号２７１１は、確認データ管理テーブル２７１０に登録されている確認データの番号を示す。
【００７２】
状態２７１２は、アプリケーションの状態、すなわち、アプリケーションのインストールが成功して正しくインストールされた状態又はインストールが失敗して正しくインストールされていない状態のいずれの状態であるかを示す。「成功」は、インストールに成功したことを示し、「失敗」はインスロールが成功しなかったことを示す。
【００７３】
タイプ２７１３は、報知のタイプ、言い換えれば、報知に用いる機器を示す。具体的には、「ＬＥＤ」はＬＥＤランプ１４００を用いることを示し、「振動」は端末装置１０００が備えるバイブレータを用いることを示し、「音」は携帯端末１０００が備える発音機を用いることを示す。
【００７４】
動作２７１４は、タイプ２７１３で示す機器をどのような動作をさせるのかを示す。
【００７５】
タイプ２７１３が「ＬＥＤ」の場合は、色と点滅のパターンとを示す。パターンは点滅のリズム等を示す。タイプ２７１３が「振動」の場合は、振動のパターンと強さとを示す。また、タイプ２７１３が「音」の場合は、メロディと強さとを示す。
【００７６】
例えば、確認データ番号２７１１が「４」の確認データでは、インストールに失敗していた場合は、パターン１で示されるリズムで中程度の強さで振動し、且つ、サウンド１が中程度の強さで鳴ることになる。
【００７７】
次に、アプリ別管理テーブル２７２０は、登録番号２７２１、アプリケーション名２７２２及び確認データ番号２７２３を有する。このアプリ別管理テーブル２７２０は、アプリケーションと確認データとの対応付けを行うものである。
【００７８】
登録番号２７２１は、アプリ別管理テーブル２７２０に登録されているアプリケーションの登録番号を示す。
【００７９】
アプリケーション名２７２２は、キッティング装置２０００がインストールを行うことができるアプリケーションの名称を示す。
【００８０】
確認データ番号２７２３は、確認データ管理テーブル２７１０の確認データ番号２７１１で示される確認データの番号を示す。
【００８１】
キッティング装置２０００は、例えば、メーラを携帯端末１０００にインストールする場合は、アプリ別管理テーブル２７２０のアプリケーション名２７２２が「メーラ」のレコードの確認データ番号２７２３の番号を読み出す。次に、確認データ管理テーブル２７１０の確認データ番号２７１１が読み出した番号と同じであるレコードの状態２７１２、タイプ２７１３及び動作２７１４を読み出して、メーラの確認データとして端末装置１０００に送信する。
【００８２】
次に、図６及び図７を用いて説明するデータは、携帯端末１０００に記憶されているデータである。
【００８３】
図６は、確認データ記憶部１９００に記憶されている確認データ１９１０の構成及び内容の例を示す図である。
【００８４】
図６において、確認データ１９１０Ａは携帯端末Ａの確認データ記憶部１９００に記憶されている確認データ１９１０を示し、確認データ１９１０Ｄは携帯端末Ｄの確認データ記憶部１９００に記憶されている確認データ１９１０を示す。また、確認データ１９１０Ｘは携帯端末Ｘの確認データ記憶部１９００に記憶されている確認データ１９１０を示す。
【００８５】
キッティング装置２０００は、インストールするアプリケーションの確認データを確認データ管理テーブル２７１０から読み出して、確認データ１９１０の形式にして端末装置１０００に送信する。
【００８６】
確認データ１９１０は、「Ｎｕｍ」、「Ｓｔａｔｕｓ」、「Ｔｙｐｅ」及び「Ａｃｔｉｏｎ」で構成される。尚、「Ａｃｔｉｏｎ」に続いて、「Ｔｙｐｅ」で指定された機器に行わせる動作の詳細が必要に応じて更に指定される。
【００８７】
「Ｎｕｍ」は、確認データの番号を示す。この番号は、確認データ管理テーブル２７１０の確認データ番号２７１１に該当する。
【００８８】
「Ｓｔａｔｕｓ」は、アプリケーションの状態、すなわち、アプリケーションのインストールが成功して正しくインストールされた状態又はインストールが失敗して正しくインストールされていない状態のいずれの状態であるかを示す。確認データ管理テーブル２７１０の状態２７１２に該当する。
【００８９】
「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」は、インストールが成功した状態であることを示し、「Ｓｔａｔｕｓ＝Ｆａｉｌｕｒｅ」は失敗した状態であることを示す。
【００９０】
「Ｔｙｐｅ」は、報知に用いる機器を示す。確認データ管理テーブル２７１０のタイプ２７１３に該当する。
【００９１】
「Ａｃｔｉｏｎ」は、「Ｔｙｐｅ」で示す機器をどのような動作をさせるのかを示す。確認データ管理テーブル２７１０の動作２７１４に該当する。
【００９２】
例えば、確認データ１９１０Ａは、携帯端末Ａにインストールされたメーラの確認データ１９１０を示したものである。
【００９３】
メーラの確認データは、確認データ管理テーブル２７１０の確認データ番号２７１１が「１」のレコードであるので、確認データ１９１０Ａには「Ｎｕｍ＝１」と記載されている。確認データ管理テーブル２７１０の状態２７１２が「成功」であるので、「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」と記載され、確認データ管理テーブル２７１０のタイプ２７１３が「ＬＥＤ」であるので、「Ｔｙｐｅ＝ＬＥＤ」と記載され、確認データ管理テーブル２７１０の動作２７１４が「点滅：パターン１、色：青」であるので、「Ａｃｔｉｏｎ＝Ｂｌｉｎｋ１，Ｃｏｌｏｒ＝Ｂｌｕｅ」と記載されている。
【００９４】
また、確認データ１９１０Ｄは、携帯端末ＤにインストールされたＶＰＮソフトの確認データ１９１０を示したものである。ＶＰＮソフトの確認データは、確認データ管理テーブル２７１０の確認データ番号２７１１が「２」のレコードであるので、「Ｎｕｍ＝２」と記載される。確認データ管理テーブル２７１０の状態２７１２が「成功」であるので、「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」と記載され、確認データ管理テーブル２７１０のタイプ２７１３が「ＬＥＤ」であるので、「Ｔｙｐｅ＝ＬＥＤ」と記載され、確認データ管理テーブル２７１０の動作２７１４が「点滅：パターン２、色：緑」であるので、確認データ１９１０Ｄには「Ａｃｔｉｏｎ＝Ｂｌｉｎｋ２，Ｃｏｌｏｒ＝Ｇｒｅｅｎ」と記載されている。
【００９５】
また、確認データ１９１０Ｘは、確認データ番号２７１１が「３」のレコードの確認データ１９１０を示したものである。
【００９６】
確認データ１９１０Ｘの１行目に、確認データ番号２７１１が「３」であるので、「Ｎｕｍ＝３」と記載されている。確認データ管理テーブル２７１０の状態２７１２の１段目が「成功」であるので、「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」と記載され、確認データ管理テーブル２７１０のタイプ２７１３の１段目が「ＬＥＤ」であるので、「Ｔｙｐｅ＝ＬＥＤ」と記載され、確認データ管理テーブル２７１０の動作２７１４の１段目が「点滅：パターン１、色：橙」であるので、「Ａｃｔｉｏｎ＝Ｂｌｉｎｋ１，Ｃｏｌｏｒ＝Ｏｒａｎｇｅ」と記載されている。
【００９７】
また、２行目に、確認データ番号２７１１が「３」であるので、確認データ１９１０Ｄには「Ｎｕｍ＝３」と記載されている。確認データ管理テーブル２７１０の状態２７１２の２段目が「失敗」であるので、「Ｓｔａｔｕｓ＝Ｆａｉｌｕｒｅ」と記載され、確認データ管理テーブル２７１０のタイプ２７１３の２段目が「振動」であるので、「Ｔｙｐｅ＝Ｖｉｂｒａｔｅｒ」と記載され、確認データ管理テーブル２７１０の動作２７１４の２段目が「振動：パターン１、強さ：中」であるので、「Ａｃｔｉｏｎ＝Ｐａｔｔｅｒｎ１,Ｓｔｒｅｎｇｔｈ＝Ｍｉｄｄｌｅ」と記載されている。
【００９８】
図７は、インストールログ記憶部１８００に記憶されているインストールログの構成及び内容の例を示す図である。
【００９９】
図７において、インストールログ１８１０Ａは携帯端末Ａのインストールログ記憶部１８００に記憶されているインストールログ１８１０を示し、インストールログ１８１０Ｄは携帯端末Ｄのインストールログ記憶部１８００に記憶されているインストールログ１８１０を示す。
【０１００】
インストールログ１８１０は、作成日時、「Ａｐｌ」、「Ｓｔａｔｕｓ」、「Ｎｕｍ」及び「ＩＤ」を含む。
【０１０１】
作成日時は、インストールログ１８１０が作成された日時を示す。
【０１０２】
「Ａｐｌ」は、インストールされたアプリケーションを示す。
【０１０３】
「Ｓｔａｔｕｓ」は、アプリケーションのインストールが成功して正しくインストールされた状態又はインストールが失敗して正しくインストールされていない状態のいずれの状態であるかを示す。「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」は、インストールが成功した状態であることを示し、「Ｓｔａｔｕｓ＝Ｆａｉｌｕｒｅ」は失敗した状態であることを示す。
【０１０４】
「Ｎｕｍ」は、確認データの番号を示す。
【０１０５】
「ＩＤ」は、キッティング作業者の識別子を示す。
【０１０６】
例えば、インストールログ１８１０Ａは、携帯端末Ａにインストールされたメーラのインストールログ１８１０を示したものである。メーラの確認データは、確認データ管理テーブル２７１０の確認データ番号２７１１が「１」のレコードである。
【０１０７】
従って、インストールログ１８１０Ａでは、「２００９／０５／０２ １１：２１：４５」、すなわち、２００９年５月２日の１１時２１分４５秒にインストールログ１８１０Ａが生成され、「Ａｐｌ＝Ｍａｉｌｅｒ」、すなわち、メーラがインストールされ、「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」、すなわち、インストールは成功し、「Ｎｕｍ＝１」、すなわち、確認データの番号は「１」であり、「ＩＤ＝Ｔａｎａｋａ」、すなわち、作業者が「Ｔａｎａｋａ」であることが、記録されている。
【０１０８】
同様に、インストールログ１８１０Ｄでは、「２００９／０５／０１ １５：３２：０９」、すなわち、２００９年５月１日の１５時３２分９秒にインストールログ１８１０Ｂが生成され、「Ａｐｌ＝ＶＰＮ」、すなわち、ＶＰＮソフトがインストールされ、「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」、すなわち、インストールは成功し、「Ｎｕｍ＝２」、すなわち、確認データの番号は「２」であり、「ＩＤ＝Ｔａｎａｋａ」、すなわち、作業者が「Ｔａｎａｋａ」であることが、記録されている。
【０１０９】
＜動作＞
以下、実施形態１の状態報知システム１００の動作について図８を用いて説明する。
【０１１０】
図８は、状態報知システム１００のキッティング処理及びキッティング確認処理を示すフローチャートである。
【０１１１】
キッティング装置２０００を使用してキッティング作業者が携帯端末１０００にアプリケーションをインストールするキッティング処理と、そのインストール状態を確認するキッティング確認処理とを説明する。キッティング処理は、図８のステップＳ１００〜ステップＳ１２０及びステップＳ２００とで示される処理である。また、キッティング確認処理は、ステップＳ１３０〜ステップＳ１６０、ステップＳ２１０及びステップＳ２２０で示される処理である。
【０１１２】
キッティング作業者は、キッティング装置２０００と携帯端末１０００とを無線ＬＡＮで接続し、必要に応じて、携帯端末１０００での操作、例えば、新しいアプリケーションのインストールを可能とするモードにする等の操作を行う。
【０１１３】
次に、キッティング作業者は、キッティング装置２０００においてアプリケーション名を指定してインストールを指示する操作を行う。この際、キッティング作業者自身の識別子も入力する。
【０１１４】
キッティング装置２０００の操作部２３００は、キッティング作業者による操作を検出すると検出した操作を制御部２１００に通知する。
【０１１５】
通知を受けた制御部２１００は、その操作からアプリケーションをインストールする指示であることを判断し、キッティング処理部２４００にインストールを指示する。その際、キッティング作業者により指定されたアプリケーション名とキッティング作業者の識別子とを渡す。
【０１１６】
指示を受けたキッティング処理部２４００は、まず、渡されたアプリケーション名のアプリケーションのインストーラをアプリケーション記憶部２６００から読み出す。読み出したインストーラとキッティング作業者の識別子とを、通信部２２００を介して携帯端末１０００に送信する。
【０１１７】
その後、キッティング処理部２４００は、アプリ別確認データ記憶部２７００からアプリケーションの確認データを読み出して、インストーラからの要求に応じて送信する。例えば、ユーザにより指定されたアプリケーション名が「メーラ」である場合、キッティング処理部２４００は、アプリ別確認データ記憶部２７００に記憶されているアプリ別管理テーブル２７２０のアプリケーション名２７２２が「メーラ」であるレコードを検索する。検索されたレコードの確認データ番号２７２３の番号を読み出す。次に確認データ管理テーブル２７１０の確認データ番号２７１１が読み出した番号と同じレコードを検索し、検索されたレコードの状態２７１２、タイプ２７１３及び動作２７１４を読み出して、確認データ１９１０（図６参照）を作成して携帯端末１０００に送信する。
【０１１８】
また、インストーラからの要求に応じて、キッティング処理部２４００は、アプリケーション記憶部２６００からアプリケーションの実行ファイル及びアプリケーションが使用するデータ等を読み出して送信する。（ステップＳ２００）。
【０１１９】
一方、携帯端末１０００において、通信部１２００を介してインストーラとキッティング作業者の識別子とを受信した制御部１１００は、受信したインストーラとキッティング作業者の識別子とを設定処理部１３００に渡す。
【０１２０】
設定処理部１３００は、作業メモリにインストーラを展開し、インストーラを起動する。
【０１２１】
起動されたインストーラは、アプリケーションの確認データ１９１０を要求して受信し、設定処理部１３００に渡す。設定処理部１３００は、渡された確認データ１９１０を確認データ記憶部１９００に記憶させる（ステップＳ１００）。
【０１２２】
その後、インストーラは、いわゆるインストールの処理、すなわち、アプリケーションの実行ファイル及びアプリケーションが使用するデータ等をキッティング装置２０００に要求して受信し、アプリケーション記憶部１７００に記憶させ、必要な設定等の処理を行う（ステップＳ１１０）。その後、インストーラは、アプリケーションのインストールの結果、すなわち、インストールが成功したのか失敗したのかを、設定処理部１３００に通知する。
【０１２３】
通知を受けた設定処理部１３００は、通知されたインストールの結果に応じて、インストールログ１８１０を生成する。
【０１２４】
具体的には、設定処理部１３００は、携帯端末１０００に内蔵されているタイマから日時を取得し、インストーラからアプリケーション名を取得する。設定処理部１３００は、取得した日時、アプリケーション名、インストール結果、確認データ１９１０に含まれている確認データの番号及び制御部１１００から渡されたキッティング作業者の識別子とから、インストールログ１８１０を生成する。
【０１２５】
インストールログ１８１０を生成した設定処理部１３００は、生成したインストールログをインストールログ記憶部１８００に記憶させる（ステップＳ１２０）。
【０１２６】
次に、キッティング作業者は、キッティング装置２０００において確認コマンドを送信する操作を行う。
【０１２７】
キッティング装置２０００の操作部２３００は、キッティング作業者による操作を検出すると検出した操作を制御部２１００に通知する。
【０１２８】
通知を受けた制御部２１００は、その操作から確認コマンドを送信する指示であると判断し、確認コマンドを送信するよう確認要求部２５００に指示する。
【０１２９】
指示を受けた確認要求部２５００は、通信部２２００を介して、確認コマンドをブロードキャストで送信する（ステップＳ２１０）。この送信は、無線ＬＡＮによって行う。
【０１３０】
携帯端末１０００において、通信部１２００を介して確認コマンドを受信した制御部１１００は、報知処理を行うよう報知処理部１５００に依頼する。
【０１３１】
依頼を受けた報知処理部１５００は、まず、確認データ記憶部１９００に記憶されている確認データ１９１０を読み出し（図６参照）、「Ａｃｔｉｏｎ」に応じた点滅間隔の初期値を求める。具体的には、「Ａｃｔｉｏｎ＝Ｂｌｉｎｋ１」であれば５００ｍｓｅｃ（ミリ秒）、「Ａｃｔｉｏｎ＝Ｂｌｉｎｋ２」であれば２５０ｍｓｅｃ（ミリ秒）を点滅間隔の初期値として求める。点滅間隔の初期値は、予め点滅のパターンによって決められているものとする。
【０１３２】
点滅間隔の初期値を求めた報知処理部１５００は、求めた初期値を点滅間隔決定部１６００に渡して点滅間隔の決定を依頼する。
【０１３３】
依頼を受けた点滅間隔決定部１６００は、インストールログ記憶部１８００に記憶されているインストールログのうち、最新に生成されたインストールログを読み出す（ステップＳ１３０）。
【０１３４】
例えば、図７のインストールログ１８１０Ａの作成日時「２００９／０５／０２ １１：２１：４５」が、インストールログ記憶部１８００に記憶されているインストールログのうち最も新しい場合は、このインストールログ１８１０Ａを読み出す。
【０１３５】
次に、点滅間隔決定部１６００は、携帯端末１０００に内蔵されているタイマから現在の日時を取得する。取得した日時からこのインストールログの中の作成日時までの、時間が単位の経過時間を求める（ステップＳ１４０）。
【０１３６】
点滅間隔決定部１６００は、求めた経過時間を日にちに換算して経過日数を求める。具体的には、経過時間を２４時間で割った商を経過日数として求める。
【０１３７】
求めた経過日数に一日当たりの点滅間隔、例えば、１００ｍｓｅｃ（ミリ秒）を掛けた値を、報知処理部１５００から渡された初期値に加算して新しい点滅間隔を求める（ステップＳ１５０）。
【０１３８】
新しい点滅間隔を求めた点滅間隔決定部１６００は、求めた新しい点滅間隔を報知処理部１５００に渡す。
【０１３９】
新しい点滅間隔を渡された報知処理部１５００は、読み出したインストールログ１８１０の「Ｓｔａｔｕｓ」が、読み出した確認データ１９１０の「Ｓｔｓｔｕｓ」と同じである場合は、確認データ記憶部１９００から読み出した確認データ１９１０に基づいて、点滅間隔を新しい点滅間隔とするよう制御して、報知をＬＥＤランプ１４００を点滅させる。
【０１４０】
例えば、インストールログ１８１０Ａ（図７参照）の「Ｓｔａｔｕｓ」が「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」であり、確認データ１９１０Ａ（図６参照）の「Ｓｔａｔｕｓ」が「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」である場合には、確認データ１９１０Ａに従って、ＬＥＤランプ１４００を青色で新しい点滅間隔で点滅させる。尚、インストールログ１８１０の「Ｓｔａｔｕｓ」が「Ｓｔａｔｕｓ＝Ｆａｉｌｕｒｅ」であり、確認データ１９１０に「Ｓｔａｔｕｓ」が「Ｓｔａｔｕｓ＝Ｆａｉｌｕｒｅ」の行がある場合（図６の確認データ１９１０Ｘ参照）には、確認データ１９１０に従って中程度の強度で振動させる。
【０１４１】
読み出したインストールログ１８１０の「Ｓｔａｔｕｓ」と、読み出した確認データ１９１０の「Ｓｔｓｔｕｓ」とが同じである行が確認データ１９１０にない場合は、報知は行わない。
【０１４２】
各端末装置の報知を目視したキッティング作業者は、その報知に応じて次の作業を行う（ステップＳ２２０）。例えば、インストールに失敗した旨の報知であれば、再インストールを行うなどである。
＜実施形態２＞
実施形態１では、アプリケーションと対応付けた確認データ１９１０に応じて報知を行った。実施形態２では、基本的には、実施形態１と同様にアプリケーションと対応付けた確認データ１９１０に応じて報知を行う。しかし、インストールされているアプリケーションによっては報知の態様が相互に似通ってしまい、携帯端末の外観のみではキッティング状態、例えば、インストールされているアプリケーションの種類やインストール時期等を確認するのが難しい場合等が生じ得る。
【０１４３】
例えば、２種類のアプリケーションがそれぞれ別の携帯端末１０００にインストールされた場合に、これらのアプリケーションに対応付けられている確認データ１９１０で示される報知態様が似通っている場合、例えば、ランプの色が同じで、点滅のパターンが似通っている場合があり得る。
【０１４４】
この場合、携帯端末１０００がＬＥＤランプを点滅させて報知したとしても、ランプの色が同じで、点滅のパターンの差がほとんどないことになる。従って、携帯端末１０００のＬＥＤランプの点滅の態様からは、どちらのアプリケーションがインストールされているのかキッティング作業者が判断するのは難しい。
【０１４５】
また、例えば、同じアプリケーションが複数台の携帯端末１０００にそれぞれ異なる日にインストールされた場合に、点滅間隔の差があまり出ない場合があり得る。インストールされた日が携帯端末１０００同士で近い場合である。
【０１４６】
この場合、携帯端末１０００がＬＥＤランプを点滅させて報知したとしても、アプリケーションが同じであるのでランプの色が同じであり、点滅の間隔の差がほとんどないことになる。従って、携帯端末１０００のＬＥＤランプの点滅の態様からは、アプリケーションを先にインストールした携帯端末１０００がどれなのかをキッティング作業者が判断するのは難しい。
【０１４７】
そこで、実施形態２は、報知の態様を動的に変更することで、キッティング作業者の確認を容易にするものである。この際、キッティング作業者に対して、どのように報知態様を変更したのかも通知するものとする。
【０１４８】
図９は、実施形態２の状態報知システム２００の構成例を示す図である。
【０１４９】
状態報知システム２００は、キッティングの対象である携帯端末４０００Ａ〜Ｄ、キッティング装置５０００及び管理サーバ３０００を有する。
【０１５０】
携帯端末４０００Ａ〜Ｄ、管理サーバ３０００及びキッティング装置５０００とは、お互い無線ＬＡＮ（Local Area Network）やＢｌｕｅｔｏｏｔｈなどの無線通信により通信できるものとする。
【０１５１】
尚、実施形態２では、キッティング装置５０００は、無線ＬＡＮを介して携帯端末４０００Ａ〜Ｄにキッティング処理を行う。また、管理サーバ３０００は、携帯端末４０００Ａ〜Ｄ及びキッティング装置５０００と無線ＬＡＮ（Local Area Network）により通信する。
【０１５２】
実施形態２では、管理サーバ３０００が報知の態様の相違度を判断して、携帯端末４０００に対して報知の態様の変更を行う。
【０１５３】
携帯端末４０００Ａ〜Ｄは、携帯端末４０００と総称するものとし、以下、携帯端末４０００Ａは携帯端末Ａ、携帯端末４０００Ｂは携帯端末Ｂ、携帯端末４０００Ｃは携帯端末Ｃ、携帯端末４０００Ｄは携帯端末Ｄというものとする。
【０１５４】
携帯端末４０００は、基本的には、実施形態１で説明した携帯端末１０００とほぼ同様の機能を有する。また、キッティング装置５０００も、基本的には、実施形態１で説明したキッティング装置２０００とほぼ同様の機能を有する。相違点は、以下の＜機能＞の項で説明する。
【０１５５】
＜機能＞
図１０は、管理サーバ３０００、携帯端末４０００及びキッティング装置５０００の機能的構成の例を示すブロック図である。
【０１５６】
管理サーバ３０００は、制御部３１００、通信部３２００、設定確認処理部３３００、インストールログ収集部３４００、相違度判定部３５００、新確認データ生成部３６００及び端末別確認データ記憶部３７００を有する。
【０１５７】
制御部３１００は、管理サーバ３０００が基本的に有している機能、例えば、サーバ装置としてのメモリ管理機能などの機能のほか、状態報知システム２００の管理サーバとして他の機能部を制御する機能等を有する。
【０１５８】
通信部３２００は、キッティング装置５０００又は携帯端末４０００と、無線で通信する機能を有する。
【０１５９】
設定確認処理部３３００は、キッティング装置５０００から確認コマンドを受信した際に、キッティングの状態を確認するための処理、例えば、確認コマンドを携帯端末４０００に送信する等の処理を行う機能を有する。
【０１６０】
インストールログ収集部３４００は、各携帯端末４０００が記憶しているインストールログ１８１０を収集する機能を有する。実施形態２では、インストールログを収集するが、携帯端末４０００が報知したとした場合の報知態様を求めることができる情報であればよい。報知態様を求めることができる情報とは、具体的には、確認データ１９１０及び点滅間隔である。従って、実施形態２では、アプリケーション名及びログの生成日時を含むインストールログ１８１０を収集するものとする。
【０１６１】
相違度判定部３５００は、確認データに基づいて報知した場合に、報知態様の相違度を判断する機能を有する。実施形態２では、確認データの構成要件のうち、同じ内容の要件がいくつあるかで判断する。
【０１６２】
また、相違度判定部３５００は、判断した相違度に基づいて確認データを変更する必要の有無及びどの確認データ１９１０を変更するのかを判断する機能を有する。
【０１６３】
新確認データ生成部３６００は、新しい確認データを生成する機能を有する。
【０１６４】
端末別確認データ記憶部３７００は、インストールログ収集部３４００が収集した携帯端末毎のインストールログを記憶しておく機能を有する。また、更に、アプリ別管理テーブル２７２０（図５参照）及び確認データ管理テーブル２７１０（図４参照）を記憶しておく機能を有する。
【０１６５】
携帯端末４０００は、制御部１１００、通信部４２００、設定処理部１３００、ＬＥＤランプ１４００、報知処理部４５００、アプリケーション記憶部１７００、インストールログ記憶部１８００、確認データ記憶部１９００及び確認データ処理部４１００を有する。
【０１６６】
制御部１１００、設定処理部１３００、ＬＥＤランプ１４００、報知処理部１５００、アプリケーション記憶部１７００、インストールログ記憶部１８００、確認データ記憶部１９００は、実施形態１で説明した携帯端末１０００（図３参照）の設定処理部１３００、ＬＥＤランプ１４００、アプリケーション記憶部１７００、インストールログ記憶部１８００、確認データ記憶部１９００と同様の機能を有する。
【０１６７】
通信部４２００は、キッティング装置５０００又は管理サーバ３０００と通信する機能を有する。
【０１６８】
確認データ処理部４１００は、インストールログ記憶部１８００に記憶しているインストールログ１８１０を読み出して管理サーバ３０００に送信する機能を有する。また、確認データ処理部４１００は、管理サーバ３０００から新しい確認データ１９１０を受信し、報知処理部４５００に通知する機能を有する。
【０１６９】
報知処理部４５００は、キッティングの状態を確認するための処理を行う機能を有する。具体的には、確認データ記憶部１９００に記憶されている確認データ１９１０又は確認データ処理部４１００から渡された新しい確認データ１９１０に基づいて報知の処理を行う。
【０１７０】
次に、キッティング装置５０００は、制御部２１００、通信部５２００、操作部２３００、キッティング処理部２４００、確認要求部２５００、アプリケーション記憶部２６００及びアプリ別確認データ記憶部２７００を有する。
【０１７１】
制御部２１００、操作部２３００、キッティング処理部２４００、確認要求部２５００、アプリケーション記憶部２６００及びアプリ別確認データ記憶部２７００は、実施形態１で説明したキッティング装置２０００（図３参照）の制御部２１００、通信部５２００、操作部２３００、キッティング処理部２４００、確認要求部２５００、アプリケーション記憶部２６００及びアプリ別確認データ記憶部２７００と同様の機能を有する。
【０１７２】
通信部５２００は、管理サーバ３０００又は携帯端末４０００と通信する機能を有する。
【０１７３】
上述した機能の全部または一部は、管理サーバ３０００、携帯端末４０００及びキッティング装置２０００の有するそれぞれのＣＰＵが、管理サーバ３０００、携帯端末１０００及びキッティング装置２０００それぞれのメモリ等に記録されているプログラムを実行することにより実現される。
【０１７４】
＜データ＞
次に、状態報知システム２００で用いるデータについて図１１を用いて説明する。実施形態１で図４〜図７を用いて説明したデータも、実施形態２の状態報知システム２００で用いる。
【０１７５】
図１１は、端末別管理テーブル３７１０の構成及び内容の例を示す図である。
【０１７６】
この端末別管理テーブル３７１０は、管理サーバ３０００の端末別確認データ記憶部３７００に記憶されている。管理サーバ３０００が確認コマンドをキッティング装置５０００から受信する都度、インストールログ収集部３３００が記憶させる。
【０１７７】
端末別管理テーブル３７１０は、登録番号３７１１、携帯端末ＩＤ３７１２、アプリケーション名３７１３及び設定日時３７１４を有する。
【０１７８】
登録番号３７１１は、端末別管理テーブル３７１０に登録されているレコードの番号を示す。
【０１７９】
携帯端末ＩＤ３７１２は、管理サーバ３０００が管理している携帯端末４０００の識別子を示す。詳細には、インストールログ収集部３４００が収集できたインストールログの携帯端末４０００の識別子である。
【０１８０】
アプリケーション名３７１３は、携帯端末ＩＤ３７１２で示される携帯端末４０００に直近にインストールされたアプリケーションのアプリケーション名を示す。
【０１８１】
設定日時３７１４は、携帯端末ＩＤ３７１２で示される携帯端末４０００にアプリケーション名３７１３で示されるアプリケーションがインストールされた日時を示す。
【０１８２】
＜動作＞
以下、実施形態２の状態報知システム２００の動作について図１２を用いて説明する。
【０１８３】
図１２は、状態報知システム２００のキッティング確認処理を示すフローチャートである。
【０１８４】
図１２では、図８を用いて説明した実施形態１のキッティング確認処理のみを説明する。実施形態２においても、実施形態１のキッティング処理と同様のキッティング処理が行われた後にキッティング確認処理が行われることとなる。
【０１８５】
以下、実施形態１のキッティング確認処理と相違する点を中心に、実施形態２のキッティング確認処理を説明する。
【０１８６】
キッティング作業者は、キッティング装置５０００において確認コマンドを送信する指示を出す操作を行う。
【０１８７】
キッティング装置５０００の操作部２３００は、キッティング作業者による操作を検出すると検出した操作を制御部２１００に通知する。
【０１８８】
通知を受けた制御部２１００は、その操作から確認コマンドを送信する指示であると判断し、確認要求部２５００に確認コマンドを送信するよう指示する。
【０１８９】
指示を受けた確認要求部２５００は、通信部５２００を介して、管理サーバ３０００に送信する（ステップＳ５１０）。
【０１９０】
管理サーバ３０００において、通信部３２００を介して確認コマンドを受信した制御部３１００は、携帯端末４０００のキッティングの状態を確認するための処理を設定確認処理部３２００に依頼する。
【０１９１】
依頼を受けた設定確認処理部３２００は、各携帯端末４０００が記憶している確認データ１９１０を収集するようインストールログ収集部３４００に依頼する。
【０１９２】
依頼を受けたインストールログ収集部３４００は、各携帯端末４０００に対して、記憶しているインストールログの送信を要求するログ要求コマンドをブロードキャストで送信する（ステップＳ３００）。
【０１９３】
携帯端末４０００において、通信部４２００を介してログ要求コマンドを受信した制御部１１００は、最新のインストールログを取得するよう確認データ処理部４１００に依頼する。
【０１９４】
依頼を受けた確認データ処理部４１００は、インストールログ記憶部１８００に記憶されている最新のインストールログ１８１０を読み出して、制御部１１００に渡す。
【０１９５】
インストールログ１８１０を渡された制御部１１００は、渡されたインストールログ１８１０を管理サーバ３０００に送信する（ステップＳ４００）。
【０１９６】
管理サーバ３０００において、通信部３２００を介してインストールログ１８１０を受信したインストールログ収集部３４００は、受信したインストールログ１８１０と、これらのデータを送信してきた携帯端末４０００のＩＤとを端末別管理テーブル３７１０に登録する。
【０１９７】
具体的には、インストールログ１８１０の「ＡＰＬ」で指定されているアプリケーションの名称をアプリケーション名３７１３に設定し、インストールログ１８１０の作成日時を設定日時３７１４に設定し、携帯端末４０００のＩＤを携帯端末ＩＤ３７１２に設定する。
【０１９８】
各携帯端末４０００からインストールログ１８１０を受信したインストールログ収集部３４００は、インストールログ１８１０を収集した旨を設定確認処理部３３００に通知する（ステップＳ３１０）。
【０１９９】
インストールログ１８１０を収集した旨の通知を受けた設定確認処理部３３００は、次に、確認データの相違度を求めて確認データを変更する必要があるか否かの判定を行うよう相違度判定部３５００に依頼する。
【０２００】
依頼を受けた相違判定部３５００は、まず、端末別確認データ記憶部３７００に記憶されている端末別管理テーブル３７１０に記憶されているアプリケーション名３７１３で示されるアプリケーション同士の確認データ１９１０の相違度を、アプリ別管理テーブル２７２０及び確認データ管理テーブル２７１０（図４参照）を参照して求める。求めた相違度に基づいて、確認データ１９１０を変更するか否かを判定し、変更する場合は変更する携帯端末を決定する（ステップＳ３２０）。
【０２０１】
この相違度判定部３５００の相違度判定処理については、図１３を用いて後で説明する。
【０２０２】
確認データ１９１０を変更するか否かを判定した相違度判定部３５００は、その旨を設定確認処理部３３００に通知する。確認データ１９１０を変更する旨を通知した場合は、変更する携帯端末４０００も通知する。具体的には、携帯端末４０００にインストールされているアプリケーション名を通知する。
【０２０３】
通知を受けた設定確認処理部３３００は、通知が確認データを変更する旨である場合は（ステップＳ３３０：Ｙｅｓ）、新確認データ生成部３６００に新しい確認データ１９１０の生成を依頼する。この際、アプリケーション名を通知する。
【０２０４】
依頼を受けた新確認データ生成部３６００は、通知されたアプリケーション名で示されるアプリケーションの確認データを読み出し、読み出した確認データの構成要素の一部を変更して新しい確認データ１９１０を生成する。
【０２０５】
例えば、アプリケーションがメーラである場合、確認データは確認データ管理テーブル２７１０（図４参照）の確認データ番号１７１１が「１」のレコードで示されるものである。従って、メーラの確認データは、タイプ２７１３が「ＬＥＤ」、動作２７１４が「点滅：パターン１」と「色：青」との３つの構成要素を含むことになる。これらの３つの要素のうちのいずれか又は全てを変更することで、新しい確認データを生成する。
【０２０６】
新しい確認データをどのような内容に変更するかは、他のアプリケーションの確認データを参照して決定する。例えば、端末別管理テーブル３７１０のアプリケーション名３７１３に登録されているメーラ以外のアプリケーションの確認データと重ならないような内容に変更する。ＶＰＮソフトの報知態様がＬＥＤを緑色に点滅させることから、メーラは緑色と異なる色で点滅させるようにする、又は、点滅パターンを変える等である。又は、どの構成要素を変更するか、どのように変更するかはランダムに決めることとしてもよい。また、音、画面表示等の新しいタイプの構成要素を追加することで、報知態様の相違を際立たせることとしてもよい。
【０２０７】
新しい確認データ１９１０を生成した新確認データ生成部３６００は、生成した新しい確認データ１９１０を設定確認処理部３３００に渡す。
【０２０８】
新しい確認データ１９１０を受け取った設定確認処理部３３００は、端末別管理テーブル３７１０を参照して、確認データ１９１０を新しい確認データ１９１０に変更させる携帯端末４０００に対して、新しい確認データ１９１０を送信する（ステップＳ３４０）。具体的には、端末別管理テーブル３７１０のアプリケーション名３７１３が相違度判定部３５００から受け取ったアプリケーション名と同じであるレコードの、携帯端末ＩＤ３７１２で示される携帯端末４０００宛に送信する。
【０２０９】
相違度判定部３５００から確認データを変更しない旨の通知を受けた設定確認処理部３３００は（ステップＳ３３０：Ｎｏ）、確認コマンドを携帯端末４０００に対して、ブロードキャストで送信する（ステップＳ３５０）。
【０２１０】
携帯端末４０００において、通信部４２００を介して新しい確認データ１９１０を受信した制御部１１００は、受信した新しい確認データ１９１０を確認データ処理部４１００に渡して処理を依頼する。
【０２１１】
依頼を受けた確認データ処理部４１００は、渡された新しい確認データ１９１０を報知処理部４５００に渡して、作業メモリに記憶するよう依頼する。
【０２１２】
依頼を受けた報知処理部４５００は、渡された新しい確認データ１９１０を確認データ１９１０として、内部の作業メモリに記憶させる。ここで作業メモリに記憶させた確認データ１９１０は、管理サーバ３０００からリセットコマンドを受信したときに、削除するものとする。
【０２１３】
また、携帯端末４０００において、通信部４２００を介して確認コマンドを受信した制御部１１００は、報知処理を行うよう報知処理部４５００に依頼する。
【０２１４】
依頼を受けた報知処理部４５００は、内部の作業メモリに確認データ１９１０が記憶されている場合は、作業メモリから確認データ１９１０を読み出し、内部の作業メモリに確認データ１９１０が記憶されていない場合は、確認データ記憶部１９００に記憶されている確認データ１９１０を読み出す（図６参照）。
【０２１５】
報知処理部４５００は、作業メモリ又は確認データ記憶部１９００から読み出した確認データ１９１０と、インストールログ記憶部１８００に記憶されている直近に生成されたインストールログとに基づいて、報知処理を行う（ステップＳ４２０）。この報知処理は、図８を用いて説明した実施形態１の設定確認処理のうちのステップＳ１３０〜ステップＳ１６０の処理と同様である。
【０２１６】
各端末装置の報知を視認したキッティング作業者は、その報知に応じて次の作業を行う（ステップＳ５２０）。例えば、インストールに失敗した旨の報知であれば、再インストールを行うなどである。
【０２１７】
次に、相違度判定部３５００が行う相違度判定処理について図１３を用いて説明する。
【０２１８】
図１３は、相違度判定処理を示すフローチャートである。
【０２１９】
設定確認処理部３３００から判定の依頼を受けた相違判定部３５００は、まず、端末別確認データ記憶部３７００に記憶されている端末別管理テーブル３７１０と確認データ管理テーブル２７１０（図４参照）とを参照してアプリケーション間の確認データ１９１０の相違度を求める。
【０２２０】
具体的には、端末別管理テーブル３７１０のアプリケーション名３７１３を検索し、登録されているアプリケーション名が同じであるか否かを判断する。
【０２２１】
登録されているアプリケーション名が全て同じである場合は（ステップＳ６００：Ｎｏ）、それぞれインストールされた日時が所定期間、例えば、７日以上間隔が開いているかを判断する。
【０２２２】
具体的には、端末別管理テーブル３７１０の設定日時３７１４を検索し、登録されている日時に所定期間以上の開きがあるかどうかを判断する。
【０２２３】
所定期間以上の開きがある場合は（ステップＳ６１０：Ｎｏ）、確認データを変更しないと判定する（ステップＳ６５０）。同じアプリケーションのインストールが異なる日になされた場合に、それらの日の間が長ければ点滅間隔も長いことになる。従って、キッティング作業者は、携帯端末１０００の外観から、どの携帯端末１０００が先にキッティングされたのかを判断することができるからである。
【０２２４】
所定期間以上の開きがない場合（ステップＳ６１０：Ｙｅｓ）、又は、携帯端末４０００に異なるアプリケーションがインストールされている場合は（ステップＳ６００：Ｙｅｓ）は、それぞれのアプリケーションの確認データ１９１０同士の相違度を求める（ステップＳ６２０）。
【０２２５】
具体的には、確認データ１９１０の構成要素のうち異なっている構成要素の個数を求める。例えば、アプリケーションがメーラである場合、確認データは確認データ管理テーブル２７１０（図４参照）の確認データ番号１７１１が「１」のレコードで示されるものである。従って、メーラの確認データは、タイプ２７１３が「ＬＥＤ」、動作２７１４が「点滅：パターン１」と「色：青」との３つの構成要素を含むことになる。また、もう一つのアプリケーションがＶＰＮソフトである場合、確認データは確認データ番号１７１１が「２」のレコードで示されるものである。従って、ＶＰＮソフトの確認データは、タイプ２７１３が「ＬＥＤ」、動作２７１４が「点滅：パターン２」、「色：緑」の３つの構成要素を含むことになる。これらメーラとＶＰＮソフト間の確認データの相違度は、３分の２となる。３要素のうちの２要素である点滅パターンと色とが異なるからである。また、タイプ２７１３が「ＬＥＤ」の確認データと「振動」の確認データとは、タイプが異なるので相違度は３分の３となる。
【０２２６】
相違度が所定数、例えば３分の１以下の場合（ステップＳ６３０：Ｙｅｓ）、すなわち、異なっている構成要素が３つの構成要素のうち１又は０個である場合は、インストールされている携帯端末４０００の数がなるべく少ないアプリケーションの確認データを変更すると判断する（ステップＳ６４０）。
【０２２７】
例えば、確認データが３種類あり、確認データ１が「ＬＥＤ、点滅：パターン１、色：青」、確認データ２が「ＬＥＤ、点滅：パターン１、色：黄」、確認データ３が「ＬＥＤ、点滅：パターン１、色：緑」であった場合には、それぞれの確認データ間の相違する構成要素は１であるので、３種類の確認データのうち対応するアプリケーションがインストールされている携帯端末の個数が少ない確認データが変更の対象となる。
【０２２８】
相違度が所定数、例えば３分の１より多い場合（ステップＳ６３０：Ｎｏ）、すなわち、異なっている構成要素が３つの構成要素のうち２又は３個である場合は、確認データを変更しないと判断する（ステップＳ６５０）。
【０２２９】
＜変形例＞
実施形態２では、管理サーバ３０００が携帯端末４０００の報知態様が紛らわしいであろうと思われる場合に、一時的に確認データの変更を一部の携帯端末４０００に指示していた。
【０２３０】
変形例では、携帯端末４０００がインストールログを管理サーバ３０００に送信する際に（図１２のステップ４００参照）、確認データ１９１０で示された報知態様を実行できない旨を通知する。
【０２３１】
例えば、確認データ１９１０が、ＬＥＤを青色に点滅させるという報知態様を示している場合、携帯端末４０００はＬＥＤを青色に点灯させる機能を有していない場合である。
【０２３２】
管理サーバ３０００は、他の携帯端末４０００の報知態様を勘案して、確認データの変更を指示する。
【０２３３】
例えば、ＬＥＤに点灯させる色を変更する、振動させるようにするなどである。
【０２３４】
＜補足＞
以上、本発明の実施形態について説明したが、本発明は上記形態に限らず、以下のようにしてもよい。
（１）実施形態では、インストールの成功又は失敗をキッティングの状態としているが、携帯端末の状態を示すものであれば他の状態であってもよい。例えば、インストールされているアプリケーションのバージョン等であってもよい。また、インストールに限らず、搭載しているメモリサイズ等でもよい。
（２）実施形態では、ＬＥＤランプを点滅させて報知する場合、インストールされてからの経過時間を考慮して点滅間隔を変化させているが、経過時間を考慮して色を変化させてもよく、また、振動等の他の要素を追加してもよい。さらには、経過時間を考慮せずに確認データが占めす報知形態の通りに報知してもよい。
（３）実施形態２では、管理サーバは確認データを、各携帯端末から送信させることで取得している。しかし、キッティング装置から、インストールしたアプリケーションの確認データを取得してもよい。また、予め記憶しておいてもよい。
（４）携帯端末１０００等は、図３等の各構成要素の全部又は一部を、１チップ又は複数チップの集積回路で実現してもよい。
（５）携帯端末１０００等は、図３等の各構成要素の全部又は一部を、コンピュータのプログラムで実現してもよいし、その他どのような形態で実施してもよい。
【０２３５】
コンピュータプログラムの場合、メモリカード、ＣＤ−ＲＯＭなどいかなる記録媒体に書き込まれたものをコンピュータに読み込ませて実行させる形にしてもよいし、ネットワークを経由してプログラムをダウンロードして実行させる形にしてもよい。
【符号の説明】
【０２３６】
１０００ 携帯端末
１１００ ２１００ ３１００ 制御部
１２００ ２２００ ３２００ ４２００ ５２００ 通信部
１３００ 設定処理部
１４００ ＬＥＤランプ
１５００ ４５００ 報知処理部
１６００ 点滅間隔決定部
１７００ ２６００ アプリケーション記憶部
１８００ インストールログ記憶部
１９００ 確認データ記憶部
２０００ キッティング装置
２３００ 操作部
２４００ キッティング処理部
２５００ 確認要求部
２７００ アプリ別確認データ記憶部
３０００ 管理サーバ
３３００ 設定確認処理部
３４００ インストールログ収集部
３５００ 相違度判定部
３６００ 新確認データ生成部
３７００ 端末別確認データ記憶部
４１００ 確認データ処理部
【技術分野】
【０００１】
本発明は、装置に設定されている内容を、装置の外見によって判断することを容易にする技術に関する。
【背景技術】
【０００２】
ノートパソコン、スマートフォン又はＰＤＡ（Personal Digital Assistants）等のモバイル端末は、その使用目的に応じて、アプリケーションを事前にインストール又は各種設定を行っておく必要があるものがある。
【０００３】
モバイル端末を実用段階にまで持っていく為のこのような作業、いわゆる、キッティング作業は、基本的には、１台ずつ行う。例えば、モバイル端末とキッティング作業用の端末をＵＳＢ（Universal Serial Bus）ケーブルで1台ずつ接続して、インストール作業などを行うことが一般的に行われている。
【０００４】
また、こういったキッティング作業は、例えば、顧客に納品するときに、工場出荷時の状態で各端末が同じ状態のものを扱う場合は大きな問題にならないが、引き続き、保守作業を行っていく中で、さまざまな端末を扱っていく途中で、端末によってインストールするアプリや設定が異なる状況が発生する。そうなると、キッティング作業を開始するときに、作業者はこれからキッティング作業を行う端末がどれかを正しく確認してから、作業を行わないと、端末へのアプリインストールや、設定変更の結果が想定した結果を整合しない結果となるおそれがある。
【０００５】
従って、キッティング作業を行う必要があるモバイル端末の台数が数台である場合はよいが、数十台〜数百台のモバイル端末にキッティングを行う必要がある場合は、正しくキッティングが行われたか否かを確かめるのには手間がかかる。
【０００６】
なぜなら、例えば、あるアプリケーションのインストールが成功したか失敗したかを確かめるためには、確認のための操作を一台一台に行う必要があるからである。
【０００７】
そこで、インストールを実行する際に、インストールの各ステップが正常に実行されたか否かを、インストールが実行されている装置が備えるインストールフィードバックライトを作動させることでインストールの状態を知らせる技術が提案されている（特許文献１参照）。
【０００８】
この技術によれば、キッティング作業者は、インストールを行ったモバイル端末のインストールフィードバックライトを見ることにより、インストールが成功したか失敗したかを知ることができる。すなわち、１台１台に確認の操作、例えば、所定のコマンドの入力を行うなどしてインストールが成功しているかを確認する必要が無くなる。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０００−９９４２３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、この技術では、あるアプリケーションのインストールが成功したのか失敗したのかはモバイル端末の外見から知ることはできるが、どのアプリケーションがインストールされたのか等はモバイル端末の外見からは知ることはできない。
【００１１】
数多くのモバイル端末にキッティング作業を行う場合は、モバイル端末によってインストールするアプリケーションが異なる場合も多い。また、キッティングするモバイル端末の数が多ければ、キッティング作業が複数日に及ぶことがあり、この場合、キッティング済みのモバイル端末と未だキッティングされていないモバイル端末とが混在することとなる。
【００１２】
このような場合、モバイル端末のキッティングの状態、例えば、インストールされているアプリケーション等を、モバイル端末の外見から知ることができれば、一台一台手作業で確かめることなくキッティング作業を迅速に行うことができるようになる。
【００１３】
そこで、本発明は、モバイル端末等の装置の様々なキッティングの状態を、モバイル端末の外見から知ることができるようにすることを目的とする。
【課題を解決するための手段】
【００１４】
本発明の１形態に係る設定報知システムの端末装置は、自装置を所定の状態にしようとする毎に、自装置の状態を示す状態情報と報知方法を示す確認情報とを対応付けて記憶する記憶手段と、自装置の状態の報知を要求する指示を、外部から取得する要求取得手段と、自装置の状態を検出する検出手段と、前記要求取得手段で前記指示を取得した場合に、前記検出手段で検出した自装置の状態に応じて、前記確認情報に基づいて報知を行う報知手段と、を有する。
【発明の効果】
【００１５】
上記構成の設定報知システムの端末装置は、装置自身の様々なキッティングの状態を、端末の外見によって知らせることができる。
【図面の簡単な説明】
【００１６】
【図１】実施形態１の状態報知システムの構成例を示す図である。
【図２】携帯端末がキッティングの状態を報知する例を示す図である。
【図３】携帯端末及びキッティング装置の機能的構成の例を示すブロック図である。
【図４】確認データ管理テーブルの構成及び内容の例を示す図である。
【図５】アプリ別管理テーブルの構成及び内容の例を示す図である。
【図６】確認データの構成及び内容の例を示す図である。
【図７】インストールログの構成及び内容の例を示す図である。
【図８】キッティング処理及びキッティング確認処理を示すフローチャートである。
【図９】実施形態２の状態報知システムの構成例を示す図である。
【図１０】管理サーバ、携帯端末及びキッティング装置の機能的構成の例を示すブロック図である。
【図１１】端末別管理テーブルの構成及び内容の例を示す図である。
【図１２】キッティング確認処理を示すフローチャートである。
【図１３】相違度判定処理を示すフローチャートである。
【発明を実施するための形態】
【００１７】
＜実施形態１＞
図１は、実施形態１の状態報知システム１００の構成例を示す図である。
【００１８】
状態報知システム１００は、キッティングの対象である携帯端末１０００Ａ、携帯端末１０００Ｂ、携帯端末１０００Ｃ、携帯端末１０００Ｄ及びキッティング装置２０００を有する。
【００１９】
携帯端末１０００Ａ〜Ｄとキッティング装置２０００とは、無線ＬＡＮ（Local Area Network）やＢｌｕｅｔｏｏｔｈ（登録商標、以下同様）などの無線通信により通信する。
【００２０】
図１では、説明の便宜上、キッティング対象の携帯端末１０００Ａ〜Ｄの４台を記載している。また、携帯端末１０００Ａ〜Ｄは、それぞれ同様の外観と機能とを有する。
【００２１】
以下、携帯端末１０００Ａ〜Ｄは、携帯端末１０００と総称するものとし、携帯端末１０００Ａは携帯端末Ａ、携帯端末１０００Ｂは携帯端末Ｂ、携帯端末１０００Ｃは携帯端末Ｃ、携帯端末１０００Ｄは携帯端末Ｄというものとする。
【００２２】
携帯端末１０００は、携帯電話機、スマートフォン、ＰＤＡ又はノートパソコン等の情報機器であり、パワーインジケータ等として使用されるＬＥＤ（Light Emitting Diode）ランプ１４００を備えている。拡大図１００１Ｂは消灯しているＬＥＤランプ１４００を示し、拡大図１００１Ａは、点灯しているＬＥＤランプ１４００を示す。
【００２３】
状態報知システム１００の携帯端末１０００は、このＬＥＤランプ１４００を用いてキッティングの状態を報知する。
【００２４】
キッティング装置２０００は、各携帯端末１０００にアプリケーションをインストールし、必要な環境設定等を行う装置である。実施形態１では、ノートパソコンとする。
【００２５】
ここで、図２を用いて、状態報知システム１００の携帯端末１０００がキッティングの状態を報知する例を説明する。
【００２６】
３日に分けて、携帯端末Ａ〜Ｄのキッティング作業を行った場合を例に説明する。
【００２７】
図２において、矩形１０は、ＬＥＤランプ１４００が点滅していることを表すものであり、ＬＥＤランプ１４００の様子の遷移を示している。矩形１１は、矩形１０と同様にＬＥＤランプ１４００が点滅していることを表すものであるが、色が異なるＬＥＤランプ１４００の様子の遷移を示している。矩形１０等に示されているＬＥＤランプ１４００の間隔が広いほど、点滅の間隔が長いものとする。
【００２８】
キッティング作業者は、キッティング作業として、４台の携帯端末１０００のうち、３台にメーラ（mailer）をインストールし、１台にＶＰＮ（Virtual Private Network）ソフトをインストールするものとする。
【００２９】
まず、４月１日に、携帯端末Ｃにメーラをインストールし、携帯端末ＤにＶＰＮソフトをインストールした。
【００３０】
次に、４月１５日に、携帯端末Ａと携帯端末Ｂとにメーラをインストールしようとする。この際、どの携帯端末１０００にメーラ又はＶＰＮソフトを４月１日にインストールしたかは、その外観からでは判別がつかない。
【００３１】
そこで、キッティング作業者はキッティング装置２０００を操作して、各携帯端末１０００に対して、どのようなキッティングがなされているかを報知させる確認コマンドを送信する。
【００３２】
確認コマンドを受信した携帯端末Ｃは、メーラがインストールされている旨を示す態様、すなわち青色及び所定の点滅間隔でＬＥＤランプ１４００を点滅させる（矩形１０参照）。
【００３３】
また、確認コマンドを受信した携帯端末Ｄは、ＶＰＮソフトがインストールされている旨を示す態様、すなわち緑色及び所定の点滅間隔でＬＥＤランプ１４００を点滅させる（矩形１１参照）。
【００３４】
このＬＥＤランプの点滅を視認することで、キッティング作業者は、携帯端末Ａ及び携帯端末Ｂには、まだアプリケーションがインストールされていないことがわかるので、携帯端末Ａ及び携帯端末Ｂにメーラをインストールする。
【００３５】
次に、４月１日にインストールしたメーラ及びＶＰＮソフトのバージョンを変更するする必要が生じ、５月１日にその変更を行うものとする。
【００３６】
この場合、キッティング作業者はキッティング装置２０００を操作して、各端末装置１０００に対して確認コマンドを送信する。
【００３７】
携帯端末Ａ、Ｂは、メーラがインストールされている旨を示す態様、すなわち青色及び所定の点滅間隔でＬＥＤランプ１４００を点滅させる（矩形１２参照）。
【００３８】
携帯端末Ｃも、メーラがインストールされている旨を示す態様、すなわち青色でＬＥＤランプ１４００を点滅させる。ただし、その点滅の間隔は携帯端末ＡのＬＥＤランプ１４００の点滅間隔より長い間隔で点滅する（矩形１３参照）。
【００３９】
点滅間隔は、携帯端末１０００にアプリケーションがインストールされたときから確認コマンドを受信したときまでの時間に応じて決められ、その時間が長いほど点滅間隔は長くなる。
【００４０】
携帯端末Ｄも、ＶＰＮソフトがインストールされている旨を示す態様、すなわち緑色でＬＥＤランプ１４００を点滅させる。その点滅の間隔は携帯端末Ｃと同じ間隔である。
【００４１】
キッティング作業者は、長い間隔でＬＥＤランプ１４００が青色で点滅している携帯端末Ｃに、新しいバージョンのメーラをインストールする。また、長い間隔でＬＥＤランプ１４００が緑色で点滅している携帯端末Ｄに、新しいバージョンのＶＰＮソフトをインストールする。
【００４２】
すなわち、状態報知システム１００の携帯端末１０００は、ＬＥＤランプ１４００を用いて、インストールされたアプリケーションがなんであるかを示すだけでなく、携帯端末１０００にアプリケーションがいつごろインストールされたかを示すことができる。
【００４３】
このように、携帯端末１０００は、インストールされているアプリケーションとそのインストール時期とをＬＥＤランプ１４００を点滅させることによって報知することで、キッティング作業者に、携帯端末１０００の外観によってキッティングの状態を知らせることができる。従って、キッティング作業者は、一台ずつキッティングの状態を調べることなく次に行うべき作業、例えば、バージョンアップを行う又は各種設定等を行うなどの作業を速やかに実行することができる。
【００４４】
図では、インストールに成功してインストールされている場合を説明したが、インストールに失敗している場合は、例えば、赤色でＬＥＤランプ１４００を点滅させるものとしてもよい。キッティング作業者は、インストールに失敗した携帯端末１０００、すなわち、ＬＥＤランプ１４００が赤色で点滅している携帯端末１０００を即座に知ることができ、その携帯端末１０００にインストールすべきアプリケーションをインストールすることができる。
【００４５】
以下、状態報知システム１００について図を用いて説明する。
【００４６】
＜機能＞
図３は、携帯端末１０００及びキッティング装置２０００の機能的構成の例を示すブロック図である。
【００４７】
携帯端末１０００は、制御部１１００、通信部１２００、設定処理部１３００、ＬＥＤランプ１４００、報知処理部１５００、点滅間隔決定部１６００、アプリケーション記憶部１７００、インストールログ記憶部１８００及び確認データ記憶部１９００を有する。
【００４８】
制御部１１００は、端末装置１０００が基本的に有している機能、例えば、携帯端末１０００が携帯電話機であれば通話機能などの機能のほか、状態報知システム１００の携帯端末として他の機能部を制御する機能等を有する。
【００４９】
通信部１２００は、キッティング装置２０００と無線で通信を行う機能を有する。
【００５０】
設定処理部１３００は、キッティング装置２０００から受信したアプリケーション及び確認データ等を自装置である携帯端末１０００にキッティングする機能を有する。詳細には、キッティング装置２０００から、インストールしようとするアプリケーションのインストーラを受信し、受信したインストーラを起動する。起動されたインストーラは、アプリケーションの実行ファイル及びアプリケーションで使用するデータ等をキッティング装置２０００から受信してアプリケーション記憶部１７００に記憶させ、必要な設定等を行う。また、キッティング装置２０００から受信した確認データを確認データ記憶部１９００に記憶させる。
【００５１】
ＬＥＤランプ１４００は、半導体素子を用いたランプである。
【００５２】
報知処理部１５００は、キッティングの状態を報知する処理を行う機能を有する。具体的には、確認データ記憶部１９００に記憶されている確認データに基づいて報知する。例えば、確認データで示される報知方法がＬＥＤを用いる方法である場合は、確認データで示されている色と、アプリケーションがインストールされたときから報知するときまでの経過時間に応じた点滅間隔とでＬＥＤランプ１４００を点滅させる。
【００５３】
点滅間隔決定部１６００は、報知処理部１５００から依頼を受け、ＬＥＤランプ１４００の点滅間隔を求める機能を有する。具体的には、インストールログを参照して取得したインストールされたときから依頼を受けたときまでの経過時間を求め、経過時間を基に点滅間隔を求める。
【００５４】
例えば、点滅間隔の初期値が５００ｍｓｅｃ（ミリ秒）であり、インストールされたときから１日経過するごとに１００ｍｓｅｃ長くなる等である。３０日経過したときの点滅間隔は、５００（ｍｓｅｃ）＋１００（ｍｓｅｃ）＊３０（日）＝３５００（ｍｓｅｃ）となる。
【００５５】
アプリケーション記憶部１７００は、インストールされたアプリケーションの実行ファイル及びアプリケーションが使用するデータ等を記憶しておく機能を有する。
【００５６】
インストールログ記憶部１８００は、携帯端末１０００にインストールされたアプリケーションのインストールのログを記憶しておく機能を有する。アプリケーションがインストールされる毎に１つのインストールログが追加される。
【００５７】
確認データ記憶部１９００は、インストールされたアプリケーションと対応付けられた確認データを記憶しておく機能を有する。確認データは、アプリケーションの種類毎に異なる。また、この確認データ記憶部１９００には、直近にインストールの処理がなされたアプリケーションの確認データのみが記憶されている。
【００５８】
次に、キッティング装置２０００は、制御部２１００、通信部２２００、操作部２３００、キッティング処理部２４００、確認要求部２５００、アプリケーション記憶部２６００及びアプリ別確認データ記憶部２７００を有する。
【００５９】
制御部２１００は、いわゆるノートパソコンであるキッティング装置２０００に必要な一般的なパソコンの機能のほか、状態報知システム１００のキッティング装置として他の機能部を制御する機能等を有する。
【００６０】
通信部２２００は、携帯端末１０００と無線で通信を行う機能を有する。実施形態１では、携帯端末１０００にアプリケーションをインストールする場合及び各種設定をする場合は、無線ＬＡＮで携帯端末１０００と接続して通信を行う。また、確認コマンドを送信する場合は、無線で送信するものとする。
【００６１】
操作部２３００は、テンキー等を含み、ユーザからの操作、例えば、キーの押下等を検出する機能を有する。
【００６２】
キッティング処理部２４００は、アプリケーションを携帯端末１０００にインストール等する機能を有する。実施形態１では、インストールするアプリケーションのインストーラ、アプリケーションの実行ファイル、アプリケーションが使用するデータ及びアプリケーションに対応した確認データを、通信部２２００を介して携帯端末１０００に送信する機能を有する。
【００６３】
確認要求部２５００は、確認コマンドを生成して、携帯端末１０００に対して送信する機能を有する。
【００６４】
アプリケーション記憶部２６００は、各種アプリケーションの実行ファイル、各アプリケーションが使用するデータ、各アプリケーションのインストーラ等を記憶しておく機能を有する。
【００６５】
アプリ別確認データ記憶部２７００は、アプリケーション記憶部２６００に記憶されているアプリケーション毎の確認データを記憶しておく機能を有する。
【００６６】
上述した機能の全部または一部は、携帯端末１０００及びキッティング装置２０００の有するそれぞれのＣＰＵが、携帯端末１０００及びキッティング装置２０００それぞれのメモリ等に記録されているプログラムを実行することにより実現される。
【００６７】
＜データ＞
次に、状態報知システム１００で用いるデータについて図４〜図７を用いて説明する。
【００６８】
図４は、確認データ管理テーブル２７１０の構成及び内容の例を示す図であり、図５は、アプリ別管理テーブル２７２０の構成及び内容の例を示す図である。
【００６９】
この確認データ管理テーブル２７１０及びアプリ別管理テーブル２７２０は、キッティング作業者によって、予め、キッティング装置２０００のアプリ別確認データ記憶部２７００に記憶されているものである。
【００７０】
確認データ管理テーブル２７１０は、確認データ番号２７１１、状態２７１２、タイプ２７１３及び動作２７１４を有する。
【００７１】
確認データ番号２７１１は、確認データ管理テーブル２７１０に登録されている確認データの番号を示す。
【００７２】
状態２７１２は、アプリケーションの状態、すなわち、アプリケーションのインストールが成功して正しくインストールされた状態又はインストールが失敗して正しくインストールされていない状態のいずれの状態であるかを示す。「成功」は、インストールに成功したことを示し、「失敗」はインスロールが成功しなかったことを示す。
【００７３】
タイプ２７１３は、報知のタイプ、言い換えれば、報知に用いる機器を示す。具体的には、「ＬＥＤ」はＬＥＤランプ１４００を用いることを示し、「振動」は端末装置１０００が備えるバイブレータを用いることを示し、「音」は携帯端末１０００が備える発音機を用いることを示す。
【００７４】
動作２７１４は、タイプ２７１３で示す機器をどのような動作をさせるのかを示す。
【００７５】
タイプ２７１３が「ＬＥＤ」の場合は、色と点滅のパターンとを示す。パターンは点滅のリズム等を示す。タイプ２７１３が「振動」の場合は、振動のパターンと強さとを示す。また、タイプ２７１３が「音」の場合は、メロディと強さとを示す。
【００７６】
例えば、確認データ番号２７１１が「４」の確認データでは、インストールに失敗していた場合は、パターン１で示されるリズムで中程度の強さで振動し、且つ、サウンド１が中程度の強さで鳴ることになる。
【００７７】
次に、アプリ別管理テーブル２７２０は、登録番号２７２１、アプリケーション名２７２２及び確認データ番号２７２３を有する。このアプリ別管理テーブル２７２０は、アプリケーションと確認データとの対応付けを行うものである。
【００７８】
登録番号２７２１は、アプリ別管理テーブル２７２０に登録されているアプリケーションの登録番号を示す。
【００７９】
アプリケーション名２７２２は、キッティング装置２０００がインストールを行うことができるアプリケーションの名称を示す。
【００８０】
確認データ番号２７２３は、確認データ管理テーブル２７１０の確認データ番号２７１１で示される確認データの番号を示す。
【００８１】
キッティング装置２０００は、例えば、メーラを携帯端末１０００にインストールする場合は、アプリ別管理テーブル２７２０のアプリケーション名２７２２が「メーラ」のレコードの確認データ番号２７２３の番号を読み出す。次に、確認データ管理テーブル２７１０の確認データ番号２７１１が読み出した番号と同じであるレコードの状態２７１２、タイプ２７１３及び動作２７１４を読み出して、メーラの確認データとして端末装置１０００に送信する。
【００８２】
次に、図６及び図７を用いて説明するデータは、携帯端末１０００に記憶されているデータである。
【００８３】
図６は、確認データ記憶部１９００に記憶されている確認データ１９１０の構成及び内容の例を示す図である。
【００８４】
図６において、確認データ１９１０Ａは携帯端末Ａの確認データ記憶部１９００に記憶されている確認データ１９１０を示し、確認データ１９１０Ｄは携帯端末Ｄの確認データ記憶部１９００に記憶されている確認データ１９１０を示す。また、確認データ１９１０Ｘは携帯端末Ｘの確認データ記憶部１９００に記憶されている確認データ１９１０を示す。
【００８５】
キッティング装置２０００は、インストールするアプリケーションの確認データを確認データ管理テーブル２７１０から読み出して、確認データ１９１０の形式にして端末装置１０００に送信する。
【００８６】
確認データ１９１０は、「Ｎｕｍ」、「Ｓｔａｔｕｓ」、「Ｔｙｐｅ」及び「Ａｃｔｉｏｎ」で構成される。尚、「Ａｃｔｉｏｎ」に続いて、「Ｔｙｐｅ」で指定された機器に行わせる動作の詳細が必要に応じて更に指定される。
【００８７】
「Ｎｕｍ」は、確認データの番号を示す。この番号は、確認データ管理テーブル２７１０の確認データ番号２７１１に該当する。
【００８８】
「Ｓｔａｔｕｓ」は、アプリケーションの状態、すなわち、アプリケーションのインストールが成功して正しくインストールされた状態又はインストールが失敗して正しくインストールされていない状態のいずれの状態であるかを示す。確認データ管理テーブル２７１０の状態２７１２に該当する。
【００８９】
「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」は、インストールが成功した状態であることを示し、「Ｓｔａｔｕｓ＝Ｆａｉｌｕｒｅ」は失敗した状態であることを示す。
【００９０】
「Ｔｙｐｅ」は、報知に用いる機器を示す。確認データ管理テーブル２７１０のタイプ２７１３に該当する。
【００９１】
「Ａｃｔｉｏｎ」は、「Ｔｙｐｅ」で示す機器をどのような動作をさせるのかを示す。確認データ管理テーブル２７１０の動作２７１４に該当する。
【００９２】
例えば、確認データ１９１０Ａは、携帯端末Ａにインストールされたメーラの確認データ１９１０を示したものである。
【００９３】
メーラの確認データは、確認データ管理テーブル２７１０の確認データ番号２７１１が「１」のレコードであるので、確認データ１９１０Ａには「Ｎｕｍ＝１」と記載されている。確認データ管理テーブル２７１０の状態２７１２が「成功」であるので、「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」と記載され、確認データ管理テーブル２７１０のタイプ２７１３が「ＬＥＤ」であるので、「Ｔｙｐｅ＝ＬＥＤ」と記載され、確認データ管理テーブル２７１０の動作２７１４が「点滅：パターン１、色：青」であるので、「Ａｃｔｉｏｎ＝Ｂｌｉｎｋ１，Ｃｏｌｏｒ＝Ｂｌｕｅ」と記載されている。
【００９４】
また、確認データ１９１０Ｄは、携帯端末ＤにインストールされたＶＰＮソフトの確認データ１９１０を示したものである。ＶＰＮソフトの確認データは、確認データ管理テーブル２７１０の確認データ番号２７１１が「２」のレコードであるので、「Ｎｕｍ＝２」と記載される。確認データ管理テーブル２７１０の状態２７１２が「成功」であるので、「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」と記載され、確認データ管理テーブル２７１０のタイプ２７１３が「ＬＥＤ」であるので、「Ｔｙｐｅ＝ＬＥＤ」と記載され、確認データ管理テーブル２７１０の動作２７１４が「点滅：パターン２、色：緑」であるので、確認データ１９１０Ｄには「Ａｃｔｉｏｎ＝Ｂｌｉｎｋ２，Ｃｏｌｏｒ＝Ｇｒｅｅｎ」と記載されている。
【００９５】
また、確認データ１９１０Ｘは、確認データ番号２７１１が「３」のレコードの確認データ１９１０を示したものである。
【００９６】
確認データ１９１０Ｘの１行目に、確認データ番号２７１１が「３」であるので、「Ｎｕｍ＝３」と記載されている。確認データ管理テーブル２７１０の状態２７１２の１段目が「成功」であるので、「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」と記載され、確認データ管理テーブル２７１０のタイプ２７１３の１段目が「ＬＥＤ」であるので、「Ｔｙｐｅ＝ＬＥＤ」と記載され、確認データ管理テーブル２７１０の動作２７１４の１段目が「点滅：パターン１、色：橙」であるので、「Ａｃｔｉｏｎ＝Ｂｌｉｎｋ１，Ｃｏｌｏｒ＝Ｏｒａｎｇｅ」と記載されている。
【００９７】
また、２行目に、確認データ番号２７１１が「３」であるので、確認データ１９１０Ｄには「Ｎｕｍ＝３」と記載されている。確認データ管理テーブル２７１０の状態２７１２の２段目が「失敗」であるので、「Ｓｔａｔｕｓ＝Ｆａｉｌｕｒｅ」と記載され、確認データ管理テーブル２７１０のタイプ２７１３の２段目が「振動」であるので、「Ｔｙｐｅ＝Ｖｉｂｒａｔｅｒ」と記載され、確認データ管理テーブル２７１０の動作２７１４の２段目が「振動：パターン１、強さ：中」であるので、「Ａｃｔｉｏｎ＝Ｐａｔｔｅｒｎ１,Ｓｔｒｅｎｇｔｈ＝Ｍｉｄｄｌｅ」と記載されている。
【００９８】
図７は、インストールログ記憶部１８００に記憶されているインストールログの構成及び内容の例を示す図である。
【００９９】
図７において、インストールログ１８１０Ａは携帯端末Ａのインストールログ記憶部１８００に記憶されているインストールログ１８１０を示し、インストールログ１８１０Ｄは携帯端末Ｄのインストールログ記憶部１８００に記憶されているインストールログ１８１０を示す。
【０１００】
インストールログ１８１０は、作成日時、「Ａｐｌ」、「Ｓｔａｔｕｓ」、「Ｎｕｍ」及び「ＩＤ」を含む。
【０１０１】
作成日時は、インストールログ１８１０が作成された日時を示す。
【０１０２】
「Ａｐｌ」は、インストールされたアプリケーションを示す。
【０１０３】
「Ｓｔａｔｕｓ」は、アプリケーションのインストールが成功して正しくインストールされた状態又はインストールが失敗して正しくインストールされていない状態のいずれの状態であるかを示す。「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」は、インストールが成功した状態であることを示し、「Ｓｔａｔｕｓ＝Ｆａｉｌｕｒｅ」は失敗した状態であることを示す。
【０１０４】
「Ｎｕｍ」は、確認データの番号を示す。
【０１０５】
「ＩＤ」は、キッティング作業者の識別子を示す。
【０１０６】
例えば、インストールログ１８１０Ａは、携帯端末Ａにインストールされたメーラのインストールログ１８１０を示したものである。メーラの確認データは、確認データ管理テーブル２７１０の確認データ番号２７１１が「１」のレコードである。
【０１０７】
従って、インストールログ１８１０Ａでは、「２００９／０５／０２ １１：２１：４５」、すなわち、２００９年５月２日の１１時２１分４５秒にインストールログ１８１０Ａが生成され、「Ａｐｌ＝Ｍａｉｌｅｒ」、すなわち、メーラがインストールされ、「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」、すなわち、インストールは成功し、「Ｎｕｍ＝１」、すなわち、確認データの番号は「１」であり、「ＩＤ＝Ｔａｎａｋａ」、すなわち、作業者が「Ｔａｎａｋａ」であることが、記録されている。
【０１０８】
同様に、インストールログ１８１０Ｄでは、「２００９／０５／０１ １５：３２：０９」、すなわち、２００９年５月１日の１５時３２分９秒にインストールログ１８１０Ｂが生成され、「Ａｐｌ＝ＶＰＮ」、すなわち、ＶＰＮソフトがインストールされ、「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」、すなわち、インストールは成功し、「Ｎｕｍ＝２」、すなわち、確認データの番号は「２」であり、「ＩＤ＝Ｔａｎａｋａ」、すなわち、作業者が「Ｔａｎａｋａ」であることが、記録されている。
【０１０９】
＜動作＞
以下、実施形態１の状態報知システム１００の動作について図８を用いて説明する。
【０１１０】
図８は、状態報知システム１００のキッティング処理及びキッティング確認処理を示すフローチャートである。
【０１１１】
キッティング装置２０００を使用してキッティング作業者が携帯端末１０００にアプリケーションをインストールするキッティング処理と、そのインストール状態を確認するキッティング確認処理とを説明する。キッティング処理は、図８のステップＳ１００〜ステップＳ１２０及びステップＳ２００とで示される処理である。また、キッティング確認処理は、ステップＳ１３０〜ステップＳ１６０、ステップＳ２１０及びステップＳ２２０で示される処理である。
【０１１２】
キッティング作業者は、キッティング装置２０００と携帯端末１０００とを無線ＬＡＮで接続し、必要に応じて、携帯端末１０００での操作、例えば、新しいアプリケーションのインストールを可能とするモードにする等の操作を行う。
【０１１３】
次に、キッティング作業者は、キッティング装置２０００においてアプリケーション名を指定してインストールを指示する操作を行う。この際、キッティング作業者自身の識別子も入力する。
【０１１４】
キッティング装置２０００の操作部２３００は、キッティング作業者による操作を検出すると検出した操作を制御部２１００に通知する。
【０１１５】
通知を受けた制御部２１００は、その操作からアプリケーションをインストールする指示であることを判断し、キッティング処理部２４００にインストールを指示する。その際、キッティング作業者により指定されたアプリケーション名とキッティング作業者の識別子とを渡す。
【０１１６】
指示を受けたキッティング処理部２４００は、まず、渡されたアプリケーション名のアプリケーションのインストーラをアプリケーション記憶部２６００から読み出す。読み出したインストーラとキッティング作業者の識別子とを、通信部２２００を介して携帯端末１０００に送信する。
【０１１７】
その後、キッティング処理部２４００は、アプリ別確認データ記憶部２７００からアプリケーションの確認データを読み出して、インストーラからの要求に応じて送信する。例えば、ユーザにより指定されたアプリケーション名が「メーラ」である場合、キッティング処理部２４００は、アプリ別確認データ記憶部２７００に記憶されているアプリ別管理テーブル２７２０のアプリケーション名２７２２が「メーラ」であるレコードを検索する。検索されたレコードの確認データ番号２７２３の番号を読み出す。次に確認データ管理テーブル２７１０の確認データ番号２７１１が読み出した番号と同じレコードを検索し、検索されたレコードの状態２７１２、タイプ２７１３及び動作２７１４を読み出して、確認データ１９１０（図６参照）を作成して携帯端末１０００に送信する。
【０１１８】
また、インストーラからの要求に応じて、キッティング処理部２４００は、アプリケーション記憶部２６００からアプリケーションの実行ファイル及びアプリケーションが使用するデータ等を読み出して送信する。（ステップＳ２００）。
【０１１９】
一方、携帯端末１０００において、通信部１２００を介してインストーラとキッティング作業者の識別子とを受信した制御部１１００は、受信したインストーラとキッティング作業者の識別子とを設定処理部１３００に渡す。
【０１２０】
設定処理部１３００は、作業メモリにインストーラを展開し、インストーラを起動する。
【０１２１】
起動されたインストーラは、アプリケーションの確認データ１９１０を要求して受信し、設定処理部１３００に渡す。設定処理部１３００は、渡された確認データ１９１０を確認データ記憶部１９００に記憶させる（ステップＳ１００）。
【０１２２】
その後、インストーラは、いわゆるインストールの処理、すなわち、アプリケーションの実行ファイル及びアプリケーションが使用するデータ等をキッティング装置２０００に要求して受信し、アプリケーション記憶部１７００に記憶させ、必要な設定等の処理を行う（ステップＳ１１０）。その後、インストーラは、アプリケーションのインストールの結果、すなわち、インストールが成功したのか失敗したのかを、設定処理部１３００に通知する。
【０１２３】
通知を受けた設定処理部１３００は、通知されたインストールの結果に応じて、インストールログ１８１０を生成する。
【０１２４】
具体的には、設定処理部１３００は、携帯端末１０００に内蔵されているタイマから日時を取得し、インストーラからアプリケーション名を取得する。設定処理部１３００は、取得した日時、アプリケーション名、インストール結果、確認データ１９１０に含まれている確認データの番号及び制御部１１００から渡されたキッティング作業者の識別子とから、インストールログ１８１０を生成する。
【０１２５】
インストールログ１８１０を生成した設定処理部１３００は、生成したインストールログをインストールログ記憶部１８００に記憶させる（ステップＳ１２０）。
【０１２６】
次に、キッティング作業者は、キッティング装置２０００において確認コマンドを送信する操作を行う。
【０１２７】
キッティング装置２０００の操作部２３００は、キッティング作業者による操作を検出すると検出した操作を制御部２１００に通知する。
【０１２８】
通知を受けた制御部２１００は、その操作から確認コマンドを送信する指示であると判断し、確認コマンドを送信するよう確認要求部２５００に指示する。
【０１２９】
指示を受けた確認要求部２５００は、通信部２２００を介して、確認コマンドをブロードキャストで送信する（ステップＳ２１０）。この送信は、無線ＬＡＮによって行う。
【０１３０】
携帯端末１０００において、通信部１２００を介して確認コマンドを受信した制御部１１００は、報知処理を行うよう報知処理部１５００に依頼する。
【０１３１】
依頼を受けた報知処理部１５００は、まず、確認データ記憶部１９００に記憶されている確認データ１９１０を読み出し（図６参照）、「Ａｃｔｉｏｎ」に応じた点滅間隔の初期値を求める。具体的には、「Ａｃｔｉｏｎ＝Ｂｌｉｎｋ１」であれば５００ｍｓｅｃ（ミリ秒）、「Ａｃｔｉｏｎ＝Ｂｌｉｎｋ２」であれば２５０ｍｓｅｃ（ミリ秒）を点滅間隔の初期値として求める。点滅間隔の初期値は、予め点滅のパターンによって決められているものとする。
【０１３２】
点滅間隔の初期値を求めた報知処理部１５００は、求めた初期値を点滅間隔決定部１６００に渡して点滅間隔の決定を依頼する。
【０１３３】
依頼を受けた点滅間隔決定部１６００は、インストールログ記憶部１８００に記憶されているインストールログのうち、最新に生成されたインストールログを読み出す（ステップＳ１３０）。
【０１３４】
例えば、図７のインストールログ１８１０Ａの作成日時「２００９／０５／０２ １１：２１：４５」が、インストールログ記憶部１８００に記憶されているインストールログのうち最も新しい場合は、このインストールログ１８１０Ａを読み出す。
【０１３５】
次に、点滅間隔決定部１６００は、携帯端末１０００に内蔵されているタイマから現在の日時を取得する。取得した日時からこのインストールログの中の作成日時までの、時間が単位の経過時間を求める（ステップＳ１４０）。
【０１３６】
点滅間隔決定部１６００は、求めた経過時間を日にちに換算して経過日数を求める。具体的には、経過時間を２４時間で割った商を経過日数として求める。
【０１３７】
求めた経過日数に一日当たりの点滅間隔、例えば、１００ｍｓｅｃ（ミリ秒）を掛けた値を、報知処理部１５００から渡された初期値に加算して新しい点滅間隔を求める（ステップＳ１５０）。
【０１３８】
新しい点滅間隔を求めた点滅間隔決定部１６００は、求めた新しい点滅間隔を報知処理部１５００に渡す。
【０１３９】
新しい点滅間隔を渡された報知処理部１５００は、読み出したインストールログ１８１０の「Ｓｔａｔｕｓ」が、読み出した確認データ１９１０の「Ｓｔｓｔｕｓ」と同じである場合は、確認データ記憶部１９００から読み出した確認データ１９１０に基づいて、点滅間隔を新しい点滅間隔とするよう制御して、報知をＬＥＤランプ１４００を点滅させる。
【０１４０】
例えば、インストールログ１８１０Ａ（図７参照）の「Ｓｔａｔｕｓ」が「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」であり、確認データ１９１０Ａ（図６参照）の「Ｓｔａｔｕｓ」が「Ｓｔａｔｕｓ＝Ｓｕｃｃｅｓｓ」である場合には、確認データ１９１０Ａに従って、ＬＥＤランプ１４００を青色で新しい点滅間隔で点滅させる。尚、インストールログ１８１０の「Ｓｔａｔｕｓ」が「Ｓｔａｔｕｓ＝Ｆａｉｌｕｒｅ」であり、確認データ１９１０に「Ｓｔａｔｕｓ」が「Ｓｔａｔｕｓ＝Ｆａｉｌｕｒｅ」の行がある場合（図６の確認データ１９１０Ｘ参照）には、確認データ１９１０に従って中程度の強度で振動させる。
【０１４１】
読み出したインストールログ１８１０の「Ｓｔａｔｕｓ」と、読み出した確認データ１９１０の「Ｓｔｓｔｕｓ」とが同じである行が確認データ１９１０にない場合は、報知は行わない。
【０１４２】
各端末装置の報知を目視したキッティング作業者は、その報知に応じて次の作業を行う（ステップＳ２２０）。例えば、インストールに失敗した旨の報知であれば、再インストールを行うなどである。
＜実施形態２＞
実施形態１では、アプリケーションと対応付けた確認データ１９１０に応じて報知を行った。実施形態２では、基本的には、実施形態１と同様にアプリケーションと対応付けた確認データ１９１０に応じて報知を行う。しかし、インストールされているアプリケーションによっては報知の態様が相互に似通ってしまい、携帯端末の外観のみではキッティング状態、例えば、インストールされているアプリケーションの種類やインストール時期等を確認するのが難しい場合等が生じ得る。
【０１４３】
例えば、２種類のアプリケーションがそれぞれ別の携帯端末１０００にインストールされた場合に、これらのアプリケーションに対応付けられている確認データ１９１０で示される報知態様が似通っている場合、例えば、ランプの色が同じで、点滅のパターンが似通っている場合があり得る。
【０１４４】
この場合、携帯端末１０００がＬＥＤランプを点滅させて報知したとしても、ランプの色が同じで、点滅のパターンの差がほとんどないことになる。従って、携帯端末１０００のＬＥＤランプの点滅の態様からは、どちらのアプリケーションがインストールされているのかキッティング作業者が判断するのは難しい。
【０１４５】
また、例えば、同じアプリケーションが複数台の携帯端末１０００にそれぞれ異なる日にインストールされた場合に、点滅間隔の差があまり出ない場合があり得る。インストールされた日が携帯端末１０００同士で近い場合である。
【０１４６】
この場合、携帯端末１０００がＬＥＤランプを点滅させて報知したとしても、アプリケーションが同じであるのでランプの色が同じであり、点滅の間隔の差がほとんどないことになる。従って、携帯端末１０００のＬＥＤランプの点滅の態様からは、アプリケーションを先にインストールした携帯端末１０００がどれなのかをキッティング作業者が判断するのは難しい。
【０１４７】
そこで、実施形態２は、報知の態様を動的に変更することで、キッティング作業者の確認を容易にするものである。この際、キッティング作業者に対して、どのように報知態様を変更したのかも通知するものとする。
【０１４８】
図９は、実施形態２の状態報知システム２００の構成例を示す図である。
【０１４９】
状態報知システム２００は、キッティングの対象である携帯端末４０００Ａ〜Ｄ、キッティング装置５０００及び管理サーバ３０００を有する。
【０１５０】
携帯端末４０００Ａ〜Ｄ、管理サーバ３０００及びキッティング装置５０００とは、お互い無線ＬＡＮ（Local Area Network）やＢｌｕｅｔｏｏｔｈなどの無線通信により通信できるものとする。
【０１５１】
尚、実施形態２では、キッティング装置５０００は、無線ＬＡＮを介して携帯端末４０００Ａ〜Ｄにキッティング処理を行う。また、管理サーバ３０００は、携帯端末４０００Ａ〜Ｄ及びキッティング装置５０００と無線ＬＡＮ（Local Area Network）により通信する。
【０１５２】
実施形態２では、管理サーバ３０００が報知の態様の相違度を判断して、携帯端末４０００に対して報知の態様の変更を行う。
【０１５３】
携帯端末４０００Ａ〜Ｄは、携帯端末４０００と総称するものとし、以下、携帯端末４０００Ａは携帯端末Ａ、携帯端末４０００Ｂは携帯端末Ｂ、携帯端末４０００Ｃは携帯端末Ｃ、携帯端末４０００Ｄは携帯端末Ｄというものとする。
【０１５４】
携帯端末４０００は、基本的には、実施形態１で説明した携帯端末１０００とほぼ同様の機能を有する。また、キッティング装置５０００も、基本的には、実施形態１で説明したキッティング装置２０００とほぼ同様の機能を有する。相違点は、以下の＜機能＞の項で説明する。
【０１５５】
＜機能＞
図１０は、管理サーバ３０００、携帯端末４０００及びキッティング装置５０００の機能的構成の例を示すブロック図である。
【０１５６】
管理サーバ３０００は、制御部３１００、通信部３２００、設定確認処理部３３００、インストールログ収集部３４００、相違度判定部３５００、新確認データ生成部３６００及び端末別確認データ記憶部３７００を有する。
【０１５７】
制御部３１００は、管理サーバ３０００が基本的に有している機能、例えば、サーバ装置としてのメモリ管理機能などの機能のほか、状態報知システム２００の管理サーバとして他の機能部を制御する機能等を有する。
【０１５８】
通信部３２００は、キッティング装置５０００又は携帯端末４０００と、無線で通信する機能を有する。
【０１５９】
設定確認処理部３３００は、キッティング装置５０００から確認コマンドを受信した際に、キッティングの状態を確認するための処理、例えば、確認コマンドを携帯端末４０００に送信する等の処理を行う機能を有する。
【０１６０】
インストールログ収集部３４００は、各携帯端末４０００が記憶しているインストールログ１８１０を収集する機能を有する。実施形態２では、インストールログを収集するが、携帯端末４０００が報知したとした場合の報知態様を求めることができる情報であればよい。報知態様を求めることができる情報とは、具体的には、確認データ１９１０及び点滅間隔である。従って、実施形態２では、アプリケーション名及びログの生成日時を含むインストールログ１８１０を収集するものとする。
【０１６１】
相違度判定部３５００は、確認データに基づいて報知した場合に、報知態様の相違度を判断する機能を有する。実施形態２では、確認データの構成要件のうち、同じ内容の要件がいくつあるかで判断する。
【０１６２】
また、相違度判定部３５００は、判断した相違度に基づいて確認データを変更する必要の有無及びどの確認データ１９１０を変更するのかを判断する機能を有する。
【０１６３】
新確認データ生成部３６００は、新しい確認データを生成する機能を有する。
【０１６４】
端末別確認データ記憶部３７００は、インストールログ収集部３４００が収集した携帯端末毎のインストールログを記憶しておく機能を有する。また、更に、アプリ別管理テーブル２７２０（図５参照）及び確認データ管理テーブル２７１０（図４参照）を記憶しておく機能を有する。
【０１６５】
携帯端末４０００は、制御部１１００、通信部４２００、設定処理部１３００、ＬＥＤランプ１４００、報知処理部４５００、アプリケーション記憶部１７００、インストールログ記憶部１８００、確認データ記憶部１９００及び確認データ処理部４１００を有する。
【０１６６】
制御部１１００、設定処理部１３００、ＬＥＤランプ１４００、報知処理部１５００、アプリケーション記憶部１７００、インストールログ記憶部１８００、確認データ記憶部１９００は、実施形態１で説明した携帯端末１０００（図３参照）の設定処理部１３００、ＬＥＤランプ１４００、アプリケーション記憶部１７００、インストールログ記憶部１８００、確認データ記憶部１９００と同様の機能を有する。
【０１６７】
通信部４２００は、キッティング装置５０００又は管理サーバ３０００と通信する機能を有する。
【０１６８】
確認データ処理部４１００は、インストールログ記憶部１８００に記憶しているインストールログ１８１０を読み出して管理サーバ３０００に送信する機能を有する。また、確認データ処理部４１００は、管理サーバ３０００から新しい確認データ１９１０を受信し、報知処理部４５００に通知する機能を有する。
【０１６９】
報知処理部４５００は、キッティングの状態を確認するための処理を行う機能を有する。具体的には、確認データ記憶部１９００に記憶されている確認データ１９１０又は確認データ処理部４１００から渡された新しい確認データ１９１０に基づいて報知の処理を行う。
【０１７０】
次に、キッティング装置５０００は、制御部２１００、通信部５２００、操作部２３００、キッティング処理部２４００、確認要求部２５００、アプリケーション記憶部２６００及びアプリ別確認データ記憶部２７００を有する。
【０１７１】
制御部２１００、操作部２３００、キッティング処理部２４００、確認要求部２５００、アプリケーション記憶部２６００及びアプリ別確認データ記憶部２７００は、実施形態１で説明したキッティング装置２０００（図３参照）の制御部２１００、通信部５２００、操作部２３００、キッティング処理部２４００、確認要求部２５００、アプリケーション記憶部２６００及びアプリ別確認データ記憶部２７００と同様の機能を有する。
【０１７２】
通信部５２００は、管理サーバ３０００又は携帯端末４０００と通信する機能を有する。
【０１７３】
上述した機能の全部または一部は、管理サーバ３０００、携帯端末４０００及びキッティング装置２０００の有するそれぞれのＣＰＵが、管理サーバ３０００、携帯端末１０００及びキッティング装置２０００それぞれのメモリ等に記録されているプログラムを実行することにより実現される。
【０１７４】
＜データ＞
次に、状態報知システム２００で用いるデータについて図１１を用いて説明する。実施形態１で図４〜図７を用いて説明したデータも、実施形態２の状態報知システム２００で用いる。
【０１７５】
図１１は、端末別管理テーブル３７１０の構成及び内容の例を示す図である。
【０１７６】
この端末別管理テーブル３７１０は、管理サーバ３０００の端末別確認データ記憶部３７００に記憶されている。管理サーバ３０００が確認コマンドをキッティング装置５０００から受信する都度、インストールログ収集部３３００が記憶させる。
【０１７７】
端末別管理テーブル３７１０は、登録番号３７１１、携帯端末ＩＤ３７１２、アプリケーション名３７１３及び設定日時３７１４を有する。
【０１７８】
登録番号３７１１は、端末別管理テーブル３７１０に登録されているレコードの番号を示す。
【０１７９】
携帯端末ＩＤ３７１２は、管理サーバ３０００が管理している携帯端末４０００の識別子を示す。詳細には、インストールログ収集部３４００が収集できたインストールログの携帯端末４０００の識別子である。
【０１８０】
アプリケーション名３７１３は、携帯端末ＩＤ３７１２で示される携帯端末４０００に直近にインストールされたアプリケーションのアプリケーション名を示す。
【０１８１】
設定日時３７１４は、携帯端末ＩＤ３７１２で示される携帯端末４０００にアプリケーション名３７１３で示されるアプリケーションがインストールされた日時を示す。
【０１８２】
＜動作＞
以下、実施形態２の状態報知システム２００の動作について図１２を用いて説明する。
【０１８３】
図１２は、状態報知システム２００のキッティング確認処理を示すフローチャートである。
【０１８４】
図１２では、図８を用いて説明した実施形態１のキッティング確認処理のみを説明する。実施形態２においても、実施形態１のキッティング処理と同様のキッティング処理が行われた後にキッティング確認処理が行われることとなる。
【０１８５】
以下、実施形態１のキッティング確認処理と相違する点を中心に、実施形態２のキッティング確認処理を説明する。
【０１８６】
キッティング作業者は、キッティング装置５０００において確認コマンドを送信する指示を出す操作を行う。
【０１８７】
キッティング装置５０００の操作部２３００は、キッティング作業者による操作を検出すると検出した操作を制御部２１００に通知する。
【０１８８】
通知を受けた制御部２１００は、その操作から確認コマンドを送信する指示であると判断し、確認要求部２５００に確認コマンドを送信するよう指示する。
【０１８９】
指示を受けた確認要求部２５００は、通信部５２００を介して、管理サーバ３０００に送信する（ステップＳ５１０）。
【０１９０】
管理サーバ３０００において、通信部３２００を介して確認コマンドを受信した制御部３１００は、携帯端末４０００のキッティングの状態を確認するための処理を設定確認処理部３２００に依頼する。
【０１９１】
依頼を受けた設定確認処理部３２００は、各携帯端末４０００が記憶している確認データ１９１０を収集するようインストールログ収集部３４００に依頼する。
【０１９２】
依頼を受けたインストールログ収集部３４００は、各携帯端末４０００に対して、記憶しているインストールログの送信を要求するログ要求コマンドをブロードキャストで送信する（ステップＳ３００）。
【０１９３】
携帯端末４０００において、通信部４２００を介してログ要求コマンドを受信した制御部１１００は、最新のインストールログを取得するよう確認データ処理部４１００に依頼する。
【０１９４】
依頼を受けた確認データ処理部４１００は、インストールログ記憶部１８００に記憶されている最新のインストールログ１８１０を読み出して、制御部１１００に渡す。
【０１９５】
インストールログ１８１０を渡された制御部１１００は、渡されたインストールログ１８１０を管理サーバ３０００に送信する（ステップＳ４００）。
【０１９６】
管理サーバ３０００において、通信部３２００を介してインストールログ１８１０を受信したインストールログ収集部３４００は、受信したインストールログ１８１０と、これらのデータを送信してきた携帯端末４０００のＩＤとを端末別管理テーブル３７１０に登録する。
【０１９７】
具体的には、インストールログ１８１０の「ＡＰＬ」で指定されているアプリケーションの名称をアプリケーション名３７１３に設定し、インストールログ１８１０の作成日時を設定日時３７１４に設定し、携帯端末４０００のＩＤを携帯端末ＩＤ３７１２に設定する。
【０１９８】
各携帯端末４０００からインストールログ１８１０を受信したインストールログ収集部３４００は、インストールログ１８１０を収集した旨を設定確認処理部３３００に通知する（ステップＳ３１０）。
【０１９９】
インストールログ１８１０を収集した旨の通知を受けた設定確認処理部３３００は、次に、確認データの相違度を求めて確認データを変更する必要があるか否かの判定を行うよう相違度判定部３５００に依頼する。
【０２００】
依頼を受けた相違判定部３５００は、まず、端末別確認データ記憶部３７００に記憶されている端末別管理テーブル３７１０に記憶されているアプリケーション名３７１３で示されるアプリケーション同士の確認データ１９１０の相違度を、アプリ別管理テーブル２７２０及び確認データ管理テーブル２７１０（図４参照）を参照して求める。求めた相違度に基づいて、確認データ１９１０を変更するか否かを判定し、変更する場合は変更する携帯端末を決定する（ステップＳ３２０）。
【０２０１】
この相違度判定部３５００の相違度判定処理については、図１３を用いて後で説明する。
【０２０２】
確認データ１９１０を変更するか否かを判定した相違度判定部３５００は、その旨を設定確認処理部３３００に通知する。確認データ１９１０を変更する旨を通知した場合は、変更する携帯端末４０００も通知する。具体的には、携帯端末４０００にインストールされているアプリケーション名を通知する。
【０２０３】
通知を受けた設定確認処理部３３００は、通知が確認データを変更する旨である場合は（ステップＳ３３０：Ｙｅｓ）、新確認データ生成部３６００に新しい確認データ１９１０の生成を依頼する。この際、アプリケーション名を通知する。
【０２０４】
依頼を受けた新確認データ生成部３６００は、通知されたアプリケーション名で示されるアプリケーションの確認データを読み出し、読み出した確認データの構成要素の一部を変更して新しい確認データ１９１０を生成する。
【０２０５】
例えば、アプリケーションがメーラである場合、確認データは確認データ管理テーブル２７１０（図４参照）の確認データ番号１７１１が「１」のレコードで示されるものである。従って、メーラの確認データは、タイプ２７１３が「ＬＥＤ」、動作２７１４が「点滅：パターン１」と「色：青」との３つの構成要素を含むことになる。これらの３つの要素のうちのいずれか又は全てを変更することで、新しい確認データを生成する。
【０２０６】
新しい確認データをどのような内容に変更するかは、他のアプリケーションの確認データを参照して決定する。例えば、端末別管理テーブル３７１０のアプリケーション名３７１３に登録されているメーラ以外のアプリケーションの確認データと重ならないような内容に変更する。ＶＰＮソフトの報知態様がＬＥＤを緑色に点滅させることから、メーラは緑色と異なる色で点滅させるようにする、又は、点滅パターンを変える等である。又は、どの構成要素を変更するか、どのように変更するかはランダムに決めることとしてもよい。また、音、画面表示等の新しいタイプの構成要素を追加することで、報知態様の相違を際立たせることとしてもよい。
【０２０７】
新しい確認データ１９１０を生成した新確認データ生成部３６００は、生成した新しい確認データ１９１０を設定確認処理部３３００に渡す。
【０２０８】
新しい確認データ１９１０を受け取った設定確認処理部３３００は、端末別管理テーブル３７１０を参照して、確認データ１９１０を新しい確認データ１９１０に変更させる携帯端末４０００に対して、新しい確認データ１９１０を送信する（ステップＳ３４０）。具体的には、端末別管理テーブル３７１０のアプリケーション名３７１３が相違度判定部３５００から受け取ったアプリケーション名と同じであるレコードの、携帯端末ＩＤ３７１２で示される携帯端末４０００宛に送信する。
【０２０９】
相違度判定部３５００から確認データを変更しない旨の通知を受けた設定確認処理部３３００は（ステップＳ３３０：Ｎｏ）、確認コマンドを携帯端末４０００に対して、ブロードキャストで送信する（ステップＳ３５０）。
【０２１０】
携帯端末４０００において、通信部４２００を介して新しい確認データ１９１０を受信した制御部１１００は、受信した新しい確認データ１９１０を確認データ処理部４１００に渡して処理を依頼する。
【０２１１】
依頼を受けた確認データ処理部４１００は、渡された新しい確認データ１９１０を報知処理部４５００に渡して、作業メモリに記憶するよう依頼する。
【０２１２】
依頼を受けた報知処理部４５００は、渡された新しい確認データ１９１０を確認データ１９１０として、内部の作業メモリに記憶させる。ここで作業メモリに記憶させた確認データ１９１０は、管理サーバ３０００からリセットコマンドを受信したときに、削除するものとする。
【０２１３】
また、携帯端末４０００において、通信部４２００を介して確認コマンドを受信した制御部１１００は、報知処理を行うよう報知処理部４５００に依頼する。
【０２１４】
依頼を受けた報知処理部４５００は、内部の作業メモリに確認データ１９１０が記憶されている場合は、作業メモリから確認データ１９１０を読み出し、内部の作業メモリに確認データ１９１０が記憶されていない場合は、確認データ記憶部１９００に記憶されている確認データ１９１０を読み出す（図６参照）。
【０２１５】
報知処理部４５００は、作業メモリ又は確認データ記憶部１９００から読み出した確認データ１９１０と、インストールログ記憶部１８００に記憶されている直近に生成されたインストールログとに基づいて、報知処理を行う（ステップＳ４２０）。この報知処理は、図８を用いて説明した実施形態１の設定確認処理のうちのステップＳ１３０〜ステップＳ１６０の処理と同様である。
【０２１６】
各端末装置の報知を視認したキッティング作業者は、その報知に応じて次の作業を行う（ステップＳ５２０）。例えば、インストールに失敗した旨の報知であれば、再インストールを行うなどである。
【０２１７】
次に、相違度判定部３５００が行う相違度判定処理について図１３を用いて説明する。
【０２１８】
図１３は、相違度判定処理を示すフローチャートである。
【０２１９】
設定確認処理部３３００から判定の依頼を受けた相違判定部３５００は、まず、端末別確認データ記憶部３７００に記憶されている端末別管理テーブル３７１０と確認データ管理テーブル２７１０（図４参照）とを参照してアプリケーション間の確認データ１９１０の相違度を求める。
【０２２０】
具体的には、端末別管理テーブル３７１０のアプリケーション名３７１３を検索し、登録されているアプリケーション名が同じであるか否かを判断する。
【０２２１】
登録されているアプリケーション名が全て同じである場合は（ステップＳ６００：Ｎｏ）、それぞれインストールされた日時が所定期間、例えば、７日以上間隔が開いているかを判断する。
【０２２２】
具体的には、端末別管理テーブル３７１０の設定日時３７１４を検索し、登録されている日時に所定期間以上の開きがあるかどうかを判断する。
【０２２３】
所定期間以上の開きがある場合は（ステップＳ６１０：Ｎｏ）、確認データを変更しないと判定する（ステップＳ６５０）。同じアプリケーションのインストールが異なる日になされた場合に、それらの日の間が長ければ点滅間隔も長いことになる。従って、キッティング作業者は、携帯端末１０００の外観から、どの携帯端末１０００が先にキッティングされたのかを判断することができるからである。
【０２２４】
所定期間以上の開きがない場合（ステップＳ６１０：Ｙｅｓ）、又は、携帯端末４０００に異なるアプリケーションがインストールされている場合は（ステップＳ６００：Ｙｅｓ）は、それぞれのアプリケーションの確認データ１９１０同士の相違度を求める（ステップＳ６２０）。
【０２２５】
具体的には、確認データ１９１０の構成要素のうち異なっている構成要素の個数を求める。例えば、アプリケーションがメーラである場合、確認データは確認データ管理テーブル２７１０（図４参照）の確認データ番号１７１１が「１」のレコードで示されるものである。従って、メーラの確認データは、タイプ２７１３が「ＬＥＤ」、動作２７１４が「点滅：パターン１」と「色：青」との３つの構成要素を含むことになる。また、もう一つのアプリケーションがＶＰＮソフトである場合、確認データは確認データ番号１７１１が「２」のレコードで示されるものである。従って、ＶＰＮソフトの確認データは、タイプ２７１３が「ＬＥＤ」、動作２７１４が「点滅：パターン２」、「色：緑」の３つの構成要素を含むことになる。これらメーラとＶＰＮソフト間の確認データの相違度は、３分の２となる。３要素のうちの２要素である点滅パターンと色とが異なるからである。また、タイプ２７１３が「ＬＥＤ」の確認データと「振動」の確認データとは、タイプが異なるので相違度は３分の３となる。
【０２２６】
相違度が所定数、例えば３分の１以下の場合（ステップＳ６３０：Ｙｅｓ）、すなわち、異なっている構成要素が３つの構成要素のうち１又は０個である場合は、インストールされている携帯端末４０００の数がなるべく少ないアプリケーションの確認データを変更すると判断する（ステップＳ６４０）。
【０２２７】
例えば、確認データが３種類あり、確認データ１が「ＬＥＤ、点滅：パターン１、色：青」、確認データ２が「ＬＥＤ、点滅：パターン１、色：黄」、確認データ３が「ＬＥＤ、点滅：パターン１、色：緑」であった場合には、それぞれの確認データ間の相違する構成要素は１であるので、３種類の確認データのうち対応するアプリケーションがインストールされている携帯端末の個数が少ない確認データが変更の対象となる。
【０２２８】
相違度が所定数、例えば３分の１より多い場合（ステップＳ６３０：Ｎｏ）、すなわち、異なっている構成要素が３つの構成要素のうち２又は３個である場合は、確認データを変更しないと判断する（ステップＳ６５０）。
【０２２９】
＜変形例＞
実施形態２では、管理サーバ３０００が携帯端末４０００の報知態様が紛らわしいであろうと思われる場合に、一時的に確認データの変更を一部の携帯端末４０００に指示していた。
【０２３０】
変形例では、携帯端末４０００がインストールログを管理サーバ３０００に送信する際に（図１２のステップ４００参照）、確認データ１９１０で示された報知態様を実行できない旨を通知する。
【０２３１】
例えば、確認データ１９１０が、ＬＥＤを青色に点滅させるという報知態様を示している場合、携帯端末４０００はＬＥＤを青色に点灯させる機能を有していない場合である。
【０２３２】
管理サーバ３０００は、他の携帯端末４０００の報知態様を勘案して、確認データの変更を指示する。
【０２３３】
例えば、ＬＥＤに点灯させる色を変更する、振動させるようにするなどである。
【０２３４】
＜補足＞
以上、本発明の実施形態について説明したが、本発明は上記形態に限らず、以下のようにしてもよい。
（１）実施形態では、インストールの成功又は失敗をキッティングの状態としているが、携帯端末の状態を示すものであれば他の状態であってもよい。例えば、インストールされているアプリケーションのバージョン等であってもよい。また、インストールに限らず、搭載しているメモリサイズ等でもよい。
（２）実施形態では、ＬＥＤランプを点滅させて報知する場合、インストールされてからの経過時間を考慮して点滅間隔を変化させているが、経過時間を考慮して色を変化させてもよく、また、振動等の他の要素を追加してもよい。さらには、経過時間を考慮せずに確認データが占めす報知形態の通りに報知してもよい。
（３）実施形態２では、管理サーバは確認データを、各携帯端末から送信させることで取得している。しかし、キッティング装置から、インストールしたアプリケーションの確認データを取得してもよい。また、予め記憶しておいてもよい。
（４）携帯端末１０００等は、図３等の各構成要素の全部又は一部を、１チップ又は複数チップの集積回路で実現してもよい。
（５）携帯端末１０００等は、図３等の各構成要素の全部又は一部を、コンピュータのプログラムで実現してもよいし、その他どのような形態で実施してもよい。
【０２３５】
コンピュータプログラムの場合、メモリカード、ＣＤ−ＲＯＭなどいかなる記録媒体に書き込まれたものをコンピュータに読み込ませて実行させる形にしてもよいし、ネットワークを経由してプログラムをダウンロードして実行させる形にしてもよい。
【符号の説明】
【０２３６】
１０００ 携帯端末
１１００ ２１００ ３１００ 制御部
１２００ ２２００ ３２００ ４２００ ５２００ 通信部
１３００ 設定処理部
１４００ ＬＥＤランプ
１５００ ４５００ 報知処理部
１６００ 点滅間隔決定部
１７００ ２６００ アプリケーション記憶部
１８００ インストールログ記憶部
１９００ 確認データ記憶部
２０００ キッティング装置
２３００ 操作部
２４００ キッティング処理部
２５００ 確認要求部
２７００ アプリ別確認データ記憶部
３０００ 管理サーバ
３３００ 設定確認処理部
３４００ インストールログ収集部
３５００ 相違度判定部
３６００ 新確認データ生成部
３７００ 端末別確認データ記憶部
４１００ 確認データ処理部
【特許請求の範囲】
【請求項１】
自装置を所定の状態にしようとする毎に、自装置の状態を示す状態情報と報知方法を示す確認情報とを対応付けて記憶する記憶手段と、
自装置の状態の報知を要求する指示を、外部から取得する要求取得手段と、
自装置の状態を検出する検出手段と、
前記要求取得手段で前記指示を取得した場合に、前記検出手段で検出した自装置の状態に応じて、前記確認情報に基づいて報知を行う報知手段と
を備える端末装置。
【請求項２】
前記記憶手段は、自装置を所定の状態にしようとした時を示す時刻情報を記憶し、
前記報知手段は、前記時刻情報で示される時から前記要求取得手段で指示を取得した時までの経過時間に応じて、前記確認データに基づいて行う報知を変更して報知する
請求項１記載の端末装置。
【請求項３】
前記所定の状態とは、アプリケーションのインストールが成功した状態をいい、
前記自装置の状態とは、前記アプリケーションのインストールが成功したか否かを示す状態であり、
前記確認情報は、前記アプリケーションのインストールが実行される際に、当該アプリケーションと対応付けて記憶される
請求項１の端末装置。
【請求項４】
前記端末装置は、ランプを備え、
前記報知方法は、前記ランプを点滅させることであり、
前記報知手段は、前記経過時間に応じて定められている間隔で前記ランプを点滅させる
請求項２に記載の端末装置。
【請求項５】
複数の端末装置、設定確認装置及びサーバ装置を有する設定報知システムであって、
前記端末装置は、
自装置を所定の状態にしようとしたときに、自装置の状態を示す状態情報と報知方法を示す確認情報とを対応付けて記憶する記憶手段と、
自装置の状態の報知を要求する指示を、前記サーバ装置から取得する要求取得手段と、
自装置の状態を検出する検出手段と、
前記要求取得手段で前記指示を取得した場合に、前記検出手段で検出した自装置の状態に応じて、前記確認情報に基づいて報知を行う報知手段とを備え、
前記設定確認装置は、
前記サーバ装置に、前記端末装置に当該端末装置の状態を報知させるよう指示する指示手段を備え、
前記サーバ装置は、
前記端末装置に対して、状態を報知する要求を送信する要求送信手段を備える
設定報知システム。
【請求項６】
前記サーバ装置は、更に、前記各端末装置が記憶している確認情報を取得し、各確認情報が示す報知方法での報知が類似している場合にはいずれかの端末装置に対して報知方法を変更させる変更手段を、備える
請求項５記載の設定報知システム。
【請求項７】
前記端末装置の報知手段は、更に、前記確認情報に基づいて報知を行うことができない場合には、その旨を示す報知不可情報を前記サーバ装置に送信し、
前記サーバ装置は、前記端末装置から前記報知不可情報を受信した場合に、当該端末装置に対して報知方法を変更させる変更手段を備える
請求項５記載の設定報知システム。
【請求項８】
自装置の状態を報知する端末装置に、
自装置を所定の状態にしようとする毎に、自装置の状態を示す状態情報と報知方法を示す確認情報とを対応付けて記憶させる記憶ステップと、
自装置の状態の報知を要求する指示を、外部から取得させる要求取得ステップと、
自装置の状態を検出させる検出ステップと、
前記要求取得ステップで前記指示を取得した場合に、前記検出ステップで検出した自装置の状態に応じて、前記確認情報に基づいて報知を行わせる報知ステップと
を備える報知方法。
【請求項９】
端末装置に自装置の状態を報知させるコンピュータプログラムであって、
自装置を所定の状態にしようとする毎に、自装置の状態を示す状態情報と報知方法を示す確認情報とを対応付けて記憶する記憶処理を実行させ、
自装置の状態の報知を要求する指示を、外部から取得する要求取得処理を実行させ、
自装置の状態を検出する検出処理を実行させ、
前記要求取得処理で前記指示を取得した場合に、前記検出処理で検出した自装置の状態に応じて、前記確認情報に基づいて報知を行う報知処理を実行させる
コンピュータプログラム。
【請求項１】
自装置を所定の状態にしようとする毎に、自装置の状態を示す状態情報と報知方法を示す確認情報とを対応付けて記憶する記憶手段と、
自装置の状態の報知を要求する指示を、外部から取得する要求取得手段と、
自装置の状態を検出する検出手段と、
前記要求取得手段で前記指示を取得した場合に、前記検出手段で検出した自装置の状態に応じて、前記確認情報に基づいて報知を行う報知手段と
を備える端末装置。
【請求項２】
前記記憶手段は、自装置を所定の状態にしようとした時を示す時刻情報を記憶し、
前記報知手段は、前記時刻情報で示される時から前記要求取得手段で指示を取得した時までの経過時間に応じて、前記確認データに基づいて行う報知を変更して報知する
請求項１記載の端末装置。
【請求項３】
前記所定の状態とは、アプリケーションのインストールが成功した状態をいい、
前記自装置の状態とは、前記アプリケーションのインストールが成功したか否かを示す状態であり、
前記確認情報は、前記アプリケーションのインストールが実行される際に、当該アプリケーションと対応付けて記憶される
請求項１の端末装置。
【請求項４】
前記端末装置は、ランプを備え、
前記報知方法は、前記ランプを点滅させることであり、
前記報知手段は、前記経過時間に応じて定められている間隔で前記ランプを点滅させる
請求項２に記載の端末装置。
【請求項５】
複数の端末装置、設定確認装置及びサーバ装置を有する設定報知システムであって、
前記端末装置は、
自装置を所定の状態にしようとしたときに、自装置の状態を示す状態情報と報知方法を示す確認情報とを対応付けて記憶する記憶手段と、
自装置の状態の報知を要求する指示を、前記サーバ装置から取得する要求取得手段と、
自装置の状態を検出する検出手段と、
前記要求取得手段で前記指示を取得した場合に、前記検出手段で検出した自装置の状態に応じて、前記確認情報に基づいて報知を行う報知手段とを備え、
前記設定確認装置は、
前記サーバ装置に、前記端末装置に当該端末装置の状態を報知させるよう指示する指示手段を備え、
前記サーバ装置は、
前記端末装置に対して、状態を報知する要求を送信する要求送信手段を備える
設定報知システム。
【請求項６】
前記サーバ装置は、更に、前記各端末装置が記憶している確認情報を取得し、各確認情報が示す報知方法での報知が類似している場合にはいずれかの端末装置に対して報知方法を変更させる変更手段を、備える
請求項５記載の設定報知システム。
【請求項７】
前記端末装置の報知手段は、更に、前記確認情報に基づいて報知を行うことができない場合には、その旨を示す報知不可情報を前記サーバ装置に送信し、
前記サーバ装置は、前記端末装置から前記報知不可情報を受信した場合に、当該端末装置に対して報知方法を変更させる変更手段を備える
請求項５記載の設定報知システム。
【請求項８】
自装置の状態を報知する端末装置に、
自装置を所定の状態にしようとする毎に、自装置の状態を示す状態情報と報知方法を示す確認情報とを対応付けて記憶させる記憶ステップと、
自装置の状態の報知を要求する指示を、外部から取得させる要求取得ステップと、
自装置の状態を検出させる検出ステップと、
前記要求取得ステップで前記指示を取得した場合に、前記検出ステップで検出した自装置の状態に応じて、前記確認情報に基づいて報知を行わせる報知ステップと
を備える報知方法。
【請求項９】
端末装置に自装置の状態を報知させるコンピュータプログラムであって、
自装置を所定の状態にしようとする毎に、自装置の状態を示す状態情報と報知方法を示す確認情報とを対応付けて記憶する記憶処理を実行させ、
自装置の状態の報知を要求する指示を、外部から取得する要求取得処理を実行させ、
自装置の状態を検出する検出処理を実行させ、
前記要求取得処理で前記指示を取得した場合に、前記検出処理で検出した自装置の状態に応じて、前記確認情報に基づいて報知を行う報知処理を実行させる
コンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１１−３０５３（Ｐ２０１１−３０５３Ａ）
【公開日】平成２３年１月６日（２０１１．１．６）
【国際特許分類】
【出願番号】特願２００９−１４６１５９（Ｐ２００９−１４６１５９）
【出願日】平成２１年６月１９日（２００９．６．１９）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２３年１月６日（２０１１．１．６）
【国際特許分類】
【出願日】平成２１年６月１９日（２００９．６．１９）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]