JPWO2019123832A1 - 端末管理装置及び端末装置 - Google Patents

Abstract

【課題】複数のＩｏＴ標準やＩｏＴプラットフォームが併存した場合に、最適なネットワークを構築する。【解決手段】本開示によれば、センサーから情報を収集する端末から、前記端末へアクセスが可能なタイミングに関するアクセスタイミング情報を受信する受信部と、前記情報を検索するサーバへ前記アクセスタイミング情報を送信する送信部と、を備える、端末管理装置が提供される。この構成により、複数のＩｏＴ標準やＩｏＴプラットフォームが併存した場合に、最適なネットワークを構築することが可能となる。【選択図】図１

Description

本開示は、端末管理装置及び端末装置に関する。

近時においては、近時では、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）の実社会への導入が進められている。例えば下記の特許文献１には、ＩｏＴデバイスにおけるコミュニティの形成について記載されている。

米国特許出願公開第２０１６／０１０５３０５号明細書

将来のＩｏＴネットワークは、複数のＩｏＴ標準やＩｏＴプラットフォームが併存することが見込まれるが、できる限り相互接続性を担保したネットワークとして構築されることが望ましい。上記特許文献に記載された技術は、複数のＩｏＴ標準やＩｏＴプラットフォームが併存することを想定していないため、相互接続性を担保したネットワークを構築することは困難である。

そこで、複数のＩｏＴ標準やＩｏＴプラットフォームが併存した場合に、最適なネットワークを構築することが求められていた。

本開示によれば、センサーから情報を収集する端末から、前記端末へアクセスが可能なタイミングに関するアクセスタイミング情報を受信する受信部と、前記情報を検索するサーバへ前記アクセスタイミング情報を送信する送信部と、を備える、端末管理装置が提供される。

また、本開示によれば、センサーから情報を取得するセンサー情報取得部と、前記情報を取得しようとする他装置がアクセス可能なタイミングに関するアクセスタイミング情報を端末管理装置へ送信する送信部と、を備える、端末装置が提供される。

また、本開示によれば、センサーから情報を取得するセンサー情報取得部と、前記センサーからデータを収集する際の計画に関する計画情報を端末管理装置へ送信する送信部と、を備え、前記計画情報は、前記情報を収集する頻度と、前記情報の収集の進捗を前記端末管理装置へアップロードするタイミングに応じて下記の表により規定される、端末装置が提供される。

また、本開示によれば、センサーから情報を収集する端末から、前記端末が前記センサーから前記情報を収集する際の計画に関する計画情報を受信する受信部と、前記計画情報と前記端末における前記情報の収集の進捗とに基づいて、前記端末におけるデータ収集状況を算出するデータ収集状況算出部と、前記情報を検索するサーバへ前記データ収集状況を送信する送信部と、を備える、端末管理装置が提供される。

また、本開示によれば、センサーから情報を取得するセンサー情報取得部と、前記情報を検索する複数のサーバから得られる情報収集要求に含まれる優先度に基づいて端末管理装置が作成したスケジュールに従って、前記端末管理装置へ前記情報を送信する送信部と、を備える、端末装置が提供される。

また、本開示によれば、検索機能を有する複数のサーバから、情報収集要求を受信する受信部と、前記情報収集要求に含まれる優先度に基づいて、前記複数のサーバに情報を提供するためのスケジュールを作成するスケジュール作成部と、前記スケジュールに基づいて、センサーから情報を収集する端末から前記情報を取得し、前記複数のサーバのそれぞれに送信する送信部と、を備える、端末管理装置が提供される。

また、本開示によれば、センサーから情報を取得するセンサー情報取得部と、前記情報を検索する複数のサーバから得られる情報収集要求に含まれる優先度に基づいて端末管理装置が作成したスケジュールに従って、前記複数のサーバへ前記情報を送信する送信部と、を備える、端末装置が提供される。

また、本開示によれば、検索機能を有する複数のサーバから、情報収集要求を受信する受信部と、前記情報収集要求に含まれる優先度に基づいて、センサーから情報を収集する端末から前記複数のサーバが前記情報を取得するためのスケジュールを作成するスケジュール作成部と、前記スケジュールを前記複数のサーバへ送信する送信部と、を備える、端末管理装置が提供される。

また、本開示によれば、センサーから情報を取得するセンサー情報取得部と、前記情報を検索する複数のサーバから得られる情報収集要求を受信する端末管理装置が算出した前記情報収集要求に共通に含まれる情報を、前記端末管理装置へ送信する送信部と、を備える、端末装置が提供される。

また、本開示によれば、検索機能を有する複数のサーバから、情報収集要求を受信する受信部と、前記複数のサーバから受信した前記情報収集要求の共通部分を算出する共通部分算出部と、センサーから情報を収集する端末から前記共通部分に関するデータを取得し、前記複数のサーバのそれぞれに送信する送信部と、を備える、端末管理装置が提供される。

また、本開示によれば、センサーから情報を取得するセンサー情報取得部と、前記情報を識別するためのタグ情報を生成するタグ情報生成部と、前記タグ情報を端末管理装置へ送信する送信部と、を備える、端末装置が提供される。

また、本開示によれば、センサーから情報を収集する端末から、前記情報を識別するためのタグ情報を取得するタグ情報取得部と、前記情報を検索するサーバへ前記タグ情報を送信する送信部と、を備える、端末管理装置が提供される。

また、本開示によれば、検索機能を有するサーバから、センサーから情報を収集する端末に関する自装置の能力の情報要求を受信する受信部と、前記情報要求に応じて、下記の表により規定される前記端末に関する能力を前記サーバへ送信する送信部と、を備える、端末管理装置が提供される。

以上説明したように本開示によれば、複数のＩｏＴ標準やＩｏＴプラットフォームが併存した場合に、最適なネットワークを構築することが可能となる。
なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。

ＩｏＴのレイヤー（Ｌａｙｅｒ）構造を示す模式図である。 異なるＩｏＴ標準やＩｏＴプラットフォームが併存するネットワークでは、相互接続できない場合を示す模式図である。 Ｗｅｂ検索システムにおける事前準備の処理を示す模式図である。 ＩｏＴ検索システムのブロックダイアグラムを示す模式図である。 ＩｏＴ検索システムのブロックダイアグラムを示す模式図である。 端末装置、センサー管理装置、ＩｏＴ検索システムのサーバの構成を示す模式図である。 第１の実施形態に係る処理を示すシーケンス図である。 第２の実施形態に係る処理を示すシーケンス図である。 第３の実施形態に係る処理を示すシーケンス図である。 第３の実施形態の別の方法に係る処理を示すシーケンス図である。 第３の実施形態の更に別の方法に係る処理を示すシーケンス図である。 第４の実施形態に係る処理を示すシーケンス図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

なお、説明は以下の順序で行うものとする。
１．ＩｏＴの概要
２．本開示に係るシステムの概要
３．第１の実施形態
４．第２の実施形態
５．第３の実施形態
６．第４の実施形態
７．第５の実施形態

１．ＩｏＴの概要
［ＩｏＴについて］
近時では、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）の実社会への導入が進められている。ＩｏＴは、物のインターネットであり、人が保有するスマートフォンの通信と異なり、物と直接通信を行う通信システムである。ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）やＭ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）もＩｏＴを実現するための通信トポロジーを表した言葉であり、機械と機械が通信する通信形態を表している。

ＩｏＴの特徴の１つとして、通信をするデバイスの数が多いということが挙げられる。例えば、一人の人間に関わる機械が１０倍から１００倍程度存在することを想定すると、通信をする機械は、人間対人間の通信に使用される電話等よりも１０倍から１００倍の数の通信機器があらゆる場所に配置される。

通信には、無線通信と有線通信があるが、ＩｏＴの場合には、無線通信を使用することが好適である。無線通信の方が、機器を配置する場所の制約がより少ないためである。

ＩｏＴシステムを構築するためには、一般的には、センサー、通信手段、アプリケーション、ストレージ、ユーザとのインタフェースが必要になる。基本的な流れとしては、センサーが情報を収集する。センサーは、その情報を無線通信等の通信手段を介してネットワーク側のアプリケーションに通知する。アプリケーションは、収集した情報に基づいて分析等を行い、分析結果を人間が見える形で報告する。ＩｏＴのユースケースは、工場管理、電力管理、農業やヘルスケアー等、多岐に渡る。現在は、その個々のユースケースに対応したＩｏＴシステムを別々に構築して運用していることが多いと考えられる。

従前では、個別の目的のために、個別のＩｏＴシステムを構築していた。このような方法は、コスト的には高額であり、汎用のＩｏＴシステムが求められている。そこで、さまざまなＩｏＴ標準やＩｏＴプラットフォームが検討されている。どのＩｏＴ標準、ＩｏＴプラットフォームも、図１に示すＩｏＴのレイヤー（Ｌａｙｅｒ）構造を有している。

以下では、図１に示すレイヤーを下層から順に説明する。デバイスセンサレイヤー（Ｄｅｖｉｃｅ Ｓｅｎｓｏｒ Ｌａｙｅｒ）１０は、様々なセンサー、アクチュエータが配置されるレイヤーである。ゲートウェイレイヤー（Ｇａｔｅｗａｙ ｌａｙｅｒ）１２は、様々な装置の違いを吸収するレイヤーであり、様々なセンサーからの情報を集約して上位レイヤーへ情報を上げるレイヤーである。コネクティビティレイヤー（Ｃｏｎｎｅｃｔｉｖｉｔｙ ｌａｙｅｒ）１４は、通信レイヤーである。このレイヤーは、ＬＴＥや３Ｇ,ＧＳＭ（登録商標）や、Ｗｉ−Ｆｉ，Ｂｌｕｅｔｏｏｔｈ（登録商標）,Ｚｉｇｂｅｅ等、様々な通信方式を使用することができる。

コモンサービスレイヤー（Ｃｏｍｍｏｎ Ｓｅｒｖｉｃｅ Ｌａｙｅｒ）１６は、ＩｏＴのアプリケーションに共通している機能を提供するレイヤーであり、異なるアプリケーション間のデータの橋渡し、異なる連結性（ｃｏｎｎｅｃｔｉｖｉｔｙ）の違いを吸収する。ＩｏＴのアプリケーションに共通している機能とは、例えば、ＩｏＴ機器の発見やアクティベーション、課金、設定、情報の収集等共通に使う機能である。

アプリケーションレイヤー（Ａｐｐｌｉｃａｔｉｏｎ ｌａｙｅｒ）１８は、ＩｏＴ用の様々なアプリケーションを配置するレイヤーである。例えば、サービス事業者毎に様々なアプリケーションがあることが見込まれる。アプリケーションには、ストレージ２０やＧＵＩ２２が必要となる。ストレージ２０の内容は、コモンサービスレイヤーを介してアプリケーションにサービスが提供されることが見込まれる。各アプリケーション間の連携もコモンサービスレイヤーを介して行われると考えて良い。

少なくとも、デバイスセンサレイヤー１２、コネクティビティレイヤー１４、アプリケーションレイヤー１８は、様々な方式、規格、仕組みがあるため、互いに情報をやり取りするにあたっては、相互運用性（ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）の問題が生じる。ＥＴＳＩ Ｍ２ＭやＯｎｅ Ｍ２Ｍ等の代表的なＩｏＴシステムでは、この問題を解決するために、ゲートウェイレイヤー１２とコモンサービスレイヤー１６を用意している。ゲートウェイレイヤー１２は、様々なデバイスセンサと様々な通信手段をつなげるために、規格の違いやシステムの違いを吸収するためのレイヤーとして用いる。コモンサービスレイヤー１６は、様々なアプリケーションと様々な通信手段をつなげるために、規格の違いやシステムの違いを吸収するためのレイヤーとして用いる。つまり、ゲートウェイレイヤー１２とコモンサービスレイヤー１６は、相互運用性のために違いを吸収するレイヤーとして設けられている。この方法は、単一の標準やプラットフォームで、ゲートウェイレイヤー１２やコモンサービスレイヤー１６という仕組みを用意した時にはうまく機能するだろう。

［複数の標準、プラットフォームの併存］
上述したように、単一のＩｏＴ標準やＩｏＴプラットフォームで動作している時には、様々なセンサーやアプリケーションの相互接続（Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ）の確保は可能である。しかし、図２に示すように、異なるＩｏＴ標準やＩｏＴプラットフォームが併存するネットワークでは、相互接続できない場合が出てくる。図２は、一方の機器がＩｏＴ標準／ＩｏＴプラットフォームＡで動作し、他方の機器がＩｏＴ標準／ＩｏＴプラットフォームＢで動作する場合を示している。このようなケースにおいて、相互接続するためには、データフォーマット変換等で対応することが多い。しかし、全てのケースにおいて、データフォーマット変換で問題が解決できるとは限らない。例えば、１時間ごとのデータが必要なアプリケーションに対し、１日毎のデータしか用意できないプラットフォームは、データ変換を行ってもアプリケーション側では本質的にデータを使用することができないからである。

［複数の標準／プラットフォームが併存しているネットワーク］
将来のＩｏＴネットワークは、複数のＩｏＴ標準やＩｏＴプラットフォームが併存して、できる限り相互接続性を担保したネットワークとして構築されることが見込まれる。そのような不完全なネットワークでは、様々な制約条件が生じる可能性がある。以下に示す表１は、不完全ネットワークの特徴を示す。不完全ネットワークでは、データを取りに行こうとしても、そのデータアクセスの容易性が不均一であるということが生じる。

［想定済みの特定の目的のために構築されたＩｏＴシステム］
ＩｏＴシステムを構築する目的が明確である場合には、単一の標準、プラットフォームでＩｏＴシステムを構築することが合理的である。想定済みの目的のために最適なシステムを構築することが可能であるためである。

［不特定の目的のために構築されたＩｏＴシステム］
一方、調べたいものがわからないような事象がある。ユーザ等が調べたいことをシステムに入力したときに、調べたいことが初めて判明するような事象である。例えば、「Ａさんがこれから新宿に行った場合に、風邪をひく確率知りたい。」、「今年の小麦の出来具合」、「欲しい部品の供給量と納期が確実なベンダーはどこか?」、「自分の体調にあった旅行先はどこか?」などが該当する。

このように、そのような目的のものかが定まらない場合には、特定のＩｏＴ検索システムで知りたいことを得られるかは不確かである。つまり、単一のＩｏＴ検索システムでは答えを得ることができない可能性があり、この場合、複数のプラットフォームのＩｏＴ検索システムに問い合わせをして答えを得る方が合理的である。その場合には、複数の標準・プラットフォーム上の複数のＩｏＴ検索システムから情報を得て、知りたいことを得る必要がある。

また、ここで挙げた例のように、検索される質問の組合せ等は無限に想定できるため、ユーザがどのような質問を不完全なＩｏＴネットワークに質問してくるかは未知である。これらのユーザの質問に対し、瞬時に返事を返すＩｏＴ検索システムが今後求められるようになることが見込まれる。

ところで、検索システムといえば、Ｗｅｂ検索システムが世の中に浸透している。しかし、Ｗｅｂ検索システムは、検索ワードに近いものを選び出して表示するシステムであり、検索対象はＷｅｂであり主な対象は言語である。一方、ＩｏＴ検索システムでは、格納されているデータは、言語ではなくｂｉｔ列であるデータである。従って、ＩｏＴ検索システムでは、どういうデータを持ってきて、どのように解析したらユーザが欲しい情報を提供できるかを判断し、結果として表示しなければならない。

［従来のＷｅｂ検索システム］
以上のように、ＩｏＴ検索システムは、現在のＷｅｂ検索システムとは異なる。ここでは、このＷｅｂ検索システムの仕組みを説明する。Ｗｅｂ検索システムの最大の特徴は、ランキング（Ｒａｎｋｉｎｇ）である。Ｗｅｂ検索システムは、検索ワードに関係のあるＷｅｂページをランキングとともに瞬時に表示するところに特徴がある。初代Ｗｅｂ検索のランキングに使われる手段は、「ページランク」、「アンカーテキスト」、単語である。「ページランク」は、人気のあるページのランクを上にするというものである。また、リンクが多く貼られているページは重要と判断される。

「アンカーテキスト」は、リンクにつけられた文字列の代表的な文字列である。例えば、「Ａ社の新製品はこちらです」というリンクがあった場合に、「Ａ社」という部分がアンカーテキストであり、そのページは、Ａ社に関するページとしてはランクが上がることになる。「単語」は、Ｗｅｂページ内にその単語が多く含まれているか等でランクを上げるものになる。なお、以上は初期のＷｅｂ検索の内容であり、最新のものはより改良されていることに留意すべきである。

