JP2018022239A - ライブデータ検索システムおよびライブデータ検索方法 - Google Patents
ライブデータ検索システムおよびライブデータ検索方法 Download PDFInfo
- Publication number
- JP2018022239A JP2018022239A JP2016151451A JP2016151451A JP2018022239A JP 2018022239 A JP2018022239 A JP 2018022239A JP 2016151451 A JP2016151451 A JP 2016151451A JP 2016151451 A JP2016151451 A JP 2016151451A JP 2018022239 A JP2018022239 A JP 2018022239A
- Authority
- JP
- Japan
- Prior art keywords
- resource
- live data
- search
- data buffer
- search request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】オープンなＩｏＴを活用したサービスにおいて、ライブデータに基づくリソースの発見（検索）を可能とする。【解決手段】ライブデータ検索システム１のリソースリゾルバ１０は、ユーザ端末４からリソース種別を含む検索条件を指定したリソース検索要求を受け付け、ライブデータをリソース毎に格納するリソースキューをライブデータバッファに備える各ライブデータバッファ装置２０に送信する。ライブデータバッファ装置２０は、リソース種別が適合するリソースのリソースキューに格納されたライブデータを検索し、検索条件に合致するライブデータが検出された場合に、そのライブデータを送信してきたリソースのアドレス情報を、リソースリゾルバ１０に送信する。【選択図】図１
Description
本発明は、ＩｏＴ（Internet of Things）デバイスを通じてデータを収集し、サービスを提供する際において、ライブデータを用いてＩｏＴデバイスを適切に検索する、ライブデータ検索システムおよびライブデータ検索方法に関する。
コンピュータなどの情報・通信機器だけでなく、世の中に存在する様々な物体（モノ）に通信機能を持たせ、インターネットに接続することにより制御を行う技術としてＩｏＴが普及しようとしている。
将来的には、このＩｏＴが普及することにより、各デバイスを提供するベンダの違いや、デバイス間をつなげるネットワークの種類、利用するクラウドのサービスプロバイダの違い等によらず、あらゆるものにいつでもどこからでも接続可能となるオープンなＩｏＴ環境が実現し、ネットワークにつながるリソースの数は莫大になると予想されている。
将来的には、このＩｏＴが普及することにより、各デバイスを提供するベンダの違いや、デバイス間をつなげるネットワークの種類、利用するクラウドのサービスプロバイダの違い等によらず、あらゆるものにいつでもどこからでも接続可能となるオープンなＩｏＴ環境が実現し、ネットワークにつながるリソースの数は莫大になると予想されている。
しかしながら、現状のＩｏＴは、例えば、個別企業内（自社工場内）や個別産業や個別企業のサービス内のみにおいて、デバイスからの情報を取得する垂直統合型（以下、「サイロ型」とも称する。）でのＩｏＴにとどまっている。ＩｏＴを利用したサービス（サービスアプリケーション）によりＩｏＴデバイス（以下、「リソース」と称する場合がある。）を活用しようとする場合において、各ネットワークに接続されたＩｏＴデバイスは、そのネットワーク内のドメイン内で管理されるリソースであり、ＩｏＴプラットフォーム毎のメタデータにより管理される。
現状では、各ＩｏＴデバイス（リソース）におけるアクセスＩＦ（Interface）、プロトコル、データ形式は多様であり、それらを相互接続できるように標準化する取り組みが、各標準化団体等で行われている（例えば、非特許文献１参照）。
Standards for M2M and the Internet of Things, ［online］，ＯｎｅＭ２Ｍ，［平成28年7月28日検索］，インターネット<ＵＲＬ:http://www.onem2m.org/>
サイロ型のＩｏＴからオープンなＩｏＴに移行するにつれて、実世界に存在するＩｏＴデバイス、例えば、デジタルカメラや、スマートフォン、ウェアラブル端末（ウォッチ）といった移動性を伴うものや、家庭内のリビングのＴＶや冷蔵庫といった固定的な（移動性を伴わない）家電製品、交差点の信号や監視カメラといった公共的な設備までを含め、多種多様なモノが、サービス（サービスアプリケーション）の対象として利用可能となる。
このような実世界の様々なモノを利用するために、サービス（サービスアプリケーション）は、人やモノなどの移動性をもつ対象物に対して、その対象物を検出できる、つまり対象物の周囲に存在するリソース（ＩｏＴデバイスとしてのセンサ）を発見し、そのリソースから情報を取得する必要がある。
この場合、従来のＷｅｂにおけるアドレス解決のような、ドメイン名による解決ではなく、Ｗｅｂの検索エンジンのように、コンテンツに対して検索を行い、対象物を検出するリソースのアドレス解決を行う必要がある。例えば、高齢者の見守りサービスのように、刻々と変化する高齢者の位置情報を高齢者が携帯するスマートフォンから取得したり、公園に設置されたビデオカメラから画像情報を取得したり等の、ダイナミックな（動的な）ライブデータを踏まえたリソースの検索（アドレス解決）が必要となる。現在のＷｅｂ検索においては、Ｗｅｂコンテンツの更新の頻度はライブデータの更新頻度と比べて桁違いに少ないため、クローリングによる情報の収集とインデックスの作成とをデータセンタに集約して行なっている。しかしながら、時々刻々変化するライブデータを収集するリソースを、サービスで利用するために発見（検出）する際には、Ｗｅｂ検索において用いられるクローリングによる手法では更新頻度が多く対応できない。
この場合、従来のＷｅｂにおけるアドレス解決のような、ドメイン名による解決ではなく、Ｗｅｂの検索エンジンのように、コンテンツに対して検索を行い、対象物を検出するリソースのアドレス解決を行う必要がある。例えば、高齢者の見守りサービスのように、刻々と変化する高齢者の位置情報を高齢者が携帯するスマートフォンから取得したり、公園に設置されたビデオカメラから画像情報を取得したり等の、ダイナミックな（動的な）ライブデータを踏まえたリソースの検索（アドレス解決）が必要となる。現在のＷｅｂ検索においては、Ｗｅｂコンテンツの更新の頻度はライブデータの更新頻度と比べて桁違いに少ないため、クローリングによる情報の収集とインデックスの作成とをデータセンタに集約して行なっている。しかしながら、時々刻々変化するライブデータを収集するリソースを、サービスで利用するために発見（検出）する際には、Ｗｅｂ検索において用いられるクローリングによる手法では更新頻度が多く対応できない。
また、既存のＩｏＴ標準化の取り組みでのリソースの発見（検索）は、各ネットワークに接続されるリソースがもつスタティックな（静的な）メタデータをデータベースとして集約する手法（例えば、非特許文献２（ＣｏＲＥ），非特許文献３（Ｈｙｐｅｒｃａｔ）参照）や、ブロードキャスト型でメタデータを交換する手法により行われている（例えば、非特許文献４，５）。つまり、既存の取り組みは静的なメタデータに基づくリソースの発見（検索）にとどまっており、動的なライブデータを含めたリソースの検索まで、できるものではない。
ここで、非特許文献２は、「Z. Shelby, “Constrained RESTful Environments (CoRE) Link Format”, RFC6690, August 2012.」である。
非特許文献３は、「Hypercat Limited, “Hypercat 3.00 Specification”, Available: http://www.hypercat.io/, February 2016.」である。
非特許文献４は、「Allseen alliance [online]. Available: https://allseenalliance.org/」である。
非特許文献５は、「S. Cheshire, and M. Krochmal, “Multicast DNS”, RFC6762,」である。
ここで、非特許文献２は、「Z. Shelby, “Constrained RESTful Environments (CoRE) Link Format”, RFC6690, August 2012.」である。
非特許文献３は、「Hypercat Limited, “Hypercat 3.00 Specification”, Available: http://www.hypercat.io/, February 2016.」である。
非特許文献４は、「Allseen alliance [online]. Available: https://allseenalliance.org/」である。
非特許文献５は、「S. Cheshire, and M. Krochmal, “Multicast DNS”, RFC6762,」である。
また、approximate computing（近似計算）の概念を用いて、ライブデータそのものを検出する代わりに、一定の条件の範囲であれば、そのリソース（センサ）が取り得る結果を予測する技術が提案されている（非特許文献６）。しかしながら、この技術では、実際のライブデータの値を用いることができず、また、比較的単純に予測可能な結果値を導出できるデータにしか適用できないという課題がある。
ここで、非特許文献６は、「B. Ostermaier, K. Roemer, F. Mattern, M. Fahrmair, W. Kellerer, A real-time search engine for the web of things, in: Proc. of Internet of Things 2010 Conference, November 2010.」である。
ここで、非特許文献６は、「B. Ostermaier, K. Roemer, F. Mattern, M. Fahrmair, W. Kellerer, A real-time search engine for the web of things, in: Proc. of Internet of Things 2010 Conference, November 2010.」である。
つまり、オープンなＩｏＴにおいて、ライブデータを収集するリソースを利用する場合に、そのリソースを発見（検索）するためのアドレス解決が困難であるという課題があった。
このような背景を鑑みて本発明がなされたのであり、本発明は、オープンなＩｏＴを活用したサービスにおいて、ライブデータに基づくリソースの発見（検索）を可能とする、ライブデータ検索システムおよびライブデータ検索方法を提供することを課題とする。
このような背景を鑑みて本発明がなされたのであり、本発明は、オープンなＩｏＴを活用したサービスにおいて、ライブデータに基づくリソースの発見（検索）を可能とする、ライブデータ検索システムおよびライブデータ検索方法を提供することを課題とする。
前記した課題を解決するため、請求項１に記載の発明は、ユーザ端末からライブデータを送信するリソースの検索要求を受け付けるリソースリゾルバと、複数の前記リソースのリソース種別を含むメタデータをメタデータＤＢとして格納するメタデータ収集装置と、複数の前記リソースそれぞれから前記ライブデータを収集する複数のライブデータバッファ装置と、がネットワークを介して接続されるライブデータ検索システムであって、前記リソースリゾルバが、前記ライブデータバッファ装置のライブデータバッファ装置ＩＤに対応付けて、当該ライブデータバッファ装置に接続される前記リソースのリソースＩＤが格納されるライブデータバッファ装置ＤＢを記憶する記憶部と、前記リソース種別を含む検索条件を指定したリソース検索要求を受け付けるリソース検索受付部と、前記リソース検索要求で示される前記リソース種別と合致する前記リソースのリソースＩＤを、前記メタデータ収集装置に対して前記メタデータＤＢの検索を要求することにより取得するメタデータ検索要求部と、前記取得したリソースＩＤを用いて、前記ライブデータバッファ装置ＤＢを参照し、取得したリソースＩＤで示されるリソースに接続するライブデータバッファ装置を特定し、前記特定したライブデータバッファ装置それぞれに前記リソース検索要求を通知するライブデータ検索通知部と、前記特定したライブデータバッファ装置それぞれから、前記リソース検索要求に付された前記検索条件に合致するリソースのアドレス情報を取得し、リソース一覧として前記ユーザ端末に送信するリソース一覧回答部と、を備え、前記ライブデータバッファ装置が、自身のライブデータバッファ装置に接続する前記リソースのリソース種別とアドレス情報とが格納されるリソースＤＢ、および、前記ライブデータを前記リソース毎のリソースキューに格納するライブデータバッファ、を記憶する記憶部と、前記リソースそれぞれから前記ライブデータを収集し、前記リソース毎のリソースキューに格納するライブデータ収集部と、前記リソース検索要求を受信し、前記リソース検索要求に付されたリソース種別に適合するリソースの前記リソースキューについて、前記検索条件に合致するライブデータがあるか否かを検索するリソース検索部と、前記リソース検索要求の検索条件に合致するライブデータが検出された場合に、当該ライブデータを送信してきたリソースのアドレス情報を、前記リソースＤＢを参照して取得し、前記リソースリゾルバに送信するアドレス情報送信部と、を備えることを特徴とするライブデータ検索システムとした。
また、請求項４に記載の発明は、ユーザ端末からライブデータを送信するリソースの検索要求を受け付けるリソースリゾルバと、複数の前記リソースのリソース種別を含むメタデータをメタデータＤＢとして格納するメタデータ収集装置と、複数の前記リソースそれぞれから前記ライブデータを収集する複数のライブデータバッファ装置と、がネットワークを介して接続されるライブデータ検索システムのライブデータ検索方法であって、前記リソースリゾルバが、前記ライブデータバッファ装置のライブデータバッファ装置ＩＤに対応付けて、当該ライブデータバッファ装置に接続される前記リソースのリソースＩＤが格納されるライブデータバッファ装置ＤＢを記憶する記憶部を備えており、前記リソース種別を含む検索条件を指定したリソース検索要求を受け付けるステップと、前記リソース検索要求で示される前記リソース種別と合致する前記リソースのリソースＩＤを、前記メタデータ収集装置に対して前記メタデータＤＢの検索を要求することにより取得するステップと、前記取得したリソースＩＤを用いて、前記ライブデータバッファ装置ＤＢを参照し、取得したリソースＩＤで示されるリソースに接続するライブデータバッファ装置を特定し、前記特定したライブデータバッファ装置それぞれに前記リソース検索要求を通知するステップと、前記特定したライブデータバッファ装置それぞれから、前記リソース検索要求に付された前記検索条件に合致するリソースのアドレス情報を取得し、リソース一覧として前記ユーザ端末に送信するステップと、を実行し、前記ライブデータバッファ装置が、自身のライブデータバッファ装置に接続する前記リソースのリソース種別とアドレス情報とが格納されるリソースＤＢ、および、前記ライブデータを前記リソース毎のリソースキューに格納するライブデータバッファ、を記憶する記憶部を備えており、前記リソースそれぞれから前記ライブデータを収集し、前記リソース毎のリソースキューに格納するステップと、前記リソース検索要求を受信し、前記リソース検索要求に付されたリソース種別に適合するリソースの前記リソースキューについて、前記検索条件に合致するライブデータがあるか否かを検索するステップと、前記リソース検索要求の検索条件に合致するライブデータが検出された場合に、当該ライブデータを送信してきたリソースのアドレス情報を、前記リソースＤＢを参照して取得し、前記リソースリゾルバに送信するステップと、を実行することを特徴とするライブデータ検索方法とした。
このようにすることで、ライブデータ検索システムは、複数のライブデータバッファ装置それぞれが各リソースからライブデータを収集し、ライブデータバッファ内のリソース毎のリソースキューに格納しておくことができる。そして、ライブデータバッファ装置は、ユーザ端末からリソースリゾルバを介して、リソース種別を含む検索条件が指定されたリソース検索要求を受信すると、そのリソース種別に適合するリソースのリソースキューについて、検索条件に合致するライブデータがあるか否かを探索する。ライブデータバッファ装置は、検索条件に合致するライブデータが検索された場合に、そのライブデータを送信してきたリソースのアドレス情報をリソースリゾルバに送信する。そして、リソースリゾルバがそのアドレス情報をユーザ端末に送信する。
これにより、非常に多くのリソースの中から、サービスに必要となるライブデータをもつリソースについてのアドレス情報を取得し、ユーザ端末がそのリソースに接続することが可能となる。つまり、ライブデータに基づきリソースを発見（検索）することが可能となる。
また、リソースリゾルバは、リソース検索要求に付されたリソース種別と合致するリソースに接続されるライブデータバッファ装置だけに、リソース検索要求を送信するため、システム全体としての処理負荷を低減させることができる。
これにより、非常に多くのリソースの中から、サービスに必要となるライブデータをもつリソースについてのアドレス情報を取得し、ユーザ端末がそのリソースに接続することが可能となる。つまり、ライブデータに基づきリソースを発見（検索）することが可能となる。
また、リソースリゾルバは、リソース検索要求に付されたリソース種別と合致するリソースに接続されるライブデータバッファ装置だけに、リソース検索要求を送信するため、システム全体としての処理負荷を低減させることができる。
請求項２に記載の発明は、前記ライブデータバッファ装置のリソース検索部が、所定の検索条件に合致するか否かを、前記ライブデータが前記リソースキューに格納される際に検索するフィルタ処理を実行することを特徴とする請求項１に記載のライブデータ検索システムとした。
このようにすることで、ライブデータバッファ装置は、ライブデータがリソースキューに格納されるときに、所定の（例えば、検索頻度が高い）検索条件に合致するか否かを判定することができる。よって、より短時間（リアルタイム）に、検索条件に合致したライブデータを送信するリソースを発見することが可能となる。
請求項３に記載の発明は、ユーザ端末からライブデータを送信するリソースの検索要求を受け付けるリソースリゾルバと、複数の前記リソースそれぞれから前記ライブデータを収集する複数のライブデータバッファ装置と、がネットワークを介して接続されるライブデータ検索システムであって、前記リソースリゾルバが、前記リソースのリソース種別を含む検索条件を指定したリソース検索要求を受け付けるリソース検索受付部と、複数の前記ライブデータバッファ装置それぞれに、前記リソース検索要求を通知するライブデータ検索通知部と、複数の前記ライブデータバッファ装置それぞれから、前記リソース検索要求に付された前記検索条件に合致するリソースのアドレス情報を取得し、リソース一覧として前記ユーザ端末に送信するリソース一覧回答部と、を備え、前記ライブデータバッファ装置が、自身のライブデータバッファ装置に接続する前記リソースのリソース種別とアドレス情報とが格納されるリソースＤＢ、および、前記ライブデータを前記リソース毎のリソースキューに格納するライブデータバッファ、を記憶する記憶部と、前記リソースそれぞれから前記ライブデータを収集し、前記リソース毎のリソースキューに格納するライブデータ収集部と、前記リソース検索要求を受信し、前記リソース検索要求に付されたリソース種別に適合するリソースの前記リソースキューについて、前記検索条件に合致するライブデータがあるか否かを検索するリソース検索部と、前記リソース検索要求の検索条件に合致するライブデータが検出された場合に、当該ライブデータを送信してきたリソースのアドレス情報を、前記リソースＤＢを参照して取得し、前記リソースリゾルバに送信するアドレス情報送信部と、を備えることを特徴とするライブデータ検索システムとした。
請求項５に記載の発明は、ユーザ端末からライブデータを送信するリソースの検索要求を受け付けるリソースリゾルバと、複数の前記リソースそれぞれから前記ライブデータを収集する複数のライブデータバッファ装置と、がネットワークを介して接続されるライブデータ検索システムのライブデータ検索方法であって、前記リソースリゾルバが、前記リソースのリソース種別を含む検索条件を指定したリソース検索要求を受け付けるステップと、複数の前記ライブデータバッファ装置それぞれに、前記リソース検索要求を通知するステップと、 複数の前記ライブデータバッファ装置それぞれから、前記リソース検索要求に付された前記検索条件に合致するリソースのアドレス情報を取得し、リソース一覧として前記ユーザ端末に送信するステップと、を実行し、前記ライブデータバッファ装置が、自身のライブデータバッファ装置に接続する前記リソースのリソース種別とアドレス情報とが格納されるリソースＤＢ、および、前記ライブデータを前記リソース毎のリソースキューに格納するライブデータバッファ、を記憶する記憶部を備えており、前記リソースそれぞれから前記ライブデータを収集し、前記リソース毎のリソースキューに格納するステップと、前記リソース検索要求を受信し、前記リソース検索要求に付されたリソース種別に適合するリソースの前記リソースキューについて、前記検索条件に合致するライブデータがあるか否かを検索するステップと、前記リソース検索要求の検索条件に合致するライブデータが検出された場合に、当該ライブデータを送信してきたリソースのアドレス情報を、前記リソースＤＢを参照して取得し、前記リソースリゾルバに送信するステップと、を実行することを特徴とするライブデータ検索方法とした。
このようにすることで、ライブデータ検索システムは、複数のライブデータバッファ装置それぞれが各リソースからライブデータを収集し、ライブデータバッファ内のリソース毎のリソースキューに格納しておくことができる。そして、ライブデータバッファ装置は、ユーザ端末からリソースリゾルバを介して、リソース種別を含む検索条件が指定されたリソース検索要求を受信すると、そのリソース種別に適合するリソースのリソースキューについて、検索条件に合致するライブデータがあるか否かを探索する。ライブデータバッファ装置は、検索条件に合致するライブデータが検索された場合に、そのライブデータを送信してきたリソースのアドレス情報をリソースリゾルバに送信する。そして、リソースリゾルバがそのアドレス情報をユーザ端末に送信する。
これにより、非常に多くのリソースの中から、サービスに必要となるライブデータをもつリソースについてのアドレス情報を取得し、ユーザ端末がそのリソースに接続することが可能となる。つまり、ライブデータに基づきリソースを発見（検索）することが可能となる。
また、リソースリゾルバは、ネットワーク内に配置されたライブデータバッファ装置それぞれにリソース検索要求を送信するため、システム内において各リソースのメタデータを集約して記憶する必要をなくすことができる。
これにより、非常に多くのリソースの中から、サービスに必要となるライブデータをもつリソースについてのアドレス情報を取得し、ユーザ端末がそのリソースに接続することが可能となる。つまり、ライブデータに基づきリソースを発見（検索）することが可能となる。
また、リソースリゾルバは、ネットワーク内に配置されたライブデータバッファ装置それぞれにリソース検索要求を送信するため、システム内において各リソースのメタデータを集約して記憶する必要をなくすことができる。
本発明によれば、オープンなＩｏＴを活用したサービスにおいて、ライブデータに基づくリソースの発見（検索）を可能とする、ライブデータ検索システムおよびライブデータ検索方法を提供することができる。
次に、本発明を実施するための形態（以下、「実施形態」という。）におけるライブデータ検索システム１等について説明する。
図１は、本実施形態に係るライブデータ検索システム１の全体構成を示す図である。
本実施形態に係るライブデータ検索システム１は、ネットワーク上に、動的に変化するライブデータを収集するライブデータバッファ装置２０を分散配置する。そのライブデータバッファ装置２０が、同一ネットワークセグメント内のリソース５（ＩｏＴデバイス）からの情報（ライブデータ）を収集しライブデータバッファ２００に記憶しておき、リソースリゾルバ１０を介して、ユーザ端末４からのリソース検索要求を受け付ける。そして、ライブデータバッファ装置２０がリソース検索要求に付された検索条件に合致するライブデータを有するリソース５を検出した場合に、そのリソース５のアドレス情報をリソースリゾルバ１０がユーザ端末４に返答することを特徴とする。
本実施形態に係るライブデータ検索システム１は、ネットワーク上に、動的に変化するライブデータを収集するライブデータバッファ装置２０を分散配置する。そのライブデータバッファ装置２０が、同一ネットワークセグメント内のリソース５（ＩｏＴデバイス）からの情報（ライブデータ）を収集しライブデータバッファ２００に記憶しておき、リソースリゾルバ１０を介して、ユーザ端末４からのリソース検索要求を受け付ける。そして、ライブデータバッファ装置２０がリソース検索要求に付された検索条件に合致するライブデータを有するリソース５を検出した場合に、そのリソース５のアドレス情報をリソースリゾルバ１０がユーザ端末４に返答することを特徴とする。
＜ライブデータ検索システムの構成＞
図１に示すように、ライブデータ検索システム１は、ユーザ端末４に接続されるリソースリゾルバ１０と、そのリソースリゾルバ１０に接続されるメタデータ収集装置３０と、各リソース５に接続されライブデータを収集する複数のライブデータバッファ装置２０とを含んで構成される。
図１に示すように、ライブデータ検索システム１は、ユーザ端末４に接続されるリソースリゾルバ１０と、そのリソースリゾルバ１０に接続されるメタデータ収集装置３０と、各リソース５に接続されライブデータを収集する複数のライブデータバッファ装置２０とを含んで構成される。
このライブデータバッファ装置２０は、自身と接続されるリソース５からライブデータを収集し、ライブデータバッファ２００に所定の時間格納しておく。図１では、例えばライブデータバッファ装置２０（２０Ａ）が、リソース５（５Ａ）である監視カメラから画像情報をライブデータとして収集し、リソース５（５Ｂ）であるスマートフォンから、ライブデータとして位置情報をライブデータとして収集する。また、ライブデータバッファ装置２０（２０Ｂ）が、リソース５（５Ｃ）である監視カメラから画像情報をライブデータとして収集し、リソース５（５Ｄ）である冷蔵庫からドアの開閉情報をライブデータとして収集し、リソース５（５Ｅ）である温度センサから温度情報をライブデータとして収集する。
リソースリゾルバ１０は、ユーザ端末４からリソース種別等を含む検索条件を指定したリソース検索要求を受け付けると、メタデータ収集装置３０が備えるメタデータＤＢ（DataBase）３３０を検索し、該当するリソース種別のリソース５を抽出する。そして、リソースリゾルバ１０は、複数のライブデータバッファ装置２０のうち、該当するリソース種別のリソース５に接続するライブデータバッファ装置２０を選択して、リソース検索要求を送信する。
リソース検索要求を受信したライブデータバッファ装置２０（後記する、リソース検索部２１３）は、リソース種別に適合するリソース５のライブデータを検索し、検索条件に該当するライブデータが検出された場合に、そのライブデータを送信したリソース５のアドレス情報を、リソースリゾルバ１０に返信する。
リソースリゾルバ１０は、各ライブデータバッファ装置２０から受信したアドレス情報を統合してリソース一覧を生成し、ユーザ端末４に返信する。これにより、ユーザ端末４は、アドレス情報で示されるリソース５に接続し、サービスの提供を受けることができる。
リソースリゾルバ１０は、各ライブデータバッファ装置２０から受信したアドレス情報を統合してリソース一覧を生成し、ユーザ端末４に返信する。これにより、ユーザ端末４は、アドレス情報で示されるリソース５に接続し、サービスの提供を受けることができる。
このようにすることにより、本実施形態に係るライブデータ検索システム１およびライブデータ検索方法によれば、ネットワーク上にライブデータを収集するライブデータバッファ装置２０を分散配置することで、動的に変動する情報であるライブデータを収集し、そのライブデータに対する検索を行うことで、検索条件に合致したリソース５のアドレス情報をユーザ端末４に提供することができる。分散配置することにより、ライブデータの収集を１拠点に集約せずに分散することができ、ネットワークトラヒックの分散が図れ、また１拠点でのデータ検索の対象とするデータ量を限定することができ、検索を高速に行うことが可能となる。これにより、ユーザ端末４に設定されたサービスアプリケーションを用いて、非常に多くの同種のリソースの中から、真に必要なリソース５についてのアドレス情報を取得し、そのリソース５に対して接続することが可能となる。
以下、ライブデータ検索システム１を構成する各装置について詳細に説明する。
以下、ライブデータ検索システム１を構成する各装置について詳細に説明する。
≪リソースリゾルバ≫
まず、リソースリゾルバ１０について詳細に説明する。
図２は、本実施形態に係るリソースリゾルバ１０の構成例を示す機能ブロック図である。
リソースリゾルバ１０は、ユーザ端末４からリソース種別を含む検索条件を指定したリソース検索要求を受け付ける。リソースリゾルバ１０は、複数のライブデータバッファ装置２０のうち、受け付けたリソース検索要求を送信するライブデータバッファ装置２０を絞り込むために、まず、リソース検索要求に付されたリソース種別を用いて、メタデータ収集装置３０のメタデータＤＢ３３０（後記する、図４，図５参照）を検索する。そして、リソースリゾルバ１０は、リソース種別が一致するリソース５を抽出し、ライブデータバッファ装置ＤＢ１３０を参照して、抽出したリソース５と接続されるライブデータバッファ装置２０に対して、リソース検索要求を送信する。また、リソースリゾルバ１０は、ライブデータバッファ装置２０から、ライブデータの検索（詳細は後記）の結果として、検索条件に該当するライブデータを送信しているリソース５のアドレス情報を収集する。そして、リソースリゾルバ１０は、各ライブデータバッファ装置２０から収集したアドレス情報を集約してリソース一覧を生成し、ユーザ端末４に送信する。
このリソースリゾルバ１０は、制御部１１と、入出力部１２と、記憶部１３とを備える。
まず、リソースリゾルバ１０について詳細に説明する。
図２は、本実施形態に係るリソースリゾルバ１０の構成例を示す機能ブロック図である。
リソースリゾルバ１０は、ユーザ端末４からリソース種別を含む検索条件を指定したリソース検索要求を受け付ける。リソースリゾルバ１０は、複数のライブデータバッファ装置２０のうち、受け付けたリソース検索要求を送信するライブデータバッファ装置２０を絞り込むために、まず、リソース検索要求に付されたリソース種別を用いて、メタデータ収集装置３０のメタデータＤＢ３３０（後記する、図４，図５参照）を検索する。そして、リソースリゾルバ１０は、リソース種別が一致するリソース５を抽出し、ライブデータバッファ装置ＤＢ１３０を参照して、抽出したリソース５と接続されるライブデータバッファ装置２０に対して、リソース検索要求を送信する。また、リソースリゾルバ１０は、ライブデータバッファ装置２０から、ライブデータの検索（詳細は後記）の結果として、検索条件に該当するライブデータを送信しているリソース５のアドレス情報を収集する。そして、リソースリゾルバ１０は、各ライブデータバッファ装置２０から収集したアドレス情報を集約してリソース一覧を生成し、ユーザ端末４に送信する。
このリソースリゾルバ１０は、制御部１１と、入出力部１２と、記憶部１３とを備える。
入出力部１２は、ユーザ端末４やメタデータ収集装置３０、各ライブデータバッファ装置２０等との間の情報の入出力を行う。この入出力部１２は、通信回線を介して情報の送受信を行う通信インタフェースと、不図示のキーボード等の入力装置やモニタ等の出力装置との間で情報の入出力を行う入出力インタフェースとから構成される。
記憶部１３は、ハードディスクやフラッシュメモリ、ＲＡＭ（Random Access Memory）等により構成される。
この記憶部１３には、後記するライブデータバッファ装置ＤＢ１３０が記憶されるとともに、制御部１１の各機能を実行させるためのプログラムや、制御部１１の処理に必要な情報が一時的に記憶される。
この記憶部１３には、後記するライブデータバッファ装置ＤＢ１３０が記憶されるとともに、制御部１１の各機能を実行させるためのプログラムや、制御部１１の処理に必要な情報が一時的に記憶される。
制御部１１は、リソースリゾルバ１０が実行する処理の全般を司り、リソース検索受付部１１１と、メタデータ検索要求部１１２と、ライブデータ検索通知部１１３と、リソース一覧回答部１１４とを含んで構成される。なお、この制御部１１は、例えば、このリソースリゾルバ１０の記憶部１３に格納されたプログラムをＣＰＵ（Central Processing Unit）がＲＡＭに展開し実行することにより実現される。
リソース検索受付部１１１は、ユーザ端末４から、リソース種別を含む検索条件を指定したリソース検索要求を受け付ける。そして、リソース検索受付部１１１は、受け付けたリソース検索要求を、メタデータ検索要求部１１２に出力する。
メタデータ検索要求部１１２は、複数のライブデータバッファ装置２０のうち、リソース検索要求を送信するライブデータバッファ装置２０を絞り込むために、受け付けたリソース検索要求をメタデータ検索要求として、メタデータ収集装置３０に送信する。
そして、メタデータ検索要求部１１２は、メタデータ収集装置３０から、リソース検索要求（メタデータ検索要求）で示されるリソース種別が一致するリソース５のリソースＩＤ（Identification）の情報が付されたメタデータ検索応答を取得する。
そして、メタデータ検索要求部１１２は、メタデータ収集装置３０から、リソース検索要求（メタデータ検索要求）で示されるリソース種別が一致するリソース５のリソースＩＤ（Identification）の情報が付されたメタデータ検索応答を取得する。
ライブデータ検索通知部１１３は、メタデータ検索要求部１１２が取得したメタデータ検索応答で示されるリソースＩＤの情報を用いて、ライブデータバッファ装置ＤＢ１３０（図３）を検索し、取得したリソースＩＤで示されるリソース５に接続するライブデータバッファ装置２０を特定する。そして、ライブデータ検索通知部１１３は、その特定したライブデータバッファ装置２０に対して、リソース検索要求を通知する。
図３は、本実施形態に係るライブデータバッファ装置ＤＢ１３０のデータ構成例を示す図である。
図３に示すように、ライブデータバッファ装置ＤＢ１３０には、ライブデータバッファ装置ＩＤに対応付けて、収容リソースＩＤ、ＩＰ（Internet Protocol）アドレスの各項目が格納される。
図３に示すように、ライブデータバッファ装置ＤＢ１３０には、ライブデータバッファ装置ＩＤに対応付けて、収容リソースＩＤ、ＩＰ（Internet Protocol）アドレスの各項目が格納される。
ライブデータバッファ装置ＩＤは、ライブデータバッファ装置２０を一意に識別するための識別情報が格納される。
収容リソースＩＤには、そのライブデータバッファ装置２０に接続（収容）される、つまり、ライブデータの取得対象となる、１つ以上のリソース５それぞれのリソースＩＤが格納される。
ＩＰアドレスには、ライブデータバッファ装置ＩＤに対応するライブデータバッファ装置２０のネットワーク上の位置情報としてＩＰアドレスが格納される。
ライブデータ検索通知部１１３は、メタデータ検索要求部１１２が取得したリソースＩＤで示されるリソース５に接続するライブデータバッファ装置２０を、収容リソースＩＤに基づき特定し、そのＩＰアドレスを取得して、リソース検索要求を通知する。
収容リソースＩＤには、そのライブデータバッファ装置２０に接続（収容）される、つまり、ライブデータの取得対象となる、１つ以上のリソース５それぞれのリソースＩＤが格納される。
ＩＰアドレスには、ライブデータバッファ装置ＩＤに対応するライブデータバッファ装置２０のネットワーク上の位置情報としてＩＰアドレスが格納される。
ライブデータ検索通知部１１３は、メタデータ検索要求部１１２が取得したリソースＩＤで示されるリソース５に接続するライブデータバッファ装置２０を、収容リソースＩＤに基づき特定し、そのＩＰアドレスを取得して、リソース検索要求を通知する。
リソース一覧回答部１１４は、ライブデータバッファ装置２０から、ライブデータの検索の結果として、リソース検索要求に付された検索条件に該当するリソース５のアドレス情報を収集する。そして、リソース一覧回答部１１４は、各ライブデータバッファ装置２０から収集したアドレス情報を集約してリソース一覧を生成し、ユーザ端末４に送信する。
なお、リソース一覧回答部１１４は、後記するように、メタデータ収集装置３０から静的なメタデータに関する検索条件に合致するリソース５のアドレス情報を、メタデータ検索応答により受信している場合には、当該アドレス情報も含めて、リソース一覧を生成し、ユーザ端末４に送信する。
なお、リソース一覧回答部１１４は、後記するように、メタデータ収集装置３０から静的なメタデータに関する検索条件に合致するリソース５のアドレス情報を、メタデータ検索応答により受信している場合には、当該アドレス情報も含めて、リソース一覧を生成し、ユーザ端末４に送信する。
≪ユーザ端末≫
次に、図１に示すユーザ端末４について説明する。
ユーザ端末４は、例えば、パーソナルコンピュータや、スマートフォン、タブレット端末等により構成される。ユーザ端末４には、サービスアプリケーションが設定され、このサービスアプリケーションの機能により、リソースリゾルバ１０に対して、リソース種別等を含む検索条件を指定したリソース検索要求を送信する。また、ユーザ端末４は、リソースリゾルバ１０から、リソース一覧で示されるアドレス情報を取得し、そのアドレス情報を用いて１つ以上のリソース５にアクセスし、情報を取得する等のサービスの提供を受ける。
次に、図１に示すユーザ端末４について説明する。
ユーザ端末４は、例えば、パーソナルコンピュータや、スマートフォン、タブレット端末等により構成される。ユーザ端末４には、サービスアプリケーションが設定され、このサービスアプリケーションの機能により、リソースリゾルバ１０に対して、リソース種別等を含む検索条件を指定したリソース検索要求を送信する。また、ユーザ端末４は、リソースリゾルバ１０から、リソース一覧で示されるアドレス情報を取得し、そのアドレス情報を用いて１つ以上のリソース５にアクセスし、情報を取得する等のサービスの提供を受ける。
≪メタデータ収集装置≫
次に、メタデータ収集装置３０について詳細に説明する。
図４は、本実施形態に係るメタデータ収集装置３０の構成例を示す機能ブロック図である。
メタデータ収集装置３０は、ネットワークに接続される各リソース５の静的な情報であるメタデータを収集する。そして、メタデータ収集装置３０は、リソースリゾルバ１０から、リソース種別を含むメタデータ検索要求を受信すると、メタデータＤＢ３３０（図５）を参照して、メタデータ検索要求で示されるリソース種別が一致するリソース５のリソースＩＤの情報を抽出し、リソースリゾルバ１０に送信する。
このメタデータ収集装置３０は、制御部３１と、入出力部３２と、記憶部３３とを備える。
次に、メタデータ収集装置３０について詳細に説明する。
図４は、本実施形態に係るメタデータ収集装置３０の構成例を示す機能ブロック図である。
メタデータ収集装置３０は、ネットワークに接続される各リソース５の静的な情報であるメタデータを収集する。そして、メタデータ収集装置３０は、リソースリゾルバ１０から、リソース種別を含むメタデータ検索要求を受信すると、メタデータＤＢ３３０（図５）を参照して、メタデータ検索要求で示されるリソース種別が一致するリソース５のリソースＩＤの情報を抽出し、リソースリゾルバ１０に送信する。
このメタデータ収集装置３０は、制御部３１と、入出力部３２と、記憶部３３とを備える。
入出力部３２は、リソースリゾルバ１０や、各ライブデータバッファ装置２０等との間の情報の入出力を行う。この入出力部３２は、通信回線を介して情報の送受信を行う通信インタフェースと、不図示のキーボード等の入力装置やモニタ等の出力装置との間で情報の入出力を行う入出力インタフェースとから構成される。
記憶部３３は、ハードディスクやフラッシュメモリ、ＲＡＭ等により構成される。
この記憶部３３には、後記するメタデータＤＢ３３０（図５）が記憶されるとともに、制御部３１の各機能を実行させるためのプログラムや、制御部３１の処理に必要な情報が一時的に記憶される。
この記憶部３３には、後記するメタデータＤＢ３３０（図５）が記憶されるとともに、制御部３１の各機能を実行させるためのプログラムや、制御部３１の処理に必要な情報が一時的に記憶される。
制御部３１は、メタデータ収集装置３０が実行する処理の全般を司り、メタデータ集約部３１１と、メタデータ検索部３１２とを含んで構成される。なお、この制御部３１は、例えば、このメタデータ収集装置３０の記憶部３３に格納されたプログラムをＣＰＵがＲＡＭに展開し実行することにより実現される。
メタデータ集約部３１１は、静的なメタデータの情報を、前記したＣｏＲＥ（非特許文献２）やＨｙｐｅｒｃａｔ（非特許文献３）等に基づき、各ドメインやネットワークに存在するリソース５から集約することができる。また、メタデータ集約部３１１は、各ライブデータバッファ装置２０等からもメタデータの情報を取得し、メタデータＤＢ３３０（後記する図５参照）に格納する。
図５は、本実施形態に係るメタデータＤＢ３３０のデータ構成例を示す図である。
図５に示すように、メタデータＤＢ３３０には、リソースＩＤに対応付けて、リソース種別、アドレス情報の各項目が格納される。
リソースＩＤには、そのリソース５を一意に識別するための識別情報が格納される。
リソース種別には、そのリソース５が備えるリソースの種別が格納される。例えば、監視カメラであれば画像センサが格納され、スマートフォンであれば、位置センサが格納される。つまり、リソース種別には、取得できる情報の種類、例えば、画像情報、位置情報等に応じたリソースの種別が、画像センサ、位置センサ等のように格納される。
アドレス情報には、そのリソースＩＤで示されるリソース５のネットワーク上のアドレス情報が例えば、ＵＲＬ（Uniform Resource Locator）として格納される。
なお、このメタデータＤＢ３３０に格納されるメタデータには、この他にも、例えば、そのリソース５の所有者であるユーザのユーザ情報（ユーザＩＤ等）や、そのリソース５が例えば冷蔵庫等の家電製品であれば、そのリソース５が設置される位置情報（住所や緯度経度）、そのリソース５の性能を示す情報（演算処理速度や解像度等）が含まれていてもよい。
図５に示すように、メタデータＤＢ３３０には、リソースＩＤに対応付けて、リソース種別、アドレス情報の各項目が格納される。
リソースＩＤには、そのリソース５を一意に識別するための識別情報が格納される。
リソース種別には、そのリソース５が備えるリソースの種別が格納される。例えば、監視カメラであれば画像センサが格納され、スマートフォンであれば、位置センサが格納される。つまり、リソース種別には、取得できる情報の種類、例えば、画像情報、位置情報等に応じたリソースの種別が、画像センサ、位置センサ等のように格納される。
アドレス情報には、そのリソースＩＤで示されるリソース５のネットワーク上のアドレス情報が例えば、ＵＲＬ（Uniform Resource Locator）として格納される。
なお、このメタデータＤＢ３３０に格納されるメタデータには、この他にも、例えば、そのリソース５の所有者であるユーザのユーザ情報（ユーザＩＤ等）や、そのリソース５が例えば冷蔵庫等の家電製品であれば、そのリソース５が設置される位置情報（住所や緯度経度）、そのリソース５の性能を示す情報（演算処理速度や解像度等）が含まれていてもよい。
図４に戻り、メタデータ検索部３１２は、リソースリゾルバ１０から、メタデータ検索要求を受信すると、メタデータＤＢ３３０（図５）を参照して、メタデータ検索要求で示されるリソース種別が一致するリソース５のリソースＩＤの情報を抽出する。そして、メタデータ検索部３１２は、抽出したリソースＩＤを付したメタデータ検索応答を生成し、リソースリゾルバ１０に送信する。
なお、メタデータ検索部３１２は、メタデータ検索要求で示される検索条件に静的なメタデータに関するものが含まれている場合には、その検索条件に合致するリソース５を、メタデータＤＢ３３０（図５）を参照して検出する。そして、メタデータ検索部３１２は、検出したリソース５のアドレス情報を取得し、メタデータ検索応答に含めて、リソースリゾルバ１０に送信する。
なお、メタデータ検索部３１２は、メタデータ検索要求で示される検索条件に静的なメタデータに関するものが含まれている場合には、その検索条件に合致するリソース５を、メタデータＤＢ３３０（図５）を参照して検出する。そして、メタデータ検索部３１２は、検出したリソース５のアドレス情報を取得し、メタデータ検索応答に含めて、リソースリゾルバ１０に送信する。
≪ライブデータバッファ装置≫
次に、ライブデータバッファ装置２０について詳細に説明する。
図６は、本実施形態に係るライブデータバッファ装置２０の構成例を示す機能ブロック図である。
ライブデータバッファ装置２０は、自身と接続されるリソース５からライブデータを収集し、そのライブデータを、ライブデータバッファ２００においてリソース５毎に設けたリソースキューに、所定の時間格納しておく。ライブデータバッファ装置２０は、リソース種別を含む検索条件を指定したリソース検索要求をリソースリゾルバ１０から受信すると、そのリソース種別に適合するリソース５のリソースキューをライブデータバッファ２００の中から抽出する。そして、ライブデータバッファ装置２０は、抽出したリソースキューについて、検索条件に合致するライブデータがあるか否かを検索する。検索条件に合致するライブデータを検出した場合に、ライブデータバッファ装置２０は、そのライブデータを送信してきたリソース５のアドレス情報を、リソースＤＢ２３０を参照して取得し、リソースリゾルバ１０に送信する。
このライブデータバッファ装置２０は、制御部２１と、入出力部２２と、記憶部２３とを備える。
次に、ライブデータバッファ装置２０について詳細に説明する。
図６は、本実施形態に係るライブデータバッファ装置２０の構成例を示す機能ブロック図である。
ライブデータバッファ装置２０は、自身と接続されるリソース５からライブデータを収集し、そのライブデータを、ライブデータバッファ２００においてリソース５毎に設けたリソースキューに、所定の時間格納しておく。ライブデータバッファ装置２０は、リソース種別を含む検索条件を指定したリソース検索要求をリソースリゾルバ１０から受信すると、そのリソース種別に適合するリソース５のリソースキューをライブデータバッファ２００の中から抽出する。そして、ライブデータバッファ装置２０は、抽出したリソースキューについて、検索条件に合致するライブデータがあるか否かを検索する。検索条件に合致するライブデータを検出した場合に、ライブデータバッファ装置２０は、そのライブデータを送信してきたリソース５のアドレス情報を、リソースＤＢ２３０を参照して取得し、リソースリゾルバ１０に送信する。
このライブデータバッファ装置２０は、制御部２１と、入出力部２２と、記憶部２３とを備える。
入出力部２２は、各リソース５やリソースリゾルバ１０等との間の情報の入出力を行う。この入出力部２２は、通信回線を介して情報の送受信を行う通信インタフェースと、不図示のキーボード等の入力装置やモニタ等の出力装置との間で情報の入出力を行う入出力インタフェースとから構成される。
記憶部２３は、ハードディスクやフラッシュメモリ、ＲＡＭ等により構成される。
この記憶部２３は、後記するリソースＤＢ２３０およびライブデータバッファ２００が格納されるとともに、制御部２１の各機能を実行させるためのプログラムや、制御部２１の処理に必要な情報が一時的に記憶される。
この記憶部２３は、後記するリソースＤＢ２３０およびライブデータバッファ２００が格納されるとともに、制御部２１の各機能を実行させるためのプログラムや、制御部２１の処理に必要な情報が一時的に記憶される。
制御部２１は、ライブデータバッファ装置２０が実行する処理の全般を司り、メタデータ収集部２１１と、ライブデータ収集部２１２と、リソース検索部２１３と、アドレス情報送信部２１６とを含んで構成される。なお、この制御部２１は、例えば、このライブデータバッファ装置２０の記憶部２３に格納されたプログラムをＣＰＵがＲＡＭに展開し実行することにより実現される。
メタデータ収集部２１１は、自身と接続される各リソース５からメタデータの情報を取得し、リソースＤＢ２３０に格納する。
このリソースＤＢ２３０に格納されるメタデータの情報は、図５のメタデータＤＢ３３０において示した情報と同じ項目であり、リソースＩＤ、リソース種別およびアドレス情報を含むものである。
そして、メタデータ収集部２１１は、メタデータ収集装置３０からの所定の時間間隔でメタデータ要求信号を受け取る等を契機として、リソースＤＢ２３０に記憶した各リソース５のメタデータの情報を、メタデータ収集装置３０に送信する。
このリソースＤＢ２３０に格納されるメタデータの情報は、図５のメタデータＤＢ３３０において示した情報と同じ項目であり、リソースＩＤ、リソース種別およびアドレス情報を含むものである。
そして、メタデータ収集部２１１は、メタデータ収集装置３０からの所定の時間間隔でメタデータ要求信号を受け取る等を契機として、リソースＤＢ２３０に記憶した各リソース５のメタデータの情報を、メタデータ収集装置３０に送信する。
ライブデータ収集部２１２は、自身と接続される各リソース５からライブデータを常時取得し、記憶部２３内に設けられたライブデータバッファ２００に格納する。
このライブデータバッファ２００には、リソース５毎に対応するキューとして、リソースキューを設けておき、所定の時間幅（タイムウィンドウ）（図６では、ｔｉ〜ｔｉ＋ｎ）でライブデータを保存する。
このライブデータバッファ２００には、リソース５毎に対応するキューとして、リソースキューを設けておき、所定の時間幅（タイムウィンドウ）（図６では、ｔｉ〜ｔｉ＋ｎ）でライブデータを保存する。
リソース検索部２１３は、リソース検索要求をリソースリゾルバ１０から受信し、検索条件に合致するライブデータを検索する。このリソース検索部２１３は、ライブデータ検索部２１４とフィルタ処理部２１５とを備える。
ライブデータ検索部２１４は、リソース種別を含む検索条件を指定したリソース検索要求をリソースリゾルバ１０から受信すると、そのリソース種別に適合するリソース５のリソースキューをライブデータバッファ２００の中から抽出する。そして、ライブデータ検索部２１４は、抽出したリソースキューについて、検索条件に合致するライブデータがあるか否かを検索する。
なお、この検索条件には、リソース種別に対応する適正な検索対象の評価値が設定される。具体的には、リソース種別が「画像センサ」であり、画像情報を検索する場合に、例えば、見守りサービスの対象となる祖母の顔の特徴量が評価値となる。リソース種別が「位置センサ」であり、位置情報を検索する場合には、緯度経度や市町村の住所を示す情報が評価値となる。リソース種別が「温度センサ」であり、温度情報を検索する場合には、「３０度以上」といった閾値の情報が評価値となる。ライブデータ検索部２１４は、この検索条件で示される評価値と、ライブデータから抽出する評価値とを比較して、検索条件と合致するか否かを判定する。
なお、この検索条件には、リソース種別に対応する適正な検索対象の評価値が設定される。具体的には、リソース種別が「画像センサ」であり、画像情報を検索する場合に、例えば、見守りサービスの対象となる祖母の顔の特徴量が評価値となる。リソース種別が「位置センサ」であり、位置情報を検索する場合には、緯度経度や市町村の住所を示す情報が評価値となる。リソース種別が「温度センサ」であり、温度情報を検索する場合には、「３０度以上」といった閾値の情報が評価値となる。ライブデータ検索部２１４は、この検索条件で示される評価値と、ライブデータから抽出する評価値とを比較して、検索条件と合致するか否かを判定する。
フィルタ処理部２１５は、検索頻度が高い検索条件（所定の検索条件）について予め指定しておくことにより、ライブデータ収集部２１２によって、ライブデータがライブデータバッファ２００の該当するリソースキューに保存された時点でライブデータを検索する処理（以下、「フィルタ処理」と称する。）を実行する。フィルタ処理部２１５が、このフィルタ処理を実行することの指示は、リソースリゾルバ１０を介してユーザ端末４から検索条件とともに指定されてもよいし、フィルタ処理部２１５が、ライブデータ検索部２１４を監視し、所定の時間内に同一の検索条件に基づく検索が所定の回数以上実行された場合に、その検索条件に基づくフィルタ処理を実行するように設定してもよい。
アドレス情報送信部２１６は、リソース検索部２１３が、リソース検索要求の検索条件に合致するライブデータを検出した場合に、そのライブデータを送信してきたリソース５のアドレス情報を、リソースＤＢ２３０を参照して抽出する。そして、アドレス情報送信部２１６は、抽出したアドレス情報を、リソースリゾルバ１０に送信する。
このようにすることで、ライブデータバッファ装置２０は、各リソース５から送信されてきた最新のライブデータを、有限のタイムウィンドウ内で検索することができる。ライブデータは、データの有効期間が限定的であるため、データが更新される頻度がとても高い。よって、タイムウィンドウを適正に設定することにより、古いデータではなく、最新のデータに基づくユーザ所望のサービスを提供することが可能となる。
また、ライブデータバッファ装置２０は、リソース検索部２１３により、リソース種別が適合するリソース５のリソースキューのみを抽出して、検索条件に合致するか否かを検索すればよいため、全てのリソースキューを検索する必要がない。よって、検索対象のデータ量を低減することが可能となる。
また、ライブデータバッファ装置２０は、リソース検索部２１３により、リソース種別が適合するリソース５のリソースキューのみを抽出して、検索条件に合致するか否かを検索すればよいため、全てのリソースキューを検索する必要がない。よって、検索対象のデータ量を低減することが可能となる。
＜処理の流れ＞
次に、ライブデータ検索システム１が実行する処理の流れを説明する。
図７は、本実施形態に係るライブデータ検索システム１が実行する処理の流れを示すシーケンス図である。
次に、ライブデータ検索システム１が実行する処理の流れを説明する。
図７は、本実施形態に係るライブデータ検索システム１が実行する処理の流れを示すシーケンス図である。
なお、ここでは、各ライブデータバッファ装置２０が、メタデータ収集部２１１により各リソース５のメタデータの情報を取得し、リソースＤＢ２３０に格納しているものとする。また、メタデータ収集装置３０が、メタデータ集約部３１１により、各ライブデータバッファ装置２０から各リソース５のメタデータの情報を取得してメタデータＤＢ３３０に格納しているものとする。
まず、各ライブデータバッファ装置２０のライブデータ収集部２１２は、自身と接続するリソース５からライブデータを取得し、記憶部２３内のライブデータバッファ２００の対応するリソースキューに記憶しているものとする（ステップＳ０）。
そして、リソースリゾルバ１０のリソース検索受付部１１１が、ユーザ端末４から、リソース種別を含む検索条件を指定したリソース検索要求を受け付ける（ステップＳ１）。
次に、リソースリゾルバ１０のメタデータ検索要求部１１２は、リソース検索受付部１１１が受け付けたリソース検索要求を、そのリソース検索要求で示されるリソース種別に該当するリソース５を抽出するためのメタデータ検索要求とし、メタデータ収集装置３０に送信する（ステップＳ２）。
メタデータ収集装置３０のメタデータ検索部３１２は、メタデータ検索要求を受信すると、メタデータＤＢ３３０（図５）を参照して、そのメタデータ検索要求で示されるリソース種別が一致するリソース５のリソースＩＤの情報を抽出する。そして、メタデータ検索部３１２は、抽出したリソースＩＤの情報を、メタデータ検索応答としてリソースリゾルバ１０に送信する（ステップＳ３）。
次に、リソースリゾルバ１０のライブデータ検索通知部１１３は、取得したメタデータ検索応答で示されるリソースＩＤの情報を用いて、ライブデータバッファ装置ＤＢ１３０（図３）を検索し、そのリソースＩＤで示されるリソース５が接続されるライブデータバッファ装置２０を特定する（ステップＳ４）。そして、ライブデータ検索通知部１１３は、その特定したライブデータバッファ装置２０に対して、リソース検索要求を通知する（ステップＳ５）。
続いて、ライブデータバッファ装置２０のリソース検索部２１３（ライブデータ検索部２１４）は、リソース検索要求をリソースリゾルバ１０から受信すると、そのリソース検索要求に付されたリソース種別に適合するリソース５のリソースキューをライブデータバッファ２００の中から抽出する。そして、リソース検索部２１３（ライブデータ検索部２１４）は、抽出したリソースキューについて、検索条件に合致するライブデータがあるか否かを検索する（ステップＳ６）。ステップＳ６では、例えば、検索すべきデータがテキストデータの場合には、検索すべき対象のキーワードが含まれるかを検索し、画像データの場合には、パターンマッチングを行い画像データの比較を行う。
そして、ライブデータバッファ装置２０のアドレス情報送信部２１６は、リソース検索部２１３が、リソース検索要求の検索条件に合致するライブデータを検出した場合に、そのライブデータを送信してきたリソース５のアドレスを、リソースＤＢ２３０（図６）を参照して抽出する。次に、アドレス情報送信部２１６は、抽出したアドレス情報を、リソースリゾルバ１０に送信する（ステップＳ７）。
続いて、リソースリゾルバ１０のリソース一覧回答部１１４は、リソース検索要求を送信したライブデータバッファ装置２０から、ライブデータの検索の結果として、該当するリソース５のアドレス情報を取得する。そして、リソース一覧回答部１１４は、各ライブデータバッファ装置２０から収集したアドレス情報を集約してリソース一覧を生成し、ユーザ端末４に送信する（ステップＳ８）。
以上説明したように、本実施形態に係るライブデータ検索システム１およびライブデータ検索方法によれば、ライブデータを収集するライブデータバッファ装置２０をネットワーク上に分散配置することで、動的に変化する情報であるライブデータに対して、リアルタイムに対象を検索し、検索に合致したライブデータを送信したリソース５のアドレス情報を取得することが可能となる。これにより非常に多数となる同種のリソース５の中からでも、真に必要なリソース５のアドレス情報を取得し、そのリソース５に接続してサービスの提供を受けることができる。
〔本実施形態の変形例〕
次に、本実施形態に係るライブデータ検索システム１の変形例について説明する。
図８は、本実施形態の変形例に係るライブデータ検索システム１ａの全体構成を示す図である。
図１に示した本実施形態に係るライブデータ検索システム１との違いは、図８に示す変形例では、メタデータ収集装置３０がシステム内にないことと、図１のリソースリゾルバ１０が、図８においては、リソースリゾルバ１０ａになっていることである。
次に、本実施形態に係るライブデータ検索システム１の変形例について説明する。
図８は、本実施形態の変形例に係るライブデータ検索システム１ａの全体構成を示す図である。
図１に示した本実施形態に係るライブデータ検索システム１との違いは、図８に示す変形例では、メタデータ収集装置３０がシステム内にないことと、図１のリソースリゾルバ１０が、図８においては、リソースリゾルバ１０ａになっていることである。
本実施形態の変形例に係るリソースリゾルバ１０ａは、ユーザ端末４から、リソース種別を含む検索条件を指定したリソース検索要求を受け付けた場合、ネットワーク上に配置された全てのライブデータバッファ装置２０に対して、リソース検索要求を送信することを特徴とする。つまり、リソースリゾルバ１０ａは、本実施形態に係るリソースリゾルバ１０が行う、メタデータ検索要求をメタデータ収集装置３０送信してメタデータ検索応答を受信し、リソースＩＤで示されるリソース５が属するライブデータバッファ装置２０を特定する処理を行わない。
このようにすることで、メタデータ収集装置３０が備えるメタデータＤＢ３３０がシステム内にない場合であっても、ライブデータに基づきリソース５を発見（検索）することができる。
このようにすることで、メタデータ収集装置３０が備えるメタデータＤＢ３３０がシステム内にない場合であっても、ライブデータに基づきリソース５を発見（検索）することができる。
図９は、本実施形態の変形例に係るリソースリゾルバ１０ａの構成例を示す機能ブロック図である。
図２に示した本実施形態に係るリソースリゾルバ１０と比べ、図９では、メタデータ検索要求部１１２を備えていない点、また、ライブデータ検索通知部１１３ａとなっている点が異なる。なお、図２で示す構成と同じ機能を備える構成については、同一の名称と符号を付し、説明を省略する。
図２に示した本実施形態に係るリソースリゾルバ１０と比べ、図９では、メタデータ検索要求部１１２を備えていない点、また、ライブデータ検索通知部１１３ａとなっている点が異なる。なお、図２で示す構成と同じ機能を備える構成については、同一の名称と符号を付し、説明を省略する。
ライブデータ検索通知部１１３ａは、リソース検索受付部１１１が取得した、リソース種別を含む検索条件を指定したリソース検索要求を、記憶部１３内のライブデータバッファ装置ＤＢ１３０を参照して、ネットワーク上の全てのライブデータバッファ装置２０に対して送信する（図８）。
これにより、リソースリゾルバ１０ａのリソース一覧回答部１１４は、全てのライブデータバッファ装置２０を対象としてアドレス情報を受信し、リソース一覧を生成してユーザ端末４に送信する。
これにより、リソースリゾルバ１０ａのリソース一覧回答部１１４は、全てのライブデータバッファ装置２０を対象としてアドレス情報を受信し、リソース一覧を生成してユーザ端末４に送信する。
本実施形態の変形例に係るライブデータ検索システム１ａは、システム内に各リソース５のメタデータを収集したメタデータＤＢ３３０を備えていない場合において、全てのライブデータバッファ装置２０に対し、リソース検索要求を送信する。これにより、ライブデータ検索システム１ａは、各ライブデータバッファ装置２０が検索条件に適合するライブデータを検出して、そのアドレス情報をリソースリゾルバ１０に送信する。そして、リソースリゾルバ１０が、アドレス情報を集約してリソース一覧を生成しユーザ端末４に送信することができる。
よって、本実施形態の変形例に係るライブデータ検索システム１ａによっても、オープンなＩｏＴを活用したサービスにおいて、ライブデータに基づくリソースの発見（検索）を可能とすることができる。
よって、本実施形態の変形例に係るライブデータ検索システム１ａによっても、オープンなＩｏＴを活用したサービスにおいて、ライブデータに基づくリソースの発見（検索）を可能とすることができる。
なお、本発明は、上記した実施形態に限定されることなく、その趣旨を逸脱しない範囲で変更することができる。
例えば、本実施形態に係るライブデータ検索システム１においては、メタデータ収集装置３０を一つの筺体の装置として構成したが、メタデータ収集装置３０が備える各機能を、例えば、リソースリゾルバ１０が備えるようにしてもよい。
また、ネットワーク上に分散配置したライブデータバッファ装置２０の各機能を、例えば、ルータ等が備えるように構成することもできる。
例えば、本実施形態に係るライブデータ検索システム１においては、メタデータ収集装置３０を一つの筺体の装置として構成したが、メタデータ収集装置３０が備える各機能を、例えば、リソースリゾルバ１０が備えるようにしてもよい。
また、ネットワーク上に分散配置したライブデータバッファ装置２０の各機能を、例えば、ルータ等が備えるように構成することもできる。
１，１ａ ライブデータ検索システム
４ ユーザ端末
５ リソース
１０，１０ａ リソースリゾルバ
２０ ライブデータバッファ装置
３０ メタデータ収集装置
１１，２１，３１ 制御部
１２，２２，３２ 入出力部
１３，２３，３３ 記憶部
１１１ リソース検索受付部
１１２ メタデータ検索要求部
１１３，１１３ａ ライブデータ検索通知部
１１４ リソース一覧回答部
１３０ ライブデータバッファ装置ＤＢ
２００ ライブデータバッファ
２１１ メタデータ収集部
２１２ ライブデータ収集部
２１３ リソース検索部
２１４ ライブデータ検索部
２１５ フィルタ処理部
２１６ アドレス情報送信部
２３０ リソースＤＢ
３１１ メタデータ集約部
３１２ メタデータ検索部
３３０ メタデータＤＢ
４ ユーザ端末
５ リソース
１０，１０ａ リソースリゾルバ
２０ ライブデータバッファ装置
３０ メタデータ収集装置
１１，２１，３１ 制御部
１２，２２，３２ 入出力部
１３，２３，３３ 記憶部
１１１ リソース検索受付部
１１２ メタデータ検索要求部
１１３，１１３ａ ライブデータ検索通知部
１１４ リソース一覧回答部
１３０ ライブデータバッファ装置ＤＢ
２００ ライブデータバッファ
２１１ メタデータ収集部
２１２ ライブデータ収集部
２１３ リソース検索部
２１４ ライブデータ検索部
２１５ フィルタ処理部
２１６ アドレス情報送信部
２３０ リソースＤＢ
３１１ メタデータ集約部
３１２ メタデータ検索部
３３０ メタデータＤＢ
Claims (5)
- ユーザ端末からライブデータを送信するリソースの検索要求を受け付けるリソースリゾルバと、複数の前記リソースのリソース種別を含むメタデータをメタデータＤＢとして格納するメタデータ収集装置と、複数の前記リソースそれぞれから前記ライブデータを収集する複数のライブデータバッファ装置と、がネットワークを介して接続されるライブデータ検索システムであって、
前記リソースリゾルバは、
前記ライブデータバッファ装置のライブデータバッファ装置ＩＤに対応付けて、当該ライブデータバッファ装置に接続される前記リソースのリソースＩＤが格納されるライブデータバッファ装置ＤＢを記憶する記憶部と、
前記リソース種別を含む検索条件を指定したリソース検索要求を受け付けるリソース検索受付部と、
前記リソース検索要求で示される前記リソース種別と合致する前記リソースのリソースＩＤを、前記メタデータ収集装置に対して前記メタデータＤＢの検索を要求することにより取得するメタデータ検索要求部と、
前記取得したリソースＩＤを用いて、前記ライブデータバッファ装置ＤＢを参照し、取得したリソースＩＤで示されるリソースに接続するライブデータバッファ装置を特定し、前記特定したライブデータバッファ装置それぞれに前記リソース検索要求を通知するライブデータ検索通知部と、
前記特定したライブデータバッファ装置それぞれから、前記リソース検索要求に付された前記検索条件に合致するリソースのアドレス情報を取得し、リソース一覧として前記ユーザ端末に送信するリソース一覧回答部と、を備え、
前記ライブデータバッファ装置は、
自身のライブデータバッファ装置に接続する前記リソースのリソース種別とアドレス情報とが格納されるリソースＤＢ、および、前記ライブデータを前記リソース毎のリソースキューに格納するライブデータバッファ、を記憶する記憶部と、
前記リソースそれぞれから前記ライブデータを収集し、前記リソース毎のリソースキューに格納するライブデータ収集部と、
前記リソース検索要求を受信し、前記リソース検索要求に付されたリソース種別に適合するリソースの前記リソースキューについて、前記検索条件に合致するライブデータがあるか否かを検索するリソース検索部と、
前記リソース検索要求の検索条件に合致するライブデータが検出された場合に、当該ライブデータを送信してきたリソースのアドレス情報を、前記リソースＤＢを参照して取得し、前記リソースリゾルバに送信するアドレス情報送信部と、
を備えることを特徴とするライブデータ検索システム。 - 前記ライブデータバッファ装置のリソース検索部は、
所定の検索条件に合致するか否かを、前記ライブデータが前記リソースキューに格納される際に検索するフィルタ処理を実行すること
を特徴とする請求項１に記載のライブデータ検索システム。 - ユーザ端末からライブデータを送信するリソースの検索要求を受け付けるリソースリゾルバと、複数の前記リソースそれぞれから前記ライブデータを収集する複数のライブデータバッファ装置と、がネットワークを介して接続されるライブデータ検索システムであって、
前記リソースリゾルバは、
前記リソースのリソース種別を含む検索条件を指定したリソース検索要求を受け付けるリソース検索受付部と、
複数の前記ライブデータバッファ装置それぞれに、前記リソース検索要求を通知するライブデータ検索通知部と、
複数の前記ライブデータバッファ装置それぞれから、前記リソース検索要求に付された前記検索条件に合致するリソースのアドレス情報を取得し、リソース一覧として前記ユーザ端末に送信するリソース一覧回答部と、を備え、
前記ライブデータバッファ装置は、
自身のライブデータバッファ装置に接続する前記リソースのリソース種別とアドレス情報とが格納されるリソースＤＢ、および、前記ライブデータを前記リソース毎のリソースキューに格納するライブデータバッファ、を記憶する記憶部と、
前記リソースそれぞれから前記ライブデータを収集し、前記リソース毎のリソースキューに格納するライブデータ収集部と、
前記リソース検索要求を受信し、前記リソース検索要求に付されたリソース種別に適合するリソースの前記リソースキューについて、前記検索条件に合致するライブデータがあるか否かを検索するリソース検索部と、
前記リソース検索要求の検索条件に合致するライブデータが検出された場合に、当該ライブデータを送信してきたリソースのアドレス情報を、前記リソースＤＢを参照して取得し、前記リソースリゾルバに送信するアドレス情報送信部と、
を備えることを特徴とするライブデータ検索システム。 - ユーザ端末からライブデータを送信するリソースの検索要求を受け付けるリソースリゾルバと、複数の前記リソースのリソース種別を含むメタデータをメタデータＤＢとして格納するメタデータ収集装置と、複数の前記リソースそれぞれから前記ライブデータを収集する複数のライブデータバッファ装置と、がネットワークを介して接続されるライブデータ検索システムのライブデータ検索方法であって、
前記リソースリゾルバは、
前記ライブデータバッファ装置のライブデータバッファ装置ＩＤに対応付けて、当該ライブデータバッファ装置に接続される前記リソースのリソースＩＤが格納されるライブデータバッファ装置ＤＢを記憶する記憶部を備えており、
前記リソース種別を含む検索条件を指定したリソース検索要求を受け付けるステップと、
前記リソース検索要求で示される前記リソース種別と合致する前記リソースのリソースＩＤを、前記メタデータ収集装置に対して前記メタデータＤＢの検索を要求することにより取得するステップと、
前記取得したリソースＩＤを用いて、前記ライブデータバッファ装置ＤＢを参照し、取得したリソースＩＤで示されるリソースに接続するライブデータバッファ装置を特定し、前記特定したライブデータバッファ装置それぞれに前記リソース検索要求を通知するステップと、
前記特定したライブデータバッファ装置それぞれから、前記リソース検索要求に付された前記検索条件に合致するリソースのアドレス情報を取得し、リソース一覧として前記ユーザ端末に送信するステップと、を実行し、
前記ライブデータバッファ装置は、
自身のライブデータバッファ装置に接続する前記リソースのリソース種別とアドレス情報とが格納されるリソースＤＢ、および、前記ライブデータを前記リソース毎のリソースキューに格納するライブデータバッファ、を記憶する記憶部を備えており、
前記リソースそれぞれから前記ライブデータを収集し、前記リソース毎のリソースキューに格納するステップと、
前記リソース検索要求を受信し、前記リソース検索要求に付されたリソース種別に適合するリソースの前記リソースキューについて、前記検索条件に合致するライブデータがあるか否かを検索するステップと、
前記リソース検索要求の検索条件に合致するライブデータが検出された場合に、当該ライブデータを送信してきたリソースのアドレス情報を、前記リソースＤＢを参照して取得し、前記リソースリゾルバに送信するステップと、を実行すること
を特徴とするライブデータ検索方法。 - ユーザ端末からライブデータを送信するリソースの検索要求を受け付けるリソースリゾルバと、複数の前記リソースそれぞれから前記ライブデータを収集する複数のライブデータバッファ装置と、がネットワークを介して接続されるライブデータ検索システムのライブデータ検索方法であって、
前記リソースリゾルバは、
前記リソースのリソース種別を含む検索条件を指定したリソース検索要求を受け付けるステップと、
複数の前記ライブデータバッファ装置それぞれに、前記リソース検索要求を通知するステップと、
複数の前記ライブデータバッファ装置それぞれから、前記リソース検索要求に付された前記検索条件に合致するリソースのアドレス情報を取得し、リソース一覧として前記ユーザ端末に送信するステップと、を実行し、
前記ライブデータバッファ装置は、
自身のライブデータバッファ装置に接続する前記リソースのリソース種別とアドレス情報とが格納されるリソースＤＢ、および、前記ライブデータを前記リソース毎のリソースキューに格納するライブデータバッファ、を記憶する記憶部を備えており、
前記リソースそれぞれから前記ライブデータを収集し、前記リソース毎のリソースキューに格納するステップと、
前記リソース検索要求を受信し、前記リソース検索要求に付されたリソース種別に適合するリソースの前記リソースキューについて、前記検索条件に合致するライブデータがあるか否かを検索するステップと、
前記リソース検索要求の検索条件に合致するライブデータが検出された場合に、当該ライブデータを送信してきたリソースのアドレス情報を、前記リソースＤＢを参照して取得し、前記リソースリゾルバに送信するステップと、を実行すること
を特徴とするライブデータ検索方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2016151451A JP6530353B2 (ja) | 2016-08-01 | 2016-08-01 | ライブデータ検索システムおよびライブデータ検索方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2016151451A JP6530353B2 (ja) | 2016-08-01 | 2016-08-01 | ライブデータ検索システムおよびライブデータ検索方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2018022239A true JP2018022239A (ja) | 2018-02-08 |
| JP6530353B2 JP6530353B2 (ja) | 2019-06-12 |
Family
ID=61165657
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2016151451A Active JP6530353B2 (ja) | 2016-08-01 | 2016-08-01 | ライブデータ検索システムおよびライブデータ検索方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6530353B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020062175A1 (en) * | 2018-09-29 | 2020-04-02 | Orange | Discovery of internet-of-things resources |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009181327A (ja) * | 2008-01-30 | 2009-08-13 | Sony Corp | 検索サービス提供システム及び検索サービス提供方法 |
| JP2014081937A (ja) * | 2012-10-16 | 2014-05-08 | Korea Electronics Technology Inst | ＩｏＴブラウジング方法および装置 |
| JP2016522490A (ja) * | 2013-05-16 | 2016-07-28 | コンヴィーダ ワイヤレス， エルエルシー | 意味命名モデル |
-
2016
- 2016-08-01 JP JP2016151451A patent/JP6530353B2/ja active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009181327A (ja) * | 2008-01-30 | 2009-08-13 | Sony Corp | 検索サービス提供システム及び検索サービス提供方法 |
| JP2014081937A (ja) * | 2012-10-16 | 2014-05-08 | Korea Electronics Technology Inst | ＩｏＴブラウジング方法および装置 |
| JP2016522490A (ja) * | 2013-05-16 | 2016-07-28 | コンヴィーダ ワイヤレス， エルエルシー | 意味命名モデル |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020062175A1 (en) * | 2018-09-29 | 2020-04-02 | Orange | Discovery of internet-of-things resources |
Also Published As
| Publication number | Publication date |
|---|---|
| JP6530353B2 (ja) | 2019-06-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Cheng et al. | FogFlow: Easy programming of IoT services over cloud and edges for smart cities | |
| US9998566B2 (en) | Intelligent gateway with a common data format | |
| CN106489144B (zh) | 针对资源目录的搜索引擎优化 | |
| Wang et al. | An experimental study on geospatial indexing for sensor service discovery | |
| KR20180049634A (ko) | IoT 데이터를 생성하는 장치 및 방법 | |
| JP2017167748A (ja) | データフロー制御装置およびデータフロー制御方法 | |
| JP2011180946A (ja) | センサデータ提供システム、方法及び装置 | |
| JP2012164369A (ja) | センサデータ提供システム、ゲートウェイ及び抽象化センサデータ生成方法 | |
| US11695832B2 (en) | Data search apparatus, and data search method and program thereof, and edge server and program thereof | |
| CN112840691A (zh) | 在网络中发现可收集数据和分析数据的设备和方法 | |
| Hasenburg et al. | GeoBroker: Leveraging geo-contexts for IoT data distribution | |
| JP2017219930A (ja) | ＩｏＴデバイスシェアリング装置、ＩｏＴデバイスシェアリング方法およびプログラム | |
| Shemshadi et al. | Searching for the internet of things: where it is and what it looks like | |
| CN103907333A (zh) | 用于通过多个异构设备的标识和上下文进行动态服务协作的系统 | |
| US9203704B2 (en) | Discovering a server device, by a non-DLNA device, within a home network | |
| US11394687B2 (en) | Fully qualified domain name (FQDN) determination | |
| KR101938734B1 (ko) | 게이트웨이 기반의 ｍ２ｍ 디바이스들 기능 공유 방법 및 장치 | |
| JP6530353B2 (ja) | ライブデータ検索システムおよびライブデータ検索方法 | |
| US20230267147A1 (en) | Systems and methods for searching for events within video content | |
| Gopikrishnan et al. | HSIR: hybrid architecture for sensor identification and registration for IoT applications | |
| JP5072880B2 (ja) | メタデータ抽出サーバ、メタデータ抽出方法およびプログラム | |
| Ismail et al. | Towards a semantic web of things framework | |
| Anupriya et al. | Smart Environmental Monitoring System Using Labview | |
| Sasirekha et al. | A generic context-aware service discovery architecture for IoT services | |
| Petrolo et al. | The discovery of relevant data-sources in a smart city environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20180607 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20190426 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20190514 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20190516 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6530353 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |