(57)【要約】      （修正有）【課題】ユーザ装置が、必要なデータを取得しやすいデータ取得システム、および、そのデータ取得システムが備えるサーバを提供する。【解決手段】データ取得システムは、ユーザ装置から、ユーザ装置が要求するデータであるユーザ要求データの要件を含むデータ取得要求である１次クエリを取得するサーバ３と、ユーザ要求データおよびユーザ要求データを導出可能なデータのいずれかである端末提供データを提供するデータ提供端末とを備える。サーバ３は、ユーザ装置から１次クエリを取得する１次クエリ取得部３３１と、１次クエリから、データ提供端末が端末提供データを特定可能な属性で、端末提供データを特定したデータ取得要求である２次クエリを決定する２次クエリ決定部３３３と、２次クエリをデータ提供端末に送信するサーバ送信部３１１とを備える。【選択図】図３
2018152053.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ装置（２）から、前記ユーザ装置が要求するユーザ要求データの要件を含むデータ取得要求である１次クエリを取得するサーバ（３、１０３、２０３、９０３）と、前記ユーザ要求データおよび前記ユーザ要求データを導出可能なデータのいずれかである端末提供データを提供するデータ提供端末（４）とを備え、前記ユーザ要求データを前記ユーザ装置が取得するデータ取得システムであって、
前記サーバは、
前記ユーザ装置から前記１次クエリを取得する１次クエリ取得部（３３１）と、
前記１次クエリ取得部が取得した前記１次クエリから、前記データ提供端末が前記端末提供データを特定可能な属性で、前記端末提供データを特定したデータ取得要求である２次クエリを決定する２次クエリ決定部（３３３、１３３３）と、
前記２次クエリ決定部が決定した前記２次クエリを前記データ提供端末に送信するサーバ送信部（３１１）とを備え、
前記データ提供端末は、
前記サーバが送信した前記２次クエリを受信する端末受信部（４１２）と、
前記端末受信部が受信した前記２次クエリを実行して前記端末提供データを取得するデータ取得部（４４２）と、
前記データ取得部が取得した前記端末提供データを、前記２次クエリにより定まる装置に送信する端末送信部（４１１）とを備えるデータ取得システム。
【請求項２】
請求項１において、
前記サーバは、前記１次クエリ取得部が取得した前記１次クエリに基づいて前記２次クエリを受信する前記データ提供端末の要件である受信端末要件を決定し、前記受信端末要件に基づいて前記２次クエリを受信する前記データ提供端末を決定する受信端末決定部（３３２）を備え、
前記サーバ送信部は、前記受信端末決定部が決定した前記データ提供端末に、前記２次クエリ決定部が決定した前記２次クエリを送信するデータ取得システム。
【請求項３】
請求項１または２において、
前記端末送信部は、前記データ取得部が取得した前記端末提供データを前記サーバに送信し、
前記サーバは、
前記端末送信部が送信した前記端末提供データを受信するサーバ受信部（３１２）と、
前記サーバ受信部が受信した前記端末提供データを保持するデータ保持部（３２１）とを備え、
前記サーバ送信部は、前記１次クエリ取得部が取得した前記１次クエリが要求する前記ユーザ要求データを前記データ保持部に保持されている前記端末提供データから決定できる場合、前記データ保持部に保持されている前記端末提供データに基づいて決定した、前記１次クエリが要求する前記ユーザ要求データを前記ユーザ装置に送信し、
前記２次クエリ決定部は、前記１次クエリ取得部が取得した前記１次クエリが要求する前記ユーザ要求データが前記データ保持部に保持されている前記端末提供データから決定できる場合、前記２次クエリを決定しない、データ取得システム。
【請求項４】
請求項１〜３のいずれか１項において、
前記２次クエリ決定部は、前記２次クエリの履歴に基づいて、前記１次クエリ取得部が取得した前記１次クエリが要求する前記ユーザ要求データを受信予定がないと判断した場合に、前記２次クエリを決定するデータ取得システム。
【請求項５】
請求項１〜４のいずれか１項において、
前記１次クエリは、前記ユーザ要求データに対する処理の時間に関する属性の要件である遂行要件を備えており、
前記２次クエリは、前記１次クエリに含まれている前記遂行要件に対応して定まる属性の要件である処理要件を備えているデータ取得システム。
【請求項６】
請求項５において、
前記遂行要件として、前記ユーザ要求データの取得頻度を定める要件を含んでいるデータ取得システム。
【請求項７】
請求項３において、
前記サーバは、前記ユーザ装置に送信した送信履歴に基づいて前記データ保持部に保存しておく前記端末提供データを決定する保持判断部（２３３４）を備えるデータ取得システム。
【請求項８】
請求項１〜７のいずれか１項において、
前記サーバ（１０３）が、前記２次クエリを決定可能な前記１次クエリを公開する公開部（１３４）を備えるデータ取得システム。
【請求項９】
請求項３または７において、
前記２次クエリ決定部（１３３３）は、前記２次クエリとして、前記１次クエリに関わらずに前記データ提供端末に要求する前記端末提供データに対する前記データ取得要求である定常クエリを決定し、
前記サーバ送信部は、前記定常クエリを前記データ提供端末に送信するデータ取得システム。
【請求項１０】
請求項９において、
前記定常クエリは、要求する前記端末提供データの属性に加えて、前記端末提供データの送信頻度を含んでいるデータ取得システム。
【請求項１１】
請求項２において、
前記２次クエリ決定部（１３３３）は、前記２次クエリとして、前記１次クエリに関わらずに前記データ提供端末に要求する前記端末提供データに対する前記データ取得要求である定常クエリを決定し、
前記サーバ送信部は、前記定常クエリを前記データ提供端末に送信し、
前記端末送信部は、前記定常クエリを実行して前記データ取得部が取得した前記端末提供データを前記サーバに送信し、
前記サーバは、
前記端末送信部が送信した前記端末提供データを受信するサーバ受信部（３１２）と、
前記サーバ受信部が受信した前記端末提供データを保持するデータ保持部（３２１）とを備え、
前記受信端末決定部は、前記受信端末要件を満たす前記データ提供端末であるか否かを、前記データ保持部に保持されている前記端末提供データを補間して決定するデータ取得システム。
【請求項１２】
請求項９または１０において、
前記定常クエリは、要求する前記端末提供データの属性に加えて、前記端末提供データの送信要求に備えて前記端末提供データを蓄積する要求を含んでおり、
前記データ提供端末は、前記端末提供データを蓄積する要求を含んだ前記定常クエリを受信した場合に、前記端末提供データを蓄積する蓄積部（４３）を備えるデータ取得システム。
【請求項１３】
請求項９、１０、１２のいずれか１項において、
前記サーバは、
前記２次クエリを決定可能な前記１次クエリを公開する公開部（１３４）と、
前記定常クエリを送信した場合、前記定常クエリにより取得可能な前記端末提供データで、前記ユーザ要求データを提供可能な前記１次クエリを、前記公開部に追加する更新部（１３３５）を備えるデータ取得システム。
【請求項１４】
請求項２において、
前記受信端末決定部は、前記１次クエリに、地図データから特定可能な属性が含まれている場合、前記１次クエリで要求されている前記ユーザ要求データを取得できる地図範囲を決定し、決定した前記地図範囲を前記受信端末要件に含ませて、前記２次クエリを受信する前記データ提供端末を決定するデータ取得システム。
【請求項１５】
請求項１〜１４のいずれか１項において、
前記サーバは、前記１次クエリと前記２次クエリとの対応テーブルであるクエリ対応テーブルを記憶するクエリ対応テーブル記憶部（３２２）を備え、
前記２次クエリ決定部は、前記１次クエリ取得部が取得した前記１次クエリと、前記クエリ対応テーブルとから、前記データ提供端末に送信する前記２次クエリを決定するデータ取得システム。
【請求項１６】
請求項２または１４において、
前記サーバは、前記１次クエリと前記受信端末要件との対応テーブルである端末要件対応テーブルを記憶する端末要件対応テーブル記憶部（３２３）を備え、
前記受信端末決定部は、前記１次クエリ取得部が取得した前記１次クエリと、前記端末要件対応テーブルとから、前記２次クエリを受信する前記データ提供端末を決定するデータ取得システム。
【請求項１７】
請求項１６において、
前記端末要件対応テーブルは、少なくとも１つの前記受信端末要件に対して、要件を充足している程度が高いほど、値が高くなる充足度スコアを備えており、
前記受信端末決定部は、前記受信端末要件を満たす前記データ提供端末のうち、前記充足度スコアが高い前記データ提供端末から順に必要数の前記データ提供端末を、前記２次クエリを受信する前記データ提供端末に決定するデータ取得システム。
【請求項１８】
請求項５において、
前記サーバは、前記１次クエリと前記２次クエリとの対応テーブルであるクエリ対応テーブルを記憶するクエリ対応テーブル記憶部（３２２）を備え、
前記クエリ対応テーブルに、前記１次クエリの前記遂行要件と前記２次クエリの前記処理要件との対応が定められており、
前記２次クエリ決定部は、前記１次クエリ取得部が取得した前記１次クエリに含まれている前記遂行要件と、前記クエリ対応テーブルとから、前記２次クエリの前記処理要件を決定するデータ取得システム。
【請求項１９】
請求項２、１４、１６のいずれか１項において、
前記１次クエリは、前記ユーザ要求データに対する処理の時間に関する属性の要件である遂行要件を備えており、
前記２次クエリは、前記１次クエリに含まれている前記遂行要件に対応して定まる属性の要件である処理要件を備えており、
前記処理要件は、要件を充足するために必要となる負担が大きいほど値が高くなる充足コストを備えており、
前記受信端末決定部は、前記受信端末要件を満たす前記データ提供端末のうち、前記充足コストが低い前記データ提供端末から順に必要数の前記データ提供端末を、前記２次クエリを受信する前記データ提供端末に決定するデータ取得システム。
【請求項２０】
請求項１９において、
前記充足コストは、前記端末提供データを前記端末送信部から送信する際の通信コストであるデータ取得システム。
【請求項２１】
請求項２、１４、１６、１７、１９のいずれか１項において、
前記受信端末決定部は、前記データ提供端末が実行可能な前記２次クエリを前記データ提供端末別に記憶する端末別２次クエリテーブルに基づいて、前記２次クエリを実行可能な前記データ提供端末を決定するデータ取得システム。
【請求項２２】
請求項９、１０、１２、１３のいずれか１項において、
前記サーバ送信部は、登録された前記データ提供端末に前記定常クエリを送信し、新たに前記データ提供端末が登録された場合には、新たに登録された前記データ提供端末にも、前記定常クエリを送信するデータ取得システム。
【請求項２３】
請求項１〜２２のいずれか１項において、
前記１次クエリは、前記データ提供端末が前記端末提供データを取得した時刻の要件である端末時刻要件を含むデータ取得システム。
【請求項２４】
請求項２において、
前記１次クエリが、前記データ提供端末が前記端末提供データを取得する時刻の要件である端末時刻要件を含み、かつ、前記データ提供端末が前記端末提供データを取得する時刻が未来の時刻を含んでいる場合、
前記受信端末決定部は、前記未来の時刻において前記２次クエリを実行可能な前記データ提供端末を検索し、検索の結果、前記２次クエリを受信する前記データ提供端末を決定した後も、前記未来の時刻まで、前記未来の時刻において前記２次クエリを実行可能な前記データ提供端末を繰り返し検索し、新たに検索できた、前記未来の時刻において前記２次クエリを実行可能な前記データ提供端末も、前記２次クエリを受信する前記データ提供端末に決定するデータ取得システム。
【請求項２５】
請求項２４において、
前記１次クエリが、前記端末時刻要件に加えて、前記端末時刻要件により定まる前記未来の時刻において前記データ提供端末が存在する位置の要件も含み、
前記受信端末決定部は、前記データ提供端末が前記端末時刻要件により定まる前記未来の時刻において存在する位置を予測して、前記２次クエリを受信する前記データ提供端末を決定するデータ取得システム。
【請求項２６】
請求項２５において、
前記受信端末決定部は、前記データ提供端末の移動計画を取得できる場合、前記移動計画に基づいて、前記データ提供端末が前記端末時刻要件により定まる前記未来の時刻において存在する位置を予測するデータ取得システム。
【請求項２７】
請求項５、６、１８のいずれか１項において、
前記サーバは、
前記１次クエリに含まれている前記遂行要件に従って前記ユーザ要求データを前記ユーザ装置に提供できる可能性を示す１次クエリ充足情報を決定し、決定した前記１次クエリ充足情報を、前記サーバ送信部から前記ユーザ装置に送信するクエリ充足判断部（９３３４）を備えるデータ取得システム。
【請求項２８】
請求項２７において、
前記クエリ充足判断部は、前記２次クエリ決定部が前記２次クエリを決定した後に、逐次、前記１次クエリ充足情報を決定し、前記１次クエリ充足情報の内容が、前記遂行要件に従って前記ユーザ要求データを前記ユーザ装置に提供できることを示すものから、前記遂行要件に従って前記ユーザ要求データを前記ユーザ装置に提供できないことを示すものになった場合に、前記１次クエリ充足情報を、前記サーバ送信部から前記ユーザ装置に送信するデータ取得システム。
【請求項２９】
ユーザ装置（２）から、前記ユーザ装置が要求するデータであるユーザ要求データの要件を含むデータ取得要求である１次クエリを取得するサーバ（３、１０３、２０３）であって、
前記ユーザ装置から前記１次クエリを取得する１次クエリ取得部（３３１）と、
前記１次クエリ取得部が取得した前記１次クエリから、前記ユーザ要求データおよび前記ユーザ要求データを導出可能なデータのいずれかである端末提供データを提供するデータ提供端末が前記端末提供データを特定可能な属性で、前記端末提供データを特定した前記データ取得要求である２次クエリを決定する２次クエリ決定部（３３３、１３３３）と、
前記２次クエリ決定部が決定した前記２次クエリを前記データ提供端末に送信するサーバ送信部（３１１）とを備えるサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ取得システム、および、そのデータ取得システムが備えるサーバに関する。
【背景技術】
【０００２】
特許文献１には、移動体用端末装置と管理センタとを備えたシステムが開示されている。特許文献１に開示されているシステムでは、管理センタは、登録された移動体の位置と属性を管理する記憶部を備えている。移動体を発見したい移動体用端末装置は、その移動体の位置を含む発見条件を管理センタに通知する。発見条件が通知された管理センタは、記憶部から発見条件に合致する移動体を検索する。そして、検索の結果、発見された移動体の位置を、発見条件を通知してきた移動体用端末装置に送信する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許第３７２１００１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１の技術では、管理センタが、各移動体の属性を予め登録しており、移動体用端末は、位置データが更新された場合に、更新された位置データを管理センタにアップロードする。移動体用端末装置が管理センタに送信する発見条件の各項目は、管理センタの記憶部に記憶されている移動体データのいずれかの項目に相当する。特許文献１では、ある属性の移動体を発見することが目的である。この目的のために、各移動体用端末装置は、逐次、現在位置を管理センサにアップロードする。
【０００５】
特許文献１では、移動体用端末装置が逐次更新するデータは位置データのみであるが、移動体で用いられる端末は、位置データ以外にも、画像データや音声データなど、逐次変化するデータを取得できることは広く知られている。たとえば、画像データや音声データを取得してセンタなどにアップロードできる車載機、携帯端末が知られている。また、端末が提供するデータの用途は、移動体を発見する用途に限らず、種々の用途が考えられる。データの種類が多いほど、データの用途は種々考えられる。
【０００６】
データの用途が種々あると、データを特定する属性が種々考えられる。データを特定する属性が種々考えられると、データを他の装置へ提供する端末（以下、データ提供端末）においてデータを特定する属性が、データを必要とするユーザが使用する装置（以下、ユーザ装置）においてデータを特定する属性と異なる場合が多くなる。
【０００７】
一例を説明する。たとえば、ユーザ装置は、交差点ｘの画像が必要であるため、データの種類を画像とし、目的の位置つまり画像内に写っている位置を交差点ｘとして、データを特定する。これに対して、データ提供端末は、画像データを、データ撮像位置に対応付けて特定する。よって、交差点ｘが写っている画像であるとしても、データを特定する属性は、交差点ｘとは異なる位置ｙで撮像した画像データとなる。
【０００８】
なお、ユーザ装置が必要とするデータ、換言すれば、ユーザ装置が取得を要求するデータは、データ提供端末が提供できるデータではなく、１つ以上のデータ提供端末が提供するデータから導出するデータである場合もある。
【０００９】
ユーザ装置が必要なデータを取得するためには、ユーザ装置が必要とするデータがデータ提供端末ではどのような属性で特定されているかを知って、必要とするデータを、データ提供端末が特定可能な属性で表せばよい。しかし、ユーザ装置を利用するユーザが、ユーザ装置が必要とするデータを、データ提供端末が特定可能な属性で表すことは困難な場合も多い。
【００１０】
本発明は、この事情に基づいて成されたものであり、その目的とするところは、ユーザ装置が、必要なデータを取得しやすいデータ取得システム、および、そのデータ取得システムが備えるサーバを提供することにある。
【課題を解決するための手段】
【００１１】
上記目的は独立請求項に記載の特徴の組み合わせにより達成され、また、下位請求項は、発明の更なる有利な具体例を規定する。特許請求の範囲に記載した括弧内の符号は、１つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。
【００１２】
上記目的を達成するためのデータ取得システムに係る発明は、
ユーザ装置（２）から、ユーザ装置が要求するユーザ要求データの要件を含むデータ取得要求である１次クエリを取得するサーバ（３、１０３、２０３、９０３）と、ユーザ要求データおよびユーザ要求データを導出可能なデータのいずれかである端末提供データを提供するデータ提供端末（４）とを備え、ユーザ要求データをユーザ装置が取得するデータ取得システムであって、
サーバは、
ユーザ装置から１次クエリを取得する１次クエリ取得部（３３１）と、
１次クエリ取得部が取得した１次クエリから、データ提供端末が端末提供データを特定可能な属性で、１次クエリが要求するユーザ要求データを特定したデータ取得要求である２次クエリを決定する２次クエリ決定部（３３３、１３３３）と、
２次クエリ決定部が決定した２次クエリをデータ提供端末に送信するサーバ送信部（３１１）とを備え、
データ提供端末は、
サーバが送信した２次クエリを受信する端末受信部（４１２）と、
端末受信部が受信した２次クエリを実行して端末提供データを取得するデータ取得部（４４２）と、
データ取得部が取得した端末提供データを、２次クエリにより定まる装置に送信する端末送信部（４１１）とを備える。
【００１３】
また、上記目的を達成するためのサーバに係る発明は、
ユーザ装置（２）から、ユーザ装置が要求するデータであるユーザ要求データの要件を含むデータ取得要求である１次クエリを取得するサーバ（３、１０３、２０３）であって、
ユーザ装置から１次クエリを取得する１次クエリ取得部（３３１）と、
１次クエリ取得部が取得した１次クエリから、データを提供するデータ提供端末がユーザ要求データおよびユーザ要求データを導出可能なデータのいずれかである端末提供データを特定可能な属性で、１次クエリが要求するユーザ要求データを特定したデータ取得要求である２次クエリを決定する２次クエリ決定部（３３３、１３３３）と、
２次クエリ決定部が決定した２次クエリをデータ提供端末に送信するサーバ送信部（３１１）とを備える。
【００１４】
これらの発明によれば、ユーザ装置が１次クエリをサーバに伝えると、サーバは、その１次クエリから、データ提供端末が端末提供データを特定可能な属性で、１次クエリが要求するユーザ要求データおよびユーザ要求データを導出可能なデータのいずれかである端末提供データを特定したデータ取得要求である２次クエリを決定する。この２次クエリをデータ提供端末に送信するので、ユーザ装置を利用するユーザが、ユーザ装置が必要とするデータを、データ提供端末が特定可能な属性で表さなくても、データ提供端末は、提供すべき端末提供データを特定することができる。よって、ユーザ装置が、必要なデータを取得しやくなる。
【図面の簡単な説明】
【００１５】
【図１】第１実施形態のデータ取得システム１の全体構成図である。
【図２】図１の遠隔監視装置２の構成を示すブロック図である。
【図３】図１のサーバ３の構成を示すブロック図である。
【図４】端末要件対応テーブルを示す図である。
【図５】クエリ対応テーブルを示す図である。
【図６】図１のデータ提供端末４の構成を示すブロック図である。
【図７】図３の制御部３３が実行する処理を示すフローチャートである。
【図８】第２実施形態で用いるクエリ対応テーブルを示す図である。
【図９】第３実施形態で決定される受信端末要件を示す図である。
【図１０】第３実施形態で決定される２次クエリを示す図である。
【図１１】第４実施形態のサーバ１０３の構成を示すブロック図である。
【図１２】第５実施形態のサーバ２０３の構成を示すブロック図である。
【図１３】第９実施形態のサーバ９０３の構成を示すブロック図である。
【発明を実施するための形態】
【００１６】
以下、本開示の複数の実施形態を図面に基づいて説明する。なお、各実施形態および変形例において対応する構成要素には同一の符号を付すことにより、重複する説明を省略する場合がある。各実施形態および変形例において構成の一部分のみを説明している場合、当該構成の他の部分については、先行して説明した他の実施形態および変形例の構成を適用することができる。また、各実施形態および変形例の説明において明示している構成の組み合わせばかりではなく、特に組み合わせに支障が生じなければ、明示していなくても複数の実施形態および変形例の構成同士を部分的に組み合わせることができる。そして、複数の実施形態および変形例に記述された構成同士の明示されていない組み合わせも、以下の説明によって開示されているものとする。
【００１７】
＜第１実施形態＞
第１実施形態となるデータ取得システム１は、図１に示すように、遠隔監視装置２と、サーバ３と、データ提供端末４とを備えている。図１を用いて、データ取得システム１の概要を説明する。
【００１８】
遠隔監視装置２は、ユーザ要求データを要求するユーザが操作するユーザ装置に相当する。また、ユーザ要求データは、ユーザ装置が要求するデータである。遠隔監視装置２は、画像データを取得して、画像データに写っている地点を遠隔監視する目的で用いられる。遠隔監視装置２は、１次クエリをサーバ３に送信する。１次クエリの詳細は後述するが、第１実施形態では、１次クエリは、画像データをクエリ要求元に送信する要求であり、この１次クエリにより特定されるデータがユーザ要求データである。なお、クエリ要求元とは、１次クエリの送信元を意味する。
【００１９】
サーバ３は、１次クエリを取得して、その１次クエリから２次クエリを決定する。そして、決定した２次クエリをデータ提供端末４に送信する。２次クエリの詳細も後述するが、第１実施形態では、２次クエリは、画像データを取得し、取得した画像データをサーバ３に送信する要求である。
【００２０】
データ提供端末４は車両５に搭載されている。車両５は、ここでは、道路上を走行する４輪車、あるいは、大型トラックなどの４輪よりも多いタイヤを備えた車両とする。ただし、二輪車を車両に含ませてもよい。
【００２１】
データ提供端末４は、２次クエリを取得すると、その２次クエリを実行する。第１実施形態では、２次クエリは、画像データを取得し、取得した画像データをサーバ３に送信する要求である。したがって、データ提供端末４は、画像データを取得し、取得した画像データをサーバ３に送信する。データ提供端末４が２次クエリを実行することにより提供するデータが端末提供データである。
【００２２】
サーバ３は、取得した画像データを遠隔監視装置２に送信する。これにより、遠隔監視装置２は、画像データを取得できる。
【００２３】
［遠隔監視装置２の構成］
図２に示すように、遠隔監視装置２は、入力部２１と、通信部２２と、記憶部２３と、表示部２４と、制御部２５とを備える。入力部２１は、１次クエリを入力するためにユーザが操作する部分であり、たとえば、キーボードである。通信部２２は、サーバ３との間でデータの送受信を行う。通信部２２は、無線通信でも有線通信でもよい。記憶部２３は、サーバ３から送信されてくる画像データを蓄積する。表示部２４は、サーバ３から送信されてくる画像データが示す画像を表示する。
【００２４】
制御部２５は、通信部２２、記憶部２３、表示部２４を制御している。制御部２５は、入力部２１から１次クエリが入力されると、その１次クエリを通信部２２からサーバ３に送信する。また、サーバ３から、１次クエリで要求した画像データが送信された場合には、その画像データを記憶部２３に記憶し、かつ、その画像データが示す画像を表示部２４に表示する。
【００２５】
［サーバ３の構成］
図３に示すように、サーバ３は、サーバ通信部３１と、記憶部３２と、制御部３３とを備える。サーバ通信部３１は、サーバ送信部３１１とサーバ受信部３１２を備える。サーバ送信部３１１は、データ提供端末４および遠隔監視装置２へデータを送信する。データ提供端末４へ送信するデータは２次クエリであり、遠隔監視装置２へ送信するデータは、１次クエリにて要求されているデータである。
【００２６】
サーバ送信部３１１は、データ提供端末４へデータを送信する部分と、遠隔監視装置２へデータを送信する部分とを別々に備えていてもよいし、同じ構成によりデータ提供端末４と遠隔監視装置２へデータを送信してもよい。データ提供端末４は移動体である車両５に搭載されているので、データ提供端末４へのデータの送信は無線送信である。なお、無線送信は、基地局からデータ提供端末４までの送信経路が無線であることを意味し、基地局とサーバ３との間の通信は有線であってもよい。
【００２７】
サーバ受信部３１２は、データ提供端末４および遠隔監視装置２からデータを受信する。データ提供端末４から受信するデータは２次クエリで要求したデータであり、遠隔監視装置２から受信するデータは１次クエリである。
【００２８】
サーバ受信部３１２は、データ提供端末４からデータを受信する部分と、遠隔監視装置２からデータを受信する部分とを別々に備えていてもよいし、同じ構成によりデータ提供端末４と遠隔監視装置２からデータを受信してもよい。ただし、データ提供端末４からのデータの受信は無線受信である。なお、無線受信は無線送信と同様、基地局からデータ提供端末４までの受信経路が無線であることを意味する。
【００２９】
記憶部３２は、フラッシュメモリなどの書き込み可能な非遷移的実体的記憶媒体を備えており、データ保持部３２１、クエリ対応テーブル記憶部３２２、端末要件対応テーブル記憶部３２３として機能している。
【００３０】
データ保持部３２１は、データ提供端末４から送信され、サーバ受信部３１２が受信したデータを保持する。このデータ保持部３２１に保持されるデータとしては、データ提供端末４の端末ＩＤ、データ提供端末４が実行可能な２次クエリの情報、データ提供端末４のＩＰアドレスがある。これらデータ提供端末４ごとに定まる情報をプローブ情報という。プローブ情報に含まれる、データ提供端末４が実行可能な２次クエリの情報には、データ提供端末４のセンサ部４２がどのようなセンサを備えるか、データ提供端末４の端末通信部４１が利用可能な通信回線の種類、通信速度などが含まれていてもよい。
【００３１】
また、データ提供端末４は、周期的に、データ提供端末４の位置をサーバ３に送信しており、データ保持部３２１には、データ提供端末４の最新の位置および過去の位置も端末ＩＤとともに保持される。データ提供端末４の最新の位置および過去の位置も、プローブ情報の一部である。過去の位置の履歴は、データ提供端末４の移動履歴を意味する。また、位置の履歴から車速を算出することができる。なお、プローブ情報に、車速が含まれていてもよい。
【００３２】
また、データ保持部３２１には、各データ提供端末４が受信端末要件に該当するか否かを判断するための情報も記憶されている。この情報は、たとえば、データ提供端末４が備えているセンサの種類である。また、データ提供端末４の最新の位置も、各データ提供端末４が受信端末要件に該当するか否かを判断するための情報になり得る。なお、データ提供端末４が実行可能な２次クエリの情報は、２次クエリを受信するデータ提供端末４を決定するための情報としても利用できる。また、データ保持部３２１には、２次クエリを実行してデータ提供端末４がサーバ３に送信するデータも保持される。
【００３３】
クエリ対応テーブル記憶部３２２はクエリ対応テーブルを記憶しており、端末要件対応テーブル記憶部３２３は端末要件対応テーブルを記憶する。クエリ対応テーブルは、１次クエリと２次クエリとの対応テーブルである。端末要件対応テーブルは、１次クエリと受信端末要件との対応テーブルである。
【００３４】
クエリ対応テーブルおよび端末要件対応テーブルは、いずれも、ユーザ装置が１次クエリを送信するかどうかに関係なく用意されているテーブルであり、かつ、逐次、サーバ３の管理者により逐次更新される。
【００３５】
［端末要件対応テーブル］
図４を用いて、端末要件対応テーブルを説明する。サーバ３は、この端末要件対応テーブルをもとに、２次クエリを送信するデータ提供端末４を決定する。端末要件対応テーブルの説明には１次クエリが必要であるから、まず、１次クエリを説明する。
【００３６】
１次クエリは、ユーザ装置である遠隔監視装置２が要求するデータ（すなわちユーザ要求データ）の要件を含んだデータ取得要求である。つまり、１次クエリは、どのような要件のデータが必要であるかを表している。要求するデータ（以下、対象データ）は、属性とその属性に対する要件で表される。この要件を対象データ要件という。要件は条件ということもできる。クエリは、対象データ要件と、対象データに対する処理（以下、対象処理）とを含んだ要求である。
【００３７】
具体例として、まず、図４に示すテーブルのＮｏ．１に記述されている１次クエリを説明する。Ｎｏ．１の１次クエリは、対象処理が、クエリ要求元にデータを転送するという処理である。対象データ要件には、２つの属性に対する要件が定められている。１つ目の属性は、データ種別であり、その属性に対する要件は画像になっている。２つ目の属性は標的位置であり、その要件は交差点ｘである。標的位置は、画像に写っている位置を意味する。よって、Ｎｏ．１の１次クエリの対象データ要件は、交差点ｘが写っている画像データという要件である。なお、交差点ｘは、座標であってもよいが、ここでは名称であるとする。地図データを持っている場合、交差点の名称が分かれば、属性である位置を座標で特定できる。名称である交差点ｘは、地図データから特定可能な属性である。
【００３８】
Ｎｏ．２に記述されている１次クエリはＮｏ．１と同じである。Ｎｏ．３に記述されている１次クエリは、対象処理は、Ｎｏ．１と同じである。一方、対象データ要件は、Ｎｏ．１とは異なる。Ｎｏ．３に記述されている１次クエリの対象データ要件は、３つの属性に対する要件が定められている。１つ目の属性はデータ種別であり、これに対する要件は平均移動速度である。２つ目の属性は位置領域であり、これに対する要件は交差点ｘを中心とする半径１００ｍの円という要件である。３つ目の属性は時刻であり、これに対する要件は時刻ｔという要件である。
【００３９】
次に受信端末要件を説明する。受信端末要件は、２次クエリを受信するデータ提供端末４が備える要件である。受信端末要件は、端末種別Ｃを備える。端末種別Ｃも要件の１つである。図４の例では、端末種別Ｃとは別に、２つの属性に対して要件が定められている。
【００４０】
受信端末要件の具体例を説明する。Ｎｏ．１の受信端末要件は、端末種別Ｃが端末種別Ｃ１になっている。端末種別Ｃ１は、前カメラ４２１（図６参照）を備えているデータ提供端末４である。Ｎｏ．１の受信端末要件における１つ目の属性は最新自車位置であり、これに対する要件は、交差点ｘの座標（ａ、ｂ）を中心とする半径１００ｍの円内である。
【００４１】
交差点ｘの座標（ａ、ｂ）を中心とする半径１００ｍの円内は、１次クエリで要求されている対象データ（すなわち交差点ｘの画像）を取得できる地図範囲として決定されたものである。なお、この半径１００ｍに代えて、前カメラ４２１の視程距離としてもよい。視程距離を用いる場合、前カメラ４２１の視程距離は、データ提供端末４ごとに予め取得しておくことになる。
【００４２】
２つ目の属性は、最新の時点よりも１秒前の自車位置であり、これに対する要件は、最新自車位置より交差点ｘの座標（ａ、ｂ）から遠いという要件である。これは、自車が座標（ａ、ｂ）に接近していることを要件としていることになる。２つ目の要件を判断するためには、たとえば、最新自車位置をｙ（０）とし、１秒前の自車位置をｙ（−１）とすると、｜ｙ（０）−ｘ｜≦｜ｙ（−１）−ｘ｜が成立するかを判断することになる。
【００４３】
Ｎｏ．２の受信端末要件は、端末種別Ｃが端末種別Ｃ２になっている。端末種別Ｃ２は、前カメラ４２１に加えて後カメラ４２２（図６参照）を備えているデータ提供端末４である。Ｎｏ．２の受信端末要件における１つ目の属性および要件は、Ｎｏ．１と同じである。しかし、Ｎｏ．２の受信端末要件は、２つ目の属性に対する要件は定められていない。この理由は、前後にカメラを備えているから、交差点ｘの座標（ａ、ｂ）から遠ざかっていても、交差点ｘが写っている画像を取得できる可能性があるからである。
【００４４】
Ｎｏ．３の受信端末要件では、端末種別Ｃは特定されていない。この理由は、どのデータ提供端末も位置が取得できることを前提としているからである。なお、サーバ３は、データ提供端末４の端末ＩＤ、データ提供端末４が実行可能な２次クエリの情報を予め登録している。本実施形態では、位置を取得できることを、登録の条件としているものとする。
【００４５】
Ｎｏ．３の受信端末要件は、２つの属性に対して要件が定められている。１つ目の属性は位置であり、これに対する要件は、交差点ｘの座標（ａ、ｂ）を中心とする半径１００−位置精度（ｍ）の円という要件である。１次クエリでは、ｘを中心とする半径１００ｍの円を２つ目の要件としているので、確実にｘを中心とする半径１００ｍの円に入っているデータ提供端末４に限定するために、位置誤差を１００ｍから引いた値を、位置に対する要件としているのである。
【００４６】
２つ目の属性および特性は、１次クエリの３つ目の属性および要件と同じであり、時刻がｔであるという要件である。よって、受信端末要件を充足するかどうかを判断するためには、時刻ｔにおけるデータ提供端末４の位置が必要になる。サーバ３は、データ提供端末４の位置を、プローブ情報として逐次取得している。しかし、取得周期は離散的であることから、必ずしも、時刻ｔにおける位置が取得できているとは限らない。時刻ｔにおけるデータ提供端末４の位置を取得していない場合には、時刻ｔの前後のプローブ情報取得時点で取得した位置から、補間により、時刻ｔにおけるデータ提供端末４の位置を求めればよい。なお、ここでの位置は、受信端末要件に対応するデータである。
【００４７】
また、Ｎｏ．１、Ｎｏ．２の受信端末要件には充足度スコアが含まれている。充足度スコアは、受信端末要件に含まれる少なくとも１つの要件に対して、要件を充足している程度を数値化した値である。本実施形態で数値化している要件は１つ目の要件である。
【００４８】
Ｎｏ．１における充足度スコアは、１／｛ｍａｘ（１０ｍ，｜ｙ−ｘ｜）｝で表される。充足度スコアを表すこの式において、ｙは最新自車位置、ｍａｘは、（）内に示される数値のうち大きい側を採用するという意味である。よって、充足度スコアを計算する式の分母は、１０ｍと、最新自車位置から交差点ｘの座標（ａ、ｂ）までの距離のうち、大きい側の値になる。最新自車位置から座標（ａ、ｂ）までの距離を１０ｍと比較している理由は、あまり自車位置が座標（ａ、ｂ）に近いと、交差点ｘが画像に写りにくい可能性があることを考慮したからである。
【００４９】
Ｎｏ．２における充足度スコアは、２／｛ｍａｘ（１０ｍ，｜ｙ−ｘ｜）｝で表される。Ｎｏ．１において充足度スコアを算出する式と比較すると、分子が１から２に変わっている点で相違する。Ｎｏ．２における受信端末要件では、端末種別Ｃが前カメラ４２１と後カメラ４２２とを備える端末であることを要件としている。そのため、前カメラ４２１のみを要件とするＮｏ．１の受信端末要件を充足する場合と比較して、受信端末要件を充足する可能性が２倍になる。この理由から、Ｎｏ．２における充足度スコアは、Ｎｏ．２における充足度スコアよりも２倍になるように、充足度スコアを算出する式が定められている。
【００５０】
図４に示す２つの充足度スコアは分母が小さいほど高い値になる。よって、交差点ｘの付近に最新自車位置があると、充足度スコアは高くなる。充足度スコアは、受信端末要件のうち、充足度スコアを除く要件を満たすデータ提供端末４が必要数よりも多い場合に、２次クエリを送信するデータ提供端末４を決定するために用いる。必要数は、１次クエリに含まれているデータ種別などに基づいて、１次クエリ別に予め設定されている。
【００５１】
［クエリ対応テーブル］
次に、図５を用いてクエリ対応テーブルを説明する。クエリ対応テーブルは、１次クエリと２次クエリとの対応テーブルであり、１次クエリは説明済みであるので、２次クエリを説明する。２次クエリは、データ提供端末４がデータを特定可能な属性で、１次クエリが要求するユーザ要求データおよびそのユーザ要求データを導出可能なデータのいずれかである端末提供データを特定したデータ取得要求であり、データ提供端末４に送信される。なお、ユーザ要求データを導出可能なデータは、１種類のデータでユーザ要求データを導出できるデータに限られず、複数種類のデータの組み合わせによりユーザ要求データを導出可能なデータも含まれる。
【００５２】
１次クエリをそのままデータ提供端末に送信しない理由は、１次クエリは、データ提供端末４が実行可能な表現で表されていない可能性があるからである。そこで、１次クエリから、データ提供端末４がデータを特定可能な属性で１次クエリが要求するデータを特定した２次クエリを決定するのである。２次クエリにも、対象データと、対象処理とが含まれている。
【００５３】
図５に示されている２次クエリの具体例を説明する。図５に示されているＮｏ．１〜Ｎｏ．３の２次クエリは、いずれも、対象処理はサーバ３に送信という処理である。Ｎｏ．１の２次クエリの対象データ要件は２つの属性に対する要件が定められている。１つ目の属性は、センサ種別であり、これに対する要件は前カメラである。２つ目の属性は自車位置であり、これに対する要件は、自車位置が標的位置である交差点ｘの手前の視程範囲内に位置しているという要件である。視程距離は、前カメラ４２１の解像度、レンズｆ値等のカメラ性能、天候など予め定められた項目により定まる距離と視野角の範囲である。
【００５４】
なお、図４で説明した受信端末テーブルで２次クエリを送信するデータ提供端末４が絞り込まれており、図５に示すＮｏ．１の２次クエリは、交差点ｘに接近しているデータ提供端末４に送信される。したがって、２つ目の要件は、自車位置が交差点ｘの手前に限定されている。
【００５５】
Ｎｏ．２の２次クエリの対象データ要件も２つの属性に対する要件が定められている。１つ目の属性は、センサ種別であり、これに対する要件は前カメラ４２１および後カメラ４２２のうち、交差点ｘ側のカメラである。
【００５６】
２つ目の属性は自車位置であり、これに対する要件は、自車位置が交差点ｘの座標（ａ，ｂ）から視程範囲内に位置しているという要件である。Ｎｏ．１の２次クエリでは、２つ目の要件は、交差点ｘの手前であった。これに対して、Ｎｏ．２の２次クエリでは、交差点ｘの手前とせずに、単に自車位置から交差点ｘの座標（ａ，ｂ）までの距離としている理由は、この２次クエリを実行するデータ提供端末４は、前カメラ４２１および後カメラ４２２を備えているからである。
【００５７】
Ｎｏ．３の２次クエリの対象データ要件も２つの属性に対する要件が定められている。１つ目の属性は、送信対象とする対象データ種別である。これに対する要件は、移動速度になっている。移動速度とのみ指定しており、センサの種別は指定していない。よって、車速センサで取得した速度に限られず、加速度センサで得られる加速度を積分した速度でもよいし、車輪速センサから得た車輪速でもよい。また、ＧＰＳ受信機が受信する信号からドップラー効果に基づいて算出する速度でもよい。ここでの要件は、移動速度であり、１次クエリが要求する平均移動速度ではない。この理由は、サーバ３で平均処理を行うからである。Ｎｏ．３の２次クエリにおいて要求されているデータは、１次クエリにて要求されているユーザ要求データである平均移動速度を導出可能なデータである。２つ目の属性および要件は、１次クエリと同じく、属性が時刻であり、要件が時刻ｔになっている。
【００５８】
また、１次クエリには、位置領域が指定されているが、この２次クエリには、位置に関する要件はない。この理由は、受信端末要件で、すでに位置の要件が考慮されているからである。
【００５９】
なお、本実施形態では、端末要件対応テーブルとクエリ対応テーブルを別々に説明しているが、クエリ対応テーブルと端末要件対応テーブルとが組みわせられたテーブルとしてもよい。クエリ対応テーブルと端末要件対応テーブルは、ともに１次クエリを備えたテーブルであるので、２つのテーブルを組み合わせることができるからである。
【００６０】
［制御部３３の機能］
説明を図３に戻す。制御部３３は、ＣＰＵ、ＲＯＭ、ＲＡＭ等を備えたコンピュータであり、ＣＰＵが、ＲＡＭの一時記憶機能を利用しつつ、ＲＯＭなどの非遷移的実体的記録媒体(non-transitory tangible storage medium)に記憶されているプログラムを実行することで、１次クエリ取得部３３１、受信端末決定部３３２、２次クエリ決定部３３３、データ処理部３３４として機能する。
【００６１】
なお、上述のプログラムは、非遷移的実体的記録媒体（non- transitory tangible storage medium）に格納されていればよく、その具体的な記憶媒体はＲＯＭに限らない。例えばプログラムはフラッシュメモリに保存されていてもよい。ＣＰＵがプログラムを実行することは、プログラムに対応する方法が実行されることに相当する。
【００６２】
また、制御部３３が備える機能ブロックの一部または全部は、一つあるいは複数のＩＣ等を用いて（換言すればハードウェアとして）実現してもよい。また、制御部３３が備える機能ブロックの一部又は全部は、ＣＰＵによるソフトウェアの実行とハードウェア部材の組み合わせによって実現されてもよい。
【００６３】
１次クエリ取得部３３１は、遠隔監視装置２から送信されてサーバ受信部３１２が受信した１次クエリを、サーバ受信部３１２から取得する。
【００６４】
受信端末決定部３３２は、１次クエリ取得部３３１が取得した１次クエリから受信端末要件を決定する。これは、端末要件対応テーブル記憶部３２３に記憶されている端末要件対応テーブルを用いて行う。つまり、端末要件対応テーブルから、１次クエリ取得部３３１が取得した１次クエリを決定し、決定した１次クエリに対応する受信端末要件を決定する。
【００６５】
取得した１次クエリが端末要件対応テーブルに含まれていない場合には、取得した１次クエリが要求する処理、対象データから、これらの処理および対象データを取得するために必要な要件を逐次決定して受信端末要件とする。また、次に説明する２次クエリ決定部３３３が決定する２次クエリを参照し、その２次クエリの内容から受信端末要件を決定してもよい。
【００６６】
さらに、受信端末決定部３３２は、受信端末要件を決定した後、その受信端末要件に基づいて２次クエリを受信するデータ提供端末４を決定する。前述したように、データ保持部３２１には各データ提供端末４が受信端末要件に該当するか否かを判断するための情報も記憶されている。データ保持部３２１に記憶されているこの情報をもとに、１次クエリから決定した受信端末要件を充足するデータ提供端末４を決定する。
【００６７】
なお、受信端末要件に充足度スコアが含まれており、かつ、充足度スコアを除く受信端末要件を充足するデータ提供端末４が必要数よりも多い場合、充足度スコアが高い側から順に必要数のデータ提供端末４を、２次クエリを受信するデータ提供端末４に決定する。
【００６８】
２次クエリ決定部３３３は、１次クエリ取得部３３１が取得した１次クエリと、クエリ対応テーブル記憶部３２２に記憶されているクエリ対応テーブルとから２次クエリを決定する。
【００６９】
取得した１次クエリがクエリ対応テーブルに含まれていない場合には、取得した１次クエリが要求する処理、対象データを、データ提供端末４が対応可能な２次クエリで表現して、データ提供端末４に送信する２次クエリを決定する。
【００７０】
データ処理部３３４は、対象データがデータ提供端末４から送信されてきた場合に、その対象データに対して、１次クエリにより定まる対象処理を実行する。この対象処理がクエリ要求元に転送という処理であれば、データ提供端末４から受信した対象データを、１次クエリを送信したユーザ装置へ転送する。
【００７１】
また、データ処理部３３４は、対象データを、将来取得する１次クエリにより要求された場合に備えてデータ保持部３２１に保存する。第１実施形態では、対象データは、全て、データ保持部３２１に一度保存することとし、かつ、保存期間は、予め定めた一定期間とする。なお、対象データを、データ保持部３２１に保存するか否かを判断する実施形態も後述する。
【００７２】
［データ提供端末４の構成］
図６に示すように、データ提供端末４は、端末通信部４１、センサ部４２、蓄積部４３、制御部４４を備えている。端末通信部４１は、端末送信部４１１と端末受信部４１２を備える。端末送信部４１１は、外部の装置へデータを無線送信する。外部の装置は、たとえばサーバ３である。また、ユーザ装置にデータを送信できるようになっていてもよいし、他のデータ提供端末４にデータを送信できるようになっていてもよい。送信するデータには２次クエリを実行して取得した対象データがある。また、自車位置すなわちデータ提供端末４の位置も、端末送信部４１１から送信する。
【００７３】
端末受信部４１２は、外部から無線で送信されるデータを受信する。受信するデータは、たとえば、サーバ３が送信する２次クエリである。
【００７４】
端末通信部４１が用いる無線通信手段は、ＬＴＥなどの電話回線網、公衆無線ＬＡＮなど、種々の無線通信手段を１種類以上、用いることができる。電話回線網は、ＭＮＯ（Mobile Network Operator）とＭＶＮＯ（Mobile Virtual Network Operator）のいずれでもよい。また、ＭＶＮＯとＭＮＯを両方使用できることが好ましい。
【００７５】
センサ部４２は種々のセンサを備えている。図６では、センサ部４２は、前カメラ４２１、後カメラ４２２、加速度センサ４２３、速度センサ４２４、位置検出センサ４２５を備えている。これらのセンサは、一例であり、この一部を備えていなくてもよいし、また、図６に示していない他のセンサを備えていてもよい。
【００７６】
前カメラ４２１は車両５の前方の画像を撮像する。後カメラ４２２は車両５の後方の画像を撮像する。加速度センサ４２３は車両５に生じる加速度を検出する。速度センサ４２４は車両５の速度、すなわち車速を検出する。位置検出センサ４２５は車両５の現在位置を検出する。
【００７７】
蓄積部４３は、フラッシュメモリなどの書き込み可能な非遷移的実体的記憶媒体を備えており、２次クエリを実行して取得した対象データを蓄積する。
【００７８】
制御部４４は、通信制御部４４１とデータ取得部４４２とを備える。通信制御部４４１は端末通信部４１を制御してデータの送受信を行う。
【００７９】
データ取得部４４２は、端末受信部４１２が２次クエリを受信した場合、その２次クエリを実行可能な間は２次クエリを実行してセンサ部４２から対象データを取得する。２次クエリを受信した時点では２次クエリが実行可能であるとしても、２次クエリに位置の要件が含まれている場合には、２次クエリを受信した時点から位置が変化すれば、２次クエリを実行可能ではなくなることもある。したがって、２次クエリを実行する条件として、２次クエリを実行可能な間がある。
【００８０】
また、過去に２次クエリを実行して、２次クエリにより要求されている対象データが蓄積部４３に蓄積されている場合には、蓄積部４３から対象データを取得する。
【００８１】
データ取得部４４２が対象データを取得した場合、通信制御部４４１は、端末送信部４１１から、その対象データを２次クエリにより定まる装置へ送信する。端末通信部４１が複数種類の無線通信手段を用いることができる場合、対象データを送信する場合において、最も安価にデータ送信可能な無線送信手段を用いる。なお、データ取得部４４２は、２次クエリにより定まる対象処理が蓄積部４３への蓄積である場合には、取得した対象データを蓄積部４３に蓄積する。
【００８２】
［サーバ３の制御部３３が実行する処理］
図３を用いて説明した制御部３３の処理は概要である。次に、図７に示すフローチャートを用いて、制御部３３が実行する処理をより詳しく説明する。制御部３３は、図７に示す処理を周期的に実行する。
【００８３】
ステップ（以下、ステップを省略）Ｓ１では、１次クエリを受信したか否かを判断する。Ｓ１は１次クエリ取得部３３１が実行する。Ｓ１の判断がＮＯであれば後述するＳ８に進む。Ｓ１の判断がＹＥＳであればＳ２へ進む。
【００８４】
Ｓ２では、１次クエリで要求されている対象データがデータ保持部３２１に保存されているか否かを判断する。Ｓ２はデータ処理部３３４が実行する。
【００８５】
Ｓ３およびＳ４は２次クエリ決定部３３３が実行する。Ｓ３では、１次クエリで要求されている対象データの受信予定があるか否かを判断する。図５に例示したように、１次クエリと２次クエリは異なる。このことは、異なる１次クエリであっても、２次クエリが同一になる可能性があることを意味する。そこで、このＳ３では、すでに送信した２次クエリの送信履歴から、今回受信した１次クエリで要求されている対象データを受信する予定があるか否かを判断する。この判断がＹＥＳであればＳ８に進み、ＮＯであればＳ４に進む。Ｓ４では、今回受信した１次クエリから２次クエリを決定する。
【００８６】
Ｓ５〜Ｓ７は受信端末決定部３３２が実行する。Ｓ５では、今回受信した１次クエリから受信端末要件を決定する。Ｓ６では、Ｓ５で決定した受信端末要件と、データ保持部３２１に保存されている各データ提供端末４の情報とから、２次クエリを送信するデータ提供端末４を決定する。Ｓ７では、Ｓ６で決定したデータ提供端末４へ２次クエリを送信する。
【００８７】
Ｓ８〜Ｓ１０はデータ処理部３３４が実行する。Ｓ８では、データ提供端末４から対象データを受信したか否かを判断する。この判断がＮＯであれば図７に示す処理を終了する。Ｓ８の判断がＹＥＳであればＳ９に進む。Ｓ９では、受信した対象データあるいはすでに保存されている対象データを、１次クエリを送信したユーザ装置へ転送する。なお、このＳ９に示す処理は、１次クエリで示されている対象処理を実行することを意味しており、この対象処理がクエリ要求元に転送ではない場合には、１次クエリの対象処理により定まる処理をこのＳ９で実行する。
【００８８】
Ｓ１０では、受信した対象データを、データ保持部３２１に保存する。加えて、保存期間が一定期間を経過した対象データは、データ保持部３２１から削除する。
【００８９】
［第１実施形態のまとめ］
データ提供端末４は、標的位置が交差点ｘであるとの要求を取得しても、標的位置が交差点ｘであるとの要求を理解することができない場合が多い。また、遠隔監視装置２が、データ提供端末４ごとに、各データ提供端末４が理解できる表現でデータ取得要求を作成することも困難である。
【００９０】
また、遠隔監視装置２が交差点ｘの付近の平均速度を取得しようとする場合に、交差点ｘの付近に存在しているデータ提供端末４を特定し、特定したデータ提供端末４に移動速度の送信を要求し、かつ、各データ提供端末４から取得した移動速度を平均するのも困難である。
【００９１】
しかし、本実施形態では、遠隔監視装置２が１次クエリをサーバ３に送信すると、サーバ３は、その１次クエリから、データ提供端末４がデータを特定可能な属性で、１次クエリが要求する対象データを特定した２次クエリを決定する。この２次クエリをデータ提供端末４に送信するので、遠隔監視装置２を利用するユーザは、必要とするデータを、データ提供端末４が特定可能な属性で表さなくても、データ提供端末４は、提供すべきデータを特定することができる。よって、遠隔監視装置２は、必要なデータを取得しやくなる。
【００９２】
＜第２実施形態＞
次に、第２実施形態を説明する。第２実施形態のデータ取得システムのハードウェア構成は第１実施形態と同じである。第２実施形態では、第１実施形態と異なる１次クエリ、２次クエリ、受信端末要件を説明する。
【００９３】
第１実施形態において、遠隔監視装置２がＮｏ．１あるいはＮｏ．２の１次クエリをサーバ３に送信すると、交差点ｘが撮像されている画像データがリアルタイムで転送される。これにより、遠隔監視装置２は、交差点ｘのリアルタイム監視が一応可能となる。
【００９４】
しかし、データ提供端末４におけるフレームレートが遅い場合、および、画像転送処理に要する時間が長い場合には、リアルタイム監視に支障が生じる。また、無線回線の通信速度が遅い場合にも同様に、リアルタイム監視に支障が生じる。
【００９５】
これら、フレームレート、画像転送時間、無線回線の通信速度など、リアルタイム監視に影響するパラメータを、遠隔監視装置２を操作するユーザが１次クエリにて指定することは困難な場合も多い。
【００９６】
また、リアルタイム監視以外でも、対象データに対する処理が、時間に無関係に実行されればよいという１次クエリではなく、時間に関する属性に対する要件を定める必要がある１次クエリが考えられる。
【００９７】
第２実施形態では、１次クエリに遂行要件が含まれている例を説明する。遂行要件は、対象データの処理、つまり対象処理に対する時間に関する属性の要件である。図８に、第２実施形態におけるクエリ対応テーブルを示す。図８に示す２次クエリは、対象処理と対象データ要件を省略している。Ｎｏ．４の１次クエリは、対象処理と対象データ要件は、第１実施形態で説明したＮｏ．１のクエリと同じである。したがって、図８において省略している２次クエリの対象処理と対象データ要件は、Ｎｏ．１の２次クエリと同じである。
【００９８】
図８に示す１次クエリには、上述した遂行要件が含まれている。Ｎｏ．４の１次クエリにおける遂行要件は、２つの属性に対する要件が定められている。１つ目の属性は用途であり、その属性に対する要件は実時間監視である。なお、実時間監視はリアルタイム監視と同じ意味である。
【００９９】
図８に示す２次クエリの処理要件は、１次クエリの遂行要件に対応して定まる属性の要件である。Ｎｏ．４の２次クエリの処理要件は、３つの属性に対する要件が定められている。１つ目の要件は無線回線速度であり、これに対する要件は５Ｍｂｐｓより速いという要件である。２つ目の属性はフレームレートであり、これに対する要件は１０ｆｐｓより速い、つまり、１秒間に１０フレームより多く撮像するという要件である。この要件はデータの取得頻度を定める要件である。３つ目の属性は転送遅延であり、これに対する要件は１秒より短いという要件である。なお、転送遅延は、画像データを撮像してから、その画像データを送信するまでの内部処理に要する時間を意味する。これらの３つの要件を満たせば、それほど遅延がなく画像データが送信先に送られることになる。よって、１次クエリの遂行要件とされている実時間監視が可能となる。
【０１００】
また、Ｎｏ．４の処理要件には、充足コストが含まれている。充足コストは、処理要件を充足するために必要となる負担を表している。ここでの負担は、具体的には通信コストすなわち料金であり、充足コストは、有料回線使用時間と有料回線のビット単価の積である。有料回線使用時間は、有料回線を使用する距離と移動速度とから定める。各位置が有料回線を使用する位置であるか否かは、通信リソースマップから定める。通信リソースマップは、各位置において無料回線が使用できるか否かを示したマップである。この通信リソースマップは、これを提供する業者が管理する端末から取得する。
【０１０１】
Ｎｏ．５の１次クエリは、対象処理が保全になっている。保全とは、後に対象データが必要になる可能性があるので、データ提供端末４が持つ記憶媒体に対象データを一時的に記憶しておく処理である。
【０１０２】
Ｎｏ．５における対象データ要件は、２つの属性に対する要件が定められている。１つ目は、データ種別という属性に対する要件であり、ＭＰ３形式の音声データという要件である。２つ目は、標的位置という属性に対する要件であり、交差点ｘという要件である。
【０１０３】
また、Ｎｏ．５における遂行要件は、２つの属性に対する要件が定められている。１つ目は、保持期間という属性に対する要件であり、期間Ｔという要件である。保持期間は、対象データの保持すなわち記録を実行する期間を意味する。２つ目は、データレートという属性に対する要件であり、ｗ（ｋｂｐｓ）より速いという要件である。このＮｏ．５の遂行要件も、保持期間という時間に関する属性に対する要件が定められている。
【０１０４】
Ｎｏ．５の遂行要件に対応する２次クエリの処理要件は、ストレージ空き容量という属性に対して、ｗＴよりも多いという要件である。１次クエリにおける遂行要件が、保持期間がＴであり、データレートがｗより速いという要件であるので、少なくとも、これらの積であるｗＴだけのデータ容量が記録されるからである。
【０１０５】
［制御部３３の処理例］
次に、Ｎｏ．４の１次クエリを遠隔監視装置２がサーバ３に送信した場合を例に、図７に示したフローチャートに沿って、第２実施形態のおけるサーバ３の制御部３３の処理を説明する。
【０１０６】
Ｎｏ．４の１次クエリを遠隔監視装置２がサーバ３に送信し、この１次クエリをサーバ３が受信すると、Ｓ１はＹＥＳになりＳ２に進む。ここでは、対象データは保存済みではなく、対象データの受信予定もなしとする。よって、Ｓ２、Ｓ３の判断はともにＮＯになりＳ４に進む。Ｓ４では、図８に示すＮｏ．４の２次クエリを決定することになる。
【０１０７】
続くＳ５では、受信端末要件を決定する。ここで決定する受信端末要件は、図４に示したＮｏ．１あるいはＮｏ．２の受信端末要件を備える。これに加えて、上りの通信速度が５Ｍｂｐｓよりも速いという要件を加えてもよい。この要件を加えれば、２次クエリの処理要件を満たさないデータ提供端末４に２次クエリを送信してしまう可能性が低くなる。
【０１０８】
Ｓ６では、Ｓ５で決定した受信端末要件を満たすデータ提供端末４を、２次クエリ送信先に決定する。このＳ６の処理を実行可能とするために、第２実施形態では、端末送信部４１１が実行可能な通信速度、前カメラ４２１および後カメラ４２２が撮像可能なフレームレート、転送遅延時間が、プローブ情報に含まれてデータ保持部３２１に記憶されている。
【０１０９】
なお、受信端末要件を満たすデータ提供端末４が必要数よりも多い場合であって、２次クエリの処理要件に充足コストが含まれている場合には、受信端末要件を満たすデータ提供端末４のうち、充足コストが低いデータ提供端末４から順に必要数のデータ提供端末４を、２次クエリを受信するデータ提供端末４に決定する。必要数は、第１実施形態で説明したように、１次クエリに含まれているデータ種別などに基づいて、１次クエリ別に予め設定されている。
【０１１０】
Ｓ７では、Ｓ６で決定したデータ提供端末４へ２次クエリを送信する。Ｓ８〜Ｓ１０は、第１実施形態と同じであるので説明を省略する。
【０１１１】
この第２実施形態のように、１次クエリに遂行要件が含まれている場合に、２次クエリに、その遂行要件に対応して定まる処理要件を含ませると、ユーザ装置は、必要なデータを、より取得しやすくなる。
【０１１２】
＜第３実施形態＞
第３実施形態では、第１実施形態、第２実施形態と異なる１次クエリ、２次クエリ、受信端末要件を説明する。第３実施形態では、ユーザ装置は、道路異常検出装置である。道路異常検出装置は、道路に何らかの異常な状態が発生しているかを逐次確認するために、周期的に道路の画像を必要とする。
【０１１３】
以下、この道路異常検出装置が、道路状況確認のために、９：００からの１０秒間のｘ交差点の画像データを要求する例を説明する。図９、図１０に、この道路異常検出装置がサーバ３に送信する１次クエリを示している。図９、図１０に示す１次クエリにおいて、対象処理は、第１実施形態と同様、クエリ要求元に転送という処理である。
【０１１４】
対象データ要件は３つの属性に対する要件が定められている。１つ目の属性と要件、２つ目の属性と要件は、図４、図５に示したＮｏ．１の１次クエリと同じである。加えて、図９、図１０に示す１次クエリの対象データ要件には３つ目の属性と要件が定められている。３つ目の属性は時刻であり、これに対する要件は９：００からの１０秒間である。
【０１１５】
さらに、この１次クエリには遂行要件が含まれている。遂行要件は、属性が用途であり、これに対する要件が道路状況確認である。
【０１１６】
この１次クエリに対して受信端末決定部３３２が決定する受信端末要件が図９に示してある。図９には、１つの１次クエリに対応する受信端末要件が２種類示されている。上側の受信端末要件は端末種別Ｃが端末種別Ｃ１であり、下側の受信端末要件は端末種別Ｃが端末種別Ｃ２である。これら端末種別Ｃ１、端末種別Ｃ２は、図４と同じ意味であり、端末種別Ｃ１は前カメラ４２１を備えたデータ提供端末４を意味し、端末種別Ｃ２は前カメラ４２１および後カメラ４２２を備えたデータ提供端末４を意味する。
【０１１７】
また、図９に示す受信端末要件は、３つの属性に対して要件が定められている。１つ目の属性は自車位置であり、これに対する要件は、９：００に交差点ｘの座標（ａ，ｂ）から１００ｍ以内という要件である。
【０１１８】
２つ目の要件は、上側の受信端末要件についてのみ定められており、進行方向という属性に対して、９：００に座標（ａ，ｂ）に接近しているという要件である。この要件は、判断時点が現在か９：００かが違うのみで、図４に示すＮｏ．１の受信端末要件における２つ目の要件と同じである。図９の下段の受信端末要件には、進行方向に対する要件がない理由は、図４のＮｏ．２に２つ目の属性に対する要件がない理由と同じく、データ提供端末４が前カメラ４２１に加えて後カメラ４２２を備えているからである。
【０１１９】
３つ目の要件は、上側の受信端末要件および下側の受信端末要件に対して同じ要件が定められている。３つ目の要件は、通信速度であり、これに対する要件は、現在の通信速度が５Ｍｂｐｓよりも速い、または、現在地が無線ＬＡＮの通信エリアから１ｋｍ以内であるという要件である。１次クエリで要求されているデータ種別が画像データであるので、ある程度、通信速度が速い必要がある。そのため、５Ｍｂｐｓよりも速いという要件が定められている。この要件に加えて、無線ＬＡＮの通信エリアから１ｋｍ以内であるという要件が定められている理由は、第１実施形態と異なり、１次クエリで要求されているデータは、即座に必要なデータではない。そのため、少し後にデータ送信してもよい。加えて、無線ＬＡＮは、画像データを送信するのに支障がない通信速度であり、かつ、通信費が無料である場合が多い。そこで、無線ＬＡＮエリアから１ｋｍ以内という要件が追加されているのである。なお、無線ＬＡＮエリアから１ｋｍ以内かどうかは、無線ＬＡＮの通信エリアマップをもとに判断する。
【０１２０】
図１０は、１次クエリに対して２次クエリ決定部３３３が決定する２次クエリを示している。図１０に示す１次クエリは図９と同じである。図１０に示されている２次クエリは２つであり、それぞれ、図９に示す２つの受信端末要件に対応した２次クエリである。
【０１２１】
図１０に示す２つの２次クエリは、対象処理は、いずれもサーバに送信である。対象データ要件は、３つの属性に対して要件が定められている。１つ目の属性と要件は、図５に示したＮｏ．１、Ｎｏ．２の２次クエリの１つ目の属性および要件と同じである。２つ目の属性も、図５に示したＮｏ．１、Ｎｏ．２の２次クエリの２つ目の属性と同じである。２つ目の属性に対する要件は、時間が９：００になっている以外は、図５に示したＮｏ．１、Ｎｏ．２の２次クエリの２つ目の要件と同じである。３つ目の属性と要件は、同じ図１０の１次クエリの３つ目の属性および要件と同じである。
【０１２２】
図１０に示す２次クエリには、処理要件も定められている。処理要件は、転送遅延という属性に対して、５分以内という要件が定められている。この処理要件は、１次クエリに示されている遂行要件から定まる要件である。遂行要件が道路状況確認であるので、画像データを即座に送信する必要はない。よって、処理要件として転送遅延が５分以内という要件が定められているのである。
【０１２３】
［第３実施形態における処理例］
次に、第３実施形態における処理例を説明する。ユーザ装置である道路異常検出装置は、図９、図１０に示す１次クエリをサーバ３に送信したとする。この１次クエリをサーバ３が受信すると、図７のＳ１がＹＥＳになりＳ２へ進む。対象データが保存済みでなく、対象データの受信予定もないとすると、Ｓ４に進む。Ｓ４では、図１０に示す２次クエリが決定される。Ｓ５では図９に示す受信端末要件が決定される。
【０１２４】
Ｓ６では、Ｓ５で決定した受信端末要件を満たすデータ提供端末４を、２次クエリの送信先に決定する。なお、図９に示した受信端末要件を満たすデータ提供端末４が必要数よりも多い場合には、さらに、受信端末要件を満たすデータ提供端末４のうち、無線ＬＡＮエリアに５分以内に到達する可能性が高いデータ提供端末４から順に、必要数分のデータ提供端末４を２次クエリ送信先に決定してもよい。このためには、データ提供端末４から、移動計画を逐次取得しておき、プローブ情報として蓄積しておくとよい。また、プローブ情報に含まれている移動履歴から、データ提供端末４の今後の移動経路を推定して、無線ＬＡＮエリアに５分以内に到達する可能性を推定してもよい。
【０１２５】
Ｓ７では、Ｓ６で決定した２次クエリ送信先に、２次クエリを送信する。２次クエリを受信したデータ提供端末４は、処理要件が５分以内とされているので、５分以内に転送完了できる通信手段のうちで最も通信費用が安い通信手段を検索する。
【０１２６】
たとえば、３分後に無線ＬＡＮの通信エリアに入ると推定でき、かつ、記憶容量に余裕がある場合には、対象データを記憶していても、即座には送信せずに、無線ＬＡＮエリアに入った後に対象データを送信することを決定する。ただし、このように後で対象データを送信する場合にも、送信された２次クエリを実行することは先にサーバ３に送信する。
【０１２７】
また、受信端末要件を満たしたデータ提供端末４が必ず２次クエリを実行可能とは限らない。データ提供端末４は、２次クエリを受信したが、その２次クエリを実行することができない場合には、その旨をサーバ３に回答する。
【０１２８】
データ提供端末４が対象データを送信し、この対象データをサーバ３が受信するとＳ８の判断がＹＥＳになり、Ｓ９で対象データを道路異常検出装置に転送する。これにより、道路異常検出装置は、交差点ｘの画像データを取得できるので、その画像から交差点ｘの道路状態を確認できる。また、サーバ３は、Ｓ１０を実行して、データ提供端末４から送信された画像データを一時的にデータ保持部３２１に保存しておく。
【０１２９】
この第３実施形態に示したように、ユーザ装置は、必要なデータが過去のデータであっても、容易に必要なデータを取得することができる。
【０１３０】
＜第４実施形態＞
これまでの実施形態では、サーバ３は、１次クエリから２次クエリが決定できるとしていた。しかし、当然のことであるが、どんな１次クエリに対しても２次クエリが決定できる訳ではなく、１次クエリから２次クエリを決定できない可能性もある。
【０１３１】
第４実施形態では、図１１に示すサーバ１０３は、２次クエリを決定可能な１次クエリのリストを公開する公開部１３４を備える。公開部１３４は、インターネットなどの通信回線を介して外部からアクセスできるようになっている記録媒体である。したがって、ユーザ装置は、公開部１３４にアクセスして、サーバ１０３が対応可能な１次クエリを知ることができる。
【０１３２】
サーバ１０３の制御部１３３は更新部１３３５を備える。この更新部１３３５は、公開部１３４に公開している、対応可能な１次クエリを更新する機能である。更新部１３３５の更新処理を具体例で説明する。
【０１３３】
たとえば、当初は、対象データを、（１）車両を指定した位置、（２）位置を指定した画像としており、これらに対して、対象処理として、（Ａ）転送、（Ｂ）保全が可能であることを公開しているとする。
【０１３４】
加えて、対象データを、（３）位置を指定した平均移動速度、（４）位置を指定した平均ワイパー稼動状態、（５）時間とワイパー可動状態を指定した位置、（６）車両と時刻を指定した位置とし、これらに対して、対象処理として（Ａ）転送が可能であることを公開しているとする。
【０１３５】
更新部１３３５は、対応可能な１次クエリとして、対象データを（７）車両と時刻を指定した画像、（８）位置と時刻を指定した画像とし、これらに対して、対象処理として（Ａ）転送が可能であることを追加する。
【０１３６】
更新部１３３５を備えることで、ユーザ装置は、公開部１３４に公開されている、２次クエリを決定可能な１次クエリが増やすことができるので、ユーザは、１次クエリを要求しやすくなる。また、サーバ３が２次クエリを決定できない１次クエリを、サーバ３に送信してしまうことも抑制できる。
【０１３７】
また、第４実施形態では、制御部１３３は、２次クエリ決定部１３３３の機能が、これまでの実施形態の２次クエリ決定部３３３とは異なる。本実施形態の２次クエリ決定部１３３３は、これまでの実施形態の２次クエリ決定部３３３が備えている機能に加えて、２次クエリとして定常クエリを決定する。定常クエリは、１次クエリに関わらずにデータ提供端末４に要求するデータに対するデータ取得要求である。この定常クエリは、定常クエリを実行可能なデータ提供端末４に、サーバ送信部３１１から送信される。送信タイミングは、周期的でもよいし、各データ提供端末４に対して一度でもよい。また、定常クエリを送信したデータ提供端末４に対しては、送信した定常クエリの停止を指示するクエリを送信する。
【０１３８】
定常クエリは、公開部１３４において公開している１次クエリに対応したクエリである。換言すれば、公開部１３４に公開している１次クエリの一部は、定常クエリにより取得可能なデータにより対応できる１次クエリである。更新部１３３５は、新たな定常クエリを送信した場合には、その定常クエリにより対応可能となる新たな１次クエリを、公開部１３４に追加する。
【０１３９】
１次クエリの対象処理が保全であれば、定常クエリも保全を対象処理としている。また、１次クエリの対象処理が転送であれば、定常クエリも転送を対象処理としている。転送の場合、データの送信頻度も定常クエリにより指定されている。定常クエリの対処処理がサーバ３へ転送であり、送信頻度が指定されていると、サーバ３に、随時、データ提供端末４から対象データが送信されることになる。この対象データが現在位置など、受信端末要件の判断に必要なデータであれば、サーバ３は、１次クエリを受信した後に受信端末要件を満たすデータ提供端末４を検索するために、各データ提供端末４からデータを取得する必要がなくなる。よって、迅速に、受信端末要件を満たすデータ提供端末４を決定できる。
【０１４０】
なお、現在位置はプローブ情報の一つである。よって、定常クエリにより、更新が必要なプローブ情報をデータ提供端末４に要求していることになる。
【０１４１】
定常クエリを実行してサーバ１０３に送信された対象データは、データ保持部３２１に一時的に保持する。まだ、この対象データを転送するユーザ装置が決まっていないからである。
【０１４２】
定常クエリをデータ提供端末４に送信することで、サーバ１０３は、１次クエリをユーザ装置から取得した場合には、迅速に、１次クエリが要求する対象データをユーザ装置に提供することができる。
【０１４３】
たとえば、定常クエリの一例を示すと、対象処理が保全であり、対象データが、前カメラ４２１で撮像したフレームレート１０ｆｐｓの画像である。保全は、データを蓄積することを意味しているので、この定常クエリを受信したデータ提供端末４は、定常クエリで指定されている対象データを蓄積部４３に蓄積する。
【０１４４】
定常クエリを送信する対象となるデータ提供端末４は、たとえば、送信時点で定常クエリを実行可能なデータ提供端末４である。また、位置の変化などにより、２次クエリを実行可能となる可能性があるデータ提供端末４にも定常クエリを送信してもよい。
【０１４５】
また、最終的に定常クエリを実行するか否かは、データ提供端末４が決定すればよいので、登録されている全部のデータ提供端末４に定常クエリを送信してもよい。この場合、新しくデータ提供端末４が追加登録された場合には、登録される都度、新たに登録されたデータ提供端末４に定常クエリを送信する。これにより、新たに登録されたデータ提供端末４からも、定常クエリで定められている対象データを取得できる。なお、新しく登録されるデータ提供端末４は、サーバ１０３へ登録を要求するメッセージを送信する。これにより、サーバ１０３は、そのデータ提供端末４を登録することができる。
【０１４６】
＜第５実施形態＞
第１実施形態では、サーバ３は、データ提供端末４から送信された対象データを、全て、予め定めた一定期間、保存していた。これに対して、図１２に示すように、第５実施形態のサーバ２０３が備える制御部２３３は、対象データをデータ保持部３２１に保存するか否かを判断する保持判断部２３３４を備える。
【０１４７】
サーバ２０３に、常時、画像データが多数のデータ提供端末４から送信されてくる場合など、単位時間当たりに多量のデータが送信されてくる場合、データ保持部３２１の空き容量がなくなってしまう恐れもある。そこで、保持判断部２３３４により、対象データをデータ保持部３２１に保存するか否かを判断するのである。
【０１４８】
保持判断部２３３４は、対象データをユーザ装置に送信した送信履歴に基づいて、データ保持部３２１に保存しておく対象データを決定する。対象データをユーザ装置に送信した回数が多いほど、保持しておく価値があるデータであることから、対象データをユーザ装置に送信した送信履歴に基づいて保存しておく対象データを決定する。
【０１４９】
データ保持部３２１に保存しておく対象データを決めるために、対象データに対して破棄優先度を決定する。破棄優先度は、たとえば、一定期間、ユーザ装置に送信していない対象データは、破棄優先度を一定値増加する。そして、データ保持部３２１の空き容量が、規定の空き容量よりも多くなるまで、破棄優先度が高い対象データから順に、対象データを破棄する。保持判断部２３３４は、この処理を周期的に実行する。
【０１５０】
この保持判断部２３３４を備えることで、データ保持部３２１に、有用な対象データを優先して保存することができる。１次クエリで要求されている対象データが、このデータ保持部３２１に保存されている場合には、データ保持部３２１に保存されている対象データをユーザ装置に送信すればよい。
【０１５１】
ユーザ装置の具体例である遠隔監視装置２や道路異常検出装置を考えると、ユーザ装置とサーバ２０３とは有線通信で接続されており低コストで通信できる場合が多いと考えられる。これに対して、サーバ２０３とデータ提供端末４との間の通信は無線通信であり、サーバ２０３とユーザ装置との間の通信に比較して高コストである。したがって、本実施形態のように、データ保持部３２１に、有用な対象データを優先して保存することができるにすることで、システム全体としてのデータ取得コストを抑えることができる。
【０１５２】
＜第６実施形態＞
これまで説明した実施形態では、２次クエリにおいて定められている、対象データの送信先はサーバ３であった。しかし、２次クエリでは、対象データの送信先としてサーバ３とは別の端末を定めることもできる。
【０１５３】
第６実施形態では、データ提供端末４が取得した対象データを車車間通信により、別のデータ提供端末４に送信する。この場合、対象データを受信するデータ提供端末４はユーザ装置であることになる。ユーザ装置であるデータ提供端末４は、１次クエリをサーバ３に送信する。
【０１５４】
この１次クエリを、次のクエリであるとして以下説明する。すなわち、サーバ３が受信した１次クエリは、対象処理がクエリ要求元に転送であり、対象データが位置ｙ付近の現在画像と音声、遂行要件の用途が道路状況確認であるとする。この１次クエリを受信したサーバ３は、図７に示す処理においてＳ１がＹＥＳになり、Ｓ２に進む。
【０１５５】
対象データが保存済みでなく、受信予定もない場合にはＳ４に進む。Ｓ４では２次クエリを決定する。ここで決定する２次クエリは、対象処理が、クエリ要求元であるデータ提供端末４へ送信するという処理であり、対象データが、位置ｙが視程内にあるカメラの画像であり、処理要件が、通信速度１Ｍｂｐｓ以上、かつ、通信遅延が１０秒以下である。なお、データ提供端末４へ送信するという処理を実行するために、２次クエリには、送信先のデータ提供端末の宛先も含まれている。サーバ３は、この宛先を、プローブ情報として事前に受信している。
【０１５６】
Ｓ５では、受信端末要件を決定する。受信端末要件は、たとえば、現在位置が位置ｙから１００ｍ以内であり、車車間通信が可能であり、位置に関連付けた画像と音声を取得可能であるという要件である。なお、車車間通信には、直接車車間通信と、間接車車間通信とがある。間接車車間通信は基地局を介しての車車間通信であり、直接車車間通信は、基地局を介さない車車間通信である。
【０１５７】
Ｓ６では、２次クエリの送信先を決定する。受信端末要件を満たすデータ提供端末４が必要数より多く存在する場合には、直接車車間通信が可能なデータ提供端末４のみを２次クエリの送信先としてもよい。この処理を行うために、直接車車間通信が可能か否かによりスコアが異なる充足度スコアを用いることもできる。
【０１５８】
Ｓ７では、Ｓ６で決定した送信先に２次クエリを送信する。２次クエリにて車車間通信を要求しているので、第６実施形態では、Ｓ８以降は実行しないことになる。
【０１５９】
＜第７実施形態＞
これまでの実施形態では、１次クエリが指定する時刻は、データの取得時点のみであった。しかし、１次クエリに、データ提供端末４がデータを取得した時刻の要件である端末時刻要件を含ませることもできる。なお、この実施形態では、データ提供端末４は、車両５に搭載されているのではなく、室内に設置されているとする。
【０１６０】
端末時刻要件を含んでいる１次クエリの一例を以下に示す。対象処理は、クエリ要求元に送信である。対象データ要件は、データ種別が位置と現在の室内画像であるという要件を備える。また、対象データ要件には、属性である端末状態と、その端末状態の有効期間に対する要件がさらに定められている。
【０１６１】
端末状態に対する要件は、最大加速度が５００ｇａｌよりも大きいという要件である。端末状態の有効期間は、その最大加速度の要件を満たした時刻が、９：００−９：０５の間にあるという要件である。９：００−９：０５が端末時刻要件である。
【０１６２】
この１次クエリは、９：００−９：０５の間に大きく揺れた地震に対して、その地震で大きな振動が生じた位置と、その位置の現在の画像を取得するためのクエリである。この１次クエリは、たとえば、災害被害調査を行うユーザが操作する装置から送信される。
【０１６３】
サーバ３がこの１次クエリを受信すると図７のＳ１がＹＥＳになる。対象データは保存済みではなく、対象データの受信予定もなしとする。よって、Ｓ２、Ｓ３の判断はともにＮＯになりＳ４に進む。Ｓ４では２次クエリを決定する。ここで決定する２次クエリの一例を次に示す。２次クエリは、対象処理がサーバに送信であり、対象データが室内画像である。また、対象データの要件には、他に、時刻が最新の時刻という要件が含まれる。また、処理要件として、転送遅延が５分以下であるという要件も含まれているとする。
【０１６４】
Ｓ５では受信端末要件を決定する。ここで決定する受信端末要件の一例を次に示す。受信端末要件は、端末種別Ｃが室内画像を取得できる端末であり、端末状態が９：００−９：０５に検出した最大加速度が５００ｇａｌよりも大きいことを要件とする。これらの要件を判断するために、本実施形態では、５分よりも短い周期で、加速度を含むプローブ情報をサーバ３に送信しているとする。また、データ提供端末４から受信した最新のプローブ情報が、現時点から１分以内という要件も受信端末要件に含まれている。この要件は、データ提供端末４が破損していないことを確認するための要件である。
【０１６５】
Ｓ６では、上記受信端末要件を満たすデータ提供端末４を２次クエリの送信先に決定し、Ｓ７で、その２次クエリを送信する。
【０１６６】
２次クエリを受信したデータ提供端末４は、現時点の静止画を撮像して、その画像をサーバ３に送信する。これにより、図７のＳ８がＹＥＳになるので、サーバ３は、静止画をユーザ装置へ転送する。
【０１６７】
この第７実施形態によれば、ユーザ装置は、地震が生じた後、大きく揺れた位置と、その位置の現在の画像を、容易に取得することができる。もちろん、過去の時点で生じた現象は地震に限らない。他の例として、データ提供端末４が雨量センサと湿度センサを備えていれば、ゲリラ豪雨通過後の室内湿度も容易に取得することができる。
【０１６８】
＜第８実施形態＞
前述した第７実施形態では、１次クエリに端末時刻要件を含ませることができることを説明した。第７実施形態での端末時刻要件は、過去の時刻を指定していた。しかし、端末時刻要件で未来の時刻を指定してもよい。
【０１６９】
この第８実施形態では、１次クエリが未来の時刻を指定した端末時刻要件を含んでいる。この１次クエリの一例を次に示す。次に示す１次クエリは、地点ｍで別の道路に合流する予定の車が、合流支援を行う装置に合流支援を依頼したときに、合流支援を行う装置がサーバ３に送信した１次クエリの例である。この例では、合流支援を行う装置がユーザ装置になる。また、この実施形態では、データ提供端末４は車両５に搭載されている。
【０１７０】
合流支援を行う装置が送信した１次クエリは、時刻ｔ１−時刻ｔ３の間、次の要件を満たすデータを高頻度に自車に送信というクエリである。つまり、この実施形態では、クエリを送信する時刻も指定されている。
【０１７１】
この１次クエリの要件は、対象が端末位置であり、端末状態が、地点ｍ付近の道路の合流路が接続されている車線Ａを走行しており、端末状態の有効期間が時刻ｔ２−時刻ｔ３という要件である。時刻ｔ２−時刻ｔ３は未来の時刻であり、本実施形態では、この時刻ｔ２−時刻ｔ３が端末時刻要件である。また、地点ｍが、端末時刻要件により定まる未来の時刻において存在する位置の要件である。
【０１７２】
なお、この１次クエリは、今までの実施形態で説明した１次クエリと異なり、対象処理、対象データ要件が何であるか、明確には示されていない。しかし、サーバ３は、この１次クエリを解析して、対象処理、対象データ要件などを抽出することができる。
【０１７３】
この１次クエリをサーバ３が受信すると、図７のＳ１の判断がＹＥＳになりＳ２に進む。１次クエリで要求されている対象データが未来の時点のデータであるので、Ｓ２の判断はＮＯになりＳ３に進む。Ｓ３の判断もＮＯであるとするとＳ４で２次クエリを決定する。
【０１７４】
ここで決定する２次クエリの一例を次に示す。２次クエリは、対象処理がサーバに送信であり、対象データは、時刻ｔ２−時刻ｔ３の現在位置である。また、処理要件として、転送周期が５秒以下であるという要件と、転送遅延が１秒以下であるという要件も含まれているとする。この処理要件は、サーバ３が１次クエリの高頻度を遂行要件と判断して決定した要件である。
【０１７５】
Ｓ５では受信端末要件を決定する。ここで決定する受信端末要件の一例を次に示す。受信端末要件は、端末種別Ｃを、５秒周期以下で現在位置を送信でき、かつ、車線まで区別した位置を検出可能なデータ提供端末４とする。
【０１７６】
５秒周期以下で現在位置を送信できる端末としている理由は、１次クエリにて、高頻度に自車位置を送信することが要求されているからである。車線まで区別した位置を検出可能な端末としている理由は、１次クエリにて車線Ａを走行していることが要件とされているからである。受信端末要件は、さらに、時刻ｔ２−時刻ｔ３の間に車線Ａの地点ｍを通過予定であることを要件としている。
【０１７７】
Ｓ６では、データ保持部３２１に保存されているプローブ情報に基づいて、受信端末要件を満たすデータ提供端末４を検索する。受信端末要件のうち、時刻ｔ２−時刻ｔ３の間に車線Ａの地点ｍを通過予定であるという要件を満たすかどうかを判断するために、データ提供端末４から移動計画が逐次送信されている場合には、その移動計画に基づいて、時刻ｔ２−時刻３においてデータ提供端末４が存在する位置を予測する。
【０１７８】
移動計画は、たとえば、経路案内中の案内経路と経路上の各点を通過する予定時刻である。また、自動運転中であれば、自動運転システムが計画している移動経路と、経路上の各点を通過する予定時刻である。
【０１７９】
移動計画が取得できていないデータ提供端末４については、最新の時点から過去一定距離文の移動軌跡と、データ提供端末４の進行方向前方の道路形状とから、時刻ｔ２−時刻３においてデータ提供端末４が存在する位置を予測する。
【０１８０】
受信端末要件を満たすデータ提供端末４を２次クエリの送信先に決定したら、Ｓ７を実行して、その２次クエリを送信する。ただし、１次クエリにて、クエリを送信する時刻が時刻ｔ１−時刻ｔ３の間であると指定されているので、時刻ｔ１になっていない場合には待機して、時刻ｔ１になった後に２次クエリを送信する。
【０１８１】
その後、Ｓ８へ進む。ただし、この第８実施形態では、時刻ｔ３までは、Ｓ８における判断とともに、Ｓ６、Ｓ７を継続する。最初にＳ６を実行したときからの状況変化により、受信端末要件を充足することになるデータ提供端末４が存在する可能性があるからである。たとえば、車線Ａの隣の車線を走行していた車が、車線変更で、車線Ａを走行することになった場合などである。
【０１８２】
時刻ｔ２よりも前に２次クエリを受信したデータ提供端末４は、時刻ｔ２から時刻ｔ３まで、２次クエリを実行して現在位置をサーバ３に送信する。一方、時刻ｔ２よりも後に２次クエリを受信したデータ提供端末４は、２次クエリを受信した時点から時刻ｔ３まで、２次クエリを実行して現在位置をサーバ３に送信する。
【０１８３】
この第８実施形態によれば、ユーザ装置は、未来の時刻における対象データを、容易に取得することができる。
【０１８４】
＜第９実施形態＞
図１３に第９実施形態のサーバ９０３の構成を示す。前述した第３実施形態において、データ提供端末４は、２次クエリを実行することができない場合には、２次クエリを受信したときに、その旨をサーバ３に回答することを説明した。この回答を取得したサーバ３は、この回答に基づき、対象データをユーザ装置に提供できるかどうかを判断することができる。
【０１８５】
第９実施形態では、対象データをユーザ装置に提供できない、あるいは、できなくなることが予測される場合に、サーバ９０３はその旨をユーザ装置に通知する機能を備える。以下、この機能を詳しく説明する。
【０１８６】
第３実施形態と同様、第９実施形態でも１次クエリには遂行要件が含まれている。クエリ充足判断部９３３４は、１次クエリ充足情報を決定する。１次クエリ充足情報は、１次クエリに含まれている遂行要件に従ってユーザ要求データをユーザ装置に提供できる可能性を示す情報である。
【０１８７】
［１次クエリ充足情報の具体的内容］
１次クエリ充足情報の具体的な内容は、たとえば、１次クエリに含まれる遂行要件をすべて充足できるか否かを示す情報である。また、充足できない遂行要件を示す情報、すなわち充足できない遂行要件がどれであるかをリストなどで示す情報でもよい。充足できない遂行要件を示す情報である場合、充足できない遂行要件の有無により、遂行要件をすべて充足できるかどうかが分かる。したがって、遂行要件をすべて充足できるか否かを示す情報を省略してもよい。また、遂行要件をすべて充足できるか否かを示す情報と充足できない遂行要件を示す情報が両方とも１次クエリ充足情報に含まれていてもよい。
【０１８８】
また、１次クエリ充足情報を決定する際にデータ提供端末４の今後の位置を予測できる場合には、１次クエリ充足情報の内容が、ある時刻ｔ１０までは１次クエリに含まれている遂行要件に従ってユーザ要求データをユーザ装置に提供できるが、その時刻ｔ１０より先は遂行要件に従ってユーザ要求データを提供できないことを示すものでもよい。
【０１８９】
［１次クエリ充足情報の決定タイミング］
クエリ充足判断部９３３４は、１次クエリ取得部３３１が１次クエリを取得した時に１次クエリ充足情報を決定する。また、その後も逐次、１次クエリ充足情報を決定する。１次クエリ充足情報を決定する時点は、たとえば、一定周期ごととすることができる。また、それらに代えて、あるいは、それらに加えて、データ提供端末４から２次クエリを実行できなくなったことを示す通知を受信した時点で１次クエリ充足情報を決定することもできる。
【０１９０】
［１次クエリ充足情報の決定方法］
１次クエリ取得部３３１が１次クエリを取得した時点では、１次クエリ充足情報は、データ保持部３２１に記憶されている情報から決定する。１次クエリ充足情報の決定に用いる、データ保持部３２１に記憶されている情報は、受信端末要件に該当するか否かを判断するための情報である。受信端末要件に該当するか否かを判断するための情報は、たとえば、データ提供端末４の位置、データ提供端末４が備えているセンサの種類、データ提供端末４が利用可能な通信回線の種類、通信速度などである。
【０１９１】
１次クエリ取得部３３１が１次クエリを取得した時点よりも後の時点で１次クエリ充足情報を決定する場合も、１次クエリを取得した時点と同様、データ保持部３２１に記憶されている情報から１次クエリ充足情報を決定することができる。
【０１９２】
また、１次クエリの要件に、対象データを取得する位置あるいは区間の要件が含まれており、データ提供端末４の移動計画を逐次取得してプローブ情報として蓄積している場合には、次のようにして１次クエリ充足情報を決定することもできる。
【０１９３】
まず、逐次、最新のプローブ情報をもとにデータ提供端末４の位置を更新し、データ提供端末４の位置が１次クエリの要件を充足するかを判断することができる。また、データ提供端末４から移動計画を逐次取得していることから、あるデータ提供端末４から取得した最新の移動計画が、同じデータ提供端末４から以前に取得した移動計画から変化していることもある。変化前の移動計画では、１次クエリに含まれる位置あるいは区間の要件を充足すると判断できたが、最新の移動計画では、その要件を将来的に充足できないと判断できることもある。この場合には、データ提供端末４の位置が１次クエリの要件を充足しなくなる位置から、１次クエリの要件を充足するデータ提供端末４の数が減少することになる。１次クエリの要件を充足するデータ提供端末４の数が減少することにより、１次クエリの要件を充足するデータ提供端末４が必要数よりも少なくなれば、１次クエリ充足情報は、１次クエリに含まれる遂行要件を充足できないことを示す情報になる。
【０１９４】
また、１次クエリ充足情報を、データ提供端末４から送信される情報に基づいて決定することもできる。以下、詳しく説明する。第３実施形態と同様、第９実施形態でも、データ提供端末４は、２次クエリを受信したときに、その２次クエリを実行することができない場合には、その旨をサーバ９０３に回答する。加えて、第９実施形態では、データ提供端末４は、２次クエリを実行できる状況が継続しているか否か、換言すれば、２次クエリを実行できない状況になったか否かを、サーバ９０３に送信する。また、将来、２次クエリを実行できない状況になると判断した場合にも、サーバ９０３にその旨を送信する。
【０１９５】
２次クエリを実行できる状況が継続しているか否かの判断を具体的に説明する。たとえば、２次クエリの要件に、通信速度の要件が含まれているとする。通信速度は、場所などの通信環境の変化により変動する。したがって、２次クエリを受信したときには、その２次クエリを実行することができたとしても、その後、通信環境が悪化した場合には、データ提供端末４は２次クエリを実行できなくなることがある。また、通信速度マップを備えており、近く通信速度が２次クエリの処理要件を満たさなくなると判断できることもある。
【０１９６】
これらが、データ提供端末４が２次クエリを実行できない状況になった例、および、将来、２次クエリを実行できない状況になると判断した例である。データ提供端末４は、２次クエリを実行できない状況になった場合、および、将来、２次クエリを実行できない状況になると判断した場合、そのことをサーバ９０３に通知する。なお、通知には、２次クエリを実行できない原因（たとえば、通信速度が低下するなど）を含ませることが好ましい。
【０１９７】
クエリ充足判断部９３３４は、データ提供端末４から、２次クエリを実行できない状況になったことが通知された場合、および、将来、２次クエリを実行できない状況になることが通知された場合、１次クエリを充足するデータ提供端末４の数を減少させる。また、１次クエリを充足するデータ提供端末４の数を減少させた結果、１次クエリを充足するデータ提供端末４の数が必要数よりも少なくなった場合には、１次クエリ充足情報を更新する。なお、１次クエリ充足情報の内容が、１次クエリを充足するデータ提供端末４の数である場合には、１次クエリを充足するデータ提供端末４の数が必要数よりも少なくなったかどうかによらず、１次クエリ充足情報を更新する。
【０１９８】
また、データ提供端末４からの通知に、２次クエリを実行できない原因が含まれている場合には、その原因とクエリ対応テーブルから、１次クエリにおいて、どの要件が充足できないかを決定することもできる。そして、１次クエリ充足情報に、充足できない遂行要件がどれであるかを示す情報を含ませることができる。
【０１９９】
［１次クエリ充足情報を送信する時］
クエリ充足判断部９３３４は、サーバ送信部３１１から、１次クエリ充足情報をユーザ装置に送信する。クエリ充足判断部９３３４は、少なくとも、１次クエリ充足情報の内容が、１次クエリの遂行要件に従って対象データ（すなわちユーザ要求データ）をユーザ装置に提供できることを示すものから、遂行要件に従って対象データをユーザ装置に提供できないことを示すものになったときに、１次クエリ充足情報を送信する。
【０２００】
このときに１次クエリ充足情報を送信できるようにするため、クエリ充足判断部９３３４は、２次クエリ決定部３３３が２次クエリを決定した後、逐次、１次クエリ充足情報を決定する。
【０２０１】
また、ユーザ装置から１次クエリを取得したときにも、１次クエリ充足情報を決定して、決定した１次クエリ充足情報をユーザ装置に送信してもよい。さらに、２次クエリ決定部３３３が２次クエリを決定した後、周期的に、１次クエリ充足情報をユーザ装置に送信してもよい。
【０２０２】
［ユーザ装置の対応］
ユーザ装置は、１次クエリ充足情報が通知されることにより、対象データが提供されることを前提とした待機状態を停止したり、要件を緩和した新たな１次クエリを発行するなどの措置を早期に実行することができる。
【０２０３】
以上、本発明の実施形態を説明したが、本発明は上述の実施形態に限定されるものではなく、次の変形例も本発明の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施できる。
【０２０４】
＜変形例１＞
図５、図１０に示すように、２次クエリには変動しない要件も含まれている。変動しない要件については、データ提供端末４ごとに予め実行可能かどうかを決めておくことができる。よって、データ提供端末４が実行可能な２次クエリを、データ提供端末４ごとに記憶する端末別２次クエリテーブルを作成しておくことができる。
【０２０５】
実行可能な２次クエリは、たとえば、位置取得する、測位精度取得する、画像を保全する、センサ操作、位置を指定した画像を取得する、時間を指定した画像を取得する、などである。これらのうち、取得する処理に関しては、対象データ要件になる。また、保全は対象処理になる。センサ操作とは、センサの設定を変更することを意味しており、設定を変更することにより、取得できるデータが変化するので、これも対象データ要件である。
【０２０６】
２次クエリを受信するデータ提供端末４を決定する際には、各データ提供端末４が、どのような２次クエリが実行可能かを参照することになる。したがって、端末別２次クエリ対応テーブルを作成しておくと、２次クエリの送信先となるデータ提供端末４を容易に決めることができる。また、テーブルとしておくことで、追加変更が容易になる。
【符号の説明】
【０２０７】
１：データ取得システム    ２：遠隔監視装置（ユーザ装置）    ３：サーバ    ４：データ提供端末    ５：車両    ３１：サーバ通信部    ３２：記憶部    ３３：制御部    ４１：端末通信部    ４２：センサ部    ４３：蓄積部    ４４：制御部    １０３：サーバ    １３３：制御部    １３４：公開部    ２０３：サーバ    ２３３：制御部    ３１１：サーバ送信部    ３１２：サーバ受信部    ３２１：データ保持部    ３２２：クエリ対応テーブル記憶部    ３２３：端末要件対応テーブル記憶部    ３３１：１次クエリ取得部    ３３２：受信端末決定部    ３３３：２次クエリ決定部    ３３４：データ処理部    ４１１：端末送信部    ４１２：端末受信部    ４２１：前カメラ    ４２２：後カメラ    ４４１：通信制御部    ４４２：データ取得部    ９０３：サーバ    １３３３：２次クエリ決定部    １３３５：更新部    ２３３４：保持判断部    ９３３４：クエリ充足判断部
【図１】
2018152053.tif 000003
【図２】
2018152053.tif 000004
【図３】
2018152053.tif 000005
【図４】
2018152053.tif 000006
【図５】
2018152053.tif 000007
【図６】
2018152053.tif 000008
【図７】
2018152053.tif 000009
【図８】
2018152053.tif 000010
【図９】
2018152053.tif 000011
【図１０】
2018152053.tif 000012
【図１１】
2018152053.tif 000013
【図１２】
2018152053.tif 000014
【図１３】
2018152053.tif 000015