Ｗｅｂ検索システムの２番目の特徴は、検索ワードが入力された時に瞬時に回答を出すための事前準備である。事前準備は、クローリングとインデックス化の２つのフェーズに分けることができる。クローリングは、世界中のＷｅｂページについて、事前にＷｅｂページの内容を収集する作業である。クローラーと呼ばれる論理的なロボットがＷｅｂページを定期的に巡回等して情報を集め、それをＷｅｂ検索システムのリポジトリと呼ばれる格納場所に保存しておく。インデックス化は、集めたＷｅｂページの内容をリンクや含まれている文字列等から内容を整理し、検索ワードに対応したランクを出しやすいようにデータを構造化しておく作業である。

図３は、Ｗｅｂ検索システムにおける事前準備の処理を示す模式図である。処理５１０において、各Ｗｅｂページがどのようなワードやリンクを含んでいるかを事前に調査しておく。この際、クローリングとインデックス化が行われる。処理５１２にて検索ワードが入力されると、処理５１４にて検索ワードを含んでいるＷｅｂページを表示する。以上のように、Ｗｅｂ検索システムでは、検索に対する答えを出しやすいようなデータ構造を事前に準備しているということになる。

［従来のＷｅｂ検索システムとＩｏＴ検索システムの違い］
以下では、従来のＷｅｂ検索システムとＩｏＴ検索システムの違いを箇条書きで示す。
・ＩｏＴのデータは、単なるｂｉｔ列であることが多いので、クローラーが意味を理解できない可能性がある。
・ＩｏＴのデータは、ページへのリンクといったものが無い可能性が高い。ＩｏＴデータがどの程度使われた実績があるのかを把握することは困難である。
・検索ワードとして、単にその情報が見たいという検索結果よりも、データを解析した結果を返してほしいという要求が多くなると予想する。ここで、ＡＩが必要になる可能性がある。
・Ｗｅｂ検索システムで検索される側は、基本的に起動している状態である。一方、ＩｏＴ検索システムで検索されるセンサー側の端末は、消費電力を抑える等の観点から、起動していない場合がある。

図４、図５は、ＩｏＴ検索システムのブロックダイアグラムを示す模式図である。図４の処理５２０では、ユーザによって検索ワードが入力される。処理５２２では、検索ワードの意味を理解するための処理を行う。処理５２２は、簡易なＡＩが行っても良い。処理５２４では、検索ワードに対し、どのネットワークからどのようなデータが必要かを計画する。処理５２６では、不完全ネットワークからデータを取得する。処理５２８では、取得したデータの意味を解析し、検索結果を決定し、検索結果を表示するための文章を作成する。

また、図５の処理５３０では、検索ワードが入力される。処理５３２では、不完全ネットワーク内にどのような情報があるかを事前に調査し、インデックス化する。処理５３４では、検索ワードと、インデックス化された情報とのマッチングを行う。処理５３６では、更にオンデマンドで取得しなければならないデータの内容を特定する。処理５３８では、不完全ネットワークからデータを取得する。処理５４０では、取得したデータの出力フォーマットを整えて結果を出力する。また、処理５４２では、取得したデータの意味を解析し、検索結果を決定し、検索結果を表示するための文章を作成する。

［ＩｏＴ検索システムに必要なデータのタグについて］
データの意味を簡易なテキストで付与したものをメタデータと称する。メタデータは、単なるｂｉｔ列であるＩｏＴデータの意味を知る上で重要である。本実施形態では、このメタデータをどのように付与するかについては詳しくは検討しない。データへのメタデータは、センサーやアプリケーション等がつけることができる。従来は、人がＷｅｂを作った時に付けていたものが、ローカルなセンサーが、メタデータを付けることがあることを考慮する。

２．本開示に係るシステムの概要
［本開示で注力する技術領域］
本開示では、ＩｏＴの機器からユーザが必要な情報を検索するためのＩｏＴ検索システムというユースケースを想定して技術を開示している。特に、本開示では、ＩｏＴ検索システムが、ローカルなエッジにあるローカルストレージからデータを収集することが必須の機能であるととらえ、このローカルストレージからデータを収集するという部分にフォーカスしている。従って、主体は、ＩｏＴ検索システムだけではなく、その他一般のＩｏＴシステムも本開示の範囲内である。

ＩｏＴ検索システムは、人間だけではなく、機械が直接する場合もあるので、検索Ｗｉｎｄｏｗに人間が入力した文字を理解するという点については、本開示では注力しない。検索すべきキーワードが抽出された上で、更に生じる課題に注力する。また、ＩｏＴデータにはタグ付がされていることも想定する。特に、データとそのデータの内容が書かれているタグがエッジストレージに格納されている場合に、むやみにそのデータとタグをネットワーク側から引き出すのは、それらのエッジにあるセンサー等の消費電力に大きな影響を与える。本開示では、この点を含めて解決していくことを想定している。

［本開示のシステムに係る装置］
本開示のシステムでは、情報を収集するセンサー、Ｉｏｔ検索システムに加え、センサーを管理するセンサーマネジメント（ｓｅｎｓｏｒ ｍａｎａｇｅｍｅｎｔ：センサー管理装置）が関わる。情報を収集するセンサーは、例えば家庭の電化製品（家電）、人が保有するスマートフォンなどのモバイル機器、自動車など、あらゆる機器に装着される。センサーと付随して、センサーが検出したデータを保持するストレージ（記憶部）が設けられる。また、センサーが設けられた機器は、端末（Ｅｄｇｅ）の装置である。このため、本明細書において、センサーが設けられた機器（端末、または端末装置）を「エッジストレージ」、「エッジデバイス」と称する場合がある。また、説明の便宜上、センサーが設けられた機器（端末装置）を、単にセンサーと称する場合もある。

エッジストレージ、センサーマネジメント、及びＩｏＴ検索システムは、相互に通信可能に構成される。このため、エッジストレージ、センサーマネジメント、及びＩｏＴ検索システムのそれぞれは、情報の送信部、及び受信部を備え、相手装置に対し情報を送り、相手装置から情報を取得することができる。通信の方式は限定されるものではないが、有線又は無線による通信、特に無線による通信を想定する。

センサーマネジメントは、エッジストレージとは別に設けられ、エッジストレージを管理するサーバなどの装置として構成される。本明細書において、センサーマネジメントをセンサーマネジメントエンティティ、エッジストレージ管理エンティティ、センサーストレージ管理エンティティ等と称する場合がある。センサーマネジメントは、コモンサービスレイヤー１６に相当する機能を備えている。

ＩｏＴ検索システムは、ユーザが入力した検索ワードに基づいて、エッジストレージが収集したデータを検索するシステムであり、現在のインターネットにおけるＷｅｂ検索システムをＩｏＴの検索システムに置き換えた態様を想定する。ＩｏＴ検索システムの装置として、検索機能を備えたサーバが相当する。

図６は、端末装置（エッジストレージ）１００、センサー管理装置（センサーマネジメント）２００、ＩｏＴ検索システムのサーバ３００の構成を示す模式図である。端末装置１００は、センサー１０２、ストレージ１０４、センサー情報取得部１０６、タグ情報生成部１０８、送受信部１１０を備える。センサー管理装置２００は、データ収集状況算出部２０２、スケジュール作成部２０４、共通部分算出部２０６、送受信部２０８、タグ情報取得部２１０を備える。サーバ３００は、送受信部３０２、検索部３０４、タグ情報取得部３０６を備える。なお、図６に示す端末装置１００、センサー管理装置２００、サーバ３００の構成要素は、ハードウェア、またはＣＰＵなどの中央演算処理装置とこれを機能させるためのソフトウェア（プログラム）から構成することができる。

３．第１の実施形態
第１の実施形態は、ＩｏＴ検索システムのためにエッジセンサーに負担をかけずにデータを取得する方法に関する。具体的に、第１の実施形態は、以下の項目に関する。
・ＩｏＴ検索システムが、センサーの中のエッジストレージにアクセス可能な時間、及び／又はアクセスしてはいけない時間又はアクセス可能な周期を問い合わせるため方法。
・プラットフォーム毎に優先度を設定して、エッジストレージへのアクセス許可時間等を優先度毎に変更する方法。
・ＩｏＴセンサーが、第３者のシステムがアクセス可能な時間をセンサーマネジメントに通知する方法。
・ＩｏＴ検索システムが、そのアクセス可能な時間にセンサーからデータを吸い出す動作
・アクセス可能時間を複数の設定を、異なる属性のエンティティ（ｅｎｔｉｔｙ）のために用意する方法

