プログラム、情報処理装置および方法
【課題】データ収集が端末のユーザの関与を伴う場合に、データの収集の緊急度とユーザの手間のバランスをとる。
【解決手段】データ記憶装置１０２はコンピュータ１０１が収集する対象のデータを記憶しており、端末１０３〜１０４はコンピュータ１０１とデータ記憶装置１０２の双方と通信可能である。コンピュータ１０１は、データ記憶装置１０２に記憶されていたデータを端末１０３〜１０４のいずれかを介して過去に収集してからの経過時間を認識し、経過時間が長いほど大きくなるように定義された閾値を取得する。コンピュータ１０１は、例えば端末１０３について、データ記憶装置１０２と端末１０３の間の距離を計算し、距離が閾値未満のとき、端末１０３に対して、データ記憶装置１０２に記憶されているデータの端末１０３への転送（Ｓ４）のための第１の指示をユーザ１０５に対して与える（Ｓ２）よう、第２の指示を与える（Ｓ１）。
【解決手段】データ記憶装置１０２はコンピュータ１０１が収集する対象のデータを記憶しており、端末１０３〜１０４はコンピュータ１０１とデータ記憶装置１０２の双方と通信可能である。コンピュータ１０１は、データ記憶装置１０２に記憶されていたデータを端末１０３〜１０４のいずれかを介して過去に収集してからの経過時間を認識し、経過時間が長いほど大きくなるように定義された閾値を取得する。コンピュータ１０１は、例えば端末１０３について、データ記憶装置１０２と端末１０３の間の距離を計算し、距離が閾値未満のとき、端末１０３に対して、データ記憶装置１０２に記憶されているデータの端末１０３への転送（Ｓ４）のための第１の指示をユーザ１０５に対して与える（Ｓ２）よう、第２の指示を与える（Ｓ１）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末のユーザの関与を伴うデータ収集システムで使われるプログラム、情報処理装置および方法に関する。
【背景技術】
【０００２】
様々な分野において、目的地または目標物の位置と現在位置に応じた制御が利用されている。
例えば、ユーザが端末を携帯している場合、目標物の位置と端末の現在位置との間の距離が所定値未満のときに、端末がユーザに対して何らかのメッセージ（例えば、指示、警告、通知など）を提示してもよい。
【０００３】
また、省電力化を図りつつ、本来の検出動作ならびにそれに伴う警報動作をすることを目的として、以下のようなマイクロ波検出器が提案されている。
マイクロ波検出器内のマイクロ波検出器本体で目的のマイクロ波を受信した場合には、マイクロ波検出器は、警報器を操作して警報出力をする。
【０００４】
また、マイクロ波検出器は、ＧＰＳ（Global Positioning System）情報を取得するＧＰＳ検出部と、目標物（検出対象物等）の位置情報を記憶する位置記憶部を有する。マイクロ波検出器はさらに、ＧＰＳ検出部で検出した現在位置と位置記憶部に記憶された周囲に存在する目標物の位置情報から、その目標物までの距離を求める距離検出部を有する。
【０００５】
そして、マイクロ波検出器は、位置情報に基づき車両の走行方向を検出する進行方向検出部と、目標物の方向を検出する目標物方向検出部と、各検出部の出力に基づいてＧＰＳ検出部の動作を制御する動作制御部も有する。動作制御部は、目標物までの距離が短いほど、間欠動作する間隔を短くなるように制御する。
【０００６】
また、周辺風景から、位置データが示す位置あるいは目的地位置を利用者が容易に目視確認し得るようにすることを目的として、以下のような技術も提案されている。
ナビゲーション装置は、経路案内プログラムによる経路案内中、ＧＰＳセンサにより検出された現在位置が、目的地位置から所定範囲内にあるか否かを判断する。そして、ナビゲーション装置は、現在位置が所定範囲内にあると判断したとき、地点情報データベースに記憶された画像データに基づく画像を、描画プログラムによりディスプレイに表示させる。
【０００７】
これにより、所定範囲内に現在位置があると、画像データに基づく画像がディスプレイに表示される。よって、ディスプレイに表示された画像と現在位置の周辺風景とを見比べることによって、利用者は目的地位置を目視確認することができる。したがって、周辺風景から目的地位置を利用者が容易に目視確認することができる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００２−２４３８３６号公報
【特許文献２】特開２００３−１９４５６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ところで、ある種のデータ収集システムは、端末のユーザの関与を伴う。例えば、データ収集システムは、データを収集するコンピュータと、当該コンピュータが収集する対象のデータを記憶しているデータ記憶装置を含んでもよい。しかし、コンピュータとデータ記憶装置が通信することができるとは限らない。
【００１０】
そこで、データ記憶装置およびコンピュータの双方と通信可能な端末が用いられてもよい。つまり、データ記憶装置からデータを一旦端末に転送し、その後、端末からデータをコンピュータに転送することで、データ記憶装置からコンピュータへのデータの収集が実現されてもよい。
【００１１】
そして、端末を介した上記のようなデータ収集は、何らかの意味でのユーザの関与を伴う。例えば、ユーザは、端末に対する操作を行うことで、データ収集に関与するかもしれない。
【００１２】
また、仮にデータ記憶装置から端末へのデータ転送や、端末からコンピュータへのデータ転送自体は自動的に行われるとしても、ユーザの関与は無ではない。例えば、端末をデータ記憶装置と通信可能な状態にするために、ユーザは「端末を携帯してデータ記憶装置に接近する」などの行為を行うことで、データ収集に関与するかもしれない。
【００１３】
つまり、端末を介した上記のようなデータ収集では、ユーザに何らかの手間が発生する。そして、「データ収集に関与するための行為をユーザが自発的または偶発的に行う」という可能性はあるが、「ユーザが当該行為を適時に必ず行う」という保証はない。
【００１４】
そこで、端末は、データ収集に関与するための行為を行うように、ユーザに指示を与えてもよい。換言すれば、端末は、データ記憶装置に記憶されているデータの端末への転送のための指示をユーザに与えてもよい。
【００１５】
ここで、上記に例示したような、目標物の位置と現在位置に応じた制御を利用して、目標物としてのデータ記憶装置の位置と端末の現在位置に応じて、端末がユーザに対して上記指示を与えることが考えられる。しかし、上記指示は、手間をかけることをユーザに要求する指示である。よって、上記指示を端末が濫発することは、ユーザに必要以上の負担をかけるおそれがあり、望ましくない。
【００１６】
例えば、ある端末を介してデータ記憶装置からデータがコンピュータに収集された後、しばらくの間は、次の収集対象のデータがまだない（または、少量しかデータ記憶装置に蓄積されていない）かもしれない。そして、「ユーザに対して上記指示を出すか否かという判断が、データ記憶装置と端末との間の距離に関する固定的な閾値に基づいてなされる」と仮定すると、結果的には指示が濫発されることになりかねない。例えば「次の収集対象のデータがない」という状況など、収集の緊急度が低い状況下では、固定的な閾値に基づく制御は、「端末が不急の指示を必要以上に出してしまう」という結果を招くおそれがある。
【００１７】
他方、仮に上記のような指示の濫発を防ぐために、収集の緊急度の低い状況に合わせて固定的な閾値を定めると、別の問題が生じかねない。すなわち、「たまたま、固定的な閾値で示される範囲内には１台も端末が存在しない」という場合は、たとえ収集の緊急度が高くても、結果的には「端末を介したデータ収集がすぐには行えない」という事態に陥るおそれがある。
【００１８】
そこで本発明の課題は、データ収集が端末のユーザの関与を伴う場合に、データの収集の緊急度とユーザの手間のバランスをとることである。
【課題を解決するための手段】
【００１９】
一態様において提供されるプログラムは、コンピュータに以下の処理を実行させる。
当該処理は、前記コンピュータが収集する対象のデータを記憶しているデータ記憶装置が設置されている第１の位置を認識することを含む。また、当該処理は、前記データ記憶装置に記憶されていたデータを、前記データ記憶装置および前記コンピュータの双方と通信可能な１台以上の端末のいずれかを介して、過去に前記コンピュータが収集した収集時点からの、経過時間を認識することを含む。さらに、当該処理は、前記経過時間が長いほど大きくなるように定義された閾値を、前記経過時間に基づいて取得することを含む。
【００２０】
また、当該処理は、前記１台以上の端末のうち少なくとも１台の端末について、当該端末の存在する第２の位置を認識し、前記第１の位置と前記第２の位置の間の距離を計算し、前記距離が前記閾値未満のとき、当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第１の指示を当該端末のユーザに対して与えるよう、第２の指示を与えることを含む。
【発明の効果】
【００２１】
データ記憶装置からのデータの収集の緊急度は、過去にコンピュータがいずれかの端末を介してデータ記憶装置からデータを収集してからの経過時間が長いほど、高いと考えられる。なぜなら、経過時間が長ければ、コンピュータは最近のデータをまだ収集しておらず、したがって、最近のデータが表す最近の状況をコンピュータは把握していないからである。つまり、経過時間は、収集の緊急度の指標である。
【００２２】
他方、第１の指示をユーザに与えることは、手間をかけることをユーザに要求することである。よって、第１の指示の濫発は好ましくない。換言すれば、第１の指示をユーザに対して与えるように端末に求める第２の指示の濫発は、好ましくない。
【００２３】
しかし、上記プログラムによれば、経過時間が短ければ、データ記憶装置から近い端末にしか第２の指示が与えられず、経過時間が長いほど、データ記憶装置からより遠い端末に対しても第２の指示が与えられるようになる。つまり、経過時間が短ければ、データ記憶装置から近い端末のユーザにしか第１の指示が与えられず、経過時間が長いほど、データ記憶装置からより遠い端末のユーザも、第１の指示を与えられることになる。
【００２４】
よって、上記プログラムによれば、収集の緊急度が低い場合（つまり経過時間が短い場合）は、収集の緊急度が高い場合（つまり経過時間が長い場合）と比べて、手間をかけることをユーザに要求する第１の指示が抑制される。すなわち、上記プログラムによれば、データの収集の緊急度と、ユーザの手間の間で、バランスをとることができる。
【図面の簡単な説明】
【００２５】
【図１】第１実施形態の概要を説明する図である。
【図２】ユーザの動きの例を示す図である。
【図３】第１実施形態のセンサデータ収集システムのブロック構成図である。
【図４】センサデータ収集システムのハードウェア構成図である。
【図５】サーバが保持する静的なＤＢの例を示す図（その１）である。
【図６】サーバが保持する静的なＤＢの例を示す図（その２）である。
【図７】センサに関連して動的に変化するＤＢの例を示す図である。
【図８】端末の移動につれて動的に変化するＤＢの例を示す図である。
【図９】第１実施形態のデータ収集システムの動作シーケンス図である。
【図１０】端末におけるＧＰＳログ処理のフローチャートである。
【図１１】サーバにおいて所定の時刻に行われるアラーム距離決定処理のフローチャートである。
【図１２】第１実施形態のアラーム関連処理のフローチャートである。
【図１３】データ収集への関与が原因でユーザの作業効率が悪くなる例を示す図である。
【図１４】第２実施形態のセンサデータ収集システムのブロック構成図である。
【図１５】第２実施形態においてサーバが保持するＤＢの例を示す図である。
【図１６】作業スケジュールとアラーム予定日の例を示す図である。
【図１７】第２実施形態のデータ収集システムの動作シーケンス図である。
【図１８】第２実施形態のアラーム関連処理のフローチャートである。
【図１９】圃場特定・アラーム再判定処理のフローチャートである。
【図２０】スケジュール確認処理のフローチャートである。
【発明を実施するための形態】
【００２６】
以下、実施形態について、図面を参照しながら詳細に説明する。具体的には、まず、図１〜１２を参照して第１実施形態について説明する。次に、図１３〜２０を参照して第２実施形態について、第１実施形態との違いを中心に説明する。最後に、その他の変形例についても説明する。
【００２７】
図１は、第１実施形態の概要を説明する図である。図１のデータ収集システム１００は、コンピュータ１０１とデータ記憶装置１０２と１台以上の端末を含む。図１では具体的には２台の端末１０３と１０４が例示されている。また、図１には、端末１０３を携帯するユーザ１０５と、端末１０４を携帯するユーザ１０６も図示されている。なお、図１にはデータ記憶装置１０２が１台しか図示されていないが、データ収集システム１００は複数のデータ記憶装置１０２を含んでもよい。
【００２８】
データ記憶装置１０２は、データを生成し、蓄積する。例えば、データ記憶装置１０２はセンサを有してもよく、センサが感知したデータを蓄積してもよい。データ記憶装置１０２は、センサ以外のモジュールによりデータを生成してもよい。つまり、データ記憶装置１０２が記憶するデータの種類は任意である。
【００２９】
データ収集システム１００は、データ記憶装置１０２に記憶されているデータをコンピュータ１０１が収集するシステムである。しかし、データ記憶装置１０２には、コンピュータ１０１と通信する機能がない。そこで、データ収集システム１００においては、データ記憶装置１０２からコンピュータ１０１へのデータの収集が、端末（例えば、端末１０３または１０４）を介して行われる。
【００３０】
端末１０３と１０４は、コンピュータ１０１と通信可能であり、データ記憶装置１０２とも通信可能である。したがって、データ記憶装置１０２に記憶されているデータは、データ記憶装置１０２から端末１０３に一旦転送され、端末１０３からコンピュータ１０１に転送されてもよい。もちろん、データは端末１０４を介してデータ記憶装置１０２からコンピュータ１０１に送られてもよい。いずれにしろ、データ収集システム１００では、端末を介してコンピュータ１０１がデータ記憶装置１０２からデータを収集する。
【００３１】
以下では説明の便宜上、端末１０３を介してデータが収集される場合を例として取り上げるが、端末１０３に関する説明は端末１０４についても同様に当てはまる。
第１実施形態では、コンピュータ１０１と端末１０３の間の通信は、例えば３Ｇ（3rd Generation）通信網などのネットワークを介して行われる。したがって、端末１０３は、物理的には必ずしもコンピュータ１０１の近傍に位置していなくても、不図示の基地局などを介してコンピュータ１０１と通信することができる。
【００３２】
他方、第１実施形態における端末１０３とデータ記憶装置１０２の間の通信は、物理的にデータ記憶装置１０２と端末１０３が近くに位置することを前提とする種類の通信である。具体的には、データ記憶装置１０２と端末１０３の間の通信は、近距離無線通信か有線通信である。
【００３３】
近距離無線通信の例は、例えば、以下のようなものである。
・ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１５シリーズの規格にしたがった通信。例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＺｉｇＢｅｅ（登録商標）などによる通信。
・ＵＷＢ（Ultra Wide Band）による無線通信。
・ＩＥＥＥ８０２．１１シリーズの規格にしたがった無線ＬＡＮ（Local Area Network）通信。
・例えば、ＩＳＯ／ＩＥＣ１８０９２やＩＳＯ／ＩＥＣ２１４８１として規格化されているＮＦＣ（Near Field Communication）などの、近接場無線通信（なお、ＩＳＯはInternational Organization for Standardizationのこと、ＩＥＣはInternational Electrotechnical Commissionのことである）。
・赤外線や可視光線などを利用した光無線通信。
【００３４】
また、有線通信の例は、例えば、ＵＳＢ（Universal Serial Bus）ケーブルを介した通信である。
近距離無線通信と有線通信のどちらが利用されるにしろ、端末１０３は、データ記憶装置１０２に近づかないとデータ記憶装置１０２と通信することができない。換言すれば、端末１０３とデータ記憶装置１０２の間の通信は、端末１０３のユーザ１０５の関与を伴う。
【００３５】
具体的には、ユーザ１０５は、「端末１０３を携帯してデータ記憶装置１０２に十分に接近する」という行為を行うことで、端末１０３とデータ記憶装置１０２の間の通信に関与する。また、ユーザ１０５は、「端末１０３とデータ記憶装置１０２の間をケーブルで接続する」または「通信開始のために端末１０３のボタンを押す」などの操作をさらに行うことで、端末１０３とデータ記憶装置１０２の間の通信に関与することもある。もちろん、近距離無線通信が使われる場合、データ記憶装置１０２と通信可能な範囲に端末１０３が入ったら、データ記憶装置１０２と端末１０３が自動的に通信を始めてもよく、その場合、ユーザ１０５の関与はデータ記憶装置１０２への接近行為だけでもよい。
【００３６】
以上例示したようなデータ記憶装置１０２と端末１０３の間の通信への関与は、ユーザ１０５が自発的に行う可能性もある。また、ユーザ１０５が端末１０３を携帯したまま偶然データ記憶装置１０２の近くを通りかかる場合など、データ記憶装置１０２と端末１０３の間の通信に、ユーザ１０５が偶発的に関与することもある。
【００３７】
しかしながら、ユーザ１０５が必ず適時にデータ記憶装置１０２と端末１０３の間の通信に関与するとは限らない。もちろん、データ記憶装置１０２からのデータの収集は、端末１０３ではなく端末１０４を介して行われてもよいので、「データ収集のためには特定の１人のユーザ１０５の関与が必須」というわけではない。しかし、端末１０４のユーザ１０６も、データ記憶装置１０２と端末１０４の間の通信に必ず適時に関与するとは限らない。
【００３８】
そこで、第１実施形態では、データ記憶装置１０２からコンピュータ１０１へのデータ収集が適切に行われるようにするために、端末１０３がユーザ１０５に指示を与えるか、または、端末１０４がユーザ１０６に指示を与える。端末がユーザに与える指示は、具体的には、データ収集に関与するための行為を行うことをユーザに求める指示である。以下では説明の便宜上、端末がユーザに与える指示を「アラーム」という。
【００３９】
なお、「データ収集に関与するための行為」は、データ記憶装置１０２と端末の間の通信方法に応じて、上記のように、単にデータ記憶装置１０２に接近する行為だけであってもよい。あるいは、「データ収集に関与するための行為」は、ケーブルの接続操作またはボタン操作などの何らかのユーザ操作をさらに含んでもよい。しかし、以下では説明の簡単化のため、次のように仮定する。
【００４０】
・データ記憶装置１０２は、端末１０３および１０４との間で、近距離無線通信による通信を行う。
・データ記憶装置１０２は、通信可能な範囲内に入ってきた端末との間で自動的に通信を開始するので、ユーザはデータ記憶装置１０２への接近行為以外の行為を意識して行う必要はない。
【００４１】
ところで、たとえユーザがデータ収集に関与するための行為が、データ記憶装置１０２への接近行為だけであったとしても、ユーザに手間が生じることには変わりない。例えば、端末１０４がユーザ１０６に対するアラームを出した場合、ユーザ１０６には「遠くからわざわざデータ記憶装置１０２まで近寄る」という手間が生じる。
【００４２】
よって、端末１０４が必要以上にユーザ１０６に対してアラームを出すことは好ましくない。同様に、端末１０３が必要以上にユーザ１０５に対してアラームを出すことも好ましくない。
【００４３】
換言すれば、データ収集の緊急度または必要性に応じて、アラームの発行が適切に制御されることが好ましい。例えば、データ記憶装置１０２からデータがコンピュータ１０１に収集された直後は、次のデータ収集を行う緊急度が比較的低い。よって、データ収集の緊急度が低ければアラームの発行を抑制するように、データ収集システム１００が構成されることが好ましい。
【００４４】
そこで、第１実施形態では、具体的にはコンピュータ１０１が以下のような制御を行うことで、データ収集の緊急度または必要性に応じた適度のアラームの発行が実現される。
コンピュータ１０１は、データ記憶装置１０２が設置されている第１の位置を認識する。例えば、コンピュータ１０１は、第１の位置を記憶したデータベース（以下「ＤＢ」と略す）を参照することで、第１の位置を認識してもよい。
【００４５】
また、コンピュータ１０１は、データ記憶装置１０２に記憶されていたデータを、いずれかの端末を介して過去にコンピュータ１０１が収集した収集時点からの、経過時間を認識する。例えば、コンピュータ１０１は、いずれかの端末を介してデータ記憶装置１０２からデータを収集するたびに、収集日時または収集日を適宜のＤＢに記憶してもよい。そして、コンピュータ１０１は、記憶した収集日時を現在時刻から引くことで（または記憶した収集日を今日の日付から引くことで）、経過時間を認識してもよい。
【００４６】
さらに、コンピュータ１０１は、経過時間が長いほど大きくなるように定義された閾値を、経過時間に基づいて取得する。例えば、コンピュータ１０１は、経過時間と閾値を対応づけたＤＢを参照することにより、閾値を取得してもよい。コンピュータ１０１は、必要に応じて補間を行って閾値を取得してもよい。また、コンピュータ１０１は、経過時間を引数とする単調増加関数を用いて閾値を計算してもよい。
【００４７】
以下では説明の便宜上、当該閾値を「アラーム距離」という。アラーム距離は、端末とデータ記憶装置１０２との間の距離に関する閾値である。具体的には、アラーム距離は、「ユーザにアラームを出せ」という指示を、コンピュータ１０１が端末に与えるか否かの判断に使われる閾値である。図１には、データ記憶装置１０２を中心とし、アラーム距離を半径とする範囲（以下「アラーム範囲」という）１０７が図示されている。
【００４８】
以上のようにして得られたアラーム距離を用いた処理は、具体的には以下のとおりである。
コンピュータ１０１は、データ収集システム１００に含まれる端末（図１の例では端末１０３と１０４）のうち少なくとも１台の端末について、当該端末の存在する第２の位置を認識する。例えば、端末１０３は、ＧＰＳ機能を有してもよく、ＧＰＳ機能により認識した端末１０３自体の位置をコンピュータ１０１に通知してもよい。端末１０４も同様にして、ＧＰＳ機能により認識した端末１０４自体の位置をコンピュータ１０１に通知してもよい。すると、コンピュータ１０１は端末１０３と１０４の位置を認識する。
【００４９】
コンピュータ１０１は、第１の位置（つまりデータ記憶装置１０２の位置）と第２の位置（つまり個々の端末の位置）の間の距離を計算する。例えば、コンピュータ１０１は、データ記憶装置１０２の位置と端末１０３の位置の間の距離を計算するとともに、データ記憶装置１０２の位置と端末１０４の位置の間の距離を計算する。
【００５０】
なお、コンピュータ１０１が計算する距離は、ユークリッド距離（直線距離）でもよいし、緯度と経度を座標軸とするマンハッタン距離でもよい。また、コンピュータ１０１がある１台の端末（例えば端末１０３）について計算する距離は、ある１つの時点における当該端末の位置に基づく距離でもよいし、複数の時点における当該端末の位置に基づく距離でもよい。例えば、複数の時点における位置に基づいて得られる複数の距離の最小値もしくは平均値、または、複数の時点の平均位置から得られる距離などが利用可能である。
【００５１】
そして、コンピュータ１０１は、計算した距離がアラーム距離未満の端末に対して、データ記憶装置１０２に記憶されているデータの当該端末への転送のための第１の指示（つまりアラーム）を当該端末のユーザに対して与えるよう、第２の指示を与える。なお、計算した距離がちょうどアラーム距離と同じ端末に対してコンピュータ１０１が第２の指示を与えるか否かは、実施形態に応じて適宜方針が決められてよい。
【００５２】
例えば、図１では、端末１０３がアラーム範囲１０７内に位置しており、端末１０４がアラーム範囲１０７外に位置している。つまり、データ記憶装置１０２と端末１０３の距離はアラーム距離より短いが、データ記憶装置１０２と端末１０４の距離はアラーム距離より長い。よって、図１の例では、コンピュータ１０１は、ステップＳ１において、「ユーザ１０５に対してアラームを出せ」という指示（以下、「アラーム指示」ともいう）を端末１０３に与えるが、端末１０４に対しては特に指示を与えない。
【００５３】
すると、ステップＳ２で端末１０３は、アラーム指示にしたがって、ユーザ１０５に対してアラームを出し、データ収集への関与をユーザ１０５に促す。よって、ステップＳ３でユーザ１０５は、アラームにしたがってデータ記憶装置１０２に近づく。その結果、端末１０３がデータ記憶装置１０２に十分に近づくと、端末１０３は、データ記憶装置１０２と通信可能な状態となる。
【００５４】
すると、「ユーザはデータ記憶装置１０２への接近行為以外の行為を意識して行う必要はない」という上記仮定のとおり、ステップＳ４で自動的にデータ記憶装置１０２と端末１０３の間の通信が始まる。そして、データ記憶装置１０２に記憶されているデータが、端末１０３に転送される。
【００５５】
その後、ステップＳ５で端末１０３からコンピュータ１０１へとデータが転送される。ステップＳ５の転送も、端末１０３が自動的に行ってよく、ユーザ１０５が意識的にボタン操作などを行わなくてもよい。以上のようにして、コンピュータ１０１は、端末１０３を介してデータ記憶装置１０２からデータを収集することができる。
【００５６】
なお、ステップＳ５の転送は、ステップＳ４の直後に行われてもよいし、多少時間が経ってから行われてもよい。例えば、端末１０３の位置における電波状況が悪い場合には、端末１０３は、電波状況を監視し、電波状況が改善するまでステップＳ５の転送を待ってもよい。
【００５７】
図１の例では、以上のようにして端末１０３を介したデータ収集が行われる一方で、アラーム範囲１０７外にある端末１０４は、コンピュータ１０１からアラーム指示を受けないので、ユーザ１０６に対してアラームを出さない。よって、ユーザ１０６は、データ記憶装置１０２と端末１０４の通信のために何かを行う必要がない。換言すれば、アラーム範囲１０７外にいるユーザ１０６は、データ記憶装置１０２と端末１０４の通信のために煩わされることがない。
【００５８】
ところで、データ記憶装置１０２に近い位置にいるユーザほど、データ記憶装置１０２の位置まで移動するのにかかる手間は小さい。例えば、図１の例では、ユーザ１０５がデータ記憶装置１０２まで移動するのにかかる手間の方が、ユーザ１０６がデータ記憶装置１０２まで移動するのにかかる手間よりも小さい。
【００５９】
よって、上記のように経過時間が長いほど大きくなるように定義されたアラーム距離をコンピュータ１０１が使うことで、データ収集システム１００においては、データ収集の緊急度（換言すれば必要性）に応じて、アラームの発行が適切に制御される。つまり、コンピュータ１０１は、データ収集の緊急度が高いときには、ユーザの負担が大きくてもアラームが出されるように端末を制御するが、データ収集の緊急度が低いときには、負担が少ないユーザに対してのみアラームが出されるように端末を制御する。
【００６０】
以上説明したデータ収集システム１００の動作について、いくつかの評価軸を使って定性的にまとめると、図１の説明図１０８のとおりである。説明図１０８は、以下のことを示している。
【００６１】
前回の収集からの経過時間が長いほど、データ記憶装置１０２から収集したデータに基づいてコンピュータ１０１が把握している状況は古く、また、データ記憶装置１０２の残り記憶容量は少ない。よって、前回の収集からの経過時間が長いと、「コンピュータ１０１が、最近の状況を認識していない」という意味でも、「データ記憶装置１０２の記憶容量がもうすぐ使い尽くされてしまう」という意味でも、データ収集の緊急度（または必要性）は高い。
【００６２】
コンピュータ１０１が最近の状況を認識していないことは、例えば次のような問題を引き起こすおそれがある。例えば、コンピュータ１０１がデータ記憶装置１０２から収集したデータに基づいて何らかの制御を行うとする。この場合、コンピュータ１０１は、最近の状況を認識していないと、現状に合わない不適切な制御を行うおそれがある。
【００６３】
また、データ記憶装置１０２の記憶容量が使い尽くされてしまうと、データ記憶装置１０２は、たとえ次の新たなデータを生成しても、生成したデータを記憶せずに破棄するかもしれない。あるいは、データ記憶装置１０２は、端末１０３または１０４を介してのコンピュータ１０１への収集がまだ済んでいなくても、古い方からデータを破棄することで最新のデータを記憶するための記憶領域を確保するかもしれない。いずれにしろ、コンピュータ１０１にとっては、一部のデータが、データ記憶装置１０２から収集できないまま失われてしまうことになる。
【００６４】
以上のように、前回の収集からの経過時間が長いほど、データ収集の緊急度（または必要性）は高い。逆に、前回の収集からの経過時間が短ければ、データ収集の緊急度（または必要性）は比較的低い。
【００６５】
そして、アラーム距離は、経過時間が長いほど、長くなるように定義されている。つまり、データ収集の緊急度（または必要性）が高ければ、データ記憶装置１０２から遠いユーザに対してもアラームが出される一方で、データ収集の緊急度（または必要性）が低ければ、データ記憶装置１０２に近いユーザにしかアラームが出されない。
【００６６】
そして、データ記憶装置１０２から遠くにユーザがいるほど、データ記憶装置１０２までユーザが移動する手間は大きい。つまり、アラーム距離が長いほど、アラームを受けたユーザの負担が大きい傾向がある。
【００６７】
もちろん、閾値であるアラーム距離が長くても、たまたまデータ記憶装置１０２のすぐ近くにユーザがいれば、当該ユーザの負担は小さい。しかし、アラームを受けたユーザの負担の期待値は、アラーム距離が長いほど、大きい。
【００６８】
以上のように、コンピュータ１０１は、データ収集の緊急度（または必要性）が高ければ、「ユーザの負担が大きくてもやむを得ない」と判断し、ユーザにかかる負荷よりもデータ収集を優先する制御を行う。逆に、データ収集の緊急度（または必要性）が低ければ、コンピュータ１０１は、「ユーザの負担が小さければ、データ収集のためにユーザに協力してもらうが、ユーザの負担が大きければデータ収集を今すぐ行う必要はない」と判断する。つまり、データ収集の緊急度（または必要性）が低ければ、コンピュータ１０１は、データ収集よりもユーザにかかる負荷の軽減を優先する制御を行う。その結果、データ収集システム１００においては、データ収集の緊急度（または必要性）と、データ収集に関与するためにユーザにかかる負荷との間で、均衡がとれる。
【００６９】
続いて、具体的なユーザの動きの例を示す図２を参照して、図１に示したデータ収集システム１００の利点についてさらに詳しく説明する。
図２には、圃場２０１におけるユーザの動きの例が示されている。図１のデータ記憶装置１０２は、具体的には、例えば、圃場２０１内に設置されたセンサユニット２０２であってもよい。
【００７０】
センサユニット２０２は、データを取得するための１つ以上のセンサと、人感センサ（例えば赤外線センサなど）を有する。つまり、図２の例では、コンピュータ１０１が収集する対象のデータは、センサユニット２０２が有するセンサが生成したデータである。
【００７１】
センサユニット２０２はバッテリで駆動される。よって、通信による電力消費を抑えるために、センサユニット２０２は、通信機能を通常はオフにしている。
ここで、通信による電力消費と比べて、人感センサによる電力消費は少ない。よって、センサユニット２０２は、人感センサをオンにしておく。そして、人感センサがユーザを検知したら、センサユニット２０２は、通信機能をオンにして、ユーザが携帯する端末と通信する。
【００７２】
しかし、圃場２０１は広く、人感センサがユーザを検知することのできる検知領域２０３は、圃場２０１のごく一部である。よって、端末がアラームを出さなければ、ユーザが誰も検知領域２０３内に入ってこないかもしれない。
【００７３】
例えば、図２に示すように、ある日、ユーザ２０４は軌跡２０５に沿って移動しながら除草などの作業を行い、同様に、ユーザ２０６は軌跡２０７に沿って移動しながら作業を行う。しかし、この日の作業は、軌跡２０５と２０７が通る範囲でのみ行われ、非作業領域２０８では何の作業も行われない。すると、非作業領域２０８の一部でしかない検知領域２０３には、ユーザ２０４が作業中に入ってくることもないし、ユーザ２０６が作業中に入ってくることもない。
【００７４】
よって、もしユーザ２０４と２０６がそれぞれ携帯する端末（図２には不図示）のいずれもアラームを出さなければ、図２の作業が行われる日には、センサユニット２０２から端末を介して図１のコンピュータ１０１へとデータが収集されることはない。
【００７５】
ここで、もし、図２の作業が行われる日におけるデータ収集の緊急度が低ければ、コンピュータ１０１へのデータ収集がこの日に行われなくても問題ない。また、データ収集の緊急度が低ければ、センサユニット２０２から遠く離れて作業しているユーザ２０４や２０６に作業を中断させて、データ収集への関与のための行動をとらせ、作業効率を落とすよりも、データ収集を後日に延期する方が好ましい。
【００７６】
他方、もし、図２の作業が行われる日におけるデータ収集の緊急度が高ければ、ユーザ２０４または２０６にセンサユニット２０２へと接近する手間を生じさせてでも、コンピュータ１０１がセンサユニット２０２からデータを収集することが好ましい。
【００７７】
そして、図１を参照して説明したコンピュータ１０１の制御によれば、データ収集の緊急度に応じたアラーム距離に基づいて、適切にアラームが発行される。よって、ユーザ２０４と２０６のどちらも作業自体のためには非作業領域２０８に入ることがないとしても、データ収集の緊急度が高ければ、例えばユーザ２０６が携帯する端末がアラームを発するので、ユーザ２０６の端末を介したデータ収集が可能となる。
【００７８】
続いて、図１のデータ収集システム１００について、図３〜１２を参照してより詳細に説明する。なお、図３はブロック構成図、図４はハードウェア構成図、図５〜８はＤＢの例を示す図、図９は動作シーケンス図、図１０〜１２はフローチャートである。
【００７９】
さて、図３は、第１実施形態のセンサデータ収集システムのブロック構成図である。図３のデータ収集システム３００は、図１のデータ収集システム１００のより具体的な例である。データ収集システム３００は、サーバ３１０と、１台以上のセンサユニットと、１台以上の端末を含む。
【００８０】
サーバ３１０は、図１のコンピュータ１０１の具体例であり、コンピュータ１０１と同様に動作する。例えば、汎用的な情報処理装置が、サーバ３１０として利用可能である。
また、図３には、３台のセンサユニット３５０ａ〜３５０ｃが例示されているが、センサユニットの数は任意である。紙面の都合上、図３ではセンサユニット３５０ａのみ内部の詳細が図示されているが、センサユニット３５０ｂと３５０ｃも、センサユニット３５０ａと同様に構成される。
【００８１】
以下では、センサユニット３５０ａ〜３５０ｃを区別する必要がない場合は、後述の図４に示すように「３５０」という参照符号を用いることもある。センサユニット３５０は、図１のデータ記憶装置１０２の具体例である。なお、図２のセンサユニット２０２も、センサユニット３５０と同様に構成されているものとする。
【００８２】
さらに、図３には、３台の端末３７０ａ〜３７０ｃが例示されているが、端末の数は任意である。紙面の都合上、図３では端末３７０ａのみ内部の詳細が図示されているが、端末３７０ｂと３７０ｃも、端末３７０ａと同様に構成される。
【００８３】
以下では、端末３７０ａ〜３７０ｃを区別する必要がない場合は、後述の図４に示すように「３７０」という参照符号を用いることもある。端末３７０は、図１の端末１０３の具体例でもあり、図１の端末１０４の具体例でもある。また、図２では端末の図示が省略されているが、図２のユーザ２０４と２０６も、それぞれ端末３７０と同様の端末を携帯しているものとする。
【００８４】
さて、サーバ３１０は、端末に関連して、ＧＰＳログＤＢ３１１、端末管理ＤＢ３１２、およびＧＰＳログ処理部３１３を有する。また、サーバ３１０は、センサユニットからの端末を介したデータ収集に関連して、収集日ＤＢ３１４とセンサログＤＢ３１５とセンサログ処理部３１６を有し、センサユニットの管理のためのセンサ位置ＤＢ３１７とセンサ種別ＤＢ３１８を有する。
【００８５】
そして、データ収集の緊急度とユーザの負荷のバランスをとるために、サーバ３１０は、センサユニット別アラーム条件ＤＢ３１９、アラーム条件ＤＢ３２０、サンプリング周期ＤＢ３２１、およびデータ量条件ＤＢ３２２を有する。また、データ収集の緊急度とユーザの負荷のバランスをとるために、サーバ３１０は、さらに、アラーム距離決定部３２３、端末・センサ間距離計算部３２４、距離比較部３２５、およびアラーム決定部３２６を有する。
【００８６】
また、サーバ３１０は、端末との通信のために通信部３２７も有する。以上のサーバ３１０内の各部についてより詳しく述べれば、以下のとおりである。
ＧＰＳログＤＢ３１１は、端末３７０の位置を示すＧＰＳログを、端末３７０の識別子と対応づけて記憶するＤＢである。ＧＰＳログＤＢ３１１の具体的なデータ例は図８とともに後述する。
【００８７】
端末管理ＤＢ３１２は、各端末３７０に関する情報（例えば、端末３７０のユーザの属性など）を記憶するＤＢである。端末管理ＤＢ３１２の具体的なデータ例は図５とともに後述する。
【００８８】
ところで、ＧＰＳログは、各端末３７０からサーバ３１０へと送信され、サーバ３１０の通信部３２７で受信され、通信部３２７からＧＰＳログ処理部３１３に出力される。すると、ＧＰＳログ処理部３１３は、通信部３２７から受け取ったＧＰＳログを、送信元の端末３７０の識別子と対応づけて、ＧＰＳログＤＢ３１１に格納する。つまり、ＧＰＳログ処理部３１３と通信部３２７は、協働して、端末３７０の存在する位置を認識する位置認識手段として動作する。
【００８９】
収集日ＤＢ３１４は、各センサユニット３５０について、当該センサユニット３５０からデータを最後に収集した日付を記憶するＤＢである。収集日ＤＢ３１４の具体的なデータ例は図７とともに後述する。
【００９０】
センサログＤＢ３１５は、いずれかの端末３７０を介してセンサユニット３５０から収集されたデータを、端末３７０の識別子と対応づけて記憶するＤＢである。以下ではセンサユニット３５０から端末３７０を介してサーバ３１０が収集する対象のデータを「センサログ」ともいう。
【００９１】
なお、端末３７０がサーバ３１０に送信するセンサログは、端末３７０がどのセンサユニット３５０から元のセンサログを取得したかを示すための、センサユニット３５０の識別子を含むように、端末３７０によって加工されたデータである。したがって、センサログＤＢ３１５の各エントリは、端末３７０の識別子だけでなく、センサユニット３５０の識別子も含む。センサログＤＢ３１５のより具体的なデータ例は、図７とともに後述する。
【００９２】
ところで、いずれかの端末３７０からサーバ３１０へ送信されたセンサログは、サーバ３１０の通信部３２７で受信され、通信部３２７からセンサログ処理部３１６に出力される。すると、センサログ処理部３１６は、通信部３２７から受け取ったセンサログを、送信元の端末３７０の識別子と対応づけて、センサログＤＢ３１５に格納する。
【００９３】
センサ位置ＤＢ３１７は、各センサユニット３５０が設置された位置を記憶するＤＢである。つまり、センサ位置ＤＢ３１７は、センサユニット３５０が設置されている位置を示す位置情報を記憶する記憶手段の具体例である。センサ位置ＤＢ３１７の具体的なデータ例は図５とともに後述する。
【００９４】
センサ種別ＤＢ３１８は、各センサユニット３５０に搭載されているセンサの種別を記憶するＤＢである。センサ種別ＤＢ３１８の具体的なデータ例は図５とともに後述する。
センサユニット別アラーム条件ＤＢ３１９は、各センサユニット３５０についてのアラーム距離の取得の仕方を規定するためのＤＢである。換言すれば、センサユニット別アラーム条件ＤＢ３１９は、経過時間に応じたアラーム距離を定義する条件（以下では「アラーム条件」という）と、センサユニット３５０とを対応づけるためのＤＢである。
【００９５】
図１に関して説明したとおり、アラーム距離は、センサユニット３５０からデータ（つまりセンサログ）を前回収集してからの経過時間に依存して決まる閾値である。そして、詳しくは図６のデータ例とともに後述するが、経過時間とアラーム距離との間の関係は、センサユニット３５０ごとに異なっていてもよい。つまり、経過時間の長さが同じでも、異なるセンサユニット３５０に対して異なるアラーム距離が定義されてもよい。センサユニット別アラーム条件ＤＢ３１９は、以上のようなセンサユニット３５０に応じたアラーム距離の違いを管理するためのＤＢである。
【００９６】
アラーム条件ＤＢ３２０は、経過時間とアラーム距離との間の関係を規定するＤＢである。アラーム条件ＤＢ３２０の各エントリは、経過時間からアラーム距離を得るための１つの方法を規定する１つのアラーム条件を表す。なお、アラーム条件ＤＢ３２０の具体的なデータ例は図６とともに後述する。
【００９７】
サンプリング周期ＤＢ３２１は、各センサユニット３５０内の各センサのサンプリング周期を記憶するＤＢである。つまり、サンプリング周期ＤＢ３２１には、各センサが計測を行って計測結果のデータを生成する周期が記憶されている。サンプリング周期ＤＢ３２１の具体的なデータ例は図６とともに後述する。後述のとおり、サンプリング周期ＤＢ３２１は、サーバ３１０がセンサユニット別アラーム条件ＤＢ３１９に適切な値を予め設定しておくために利用される。
【００９８】
データ量条件ＤＢ３２２は、１日あたりにセンサユニット３５０が生成するデータの量の範囲ごとに、推奨されるアラーム条件を規定するＤＢである。後述のとおり、データ量条件ＤＢ３２２も、サーバ３１０がセンサユニット別アラーム条件ＤＢ３１９に適切な値を予め設定しておくために利用される。
【００９９】
アラーム距離決定部３２３は、各センサユニット３５０について、当該センサユニット３５０に関するアラーム距離を決定する。具体的には、アラーム距離決定部３２３は、収集日ＤＢ３１４とセンサユニット別アラーム条件ＤＢ３１９とアラーム条件ＤＢ３２０を参照して、アラーム距離を決定する。つまり、アラーム距離決定部３２３は、アラーム距離を取得する取得手段の具体例である。
【０１００】
端末・センサ間距離計算部３２４は、ＧＰＳログＤＢ３１１とセンサ位置ＤＢ３１７を参照して、注目している端末３７０と注目しているセンサユニット３５０の間の距離を計算する。
【０１０１】
距離比較部３２５は、端末・センサ間距離計算部３２４が計算した距離を、アラーム距離決定部３２３が決定したアラーム距離と比較する。
アラーム決定部３２６は、距離比較部３２５による比較結果に応じて、端末３７０にアラーム指示を出すか否かを決定するとともに、アラーム指示の対象のセンサユニット３５０を決定する。
【０１０２】
例えば、「センサユニット３５０ａと端末３７０ａの間の距離は、センサユニット３５０ａに関するアラーム距離以下である」という比較結果を距離比較部３２５が得たとする。この場合、アラーム決定部３２６は、センサユニット３５０ａについてのアラーム指示を端末３７０ａに出すことを決定する。
【０１０３】
また、アラーム決定部３２６は、決定にしたがって、通信部３２７にアラーム指示を送信させる。つまり、距離比較部３２５とアラーム決定部３２６と通信部３２７は、協働して、計算手段としての端末・センサ間距離計算部３２４が計算した距離がアラーム距離以下の端末３７０にアラーム指示を与える指示手段として機能している。
【０１０４】
通信部３２７は、端末３７０との間の通信を行う。例えば、通信部３２７は、ネットワークを介して端末３７０からＧＰＳログやセンサログを受信する。また、通信部３２７は、アラーム決定部３２６の決定にしたがい、ネットワークを介して端末３７０にアラーム指示を送信する。
【０１０５】
さて、センサユニット３５０ａ〜３５０ｃは、図２のセンサユニット２０２と同様に、圃場２０１の内部などの予め決められた場所に設置される。センサユニット３５０ａ〜３５０ｃの各々は、各種センサ３５１、センサログＤＢ３５２、センサログ処理部３５３、および通信部３５４を有する。
【０１０６】
各種センサ３５１は、サーバ３１０が収集する対象のデータを生成する１つ以上のセンサと、図２に関して説明した人感センサを含む。例えば、各種センサ３５１は、温度センサ、湿度センサ、または画像センサを含んでもよいし、他の種類のセンサを含んでもよい。
【０１０７】
センサログＤＢ３５２は、各種センサ３５１が生成したデータを記憶するＤＢである。センサログＤＢ３５２の具体的なデータ例は図７とともに後述する。
センサログ処理部３５３は、各種センサ３５１が生成したデータをセンサログＤＢ３５２に格納する。また、センサログ処理部３５３は、端末３７０ａ〜３７０ｃのいずれかが人感センサの検知領域に入ってきたときに、通信部３５４をオンにして、センサログＤＢ３５２内のデータを、通信部３５４を介して当該端末に送信する。センサログ処理部３５３は、送信済みのデータをセンサログＤＢ３５２から消去してもよい。
【０１０８】
通信部３５４は端末３７０との間の通信を行う。図１に関して説明したように、第１実施形態では、図１のデータ記憶装置１０２と端末１０３が近距離無線通信により通信を行うものと仮定している。つまり、通信部３５４は、端末３７０との間で、例えばＢｌｕｅｔｏｏｔｈ（登録商標）などの近距離無線通信による通信を行う。なお、通信部３５４は、図２のセンサユニット２０２に関して説明したとおり、消費電力抑制のために、普段はオフにされており、必要に応じてセンサログ処理部３５３によりオンにされる。
【０１０９】
さて、端末３７０ａ〜３７０ｃの各々は、例えば、携帯電話、スマートフォン、タブレット端末、モバイルＰＣ（Personal Computer）などの端末である。端末３７０ａ〜３７０ｃの各々は、ＧＰＳ情報取得部３７１、ＧＰＳログＤＢ３７２、サーバ通信部３７３、アラーム処理部３７４、センサ通信部３７５、センサログＤＢ３７６、およびセンサログ処理部３７７を有する。
【０１１０】
ＧＰＳ情報取得部３７１は、ＧＰＳ衛星からの測位信号を受信することで、端末３７０の位置を示すＧＰＳ情報を取得する。そして、ＧＰＳ情報取得部３７１は、取得したＧＰＳ情報をＧＰＳログＤＢ３７２に格納する。なお、ＧＰＳログＤＢ３７２の具体的なデータ例は図８とともに後述する。
【０１１１】
サーバ通信部３７３は、ネットワークを介して、サーバ３１０（より具体的には通信部３２７）との間の通信を行う。例えば、端末３７０のサーバ通信部３７３とサーバ３１０の通信部３２７との間の通信は、３Ｇ通信網とインターネットを介して行われてもよい。
【０１１２】
アラーム処理部３７４は、サーバ３１０からサーバ通信部３７３を介してアラーム指示を受け取り、アラーム指示にしたがってユーザにアラームを出す。なお、アラームは、ブザーその他の音声的なものでもよいし、振動などの触覚的なものでもよいし、ディスプレイへのメッセージ表示などの視覚的なものでもよいし、それらの組み合わせでもよい。
【０１１３】
センサ通信部３７５は、センサユニット３５０（より具体的には通信部３５４）との間の通信を行う。図１に関して説明したように、第１実施形態では、図１のデータ記憶装置１０２と端末１０３が近距離無線通信により通信を行うものと仮定している。つまり、センサ通信部３７５は、センサユニット３５０の通信部３５４との間で、例えばＢｌｕｅｔｏｏｔｈ（登録商標）などの近距離無線通信による通信を行う。
【０１１４】
センサログＤＢ３７６は、センサユニット３５０から受信したデータを一時的に記憶するＤＢである。なお、センサログＤＢ３７６の具体的なデータ例は図７とともに後述する。
【０１１５】
センサログ処理部３７７は、センサログＤＢ３５２に記憶されているデータを、センサ通信部３７５を介してセンサユニット３５０から受信し、受信したデータをセンサログＤＢ３７６に格納する。また、センサログ処理部３７７は、センサユニット３５０からデータを受信し終わると、センサログＤＢ３７６に格納したデータを、今度はサーバ通信部３７３を介してサーバ３１０に送信する。
【０１１６】
続いて、図３の各ブロックを実現するハードウェア構成について、図４を参照して説明する。
サーバ３１０は、ＣＰＵ（Central Processing Unit）４０１、ＲＡＭ（Random Access Memory）４０２、およびＨＤＤ（Hard Disk Drive）４０３を有する。また、サーバ３１０は、ネットワークＩＦ（interface）４０４、機器ＩＦ４０５、ディスプレイＩＦ４０６、および駆動装置４０７を有する。そして、サーバ３１０内の上記各部は互いにバスで接続されている。
【０１１７】
ＣＰＵ４０１は、プログラムをＲＡＭ４０２にロードし、ＲＡＭ４０２をワーキングエリアとしても使いながら、プログラムを実行する。また、ＨＤＤ４０３は、プログラムや各種ＤＢを保持する。
【０１１８】
ネットワークＩＦ４０４は、例えば、有線ＬＡＮまたは無線ＬＡＮのインタフェイスである。ネットワークＩＦ４０４を介してサーバ３１０はネットワーク４１１に接続される。ネットワーク４１１は、例えば、ＬＡＮ、インターネット、３Ｇ通信網の組み合わせであり、ネットワーク４１１を介してサーバ３１０と端末３７０は接続される。
【０１１９】
機器ＩＦ４０５は、入力機器をサーバ３１０に接続するインタフェイスである。入力機器の例として、図４には、キーボード４１２とマウス４１３が例示されているが、その他のポインティングデバイスが機器ＩＦ４０５に接続されてもよい。
【０１２０】
また、ディスプレイＩＦ４０６は、ディスプレイ４１４をサーバ３１０に接続するインタフェイスである。ディスプレイ４１４は視覚的な出力機器の例である。サーバ３１０には、さらに、スピーカなどの音声的な出力機器が、適宜のインタフェイスを介して接続されていてもよい。
【０１２１】
駆動装置４０７は、コンピュータ読み取り可能な記憶媒体４１５の駆動装置である。記憶媒体４１５の例は、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク、磁気ディスク、半導体メモリを用いたメモリカードなどである。
【０１２２】
ＣＰＵ４０１が実行するプログラムは、例えば、予めＨＤＤ４０３にインストールされていてもよいし、ネットワーク４１１とネットワークＩＦ４０４を介してＨＤＤ４０３にダウンロードされてもよい。あるいは、プログラムは、記憶媒体４１５に記憶されて提供され、駆動装置４０７を介して読み取られ、ＨＤＤ４０３にインストールされてもよい。
【０１２３】
なお、記憶媒体４１５、ＲＡＭ４０２、およびＨＤＤ４０３は、いずれも、コンピュータ読み取り可能で有形の（tangible）媒体の例である。記憶媒体４１５、ＲＡＭ４０２、およびＨＤＤ４０３は、信号搬送波のような一時的な（transitory）媒体ではない。
【０１２４】
また、サーバ３１０に関して、図３と図４の関係を説明すると以下のとおりである。
図３のサーバ３１０が保持するＤＢのうち、静的なＤＢは、予めＨＤＤ４０３に記憶され、必要に応じてＲＡＭ４０２にデータが読み込まれる。具体的には、端末管理ＤＢ３１２、センサ位置ＤＢ３１７、センサ種別ＤＢ３１８、センサユニット別アラーム条件ＤＢ３１９、アラーム条件ＤＢ３２０、サンプリング周期ＤＢ３２１、およびデータ量条件ＤＢ３２２は、予めＨＤＤ４０３に記憶される。また、動的にエントリが増えるＧＰＳログＤＢ３１１とセンサログＤＢ３１５も、ＨＤＤ４０３に記憶されていてもよい。なお、データ収集のたびに書き換えられる収集日ＤＢ３１４は、ＨＤＤ４０３に記憶されていてもよいし、ＲＡＭ４０２に記憶されていてもよい。
【０１２５】
そして、ＧＰＳログ処理部３１３、センサログ処理部３１６、アラーム距離決定部３２３、端末・センサ間距離計算部３２４、距離比較部３２５、およびアラーム決定部３２６は、ＣＰＵ４０１がプログラムを実行することにより実現される。また、通信部３２７は、ネットワークＩＦ４０４により実現される。
【０１２６】
ここで図４の説明に戻る。センサユニット３５０は、バッテリ４２１によって駆動され、ＭＰＵ（Microprocessor Unit）４２２、ＲＡＭ４２３、およびフラッシュＲＯＭ（Read Only Memory）４２４を有する。なお、図４では紙面の都合上、バッテリ４２１とＭＰＵ４２２のみが線で結ばれているが、センサユニット３５０内の各部へは、いずれもバッテリ４２１から電力が供給される。
【０１２７】
ＭＰＵ４２２は、プログラムをＲＡＭ４２３にロードし、ＲＡＭ４２３をワーキングエリアとしても使いながら、プログラムを実行する。また、フラッシュＲＯＭ４２４は、プログラムや各種ＤＢを保持する。フラッシュＲＯＭ４２４の代わりに（あるいはフラッシュＲＯＭ４２４と組み合わせて）、ＨＤＤなどの他の種類の不揮発性記憶装置が使われてもよい。
【０１２８】
また、センサユニット３５０は、必要に応じて、適宜の種類の適宜の個数のセンサを有し、各センサはセンサＩＦを介してＭＰＵ４２２に接続される。図４の例では、具体的には、センサユニット３５０は、温度センサ４２５、湿度センサ４２６、温度センサ４２７、および人感センサ４２８を有する。
【０１２９】
センサユニット３５０は、さらに、センサＩＦ４２９〜４３３を有する。なお、紙面の都合上、図４には５個のセンサＩＦ４２９〜４３３のみが図示されているが、センサユニット３５０は６個以上のセンサＩＦを有していてもよいし、４個以下のセンサＩＦを有していてもよい。
【０１３０】
そして、温度センサ４２５はセンサＩＦ４２９を介して、湿度センサ４２６はセンサＩＦ４３０を介して、温度センサ４２７はセンサＩＦ４３１を介して、人感センサ４２８はセンサＩＦ４３２を介して、それぞれＭＰＵ４２２に接続されている。他方、センサＩＦ４３３は余っており、センサＩＦ４３３には何のセンサも接続されていない。
【０１３１】
センサユニット３５０はさらに、端末３７０との間で近距離無線通信を行う近距離無線通信機４３４を有する。電力消費を抑えるため、ＭＰＵ４２２は、バッテリ４２１から近距離無線通信機４３４への電力供給を制御することが望ましい。
【０１３２】
また、センサユニット３５０に関して、図３と図４の関係を説明すると以下のとおりである。
図３の各種センサ３５１は、具体的には、例えば、図４の温度センサ４２５、湿度センサ４２６、温度センサ４２７、および人感センサ４２８を含んでもよい。また、センサログＤＢ３５２は、フラッシュＲＯＭ４２４に記憶される。そして、センサログ処理部３５３は、ＭＰＵ４２２がプログラムを実行することにより実現される。また、通信部３５４は、近距離無線通信機４３４により実現される。
【０１３３】
ここで図４の説明に戻る。端末３７０は、バッテリ４４１によって駆動され、ＭＰＵ４４２、ＲＡＭ４４３、およびフラッシュＲＯＭ４４４を有する。なお、図４では紙面の都合上、バッテリ４４１とＭＰＵ４４２のみが線で結ばれているが、端末３７０内の各部へは、いずれもバッテリ４４１から電力が供給される。
【０１３４】
ＭＰＵ４４２は、プログラムをＲＡＭ４４３にロードし、ＲＡＭ４４３をワーキングエリアとしても使いながら、プログラムを実行する。また、フラッシュＲＯＭ４４４は、プログラムや各種ＤＢを保持する。フラッシュＲＯＭ４４４の代わりに（あるいはフラッシュＲＯＭ４４４と組み合わせて）、ＨＤＤなどの他の種類の不揮発性記憶装置が使われてもよい。
【０１３５】
また、端末３７０は、センサユニット３５０との間で近距離無線通信を行う近距離無線通信機４４５を有し、ＧＰＳ衛星から測位信号を受信してＧＰＳ情報を取得するＧＰＳ受信機４４６も有する。端末３７０はさらに、３Ｇ通信網（つまりネットワーク４１１の一部）を介した通信を行う３Ｇ通信機４４７を有する。
【０１３６】
また、端末３７０は、ユーザインタフェイス用の１つ以上の装置を有する。具体的には、図４の例では、端末３７０は、ユーザインタフェイス用にＬＥＤ（Light Emitting Diode）４４８、ブザー４４９、振動モータ４５０、およびディスプレイ４５１を有する。
【０１３７】
もちろん、端末３７０は、例えばボタンやキーボードなどの入力機器をさらに有していてもよいし、スピーカとマイクをさらに有していてもよい。また、ディスプレイ４５１がポインティングデバイスを兼ねていてもよい（つまり、ディスプレイ４５１がタッチスクリーンであってもよい）。
【０１３８】
また、端末３７０に関して、図３と図４の関係を説明すると以下のとおりである。
ＧＰＳ情報取得部３７１はＧＰＳ受信機４４６により実現され、ＧＰＳログＤＢ３７２はフラッシュＲＯＭ４４４に記憶される。また、サーバ通信部３７３は３Ｇ通信機４４７により実現される。なお、実施形態によっては、３Ｇ通信機４４７が、複数の基地局からの受信電波強度と、それら複数の基地局の既知の位置に基づいて、端末３７０の位置を計算することで、ＧＰＳ情報取得部３７１と類似の機能を実現してもよい。
【０１３９】
アラーム処理部３７４は、プログラムを実行するＭＰＵ４４２と、ＭＰＵ４４２の制御にしたがってアラームを発するモジュール（つまり、ＬＥＤ４４８、ブザー４４９、振動モータ４５０、およびディスプレイ４５１のうちの少なくとも１つ）により、実現される。そして、センサ通信部３７５は近距離無線通信機４４５により実現され、センサログＤＢ３７６はフラッシュＲＯＭ４４４に記憶される。また、センサログ処理部３７７は、ＭＰＵ４４２がプログラムを実行することにより実現される。
【０１４０】
ところで、図１のデータ収集システム１００が図２の圃場２０１に適用される場合に、具体的には図３〜４のような構成が好適である理由について説明すれば、以下のとおりである。
【０１４１】
図１のデータ記憶装置１０２を図２の圃場２０１のような広い屋外に設置する場合、金銭的なコストの観点から、コンピュータ１０１と通信する機能をデータ記憶装置１０２に実装することが難しいことが多い。その理由は次のとおりである。
【０１４２】
屋外に設置される装置がコンピュータ１０１と通信するには、例えば、３Ｇ通信網による通信機能または無線ＬＡＮによる通信機能を利用することが考えられる。しかし、３Ｇ通信網による通信機能を利用するには、電話会社等の通信プロバイダとの契約料金がかかり、通信料金もかかる。
【０１４３】
また、無線ＬＡＮによる通信機能を利用するには、中継用のアクセスポイントを設置する必要がある。しかし、例えば非常に広い範囲に散在する複数の圃場に複数のセンサユニットを設置しようとする場合、多数のアクセスポイントが必要になるかもしれず、中継用のインフラストラクチャの整備および保守にかかる金銭的・人的なコストは、実用上は無視し難い。
【０１４４】
よって、実用上、コンピュータ１０１と通信する機能をデータ記憶装置１０２に実装することが難しい場合がある。
他方、近年では農業に従事する作業者の多くが、携帯電話やスマートフォンなどの３Ｇ通信機能を備えた端末を作業中にも携帯しており、何らかの端末のユーザでもある。よって、コンピュータ１０１（つまりサーバ３１０）との間の通信は、ユーザが携帯する端末の機能を使うことで、新たな金銭的コストをそれほどかけずに実現可能である。
【０１４５】
また、近年の携帯電話やスマートフォンなどの端末は、ＧＰＳ機能を有するものが多い。よって、ユーザの持つ既存の端末にプログラムをインストールすることで、図３の端末３７０の機能を実現することができる。すなわち、端末３７０の導入に関するコストは低い。
【０１４６】
さらに、近年の携帯電話やスマートフォンなどの端末の多くは、近距離無線通信機能も有する。よって、既存の近距離無線通信機能を、端末とデータ記憶装置１０２（つまりセンサユニット３５０）の間の通信のために利用することができる。
【０１４７】
そして、近距離無線通信であれば、当然アクセスポイントなどのインフラストラクチャは不要である。よって、センサユニット３５０に近距離無線通信機能を持たせても、データ収集システム３００全体としてはさほど導入コストはかからない。
【０１４８】
また、有線通信と比べた近距離無線通信の利点の一つは、ユーザに「ケーブルを接続する」などの意識的な操作をさせなくても、装置同士（例えば端末３７０とセンサユニット３５０）が自動的に通信を開始することが可能なことである。つまり、図４に示すように近距離無線通信を端末３７０とセンサユニット３５０の間の通信に利用することで、ユーザがデータ収集に関与するための負荷を軽減することができる。
【０１４９】
したがって、図３〜４のシステム構成は、データ収集システム３００の導入と保守にかかる金銭的・人的なコストの観点からも、ユーザの負荷軽減という観点からも、圃場２０１のような広い屋外での利用に好適である。
【０１５０】
続いて、図５〜８を参照して、データ収集システム３００内の各種ＤＢの例について説明する。
図５〜６は、サーバ３１０が保持する静的なＤＢの例を示す図である。
【０１５１】
図５に示すように、端末管理ＤＢ３１２の各エントリは、データ収集システム３００内の各端末３７０に対応し、「端末ＩＤ」と「ユーザ氏名」というフィールドを有する。端末ＩＤは、データ収集システム３００内で端末３７０を一意に識別する識別子（ＩＤ（identifier））を示し、作業者名は、端末ＩＤで識別される当該端末３７０を携帯するユーザの氏名を示す。
【０１５２】
図５の例によれば、端末ＩＤが「０００１」の端末３７０のユーザは「山田太郎」という氏名であり、端末ＩＤが「０００２」の端末３７０のユーザは「佐藤二郎」という氏名である。端末管理ＤＢ３１２の各エントリは、端末３７０とユーザを管理するための他のフィールド（例えば、端末３７０で利用可能な電子メールアドレスや、ユーザの属性などのフィールド）をさらに含んでもよい。端末管理ＤＢ３１２は、例えば、端末３７０がディスプレイ４５１に表示するアラームの内容を指定するために、サーバ３１０のアラーム決定部３２６により参照されてもよい。
【０１５３】
なお、端末管理ＤＢ３１２は静的なＤＢだが、端末３７０が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存の端末３７０の設定の変更または端末３７０のユーザの属性の変更などがあれば、それに応じて既存のエントリが変更される。
【０１５４】
また、図５に示すように、センサ位置ＤＢ３１７の各エントリは、データ収集システム３００内の各センサユニット３５０に対応し、「センサユニットＩＤ」と「緯度」と「経度」というフィールドを有する。センサユニットＩＤは、データ収集システム３００内でセンサユニット３５０を一意に識別する識別子を示す。また、緯度と経度は、センサユニットＩＤで識別される当該センサユニット３５０が設置された場所を示す。
【０１５５】
図５の例によれば、センサユニットＩＤが「０００１」のセンサユニット３５０は、北緯３５．４４３５４度・東経１３９．３１４１度の場所に設置されている。また、センサユニットＩＤが「０００２」のセンサユニット３５０は、北緯３５．４３９８９度・東経１３９．３０９５度の場所に設置されている。図５には、他にもセンサユニットＩＤが「０００３」と「００１０」のセンサユニット３５０についてのエントリが例示されている。
【０１５６】
なお、センサ位置ＤＢ３１７は静的なＤＢだが、センサユニット３５０が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存のセンサユニット３５０が移動されれば、それに応じて既存のエントリが変更される。
【０１５７】
また、図５に示すように、センサ種別ＤＢ３１８の各エントリは、データ収集システム３００内の各センサユニット３５０に対応し、「センサユニットＩＤ」と「センサＮｏ．１」〜「センサＮｏ．１０」というフィールドを有する。なお、図５では紙幅の都合上「センサＮｏ．４」〜「センサＮｏ．９」のフィールドの図示は省略されている。
【０１５８】
図５のセンサ種別ＤＢ３１８の例は、センサユニット３５０が、人感センサを除いて最大で１０個のセンサを持ち得る場合の例である。そのため、図５では、各エントリが１０個のセンサにそれぞれ対応するフィールドを含む。
【０１５９】
センサユニットＩＤは、センサ位置ＤＢ３１７と同様に、センサユニット３５０の識別子を示す。また、センサＮｏ．ａ（１≦ａ≦１０）は、センサユニットＩＤで識別される当該センサユニット３５０のａ番目のセンサ（つまり、サーバ３１０による収集対象のデータを生成するセンサのうちａ番目のもの）の種類を示す。
【０１６０】
図５の例によれば、センサユニットＩＤが「０００１」のセンサユニット３５０は、１番目のセンサとして気温センサを有し、２番目のセンサとして湿度センサを有し、３番目のセンサとして土中温度センサを有する。また、センサユニットＩＤが「０００１」のセンサユニット３５０の「センサＮｏ．１０」フィールドに「−」と示されているのは、当該センサユニット３５０が１０番目のセンサを持たないことを示す。同様に、図５の例によれば、センサユニットＩＤが「０００２」のセンサユニット３５０は、１番目のセンサとして湿度センサを有し、２番目のセンサとして土中温度センサを有し、３番目のセンサとして土中水分センサを有するが、１０番目のセンサは持たない。
【０１６１】
なお、センサ種別ＤＢ３１８は静的なＤＢだが、センサユニット３５０自体が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存のセンサユニット３５０に対してセンサの追加・削除・交換などが行われれば、それに応じて既存のエントリが変更される。
【０１６２】
また、図６に示すように、センサユニット別アラーム条件ＤＢ３１９の各エントリは、データ収集システム３００内の各センサユニット３５０に対応し、「センサユニットＩＤ」と「アラーム条件ＩＤ」というフィールドを有する。センサユニットＩＤは、センサ位置ＤＢ３１７と同様にセンサユニット３５０の識別子を示す。また、アラーム条件ＩＤは、センサユニットＩＤで識別される当該センサユニット３５０についてのアラーム距離を求めるのに用いる「アラーム条件」の識別子である。なお、以下の説明において、「アラーム条件」とは、経過時間に応じたアラーム距離を定義する条件のことである。
【０１６３】
第１実施形態では、複数のアラーム条件が利用可能である。そして、第１実施形態では、センサユニット３５０ごとに、「サーバ３１０のアラーム距離決定部３２３は、どのアラーム条件にしたがって当該センサユニット３５０についてのアラーム距離を取得するか」ということが設定可能である。例えば、センサユニット３５０に搭載されているセンサの種類と数、各センサが単位時間あたりに生成するデータの量、センサユニット３５０のフラッシュＲＯＭ４２４の容量などに応じて、適切なアラーム条件は異なる。
【０１６４】
そのため、第１実施形態では、センサユニット別アラーム条件ＤＢ３１９により、センサユニット３５０ごとにアラーム条件が管理される。図６の例によれば、センサユニットＩＤが「０００１」のセンサユニット３５０用には、「０２」というアラーム条件ＩＤのアラーム条件が使われる。また、センサユニットＩＤが「０００２」のセンサユニット３５０用には、「０１」というアラーム条件ＩＤのアラーム条件が使われる。
【０１６５】
なお、センサユニット別アラーム条件ＤＢ３１９は静的なＤＢだが、センサユニット３５０自体が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存のセンサユニット３５０に対してセンサの追加・削除・交換・設定変更、あるいはフラッシュＲＯＭ４２４の増設などが行われれば、それに応じて既存のエントリが変更される。
【０１６６】
また、図６に示すように、アラーム条件ＤＢ３２０の各エントリは、各アラーム条件に対応し、「アラーム条件ＩＤ」と「条件数」というフィールドを有する。また、第１実施形態では、各アラーム条件が、１〜４個の条件の組み合わせにより表現されるので、アラーム条件ＤＢ３２０の各エントリは、「条件ｃ」と「条件ｃ距離」（１≦ｃ≦４）というフィールドも有する。
【０１６７】
もちろん、アラーム条件を表現するための条件の個数の上限は、実施形態に応じた適宜の数でよく、４でなくてもよい。そして、上限に応じて、アラーム条件ＤＢ３２０の形式も適宜変形されてよい。
【０１６８】
アラーム条件ＩＤは、センサユニット別アラーム条件ＤＢ３１９と同様にアラーム条件の識別子を示す。また、条件数は、アラーム条件ＩＤで識別される当該アラーム条件がいくつの条件の組み合わせで表されるかを示す。そして、条件数がＣのとき、１≦ｃ≦Ｃなる各ｃについて、「条件ｃ」と「条件ｃ距離」のペアは、経過時間とアラーム距離のペアで定義される条件を示す。
【０１６９】
例えば、図６の例によれば、アラーム条件ＩＤが「０１」のアラーム条件は、４つの条件の組み合わせで表される。そして、１つ目の条件は「１日」と「１ｍ」のペアで定義され、２つ目の条件は「３日」と「５０ｍ」のペアで定義され、３つ目の条件は「７日」と「２００ｍ」のペアで定義され、４つ目の条件は「１０日」と「５００ｍ」のペアで定義される。より具体的には、アラーム条件ＩＤが「０１」のアラーム条件は、以上の４つの条件の組み合わせにより、以下のことを示す（なお、説明の便宜上、前回のデータの収集からの経過時間（より具体的には、１日単位で数えた経過時間である経過日数）をｐとする）。
・ｐ＜１日ならば、アラーム距離は０ｍ
・１日≦ｐ＜３日ならば、アラーム距離は１ｍ
・３日≦ｐ＜７日ならば、アラーム距離は５０ｍ
・７日≦ｐ＜１０日ならば、アラーム距離は２００ｍ
・１０日≦ｐならば、アラーム距離は５００ｍ
【０１７０】
同様に、図６の例によれば、アラーム条件ＩＤが「０２」のアラーム条件は、３つの条件の組み合わせにより、以下のことを示す。
・ｐ＜１日ならば、アラーム距離は０ｍ
・１日≦ｐ＜３日ならば、アラーム距離は１ｍ
・３日≦ｐ＜７日ならば、アラーム距離は２００ｍ
・７日＜ｐならば、アラーム距離は６００ｍ
【０１７１】
以上の２つのアラーム条件を比較すると、アラーム条件ＩＤが「０１」のアラーム条件の方が、より細かい粒度でアラーム距離が規定されている。また、同じ経過時間に対しては、アラーム条件ＩＤが「０１」のアラーム条件によって決まるアラーム距離は、アラーム条件ＩＤが「０２」のアラーム条件によって決まるアラーム距離以下である。
【０１７２】
例えば、経過時間が同じ５日でも、アラーム条件ＩＤが「０１」と「０２」のアラーム条件がそれぞれ適用されるセンサユニット３５０に関するアラーム距離は、５０ｍと２００ｍであり、後者のアラーム距離の方が長い。すなわち、アラーム条件ＩＤが「０２」のアラーム条件は、同じ経過時間に対してデータ収集の緊急度がより高いセンサユニット３５０に好適である。例えば、１日当たりに生成するデータの量が多いセンサユニット３５０ほど、同じ経過時間に対してデータ収集の緊急度がより高い。
【０１７３】
なお、アラーム条件ＤＢ３２０は静的なＤＢだが、アラーム条件が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存のアラーム条件の定義が変更されれば、それに応じて既存のエントリが変更される。
【０１７４】
また、図６に示すように、サンプリング周期ＤＢ３２１の各エントリは、データ収集システム３００内の各センサユニット３５０に対応し、「センサユニットＩＤ」と「センサＮｏ．１」〜「センサＮｏ．１０」というフィールドを有する。なお、図６では紙幅の都合上「センサＮｏ．４」〜「センサＮｏ．９」のフィールドの図示は省略されている。
【０１７５】
図６のサンプリング周期ＤＢ３２１の例は、センサユニット３５０が、人感センサを除いて最大で１０個のセンサを持ち得る場合の例である。そのため、図６では、各エントリが１０個のセンサにそれぞれ対応するフィールドを含む。つまり、図５のセンサ種別ＤＢ３１８と図６のサンプリング周期ＤＢ３２１のフィールドの数は同じである。
【０１７６】
センサユニットＩＤは、センサ位置ＤＢ３１８と同様に、センサユニット３５０の識別子を示す。また、センサＮｏ．ａ（１≦ａ≦１０）は、センサユニットＩＤで識別される当該センサユニット３５０のａ番目のセンサが、データをサンプリングするサンプリング周期を示す（単位は秒）。サンプリング周期は、換言すれば、センサが気温などの計測対象を計測してデータを生成する周期である。
【０１７７】
図６の例によれば、センサユニットＩＤが「０００１」のセンサユニット３５０においては、１番目〜３番目のセンサがいずれも９００秒周期でデータを生成する。なお、１番目〜３番目のセンサの種別は、図５のセンサ種別ＤＢ３１８に示すとおり、気温センサ、湿度センサ、および土中温度センサである。
【０１７８】
また、図５に示すように、センサユニットＩＤが「０００１」のセンサユニット３５０は１０番目のセンサを持たない。よって、図６のサンプリング周期ＤＢ３２１でも、センサユニットＩＤが「０００１」のエントリの「センサＮｏ．１０」フィールドの値は無効な値（例えばＮＵＬＬ。図６では「−」と表記）に設定されている。
【０１７９】
また、図６の例によれば、センサユニットＩＤが「０００２」のセンサユニット３５０においては、１番目〜３番目のセンサがいずれも３６００秒周期でデータを生成する。なお、１番目〜３番目のセンサの種別は、図５のセンサ種別ＤＢ３１８に示すとおり、湿度センサ、土中湿度センサ、および土中水分センサである。
【０１８０】
サンプリング周期ＤＢ３２１は静的なＤＢだが、センサユニット３５０自体が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存のセンサユニット３５０に対してセンサの追加・削除・交換・サンプリング周期の設定変更などが行われれば、それに応じて既存のエントリが変更される。
【０１８１】
また、図６に示すように、データ量条件ＤＢ３２２の各エントリは、各アラーム条件に対応し、「アラーム条件ＩＤ」と「データ量下限」と「データ量上限」というフィールドを有する。
【０１８２】
アラーム条件ＩＤは、アラーム条件ＤＢ３２０などと同様に、アラーム条件の識別子を示す。データ量下限とデータ量上限のペアは、センサユニット３５０が１日あたりに生成するデータの量の範囲を示す。各エントリは、「１日あたりに生成するデータの量が、データ量下限とデータ量上限のペアで表される範囲に該当するセンサユニット３５０にとっては、アラーム条件ＩＤで識別されるアラーム条件が好適である」ということを示す。
【０１８３】
例えば、図６の例によれば、アラーム条件ＩＤが「０１」のアラーム条件は、１日あたりに生成するデータの量が０以上２４０未満のセンサユニット３５０に好適である。そして、アラーム条件ＩＤが「０２」のアラーム条件は、１日あたりに生成するデータの量が２４０以上１４４０未満のセンサユニット３５０に好適である。
【０１８４】
なお、データ量条件ＤＢ３２２におけるデータ量下限とデータ量上限の単位は、実施形態に応じて任意である。第１実施形態では説明の簡略化のため、「１つのセンサによる１回の計測によって固定長の記憶領域が消費される」と仮定し、固定長の記憶領域を１単位として、データ量下限とデータ量上限を表している。実施形態によっては、各センサによる１回の計測で消費される記憶領域のバイト数をセンサ別に管理するＤＢをさらにサーバ３１０が有してもよく、データ量条件ＤＢ３２２における単位が１バイトであってもよい。
【０１８５】
サーバ３１０は、サンプリング周期ＤＢ３２１にエントリが追加されると、追加されたエントリのセンサユニットＩＤに関して、データ量条件ＤＢ３２２に基づいてアラーム条件ＩＤを決定する。そして、サーバ３１０は、センサユニット別アラーム条件ＤＢ３１９に新規エントリを追加し、新規エントリに、上記センサユニットＩＤと上記で決定したアラーム条件ＩＤを設定する。
【０１８６】
また、サーバ３１０は、サンプリング周期ＤＢ３２１のいずれかのエントリで１つ以上のサンプリング周期が変更されると、当該エントリのセンサユニットＩＤに関して、データ量条件ＤＢ３２２に基づいて、アラーム条件ＩＤを決定しなおす。そして、サーバ３１０は、再決定したアラーム条件ＩＤを、センサユニット別アラーム条件ＤＢ３１９において上記センサユニットＩＤに対応するエントリのアラーム条件ＩＤとして設定する。
【０１８７】
エントリの追加とサンプリング周期の変更のいずれの場合にせよ、サーバ３１０は、サンプリング周期ＤＢ３２１とデータ量条件ＤＢ３２２を参照して、具体的には以下の式（１）にしたがってアラーム条件ＩＤを決定する。
【０１８８】
【数１】
【０１８９】
ここで、ｄａｔａｉは、データ収集システム３００内でｉ番目のセンサユニット３５０が１日あたりに生成するデータ量である。データ量ｄａｔａｉの単位は、データ量条件ＤＢ３２２で使われている単位と同じである。
【０１９０】
また、Ａｉは、ｉ番目のセンサユニット３５０が有する人感センサ以外のセンサ（つまり、サーバ３１０が収集する対象のデータを生成するセンサ）の数である。そして、ｐｅｒｉｏｄｉ，ａは、ｉ番目のセンサユニット３５０のａ番目のセンサ（１≦ａ≦Ａｉ）のサンプリング周期である。サーバ３１０は、サンプリング周期ＤＢ３２１を参照することで、ｉ番目のセンサユニット３５０に関して、センサの数Ａｉと各センサのサンプリング周期ｐｅｒｉｏｄｉ，ａ（１≦ａ≦Ａｉ）を認識することができる。
【０１９１】
なお、式（１）におけるａｍｏｕｎｔｉ，ａは、ｉ番目のセンサユニット３５０のａ番目のセンサが１回の計測で生成するデータ量を示す。データ量ａｍｏｕｎｔｉ，ａの単位も、データ量条件ＤＢ３２２で使われている単位と同じである。また、データ量条件ＤＢ３２２に関して上記で説明した「１つのセンサによる１回の計測によって固定長の記憶領域が消費される」という仮定より、第１実施形態では、すべてのｉとａの組み合わせに対して、ａｍｏｕｎｔｉ，ａ＝１である。しかし、もちろん実施形態によっては、データ量ａｍｏｕｎｔｉ，ａは、ｉとａに応じて可変のこともある。
【０１９２】
そして、サンプリング周期ＤＢ３２１ではサンプリング周期ｐｅｒｉｏｄｉ，ａが秒単位で表されているので、ｉ番目のセンサユニット３５０が１日あたりに生成するデータ量ｄａｔａｉは、式（１）のとおりである。サーバ３１０は、サンプリング周期ＤＢ３２１を参照して式（１）にしたがってデータ量ｄａｔａｉを計算し、データ量ｄａｔａｉが該当する範囲をデータ量条件ＤＢ３２２から探す。そして、サーバ３１０は、データ量条件ＤＢ３２２で見つかったエントリのアラーム条件ＩＤを、ｉ番目のセンサユニット３５０用のアラーム条件ＩＤとして決定し、決定したアラーム条件ＩＤを、センサユニット別アラーム条件ＤＢ３１９に設定する。
【０１９３】
例えば、ｉ番目のセンサユニット３５０のセンサユニットＩＤが「０１」であり、計算されたデータ量ｄａｔａｉが３８４であったとする。すると、２４０≦３８４＜１４４０なので、データ量条件ＤＢ３２２より、センサユニットＩＤが「０１」のセンサユニット３５０に適切なアラーム条件は、「０２」というアラーム条件ＩＤのものである。よって、サーバ３１０は、センサユニット別アラーム条件ＤＢ３１９において、「０１」というセンサユニットＩＤと、以上のようにして決定した「０２」というアラーム条件ＩＤを対応づける。
【０１９４】
さて、図７は、センサに関連して動的に変化するＤＢの例を示す図である。
図７に示すように、サーバ３１０内の収集日ＤＢ３１４の各エントリは、データ収集システム３００内の各センサユニット３５０に対応し、「センサユニットＩＤ」と「収集日」というフィールドを有する。センサユニットＩＤはセンサ位置ＤＢ３１７などと同様にセンサユニット３５０の識別子を示す。収集日は、センサユニットＩＤで識別される当該センサユニット３５０からサーバ３１０がデータを前回収集した日付を示す。もちろん、実施形態によっては、収集日の代わりに収集日時が使われてもよい。
【０１９５】
図７の例によれば、センサユニットＩＤが「０００１」のセンサユニット３５０からサーバ３１０がデータを前回収集したのは２０１１年３月１日である。また、センサユニットＩＤが「０００２」のセンサユニット３５０からサーバ３１０がデータを前回収集したのは２０１１年３月３日である。
【０１９６】
そして、センサユニットＩＤが「０００３」のセンサユニット３５０からサーバ３１０がデータを前回収集したのは２０１１年３月２日である。また、センサユニットＩＤが「００１０」のセンサユニット３５０からサーバ３１０がデータを前回収集したのは２０１１年２月２０日である。
【０１９７】
収集日ＤＢ３１４は動的に変化するＤＢである。具体的には、サーバ３１０がいずれかの端末３７０を介していずれかのセンサユニット３５０からデータを収集するたびに、当該センサユニット３５０に対応するエントリの収集日が更新される。また、もちろん、センサユニット３５０がデータ収集システム３００に追加または削除されれば、それに応じて収集日ＤＢ３１４にもエントリが追加または削除される。
【０１９８】
また、図７に示すように、センサユニット３５０内のセンサログＤＢ３５２には、当該センサユニット３５０の各種センサ３５１がデータを生成するたびにエントリが追加される。センサログＤＢ３５２の各エントリは、「取得日時」と「センサＮｏ．１」〜「センサＮｏ．１０」というフィールドを有する。なお、図７では紙幅の都合上「センサＮｏ．４」〜「センサＮｏ．１０」のフィールドの図示は省略されている。
取得日時は、各種センサ３５１が計測を行ってデータを生成した日時を示す。また、センサＮｏ．ａ（１≦ａ≦１０）は、ａ番目のセンサが取得日時に計測した計測値を示す。
【０１９９】
図７のセンサログＤＢ３５２の例は、センサユニットＩＤが「０００１」のセンサユニット３５０内のセンサログＤＢ３５２の例である。そして、図７のセンサログＤＢ３５２の例によれば、２０１１年２月２１日の３時には、１番目のセンサが「２．１」という計測値を取得し、２番目のセンサが「７０」という計測値を取得し、３番目のセンサが「５．０」という計測値を取得している。また、２０１１年２月２１日の３時１５分には、１番目のセンサが「２．３」という計測値を取得し、２番目のセンサが「７３」という計測値を取得し、３番目のセンサが「５．３」という計測値を取得している。
【０２００】
なお、図６のサンプリング周期ＤＢ３２１に示すように、センサユニットＩＤが「０００１」のセンサユニット３５０における１〜３番目のセンサのサンプリング周期は同じ９００秒である。そのため、図７のセンサログＤＢ３５２の例では、１つの同じエントリの「センサＮｏ．１」〜「センサＮｏ．３」の各フィールドに計測値が記録されている。
【０２０１】
しかし、センサ間のサンプリング周期が異なるセンサユニット３５０においては、センサログＤＢ３５２において、個々のセンサのサンプリング周期に応じて、ＮＵＬＬなどの無効な値が記録されることもある。例えば、仮に２番目のセンサのサンプリング周期が１８００秒とすれば、図７のセンサログＤＢ３５２の例の２番目のエントリの「センサＮｏ．２」のフィールドには、無効な値が記録される。
【０２０２】
もちろん、実施形態によっては、センサログＤＢ３５２は、取得日時と、１つのセンサを識別する識別子と、当該１つのセンサが計測した計測値という３つのフィールドを持つ形式であってもよい。
【０２０３】
また、図７に示すように、端末３７０内のセンサログＤＢ３７６の各エントリは、端末３７０がセンサユニット３５０から受信したセンサログを、当該センサユニット３５０の識別子および受信時刻と対応づけている。具体的には、センサログＤＢ３７６の各エントリは、「センサユニットＩＤ」、「端末収集日時」、「取得日時」、「センサＮｏ．１」〜「センサＮｏ．１０」というフィールドを有する。
【０２０４】
センサユニットＩＤはセンサログの送信元のセンサユニット３５０の識別子を示し、端末収集日時は、センサログを端末３７０がセンサユニット３５０から受信した日時を示す。「取得日時」と「センサＮｏ．１」〜「センサＮｏ．１０」の各フィールドは、端末３７０が受信したセンサログが元々センサユニット３５０において記憶されていたセンサログＤＢ３５２と同様である。
【０２０５】
図７には、センサユニットＩＤが「０００１」のセンサユニット３５０から受信された２つのエントリが図示されている。つまり、図７に例示したセンサログＤＢ３７６の２つのエントリは、「図７に例示したセンサログＤＢ３５２の２つのエントリを含むセンサログを、端末３７０がセンサユニット３５０から２０１１年３月１日８時５９分に受信した」ということを示す。
【０２０６】
なお、センサログＤＢ３７６には、センサ通信部３７５を介してセンサログ処理部３７７がいずれかのセンサユニット３５０からセンサログを受信するたびに、受信したセンサログに含まれるエントリと同数のエントリが追加される。
【０２０７】
また、図７に示すように、サーバ３１０内のセンサログＤＢ３１５の各エントリは、端末３７０からサーバ３１０が受信したセンサログを、当該端末３７０の識別子および受信日時と対応づけている。具体的には、センサログＤＢ３１５各エントリは、「端末ＩＤ」、「サーバ収集日時」、「センサユニットＩＤ」、「端末収集日時」、「取得日時」、および「センサＮｏ．１」〜「センサＮｏ．１０」というフィールドを有する。
【０２０８】
端末ＩＤは、センサログの送信元の端末３７０の識別子を示し、サーバ収集日時は、端末３７０からサーバ３１０がセンサログを受信した日時を示す。そして、「センサユニットＩＤ」、「端末収集日時」、「取得日時」、および「センサＮｏ．１」〜「センサＮｏ．１０」の各フィールドは、サーバ３１０が受信したセンサログが元々端末３７０において記憶されていたセンサログＤＢ３７６と同様である。
【０２０９】
図７には、端末ＩＤが「０００３」の端末３７０を介してサーバ３１０が収集した２つのエントリが図示されている。つまり、図７に例示したセンサログＤＢ３１５の２つのエントリは、図７に例示したセンサログＤＢ３７６の２つのエントリに対応する。図７の例によれば、サーバ３１０は、端末ＩＤが「０００３」の端末３７０から、２０１１年３月１日９時にセンサログを受信している。
【０２１０】
なお、センサログＤＢ３１５には、センサログ処理部３１６が通信部３２７を介していずれかの端末３７０からセンサログを受信するたびに、受信されたセンサログに含まれるエントリと同数のエントリが追加される。
【０２１１】
さて、図８は、端末の移動につれて動的に変化するＤＢの例を示す図である。
図８に示すように、端末３７０内のＧＰＳログＤＢ３７２の各エントリは、ある時点でＧＰＳ情報取得部３７１が取得したＧＰＳ情報に対応し、「取得日時」と「緯度」と「経度」というフィールドを有する。取得日時は、ＧＰＳ情報取得部３７１がＧＰＳ情報を取得した日時を示す。また、端末３７０の位置を示すＧＰＳ情報は、具体的には緯度と経度により表される。そして、ＧＰＳログＤＢ３７２の１つ以上のエントリのかたまりが、ＧＰＳログとして端末３７０からサーバ３１０に送信される。
【０２１２】
図８には、端末ＩＤが「０００３」の端末３７０におけるＧＰＳログＤＢ３７２が例示されている。図８の例によれば、当該端末３７０のＧＰＳ情報取得部３７１は、２０１１年２月２１日８時１分に、北緯３５．４４３５４度・東経１３９．３１４１度というＧＰＳ情報を取得している。また、図８の例によれば、当該端末３７０のＧＰＳ情報取得部３７１は、２０１１年２月２１日８時２分に、北緯３５．４４３５３度・東経１３９．３１４２度というＧＰＳ情報を取得している。
【０２１３】
なお、ＧＰＳログＤＢ３７２には、ＧＰＳ情報取得部３７１がＧＰＳ情報を取得するたびにエントリが追加される。ＧＰＳ情報取得部３７１は、サーバ通信部３７３を介してサーバ３１０にＧＰＳログを送信した後、送信済みのＧＰＳログ（つまり送信済みのエントリ）をＧＰＳログＤＢ３７２から消去してもよい。
【０２１４】
また、図８に示すように、サーバ３１０内のＧＰＳログＤＢ３１１の各エントリは、端末３７０からサーバ３１０が受信したＧＰＳログを、当該端末３７０の識別子および受信日時と対応づけている。具体的には、ＧＰＳログＤＢ３１１の各エントリは、「端末ＩＤ」、「収集日時」、「取得日時」、「緯度」、および「経度」というフィールドを有する。
【０２１５】
端末ＩＤは、ＧＰＳログの送信元の端末３７０の識別子を示し、収集日時は、端末３７０からサーバ３１０がＧＰＳログを受信した日時を示す。取得日時と緯度と経度は、サーバ３１０が受信したＧＰＳログが元々端末３７０において記憶されていたＧＰＳログＤＢ３７２と同様である。
【０２１６】
図８には、端末ＩＤが「０００３」の端末３７０から収集された２つのエントリが図示されている。つまり、図８に例示したＧＰＳログＤＢ３１１の２つのエントリは、図８に例示したＧＰＳログＤＢ３７２の２つのエントリに対応する。図８の例によれば、サーバ３１０は、端末ＩＤが「０００３」の端末３７０から、２０１１年２月２１日８時１５分にＧＰＳログを受信している。
【０２１７】
なお、ＧＰＳログＤＢ３１１には、ＧＰＳログ処理部３１３が通信部３２７を介していずれかの端末３７０からＧＰＳログを受信するたびに、受信されたＧＰＳログに含まれるエントリと同数のエントリが追加される。
【０２１８】
図９は、第１実施形態のデータ収集システムの動作シーケンス図である。なお、図９には簡単のため１つのセンサユニット３５０と１つの端末３７０しか図示していないが、複数のセンサユニット３５０と複数の端末３７０がデータ収集システム３００内に存在してもよい。
【０２１９】
センサユニット３５０は、ステップＳ１０１に示すように、ユーザが端末３７０を携帯して近づいてくるのを待ち受ける。つまり、ユーザがセンサユニット３５０の人感センサの検知領域に入ってくるまで、センサユニット３５０は通信部３５４をオフにして待機する。
【０２２０】
他方、端末３７０では、ステップＳ１１１に示すように、ＧＰＳ情報取得部３７１がＧＰＳ情報を定期的に取得し、取得したＧＰＳ情報をＧＰＳログＤＢ３７２に格納する。ＧＰＳ情報取得部３７１は、ＧＰＳ情報の取得を所定回数繰り返す。例えば、ＧＰＳ情報取得部３７１は、１分間隔でＧＰＳ情報を取得してもよく、上記の所定回数は、例えば、１５回であってもよい。
【０２２１】
そして、所定回数ＧＰＳ情報を取得すると、ＧＰＳ情報取得部３７１は、ＧＰＳログＤＢ３７２に格納したＧＰＳログ（すなわち所定回数分のエントリ）を、サーバ通信部３７３を介してステップＳ１１２でサーバ３１０に送信する。
【０２２２】
また、図９では紙面の都合上省略しているが、端末３７０では、以上のステップＳ１１１〜Ｓ１１２の処理が繰り返される。なお、ステップＳ１１１〜Ｓ１１２の処理の詳細は、図１０のフローチャートとともに後述する。
【０２２３】
さて、ステップＳ１１２で送信されたＧＰＳログは、ステップＳ１２２においてサーバ３１０の通信部３２７で受信され、ＧＰＳログ処理部３１３に出力される。また、サーバ３１０では、以上のような端末３７０からのＧＰＳログの受信とは独立して、ステップＳ１２１の処理も行われる。
【０２２４】
例えば、ステップＳ１２１の処理は、圃場２０１での作業が始まる前の、毎朝決まった時刻に行われてもよい。図９の例は、ステップＳ１２１の処理の後にステップＳ１２２でＧＰＳログが受信される例である。
【０２２５】
具体的には、ステップＳ１２１では、アラーム距離決定部３２３が、収集日ＤＢ３１４とセンサユニット別アラーム条件ＤＢ３１９とアラーム条件ＤＢ３２０を参照して、各センサユニット３５０についてアラーム距離を決定する。アラーム距離決定部３２３は、決定した各アラーム距離を例えばＲＡＭ４０２上に記憶する。なお、ステップＳ１２１の処理の詳細は、図１１のフローチャートとともに後述する。
【０２２６】
そして、ステップＳ１２２では、端末３７０からのＧＰＳログを通信部３２７が受信し、受信されたＧＰＳログは、ＧＰＳログ処理部３１３の制御のもと、ＧＰＳログＤＢ３１１に格納される。
【０２２７】
すると、ＧＰＳログの受信を契機として、各センサユニット３５０についてステップＳ１２３〜Ｓ１２４の処理が行われる。
具体的には、ステップＳ１２３で端末・センサ間距離計算部３２４が、ＧＰＳログＤＢ３１１とセンサ位置ＤＢ３１７を参照して、センサユニット３５０と、ＧＰＳログの送信元の端末３７０の間の距離を計算する。そして、次のステップＳ１２４で距離比較部３２５が、端末・センサ間距離計算部３２４がステップＳ１２３で計算した距離と、アラーム距離決定部３２３がステップＳ１２１で決定したアラーム距離を比較する。
【０２２８】
その後、ステップＳ１２５でアラーム決定部３２６は、比較結果に基づいて、ＧＰＳログの送信元の端末３７０に対してアラーム指示を与える対象のセンサユニット３５０を決定する。端末３７０の位置に応じて、アラーム指示を与える対象のセンサユニット３５０の台数は、０台のこともあるし、１台のこともあるし、複数台のこともある。
【０２２９】
そして、次のステップＳ１２６でアラーム決定部３２６は、ＧＰＳログの送信元の端末３７０に対して、ステップＳ１２５での決定に基づく適宜のアラーム指示を、通信部３２７を介して送信する。なお、以上のステップＳ１２２〜Ｓ１２６の詳細は、図１２のフローチャートとともに後述する。
【０２３０】
さて、ステップＳ１２６で送信されたアラーム指示は、端末３７０のサーバ通信部３７３において、ステップＳ１１３で受信される。
すると、ステップＳ１１４でアラーム処理部３７４は、受信されたアラーム指示にしたがって、適宜のアラームを発する。
【０２３１】
例えば、アラームは、「山田太郎さん、××圃場のセンサユニットに近寄って、データ収集に御協力ください」のように文字で表現されていてもよいし、圃場の地図などの画像を含んでもよい。文字や画像による視覚的なアラームは、図４のディスプレイ４５１に表示される。あるいは、アラームは、ＬＥＤ４４８の点灯や点滅により視覚的に表現されてもよいし、ブザー４４９や不図示のスピーカからの放音により音声的に表現されてもよい。また、アラームは、振動モータ４５０による振動のように、触覚的に表現されてもよい。もちろん、視覚的、音声的、触覚的なアラームが組み合わされてもよい。
【０２３２】
アラームを受けたユーザは、アラームにしたがって、端末３７０を携帯したままセンサユニット３５０に近づく。そして、センサユニット３５０の人感センサの検知領域にユーザが入ると、センサユニット３５０は通信部３５４をオンにする。その結果、センサユニット３５０の通信部３５４と端末３７０のセンサ通信部３７５の間での通信が可能となる。
【０２３３】
よって、センサユニット３５０内ではセンサログ処理部３５３が通信部３５４を制御し、端末３７０内ではセンサログ処理部３７７がセンサ通信部３７５を制御することで、センサログがセンサユニット３５０から端末３７０へと送信される。なお、図９には特に明示しないが、通信部３５４とセンサ通信部３７５の間の通信は、実施形態に応じた適宜のプロトコルにしたがって確立されればよい。つまり、通信を確立するための最初のトリガは通信部３５４による要求でもよいし、センサ通信部３７５による要求でもよい。
【０２３４】
いずれにしろ、センサユニット３５０においては、ステップＳ１０２で、センサログ処理部３５３が通信部３５４を介して、センサログＤＢ３５２内のセンサログを送信する。そして、端末３７０においては、ステップＳ１１５で、センサログ処理部３７７がセンサ通信部３７５を介してセンサログを受信し、受信したセンサログを一旦センサログＤＢ３７６に格納する。
【０２３５】
そして、センサログの送受信が完了すると、ステップＳ１１６で、端末３７０のセンサログ処理部３７７が、サーバ通信部３７３を介して、センサログＤＢ３７６内のセンサログをサーバ３１０に送信する。
【０２３６】
すると、サーバ３１０では、ステップＳ１２７で通信部３２７を介してセンサログ処理部３１６がセンサログを受信する。センサログ処理部３１６は、受信したセンサログの各エントリを、送信元の端末３７０の端末ＩＤおよび受信時刻と対応づけて、センサログＤＢ３１５に格納する。
【０２３７】
そして、センサログのセンサユニット３５０から端末３７０への転送が済むと、ステップＳ１２８でセンサログ処理部３１６は、収集日ＤＢ３１４を更新する。すなわち、センサログ処理部３１６は、収集日ＤＢ３１４を検索して、センサログの送信元のセンサユニット３５０のセンサユニットＩＤを持つエントリを探し出す。そして、センサログ処理部３１６は、見つかったエントリの収集日に、今日の日付を上書きする。
【０２３８】
さらに、次のステップＳ１２９でセンサログ処理部３１６は、センサログの送信元のセンサユニット３５０のセンサユニットＩＤをアラーム距離決定部３２３に通知する。すると、アラーム距離決定部３２３は、通知されたセンサユニットＩＤに関して、ステップＳ１２１と同様にしてアラーム距離を再決定する。つまり、アラーム距離決定部３２３は、収集日の更新に応じて変化した経過時間に基づき、アラーム距離を再決定する。
【０２３９】
なお、サーバ３１０における以上のステップＳ１２８〜Ｓ１２９の処理と並行して、端末３７０においてセンサログ処理部３７７は、ステップＳ１１６で送信し終わったセンサログをセンサログＤＢ３７６から消去してもよい。
【０２４０】
図１０は、端末におけるＧＰＳログ処理のフローチャートである。図１０の処理は、例えば、端末３７０に電源が入っている間中、実行され続けてもよい。
ステップＳ２０１でＧＰＳ情報取得部３７１は、取得間隔用と送信間隔用のタイマをそれぞれ設定する。なお、以下の説明において「取得間隔」とは、ＧＰＳ情報取得部３７１が測位信号を受信してＧＰＳ情報を取得する間隔である。また、以下の説明において「送信間隔」とは、ＧＰＳ情報取得部３７１がサーバ通信部３７３を介してサーバ３１０にＧＰＳログを送信する間隔である。
【０２４１】
以下では説明の便宜上、取得間隔が１分であり、送信間隔が１５分であるものとする。つまり、ステップＳ２０１でＧＰＳ情報取得部３７１は、取得間隔用のタイマを１分に設定し、送信間隔用のタイマを１５分に設定する。しかし、取得間隔と送信間隔の具体的な値は実施形態に応じて任意であり、実施形態によっては、取得間隔と送信間隔が等しくてもよい。
【０２４２】
さて、ＧＰＳ情報取得部３７１は、取得間隔用のタイマにしたがい、取得間隔が経過するまで次のステップＳ２０２で待機する。取得間隔が経過すると、処理はステップＳ２０３に移行する。
【０２４３】
ステップＳ２０３でＧＰＳ情報取得部３７１は、ＧＰＳ受信機４４６により測位信号を受信し、端末３７０の現在位置の座標（つまり緯度と経度）を取得する。
そして、次のステップＳ２０４でＧＰＳ情報取得部３７１は、現在位置の座標を取得した取得日時（つまり現在時刻）と、取得した座標値（つまり緯度と経度）を、図８に例示するようにＧＰＳログＤＢ３７２に記録する。
【０２４４】
また、次のステップＳ２０５でＧＰＳ情報取得部３７１は、取得間隔用のタイマを再度１分に設定する。
そして、次のステップＳ２０６でＧＰＳ情報取得部３７１は、送信間隔用のタイマに基づいて、送信間隔が経過したか否かを判断する。送信間隔がまだ経過していなければ、処理はステップＳ２０２に戻る。
【０２４５】
逆に、送信間隔が経過していれば、処理はステップＳ２０７に移行する。つまり、ステップＳ２０２〜Ｓ２０５の処理を１５（＝１５／１）回繰り返すごとに、処理はステップＳ２０６からステップＳ２０７へと移行する。なお、上記「１５回」という回数は、図９のステップＳ１１１の「所定回数」に相当し、ステップＳ１１１はステップＳ２０２〜Ｓ２０５を１５回繰り返すことに相当する。
【０２４６】
そして、ステップＳ２０７でＧＰＳ情報取得部３７１は、送信間隔用のタイマを再度１５分に設定する。
続いて、ステップＳ２０８でＧＰＳ情報取得部３７１は、ＧＰＳログＤＢ３７２のデータを、端末３７０自体の端末ＩＤとともにサーバ３１０に送信する。すなわち、ステップＳ２０４の１５回の繰り返しによりＧＰＳログＤＢ３７２に蓄積された１５個のエントリを、ＧＰＳ情報取得部３７１は端末ＩＤとともに送信する。なお、ステップＳ２０８は図９のステップＳ１１２に相当する。
【０２４７】
また、次のステップＳ２０９でＧＰＳ情報取得部３７１は、ステップＳ２０８で送信したデータをＧＰＳログＤＢ３７２から削除する。そして、処理はステップＳ２０２に戻る。
【０２４８】
続いて、図１１を参照して、サーバ３１０において所定の時刻に行われるアラーム距離決定処理について説明する。図１１のアラーム距離決定処理は、図９のステップＳ１２１に相当する。
【０２４９】
ステップＳ３０１でアラーム距離決定部３２３は、今日の日付を取得する。
次に、ステップＳ３０２でアラーム距離決定部３２３は、センサユニット３５０に関するループ変数ｉを１に初期化する。
【０２５０】
そして、次のステップＳ３０３でアラーム距離決定部３２３は、図７の収集日ＤＢ３１４を参照して、ｉ番目のセンサユニット３５０から前回データを収集してからの経過日数を計算する。
【０２５１】
例えば、ｉ番目のセンサユニット３５０のセンサユニットＩＤが「０００２」であり、ステップＳ３０１で取得された日付が２０１１年３月５日だとする。図７の収集日ＤＢ３１４の例によれば、センサユニットＩＤが「０００２」のセンサユニット３５０から前回サーバ３１０がデータを収集した日は２０１１年３月３日である。よって、ステップＳ３０３でアラーム距離決定部３２３は、計算により「２日」という経過日数を得る。
【０２５２】
なお、図１１の例では、経過時間の一例として、１日単位の経過日数が使われる。しかし、実施形態によっては、例えば１秒単位などの、より粒度の細かい経過時間が使われてもよいことは無論である。
【０２５３】
続いて、ステップＳ３０４でアラーム距離決定部３２３は、図６のセンサユニット別アラーム条件ＤＢ３１９を参照して、ｉ番目のセンサユニット３５０のアラーム条件ＩＤを読み出す。例えば、上記のようにｉ番目のセンサユニット３５０のセンサユニットＩＤが「０００２」の場合、図６の例によると、ステップＳ３０４で読み出されるアラーム条件ＩＤは「０１」である。
【０２５４】
そして、次のステップＳ３０５でアラーム距離決定部３２３は、ステップＳ３０４で読み出したアラーム条件ＩＤを持つアラーム条件を、図６のアラーム条件ＤＢ３２０から読み出す。例えば、上記のようにアラーム条件ＩＤが「０１」の場合、アラーム距離決定部３２３は、図６のアラーム条件ＤＢ３２０の１番目のエントリを読み出す。
【０２５５】
そして、次のステップＳ３０６でアラーム距離決定部３２３は、ステップＳ３０３で計算した経過日数と、ステップＳ３０５で読み出したアラーム条件から、アラーム距離を決定する。また、アラーム距離決定部３２３は、以上のようにして決定したアラーム距離を、ｉ番目のセンサユニット３５０のセンサユニットＩＤと対応づけてＲＡＭ４０２上に保持する。
【０２５６】
例えば、上記のように経過日数が２日であり、アラーム条件ＩＤが「０１」のアラーム条件が読み出されたとする。この場合、図６のアラーム条件ＤＢ３２０の定義によれば、１日≦２日＜３日なので、ステップＳ３０６で決定されるアラーム距離は１ｍである。
【０２５７】
そして、次のステップＳ３０７でアラーム距離決定部３２３は、ループ変数ｉの値がデータ収集システム３００内のセンサユニット３５０の総数Ｕに達したか否かを判断する。もし、ｉ＝Ｕであれば、図１１のアラーム距離決定処理は終了する。逆に、ｉ≠Ｕであれば（つまりｉ＜Ｕであれば）、処理はステップＳ３０８へと移行する。
【０２５８】
ステップＳ３０８でアラーム距離決定部３２３は、ループ変数ｉをインクリメントする。そして、処理はステップＳ３０３に戻る。
ところで、上記のとおり、アラーム距離決定部３２３は、図１１のアラーム距離決定処理により決定した各センサユニット３５０についてのアラーム距離を、例えばＲＡＭ４０２上に保持し続ける。よって、図９においては、図１１に相当するステップＳ１２１で決定されたアラーム距離を、距離比較部３２５が後のステップＳ１２４で参照することが可能である。
【０２５９】
また、図９のステップＳ１２９の再決定は、具体的には、再決定の対象のセンサユニット３５０に関してアラーム距離決定部３２３がステップＳ３０３〜Ｓ３０６の処理を行うことに相当する。
【０２６０】
続いて、図９のステップＳ１２２〜Ｓ１２６に相当する処理について、図１２を参照して説明する。図１２は、第１実施形態のアラーム関連処理のフローチャートである。
ＧＰＳログ処理部３１３は、いずれかの端末３７０から通信部３２７を介してＧＰＳログを受信するまで、ステップＳ４０１で待機する。そして、ＧＰＳログが受信されると、ＧＰＳログ処理部３１３は、ＧＰＳログを端末３７０の端末ＩＤおよび受信時刻と対応づけてＧＰＳログＤＢ３１１に格納し、その後、処理はステップＳ４０２に移行する。
【０２６１】
すると、ステップＳ４０２で端末・センサ間距離計算部３２４は、ステップＳ４０１でＧＰＳログ処理部３１３が受信したＧＰＳログに相当するエントリをＧＰＳログＤＢ３１１から読み出す。例えば、端末３７０が図１０にしたがって動作する場合、１回の送信で端末３７０から送信されるＧＰＳログは、１５（＝１５／１）個のエントリに相当するので、ステップＳ４０２ではＧＰＳログＤＢ３１１内で収集日時が最新の１５個のエントリが読み出される。
【０２６２】
端末・センサ間距離計算部３２４は、ステップＳ４０２においてさらに、読み出したエントリをウィンドウ間隔ＷごとにＮ個のブロックに分割する。ここで、ウィンドウ間隔Ｗは、ＧＰＳログの１回の送信に対応するエントリ数よりも小さな所定の値であり、端末３７０の位置の平均をとるための時間の幅を表す。以下では説明の便宜上Ｗ＝５とする。例えば、図１０の例のように取得間隔が１分であり、上記仮定のようにＷ＝５の場合、ウィンドウ間隔Ｗが示す時間の幅は５分（＝１分×Ｗ）である。
【０２６３】
そして、ブロックの個数Ｎは、ＧＰＳログの１回の送信に対応するエントリ数をウィンドウ間隔で割った値である。よって、上記のように１回の送信で端末３７０から送信されるＧＰＳログが１５個のエントリに相当する場合、Ｎ＝１５／５＝３である。
【０２６４】
以上のようなブロックへの分割の後、ステップＳ４０３で端末・センサ間距離計算部３２４は、分割して得られた各ブロックにおける平均座標を求める。例えばＷ＝５の場合、１つのブロックにはＧＰＳログＤＢ３１１から読み出された５つのエントリが対応するので、ステップＳ４０３では、各ブロックについて、５つのエントリの平均座標（つまり平均緯度と平均経度）が計算される。
【０２６５】
ここで説明の便宜上、ステップＳ４０１で受信されたＧＰＳログが、ｊ番目の端末ｔｅｒｍｊが時刻ｔｊ，ｋ〜ｔｊ，ｋ＋ＷＮ−１に取得したＷＮ個の座標ｇｐｓｊ，ｋ〜ｇｐｓｊ，ｋ＋ＷＮ−１に対応するものとする。すると、ステップＳ４０３でｎ番目（１≦ｎ≦Ｎ）のブロックについて計算される平均座標ａｖｒｊ，ｎは、式（２）のとおりである。
【０２６６】
【数２】
【０２６７】
なお、図８から理解されるように、個々の座標ｇｐｓｊ，ｋ〜ｇｐｓｊ，ｋ＋ＷＮ−１と平均座標ａｖｒｊ，ｎのいずれも、具体的には、緯度と経度のペアで表される。
【０２６８】
続くステップＳ４０４〜Ｓ４１３の処理は、各センサユニット３５０についてステップＳ４０５〜Ｓ４１１の処理を繰り返すことを含む。そして、ステップＳ４０５〜Ｓ４１１の処理は、「ブロックの平均座標とセンサユニット３５０との間の距離がアラーム距離以下になるブロックが１つでもあるか」ということを判定する処理である。
【０２６９】
具体的には、ステップＳ４０４でサーバ３１０は、センサユニット３５０についてのループ変数ｉを１に初期化する。
また、次のステップＳ４０５で距離比較部３２５は、ｉ番目のセンサユニット３５０に対応するフラグをｆａｌｓｅに初期化する。当該フラグは、「ステップＳ４０１で受信されたＧＰＳログの送信元の端末３７０のブロックごとの平均座標のうち、ｉ番目のセンサユニット３５０からの距離がｉ番目のセンサユニット３５０に関するアラーム距離以下のものが１つでもあるか」ということを示す。換言すれば、当該フラグは、「ステップＳ４０１で受信されたＧＰＳログの送信元の端末３７０に対してｉ番目のセンサユニット３５０についてのアラーム指示を送信するか否かを示す。初期値のｆａｌｓｅは、アラーム指示を送信しないことを示す。
【０２７０】
また、次のステップＳ４０６でサーバ３１０は、ブロックについてのループ変数ｎを１に初期化する。
そして、次のステップＳ４０７で端末・センサ間距離計算部３２４は、ステップＳ４０３で計算したｎ番目のブロックの平均座標が示す位置と、ｉ番目のセンサユニット３５０との間の距離を計算する。つまり、端末・センサ間距離計算部３２４は、図５のセンサ位置ＤＢ３１７を参照してｉ番目のセンサユニット３５０が設置された位置の緯度と経度を読み出し、読み出した緯度と経度と、ステップＳ４０３の計算結果を用いて、距離を計算する。
【０２７１】
説明の便宜上、ｉ番目のセンサユニット３５０の位置をｐｏｓｉとする。すると、ステップＳ４０７で計算される距離ｄｉｓｔｉ，ｊ，ｎは、式（３）のように表すことができる。
【０２７２】
【数３】
【０２７３】
なお、図５から理解されるように、ｉ番目のセンサユニット３５０の位置ｐｏｓｉは緯度と経度のペアで表される。また、式（３）において｜｜ｘ−ｙ｜｜は、位置ｘと位置ｙの間の距離（例えば、ユークリッド距離でもよいし、マンハッタン距離でもよい）を示すものとする。
【０２７４】
そして、次のステップＳ４０８で距離比較部３２５は、ステップＳ４０７で計算された距離ｄｉｓｔｉ，ｊ，ｎが、図１１の処理の結果としてアラーム距離決定部３２３がｉ番目のセンサユニット３５０に関して記憶しているアラーム距離以下か否かを判断する。以下では、説明の便宜上、アラーム距離決定部３２３がｉ番目のセンサユニット３５０に関して記憶しているアラーム距離をａｌａｒｍｉと表記する。
【０２７５】
計算された距離ｄｉｓｔｉ，ｊ，ｎがアラーム距離ａｌａｒｍｉ以下のとき、処理はステップＳ４０９に移行する。逆に、距離ｄｉｓｔｉ，ｊ，ｎがアラーム距離ａｌａｒｍｉより大きいとき、処理はステップＳ４１０に移行する。
【０２７６】
ステップＳ４０９が実行されるのは、ブロックの平均座標ａｖｒｊ，ｎとｉ番目のセンサユニット３５０との間の距離ｄｉｓｔｉ，ｊ，ｎがアラーム距離ａｌａｒｍｉ以下になるブロックが見つかった場合である。この場合、距離比較部３２５は、ｉ番目のセンサユニット３５０に対応するフラグ（つまりステップＳ４０５で初期化したフラグ）をｔｒｕｅに設定する。そして、さらに別のブロックについて検討する必要はもうないので、処理はステップＳ４１２に移行する。
【０２７７】
他方、ステップＳ４１０が実行されるのは、ブロックの平均座標ａｖｒｊ，ｎとｉ番目のセンサユニット３５０との間の距離ｄｉｓｔｉ，ｊ，ｎがアラーム距離ａｌａｒｍｉ以下になるブロックがまだ見つかっていない場合である。この場合、ステップＳ４１０でサーバ３１０は、未注目のブロックが残っているか否かを判断する。すなわち、サーバ３１０は、ｎ＝Ｎであるか否かを判断する。
【０２７８】
そして、ｎ＝Ｎの場合は、全ブロックが注目済みであり、どのブロックの平均座標ａｖｒｊ，ｎも、ｉ番目のセンサユニット３５０との間の距離がアラーム距離ａｌａｒｍｉより大きい場合である。よって、ｎ＝Ｎの場合は、ステップＳ４０５で初期化されたフラグの値がｆａｌｓｅのまま、処理がステップＳ４１２へと移行する。
【０２７９】
他方、ｎ≠Ｎの場合（より具体的にはｎ＜Ｎの場合）は、未注目のブロックが残っている。よって、次のブロックに注目するために処理はステップＳ４１１に移行する。
そして、ステップＳ４１１でサーバ３１０は、ブロックに関するループ変数ｎをインクリメントし、その後、処理はステップＳ４０７に戻る。
【０２８０】
ここで、ｊ番目の端末ｔｅｒｍｊからステップＳ４０１でＧＰＳログが受信された場合の、ｉ番目のセンサユニット３５０についてのフラグをｆｌａｇｉ，ｊと表記する。上記のステップＳ４０５〜Ｓ４１１の処理により、フラグｆｌａｇｉ，ｊは、式（４）のように設定される。
【０２８１】
【数４】
【０２８２】
さて、ステップＳ４１２でサーバ３１０は、すべてのセンサユニット３５０について注目し終えたか否かを判断する。つまり、サーバ３１０は、センサユニット３５０についてのループ変数ｉの値がデータ収集システム３００内のセンサユニット３５０の総数Ｕに達したか否かを判断する。
【０２８３】
そして、ｉ＝Ｕの場合、処理はステップＳ４１４に移行する。他方、ｉ≠Ｕの場合（より具体的にはｉ＜Ｕの場合）は、未注目のセンサユニット３５０が残っているので、処理はステップＳ４１３に移行する。
【０２８４】
ステップＳ４１３でサーバ３１０は、センサユニット３５０についてのループ変数ｉをインクリメントする。その後、処理はステップＳ４０５に戻る。
さて、ステップＳ４１４の処理が実行されるのは、データ収集システム３００内のすべてのセンサユニット３５０に関して、フラグｆｌａｇｉ，ｊが設定された後である。そして、ステップＳ４１４でアラーム決定部３２６は、対応するフラグがｔｒｕｅの全センサユニット３５０のリストを取得する。なお、センサユニット３５０のリストは、具体的にはセンサユニットＩＤのリストとして表現される。
【０２８５】
ここで説明の便宜上、ｉ番目のセンサユニット３５０のセンサユニットＩＤをｕｎｉｔｉと表記すると、ステップＳ４１４で取得されるリストは、式（５）の集合ｔａｒｇｅｔｊを表すリストである。つまり、ステップＳ４１４においてアラーム決定部３２６は、ステップＳ４０１で受信されたＧＰＳログの送信元の端末３７０（すなわち端末ｔｅｒｍｊ）に対してアラーム指示を出す対象のセンサユニット３５０の集合ｔａｒｇｅｔｊを決定する。
【０２８６】
【数５】
【０２８７】
そして、次のステップＳ４１５でアラーム決定部３２６は、アラーム指示として、ステップＳ４１４で取得したリストを、ステップＳ４０１で受信されたＧＰＳログの送信元の端末３７０に、通信部３２７を介して送信する。
【０２８８】
なお、場合によっては、ステップＳ４１４で得られるリストが空リストのことがある（つまり集合ｔａｒｇｅｔｊが空集合のことがある）。空リストがアラーム指示として送信される場合のアラーム指示とは、具体的には「どのセンサユニット３５０に関してもアラームを発する必要がない」という指示である。
【０２８９】
しかし、「アラームを発する必要がない」ということは、明示的に指示されなくても構わない。よって、ステップＳ４１４で得られるリストが空リストの場合、ステップＳ４１５の送信が省略されてもよい。
【０２９０】
逆に、非空のリストがアラーム指示としてステップＳ４１５で送信される場合、アラーム指示は「当該リストに含まれる各センサユニットＩＤのセンサユニット３５０について、アラームを発せよ」という指示である。
【０２９１】
いずれにしろ、ステップＳ４１５でのリストの送信後、処理はステップＳ４０１に戻る。
なお、図１２のステップＳ４０１における受信が図９のステップＳ１２２における受信に対応し、図１２のステップＳ４０７とＳ４０８が図９のステップＳ１２３とＳ１２４に対応する。また、図１２のステップＳ４１４が図９のステップＳ１２５に対応し、ステップＳ４１５がステップＳ１２６に対応する。
【０２９２】
そして、以上説明した第１実施形態によれば、センサユニット３５０ごとに、データ収集の緊急度に応じてアラーム距離が決定され、アラーム距離と端末３７０の位置に基づいてサーバ３１０が端末３７０にアラーム指示を出す。つまり、端末３７０がユーザに対してアラームを出すか否かは、センサユニット３５０からのデータ収集の緊急度に依存する。よって、第１実施形態によれば、センサユニット３５０からのデータ収集にユーザが関与するデータ収集システム３００において、データ収集の緊急度とユーザの負担のバランスがとれる。
【０２９３】
続いて、図１３〜２０を参照して第２実施形態について説明する。なお、第１実施形態との共通点については適宜説明を省略する。第２実施形態は、第１実施形態と同様にデータ収集の緊急度とユーザの負荷のバランスをとる効果だけでなく、さらに、ユーザの作業効率の低下を防ぐ効果を奏する。
【０２９４】
まず、図１３を参照して、第２実施形態により解決しようとする課題について説明する。図１３は、データ収集への関与が原因でユーザの作業効率が悪くなる例を示す図である。
【０２９５】
図２と同様に図１３にも、圃場２０１におけるユーザの動きの例が示されている。図２と同様に図１３でも圃場２０１の隅にセンサユニット２０２が設置されており、センサユニット２０２の人感センサの検知領域２０３は、広い圃場２０１のごく一部である。
【０２９６】
ここで、ユーザ２０９が軌跡２１０に沿って移動しながら除草などの作業を行っているものとする。そして、軌跡２１０の矢印の先端までユーザ２０９が移動した時点で、ユーザ２０９が携帯する不図示の端末がアラームを発したとする。
【０２９７】
すると、アラームを受けたユーザ２０９は、作業を中断して、軌跡２１１として示すようにセンサユニット２０２の近傍まで移動する。そして、ユーザ２０９が検知領域２０３に入ると、センサユニット２０２の人感センサがユーザ２０９の存在を検知し、センサユニット２０２は通信機能をオンにする。すると、センサユニット２０２と端末が通信を開始し、その結果、センサユニット２０２から端末へとセンサログが転送される。
【０２９８】
ユーザ２０９は、センサログが端末に転送され終わるのを待ってから、軌跡２１２として示すように元の位置まで移動する。その後、ユーザ２０９は、中断した作業を再開する。具体的には、ユーザ２０９は、軌跡２１３に沿って移動しながら作業の続きを行う。
【０２９９】
以上の図１３の例のとおり、ユーザ２０９がアラームを受けるタイミングによっては、ユーザ２０９は、データ収集に関与するために作業を中断することがある。作業の中断は、作業効率を落とす。
【０３００】
また、アラームを受けたときにユーザ２０９がいる場所が図１３のようにセンサユニット２０２から遠く離れている場合、ユーザ２０９が軌跡２１１と２１２に沿って移動する距離も長い。長い距離をユーザ２０９が移動する場合、作業の中断時間も長い。すると、ユーザ２０９は、移動に気を取られて、例えば「どこまで作業が済んだか」ということを忘れてしまうかもしれない。その結果、作業効率がさらに悪化するおそれもある。
【０３０１】
以上の図１３の例から理解されるように、ユーザ２０９の作業中に端末がアラームを出すことは、作業効率を悪化させるおそれがある。そこで、第２実施形態では、作業効率が悪化する度合を小さくするために、作業スケジュールに基づいて２種類の制御が行われる。
【０３０２】
すなわち、第１に、データ収集の緊急度がまだそれほど高くない場合（換言すれば、前回の収集からの経過時間がまだそれほど長くないためアラーム距離がそれほど大きくない場合）は、アラームの発行を後日に延期する制御が行われる。「あるセンサユニットに関するアラームの発行を延期する」ということは、「端末の位置によらず、延期された日までは、当該センサユニットに関するアラームが発行されない」ということである。つまり、延期により、アラームによる作業の中断が防止され、作業効率の悪化を防ぐことができる。
【０３０３】
しかし、無制限の延期は好ましくない。そこで、第２実施形態では、「どの程度の延期が適切なのか」という判断のため、センサユニットが設置された場所（例えば圃場２０１）での作業スケジュールが参照される。
【０３０４】
また、第２に、アラームの発行は、なるべくユーザの作業を中断させないタイミングで行われるように制御される。ユーザの作業を中断させないタイミングとは、ユーザが作業をしていないと想定されるタイミングであり、具体的には、休憩時間である。例えば、休憩時間の開始時刻もしくは終了時刻、または休憩時間中にアラームが出されれば、ユーザは作業を中断せずに済む。つまり、端末がアラームを出す時刻を調整することは、ユーザの負荷自体を減らすことはないとはいえ、作業効率に与える悪影響を減らす効果がある。
【０３０５】
以下では、以上に概略を述べたような第２実施形態の動作と構成について、より具体的に説明する。
図１４は、第２実施形態のセンサデータ収集システムのブロック構成図である。図１４では、第１実施形態と同様の構成要素には図３と同じ参照符号が割り当てられている。
【０３０６】
図１４のデータ収集システム３００ｂは、サーバ３１０ｂと、１台以上のセンサユニットと、１台以上の端末を含む。図１４には図３と同様に、３台のセンサユニット３５０ａ〜３５０ｃと３台の端末３７０ａ〜３７０ｃが例示されているが、センサユニット３５０および端末３７０の台数は任意である。また、図１４に示す第２実施形態のセンサユニット３５０ａ〜３５０ｃと端末３７０ａ〜３７０ｃは、図３に示す第１実施形態のものと同様である。
【０３０７】
図１４のサーバ３１０ｂは、以下の点において図３のサーバ３１０と異なる。すなわち、サーバ３１０ｂは、図３の収集日ＤＢ３１４の代わりに収集日ＤＢ３２８を有し、図３のアラーム決定部３２６の代わりにアラーム決定部３３４を有する。また、サーバ３１０ｂはさらに、圃場形状ＤＢ３２９、スケジュールＤＢ３３０、休憩時間ＤＢ３３１、スケジュール単位定義ＤＢ３３２、および圃場特定部３３３を有する。
【０３０８】
収集日ＤＢ３２８は、詳しくは図１５に示すとおり、図７の収集日ＤＢ３１４とは異なる構造を有する。収集日ＤＢ３２８は、収集日ＤＢ３１４と同様に、図４のＨＤＤ４０３に保持されていてもよいし、ＲＡＭ４０２に保持されていてもよい。
【０３０９】
また、アラーム決定部３３４は、図３のアラーム決定部３２６が行う処理とはやや異なる処理を行う。アラーム決定部３３４も、アラーム決定部３２６と同様に、図４のＣＰＵ４０１がプログラムを実行することにより実現される。
【０３１０】
そして、圃場形状ＤＢ３２９は、センサユニット３５０が設置された圃場の形状を表す情報を記憶するＤＢである。また、スケジュールＤＢ３３０は、各圃場での作業スケジュールを記憶するＤＢである。なお、第２実施形態では「どの圃場でも作業の休憩時間は共通である」と仮定しており、休憩時間ＤＢ３３１はこの仮定に基づいて休憩時間を記憶するＤＢである。スケジュール単位定義ＤＢ３３２は、「作業が予定されている日と作業が予定されていない日が混在する場合に、どの範囲をひとかたまりの作業の単位として見なすか」を規定する規則を記憶するＤＢである。具体的には、スケジュール単位定義ＤＢ３３２には、規則を表現するための１つ以上のパラメタが記憶される。
【０３１１】
以上の各種ＤＢの詳細は図１５とともに後述する。また、以上の各種ＤＢは、例えば、図４のＨＤＤ４０３に格納され、必要に応じてＲＡＭ４０２に読み出される。
そして、圃場特定部３３３は、端末３７０が存在する圃場を、端末３７０から受信したＧＰＳログに基づいて特定する。圃場を特定することにより、当該圃場でのスケジュールを参照することが可能になる。圃場特定部３３３は、図４のＣＰＵ４０１がプログラムを実行することにより実現される。
【０３１２】
図１５は、第２実施形態においてサーバが保持するＤＢの例を示す図である。
収集日ＤＢ３２８は、図７の収集日ＤＢ３１４と類似のＤＢだが、各エントリが「アラーム予定日」および「圃場ＩＤ」というフィールドを含む点で、収集日ＤＢ３１４と異なる。アラーム予定日は、センサユニットＩＤで識別される当該センサユニット３５０に関するアラーム指示を端末３７０に出す予定の日である。換言すれば、アラーム予定日は、当該センサユニット３５０に関するアラームを端末３７０に出させる予定の日である。
【０３１３】
図１５の例では、センサユニットＩＤが「０００２」のエントリに関してのみアラーム予定日が２０１１年３月５日に設定されており、他のエントリではアラーム予定日が未設定である。
【０３１４】
なお、詳しくは後述するが、アラーム予定日は、アラーム決定部３３４によって随時更新され得る。また、実際にサーバ３１０ｂがデータを収集すると、アラーム予定日はクリアされ、未設定の状態に戻される。
【０３１５】
また、圃場ＩＤは、センサユニットＩＤで識別される当該センサユニット３５０が設定されている圃場を、データ収集システム３００ｂ内で一意に識別する識別子を示す。圃場ＩＤは、センサユニットＩＤから一意に定まるので、例えば図５のセンサ位置ＤＢ３１７などに記憶されていてもよいが、説明の便宜上、第２実施形態では収集日ＤＢ３２８に記憶されているものとする。
【０３１６】
図１５の例では、センサユニットＩＤが「０００１」と「０００２」のセンサユニット３５０は、「０００５」という圃場ＩＤの圃場に設置されている。また、センサユニットＩＤが「０００３」のセンサユニット３５０は、「０００１」という圃場ＩＤの圃場に設置されており、センサユニットＩＤが「００１０」のセンサユニット３５０は、「０００７」という圃場ＩＤの圃場に設置されている。
【０３１７】
さて、図１５に示すように、圃場形状ＤＢ３２９は、センサユニット３５０が設置される圃場の形状を表すＤＢである。第２実施形態では、１つの圃場の形状が多角形で近似され、ｘ角形（３≦ｘ）で近似される圃場の形状は、圃場形状ＤＢ３２９のｘ個のエントリで表される。
【０３１８】
具体的には、圃場形状ＤＢ３２９の各エントリは、「圃場ＩＤ」、「頂点数」、「頂点ＩＤ」、「緯度」、および「経度」というフィールドを有する。圃場ＩＤは圃場の識別子を示す。頂点数は、圃場ＩＤで識別される圃場の形状を近似する多角形の頂点の数を示す。頂点ＩＤは、１つの圃場内で各頂点を一意に識別する識別子であり、緯度と経度は頂点の位置を示す。
【０３１９】
図１５の例によれば、圃場ＩＤが「０００１」の圃場は４角形で近似され、そのうち２つの頂点は、北緯３５．４３９９６度・東経１３９．３０７１度と、北緯３５．４３９９６度・東経１３９．３０８０度にある。
【０３２０】
なお、圃場形状ＤＢ３２９は静的なＤＢだが、センサユニット３５０を設置する対象の圃場の増減に応じてエントリが追加または削除される。また、実施形態によっては、圃場形状ＤＢ３２９のように数値による圃場の形状を表すＤＢの代わりに、緯度と経度に対応づけて圃場の範囲を示す２値画像などによって圃場の形状を表す画像ＤＢが利用されてもよい。
【０３２１】
さて、図１５に示すように、スケジュールＤＢ３３０の各エントリは、個々の圃場での個々の作業に対応し、「圃場ＩＤ」と「開始日時」と「終了日時」と「作業内容」というフィールドを有する。圃場ＩＤは、圃場形状ＤＢ３２９と同様に、圃場の識別子である。開始日時と終了日時は、作業がいつからいつまで行われる予定であるかを示す。作業内容は、作業の内容を示す。
【０３２２】
図１５の例によれば、圃場ＩＤが「０００１」の圃場では、２０１１年３月１４日の８時から１２時まで、草取りが予定されている。また、圃場ＩＤが「０００２」の圃場では、２０１１年３月１４日の１３時から１５時まで、播種が予定されている。
【０３２３】
スケジュールＤＢ３３０は動的なＤＢであり、新たな作業の予定が立てられるたびに、例えば、端末３７０からの指示またはサーバ３１０ｂのキーボード４１２からの入力に応じて、エントリが追加される。
【０３２４】
また、図１５に示すように、休憩時間ＤＢ３３１の各エントリは、１回の休憩時間に対応する。なお、第２実施形態では、「どの圃場でも休憩時間のスケジュールは共通である」と仮定している。よって、休憩時間ＤＢ３３１の各エントリは、「休憩時間ＩＤ」と「開始時刻」と「終了時刻」というフィールドを有する。休憩時間ＩＤは個々の休憩時間を識別する識別子であり、開始時刻と終了時刻は休憩時間の範囲を示す。
【０３２５】
図１５の例によれば、休憩時間ＩＤが「０１」の休憩時間は１０時から１０時１５分までであり、休憩時間ＩＤが「０２」の休憩時間は１２時から１３時までであり、休憩時間ＩＤが「０３」の休憩時間は１５時から１５時１５分までである。なお、休憩時間ＤＢ３３１は静的なＤＢだが、休憩時間の予定が変われば、エントリの追加・削除・変更などが行われてもよい。
【０３２６】
また、図１５に示すように、スケジュール単位定義ＤＢ３３２には、「作業が予定されている日と作業が予定されていない日が混在する場合に、どの範囲をひとかたまりの作業の単位として見なすか」を規定する規則を表現するためのパラメタが設定されている。第２実施形態では、上記規則は、具体的には、「作業なし期間の最大長さ」と「作業なし期間の最大回数」という２つのパラメタで表される。
【０３２７】
そして、図１５の例では、これら２つのパラメタの値は、それぞれ「３日」と「２回」である。すなわち、図１５の例は、以下のような規則を表す。
・作業なし期間をはさんで断続的に作業が予定されている場合であっても、作業なし期間をはさんだ全体を、ひとかたまりの作業の単位として見なせることがある。
・具体的には、作業なし期間をはさんで断続的に作業が行われる場合、３日以内の作業なし期間を２回まで含んでいても、全体をひとかたまりの作業の単位として見なしてよい。
・３日より長い作業なし期間がある場合は、当該作業なし期間が、作業の単位同士の区切れ目になる。
・３回目の３日以内の作業なし期間も、作業の単位同士の区切れ目になる。
【０３２８】
なお、スケジュール単位定義ＤＢ３３２は静的なＤＢである。スケジュール単位定義ＤＢ３３２に設定されるパラメタの種類と値は実施形態に応じて適宜決められてよい。
【０３２９】
図１６は、作業スケジュールとアラーム予定日の例を示す図である。図１６には４通りのスケジュール例５０１〜５０４が例示されている。
スケジュール例５０１は、「前回のデータ収集日から２週間あいて、今日から３日間作業が予定されている」という例である。スケジュール例５０１のように前回のデータ収集日からの経過時間が長い場合は、データ収集の緊急度が高いので、データ収集を延期しないことが望ましい。
【０３３０】
つまり、サーバ３１０ｂは、今日のうちにアラーム指示を出し、端末３７０を介してセンサユニット３５０からデータを収集することが望ましい。換言すれば、アラーム決定部３３４は、アラーム予定日を設定しないこと（それにより、暗黙的に、今日をアラーム予定日として指定すること）が望ましい。なお、図１６ではアラーム予定日が二重丸で示されている、
【０３３１】
他方、スケジュール例５０２は、「前回のデータ収集日から３日間だけあいて、今日から３日間作業が予定されている」という例である。スケジュール例５０２のように前回のデータ収集日からの経過時間が短い場合は、データ収集の緊急度が低いので、データ収集を延期しても構わない。
【０３３２】
また、３日間の作業の最終日であっても前回の収集日の６日後である。例えば、データ収集の緊急度が「当日中にデータを収集することが望ましい」という程度にまで高まるのが、前回の収集日から１０日後であるとすると、スケジュール例５０２の作業最終日にデータが収集されることは十分許容される。
【０３３３】
そこで、スケジュール例５０２の場合、アラーム決定部３３４は、今日から予定されている３日間の作業の最終日をアラーム予定日として設定することが好ましい。すると、サーバ３１０ｂは、作業１日目をアラーム予定日として設定する場合と比べて、次の収集でより多くのデータ（つまり作業２日目や３日目のセンサログ）を取得することができる。
【０３３４】
もちろん、設定されたアラーム予定日よりも前に、偶発的または自発的にユーザがセンサユニット３５０に近寄ってデータ収集に関与することもあり得る。よって、例えば、作業２日目にデータが収集される場合もあり得る。すると、収集に応じて、アラーム決定部３３４はアラーム予定日を新たに設定しなおす。
【０３３５】
また、スケジュール例５０１と５０２は、作業が３日間連続する例だが、場合によっては、作業のない日を間にはさみながら、断続的に作業が予定されることもある。例えば、スケジュール例５０３と５０４はその例である。
【０３３６】
スケジュール例５０３は、「前回のデータ収集日から２日間あいて、今日から３日間作業が予定されており、その後、２日間の作業なし期間をはさんで作業が再開される予定であり、再開後の作業は４日間にわたる予定である」という例である。そして、図１５のスケジュール単位定義ＤＢ３３２によれば、２日間の作業なし期間をはさんだ合計７日間の作業の全体（つまり、作業なし期間も数えれば９日にわたる期間の全体）は、ひとかたまりの単位と見なせる。
【０３３７】
また、ここで、スケジュール例５０２について例示したのと同様に、前回の収集日から１０日後には、データ収集の緊急度が「当日中にデータを収集することが望ましい」という程度にまで高まる、と仮定する。つまり、収集を後日に延期することが許容されるのは、前回の収集日から９日目までである、と仮定する。したがって、前回の収集日から１０日目になったら、サーバ３１０ｂはアラーム指示を出すことが望ましい。
【０３３８】
スケジュール例５０３の例では、ひとかたまりの単位の最終日は再開後作業最終日であるが、再開後作業最終日には前回の収集日から１１日が経過してしまう。よって、アラーム予定日は、前回の収集日から１０日後にあたる再開後作業３日目とすることが望ましい。
【０３３９】
つまり、たとえ今日が前回の収集日から間もないとしても、ひとかたまりの作業の単位が長ければ、最終日には、前回の収集日から大幅な日数が経過してしまうおそれがある。よって、サーバ３１０ｂは、一律にひとかたまりの作業の単位の最終日をアラーム予定日とするのではなく、前回の収集日からの経過時間がある程度の範囲内に収まるように、アラーム予定日を設定することが好ましい。
【０３４０】
また、スケジュール例５０４は、「前回のデータ収集日から４日間あいて、今日から３日間作業が予定されており、その後、３日間の作業なし期間をはさんで作業が再開される予定であり、再開後の作業は３日間にわたる予定である」という例である。そして、図１５のスケジュール単位定義ＤＢ３３２によれば、３日間の作業なし期間をはさんだ合計６日間の作業の全体（つまり、作業なし期間も数えれば９日にわたる期間の全体）は、ひとかたまりの単位と見なせる。
【０３４１】
スケジュール例５０３の場合と同様に、スケジュール例５０４でも、前回の収集日から１０日後がアラーム予定日として設定されてもよい。スケジュール例５０４の場合は、前回の収集日から１０日後が偶然にも作業なし日であるが、例えば上記の１０日という閾値が多少の余裕をもって設定された値であれば、このように作業なし日にアラーム予定日が重なってもよい。例えば、アラーム予定日の翌日（つまり作業再開１日目）に実際にユーザが作業をしに圃場に来たときに、サーバ３１０ｂは、既に前回の収集日から１０日以上経過していることを検知して、アラーム指示を出せばよい。
【０３４２】
図１７は、第２実施形態のデータ収集システムの動作シーケンス図である。なお、センサユニット３５０の動作は第１実施形態と同様なので、図１７ではセンサユニット３５０の動作は省略されている。
【０３４３】
また、端末３７０の動作も第１実施形態と同様である。図１７には、図９の第１実施形態のシーケンス図と同様に、端末３７０が行うステップＳ１１１〜Ｓ１１３の処理が図示されているが、ステップＳ１１４以後の端末３７０の処理は、紙幅の都合上、図１７では省略されている。
【０３４４】
サーバ３１０ｂにおいては、図９の第１実施形態と同様に図１７の第２実施形態でも、ステップＳ１２１でアラーム距離決定部３２３が各センサユニット３５０についてのアラーム距離を決定する。そして、図９のステップＳ１２２〜Ｓ１２６の代わりに図１７にはステップＳ５０１〜Ｓ５０８が示されている。
【０３４５】
なお、紙幅の都合上、図１７では省略されているが、ステップＳ５０８の後でサーバ３１０ｂは、いずれかの端末３７０（通常は、アラーム指示の送信先の端末３７０）を介してセンサログを受信することがある。その場合、サーバ３１０ｂは図９のステップＳ１２７〜Ｓ１２９と同様の処理を行う。
【０３４６】
以下では、図９と異なるステップＳ５０１〜５０８でのサーバ３１０ｂの動作について詳しく説明する。
ステップＳ５０１では、端末３７０からのＧＰＳログを通信部３２７が受信する。受信されたＧＰＳログは、ＧＰＳログ処理部３１３の制御のもと、ＧＰＳログＤＢ３１１に格納される。
【０３４７】
次に、ステップＳ５０２でアラーム決定部３３４は、アラーム指示を送る時刻か否かを判断するために、図１５の休憩時間ＤＢ３３１を参照し、現在が休憩時間か否かを判断する。現在がまだ休憩時間でなければ、サーバ３１０ｂは再度ＧＰＳログの受信待ち状態に戻る。図１７の例は、ステップＳ５０２でのチェックの結果、現在が休憩時間であることが判明した場合の動作シーケンスである。
【０３４８】
現在が休憩時間である場合、サーバ３１０ｂは、各端末３７０について以下のステップＳ５０３〜Ｓ５０６の処理を行う。なお、ステップＳ５０３〜Ｓ５０４の処理は各センサユニット３５０について行われるが、紙幅の都合上、図１７ではセンサユニット３５０ごとのループを示すループ端が省略されている。
【０３４９】
ステップＳ５０３で端末・センサ間距離計算部３２４は、ＧＰＳログＤＢ３１１とセンサ位置ＤＢ３１７を参照して、処理対象として注目している端末３７０とセンサユニット３５０の間の距離を計算する。なお、ステップＳ５０３の動作は、図９のステップＳ１２３の動作と似ているが、計算に用いるＧＰＳログの範囲が異なる。
【０３５０】
そして、次のステップＳ５０４で距離比較部３２５は、端末・センサ間距離計算部３２４が計算した距離と、アラーム距離決定部３２３がステップＳ１２１で決定したアラーム距離を比較する。比較結果は、処理対象として注目している端末３７０とセンサユニット３５０の組み合わせに関して、「当該端末３７０に当該センサユニット３５０についてのアラーム指示を与えるか否か」という暫定的な判定結果を表す。
【０３５１】
また、次のステップＳ５０５で圃場特定部３３３は、処理対象として注目している端末３７０が休憩時間の直前の時間帯（例えば、休憩時間が始まる３０分前から休憩時間の開始時刻までの時間帯）に存在していた圃場を特定する。圃場特定部３３３は、ＧＰＳログＤＢ３１１と圃場形状ＤＢ３２９に基づいて、圃場を特定することができる。
【０３５２】
そして、次のステップＳ５０６でアラーム決定部３３４は、ステップＳ５０４での暫定的な判定について再判定を行う。すなわち、アラーム決定部３３４は、圃場のスケジュールに基づき、端末３７０へのアラーム指示の要否を再判定する。
【０３５３】
具体的には、アラーム決定部３３４は、まず、図１５のスケジュールＤＢ３３０を参照することで、ステップＳ５０５で特定された圃場での作業スケジュールを認識する。そして、アラーム決定部３３４は、認識した作業スケジュールと、スケジュール単位定義ＤＢ３３２で定義される規則と、前回のデータ収集からの経過時間に基づいて、アラーム指示の送信を延期するか否かを判断する。
【０３５４】
アラーム指示の送信を延期するということは、ステップＳ５０４で暫定的に決められたアラーム指示をキャンセルするということであり、「今日はアラーム指示は不要である」と決定することである。つまり、アラーム決定部３３４は、アラーム指示の送信を延期するか否かを判断することで、アラーム指示の要否を判定しなおす。
【０３５５】
そして、以上のステップＳ５０３〜Ｓ５０６の処理が各端末３７０について行われた後、ステップＳ５０７では、アラーム決定部３３４が、アラーム指示を送信する送信先の端末３７０を決定する。ステップＳ５０７の決定は、ステップＳ５０６での再判定結果に基づく。
【０３５６】
さらに、次のステップＳ５０８でアラーム決定部３３４は、ステップＳ５０７で決定した端末３７０に対して、通信部３２７を介してアラーム指示を送信する。なお、以上のステップＳ５０１〜５０８の詳細は、図１８〜２０のフローチャートとともに後述する。また、送信されたアラーム指示は、端末３７０においてステップＳ１１３で受信される。
【０３５７】
図１８は、第２実施形態のアラーム関連処理のフローチャートである。
ＧＰＳログ処理部３１３は、いずれかの端末３７０から通信部３２７を介してＧＰＳログを受信するまで、ステップＳ６０１で待機する。そして、ＧＰＳログが受信されると、処理はステップＳ６０２に移行する。
【０３５８】
すると、ステップＳ６０２でＧＰＳログ処理部３１３は、ＧＰＳログを端末３７０の端末ＩＤおよび受信時刻と対応づけてＧＰＳログＤＢ３１１に格納し、その後、処理はステップＳ６０３に移行する。
【０３５９】
ステップＳ６０３でアラーム決定部３３４は、休憩時間ＤＢ３３１を参照して、現在が休憩時間か否かを判断する。
例えば、図１５の休憩時間ＤＢ３３１の例では、１０時から１０時１５分と、１２時から１３時と、１５時から１５時１５分が休憩時間である。よって、例えば現在時刻が９時や１４時などであれば、アラーム決定部３３４は「現在は休憩時間中ではない」と判断し、処理はステップＳ６０１に戻る。つまり、第２実施形態では、休憩時間外では、ＧＰＳログが単にＧＰＳログＤＢ３１１に蓄積されるだけであり、ＧＰＳログの受信を契機にアラーム指示が送信されるわけではない。
【０３６０】
逆に、例えば現在時刻が１０時や１２時３分などであれば、アラーム決定部３３４は「現在は休憩時間中である」と判断し、処理はステップＳ６０４に移行する。第２実施形態では、休憩時間に入ると、サーバ３１０ｂがステップＳ６０４〜Ｓ６１６の処理を行い、必要に応じてアラーム指示を送信する。もちろん、実施形態によっては、ステップＳ６０１〜Ｓ６０２でのＧＰＳログの蓄積とは独立した処理として、休憩時間の開始時刻になるとサーバ３１０ｂがステップＳ６０４〜Ｓ６１６の処理を行ってもよい。
【０３６１】
さて、ステップＳ６０４で端末・センサ間距離計算部３２４は、休憩開始時刻よりも所定の時間だけ遡った時刻以降のデータをＧＰＳログＤＢ３１１から抽出する。ここでの「所定の時間」は、実施形態に応じて適宜定められていてよい。
【０３６２】
以下では説明の便宜上、上記「所定の時間」を３０分とする。また、以下では説明の便宜上、ステップＳ６０３において「現在は１２時から１３時の休憩時間中である」と判断されたものとする。つまり、ステップＳ６０４では、端末・センサ間距離計算部３２４が１１時３０分以降のエントリをＧＰＳログＤＢ３１１から抽出するものとする。
【０３６３】
次に、ステップＳ６０５でサーバ３１０ｂは、端末３７０についてのループ変数ｊを１に初期化する。
そして、次のステップＳ６０６で端末・センサ間距離計算部３２４は、ステップＳ６０４で抽出したデータの中からさらに、ｊ番目の端末３７０のデータのみを抽出する。
【０３６４】
例えば、第１実施形態と同様に、端末３７０は、１分に１回ＧＰＳ情報を取得し、１５分に１回ＧＰＳログを送信してもよい。仮に、ｊ番目の端末３７０が１１時３５分と１１時５０分にＧＰＳログをサーバ３１０ｂに送信し、現在時刻が１２時１分であるとすれば、ステップＳ６０６では、１１時３０分から１１時５０分までのＧＰＳログのエントリが抽出される。
【０３６５】
そして、次のステップＳ６０７では、ｊ番目の端末３７０について、第１実施形態と同様にして、各センサユニット３５０についてフラグｆｌａｇｉ，ｊの値が求められる。なお、データ収集システム３００ｂ内のセンサユニット３５０の総数をＵとすると、１≦ｉ≦Ｕである。つまり、ステップＳ６０７では以下の処理が行われる。
【０３６６】
まず、図１２のステップＳ４０２と同様に、端末・センサ間距離計算部３２４が、適宜のウィンドウ間隔Ｗを用いて、ステップＳ６０６で抽出したエントリをいくつかのブロックに分割する。ステップＳ６０７で得られるブロックの数は、ステップＳ４０２でのブロック数とは異なるかもしれないが、以下では説明の便宜上、ステップＳ６０７でＮ個のブロックが得られたとする。なお、個々の端末３７０がＧＰＳログを送信するタイミングによっては、ブロックの個数Ｎが端末３７０ごとに異なる場合もあり得る。
【０３６７】
さて、その後、端末・センサ間距離計算部３２４と距離比較部３２５とアラーム決定部３３４が協働し、第１実施形態の図１２のステップＳ４０３〜Ｓ４１４と同様にして、フラグｆｌａｇｉ，ｊの値を求める。つまり、ｎ番目（１≦ｎ≦Ｎ）のブロックにおける、ｊ番目の端末とｉ番目のセンサユニット３５０との間の距離ｄｉｓｔｉ，ｊ，ｎと、ｉ番目のセンサユニット３５０についてのアラーム距離ａｌａｒｍｉに基づいて、フラグｆｌａｇｉ，ｊの値が求められる。なお、図１７のステップＳ５０３とＳ５０４は、ステップＳ６０７に含まれる。
【０３６８】
フラグｆｌａｇｉ，ｊの値がｔｒｕｅの場合は、すなわち、「ｉ番目のセンサユニット３５０についてのアラーム指示を出す対象の端末３７０の候補として、ｊ番目の端末３７０を、アラーム決定部３３４が暫定的に選んだ」という場合である。逆に、フラグｆｌａｇｉ，ｊの値がｆａｌｓｅの場合は、「ｉ番目のセンサユニット３５０についてのアラーム指示を出す対象の端末３７０の候補として、アラーム決定部３３４はｊ番目の端末３７０を選ばなかった」という場合である。
【０３６９】
以上のようにしてステップＳ６０７で得られたフラグｆｌａｇｉ，ｊの値は、第２実施形態では暫定的な値である。より具体的には、フラグｆｌａｇｉ，ｊの値がｔｒｕｅの場合、値がｆａｌｓｅに変更される余地がある。
【０３７０】
つまり、フラグｆｌａｇｉ，ｊの値は、次のステップＳ６０８で書き換えられることがある。ステップＳ６０８の圃場特定・アラーム再判定処理の詳細は図１９とともに後述するが、ステップＳ６０８は図１７のステップＳ５０５〜Ｓ５０６に対応する。そして、ステップＳ６０８での再判定により、具体的には、フラグｆｌａｇｉ，ｊの値が場合に応じて書き換えられる。
【０３７１】
つまり、フラグｆｌａｇｉ，ｊの値は、「今日、ｉ番目のセンサユニット３５０についてのアラーム指示をｊ番目の端末３７０に送信するか否か」を示す。よって、ステップＳ６０８の再判定により、「ｉ番目のセンサユニット３５０についてのアラーム指示の送信が後日に延期される」と決まる場合は、ステップＳ６０８でフラグｆｌａｇｉ，ｊは、「送信しない」と示す値（つまりｆａｌｓｅ）に書き換えられる。
【０３７２】
その後、ステップＳ６０９でサーバ３１０ｂは、すべての端末３７０について注目し終えたか否かを判断する。つまり、サーバ３１０ｂは、端末３７０についてのループ変数ｊの値がデータ収集システム３００ｂ内の端末３７０の総数Ｔに達したか否かを判断する。
【０３７３】
そして、ｊ＝Ｔの場合、処理はステップＳ６１１に移行する。他方、ｊ≠Ｔの場合（より具体的にはｊ＜Ｔの場合）は、未注目の端末３７０が残っているので、処理はステップＳ６１０に移行する。
ステップＳ６１０でサーバ３１０ｂは、端末３７０についてのループ変数ｊをインクリメントする。その後、処理はステップＳ６０６に戻る。
【０３７４】
さて、ステップＳ６１１の処理が実行されるのは、データ収集システム３００ｂ内のすべてのセンサユニット３５０と端末３７０の組み合わせについて、フラグｆｌａｇｉ，ｊが設定された後である。そして、ステップＳ６１１の時点でのフラグｆｌａｇｉ，ｊの値は、「アラーム指示の送信を後日に延期するか否か」についてのアラーム決定部３３４の再判定結果を反映している。そこで、ステップＳ６１１〜Ｓ６１６では、再判定結果を反映したフラグｆｌａｇｉ，ｊの値を参照して適宜アラーム指示を送信するための処理が行われる。
【０３７５】
具体的には、まずステップＳ６１１でサーバ３１０ｂが、センサユニット３５０についてのループ変数ｉを１に初期化する。
そして、次のステップＳ６１２でアラーム決定部３３４が、ｉ番目のセンサユニット３５０に対応するフラグｆｌａｇｉ，ｊの値がｔｒｕｅの端末３７０のリストを取得する。ステップＳ６１２で取得されるリストは、具体的には端末ＩＤのリストであり、式（５）の集合ｔａｒｇｅｔｊを表すリストである。ただし、第２実施形態では、式（５）のフラグｆｌａｇｉ，ｊは、再判定結果を反映している点で第１実施形態のフラグｆｌａｇｉ，ｊと異なる。
【０３７６】
そして、次のステップＳ６１３でアラーム決定部３３４は、ｉ番目のセンサユニット３５０との距離が最短の端末３７０を、ステップＳ６１２で得たリストの中から選択する。
なお、例えばｊ番目の端末３７０の端末ＩＤがステップＳ６１２で得られたリスト中に存在する場合、ステップＳ６１３でｊ番目の端末３７０に関して参照される距離として、例えば以下のようなものが利用可能である。
【０３７７】
・ステップＳ６０７でフラグｆｌａｇｉ，ｊの値を暫定的に求めるのに用いられた、Ｎ個のブロックに対応するＮ個の距離ｄｉｓｔｉ，ｊ，１〜ｄｉｓｔｉ，ｊ，Ｎの、平均値または最小値が使われてもよい。すると、リスト中の各端末３７０の休憩時間の直近３０分における動きが、ステップＳ６１３の選択に反映される。
・より直近の端末３７０の位置を重視するならば、最後のブロック（つまりＮ番目のブロック）から得られた距離ｄｉｓｔｉ，ｊ，Ｎが使われてもよい。
【０３７８】
そして、次のステップＳ６１４でアラーム決定部３３４は、ステップＳ６１３で選択した端末３７０に、通信部３２７を介して、ｉ番目のセンサユニット３５０に関するアラーム指示を送信する。なお、ステップＳ６１２で得られたリストが空リストの場合は、アラーム決定部３３４はステップＳ６１３で何も選択しないので、ステップＳ６１４でもアラーム指示の送信は行われない。
【０３７９】
その後、ステップＳ６１５でサーバ３１０ｂは、センサユニット３５０についてのループ変数ｉの値がデータ収集システム３００ｂ内のセンサユニット３５０の総数Ｕに達したか否かを判断する。
【０３８０】
そして、ｉ＝Ｕの場合、今回の休憩時間の開始に合わせて送信する対象のアラーム指示はすべて送信し終わっているので、処理がステップＳ６０１に戻る。逆に、ｉ≠Ｕの場合（より具体的にはｉ＜Ｕの場合）は、未注目のセンサユニット３５０が残っているので、処理はステップＳ６１６に移行する。
【０３８１】
そして、ステップＳ６１６でサーバ３１０ｂは、センサユニット３５０についてのループ変数ｉをインクリメントする。その後、処理はステップＳ６１２に戻る。
さて、続いて図１９を参照して、上記のステップＳ６０８の圃場特定・アラーム再判定処理について説明する。図１８から理解されるとおり、圃場特定・アラーム再判定処理は、ｊ番目の端末３７０（１≦ｊ≦Ｔ）について呼び出される。
【０３８２】
ステップＳ７０１で圃場特定部３３３は、圃場ＩＤリストを空に初期化する。
そして、次にステップＳ７０２で圃場特定部３３３は、引数で指定されたｊ番目の端末３７０についてステップＳ６０６で抽出されたＧＰＳログの各ブロックでの平均座標を取得する。
【０３８３】
なお、ステップＳ７０２で取得する対象の平均座標（すなわち、式（２）のａｖｒｊ，ｎ）は、図１８のステップＳ６０７でフラグｆｌａｇｉ，ｊの値を暫定的に求めるために、既に端末・センサ間距離計算部３２４が計算済みである。例えば、端末・センサ間距離計算部３２４は、ステップＳ６０７で得た各端末３７０の各ブロックでの平均座標ａｖｒｊ，ｎの値を、圃場特定部３３３からもアクセス可能なＲＡＭ４０２上の領域に格納しておいてもよい。すると、ステップＳ７０２で圃場特定部３３３は、単にＲＡＭ４０２からｊ番目の端末３７０の各ブロックについての平均座標ａｖｒｊ，ｎの値を読み出すだけでよい。もちろん、圃場特定部３３３は、端末・センサ間距離計算部３２４と同様の方法にて、ステップＳ７０２で改めて、ｊ番目の端末３７０の各ブロックでの平均座標ａｖｒｊ，ｎを計算してもよい。
【０３８４】
いずれにせよ、圃場特定部３３３は、ｊ番目の端末３７０に関して、ブロックの個数Ｎと同数の平均座標ａｖｒｊ，１〜ａｖｒｊ，Ｎを取得する。そして、圃場特定部３３３は、取得した各平均座標ａｖｒｊ，ｎ（１≦ｎ≦Ｎ）について、圃場形状ＤＢ３２９に形状が登録されている圃場の中から、当該平均座標ａｖｒｊ，ｎを含む圃場を探す。そして、もし圃場が見つかれば、圃場特定部３３３は、見つかった圃場の圃場ＩＤを、ステップＳ７０１で初期化した圃場ＩＤリストに追加する。
【０３８５】
ここで、説明の便宜上、圃場形状ＤＢ３２９には、Ｈ箇所の圃場の形状が登録されているものとする。すると、ｎ番目のブロックの平均座標ａｖｒｊ，ｎを含む圃場を探して圃場ＩＤリストを更新する上記の処理は、具体的には例えば以下のような処理である。
【０３８６】
圃場特定部３３３は、１番目の圃場から順に注目していく。ここで、圃場特定部３３３が処理対象として注目しているのがｈ番目の圃場であるとする（１≦ｈ≦Ｈ）。
このとき、圃場特定部３３３は、ｈ番目の圃場の形状を近似する多角形のすべての頂点の座標（つまり緯度と経度）を、圃場形状ＤＢ３２９から読み出す。そして、「与えられた点が多角形の内部または辺上に位置するか否か」を判定するための公知のアルゴリズムにしたがって、圃場特定部３３３は、「平均座標ａｖｒｊ，ｎがｈ番目の圃場の内部または境界線上に位置するか否か」を判定する。
【０３８７】
もし、平均座標ａｖｒｊ，ｎがｈ番目の圃場の内部または境界線上に位置していれば、圃場特定部３３３は、ｈ番目の圃場の圃場ＩＤを、圃場ＩＤリストに追加する。なお、圃場特定部３３３は、ｎ番目のブロックの平均座標ａｖｒｊ，ｎに関しては、もう残りの圃場に注目する必要はない。
【０３８８】
逆に、平均座標ａｖｒｊ，ｎが、ｈ番目の圃場の外部に位置していれば、圃場特定部３３３は、未注目の圃場が残っているか否か（つまりｈ＜Ｈか否か）を判断する。そして、もしｈ＜Ｈならば、次の圃場に注目して、ｎ番目のブロックの平均座標ａｖｒｊ，ｎに関する上記の処理を繰り返す。逆に、既にＨ箇所すべての圃場に注目し終えていれば、ｎ番目のブロックの平均座標ａｖｒｊ，ｎは、どの圃場から見ても外部に位置しているので、ｎ番目のブロックに関する処理は終了する。
【０３８９】
以上のようにして、ステップＳ７０２で圃場特定部３３３は、各平均座標ａｖｒｊ，ｎ（１≦ｎ≦Ｎ）について、当該平均座標ａｖｒｊ，ｎを含む圃場を探し、見つかった圃場の圃場ＩＤを圃場ＩＤリストに追加する。
【０３９０】
例えば、ｊ番目の端末３７０が、休憩時間の開始３０分前からずっと１番目の圃場の中に位置していたとする。すると、圃場ＩＤリストには、１番目の圃場の圃場ＩＤのみが含まれる。
【０３９１】
あるいは、ｊ番目の端末３７０が、休憩時間の開始直前の３０分間のうち、最初の１０分間は１番目の圃場に位置しており、その後移動して、残りの時間はずっと２番目の圃場に位置していたとする。すると、圃場ＩＤリストには、１番目と２番目の圃場の圃場ＩＤが含まれる。
【０３９２】
以上のようにして、ｊ番目の端末３７０が休憩時間の開始直前の３０分間に位置していたことのある圃場が判明すると、次に、ステップＳ７０３でアラーム決定部３３４は、以下の処理を行う。すなわち、アラーム決定部３３４は、圃場ＩＤリストに圃場ＩＤが含まれる圃場に設置されたすべてのセンサユニット３５０のリストを求める。
【０３９３】
リストは、具体的にはセンサユニットＩＤのリストとして表される。また、アラーム決定部３３４は、具体的には、圃場ＩＤリストに含まれる圃場ＩＤを検索キーにして図１５の収集日ＤＢ３２８を検索することで、当該圃場ＩＤで識別される圃場に設置されたセンサユニット３５０のセンサユニットＩＤを取得することができる。
【０３９４】
例えば、ステップＳ７０２で得られた圃場ＩＤリストに、「０００５」と「０００７」という圃場ＩＤのみが含まれているとする。また、圃場ＩＤが「０００５」の圃場にはセンサユニットＩＤが「０００１」と「０００２」のセンサユニット３５０が設置されており、圃場ＩＤが「０００７」の圃場にはセンサユニットＩＤが「００１０」のセンサユニット３５０が設置されているとする。すると、アラーム決定部３３４は、ステップＳ７０３で、「０００１」と「０００２」と「００１０」という３つのセンサユニットＩＤを要素として含むリストを取得する。
【０３９５】
そして、次のステップＳ７０４でアラーム決定部３３４は、ステップＳ７０３で得たリストの各要素に順に注目するためのループ変数ｂを１に初期化する。
また、次のステップＳ７０５でアラーム決定部３３４は、図１５の収集日ＤＢ３２８を参照して、ステップＳ７０３で得たリスト内のｂ番目のセンサユニットＩＤに対応してアラーム予定日が設定されているか否かを判断する。図１５に示すように、収集日ＤＢ３２８では、あるセンサユニットＩＤに対してはアラーム予定日が設定されているかもしれないが、別のあるセンサユニットＩＤに対してはアラーム予定日が設定されていないかもしれない。そこで、アラーム決定部３３４は、ｂ番目のセンサユニットＩＤに対応するアラーム予定日の有無を、収集日ＤＢ３２８を参照して判断する。
【０３９６】
もし、ｂ番目のセンサユニットＩＤに対応するアラーム予定日があれば、処理はステップＳ７０６に移行する。つまり、過去にアラーム決定部３３４が後述の図２０の処理を行うことで設定されたアラーム予定日が見つかれば、処理はステップＳ７０６に移行する。
【０３９７】
例えば、図１６のスケジュール例５０２の「作業１日目」に、図２０の処理が行われて、「作業最終日」がアラーム予定日として設定されたとする。この場合、「作業２日目」に図１９の処理が呼び出されると、ステップＳ７０５で、設定済みのアラーム予定日が見つかる。
【０３９８】
逆に、ｂ番目のセンサユニットＩＤに対応するアラーム予定日がなければ、処理はステップＳ７０５からステップＳ７０８へと移行する。例えば、図１６のスケジュール例５０１の「作業１日目」に初めて図１９の処理が呼び出された場合には、アラーム予定日がまだ設定されていない。
【０３９９】
さて、ステップＳ７０６が実行されるのは、上記のとおり、リスト中のｂ番目のセンサユニット３５０に関して、アラーム予定日が設定されている場合である。この場合、アラーム決定部３３４は、設定されているアラーム予定日が今日またはそれより前の日付であるか否かを判断する。
【０４００】
そして、設定されているアラーム予定日が今日またはそれより前の日付である場合、リスト中のｂ番目のセンサユニット３５０に関して、アラーム指示の送信を延期する必要はない。よって、設定されているアラーム予定日が今日またはそれより前の日付である場合は、フラグの暫定的な値を何も変えずに、ただ処理がステップＳ７１０へと移行する。
【０４０１】
つまり、リスト中のｂ番目のセンサユニット３５０と、引数で指定されたｊ番目の端末３７０の組み合わせに対応するフラグの暫定的な値がｔｒｕｅであれば、フラグの値はｔｒｕｅのままでよい。
【０４０２】
逆に、フラグの暫定的な値がｆａｌｓｅであれば、そもそもリスト中のｂ番目のセンサユニット３５０についてのアラーム距離よりも遠くにｊ番目の端末３７０がある。つまり、ｊ番目の端末３７０はそもそも、リスト中のｂ番目のセンサユニット３５０に関するアラーム指示の送信対象ではないので、フラグの暫定的な値を書き換える必要がない。
【０４０３】
よって、設定されているアラーム予定日が今日またはそれより前の日付である場合、フラグの暫定的な値が何であれ、処理はステップＳ７１０へと移行する。
逆に、既に設定されているアラーム予定日が今日よりも後の日付である場合は、リスト中のｂ番目のセンサユニット３５０に関するアラーム指示の送信は、アラーム予定日まで延期可能である。つまり、リスト中のｂ番目のセンサユニット３５０に関するアラーム指示は、今日送信する必要がない。そこで、今日の送信をキャンセルするために、処理はステップＳ７０７に移行する。
【０４０４】
そして、ステップＳ７０７でアラーム決定部３３４は、リスト中のｂ番目のセンサユニット３５０に関するアラーム指示の今日の送信を強制的にキャンセルする。つまり、アラーム決定部３３４は、リスト中のｂ番目のセンサユニット３５０と、引数で指定されたｊ番目のセンサユニット３５０の組み合わせに対応するフラグの値を、暫定的な値がｔｒｕｅであるかｆａｌｓｅであるかによらず、強制的にｆａｌｓｅに設定する。そして、処理はステップＳ７１０に移行する。
【０４０５】
さて、ステップＳ７０８が実行されるのは、リスト中のｂ番目のセンサユニット３５０に関してアラーム予定日が設定されていない場合である。この場合、「アラーム予定日を新たに設定することができるか否か」、すなわち、「リスト中のｂ番目のセンサユニット３５０に関してアラーム指示の送信を延期する余地があるか否か」をアラーム決定部３３４が判断する。
【０４０６】
具体的には、ステップＳ７０８でアラーム決定部３３４は、リスト中のｂ番目のセンサユニット３５０が設置されている圃場について、「今日または明日以降のスケジュールがスケジュールＤＢ３３０に登録されているか否か」を判断する。なお、アラーム決定部３３４は、収集日ＤＢ３２８を参照することで、リスト中のｂ番目のセンサユニット３５０が設置されている圃場の圃場ＩＤを認識することができる。あるいは、アラーム決定部３３４は、ステップＳ７０３の処理を行ったときに、圃場ＩＤとセンサユニットＩＤの対応関係をＲＡＭ４０２上に記憶しておいてもよい。
【０４０７】
もし、リスト中のｂ番目のセンサユニット３５０が設置されている圃場について、今日または明日以降、スケジュールＤＢ３３０に１つもスケジュールが登録されていなければ、処理はステップＳ７１０に移行する。なぜなら、スケジュールが登録されていなければ、リスト中のｂ番目のセンサユニット３５０についてのアラーム指示の送信を延期する余地はないからである。つまり、リスト中のｂ番目のセンサユニット３５０と、引数で指定されたｊ番目の端末３７０の組み合わせに対して暫定的に決められたフラグの値を書き換える必要がないからである。
【０４０８】
逆に、リスト中のｂ番目のセンサユニット３５０が設置されている圃場について、今日または明日以降、スケジュールＤＢ３３０に１つ以上スケジュールが登録されていれば、場合によっては、アラーム指示の送信を延期することが可能である。つまり、スケジュールの分布と前回の収集日からの経過時間によっては、リスト中のｂ番目のセンサユニット３５０に関するアラーム指示の送信を、明日以降に延期することが可能な場合がある。そこで、延期の可能性を検討し、可能ならばアラーム予定日を設定してアラーム指示の送信を延期するために、処理はステップＳ７０９に移行する。
【０４０９】
そして、ステップＳ７０９のスケジュール確認処理では、リスト中のｂ番目のセンサユニット３５０に関するアラーム指示の送信の延期の可能性が検討され、可能ならばアラーム予定日が新たに設定される。ステップＳ７０９の詳細は図２０とともに後述する。また、ステップＳ７０９の実行後、処理はステップＳ７１０に移行する。
【０４１０】
さて、ステップＳ７１０は、リスト中のｂ番目のセンサユニット３５０と、引数で指定されたｊ番目の端末３７０の組み合わせに関して、フラグの値を書き換えた後、またはフラグの値を書き換える必要がないと判明した後に、実行される。すなわち、フラグの値が確定すると、ステップＳ７１０が実行される。
【０４１１】
ステップＳ７１０でアラーム決定部３３４は、ステップＳ７０３で求めたリスト内の全センサユニット３５０に注目し終えたか否かを判断する。そして、未注目のセンサユニット３５０が残っている場合は、処理がステップＳ７１１に移行する。逆に、リスト内の全センサユニット３５０に、アラーム決定部３３４が既に注目し終えた場合は、図１９の圃場特定・アラーム再判定処理（つまり図１８のステップＳ６０８）も終了する。
【０４１２】
ステップＳ７１１でアラーム決定部３３４は、センサユニットＩＤのリスト内の要素に関するループ変数ｂをインクリメントする。そして、処理はステップＳ７０５に戻る。
さて、続いて図２０を参照して、上記のステップＳ７０９のスケジュール確認処理について説明する。図１９から理解されるとおり、スケジュール確認処理は、確認の対象として指定された特定のセンサユニット３５０と端末３７０の組み合わせに対して呼び出される。つまり、具体的には、図２０のスケジュール確認処理は、センサユニットＩＤと端末ＩＤを引数として呼び出される。
【０４１３】
ステップＳ８０１でアラーム決定部３３４は、スケジュールの初日として、今日に注目する。以下ではアラーム決定部３３４が注目している日付を「注目日」という。
そして、次のステップＳ８０２でアラーム決定部３３４は、図２０の処理を開始してから今までに数えた作業なし期間の回数が２回未満か否かを判断する。ステップＳ８０２の判断が最初に実行される時点では、今までに数えた作業なし期間の回数は当然０回である。
【０４１４】
なお、ステップＳ８０２における「２回」という閾値は、図１５のスケジュール単位定義ＤＢ３３２の「作業なし期間の最大回数」として定義されている値であり、実施形態に応じて適宜その他の値が用いられてもよい。
【０４１５】
スケジュール単位定義ＤＢ３３２や図１６に関して説明したごとく、作業のひとかたまりの単位は、３日以内の作業なし期間を２回までははさんでいてもよい。しかし、３回目の作業なし期間のところで、作業のひとかたまりの単位は途切れる。
【０４１６】
よって、今までに数えた作業なし期間の回数が既に２回に達しているならば、注目日から始まって連続する１日以上の作業予定日の最後の日で、作業のひとかたまりの単位は終了する。逆に、今までに数えた作業なし期間の回数が２回未満ならば、注目日から始まって連続する１日以上の作業予定日の最後の日よりもさらに後の日付までを、作業のひとかたまりの単位として見なせる可能性がある。
【０４１７】
そこで、今までに数えた作業なし期間の回数が既に２回に達していれば、処理はステップＳ８０６に移行する。逆に、今までに数えた作業なし期間の回数が２回未満ならば、処理はステップＳ８０３に移行する。
【０４１８】
ステップＳ８０３でアラーム決定部３３４は、引数として指定されたセンサユニットＩＤのセンサユニット３５０が存在する圃場における、注目日から始まって連続する作業予定日の後の、次の作業予定日までの作業なし日数を数える。なお、注目日から連続する作業予定日は、１日だけの場合もあるし、２日以上の場合もある。
【０４１９】
例えば、図１６のスケジュール例５０３の「作業１日目」が注目日の場合、注目日から始まって連続する作業予定日は３日であり、ステップＳ８０３でアラーム決定部３３４が数えた結果は２日である。
【０４２０】
ステップＳ８０３の処理は、具体的には例えば次のような処理である。アラーム決定部３３４は、収集日ＤＢ３２８を参照することで、引数として指定されたセンサユニットＩＤのセンサユニット３５０が存在する圃場の圃場ＩＤを特定する。そして、アラーム決定部３３４は、特定した圃場ＩＤを検索キーにしてスケジュールＤＢ３３０を検索し、注目日から連続する作業予定日の後の次の作業予定日までの作業なし日数を数える。
【０４２１】
なお、図２０の処理は、図１９のステップＳ７０８で「今日または明日以降のスケジュールがスケジュールＤＢ３３０に登録されている」と確認されたときに実行される。そして、説明の簡単化のため、スケジュールＤＢ３３０が正しい（すなわち、スケジュールどおりにユーザが作業を行う）と仮定するならば、少なくとも今日は何らかの作業が予定されているはずである。なぜなら、以下のように考えられるからである。
【０４２２】
・今日、ある圃場で作業が予定されており、その予定にしたがってユーザが当該圃場にいたからこそ、ユーザが携帯する端末３７０が当該圃場に存在していることが図１９のステップＳ７０２で検出された。
【０４２３】
・その結果、当該圃場に設置されたセンサユニット３５０と、上記ユーザの携帯する端末３７０の組み合わせに対して、図１９のステップＳ７０９から、図２０の処理が呼び出された。
【０４２４】
・よって、図２０の処理が呼び出される場合、引数として指定されたセンサユニットＩＤのセンサユニット３５０が存在する圃場に関して、少なくとも今日は何らかの作業が予定されている。
【０４２５】
したがって、ステップＳ８０３では、引数として指定されたセンサユニットＩＤのセンサユニット３５０が存在する圃場において、注目日から始まる１日以上の連続した作業予定日が存在する。
【０４２６】
ただし、注目日から始まる１日以上の連続した作業予定日の後の、次の作業予定日は、あるとは限らない。例えば、図１６のスケジュール例５０２において、注目日が「作業１日目」の場合、注目日から始まる１日以上の連続した作業予定日は、「作業１日目」から「作業最終日」までの３日間である。しかし、当該３日間の後には何の予定もまだないので、「次の作業予定日」は見つからない。このように、次の作業予定日がない場合、アラーム決定部３３４は、ステップＳ８０３において、「次の作業予定日までの作業なし日数は、無限大である」と認識する。
【０４２７】
以上のようにしてステップＳ８０３で作業なし日数を数えた後、アラーム決定部３３４は、ステップＳ８０４において、作業なし日数が３日より多いか否かを判断する。なお、ステップＳ８０４における「３日」という閾値は、図１５のスケジュール単位定義ＤＢ３３２の「作業なし期間の最大長さ」として定義されている値であり、実施形態に応じて適宜その他の値が用いられてもよい。
【０４２８】
スケジュール単位定義ＤＢ３３２や図１６に関して説明したごとく、作業なし日数が３日より多ければ、そこで作業のひとかたまりの単位は途切れる。そこで、処理はステップＳ８０６に移行する。
【０４２９】
逆に、作業なし日数が３日以内であれば、作業のひとかたまりの単位がまだ終わっていない可能性がある。そこで、処理はステップＳ８０５に移行する。
ステップＳ８０５でアラーム決定部３３４は、ステップＳ８０３で日数を数えた作業なし日をはさんだ、次の作業予定日に注目する。例えば、図１６のスケジュール例５０３において、現在の注目日が「作業１日目」の場合、ステップＳ８０５で「作業再開１日目」が新たな注目日として注目される。そして、アラーム決定部３３４が注目日を更新すると、処理はステップＳ８０２に戻る。
【０４３０】
ステップＳ８０６でアラーム決定部３３４は、注目日から連続する１日以上の作業予定日の最後の日を、ひとかたまりのスケジュールの最終日として決定する。
例えば、ステップＳ８０５に関して例示したように、図１６のスケジュール例５０３の「作業再開１日目」が新たな注目日となった場合は、その後のステップＳ８０３で数えられる作業なし日数は無限大である。よって、処理はステップＳ８０４からステップＳ８０６へと進む。そして、ステップＳ８０６でアラーム決定部３３４は、注目日である「作業再開１日目」から連続する作業予定日の最後の日（つまり、図１６に示す「再開後作業最終日」）を、ひとかたまりのスケジュールの最終日として決定する。
【０４３１】
なお、スケジュールＤＢ３３０に登録されているスケジュールによっては、ステップＳ８０６で決定される最終日が、今日と一致する場合もある（例えば、今日１日だけ作業が予定されており、明日以降の予定がまったくない場合など）。
【０４３２】
また、次のステップＳ８０７でアラーム決定部３３４は、ステップＳ８０１で注目した初日（すなわち今日）における、前回のデータ収集からの経過日数と閾値を比較する。
より具体的には、アラーム決定部３３４は、引数で指定されるセンサユニットＩＤを含むエントリを図１５の収集日ＤＢ３２８で検索し、見つかったエントリの収集日を読み取る。そして、アラーム決定部３３４は、図２０の処理を行っている今日の日付から、読み取った収集日を引くことで、経過日数を計算する。
【０４３３】
また、ステップＳ８０７で参照される閾値は、実施形態に応じて適宜定められる。例えば、「１０日」などと固定の閾値が使われてもよい。あるいは、ステップＳ８０７で参照される閾値は、引数で指定されるセンサユニットＩＤに依存する値であってもよい。
【０４３４】
例えば、アラーム決定部３３４は、引数で指定されたセンサユニットＩＤと対応づけられているアラーム条件ＩＤを図６のセンサユニット別アラーム条件ＤＢ３１９から読み取る。そして、アラーム決定部３３４は、読み取ったアラーム条件ＩＤに対応するエントリをアラーム条件ＤＢ３２０で検索する。そして、アラーム決定部３３４は、見つかったエントリのアラーム条件で使われる境界値のうち、最大のものを、ステップＳ８０７での閾値として利用してもよい。
【０４３５】
例えば、図６のセンサユニット別アラーム条件ＤＢ３１９の例では、「０００２」というセンサユニットＩＤに対応するアラーム条件ＩＤは「０１」である。そして、「０１」というアラーム条件ＩＤで識別されるアラーム条件で使われる最大の境界値は、図６のアラーム条件ＤＢ３２０の例では、「条件４」フィールドに設定されている「１０日」という値である。よって、「０００２」というセンサユニットＩＤが図２０の処理の引数として与えられた場合、アラーム決定部３３４は、ステップＳ８０７での閾値として「１０日」を利用してもよい。
【０４３６】
もちろん、実施形態によっては、アラーム決定部３３４は、上記のようにして見つかったアラーム条件で使われる境界値のうち２番目に大きなものを使ってもよいし、あるいは、最大の境界値から所定値（例えば１日）を引いた値を使ってもよい。
【０４３７】
なお、具体的にどのような閾値が利用されるにしろ、初日における経過日数が閾値以上のとき、図２０のスケジュール確認処理は終了する。
つまり、初日における経過日数が閾値以上のとき、アラーム決定部３３４は「初日の時点で既にアラーム指示の送信を延期する余地がない」と判断する。よって、引数として与えられたセンサユニットＩＤと端末ＩＤの組に対応して図１８のステップＳ６０７で求められたフラグは、書き換え不要である。そのため、初日における経過日数が閾値以上のときは、フラグの書き換えは行われず、そのままスケジュール確認処理が終了する。
【０４３８】
逆に、初日における経過日数が閾値未満の場合、アラーム指示の送信を延期する余地があるかもしれない。そこで、処理はステップＳ８０８に移行する。
ステップＳ８０８でアラーム決定部３３４は、ステップＳ８０６で決定した最終日における、前回のデータ収集からの経過日数と閾値を比較する。アラーム決定部３３４は、最終日から、ステップＳ８０７で読み取った収集日を引くことで、最終日における経過日数を計算する。また、ステップＳ８０８で使われる閾値は、ステップＳ８０７で使われる閾値と同じものである。
【０４３９】
最終日における経過日数が閾値未満であれば、アラーム指示の送信を最終日まで延期することは妥当である。そこで、処理はステップＳ８０９に移行する。
逆に、最終日における経過日数が閾値以上であれば、処理はステップＳ８１０に移行する。例えば、「閾値が７日であり、前回の収集が２日前であり、今日から１５日間連続で作業が予定されている」といった場合など、作業のひとかたまりの単位が長期間に及ぶ場合があり得る。そのような場合には、最終日よりも前にサーバ３１０ｂが一旦センサログを収集することが好ましい。そのため、ステップＳ８０８でアラーム決定部３３４は最終日における経過日数と閾値を比較している。
【０４４０】
さて、ステップＳ８０９でアラーム決定部３３４は、図１５の収集日ＤＢ３２８にアラーム予定日を設定する。具体的には、アラーム決定部３３４は、引数で指定されたセンサユニットＩＤに対応する収集日ＤＢ３２８のエントリを検索し、見つかったエントリのアラーム予定日に、ステップＳ８０６で決定した最終日の日付を設定する。
【０４４１】
さらに、ステップＳ８０９でアラーム決定部３３４は、引数で指定されたセンサユニットＩＤと端末ＩＤの組み合わせに対応して図１８のステップＳ６０７で求められたフラグの値を、ｆｌａｓｅに設定する。つまり、アラーム決定部３３４は、「今日は、引数で指定されたセンサユニットＩＤに関して、引数で指定された端末ＩＤの端末３７０にアラーム指示を送信しない」と決定する。そして、図２０のスケジュール確認処理は終了する。
【０４４２】
また、ステップＳ８１０でアラーム決定部３３４は、図１５の収集日ＤＢ３２８にアラーム予定日を設定する。具体的には、アラーム決定部３３４は、ステップＳ８０７で読み取った前回の収集日に、ステップＳ８０７とＳ８０８で使った閾値を足し、前回の収集日から閾値のぶんだけ経過した日付を計算する。また、アラーム決定部３３４は、引数で指定されたセンサユニットＩＤに対応する収集日ＤＢ３２８のエントリを検索し、見つかったエントリのアラーム予定日に、上記の計算で得られた日付を設定する。
【０４４３】
さらに、ステップＳ８１０でアラーム決定部３３４は、引数で指定されたセンサユニットＩＤと端末ＩＤの組み合わせに対応して図１８のステップＳ６０７で求められたフラグの値を、ｆｌａｓｅに設定する。つまり、アラーム決定部３３４は、「今日は、引数で指定されたセンサユニットＩＤに関して、引数で指定された端末ＩＤの端末３７０にアラーム指示を送信しない」と決定する。そして、図２０のスケジュール確認処理は終了する。
【０４４４】
以上のようにして、図２０のスケジュール確認処理により、アラーム指示の送信の延期の妥当性が検討され、検討結果に応じてフラグが書き換えられる。よって、書き換え後のフラグに応じて図１８のステップＳ６１１〜Ｓ６１６の処理が行われることで、不急のアラーム指示の送信が抑制される。
【０４４５】
なお、以上の図１８〜２０の処理についてまとめれば以下の通りである。
サーバ３１０ｂは、センサユニット３５０が設置された領域における作業のスケジュールを認識し、端末３７０にアラームを出させる（つまりユーザへの指示を与えさせる）日または日時を、スケジュールに応じて決定する。具体的には、図２０のステップＳ８０７に示すように、所定の基準よりも経過時間が長ければ、サーバ３１０ｂは、日または日時を決定する処理が行われる当日を、端末３７０にアラームを出させる日として決定する。逆に、所定の基準よりも経過時間が短ければ、サーバ３１０ｂは、スケジュールによって作業が計画されている日と計画されていない日の分布に基づいて、端末３７０にアラームを出させる日または日時の延長期限を決定する。
【０４４６】
例えば、図２０の例では、ステップＳ８０１〜Ｓ８０６で認識された分布に基づいて、ステップＳ８０９またはＳ８１０で延長期限が決定されている。そして、延長期限の決定は、例えば以下のような情報と上記分布を照らし合わせた結果に基づく。
【０４４７】
・作業なし期間の長さの上限と、作業なし期間の回数の上限の少なくとも一方（例えば、スケジュール単位定義ＤＢ３３２の例では双方）
・前回のデータ収集時点からの時間の長さの上限（例えば、図２０のステップＳ８０７〜Ｓ８１０で使われる閾値）
【０４４８】
そして、サーバ３１０ｂは、アラーム指示の与え方を制御することで、端末３７０に、決定された日または日時にアラームをユーザに与えさせる。アラーム指示の与え方を制御する方法としては、上記のように、アラーム指示を端末３７０に与えるタイミングを、決定された日または日時に応じて（つまり、アラーム予定日や休憩時間などに応じて）制御する方法がある。あるいは、サーバ３１０ｂは、アラーム指示の与え方を制御する方法として、「アラームをユーザに与える日または日時を指定する情報をアラーム指示に含めて端末３７０に送る」という方法を採用してもよい。
【０４４９】
ところで、本発明は上記の第１〜２実施形態に限られるものではない。上記の説明においてもいくつかの変形について説明したが、上記実施形態は、さらに例えば下記の（１）〜（９）の観点から様々に変形することもできる。上記および下記の変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。
【０４５０】
（１）ハードウェア構成についての変形
図４には、プログラムにしたがって動作する汎用的なプロセッサ（すなわち、ＣＰＵ４０１、ＭＰＵ４２２、およびＭＰＵ４４２）が例示されている。しかし、汎用的なプロセッサの代わりに、ＡＳＩＣ（Application Specific Integrated Circuit）などの専用のハードウェア回路が利用されてもよいし、汎用的なプロセッサと専用のハードウェア回路の組み合わせが利用されてもよい。
【０４５１】
（２）データ構造についての変形
また、図面では便宜上、各種ＤＢをテーブル形式で表現しているが、各種ＤＢのデータ構造は実施形態に応じて適宜変形されてもよい。例えば、アレイや連想配列などが利用されてもよいし、ＸＭＬ（Extensible Markup Language）などによりマークアップされた形式のデータが利用されてもよい。
【０４５２】
また、例えばセンサユニットＩＤを一意のキーとして含む複数のＤＢが、１つのテーブルにまとめられてもよい。また、センサログは、図７のように１つのエントリが複数のセンサについてのフィールドを有する形式でもよいし、１つのエントリが１つのセンサについてのフィールドとセンサを識別するフィールドを有する形式であってもよい。
【０４５３】
（３）数値の計算方法についての変形
実施形態によっては、式（３）の代わりに式（６）が使われてもよい。また、式（４）の代わりに式（７）が使われてもよい。
【０４５４】
【数６】
【０４５５】
【数７】
【０４５６】
さらに、式（２）などで使われるウィンドウ間隔Ｗの値が１であってもよい（つまり、ウィンドウが利用されなくてもよい）。なお、式（７）のようにＮ個のブロック間で距離を平均する代わりに、Ｎ個のブロック間で最小距離を求めてもよい。
【０４５７】
また、実施形態によっては、アラーム距離が、離散的に図６のようにＤＢにより定義されるのではなく、経過時間ｐを引数とする連続関数ｆ（ｐ）により定義されてもよい。経過時間ｐに対して単調増加する適宜の関数が、アラーム距離を定義する関数ｆ（ｐ）として利用可能である。
【０４５８】
もちろん、図６のアラーム条件ＤＢ３２０と同様に境界値を規定するＤＢと、境界値同士の間の補間によって、アラーム距離が連続的に定義されてもよい。つまり、アラーム距離は、経過時間につれて増大するように定義されてさえいれば、どのような形式で定義されていてもよい。
【０４５９】
（４）閾値その他の定数についての変形
上記に説明したいくつかの処理は、閾値との比較を含む（例えば、図１２のステップＳ４０８や、図２０のステップＳ８０７とＳ８０８など）。閾値との比較は、実施形態に応じて「比較対象の数値が、閾値を超えるか否か」を判断する処理でもよいし、「比較対象の数値が、閾値以上か否か」を判断する処理でもよい。また、上記の説明における各種定数の例は、説明の便宜上のものである。各種定数の具体的な値は、実施形態に応じて適宜に決められてよい。
【０４６０】
（５）センサユニットの設置場所に関する変形
なお、図２と１３には、センサユニット２０２が圃場２０１に設置される例を示したが、センサユニット２０２が設置される場所は、端末３７０のユーザのうち少なくとも１人が何らかの作業を行う任意の領域であってよい。センサユニット２０２は、例えば、以下のような場所に設置されてもよい。また、当該場所における作業スケジュールが第２実施形態と同様にして参照され、アラーム予定日の決定のために用いられてもよい。
・水田、畑をはじめとする各種圃場
・林班、準林班、林小班などの、林業用に区切られた森林区画
・放牧場、養鶏場、養豚場、養牛場など、畜産業が営まれる場所
・養魚場、その他の水生生物（藻類、海老、真珠など）の養殖場（人工池でもよいし、自然の湖沼、河川、港湾等の特定部分でもよい）など、水産業が営まれる場所
・養蜂場など、その他の生き物を飼養するための場所
・鉱山、採石場、砂利採取場など、鉱業が営まれる場所
・土木工事現場、建設現場など、建設業が営まれる場所
【０４６１】
圃場をはじめとして、上記に例示したような場所は、広い屋外であることが多いので、データ収集に関与するためのユーザの負担（例えば移動距離の長さ）を無視しがたい。よって、上記に例示したような場所にセンサユニット３５０が設置されている場合に、データ収集システム３００や３００ｂは好適である。
【０４６２】
また、農林水産業などの第一次産業では特に、毎日同じ場所での作業が予定されているとは限らない。つまり、毎日データ収集が可能であるとは限らず、データ収集の緊急度が日によって変動し得る。よって、農林水産業等に関連する上記のような場所に設置されたセンサユニット３５０を含むシステムとして、データ収集システム３００や３００ｂは好適である。
【０４６３】
また、データ収集システム３００ｂは、作業スケジュールと経過時間に基づいて柔軟にアラーム予定日を適宜延期するという点においても、毎日同じ場所での作業が予定されているとは限らない農林水産業向けのシステムとして好適である。
【０４６４】
（６）端末３７０間の比較を第１実施形態に導入する変形
ところで、第１実施形態と第２実施形態を比べると、第２実施形態では図１８のステップＳ６１３で端末３７０間の比較が行われるのに対し、第１実施形態では端末３７０間の比較は行われない。しかし、ある１台のセンサユニット３５０からアラーム距離の範囲内に、複数のユーザがいる場合もあり得る。よって、端末３７０間の比較をサーバ３１０が行うように、第１実施形態が変形されてもよい。具体的には次のとおりである。
【０４６５】
ある１台のセンサユニット３５０からアラーム距離の範囲内に、複数のユーザがいるとする。この場合、ユーザの負荷軽減という観点からは、サーバ３１０は、複数のユーザがそれぞれ携帯する複数の端末３７０のうち、センサユニット３５０により近い一部の端末３７０にのみ、アラーム指示を送信することが好ましい。例えば、サーバ３１０は、センサユニット３５０に最も近い１台の端末３７０にのみ、アラーム指示を送信してもよい。
【０４６６】
そして、センサユニット３５０からアラーム距離の範囲内の複数の端末３７０の中から一部だけをアラーム指示の送信対象として選び出すためには、サーバ３１０は、端末３７０間でセンサユニット３５０までの距離を比較すればよい。例えば、サーバ３１０は、図１２のように個々の端末３７０からステップＳ４０１でＧＰＳログを受信するたびにステップＳ４０２〜Ｓ４１５の処理を行うのではなく、ＧＰＳログの受信と蓄積を行う処理と、アラーム指示の送信に関する処理を独立して行ってもよい。
【０４６７】
例えば、サーバ３１０は、いずれかの端末３７０からＧＰＳログを受信するたびに、ＧＰＳログＤＢ３１１にＧＰＳログを蓄積する。一方で、サーバ３１０は、所定の間隔で（例えば１時間ごとに）、次のような処理を行ってもよい。
【０４６８】
サーバ３１０は、直近の所定の時間（例えば上記間隔と同じ１時間でもよいし、より短い１５分などの時間でもよい）に受信されたＧＰＳログを、ＧＰＳログＤＢ３１１から抽出する。そして、サーバ３１０は、抽出したＧＰＳログについて、端末３７０ごとに、図１２のステップＳ４０２〜Ｓ４１３と同様の処理を行う。
【０４６９】
その後、サーバ３１０は、各センサユニット３５０について、当該センサユニット３５０に対応するフラグの値がｔｒｕｅの端末３７０の端末ＩＤを抽出する。もし、２台以上の端末３７０の端末ＩＤが抽出された場合、サーバ３１０は、当該センサユニット３５０までの距離が一番短い端末３７０を選択する。
【０４７０】
ここで、端末３７０間での比較のために使われるセンサユニット３５０までの距離としては、例えば、複数のブロックについてそれぞれステップＳ４０７で計算された距離の最小値または平均値が利用可能である。あるいは、最新のブロックについてステップＳ４０７で計算された距離が利用されてもよい。
【０４７１】
以上のようにしてサーバ３１０は、各センサユニット３５０に関して端末３７０を選択し、当該センサユニット３５０についてのアラーム指示を、選択した端末３７０に対してのみ送信してもよい。すると、「あるセンサユニット３５０の近辺に大勢のユーザがいる場合に、全員の端末３７０がアラームを発してしまう」といった事態が避けられるようになり、複数のユーザ全体での作業効率の悪化を防ぐことができる。
【０４７２】
なお、以上のような第１実施形態の変形例と図１３〜２０の第２実施形態は、「あるセンサユニット３５０からの距離がアラーム距離未満の端末３７０が２台以上ある場合に、アラーム指示を与える対象の端末３７０を絞り込む」という点で共通である。その絞り込みは、具体的には、「センサユニット３５０からの距離がアラーム距離未満の端末３７０のうちで、相対的に距離が短い端末３７０に絞り込む」という処理である。そして、以上の絞り込みにより、第１実施形態の変形例でも、第２実施形態でも、複数のユーザ全体での作業効率の悪化を防ぐことができる。
【０４７３】
（７）休憩時間に関する変形
ところで、第２実施形態では、図１５の休憩時間ＤＢ３３１のような静的なデータに基づいて、図１８のステップＳ６０３で「現在が休憩時間か否か」という判断が下される。しかし、例えば、サーバ３１０ｂは、ＧＰＳログＤＢ３１１に基づいて端末３７０が存在する位置を追跡することで、動的に休憩時間を認識してもよい。例えば、端末３７０が所定の時間以上、１箇所に留まっている場合に、サーバ３１０ｂは、「当該端末３７０のユーザは休憩中である」と判断してもよい。
【０４７４】
また、圃場ごとに休憩時間が異なる場合は、休憩時間ＤＢ３３１のデータ構造が、圃場ごとに休憩時間を管理するように変形されてもよい。そして、サーバ３１０ｂは、個々の圃場について、当該圃場での休憩時間になったら、当該圃場に設置されているセンサユニット３５０のみを対象として、図１８のステップＳ６０４〜Ｓ６１６と同様の処理を行ってもよい。
【０４７５】
（８）アラーム指示の送信タイミングに関する変形
図１８のステップＳ６０３では、現在時刻が休憩時間に該当するか否かが判断される。しかし、サーバ３１０ｂは、例えば休憩終了時刻よりも所定時間だけ前の時刻にステップＳ６０４以降の処理を行うことで、ユーザが休憩終了直後、作業を始める前にデータ収集に関与することができるようにしてもよい。
【０４７６】
あるいは、サーバ３１０ｂは、例えば休憩開始時刻よりも所定時間だけ前の時刻にステップＳ６０４以降の処理を行ってもよい。その場合、サーバ３１０ｂは、さらに、アラーム指示の送信のタイミングを調整してもよい。つまり、サーバ３１０ｂは、休憩時間に応じて決まる適宜の時刻にアラームがユーザに与えられるようにアラーム指示の与え方を制御すればよく、「休憩時間に応じて決まる適宜の時刻」が具体的にどのような時刻であるかは、実施形態によって異なっていてよい。
【０４７７】
例えば、１２時から１３時が休憩時間であり、上記の所定時間が１０分間とする。この場合、サーバ３１０ｂは、ＧＰＳログの受信および蓄積とは独立して、１１時５０分になったらステップＳ６０４以降の処理を開始してもよい。
【０４７８】
端末３７０のユーザは、必ずしも予定どおり１２時きっかりに休憩を始めるとは限らない。例えば、ユーザは、１２時よりも少し前から休憩し始めて、昼食をとるために圃場から出て行こうとするかもしれない。このような状況を想定すると、ユーザが圃場から出て行ってセンサユニット３５０から遠ざかってしまう前に、確実に端末３７０がアラームを発するようにするために、サーバ３１０ｂが１１時５０分にステップＳ６０４以降の処理を行うことは有意義である。
【０４７９】
なお、その結果として１１時５０分に端末３７０がアラームを発した場合であっても、ユーザは１２時から休憩をとるかもしれない。たとえそうだとしても、ユーザは、アラームを受けた後、自分の都合のよいとき（例えば１２時になったとき）にアラームにしたがってセンサユニット３５０に近寄ればよい。
【０４８０】
また、あるセンサユニット３５０についてのアラーム距離が長い場合、当該センサユニット３５０に関するアラーム指示は、当該センサユニット３５０から遠く離れた端末３７０へと送信される可能性がある。そして、センサユニット３５０からの距離が長いほど、ユーザがセンサユニット３５０まで移動するのにかかる時間も長い。
【０４８１】
例えば、サーバ３１０ｂが、あるセンサユニット３５０から歩いて５分の距離にいるユーザの端末３７０にアラーム指示を送信する場合、サーバ３１０ｂは、休憩開始時刻の５分以上前にアラーム指示を送信してもよい。すると、端末３７０からアラームを受けたユーザは、アラームにしたがってセンサユニット３５０まで移動してデータ収集に関与しても、「データ収集に関与することで休憩時間が減ってしまう」ということがない。
【０４８２】
つまり、サーバ３１０ｂは、休憩開始時刻よりも所定時間前（例えば１１時５０分）になったら、ステップＳ６０４〜Ｓ６１０の処理を行い、さらに、各センサユニット３５０についてステップＳ６１２とＳ６１３の処理を行ってもよい。そして、ｉ番目のセンサユニット３５０についてのアラーム指示の送信先としてステップＳ６１３で選んだ端末３７０からの、ｉ番目のセンサユニット３５０までの距離に応じて、サーバ３１０ｂがアラーム指示の送信時刻を決めてもよい。例えば、サーバ３１０ｂは、ステップＳ６１３で選んだ端末３７０がｉ番目のセンサユニット３５０から遠いほど、送信時刻を早くしてもよい。そして、送信時刻になったら、サーバ３１０ｂは、アラーム指示を送信する。
【０４８３】
以上述べたとおり、休憩時間の開始に合わせてユーザにデータ収集に関与させる場合は、サーバ３１０ｂが休憩開始時刻よりも前にステップＳ６０４以降の処理を開始することが有益である。
【０４８４】
なお、上記とは逆に、サーバ３１０ｂは、ステップＳ６１３で選んだ端末３７０がｉ番目のセンサユニット３５０から遠いほど、送信時刻を遅くしてもよい。
例えば、もし端末３７０のユーザがセンサユニット３５０から歩いて１分の距離にいるのであれば、データ収集への関与の手間はさほど大きくない。そこで、休憩時間に入る前にユーザがデータ収集への関与をさっさと済ますことができるように、サーバ３１０ｂは、早め（例えば１１時５０分）にアラーム指示を送信してもよい。
【０４８５】
他方、もし端末３７０のユーザがセンサユニット３５０から歩いて１５分の距離にいるのであれば、例えばサーバ３１０ｂは休憩開始時刻まで待ってから端末３７０にアラーム指示を送信してもよい。つまり、センサユニット３５０から遠くにいるユーザに関しては、サーバ３１０ｂは、休憩開始時刻まではユーザの作業をアラームによって邪魔しないことを優先させてもよい。
【０４８６】
（９）スケジュール確認処理に関する変形
図２０のスケジュール確認処理のステップＳ８１０によれば、アラーム予定日がたまたま途中の作業なし日にあたってしまう場合もあり得る。そこで、アラーム決定部３３４は、前回のデータ収集日に閾値を足した日が作業なし日にあたる場合は、当該作業なし日よりも前で当該作業なし日の直近の作業予定日を、アラーム予定日として決定してもよい。
【０４８７】
例えば、図２０のステップＳ８０７〜Ｓ８１０で使われる閾値が１０日であるとする。すると、図１６のスケジュール例５０４のように、前回のデータ収集日から１０日後が作業なし日にあたる場合もある。この場合、アラーム決定部３３４は、当該作業なし日よりも前で当該作業なし日の直近の作業予定日（スケジュール例５０４の例では、「前回収集日」から７日後の「作業最終日」）を、アラーム予定日として設定してもよい。
【０４８８】
また、図２０のスケジュール確認処理では、アラーム決定部３３４が作業のひとかたまりの単位を認識するが、作業のひとかたまりの単位をどのように定義するかは、実施形態に応じて任意である。図１５のスケジュール単位定義ＤＢ３３２とは異なる基準で、作業のひとかたまりの単位が定義されてもよい。
【０４８９】
つまり、作業のひとかたまりの単位に関しては、その中に含まれる作業予定日と作業なし日の分布に関する何らかの基準が与えられさえすればよく、具体的にどのような基準が使われるかは、実施形態に応じて任意である。例えば、スケジュール単位定義ＤＢ３３２により与えられる基準の代わりに、以下のような基準を適宜に組み合わせた基準が利用されてもよい。
・開始日と終了日には作業が予定されていること
・作業なし日の比率が所定値（例えば２５％）以下であること
・作業なし日の合計日数が所定値（例えば６日）以下であること
【０４９０】
最後に、上記の種々の実施形態に関して、さらに下記の付記を開示する。
（付記１）
コンピュータに、
前記コンピュータが収集する対象のデータを記憶しているデータ記憶装置が設置されている第１の位置を認識し、
前記データ記憶装置に記憶されていたデータを、前記データ記憶装置および前記コンピュータの双方と通信可能な１台以上の端末のいずれかを介して、過去に前記コンピュータが収集した収集時点からの、経過時間を認識し、
前記経過時間が長いほど大きくなるように定義された閾値を、前記経過時間に基づいて取得し、
前記１台以上の端末のうち少なくとも１台の端末について、
当該端末の存在する第２の位置を認識し、
前記第１の位置と前記第２の位置の間の距離を計算し、
前記距離が前記閾値未満のとき、当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第１の指示を当該端末のユーザに対して与えるよう、第２の指示を与える
ことを含む処理を実行させるプログラム。
（付記２）
前記データ記憶装置は、前記１台以上の端末それぞれのユーザのうち少なくとも１人が作業を行う領域に設置されており、
前記プログラムが前記コンピュータに実行させる前記処理が、さらに、
前記領域における前記作業のスケジュールを認識し、
前記端末に前記第１の指示を与えさせる日または日時を、前記スケジュールに応じて決定し、
前記第２の指示の与え方を制御することで、前記端末に、決定された前記日または前記日時に前記第１の指示を前記ユーザに与えさせる、
ことを含む
ことを特徴とする付記１に記載のプログラム。
（付記３）
前記日または前記日時を決定する処理は、
所定の基準よりも前記経過時間が長ければ、前記日または前記日時を決定する前記処理が行われる当日を、前記端末に前記第１の指示を与えさせる日として決定し、
前記基準よりも前記経過時間が短ければ、前記スケジュールによって前記作業が計画されている日と計画されていない日の分布に基づいて、前記端末に前記第１の指示を与えさせる前記日または前記日時の延長期限を決定する
ことを含む
ことを特徴とする付記２に記載のプログラム。
（付記４）
前記延長期限を決定する処理が、
前記作業が計画されていない日が連続する作業なし期間の長さの上限と、前記作業なし期間の回数の上限の少なくとも一方と、
前記収集時点からの時間の長さの上限
を前記分布と照らし合わせた結果に基づく
ことを特徴とする付記３に記載のプログラム。
（付記５）
前記プログラムが前記コンピュータに実行させる前記処理が、さらに、
前記作業の休憩時間に応じて決まる時刻に、前記端末に前記第１の指示を与えさせるように、前記第２の指示の与え方を制御することを含む
ことを特徴とする付記３または４に記載のプログラム。
（付記６）
前記プログラムが前記コンピュータに実行させる前記処理が、さらに、
前記休憩時間を表す情報を読み出すこと、または、
前記第２の指示を与える対象の前記端末が存在する位置を追跡すること
により、前記休憩時間を認識することを含む
ことを特徴とする付記５に記載のプログラム。
（付記７）
前記第２の指示の与え方を制御する処理は、
前記第２の指示を前記端末に与えるタイミングを、決定された前記日または前記日時に応じて制御するか、または、
決定された前記日または前記日時を指定する情報を、前記第２の指示に含める
ことを含む
ことを特徴とする付記２から６のいずれか１項に記載のプログラム。
（付記８）
前記プログラムが前記コンピュータに実行させる前記処理は、前記１台以上の端末のいずれかから、前記データ記憶装置から当該端末に転送されて格納されたデータを、前記コンピュータが受信するたびに、当該データを前記コンピュータが受信した収集時点を記憶することを含み、
前記経過時間を認識する処理は、記憶された前記収集時点と現在日時に基づいて前記経過時間を計算することを含む
ことを特徴とする付記１から７のいずれか１項に記載のプログラム。
（付記９）
前記１台以上の端末と前記データ記憶装置との間の通信は無線通信であり、
前記第１の指示は、前記ユーザに対して前記データ記憶装置へ接近することを求める指示である
ことを特徴とする付記１から８のいずれか１項に記載のプログラム。
（付記１０）
前記１台以上の端末の数は複数であり、
前記プログラムが前記コンピュータに実行させる前記処理は、
前記複数の端末のうち少なくとも２台以上の端末について、前記第１の位置と前記第２の位置の間の前記距離を計算し、
前記距離が前記閾値未満の端末が２台以上ある場合、前記第２の指示を与える対象の端末を、前記距離が前記閾値未満の端末のうちで相対的に前記距離が短い端末に絞り込む
ことを含む
ことを特徴とする付記１から９のいずれか１項に記載のプログラム。
（付記１１）
情報処理装置であって、
前記情報処理装置が収集する対象のデータを記憶しているデータ記憶装置が設置されている第１の位置を示す位置情報を記憶する記憶手段と、
前記データ記憶装置と通信可能な１台以上の端末の各々との通信を行う通信手段と、
前記データ記憶装置に記憶されていたデータを、前記１台以上の端末のいずれかと前記通信手段を介して過去に前記情報処理装置が収集した収集時点からの経過時間を認識し、前記経過時間が長いほど大きくなるように定義された閾値を、認識した前記経過時間に基づいて取得する取得手段と、
前記１台以上の端末のうち少なくとも１台の端末について、当該端末の存在する第２の位置を認識する位置認識手段と、
前記記憶手段から前記位置情報を読み出し、前記位置情報が示す前記第１の位置と、前記位置認識手段が認識した前記第２の位置との間の距離を計算する計算手段と、
前記計算手段が計算した前記距離が、前記取得手段が取得した前記閾値未満のとき、前記計算手段が前記距離の計算に用いた前記第２の位置に存在すると前記位置認識手段により認識された当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第１の指示を当該端末のユーザに対して与えるよう、第２の指示を与える指示手段
を備える情報処理装置。
（付記１２）
コンピュータが、
前記コンピュータが収集する対象のデータを記憶しているデータ記憶装置が設置されている第１の位置を認識し、
前記データ記憶装置に記憶されていたデータを、前記データ記憶装置および前記コンピュータの双方と通信可能な１台以上の端末のいずれかを介して、過去に前記コンピュータが収集した収集時点からの、経過時間を認識し、
前記経過時間が長いほど大きくなるように定義された閾値を、前記経過時間に基づいて取得し、
前記１台以上の端末のうち少なくとも１台の端末について、
当該端末の存在する第２の位置を認識し、
前記第１の位置と前記第２の位置の間の距離を計算し、
前記距離が前記閾値未満のとき、当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第１の指示を当該端末のユーザに対して与えるよう、第２の指示を与える
ことを特徴とする方法。
【符号の説明】
【０４９１】
１００、３００、３００ｂ データ収集システム
１０１ コンピュータ
１０２ データ記憶装置
１０３、１０４、３７０、３７０ａ〜３７０ｃ 端末
１０５、１０６、２０４、２０６、２０９ ユーザ
１０７ アラーム範囲
１０８ 説明図
２０１ 圃場
２０２、３５０、３５０ａ〜３５０ｃ センサユニット
２０３ 検知領域
２０５、２０７、２１０〜２１３ 軌跡
２０８ 非作業領域
３１０、３１０ｂ サーバ
３１１ ＧＰＳログＤＢ
３１２ 端末管理ＤＢ
３１３ ＧＰＳログ処理部
３１４、３２８ 収集日ＤＢ
３１５ センサログＤＢ
３１６ センサログ処理部
３１７ センサ位置ＤＢ
３１８ センサ種別ＤＢ
３１９ センサユニット別アラーム条件ＤＢ
３２０ アラーム条件ＤＢ
３２１ サンプリング周期ＤＢ
３２２ データ量条件ＤＢ
３２３ アラーム距離決定部
３２４ 端末・センサ間距離計算部
３２５ 距離比較部
３２６、３３４ アラーム決定部
３２７ 通信部
３２９ 圃場形状ＤＢ
３３０ スケジュールＤＢ
３３１ 休憩時間ＤＢ
３３２ スケジュール単位定義ＤＢ
３３３ 圃場特定部
３５１ 各種センサ
３５２ センサログＤＢ
３５３ センサログ処理部
３５４ 通信部
３７１ ＧＰＳ情報取得部
３７２ ＧＰＳログＤＢ
３７３ サーバ通信部
３７４ アラーム処理部
３７５ センサ通信部
３７６ センサログＤＢ
３７７ センサログ処理部
４０１ ＣＰＵ
４０２、４２３、４４３ ＲＡＭ
４０３ ＨＤＤ
４０４ ネットワークＩＦ
４０５ 機器ＩＦ
４０６ ディスプレイＩＦ
４０７ 駆動装置
４１１ ネットワーク
４１２ キーボード
４１３ マウス
４１４、４５１ ディスプレイ
４１５ 記憶媒体
４２１、４４１ バッテリ
４２２、４４２ ＭＰＵ
４２４、４４４ フラッシュＲＯＭ
４２５、４２７ 温度センサ
４２６ 湿度センサ
４２８ 人感センサ
４２９〜４３３ センサＩＦ
４３４、４４５ 近距離無線通信機
４４６ ＧＰＳ受信機
４４７ ３Ｇ通信機
４４８ ＬＥＤ
４４９ ブザー
４５０ 振動モータ
５０１〜５０４ スケジュール例
【技術分野】
【０００１】
本発明は、端末のユーザの関与を伴うデータ収集システムで使われるプログラム、情報処理装置および方法に関する。
【背景技術】
【０００２】
様々な分野において、目的地または目標物の位置と現在位置に応じた制御が利用されている。
例えば、ユーザが端末を携帯している場合、目標物の位置と端末の現在位置との間の距離が所定値未満のときに、端末がユーザに対して何らかのメッセージ（例えば、指示、警告、通知など）を提示してもよい。
【０００３】
また、省電力化を図りつつ、本来の検出動作ならびにそれに伴う警報動作をすることを目的として、以下のようなマイクロ波検出器が提案されている。
マイクロ波検出器内のマイクロ波検出器本体で目的のマイクロ波を受信した場合には、マイクロ波検出器は、警報器を操作して警報出力をする。
【０００４】
また、マイクロ波検出器は、ＧＰＳ（Global Positioning System）情報を取得するＧＰＳ検出部と、目標物（検出対象物等）の位置情報を記憶する位置記憶部を有する。マイクロ波検出器はさらに、ＧＰＳ検出部で検出した現在位置と位置記憶部に記憶された周囲に存在する目標物の位置情報から、その目標物までの距離を求める距離検出部を有する。
【０００５】
そして、マイクロ波検出器は、位置情報に基づき車両の走行方向を検出する進行方向検出部と、目標物の方向を検出する目標物方向検出部と、各検出部の出力に基づいてＧＰＳ検出部の動作を制御する動作制御部も有する。動作制御部は、目標物までの距離が短いほど、間欠動作する間隔を短くなるように制御する。
【０００６】
また、周辺風景から、位置データが示す位置あるいは目的地位置を利用者が容易に目視確認し得るようにすることを目的として、以下のような技術も提案されている。
ナビゲーション装置は、経路案内プログラムによる経路案内中、ＧＰＳセンサにより検出された現在位置が、目的地位置から所定範囲内にあるか否かを判断する。そして、ナビゲーション装置は、現在位置が所定範囲内にあると判断したとき、地点情報データベースに記憶された画像データに基づく画像を、描画プログラムによりディスプレイに表示させる。
【０００７】
これにより、所定範囲内に現在位置があると、画像データに基づく画像がディスプレイに表示される。よって、ディスプレイに表示された画像と現在位置の周辺風景とを見比べることによって、利用者は目的地位置を目視確認することができる。したがって、周辺風景から目的地位置を利用者が容易に目視確認することができる。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００２−２４３８３６号公報
【特許文献２】特開２００３−１９４５６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ところで、ある種のデータ収集システムは、端末のユーザの関与を伴う。例えば、データ収集システムは、データを収集するコンピュータと、当該コンピュータが収集する対象のデータを記憶しているデータ記憶装置を含んでもよい。しかし、コンピュータとデータ記憶装置が通信することができるとは限らない。
【００１０】
そこで、データ記憶装置およびコンピュータの双方と通信可能な端末が用いられてもよい。つまり、データ記憶装置からデータを一旦端末に転送し、その後、端末からデータをコンピュータに転送することで、データ記憶装置からコンピュータへのデータの収集が実現されてもよい。
【００１１】
そして、端末を介した上記のようなデータ収集は、何らかの意味でのユーザの関与を伴う。例えば、ユーザは、端末に対する操作を行うことで、データ収集に関与するかもしれない。
【００１２】
また、仮にデータ記憶装置から端末へのデータ転送や、端末からコンピュータへのデータ転送自体は自動的に行われるとしても、ユーザの関与は無ではない。例えば、端末をデータ記憶装置と通信可能な状態にするために、ユーザは「端末を携帯してデータ記憶装置に接近する」などの行為を行うことで、データ収集に関与するかもしれない。
【００１３】
つまり、端末を介した上記のようなデータ収集では、ユーザに何らかの手間が発生する。そして、「データ収集に関与するための行為をユーザが自発的または偶発的に行う」という可能性はあるが、「ユーザが当該行為を適時に必ず行う」という保証はない。
【００１４】
そこで、端末は、データ収集に関与するための行為を行うように、ユーザに指示を与えてもよい。換言すれば、端末は、データ記憶装置に記憶されているデータの端末への転送のための指示をユーザに与えてもよい。
【００１５】
ここで、上記に例示したような、目標物の位置と現在位置に応じた制御を利用して、目標物としてのデータ記憶装置の位置と端末の現在位置に応じて、端末がユーザに対して上記指示を与えることが考えられる。しかし、上記指示は、手間をかけることをユーザに要求する指示である。よって、上記指示を端末が濫発することは、ユーザに必要以上の負担をかけるおそれがあり、望ましくない。
【００１６】
例えば、ある端末を介してデータ記憶装置からデータがコンピュータに収集された後、しばらくの間は、次の収集対象のデータがまだない（または、少量しかデータ記憶装置に蓄積されていない）かもしれない。そして、「ユーザに対して上記指示を出すか否かという判断が、データ記憶装置と端末との間の距離に関する固定的な閾値に基づいてなされる」と仮定すると、結果的には指示が濫発されることになりかねない。例えば「次の収集対象のデータがない」という状況など、収集の緊急度が低い状況下では、固定的な閾値に基づく制御は、「端末が不急の指示を必要以上に出してしまう」という結果を招くおそれがある。
【００１７】
他方、仮に上記のような指示の濫発を防ぐために、収集の緊急度の低い状況に合わせて固定的な閾値を定めると、別の問題が生じかねない。すなわち、「たまたま、固定的な閾値で示される範囲内には１台も端末が存在しない」という場合は、たとえ収集の緊急度が高くても、結果的には「端末を介したデータ収集がすぐには行えない」という事態に陥るおそれがある。
【００１８】
そこで本発明の課題は、データ収集が端末のユーザの関与を伴う場合に、データの収集の緊急度とユーザの手間のバランスをとることである。
【課題を解決するための手段】
【００１９】
一態様において提供されるプログラムは、コンピュータに以下の処理を実行させる。
当該処理は、前記コンピュータが収集する対象のデータを記憶しているデータ記憶装置が設置されている第１の位置を認識することを含む。また、当該処理は、前記データ記憶装置に記憶されていたデータを、前記データ記憶装置および前記コンピュータの双方と通信可能な１台以上の端末のいずれかを介して、過去に前記コンピュータが収集した収集時点からの、経過時間を認識することを含む。さらに、当該処理は、前記経過時間が長いほど大きくなるように定義された閾値を、前記経過時間に基づいて取得することを含む。
【００２０】
また、当該処理は、前記１台以上の端末のうち少なくとも１台の端末について、当該端末の存在する第２の位置を認識し、前記第１の位置と前記第２の位置の間の距離を計算し、前記距離が前記閾値未満のとき、当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第１の指示を当該端末のユーザに対して与えるよう、第２の指示を与えることを含む。
【発明の効果】
【００２１】
データ記憶装置からのデータの収集の緊急度は、過去にコンピュータがいずれかの端末を介してデータ記憶装置からデータを収集してからの経過時間が長いほど、高いと考えられる。なぜなら、経過時間が長ければ、コンピュータは最近のデータをまだ収集しておらず、したがって、最近のデータが表す最近の状況をコンピュータは把握していないからである。つまり、経過時間は、収集の緊急度の指標である。
【００２２】
他方、第１の指示をユーザに与えることは、手間をかけることをユーザに要求することである。よって、第１の指示の濫発は好ましくない。換言すれば、第１の指示をユーザに対して与えるように端末に求める第２の指示の濫発は、好ましくない。
【００２３】
しかし、上記プログラムによれば、経過時間が短ければ、データ記憶装置から近い端末にしか第２の指示が与えられず、経過時間が長いほど、データ記憶装置からより遠い端末に対しても第２の指示が与えられるようになる。つまり、経過時間が短ければ、データ記憶装置から近い端末のユーザにしか第１の指示が与えられず、経過時間が長いほど、データ記憶装置からより遠い端末のユーザも、第１の指示を与えられることになる。
【００２４】
よって、上記プログラムによれば、収集の緊急度が低い場合（つまり経過時間が短い場合）は、収集の緊急度が高い場合（つまり経過時間が長い場合）と比べて、手間をかけることをユーザに要求する第１の指示が抑制される。すなわち、上記プログラムによれば、データの収集の緊急度と、ユーザの手間の間で、バランスをとることができる。
【図面の簡単な説明】
【００２５】
【図１】第１実施形態の概要を説明する図である。
【図２】ユーザの動きの例を示す図である。
【図３】第１実施形態のセンサデータ収集システムのブロック構成図である。
【図４】センサデータ収集システムのハードウェア構成図である。
【図５】サーバが保持する静的なＤＢの例を示す図（その１）である。
【図６】サーバが保持する静的なＤＢの例を示す図（その２）である。
【図７】センサに関連して動的に変化するＤＢの例を示す図である。
【図８】端末の移動につれて動的に変化するＤＢの例を示す図である。
【図９】第１実施形態のデータ収集システムの動作シーケンス図である。
【図１０】端末におけるＧＰＳログ処理のフローチャートである。
【図１１】サーバにおいて所定の時刻に行われるアラーム距離決定処理のフローチャートである。
【図１２】第１実施形態のアラーム関連処理のフローチャートである。
【図１３】データ収集への関与が原因でユーザの作業効率が悪くなる例を示す図である。
【図１４】第２実施形態のセンサデータ収集システムのブロック構成図である。
【図１５】第２実施形態においてサーバが保持するＤＢの例を示す図である。
【図１６】作業スケジュールとアラーム予定日の例を示す図である。
【図１７】第２実施形態のデータ収集システムの動作シーケンス図である。
【図１８】第２実施形態のアラーム関連処理のフローチャートである。
【図１９】圃場特定・アラーム再判定処理のフローチャートである。
【図２０】スケジュール確認処理のフローチャートである。
【発明を実施するための形態】
【００２６】
以下、実施形態について、図面を参照しながら詳細に説明する。具体的には、まず、図１〜１２を参照して第１実施形態について説明する。次に、図１３〜２０を参照して第２実施形態について、第１実施形態との違いを中心に説明する。最後に、その他の変形例についても説明する。
【００２７】
図１は、第１実施形態の概要を説明する図である。図１のデータ収集システム１００は、コンピュータ１０１とデータ記憶装置１０２と１台以上の端末を含む。図１では具体的には２台の端末１０３と１０４が例示されている。また、図１には、端末１０３を携帯するユーザ１０５と、端末１０４を携帯するユーザ１０６も図示されている。なお、図１にはデータ記憶装置１０２が１台しか図示されていないが、データ収集システム１００は複数のデータ記憶装置１０２を含んでもよい。
【００２８】
データ記憶装置１０２は、データを生成し、蓄積する。例えば、データ記憶装置１０２はセンサを有してもよく、センサが感知したデータを蓄積してもよい。データ記憶装置１０２は、センサ以外のモジュールによりデータを生成してもよい。つまり、データ記憶装置１０２が記憶するデータの種類は任意である。
【００２９】
データ収集システム１００は、データ記憶装置１０２に記憶されているデータをコンピュータ１０１が収集するシステムである。しかし、データ記憶装置１０２には、コンピュータ１０１と通信する機能がない。そこで、データ収集システム１００においては、データ記憶装置１０２からコンピュータ１０１へのデータの収集が、端末（例えば、端末１０３または１０４）を介して行われる。
【００３０】
端末１０３と１０４は、コンピュータ１０１と通信可能であり、データ記憶装置１０２とも通信可能である。したがって、データ記憶装置１０２に記憶されているデータは、データ記憶装置１０２から端末１０３に一旦転送され、端末１０３からコンピュータ１０１に転送されてもよい。もちろん、データは端末１０４を介してデータ記憶装置１０２からコンピュータ１０１に送られてもよい。いずれにしろ、データ収集システム１００では、端末を介してコンピュータ１０１がデータ記憶装置１０２からデータを収集する。
【００３１】
以下では説明の便宜上、端末１０３を介してデータが収集される場合を例として取り上げるが、端末１０３に関する説明は端末１０４についても同様に当てはまる。
第１実施形態では、コンピュータ１０１と端末１０３の間の通信は、例えば３Ｇ（3rd Generation）通信網などのネットワークを介して行われる。したがって、端末１０３は、物理的には必ずしもコンピュータ１０１の近傍に位置していなくても、不図示の基地局などを介してコンピュータ１０１と通信することができる。
【００３２】
他方、第１実施形態における端末１０３とデータ記憶装置１０２の間の通信は、物理的にデータ記憶装置１０２と端末１０３が近くに位置することを前提とする種類の通信である。具体的には、データ記憶装置１０２と端末１０３の間の通信は、近距離無線通信か有線通信である。
【００３３】
近距離無線通信の例は、例えば、以下のようなものである。
・ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１５シリーズの規格にしたがった通信。例えば、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＺｉｇＢｅｅ（登録商標）などによる通信。
・ＵＷＢ（Ultra Wide Band）による無線通信。
・ＩＥＥＥ８０２．１１シリーズの規格にしたがった無線ＬＡＮ（Local Area Network）通信。
・例えば、ＩＳＯ／ＩＥＣ１８０９２やＩＳＯ／ＩＥＣ２１４８１として規格化されているＮＦＣ（Near Field Communication）などの、近接場無線通信（なお、ＩＳＯはInternational Organization for Standardizationのこと、ＩＥＣはInternational Electrotechnical Commissionのことである）。
・赤外線や可視光線などを利用した光無線通信。
【００３４】
また、有線通信の例は、例えば、ＵＳＢ（Universal Serial Bus）ケーブルを介した通信である。
近距離無線通信と有線通信のどちらが利用されるにしろ、端末１０３は、データ記憶装置１０２に近づかないとデータ記憶装置１０２と通信することができない。換言すれば、端末１０３とデータ記憶装置１０２の間の通信は、端末１０３のユーザ１０５の関与を伴う。
【００３５】
具体的には、ユーザ１０５は、「端末１０３を携帯してデータ記憶装置１０２に十分に接近する」という行為を行うことで、端末１０３とデータ記憶装置１０２の間の通信に関与する。また、ユーザ１０５は、「端末１０３とデータ記憶装置１０２の間をケーブルで接続する」または「通信開始のために端末１０３のボタンを押す」などの操作をさらに行うことで、端末１０３とデータ記憶装置１０２の間の通信に関与することもある。もちろん、近距離無線通信が使われる場合、データ記憶装置１０２と通信可能な範囲に端末１０３が入ったら、データ記憶装置１０２と端末１０３が自動的に通信を始めてもよく、その場合、ユーザ１０５の関与はデータ記憶装置１０２への接近行為だけでもよい。
【００３６】
以上例示したようなデータ記憶装置１０２と端末１０３の間の通信への関与は、ユーザ１０５が自発的に行う可能性もある。また、ユーザ１０５が端末１０３を携帯したまま偶然データ記憶装置１０２の近くを通りかかる場合など、データ記憶装置１０２と端末１０３の間の通信に、ユーザ１０５が偶発的に関与することもある。
【００３７】
しかしながら、ユーザ１０５が必ず適時にデータ記憶装置１０２と端末１０３の間の通信に関与するとは限らない。もちろん、データ記憶装置１０２からのデータの収集は、端末１０３ではなく端末１０４を介して行われてもよいので、「データ収集のためには特定の１人のユーザ１０５の関与が必須」というわけではない。しかし、端末１０４のユーザ１０６も、データ記憶装置１０２と端末１０４の間の通信に必ず適時に関与するとは限らない。
【００３８】
そこで、第１実施形態では、データ記憶装置１０２からコンピュータ１０１へのデータ収集が適切に行われるようにするために、端末１０３がユーザ１０５に指示を与えるか、または、端末１０４がユーザ１０６に指示を与える。端末がユーザに与える指示は、具体的には、データ収集に関与するための行為を行うことをユーザに求める指示である。以下では説明の便宜上、端末がユーザに与える指示を「アラーム」という。
【００３９】
なお、「データ収集に関与するための行為」は、データ記憶装置１０２と端末の間の通信方法に応じて、上記のように、単にデータ記憶装置１０２に接近する行為だけであってもよい。あるいは、「データ収集に関与するための行為」は、ケーブルの接続操作またはボタン操作などの何らかのユーザ操作をさらに含んでもよい。しかし、以下では説明の簡単化のため、次のように仮定する。
【００４０】
・データ記憶装置１０２は、端末１０３および１０４との間で、近距離無線通信による通信を行う。
・データ記憶装置１０２は、通信可能な範囲内に入ってきた端末との間で自動的に通信を開始するので、ユーザはデータ記憶装置１０２への接近行為以外の行為を意識して行う必要はない。
【００４１】
ところで、たとえユーザがデータ収集に関与するための行為が、データ記憶装置１０２への接近行為だけであったとしても、ユーザに手間が生じることには変わりない。例えば、端末１０４がユーザ１０６に対するアラームを出した場合、ユーザ１０６には「遠くからわざわざデータ記憶装置１０２まで近寄る」という手間が生じる。
【００４２】
よって、端末１０４が必要以上にユーザ１０６に対してアラームを出すことは好ましくない。同様に、端末１０３が必要以上にユーザ１０５に対してアラームを出すことも好ましくない。
【００４３】
換言すれば、データ収集の緊急度または必要性に応じて、アラームの発行が適切に制御されることが好ましい。例えば、データ記憶装置１０２からデータがコンピュータ１０１に収集された直後は、次のデータ収集を行う緊急度が比較的低い。よって、データ収集の緊急度が低ければアラームの発行を抑制するように、データ収集システム１００が構成されることが好ましい。
【００４４】
そこで、第１実施形態では、具体的にはコンピュータ１０１が以下のような制御を行うことで、データ収集の緊急度または必要性に応じた適度のアラームの発行が実現される。
コンピュータ１０１は、データ記憶装置１０２が設置されている第１の位置を認識する。例えば、コンピュータ１０１は、第１の位置を記憶したデータベース（以下「ＤＢ」と略す）を参照することで、第１の位置を認識してもよい。
【００４５】
また、コンピュータ１０１は、データ記憶装置１０２に記憶されていたデータを、いずれかの端末を介して過去にコンピュータ１０１が収集した収集時点からの、経過時間を認識する。例えば、コンピュータ１０１は、いずれかの端末を介してデータ記憶装置１０２からデータを収集するたびに、収集日時または収集日を適宜のＤＢに記憶してもよい。そして、コンピュータ１０１は、記憶した収集日時を現在時刻から引くことで（または記憶した収集日を今日の日付から引くことで）、経過時間を認識してもよい。
【００４６】
さらに、コンピュータ１０１は、経過時間が長いほど大きくなるように定義された閾値を、経過時間に基づいて取得する。例えば、コンピュータ１０１は、経過時間と閾値を対応づけたＤＢを参照することにより、閾値を取得してもよい。コンピュータ１０１は、必要に応じて補間を行って閾値を取得してもよい。また、コンピュータ１０１は、経過時間を引数とする単調増加関数を用いて閾値を計算してもよい。
【００４７】
以下では説明の便宜上、当該閾値を「アラーム距離」という。アラーム距離は、端末とデータ記憶装置１０２との間の距離に関する閾値である。具体的には、アラーム距離は、「ユーザにアラームを出せ」という指示を、コンピュータ１０１が端末に与えるか否かの判断に使われる閾値である。図１には、データ記憶装置１０２を中心とし、アラーム距離を半径とする範囲（以下「アラーム範囲」という）１０７が図示されている。
【００４８】
以上のようにして得られたアラーム距離を用いた処理は、具体的には以下のとおりである。
コンピュータ１０１は、データ収集システム１００に含まれる端末（図１の例では端末１０３と１０４）のうち少なくとも１台の端末について、当該端末の存在する第２の位置を認識する。例えば、端末１０３は、ＧＰＳ機能を有してもよく、ＧＰＳ機能により認識した端末１０３自体の位置をコンピュータ１０１に通知してもよい。端末１０４も同様にして、ＧＰＳ機能により認識した端末１０４自体の位置をコンピュータ１０１に通知してもよい。すると、コンピュータ１０１は端末１０３と１０４の位置を認識する。
【００４９】
コンピュータ１０１は、第１の位置（つまりデータ記憶装置１０２の位置）と第２の位置（つまり個々の端末の位置）の間の距離を計算する。例えば、コンピュータ１０１は、データ記憶装置１０２の位置と端末１０３の位置の間の距離を計算するとともに、データ記憶装置１０２の位置と端末１０４の位置の間の距離を計算する。
【００５０】
なお、コンピュータ１０１が計算する距離は、ユークリッド距離（直線距離）でもよいし、緯度と経度を座標軸とするマンハッタン距離でもよい。また、コンピュータ１０１がある１台の端末（例えば端末１０３）について計算する距離は、ある１つの時点における当該端末の位置に基づく距離でもよいし、複数の時点における当該端末の位置に基づく距離でもよい。例えば、複数の時点における位置に基づいて得られる複数の距離の最小値もしくは平均値、または、複数の時点の平均位置から得られる距離などが利用可能である。
【００５１】
そして、コンピュータ１０１は、計算した距離がアラーム距離未満の端末に対して、データ記憶装置１０２に記憶されているデータの当該端末への転送のための第１の指示（つまりアラーム）を当該端末のユーザに対して与えるよう、第２の指示を与える。なお、計算した距離がちょうどアラーム距離と同じ端末に対してコンピュータ１０１が第２の指示を与えるか否かは、実施形態に応じて適宜方針が決められてよい。
【００５２】
例えば、図１では、端末１０３がアラーム範囲１０７内に位置しており、端末１０４がアラーム範囲１０７外に位置している。つまり、データ記憶装置１０２と端末１０３の距離はアラーム距離より短いが、データ記憶装置１０２と端末１０４の距離はアラーム距離より長い。よって、図１の例では、コンピュータ１０１は、ステップＳ１において、「ユーザ１０５に対してアラームを出せ」という指示（以下、「アラーム指示」ともいう）を端末１０３に与えるが、端末１０４に対しては特に指示を与えない。
【００５３】
すると、ステップＳ２で端末１０３は、アラーム指示にしたがって、ユーザ１０５に対してアラームを出し、データ収集への関与をユーザ１０５に促す。よって、ステップＳ３でユーザ１０５は、アラームにしたがってデータ記憶装置１０２に近づく。その結果、端末１０３がデータ記憶装置１０２に十分に近づくと、端末１０３は、データ記憶装置１０２と通信可能な状態となる。
【００５４】
すると、「ユーザはデータ記憶装置１０２への接近行為以外の行為を意識して行う必要はない」という上記仮定のとおり、ステップＳ４で自動的にデータ記憶装置１０２と端末１０３の間の通信が始まる。そして、データ記憶装置１０２に記憶されているデータが、端末１０３に転送される。
【００５５】
その後、ステップＳ５で端末１０３からコンピュータ１０１へとデータが転送される。ステップＳ５の転送も、端末１０３が自動的に行ってよく、ユーザ１０５が意識的にボタン操作などを行わなくてもよい。以上のようにして、コンピュータ１０１は、端末１０３を介してデータ記憶装置１０２からデータを収集することができる。
【００５６】
なお、ステップＳ５の転送は、ステップＳ４の直後に行われてもよいし、多少時間が経ってから行われてもよい。例えば、端末１０３の位置における電波状況が悪い場合には、端末１０３は、電波状況を監視し、電波状況が改善するまでステップＳ５の転送を待ってもよい。
【００５７】
図１の例では、以上のようにして端末１０３を介したデータ収集が行われる一方で、アラーム範囲１０７外にある端末１０４は、コンピュータ１０１からアラーム指示を受けないので、ユーザ１０６に対してアラームを出さない。よって、ユーザ１０６は、データ記憶装置１０２と端末１０４の通信のために何かを行う必要がない。換言すれば、アラーム範囲１０７外にいるユーザ１０６は、データ記憶装置１０２と端末１０４の通信のために煩わされることがない。
【００５８】
ところで、データ記憶装置１０２に近い位置にいるユーザほど、データ記憶装置１０２の位置まで移動するのにかかる手間は小さい。例えば、図１の例では、ユーザ１０５がデータ記憶装置１０２まで移動するのにかかる手間の方が、ユーザ１０６がデータ記憶装置１０２まで移動するのにかかる手間よりも小さい。
【００５９】
よって、上記のように経過時間が長いほど大きくなるように定義されたアラーム距離をコンピュータ１０１が使うことで、データ収集システム１００においては、データ収集の緊急度（換言すれば必要性）に応じて、アラームの発行が適切に制御される。つまり、コンピュータ１０１は、データ収集の緊急度が高いときには、ユーザの負担が大きくてもアラームが出されるように端末を制御するが、データ収集の緊急度が低いときには、負担が少ないユーザに対してのみアラームが出されるように端末を制御する。
【００６０】
以上説明したデータ収集システム１００の動作について、いくつかの評価軸を使って定性的にまとめると、図１の説明図１０８のとおりである。説明図１０８は、以下のことを示している。
【００６１】
前回の収集からの経過時間が長いほど、データ記憶装置１０２から収集したデータに基づいてコンピュータ１０１が把握している状況は古く、また、データ記憶装置１０２の残り記憶容量は少ない。よって、前回の収集からの経過時間が長いと、「コンピュータ１０１が、最近の状況を認識していない」という意味でも、「データ記憶装置１０２の記憶容量がもうすぐ使い尽くされてしまう」という意味でも、データ収集の緊急度（または必要性）は高い。
【００６２】
コンピュータ１０１が最近の状況を認識していないことは、例えば次のような問題を引き起こすおそれがある。例えば、コンピュータ１０１がデータ記憶装置１０２から収集したデータに基づいて何らかの制御を行うとする。この場合、コンピュータ１０１は、最近の状況を認識していないと、現状に合わない不適切な制御を行うおそれがある。
【００６３】
また、データ記憶装置１０２の記憶容量が使い尽くされてしまうと、データ記憶装置１０２は、たとえ次の新たなデータを生成しても、生成したデータを記憶せずに破棄するかもしれない。あるいは、データ記憶装置１０２は、端末１０３または１０４を介してのコンピュータ１０１への収集がまだ済んでいなくても、古い方からデータを破棄することで最新のデータを記憶するための記憶領域を確保するかもしれない。いずれにしろ、コンピュータ１０１にとっては、一部のデータが、データ記憶装置１０２から収集できないまま失われてしまうことになる。
【００６４】
以上のように、前回の収集からの経過時間が長いほど、データ収集の緊急度（または必要性）は高い。逆に、前回の収集からの経過時間が短ければ、データ収集の緊急度（または必要性）は比較的低い。
【００６５】
そして、アラーム距離は、経過時間が長いほど、長くなるように定義されている。つまり、データ収集の緊急度（または必要性）が高ければ、データ記憶装置１０２から遠いユーザに対してもアラームが出される一方で、データ収集の緊急度（または必要性）が低ければ、データ記憶装置１０２に近いユーザにしかアラームが出されない。
【００６６】
そして、データ記憶装置１０２から遠くにユーザがいるほど、データ記憶装置１０２までユーザが移動する手間は大きい。つまり、アラーム距離が長いほど、アラームを受けたユーザの負担が大きい傾向がある。
【００６７】
もちろん、閾値であるアラーム距離が長くても、たまたまデータ記憶装置１０２のすぐ近くにユーザがいれば、当該ユーザの負担は小さい。しかし、アラームを受けたユーザの負担の期待値は、アラーム距離が長いほど、大きい。
【００６８】
以上のように、コンピュータ１０１は、データ収集の緊急度（または必要性）が高ければ、「ユーザの負担が大きくてもやむを得ない」と判断し、ユーザにかかる負荷よりもデータ収集を優先する制御を行う。逆に、データ収集の緊急度（または必要性）が低ければ、コンピュータ１０１は、「ユーザの負担が小さければ、データ収集のためにユーザに協力してもらうが、ユーザの負担が大きければデータ収集を今すぐ行う必要はない」と判断する。つまり、データ収集の緊急度（または必要性）が低ければ、コンピュータ１０１は、データ収集よりもユーザにかかる負荷の軽減を優先する制御を行う。その結果、データ収集システム１００においては、データ収集の緊急度（または必要性）と、データ収集に関与するためにユーザにかかる負荷との間で、均衡がとれる。
【００６９】
続いて、具体的なユーザの動きの例を示す図２を参照して、図１に示したデータ収集システム１００の利点についてさらに詳しく説明する。
図２には、圃場２０１におけるユーザの動きの例が示されている。図１のデータ記憶装置１０２は、具体的には、例えば、圃場２０１内に設置されたセンサユニット２０２であってもよい。
【００７０】
センサユニット２０２は、データを取得するための１つ以上のセンサと、人感センサ（例えば赤外線センサなど）を有する。つまり、図２の例では、コンピュータ１０１が収集する対象のデータは、センサユニット２０２が有するセンサが生成したデータである。
【００７１】
センサユニット２０２はバッテリで駆動される。よって、通信による電力消費を抑えるために、センサユニット２０２は、通信機能を通常はオフにしている。
ここで、通信による電力消費と比べて、人感センサによる電力消費は少ない。よって、センサユニット２０２は、人感センサをオンにしておく。そして、人感センサがユーザを検知したら、センサユニット２０２は、通信機能をオンにして、ユーザが携帯する端末と通信する。
【００７２】
しかし、圃場２０１は広く、人感センサがユーザを検知することのできる検知領域２０３は、圃場２０１のごく一部である。よって、端末がアラームを出さなければ、ユーザが誰も検知領域２０３内に入ってこないかもしれない。
【００７３】
例えば、図２に示すように、ある日、ユーザ２０４は軌跡２０５に沿って移動しながら除草などの作業を行い、同様に、ユーザ２０６は軌跡２０７に沿って移動しながら作業を行う。しかし、この日の作業は、軌跡２０５と２０７が通る範囲でのみ行われ、非作業領域２０８では何の作業も行われない。すると、非作業領域２０８の一部でしかない検知領域２０３には、ユーザ２０４が作業中に入ってくることもないし、ユーザ２０６が作業中に入ってくることもない。
【００７４】
よって、もしユーザ２０４と２０６がそれぞれ携帯する端末（図２には不図示）のいずれもアラームを出さなければ、図２の作業が行われる日には、センサユニット２０２から端末を介して図１のコンピュータ１０１へとデータが収集されることはない。
【００７５】
ここで、もし、図２の作業が行われる日におけるデータ収集の緊急度が低ければ、コンピュータ１０１へのデータ収集がこの日に行われなくても問題ない。また、データ収集の緊急度が低ければ、センサユニット２０２から遠く離れて作業しているユーザ２０４や２０６に作業を中断させて、データ収集への関与のための行動をとらせ、作業効率を落とすよりも、データ収集を後日に延期する方が好ましい。
【００７６】
他方、もし、図２の作業が行われる日におけるデータ収集の緊急度が高ければ、ユーザ２０４または２０６にセンサユニット２０２へと接近する手間を生じさせてでも、コンピュータ１０１がセンサユニット２０２からデータを収集することが好ましい。
【００７７】
そして、図１を参照して説明したコンピュータ１０１の制御によれば、データ収集の緊急度に応じたアラーム距離に基づいて、適切にアラームが発行される。よって、ユーザ２０４と２０６のどちらも作業自体のためには非作業領域２０８に入ることがないとしても、データ収集の緊急度が高ければ、例えばユーザ２０６が携帯する端末がアラームを発するので、ユーザ２０６の端末を介したデータ収集が可能となる。
【００７８】
続いて、図１のデータ収集システム１００について、図３〜１２を参照してより詳細に説明する。なお、図３はブロック構成図、図４はハードウェア構成図、図５〜８はＤＢの例を示す図、図９は動作シーケンス図、図１０〜１２はフローチャートである。
【００７９】
さて、図３は、第１実施形態のセンサデータ収集システムのブロック構成図である。図３のデータ収集システム３００は、図１のデータ収集システム１００のより具体的な例である。データ収集システム３００は、サーバ３１０と、１台以上のセンサユニットと、１台以上の端末を含む。
【００８０】
サーバ３１０は、図１のコンピュータ１０１の具体例であり、コンピュータ１０１と同様に動作する。例えば、汎用的な情報処理装置が、サーバ３１０として利用可能である。
また、図３には、３台のセンサユニット３５０ａ〜３５０ｃが例示されているが、センサユニットの数は任意である。紙面の都合上、図３ではセンサユニット３５０ａのみ内部の詳細が図示されているが、センサユニット３５０ｂと３５０ｃも、センサユニット３５０ａと同様に構成される。
【００８１】
以下では、センサユニット３５０ａ〜３５０ｃを区別する必要がない場合は、後述の図４に示すように「３５０」という参照符号を用いることもある。センサユニット３５０は、図１のデータ記憶装置１０２の具体例である。なお、図２のセンサユニット２０２も、センサユニット３５０と同様に構成されているものとする。
【００８２】
さらに、図３には、３台の端末３７０ａ〜３７０ｃが例示されているが、端末の数は任意である。紙面の都合上、図３では端末３７０ａのみ内部の詳細が図示されているが、端末３７０ｂと３７０ｃも、端末３７０ａと同様に構成される。
【００８３】
以下では、端末３７０ａ〜３７０ｃを区別する必要がない場合は、後述の図４に示すように「３７０」という参照符号を用いることもある。端末３７０は、図１の端末１０３の具体例でもあり、図１の端末１０４の具体例でもある。また、図２では端末の図示が省略されているが、図２のユーザ２０４と２０６も、それぞれ端末３７０と同様の端末を携帯しているものとする。
【００８４】
さて、サーバ３１０は、端末に関連して、ＧＰＳログＤＢ３１１、端末管理ＤＢ３１２、およびＧＰＳログ処理部３１３を有する。また、サーバ３１０は、センサユニットからの端末を介したデータ収集に関連して、収集日ＤＢ３１４とセンサログＤＢ３１５とセンサログ処理部３１６を有し、センサユニットの管理のためのセンサ位置ＤＢ３１７とセンサ種別ＤＢ３１８を有する。
【００８５】
そして、データ収集の緊急度とユーザの負荷のバランスをとるために、サーバ３１０は、センサユニット別アラーム条件ＤＢ３１９、アラーム条件ＤＢ３２０、サンプリング周期ＤＢ３２１、およびデータ量条件ＤＢ３２２を有する。また、データ収集の緊急度とユーザの負荷のバランスをとるために、サーバ３１０は、さらに、アラーム距離決定部３２３、端末・センサ間距離計算部３２４、距離比較部３２５、およびアラーム決定部３２６を有する。
【００８６】
また、サーバ３１０は、端末との通信のために通信部３２７も有する。以上のサーバ３１０内の各部についてより詳しく述べれば、以下のとおりである。
ＧＰＳログＤＢ３１１は、端末３７０の位置を示すＧＰＳログを、端末３７０の識別子と対応づけて記憶するＤＢである。ＧＰＳログＤＢ３１１の具体的なデータ例は図８とともに後述する。
【００８７】
端末管理ＤＢ３１２は、各端末３７０に関する情報（例えば、端末３７０のユーザの属性など）を記憶するＤＢである。端末管理ＤＢ３１２の具体的なデータ例は図５とともに後述する。
【００８８】
ところで、ＧＰＳログは、各端末３７０からサーバ３１０へと送信され、サーバ３１０の通信部３２７で受信され、通信部３２７からＧＰＳログ処理部３１３に出力される。すると、ＧＰＳログ処理部３１３は、通信部３２７から受け取ったＧＰＳログを、送信元の端末３７０の識別子と対応づけて、ＧＰＳログＤＢ３１１に格納する。つまり、ＧＰＳログ処理部３１３と通信部３２７は、協働して、端末３７０の存在する位置を認識する位置認識手段として動作する。
【００８９】
収集日ＤＢ３１４は、各センサユニット３５０について、当該センサユニット３５０からデータを最後に収集した日付を記憶するＤＢである。収集日ＤＢ３１４の具体的なデータ例は図７とともに後述する。
【００９０】
センサログＤＢ３１５は、いずれかの端末３７０を介してセンサユニット３５０から収集されたデータを、端末３７０の識別子と対応づけて記憶するＤＢである。以下ではセンサユニット３５０から端末３７０を介してサーバ３１０が収集する対象のデータを「センサログ」ともいう。
【００９１】
なお、端末３７０がサーバ３１０に送信するセンサログは、端末３７０がどのセンサユニット３５０から元のセンサログを取得したかを示すための、センサユニット３５０の識別子を含むように、端末３７０によって加工されたデータである。したがって、センサログＤＢ３１５の各エントリは、端末３７０の識別子だけでなく、センサユニット３５０の識別子も含む。センサログＤＢ３１５のより具体的なデータ例は、図７とともに後述する。
【００９２】
ところで、いずれかの端末３７０からサーバ３１０へ送信されたセンサログは、サーバ３１０の通信部３２７で受信され、通信部３２７からセンサログ処理部３１６に出力される。すると、センサログ処理部３１６は、通信部３２７から受け取ったセンサログを、送信元の端末３７０の識別子と対応づけて、センサログＤＢ３１５に格納する。
【００９３】
センサ位置ＤＢ３１７は、各センサユニット３５０が設置された位置を記憶するＤＢである。つまり、センサ位置ＤＢ３１７は、センサユニット３５０が設置されている位置を示す位置情報を記憶する記憶手段の具体例である。センサ位置ＤＢ３１７の具体的なデータ例は図５とともに後述する。
【００９４】
センサ種別ＤＢ３１８は、各センサユニット３５０に搭載されているセンサの種別を記憶するＤＢである。センサ種別ＤＢ３１８の具体的なデータ例は図５とともに後述する。
センサユニット別アラーム条件ＤＢ３１９は、各センサユニット３５０についてのアラーム距離の取得の仕方を規定するためのＤＢである。換言すれば、センサユニット別アラーム条件ＤＢ３１９は、経過時間に応じたアラーム距離を定義する条件（以下では「アラーム条件」という）と、センサユニット３５０とを対応づけるためのＤＢである。
【００９５】
図１に関して説明したとおり、アラーム距離は、センサユニット３５０からデータ（つまりセンサログ）を前回収集してからの経過時間に依存して決まる閾値である。そして、詳しくは図６のデータ例とともに後述するが、経過時間とアラーム距離との間の関係は、センサユニット３５０ごとに異なっていてもよい。つまり、経過時間の長さが同じでも、異なるセンサユニット３５０に対して異なるアラーム距離が定義されてもよい。センサユニット別アラーム条件ＤＢ３１９は、以上のようなセンサユニット３５０に応じたアラーム距離の違いを管理するためのＤＢである。
【００９６】
アラーム条件ＤＢ３２０は、経過時間とアラーム距離との間の関係を規定するＤＢである。アラーム条件ＤＢ３２０の各エントリは、経過時間からアラーム距離を得るための１つの方法を規定する１つのアラーム条件を表す。なお、アラーム条件ＤＢ３２０の具体的なデータ例は図６とともに後述する。
【００９７】
サンプリング周期ＤＢ３２１は、各センサユニット３５０内の各センサのサンプリング周期を記憶するＤＢである。つまり、サンプリング周期ＤＢ３２１には、各センサが計測を行って計測結果のデータを生成する周期が記憶されている。サンプリング周期ＤＢ３２１の具体的なデータ例は図６とともに後述する。後述のとおり、サンプリング周期ＤＢ３２１は、サーバ３１０がセンサユニット別アラーム条件ＤＢ３１９に適切な値を予め設定しておくために利用される。
【００９８】
データ量条件ＤＢ３２２は、１日あたりにセンサユニット３５０が生成するデータの量の範囲ごとに、推奨されるアラーム条件を規定するＤＢである。後述のとおり、データ量条件ＤＢ３２２も、サーバ３１０がセンサユニット別アラーム条件ＤＢ３１９に適切な値を予め設定しておくために利用される。
【００９９】
アラーム距離決定部３２３は、各センサユニット３５０について、当該センサユニット３５０に関するアラーム距離を決定する。具体的には、アラーム距離決定部３２３は、収集日ＤＢ３１４とセンサユニット別アラーム条件ＤＢ３１９とアラーム条件ＤＢ３２０を参照して、アラーム距離を決定する。つまり、アラーム距離決定部３２３は、アラーム距離を取得する取得手段の具体例である。
【０１００】
端末・センサ間距離計算部３２４は、ＧＰＳログＤＢ３１１とセンサ位置ＤＢ３１７を参照して、注目している端末３７０と注目しているセンサユニット３５０の間の距離を計算する。
【０１０１】
距離比較部３２５は、端末・センサ間距離計算部３２４が計算した距離を、アラーム距離決定部３２３が決定したアラーム距離と比較する。
アラーム決定部３２６は、距離比較部３２５による比較結果に応じて、端末３７０にアラーム指示を出すか否かを決定するとともに、アラーム指示の対象のセンサユニット３５０を決定する。
【０１０２】
例えば、「センサユニット３５０ａと端末３７０ａの間の距離は、センサユニット３５０ａに関するアラーム距離以下である」という比較結果を距離比較部３２５が得たとする。この場合、アラーム決定部３２６は、センサユニット３５０ａについてのアラーム指示を端末３７０ａに出すことを決定する。
【０１０３】
また、アラーム決定部３２６は、決定にしたがって、通信部３２７にアラーム指示を送信させる。つまり、距離比較部３２５とアラーム決定部３２６と通信部３２７は、協働して、計算手段としての端末・センサ間距離計算部３２４が計算した距離がアラーム距離以下の端末３７０にアラーム指示を与える指示手段として機能している。
【０１０４】
通信部３２７は、端末３７０との間の通信を行う。例えば、通信部３２７は、ネットワークを介して端末３７０からＧＰＳログやセンサログを受信する。また、通信部３２７は、アラーム決定部３２６の決定にしたがい、ネットワークを介して端末３７０にアラーム指示を送信する。
【０１０５】
さて、センサユニット３５０ａ〜３５０ｃは、図２のセンサユニット２０２と同様に、圃場２０１の内部などの予め決められた場所に設置される。センサユニット３５０ａ〜３５０ｃの各々は、各種センサ３５１、センサログＤＢ３５２、センサログ処理部３５３、および通信部３５４を有する。
【０１０６】
各種センサ３５１は、サーバ３１０が収集する対象のデータを生成する１つ以上のセンサと、図２に関して説明した人感センサを含む。例えば、各種センサ３５１は、温度センサ、湿度センサ、または画像センサを含んでもよいし、他の種類のセンサを含んでもよい。
【０１０７】
センサログＤＢ３５２は、各種センサ３５１が生成したデータを記憶するＤＢである。センサログＤＢ３５２の具体的なデータ例は図７とともに後述する。
センサログ処理部３５３は、各種センサ３５１が生成したデータをセンサログＤＢ３５２に格納する。また、センサログ処理部３５３は、端末３７０ａ〜３７０ｃのいずれかが人感センサの検知領域に入ってきたときに、通信部３５４をオンにして、センサログＤＢ３５２内のデータを、通信部３５４を介して当該端末に送信する。センサログ処理部３５３は、送信済みのデータをセンサログＤＢ３５２から消去してもよい。
【０１０８】
通信部３５４は端末３７０との間の通信を行う。図１に関して説明したように、第１実施形態では、図１のデータ記憶装置１０２と端末１０３が近距離無線通信により通信を行うものと仮定している。つまり、通信部３５４は、端末３７０との間で、例えばＢｌｕｅｔｏｏｔｈ（登録商標）などの近距離無線通信による通信を行う。なお、通信部３５４は、図２のセンサユニット２０２に関して説明したとおり、消費電力抑制のために、普段はオフにされており、必要に応じてセンサログ処理部３５３によりオンにされる。
【０１０９】
さて、端末３７０ａ〜３７０ｃの各々は、例えば、携帯電話、スマートフォン、タブレット端末、モバイルＰＣ（Personal Computer）などの端末である。端末３７０ａ〜３７０ｃの各々は、ＧＰＳ情報取得部３７１、ＧＰＳログＤＢ３７２、サーバ通信部３７３、アラーム処理部３７４、センサ通信部３７５、センサログＤＢ３７６、およびセンサログ処理部３７７を有する。
【０１１０】
ＧＰＳ情報取得部３７１は、ＧＰＳ衛星からの測位信号を受信することで、端末３７０の位置を示すＧＰＳ情報を取得する。そして、ＧＰＳ情報取得部３７１は、取得したＧＰＳ情報をＧＰＳログＤＢ３７２に格納する。なお、ＧＰＳログＤＢ３７２の具体的なデータ例は図８とともに後述する。
【０１１１】
サーバ通信部３７３は、ネットワークを介して、サーバ３１０（より具体的には通信部３２７）との間の通信を行う。例えば、端末３７０のサーバ通信部３７３とサーバ３１０の通信部３２７との間の通信は、３Ｇ通信網とインターネットを介して行われてもよい。
【０１１２】
アラーム処理部３７４は、サーバ３１０からサーバ通信部３７３を介してアラーム指示を受け取り、アラーム指示にしたがってユーザにアラームを出す。なお、アラームは、ブザーその他の音声的なものでもよいし、振動などの触覚的なものでもよいし、ディスプレイへのメッセージ表示などの視覚的なものでもよいし、それらの組み合わせでもよい。
【０１１３】
センサ通信部３７５は、センサユニット３５０（より具体的には通信部３５４）との間の通信を行う。図１に関して説明したように、第１実施形態では、図１のデータ記憶装置１０２と端末１０３が近距離無線通信により通信を行うものと仮定している。つまり、センサ通信部３７５は、センサユニット３５０の通信部３５４との間で、例えばＢｌｕｅｔｏｏｔｈ（登録商標）などの近距離無線通信による通信を行う。
【０１１４】
センサログＤＢ３７６は、センサユニット３５０から受信したデータを一時的に記憶するＤＢである。なお、センサログＤＢ３７６の具体的なデータ例は図７とともに後述する。
【０１１５】
センサログ処理部３７７は、センサログＤＢ３５２に記憶されているデータを、センサ通信部３７５を介してセンサユニット３５０から受信し、受信したデータをセンサログＤＢ３７６に格納する。また、センサログ処理部３７７は、センサユニット３５０からデータを受信し終わると、センサログＤＢ３７６に格納したデータを、今度はサーバ通信部３７３を介してサーバ３１０に送信する。
【０１１６】
続いて、図３の各ブロックを実現するハードウェア構成について、図４を参照して説明する。
サーバ３１０は、ＣＰＵ（Central Processing Unit）４０１、ＲＡＭ（Random Access Memory）４０２、およびＨＤＤ（Hard Disk Drive）４０３を有する。また、サーバ３１０は、ネットワークＩＦ（interface）４０４、機器ＩＦ４０５、ディスプレイＩＦ４０６、および駆動装置４０７を有する。そして、サーバ３１０内の上記各部は互いにバスで接続されている。
【０１１７】
ＣＰＵ４０１は、プログラムをＲＡＭ４０２にロードし、ＲＡＭ４０２をワーキングエリアとしても使いながら、プログラムを実行する。また、ＨＤＤ４０３は、プログラムや各種ＤＢを保持する。
【０１１８】
ネットワークＩＦ４０４は、例えば、有線ＬＡＮまたは無線ＬＡＮのインタフェイスである。ネットワークＩＦ４０４を介してサーバ３１０はネットワーク４１１に接続される。ネットワーク４１１は、例えば、ＬＡＮ、インターネット、３Ｇ通信網の組み合わせであり、ネットワーク４１１を介してサーバ３１０と端末３７０は接続される。
【０１１９】
機器ＩＦ４０５は、入力機器をサーバ３１０に接続するインタフェイスである。入力機器の例として、図４には、キーボード４１２とマウス４１３が例示されているが、その他のポインティングデバイスが機器ＩＦ４０５に接続されてもよい。
【０１２０】
また、ディスプレイＩＦ４０６は、ディスプレイ４１４をサーバ３１０に接続するインタフェイスである。ディスプレイ４１４は視覚的な出力機器の例である。サーバ３１０には、さらに、スピーカなどの音声的な出力機器が、適宜のインタフェイスを介して接続されていてもよい。
【０１２１】
駆動装置４０７は、コンピュータ読み取り可能な記憶媒体４１５の駆動装置である。記憶媒体４１５の例は、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）などの光ディスク、光磁気ディスク、磁気ディスク、半導体メモリを用いたメモリカードなどである。
【０１２２】
ＣＰＵ４０１が実行するプログラムは、例えば、予めＨＤＤ４０３にインストールされていてもよいし、ネットワーク４１１とネットワークＩＦ４０４を介してＨＤＤ４０３にダウンロードされてもよい。あるいは、プログラムは、記憶媒体４１５に記憶されて提供され、駆動装置４０７を介して読み取られ、ＨＤＤ４０３にインストールされてもよい。
【０１２３】
なお、記憶媒体４１５、ＲＡＭ４０２、およびＨＤＤ４０３は、いずれも、コンピュータ読み取り可能で有形の（tangible）媒体の例である。記憶媒体４１５、ＲＡＭ４０２、およびＨＤＤ４０３は、信号搬送波のような一時的な（transitory）媒体ではない。
【０１２４】
また、サーバ３１０に関して、図３と図４の関係を説明すると以下のとおりである。
図３のサーバ３１０が保持するＤＢのうち、静的なＤＢは、予めＨＤＤ４０３に記憶され、必要に応じてＲＡＭ４０２にデータが読み込まれる。具体的には、端末管理ＤＢ３１２、センサ位置ＤＢ３１７、センサ種別ＤＢ３１８、センサユニット別アラーム条件ＤＢ３１９、アラーム条件ＤＢ３２０、サンプリング周期ＤＢ３２１、およびデータ量条件ＤＢ３２２は、予めＨＤＤ４０３に記憶される。また、動的にエントリが増えるＧＰＳログＤＢ３１１とセンサログＤＢ３１５も、ＨＤＤ４０３に記憶されていてもよい。なお、データ収集のたびに書き換えられる収集日ＤＢ３１４は、ＨＤＤ４０３に記憶されていてもよいし、ＲＡＭ４０２に記憶されていてもよい。
【０１２５】
そして、ＧＰＳログ処理部３１３、センサログ処理部３１６、アラーム距離決定部３２３、端末・センサ間距離計算部３２４、距離比較部３２５、およびアラーム決定部３２６は、ＣＰＵ４０１がプログラムを実行することにより実現される。また、通信部３２７は、ネットワークＩＦ４０４により実現される。
【０１２６】
ここで図４の説明に戻る。センサユニット３５０は、バッテリ４２１によって駆動され、ＭＰＵ（Microprocessor Unit）４２２、ＲＡＭ４２３、およびフラッシュＲＯＭ（Read Only Memory）４２４を有する。なお、図４では紙面の都合上、バッテリ４２１とＭＰＵ４２２のみが線で結ばれているが、センサユニット３５０内の各部へは、いずれもバッテリ４２１から電力が供給される。
【０１２７】
ＭＰＵ４２２は、プログラムをＲＡＭ４２３にロードし、ＲＡＭ４２３をワーキングエリアとしても使いながら、プログラムを実行する。また、フラッシュＲＯＭ４２４は、プログラムや各種ＤＢを保持する。フラッシュＲＯＭ４２４の代わりに（あるいはフラッシュＲＯＭ４２４と組み合わせて）、ＨＤＤなどの他の種類の不揮発性記憶装置が使われてもよい。
【０１２８】
また、センサユニット３５０は、必要に応じて、適宜の種類の適宜の個数のセンサを有し、各センサはセンサＩＦを介してＭＰＵ４２２に接続される。図４の例では、具体的には、センサユニット３５０は、温度センサ４２５、湿度センサ４２６、温度センサ４２７、および人感センサ４２８を有する。
【０１２９】
センサユニット３５０は、さらに、センサＩＦ４２９〜４３３を有する。なお、紙面の都合上、図４には５個のセンサＩＦ４２９〜４３３のみが図示されているが、センサユニット３５０は６個以上のセンサＩＦを有していてもよいし、４個以下のセンサＩＦを有していてもよい。
【０１３０】
そして、温度センサ４２５はセンサＩＦ４２９を介して、湿度センサ４２６はセンサＩＦ４３０を介して、温度センサ４２７はセンサＩＦ４３１を介して、人感センサ４２８はセンサＩＦ４３２を介して、それぞれＭＰＵ４２２に接続されている。他方、センサＩＦ４３３は余っており、センサＩＦ４３３には何のセンサも接続されていない。
【０１３１】
センサユニット３５０はさらに、端末３７０との間で近距離無線通信を行う近距離無線通信機４３４を有する。電力消費を抑えるため、ＭＰＵ４２２は、バッテリ４２１から近距離無線通信機４３４への電力供給を制御することが望ましい。
【０１３２】
また、センサユニット３５０に関して、図３と図４の関係を説明すると以下のとおりである。
図３の各種センサ３５１は、具体的には、例えば、図４の温度センサ４２５、湿度センサ４２６、温度センサ４２７、および人感センサ４２８を含んでもよい。また、センサログＤＢ３５２は、フラッシュＲＯＭ４２４に記憶される。そして、センサログ処理部３５３は、ＭＰＵ４２２がプログラムを実行することにより実現される。また、通信部３５４は、近距離無線通信機４３４により実現される。
【０１３３】
ここで図４の説明に戻る。端末３７０は、バッテリ４４１によって駆動され、ＭＰＵ４４２、ＲＡＭ４４３、およびフラッシュＲＯＭ４４４を有する。なお、図４では紙面の都合上、バッテリ４４１とＭＰＵ４４２のみが線で結ばれているが、端末３７０内の各部へは、いずれもバッテリ４４１から電力が供給される。
【０１３４】
ＭＰＵ４４２は、プログラムをＲＡＭ４４３にロードし、ＲＡＭ４４３をワーキングエリアとしても使いながら、プログラムを実行する。また、フラッシュＲＯＭ４４４は、プログラムや各種ＤＢを保持する。フラッシュＲＯＭ４４４の代わりに（あるいはフラッシュＲＯＭ４４４と組み合わせて）、ＨＤＤなどの他の種類の不揮発性記憶装置が使われてもよい。
【０１３５】
また、端末３７０は、センサユニット３５０との間で近距離無線通信を行う近距離無線通信機４４５を有し、ＧＰＳ衛星から測位信号を受信してＧＰＳ情報を取得するＧＰＳ受信機４４６も有する。端末３７０はさらに、３Ｇ通信網（つまりネットワーク４１１の一部）を介した通信を行う３Ｇ通信機４４７を有する。
【０１３６】
また、端末３７０は、ユーザインタフェイス用の１つ以上の装置を有する。具体的には、図４の例では、端末３７０は、ユーザインタフェイス用にＬＥＤ（Light Emitting Diode）４４８、ブザー４４９、振動モータ４５０、およびディスプレイ４５１を有する。
【０１３７】
もちろん、端末３７０は、例えばボタンやキーボードなどの入力機器をさらに有していてもよいし、スピーカとマイクをさらに有していてもよい。また、ディスプレイ４５１がポインティングデバイスを兼ねていてもよい（つまり、ディスプレイ４５１がタッチスクリーンであってもよい）。
【０１３８】
また、端末３７０に関して、図３と図４の関係を説明すると以下のとおりである。
ＧＰＳ情報取得部３７１はＧＰＳ受信機４４６により実現され、ＧＰＳログＤＢ３７２はフラッシュＲＯＭ４４４に記憶される。また、サーバ通信部３７３は３Ｇ通信機４４７により実現される。なお、実施形態によっては、３Ｇ通信機４４７が、複数の基地局からの受信電波強度と、それら複数の基地局の既知の位置に基づいて、端末３７０の位置を計算することで、ＧＰＳ情報取得部３７１と類似の機能を実現してもよい。
【０１３９】
アラーム処理部３７４は、プログラムを実行するＭＰＵ４４２と、ＭＰＵ４４２の制御にしたがってアラームを発するモジュール（つまり、ＬＥＤ４４８、ブザー４４９、振動モータ４５０、およびディスプレイ４５１のうちの少なくとも１つ）により、実現される。そして、センサ通信部３７５は近距離無線通信機４４５により実現され、センサログＤＢ３７６はフラッシュＲＯＭ４４４に記憶される。また、センサログ処理部３７７は、ＭＰＵ４４２がプログラムを実行することにより実現される。
【０１４０】
ところで、図１のデータ収集システム１００が図２の圃場２０１に適用される場合に、具体的には図３〜４のような構成が好適である理由について説明すれば、以下のとおりである。
【０１４１】
図１のデータ記憶装置１０２を図２の圃場２０１のような広い屋外に設置する場合、金銭的なコストの観点から、コンピュータ１０１と通信する機能をデータ記憶装置１０２に実装することが難しいことが多い。その理由は次のとおりである。
【０１４２】
屋外に設置される装置がコンピュータ１０１と通信するには、例えば、３Ｇ通信網による通信機能または無線ＬＡＮによる通信機能を利用することが考えられる。しかし、３Ｇ通信網による通信機能を利用するには、電話会社等の通信プロバイダとの契約料金がかかり、通信料金もかかる。
【０１４３】
また、無線ＬＡＮによる通信機能を利用するには、中継用のアクセスポイントを設置する必要がある。しかし、例えば非常に広い範囲に散在する複数の圃場に複数のセンサユニットを設置しようとする場合、多数のアクセスポイントが必要になるかもしれず、中継用のインフラストラクチャの整備および保守にかかる金銭的・人的なコストは、実用上は無視し難い。
【０１４４】
よって、実用上、コンピュータ１０１と通信する機能をデータ記憶装置１０２に実装することが難しい場合がある。
他方、近年では農業に従事する作業者の多くが、携帯電話やスマートフォンなどの３Ｇ通信機能を備えた端末を作業中にも携帯しており、何らかの端末のユーザでもある。よって、コンピュータ１０１（つまりサーバ３１０）との間の通信は、ユーザが携帯する端末の機能を使うことで、新たな金銭的コストをそれほどかけずに実現可能である。
【０１４５】
また、近年の携帯電話やスマートフォンなどの端末は、ＧＰＳ機能を有するものが多い。よって、ユーザの持つ既存の端末にプログラムをインストールすることで、図３の端末３７０の機能を実現することができる。すなわち、端末３７０の導入に関するコストは低い。
【０１４６】
さらに、近年の携帯電話やスマートフォンなどの端末の多くは、近距離無線通信機能も有する。よって、既存の近距離無線通信機能を、端末とデータ記憶装置１０２（つまりセンサユニット３５０）の間の通信のために利用することができる。
【０１４７】
そして、近距離無線通信であれば、当然アクセスポイントなどのインフラストラクチャは不要である。よって、センサユニット３５０に近距離無線通信機能を持たせても、データ収集システム３００全体としてはさほど導入コストはかからない。
【０１４８】
また、有線通信と比べた近距離無線通信の利点の一つは、ユーザに「ケーブルを接続する」などの意識的な操作をさせなくても、装置同士（例えば端末３７０とセンサユニット３５０）が自動的に通信を開始することが可能なことである。つまり、図４に示すように近距離無線通信を端末３７０とセンサユニット３５０の間の通信に利用することで、ユーザがデータ収集に関与するための負荷を軽減することができる。
【０１４９】
したがって、図３〜４のシステム構成は、データ収集システム３００の導入と保守にかかる金銭的・人的なコストの観点からも、ユーザの負荷軽減という観点からも、圃場２０１のような広い屋外での利用に好適である。
【０１５０】
続いて、図５〜８を参照して、データ収集システム３００内の各種ＤＢの例について説明する。
図５〜６は、サーバ３１０が保持する静的なＤＢの例を示す図である。
【０１５１】
図５に示すように、端末管理ＤＢ３１２の各エントリは、データ収集システム３００内の各端末３７０に対応し、「端末ＩＤ」と「ユーザ氏名」というフィールドを有する。端末ＩＤは、データ収集システム３００内で端末３７０を一意に識別する識別子（ＩＤ（identifier））を示し、作業者名は、端末ＩＤで識別される当該端末３７０を携帯するユーザの氏名を示す。
【０１５２】
図５の例によれば、端末ＩＤが「０００１」の端末３７０のユーザは「山田太郎」という氏名であり、端末ＩＤが「０００２」の端末３７０のユーザは「佐藤二郎」という氏名である。端末管理ＤＢ３１２の各エントリは、端末３７０とユーザを管理するための他のフィールド（例えば、端末３７０で利用可能な電子メールアドレスや、ユーザの属性などのフィールド）をさらに含んでもよい。端末管理ＤＢ３１２は、例えば、端末３７０がディスプレイ４５１に表示するアラームの内容を指定するために、サーバ３１０のアラーム決定部３２６により参照されてもよい。
【０１５３】
なお、端末管理ＤＢ３１２は静的なＤＢだが、端末３７０が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存の端末３７０の設定の変更または端末３７０のユーザの属性の変更などがあれば、それに応じて既存のエントリが変更される。
【０１５４】
また、図５に示すように、センサ位置ＤＢ３１７の各エントリは、データ収集システム３００内の各センサユニット３５０に対応し、「センサユニットＩＤ」と「緯度」と「経度」というフィールドを有する。センサユニットＩＤは、データ収集システム３００内でセンサユニット３５０を一意に識別する識別子を示す。また、緯度と経度は、センサユニットＩＤで識別される当該センサユニット３５０が設置された場所を示す。
【０１５５】
図５の例によれば、センサユニットＩＤが「０００１」のセンサユニット３５０は、北緯３５．４４３５４度・東経１３９．３１４１度の場所に設置されている。また、センサユニットＩＤが「０００２」のセンサユニット３５０は、北緯３５．４３９８９度・東経１３９．３０９５度の場所に設置されている。図５には、他にもセンサユニットＩＤが「０００３」と「００１０」のセンサユニット３５０についてのエントリが例示されている。
【０１５６】
なお、センサ位置ＤＢ３１７は静的なＤＢだが、センサユニット３５０が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存のセンサユニット３５０が移動されれば、それに応じて既存のエントリが変更される。
【０１５７】
また、図５に示すように、センサ種別ＤＢ３１８の各エントリは、データ収集システム３００内の各センサユニット３５０に対応し、「センサユニットＩＤ」と「センサＮｏ．１」〜「センサＮｏ．１０」というフィールドを有する。なお、図５では紙幅の都合上「センサＮｏ．４」〜「センサＮｏ．９」のフィールドの図示は省略されている。
【０１５８】
図５のセンサ種別ＤＢ３１８の例は、センサユニット３５０が、人感センサを除いて最大で１０個のセンサを持ち得る場合の例である。そのため、図５では、各エントリが１０個のセンサにそれぞれ対応するフィールドを含む。
【０１５９】
センサユニットＩＤは、センサ位置ＤＢ３１７と同様に、センサユニット３５０の識別子を示す。また、センサＮｏ．ａ（１≦ａ≦１０）は、センサユニットＩＤで識別される当該センサユニット３５０のａ番目のセンサ（つまり、サーバ３１０による収集対象のデータを生成するセンサのうちａ番目のもの）の種類を示す。
【０１６０】
図５の例によれば、センサユニットＩＤが「０００１」のセンサユニット３５０は、１番目のセンサとして気温センサを有し、２番目のセンサとして湿度センサを有し、３番目のセンサとして土中温度センサを有する。また、センサユニットＩＤが「０００１」のセンサユニット３５０の「センサＮｏ．１０」フィールドに「−」と示されているのは、当該センサユニット３５０が１０番目のセンサを持たないことを示す。同様に、図５の例によれば、センサユニットＩＤが「０００２」のセンサユニット３５０は、１番目のセンサとして湿度センサを有し、２番目のセンサとして土中温度センサを有し、３番目のセンサとして土中水分センサを有するが、１０番目のセンサは持たない。
【０１６１】
なお、センサ種別ＤＢ３１８は静的なＤＢだが、センサユニット３５０自体が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存のセンサユニット３５０に対してセンサの追加・削除・交換などが行われれば、それに応じて既存のエントリが変更される。
【０１６２】
また、図６に示すように、センサユニット別アラーム条件ＤＢ３１９の各エントリは、データ収集システム３００内の各センサユニット３５０に対応し、「センサユニットＩＤ」と「アラーム条件ＩＤ」というフィールドを有する。センサユニットＩＤは、センサ位置ＤＢ３１７と同様にセンサユニット３５０の識別子を示す。また、アラーム条件ＩＤは、センサユニットＩＤで識別される当該センサユニット３５０についてのアラーム距離を求めるのに用いる「アラーム条件」の識別子である。なお、以下の説明において、「アラーム条件」とは、経過時間に応じたアラーム距離を定義する条件のことである。
【０１６３】
第１実施形態では、複数のアラーム条件が利用可能である。そして、第１実施形態では、センサユニット３５０ごとに、「サーバ３１０のアラーム距離決定部３２３は、どのアラーム条件にしたがって当該センサユニット３５０についてのアラーム距離を取得するか」ということが設定可能である。例えば、センサユニット３５０に搭載されているセンサの種類と数、各センサが単位時間あたりに生成するデータの量、センサユニット３５０のフラッシュＲＯＭ４２４の容量などに応じて、適切なアラーム条件は異なる。
【０１６４】
そのため、第１実施形態では、センサユニット別アラーム条件ＤＢ３１９により、センサユニット３５０ごとにアラーム条件が管理される。図６の例によれば、センサユニットＩＤが「０００１」のセンサユニット３５０用には、「０２」というアラーム条件ＩＤのアラーム条件が使われる。また、センサユニットＩＤが「０００２」のセンサユニット３５０用には、「０１」というアラーム条件ＩＤのアラーム条件が使われる。
【０１６５】
なお、センサユニット別アラーム条件ＤＢ３１９は静的なＤＢだが、センサユニット３５０自体が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存のセンサユニット３５０に対してセンサの追加・削除・交換・設定変更、あるいはフラッシュＲＯＭ４２４の増設などが行われれば、それに応じて既存のエントリが変更される。
【０１６６】
また、図６に示すように、アラーム条件ＤＢ３２０の各エントリは、各アラーム条件に対応し、「アラーム条件ＩＤ」と「条件数」というフィールドを有する。また、第１実施形態では、各アラーム条件が、１〜４個の条件の組み合わせにより表現されるので、アラーム条件ＤＢ３２０の各エントリは、「条件ｃ」と「条件ｃ距離」（１≦ｃ≦４）というフィールドも有する。
【０１６７】
もちろん、アラーム条件を表現するための条件の個数の上限は、実施形態に応じた適宜の数でよく、４でなくてもよい。そして、上限に応じて、アラーム条件ＤＢ３２０の形式も適宜変形されてよい。
【０１６８】
アラーム条件ＩＤは、センサユニット別アラーム条件ＤＢ３１９と同様にアラーム条件の識別子を示す。また、条件数は、アラーム条件ＩＤで識別される当該アラーム条件がいくつの条件の組み合わせで表されるかを示す。そして、条件数がＣのとき、１≦ｃ≦Ｃなる各ｃについて、「条件ｃ」と「条件ｃ距離」のペアは、経過時間とアラーム距離のペアで定義される条件を示す。
【０１６９】
例えば、図６の例によれば、アラーム条件ＩＤが「０１」のアラーム条件は、４つの条件の組み合わせで表される。そして、１つ目の条件は「１日」と「１ｍ」のペアで定義され、２つ目の条件は「３日」と「５０ｍ」のペアで定義され、３つ目の条件は「７日」と「２００ｍ」のペアで定義され、４つ目の条件は「１０日」と「５００ｍ」のペアで定義される。より具体的には、アラーム条件ＩＤが「０１」のアラーム条件は、以上の４つの条件の組み合わせにより、以下のことを示す（なお、説明の便宜上、前回のデータの収集からの経過時間（より具体的には、１日単位で数えた経過時間である経過日数）をｐとする）。
・ｐ＜１日ならば、アラーム距離は０ｍ
・１日≦ｐ＜３日ならば、アラーム距離は１ｍ
・３日≦ｐ＜７日ならば、アラーム距離は５０ｍ
・７日≦ｐ＜１０日ならば、アラーム距離は２００ｍ
・１０日≦ｐならば、アラーム距離は５００ｍ
【０１７０】
同様に、図６の例によれば、アラーム条件ＩＤが「０２」のアラーム条件は、３つの条件の組み合わせにより、以下のことを示す。
・ｐ＜１日ならば、アラーム距離は０ｍ
・１日≦ｐ＜３日ならば、アラーム距離は１ｍ
・３日≦ｐ＜７日ならば、アラーム距離は２００ｍ
・７日＜ｐならば、アラーム距離は６００ｍ
【０１７１】
以上の２つのアラーム条件を比較すると、アラーム条件ＩＤが「０１」のアラーム条件の方が、より細かい粒度でアラーム距離が規定されている。また、同じ経過時間に対しては、アラーム条件ＩＤが「０１」のアラーム条件によって決まるアラーム距離は、アラーム条件ＩＤが「０２」のアラーム条件によって決まるアラーム距離以下である。
【０１７２】
例えば、経過時間が同じ５日でも、アラーム条件ＩＤが「０１」と「０２」のアラーム条件がそれぞれ適用されるセンサユニット３５０に関するアラーム距離は、５０ｍと２００ｍであり、後者のアラーム距離の方が長い。すなわち、アラーム条件ＩＤが「０２」のアラーム条件は、同じ経過時間に対してデータ収集の緊急度がより高いセンサユニット３５０に好適である。例えば、１日当たりに生成するデータの量が多いセンサユニット３５０ほど、同じ経過時間に対してデータ収集の緊急度がより高い。
【０１７３】
なお、アラーム条件ＤＢ３２０は静的なＤＢだが、アラーム条件が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存のアラーム条件の定義が変更されれば、それに応じて既存のエントリが変更される。
【０１７４】
また、図６に示すように、サンプリング周期ＤＢ３２１の各エントリは、データ収集システム３００内の各センサユニット３５０に対応し、「センサユニットＩＤ」と「センサＮｏ．１」〜「センサＮｏ．１０」というフィールドを有する。なお、図６では紙幅の都合上「センサＮｏ．４」〜「センサＮｏ．９」のフィールドの図示は省略されている。
【０１７５】
図６のサンプリング周期ＤＢ３２１の例は、センサユニット３５０が、人感センサを除いて最大で１０個のセンサを持ち得る場合の例である。そのため、図６では、各エントリが１０個のセンサにそれぞれ対応するフィールドを含む。つまり、図５のセンサ種別ＤＢ３１８と図６のサンプリング周期ＤＢ３２１のフィールドの数は同じである。
【０１７６】
センサユニットＩＤは、センサ位置ＤＢ３１８と同様に、センサユニット３５０の識別子を示す。また、センサＮｏ．ａ（１≦ａ≦１０）は、センサユニットＩＤで識別される当該センサユニット３５０のａ番目のセンサが、データをサンプリングするサンプリング周期を示す（単位は秒）。サンプリング周期は、換言すれば、センサが気温などの計測対象を計測してデータを生成する周期である。
【０１７７】
図６の例によれば、センサユニットＩＤが「０００１」のセンサユニット３５０においては、１番目〜３番目のセンサがいずれも９００秒周期でデータを生成する。なお、１番目〜３番目のセンサの種別は、図５のセンサ種別ＤＢ３１８に示すとおり、気温センサ、湿度センサ、および土中温度センサである。
【０１７８】
また、図５に示すように、センサユニットＩＤが「０００１」のセンサユニット３５０は１０番目のセンサを持たない。よって、図６のサンプリング周期ＤＢ３２１でも、センサユニットＩＤが「０００１」のエントリの「センサＮｏ．１０」フィールドの値は無効な値（例えばＮＵＬＬ。図６では「−」と表記）に設定されている。
【０１７９】
また、図６の例によれば、センサユニットＩＤが「０００２」のセンサユニット３５０においては、１番目〜３番目のセンサがいずれも３６００秒周期でデータを生成する。なお、１番目〜３番目のセンサの種別は、図５のセンサ種別ＤＢ３１８に示すとおり、湿度センサ、土中湿度センサ、および土中水分センサである。
【０１８０】
サンプリング周期ＤＢ３２１は静的なＤＢだが、センサユニット３５０自体が追加または削除されれば、それに応じてエントリが追加または削除される。また、既存のセンサユニット３５０に対してセンサの追加・削除・交換・サンプリング周期の設定変更などが行われれば、それに応じて既存のエントリが変更される。
【０１８１】
また、図６に示すように、データ量条件ＤＢ３２２の各エントリは、各アラーム条件に対応し、「アラーム条件ＩＤ」と「データ量下限」と「データ量上限」というフィールドを有する。
【０１８２】
アラーム条件ＩＤは、アラーム条件ＤＢ３２０などと同様に、アラーム条件の識別子を示す。データ量下限とデータ量上限のペアは、センサユニット３５０が１日あたりに生成するデータの量の範囲を示す。各エントリは、「１日あたりに生成するデータの量が、データ量下限とデータ量上限のペアで表される範囲に該当するセンサユニット３５０にとっては、アラーム条件ＩＤで識別されるアラーム条件が好適である」ということを示す。
【０１８３】
例えば、図６の例によれば、アラーム条件ＩＤが「０１」のアラーム条件は、１日あたりに生成するデータの量が０以上２４０未満のセンサユニット３５０に好適である。そして、アラーム条件ＩＤが「０２」のアラーム条件は、１日あたりに生成するデータの量が２４０以上１４４０未満のセンサユニット３５０に好適である。
【０１８４】
なお、データ量条件ＤＢ３２２におけるデータ量下限とデータ量上限の単位は、実施形態に応じて任意である。第１実施形態では説明の簡略化のため、「１つのセンサによる１回の計測によって固定長の記憶領域が消費される」と仮定し、固定長の記憶領域を１単位として、データ量下限とデータ量上限を表している。実施形態によっては、各センサによる１回の計測で消費される記憶領域のバイト数をセンサ別に管理するＤＢをさらにサーバ３１０が有してもよく、データ量条件ＤＢ３２２における単位が１バイトであってもよい。
【０１８５】
サーバ３１０は、サンプリング周期ＤＢ３２１にエントリが追加されると、追加されたエントリのセンサユニットＩＤに関して、データ量条件ＤＢ３２２に基づいてアラーム条件ＩＤを決定する。そして、サーバ３１０は、センサユニット別アラーム条件ＤＢ３１９に新規エントリを追加し、新規エントリに、上記センサユニットＩＤと上記で決定したアラーム条件ＩＤを設定する。
【０１８６】
また、サーバ３１０は、サンプリング周期ＤＢ３２１のいずれかのエントリで１つ以上のサンプリング周期が変更されると、当該エントリのセンサユニットＩＤに関して、データ量条件ＤＢ３２２に基づいて、アラーム条件ＩＤを決定しなおす。そして、サーバ３１０は、再決定したアラーム条件ＩＤを、センサユニット別アラーム条件ＤＢ３１９において上記センサユニットＩＤに対応するエントリのアラーム条件ＩＤとして設定する。
【０１８７】
エントリの追加とサンプリング周期の変更のいずれの場合にせよ、サーバ３１０は、サンプリング周期ＤＢ３２１とデータ量条件ＤＢ３２２を参照して、具体的には以下の式（１）にしたがってアラーム条件ＩＤを決定する。
【０１８８】
【数１】
【０１８９】
ここで、ｄａｔａｉは、データ収集システム３００内でｉ番目のセンサユニット３５０が１日あたりに生成するデータ量である。データ量ｄａｔａｉの単位は、データ量条件ＤＢ３２２で使われている単位と同じである。
【０１９０】
また、Ａｉは、ｉ番目のセンサユニット３５０が有する人感センサ以外のセンサ（つまり、サーバ３１０が収集する対象のデータを生成するセンサ）の数である。そして、ｐｅｒｉｏｄｉ，ａは、ｉ番目のセンサユニット３５０のａ番目のセンサ（１≦ａ≦Ａｉ）のサンプリング周期である。サーバ３１０は、サンプリング周期ＤＢ３２１を参照することで、ｉ番目のセンサユニット３５０に関して、センサの数Ａｉと各センサのサンプリング周期ｐｅｒｉｏｄｉ，ａ（１≦ａ≦Ａｉ）を認識することができる。
【０１９１】
なお、式（１）におけるａｍｏｕｎｔｉ，ａは、ｉ番目のセンサユニット３５０のａ番目のセンサが１回の計測で生成するデータ量を示す。データ量ａｍｏｕｎｔｉ，ａの単位も、データ量条件ＤＢ３２２で使われている単位と同じである。また、データ量条件ＤＢ３２２に関して上記で説明した「１つのセンサによる１回の計測によって固定長の記憶領域が消費される」という仮定より、第１実施形態では、すべてのｉとａの組み合わせに対して、ａｍｏｕｎｔｉ，ａ＝１である。しかし、もちろん実施形態によっては、データ量ａｍｏｕｎｔｉ，ａは、ｉとａに応じて可変のこともある。
【０１９２】
そして、サンプリング周期ＤＢ３２１ではサンプリング周期ｐｅｒｉｏｄｉ，ａが秒単位で表されているので、ｉ番目のセンサユニット３５０が１日あたりに生成するデータ量ｄａｔａｉは、式（１）のとおりである。サーバ３１０は、サンプリング周期ＤＢ３２１を参照して式（１）にしたがってデータ量ｄａｔａｉを計算し、データ量ｄａｔａｉが該当する範囲をデータ量条件ＤＢ３２２から探す。そして、サーバ３１０は、データ量条件ＤＢ３２２で見つかったエントリのアラーム条件ＩＤを、ｉ番目のセンサユニット３５０用のアラーム条件ＩＤとして決定し、決定したアラーム条件ＩＤを、センサユニット別アラーム条件ＤＢ３１９に設定する。
【０１９３】
例えば、ｉ番目のセンサユニット３５０のセンサユニットＩＤが「０１」であり、計算されたデータ量ｄａｔａｉが３８４であったとする。すると、２４０≦３８４＜１４４０なので、データ量条件ＤＢ３２２より、センサユニットＩＤが「０１」のセンサユニット３５０に適切なアラーム条件は、「０２」というアラーム条件ＩＤのものである。よって、サーバ３１０は、センサユニット別アラーム条件ＤＢ３１９において、「０１」というセンサユニットＩＤと、以上のようにして決定した「０２」というアラーム条件ＩＤを対応づける。
【０１９４】
さて、図７は、センサに関連して動的に変化するＤＢの例を示す図である。
図７に示すように、サーバ３１０内の収集日ＤＢ３１４の各エントリは、データ収集システム３００内の各センサユニット３５０に対応し、「センサユニットＩＤ」と「収集日」というフィールドを有する。センサユニットＩＤはセンサ位置ＤＢ３１７などと同様にセンサユニット３５０の識別子を示す。収集日は、センサユニットＩＤで識別される当該センサユニット３５０からサーバ３１０がデータを前回収集した日付を示す。もちろん、実施形態によっては、収集日の代わりに収集日時が使われてもよい。
【０１９５】
図７の例によれば、センサユニットＩＤが「０００１」のセンサユニット３５０からサーバ３１０がデータを前回収集したのは２０１１年３月１日である。また、センサユニットＩＤが「０００２」のセンサユニット３５０からサーバ３１０がデータを前回収集したのは２０１１年３月３日である。
【０１９６】
そして、センサユニットＩＤが「０００３」のセンサユニット３５０からサーバ３１０がデータを前回収集したのは２０１１年３月２日である。また、センサユニットＩＤが「００１０」のセンサユニット３５０からサーバ３１０がデータを前回収集したのは２０１１年２月２０日である。
【０１９７】
収集日ＤＢ３１４は動的に変化するＤＢである。具体的には、サーバ３１０がいずれかの端末３７０を介していずれかのセンサユニット３５０からデータを収集するたびに、当該センサユニット３５０に対応するエントリの収集日が更新される。また、もちろん、センサユニット３５０がデータ収集システム３００に追加または削除されれば、それに応じて収集日ＤＢ３１４にもエントリが追加または削除される。
【０１９８】
また、図７に示すように、センサユニット３５０内のセンサログＤＢ３５２には、当該センサユニット３５０の各種センサ３５１がデータを生成するたびにエントリが追加される。センサログＤＢ３５２の各エントリは、「取得日時」と「センサＮｏ．１」〜「センサＮｏ．１０」というフィールドを有する。なお、図７では紙幅の都合上「センサＮｏ．４」〜「センサＮｏ．１０」のフィールドの図示は省略されている。
取得日時は、各種センサ３５１が計測を行ってデータを生成した日時を示す。また、センサＮｏ．ａ（１≦ａ≦１０）は、ａ番目のセンサが取得日時に計測した計測値を示す。
【０１９９】
図７のセンサログＤＢ３５２の例は、センサユニットＩＤが「０００１」のセンサユニット３５０内のセンサログＤＢ３５２の例である。そして、図７のセンサログＤＢ３５２の例によれば、２０１１年２月２１日の３時には、１番目のセンサが「２．１」という計測値を取得し、２番目のセンサが「７０」という計測値を取得し、３番目のセンサが「５．０」という計測値を取得している。また、２０１１年２月２１日の３時１５分には、１番目のセンサが「２．３」という計測値を取得し、２番目のセンサが「７３」という計測値を取得し、３番目のセンサが「５．３」という計測値を取得している。
【０２００】
なお、図６のサンプリング周期ＤＢ３２１に示すように、センサユニットＩＤが「０００１」のセンサユニット３５０における１〜３番目のセンサのサンプリング周期は同じ９００秒である。そのため、図７のセンサログＤＢ３５２の例では、１つの同じエントリの「センサＮｏ．１」〜「センサＮｏ．３」の各フィールドに計測値が記録されている。
【０２０１】
しかし、センサ間のサンプリング周期が異なるセンサユニット３５０においては、センサログＤＢ３５２において、個々のセンサのサンプリング周期に応じて、ＮＵＬＬなどの無効な値が記録されることもある。例えば、仮に２番目のセンサのサンプリング周期が１８００秒とすれば、図７のセンサログＤＢ３５２の例の２番目のエントリの「センサＮｏ．２」のフィールドには、無効な値が記録される。
【０２０２】
もちろん、実施形態によっては、センサログＤＢ３５２は、取得日時と、１つのセンサを識別する識別子と、当該１つのセンサが計測した計測値という３つのフィールドを持つ形式であってもよい。
【０２０３】
また、図７に示すように、端末３７０内のセンサログＤＢ３７６の各エントリは、端末３７０がセンサユニット３５０から受信したセンサログを、当該センサユニット３５０の識別子および受信時刻と対応づけている。具体的には、センサログＤＢ３７６の各エントリは、「センサユニットＩＤ」、「端末収集日時」、「取得日時」、「センサＮｏ．１」〜「センサＮｏ．１０」というフィールドを有する。
【０２０４】
センサユニットＩＤはセンサログの送信元のセンサユニット３５０の識別子を示し、端末収集日時は、センサログを端末３７０がセンサユニット３５０から受信した日時を示す。「取得日時」と「センサＮｏ．１」〜「センサＮｏ．１０」の各フィールドは、端末３７０が受信したセンサログが元々センサユニット３５０において記憶されていたセンサログＤＢ３５２と同様である。
【０２０５】
図７には、センサユニットＩＤが「０００１」のセンサユニット３５０から受信された２つのエントリが図示されている。つまり、図７に例示したセンサログＤＢ３７６の２つのエントリは、「図７に例示したセンサログＤＢ３５２の２つのエントリを含むセンサログを、端末３７０がセンサユニット３５０から２０１１年３月１日８時５９分に受信した」ということを示す。
【０２０６】
なお、センサログＤＢ３７６には、センサ通信部３７５を介してセンサログ処理部３７７がいずれかのセンサユニット３５０からセンサログを受信するたびに、受信したセンサログに含まれるエントリと同数のエントリが追加される。
【０２０７】
また、図７に示すように、サーバ３１０内のセンサログＤＢ３１５の各エントリは、端末３７０からサーバ３１０が受信したセンサログを、当該端末３７０の識別子および受信日時と対応づけている。具体的には、センサログＤＢ３１５各エントリは、「端末ＩＤ」、「サーバ収集日時」、「センサユニットＩＤ」、「端末収集日時」、「取得日時」、および「センサＮｏ．１」〜「センサＮｏ．１０」というフィールドを有する。
【０２０８】
端末ＩＤは、センサログの送信元の端末３７０の識別子を示し、サーバ収集日時は、端末３７０からサーバ３１０がセンサログを受信した日時を示す。そして、「センサユニットＩＤ」、「端末収集日時」、「取得日時」、および「センサＮｏ．１」〜「センサＮｏ．１０」の各フィールドは、サーバ３１０が受信したセンサログが元々端末３７０において記憶されていたセンサログＤＢ３７６と同様である。
【０２０９】
図７には、端末ＩＤが「０００３」の端末３７０を介してサーバ３１０が収集した２つのエントリが図示されている。つまり、図７に例示したセンサログＤＢ３１５の２つのエントリは、図７に例示したセンサログＤＢ３７６の２つのエントリに対応する。図７の例によれば、サーバ３１０は、端末ＩＤが「０００３」の端末３７０から、２０１１年３月１日９時にセンサログを受信している。
【０２１０】
なお、センサログＤＢ３１５には、センサログ処理部３１６が通信部３２７を介していずれかの端末３７０からセンサログを受信するたびに、受信されたセンサログに含まれるエントリと同数のエントリが追加される。
【０２１１】
さて、図８は、端末の移動につれて動的に変化するＤＢの例を示す図である。
図８に示すように、端末３７０内のＧＰＳログＤＢ３７２の各エントリは、ある時点でＧＰＳ情報取得部３７１が取得したＧＰＳ情報に対応し、「取得日時」と「緯度」と「経度」というフィールドを有する。取得日時は、ＧＰＳ情報取得部３７１がＧＰＳ情報を取得した日時を示す。また、端末３７０の位置を示すＧＰＳ情報は、具体的には緯度と経度により表される。そして、ＧＰＳログＤＢ３７２の１つ以上のエントリのかたまりが、ＧＰＳログとして端末３７０からサーバ３１０に送信される。
【０２１２】
図８には、端末ＩＤが「０００３」の端末３７０におけるＧＰＳログＤＢ３７２が例示されている。図８の例によれば、当該端末３７０のＧＰＳ情報取得部３７１は、２０１１年２月２１日８時１分に、北緯３５．４４３５４度・東経１３９．３１４１度というＧＰＳ情報を取得している。また、図８の例によれば、当該端末３７０のＧＰＳ情報取得部３７１は、２０１１年２月２１日８時２分に、北緯３５．４４３５３度・東経１３９．３１４２度というＧＰＳ情報を取得している。
【０２１３】
なお、ＧＰＳログＤＢ３７２には、ＧＰＳ情報取得部３７１がＧＰＳ情報を取得するたびにエントリが追加される。ＧＰＳ情報取得部３７１は、サーバ通信部３７３を介してサーバ３１０にＧＰＳログを送信した後、送信済みのＧＰＳログ（つまり送信済みのエントリ）をＧＰＳログＤＢ３７２から消去してもよい。
【０２１４】
また、図８に示すように、サーバ３１０内のＧＰＳログＤＢ３１１の各エントリは、端末３７０からサーバ３１０が受信したＧＰＳログを、当該端末３７０の識別子および受信日時と対応づけている。具体的には、ＧＰＳログＤＢ３１１の各エントリは、「端末ＩＤ」、「収集日時」、「取得日時」、「緯度」、および「経度」というフィールドを有する。
【０２１５】
端末ＩＤは、ＧＰＳログの送信元の端末３７０の識別子を示し、収集日時は、端末３７０からサーバ３１０がＧＰＳログを受信した日時を示す。取得日時と緯度と経度は、サーバ３１０が受信したＧＰＳログが元々端末３７０において記憶されていたＧＰＳログＤＢ３７２と同様である。
【０２１６】
図８には、端末ＩＤが「０００３」の端末３７０から収集された２つのエントリが図示されている。つまり、図８に例示したＧＰＳログＤＢ３１１の２つのエントリは、図８に例示したＧＰＳログＤＢ３７２の２つのエントリに対応する。図８の例によれば、サーバ３１０は、端末ＩＤが「０００３」の端末３７０から、２０１１年２月２１日８時１５分にＧＰＳログを受信している。
【０２１７】
なお、ＧＰＳログＤＢ３１１には、ＧＰＳログ処理部３１３が通信部３２７を介していずれかの端末３７０からＧＰＳログを受信するたびに、受信されたＧＰＳログに含まれるエントリと同数のエントリが追加される。
【０２１８】
図９は、第１実施形態のデータ収集システムの動作シーケンス図である。なお、図９には簡単のため１つのセンサユニット３５０と１つの端末３７０しか図示していないが、複数のセンサユニット３５０と複数の端末３７０がデータ収集システム３００内に存在してもよい。
【０２１９】
センサユニット３５０は、ステップＳ１０１に示すように、ユーザが端末３７０を携帯して近づいてくるのを待ち受ける。つまり、ユーザがセンサユニット３５０の人感センサの検知領域に入ってくるまで、センサユニット３５０は通信部３５４をオフにして待機する。
【０２２０】
他方、端末３７０では、ステップＳ１１１に示すように、ＧＰＳ情報取得部３７１がＧＰＳ情報を定期的に取得し、取得したＧＰＳ情報をＧＰＳログＤＢ３７２に格納する。ＧＰＳ情報取得部３７１は、ＧＰＳ情報の取得を所定回数繰り返す。例えば、ＧＰＳ情報取得部３７１は、１分間隔でＧＰＳ情報を取得してもよく、上記の所定回数は、例えば、１５回であってもよい。
【０２２１】
そして、所定回数ＧＰＳ情報を取得すると、ＧＰＳ情報取得部３７１は、ＧＰＳログＤＢ３７２に格納したＧＰＳログ（すなわち所定回数分のエントリ）を、サーバ通信部３７３を介してステップＳ１１２でサーバ３１０に送信する。
【０２２２】
また、図９では紙面の都合上省略しているが、端末３７０では、以上のステップＳ１１１〜Ｓ１１２の処理が繰り返される。なお、ステップＳ１１１〜Ｓ１１２の処理の詳細は、図１０のフローチャートとともに後述する。
【０２２３】
さて、ステップＳ１１２で送信されたＧＰＳログは、ステップＳ１２２においてサーバ３１０の通信部３２７で受信され、ＧＰＳログ処理部３１３に出力される。また、サーバ３１０では、以上のような端末３７０からのＧＰＳログの受信とは独立して、ステップＳ１２１の処理も行われる。
【０２２４】
例えば、ステップＳ１２１の処理は、圃場２０１での作業が始まる前の、毎朝決まった時刻に行われてもよい。図９の例は、ステップＳ１２１の処理の後にステップＳ１２２でＧＰＳログが受信される例である。
【０２２５】
具体的には、ステップＳ１２１では、アラーム距離決定部３２３が、収集日ＤＢ３１４とセンサユニット別アラーム条件ＤＢ３１９とアラーム条件ＤＢ３２０を参照して、各センサユニット３５０についてアラーム距離を決定する。アラーム距離決定部３２３は、決定した各アラーム距離を例えばＲＡＭ４０２上に記憶する。なお、ステップＳ１２１の処理の詳細は、図１１のフローチャートとともに後述する。
【０２２６】
そして、ステップＳ１２２では、端末３７０からのＧＰＳログを通信部３２７が受信し、受信されたＧＰＳログは、ＧＰＳログ処理部３１３の制御のもと、ＧＰＳログＤＢ３１１に格納される。
【０２２７】
すると、ＧＰＳログの受信を契機として、各センサユニット３５０についてステップＳ１２３〜Ｓ１２４の処理が行われる。
具体的には、ステップＳ１２３で端末・センサ間距離計算部３２４が、ＧＰＳログＤＢ３１１とセンサ位置ＤＢ３１７を参照して、センサユニット３５０と、ＧＰＳログの送信元の端末３７０の間の距離を計算する。そして、次のステップＳ１２４で距離比較部３２５が、端末・センサ間距離計算部３２４がステップＳ１２３で計算した距離と、アラーム距離決定部３２３がステップＳ１２１で決定したアラーム距離を比較する。
【０２２８】
その後、ステップＳ１２５でアラーム決定部３２６は、比較結果に基づいて、ＧＰＳログの送信元の端末３７０に対してアラーム指示を与える対象のセンサユニット３５０を決定する。端末３７０の位置に応じて、アラーム指示を与える対象のセンサユニット３５０の台数は、０台のこともあるし、１台のこともあるし、複数台のこともある。
【０２２９】
そして、次のステップＳ１２６でアラーム決定部３２６は、ＧＰＳログの送信元の端末３７０に対して、ステップＳ１２５での決定に基づく適宜のアラーム指示を、通信部３２７を介して送信する。なお、以上のステップＳ１２２〜Ｓ１２６の詳細は、図１２のフローチャートとともに後述する。
【０２３０】
さて、ステップＳ１２６で送信されたアラーム指示は、端末３７０のサーバ通信部３７３において、ステップＳ１１３で受信される。
すると、ステップＳ１１４でアラーム処理部３７４は、受信されたアラーム指示にしたがって、適宜のアラームを発する。
【０２３１】
例えば、アラームは、「山田太郎さん、××圃場のセンサユニットに近寄って、データ収集に御協力ください」のように文字で表現されていてもよいし、圃場の地図などの画像を含んでもよい。文字や画像による視覚的なアラームは、図４のディスプレイ４５１に表示される。あるいは、アラームは、ＬＥＤ４４８の点灯や点滅により視覚的に表現されてもよいし、ブザー４４９や不図示のスピーカからの放音により音声的に表現されてもよい。また、アラームは、振動モータ４５０による振動のように、触覚的に表現されてもよい。もちろん、視覚的、音声的、触覚的なアラームが組み合わされてもよい。
【０２３２】
アラームを受けたユーザは、アラームにしたがって、端末３７０を携帯したままセンサユニット３５０に近づく。そして、センサユニット３５０の人感センサの検知領域にユーザが入ると、センサユニット３５０は通信部３５４をオンにする。その結果、センサユニット３５０の通信部３５４と端末３７０のセンサ通信部３７５の間での通信が可能となる。
【０２３３】
よって、センサユニット３５０内ではセンサログ処理部３５３が通信部３５４を制御し、端末３７０内ではセンサログ処理部３７７がセンサ通信部３７５を制御することで、センサログがセンサユニット３５０から端末３７０へと送信される。なお、図９には特に明示しないが、通信部３５４とセンサ通信部３７５の間の通信は、実施形態に応じた適宜のプロトコルにしたがって確立されればよい。つまり、通信を確立するための最初のトリガは通信部３５４による要求でもよいし、センサ通信部３７５による要求でもよい。
【０２３４】
いずれにしろ、センサユニット３５０においては、ステップＳ１０２で、センサログ処理部３５３が通信部３５４を介して、センサログＤＢ３５２内のセンサログを送信する。そして、端末３７０においては、ステップＳ１１５で、センサログ処理部３７７がセンサ通信部３７５を介してセンサログを受信し、受信したセンサログを一旦センサログＤＢ３７６に格納する。
【０２３５】
そして、センサログの送受信が完了すると、ステップＳ１１６で、端末３７０のセンサログ処理部３７７が、サーバ通信部３７３を介して、センサログＤＢ３７６内のセンサログをサーバ３１０に送信する。
【０２３６】
すると、サーバ３１０では、ステップＳ１２７で通信部３２７を介してセンサログ処理部３１６がセンサログを受信する。センサログ処理部３１６は、受信したセンサログの各エントリを、送信元の端末３７０の端末ＩＤおよび受信時刻と対応づけて、センサログＤＢ３１５に格納する。
【０２３７】
そして、センサログのセンサユニット３５０から端末３７０への転送が済むと、ステップＳ１２８でセンサログ処理部３１６は、収集日ＤＢ３１４を更新する。すなわち、センサログ処理部３１６は、収集日ＤＢ３１４を検索して、センサログの送信元のセンサユニット３５０のセンサユニットＩＤを持つエントリを探し出す。そして、センサログ処理部３１６は、見つかったエントリの収集日に、今日の日付を上書きする。
【０２３８】
さらに、次のステップＳ１２９でセンサログ処理部３１６は、センサログの送信元のセンサユニット３５０のセンサユニットＩＤをアラーム距離決定部３２３に通知する。すると、アラーム距離決定部３２３は、通知されたセンサユニットＩＤに関して、ステップＳ１２１と同様にしてアラーム距離を再決定する。つまり、アラーム距離決定部３２３は、収集日の更新に応じて変化した経過時間に基づき、アラーム距離を再決定する。
【０２３９】
なお、サーバ３１０における以上のステップＳ１２８〜Ｓ１２９の処理と並行して、端末３７０においてセンサログ処理部３７７は、ステップＳ１１６で送信し終わったセンサログをセンサログＤＢ３７６から消去してもよい。
【０２４０】
図１０は、端末におけるＧＰＳログ処理のフローチャートである。図１０の処理は、例えば、端末３７０に電源が入っている間中、実行され続けてもよい。
ステップＳ２０１でＧＰＳ情報取得部３７１は、取得間隔用と送信間隔用のタイマをそれぞれ設定する。なお、以下の説明において「取得間隔」とは、ＧＰＳ情報取得部３７１が測位信号を受信してＧＰＳ情報を取得する間隔である。また、以下の説明において「送信間隔」とは、ＧＰＳ情報取得部３７１がサーバ通信部３７３を介してサーバ３１０にＧＰＳログを送信する間隔である。
【０２４１】
以下では説明の便宜上、取得間隔が１分であり、送信間隔が１５分であるものとする。つまり、ステップＳ２０１でＧＰＳ情報取得部３７１は、取得間隔用のタイマを１分に設定し、送信間隔用のタイマを１５分に設定する。しかし、取得間隔と送信間隔の具体的な値は実施形態に応じて任意であり、実施形態によっては、取得間隔と送信間隔が等しくてもよい。
【０２４２】
さて、ＧＰＳ情報取得部３７１は、取得間隔用のタイマにしたがい、取得間隔が経過するまで次のステップＳ２０２で待機する。取得間隔が経過すると、処理はステップＳ２０３に移行する。
【０２４３】
ステップＳ２０３でＧＰＳ情報取得部３７１は、ＧＰＳ受信機４４６により測位信号を受信し、端末３７０の現在位置の座標（つまり緯度と経度）を取得する。
そして、次のステップＳ２０４でＧＰＳ情報取得部３７１は、現在位置の座標を取得した取得日時（つまり現在時刻）と、取得した座標値（つまり緯度と経度）を、図８に例示するようにＧＰＳログＤＢ３７２に記録する。
【０２４４】
また、次のステップＳ２０５でＧＰＳ情報取得部３７１は、取得間隔用のタイマを再度１分に設定する。
そして、次のステップＳ２０６でＧＰＳ情報取得部３７１は、送信間隔用のタイマに基づいて、送信間隔が経過したか否かを判断する。送信間隔がまだ経過していなければ、処理はステップＳ２０２に戻る。
【０２４５】
逆に、送信間隔が経過していれば、処理はステップＳ２０７に移行する。つまり、ステップＳ２０２〜Ｓ２０５の処理を１５（＝１５／１）回繰り返すごとに、処理はステップＳ２０６からステップＳ２０７へと移行する。なお、上記「１５回」という回数は、図９のステップＳ１１１の「所定回数」に相当し、ステップＳ１１１はステップＳ２０２〜Ｓ２０５を１５回繰り返すことに相当する。
【０２４６】
そして、ステップＳ２０７でＧＰＳ情報取得部３７１は、送信間隔用のタイマを再度１５分に設定する。
続いて、ステップＳ２０８でＧＰＳ情報取得部３７１は、ＧＰＳログＤＢ３７２のデータを、端末３７０自体の端末ＩＤとともにサーバ３１０に送信する。すなわち、ステップＳ２０４の１５回の繰り返しによりＧＰＳログＤＢ３７２に蓄積された１５個のエントリを、ＧＰＳ情報取得部３７１は端末ＩＤとともに送信する。なお、ステップＳ２０８は図９のステップＳ１１２に相当する。
【０２４７】
また、次のステップＳ２０９でＧＰＳ情報取得部３７１は、ステップＳ２０８で送信したデータをＧＰＳログＤＢ３７２から削除する。そして、処理はステップＳ２０２に戻る。
【０２４８】
続いて、図１１を参照して、サーバ３１０において所定の時刻に行われるアラーム距離決定処理について説明する。図１１のアラーム距離決定処理は、図９のステップＳ１２１に相当する。
【０２４９】
ステップＳ３０１でアラーム距離決定部３２３は、今日の日付を取得する。
次に、ステップＳ３０２でアラーム距離決定部３２３は、センサユニット３５０に関するループ変数ｉを１に初期化する。
【０２５０】
そして、次のステップＳ３０３でアラーム距離決定部３２３は、図７の収集日ＤＢ３１４を参照して、ｉ番目のセンサユニット３５０から前回データを収集してからの経過日数を計算する。
【０２５１】
例えば、ｉ番目のセンサユニット３５０のセンサユニットＩＤが「０００２」であり、ステップＳ３０１で取得された日付が２０１１年３月５日だとする。図７の収集日ＤＢ３１４の例によれば、センサユニットＩＤが「０００２」のセンサユニット３５０から前回サーバ３１０がデータを収集した日は２０１１年３月３日である。よって、ステップＳ３０３でアラーム距離決定部３２３は、計算により「２日」という経過日数を得る。
【０２５２】
なお、図１１の例では、経過時間の一例として、１日単位の経過日数が使われる。しかし、実施形態によっては、例えば１秒単位などの、より粒度の細かい経過時間が使われてもよいことは無論である。
【０２５３】
続いて、ステップＳ３０４でアラーム距離決定部３２３は、図６のセンサユニット別アラーム条件ＤＢ３１９を参照して、ｉ番目のセンサユニット３５０のアラーム条件ＩＤを読み出す。例えば、上記のようにｉ番目のセンサユニット３５０のセンサユニットＩＤが「０００２」の場合、図６の例によると、ステップＳ３０４で読み出されるアラーム条件ＩＤは「０１」である。
【０２５４】
そして、次のステップＳ３０５でアラーム距離決定部３２３は、ステップＳ３０４で読み出したアラーム条件ＩＤを持つアラーム条件を、図６のアラーム条件ＤＢ３２０から読み出す。例えば、上記のようにアラーム条件ＩＤが「０１」の場合、アラーム距離決定部３２３は、図６のアラーム条件ＤＢ３２０の１番目のエントリを読み出す。
【０２５５】
そして、次のステップＳ３０６でアラーム距離決定部３２３は、ステップＳ３０３で計算した経過日数と、ステップＳ３０５で読み出したアラーム条件から、アラーム距離を決定する。また、アラーム距離決定部３２３は、以上のようにして決定したアラーム距離を、ｉ番目のセンサユニット３５０のセンサユニットＩＤと対応づけてＲＡＭ４０２上に保持する。
【０２５６】
例えば、上記のように経過日数が２日であり、アラーム条件ＩＤが「０１」のアラーム条件が読み出されたとする。この場合、図６のアラーム条件ＤＢ３２０の定義によれば、１日≦２日＜３日なので、ステップＳ３０６で決定されるアラーム距離は１ｍである。
【０２５７】
そして、次のステップＳ３０７でアラーム距離決定部３２３は、ループ変数ｉの値がデータ収集システム３００内のセンサユニット３５０の総数Ｕに達したか否かを判断する。もし、ｉ＝Ｕであれば、図１１のアラーム距離決定処理は終了する。逆に、ｉ≠Ｕであれば（つまりｉ＜Ｕであれば）、処理はステップＳ３０８へと移行する。
【０２５８】
ステップＳ３０８でアラーム距離決定部３２３は、ループ変数ｉをインクリメントする。そして、処理はステップＳ３０３に戻る。
ところで、上記のとおり、アラーム距離決定部３２３は、図１１のアラーム距離決定処理により決定した各センサユニット３５０についてのアラーム距離を、例えばＲＡＭ４０２上に保持し続ける。よって、図９においては、図１１に相当するステップＳ１２１で決定されたアラーム距離を、距離比較部３２５が後のステップＳ１２４で参照することが可能である。
【０２５９】
また、図９のステップＳ１２９の再決定は、具体的には、再決定の対象のセンサユニット３５０に関してアラーム距離決定部３２３がステップＳ３０３〜Ｓ３０６の処理を行うことに相当する。
【０２６０】
続いて、図９のステップＳ１２２〜Ｓ１２６に相当する処理について、図１２を参照して説明する。図１２は、第１実施形態のアラーム関連処理のフローチャートである。
ＧＰＳログ処理部３１３は、いずれかの端末３７０から通信部３２７を介してＧＰＳログを受信するまで、ステップＳ４０１で待機する。そして、ＧＰＳログが受信されると、ＧＰＳログ処理部３１３は、ＧＰＳログを端末３７０の端末ＩＤおよび受信時刻と対応づけてＧＰＳログＤＢ３１１に格納し、その後、処理はステップＳ４０２に移行する。
【０２６１】
すると、ステップＳ４０２で端末・センサ間距離計算部３２４は、ステップＳ４０１でＧＰＳログ処理部３１３が受信したＧＰＳログに相当するエントリをＧＰＳログＤＢ３１１から読み出す。例えば、端末３７０が図１０にしたがって動作する場合、１回の送信で端末３７０から送信されるＧＰＳログは、１５（＝１５／１）個のエントリに相当するので、ステップＳ４０２ではＧＰＳログＤＢ３１１内で収集日時が最新の１５個のエントリが読み出される。
【０２６２】
端末・センサ間距離計算部３２４は、ステップＳ４０２においてさらに、読み出したエントリをウィンドウ間隔ＷごとにＮ個のブロックに分割する。ここで、ウィンドウ間隔Ｗは、ＧＰＳログの１回の送信に対応するエントリ数よりも小さな所定の値であり、端末３７０の位置の平均をとるための時間の幅を表す。以下では説明の便宜上Ｗ＝５とする。例えば、図１０の例のように取得間隔が１分であり、上記仮定のようにＷ＝５の場合、ウィンドウ間隔Ｗが示す時間の幅は５分（＝１分×Ｗ）である。
【０２６３】
そして、ブロックの個数Ｎは、ＧＰＳログの１回の送信に対応するエントリ数をウィンドウ間隔で割った値である。よって、上記のように１回の送信で端末３７０から送信されるＧＰＳログが１５個のエントリに相当する場合、Ｎ＝１５／５＝３である。
【０２６４】
以上のようなブロックへの分割の後、ステップＳ４０３で端末・センサ間距離計算部３２４は、分割して得られた各ブロックにおける平均座標を求める。例えばＷ＝５の場合、１つのブロックにはＧＰＳログＤＢ３１１から読み出された５つのエントリが対応するので、ステップＳ４０３では、各ブロックについて、５つのエントリの平均座標（つまり平均緯度と平均経度）が計算される。
【０２６５】
ここで説明の便宜上、ステップＳ４０１で受信されたＧＰＳログが、ｊ番目の端末ｔｅｒｍｊが時刻ｔｊ，ｋ〜ｔｊ，ｋ＋ＷＮ−１に取得したＷＮ個の座標ｇｐｓｊ，ｋ〜ｇｐｓｊ，ｋ＋ＷＮ−１に対応するものとする。すると、ステップＳ４０３でｎ番目（１≦ｎ≦Ｎ）のブロックについて計算される平均座標ａｖｒｊ，ｎは、式（２）のとおりである。
【０２６６】
【数２】
【０２６７】
なお、図８から理解されるように、個々の座標ｇｐｓｊ，ｋ〜ｇｐｓｊ，ｋ＋ＷＮ−１と平均座標ａｖｒｊ，ｎのいずれも、具体的には、緯度と経度のペアで表される。
【０２６８】
続くステップＳ４０４〜Ｓ４１３の処理は、各センサユニット３５０についてステップＳ４０５〜Ｓ４１１の処理を繰り返すことを含む。そして、ステップＳ４０５〜Ｓ４１１の処理は、「ブロックの平均座標とセンサユニット３５０との間の距離がアラーム距離以下になるブロックが１つでもあるか」ということを判定する処理である。
【０２６９】
具体的には、ステップＳ４０４でサーバ３１０は、センサユニット３５０についてのループ変数ｉを１に初期化する。
また、次のステップＳ４０５で距離比較部３２５は、ｉ番目のセンサユニット３５０に対応するフラグをｆａｌｓｅに初期化する。当該フラグは、「ステップＳ４０１で受信されたＧＰＳログの送信元の端末３７０のブロックごとの平均座標のうち、ｉ番目のセンサユニット３５０からの距離がｉ番目のセンサユニット３５０に関するアラーム距離以下のものが１つでもあるか」ということを示す。換言すれば、当該フラグは、「ステップＳ４０１で受信されたＧＰＳログの送信元の端末３７０に対してｉ番目のセンサユニット３５０についてのアラーム指示を送信するか否かを示す。初期値のｆａｌｓｅは、アラーム指示を送信しないことを示す。
【０２７０】
また、次のステップＳ４０６でサーバ３１０は、ブロックについてのループ変数ｎを１に初期化する。
そして、次のステップＳ４０７で端末・センサ間距離計算部３２４は、ステップＳ４０３で計算したｎ番目のブロックの平均座標が示す位置と、ｉ番目のセンサユニット３５０との間の距離を計算する。つまり、端末・センサ間距離計算部３２４は、図５のセンサ位置ＤＢ３１７を参照してｉ番目のセンサユニット３５０が設置された位置の緯度と経度を読み出し、読み出した緯度と経度と、ステップＳ４０３の計算結果を用いて、距離を計算する。
【０２７１】
説明の便宜上、ｉ番目のセンサユニット３５０の位置をｐｏｓｉとする。すると、ステップＳ４０７で計算される距離ｄｉｓｔｉ，ｊ，ｎは、式（３）のように表すことができる。
【０２７２】
【数３】
【０２７３】
なお、図５から理解されるように、ｉ番目のセンサユニット３５０の位置ｐｏｓｉは緯度と経度のペアで表される。また、式（３）において｜｜ｘ−ｙ｜｜は、位置ｘと位置ｙの間の距離（例えば、ユークリッド距離でもよいし、マンハッタン距離でもよい）を示すものとする。
【０２７４】
そして、次のステップＳ４０８で距離比較部３２５は、ステップＳ４０７で計算された距離ｄｉｓｔｉ，ｊ，ｎが、図１１の処理の結果としてアラーム距離決定部３２３がｉ番目のセンサユニット３５０に関して記憶しているアラーム距離以下か否かを判断する。以下では、説明の便宜上、アラーム距離決定部３２３がｉ番目のセンサユニット３５０に関して記憶しているアラーム距離をａｌａｒｍｉと表記する。
【０２７５】
計算された距離ｄｉｓｔｉ，ｊ，ｎがアラーム距離ａｌａｒｍｉ以下のとき、処理はステップＳ４０９に移行する。逆に、距離ｄｉｓｔｉ，ｊ，ｎがアラーム距離ａｌａｒｍｉより大きいとき、処理はステップＳ４１０に移行する。
【０２７６】
ステップＳ４０９が実行されるのは、ブロックの平均座標ａｖｒｊ，ｎとｉ番目のセンサユニット３５０との間の距離ｄｉｓｔｉ，ｊ，ｎがアラーム距離ａｌａｒｍｉ以下になるブロックが見つかった場合である。この場合、距離比較部３２５は、ｉ番目のセンサユニット３５０に対応するフラグ（つまりステップＳ４０５で初期化したフラグ）をｔｒｕｅに設定する。そして、さらに別のブロックについて検討する必要はもうないので、処理はステップＳ４１２に移行する。
【０２７７】
他方、ステップＳ４１０が実行されるのは、ブロックの平均座標ａｖｒｊ，ｎとｉ番目のセンサユニット３５０との間の距離ｄｉｓｔｉ，ｊ，ｎがアラーム距離ａｌａｒｍｉ以下になるブロックがまだ見つかっていない場合である。この場合、ステップＳ４１０でサーバ３１０は、未注目のブロックが残っているか否かを判断する。すなわち、サーバ３１０は、ｎ＝Ｎであるか否かを判断する。
【０２７８】
そして、ｎ＝Ｎの場合は、全ブロックが注目済みであり、どのブロックの平均座標ａｖｒｊ，ｎも、ｉ番目のセンサユニット３５０との間の距離がアラーム距離ａｌａｒｍｉより大きい場合である。よって、ｎ＝Ｎの場合は、ステップＳ４０５で初期化されたフラグの値がｆａｌｓｅのまま、処理がステップＳ４１２へと移行する。
【０２７９】
他方、ｎ≠Ｎの場合（より具体的にはｎ＜Ｎの場合）は、未注目のブロックが残っている。よって、次のブロックに注目するために処理はステップＳ４１１に移行する。
そして、ステップＳ４１１でサーバ３１０は、ブロックに関するループ変数ｎをインクリメントし、その後、処理はステップＳ４０７に戻る。
【０２８０】
ここで、ｊ番目の端末ｔｅｒｍｊからステップＳ４０１でＧＰＳログが受信された場合の、ｉ番目のセンサユニット３５０についてのフラグをｆｌａｇｉ，ｊと表記する。上記のステップＳ４０５〜Ｓ４１１の処理により、フラグｆｌａｇｉ，ｊは、式（４）のように設定される。
【０２８１】
【数４】
【０２８２】
さて、ステップＳ４１２でサーバ３１０は、すべてのセンサユニット３５０について注目し終えたか否かを判断する。つまり、サーバ３１０は、センサユニット３５０についてのループ変数ｉの値がデータ収集システム３００内のセンサユニット３５０の総数Ｕに達したか否かを判断する。
【０２８３】
そして、ｉ＝Ｕの場合、処理はステップＳ４１４に移行する。他方、ｉ≠Ｕの場合（より具体的にはｉ＜Ｕの場合）は、未注目のセンサユニット３５０が残っているので、処理はステップＳ４１３に移行する。
【０２８４】
ステップＳ４１３でサーバ３１０は、センサユニット３５０についてのループ変数ｉをインクリメントする。その後、処理はステップＳ４０５に戻る。
さて、ステップＳ４１４の処理が実行されるのは、データ収集システム３００内のすべてのセンサユニット３５０に関して、フラグｆｌａｇｉ，ｊが設定された後である。そして、ステップＳ４１４でアラーム決定部３２６は、対応するフラグがｔｒｕｅの全センサユニット３５０のリストを取得する。なお、センサユニット３５０のリストは、具体的にはセンサユニットＩＤのリストとして表現される。
【０２８５】
ここで説明の便宜上、ｉ番目のセンサユニット３５０のセンサユニットＩＤをｕｎｉｔｉと表記すると、ステップＳ４１４で取得されるリストは、式（５）の集合ｔａｒｇｅｔｊを表すリストである。つまり、ステップＳ４１４においてアラーム決定部３２６は、ステップＳ４０１で受信されたＧＰＳログの送信元の端末３７０（すなわち端末ｔｅｒｍｊ）に対してアラーム指示を出す対象のセンサユニット３５０の集合ｔａｒｇｅｔｊを決定する。
【０２８６】
【数５】
【０２８７】
そして、次のステップＳ４１５でアラーム決定部３２６は、アラーム指示として、ステップＳ４１４で取得したリストを、ステップＳ４０１で受信されたＧＰＳログの送信元の端末３７０に、通信部３２７を介して送信する。
【０２８８】
なお、場合によっては、ステップＳ４１４で得られるリストが空リストのことがある（つまり集合ｔａｒｇｅｔｊが空集合のことがある）。空リストがアラーム指示として送信される場合のアラーム指示とは、具体的には「どのセンサユニット３５０に関してもアラームを発する必要がない」という指示である。
【０２８９】
しかし、「アラームを発する必要がない」ということは、明示的に指示されなくても構わない。よって、ステップＳ４１４で得られるリストが空リストの場合、ステップＳ４１５の送信が省略されてもよい。
【０２９０】
逆に、非空のリストがアラーム指示としてステップＳ４１５で送信される場合、アラーム指示は「当該リストに含まれる各センサユニットＩＤのセンサユニット３５０について、アラームを発せよ」という指示である。
【０２９１】
いずれにしろ、ステップＳ４１５でのリストの送信後、処理はステップＳ４０１に戻る。
なお、図１２のステップＳ４０１における受信が図９のステップＳ１２２における受信に対応し、図１２のステップＳ４０７とＳ４０８が図９のステップＳ１２３とＳ１２４に対応する。また、図１２のステップＳ４１４が図９のステップＳ１２５に対応し、ステップＳ４１５がステップＳ１２６に対応する。
【０２９２】
そして、以上説明した第１実施形態によれば、センサユニット３５０ごとに、データ収集の緊急度に応じてアラーム距離が決定され、アラーム距離と端末３７０の位置に基づいてサーバ３１０が端末３７０にアラーム指示を出す。つまり、端末３７０がユーザに対してアラームを出すか否かは、センサユニット３５０からのデータ収集の緊急度に依存する。よって、第１実施形態によれば、センサユニット３５０からのデータ収集にユーザが関与するデータ収集システム３００において、データ収集の緊急度とユーザの負担のバランスがとれる。
【０２９３】
続いて、図１３〜２０を参照して第２実施形態について説明する。なお、第１実施形態との共通点については適宜説明を省略する。第２実施形態は、第１実施形態と同様にデータ収集の緊急度とユーザの負荷のバランスをとる効果だけでなく、さらに、ユーザの作業効率の低下を防ぐ効果を奏する。
【０２９４】
まず、図１３を参照して、第２実施形態により解決しようとする課題について説明する。図１３は、データ収集への関与が原因でユーザの作業効率が悪くなる例を示す図である。
【０２９５】
図２と同様に図１３にも、圃場２０１におけるユーザの動きの例が示されている。図２と同様に図１３でも圃場２０１の隅にセンサユニット２０２が設置されており、センサユニット２０２の人感センサの検知領域２０３は、広い圃場２０１のごく一部である。
【０２９６】
ここで、ユーザ２０９が軌跡２１０に沿って移動しながら除草などの作業を行っているものとする。そして、軌跡２１０の矢印の先端までユーザ２０９が移動した時点で、ユーザ２０９が携帯する不図示の端末がアラームを発したとする。
【０２９７】
すると、アラームを受けたユーザ２０９は、作業を中断して、軌跡２１１として示すようにセンサユニット２０２の近傍まで移動する。そして、ユーザ２０９が検知領域２０３に入ると、センサユニット２０２の人感センサがユーザ２０９の存在を検知し、センサユニット２０２は通信機能をオンにする。すると、センサユニット２０２と端末が通信を開始し、その結果、センサユニット２０２から端末へとセンサログが転送される。
【０２９８】
ユーザ２０９は、センサログが端末に転送され終わるのを待ってから、軌跡２１２として示すように元の位置まで移動する。その後、ユーザ２０９は、中断した作業を再開する。具体的には、ユーザ２０９は、軌跡２１３に沿って移動しながら作業の続きを行う。
【０２９９】
以上の図１３の例のとおり、ユーザ２０９がアラームを受けるタイミングによっては、ユーザ２０９は、データ収集に関与するために作業を中断することがある。作業の中断は、作業効率を落とす。
【０３００】
また、アラームを受けたときにユーザ２０９がいる場所が図１３のようにセンサユニット２０２から遠く離れている場合、ユーザ２０９が軌跡２１１と２１２に沿って移動する距離も長い。長い距離をユーザ２０９が移動する場合、作業の中断時間も長い。すると、ユーザ２０９は、移動に気を取られて、例えば「どこまで作業が済んだか」ということを忘れてしまうかもしれない。その結果、作業効率がさらに悪化するおそれもある。
【０３０１】
以上の図１３の例から理解されるように、ユーザ２０９の作業中に端末がアラームを出すことは、作業効率を悪化させるおそれがある。そこで、第２実施形態では、作業効率が悪化する度合を小さくするために、作業スケジュールに基づいて２種類の制御が行われる。
【０３０２】
すなわち、第１に、データ収集の緊急度がまだそれほど高くない場合（換言すれば、前回の収集からの経過時間がまだそれほど長くないためアラーム距離がそれほど大きくない場合）は、アラームの発行を後日に延期する制御が行われる。「あるセンサユニットに関するアラームの発行を延期する」ということは、「端末の位置によらず、延期された日までは、当該センサユニットに関するアラームが発行されない」ということである。つまり、延期により、アラームによる作業の中断が防止され、作業効率の悪化を防ぐことができる。
【０３０３】
しかし、無制限の延期は好ましくない。そこで、第２実施形態では、「どの程度の延期が適切なのか」という判断のため、センサユニットが設置された場所（例えば圃場２０１）での作業スケジュールが参照される。
【０３０４】
また、第２に、アラームの発行は、なるべくユーザの作業を中断させないタイミングで行われるように制御される。ユーザの作業を中断させないタイミングとは、ユーザが作業をしていないと想定されるタイミングであり、具体的には、休憩時間である。例えば、休憩時間の開始時刻もしくは終了時刻、または休憩時間中にアラームが出されれば、ユーザは作業を中断せずに済む。つまり、端末がアラームを出す時刻を調整することは、ユーザの負荷自体を減らすことはないとはいえ、作業効率に与える悪影響を減らす効果がある。
【０３０５】
以下では、以上に概略を述べたような第２実施形態の動作と構成について、より具体的に説明する。
図１４は、第２実施形態のセンサデータ収集システムのブロック構成図である。図１４では、第１実施形態と同様の構成要素には図３と同じ参照符号が割り当てられている。
【０３０６】
図１４のデータ収集システム３００ｂは、サーバ３１０ｂと、１台以上のセンサユニットと、１台以上の端末を含む。図１４には図３と同様に、３台のセンサユニット３５０ａ〜３５０ｃと３台の端末３７０ａ〜３７０ｃが例示されているが、センサユニット３５０および端末３７０の台数は任意である。また、図１４に示す第２実施形態のセンサユニット３５０ａ〜３５０ｃと端末３７０ａ〜３７０ｃは、図３に示す第１実施形態のものと同様である。
【０３０７】
図１４のサーバ３１０ｂは、以下の点において図３のサーバ３１０と異なる。すなわち、サーバ３１０ｂは、図３の収集日ＤＢ３１４の代わりに収集日ＤＢ３２８を有し、図３のアラーム決定部３２６の代わりにアラーム決定部３３４を有する。また、サーバ３１０ｂはさらに、圃場形状ＤＢ３２９、スケジュールＤＢ３３０、休憩時間ＤＢ３３１、スケジュール単位定義ＤＢ３３２、および圃場特定部３３３を有する。
【０３０８】
収集日ＤＢ３２８は、詳しくは図１５に示すとおり、図７の収集日ＤＢ３１４とは異なる構造を有する。収集日ＤＢ３２８は、収集日ＤＢ３１４と同様に、図４のＨＤＤ４０３に保持されていてもよいし、ＲＡＭ４０２に保持されていてもよい。
【０３０９】
また、アラーム決定部３３４は、図３のアラーム決定部３２６が行う処理とはやや異なる処理を行う。アラーム決定部３３４も、アラーム決定部３２６と同様に、図４のＣＰＵ４０１がプログラムを実行することにより実現される。
【０３１０】
そして、圃場形状ＤＢ３２９は、センサユニット３５０が設置された圃場の形状を表す情報を記憶するＤＢである。また、スケジュールＤＢ３３０は、各圃場での作業スケジュールを記憶するＤＢである。なお、第２実施形態では「どの圃場でも作業の休憩時間は共通である」と仮定しており、休憩時間ＤＢ３３１はこの仮定に基づいて休憩時間を記憶するＤＢである。スケジュール単位定義ＤＢ３３２は、「作業が予定されている日と作業が予定されていない日が混在する場合に、どの範囲をひとかたまりの作業の単位として見なすか」を規定する規則を記憶するＤＢである。具体的には、スケジュール単位定義ＤＢ３３２には、規則を表現するための１つ以上のパラメタが記憶される。
【０３１１】
以上の各種ＤＢの詳細は図１５とともに後述する。また、以上の各種ＤＢは、例えば、図４のＨＤＤ４０３に格納され、必要に応じてＲＡＭ４０２に読み出される。
そして、圃場特定部３３３は、端末３７０が存在する圃場を、端末３７０から受信したＧＰＳログに基づいて特定する。圃場を特定することにより、当該圃場でのスケジュールを参照することが可能になる。圃場特定部３３３は、図４のＣＰＵ４０１がプログラムを実行することにより実現される。
【０３１２】
図１５は、第２実施形態においてサーバが保持するＤＢの例を示す図である。
収集日ＤＢ３２８は、図７の収集日ＤＢ３１４と類似のＤＢだが、各エントリが「アラーム予定日」および「圃場ＩＤ」というフィールドを含む点で、収集日ＤＢ３１４と異なる。アラーム予定日は、センサユニットＩＤで識別される当該センサユニット３５０に関するアラーム指示を端末３７０に出す予定の日である。換言すれば、アラーム予定日は、当該センサユニット３５０に関するアラームを端末３７０に出させる予定の日である。
【０３１３】
図１５の例では、センサユニットＩＤが「０００２」のエントリに関してのみアラーム予定日が２０１１年３月５日に設定されており、他のエントリではアラーム予定日が未設定である。
【０３１４】
なお、詳しくは後述するが、アラーム予定日は、アラーム決定部３３４によって随時更新され得る。また、実際にサーバ３１０ｂがデータを収集すると、アラーム予定日はクリアされ、未設定の状態に戻される。
【０３１５】
また、圃場ＩＤは、センサユニットＩＤで識別される当該センサユニット３５０が設定されている圃場を、データ収集システム３００ｂ内で一意に識別する識別子を示す。圃場ＩＤは、センサユニットＩＤから一意に定まるので、例えば図５のセンサ位置ＤＢ３１７などに記憶されていてもよいが、説明の便宜上、第２実施形態では収集日ＤＢ３２８に記憶されているものとする。
【０３１６】
図１５の例では、センサユニットＩＤが「０００１」と「０００２」のセンサユニット３５０は、「０００５」という圃場ＩＤの圃場に設置されている。また、センサユニットＩＤが「０００３」のセンサユニット３５０は、「０００１」という圃場ＩＤの圃場に設置されており、センサユニットＩＤが「００１０」のセンサユニット３５０は、「０００７」という圃場ＩＤの圃場に設置されている。
【０３１７】
さて、図１５に示すように、圃場形状ＤＢ３２９は、センサユニット３５０が設置される圃場の形状を表すＤＢである。第２実施形態では、１つの圃場の形状が多角形で近似され、ｘ角形（３≦ｘ）で近似される圃場の形状は、圃場形状ＤＢ３２９のｘ個のエントリで表される。
【０３１８】
具体的には、圃場形状ＤＢ３２９の各エントリは、「圃場ＩＤ」、「頂点数」、「頂点ＩＤ」、「緯度」、および「経度」というフィールドを有する。圃場ＩＤは圃場の識別子を示す。頂点数は、圃場ＩＤで識別される圃場の形状を近似する多角形の頂点の数を示す。頂点ＩＤは、１つの圃場内で各頂点を一意に識別する識別子であり、緯度と経度は頂点の位置を示す。
【０３１９】
図１５の例によれば、圃場ＩＤが「０００１」の圃場は４角形で近似され、そのうち２つの頂点は、北緯３５．４３９９６度・東経１３９．３０７１度と、北緯３５．４３９９６度・東経１３９．３０８０度にある。
【０３２０】
なお、圃場形状ＤＢ３２９は静的なＤＢだが、センサユニット３５０を設置する対象の圃場の増減に応じてエントリが追加または削除される。また、実施形態によっては、圃場形状ＤＢ３２９のように数値による圃場の形状を表すＤＢの代わりに、緯度と経度に対応づけて圃場の範囲を示す２値画像などによって圃場の形状を表す画像ＤＢが利用されてもよい。
【０３２１】
さて、図１５に示すように、スケジュールＤＢ３３０の各エントリは、個々の圃場での個々の作業に対応し、「圃場ＩＤ」と「開始日時」と「終了日時」と「作業内容」というフィールドを有する。圃場ＩＤは、圃場形状ＤＢ３２９と同様に、圃場の識別子である。開始日時と終了日時は、作業がいつからいつまで行われる予定であるかを示す。作業内容は、作業の内容を示す。
【０３２２】
図１５の例によれば、圃場ＩＤが「０００１」の圃場では、２０１１年３月１４日の８時から１２時まで、草取りが予定されている。また、圃場ＩＤが「０００２」の圃場では、２０１１年３月１４日の１３時から１５時まで、播種が予定されている。
【０３２３】
スケジュールＤＢ３３０は動的なＤＢであり、新たな作業の予定が立てられるたびに、例えば、端末３７０からの指示またはサーバ３１０ｂのキーボード４１２からの入力に応じて、エントリが追加される。
【０３２４】
また、図１５に示すように、休憩時間ＤＢ３３１の各エントリは、１回の休憩時間に対応する。なお、第２実施形態では、「どの圃場でも休憩時間のスケジュールは共通である」と仮定している。よって、休憩時間ＤＢ３３１の各エントリは、「休憩時間ＩＤ」と「開始時刻」と「終了時刻」というフィールドを有する。休憩時間ＩＤは個々の休憩時間を識別する識別子であり、開始時刻と終了時刻は休憩時間の範囲を示す。
【０３２５】
図１５の例によれば、休憩時間ＩＤが「０１」の休憩時間は１０時から１０時１５分までであり、休憩時間ＩＤが「０２」の休憩時間は１２時から１３時までであり、休憩時間ＩＤが「０３」の休憩時間は１５時から１５時１５分までである。なお、休憩時間ＤＢ３３１は静的なＤＢだが、休憩時間の予定が変われば、エントリの追加・削除・変更などが行われてもよい。
【０３２６】
また、図１５に示すように、スケジュール単位定義ＤＢ３３２には、「作業が予定されている日と作業が予定されていない日が混在する場合に、どの範囲をひとかたまりの作業の単位として見なすか」を規定する規則を表現するためのパラメタが設定されている。第２実施形態では、上記規則は、具体的には、「作業なし期間の最大長さ」と「作業なし期間の最大回数」という２つのパラメタで表される。
【０３２７】
そして、図１５の例では、これら２つのパラメタの値は、それぞれ「３日」と「２回」である。すなわち、図１５の例は、以下のような規則を表す。
・作業なし期間をはさんで断続的に作業が予定されている場合であっても、作業なし期間をはさんだ全体を、ひとかたまりの作業の単位として見なせることがある。
・具体的には、作業なし期間をはさんで断続的に作業が行われる場合、３日以内の作業なし期間を２回まで含んでいても、全体をひとかたまりの作業の単位として見なしてよい。
・３日より長い作業なし期間がある場合は、当該作業なし期間が、作業の単位同士の区切れ目になる。
・３回目の３日以内の作業なし期間も、作業の単位同士の区切れ目になる。
【０３２８】
なお、スケジュール単位定義ＤＢ３３２は静的なＤＢである。スケジュール単位定義ＤＢ３３２に設定されるパラメタの種類と値は実施形態に応じて適宜決められてよい。
【０３２９】
図１６は、作業スケジュールとアラーム予定日の例を示す図である。図１６には４通りのスケジュール例５０１〜５０４が例示されている。
スケジュール例５０１は、「前回のデータ収集日から２週間あいて、今日から３日間作業が予定されている」という例である。スケジュール例５０１のように前回のデータ収集日からの経過時間が長い場合は、データ収集の緊急度が高いので、データ収集を延期しないことが望ましい。
【０３３０】
つまり、サーバ３１０ｂは、今日のうちにアラーム指示を出し、端末３７０を介してセンサユニット３５０からデータを収集することが望ましい。換言すれば、アラーム決定部３３４は、アラーム予定日を設定しないこと（それにより、暗黙的に、今日をアラーム予定日として指定すること）が望ましい。なお、図１６ではアラーム予定日が二重丸で示されている、
【０３３１】
他方、スケジュール例５０２は、「前回のデータ収集日から３日間だけあいて、今日から３日間作業が予定されている」という例である。スケジュール例５０２のように前回のデータ収集日からの経過時間が短い場合は、データ収集の緊急度が低いので、データ収集を延期しても構わない。
【０３３２】
また、３日間の作業の最終日であっても前回の収集日の６日後である。例えば、データ収集の緊急度が「当日中にデータを収集することが望ましい」という程度にまで高まるのが、前回の収集日から１０日後であるとすると、スケジュール例５０２の作業最終日にデータが収集されることは十分許容される。
【０３３３】
そこで、スケジュール例５０２の場合、アラーム決定部３３４は、今日から予定されている３日間の作業の最終日をアラーム予定日として設定することが好ましい。すると、サーバ３１０ｂは、作業１日目をアラーム予定日として設定する場合と比べて、次の収集でより多くのデータ（つまり作業２日目や３日目のセンサログ）を取得することができる。
【０３３４】
もちろん、設定されたアラーム予定日よりも前に、偶発的または自発的にユーザがセンサユニット３５０に近寄ってデータ収集に関与することもあり得る。よって、例えば、作業２日目にデータが収集される場合もあり得る。すると、収集に応じて、アラーム決定部３３４はアラーム予定日を新たに設定しなおす。
【０３３５】
また、スケジュール例５０１と５０２は、作業が３日間連続する例だが、場合によっては、作業のない日を間にはさみながら、断続的に作業が予定されることもある。例えば、スケジュール例５０３と５０４はその例である。
【０３３６】
スケジュール例５０３は、「前回のデータ収集日から２日間あいて、今日から３日間作業が予定されており、その後、２日間の作業なし期間をはさんで作業が再開される予定であり、再開後の作業は４日間にわたる予定である」という例である。そして、図１５のスケジュール単位定義ＤＢ３３２によれば、２日間の作業なし期間をはさんだ合計７日間の作業の全体（つまり、作業なし期間も数えれば９日にわたる期間の全体）は、ひとかたまりの単位と見なせる。
【０３３７】
また、ここで、スケジュール例５０２について例示したのと同様に、前回の収集日から１０日後には、データ収集の緊急度が「当日中にデータを収集することが望ましい」という程度にまで高まる、と仮定する。つまり、収集を後日に延期することが許容されるのは、前回の収集日から９日目までである、と仮定する。したがって、前回の収集日から１０日目になったら、サーバ３１０ｂはアラーム指示を出すことが望ましい。
【０３３８】
スケジュール例５０３の例では、ひとかたまりの単位の最終日は再開後作業最終日であるが、再開後作業最終日には前回の収集日から１１日が経過してしまう。よって、アラーム予定日は、前回の収集日から１０日後にあたる再開後作業３日目とすることが望ましい。
【０３３９】
つまり、たとえ今日が前回の収集日から間もないとしても、ひとかたまりの作業の単位が長ければ、最終日には、前回の収集日から大幅な日数が経過してしまうおそれがある。よって、サーバ３１０ｂは、一律にひとかたまりの作業の単位の最終日をアラーム予定日とするのではなく、前回の収集日からの経過時間がある程度の範囲内に収まるように、アラーム予定日を設定することが好ましい。
【０３４０】
また、スケジュール例５０４は、「前回のデータ収集日から４日間あいて、今日から３日間作業が予定されており、その後、３日間の作業なし期間をはさんで作業が再開される予定であり、再開後の作業は３日間にわたる予定である」という例である。そして、図１５のスケジュール単位定義ＤＢ３３２によれば、３日間の作業なし期間をはさんだ合計６日間の作業の全体（つまり、作業なし期間も数えれば９日にわたる期間の全体）は、ひとかたまりの単位と見なせる。
【０３４１】
スケジュール例５０３の場合と同様に、スケジュール例５０４でも、前回の収集日から１０日後がアラーム予定日として設定されてもよい。スケジュール例５０４の場合は、前回の収集日から１０日後が偶然にも作業なし日であるが、例えば上記の１０日という閾値が多少の余裕をもって設定された値であれば、このように作業なし日にアラーム予定日が重なってもよい。例えば、アラーム予定日の翌日（つまり作業再開１日目）に実際にユーザが作業をしに圃場に来たときに、サーバ３１０ｂは、既に前回の収集日から１０日以上経過していることを検知して、アラーム指示を出せばよい。
【０３４２】
図１７は、第２実施形態のデータ収集システムの動作シーケンス図である。なお、センサユニット３５０の動作は第１実施形態と同様なので、図１７ではセンサユニット３５０の動作は省略されている。
【０３４３】
また、端末３７０の動作も第１実施形態と同様である。図１７には、図９の第１実施形態のシーケンス図と同様に、端末３７０が行うステップＳ１１１〜Ｓ１１３の処理が図示されているが、ステップＳ１１４以後の端末３７０の処理は、紙幅の都合上、図１７では省略されている。
【０３４４】
サーバ３１０ｂにおいては、図９の第１実施形態と同様に図１７の第２実施形態でも、ステップＳ１２１でアラーム距離決定部３２３が各センサユニット３５０についてのアラーム距離を決定する。そして、図９のステップＳ１２２〜Ｓ１２６の代わりに図１７にはステップＳ５０１〜Ｓ５０８が示されている。
【０３４５】
なお、紙幅の都合上、図１７では省略されているが、ステップＳ５０８の後でサーバ３１０ｂは、いずれかの端末３７０（通常は、アラーム指示の送信先の端末３７０）を介してセンサログを受信することがある。その場合、サーバ３１０ｂは図９のステップＳ１２７〜Ｓ１２９と同様の処理を行う。
【０３４６】
以下では、図９と異なるステップＳ５０１〜５０８でのサーバ３１０ｂの動作について詳しく説明する。
ステップＳ５０１では、端末３７０からのＧＰＳログを通信部３２７が受信する。受信されたＧＰＳログは、ＧＰＳログ処理部３１３の制御のもと、ＧＰＳログＤＢ３１１に格納される。
【０３４７】
次に、ステップＳ５０２でアラーム決定部３３４は、アラーム指示を送る時刻か否かを判断するために、図１５の休憩時間ＤＢ３３１を参照し、現在が休憩時間か否かを判断する。現在がまだ休憩時間でなければ、サーバ３１０ｂは再度ＧＰＳログの受信待ち状態に戻る。図１７の例は、ステップＳ５０２でのチェックの結果、現在が休憩時間であることが判明した場合の動作シーケンスである。
【０３４８】
現在が休憩時間である場合、サーバ３１０ｂは、各端末３７０について以下のステップＳ５０３〜Ｓ５０６の処理を行う。なお、ステップＳ５０３〜Ｓ５０４の処理は各センサユニット３５０について行われるが、紙幅の都合上、図１７ではセンサユニット３５０ごとのループを示すループ端が省略されている。
【０３４９】
ステップＳ５０３で端末・センサ間距離計算部３２４は、ＧＰＳログＤＢ３１１とセンサ位置ＤＢ３１７を参照して、処理対象として注目している端末３７０とセンサユニット３５０の間の距離を計算する。なお、ステップＳ５０３の動作は、図９のステップＳ１２３の動作と似ているが、計算に用いるＧＰＳログの範囲が異なる。
【０３５０】
そして、次のステップＳ５０４で距離比較部３２５は、端末・センサ間距離計算部３２４が計算した距離と、アラーム距離決定部３２３がステップＳ１２１で決定したアラーム距離を比較する。比較結果は、処理対象として注目している端末３７０とセンサユニット３５０の組み合わせに関して、「当該端末３７０に当該センサユニット３５０についてのアラーム指示を与えるか否か」という暫定的な判定結果を表す。
【０３５１】
また、次のステップＳ５０５で圃場特定部３３３は、処理対象として注目している端末３７０が休憩時間の直前の時間帯（例えば、休憩時間が始まる３０分前から休憩時間の開始時刻までの時間帯）に存在していた圃場を特定する。圃場特定部３３３は、ＧＰＳログＤＢ３１１と圃場形状ＤＢ３２９に基づいて、圃場を特定することができる。
【０３５２】
そして、次のステップＳ５０６でアラーム決定部３３４は、ステップＳ５０４での暫定的な判定について再判定を行う。すなわち、アラーム決定部３３４は、圃場のスケジュールに基づき、端末３７０へのアラーム指示の要否を再判定する。
【０３５３】
具体的には、アラーム決定部３３４は、まず、図１５のスケジュールＤＢ３３０を参照することで、ステップＳ５０５で特定された圃場での作業スケジュールを認識する。そして、アラーム決定部３３４は、認識した作業スケジュールと、スケジュール単位定義ＤＢ３３２で定義される規則と、前回のデータ収集からの経過時間に基づいて、アラーム指示の送信を延期するか否かを判断する。
【０３５４】
アラーム指示の送信を延期するということは、ステップＳ５０４で暫定的に決められたアラーム指示をキャンセルするということであり、「今日はアラーム指示は不要である」と決定することである。つまり、アラーム決定部３３４は、アラーム指示の送信を延期するか否かを判断することで、アラーム指示の要否を判定しなおす。
【０３５５】
そして、以上のステップＳ５０３〜Ｓ５０６の処理が各端末３７０について行われた後、ステップＳ５０７では、アラーム決定部３３４が、アラーム指示を送信する送信先の端末３７０を決定する。ステップＳ５０７の決定は、ステップＳ５０６での再判定結果に基づく。
【０３５６】
さらに、次のステップＳ５０８でアラーム決定部３３４は、ステップＳ５０７で決定した端末３７０に対して、通信部３２７を介してアラーム指示を送信する。なお、以上のステップＳ５０１〜５０８の詳細は、図１８〜２０のフローチャートとともに後述する。また、送信されたアラーム指示は、端末３７０においてステップＳ１１３で受信される。
【０３５７】
図１８は、第２実施形態のアラーム関連処理のフローチャートである。
ＧＰＳログ処理部３１３は、いずれかの端末３７０から通信部３２７を介してＧＰＳログを受信するまで、ステップＳ６０１で待機する。そして、ＧＰＳログが受信されると、処理はステップＳ６０２に移行する。
【０３５８】
すると、ステップＳ６０２でＧＰＳログ処理部３１３は、ＧＰＳログを端末３７０の端末ＩＤおよび受信時刻と対応づけてＧＰＳログＤＢ３１１に格納し、その後、処理はステップＳ６０３に移行する。
【０３５９】
ステップＳ６０３でアラーム決定部３３４は、休憩時間ＤＢ３３１を参照して、現在が休憩時間か否かを判断する。
例えば、図１５の休憩時間ＤＢ３３１の例では、１０時から１０時１５分と、１２時から１３時と、１５時から１５時１５分が休憩時間である。よって、例えば現在時刻が９時や１４時などであれば、アラーム決定部３３４は「現在は休憩時間中ではない」と判断し、処理はステップＳ６０１に戻る。つまり、第２実施形態では、休憩時間外では、ＧＰＳログが単にＧＰＳログＤＢ３１１に蓄積されるだけであり、ＧＰＳログの受信を契機にアラーム指示が送信されるわけではない。
【０３６０】
逆に、例えば現在時刻が１０時や１２時３分などであれば、アラーム決定部３３４は「現在は休憩時間中である」と判断し、処理はステップＳ６０４に移行する。第２実施形態では、休憩時間に入ると、サーバ３１０ｂがステップＳ６０４〜Ｓ６１６の処理を行い、必要に応じてアラーム指示を送信する。もちろん、実施形態によっては、ステップＳ６０１〜Ｓ６０２でのＧＰＳログの蓄積とは独立した処理として、休憩時間の開始時刻になるとサーバ３１０ｂがステップＳ６０４〜Ｓ６１６の処理を行ってもよい。
【０３６１】
さて、ステップＳ６０４で端末・センサ間距離計算部３２４は、休憩開始時刻よりも所定の時間だけ遡った時刻以降のデータをＧＰＳログＤＢ３１１から抽出する。ここでの「所定の時間」は、実施形態に応じて適宜定められていてよい。
【０３６２】
以下では説明の便宜上、上記「所定の時間」を３０分とする。また、以下では説明の便宜上、ステップＳ６０３において「現在は１２時から１３時の休憩時間中である」と判断されたものとする。つまり、ステップＳ６０４では、端末・センサ間距離計算部３２４が１１時３０分以降のエントリをＧＰＳログＤＢ３１１から抽出するものとする。
【０３６３】
次に、ステップＳ６０５でサーバ３１０ｂは、端末３７０についてのループ変数ｊを１に初期化する。
そして、次のステップＳ６０６で端末・センサ間距離計算部３２４は、ステップＳ６０４で抽出したデータの中からさらに、ｊ番目の端末３７０のデータのみを抽出する。
【０３６４】
例えば、第１実施形態と同様に、端末３７０は、１分に１回ＧＰＳ情報を取得し、１５分に１回ＧＰＳログを送信してもよい。仮に、ｊ番目の端末３７０が１１時３５分と１１時５０分にＧＰＳログをサーバ３１０ｂに送信し、現在時刻が１２時１分であるとすれば、ステップＳ６０６では、１１時３０分から１１時５０分までのＧＰＳログのエントリが抽出される。
【０３６５】
そして、次のステップＳ６０７では、ｊ番目の端末３７０について、第１実施形態と同様にして、各センサユニット３５０についてフラグｆｌａｇｉ，ｊの値が求められる。なお、データ収集システム３００ｂ内のセンサユニット３５０の総数をＵとすると、１≦ｉ≦Ｕである。つまり、ステップＳ６０７では以下の処理が行われる。
【０３６６】
まず、図１２のステップＳ４０２と同様に、端末・センサ間距離計算部３２４が、適宜のウィンドウ間隔Ｗを用いて、ステップＳ６０６で抽出したエントリをいくつかのブロックに分割する。ステップＳ６０７で得られるブロックの数は、ステップＳ４０２でのブロック数とは異なるかもしれないが、以下では説明の便宜上、ステップＳ６０７でＮ個のブロックが得られたとする。なお、個々の端末３７０がＧＰＳログを送信するタイミングによっては、ブロックの個数Ｎが端末３７０ごとに異なる場合もあり得る。
【０３６７】
さて、その後、端末・センサ間距離計算部３２４と距離比較部３２５とアラーム決定部３３４が協働し、第１実施形態の図１２のステップＳ４０３〜Ｓ４１４と同様にして、フラグｆｌａｇｉ，ｊの値を求める。つまり、ｎ番目（１≦ｎ≦Ｎ）のブロックにおける、ｊ番目の端末とｉ番目のセンサユニット３５０との間の距離ｄｉｓｔｉ，ｊ，ｎと、ｉ番目のセンサユニット３５０についてのアラーム距離ａｌａｒｍｉに基づいて、フラグｆｌａｇｉ，ｊの値が求められる。なお、図１７のステップＳ５０３とＳ５０４は、ステップＳ６０７に含まれる。
【０３６８】
フラグｆｌａｇｉ，ｊの値がｔｒｕｅの場合は、すなわち、「ｉ番目のセンサユニット３５０についてのアラーム指示を出す対象の端末３７０の候補として、ｊ番目の端末３７０を、アラーム決定部３３４が暫定的に選んだ」という場合である。逆に、フラグｆｌａｇｉ，ｊの値がｆａｌｓｅの場合は、「ｉ番目のセンサユニット３５０についてのアラーム指示を出す対象の端末３７０の候補として、アラーム決定部３３４はｊ番目の端末３７０を選ばなかった」という場合である。
【０３６９】
以上のようにしてステップＳ６０７で得られたフラグｆｌａｇｉ，ｊの値は、第２実施形態では暫定的な値である。より具体的には、フラグｆｌａｇｉ，ｊの値がｔｒｕｅの場合、値がｆａｌｓｅに変更される余地がある。
【０３７０】
つまり、フラグｆｌａｇｉ，ｊの値は、次のステップＳ６０８で書き換えられることがある。ステップＳ６０８の圃場特定・アラーム再判定処理の詳細は図１９とともに後述するが、ステップＳ６０８は図１７のステップＳ５０５〜Ｓ５０６に対応する。そして、ステップＳ６０８での再判定により、具体的には、フラグｆｌａｇｉ，ｊの値が場合に応じて書き換えられる。
【０３７１】
つまり、フラグｆｌａｇｉ，ｊの値は、「今日、ｉ番目のセンサユニット３５０についてのアラーム指示をｊ番目の端末３７０に送信するか否か」を示す。よって、ステップＳ６０８の再判定により、「ｉ番目のセンサユニット３５０についてのアラーム指示の送信が後日に延期される」と決まる場合は、ステップＳ６０８でフラグｆｌａｇｉ，ｊは、「送信しない」と示す値（つまりｆａｌｓｅ）に書き換えられる。
【０３７２】
その後、ステップＳ６０９でサーバ３１０ｂは、すべての端末３７０について注目し終えたか否かを判断する。つまり、サーバ３１０ｂは、端末３７０についてのループ変数ｊの値がデータ収集システム３００ｂ内の端末３７０の総数Ｔに達したか否かを判断する。
【０３７３】
そして、ｊ＝Ｔの場合、処理はステップＳ６１１に移行する。他方、ｊ≠Ｔの場合（より具体的にはｊ＜Ｔの場合）は、未注目の端末３７０が残っているので、処理はステップＳ６１０に移行する。
ステップＳ６１０でサーバ３１０ｂは、端末３７０についてのループ変数ｊをインクリメントする。その後、処理はステップＳ６０６に戻る。
【０３７４】
さて、ステップＳ６１１の処理が実行されるのは、データ収集システム３００ｂ内のすべてのセンサユニット３５０と端末３７０の組み合わせについて、フラグｆｌａｇｉ，ｊが設定された後である。そして、ステップＳ６１１の時点でのフラグｆｌａｇｉ，ｊの値は、「アラーム指示の送信を後日に延期するか否か」についてのアラーム決定部３３４の再判定結果を反映している。そこで、ステップＳ６１１〜Ｓ６１６では、再判定結果を反映したフラグｆｌａｇｉ，ｊの値を参照して適宜アラーム指示を送信するための処理が行われる。
【０３７５】
具体的には、まずステップＳ６１１でサーバ３１０ｂが、センサユニット３５０についてのループ変数ｉを１に初期化する。
そして、次のステップＳ６１２でアラーム決定部３３４が、ｉ番目のセンサユニット３５０に対応するフラグｆｌａｇｉ，ｊの値がｔｒｕｅの端末３７０のリストを取得する。ステップＳ６１２で取得されるリストは、具体的には端末ＩＤのリストであり、式（５）の集合ｔａｒｇｅｔｊを表すリストである。ただし、第２実施形態では、式（５）のフラグｆｌａｇｉ，ｊは、再判定結果を反映している点で第１実施形態のフラグｆｌａｇｉ，ｊと異なる。
【０３７６】
そして、次のステップＳ６１３でアラーム決定部３３４は、ｉ番目のセンサユニット３５０との距離が最短の端末３７０を、ステップＳ６１２で得たリストの中から選択する。
なお、例えばｊ番目の端末３７０の端末ＩＤがステップＳ６１２で得られたリスト中に存在する場合、ステップＳ６１３でｊ番目の端末３７０に関して参照される距離として、例えば以下のようなものが利用可能である。
【０３７７】
・ステップＳ６０７でフラグｆｌａｇｉ，ｊの値を暫定的に求めるのに用いられた、Ｎ個のブロックに対応するＮ個の距離ｄｉｓｔｉ，ｊ，１〜ｄｉｓｔｉ，ｊ，Ｎの、平均値または最小値が使われてもよい。すると、リスト中の各端末３７０の休憩時間の直近３０分における動きが、ステップＳ６１３の選択に反映される。
・より直近の端末３７０の位置を重視するならば、最後のブロック（つまりＮ番目のブロック）から得られた距離ｄｉｓｔｉ，ｊ，Ｎが使われてもよい。
【０３７８】
そして、次のステップＳ６１４でアラーム決定部３３４は、ステップＳ６１３で選択した端末３７０に、通信部３２７を介して、ｉ番目のセンサユニット３５０に関するアラーム指示を送信する。なお、ステップＳ６１２で得られたリストが空リストの場合は、アラーム決定部３３４はステップＳ６１３で何も選択しないので、ステップＳ６１４でもアラーム指示の送信は行われない。
【０３７９】
その後、ステップＳ６１５でサーバ３１０ｂは、センサユニット３５０についてのループ変数ｉの値がデータ収集システム３００ｂ内のセンサユニット３５０の総数Ｕに達したか否かを判断する。
【０３８０】
そして、ｉ＝Ｕの場合、今回の休憩時間の開始に合わせて送信する対象のアラーム指示はすべて送信し終わっているので、処理がステップＳ６０１に戻る。逆に、ｉ≠Ｕの場合（より具体的にはｉ＜Ｕの場合）は、未注目のセンサユニット３５０が残っているので、処理はステップＳ６１６に移行する。
【０３８１】
そして、ステップＳ６１６でサーバ３１０ｂは、センサユニット３５０についてのループ変数ｉをインクリメントする。その後、処理はステップＳ６１２に戻る。
さて、続いて図１９を参照して、上記のステップＳ６０８の圃場特定・アラーム再判定処理について説明する。図１８から理解されるとおり、圃場特定・アラーム再判定処理は、ｊ番目の端末３７０（１≦ｊ≦Ｔ）について呼び出される。
【０３８２】
ステップＳ７０１で圃場特定部３３３は、圃場ＩＤリストを空に初期化する。
そして、次にステップＳ７０２で圃場特定部３３３は、引数で指定されたｊ番目の端末３７０についてステップＳ６０６で抽出されたＧＰＳログの各ブロックでの平均座標を取得する。
【０３８３】
なお、ステップＳ７０２で取得する対象の平均座標（すなわち、式（２）のａｖｒｊ，ｎ）は、図１８のステップＳ６０７でフラグｆｌａｇｉ，ｊの値を暫定的に求めるために、既に端末・センサ間距離計算部３２４が計算済みである。例えば、端末・センサ間距離計算部３２４は、ステップＳ６０７で得た各端末３７０の各ブロックでの平均座標ａｖｒｊ，ｎの値を、圃場特定部３３３からもアクセス可能なＲＡＭ４０２上の領域に格納しておいてもよい。すると、ステップＳ７０２で圃場特定部３３３は、単にＲＡＭ４０２からｊ番目の端末３７０の各ブロックについての平均座標ａｖｒｊ，ｎの値を読み出すだけでよい。もちろん、圃場特定部３３３は、端末・センサ間距離計算部３２４と同様の方法にて、ステップＳ７０２で改めて、ｊ番目の端末３７０の各ブロックでの平均座標ａｖｒｊ，ｎを計算してもよい。
【０３８４】
いずれにせよ、圃場特定部３３３は、ｊ番目の端末３７０に関して、ブロックの個数Ｎと同数の平均座標ａｖｒｊ，１〜ａｖｒｊ，Ｎを取得する。そして、圃場特定部３３３は、取得した各平均座標ａｖｒｊ，ｎ（１≦ｎ≦Ｎ）について、圃場形状ＤＢ３２９に形状が登録されている圃場の中から、当該平均座標ａｖｒｊ，ｎを含む圃場を探す。そして、もし圃場が見つかれば、圃場特定部３３３は、見つかった圃場の圃場ＩＤを、ステップＳ７０１で初期化した圃場ＩＤリストに追加する。
【０３８５】
ここで、説明の便宜上、圃場形状ＤＢ３２９には、Ｈ箇所の圃場の形状が登録されているものとする。すると、ｎ番目のブロックの平均座標ａｖｒｊ，ｎを含む圃場を探して圃場ＩＤリストを更新する上記の処理は、具体的には例えば以下のような処理である。
【０３８６】
圃場特定部３３３は、１番目の圃場から順に注目していく。ここで、圃場特定部３３３が処理対象として注目しているのがｈ番目の圃場であるとする（１≦ｈ≦Ｈ）。
このとき、圃場特定部３３３は、ｈ番目の圃場の形状を近似する多角形のすべての頂点の座標（つまり緯度と経度）を、圃場形状ＤＢ３２９から読み出す。そして、「与えられた点が多角形の内部または辺上に位置するか否か」を判定するための公知のアルゴリズムにしたがって、圃場特定部３３３は、「平均座標ａｖｒｊ，ｎがｈ番目の圃場の内部または境界線上に位置するか否か」を判定する。
【０３８７】
もし、平均座標ａｖｒｊ，ｎがｈ番目の圃場の内部または境界線上に位置していれば、圃場特定部３３３は、ｈ番目の圃場の圃場ＩＤを、圃場ＩＤリストに追加する。なお、圃場特定部３３３は、ｎ番目のブロックの平均座標ａｖｒｊ，ｎに関しては、もう残りの圃場に注目する必要はない。
【０３８８】
逆に、平均座標ａｖｒｊ，ｎが、ｈ番目の圃場の外部に位置していれば、圃場特定部３３３は、未注目の圃場が残っているか否か（つまりｈ＜Ｈか否か）を判断する。そして、もしｈ＜Ｈならば、次の圃場に注目して、ｎ番目のブロックの平均座標ａｖｒｊ，ｎに関する上記の処理を繰り返す。逆に、既にＨ箇所すべての圃場に注目し終えていれば、ｎ番目のブロックの平均座標ａｖｒｊ，ｎは、どの圃場から見ても外部に位置しているので、ｎ番目のブロックに関する処理は終了する。
【０３８９】
以上のようにして、ステップＳ７０２で圃場特定部３３３は、各平均座標ａｖｒｊ，ｎ（１≦ｎ≦Ｎ）について、当該平均座標ａｖｒｊ，ｎを含む圃場を探し、見つかった圃場の圃場ＩＤを圃場ＩＤリストに追加する。
【０３９０】
例えば、ｊ番目の端末３７０が、休憩時間の開始３０分前からずっと１番目の圃場の中に位置していたとする。すると、圃場ＩＤリストには、１番目の圃場の圃場ＩＤのみが含まれる。
【０３９１】
あるいは、ｊ番目の端末３７０が、休憩時間の開始直前の３０分間のうち、最初の１０分間は１番目の圃場に位置しており、その後移動して、残りの時間はずっと２番目の圃場に位置していたとする。すると、圃場ＩＤリストには、１番目と２番目の圃場の圃場ＩＤが含まれる。
【０３９２】
以上のようにして、ｊ番目の端末３７０が休憩時間の開始直前の３０分間に位置していたことのある圃場が判明すると、次に、ステップＳ７０３でアラーム決定部３３４は、以下の処理を行う。すなわち、アラーム決定部３３４は、圃場ＩＤリストに圃場ＩＤが含まれる圃場に設置されたすべてのセンサユニット３５０のリストを求める。
【０３９３】
リストは、具体的にはセンサユニットＩＤのリストとして表される。また、アラーム決定部３３４は、具体的には、圃場ＩＤリストに含まれる圃場ＩＤを検索キーにして図１５の収集日ＤＢ３２８を検索することで、当該圃場ＩＤで識別される圃場に設置されたセンサユニット３５０のセンサユニットＩＤを取得することができる。
【０３９４】
例えば、ステップＳ７０２で得られた圃場ＩＤリストに、「０００５」と「０００７」という圃場ＩＤのみが含まれているとする。また、圃場ＩＤが「０００５」の圃場にはセンサユニットＩＤが「０００１」と「０００２」のセンサユニット３５０が設置されており、圃場ＩＤが「０００７」の圃場にはセンサユニットＩＤが「００１０」のセンサユニット３５０が設置されているとする。すると、アラーム決定部３３４は、ステップＳ７０３で、「０００１」と「０００２」と「００１０」という３つのセンサユニットＩＤを要素として含むリストを取得する。
【０３９５】
そして、次のステップＳ７０４でアラーム決定部３３４は、ステップＳ７０３で得たリストの各要素に順に注目するためのループ変数ｂを１に初期化する。
また、次のステップＳ７０５でアラーム決定部３３４は、図１５の収集日ＤＢ３２８を参照して、ステップＳ７０３で得たリスト内のｂ番目のセンサユニットＩＤに対応してアラーム予定日が設定されているか否かを判断する。図１５に示すように、収集日ＤＢ３２８では、あるセンサユニットＩＤに対してはアラーム予定日が設定されているかもしれないが、別のあるセンサユニットＩＤに対してはアラーム予定日が設定されていないかもしれない。そこで、アラーム決定部３３４は、ｂ番目のセンサユニットＩＤに対応するアラーム予定日の有無を、収集日ＤＢ３２８を参照して判断する。
【０３９６】
もし、ｂ番目のセンサユニットＩＤに対応するアラーム予定日があれば、処理はステップＳ７０６に移行する。つまり、過去にアラーム決定部３３４が後述の図２０の処理を行うことで設定されたアラーム予定日が見つかれば、処理はステップＳ７０６に移行する。
【０３９７】
例えば、図１６のスケジュール例５０２の「作業１日目」に、図２０の処理が行われて、「作業最終日」がアラーム予定日として設定されたとする。この場合、「作業２日目」に図１９の処理が呼び出されると、ステップＳ７０５で、設定済みのアラーム予定日が見つかる。
【０３９８】
逆に、ｂ番目のセンサユニットＩＤに対応するアラーム予定日がなければ、処理はステップＳ７０５からステップＳ７０８へと移行する。例えば、図１６のスケジュール例５０１の「作業１日目」に初めて図１９の処理が呼び出された場合には、アラーム予定日がまだ設定されていない。
【０３９９】
さて、ステップＳ７０６が実行されるのは、上記のとおり、リスト中のｂ番目のセンサユニット３５０に関して、アラーム予定日が設定されている場合である。この場合、アラーム決定部３３４は、設定されているアラーム予定日が今日またはそれより前の日付であるか否かを判断する。
【０４００】
そして、設定されているアラーム予定日が今日またはそれより前の日付である場合、リスト中のｂ番目のセンサユニット３５０に関して、アラーム指示の送信を延期する必要はない。よって、設定されているアラーム予定日が今日またはそれより前の日付である場合は、フラグの暫定的な値を何も変えずに、ただ処理がステップＳ７１０へと移行する。
【０４０１】
つまり、リスト中のｂ番目のセンサユニット３５０と、引数で指定されたｊ番目の端末３７０の組み合わせに対応するフラグの暫定的な値がｔｒｕｅであれば、フラグの値はｔｒｕｅのままでよい。
【０４０２】
逆に、フラグの暫定的な値がｆａｌｓｅであれば、そもそもリスト中のｂ番目のセンサユニット３５０についてのアラーム距離よりも遠くにｊ番目の端末３７０がある。つまり、ｊ番目の端末３７０はそもそも、リスト中のｂ番目のセンサユニット３５０に関するアラーム指示の送信対象ではないので、フラグの暫定的な値を書き換える必要がない。
【０４０３】
よって、設定されているアラーム予定日が今日またはそれより前の日付である場合、フラグの暫定的な値が何であれ、処理はステップＳ７１０へと移行する。
逆に、既に設定されているアラーム予定日が今日よりも後の日付である場合は、リスト中のｂ番目のセンサユニット３５０に関するアラーム指示の送信は、アラーム予定日まで延期可能である。つまり、リスト中のｂ番目のセンサユニット３５０に関するアラーム指示は、今日送信する必要がない。そこで、今日の送信をキャンセルするために、処理はステップＳ７０７に移行する。
【０４０４】
そして、ステップＳ７０７でアラーム決定部３３４は、リスト中のｂ番目のセンサユニット３５０に関するアラーム指示の今日の送信を強制的にキャンセルする。つまり、アラーム決定部３３４は、リスト中のｂ番目のセンサユニット３５０と、引数で指定されたｊ番目のセンサユニット３５０の組み合わせに対応するフラグの値を、暫定的な値がｔｒｕｅであるかｆａｌｓｅであるかによらず、強制的にｆａｌｓｅに設定する。そして、処理はステップＳ７１０に移行する。
【０４０５】
さて、ステップＳ７０８が実行されるのは、リスト中のｂ番目のセンサユニット３５０に関してアラーム予定日が設定されていない場合である。この場合、「アラーム予定日を新たに設定することができるか否か」、すなわち、「リスト中のｂ番目のセンサユニット３５０に関してアラーム指示の送信を延期する余地があるか否か」をアラーム決定部３３４が判断する。
【０４０６】
具体的には、ステップＳ７０８でアラーム決定部３３４は、リスト中のｂ番目のセンサユニット３５０が設置されている圃場について、「今日または明日以降のスケジュールがスケジュールＤＢ３３０に登録されているか否か」を判断する。なお、アラーム決定部３３４は、収集日ＤＢ３２８を参照することで、リスト中のｂ番目のセンサユニット３５０が設置されている圃場の圃場ＩＤを認識することができる。あるいは、アラーム決定部３３４は、ステップＳ７０３の処理を行ったときに、圃場ＩＤとセンサユニットＩＤの対応関係をＲＡＭ４０２上に記憶しておいてもよい。
【０４０７】
もし、リスト中のｂ番目のセンサユニット３５０が設置されている圃場について、今日または明日以降、スケジュールＤＢ３３０に１つもスケジュールが登録されていなければ、処理はステップＳ７１０に移行する。なぜなら、スケジュールが登録されていなければ、リスト中のｂ番目のセンサユニット３５０についてのアラーム指示の送信を延期する余地はないからである。つまり、リスト中のｂ番目のセンサユニット３５０と、引数で指定されたｊ番目の端末３７０の組み合わせに対して暫定的に決められたフラグの値を書き換える必要がないからである。
【０４０８】
逆に、リスト中のｂ番目のセンサユニット３５０が設置されている圃場について、今日または明日以降、スケジュールＤＢ３３０に１つ以上スケジュールが登録されていれば、場合によっては、アラーム指示の送信を延期することが可能である。つまり、スケジュールの分布と前回の収集日からの経過時間によっては、リスト中のｂ番目のセンサユニット３５０に関するアラーム指示の送信を、明日以降に延期することが可能な場合がある。そこで、延期の可能性を検討し、可能ならばアラーム予定日を設定してアラーム指示の送信を延期するために、処理はステップＳ７０９に移行する。
【０４０９】
そして、ステップＳ７０９のスケジュール確認処理では、リスト中のｂ番目のセンサユニット３５０に関するアラーム指示の送信の延期の可能性が検討され、可能ならばアラーム予定日が新たに設定される。ステップＳ７０９の詳細は図２０とともに後述する。また、ステップＳ７０９の実行後、処理はステップＳ７１０に移行する。
【０４１０】
さて、ステップＳ７１０は、リスト中のｂ番目のセンサユニット３５０と、引数で指定されたｊ番目の端末３７０の組み合わせに関して、フラグの値を書き換えた後、またはフラグの値を書き換える必要がないと判明した後に、実行される。すなわち、フラグの値が確定すると、ステップＳ７１０が実行される。
【０４１１】
ステップＳ７１０でアラーム決定部３３４は、ステップＳ７０３で求めたリスト内の全センサユニット３５０に注目し終えたか否かを判断する。そして、未注目のセンサユニット３５０が残っている場合は、処理がステップＳ７１１に移行する。逆に、リスト内の全センサユニット３５０に、アラーム決定部３３４が既に注目し終えた場合は、図１９の圃場特定・アラーム再判定処理（つまり図１８のステップＳ６０８）も終了する。
【０４１２】
ステップＳ７１１でアラーム決定部３３４は、センサユニットＩＤのリスト内の要素に関するループ変数ｂをインクリメントする。そして、処理はステップＳ７０５に戻る。
さて、続いて図２０を参照して、上記のステップＳ７０９のスケジュール確認処理について説明する。図１９から理解されるとおり、スケジュール確認処理は、確認の対象として指定された特定のセンサユニット３５０と端末３７０の組み合わせに対して呼び出される。つまり、具体的には、図２０のスケジュール確認処理は、センサユニットＩＤと端末ＩＤを引数として呼び出される。
【０４１３】
ステップＳ８０１でアラーム決定部３３４は、スケジュールの初日として、今日に注目する。以下ではアラーム決定部３３４が注目している日付を「注目日」という。
そして、次のステップＳ８０２でアラーム決定部３３４は、図２０の処理を開始してから今までに数えた作業なし期間の回数が２回未満か否かを判断する。ステップＳ８０２の判断が最初に実行される時点では、今までに数えた作業なし期間の回数は当然０回である。
【０４１４】
なお、ステップＳ８０２における「２回」という閾値は、図１５のスケジュール単位定義ＤＢ３３２の「作業なし期間の最大回数」として定義されている値であり、実施形態に応じて適宜その他の値が用いられてもよい。
【０４１５】
スケジュール単位定義ＤＢ３３２や図１６に関して説明したごとく、作業のひとかたまりの単位は、３日以内の作業なし期間を２回までははさんでいてもよい。しかし、３回目の作業なし期間のところで、作業のひとかたまりの単位は途切れる。
【０４１６】
よって、今までに数えた作業なし期間の回数が既に２回に達しているならば、注目日から始まって連続する１日以上の作業予定日の最後の日で、作業のひとかたまりの単位は終了する。逆に、今までに数えた作業なし期間の回数が２回未満ならば、注目日から始まって連続する１日以上の作業予定日の最後の日よりもさらに後の日付までを、作業のひとかたまりの単位として見なせる可能性がある。
【０４１７】
そこで、今までに数えた作業なし期間の回数が既に２回に達していれば、処理はステップＳ８０６に移行する。逆に、今までに数えた作業なし期間の回数が２回未満ならば、処理はステップＳ８０３に移行する。
【０４１８】
ステップＳ８０３でアラーム決定部３３４は、引数として指定されたセンサユニットＩＤのセンサユニット３５０が存在する圃場における、注目日から始まって連続する作業予定日の後の、次の作業予定日までの作業なし日数を数える。なお、注目日から連続する作業予定日は、１日だけの場合もあるし、２日以上の場合もある。
【０４１９】
例えば、図１６のスケジュール例５０３の「作業１日目」が注目日の場合、注目日から始まって連続する作業予定日は３日であり、ステップＳ８０３でアラーム決定部３３４が数えた結果は２日である。
【０４２０】
ステップＳ８０３の処理は、具体的には例えば次のような処理である。アラーム決定部３３４は、収集日ＤＢ３２８を参照することで、引数として指定されたセンサユニットＩＤのセンサユニット３５０が存在する圃場の圃場ＩＤを特定する。そして、アラーム決定部３３４は、特定した圃場ＩＤを検索キーにしてスケジュールＤＢ３３０を検索し、注目日から連続する作業予定日の後の次の作業予定日までの作業なし日数を数える。
【０４２１】
なお、図２０の処理は、図１９のステップＳ７０８で「今日または明日以降のスケジュールがスケジュールＤＢ３３０に登録されている」と確認されたときに実行される。そして、説明の簡単化のため、スケジュールＤＢ３３０が正しい（すなわち、スケジュールどおりにユーザが作業を行う）と仮定するならば、少なくとも今日は何らかの作業が予定されているはずである。なぜなら、以下のように考えられるからである。
【０４２２】
・今日、ある圃場で作業が予定されており、その予定にしたがってユーザが当該圃場にいたからこそ、ユーザが携帯する端末３７０が当該圃場に存在していることが図１９のステップＳ７０２で検出された。
【０４２３】
・その結果、当該圃場に設置されたセンサユニット３５０と、上記ユーザの携帯する端末３７０の組み合わせに対して、図１９のステップＳ７０９から、図２０の処理が呼び出された。
【０４２４】
・よって、図２０の処理が呼び出される場合、引数として指定されたセンサユニットＩＤのセンサユニット３５０が存在する圃場に関して、少なくとも今日は何らかの作業が予定されている。
【０４２５】
したがって、ステップＳ８０３では、引数として指定されたセンサユニットＩＤのセンサユニット３５０が存在する圃場において、注目日から始まる１日以上の連続した作業予定日が存在する。
【０４２６】
ただし、注目日から始まる１日以上の連続した作業予定日の後の、次の作業予定日は、あるとは限らない。例えば、図１６のスケジュール例５０２において、注目日が「作業１日目」の場合、注目日から始まる１日以上の連続した作業予定日は、「作業１日目」から「作業最終日」までの３日間である。しかし、当該３日間の後には何の予定もまだないので、「次の作業予定日」は見つからない。このように、次の作業予定日がない場合、アラーム決定部３３４は、ステップＳ８０３において、「次の作業予定日までの作業なし日数は、無限大である」と認識する。
【０４２７】
以上のようにしてステップＳ８０３で作業なし日数を数えた後、アラーム決定部３３４は、ステップＳ８０４において、作業なし日数が３日より多いか否かを判断する。なお、ステップＳ８０４における「３日」という閾値は、図１５のスケジュール単位定義ＤＢ３３２の「作業なし期間の最大長さ」として定義されている値であり、実施形態に応じて適宜その他の値が用いられてもよい。
【０４２８】
スケジュール単位定義ＤＢ３３２や図１６に関して説明したごとく、作業なし日数が３日より多ければ、そこで作業のひとかたまりの単位は途切れる。そこで、処理はステップＳ８０６に移行する。
【０４２９】
逆に、作業なし日数が３日以内であれば、作業のひとかたまりの単位がまだ終わっていない可能性がある。そこで、処理はステップＳ８０５に移行する。
ステップＳ８０５でアラーム決定部３３４は、ステップＳ８０３で日数を数えた作業なし日をはさんだ、次の作業予定日に注目する。例えば、図１６のスケジュール例５０３において、現在の注目日が「作業１日目」の場合、ステップＳ８０５で「作業再開１日目」が新たな注目日として注目される。そして、アラーム決定部３３４が注目日を更新すると、処理はステップＳ８０２に戻る。
【０４３０】
ステップＳ８０６でアラーム決定部３３４は、注目日から連続する１日以上の作業予定日の最後の日を、ひとかたまりのスケジュールの最終日として決定する。
例えば、ステップＳ８０５に関して例示したように、図１６のスケジュール例５０３の「作業再開１日目」が新たな注目日となった場合は、その後のステップＳ８０３で数えられる作業なし日数は無限大である。よって、処理はステップＳ８０４からステップＳ８０６へと進む。そして、ステップＳ８０６でアラーム決定部３３４は、注目日である「作業再開１日目」から連続する作業予定日の最後の日（つまり、図１６に示す「再開後作業最終日」）を、ひとかたまりのスケジュールの最終日として決定する。
【０４３１】
なお、スケジュールＤＢ３３０に登録されているスケジュールによっては、ステップＳ８０６で決定される最終日が、今日と一致する場合もある（例えば、今日１日だけ作業が予定されており、明日以降の予定がまったくない場合など）。
【０４３２】
また、次のステップＳ８０７でアラーム決定部３３４は、ステップＳ８０１で注目した初日（すなわち今日）における、前回のデータ収集からの経過日数と閾値を比較する。
より具体的には、アラーム決定部３３４は、引数で指定されるセンサユニットＩＤを含むエントリを図１５の収集日ＤＢ３２８で検索し、見つかったエントリの収集日を読み取る。そして、アラーム決定部３３４は、図２０の処理を行っている今日の日付から、読み取った収集日を引くことで、経過日数を計算する。
【０４３３】
また、ステップＳ８０７で参照される閾値は、実施形態に応じて適宜定められる。例えば、「１０日」などと固定の閾値が使われてもよい。あるいは、ステップＳ８０７で参照される閾値は、引数で指定されるセンサユニットＩＤに依存する値であってもよい。
【０４３４】
例えば、アラーム決定部３３４は、引数で指定されたセンサユニットＩＤと対応づけられているアラーム条件ＩＤを図６のセンサユニット別アラーム条件ＤＢ３１９から読み取る。そして、アラーム決定部３３４は、読み取ったアラーム条件ＩＤに対応するエントリをアラーム条件ＤＢ３２０で検索する。そして、アラーム決定部３３４は、見つかったエントリのアラーム条件で使われる境界値のうち、最大のものを、ステップＳ８０７での閾値として利用してもよい。
【０４３５】
例えば、図６のセンサユニット別アラーム条件ＤＢ３１９の例では、「０００２」というセンサユニットＩＤに対応するアラーム条件ＩＤは「０１」である。そして、「０１」というアラーム条件ＩＤで識別されるアラーム条件で使われる最大の境界値は、図６のアラーム条件ＤＢ３２０の例では、「条件４」フィールドに設定されている「１０日」という値である。よって、「０００２」というセンサユニットＩＤが図２０の処理の引数として与えられた場合、アラーム決定部３３４は、ステップＳ８０７での閾値として「１０日」を利用してもよい。
【０４３６】
もちろん、実施形態によっては、アラーム決定部３３４は、上記のようにして見つかったアラーム条件で使われる境界値のうち２番目に大きなものを使ってもよいし、あるいは、最大の境界値から所定値（例えば１日）を引いた値を使ってもよい。
【０４３７】
なお、具体的にどのような閾値が利用されるにしろ、初日における経過日数が閾値以上のとき、図２０のスケジュール確認処理は終了する。
つまり、初日における経過日数が閾値以上のとき、アラーム決定部３３４は「初日の時点で既にアラーム指示の送信を延期する余地がない」と判断する。よって、引数として与えられたセンサユニットＩＤと端末ＩＤの組に対応して図１８のステップＳ６０７で求められたフラグは、書き換え不要である。そのため、初日における経過日数が閾値以上のときは、フラグの書き換えは行われず、そのままスケジュール確認処理が終了する。
【０４３８】
逆に、初日における経過日数が閾値未満の場合、アラーム指示の送信を延期する余地があるかもしれない。そこで、処理はステップＳ８０８に移行する。
ステップＳ８０８でアラーム決定部３３４は、ステップＳ８０６で決定した最終日における、前回のデータ収集からの経過日数と閾値を比較する。アラーム決定部３３４は、最終日から、ステップＳ８０７で読み取った収集日を引くことで、最終日における経過日数を計算する。また、ステップＳ８０８で使われる閾値は、ステップＳ８０７で使われる閾値と同じものである。
【０４３９】
最終日における経過日数が閾値未満であれば、アラーム指示の送信を最終日まで延期することは妥当である。そこで、処理はステップＳ８０９に移行する。
逆に、最終日における経過日数が閾値以上であれば、処理はステップＳ８１０に移行する。例えば、「閾値が７日であり、前回の収集が２日前であり、今日から１５日間連続で作業が予定されている」といった場合など、作業のひとかたまりの単位が長期間に及ぶ場合があり得る。そのような場合には、最終日よりも前にサーバ３１０ｂが一旦センサログを収集することが好ましい。そのため、ステップＳ８０８でアラーム決定部３３４は最終日における経過日数と閾値を比較している。
【０４４０】
さて、ステップＳ８０９でアラーム決定部３３４は、図１５の収集日ＤＢ３２８にアラーム予定日を設定する。具体的には、アラーム決定部３３４は、引数で指定されたセンサユニットＩＤに対応する収集日ＤＢ３２８のエントリを検索し、見つかったエントリのアラーム予定日に、ステップＳ８０６で決定した最終日の日付を設定する。
【０４４１】
さらに、ステップＳ８０９でアラーム決定部３３４は、引数で指定されたセンサユニットＩＤと端末ＩＤの組み合わせに対応して図１８のステップＳ６０７で求められたフラグの値を、ｆｌａｓｅに設定する。つまり、アラーム決定部３３４は、「今日は、引数で指定されたセンサユニットＩＤに関して、引数で指定された端末ＩＤの端末３７０にアラーム指示を送信しない」と決定する。そして、図２０のスケジュール確認処理は終了する。
【０４４２】
また、ステップＳ８１０でアラーム決定部３３４は、図１５の収集日ＤＢ３２８にアラーム予定日を設定する。具体的には、アラーム決定部３３４は、ステップＳ８０７で読み取った前回の収集日に、ステップＳ８０７とＳ８０８で使った閾値を足し、前回の収集日から閾値のぶんだけ経過した日付を計算する。また、アラーム決定部３３４は、引数で指定されたセンサユニットＩＤに対応する収集日ＤＢ３２８のエントリを検索し、見つかったエントリのアラーム予定日に、上記の計算で得られた日付を設定する。
【０４４３】
さらに、ステップＳ８１０でアラーム決定部３３４は、引数で指定されたセンサユニットＩＤと端末ＩＤの組み合わせに対応して図１８のステップＳ６０７で求められたフラグの値を、ｆｌａｓｅに設定する。つまり、アラーム決定部３３４は、「今日は、引数で指定されたセンサユニットＩＤに関して、引数で指定された端末ＩＤの端末３７０にアラーム指示を送信しない」と決定する。そして、図２０のスケジュール確認処理は終了する。
【０４４４】
以上のようにして、図２０のスケジュール確認処理により、アラーム指示の送信の延期の妥当性が検討され、検討結果に応じてフラグが書き換えられる。よって、書き換え後のフラグに応じて図１８のステップＳ６１１〜Ｓ６１６の処理が行われることで、不急のアラーム指示の送信が抑制される。
【０４４５】
なお、以上の図１８〜２０の処理についてまとめれば以下の通りである。
サーバ３１０ｂは、センサユニット３５０が設置された領域における作業のスケジュールを認識し、端末３７０にアラームを出させる（つまりユーザへの指示を与えさせる）日または日時を、スケジュールに応じて決定する。具体的には、図２０のステップＳ８０７に示すように、所定の基準よりも経過時間が長ければ、サーバ３１０ｂは、日または日時を決定する処理が行われる当日を、端末３７０にアラームを出させる日として決定する。逆に、所定の基準よりも経過時間が短ければ、サーバ３１０ｂは、スケジュールによって作業が計画されている日と計画されていない日の分布に基づいて、端末３７０にアラームを出させる日または日時の延長期限を決定する。
【０４４６】
例えば、図２０の例では、ステップＳ８０１〜Ｓ８０６で認識された分布に基づいて、ステップＳ８０９またはＳ８１０で延長期限が決定されている。そして、延長期限の決定は、例えば以下のような情報と上記分布を照らし合わせた結果に基づく。
【０４４７】
・作業なし期間の長さの上限と、作業なし期間の回数の上限の少なくとも一方（例えば、スケジュール単位定義ＤＢ３３２の例では双方）
・前回のデータ収集時点からの時間の長さの上限（例えば、図２０のステップＳ８０７〜Ｓ８１０で使われる閾値）
【０４４８】
そして、サーバ３１０ｂは、アラーム指示の与え方を制御することで、端末３７０に、決定された日または日時にアラームをユーザに与えさせる。アラーム指示の与え方を制御する方法としては、上記のように、アラーム指示を端末３７０に与えるタイミングを、決定された日または日時に応じて（つまり、アラーム予定日や休憩時間などに応じて）制御する方法がある。あるいは、サーバ３１０ｂは、アラーム指示の与え方を制御する方法として、「アラームをユーザに与える日または日時を指定する情報をアラーム指示に含めて端末３７０に送る」という方法を採用してもよい。
【０４４９】
ところで、本発明は上記の第１〜２実施形態に限られるものではない。上記の説明においてもいくつかの変形について説明したが、上記実施形態は、さらに例えば下記の（１）〜（９）の観点から様々に変形することもできる。上記および下記の変形は、相互に矛盾しない限り、任意に組み合わせることが可能である。
【０４５０】
（１）ハードウェア構成についての変形
図４には、プログラムにしたがって動作する汎用的なプロセッサ（すなわち、ＣＰＵ４０１、ＭＰＵ４２２、およびＭＰＵ４４２）が例示されている。しかし、汎用的なプロセッサの代わりに、ＡＳＩＣ（Application Specific Integrated Circuit）などの専用のハードウェア回路が利用されてもよいし、汎用的なプロセッサと専用のハードウェア回路の組み合わせが利用されてもよい。
【０４５１】
（２）データ構造についての変形
また、図面では便宜上、各種ＤＢをテーブル形式で表現しているが、各種ＤＢのデータ構造は実施形態に応じて適宜変形されてもよい。例えば、アレイや連想配列などが利用されてもよいし、ＸＭＬ（Extensible Markup Language）などによりマークアップされた形式のデータが利用されてもよい。
【０４５２】
また、例えばセンサユニットＩＤを一意のキーとして含む複数のＤＢが、１つのテーブルにまとめられてもよい。また、センサログは、図７のように１つのエントリが複数のセンサについてのフィールドを有する形式でもよいし、１つのエントリが１つのセンサについてのフィールドとセンサを識別するフィールドを有する形式であってもよい。
【０４５３】
（３）数値の計算方法についての変形
実施形態によっては、式（３）の代わりに式（６）が使われてもよい。また、式（４）の代わりに式（７）が使われてもよい。
【０４５４】
【数６】
【０４５５】
【数７】
【０４５６】
さらに、式（２）などで使われるウィンドウ間隔Ｗの値が１であってもよい（つまり、ウィンドウが利用されなくてもよい）。なお、式（７）のようにＮ個のブロック間で距離を平均する代わりに、Ｎ個のブロック間で最小距離を求めてもよい。
【０４５７】
また、実施形態によっては、アラーム距離が、離散的に図６のようにＤＢにより定義されるのではなく、経過時間ｐを引数とする連続関数ｆ（ｐ）により定義されてもよい。経過時間ｐに対して単調増加する適宜の関数が、アラーム距離を定義する関数ｆ（ｐ）として利用可能である。
【０４５８】
もちろん、図６のアラーム条件ＤＢ３２０と同様に境界値を規定するＤＢと、境界値同士の間の補間によって、アラーム距離が連続的に定義されてもよい。つまり、アラーム距離は、経過時間につれて増大するように定義されてさえいれば、どのような形式で定義されていてもよい。
【０４５９】
（４）閾値その他の定数についての変形
上記に説明したいくつかの処理は、閾値との比較を含む（例えば、図１２のステップＳ４０８や、図２０のステップＳ８０７とＳ８０８など）。閾値との比較は、実施形態に応じて「比較対象の数値が、閾値を超えるか否か」を判断する処理でもよいし、「比較対象の数値が、閾値以上か否か」を判断する処理でもよい。また、上記の説明における各種定数の例は、説明の便宜上のものである。各種定数の具体的な値は、実施形態に応じて適宜に決められてよい。
【０４６０】
（５）センサユニットの設置場所に関する変形
なお、図２と１３には、センサユニット２０２が圃場２０１に設置される例を示したが、センサユニット２０２が設置される場所は、端末３７０のユーザのうち少なくとも１人が何らかの作業を行う任意の領域であってよい。センサユニット２０２は、例えば、以下のような場所に設置されてもよい。また、当該場所における作業スケジュールが第２実施形態と同様にして参照され、アラーム予定日の決定のために用いられてもよい。
・水田、畑をはじめとする各種圃場
・林班、準林班、林小班などの、林業用に区切られた森林区画
・放牧場、養鶏場、養豚場、養牛場など、畜産業が営まれる場所
・養魚場、その他の水生生物（藻類、海老、真珠など）の養殖場（人工池でもよいし、自然の湖沼、河川、港湾等の特定部分でもよい）など、水産業が営まれる場所
・養蜂場など、その他の生き物を飼養するための場所
・鉱山、採石場、砂利採取場など、鉱業が営まれる場所
・土木工事現場、建設現場など、建設業が営まれる場所
【０４６１】
圃場をはじめとして、上記に例示したような場所は、広い屋外であることが多いので、データ収集に関与するためのユーザの負担（例えば移動距離の長さ）を無視しがたい。よって、上記に例示したような場所にセンサユニット３５０が設置されている場合に、データ収集システム３００や３００ｂは好適である。
【０４６２】
また、農林水産業などの第一次産業では特に、毎日同じ場所での作業が予定されているとは限らない。つまり、毎日データ収集が可能であるとは限らず、データ収集の緊急度が日によって変動し得る。よって、農林水産業等に関連する上記のような場所に設置されたセンサユニット３５０を含むシステムとして、データ収集システム３００や３００ｂは好適である。
【０４６３】
また、データ収集システム３００ｂは、作業スケジュールと経過時間に基づいて柔軟にアラーム予定日を適宜延期するという点においても、毎日同じ場所での作業が予定されているとは限らない農林水産業向けのシステムとして好適である。
【０４６４】
（６）端末３７０間の比較を第１実施形態に導入する変形
ところで、第１実施形態と第２実施形態を比べると、第２実施形態では図１８のステップＳ６１３で端末３７０間の比較が行われるのに対し、第１実施形態では端末３７０間の比較は行われない。しかし、ある１台のセンサユニット３５０からアラーム距離の範囲内に、複数のユーザがいる場合もあり得る。よって、端末３７０間の比較をサーバ３１０が行うように、第１実施形態が変形されてもよい。具体的には次のとおりである。
【０４６５】
ある１台のセンサユニット３５０からアラーム距離の範囲内に、複数のユーザがいるとする。この場合、ユーザの負荷軽減という観点からは、サーバ３１０は、複数のユーザがそれぞれ携帯する複数の端末３７０のうち、センサユニット３５０により近い一部の端末３７０にのみ、アラーム指示を送信することが好ましい。例えば、サーバ３１０は、センサユニット３５０に最も近い１台の端末３７０にのみ、アラーム指示を送信してもよい。
【０４６６】
そして、センサユニット３５０からアラーム距離の範囲内の複数の端末３７０の中から一部だけをアラーム指示の送信対象として選び出すためには、サーバ３１０は、端末３７０間でセンサユニット３５０までの距離を比較すればよい。例えば、サーバ３１０は、図１２のように個々の端末３７０からステップＳ４０１でＧＰＳログを受信するたびにステップＳ４０２〜Ｓ４１５の処理を行うのではなく、ＧＰＳログの受信と蓄積を行う処理と、アラーム指示の送信に関する処理を独立して行ってもよい。
【０４６７】
例えば、サーバ３１０は、いずれかの端末３７０からＧＰＳログを受信するたびに、ＧＰＳログＤＢ３１１にＧＰＳログを蓄積する。一方で、サーバ３１０は、所定の間隔で（例えば１時間ごとに）、次のような処理を行ってもよい。
【０４６８】
サーバ３１０は、直近の所定の時間（例えば上記間隔と同じ１時間でもよいし、より短い１５分などの時間でもよい）に受信されたＧＰＳログを、ＧＰＳログＤＢ３１１から抽出する。そして、サーバ３１０は、抽出したＧＰＳログについて、端末３７０ごとに、図１２のステップＳ４０２〜Ｓ４１３と同様の処理を行う。
【０４６９】
その後、サーバ３１０は、各センサユニット３５０について、当該センサユニット３５０に対応するフラグの値がｔｒｕｅの端末３７０の端末ＩＤを抽出する。もし、２台以上の端末３７０の端末ＩＤが抽出された場合、サーバ３１０は、当該センサユニット３５０までの距離が一番短い端末３７０を選択する。
【０４７０】
ここで、端末３７０間での比較のために使われるセンサユニット３５０までの距離としては、例えば、複数のブロックについてそれぞれステップＳ４０７で計算された距離の最小値または平均値が利用可能である。あるいは、最新のブロックについてステップＳ４０７で計算された距離が利用されてもよい。
【０４７１】
以上のようにしてサーバ３１０は、各センサユニット３５０に関して端末３７０を選択し、当該センサユニット３５０についてのアラーム指示を、選択した端末３７０に対してのみ送信してもよい。すると、「あるセンサユニット３５０の近辺に大勢のユーザがいる場合に、全員の端末３７０がアラームを発してしまう」といった事態が避けられるようになり、複数のユーザ全体での作業効率の悪化を防ぐことができる。
【０４７２】
なお、以上のような第１実施形態の変形例と図１３〜２０の第２実施形態は、「あるセンサユニット３５０からの距離がアラーム距離未満の端末３７０が２台以上ある場合に、アラーム指示を与える対象の端末３７０を絞り込む」という点で共通である。その絞り込みは、具体的には、「センサユニット３５０からの距離がアラーム距離未満の端末３７０のうちで、相対的に距離が短い端末３７０に絞り込む」という処理である。そして、以上の絞り込みにより、第１実施形態の変形例でも、第２実施形態でも、複数のユーザ全体での作業効率の悪化を防ぐことができる。
【０４７３】
（７）休憩時間に関する変形
ところで、第２実施形態では、図１５の休憩時間ＤＢ３３１のような静的なデータに基づいて、図１８のステップＳ６０３で「現在が休憩時間か否か」という判断が下される。しかし、例えば、サーバ３１０ｂは、ＧＰＳログＤＢ３１１に基づいて端末３７０が存在する位置を追跡することで、動的に休憩時間を認識してもよい。例えば、端末３７０が所定の時間以上、１箇所に留まっている場合に、サーバ３１０ｂは、「当該端末３７０のユーザは休憩中である」と判断してもよい。
【０４７４】
また、圃場ごとに休憩時間が異なる場合は、休憩時間ＤＢ３３１のデータ構造が、圃場ごとに休憩時間を管理するように変形されてもよい。そして、サーバ３１０ｂは、個々の圃場について、当該圃場での休憩時間になったら、当該圃場に設置されているセンサユニット３５０のみを対象として、図１８のステップＳ６０４〜Ｓ６１６と同様の処理を行ってもよい。
【０４７５】
（８）アラーム指示の送信タイミングに関する変形
図１８のステップＳ６０３では、現在時刻が休憩時間に該当するか否かが判断される。しかし、サーバ３１０ｂは、例えば休憩終了時刻よりも所定時間だけ前の時刻にステップＳ６０４以降の処理を行うことで、ユーザが休憩終了直後、作業を始める前にデータ収集に関与することができるようにしてもよい。
【０４７６】
あるいは、サーバ３１０ｂは、例えば休憩開始時刻よりも所定時間だけ前の時刻にステップＳ６０４以降の処理を行ってもよい。その場合、サーバ３１０ｂは、さらに、アラーム指示の送信のタイミングを調整してもよい。つまり、サーバ３１０ｂは、休憩時間に応じて決まる適宜の時刻にアラームがユーザに与えられるようにアラーム指示の与え方を制御すればよく、「休憩時間に応じて決まる適宜の時刻」が具体的にどのような時刻であるかは、実施形態によって異なっていてよい。
【０４７７】
例えば、１２時から１３時が休憩時間であり、上記の所定時間が１０分間とする。この場合、サーバ３１０ｂは、ＧＰＳログの受信および蓄積とは独立して、１１時５０分になったらステップＳ６０４以降の処理を開始してもよい。
【０４７８】
端末３７０のユーザは、必ずしも予定どおり１２時きっかりに休憩を始めるとは限らない。例えば、ユーザは、１２時よりも少し前から休憩し始めて、昼食をとるために圃場から出て行こうとするかもしれない。このような状況を想定すると、ユーザが圃場から出て行ってセンサユニット３５０から遠ざかってしまう前に、確実に端末３７０がアラームを発するようにするために、サーバ３１０ｂが１１時５０分にステップＳ６０４以降の処理を行うことは有意義である。
【０４７９】
なお、その結果として１１時５０分に端末３７０がアラームを発した場合であっても、ユーザは１２時から休憩をとるかもしれない。たとえそうだとしても、ユーザは、アラームを受けた後、自分の都合のよいとき（例えば１２時になったとき）にアラームにしたがってセンサユニット３５０に近寄ればよい。
【０４８０】
また、あるセンサユニット３５０についてのアラーム距離が長い場合、当該センサユニット３５０に関するアラーム指示は、当該センサユニット３５０から遠く離れた端末３７０へと送信される可能性がある。そして、センサユニット３５０からの距離が長いほど、ユーザがセンサユニット３５０まで移動するのにかかる時間も長い。
【０４８１】
例えば、サーバ３１０ｂが、あるセンサユニット３５０から歩いて５分の距離にいるユーザの端末３７０にアラーム指示を送信する場合、サーバ３１０ｂは、休憩開始時刻の５分以上前にアラーム指示を送信してもよい。すると、端末３７０からアラームを受けたユーザは、アラームにしたがってセンサユニット３５０まで移動してデータ収集に関与しても、「データ収集に関与することで休憩時間が減ってしまう」ということがない。
【０４８２】
つまり、サーバ３１０ｂは、休憩開始時刻よりも所定時間前（例えば１１時５０分）になったら、ステップＳ６０４〜Ｓ６１０の処理を行い、さらに、各センサユニット３５０についてステップＳ６１２とＳ６１３の処理を行ってもよい。そして、ｉ番目のセンサユニット３５０についてのアラーム指示の送信先としてステップＳ６１３で選んだ端末３７０からの、ｉ番目のセンサユニット３５０までの距離に応じて、サーバ３１０ｂがアラーム指示の送信時刻を決めてもよい。例えば、サーバ３１０ｂは、ステップＳ６１３で選んだ端末３７０がｉ番目のセンサユニット３５０から遠いほど、送信時刻を早くしてもよい。そして、送信時刻になったら、サーバ３１０ｂは、アラーム指示を送信する。
【０４８３】
以上述べたとおり、休憩時間の開始に合わせてユーザにデータ収集に関与させる場合は、サーバ３１０ｂが休憩開始時刻よりも前にステップＳ６０４以降の処理を開始することが有益である。
【０４８４】
なお、上記とは逆に、サーバ３１０ｂは、ステップＳ６１３で選んだ端末３７０がｉ番目のセンサユニット３５０から遠いほど、送信時刻を遅くしてもよい。
例えば、もし端末３７０のユーザがセンサユニット３５０から歩いて１分の距離にいるのであれば、データ収集への関与の手間はさほど大きくない。そこで、休憩時間に入る前にユーザがデータ収集への関与をさっさと済ますことができるように、サーバ３１０ｂは、早め（例えば１１時５０分）にアラーム指示を送信してもよい。
【０４８５】
他方、もし端末３７０のユーザがセンサユニット３５０から歩いて１５分の距離にいるのであれば、例えばサーバ３１０ｂは休憩開始時刻まで待ってから端末３７０にアラーム指示を送信してもよい。つまり、センサユニット３５０から遠くにいるユーザに関しては、サーバ３１０ｂは、休憩開始時刻まではユーザの作業をアラームによって邪魔しないことを優先させてもよい。
【０４８６】
（９）スケジュール確認処理に関する変形
図２０のスケジュール確認処理のステップＳ８１０によれば、アラーム予定日がたまたま途中の作業なし日にあたってしまう場合もあり得る。そこで、アラーム決定部３３４は、前回のデータ収集日に閾値を足した日が作業なし日にあたる場合は、当該作業なし日よりも前で当該作業なし日の直近の作業予定日を、アラーム予定日として決定してもよい。
【０４８７】
例えば、図２０のステップＳ８０７〜Ｓ８１０で使われる閾値が１０日であるとする。すると、図１６のスケジュール例５０４のように、前回のデータ収集日から１０日後が作業なし日にあたる場合もある。この場合、アラーム決定部３３４は、当該作業なし日よりも前で当該作業なし日の直近の作業予定日（スケジュール例５０４の例では、「前回収集日」から７日後の「作業最終日」）を、アラーム予定日として設定してもよい。
【０４８８】
また、図２０のスケジュール確認処理では、アラーム決定部３３４が作業のひとかたまりの単位を認識するが、作業のひとかたまりの単位をどのように定義するかは、実施形態に応じて任意である。図１５のスケジュール単位定義ＤＢ３３２とは異なる基準で、作業のひとかたまりの単位が定義されてもよい。
【０４８９】
つまり、作業のひとかたまりの単位に関しては、その中に含まれる作業予定日と作業なし日の分布に関する何らかの基準が与えられさえすればよく、具体的にどのような基準が使われるかは、実施形態に応じて任意である。例えば、スケジュール単位定義ＤＢ３３２により与えられる基準の代わりに、以下のような基準を適宜に組み合わせた基準が利用されてもよい。
・開始日と終了日には作業が予定されていること
・作業なし日の比率が所定値（例えば２５％）以下であること
・作業なし日の合計日数が所定値（例えば６日）以下であること
【０４９０】
最後に、上記の種々の実施形態に関して、さらに下記の付記を開示する。
（付記１）
コンピュータに、
前記コンピュータが収集する対象のデータを記憶しているデータ記憶装置が設置されている第１の位置を認識し、
前記データ記憶装置に記憶されていたデータを、前記データ記憶装置および前記コンピュータの双方と通信可能な１台以上の端末のいずれかを介して、過去に前記コンピュータが収集した収集時点からの、経過時間を認識し、
前記経過時間が長いほど大きくなるように定義された閾値を、前記経過時間に基づいて取得し、
前記１台以上の端末のうち少なくとも１台の端末について、
当該端末の存在する第２の位置を認識し、
前記第１の位置と前記第２の位置の間の距離を計算し、
前記距離が前記閾値未満のとき、当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第１の指示を当該端末のユーザに対して与えるよう、第２の指示を与える
ことを含む処理を実行させるプログラム。
（付記２）
前記データ記憶装置は、前記１台以上の端末それぞれのユーザのうち少なくとも１人が作業を行う領域に設置されており、
前記プログラムが前記コンピュータに実行させる前記処理が、さらに、
前記領域における前記作業のスケジュールを認識し、
前記端末に前記第１の指示を与えさせる日または日時を、前記スケジュールに応じて決定し、
前記第２の指示の与え方を制御することで、前記端末に、決定された前記日または前記日時に前記第１の指示を前記ユーザに与えさせる、
ことを含む
ことを特徴とする付記１に記載のプログラム。
（付記３）
前記日または前記日時を決定する処理は、
所定の基準よりも前記経過時間が長ければ、前記日または前記日時を決定する前記処理が行われる当日を、前記端末に前記第１の指示を与えさせる日として決定し、
前記基準よりも前記経過時間が短ければ、前記スケジュールによって前記作業が計画されている日と計画されていない日の分布に基づいて、前記端末に前記第１の指示を与えさせる前記日または前記日時の延長期限を決定する
ことを含む
ことを特徴とする付記２に記載のプログラム。
（付記４）
前記延長期限を決定する処理が、
前記作業が計画されていない日が連続する作業なし期間の長さの上限と、前記作業なし期間の回数の上限の少なくとも一方と、
前記収集時点からの時間の長さの上限
を前記分布と照らし合わせた結果に基づく
ことを特徴とする付記３に記載のプログラム。
（付記５）
前記プログラムが前記コンピュータに実行させる前記処理が、さらに、
前記作業の休憩時間に応じて決まる時刻に、前記端末に前記第１の指示を与えさせるように、前記第２の指示の与え方を制御することを含む
ことを特徴とする付記３または４に記載のプログラム。
（付記６）
前記プログラムが前記コンピュータに実行させる前記処理が、さらに、
前記休憩時間を表す情報を読み出すこと、または、
前記第２の指示を与える対象の前記端末が存在する位置を追跡すること
により、前記休憩時間を認識することを含む
ことを特徴とする付記５に記載のプログラム。
（付記７）
前記第２の指示の与え方を制御する処理は、
前記第２の指示を前記端末に与えるタイミングを、決定された前記日または前記日時に応じて制御するか、または、
決定された前記日または前記日時を指定する情報を、前記第２の指示に含める
ことを含む
ことを特徴とする付記２から６のいずれか１項に記載のプログラム。
（付記８）
前記プログラムが前記コンピュータに実行させる前記処理は、前記１台以上の端末のいずれかから、前記データ記憶装置から当該端末に転送されて格納されたデータを、前記コンピュータが受信するたびに、当該データを前記コンピュータが受信した収集時点を記憶することを含み、
前記経過時間を認識する処理は、記憶された前記収集時点と現在日時に基づいて前記経過時間を計算することを含む
ことを特徴とする付記１から７のいずれか１項に記載のプログラム。
（付記９）
前記１台以上の端末と前記データ記憶装置との間の通信は無線通信であり、
前記第１の指示は、前記ユーザに対して前記データ記憶装置へ接近することを求める指示である
ことを特徴とする付記１から８のいずれか１項に記載のプログラム。
（付記１０）
前記１台以上の端末の数は複数であり、
前記プログラムが前記コンピュータに実行させる前記処理は、
前記複数の端末のうち少なくとも２台以上の端末について、前記第１の位置と前記第２の位置の間の前記距離を計算し、
前記距離が前記閾値未満の端末が２台以上ある場合、前記第２の指示を与える対象の端末を、前記距離が前記閾値未満の端末のうちで相対的に前記距離が短い端末に絞り込む
ことを含む
ことを特徴とする付記１から９のいずれか１項に記載のプログラム。
（付記１１）
情報処理装置であって、
前記情報処理装置が収集する対象のデータを記憶しているデータ記憶装置が設置されている第１の位置を示す位置情報を記憶する記憶手段と、
前記データ記憶装置と通信可能な１台以上の端末の各々との通信を行う通信手段と、
前記データ記憶装置に記憶されていたデータを、前記１台以上の端末のいずれかと前記通信手段を介して過去に前記情報処理装置が収集した収集時点からの経過時間を認識し、前記経過時間が長いほど大きくなるように定義された閾値を、認識した前記経過時間に基づいて取得する取得手段と、
前記１台以上の端末のうち少なくとも１台の端末について、当該端末の存在する第２の位置を認識する位置認識手段と、
前記記憶手段から前記位置情報を読み出し、前記位置情報が示す前記第１の位置と、前記位置認識手段が認識した前記第２の位置との間の距離を計算する計算手段と、
前記計算手段が計算した前記距離が、前記取得手段が取得した前記閾値未満のとき、前記計算手段が前記距離の計算に用いた前記第２の位置に存在すると前記位置認識手段により認識された当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第１の指示を当該端末のユーザに対して与えるよう、第２の指示を与える指示手段
を備える情報処理装置。
（付記１２）
コンピュータが、
前記コンピュータが収集する対象のデータを記憶しているデータ記憶装置が設置されている第１の位置を認識し、
前記データ記憶装置に記憶されていたデータを、前記データ記憶装置および前記コンピュータの双方と通信可能な１台以上の端末のいずれかを介して、過去に前記コンピュータが収集した収集時点からの、経過時間を認識し、
前記経過時間が長いほど大きくなるように定義された閾値を、前記経過時間に基づいて取得し、
前記１台以上の端末のうち少なくとも１台の端末について、
当該端末の存在する第２の位置を認識し、
前記第１の位置と前記第２の位置の間の距離を計算し、
前記距離が前記閾値未満のとき、当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第１の指示を当該端末のユーザに対して与えるよう、第２の指示を与える
ことを特徴とする方法。
【符号の説明】
【０４９１】
１００、３００、３００ｂ データ収集システム
１０１ コンピュータ
１０２ データ記憶装置
１０３、１０４、３７０、３７０ａ〜３７０ｃ 端末
１０５、１０６、２０４、２０６、２０９ ユーザ
１０７ アラーム範囲
１０８ 説明図
２０１ 圃場
２０２、３５０、３５０ａ〜３５０ｃ センサユニット
２０３ 検知領域
２０５、２０７、２１０〜２１３ 軌跡
２０８ 非作業領域
３１０、３１０ｂ サーバ
３１１ ＧＰＳログＤＢ
３１２ 端末管理ＤＢ
３１３ ＧＰＳログ処理部
３１４、３２８ 収集日ＤＢ
３１５ センサログＤＢ
３１６ センサログ処理部
３１７ センサ位置ＤＢ
３１８ センサ種別ＤＢ
３１９ センサユニット別アラーム条件ＤＢ
３２０ アラーム条件ＤＢ
３２１ サンプリング周期ＤＢ
３２２ データ量条件ＤＢ
３２３ アラーム距離決定部
３２４ 端末・センサ間距離計算部
３２５ 距離比較部
３２６、３３４ アラーム決定部
３２７ 通信部
３２９ 圃場形状ＤＢ
３３０ スケジュールＤＢ
３３１ 休憩時間ＤＢ
３３２ スケジュール単位定義ＤＢ
３３３ 圃場特定部
３５１ 各種センサ
３５２ センサログＤＢ
３５３ センサログ処理部
３５４ 通信部
３７１ ＧＰＳ情報取得部
３７２ ＧＰＳログＤＢ
３７３ サーバ通信部
３７４ アラーム処理部
３７５ センサ通信部
３７６ センサログＤＢ
３７７ センサログ処理部
４０１ ＣＰＵ
４０２、４２３、４４３ ＲＡＭ
４０３ ＨＤＤ
４０４ ネットワークＩＦ
４０５ 機器ＩＦ
４０６ ディスプレイＩＦ
４０７ 駆動装置
４１１ ネットワーク
４１２ キーボード
４１３ マウス
４１４、４５１ ディスプレイ
４１５ 記憶媒体
４２１、４４１ バッテリ
４２２、４４２ ＭＰＵ
４２４、４４４ フラッシュＲＯＭ
４２５、４２７ 温度センサ
４２６ 湿度センサ
４２８ 人感センサ
４２９〜４３３ センサＩＦ
４３４、４４５ 近距離無線通信機
４４６ ＧＰＳ受信機
４４７ ３Ｇ通信機
４４８ ＬＥＤ
４４９ ブザー
４５０ 振動モータ
５０１〜５０４ スケジュール例
【特許請求の範囲】
【請求項１】
コンピュータに、
前記コンピュータが収集する対象のデータを記憶しているデータ記憶装置が設置されている第１の位置を認識し、
前記データ記憶装置に記憶されていたデータを、前記データ記憶装置および前記コンピュータの双方と通信可能な１台以上の端末のいずれかを介して、過去に前記コンピュータが収集した収集時点からの、経過時間を認識し、
前記経過時間が長いほど大きくなるように定義された閾値を、前記経過時間に基づいて取得し、
前記１台以上の端末のうち少なくとも１台の端末について、
当該端末の存在する第２の位置を認識し、
前記第１の位置と前記第２の位置の間の距離を計算し、
前記距離が前記閾値未満のとき、当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第１の指示を当該端末のユーザに対して与えるよう、第２の指示を与える
ことを含む処理を実行させるプログラム。
【請求項２】
前記データ記憶装置は、前記１台以上の端末それぞれのユーザのうち少なくとも１人が作業を行う領域に設置されており、
前記プログラムが前記コンピュータに実行させる前記処理が、さらに、
前記領域における前記作業のスケジュールを認識し、
前記端末に前記第１の指示を与えさせる日または日時を、前記スケジュールに応じて決定し、
前記第２の指示の与え方を制御することで、前記端末に、決定された前記日または前記日時に前記第１の指示を前記ユーザに与えさせる、
ことを含む
ことを特徴とする請求項１に記載のプログラム。
【請求項３】
前記日または前記日時を決定する処理は、
所定の基準よりも前記経過時間が長ければ、前記日または前記日時を決定する前記処理が行われる当日を、前記端末に前記第１の指示を与えさせる日として決定し、
前記基準よりも前記経過時間が短ければ、前記スケジュールによって前記作業が計画されている日と計画されていない日の分布に基づいて、前記端末に前記第１の指示を与えさせる前記日または前記日時の延長期限を決定する
ことを含む
ことを特徴とする請求項２に記載のプログラム。
【請求項４】
前記プログラムが前記コンピュータに実行させる前記処理が、さらに、
前記作業の休憩時間に応じて決まる時刻に、前記端末に前記第１の指示を与えさせるように、前記第２の指示の与え方を制御することを含む
ことを特徴とする請求項３に記載のプログラム。
【請求項５】
情報処理装置であって、
前記情報処理装置が収集する対象のデータを記憶しているデータ記憶装置が設置されている第１の位置を示す位置情報を記憶する記憶手段と、
前記データ記憶装置と通信可能な１台以上の端末の各々との通信を行う通信手段と、
前記データ記憶装置に記憶されていたデータを、前記１台以上の端末のいずれかと前記通信手段を介して過去に前記情報処理装置が収集した収集時点からの経過時間を認識し、前記経過時間が長いほど大きくなるように定義された閾値を、認識した前記経過時間に基づいて取得する取得手段と、
前記１台以上の端末のうち少なくとも１台の端末について、当該端末の存在する第２の位置を認識する位置認識手段と、
前記記憶手段から前記位置情報を読み出し、前記位置情報が示す前記第１の位置と、前記位置認識手段が認識した前記第２の位置との間の距離を計算する計算手段と、
前記計算手段が計算した前記距離が、前記取得手段が取得した前記閾値未満のとき、前記計算手段が前記距離の計算に用いた前記第２の位置に存在すると前記位置認識手段により認識された当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第１の指示を当該端末のユーザに対して与えるよう、第２の指示を与える指示手段
を備える情報処理装置。
【請求項６】
コンピュータが、
前記コンピュータが収集する対象のデータを記憶しているデータ記憶装置が設置されている第１の位置を認識し、
前記データ記憶装置に記憶されていたデータを、前記データ記憶装置および前記コンピュータの双方と通信可能な１台以上の端末のいずれかを介して、過去に前記コンピュータが収集した収集時点からの、経過時間を認識し、
前記経過時間が長いほど大きくなるように定義された閾値を、前記経過時間に基づいて取得し、
前記１台以上の端末のうち少なくとも１台の端末について、
当該端末の存在する第２の位置を認識し、
前記第１の位置と前記第２の位置の間の距離を計算し、
前記距離が前記閾値未満のとき、当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第１の指示を当該端末のユーザに対して与えるよう、第２の指示を与える
ことを特徴とする方法。
【請求項１】
コンピュータに、
前記コンピュータが収集する対象のデータを記憶しているデータ記憶装置が設置されている第１の位置を認識し、
前記データ記憶装置に記憶されていたデータを、前記データ記憶装置および前記コンピュータの双方と通信可能な１台以上の端末のいずれかを介して、過去に前記コンピュータが収集した収集時点からの、経過時間を認識し、
前記経過時間が長いほど大きくなるように定義された閾値を、前記経過時間に基づいて取得し、
前記１台以上の端末のうち少なくとも１台の端末について、
当該端末の存在する第２の位置を認識し、
前記第１の位置と前記第２の位置の間の距離を計算し、
前記距離が前記閾値未満のとき、当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第１の指示を当該端末のユーザに対して与えるよう、第２の指示を与える
ことを含む処理を実行させるプログラム。
【請求項２】
前記データ記憶装置は、前記１台以上の端末それぞれのユーザのうち少なくとも１人が作業を行う領域に設置されており、
前記プログラムが前記コンピュータに実行させる前記処理が、さらに、
前記領域における前記作業のスケジュールを認識し、
前記端末に前記第１の指示を与えさせる日または日時を、前記スケジュールに応じて決定し、
前記第２の指示の与え方を制御することで、前記端末に、決定された前記日または前記日時に前記第１の指示を前記ユーザに与えさせる、
ことを含む
ことを特徴とする請求項１に記載のプログラム。
【請求項３】
前記日または前記日時を決定する処理は、
所定の基準よりも前記経過時間が長ければ、前記日または前記日時を決定する前記処理が行われる当日を、前記端末に前記第１の指示を与えさせる日として決定し、
前記基準よりも前記経過時間が短ければ、前記スケジュールによって前記作業が計画されている日と計画されていない日の分布に基づいて、前記端末に前記第１の指示を与えさせる前記日または前記日時の延長期限を決定する
ことを含む
ことを特徴とする請求項２に記載のプログラム。
【請求項４】
前記プログラムが前記コンピュータに実行させる前記処理が、さらに、
前記作業の休憩時間に応じて決まる時刻に、前記端末に前記第１の指示を与えさせるように、前記第２の指示の与え方を制御することを含む
ことを特徴とする請求項３に記載のプログラム。
【請求項５】
情報処理装置であって、
前記情報処理装置が収集する対象のデータを記憶しているデータ記憶装置が設置されている第１の位置を示す位置情報を記憶する記憶手段と、
前記データ記憶装置と通信可能な１台以上の端末の各々との通信を行う通信手段と、
前記データ記憶装置に記憶されていたデータを、前記１台以上の端末のいずれかと前記通信手段を介して過去に前記情報処理装置が収集した収集時点からの経過時間を認識し、前記経過時間が長いほど大きくなるように定義された閾値を、認識した前記経過時間に基づいて取得する取得手段と、
前記１台以上の端末のうち少なくとも１台の端末について、当該端末の存在する第２の位置を認識する位置認識手段と、
前記記憶手段から前記位置情報を読み出し、前記位置情報が示す前記第１の位置と、前記位置認識手段が認識した前記第２の位置との間の距離を計算する計算手段と、
前記計算手段が計算した前記距離が、前記取得手段が取得した前記閾値未満のとき、前記計算手段が前記距離の計算に用いた前記第２の位置に存在すると前記位置認識手段により認識された当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第１の指示を当該端末のユーザに対して与えるよう、第２の指示を与える指示手段
を備える情報処理装置。
【請求項６】
コンピュータが、
前記コンピュータが収集する対象のデータを記憶しているデータ記憶装置が設置されている第１の位置を認識し、
前記データ記憶装置に記憶されていたデータを、前記データ記憶装置および前記コンピュータの双方と通信可能な１台以上の端末のいずれかを介して、過去に前記コンピュータが収集した収集時点からの、経過時間を認識し、
前記経過時間が長いほど大きくなるように定義された閾値を、前記経過時間に基づいて取得し、
前記１台以上の端末のうち少なくとも１台の端末について、
当該端末の存在する第２の位置を認識し、
前記第１の位置と前記第２の位置の間の距離を計算し、
前記距離が前記閾値未満のとき、当該端末に対して、前記データ記憶装置に記憶されているデータの当該端末への転送のための第１の指示を当該端末のユーザに対して与えるよう、第２の指示を与える
ことを特徴とする方法。
【図１】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図１３】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図１３】
【公開番号】特開２０１３−３８５３５（Ｐ２０１３−３８５３５Ａ）
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願番号】特願２０１１−１７１７４６（Ｐ２０１１−１７１７４６）
【出願日】平成２３年８月５日（２０１１．８．５）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願日】平成２３年８月５日（２０１１．８．５）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]