天候検知装置及び天候情報収集システム
【課題】観測地点が高密度の観測網を安価に形成する天候検知装置及び天候情報収集システムを提供する。
【解決手段】傘取り付け部２００３を介して傘に無線ＩＤタグ２００４が取り付けられる。携帯情報端末２００５の無線タグ読取装置２００７は、傘利用時に無線ＩＤタグ２００４を読み取り可能な距離が設定されており、無線ＩＤタグ２００４の読み取りを行う。傘利用判定部２００８は、読み取ったＩＤとメモリ２００９に予め登録されたＩＤとが一致する場合に、傘を利用していると判定し、ＩＤを読みとれなかった場合及びメモリ２００９に登録されたＩＤと一致しない場合、傘を利用していないと判定する。すなわち、降雨の有無を判定する。
【解決手段】傘取り付け部２００３を介して傘に無線ＩＤタグ２００４が取り付けられる。携帯情報端末２００５の無線タグ読取装置２００７は、傘利用時に無線ＩＤタグ２００４を読み取り可能な距離が設定されており、無線ＩＤタグ２００４の読み取りを行う。傘利用判定部２００８は、読み取ったＩＤとメモリ２００９に予め登録されたＩＤとが一致する場合に、傘を利用していると判定し、ＩＤを読みとれなかった場合及びメモリ２００９に登録されたＩＤと一致しない場合、傘を利用していないと判定する。すなわち、降雨の有無を判定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ある地点における現在の天候を検知する天候検知装置と、様々な場所に配置された多数の天候検知装置によって観測された天候情報を収集して解析する天候情報収集システムに関する。
【背景技術】
【０００２】
近年、東京等の都会地域においては、夏季に突然現われる集中豪雨、いわゆるゲリラ雷雨の被害が問題となっており、早急な観測体制が望まれている。しかし、従来の、例えば気象庁の地域気象観測システム（通称、アメダス）における観測装置は、１７ｋｍ四方に一台程度の密度で、１０分に１度程度の頻度で観測データを収集することしかできない。これに対して、ゲリラ雷雨はごく狭い地域に短時間で集中して雨が降る局地現象であり、現在の気象観測網では網が粗すぎ、正確な観測が難しい。
【０００３】
そこで、ゲリラ雷雨等局地気象の現況情報収集には、現在の観測網よりさらにきめ細かい多地点での降雨観測が必要だが、従来の気象観測装置は高価かつ大型であり、都会では設置する場所にも制約がある。このため、極めて安価な降雨観測装置を多地点に配することができる降雨観測の仕組み、及び、それに供する降雨検知装置やその情報を収集するシステムの開発が望まれている。
【０００４】
このようなシステムの一例として、株式会社ウェザーニューズ社（以下、ＷＮＩ）の「ゲリラ雷雨メールサービス」がある。これは、ＷＮＩの天気予報サービス会員が、目視や空の写真撮影により天候を観測し、それを携帯電話メール経由でＷＮＩに送付し、ＷＮＩが集計し、ゲリラ雷雨を予測するというものである（非特許文献１参照）。
【０００５】
また、他のシステムとして、自動車のワイパーの動作を降雨の有無に関連付け、各自動車の走行地点における降雨の有無を収集するシステムが特許文献１及び非特許文献２等に開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００５−１１５８５４号公報
【非特許文献】
【０００７】
【非特許文献１】http://weathernews.jp/observation/
【非特許文献２】http://www.internetits.org/ja/projects/pdf/nagoya-press020124.pdf
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、非特許文献１に開示の技術では、天気予報サービス会員が、天候を観測し、情報を提供するという手間をかけなければならず、観測地点及び観測頻度が高密度の観測網による安定したサービスを長期にわたって維持するのは困難である。
【０００９】
また、特許文献１及び非特許文献２に開示の技術では、このような装置の設置費用を負担する自動車ユーザがそれに見合う利益を享受するものではなく、このようなシステムを普及させるのは困難である。
【００１０】
本発明の目的は、観測地点が高密度の観測網を安価に形成する天候検知装置及び天候情報収集システムを提供することである。
【課題を解決するための手段】
【００１１】
本発明の天候検知装置は、傘に取り付けられる無線ＩＤタグと、傘利用時の前記無線ＩＤタグとの距離が読み取り可能な距離に設定され、前記無線ＩＤタグを読み取る読み取り手段と、前記無線ＩＤタグが読み取れた場合、傘が利用されていると判定し、前記無線ＩＤタグが読み取れない場合、傘が利用されていないと判定する判定手段と、を具備する構成を採る。
【００１２】
本発明の天候情報収集システムは、傘に取り付けられる無線ＩＤタグと、傘利用時の前記無線ＩＤタグとの距離が読み取り可能な距離に設定され、前記無線ＩＤタグを読み取る読み取り手段と、前記無線ＩＤタグが読み取れた場合、傘が利用されていると判定し、前記無線ＩＤタグが読み取れない場合、傘が利用されていないと判定する判定手段と、現在地を示す位置情報を取得する位置情報取得手段と、前記位置情報及び傘の利用状態を示す傘利用情報を含む天候情報を送信する送信手段と、を有する天候検知装置と、前記天候検知装置から送信された天候情報に基づいて、前記天候検知装置の信頼度を算出する信頼度算出手段と、前記信頼度に基づいて、前記天候情報をフィルタリングするフィルタリング手段と、フィルタリングされた前記天候情報を用いて現時点における気象現況を示す統合天候情報を作成する作成手段と、を有する天候情報サーバと、を具備する構成を採る。
【発明の効果】
【００１３】
本発明によれば、観測地点が高密度の観測網を安価に形成することができる。
【図面の簡単な説明】
【００１４】
【図１】実施の形態１に係る天候検知装置の構成を示すブロック図
【図２】天候検知装置を実際に用いる場合の模式図
【図３】傘利用検知装置を傘に取り付けた様子を示す模式図
【図４】傘利用検知装置を傘に取り付けた他の様子を示す模式図
【図５】転倒検出センサを加えた構成を示すブロック図
【図６】実施の形態２に係る天候検知装置の利用形態を示す図
【図７】実施の形態３に係る天候情報収集システムの構成を示すブロック図
【図８】タイマーイベント（傘利用判定）のイベント処理の手順を示すフロー図
【図９】パラメータテーブルを示す図
【図１０】気象観測データ取得部の従うアルゴリズムを示すフロー図
【図１１】統合天候情報作成公開部の従うアルゴリズムを示すフロー図
【図１２】天候情報サーバ制御部の従うアルゴリズムを示すフロー図
【図１３】降雨判定の説明に供する図
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００１６】
（実施の形態１）
実施の形態１では、図１〜３を用いて本発明の天候検知装置の最小の構成について説明する。図１は、実施の形態１の天候検知装置２００１の構成図であり、図１（ａ）と図１（ｂ）とでは、物理的な形態が異なるが基本的には同じ内部構成を持つ。
【００１７】
２００２は、傘利用検知装置であり、傘取り付け部２００３と無線ＩＤタグ２００４から構成される。２００５は、携帯情報端末であり、この端末は、天候アプリ制御部２００６と、無線タグ読取装置２００７と傘利用判定部２００８とメモリ２００９から構成される。なお、携帯情報端末２００５は、スマートフォンや携帯電話として実装されることを想定しており、これらモジュールの他に、通常のスマートフォンや携帯電話が備えているようなモジュールを備えているとする。
【００１８】
天候アプリ制御部２００６は、ユーザの明示的な指示等で起動され、その後、他モジュールを制御して、初期設定及び天候検知動作を行わせる。具体的なアルゴリズムについては、後述する。
【００１９】
無線ＩＤタグ２００４は、ＲＦＩＤ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）タグ、無線タグとも呼称され、無線タグ読取装置２００７から無線電波による問い合わせを受けると、内部の保持しているＩＤを返す。
【００２０】
本実施の形態では、電源を要しないパッシブ型の無線ＩＤタグを想定しているが、これはタグが安価だからであり、アクティブ型の無線ＩＤタグでも利用することができる。なお、無線ＩＤタグと無線タグ読取装置間には、読み取り可能な距離（読取距離）があるが、本実施の形態では、読取距離がある一定の範囲内にあることが必要である。すなわち、読取距離は、天候検知装置の想定ユーザのうち典型的ユーザが、雨天時に傘をさした時の傘中央（傘を張った場合の下ろくろの位置）とユーザの頭の距離よりも大きく、ユーザの腰部とユーザの頭の距離程度よりも小さいものであることが必要である。この理由は後述する。
【００２１】
図１（ａ）は、１つの筐体内に全てのモジュールが内蔵されている場合で、図１（ｂ）は、無線タグ読取装置を携帯情報端末２００５の筐体内から取り出し、その間をケーブル２０１１で結んだ構成である。物理的形態が２通りある理由は後述する。
【００２２】
図２は、天候検知装置を実際に用いる場合の模式図である。３００１は、傘利用検知装置であり、３００２は、携帯情報端末である。３００３は傘であり、傘利用検知装置３００１は、傘３００３の受け骨に取り付けられている。３００４は、ユーザである。
【００２３】
図２（ａ）は、ユーザ３００４が、傘３００３を利用している（つまり、「傘をさしている」）場合で、図２（ｂ）は、傘を利用していないし、携帯もしていない場合で、図２（ｃ）は、傘を携帯している（この場合は手で持って運んでいる）場合である。
【００２４】
３００５は、無線タグ読取装置２００７の読取範囲を模式的に表したものである。
【００２５】
図３は、傘利用検知装置を傘に取り付けた場合の模式図である。図３（ａ）は、傘全体を見渡した図であり、図３（ｂ）は、図３（ａ）の破線で丸く囲んだ部分を拡大したものである。
【００２６】
６００１は、無線ＩＤタグであり、傘取り付け部６００２を介して、傘の受け骨の一本の６００３に取り付けられている。傘取り付け部６００２は、図７の１０１１、図１の２００３と同じもので、紐やカラビナ、針金、フック等、受け骨にぶらさげられるものであれば、どのようなものでもよい。さらには、このように物理的な形状を用いて引っ掛けるものではなくて、例えば接着剤、両面テープなどの粘着性を利用して傘の任意の部分に接着させるものであったり、磁石などの磁力で接着させるものであったり、そもそも最初から傘内部の任意の場所に組み込んであってもよい。例えば、図４の（ａ）のように、中棒の上の方（７００１）や、図４（ｂ）の手元部分（７００２）に貼付してもよい。なお、傘の構成は、図３（ａ）に示す通り、石突６００６、親骨６００７、はじき６００８、玉留６００９及び手元６０１０を備えている。
【００２７】
次に、以上のように構成された天候検知装置について、その動作を説明する。まず、この天候検知装置２００１の初期設定を行う。天候アプリ制御部２００６には、初期設定モードが備わっているとする。初期設定モード中では、無線タグ読取装置２００７は無線ＩＤタグの読取動作に入り、無線ＩＤタグ２００４が内部に保持しているＩＤを読み取ると、天候アプリ制御部２００６は、それをメモリ２００９内に記憶する。記憶させたところで、初期設定モードが終了する。
【００２８】
初期設定モードの起動は、ユーザ等の指示によって開始され、その後、ユーザは無線ＩＤタグ２００４と無線タグ読取装置２００７を読み取り可能距離以下に接近させる。その後、自動的に初期設定モードは終了する。
【００２９】
初期設定により、無線ＩＤタグ２００４のＩＤが取得できたが、これは、他の用途に利用されている無線ＩＤタグと本発明の用途に利用される無線ＩＤタグを区別するために利用される。よって、無線タグ読取装置２００７が読み取れるタグは、傘利用検知にしか利用されないのであれば、この初期設定は省略することが可能である。
【００３０】
次に、天候検知装置２００１を利用するには、傘利用検知装置２００２と携帯情報端末２００５が、所定の位置に取り付けてある必要がある。まず、傘利用検知装置２００２は、ユーザ３００４が利用している傘に取りつけられている必要がある。この取り付け方法に関しては、前述した通りである。
【００３１】
一方、携帯情報端末２００５は、ユーザ３００４の頭部３００２に装着されているか、または、少なくとも無線タグ読取装置２００７が頭部３００２に装着される必要がある。前者の場合の携帯情報端末の構成を表した模式図が、図１（ａ）であり、後者が図１（ｂ）である。
【００３２】
携帯電話のような手持ちが前提のモバイル端末を頭部に装着するのではなく、これは、ヘッドマウントディスプレーやヘッドセットを入出力装置として持つ携帯情報端末（またはウェアラブルコンピュータ）を前提として考えたものである。例えば、ヘッドマウントディスプレーとスマートフォン上に、本携帯情報端末２００５が実装されている場合に、ヘッドマウントディスプレー内に本携帯情報端末２００５全てを格納することも可能であるし（図１（ａ）の場合）、無線タグ読取装置２００７のみヘッドマウントディスプレー内に実装し、残りのモジュールは、スマートフォン内に実装し、その間をケーブルで繋ぐことも可能である（図１（ｂ）の場合、ここでケーブルは、２０１１を指す）。
【００３３】
いずれにしろ、無線タグ読取装置２００７は、ユーザ３００４の頭部３００２に装着されることとなる。
【００３４】
さて、天候検知装置２００１を所定位置に装着した後、ユーザの指示等により天候アプリ制御部２００６が起動される。当然ながら、ユーザが起動せずとも、携帯情報端末２００５が起動すれば自動で起動されるようにしてもよい。
【００３５】
起動後、天候アプリ制御部２００６は、以下の（１）から（４）を、繰り返す。
【００３６】
（１） 無線タグ読取装置２００７を起動し、無線ＩＤタグの読取を行う。
【００３７】
（２） 読取に失敗したら、ＩＤは不定値のまま（３）に進む。成功したら、傘利用判定部２００８に読みとったＩＤを渡す。
【００３８】
（３） 傘利用判定部２００８は、読み取ったＩＤをメモリ２００９内に格納されているＩＤと比較し、同一であれば、傘が利用されていると判定する。すなわち降雨があると判断できる。そうでなければ、傘は不利用と判定する。ＩＤが不定値の場合も傘は不利用と判定する。傘の不利用は降雨なしとの判定となる。
【００３９】
この判定をメモリ２００９の所定部分に記録する。
【００４０】
なお、前述したように、初期設定が不要な場合は、傘利用判定部は、常に傘利用すなわち降雨の判定を下す。
【００４１】
（４） 一定時間休止する。
【００４２】
ここで、ステップ（３）の判断ができる理由について図２を使って説明する。図２の３００５は、無線タグ読取装置３００２の読取可能範囲を表わしたものである。読取可能範囲３００５は、典型ユーザが傘をさしている場合の頭部から傘中央（下ろくろ）までの距離より大きく、頭部から腰部の距離より小さいよう調整してある。よって、典型ユーザとほぼ同じ体格のユーザであれば（ユーザ３００４は、そうだとする）、傘利用の場合（図２（ａ））は、読取可能となる。
【００４３】
一方、不利用の場合（図２（ｂ）、傘を傘立などに放置し、ユーザの身近にない場合）や、傘を持ち運んでいる場合（図２（ｃ））などは、傘中心に取りつけられた無線ＩＤタグ２００４は、読取可能範囲３００５の圏外に出るために、読み取れないこととなる。よって、読み取りの可否から、傘を利用しているかどうかが推測でき、さらに、ユーザの周囲の降雨は現時点であるのかないのかも推測できることとなる。
【００４４】
ここで、読取可能範囲３００５の大きさの決め方について補足しておく。まず読取可能範囲３００５の大きさについては固定でも可変でもよい。固定の場合は、天候検知装置２００１の想定ユーザのうち、典型的ユーザの体格や傘のさし方に合わせて、予め読取可能範囲３００５の大きさを設定しておく。これに対して、読取可能範囲３００５が可変の場合は、個々のユーザに合わせて読取可能範囲３００５を設定することで、天候検知装置２００１の精度を向上させることができる。
【００４５】
これには、例えば、あるユーザが天候検出装置２００１を初めて使う場合に、携帯情報端末２００５からユーザに傘を挿すように指示し、その状態で読取可能範囲３００５を小さな値から大きな値まで変化させ、無線ＩＤタグ２００４が読取可能な読取可能範囲３００５の大きさを調べる（この半径をＲ１とする。Ｒ１は１つの値ではなく数値の集合である）、次にユーザに傘挿しをやめて移動中のように傘を保持するように指示したところで、同様に読取可能範囲３００５を変化させ読取可能な読取可能範囲３００５の大きさを検出する（この半径をＲ２とする。Ｒ２も数値の集合である）。その上で、読取可能範囲３００５の半径を、Ｒ１の最小値より大きく、Ｒ２の最小値より小さいように設定すれば、適切な読取可能範囲３００５の設定ができる。
【００４６】
また、自動計測するのではなく、ユーザに利用状況を入力させ、その値に従い読取可能範囲３００５の設定をすることもできる。つまり、ユーザの身体的特徴（身長や性別、利き手）、情報携帯端末２００５の使い方（普段どこに入れて持ち歩くのか）、傘の使い方や種類（持ち歩くときはどうやっているのか、折り畳み傘か、大きさ、傘はどちらの手で持つか）、傘利用検知装置２００２はどこに取り付けたかなどを、ユーザに情報携帯端末２００５を通じて入力させる。すると、ユーザの傘利用時と非利用時における情報携帯端末２００５と傘利用検知装置２００２との距離がそれぞれ、Ｒ１、Ｒ２と推定できるから、読取可能範囲３００５の大きさは、Ｒ１とＲ２の間（中間）の値に設定してやればよい。
【００４７】
なお、読取可能範囲３００５を可変とするための方法については、無線タグ読取装置２００７や無線ＩＤタグ２００４の電波強度や感度を可変とする方法も他に、ソフトウエア的に擬似的に読取範囲を可変とする方法がある。後者については実施の形態３で述べる。
【００４８】
このように実施の形態１によれば、傘に無線ＩＤタグを取り付け、傘利用時に無線ＩＤタグを読み取り可能な距離が設定された携帯情報端末が無線ＩＤタグの読み取りを行い、無線ＩＤタグの読み取りの可否に応じて、傘の利用又は不利用、すなわち、降雨の有無を判定することにより、安価な無線ＩＤタグを傘に取り付けるという簡易な手順で天候情報を取得することができるので、観測地点が高密度の観測網を容易に形成することができる。
【００４９】
（実施の形態２）
実施の形態２では、実施の形態１の無線ＩＤタグに簡単なセンサを組み合わせることで、降雨の推測をより確からしいものにできることを示す。
【００５０】
本実施の形態の天候検知装置も、図１のような構成をしている。ただし、無線ＩＤタグ２００４に転倒検出センサ（または転倒検出スイッチ、転倒スイッチとも呼ばれる）を付け加える。
【００５１】
図５に転倒検出センサを加えた一例を示す。図５（ａ）は、転倒検出センサを加える前の典型的な無線ＩＤタグの構成図であり、図５（ｂ）は、その外観の模式図である。
【００５２】
無線ＩＤタグは、ＩＤが記憶されているメモリ５００５と、外部からの電波を受信したり、また送信したりするループアンテナ部５００２と、外部からのＩＤの読み出し要求を解釈し、それに対してＩＤをメモリ５００５から読み出し、データ送受信部５００３を使ってＩＤを返す制御部５００４からなる。データ送受信部５００３、制御部５００４、メモリ５００５は、１つのＩＣチップ（ＩＣ部５００６）としてまとめられており、それに比べて、ループアンテナ部５００２は、巨大で、例えば図５（ｂ）に示したような外観を呈している。
【００５３】
このような無線ＩＤタグ５００１に、転倒検出センサを加えて、無線ＩＤタグに鉛直方向を定義し、その鉛直方向から無線ＩＤタグがある角度以上傾いた場合は、無線ＩＤタグが機能しないようにすることができる。ここで、無線ＩＤタグが機能しない（機能オフ）とは、外部から無線ＩＤタグの読み出し命令があった場合でも、それに対して応答しないことをいう。
【００５４】
図５（ｃ）は、その構成図で、図５（ｄ）は、その外観の模式図である。鉛直方向（上方向）は、図５（ｄ）の矢印に示した通りの向きである。
【００５５】
ここでは、転倒検出センサとして、水銀スイッチを利用するとする。この場合、構成は単純で、図５（ｃ）のように、５０１２部分の配線を切断し、その間に転倒検出センサ（水銀スイッチ）５０１１を挿入する。あとは、図５（ｄ）のように、水銀スイッチ５０１１の方向を調節して、鉛直方向に無線ＩＤタグがある場合に、スイッチが入り、鉛直方向からある程度（例えば４５°程度）以上傾いた場合にはスイッチが切れるようにすればよい。
【００５６】
なお、水銀スイッチは、構造が簡単で非常に廉価であるが、水銀の毒性も心配されるため、その代替品として、加速度センサや金属球によるスイッチを利用することもできる。金属球による転倒検出スイッチの場合は、水銀スイッチと構成の方法は同様である。
【００５７】
加速度センサを使う場合は、無線ＩＤタグの内部に加速度センサの加速度値から、無線ＩＤタグ全体の傾きを演算して、傾きがある程度以上の場合は、無線ＩＤタグが機能しないようにすることとしてもよい。または、そのような傾き計算や機能をオフにすることは、携帯情報端末２００５の傘利用判定部２００８が行い、無線ＩＤタグは、傾きに関係なくオン状態のまま、ＩＤとともに、加速度値を返すようにしてもよい。具体的には、無線ＩＤタグからＩＤ及び加速度値を取得した傘利用判定部２００８は、傾斜角が一定の範囲内の場合、傘が利用されていると判定し、傾斜角が一定以上となった場合、傘が利用されていないと判定する。
【００５８】
このように構成した転倒検出センサつき無線ＩＤタグを傘のとりつけた様子を図３に示す。図３の（ａ）は、全体図で、図３（ｂ）が、その取り付け部分（図３（ａ）の破線で囲んだところ）を拡大したものである。
【００５９】
転倒検出センサ付き無線ＩＤタグ６００１には、傘取り付け部６００２をつけ、傘にとりつけられるようにする。傘取り付け部６００２は、紐や針金等で結んで使うものでもよいしフックやカラビナなどの取りつけ具でもよい。つまり、簡単に傘の骨（受骨）にとりつけ、そのままぶら下げることができるものならばよい。あるいは、粘着テープのようなもので、傘の中棒６００４に貼って固定するものでもよい。この固定タイプの場合は、無線ＩＤタグの上方向と、傘の上方向が一致させて貼ることが必要である。
【００６０】
図３（ａ）は、受骨６００３に無線ＩＤタグを吊した例である。本実施の形態では、受骨に吊したが、親骨６００７に吊しても問題はない。図３の例では、受骨６００３に無線ＩＤタグ６００１は吊されていることで、無線ＩＤタグ６００１の上方向が、重力の鉛直上方の方向と一致するために、無線ＩＤタグの機能はオンになっている。
【００６１】
図６（ａ）〜（ｃ）には、実施の形態１に係る天候検知装置の利用形態を示す。いずれの場合にもユーザ４０００は、携帯情報端末４００１を胸のポケット等に入れているとする。また、本実施の形態では、無線タグ読取装置２００７が、無線ＩＤタグ２００４を読みとれる距離は、１メートル以上（平均的なユーザの身長の５〜６割程度以上）とする。
【００６２】
このような利用形態において、図６（ａ）の「傘を利用している場合」は携帯情報端末４００１と、傘利用検知装置４００２との距離は１メートル以下で、かつ、傘利用検知装置４００２は、傘が開いている状態では吊り下っている状態であるから、転倒検出センサの働きにより機能がオンになっている。つまり、この場合、携帯情報端末４００１は、傘利用検知装置４００２から、そのＩＤを読み取ることができる。
【００６３】
図６（ｂ）の「傘不利用の場合」であるが、通常傘を利用していない場合は、傘立に入っていたりしているはずで、ユーザから離れているところにおかれるし、また、傘も石突方向を下に向けて畳んでおくので、転倒検出センサの働きて機能がオフになることが多いと考えられる。よって、この場合は、携帯情報端末４００１は、傘利用検知装置４００２から、そのＩＤを読み取ることができない。
【００６４】
図６（ｃ）の「傘携帯の場合」であるが、携帯の場合は、図のように手で傘の手元６０１０を持ったり、あるいは、折り畳み傘であれば、畳んでカバンの中等に寝せていれておいたりする。この図６（ｃ）の場合は、携帯情報端末４００１と傘利用検知装置４００２の距離的には、読取可能範囲に入っていることが多いと考えられるが、転倒検出センサの働きで機能はオフになることが多いと考えらえる。よって、この場合は、携帯情報端末４００１は、傘利用検知装置４００２から、そのＩＤを読み取ることができない。
【００６５】
これに対して、実施の形態１の仕組みでは、情報端末４００１と、傘利用検知装置４００２の距離だけで、ＩＤの読取の成否が決まってしまうから、例えば、図６（ｃ）のような場合は、ＩＤは読取可能で、すなわち傘利用判定部２００８は、傘を利用しているとの誤った判定を下すことであろう。
【００６６】
ここで、転倒検出センサとして加速度センサを利用する場合について補足する。転倒検出センサとして加速度センサを利用する場合は、傘が何度傾いているかの角度が分かるが、この傾きをある閾値（パラメータ）と比較して転倒の判断をすることとなる。つまり、加速度センサによって得られた傾きが、メモリ２００９に保持されている当該パラメータを超えている場合は、転倒とみなすような計算が行われる（これについては、実施の形態３にてより詳しく述べる）。メモリ２００９に保持されたそのパラメータは、初期値として当該天候検知装置２００１が想定する典型ユーザに合わせたデフォルト値が設定されていることになるが、これを、各個別のユーザに合わせて設定しなおすことも可能であり、そうすれば天候検出の精度に寄与することになる。
【００６７】
パラメータの設定の方法については、実施の形態１に示したと同じように、例えば利用初回時に、実際にユーザに傘を挿させて、その傾きを測定し（Ｖとする）、そのＶの値に多少余裕を持たせて、傾き閾値のパラメータとして設定してやればよい。例えば、Ｖ値の１割増しをパラメータとして設定するなどである。または、Ｖは何度も測定し、その中の最大値をパラメータとして設定すれば、より天候検出の精度が上がることが期待できる。
【００６８】
また、実施の形態１の場合と同様に、自動計測するのではなく、ユーザに利用状況を入力させ、その値に従いパラメータの設定をすることもできる。
【００６９】
このように実施の形態２によれば、転倒検出センサを傘利用検知装置に組み込むことにより、より正確に傘利用を推測することができる。
【００７０】
（実施の形態３）
実施の形態３では、実施の形態１または実施の形態２で説明したような傘側の装置単独による判断に加えて、傘の降雨推定データを収集サーバに収集し、データ全体に確率的な判断を加えることで、より推定を精密にできることを示す。同時に、収集サーバから、傘側にその傘が出した降雨判定の確からしさについてフィードバックをかけることで、傘単独での降雨推定の精度をあげることができることを示す。
【００７１】
図７を用いて、本発明の実施の形態３に係る天候情報収集システムの構成を説明する。まず、１０００は天候検知装置である。天候検知装置１０００は、傘利用検知装置１０１０と携帯情報端末１０２０から構成される。
【００７２】
傘利用検知装置１０１０は、傘取り付け部１０１１と無線センサタグ１０１２から構成され、これは、第２の実施の形態で示した転倒検出センサつき無線ＩＤタグ５０１０と同様のものである。ただし、本実施の形態では、転倒検出スイッチとして加速度センサを用いるとする。つまり、無線センサタグ１０１２は、外部からの読取要求に応じて、無線センサタグ１０１２が保持するＩＤと、加速度値を渡すことができる。加速度値としては、傘利用検知装置の鉛直方向（図３（ｂ）の矢印方向）を算出できるだけの加速度値が渡されるとする。
【００７３】
ここでは説明の便宜上、無線センサタグ１０１２には、１軸の加速度センサが内蔵されており、それは、傘利用検知装置の鉛直方向の下方向向きの加速度を計測しているとする。これは、３軸の加速度センサを搭載して、傘利用検知装置の鉛直方向の下方向向きの加速度成分を計算しても同等である。
【００７４】
携帯情報端末１０２０は、無線センサタグ１０１２から読みとった、ＩＤ値と加速度値等から傘利用判定を行い、それをあらかじめ定められた天候情報サーバ１０４０に渡すとともに、天候情報サーバ１０４０からは、各種天気現況あるいは予報を受けとり、それをユーザに提示することができる。さらには、天候情報サーバ１０４０から受けとった情報をもとに、より傘利用判定を正確にするための学習を行うこともできる。
【００７５】
本実施の形態では、説明のため、これらの機能はアプリケーションとして１つにまとめられているとし、そのアプリケーションが天候アプリ制御部１０２１である。天候アプリ制御部１０２１は、ユーザインタフェース１０２８と介して、ユーザに情報を提示したり、ユーザから命令を受けとる。またユーザからの命令などの外部からの入力やイベントに従い、各種サブモジュールやメモリを参照書き込みしながら、処理を進めていくことができる。
【００７６】
１０２２〜１０２８は、サブモジュールである。
【００７７】
無線タグ読取装置１０２２は、読取命令を受けると、無線センサタグ１０１２から、ＩＤ、加速度値及び、無線センサタグが応答してきた電波強度を読み出すことができる。
【００７８】
傘利用判定部１０２３は、無線タグ読取装置１０２２が読んだ、ＩＤ、加速度値及び、無線センサタグが応答してきた電波強度及び、メモリ１０２９に記録されているパラメータ、信頼度から、傘利用判定を行うことができる。
【００７９】
１０２４は、広域位置情報取得部であり、現在地を示す位置情報を取得する。いわゆるＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）である。
【００８０】
１０２５は、気象情報閲覧アプリで、ネットワーク１０６０を通して、各気象サーバ（１０６１や１０４０）の気象データを閲覧することができる。
【００８１】
１０２６は、パラメータ学習部であり、より精度が高い傘利用判定、つまり降雨判定をするための学習を行う。
【００８２】
１０２７は、データ命令送受信部であり、ネットワーク１０６０を介してデータや命令の送受信を行うためのネットワークインタフェースである。１０２８は、ユーザインタフェースであり、さらにディスプレーやスピーカー、キーボード、マイク等の入出力デバイスやＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）システムからなる。
【００８３】
一方、天候情報サーバ１０４０は、多数の天候検知装置から情報を収集し、天気現況の解析を行うとともに、各天候検知装置があげてきた観測データの信頼度を計算することができる。そして、得られた天気現況や予報について、各天候検知装置に教えるとともに、信頼度をフィードバックすることができる。
【００８４】
１０４１〜１０４６は、天候情報サーバ１０４０のサブモジュールである。
【００８５】
１０４１の天候情報サーバ制御部は、各サブモジュールの動作制御を行う。
【００８６】
１０４２は、天候データ集計部であり、各天候検知装置からのデータを集計する。
【００８７】
１０４３は、信頼度算出手段としての端末信頼度学習更新部であり、過去の各天候検知装置からのデータと実際の天候情報に基づいて、各天候検知装置の信頼度を計算し直す。１０４４は、統合天候情報作成公開部であり、各天候検知装置に対して天候に関する現況、予報を公開するとともに、各天候検知装置にその信頼度をフィードバックする。１０４５は、天候情報サーバ１０４０外から、気象観測データを取得するものである。１０４６は、データ命令送受信部であり、ネットワーク１０６０を介してデータや命令の送受信を行うためのネットワークインタフェースである。
【００８８】
１０４７はメモリであり、データを記録し、書き変え、削除することができる。
【００８９】
１００１は、気象データサーバであり、公設の天気情報組織や民間の天気予報会社等のデータサーバであって、そこには、信頼度が非常に高い気象観測装置で観測された（例えばアメダスの観測値）データ（１０６２）が記録されており、ネットワーク１０６０を通して、天候情報サーバ１０４０は、データを参照することができるものとする。なお、アメダス（ＡＭｅＤＡＳ： Ａｕｔｏｍａｔｅｄ Ｍｅｔｅｏｒｏｌｏｇｉｃａｌ Ｄａｔａ Ａｃｑｕｉｓｉｔｉｏｎ Ｓｙｓｔｅｍ）とは、気象庁の「地域気象観測システム」の愛称であり、日本全国の約１３００箇所に設置された観測機器から構成される。
【００９０】
１０６０は、ネットワークである。
【００９１】
以上のように構成された天候情報収集システムの動作を以下で説明する。
【００９２】
まず、天候検知装置１０００の概要と動作詳細を説明する。本システムでは、１つの天候情報サーバ１０４０に対して、複数の天候検知装置が対応している。天候検知装置のうち携帯情報端末部分は、それ専用の機器というよりは、携帯電話やスマートフォン、あるいは小型のノートＰＣに無線タグ読取機能を付加した構成を想定している。無線タグ読取機能は、携帯電話等に内蔵されていてもよいし、また、外付けされてもよい。さらに、傘利用検知装置に関しては、天候情報サーバを運営する会社や団体が、販売や配布することを仮定している。つまり、天候情報サーバ運営団体は、傘利用検知装置を多数のユーザに無料配布し、そのかわりに、傘利用判定部１０２３が出力する傘利用（つまり、降雨の有無）のデータを収集し、その運営団体自らの天候情報の精度向上に資する。
【００９３】
そのため、傘利用判定部の価格は、十分安価で大量に生産可能で、かつ、取り付けが容易なものでなければならない。また、ユーザが傘に取り付けるインセンティブとして、例えば、傘利用検知装置１０１０の外観をマスコット人形（例えば、てるてる坊主）、いわゆるフィギュア（アニメのキャラクターなどの立体造形物）、またはトレーディングカード風にしたりすることが有効である。同様に、ユーザが傘利用判定データを天候情報サーバ１０４０にアップロードする対価として、天候情報サーバ１０４０が集計し、見易いように加工したデータ（例えば、ユーザの詳細周辺地図に降雨地域を重ねて表示したもの）や、短時間局所の天気予報等を得られるようにする必要がある。
【００９４】
ユーザは、傘利用検知装置１０１０を手に入れ、自分の傘の所定部分（図３参照）に取りつけたとする。また、同時に自分の携帯情報端末（携帯電話やスマートフォン、通信機能つきノートＰＣ等）に、必要なソフトウエアをインストールする。必要なソフトウエアとは、天候アプリ制御部１０２１、傘利用判定部１０２３、パラメータ学習部１０２６等である。これらのアプリケーションのインストール方法は、ユーザの持つ携帯情報端末それぞれの方法で行う。
【００９５】
傘利用検知装置１０１０がユーザの傘に取り付けられ、携帯情報端末１０２０にも必要なソフトウエア等がインストールされると、天候アプリ制御部１０２１は、まず初期化動作を行う。いつの時点でどのように初期化を行うかは、ソフトウエアを使い易くするための工夫の範疇であり、例えば、ダウンロード直後に自動で始まる、最初に作動した時に自動で始まる、等が考えられる。具体的な初期化の内容であるが、天候アプリ制御部１０２１の動作に必要なパラメータ、信頼度、タグＩＤのデフォルト値への設定と、過去のセンサ測定値の無効化である。
【００９６】
天候アプリ制御部１０２１は、作動すると、必要な初期化処理を行ったのちに、イベント待ちとなる。天候アプリ制御部１０２１が待つイベントは、以下の２種類である。
（１） タイマーイベント（傘利用判定）
（２） パラメータ学習命令
【００９７】
以下では、図８のフローチャートを参照しながら、タイマーイベント（傘利用判定）のイベント処理について述べる。
【００９８】
傘利用判定のためのタイマーイベントは、パラメータテーブル１０３０に１つのパラメータとして格納されている「無線タグ読み取り間隔（図９のパラメータテーブル）」の間隔に従い発生するイベントであり、ここでは２分間隔でイベントが発生しているとする。
【００９９】
天候アプリ制御部１０２１は、そのタイマーイベントを受けとると、図８のフローチャートに従い、まず無線タグ読取装置１０２２を作動させ、無線センサタグ１０１２から読取を行う（９００１）。読取結果は、次の４つ組で表わされるとする。（ｒｅｓｕｌｔ ｌｅｖｅｌ ｉｄ ａｃｃ）
【０１００】
ここで、ｒｅｓｕｌｔは、無線センサタグ１０１２の読み取りができた場合には１、できなかった場合には０で示す。ｌｅｖｅｌは、無線センサタグ１０１２が返した応答の電界強度レベルで０〜１０の値を取る。ｉｄは、無線センサタグのＩＤで、適当なユニークな自然数である。ａｃｃは、鉛直方向の加速度である。傘が石突を上に直立していれば（傘をさしている場合）、９８０である（地球の重力加速度。単位はＧａｌ）。
【０１０１】
なお、本実施の形態では４つ組であるが、４つに限ることが必要なわけではない。他に有用なセンサを搭載可能であれば、例えば、センサのタイプ等が入ってもよいし、電子コンパスの値（方角）、気温、湿度など、各種センシングの値が考えられる。
【０１０２】
次に、ステップ９００１で取得したセンサ値の補正が必要であればこれを行う。例えば、本実施の形態では、説明を簡単にするために、加速度値（ａｃｃ）は、鉛直方向の値を直接とれるようにしているが、実際の生データは３軸の加速度（ｘ、ｙ、ｚ方向の加速度）値で、鉛直方向の値は計算が必要であったり、また、加速度値は細かく変動することが多いため、短時間に何回も計測して平均をとったりする必要がある。
【０１０３】
補正が終了すると、ＧＰＳから現在地情報を取得し、また、パラメータテーブル（１０３０、８０００）を読みこみ、また、過去のセンサ値も必要な分だけ読みこむ（９００２）。
【０１０４】
次に、傘利用判定のステップ９００３に進む。
【０１０５】
この判定式は、「傘を利用しているかどうか」を意味するもので、判定式が真（はい）の場合は、利用している、偽（いいえ）の場合は、利用していないことを意味する。なお、“＝”は等号を、“＞＝”は「以上」の判定を、“＞”は「より大きい」の判定を表し、“ａｎｄ”は論理的積のオペレータで、表記はＳ式で記載した。
【０１０６】
（（ｒｅｓｕｌｔ＝１）ａｎｄ
（ｉｄ＝（タグＩＤ１０３２に保持された値））ａｎｄ
（（ｌｅｖｅｌ＞＝（パラメータテーブル８０００の電界強度閾値の値））ａｎｄ
（ａｃｃ＞（パラメータテーブル８０００の傘傾き閾値の値）））
【０１０７】
判定式の１行目は、「無線タグが読みとれたか」を示す。読みとれなかった場合（値＝０）、少なくとも傘がユーザの近くにはないということを意味し、ユーザは傘を利用していないことが推測できる。
【０１０８】
次に、２行目であるが、タグＩＤ１０３２には、初期化時に記録されたタグのＩＤが記録されている。この記録されたＩＤと、今読みこんだＩＤが異なる（つまり２行目が偽）ということは、その無線タグが傘についているものではない（たまたま読取可能な同種の無線ＩＤが近くにあった）ことが推測でき、これもユーザが傘を利用していないことの根拠となる。
【０１０９】
３行目に関しては、後の学習過程で説明する。この時点では、パラメータテーブル８０００記載の電界強度閾値としては、０が入っているから、ここは常に真となる。
【０１１０】
４行目は、傘の傾きである。パラメータテーブル８０００の傘傾き閾値は８４９で、これは、９８０×ｃｏｓ（３０°）（Ｇａｌ）に相当する。つまり、３０°傘が傾いている時に観測されるべき鉛直下向きの加速度の大きさで、これ以下ということ（つまり４行目が偽）は、傘が３０°以上傾いているということで、これも傘を利用していないことが推測される。
【０１１１】
全体として真になれば、ユーザ傘を利用していると推測される。偽の場合は、利用していないと推測される。
【０１１２】
判定が出ると、次にステップ９００４に進む。ここでは、その判定結果に、ｉｄ値、ＧＰＳによる現在地情報を組みにして、データ・命令送受信部１０２７を利用して、天候情報サーバ１０４０に送付する。
【０１１３】
次に、データを受けとった天候情報サーバ１０４０の動作について説明する。
【０１１４】
サーバでは、天候情報サーバ制御部１０４１と統合天候情報作成公開部１０４４と気象観測データ取得部１０４５が同時並列に動作している。
【０１１５】
気象観測データ取得部１０４５は、図１０に示すアルゴリズムで動作する。つまり、周期的に外部の気象データサーバ１０６１が保持する気象観測データ１００２から、必要な気象観測データを取得してメモリ１０４７内に気象観測データ１０５０として記録する（１００２２）。
【０１１６】
取得する気象観測データとしては、各観測地点の気象観測値や雨のレーダーデータである。取得間隔は、取得対象の気象観測データの更新周期にあわせる。
【０１１７】
統合天候情報作成公開部１０４４は、図１１のアルゴリズムで動作する。これも、周期的に統合天候情報を作成し、メモリ１０４７に統合天候情報として記録する（１００１２）。統合天候情報は、気象観測データ取得部１０４５が取得した気象観測データ１０５０と、天候情報サーバ制御部１０４１が作成した天候データ１０４８をつきあわせて、信頼度が高いと思われる気象の現況及び予報を統合天候情報１０５１として作成する。
【０１１８】
天候情報サーバ制御部１０４１は、図１２のアルゴリズムで動作する。まず、天候情報サーバ制御部１０４１が、データ命令送受信部１０４６が、各天候検知装置から天候情報がアップロードされてくるのを監視している（図１２の１０００１）。
【０１１９】
ここで、天候情報が受信されると（１０００２）、そのデータを気象観測データ取得部１０４５が取得した気象観測データ１０５０と、各天候検知装置が送ってきたものに信頼度の修正を加えた天候データ１０４８と比較して、受信した天候情報の確度を計算し、それに基づきその天候情報を送った天候検知装置（以下、単に「端末」という場合は天候検知装置を指す）の信頼度を計算する（１０００３）。
【０１２０】
ここで、信頼度とは、端末がアップロードした天候データがそれを信頼すべきデータとして用いることができるかどうかの値である。
【０１２１】
信頼度の具体化には各種のものが考えられる。精密な計算を行う必要があれば、端末があげる天候データには確率的な揺らぎが存在すると考えて、そのゆらぎになんらかの確率分布を仮定して条件付確率としてとらえてもよい。また、確率ではなく、尤度の一種と考えてもよい。
【０１２２】
例えば、条件つき確率Ｐ（Ｘ｜Ｙ）を、Ｘは傘を用いたと検知される確率で、Ｙは、降雨の確率とすれば、ベイズ推定等を用いて、Ｐ（Ｙ｜Ｘ）、つまり、Ｘとの天候情報があげられた場合の、Ｙ（降雨）があった確率を推定することができる。
【０１２３】
ただし、Ｐ（Ｘ）のような、「傘を用いたと検知される確率」を表現するようなモデルは、ある程度複雑になり端末の数が膨大になると計算量も膨大になる一方、降雨の推定という点では、各々の端末の信頼度の不正確さは、端末の数でカバーできると考えられる。そこで、本実施の形態の場合は、確率モデルベースの信頼度は使わない。本実施の形態の場合、信頼度とは、端末がアップロードした天候データが「傘利用（すなわち降雨あり）」の場合、それを信頼すべきデータとして用いることができるかどうかの値であるが、これは確率や定義された尤度ではなく、直感的なものである。
【０１２４】
本実施の形態における信頼度は、０．０以上、１．０以下の値をとるとする。０の場合は、アップロードされた天候データは全く信用できない（正しい値かどうか不明）として、データから棄却される。１の場合は、信頼できる（つまり、その地点では必ず雨が降っている）という意味となる。
【０１２５】
さて、ここで信頼度の計算と更新が行われるが、その説明上で使われる記号の意味を先に述べておく。
【０１２６】
天候データ１０４８は、全端末からアップロードされたデータが蓄積されたテーブルで、各々の要素 ｗ（ｎ）は、次のように表現される。
【０１２７】
ｗ（ｎ）＝（ｉｄ ｔｉｍｅ ｐｏｓ ｒｅｓｕｌｔ ａｃｃ）、ｎは１〜現在格納された全要素の数
【０１２８】
ここで、ｉｄは、端末ＩＤ、ｔｉｍｅは登録日時、ｐｏｓは、位置情報（経度、緯度、光度）、ｒｅｓｕｌｔは、降雨の有無、ａｃｃは、傘鉛直方向の加速度である。天候データの要素は、ｉｄとｔｉｍｅの値でユニークに識別される。ｗ（ｎ）は、変数ｗのインデックスｎを表現するとする。信頼度は、端末データ１０４９中に、ｉｄに紐づけられて格納されているとする。また、今端末があげてきた天候情報を、ｗ（ｎ＋１）とする。
【０１２９】
信頼度の計算及び更新は、以下の（１）〜（４）のように行われる。
【０１３０】
（１） 信頼度は、端末データ１０４９内に、端末毎に１つ設定されている。
【０１３１】
（２） 初めて天候情報をアップロードしてきた端末に対しては、信頼度の初期値として、０．５が割りあてられ、（３）に進む。
【０１３２】
（３） 以下の順番で当該端末に対する信頼度を計算する。
【０１３３】
（３−１） 既に天候データ１０４８に格納されたデータからの信頼度の計算を行う。
【０１３４】
（３−１−１） ｗ（ｎ＋１）を基準に、ｔｉｍｅ値の差が２分以内であるもの、及び、ｐｏｓの値のずれが１００ｍ以内であるものを検索する。これをｗ（ｎ＋１）の近傍と呼ぶ。ｗ（ｋ）の近傍を、Ｓ（ｋ）で表わす。
【０１３５】
この結果を模式的に示したものが、図１３（ａ）である。これは、Ｓ（ｎ＋１）と、その周辺の天候データを地図風にプロットしたものである。黒丸はｗ（ｉ）のｒｅｓｕｌｔ値が１（降雨）のもの、白丸は０（降雨ではない）ものを示している。また×印（１１００１）は、ｗ（ｎ＋１）、つまり当該端末の場所を示す。このうち、半径Ｒ（＝１００メートル）以内（１１００２の破線円内）のものが、前述の近傍Ｓ（ｎ＋１）である。この例では、図１３（ａ）のＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆの集合が近傍である。
【０１３６】
（３−１−２） ｗ（ｎ＋１）近傍内での降雨判定を行う。これには、まず信頼度が低い天候データを排除（フィルタリング）し、次に降雨あり、降雨なしの天候データの数、信頼度を勘案して、降雨判定を行う。
【０１３７】
まず、近傍Ｓ（ｎ＋１）から、信頼度が一定の閾値未満の天候データを排除する。閾値としては、０．３を利用する。今回の場合は、Ｓ（ｎ＋１）＝｛Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ｝の信頼度は全て０．３を上回っているとして、排除されたものはないとする。
【０１３８】
次に降雨判定を行う。ここでは、単純に信頼度でフィルタリングされた後の近傍Ｓ（ｎ＋１）のデータでの多数決で行う。今回の場合では、降雨ありとしているのは、｛Ａ、Ｂ、Ｃ、Ｄ｝の４つ、降雨なしは、｛Ｅ、Ｆ｝の２つであるから、４対２で、この近傍での降雨判定は「あり」となる。
【０１３９】
なお、近傍に天候データがなかった場合は、判定はできない。また、同数であった場合は、降雨ありとする。
【０１４０】
信頼度を重みとした重みつき多数決（例えば１票に信頼度を掛けたものを合計する）をすれば、多少の精度の向上は得られると思われる（ただし、その分処理は遅くなる）。
【０１４１】
さらには、信頼度を尤度と捉え直して、ベイズ学習、ベイズ推定を利用すれば、信頼度の値自身が精度の高いものとなろう。ただし、このためには、学習過程（ここでは、天候データの実際の真偽をなんらかの形で取得しなければならない）と、もう少しの処理能力が必要となる。
【０１４２】
また、降雨判定に、アメダス等の信頼度が非常に高いデータを利用することも考えられようが、そもそも、この降雨判定は、アメダス等の信頼度が高いが、観測密度が場所的にも時間的にも疎である観測網のすきまを埋め（アメダスは、２００９年現在、観測地点間は１０キロメートル以上、時間的には１０分に一度程度の情報しかえられない）、また、降雨レーダー等のエラーや誤差を補うものであるため、この方法はあまり得策ではない。
【０１４３】
（３−１−３） 降雨判定と、ｗ（ｎ＋１）のｒｅｓｕｌｔ値に従い、ｗ（ｎ＋１）をアップロードした端末の信頼度（以下、ｌｌ（ｎ＋１）と表記）を更新する。
【０１４４】
以下のアルゴリズムで降雨判定を更新する。ここでは、ｗ（ｋ）はｗｋとし、ｗｋの要素はｗｋ＝（ｉｄｋ ｔｉｍｅｋ ｐｏｓｋ ｒｅｓｕｌｔｋ ａｃｃｋ）と表す。また、ｌｌｋはｗｋをアップロードした端末の信頼度とし、ＲＥＳは（３−１−２）で行われた降雨判定の値とし、降雨ありを１、降雨なしを０、不明を−１とする。
【０１４５】
（数１）
ｉｆ（ＲＥＳ＝＝ｒｅｓｕｌｔｋ）ｔｈｅｎ
ｌｌｋ＝（１−α）ｌｌｋ＋α …（１）
ｅｌｓｅｉｆ（ｎｏｔ（ＲＥＳ＝＝−１））ｔｈｅｎ
ｌｌｋ＝（ｌｌｋ−α）／（１−α） …（２）
ｅｌｓｅ（３−１−４）の更新手法を用いる
ｅｎｄ
【０１４６】
数１の式（１）及び式（２）中のαは、０より大きく１未満の数であり、本実施の形態では、０．３とする。このα及び式（１）、式（２）の更新のための式自体も、他の値や関数で置きかえ可能である。つまり、式（１）の場合は、連続適用した場合に漸近的に１の値に近づいていくような関数で、式（２）の場合は、逆に０に漸近的に近づく関数であればよい。
【０１４７】
数１の式（１）及び式（２）で、信頼度の更新が済んだ場合は、これで終了である。なお、数１の式（１）及び式（２）では、信頼度の変数への代入となっているが、実際には、端末データ１０４９内の信頼度が更新される。（３）に進んだ場合は、次の（３−１−４）で信頼度を更新する。
【０１４８】
（３−１−４） 近傍がなく、判定ができなかった場合の信頼度の更新は、アメダス等の気象観測データを利用して行う。
【０１４９】
図１３（ｂ）は、気象レーダーのデータを地図風に模式的に表わしたもので、１１０１１が、ｗ（ｎ＋１）の地点で、１１０１２が気象レーダーにより雨が降っているとされる地点である。この図から、１１０１１の地点では、気象レーダーの観測時点では降雨ありと観測されたと見ることができる。
【０１５０】
ただし、気象レーダーの値は、１０分あるいは５分間隔でしか更新されないため、このデータは過去のものであり、とくに変化が激しい雷雨のような場合には、問題が大きい。また、気象レーダーのデータには誤差（誤観測）もあるために、完全ではない。
【０１５１】
ここで、気象観測データによる降雨判定による信頼度の変更は、（３−１−３）で行った信頼度の変更の幅よりも小さくしたい。
【０１５２】
具体的には、以下の数２に従って更新を行う。ここでは、ｗ（ｋ）はｗｋとし、ｗｋの要素はｗｋ＝（ｉｄｋ ｔｉｍｅｋ ｐｏｓｋ ｒｅｓｕｌｔｋ ａｃｃｋ）と表す。また、ｌｌｋはｗｋをアップロードした端末の信頼度とし、ＲＥＳは気象観測データから得られた降雨判定の値とし、降雨ありを１、降雨なしを０とする。
【０１５３】
（数２）
ｉｆ（ＲＥＳ＝＝ｒｅｓｕｌｔｋ）ｔｈｅｎ
ｌｌｋ＝（１−β）ｌｌｋ＋β …（３）
ｅｌｓｅｉｆ（ｎｏｔ（ＲＥＳ＝＝−１））ｔｈｅｎ
ｌｌｋ＝（ｌｌｋ−β）／（１−β） …（４）
ｅｎｄ
【０１５４】
ここで、数２の式（３）、式（４）に出るパラメータβは、数１の式（１）、式（２）のパラメータαの値より小さなものとする。ここでは、０．１としておく。
【０１５５】
これで、信頼度の更新は終了する。
【０１５６】
（４） これで信頼度の計算と更新は終了である（図１２のステップ１０００５まで終了）。
【０１５７】
その端末の信頼度の計算が終わると、端末に新しい信頼度を告げる。これは、通常天候情報のアップロードと同一のコネクション内で行われる。例えばアップロードにＨＴＴＰを利用した場合、ＨＴＴＰの応答内で、天候情報サーバ１０４０から端末（天候検知装置１０００）側に伝えられる。
【０１５８】
以上のように、信頼度が更新される。これにより、継続的に間違いと思われるデータをアップロードし続ける端末の信頼度は徐々に下っていき、０に近づく。逆に、正しい情報をアップロードしていると思われる端末の信頼度は、徐々に高くなり１に近づく。
【０１５９】
今後天候情報サーバ制御部１０４１は、システム停止命令がない限り（ステップ１０００６）、新たな天候情報がアップロードされてくるのを待つ状態（ステップ１０００１）に戻る。
【０１６０】
次に、作成手段としての統合天候情報作成公開部１０４４が、これらの天候データ１０４８、端末データ１０４９から統合天候情報１０５１を作成する過程の説明を行う。図１１のアルゴリズムがこれに相当する。
【０１６１】
このアルゴリズムでは、周期動作を行うとしているが（ステップ１００１１）、周期動作ではなく、端末からある一定数（最小１でシステム全体の負荷で決定）アップロードがあった場合に動作を開始することと組みあわせてもよい。
【０１６２】
ステップ１００１２では、統合天候情報を作成または更新する。統合天候情報とは、気象観測データ１０５０と、天候データ１０４８、端末データ１０４９を統合して、現時点（または直前）での気象現況及び、短時間先の未来の予測データからなる。
【０１６３】
前者の気象観測現況は、天候データ１０４８から、最近の２分のデータを取得し信頼度でフィルタリングをかけたものと補助的に気象観測データ１０５０を用いて作成する。例えば、気象観測現況の対象地域に対して、どの地点で降雨があるのかを、天候データ１０４８と信頼度を用いて判断し、データがない地点に対しては、気象観測データ１０５０で補完する。さらに、できあがった気象現況情報から、気象予報技術を利用して短時間予報を作成したりする。
【０１６４】
最終的には、これら作成したデータは、統合天候情報として記録し、また外部に向けて公開できる形に整え（例えば、ＸＭＬ化やＨＴＭＬ化）、適当なプロトコル（例えば、ＨＴＴＰ）で公開する。
【０１６５】
以上のように、天候情報サーバ１０４０は動作する。
【０１６６】
最後に、天候情報サーバ１０４０へ天候情報をアップロードした後の端末（天候検知装置１０００）の動作を説明する。
【０１６７】
端末１０００は、天候情報サーバ１０４０にアップロードすると、その返答内で、端末自身に対する新しい信頼度を受けとる。
【０１６８】
端末１０００は、メモリ１０２９中に過去の信頼度を時系列で複数個記録しており（１０３１）、それを新しい信頼度と比較して下っている場合は、信頼度を回復すべく、パラメータ学習部１０２６はパラメータの調整を行う。パラメータは、図９に示したように４つあるが、このうち調整可能なのは、電界強度閾値と、傘傾き閾値の２つの閾値である。
【０１６９】
まず、電界強度閾値である。これは、傘利用探知装置１０１０から携帯情報端末１０２０への返しの電波が弱い場合を、傘が比較的遠くにある、すなわち、傘を利用していないとして切り捨てるための閾値である。この調節は、以下のように行う。
【０１７０】
今、直前にアップロードした気象情報の降雨判定をｒｅｓｕｌｔとして、ｒｅｓｕｌｔが降雨ありの場合は、電界強度閾値を一定数（Ｐとする）上げる。ｒｅｓｕｌｔが降雨なしの場合は、一定数下げることにより調節する。Ｐの値は、最大電界強度が１００として０〜２０程度をとる。
【０１７１】
次に傘傾き閾値であるが、ｒｅｓｕｌｔが降雨ありの場合は、傘傾き閾値を上げる。ｒｅｓｕｌｔが降雨なしの場合は、下げることにより調節する。なお、傘傾き閾値は、９８０×ｃｏｓ（θ）であり、初期状態ではθ＝３０°（０≦θ≦９０）である。上げ下げの調節は、θをＴずつ調節することで行い、Ｔは０〜５°程度とする。
【０１７２】
調節の幅Ｐ、Ｔは、一定値ではなく、信頼度が上った場合は、Ｐ、Ｔの値ともに小さくしていく。こうすることでパラメータが振動してしまうことを防ぐ。
【０１７３】
また、信頼度の値が、一定回数（例えば、１２０回＝４時間）連続して下りつづける、または、ある一定以下に下ったままである場合は、天候検知装置全体１０００のどこかに重大な問題があるとして、ユーザに警告を与えた上で、パラメータテーブル１０３０、信頼度１０３１、タグＩＤ１０３２を初期状態に戻す。これは、おそらくは、傘利用検知装置１０１１が間違った位置に取りつけられている、あるいは、使われていない傘に取りつけられた等している可能性が高いためである。
【０１７４】
なお、傘利用検知装置１０１０はユーザが自分の傘に取りつけるが、これは、なんらかのインセンティブがないとユーザはこの行動を起しにくい。ユーザが自ら装置の初期設定を行い、ユーザが天候情報をアップロードするには、天候情報サーバ側からユーザに対して、例えば、統合天候情報を配信する等のサービスが有効である。例えば、気象情報閲覧アプリ１０２５で、天候情報サーバ１０４０の天気予報を閲覧する場合に、もしその端末が天候情報をアップロードしている端末であれば、通常は課金されないと見られない情報を見られるようにするなどの工夫が考えられる。
【０１７５】
このように実施の形態３によれば、天候情報サーバは、多地点に位置する天候検知装置から天候情報を収集し、収集した天候情報に天候検知装置の信頼度に応じてフィルタリングを行い、フィルタリングした天候情報を用いて、現時点における気象現況を示す統合天候情を作成して公開することにより、高密度の観測地点から得られた天候情報を精度良く統合し、正確な気象データを提供することができる。
【産業上の利用可能性】
【０１７６】
本発明にかかる天候検知装置及び天候情報収集システムは、気象観測システム等に適用できる。
【符号の説明】
【０１７７】
１０００、２００１、２０１０ 天候検知装置
１００１ 気象データサーバ
１０１０、２００２、３００１、４００２、７００１、７００２ 傘利用検知装置
１０１１、２００３、６００２ 傘取り付け部
１０１２ 無線センサタグ
１０２０ 携帯情報端末
１０２１、２００６ 天候アプリ制御部
１０２２、２００７ 無線タグ読取装置
１０２３、２００８ 傘利用判定部
１０２４ 広域位置情報取得部
１０２５ 気象情報閲覧アプリ
１０２６ パラメータ学習部
１０２７、１０４６ データ・命令送受信部
１０２８ ユーザインタフェース
１０２９、１０４７、２００９、５００５ メモリ
１０４０ 天候情報サーバ
１０４１ 天候情報サーバ制御部
１０４２ 天候データ集計部
１０４３ 端末信頼度学習更新部
１０４４ 統合天候情報作成公開部
１０４５ 気象観測データ取得部
１０６０ ネットワーク
２００４、５００１、５０１０、６００１ 無線ＩＤタグ
２００５、３００２、４００１ 携帯情報端末
２０１１ ケーブル
２０１２ 読取部筐体
２０１３ 携帯情報端末本体
３００３ 傘
３００４、４０００ ユーザ
５００２ ループアンテナ部
５００３ データ送受信部
５００４ 制御部
５００６ ＩＣ部
５０１１ 転倒センサ
６００３ 受骨
６００４ 中棒
６００５ 下ろくろ
８０００ パラメータテーブル
【技術分野】
【０００１】
本発明は、ある地点における現在の天候を検知する天候検知装置と、様々な場所に配置された多数の天候検知装置によって観測された天候情報を収集して解析する天候情報収集システムに関する。
【背景技術】
【０００２】
近年、東京等の都会地域においては、夏季に突然現われる集中豪雨、いわゆるゲリラ雷雨の被害が問題となっており、早急な観測体制が望まれている。しかし、従来の、例えば気象庁の地域気象観測システム（通称、アメダス）における観測装置は、１７ｋｍ四方に一台程度の密度で、１０分に１度程度の頻度で観測データを収集することしかできない。これに対して、ゲリラ雷雨はごく狭い地域に短時間で集中して雨が降る局地現象であり、現在の気象観測網では網が粗すぎ、正確な観測が難しい。
【０００３】
そこで、ゲリラ雷雨等局地気象の現況情報収集には、現在の観測網よりさらにきめ細かい多地点での降雨観測が必要だが、従来の気象観測装置は高価かつ大型であり、都会では設置する場所にも制約がある。このため、極めて安価な降雨観測装置を多地点に配することができる降雨観測の仕組み、及び、それに供する降雨検知装置やその情報を収集するシステムの開発が望まれている。
【０００４】
このようなシステムの一例として、株式会社ウェザーニューズ社（以下、ＷＮＩ）の「ゲリラ雷雨メールサービス」がある。これは、ＷＮＩの天気予報サービス会員が、目視や空の写真撮影により天候を観測し、それを携帯電話メール経由でＷＮＩに送付し、ＷＮＩが集計し、ゲリラ雷雨を予測するというものである（非特許文献１参照）。
【０００５】
また、他のシステムとして、自動車のワイパーの動作を降雨の有無に関連付け、各自動車の走行地点における降雨の有無を収集するシステムが特許文献１及び非特許文献２等に開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００５−１１５８５４号公報
【非特許文献】
【０００７】
【非特許文献１】http://weathernews.jp/observation/
【非特許文献２】http://www.internetits.org/ja/projects/pdf/nagoya-press020124.pdf
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、非特許文献１に開示の技術では、天気予報サービス会員が、天候を観測し、情報を提供するという手間をかけなければならず、観測地点及び観測頻度が高密度の観測網による安定したサービスを長期にわたって維持するのは困難である。
【０００９】
また、特許文献１及び非特許文献２に開示の技術では、このような装置の設置費用を負担する自動車ユーザがそれに見合う利益を享受するものではなく、このようなシステムを普及させるのは困難である。
【００１０】
本発明の目的は、観測地点が高密度の観測網を安価に形成する天候検知装置及び天候情報収集システムを提供することである。
【課題を解決するための手段】
【００１１】
本発明の天候検知装置は、傘に取り付けられる無線ＩＤタグと、傘利用時の前記無線ＩＤタグとの距離が読み取り可能な距離に設定され、前記無線ＩＤタグを読み取る読み取り手段と、前記無線ＩＤタグが読み取れた場合、傘が利用されていると判定し、前記無線ＩＤタグが読み取れない場合、傘が利用されていないと判定する判定手段と、を具備する構成を採る。
【００１２】
本発明の天候情報収集システムは、傘に取り付けられる無線ＩＤタグと、傘利用時の前記無線ＩＤタグとの距離が読み取り可能な距離に設定され、前記無線ＩＤタグを読み取る読み取り手段と、前記無線ＩＤタグが読み取れた場合、傘が利用されていると判定し、前記無線ＩＤタグが読み取れない場合、傘が利用されていないと判定する判定手段と、現在地を示す位置情報を取得する位置情報取得手段と、前記位置情報及び傘の利用状態を示す傘利用情報を含む天候情報を送信する送信手段と、を有する天候検知装置と、前記天候検知装置から送信された天候情報に基づいて、前記天候検知装置の信頼度を算出する信頼度算出手段と、前記信頼度に基づいて、前記天候情報をフィルタリングするフィルタリング手段と、フィルタリングされた前記天候情報を用いて現時点における気象現況を示す統合天候情報を作成する作成手段と、を有する天候情報サーバと、を具備する構成を採る。
【発明の効果】
【００１３】
本発明によれば、観測地点が高密度の観測網を安価に形成することができる。
【図面の簡単な説明】
【００１４】
【図１】実施の形態１に係る天候検知装置の構成を示すブロック図
【図２】天候検知装置を実際に用いる場合の模式図
【図３】傘利用検知装置を傘に取り付けた様子を示す模式図
【図４】傘利用検知装置を傘に取り付けた他の様子を示す模式図
【図５】転倒検出センサを加えた構成を示すブロック図
【図６】実施の形態２に係る天候検知装置の利用形態を示す図
【図７】実施の形態３に係る天候情報収集システムの構成を示すブロック図
【図８】タイマーイベント（傘利用判定）のイベント処理の手順を示すフロー図
【図９】パラメータテーブルを示す図
【図１０】気象観測データ取得部の従うアルゴリズムを示すフロー図
【図１１】統合天候情報作成公開部の従うアルゴリズムを示すフロー図
【図１２】天候情報サーバ制御部の従うアルゴリズムを示すフロー図
【図１３】降雨判定の説明に供する図
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００１６】
（実施の形態１）
実施の形態１では、図１〜３を用いて本発明の天候検知装置の最小の構成について説明する。図１は、実施の形態１の天候検知装置２００１の構成図であり、図１（ａ）と図１（ｂ）とでは、物理的な形態が異なるが基本的には同じ内部構成を持つ。
【００１７】
２００２は、傘利用検知装置であり、傘取り付け部２００３と無線ＩＤタグ２００４から構成される。２００５は、携帯情報端末であり、この端末は、天候アプリ制御部２００６と、無線タグ読取装置２００７と傘利用判定部２００８とメモリ２００９から構成される。なお、携帯情報端末２００５は、スマートフォンや携帯電話として実装されることを想定しており、これらモジュールの他に、通常のスマートフォンや携帯電話が備えているようなモジュールを備えているとする。
【００１８】
天候アプリ制御部２００６は、ユーザの明示的な指示等で起動され、その後、他モジュールを制御して、初期設定及び天候検知動作を行わせる。具体的なアルゴリズムについては、後述する。
【００１９】
無線ＩＤタグ２００４は、ＲＦＩＤ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ ＩＤｅｎｔｉｆｉｃａｔｉｏｎ）タグ、無線タグとも呼称され、無線タグ読取装置２００７から無線電波による問い合わせを受けると、内部の保持しているＩＤを返す。
【００２０】
本実施の形態では、電源を要しないパッシブ型の無線ＩＤタグを想定しているが、これはタグが安価だからであり、アクティブ型の無線ＩＤタグでも利用することができる。なお、無線ＩＤタグと無線タグ読取装置間には、読み取り可能な距離（読取距離）があるが、本実施の形態では、読取距離がある一定の範囲内にあることが必要である。すなわち、読取距離は、天候検知装置の想定ユーザのうち典型的ユーザが、雨天時に傘をさした時の傘中央（傘を張った場合の下ろくろの位置）とユーザの頭の距離よりも大きく、ユーザの腰部とユーザの頭の距離程度よりも小さいものであることが必要である。この理由は後述する。
【００２１】
図１（ａ）は、１つの筐体内に全てのモジュールが内蔵されている場合で、図１（ｂ）は、無線タグ読取装置を携帯情報端末２００５の筐体内から取り出し、その間をケーブル２０１１で結んだ構成である。物理的形態が２通りある理由は後述する。
【００２２】
図２は、天候検知装置を実際に用いる場合の模式図である。３００１は、傘利用検知装置であり、３００２は、携帯情報端末である。３００３は傘であり、傘利用検知装置３００１は、傘３００３の受け骨に取り付けられている。３００４は、ユーザである。
【００２３】
図２（ａ）は、ユーザ３００４が、傘３００３を利用している（つまり、「傘をさしている」）場合で、図２（ｂ）は、傘を利用していないし、携帯もしていない場合で、図２（ｃ）は、傘を携帯している（この場合は手で持って運んでいる）場合である。
【００２４】
３００５は、無線タグ読取装置２００７の読取範囲を模式的に表したものである。
【００２５】
図３は、傘利用検知装置を傘に取り付けた場合の模式図である。図３（ａ）は、傘全体を見渡した図であり、図３（ｂ）は、図３（ａ）の破線で丸く囲んだ部分を拡大したものである。
【００２６】
６００１は、無線ＩＤタグであり、傘取り付け部６００２を介して、傘の受け骨の一本の６００３に取り付けられている。傘取り付け部６００２は、図７の１０１１、図１の２００３と同じもので、紐やカラビナ、針金、フック等、受け骨にぶらさげられるものであれば、どのようなものでもよい。さらには、このように物理的な形状を用いて引っ掛けるものではなくて、例えば接着剤、両面テープなどの粘着性を利用して傘の任意の部分に接着させるものであったり、磁石などの磁力で接着させるものであったり、そもそも最初から傘内部の任意の場所に組み込んであってもよい。例えば、図４の（ａ）のように、中棒の上の方（７００１）や、図４（ｂ）の手元部分（７００２）に貼付してもよい。なお、傘の構成は、図３（ａ）に示す通り、石突６００６、親骨６００７、はじき６００８、玉留６００９及び手元６０１０を備えている。
【００２７】
次に、以上のように構成された天候検知装置について、その動作を説明する。まず、この天候検知装置２００１の初期設定を行う。天候アプリ制御部２００６には、初期設定モードが備わっているとする。初期設定モード中では、無線タグ読取装置２００７は無線ＩＤタグの読取動作に入り、無線ＩＤタグ２００４が内部に保持しているＩＤを読み取ると、天候アプリ制御部２００６は、それをメモリ２００９内に記憶する。記憶させたところで、初期設定モードが終了する。
【００２８】
初期設定モードの起動は、ユーザ等の指示によって開始され、その後、ユーザは無線ＩＤタグ２００４と無線タグ読取装置２００７を読み取り可能距離以下に接近させる。その後、自動的に初期設定モードは終了する。
【００２９】
初期設定により、無線ＩＤタグ２００４のＩＤが取得できたが、これは、他の用途に利用されている無線ＩＤタグと本発明の用途に利用される無線ＩＤタグを区別するために利用される。よって、無線タグ読取装置２００７が読み取れるタグは、傘利用検知にしか利用されないのであれば、この初期設定は省略することが可能である。
【００３０】
次に、天候検知装置２００１を利用するには、傘利用検知装置２００２と携帯情報端末２００５が、所定の位置に取り付けてある必要がある。まず、傘利用検知装置２００２は、ユーザ３００４が利用している傘に取りつけられている必要がある。この取り付け方法に関しては、前述した通りである。
【００３１】
一方、携帯情報端末２００５は、ユーザ３００４の頭部３００２に装着されているか、または、少なくとも無線タグ読取装置２００７が頭部３００２に装着される必要がある。前者の場合の携帯情報端末の構成を表した模式図が、図１（ａ）であり、後者が図１（ｂ）である。
【００３２】
携帯電話のような手持ちが前提のモバイル端末を頭部に装着するのではなく、これは、ヘッドマウントディスプレーやヘッドセットを入出力装置として持つ携帯情報端末（またはウェアラブルコンピュータ）を前提として考えたものである。例えば、ヘッドマウントディスプレーとスマートフォン上に、本携帯情報端末２００５が実装されている場合に、ヘッドマウントディスプレー内に本携帯情報端末２００５全てを格納することも可能であるし（図１（ａ）の場合）、無線タグ読取装置２００７のみヘッドマウントディスプレー内に実装し、残りのモジュールは、スマートフォン内に実装し、その間をケーブルで繋ぐことも可能である（図１（ｂ）の場合、ここでケーブルは、２０１１を指す）。
【００３３】
いずれにしろ、無線タグ読取装置２００７は、ユーザ３００４の頭部３００２に装着されることとなる。
【００３４】
さて、天候検知装置２００１を所定位置に装着した後、ユーザの指示等により天候アプリ制御部２００６が起動される。当然ながら、ユーザが起動せずとも、携帯情報端末２００５が起動すれば自動で起動されるようにしてもよい。
【００３５】
起動後、天候アプリ制御部２００６は、以下の（１）から（４）を、繰り返す。
【００３６】
（１） 無線タグ読取装置２００７を起動し、無線ＩＤタグの読取を行う。
【００３７】
（２） 読取に失敗したら、ＩＤは不定値のまま（３）に進む。成功したら、傘利用判定部２００８に読みとったＩＤを渡す。
【００３８】
（３） 傘利用判定部２００８は、読み取ったＩＤをメモリ２００９内に格納されているＩＤと比較し、同一であれば、傘が利用されていると判定する。すなわち降雨があると判断できる。そうでなければ、傘は不利用と判定する。ＩＤが不定値の場合も傘は不利用と判定する。傘の不利用は降雨なしとの判定となる。
【００３９】
この判定をメモリ２００９の所定部分に記録する。
【００４０】
なお、前述したように、初期設定が不要な場合は、傘利用判定部は、常に傘利用すなわち降雨の判定を下す。
【００４１】
（４） 一定時間休止する。
【００４２】
ここで、ステップ（３）の判断ができる理由について図２を使って説明する。図２の３００５は、無線タグ読取装置３００２の読取可能範囲を表わしたものである。読取可能範囲３００５は、典型ユーザが傘をさしている場合の頭部から傘中央（下ろくろ）までの距離より大きく、頭部から腰部の距離より小さいよう調整してある。よって、典型ユーザとほぼ同じ体格のユーザであれば（ユーザ３００４は、そうだとする）、傘利用の場合（図２（ａ））は、読取可能となる。
【００４３】
一方、不利用の場合（図２（ｂ）、傘を傘立などに放置し、ユーザの身近にない場合）や、傘を持ち運んでいる場合（図２（ｃ））などは、傘中心に取りつけられた無線ＩＤタグ２００４は、読取可能範囲３００５の圏外に出るために、読み取れないこととなる。よって、読み取りの可否から、傘を利用しているかどうかが推測でき、さらに、ユーザの周囲の降雨は現時点であるのかないのかも推測できることとなる。
【００４４】
ここで、読取可能範囲３００５の大きさの決め方について補足しておく。まず読取可能範囲３００５の大きさについては固定でも可変でもよい。固定の場合は、天候検知装置２００１の想定ユーザのうち、典型的ユーザの体格や傘のさし方に合わせて、予め読取可能範囲３００５の大きさを設定しておく。これに対して、読取可能範囲３００５が可変の場合は、個々のユーザに合わせて読取可能範囲３００５を設定することで、天候検知装置２００１の精度を向上させることができる。
【００４５】
これには、例えば、あるユーザが天候検出装置２００１を初めて使う場合に、携帯情報端末２００５からユーザに傘を挿すように指示し、その状態で読取可能範囲３００５を小さな値から大きな値まで変化させ、無線ＩＤタグ２００４が読取可能な読取可能範囲３００５の大きさを調べる（この半径をＲ１とする。Ｒ１は１つの値ではなく数値の集合である）、次にユーザに傘挿しをやめて移動中のように傘を保持するように指示したところで、同様に読取可能範囲３００５を変化させ読取可能な読取可能範囲３００５の大きさを検出する（この半径をＲ２とする。Ｒ２も数値の集合である）。その上で、読取可能範囲３００５の半径を、Ｒ１の最小値より大きく、Ｒ２の最小値より小さいように設定すれば、適切な読取可能範囲３００５の設定ができる。
【００４６】
また、自動計測するのではなく、ユーザに利用状況を入力させ、その値に従い読取可能範囲３００５の設定をすることもできる。つまり、ユーザの身体的特徴（身長や性別、利き手）、情報携帯端末２００５の使い方（普段どこに入れて持ち歩くのか）、傘の使い方や種類（持ち歩くときはどうやっているのか、折り畳み傘か、大きさ、傘はどちらの手で持つか）、傘利用検知装置２００２はどこに取り付けたかなどを、ユーザに情報携帯端末２００５を通じて入力させる。すると、ユーザの傘利用時と非利用時における情報携帯端末２００５と傘利用検知装置２００２との距離がそれぞれ、Ｒ１、Ｒ２と推定できるから、読取可能範囲３００５の大きさは、Ｒ１とＲ２の間（中間）の値に設定してやればよい。
【００４７】
なお、読取可能範囲３００５を可変とするための方法については、無線タグ読取装置２００７や無線ＩＤタグ２００４の電波強度や感度を可変とする方法も他に、ソフトウエア的に擬似的に読取範囲を可変とする方法がある。後者については実施の形態３で述べる。
【００４８】
このように実施の形態１によれば、傘に無線ＩＤタグを取り付け、傘利用時に無線ＩＤタグを読み取り可能な距離が設定された携帯情報端末が無線ＩＤタグの読み取りを行い、無線ＩＤタグの読み取りの可否に応じて、傘の利用又は不利用、すなわち、降雨の有無を判定することにより、安価な無線ＩＤタグを傘に取り付けるという簡易な手順で天候情報を取得することができるので、観測地点が高密度の観測網を容易に形成することができる。
【００４９】
（実施の形態２）
実施の形態２では、実施の形態１の無線ＩＤタグに簡単なセンサを組み合わせることで、降雨の推測をより確からしいものにできることを示す。
【００５０】
本実施の形態の天候検知装置も、図１のような構成をしている。ただし、無線ＩＤタグ２００４に転倒検出センサ（または転倒検出スイッチ、転倒スイッチとも呼ばれる）を付け加える。
【００５１】
図５に転倒検出センサを加えた一例を示す。図５（ａ）は、転倒検出センサを加える前の典型的な無線ＩＤタグの構成図であり、図５（ｂ）は、その外観の模式図である。
【００５２】
無線ＩＤタグは、ＩＤが記憶されているメモリ５００５と、外部からの電波を受信したり、また送信したりするループアンテナ部５００２と、外部からのＩＤの読み出し要求を解釈し、それに対してＩＤをメモリ５００５から読み出し、データ送受信部５００３を使ってＩＤを返す制御部５００４からなる。データ送受信部５００３、制御部５００４、メモリ５００５は、１つのＩＣチップ（ＩＣ部５００６）としてまとめられており、それに比べて、ループアンテナ部５００２は、巨大で、例えば図５（ｂ）に示したような外観を呈している。
【００５３】
このような無線ＩＤタグ５００１に、転倒検出センサを加えて、無線ＩＤタグに鉛直方向を定義し、その鉛直方向から無線ＩＤタグがある角度以上傾いた場合は、無線ＩＤタグが機能しないようにすることができる。ここで、無線ＩＤタグが機能しない（機能オフ）とは、外部から無線ＩＤタグの読み出し命令があった場合でも、それに対して応答しないことをいう。
【００５４】
図５（ｃ）は、その構成図で、図５（ｄ）は、その外観の模式図である。鉛直方向（上方向）は、図５（ｄ）の矢印に示した通りの向きである。
【００５５】
ここでは、転倒検出センサとして、水銀スイッチを利用するとする。この場合、構成は単純で、図５（ｃ）のように、５０１２部分の配線を切断し、その間に転倒検出センサ（水銀スイッチ）５０１１を挿入する。あとは、図５（ｄ）のように、水銀スイッチ５０１１の方向を調節して、鉛直方向に無線ＩＤタグがある場合に、スイッチが入り、鉛直方向からある程度（例えば４５°程度）以上傾いた場合にはスイッチが切れるようにすればよい。
【００５６】
なお、水銀スイッチは、構造が簡単で非常に廉価であるが、水銀の毒性も心配されるため、その代替品として、加速度センサや金属球によるスイッチを利用することもできる。金属球による転倒検出スイッチの場合は、水銀スイッチと構成の方法は同様である。
【００５７】
加速度センサを使う場合は、無線ＩＤタグの内部に加速度センサの加速度値から、無線ＩＤタグ全体の傾きを演算して、傾きがある程度以上の場合は、無線ＩＤタグが機能しないようにすることとしてもよい。または、そのような傾き計算や機能をオフにすることは、携帯情報端末２００５の傘利用判定部２００８が行い、無線ＩＤタグは、傾きに関係なくオン状態のまま、ＩＤとともに、加速度値を返すようにしてもよい。具体的には、無線ＩＤタグからＩＤ及び加速度値を取得した傘利用判定部２００８は、傾斜角が一定の範囲内の場合、傘が利用されていると判定し、傾斜角が一定以上となった場合、傘が利用されていないと判定する。
【００５８】
このように構成した転倒検出センサつき無線ＩＤタグを傘のとりつけた様子を図３に示す。図３の（ａ）は、全体図で、図３（ｂ）が、その取り付け部分（図３（ａ）の破線で囲んだところ）を拡大したものである。
【００５９】
転倒検出センサ付き無線ＩＤタグ６００１には、傘取り付け部６００２をつけ、傘にとりつけられるようにする。傘取り付け部６００２は、紐や針金等で結んで使うものでもよいしフックやカラビナなどの取りつけ具でもよい。つまり、簡単に傘の骨（受骨）にとりつけ、そのままぶら下げることができるものならばよい。あるいは、粘着テープのようなもので、傘の中棒６００４に貼って固定するものでもよい。この固定タイプの場合は、無線ＩＤタグの上方向と、傘の上方向が一致させて貼ることが必要である。
【００６０】
図３（ａ）は、受骨６００３に無線ＩＤタグを吊した例である。本実施の形態では、受骨に吊したが、親骨６００７に吊しても問題はない。図３の例では、受骨６００３に無線ＩＤタグ６００１は吊されていることで、無線ＩＤタグ６００１の上方向が、重力の鉛直上方の方向と一致するために、無線ＩＤタグの機能はオンになっている。
【００６１】
図６（ａ）〜（ｃ）には、実施の形態１に係る天候検知装置の利用形態を示す。いずれの場合にもユーザ４０００は、携帯情報端末４００１を胸のポケット等に入れているとする。また、本実施の形態では、無線タグ読取装置２００７が、無線ＩＤタグ２００４を読みとれる距離は、１メートル以上（平均的なユーザの身長の５〜６割程度以上）とする。
【００６２】
このような利用形態において、図６（ａ）の「傘を利用している場合」は携帯情報端末４００１と、傘利用検知装置４００２との距離は１メートル以下で、かつ、傘利用検知装置４００２は、傘が開いている状態では吊り下っている状態であるから、転倒検出センサの働きにより機能がオンになっている。つまり、この場合、携帯情報端末４００１は、傘利用検知装置４００２から、そのＩＤを読み取ることができる。
【００６３】
図６（ｂ）の「傘不利用の場合」であるが、通常傘を利用していない場合は、傘立に入っていたりしているはずで、ユーザから離れているところにおかれるし、また、傘も石突方向を下に向けて畳んでおくので、転倒検出センサの働きて機能がオフになることが多いと考えられる。よって、この場合は、携帯情報端末４００１は、傘利用検知装置４００２から、そのＩＤを読み取ることができない。
【００６４】
図６（ｃ）の「傘携帯の場合」であるが、携帯の場合は、図のように手で傘の手元６０１０を持ったり、あるいは、折り畳み傘であれば、畳んでカバンの中等に寝せていれておいたりする。この図６（ｃ）の場合は、携帯情報端末４００１と傘利用検知装置４００２の距離的には、読取可能範囲に入っていることが多いと考えられるが、転倒検出センサの働きで機能はオフになることが多いと考えらえる。よって、この場合は、携帯情報端末４００１は、傘利用検知装置４００２から、そのＩＤを読み取ることができない。
【００６５】
これに対して、実施の形態１の仕組みでは、情報端末４００１と、傘利用検知装置４００２の距離だけで、ＩＤの読取の成否が決まってしまうから、例えば、図６（ｃ）のような場合は、ＩＤは読取可能で、すなわち傘利用判定部２００８は、傘を利用しているとの誤った判定を下すことであろう。
【００６６】
ここで、転倒検出センサとして加速度センサを利用する場合について補足する。転倒検出センサとして加速度センサを利用する場合は、傘が何度傾いているかの角度が分かるが、この傾きをある閾値（パラメータ）と比較して転倒の判断をすることとなる。つまり、加速度センサによって得られた傾きが、メモリ２００９に保持されている当該パラメータを超えている場合は、転倒とみなすような計算が行われる（これについては、実施の形態３にてより詳しく述べる）。メモリ２００９に保持されたそのパラメータは、初期値として当該天候検知装置２００１が想定する典型ユーザに合わせたデフォルト値が設定されていることになるが、これを、各個別のユーザに合わせて設定しなおすことも可能であり、そうすれば天候検出の精度に寄与することになる。
【００６７】
パラメータの設定の方法については、実施の形態１に示したと同じように、例えば利用初回時に、実際にユーザに傘を挿させて、その傾きを測定し（Ｖとする）、そのＶの値に多少余裕を持たせて、傾き閾値のパラメータとして設定してやればよい。例えば、Ｖ値の１割増しをパラメータとして設定するなどである。または、Ｖは何度も測定し、その中の最大値をパラメータとして設定すれば、より天候検出の精度が上がることが期待できる。
【００６８】
また、実施の形態１の場合と同様に、自動計測するのではなく、ユーザに利用状況を入力させ、その値に従いパラメータの設定をすることもできる。
【００６９】
このように実施の形態２によれば、転倒検出センサを傘利用検知装置に組み込むことにより、より正確に傘利用を推測することができる。
【００７０】
（実施の形態３）
実施の形態３では、実施の形態１または実施の形態２で説明したような傘側の装置単独による判断に加えて、傘の降雨推定データを収集サーバに収集し、データ全体に確率的な判断を加えることで、より推定を精密にできることを示す。同時に、収集サーバから、傘側にその傘が出した降雨判定の確からしさについてフィードバックをかけることで、傘単独での降雨推定の精度をあげることができることを示す。
【００７１】
図７を用いて、本発明の実施の形態３に係る天候情報収集システムの構成を説明する。まず、１０００は天候検知装置である。天候検知装置１０００は、傘利用検知装置１０１０と携帯情報端末１０２０から構成される。
【００７２】
傘利用検知装置１０１０は、傘取り付け部１０１１と無線センサタグ１０１２から構成され、これは、第２の実施の形態で示した転倒検出センサつき無線ＩＤタグ５０１０と同様のものである。ただし、本実施の形態では、転倒検出スイッチとして加速度センサを用いるとする。つまり、無線センサタグ１０１２は、外部からの読取要求に応じて、無線センサタグ１０１２が保持するＩＤと、加速度値を渡すことができる。加速度値としては、傘利用検知装置の鉛直方向（図３（ｂ）の矢印方向）を算出できるだけの加速度値が渡されるとする。
【００７３】
ここでは説明の便宜上、無線センサタグ１０１２には、１軸の加速度センサが内蔵されており、それは、傘利用検知装置の鉛直方向の下方向向きの加速度を計測しているとする。これは、３軸の加速度センサを搭載して、傘利用検知装置の鉛直方向の下方向向きの加速度成分を計算しても同等である。
【００７４】
携帯情報端末１０２０は、無線センサタグ１０１２から読みとった、ＩＤ値と加速度値等から傘利用判定を行い、それをあらかじめ定められた天候情報サーバ１０４０に渡すとともに、天候情報サーバ１０４０からは、各種天気現況あるいは予報を受けとり、それをユーザに提示することができる。さらには、天候情報サーバ１０４０から受けとった情報をもとに、より傘利用判定を正確にするための学習を行うこともできる。
【００７５】
本実施の形態では、説明のため、これらの機能はアプリケーションとして１つにまとめられているとし、そのアプリケーションが天候アプリ制御部１０２１である。天候アプリ制御部１０２１は、ユーザインタフェース１０２８と介して、ユーザに情報を提示したり、ユーザから命令を受けとる。またユーザからの命令などの外部からの入力やイベントに従い、各種サブモジュールやメモリを参照書き込みしながら、処理を進めていくことができる。
【００７６】
１０２２〜１０２８は、サブモジュールである。
【００７７】
無線タグ読取装置１０２２は、読取命令を受けると、無線センサタグ１０１２から、ＩＤ、加速度値及び、無線センサタグが応答してきた電波強度を読み出すことができる。
【００７８】
傘利用判定部１０２３は、無線タグ読取装置１０２２が読んだ、ＩＤ、加速度値及び、無線センサタグが応答してきた電波強度及び、メモリ１０２９に記録されているパラメータ、信頼度から、傘利用判定を行うことができる。
【００７９】
１０２４は、広域位置情報取得部であり、現在地を示す位置情報を取得する。いわゆるＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）である。
【００８０】
１０２５は、気象情報閲覧アプリで、ネットワーク１０６０を通して、各気象サーバ（１０６１や１０４０）の気象データを閲覧することができる。
【００８１】
１０２６は、パラメータ学習部であり、より精度が高い傘利用判定、つまり降雨判定をするための学習を行う。
【００８２】
１０２７は、データ命令送受信部であり、ネットワーク１０６０を介してデータや命令の送受信を行うためのネットワークインタフェースである。１０２８は、ユーザインタフェースであり、さらにディスプレーやスピーカー、キーボード、マイク等の入出力デバイスやＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）システムからなる。
【００８３】
一方、天候情報サーバ１０４０は、多数の天候検知装置から情報を収集し、天気現況の解析を行うとともに、各天候検知装置があげてきた観測データの信頼度を計算することができる。そして、得られた天気現況や予報について、各天候検知装置に教えるとともに、信頼度をフィードバックすることができる。
【００８４】
１０４１〜１０４６は、天候情報サーバ１０４０のサブモジュールである。
【００８５】
１０４１の天候情報サーバ制御部は、各サブモジュールの動作制御を行う。
【００８６】
１０４２は、天候データ集計部であり、各天候検知装置からのデータを集計する。
【００８７】
１０４３は、信頼度算出手段としての端末信頼度学習更新部であり、過去の各天候検知装置からのデータと実際の天候情報に基づいて、各天候検知装置の信頼度を計算し直す。１０４４は、統合天候情報作成公開部であり、各天候検知装置に対して天候に関する現況、予報を公開するとともに、各天候検知装置にその信頼度をフィードバックする。１０４５は、天候情報サーバ１０４０外から、気象観測データを取得するものである。１０４６は、データ命令送受信部であり、ネットワーク１０６０を介してデータや命令の送受信を行うためのネットワークインタフェースである。
【００８８】
１０４７はメモリであり、データを記録し、書き変え、削除することができる。
【００８９】
１００１は、気象データサーバであり、公設の天気情報組織や民間の天気予報会社等のデータサーバであって、そこには、信頼度が非常に高い気象観測装置で観測された（例えばアメダスの観測値）データ（１０６２）が記録されており、ネットワーク１０６０を通して、天候情報サーバ１０４０は、データを参照することができるものとする。なお、アメダス（ＡＭｅＤＡＳ： Ａｕｔｏｍａｔｅｄ Ｍｅｔｅｏｒｏｌｏｇｉｃａｌ Ｄａｔａ Ａｃｑｕｉｓｉｔｉｏｎ Ｓｙｓｔｅｍ）とは、気象庁の「地域気象観測システム」の愛称であり、日本全国の約１３００箇所に設置された観測機器から構成される。
【００９０】
１０６０は、ネットワークである。
【００９１】
以上のように構成された天候情報収集システムの動作を以下で説明する。
【００９２】
まず、天候検知装置１０００の概要と動作詳細を説明する。本システムでは、１つの天候情報サーバ１０４０に対して、複数の天候検知装置が対応している。天候検知装置のうち携帯情報端末部分は、それ専用の機器というよりは、携帯電話やスマートフォン、あるいは小型のノートＰＣに無線タグ読取機能を付加した構成を想定している。無線タグ読取機能は、携帯電話等に内蔵されていてもよいし、また、外付けされてもよい。さらに、傘利用検知装置に関しては、天候情報サーバを運営する会社や団体が、販売や配布することを仮定している。つまり、天候情報サーバ運営団体は、傘利用検知装置を多数のユーザに無料配布し、そのかわりに、傘利用判定部１０２３が出力する傘利用（つまり、降雨の有無）のデータを収集し、その運営団体自らの天候情報の精度向上に資する。
【００９３】
そのため、傘利用判定部の価格は、十分安価で大量に生産可能で、かつ、取り付けが容易なものでなければならない。また、ユーザが傘に取り付けるインセンティブとして、例えば、傘利用検知装置１０１０の外観をマスコット人形（例えば、てるてる坊主）、いわゆるフィギュア（アニメのキャラクターなどの立体造形物）、またはトレーディングカード風にしたりすることが有効である。同様に、ユーザが傘利用判定データを天候情報サーバ１０４０にアップロードする対価として、天候情報サーバ１０４０が集計し、見易いように加工したデータ（例えば、ユーザの詳細周辺地図に降雨地域を重ねて表示したもの）や、短時間局所の天気予報等を得られるようにする必要がある。
【００９４】
ユーザは、傘利用検知装置１０１０を手に入れ、自分の傘の所定部分（図３参照）に取りつけたとする。また、同時に自分の携帯情報端末（携帯電話やスマートフォン、通信機能つきノートＰＣ等）に、必要なソフトウエアをインストールする。必要なソフトウエアとは、天候アプリ制御部１０２１、傘利用判定部１０２３、パラメータ学習部１０２６等である。これらのアプリケーションのインストール方法は、ユーザの持つ携帯情報端末それぞれの方法で行う。
【００９５】
傘利用検知装置１０１０がユーザの傘に取り付けられ、携帯情報端末１０２０にも必要なソフトウエア等がインストールされると、天候アプリ制御部１０２１は、まず初期化動作を行う。いつの時点でどのように初期化を行うかは、ソフトウエアを使い易くするための工夫の範疇であり、例えば、ダウンロード直後に自動で始まる、最初に作動した時に自動で始まる、等が考えられる。具体的な初期化の内容であるが、天候アプリ制御部１０２１の動作に必要なパラメータ、信頼度、タグＩＤのデフォルト値への設定と、過去のセンサ測定値の無効化である。
【００９６】
天候アプリ制御部１０２１は、作動すると、必要な初期化処理を行ったのちに、イベント待ちとなる。天候アプリ制御部１０２１が待つイベントは、以下の２種類である。
（１） タイマーイベント（傘利用判定）
（２） パラメータ学習命令
【００９７】
以下では、図８のフローチャートを参照しながら、タイマーイベント（傘利用判定）のイベント処理について述べる。
【００９８】
傘利用判定のためのタイマーイベントは、パラメータテーブル１０３０に１つのパラメータとして格納されている「無線タグ読み取り間隔（図９のパラメータテーブル）」の間隔に従い発生するイベントであり、ここでは２分間隔でイベントが発生しているとする。
【００９９】
天候アプリ制御部１０２１は、そのタイマーイベントを受けとると、図８のフローチャートに従い、まず無線タグ読取装置１０２２を作動させ、無線センサタグ１０１２から読取を行う（９００１）。読取結果は、次の４つ組で表わされるとする。（ｒｅｓｕｌｔ ｌｅｖｅｌ ｉｄ ａｃｃ）
【０１００】
ここで、ｒｅｓｕｌｔは、無線センサタグ１０１２の読み取りができた場合には１、できなかった場合には０で示す。ｌｅｖｅｌは、無線センサタグ１０１２が返した応答の電界強度レベルで０〜１０の値を取る。ｉｄは、無線センサタグのＩＤで、適当なユニークな自然数である。ａｃｃは、鉛直方向の加速度である。傘が石突を上に直立していれば（傘をさしている場合）、９８０である（地球の重力加速度。単位はＧａｌ）。
【０１０１】
なお、本実施の形態では４つ組であるが、４つに限ることが必要なわけではない。他に有用なセンサを搭載可能であれば、例えば、センサのタイプ等が入ってもよいし、電子コンパスの値（方角）、気温、湿度など、各種センシングの値が考えられる。
【０１０２】
次に、ステップ９００１で取得したセンサ値の補正が必要であればこれを行う。例えば、本実施の形態では、説明を簡単にするために、加速度値（ａｃｃ）は、鉛直方向の値を直接とれるようにしているが、実際の生データは３軸の加速度（ｘ、ｙ、ｚ方向の加速度）値で、鉛直方向の値は計算が必要であったり、また、加速度値は細かく変動することが多いため、短時間に何回も計測して平均をとったりする必要がある。
【０１０３】
補正が終了すると、ＧＰＳから現在地情報を取得し、また、パラメータテーブル（１０３０、８０００）を読みこみ、また、過去のセンサ値も必要な分だけ読みこむ（９００２）。
【０１０４】
次に、傘利用判定のステップ９００３に進む。
【０１０５】
この判定式は、「傘を利用しているかどうか」を意味するもので、判定式が真（はい）の場合は、利用している、偽（いいえ）の場合は、利用していないことを意味する。なお、“＝”は等号を、“＞＝”は「以上」の判定を、“＞”は「より大きい」の判定を表し、“ａｎｄ”は論理的積のオペレータで、表記はＳ式で記載した。
【０１０６】
（（ｒｅｓｕｌｔ＝１）ａｎｄ
（ｉｄ＝（タグＩＤ１０３２に保持された値））ａｎｄ
（（ｌｅｖｅｌ＞＝（パラメータテーブル８０００の電界強度閾値の値））ａｎｄ
（ａｃｃ＞（パラメータテーブル８０００の傘傾き閾値の値）））
【０１０７】
判定式の１行目は、「無線タグが読みとれたか」を示す。読みとれなかった場合（値＝０）、少なくとも傘がユーザの近くにはないということを意味し、ユーザは傘を利用していないことが推測できる。
【０１０８】
次に、２行目であるが、タグＩＤ１０３２には、初期化時に記録されたタグのＩＤが記録されている。この記録されたＩＤと、今読みこんだＩＤが異なる（つまり２行目が偽）ということは、その無線タグが傘についているものではない（たまたま読取可能な同種の無線ＩＤが近くにあった）ことが推測でき、これもユーザが傘を利用していないことの根拠となる。
【０１０９】
３行目に関しては、後の学習過程で説明する。この時点では、パラメータテーブル８０００記載の電界強度閾値としては、０が入っているから、ここは常に真となる。
【０１１０】
４行目は、傘の傾きである。パラメータテーブル８０００の傘傾き閾値は８４９で、これは、９８０×ｃｏｓ（３０°）（Ｇａｌ）に相当する。つまり、３０°傘が傾いている時に観測されるべき鉛直下向きの加速度の大きさで、これ以下ということ（つまり４行目が偽）は、傘が３０°以上傾いているということで、これも傘を利用していないことが推測される。
【０１１１】
全体として真になれば、ユーザ傘を利用していると推測される。偽の場合は、利用していないと推測される。
【０１１２】
判定が出ると、次にステップ９００４に進む。ここでは、その判定結果に、ｉｄ値、ＧＰＳによる現在地情報を組みにして、データ・命令送受信部１０２７を利用して、天候情報サーバ１０４０に送付する。
【０１１３】
次に、データを受けとった天候情報サーバ１０４０の動作について説明する。
【０１１４】
サーバでは、天候情報サーバ制御部１０４１と統合天候情報作成公開部１０４４と気象観測データ取得部１０４５が同時並列に動作している。
【０１１５】
気象観測データ取得部１０４５は、図１０に示すアルゴリズムで動作する。つまり、周期的に外部の気象データサーバ１０６１が保持する気象観測データ１００２から、必要な気象観測データを取得してメモリ１０４７内に気象観測データ１０５０として記録する（１００２２）。
【０１１６】
取得する気象観測データとしては、各観測地点の気象観測値や雨のレーダーデータである。取得間隔は、取得対象の気象観測データの更新周期にあわせる。
【０１１７】
統合天候情報作成公開部１０４４は、図１１のアルゴリズムで動作する。これも、周期的に統合天候情報を作成し、メモリ１０４７に統合天候情報として記録する（１００１２）。統合天候情報は、気象観測データ取得部１０４５が取得した気象観測データ１０５０と、天候情報サーバ制御部１０４１が作成した天候データ１０４８をつきあわせて、信頼度が高いと思われる気象の現況及び予報を統合天候情報１０５１として作成する。
【０１１８】
天候情報サーバ制御部１０４１は、図１２のアルゴリズムで動作する。まず、天候情報サーバ制御部１０４１が、データ命令送受信部１０４６が、各天候検知装置から天候情報がアップロードされてくるのを監視している（図１２の１０００１）。
【０１１９】
ここで、天候情報が受信されると（１０００２）、そのデータを気象観測データ取得部１０４５が取得した気象観測データ１０５０と、各天候検知装置が送ってきたものに信頼度の修正を加えた天候データ１０４８と比較して、受信した天候情報の確度を計算し、それに基づきその天候情報を送った天候検知装置（以下、単に「端末」という場合は天候検知装置を指す）の信頼度を計算する（１０００３）。
【０１２０】
ここで、信頼度とは、端末がアップロードした天候データがそれを信頼すべきデータとして用いることができるかどうかの値である。
【０１２１】
信頼度の具体化には各種のものが考えられる。精密な計算を行う必要があれば、端末があげる天候データには確率的な揺らぎが存在すると考えて、そのゆらぎになんらかの確率分布を仮定して条件付確率としてとらえてもよい。また、確率ではなく、尤度の一種と考えてもよい。
【０１２２】
例えば、条件つき確率Ｐ（Ｘ｜Ｙ）を、Ｘは傘を用いたと検知される確率で、Ｙは、降雨の確率とすれば、ベイズ推定等を用いて、Ｐ（Ｙ｜Ｘ）、つまり、Ｘとの天候情報があげられた場合の、Ｙ（降雨）があった確率を推定することができる。
【０１２３】
ただし、Ｐ（Ｘ）のような、「傘を用いたと検知される確率」を表現するようなモデルは、ある程度複雑になり端末の数が膨大になると計算量も膨大になる一方、降雨の推定という点では、各々の端末の信頼度の不正確さは、端末の数でカバーできると考えられる。そこで、本実施の形態の場合は、確率モデルベースの信頼度は使わない。本実施の形態の場合、信頼度とは、端末がアップロードした天候データが「傘利用（すなわち降雨あり）」の場合、それを信頼すべきデータとして用いることができるかどうかの値であるが、これは確率や定義された尤度ではなく、直感的なものである。
【０１２４】
本実施の形態における信頼度は、０．０以上、１．０以下の値をとるとする。０の場合は、アップロードされた天候データは全く信用できない（正しい値かどうか不明）として、データから棄却される。１の場合は、信頼できる（つまり、その地点では必ず雨が降っている）という意味となる。
【０１２５】
さて、ここで信頼度の計算と更新が行われるが、その説明上で使われる記号の意味を先に述べておく。
【０１２６】
天候データ１０４８は、全端末からアップロードされたデータが蓄積されたテーブルで、各々の要素 ｗ（ｎ）は、次のように表現される。
【０１２７】
ｗ（ｎ）＝（ｉｄ ｔｉｍｅ ｐｏｓ ｒｅｓｕｌｔ ａｃｃ）、ｎは１〜現在格納された全要素の数
【０１２８】
ここで、ｉｄは、端末ＩＤ、ｔｉｍｅは登録日時、ｐｏｓは、位置情報（経度、緯度、光度）、ｒｅｓｕｌｔは、降雨の有無、ａｃｃは、傘鉛直方向の加速度である。天候データの要素は、ｉｄとｔｉｍｅの値でユニークに識別される。ｗ（ｎ）は、変数ｗのインデックスｎを表現するとする。信頼度は、端末データ１０４９中に、ｉｄに紐づけられて格納されているとする。また、今端末があげてきた天候情報を、ｗ（ｎ＋１）とする。
【０１２９】
信頼度の計算及び更新は、以下の（１）〜（４）のように行われる。
【０１３０】
（１） 信頼度は、端末データ１０４９内に、端末毎に１つ設定されている。
【０１３１】
（２） 初めて天候情報をアップロードしてきた端末に対しては、信頼度の初期値として、０．５が割りあてられ、（３）に進む。
【０１３２】
（３） 以下の順番で当該端末に対する信頼度を計算する。
【０１３３】
（３−１） 既に天候データ１０４８に格納されたデータからの信頼度の計算を行う。
【０１３４】
（３−１−１） ｗ（ｎ＋１）を基準に、ｔｉｍｅ値の差が２分以内であるもの、及び、ｐｏｓの値のずれが１００ｍ以内であるものを検索する。これをｗ（ｎ＋１）の近傍と呼ぶ。ｗ（ｋ）の近傍を、Ｓ（ｋ）で表わす。
【０１３５】
この結果を模式的に示したものが、図１３（ａ）である。これは、Ｓ（ｎ＋１）と、その周辺の天候データを地図風にプロットしたものである。黒丸はｗ（ｉ）のｒｅｓｕｌｔ値が１（降雨）のもの、白丸は０（降雨ではない）ものを示している。また×印（１１００１）は、ｗ（ｎ＋１）、つまり当該端末の場所を示す。このうち、半径Ｒ（＝１００メートル）以内（１１００２の破線円内）のものが、前述の近傍Ｓ（ｎ＋１）である。この例では、図１３（ａ）のＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆの集合が近傍である。
【０１３６】
（３−１−２） ｗ（ｎ＋１）近傍内での降雨判定を行う。これには、まず信頼度が低い天候データを排除（フィルタリング）し、次に降雨あり、降雨なしの天候データの数、信頼度を勘案して、降雨判定を行う。
【０１３７】
まず、近傍Ｓ（ｎ＋１）から、信頼度が一定の閾値未満の天候データを排除する。閾値としては、０．３を利用する。今回の場合は、Ｓ（ｎ＋１）＝｛Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ｝の信頼度は全て０．３を上回っているとして、排除されたものはないとする。
【０１３８】
次に降雨判定を行う。ここでは、単純に信頼度でフィルタリングされた後の近傍Ｓ（ｎ＋１）のデータでの多数決で行う。今回の場合では、降雨ありとしているのは、｛Ａ、Ｂ、Ｃ、Ｄ｝の４つ、降雨なしは、｛Ｅ、Ｆ｝の２つであるから、４対２で、この近傍での降雨判定は「あり」となる。
【０１３９】
なお、近傍に天候データがなかった場合は、判定はできない。また、同数であった場合は、降雨ありとする。
【０１４０】
信頼度を重みとした重みつき多数決（例えば１票に信頼度を掛けたものを合計する）をすれば、多少の精度の向上は得られると思われる（ただし、その分処理は遅くなる）。
【０１４１】
さらには、信頼度を尤度と捉え直して、ベイズ学習、ベイズ推定を利用すれば、信頼度の値自身が精度の高いものとなろう。ただし、このためには、学習過程（ここでは、天候データの実際の真偽をなんらかの形で取得しなければならない）と、もう少しの処理能力が必要となる。
【０１４２】
また、降雨判定に、アメダス等の信頼度が非常に高いデータを利用することも考えられようが、そもそも、この降雨判定は、アメダス等の信頼度が高いが、観測密度が場所的にも時間的にも疎である観測網のすきまを埋め（アメダスは、２００９年現在、観測地点間は１０キロメートル以上、時間的には１０分に一度程度の情報しかえられない）、また、降雨レーダー等のエラーや誤差を補うものであるため、この方法はあまり得策ではない。
【０１４３】
（３−１−３） 降雨判定と、ｗ（ｎ＋１）のｒｅｓｕｌｔ値に従い、ｗ（ｎ＋１）をアップロードした端末の信頼度（以下、ｌｌ（ｎ＋１）と表記）を更新する。
【０１４４】
以下のアルゴリズムで降雨判定を更新する。ここでは、ｗ（ｋ）はｗｋとし、ｗｋの要素はｗｋ＝（ｉｄｋ ｔｉｍｅｋ ｐｏｓｋ ｒｅｓｕｌｔｋ ａｃｃｋ）と表す。また、ｌｌｋはｗｋをアップロードした端末の信頼度とし、ＲＥＳは（３−１−２）で行われた降雨判定の値とし、降雨ありを１、降雨なしを０、不明を−１とする。
【０１４５】
（数１）
ｉｆ（ＲＥＳ＝＝ｒｅｓｕｌｔｋ）ｔｈｅｎ
ｌｌｋ＝（１−α）ｌｌｋ＋α …（１）
ｅｌｓｅｉｆ（ｎｏｔ（ＲＥＳ＝＝−１））ｔｈｅｎ
ｌｌｋ＝（ｌｌｋ−α）／（１−α） …（２）
ｅｌｓｅ（３−１−４）の更新手法を用いる
ｅｎｄ
【０１４６】
数１の式（１）及び式（２）中のαは、０より大きく１未満の数であり、本実施の形態では、０．３とする。このα及び式（１）、式（２）の更新のための式自体も、他の値や関数で置きかえ可能である。つまり、式（１）の場合は、連続適用した場合に漸近的に１の値に近づいていくような関数で、式（２）の場合は、逆に０に漸近的に近づく関数であればよい。
【０１４７】
数１の式（１）及び式（２）で、信頼度の更新が済んだ場合は、これで終了である。なお、数１の式（１）及び式（２）では、信頼度の変数への代入となっているが、実際には、端末データ１０４９内の信頼度が更新される。（３）に進んだ場合は、次の（３−１−４）で信頼度を更新する。
【０１４８】
（３−１−４） 近傍がなく、判定ができなかった場合の信頼度の更新は、アメダス等の気象観測データを利用して行う。
【０１４９】
図１３（ｂ）は、気象レーダーのデータを地図風に模式的に表わしたもので、１１０１１が、ｗ（ｎ＋１）の地点で、１１０１２が気象レーダーにより雨が降っているとされる地点である。この図から、１１０１１の地点では、気象レーダーの観測時点では降雨ありと観測されたと見ることができる。
【０１５０】
ただし、気象レーダーの値は、１０分あるいは５分間隔でしか更新されないため、このデータは過去のものであり、とくに変化が激しい雷雨のような場合には、問題が大きい。また、気象レーダーのデータには誤差（誤観測）もあるために、完全ではない。
【０１５１】
ここで、気象観測データによる降雨判定による信頼度の変更は、（３−１−３）で行った信頼度の変更の幅よりも小さくしたい。
【０１５２】
具体的には、以下の数２に従って更新を行う。ここでは、ｗ（ｋ）はｗｋとし、ｗｋの要素はｗｋ＝（ｉｄｋ ｔｉｍｅｋ ｐｏｓｋ ｒｅｓｕｌｔｋ ａｃｃｋ）と表す。また、ｌｌｋはｗｋをアップロードした端末の信頼度とし、ＲＥＳは気象観測データから得られた降雨判定の値とし、降雨ありを１、降雨なしを０とする。
【０１５３】
（数２）
ｉｆ（ＲＥＳ＝＝ｒｅｓｕｌｔｋ）ｔｈｅｎ
ｌｌｋ＝（１−β）ｌｌｋ＋β …（３）
ｅｌｓｅｉｆ（ｎｏｔ（ＲＥＳ＝＝−１））ｔｈｅｎ
ｌｌｋ＝（ｌｌｋ−β）／（１−β） …（４）
ｅｎｄ
【０１５４】
ここで、数２の式（３）、式（４）に出るパラメータβは、数１の式（１）、式（２）のパラメータαの値より小さなものとする。ここでは、０．１としておく。
【０１５５】
これで、信頼度の更新は終了する。
【０１５６】
（４） これで信頼度の計算と更新は終了である（図１２のステップ１０００５まで終了）。
【０１５７】
その端末の信頼度の計算が終わると、端末に新しい信頼度を告げる。これは、通常天候情報のアップロードと同一のコネクション内で行われる。例えばアップロードにＨＴＴＰを利用した場合、ＨＴＴＰの応答内で、天候情報サーバ１０４０から端末（天候検知装置１０００）側に伝えられる。
【０１５８】
以上のように、信頼度が更新される。これにより、継続的に間違いと思われるデータをアップロードし続ける端末の信頼度は徐々に下っていき、０に近づく。逆に、正しい情報をアップロードしていると思われる端末の信頼度は、徐々に高くなり１に近づく。
【０１５９】
今後天候情報サーバ制御部１０４１は、システム停止命令がない限り（ステップ１０００６）、新たな天候情報がアップロードされてくるのを待つ状態（ステップ１０００１）に戻る。
【０１６０】
次に、作成手段としての統合天候情報作成公開部１０４４が、これらの天候データ１０４８、端末データ１０４９から統合天候情報１０５１を作成する過程の説明を行う。図１１のアルゴリズムがこれに相当する。
【０１６１】
このアルゴリズムでは、周期動作を行うとしているが（ステップ１００１１）、周期動作ではなく、端末からある一定数（最小１でシステム全体の負荷で決定）アップロードがあった場合に動作を開始することと組みあわせてもよい。
【０１６２】
ステップ１００１２では、統合天候情報を作成または更新する。統合天候情報とは、気象観測データ１０５０と、天候データ１０４８、端末データ１０４９を統合して、現時点（または直前）での気象現況及び、短時間先の未来の予測データからなる。
【０１６３】
前者の気象観測現況は、天候データ１０４８から、最近の２分のデータを取得し信頼度でフィルタリングをかけたものと補助的に気象観測データ１０５０を用いて作成する。例えば、気象観測現況の対象地域に対して、どの地点で降雨があるのかを、天候データ１０４８と信頼度を用いて判断し、データがない地点に対しては、気象観測データ１０５０で補完する。さらに、できあがった気象現況情報から、気象予報技術を利用して短時間予報を作成したりする。
【０１６４】
最終的には、これら作成したデータは、統合天候情報として記録し、また外部に向けて公開できる形に整え（例えば、ＸＭＬ化やＨＴＭＬ化）、適当なプロトコル（例えば、ＨＴＴＰ）で公開する。
【０１６５】
以上のように、天候情報サーバ１０４０は動作する。
【０１６６】
最後に、天候情報サーバ１０４０へ天候情報をアップロードした後の端末（天候検知装置１０００）の動作を説明する。
【０１６７】
端末１０００は、天候情報サーバ１０４０にアップロードすると、その返答内で、端末自身に対する新しい信頼度を受けとる。
【０１６８】
端末１０００は、メモリ１０２９中に過去の信頼度を時系列で複数個記録しており（１０３１）、それを新しい信頼度と比較して下っている場合は、信頼度を回復すべく、パラメータ学習部１０２６はパラメータの調整を行う。パラメータは、図９に示したように４つあるが、このうち調整可能なのは、電界強度閾値と、傘傾き閾値の２つの閾値である。
【０１６９】
まず、電界強度閾値である。これは、傘利用探知装置１０１０から携帯情報端末１０２０への返しの電波が弱い場合を、傘が比較的遠くにある、すなわち、傘を利用していないとして切り捨てるための閾値である。この調節は、以下のように行う。
【０１７０】
今、直前にアップロードした気象情報の降雨判定をｒｅｓｕｌｔとして、ｒｅｓｕｌｔが降雨ありの場合は、電界強度閾値を一定数（Ｐとする）上げる。ｒｅｓｕｌｔが降雨なしの場合は、一定数下げることにより調節する。Ｐの値は、最大電界強度が１００として０〜２０程度をとる。
【０１７１】
次に傘傾き閾値であるが、ｒｅｓｕｌｔが降雨ありの場合は、傘傾き閾値を上げる。ｒｅｓｕｌｔが降雨なしの場合は、下げることにより調節する。なお、傘傾き閾値は、９８０×ｃｏｓ（θ）であり、初期状態ではθ＝３０°（０≦θ≦９０）である。上げ下げの調節は、θをＴずつ調節することで行い、Ｔは０〜５°程度とする。
【０１７２】
調節の幅Ｐ、Ｔは、一定値ではなく、信頼度が上った場合は、Ｐ、Ｔの値ともに小さくしていく。こうすることでパラメータが振動してしまうことを防ぐ。
【０１７３】
また、信頼度の値が、一定回数（例えば、１２０回＝４時間）連続して下りつづける、または、ある一定以下に下ったままである場合は、天候検知装置全体１０００のどこかに重大な問題があるとして、ユーザに警告を与えた上で、パラメータテーブル１０３０、信頼度１０３１、タグＩＤ１０３２を初期状態に戻す。これは、おそらくは、傘利用検知装置１０１１が間違った位置に取りつけられている、あるいは、使われていない傘に取りつけられた等している可能性が高いためである。
【０１７４】
なお、傘利用検知装置１０１０はユーザが自分の傘に取りつけるが、これは、なんらかのインセンティブがないとユーザはこの行動を起しにくい。ユーザが自ら装置の初期設定を行い、ユーザが天候情報をアップロードするには、天候情報サーバ側からユーザに対して、例えば、統合天候情報を配信する等のサービスが有効である。例えば、気象情報閲覧アプリ１０２５で、天候情報サーバ１０４０の天気予報を閲覧する場合に、もしその端末が天候情報をアップロードしている端末であれば、通常は課金されないと見られない情報を見られるようにするなどの工夫が考えられる。
【０１７５】
このように実施の形態３によれば、天候情報サーバは、多地点に位置する天候検知装置から天候情報を収集し、収集した天候情報に天候検知装置の信頼度に応じてフィルタリングを行い、フィルタリングした天候情報を用いて、現時点における気象現況を示す統合天候情を作成して公開することにより、高密度の観測地点から得られた天候情報を精度良く統合し、正確な気象データを提供することができる。
【産業上の利用可能性】
【０１７６】
本発明にかかる天候検知装置及び天候情報収集システムは、気象観測システム等に適用できる。
【符号の説明】
【０１７７】
１０００、２００１、２０１０ 天候検知装置
１００１ 気象データサーバ
１０１０、２００２、３００１、４００２、７００１、７００２ 傘利用検知装置
１０１１、２００３、６００２ 傘取り付け部
１０１２ 無線センサタグ
１０２０ 携帯情報端末
１０２１、２００６ 天候アプリ制御部
１０２２、２００７ 無線タグ読取装置
１０２３、２００８ 傘利用判定部
１０２４ 広域位置情報取得部
１０２５ 気象情報閲覧アプリ
１０２６ パラメータ学習部
１０２７、１０４６ データ・命令送受信部
１０２８ ユーザインタフェース
１０２９、１０４７、２００９、５００５ メモリ
１０４０ 天候情報サーバ
１０４１ 天候情報サーバ制御部
１０４２ 天候データ集計部
１０４３ 端末信頼度学習更新部
１０４４ 統合天候情報作成公開部
１０４５ 気象観測データ取得部
１０６０ ネットワーク
２００４、５００１、５０１０、６００１ 無線ＩＤタグ
２００５、３００２、４００１ 携帯情報端末
２０１１ ケーブル
２０１２ 読取部筐体
２０１３ 携帯情報端末本体
３００３ 傘
３００４、４０００ ユーザ
５００２ ループアンテナ部
５００３ データ送受信部
５００４ 制御部
５００６ ＩＣ部
５０１１ 転倒センサ
６００３ 受骨
６００４ 中棒
６００５ 下ろくろ
８０００ パラメータテーブル
【特許請求の範囲】
【請求項１】
傘に取り付けられる無線ＩＤタグと、
傘利用時の前記無線ＩＤタグとの距離が読み取り可能な距離に設定され、前記無線ＩＤタグを読み取る読み取り手段と、
前記無線ＩＤタグが読み取れた場合、傘が利用されていると判定し、前記無線ＩＤタグが読み取れない場合、傘が利用されていないと判定する判定手段と、
を具備する天候検知装置。
【請求項２】
鉛直方向に対する傾斜角を検出し、前記傾斜角が一定以上となった場合、前記無線ＩＤタグの機能をオフにする転倒検出手段を具備する請求項１に記載の天候検知装置。
【請求項３】
鉛直方向に対する傾斜角を検出する転倒検出手段を具備し、
前記判定手段は、前記無線ＩＤタグが読み取れ、かつ、前記傾斜角が一定の範囲内の場合、傘が利用されていると判定し、前記無線ＩＤタグが読み取れない場合、または、前記傾斜角が一定以上となった場合、傘が利用されていないと判定する請求項１に記載の天候検知装置。
【請求項４】
前記転倒検出手段は、加速度センサである請求項２又は請求項３に記載の天候検知装置。
【請求項５】
前記読み取り手段は、前記無線ＩＤタグからの電波の強度を測定し、
前記判定手段は、前記無線ＩＤタグが読み取れ、かつ、前記電波の強度が所定の閾値を超えた場合、傘が利用されていると判定し、前記無線ＩＤタグが読み取れない場合、または、前記電波の強度が所定の閾値以下の場合、傘が利用されていないと判定する請求項１に記載の天候検知装置。
【請求項６】
傘に取り付けられる無線ＩＤタグと、
傘利用時の前記無線ＩＤタグとの距離が読み取り可能な距離に設定され、前記無線ＩＤタグを読み取る読み取り手段と、
前記無線ＩＤタグが読み取れた場合、傘が利用されていると判定し、前記無線ＩＤタグが読み取れない場合、傘が利用されていないと判定する判定手段と、
現在地を示す位置情報を取得する位置情報取得手段と、
前記位置情報及び傘の利用状態を示す傘利用情報を含む天候情報を送信する送信手段と、
を有する天候検知装置と、
前記天候検知装置から送信された天候情報に基づいて、前記天候検知装置の信頼度を算出する信頼度算出手段と、
前記信頼度に基づいて、前記天候情報をフィルタリングするフィルタリング手段と、
フィルタリングされた前記天候情報を用いて現時点における気象現況を示す統合天候情報を作成する作成手段と、
を有する天候情報サーバと、
を具備する天候情報収集システム。
【請求項７】
前記信頼度算出手段は、第１天候検知装置から送信された第１天候情報と、実際の気象観測データ及び第２天候検知装置から送信された第２天候情報とを比較し、比較結果に基づいて、算出した前記第１天候検知装置の信頼度を更新する請求項６に記載の天候情報収集システム。
【請求項８】
前記天候検知装置は、前記更新された信頼度を取得し、更新された信頼度が過去の信頼度より低下した場合、前記判定手段における判定の基準となるパラメータを調整するパラメータ学習手段を具備する請求項７に記載の天候情報収集システム。
【請求項１】
傘に取り付けられる無線ＩＤタグと、
傘利用時の前記無線ＩＤタグとの距離が読み取り可能な距離に設定され、前記無線ＩＤタグを読み取る読み取り手段と、
前記無線ＩＤタグが読み取れた場合、傘が利用されていると判定し、前記無線ＩＤタグが読み取れない場合、傘が利用されていないと判定する判定手段と、
を具備する天候検知装置。
【請求項２】
鉛直方向に対する傾斜角を検出し、前記傾斜角が一定以上となった場合、前記無線ＩＤタグの機能をオフにする転倒検出手段を具備する請求項１に記載の天候検知装置。
【請求項３】
鉛直方向に対する傾斜角を検出する転倒検出手段を具備し、
前記判定手段は、前記無線ＩＤタグが読み取れ、かつ、前記傾斜角が一定の範囲内の場合、傘が利用されていると判定し、前記無線ＩＤタグが読み取れない場合、または、前記傾斜角が一定以上となった場合、傘が利用されていないと判定する請求項１に記載の天候検知装置。
【請求項４】
前記転倒検出手段は、加速度センサである請求項２又は請求項３に記載の天候検知装置。
【請求項５】
前記読み取り手段は、前記無線ＩＤタグからの電波の強度を測定し、
前記判定手段は、前記無線ＩＤタグが読み取れ、かつ、前記電波の強度が所定の閾値を超えた場合、傘が利用されていると判定し、前記無線ＩＤタグが読み取れない場合、または、前記電波の強度が所定の閾値以下の場合、傘が利用されていないと判定する請求項１に記載の天候検知装置。
【請求項６】
傘に取り付けられる無線ＩＤタグと、
傘利用時の前記無線ＩＤタグとの距離が読み取り可能な距離に設定され、前記無線ＩＤタグを読み取る読み取り手段と、
前記無線ＩＤタグが読み取れた場合、傘が利用されていると判定し、前記無線ＩＤタグが読み取れない場合、傘が利用されていないと判定する判定手段と、
現在地を示す位置情報を取得する位置情報取得手段と、
前記位置情報及び傘の利用状態を示す傘利用情報を含む天候情報を送信する送信手段と、
を有する天候検知装置と、
前記天候検知装置から送信された天候情報に基づいて、前記天候検知装置の信頼度を算出する信頼度算出手段と、
前記信頼度に基づいて、前記天候情報をフィルタリングするフィルタリング手段と、
フィルタリングされた前記天候情報を用いて現時点における気象現況を示す統合天候情報を作成する作成手段と、
を有する天候情報サーバと、
を具備する天候情報収集システム。
【請求項７】
前記信頼度算出手段は、第１天候検知装置から送信された第１天候情報と、実際の気象観測データ及び第２天候検知装置から送信された第２天候情報とを比較し、比較結果に基づいて、算出した前記第１天候検知装置の信頼度を更新する請求項６に記載の天候情報収集システム。
【請求項８】
前記天候検知装置は、前記更新された信頼度を取得し、更新された信頼度が過去の信頼度より低下した場合、前記判定手段における判定の基準となるパラメータを調整するパラメータ学習手段を具備する請求項７に記載の天候情報収集システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１２−２５４５（Ｐ２０１２−２５４５Ａ）
【公開日】平成２４年１月５日（２０１２．１．５）
【国際特許分類】
【出願番号】特願２０１０−１３５４２３（Ｐ２０１０−１３５４２３）
【出願日】平成２２年６月１４日（２０１０．６．１４）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
【公開日】平成２４年１月５日（２０１２．１．５）
【国際特許分類】
【出願日】平成２２年６月１４日（２０１０．６．１４）
【出願人】（０００００５８２１）パナソニック株式会社 (73,050)
[ Back to top ]