ＩｏＴデータを事前にサーバー側に格納するために、タグ情報とそのタグに付随したＩｏＴデータを取得するために、クローリングを行うことを考える。なお、クローリングとは、特定のセンサーやサーバーの情報を取りに行くことを意味する。この際、ＩｏＴ機器は、低消費電力の要求から、起動している時間に制限があるものが多い。このため、そのタグ情報を得ようとしてもＩｏＴ機器とその内部にあるタグにアクセスできないことがある。このため、特にＩｏＴ機器に関しては、クローリングの作業効率が著しく低くなるという問題が想定できる。

第１の実施形態では、各ＩｏＴ機器などのセンサーは、アクセス可能な時間（ｗａｋｅ ｕｐ ｔｉｍｅ）を、その機器の情報を知っている常時アクセス可能なサーバー（センサーマネジメント）に報告しておく。ＩｏＴ検索システムは、そのサーバーに対し、どのようなセンサーがどのタイミングでアクセス可能であるかを事前に問い合わせ、アクセス可能なタイミングに関する情報（アクセスタイミング情報）を取得する。

図７は、第１の実施形態に係る処理を示すシーケンス図である。図７では、エッジストレージ、センサーマネジメント、及びＩｏＴ検索システムの間の処理を示している。ステップＳ１０では、エッジストレージが、センサーを使用して取得したデータの蓄積を継続的に行う。ステップＳ１１では、エッジストレージがセンサーマネジメントに対し、エッジストレージが起動している起動時間（ｗａｋｅ ｕｐ ｔｉｍｅ）を送信する。この起動時間は、上述したアクセスタイミング情報に相当する。次のステップＳ１２では、センサーマネジメントが、起動時間を蓄積する。次のステップＳ１４では、ＩｏＴ検索システムが、センサーマネジメントに対し、センサ情報の要求を送信する。次のステップＳ１６では、センサーマネジメントが、センサーに関する情報と、起動時間に関する情報をＩｏＴ検索システムへ送信する。次のステップＳ１８では、ＩｏＴ検索システムが、エッジストレージが起動している時間内で、エッジストレージからデータとタグを取得する。次のステップＳ２０では、ＩｏＴ検索システムが、データとタグを蓄積する。

以上のように、第１の実施形態では、センサー（エッジストレージ）へアクセス可能なタイミングに関する情報に基づいて、アクセス可能な時間にセンサーにアクセスをして、ＩｏＴデータと関連するタグを取得する。これにより、クローラー（ＩｏＴ検索システム、又はそのサーバー）が適切に情報を集めに行くことができる。ＩｏＴ検索システムが直接センサーから情報を取得する理由は、全てのデータがネットワーク側に常時集められているとは限らないためであり、むしろ、データのほとんどは局所的に保持され、必要な時にネットワーク側に吸い出されるというケースがあるからである。もちろん、古いデータは、ネットワーク側に吸い出されている可能性が高いが、新しいデータは、センサー側のエッジストレージ内に格納されたままであることが多い。古いデータだけでは不足する場合、新しいデータをセンサーのエッジストレージから得る必要があるが、このような場合に図７に示した手順でアクセスすることにより、センサー側の電池の消費を抑えることが可能になる。

ステップＳ１１において、センサーが、センサーに対してアクセス可能な時間をセンサーマネジメントに通知するが、そのアクセス可能時間は、以下の表２に示すように、複数のシステムに異なる値を設定することができる。

表２に示したように、同じプラットフォーム内からのアクセスに対する許容するアクセス可能時間と、プラットフォーム外からのアクセスに対するアクセス可能時間を異なるものにすることができる。この仕組みを用いて、優先度を設定することが可能となる。

図７中のステップＳ１６（Ｐｒｏｖｉｄｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ ｒｅｇａｒｄｉｎｇ ｓｅｎｓｏｒ ａｎｄ ｉｔｓ ｗａｋｅ ｕｐ ｔｉｍｅ）というシグナリング（ｓｉｇｎａｌｌｉｎｇ）で使用されるフォーマットの例を表２、表３、表４に示す。また、図７のステップＳ１４（Ｒｅｑｕｅｓｔ ｓｅｎｓｏｒ ｉｎｆｏｒｍａｔｉｏｎ）というシグナリングで使用されるフォーマットの例を表５に示す。

４．第２の実施形態
第２の実施形態では、エッジストレージのデータ収集計画書を保持するセンサーマネジメントが、ＩｏＴ検索システムの要求に基づき、その情報を提供する。ＩｏＴ検索システムは、取得した情報に基づき、エッジストレージからデータを取得するかどうかを判断して、データの取得を行う。

低消費電力を追及するＩｏＴ機器やＩｏＴ用のセンサーは、常にクローリングされて情報を取られると電力を消費する。このため、第１の実施形態のようにエッジストレージへのアクセス可能な時間を制限する。しかし、センサーの中のデータまでクローリングする必要があるかを事前に判断して、センサーの中のデータをクローリングする必要がないときは、センサーに対してデータの収集をするためにアクセスするような動作を行わないことが重要である。

センサーマネジメントは、エッジストレージ（センサー）が持つデータ収集計画書（ｓｃｈｅｄｕｌｅ ｔｏ ｃｏｌｌｅｃｔ ｄａｔａ）を保持しており、前回、ｓｅｎｓｏｒからデータを吸い出した後、どれ位のデータがセンサー若しくはそのストレージに保存されているかを示す情報を保持する。ＩｏＴ検索システムや、その他のセンサーデータを必要とするシステムは、アクセス（ｄａｔａ ａｃｃｅｓｓｉｂｉｌｉｔｙ）に難があるセンサーのデータやエッジストレージからデータを吸い出す前に、これらのセンサーやエッジストレージを管理しているセンサーマネジメントに対して、アクセスに難があるセンサー若しくはエッジストレージのデータ取得状況を問い合わせる。その問い合わせた結果に応じて、センサー等にアクセスする価値があると認めた時だけアクセスすることによりセンサー等のデータ送信にかかわる負担を減らすことができる。このような動作は、従来のＷｅｂでのデータ収集のためのロボットであるクローラーには求められなかったものであり、ＩｏＴ検索システムならではの動作になる。

図８は、第２の実施形態に係る処理を示すシーケンス図である。図８では、エッジストレージ、センサーマネジメント、及びＩｏＴ検索システムの間の処理を示している。ステップＳ３０では、エッジストレージが、センサーを使用して取得したデータの蓄積を継続的に行う。ステップＳ３１では、エッジストレージがセンサーマネジメントに対し、データ収集計画書（ｓｃｈｅｄｕｌｅ ｔｏ ｃｏｌｌｅｃｔ ｄａｔａ）を送る。次のステップＳ３２では、センサーマネジメントがエッジストレージへ、エッジストレージが現在取得しているデータを報告するよう要求を送る。次のステップＳ３４では、エッジストレージがセンサーマネジメントに対し、取得していない残りのデータ量を報告する。次のステップＳ３６では、センサーマネジメントが、エッジストレージにおけるデータの収集状況を蓄積する。次のステップＳ３８では、ＩｏＴ検索システムが、センサーマネジメントに対し、エッジストレージにおけるデータの収集状況を要求する。次のステップＳ４０では、センサーマネジメントが、ＩｏＴ検索システムに対し、エッジストレージにおけるデータの収集状況を送信する。

次のステップＳ４２では、ＩｏＴ検索システムが、エッジストレージにおけるデータの収集状況に基づいて、エッジストレージからデータを収集することを決定する。次のステップＳ４４では、ＩｏＴ検索システムが、エッジストレージが起動している時間内で、エッジストレージからデータとタグを取得する。次のステップＳ４６では、ＩｏＴ検索システムが、データとタグを蓄積する。

表６に１つのセンサーのデータ収集計画書と、その進捗状況を表すフォーマットの例を示す。センサーマネジメントは、この表６に相当する情報を、センサー毎に保持している。

５．第３の実施形態
第３の実施形態では、複数のＩｏＴシステムが要求するエッジストレージへのアクセスの優先度に基づき、センサーマネジメントがスケジューリングを行う。具体的に、第３の実施形態は、以下の項目に関する。
・複数のＩｏＴシステムが要求するエッジストレージへのアクセスの優先度に基づき、センサーマネジメントがスケジューリングを行い、そのスケジュール情報を各ＩｏＴシステムに送信する。
・複数のＩｏＴシステムが要求するエッジストレージへのアクセスの優先度に基づき、センサーマネジメントがスケジューリングを行い、各ＩｏＴシステムの代替えしてデータを取得する。
・更に、複数のＩｏＴシステムが要求するエッジストレージへのデータ要求の最大公約数的な部分集合のデータをセンサーマネジメントが同定して、代表して、そのデータを取得する。
・ＩｏＴ検索システムは、エッジストレージからデータを取得できる時間を把握して、その結果をエンドユーザに提示する。検索結果が得られるまでどの程度時間がかかるかを提示する。

第１の実施形態では、エッジストレージを持つセンサー等のエンティティ（デバイス）にアクセスできる時間を制限した。しかし、その制限した時間に、集中してＩｏＴ検索システムのクローラーがデータを集めに来ると、センサー等のエンティティ側で対応できなくなる。

第３の実施形態では、クローリング（データ収集）のためのアクセスをクローラー毎（ＩｏＴ検索システム毎）にスケジューリングする調整機能をセンサーマネジメント内に配置する。この機能をスケジューラ（ｓｃｈｅｄｕｌｅｒ）とも称する。スケジューラは、各クローラーの要求を代替えしてセンサーからデータを引き出す。引き出したデータは、元々リクエストを行ったＩｏＴ検索システムに対して送信する。どのような優先度に基づいてスケジューリングするかは、センサーマネジメント内のスケジューラの実装に依存するが、その優先度を決めるにあたって、各ＩｏＴ検索システムからＱｏＳの優先度に対応する値とともにリクエストしても良い。

図９は、第３の実施形態に係る処理を示すシーケンス図である。図９では、エッジストレージ、センサーマネジメント、及びＩｏＴ検索システムの間の処理を示している。ステップＳ５０では、エッジストレージが、センサーを使用して取得したデータの蓄積を継続的に行う。ステップＳ５１では、エッジストレージがセンサーマネジメントに対し、エッジストレージが起動している起動時間（ｗａｋｅ ｕｐ ｔｉｍｅ）を送信する。次のステップＳ５２では、ＩｏＴ検索システム（１）が、センサーマネジメントに対し、優先度ＩＤを示してエッジストレージからのデータ収集を要求する。次のステップＳ５４では、ＩｏＴ検索システム（２）が、センサーマネジメントに対し、優先度ＩＤを示してエッジストレージからのデータ収集を要求する。

次のステップＳ５６では、センサーマネジメントが、ＩｏＴ検索システム（１）、ＩｏＴ検索システム（２）からの要求をスケジューリングする。スケジューリングの際には、優先度ＩＤが用いられる。

次のステップＳ５８では、ステップＳ５６で決定したスケジュールに基づき、センサーマネジメントが、ＩｏＴ検索システム（１）の要求に応じて、エッジストレージが起動している時間内で、エッジストレージからデータとタグを取得する。次のステップＳ６０では、センサーマネジメントが、ステップＳ５８で取得したデータとタグを、ＩｏＴ検索システム（１）に送信する。

次のステップＳ６２では、ステップＳ５６で決定したスケジュールに基づき、センサーマネジメントが、ＩｏＴ検索システム（２）の要求に応じて、エッジストレージが起動している時間内で、エッジストレージからデータとタグを取得する。次のステップＳ６４では、センサーマネジメントが、ステップＳ６２で取得したデータとタグを、ＩｏＴ検索システム（２）に送信する。

また、第３の実施形態の別の方法では、スケジューラ（センサーマネジメント）が各クローラー（ＩｏＴ検索システム）からの要求を受け付けて、各クローラーの優先度考慮した上で決定したスケジューリング情報を、各クローラーに対してアクセスすべき時間として通知する。図１０は、この場合の処理を示すシーケンス図である。図１０では、エッジストレージ、センサーマネジメント、及びＩｏＴ検索システムの間の処理を示している。ステップＳ７０では、エッジストレージが、センサーを使用して取得したデータの蓄積を継続的に行う。ステップＳ７１では、エッジストレージがセンサーマネジメントに対し、エッジストレージが起動している起動時間（ｗａｋｅ ｕｐ ｔｉｍｅ）を送信する。次のステップＳ７２では、ＩｏＴ検索システム（１）が、センサーマネジメントに対し、優先度ＩＤを示してエッジストレージからのデータ収集を要求する。次のステップＳ７４では、ＩｏＴ検索システム（２）が、センサーマネジメントに対し、優先度ＩＤを示してエッジストレージからのデータ収集を要求する。

次のステップＳ７６では、センサーマネジメントが、ＩｏＴ検索システム（１）、ＩｏＴ検索システム（２）からの要求をスケジューリングする。スケジューリングの際には、優先度ＩＤが用いられる。次のステップＳ７８では、センサーマネジメントが、ＩｏＴ検索システム（１）に対し、ステップＳ７６で決定したスケジュールの情報を送信する。次のステップＳ８０では、センサーマネジメントが、ＩｏＴ検索システム（２）に対し、ステップＳ７６で決定したスケジュールの情報を送信する。

次のステップＳ８２では、ステップＳ７８で受信したスケジュールに基づき、ＩｏＴ検索システム（１）が、エッジストレージが起動している時間内で、エッジストレージからデータとタグを取得する。

次のステップＳ８４では、ステップＳ７８で受信したスケジュールに基づき、ＩｏＴ検索システム（２）が、エッジストレージが起動している時間内で、エッジストレージからデータとタグを取得する。

また、第３の実施形態の更に別の方法では、事前に集めたいデータの情報を、複数のプラットフォームや複数のＩｏＴ検索システムの情報を集約し、どのようなデータを集めるかについて最大公約数的なものを同定する。そして、その共通の収集すべき情報は、エッジストレージ側に複数回データ収集をしなくても済むようにしておく。そして、しかるべくタイミングでセンサーに負担を掛けないようにしてＩｏＴ検索システム側にデータを吸い出す。その吸い出したデータは、事前にこのようなデータが欲しいと予約していた複数のプラットフォームや複数のＩｏＴ検索システムの検索依頼に対して分配する。図１１は、この場合の処理を示すシーケンス図である。図１１では、エッジストレージ、センサーマネジメント、及びＩｏＴ検索システムの間の処理を示している。ステップＳ９０では、エッジストレージが、センサーを使用して取得したデータの蓄積を継続的に行う。ステップＳ９１では、エッジストレージがセンサーマネジメントに対し、エッジストレージが起動している起動時間（ｗａｋｅ ｕｐ ｔｉｍｅ）を送信する。次のステップＳ９２では、ＩｏＴ検索システム（１）が、センサーマネジメントに対し、優先度ＩＤを示してエッジストレージからのデータ収集を要求する。次のステップＳ９４では、ＩｏＴ検索システム（２）が、センサーマネジメントに対し、優先度ＩＤを示してエッジストレージからのデータ収集を要求する。

次のステップＳ９６では、センサーマネジメントが、ＩｏＴ検索システム（１）、ＩｏＴ検索システム（２）からの要求について、サブセットを特定する。ここで、サブセットとは、ＩｏＴ検索システム（１）、ＩｏＴ検索システム（２）からの要求のうち、共通のデータの収集要求に相当する。すなわち、サブセットは、ＩｏＴ検索システム（１）、ＩｏＴ検索システム（２）がどのようなデータを集めようとしているかについて、両者が集めようとするデータの最大公約数的なデータを示す。次のステップＳ９８では、センサーマネジメントが、エッジストレージが起動している時間内で、エッジストレージからサブセットのデータとタグを取得する。

次のステップＳ１００では、センサーマネジメントが、ＩｏＴ検索システム（１）に対し、サブセットのデータとタグを送信する。この際、センサーマネジメントが、ＩｏＴ検索システム（１）に対し、ＩｏＴ検索システム（１）が元々要求していたデータに対し、サブセットのデータに含まれない残りのデータに関する情報を伝えることもできる。

次のステップＳ１０２では、センサーマネジメントが、ＩｏＴ検索システム（２）に対し、サブセットのデータとタグを送信する。この際、センサーマネジメントが、ＩｏＴ検索システム（２）に対し、ＩｏＴ検索システム（２）が元々要求していたデータに対し、サブセットのデータに含まれない残りのデータに関する情報を伝えることもできる。

次のステップＳ１０４では、ＩｏＴ検索システム（１）が、エッジストレージが起動している時間内で、エッジストレージからサブセット以外の残りのデータとタグを取得する。 次のステップＳ１０６では、ＩｏＴ検索システム（２）が、エッジストレージが起動している時間内で、エッジストレージからサブセット以外の残りのデータとタグを取得する。

また、図９〜図１１に示した処理と関連して、ＩｏＴ検索システムは、センサーの結果をいつ受け取ることができるかについて予測ができるため、検索結果を返信するのにかかる時間をユーザに対して提示することができる。

６．第４の実施形態
第４の実施形態では、タグの収集は直接センサーに対して行うが、そのタグに関連したデータは、センサーを管理するセンサーマネジメント経由でのみ収集することができる方法に関する。

ウェブ検索等で用いられている従来のクローラーは、ＩｏＴデータに相当するＷｅｂの文書や図と、それらのＷｅｂの文書や図の内容を簡易に示すタグを同時に取得することが可能であった。しかし、ＩｏＴシステムにおいては、タグと比較して、データ量が膨大になる可能性がある。そのようなデータ全てを引き出してＩｏＴ検索システムでのインデックス化のために処理するのは、ネットワーク全体にとっても問題が大きかった。なお、インデックス化とは、事前に情報を整理しておき、データを引き出しやすくする処理をいう。

第４の実施形態では、クローラー（ＩｏＴ検索システム）に対しては、タグの提供だけを許可し、実際のデータは、センサー等に搭載されているエッジストレージを管理するセンサーマネジメント（Ｅｄｇｅ Ｓｔｏｒａｇｅ Ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｙ／Ｓｅｎｓｏｒ Ｓｔｏｒａｇｅ Ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｙ）からのみ収集するようにする。つまり、ＩｏＴ検索システムに対し、エッジストレージ（ｅｄｇｅ ｄｅｖｉｃｅ）へのアクセスは認めるが、抽出できる内容は制限されたある領域だけであり、全てのデータは、そのエッジストレージを管理しているセンサーマネジメントからのみ取得可能とする方法である。

図１２は、第４の実施形態に係る処理を示すシーケンス図である。図１２では、エッジストレージ、センサーマネジメント、及びＩｏＴ検索システムの間の処理を示している。ステップＳ１１０では、エッジストレージが、センサーを使用して取得したデータの蓄積と、タグの情報の生成を継続的に行う。ステップＳ１１２では、エッジストレージがセンサーマネジメントに対し、エッジストレージが起動している起動時間（ｗａｋｅ ｕｐ ｔｉｍｅ）を送信する。次のステップＳ１１４では、センサーマネジメントが、起動時間を蓄積する。

次のステップＳ１１６では、ＩｏＴ検索システムが、センサーマネジメントに対し、エッジストレージのタグの情報を要求する。次のステップＳ１１８では、センサーマネジメントが、ＩｏＴ検索システムに対し、エッジストレージが起動している起動時間に関する情報を送信する。次のステップＳ１２０では、ＩｏＴ検索システムが、エッジストレージから、起動時間内にタグの情報を取得する。

次のステップＳ１２２では、ＩｏＴ検索システムが、エッジストレージから取得したタグの情報を蓄積する。次のステップＳ１２４では、Ｉｏｔ検索システムが、センサーマネジメントに対し、タグに関連するセンサーのデータを要求する。次のステップＳ１２６では、センサーマネジメントが、エッジストレージから、タグに関連するセンサーのデータを取得する。次のステップＳ１２８では、センサーマネジメントが、ステップＳ１２６で取得したタグに関連するデータをＩｏＴ検索システムへ送信する。

ＩｏＴ検索システムでは、データを収集したい事項が生じた時に、事前に収集したタグをもとに、どのサーバーにアクセスしてデータを収集するかを事前に整理しておく必要がある。そのための情報であるタグデータは、常に最新のものにしておく必要があるため、センサーマネジメントに直接アクセスして収集する必要がある。タグの内容はセンサーが常に最新の状態に書き換えている。ただし、そのタグが指し示すデータまで収集する必要はない。そのデータが必要かどうかは、まだわからないからである。ＩｏＴ検索システムでは、事前に、どのようなデータがどこにあるかを収集しておくだけで良い。

タグ（Ｔａｇ）は、直接センサーから収集可能であるが、そのタグに関連したデータは、センサーマネジメント経由でのみ収集可能である。これにより、不要なクローリングに対する応答に伴うセンサー側の負担を軽減することができる。また、ＩｏＴ検索システムとしては、センサーにより更新された新しいタグを、直接センサーにアクセスして取得できるので、ＩｏＴ検索システムにとって必要なデータが何処にあるかを最新に近い形で保持することができる。ここで、直接センサーへアクセスという意味は、センサーマネジメントを経由して取得することを完全に排除するものではなく、また、ＩｏＴ検索システムがセンサーマネジメントからセンサーのＩＰ ａｄｄｒｅｓｓやＵＲＬを教えてもらうことを排除するものではない。

７．第５の実施形態
第５の実施形態では、センサーを管理するセンサーマネジメント（Ｓｅｎｓｏｒ ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｙ）のｃａｐａｂｉｌｉｔｙ／ｄｅｖｉｃｅ ｃｌａｓｓをＩｏＴ検索システムに通知する。

第１〜第４の実施形態において、センサーを管理するセンサーマネジメントが重要な役割を果たしてきた。このセンサーマネジメントは、能力（ｃａｐａｂｉｌｉｔｙ）が異なるものがネットワーク内に配置されることがある。ＩｏＴ検索システムは、これらの能力を知らずにセンサーマネジメントにアクセスしても、有効な情報をセンサーマネジメントから得ることはできない。

表７は、センサーマネジメントの能力の例を示している。各ＩｏＴシステムは、事前にセンサーマネジメントに能力についての情報要求（ｃａｐａｂｉｌｉｔｙ ｉｎｆｏｒｍａｔｉｏｎ ｒｅｑｕｅｓｔ）を送り、表７の情報を取得する。センサーマネジメントは、能力を通知する代わりに、デバイスクラス（ｄｅｖｉｃｅ ｃｌａｓｓ）を通知しても良い。例えば、ｃａｐａｂｉｌｉｔｙの番号１から５の全てが有効なものは、ｄｅｖｉｃｅ ｃｌａｓｓ １であり、番号１から５の４つが有効なものをｄｅｖｉｃｅ ｃｌａｓｓ ２とし、それ以外をｄｅｖｉｃｅ ｃｌａｓｓ ３とする。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。

なお、以下のような構成も本開示の技術的範囲に属する。
（１） センサーから情報を収集する端末から、前記端末へアクセスが可能なタイミングに関するアクセスタイミング情報を受信する受信部と、
前記情報を検索するサーバへ前記アクセスタイミング情報を送信する送信部と、
を備える、端末管理装置。
（２） 前記アクセスタイミング情報は、前記端末のプラットフォームの相違に応じて異なるタイミングである、前記（１）に記載の端末管理装置。
（３） 前記アクセスタイミング情報は、前記プラットフォームと前記端末の優先度に応じて前記端末へアクセスが可能な前記タイミングの頻度が異なるように、下記の表により規定される、前記（２）に記載の端末管理装置。

（４） 前記アクセスタイミング情報は、前記プラットフォームと前記端末の優先度に応じて前記端末へアクセスが可能な前記タイミングの時間が異なるように、下記の表により規定される、前記（２）に記載の端末管理装置。

（５） 前記アクセスタイミング情報は、前記端末が前記アクセスを拒否するアクセス拒否時間に関する情報を含み、前記アクセス拒否時間は前記プラットフォームと前記端末の優先度に応じて下記の表により規定される、前記（２）に記載の端末管理装置。

（６） 前記サーバから前記端末を指定するＩＤを受信し、前記サーバが前記端末にアクセスするため、前記ＩＤに対応する前記端末の前記アクセスタイミング情報を前記サーバへ送信する、前記（１）に記載の端末管理装置。
（７） センサーから情報を取得するセンサー情報取得部と、
前記情報を取得しようとする他装置がアクセス可能なタイミングに関するアクセスタイミング情報を端末管理装置へ送信する送信部と、
を備える、端末装置。
（８） 前記アクセスタイミング情報は、プラットフォームの相違に応じて異なるタイミングである、前記（７）に記載の端末装置。
（９） 前記アクセスタイミング情報は、前記プラットフォームと優先度に応じて前記アクセス可能な前記タイミングの頻度が異なるように、下記の表により規定される、前記（８）に記載の端末装置。

（１０） 前記アクセスタイミング情報は、前記プラットフォームと優先度に応じて前記アクセス可能な前記タイミングの時間が異なるように、下記の表により規定される、前記（８）に記載の端末装置。

（１１） 前記アクセスタイミング情報は、前記他装置によるアクセスを拒否するアクセス拒否時間に関する情報を含み、前記アクセス拒否時間は前記プラットフォームと優先度に応じて下記の表により規定される、前記（８）に記載の端末装置。

（１２） センサーから情報を収集する端末へアクセスが可能なタイミングに関するアクセスタイミング情報を受信する受信部を備え、
前記アクセスタイミング情報に基づいて、前記端末の前記情報を検索する、サーバ。
（１３） センサーから情報を取得するセンサー情報取得部と、
前記センサーからデータを収集する際の計画に関する計画情報を端末管理装置へ送信する送信部と、
を備える、端末装置。
（１４） 前記計画情報は、前記情報を収集する頻度と、前記情報の収集の進捗を前記端末管理装置へアップロードするタイミングに応じて下記の表により規定される、前記（１３）に記載の端末装置。

（１５） センサーから情報を収集する端末から、前記端末が前記センサーから前記情報を収集する際の計画に関する計画情報を受信する受信部と、
前記計画情報と前記端末における前記情報の収集の進捗とに基づいて、前記端末におけるデータ収集状況を算出するデータ収集状況算出部と、
前記情報を検索するサーバへ前記データ収集状況を送信する送信部と、
を備える、端末管理装置。
（１６） 前記計画情報は、前記情報を収集する頻度と、前記情報の収集の進捗をアップロードするタイミングに応じて下記の表により規定される、請求項１５に記載の端末管理装置。

（１７） センサーから情報を取得するセンサー情報取得部と、
前記情報を検索する複数のサーバから得られる情報収集要求に含まれる優先度に基づいて端末管理装置が作成したスケジュールに従って、前記端末管理装置へ前記情報を送信する送信部と、
を備える、端末装置。
（１８） 検索機能を有する複数のサーバから、情報収集要求を受信する受信部と、
前記情報収集要求に含まれる優先度に基づいて、前記複数のサーバに情報を提供するためのスケジュールを作成するスケジュール作成部と、
前記スケジュールに基づいて、センサーから情報を収集する端末から前記情報を取得し、前記複数のサーバのそれぞれに送信する送信部と、
を備える、端末管理装置。
（１９） センサーから情報を取得するセンサー情報取得部と、
前記情報を検索する複数のサーバから得られる情報収集要求に含まれる優先度に基づいて端末管理装置が作成したスケジュールに従って、前記複数のサーバへ前記情報を送信する送信部と、
を備える、端末装置。
（２０） 検索機能を有する複数のサーバから、情報収集要求を受信する受信部と、
前記情報収集要求に含まれる優先度に基づいて、センサーから情報を収集する端末から前記複数のサーバが前記情報を取得するためのスケジュールを作成するスケジュール作成部と、
前記スケジュールを前記複数のサーバへ送信する送信部と、
を備える、端末管理装置。
（２１） センサーから情報を取得するセンサー情報取得部と、
前記情報を検索する複数のサーバから得られる情報収集要求を受信する端末管理装置が算出した前記情報収集要求に共通に含まれる情報を、前記端末管理装置へ送信する送信部と、
を備える、端末装置。
（２２） 検索機能を有する複数のサーバから、情報収集要求を受信する受信部と、
前記複数のサーバから受信した前記情報収集要求の共通部分を算出する共通部分算出部と、
センサーから情報を収集する端末から前記共通部分に関するデータを取得し、前記複数のサーバのそれぞれに送信する送信部と、
を備える、端末管理装置。
（２３） センサーから情報を取得するセンサー情報取得部と、
前記情報を識別するためのタグ情報を生成するタグ情報生成部と、
前記タグ情報を端末管理装置へ送信する送信部と、
を備える、端末装置。
（２４） センサーから情報を収集する端末から、前記情報を識別するためのタグ情報を取得するタグ情報取得部と、
前記情報を検索するサーバへ前記タグ情報を送信する送信部と、
を備える、端末管理装置。
（２５） センサーから情報を収集する端末における前記情報を識別するためのタグ情報を取得するタグ情報取得部と、
前記タグ情報に基づいて、前記端末の前記情報を検索する検索部と、
を備える、サーバ。
（２６） 検索機能を有するサーバから、センサーから情報を収集する端末に関する自装置の能力の情報要求を受信する受信部と、
前記情報要求に応じて、下記の表により規定される前記端末に関する能力を前記サーバへ送信する送信部と、
を備える、端末管理装置。

（２７） センサーから情報を収集する端末を管理する端末管理装置から、下記の表により規定される前記端末に関する前記端末管理装置の能力を受信する受信部と、
前記能力に応じて前記情報を検索する検索部と、
を備える、サーバ。

（２８） センサーから情報を収集する端末から、前記端末へアクセスが可能なタイミングに関するアクセスタイミング情報を受信することと、
前記情報を検索するサーバへ前記アクセスタイミング情報を送信することと、
を備える、端末管理装置における方法。
（２９） 前記アクセスタイミング情報は、前記端末のプラットフォームの相違に応じて異なるタイミングである、前記（２８）に記載の端末管理装置における方法。
（３０） 前記アクセスタイミング情報は、前記プラットフォームと前記端末の優先度に応じて前記端末へアクセスが可能な前記タイミングの頻度が異なるように、下記の表により規定される、前記（２９）に記載の端末管理装置における方法。

（３１） 前記アクセスタイミング情報は、前記プラットフォームと前記端末の優先度に応じて前記端末へアクセスが可能な前記タイミングの時間が異なるように、下記の表により規定される、前記（２９）に記載の端末管理装置における方法。

（３２） 前記アクセスタイミング情報は、前記端末が前記アクセスを拒否するアクセス拒否時間に関する情報を含み、前記アクセス拒否時間は前記プラットフォームと前記端末の優先度に応じて下記の表により規定される、前記（２９）に記載の端末管理装置における方法。

（３３） 前記サーバから前記端末を指定するＩＤを受信し、前記サーバが前記端末にアクセスするため、前記ＩＤに対応する前記端末の前記アクセスタイミング情報を前記サーバへ送信する、前記（２８）に記載の端末管理装置における方法。
（３４） センサーから情報を取得することと、
前記情報を取得しようとする他装置がアクセス可能なタイミングに関するアクセスタイミング情報を端末管理装置へ送信することと、
を備える、端末装置における方法。
（３５） 前記アクセスタイミング情報は、プラットフォームの相違に応じて異なるタイミングである、前記（３４）に記載の端末装置における方法。
（３６） 前記アクセスタイミング情報は、前記プラットフォームと優先度に応じて前記アクセス可能な前記タイミングの頻度が異なるように、下記の表により規定される、前記（３５）に記載の端末装置における方法。

（３７） 前記アクセスタイミング情報は、前記プラットフォームと優先度に応じて前記アクセス可能な前記タイミングの時間が異なるように、下記の表により規定される、前記（３５）に記載の端末装置における方法。

（３８） 前記アクセスタイミング情報は、前記他装置によるアクセスを拒否するアクセス拒否時間に関する情報を含み、前記アクセス拒否時間は前記プラットフォームと優先度に応じて下記の表により規定される、前記（３５）に記載の端末装置における方法。

（３９） センサーから情報を収集する端末へアクセスが可能なタイミングに関するアクセスタイミング情報を受信することと、
前記アクセスタイミング情報に基づいて、前記端末の前記情報を検索することと、
を備える、サーバにおける方法。
（４０） センサーから情報を取得することと、
前記センサーからデータを収集する際の計画に関する計画情報を端末管理装置へ送信することと、
を備える、端末装置における方法。
（４１） 前記計画情報は、前記情報を収集する頻度と、前記情報の収集の進捗を前記端末管理装置へアップロードするタイミングに応じて下記の表により規定される、前記（４０）に記載の端末装置における方法。

（４２） センサーから情報を収集する端末から、前記端末が前記センサーから前記情報を収集する際の計画に関する計画情報を受信することと、
前記計画情報と前記端末における前記情報の収集の進捗とに基づいて、前記端末におけるデータ収集状況を算出することと、
前記情報を検索するサーバへ前記データ収集状況を送信することと、
を備える、端末管理装置における方法。
（４３） 前記計画情報は、前記情報を収集する頻度と、前記情報の収集の進捗をアップロードするタイミングに応じて下記の表により規定される、請求項１５に記載の端末管理装置における方法。

（４４） センサーから情報を取得することと、
前記情報を検索する複数のサーバから得られる情報収集要求に含まれる優先度に基づいて端末管理装置が作成したスケジュールに従って、前記端末管理装置へ前記情報を送信することと、
を備える、端末装置における方法。
（４５） 検索機能を有する複数のサーバから、情報収集要求を受信することと、
前記情報収集要求に含まれる優先度に基づいて、前記複数のサーバに情報を提供するためのスケジュールを作成することと、
前記スケジュールに基づいて、センサーから情報を収集する端末から前記情報を取得し、前記複数のサーバのそれぞれに送信することと、
を備える、端末管理装置における方法。
（４６） センサーから情報を取得することと、
前記情報を検索する複数のサーバから得られる情報収集要求に含まれる優先度に基づいて端末管理装置が作成したスケジュールに従って、前記複数のサーバへ前記情報を送信することと、
を備える、端末装置における方法。
（４７） 検索機能を有する複数のサーバから、情報収集要求を受信することと、
前記情報収集要求に含まれる優先度に基づいて、センサーから情報を収集する端末から前記複数のサーバが前記情報を取得するためのスケジュールを作成することと、
前記スケジュールを前記複数のサーバへ送信することと、
を備える、端末管理装置における方法。
（４８） センサーから情報を取得することと、
前記情報を検索する複数のサーバから得られる情報収集要求を受信する端末管理装置が算出した前記情報収集要求に共通に含まれる情報を、前記端末管理装置へ送信することと、
を備える、端末装置における方法。
（４９） 検索機能を有する複数のサーバから、情報収集要求を受信することと、
前記複数のサーバから受信した前記情報収集要求の共通部分を算出することと、
センサーから情報を収集する端末から前記共通部分に関するデータを取得し、前記複数のサーバのそれぞれに送信することと、
を備える、端末管理装置における方法。
（５０） センサーから情報を取得することと、
前記情報を識別するためのタグ情報を生成することと、
前記タグ情報を端末管理装置へ送信することと、
を備える、端末装置における方法。
（５１） センサーから情報を収集する端末から、前記情報を識別するためのタグ情報を取得することと、
前記情報を検索するサーバへ前記タグ情報を送信することと、
を備える、端末管理装置における方法。
（５２） センサーから情報を収集する端末における前記情報を識別するためのタグ情報を取得することと、
前記タグ情報に基づいて、前記端末の前記情報を検索することと、
を備える、サーバにおける方法。
（５３） 検索機能を有するサーバから、センサーから情報を収集する端末に関する自装置の能力の情報要求を受信することと、
前記情報要求に応じて、下記の表により規定される前記端末に関する能力を前記サーバへ送信することと、
を備える、端末管理装置における方法。

（５４） センサーから情報を収集する端末を管理する端末管理装置から、下記の表により規定される前記端末に関する前記端末管理装置の能力を受信することと、
前記能力に応じて前記情報を検索することと、
を備える、サーバにおける方法。

１００ 端末装置
１０２ センサー
１０４ ストレージ
１０６ センサー情報取得部
１０８ タグ情報生成部
１１０ 送信部
２００ センサー管理装置
２０２ データ収集状況算出部
２０４ スケジュール作成部
２０６ 共通部分算出部
２０８ 送受信部
２１０ タグ情報取得部
３００ サーバ
３０２ 送受信部
３０４ 検索部
３０６ タグ情報取得部

Claims (20)

1. センサーから情報を収集する端末から、前記端末へアクセスが可能なタイミングに関するアクセスタイミング情報を受信する受信部と、
   前記情報を検索するサーバへ前記アクセスタイミング情報を送信する送信部と、
   を備える、端末管理装置。
2. 前記アクセスタイミング情報は、前記端末のプラットフォームの相違に応じて異なるタイミングである、請求項１に記載の端末管理装置。
3. 前記アクセスタイミング情報は、前記プラットフォームと前記端末の優先度に応じて前記端末へアクセスが可能な前記タイミングの頻度が異なるように、下記の表により規定される、請求項２に記載の端末管理装置。
   

   
4. 前記アクセスタイミング情報は、前記プラットフォームと前記端末の優先度に応じて前記端末へアクセスが可能な前記タイミングの時間が異なるように、下記の表により規定される、請求項２に記載の端末管理装置。
   

   
5. 前記アクセスタイミング情報は、前記端末が前記アクセスを拒否するアクセス拒否時間に関する情報を含み、前記アクセス拒否時間は前記プラットフォームと前記端末の優先度に応じて下記の表により規定される、請求項２に記載の端末管理装置。
   
   

   
6. 前記サーバから前記端末を指定するＩＤを受信し、前記サーバが前記端末にアクセスするため、前記ＩＤに対応する前記端末の前記アクセスタイミング情報を前記サーバへ送信する、請求項１に記載の端末管理装置。
7. センサーから情報を取得するセンサー情報取得部と、
   前記情報を取得しようとする他装置がアクセス可能なタイミングに関するアクセスタイミング情報を端末管理装置へ送信する送信部と、
   を備える、端末装置。
8. 前記アクセスタイミング情報は、プラットフォームと優先度に応じて前記アクセス可能な前記タイミングの頻度が異なるように、下記の表により規定される、請求項７に記載の端末装置。
   

   
9. センサーから情報を取得するセンサー情報取得部と、
   前記センサーからデータを収集する際の計画に関する計画情報を端末管理装置へ送信する送信部と、
   を備え、
   前記計画情報は、前記情報を収集する頻度と、前記情報の収集の進捗を前記端末管理装置へアップロードするタイミングに応じて下記の表により規定される、端末装置。
   

   
10. センサーから情報を収集する端末から、前記端末が前記センサーから前記情報を収集する際の計画に関する計画情報を受信する受信部と、
    前記計画情報と前記端末における前記情報の収集の進捗とに基づいて、前記端末におけるデータ収集状況を算出するデータ収集状況算出部と、
    前記情報を検索するサーバへ前記データ収集状況を送信する送信部と、
    を備える、端末管理装置。
11. 前記計画情報は、前記情報を収集する頻度と、前記情報の収集の進捗をアップロードするタイミングに応じて下記の表により規定される、請求項１０に記載の端末管理装置。
    

    
12. センサーから情報を取得するセンサー情報取得部と、
    前記情報を検索する複数のサーバから得られる情報収集要求に含まれる優先度に基づいて端末管理装置が作成したスケジュールに従って、前記端末管理装置へ前記情報を送信する送信部と、
    を備える、端末装置。
13. 検索機能を有する複数のサーバから、情報収集要求を受信する受信部と、
    前記情報収集要求に含まれる優先度に基づいて、前記複数のサーバに情報を提供するためのスケジュールを作成するスケジュール作成部と、
    前記スケジュールに基づいて、センサーから情報を収集する端末から前記情報を取得し、前記複数のサーバのそれぞれに送信する送信部と、
    を備える、端末管理装置。
14. センサーから情報を取得するセンサー情報取得部と、
    前記情報を検索する複数のサーバから得られる情報収集要求に含まれる優先度に基づいて端末管理装置が作成したスケジュールに従って、前記複数のサーバへ前記情報を送信する送信部と、
    を備える、端末装置。
15. 検索機能を有する複数のサーバから、情報収集要求を受信する受信部と、
    前記情報収集要求に含まれる優先度に基づいて、センサーから情報を収集する端末から前記複数のサーバが前記情報を取得するためのスケジュールを作成するスケジュール作成部と、
    前記スケジュールを前記複数のサーバへ送信する送信部と、
    を備える、端末管理装置。
16. センサーから情報を取得するセンサー情報取得部と、
    前記情報を検索する複数のサーバから得られる情報収集要求を受信する端末管理装置が算出した前記情報収集要求に共通に含まれる情報を、前記端末管理装置へ送信する送信部と、
    を備える、端末装置。
17. 検索機能を有する複数のサーバから、情報収集要求を受信する受信部と、
    前記複数のサーバから受信した前記情報収集要求の共通部分を算出する共通部分算出部と、
    センサーから情報を収集する端末から前記共通部分に関するデータを取得し、前記複数のサーバのそれぞれに送信する送信部と、
    を備える、端末管理装置。
18. センサーから情報を取得するセンサー情報取得部と、
    前記情報を識別するためのタグ情報を生成するタグ情報生成部と、
    前記タグ情報を端末管理装置へ送信する送信部と、
    を備える、端末装置。
19. センサーから情報を収集する端末から、前記情報を識別するためのタグ情報を取得するタグ情報取得部と、
    前記情報を検索するサーバへ前記タグ情報を送信する送信部と、
    を備える、端末管理装置。
20. 検索機能を有するサーバから、センサーから情報を収集する端末に関する自装置の能力の情報要求を受信する受信部と、
    前記情報要求に応じて、下記の表により規定される前記端末に関する能力を前記サーバへ送信する送信部と、
    を備える、端末管理装置。
    

    

Images