特許 7311461 連携装置、方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-07-10

(45)【発行日】2023-07-19

(54)【発明の名称】連携装置、方法及びプログラム

(51)【国際特許分類】

   G06Q 50/10 20120101AFI20230711BHJP

   G01B 11/00 20060101ALI20230711BHJP

   H04L 67/00 20220101ALI20230711BHJP

【ＦＩ】

G06Q50/10

G01B11/00 H

H04L67/00

【請求項の数】 7

(21)【出願番号】P 2020088760

(22)【出願日】2020-05-21

(65)【公開番号】P2021184137

(43)【公開日】2021-12-02

【審査請求日】2022-06-07

(73)【特許権者】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】100092772

【弁理士】

【氏名又は名称】阪本 清孝

(74)【代理人】

【識別番号】100119688

【弁理士】

【氏名又は名称】田邉 壽二

(72)【発明者】

【氏名】小森田 賢史

(72)【発明者】

【氏名】田坂 和之

【審査官】塩田 徳彦

(56)【参考文献】

【文献】特開２００２－３１１１２４（ＪＰ，Ａ）

【文献】特開２０１８－０７９７３２（ＪＰ，Ａ）

【文献】特開２０１３－１２４９８８（ＪＰ，Ａ）

【文献】国際公開第２０１２／０９０８９０（ＷＯ，Ａ１）

【文献】特開２０１８－１４６５４６（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

Ｇ０１Ｂ １１／００

Ｈ０４Ｌ ６７／００

(57)【特許請求の範囲】

【請求項1】

端末において取得される測位情報と、前記端末において撮影される撮影画像と、を受信し、
複数のVPSサーバの各々について記憶されている、当該VPSサーバがカバーしている測位情報範囲を参照し、前記受信した測位情報が該当するVPSサーバを候補として選択し、
前記選択されたVPSサーバの中から、VPS測位をリクエストする対象としてVPSサーバを決定して、前記撮影画像を送信する決定部と、
前記決定されたVPSサーバが前記撮影画像を点群と照合して推定した、前記撮影画像の位置及び向きの推定結果を受信し、当該推定結果の成否を判定する判定部と、
前記撮影画像と前記推定結果の成否と前記決定したVPSサーバとを紐づけて記憶する判定結果記憶部と、を備える連携装置であって、
前記決定部では、前記判定結果記憶部に蓄積して記憶されている、撮影画像と当該撮影画像の推定結果の成否とVPSサーバとの情報を参照して、前記決定することを特徴とする連携装置。

【請求項2】

前記決定部では、前記判定結果記憶部に蓄積して記憶されている情報のうち、撮影画像と、当該撮影画像の推定結果の成否のうち成功したものと、VPSサーバと、の情報を参照して、前記端末において撮影された撮影画像に類似する撮影画像が蓄積されていると判定されるVPSサーバを、VPS測位をリクエストする対象として前記決定することを特徴とする請求項１に記載の連携装置。

【請求項3】

前記決定部では前記決定したVPSサーバに対して、前記撮影画像に加えて、前記端末において取得された測位情報を送信し、
前記判定結果記憶部では、前記撮影画像と前記推定結果の成否と前記決定したVPSサーバと前記端末において取得された測位情報とを紐づけて記憶し、
前記決定部では、前記判定結果記憶部に蓄積して記憶されている情報のうち、紐づけられている測位情報が、前記端末において取得された測位情報に近いと判定される情報を参照して、前記決定することを特徴とする請求項１または２に記載の連携装置。

【請求項4】

前記判定部において前記推定結果が成功であると判定された場合、前記推定結果における位置及び向きを、前記端末の位置及び向きであるものとして、前記端末に通知することを特徴とする請求項１ないし３のいずれかに記載の連携装置。

【請求項5】

前記決定部では、前記決定したうえでさらに、
前記決定されたVPSサーバに紐づけて前記判定結果記憶部に過去のものとして蓄積して記憶されている、過去の撮影画像であって推定結果が成功であるものの中から、前記撮影画像に類似すると判定されるものを検索し、当該検索された過去の撮影画像に紐づいた推定結果における位置及び向きの情報を取得し、
前記決定されたVPSサーバでは、
前記撮影画像を点群と照合する際の範囲を、前記過去の撮影画像に紐づいた推定結果における位置及び向きに近いと判定される部分に限定することを特徴とする請求項１ないし４のいずれかに記載の連携装置。

【請求項6】

端末において取得される測位情報と、前記端末において撮影される撮影画像と、を受信し、
複数のVPSサーバの各々について記憶されている、当該VPSサーバがカバーしている測位情報範囲を参照し、前記受信した測位情報が該当するVPSサーバを候補として選択し、
前記選択されたVPSサーバの中から、VPS測位をリクエストする対象としてVPSサーバを決定して、前記撮影画像を送信する決定段階と、
前記決定されたVPSサーバが前記撮影画像を点群と照合して推定した、前記撮影画像の位置及び向きの推定結果を受信し、当該推定結果の成否を判定する判定段階と、
前記撮影画像と前記推定結果の成否と前記決定したVPSサーバとを紐づけて記憶する判定結果記憶段階と、を備える、コンピュータによって実行される連携方法であって、
前記決定段階では、前記判定結果記憶段階によって蓄積して記憶されている、撮影画像と当該撮影画像の推定結果の成否とVPSサーバとの情報を参照して、前記決定することを特徴とする連携方法。

【請求項7】

コンピュータを請求項１ないし５のいずれかに記載の連携装置として機能させることを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、複数のVPSサーバが存在する場合に、効率的なサーバ選択を可能とする連携装置、方法及びプログラムに関する。

【背景技術】

【0002】

ユーザに地図情報等を提供する様々な技術が存在する。

【0003】

特許文献１では、複数の地図がある際に、移動履歴やランドマークに基づき地図を選択し表示する。特許文献２では、車での位置推定において、地図情報選択部を設け、位置や角度によって地図を選択する仕組みを提供している。特許文献３では、地理的ルールに基づき、エリア推定アルゴリズムを有する。これらには位置情報やユーザの投稿情報などが用いられる。

【先行技術文献】

【特許文献】

【0004】

【文献】特開2007-249221号公報

【文献】特開2011-209845号公報

【文献】特開2016-161828号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかしながら、以上のような従来技術では、地図情報等の提供システムが複数ある場合に、適したシステムを選んで利用することに特段の制約がないことを前提としており、このような制約がある場合に適切な利用を行うことについての考慮はなされていなかった。

【0006】

このような制約がある場合として、事業主体が異なるVPS(Visual Positioning System)サービス提供者に対して、ユーザがGNSS（全地球測位衛星システム、Global Navigation Satellite System）等による概略的な位置情報と、ユーザの周辺環境を撮影した画像とを送信して、サービス提供者側でこの画像を3D点群と照合することで詳細な撮影位置をユーザに返信する場合が挙げられる。

【0007】

特に、ユーザの概略的な位置情報に該当する地図を有しているサービス提供者が複数ある場合に、ユーザの側で適切なサービス提供者を事前に選択することが困難であった。このようなサービス提供者が複数ある場合として、屋内外の境界など、どのVPSサービス提供者が担当する、どの地図が担当する区域かが、ユーザの概略的な位置情報ではわからない場合がある。すなわち、ユーザがそのような境界に存在する場合には、位置に基づくVPSシステムの選択が難しい。

【0008】

例えば、ユーザがあるローカルエリアに存在しており、このローカルエリア内には屋内と屋外の区別があるとし、屋内の地図は事業者aが、屋外の地図は事業者bが担当している場合に、ユーザがこの境界位置に存在していると、概略的な位置情報のみから、事業者a,bのいずれが適切かを判断することができなかった。仮にユーザが屋内に存在するにもかかわらず、屋外の情報を提供する事業者bに問い合わせたとすると、ユーザは適切な位置情報が得られないのみならず、問い合わせのコストも無駄になってしまうという課題があった。ユーザ自身が事業者a,bのいずれを利用するか選択することも考えられるが、その都度、手間が発生してしまうという課題があった。

【0009】

以上のような従来技術の課題に鑑み、本発明は、ユーザの概略的な測位情報をカバーしうる複数のVPSサーバが存在する場合に、効率的なサーバ選択を可能とする連携装置、方法及びプログラムを提供することを目的とする。

【課題を解決するための手段】

【0010】

上記目的を達成するため、本発明は、端末において取得される測位情報と、前記端末において撮影される撮影画像と、を受信し、複数のVPSサーバの各々について記憶されている、当該VPSサーバがカバーしている測位情報範囲を参照し、前記受信した測位情報が該当するVPSサーバを候補として選択し、前記選択されたVPSサーバの中から、VPS測位をリクエストする対象としてVPSサーバを決定して、前記撮影画像を送信する決定部と、前記決定されたVPSサーバが前記撮影画像を点群と照合して推定した、前記撮影画像の位置及び向きの推定結果を受信し、当該推定結果の成否を判定する判定部と、前記撮影画像と前記推定結果の成否と前記決定したVPSサーバとを紐づけて記憶する判定結果記憶部と、を備える連携装置であって、前記決定部では、前記判定結果記憶部に蓄積して記憶されている、撮影画像と当該撮影画像の推定結果の成否とVPSサーバとの情報を参照して、前記決定することを特徴とする。また、当該連携装置に対応する方法及びプログラムであることを特徴とする。

【発明の効果】

【0011】

本発明によれば、VPS測位をリクエストした結果の実績の情報として、撮影画像と、当該撮影画像の推定結果の成否とVPSサーバとの情報を蓄積して記憶しておき、この情報を参照してVPS測位をリクエストする対象としてVPSサーバを決定することにより、実績を考慮することにより効率的に、VPS測位をリクエストする対象として適切なVPSサーバを決定することができる。

【図面の簡単な説明】

【0012】

【図1】一実施形態に係るVPSシステムの構成例を示す図である。

【図2】図１の３つのサーバが測位サービスを提供するローカルエリアの構成の模式的な例を示す図である。

【図3】一実施形態に係るVPSシステムの機能ブロック図である。

【図4】一実施形態に係るVPSシステムの動作のフローチャートである。

【図5】図１の構成のローカルエリアLにおいて、図４のフローを実施した場合の動作例を示す図である。

【図6】一般的なコンピュータにおけるハードウェア構成の例を示す図である。

【発明を実施するための形態】

【0013】

図１は、一実施形態に係るVPSシステム100の構成例を示す図である。VPSシステム100には、自身の測位を行うことを要望するユーザが利用する端末10（スマートフォン等のモバイル端末）と、連携装置20と、複数のVPSサーバ30（図３で後述）の例としての３つのサーバ30A,30B,30Cと、が存在し、これらは相互にネットワークを介して通信可能に構成されている。

【0014】

端末10のユーザは、自身で判断して３つのサーバ30A,30B,30Cの中から適切に測位サービスを提供するサーバを選択して測位のリクエストを行うことも可能であるが、手間が発生し、間違う可能性がある。本実施形態においては、ユーザはこのような選択を行う必要なく、連携装置20へと測位のリクエストを行い、連携装置20において３つのサーバ30A,30B,30Cの中から適切なサーバを選択して当該リクエストを選択されたサーバに送信して当該サーバからの返信として測位結果を受信し、端末10へと測位結果を返信することができる。

【0015】

ここで、ユーザの端末10はローカルエリアLに存在し、このローカルエリアLに該当する地図情報を有し、VPSによる測位サービスを提供可能な複数のサーバ30の例が、図１における３つのサーバ30A,30B,30Cである。このようなサーバ数及び種類は、端末10が存在するローカルエリア毎に一般に変化しうるものとなる。

【0016】

図２は、図１の３つのサーバ30A,30B,30Cが測位サービスを提供するローカルエリアLの構成の模式的な例を示す図である。例EX1はローカルエリアLを上空側から見た状態を示し、例EX2は例EX1の線LNでの断面図として、ローカルエリアLを水平で見た状態を示している。ローカルエリアLには２つの建物BA,BC（例えばショッピングモール等の建物）と、これらの建物BA,BCの間にある屋外エリアLBと、が存在する。建物BA内には屋内エリアLA（１階エリアA1、２階エリアA2及び３階エリアA3）が存在し、建物BC内には屋内エリアLC（１階エリアC1及び２階エリアC2）が存在する。

【0017】

図１の３つのサーバ30A,30B,30Cは例えばそれぞれ、図２の屋内エリアLA、屋外エリアLB及び屋内エリアLCの地図を有するVPSサーバであり、当該エリア内に端末10が存在する場合に、適切な測位サービスを提供することが可能なものとして構成されているものである。しかしながら、端末10がローカルエリアL内に存在することで、エリアLA,LB,LCのいずれかに存在する場合であっても、端末10においてGNSS等による測位を行うと、マルチパス誤差等により、エリアLA,LB,LCのいずれに端末10が存在するかを正確に判定することができないため、VPSサービスを受けるための事前情報としてのGNSS等による概略的な測位情報では、３つのサーバ30A,30B,30CのいずれにVPS測位サービスを受けるべきかを正確に決定することができない。本実施形態では連携装置20が端末10からのVPS測位リクエストに対して中継を行い、３つのサーバ30A,30B,30Cの中から（後述するようにある程度の測位サービスの提供結果（すなわち、測位結果）の成否の情報が蓄積された後において、）適切なサーバを自動で選択することが可能である。

【0018】

図３は、一実施形態に係るVPSシステム100の機能ブロック図である。VPSシステム100は、端末10、連携装置20及びVPSサーバ30を備える。VPSサーバ30は、図１及び図２を参照して概略的に説明したように、端末10の存在するローカルエリアの地図情報を有し、測位サービスを提供可能な複数のサーバのうちの任意の１つを表すものである。

【0019】

端末10は、測位部11、撮影部12及びUI（ユーザインタフェース）部13を備える。連携装置20は、エリア記憶部21、決定部22、判定結果記憶部23及び判定部24を備える。VPSサーバ推定部31及び点群記憶部32を備える。各部の機能概要は以下の通りである。

【0020】

測位部11は、ハードウェアとしてはGNSS等で構成され、端末10の概略的な位置として３次元座標または２次元座標での測位を行い、測位情報（誤差を含みうるもの）を決定部22へと送信する。測位部11は、GNSS等に代えて、または加えて、測位衛星を利用するGNSS等では測位が困難となる屋内測位も可能な手法として、WiFi（登録商標）による位置測位やBluetooth（登録商標）のビーコンによる測位を行うものとして構成されていてもよい。測位部11はまた、複数のこれらの測位手法を組み合わせて補正した測位情報を出力するものとして構成されていてもよく、VPS測位以外の任意の既存手法により誤差を含みうる測位情報を出力するものとして構成されていればよい。撮影部12は、ハードウェアとしてはカメラで構成され、端末10の周辺環境（フィールド）の撮影を行い、得られた画像を決定部22へと送信する。

【0021】

決定部22は、（１）測位部11で得た誤差を含みうる測位情報をエリア記憶部21に対して照合し、この測位情報が該当する地図情報（測位情報の誤差によるマージンも考慮したうえで、当該地図情報が当該測位された位置をカバーしているもの）を有しているような候補としてのVPSサーバ30の情報（当該サーバにネットワーク経由でアクセスするためのIPアドレス等の情報）を取得し、（２）このようなVPSサーバ30が２つ以上取得された場合には、判定結果記憶部23に対して撮影部12から得られた画像を照合することにより、２つ以上のVPSサーバ30の中から測位サービスを要求するのに適切な１つのサーバを決定し、（３）当該決定したサーバ（VPSサーバ30）の推定部31に対して、撮影部12から得られた画像を送信する。

【0022】

なお、上記の決定部22の（１）～（３）の処理のうち、（１）の模式例が図１及び図２で説明した例である。すなわち、測位部11で得た測位情報がローカルエリアL内にある場合には、候補となるVPSサーバ30として、３つのサーバ30A,30B,30Cの情報が取得される。

【0023】

また、上記の（２）の処理に関しては、後述する図４のステップS2の説明においてその詳細をさらに説明する。上記の処理（３）に関して、推定部31に対して撮影部12から得られた画像に加えて、測位部11から得られた測位情報も送信するようにしてもよい。

【0024】

エリア記憶部21は、決定部22が上記の（１）の処理を行うことを可能とすべく、予め、複数のVPSサーバ30の各々につき、該当しうる測位情報（測位部11で得る測位情報）の範囲を記憶しておく。ここで、当該VPSサーバ30の点群記憶部32（後述）に記憶されている地図の範囲R1内において、測位部11が測位を行ったとする場合に測位情報として得られうる範囲R2として、エリア記憶部21において予め記憶しておく。従って、点群記憶部32が記憶している範囲R1（測位サービスを提供できる所定範囲）よりも、測位部11の測位情報の誤差によるマージンを考慮した広い所定範囲R2（R2⊃R1）として、エリア記憶部21では範囲R2を記憶しておく。なお、範囲R2を記憶しておく実施形態とは別の実施形態として、エリア記憶部21では点群記憶部32が記憶しておくのと同様の範囲R1のみをVPSサーバ30の各々について記憶しておき、決定部22が上記の（１）の処理を行う際に、測位部11で得た測位情報に誤差による所定のマージンを考慮して、測位情報が範囲R1内に該当しうるものであるかを判断するようにしてもよい。すなわち、測位部11で得た測位情報において、誤差による所定のマージンを考慮した測位情報の近傍範囲（測位情報の位置を中心に誤差マージンで変動しうる真値の範囲）と範囲R1とが重複していれば、当該VPSサーバ30を候補として決定してもよい。

【0025】

判定結果記憶部23では、決定部22が上記の（２）の処理を行うことを可能とすべく、後述する判定部24で得た判定結果（及びその関連情報）を記憶しておく。具体的には、VPSサーバ30へと測位サービスのリクエストを送信し、その結果を得る都度取得される情報として、以下のデータD1を紐づけて記憶しておく。
（データD1）
●測位部11から得た測位情報
●撮影部12で得た画像（及び／またはこの画像から抽出される画像特徴情報）
●測位部11の測位情報と撮影部12の画像との共通の時刻情報（タイムスタンプ）
●決定部22が処理（２）で決定したVPSサーバ30のID（識別子）
●判定部24において判定した判定結果（判定成否と、成功の場合は推定部31が推定した位置及び向きの情報）

【0026】

推定部31は、決定部22から送信された画像（撮影部12で撮影された画像）を解析し、点群記憶部32で記憶されている3D点群と照合することにより、この画像の位置及び向き（撮影部12を構成するカメラの３次元世界座標における位置及び向き）を推定して、推定結果の位置及び向きを判定部24へと送信する。

【0027】

推定部31では、既存手法のVPSの手法（SfM(Structure from Motion)等を用いた手法）により、画像の位置及び向きを推定することができる。SfMにおいては、例えばSIFT特徴等により画像から特徴点（２次元画像座標）及び局所特徴量を求め、点群記憶部32に記憶しておく3D点群に関しても同様に、各点を特徴点（３次元世界座標）としてその局所特徴量を予め登録しておき、画像の特徴点と3D点群の特徴点との間で対応（局所特徴量が一致すると判定される特徴点同士の対応）を利用して三角測量等の原理により、画像の各特徴点の３次元世界座標の情報を得ることで、画像の位置及び向きを推定することができる。

【0028】

なお、推定部31では、点群記憶部32で記憶している3D点群と、決定部22で得た画像から抽出される特徴点との整合度合いが閾値判定で低い（例えば点対応の誤差の二乗和等が閾値判定で大きい）と判定される場合には、この画像に該当する位置及び向きが存在しないものとして、測位に失敗した旨の情報を判定部24へと送信すればよい。

【0029】

点群記憶部32では、推定部31が上記のように位置及び向きの推定を可能とすべく、所定の3D点群の情報（各特徴点の３次元座標と局所特徴量の情報）を予め記憶しておく。決定部22及びエリア記憶部21に関して前述した通り、点群記憶部32が記憶しておく3D点群の範囲が、当該VPSサーバ30が測位サービスを提供可能な地図の範囲に相当するものとなる。

【0030】

判定部24では、推定部31から得た位置及び向きの推定結果を判定結果として判定結果記憶部23へと保存し、且つ、位置及び向きの推定結果をUI部13へと送信する。判定部24で判定結果を保存することにより、判定結果記憶部23では前述したデータD1の形式での判定結果及びその関連情報を蓄積して記憶することとなる。

【0031】

判定部24では、推定部31から得た推定結果が、測位に失敗した旨を意味している場合は、失敗しているものとして、判定結果を判定結果記憶部23に保存すればよく、失敗した旨を意味しておらず位置及び向きの推定結果が得られている場合には、測位に成功したものとして、判定結果を判定結果記憶部23に保存すればよい。

【0032】

上記の判定部24の実施形態は、推定部31から得た推定結果をそのまま利用するものであるが、判定部24の別の実施形態として、当該推定結果をさらに端末10のユーザに対して提示したうえで、推定部31の推定結果が成功である場合に、ユーザの立場で実際に成功しているかの確認を得たうえで、判定結果を判定結果記憶部23に保存するようにしてもよい。すなわち、推定部31で得た推定結果が失敗した旨を意味していない場合には、得られた位置及び向きの推定結果をUI部13において端末10のユーザに対して提示し、ユーザより位置及び向きの推定結果がユーザの立場において実際に正しかったか否かの情報をユーザフィードバックとして受け付け、UI部13より判定部24へと返信したうえで、ユーザフィードバックにおいても正しかったと判定されている場合に、成功しているものとして判定結果を判定結果記憶部23に保存するようにしてもよい。（すなわち、推定部31で推定結果が成功として得られていても、ユーザフィードバックで失敗と判定された場合には、失敗したものとして判定結果を判定結果記憶部23に保存するようにしてもよい。）

【0033】

UI部13は上記の通り、端末10のユーザへのユーザインタフェースを提供する役割を有するものであり、判定部24から送信された位置及び向きの推定結果を、所定の地図上にプロットする等の形により、ユーザに対して提供する。（推定失敗の場合は、失敗した旨をテキストメッセージ等によりユーザに対して提供すればよい。）判定部24において上記のユーザ確認を求める実施形態の場合、UI部13ではさらに、推定結果を確認したユーザより、推定結果がユーザ判断で実際に正しいものであったか否かの情報をユーザフィードバックとして、メニュー入力等の形により受け取り、このユーザフィードバックを判定部24へと送信する。

【0034】

図４は、一実施形態に係るVPSシステム100の動作のフローチャートであり、以上説明してきた図３の機能ブロックの各部の処理に関して、処理タイミングの観点から説明するものである。

【0035】

当該フローが開始されると、ステップS1では、端末10において、ユーザによるVPS測位のリクエストのために、位置の測位及び画像の撮影が行われたか否かを判定し、肯定の場合にはステップS2へと進み、否定の場合はステップS1に戻り、肯定判定が得られるまで待機する。ステップS1で肯定判定の場合、ユーザ操作により、撮影部12がユーザの存在するフィールド（端末10の存在するフィールド）を撮影することで画像を取得し、且つ、この撮影時刻と同時刻において、測位部11が測位を行うことで測位情報を取得し、これら画像及び測位情報が連携装置20の決定部22へと送信される。

【0036】

ステップS2では、連携装置20の決定部22において、ステップS1で肯定判定を得て送信された測位情報及び画像を受信し、前述した（１）～（３）の処理を行うことにより、VPS測位のリクエストを送信するのに最適と判定される１つのVPSサーバ30を決定して、このVPSサーバ30へと画像（ステップS1で肯定判定を得て撮影部12で撮影された画像）（及びステップS1で肯定判定を得て測位部11で得られた測位情報）を送信してから、ステップS3へと進む。

【0037】

後述するとした決定部22の処理（２）の詳細は次の通りである。決定部22は、判定結果記憶部23を参照し、処理（１）で候補として得た複数のVPSサーバ30に関してそれぞれ、判定結果記憶部23で記憶している情報のうち、測位に成功したと判定される情報を取得する。当該取得することにより、候補のVPSサーバ30の各々に関して、測位に成功した際の複数の画像（成功画像クラスタ）が得られることとなる。従って、決定部22では、ステップS1で肯定判定を得たリクエストとなる画像（撮影画像）と、各VPSサーバ30の成功画像クラスタと、を照合し、撮影画像に最も類似していると判定される成功画像クラスタに対応するVPSサーバ30を、測位サービスを要求すべきサーバとして決定することができる。画像と成功画像クラスタとの類似判定には、任意の既存手法を用いることができ、例えばBoVW（バグオブビジュアルワーズ）等の手法で類似度を評価すればよい。成功画像クラスタに関しては、BoVWの代表ベクトルを１つあるいは複数定める等して、画像との間で類似度評価をすればよい。

【0038】

なお、このような類似度評価が適切に機能するためには、例えば図１及び図２の例であれば、サーバ30A,30B,30Cが地図情報を有する各エリアLA,LB,LCにおいて撮影される画像は、互いに少なくともある程度は非類似であることが前提である。なお、異なるエリアで全く同じ画像が撮影されるということは通常であれば起こりえないため、この前提は通常であれば成立する。また、異なるエリアで幾分か類似する画像が撮影される場合であっても、完全同一の画像が撮影されることは通常起こりえないため、判定結果記憶部23に記憶されている異なるエリアでの測位の成功画像クラスタの画像数が多数あれば、類似度評価は適切に機能しうるものとなる。

【0039】

なお、決定部22の処理（２）において候補のVPSサーバ30の各々に関して成功画像クラスタを得る際には、判定結果記憶部23で記憶している情報のうち、測位に成功しており、且つ、前述のデータD1の形式で記憶されている測位情報がステップS1で肯定判定を得て送信された測位情報に閾値判定で近いと判定されるようなものとして、成功画像クラスタを取得するようにしてもよい。

【0040】

ステップS3では、ステップS2で決定されたVPSサーバ30の推定部31において、決定部22から送信された画像（及び測位情報）を受信し、画像より特徴点及び局所特徴量を抽出したうえで点群記憶部32に記憶されている点群と照合し、照合結果として画像の位置及び向きを連携装置20の判定部24へと送信してから、ステップS4へと進む。

【0041】

ステップS3において、推定部31で画像に加えて測位情報も受信している場合には、点群記憶部32に記憶されている点群の全体のうち、測位情報の３次元位置に閾値判定で近いと判定される一部分の点群のみを、照合の対象として限定するようにしてもよい。

【0042】

ステップS4では、連携装置20の判定部24において、ステップS3で推定部31から送信された位置及び向きの推定結果の成否を判定してから、ステップS5へと進む。

【0043】

判定部24に関して既に説明した通り、推定結果の成否は、推定部31で得た位置及び姿勢の推定結果が閾値判定で失敗と判定されているか否かのみに基づくものとして、この推定部31の（自動）推定結果をそのまま判定結果として利用してもよいし、推定部31の推定結果が成功であったとしてもさらに、端末10のユーザへの確認を求めたうえで、UI部13を介して得られるユーザ判断も反映したものを判定結果として利用してもよい。

【0044】

ステップS5では、ステップS4での判定部24による判定結果を前述したデータD1の形式で判定結果記憶部23に対して新たに記憶させることで判定結果記憶部23での記憶内容（データD1の蓄積）を更新したうえで、ステップS6へと進む。

【0045】

ステップS6では、ステップS4で判定した推定結果の成否による場合分けが行われ、推定結果が正しい（推定に成功している）結果であった場合にはステップS7へと進み、推定結果が間違っている（推定に失敗している）結果であった場合にはステップS8へと進む。

【0046】

ステップS7では、推定結果（成功判定された位置及び向きの推定結果）を、UI部13を介して端末10のユーザへと通知してから、ステップS1へと戻る。（なお、ステップS4において、判定部24がユーザフィードバックを得るために既に推定結果をユーザに対してUI部13より通知済みである場合は、重複した通知となってしまうため、ステップS7での通知を省略してよい。）

【0047】

ステップS8では、推定結果が失敗であったため再度の推定を行うべく、判定部24が、VPSサーバ30において追加推定が可能であるかを判定してから、ステップS9へと進む。追加推定が可能であるか否かの判定は、ステップS1での１回の測位及び撮影に応じた推定処理の所定上限回数を設定しておいて判定してもよいし、VPSサーバ30において当該端末10のユーザによる推定処理の上限数に到達しているか否かや、当該端末10のユーザがVPSサーバ30を利用する際の課金量が所定の上限値に到達しているか否か等に従って、ルールベースで判定してもよい。

【0048】

ステップS9では、ステップS8での追加推定の可能性の判定が肯定であったか否定であったかによって場合分けが行われ、肯定（追加推定が可能）の場合にはステップS2へと戻り、否定（追加推定が不可能）の場合にはステップS10へと進む。

【0049】

なお、ステップS9から戻ったステップS2においては、推定結果が失敗であったようなVPSサーバ30は候補から除外したうえで、決定部22が処理（１）～（３）により別途のVPSサーバ30を決定すればよい。

【0050】

ステップS10では、推定結果（失敗であった旨）を、UI部13を介して端末10のユーザへと通知してから、ステップS1へと戻る。（なお、ステップS4において、判定部24がユーザフィードバックを得るために既に推定結果（推定部31では成功判定した推定結果）をユーザに対してUI部13より通知済みである場合（この場合、ユーザフィードバックとして失敗である旨が返信されている）は、重複した通知となってしまうため、ステップS10での通知を省略してよい。）

【0051】

以上の図４のフローは、ある１つの端末10に注目したものであるが、実際には複数ユーザの各々の端末10について、共通の連携装置20において、図４のフローが実施されることとなる。従って、判定結果記憶部23には、様々なローカルエリアに対応して、VPS測位に成功したVPSサーバ30での情報が多数、前述したデータD1の形で蓄積されていくこととなり、このように充分に蓄積された判定結果記憶部23の情報を利用することで、連携装置20では精度よく、VPS測位を行うことが可能なVPSサーバ30を決定することが可能となる。

【0052】

図５は、図１の構成のローカルエリアLにおいて、図４のフローを実施した場合の動作例を示す図であり、縦軸下方向が時間進行を表し、横軸方向がVPSサーバ100内での情報の送受信の流れを表している。手順p1（ステップS1が肯定判定となる例）として、端末10で測位及び撮影を行い、この結果を連携装置20へと送信する。手順pA1として、連携装置20がサーバ30Aに決定し、手順pA2としてサーバ30Aにおいて位置及び向きの推定を行い、手順pA3においてこの推定結果の成否を判定するが失敗であったと判定される。（なお、手順pA3では端末10とサーバ20との間に双方向矢印が描かれているが、これは前述した通りの、サーバ30Aの推定結果が成功であったがユーザに確認を求める実施形態を適用する場合の情報のやりとりを表すものであり、確認を求めない実施形態では省略することができ、必須の処理ではない。次の手順pB3における双方向矢印も同様である。）これは、ステップS3でサーバ30Aに決定したうえで、ステップS4→S5→S6→S8→S9→S2と進む例である。

【0053】

再度、手順pB1として、連携装置20がサーバ30Bに決定（失敗したサーバ30Aを除外して決定）し、手順pB2としてサーバ30Bにおいて位置及び向きの推定を行い、手順pB3においてこの推定結果の成否を判定するが失敗であったと判定される。これは、ステップS3でサーバ30Bに決定したうえで、ステップS4→S5→S6→S8→S9→S2と進む例である。

【0054】

再度、手順pC1として、連携装置20がサーバ30Cに決定（失敗したサーバ30A,30Bを除外して決定）し、手順pC2としてサーバ30Cにおいて位置及び向きの推定を行い、手順pC3においてこの推定結果の成否を判定し、成功であったと判定され、推定結果が端末10のユーザに通知される。

【0055】

この図５の例は、３つのサーバ30A,30B,30Cのうち正解（正しく位置及び向きを推定できるもの）がサーバ30Cであるにもかかわらず、２回ほど間違えて決定している例であるが、前述の通り、連携装置20の判定結果記憶部23において正解の事例が蓄積されて行くにつれて、連携装置20ではより精度よく、VPS測位を行うことが可能なVPSサーバ30を決定することが可能となる。（正解の事例の蓄積が少ない際は、図５の例のように間違う可能性もあるが、正解事例が蓄積されることでこのような間違いは少なくなる。）

【0056】

以上、本実施形態によれば、隣接したり一部重複したりしているローカルエリアに関してVPS測位が可能な複数のVPSサーバ30が複数存在し、ユーザサイドで誤差を伴って取得されるGNSS等の測位情報では適切なVPSサーバ30を自動決定できない状況であっても、連携装置20においてこのような状況における正解事例を蓄積することで、適切なVPSサーバ30を自動決定することが可能となる。

【0057】

特に、VPSサーバ30を利用する際に、ユーザの端末10側に利用料が課せられる状況や、利用の上限数があるような場合に、本実施形態による自動決定は好適である。また、VPSサーバ30の側においても、自身が地図情報（3D点群情報）を有していないような不適切なリクエストを受信する回数が削減されることにより、無駄な処理を減らすことが可能となる。また、各々のVPSサーバ30がそれぞれ異なる事業者によって運営され、VPSサーバ30での内部処理や地図情報の詳細等が不明な場合（VPSサーバ30の内部処理や地図情報等の一部または全部がブラックボックス化されており端末10のユーザや連携装置20の運営者に対してこれら情報等が非公開となる場合）や、地図情報が公開可能であったとしても複雑であるような場合であっても、本実施形態による自動決定により、無駄なリクエストが発生することを抑制することが可能となる。

【0058】

以下、種々の補足的事項や追加的事項に関して説明する。

【0059】

（Ａ） 決定部22の（１）の処理においてエリア記憶部21を照合した結果、測位部11で得た測位情報に該当する地図情報を有するようなVPSサーバ30が１つしか存在しなかった場合は、（２）の処理では判定結果記憶部23を照合することなく、当該１つのVPSサーバ30を単一の候補サーバとして決定すればよい。決定部22の（１）の処理においてエリア記憶部21を照合した結果、測位部11で得た測位情報に該当する地図情報を有するようなVPSサーバ30が１つも存在しなかった場合は、（２）及び（３）の処理を省略し、端末10のユーザに対して、適切なVPSサーバ30が存在しないという原因でVPS測位を行うことが不可能である旨を通知するようにすればよい。これらのいずれの場合も、判定結果記憶部23に対して判定結果を新たに記憶する処理（図４のステップS5の処理）は省略してよい。

【0060】

（Ｂ） 以上の説明では、決定部22の（２）の処理において、適切なVPSサーバ30を１つだけ決定する場合を想定した。この想定は、図２の模式例に示されるように、複数のVPSサーバ30がカバーしている地図情報の範囲がローカルエリア内で近接しているが、重複していない場合を前提としている。この前提を設けない場合、例えば、図２の模式例において、サーバ30Aは屋内エリアLA及び屋外エリアLBの地図情報を有し、サーバ30Bは屋外エリアLBの地図情報を有し、サーバ30Cは屋内エリアLC及び屋外エリアLBの地図情報を有するとする場合、すなわち、屋外エリアLBに関して３つのサーバ30A,30B,30Cのいずれも地図情報を有しており、測位情報の提供が可能となる場合の実施形態も可能である。

【0061】

この場合はすなわち、VPS測位範囲（保有する地図情報の範囲）の少なくとも一部が重複している複数のVPSサーバ30が存在する場合であり、同程度に適切となるVPSサーバ30が複数存在しうることになるため、次のような実施形態が可能である。まず、決定部22では、所定数の範囲内で、複数の適切なVPSサーバ30を決定し、これら複数のVPSサーバ30の全てまたは一部に撮影された画像を送信することにより位置及び向きを問合せる。次に、判定部24では、これら複数のVPSサーバ30から受信した位置及び向きの推定結果を判定結果として判定結果記憶部23へと保存し、且つ、受信した複数の推定結果のうち、推定成功と判定された結果に対して統計処理（例えば平均化）を行って、最終的な位置及び向きの推定結果として、端末10のUI部13へ送信するようにしてもよい。あるいは、推定成功となった複数の推定結果のうち、VPSサーバ30における推定精度が最高となる１つの結果のみを端末10に送信（及び判定結果記憶部23に記憶）してもよいし、推定精度による重みづけ平均された結果を端末10へと送信（及び判定結果記憶部23に記憶）してもよい。これにより、ユーザは、短時間で精度の高い推定結果を取得できるようになる。

【0062】

上記の通り、地図情報が重複しうる場合にも適用可能な実施形態は、決定部22が決定するVPSサーバ30が１つのみではなく複数となりうることも許容することによって可能となる。具体的には、決定部22の（２）の処理において、候補のVPSサーバ30の各々の成功画像クラスタと撮影画像との類似度判定を行い、最類似となる１つのVPSサーバ30に決定するのではなく、類似度が閾値以上となる全てまたは一部のVPSサーバ30に決定すればよい。（また、類似度が閾値以上となるVPSサーバ30が１つも存在しなかった場合、（Ａ）の場合と同様に、決定部22では該当なしとして決定すればよい。）

【0063】

（Ｃ） 決定部22の（２）の処理においては、候補のVPSサーバ30の各々の成功画像クラスタと撮影画像との類似度判定を行うものとしたが、追加的な実施形態としてさらに、候補のVPSサーバ30の各々の失敗画像クラスタと撮影画像との非類似度判定も行うようにしてよく、成功画像クラスタとの類似度（類似するほど値が大きい）と、失敗画像クラスタとの非類似度（類似しないほど値が大きい）と、の重みづけスコアにより、類似度のみで決定する場合と同様に決定することができる。失敗画像クラスタを構成する各画像は、データD1の形式で記憶されている情報のうち、判定部24での判定結果が失敗であった画像として得ることができる。

【0064】

（Ｄ） 本発明の各実施形態のVPSシステム100は、様々な事業者等によって運営されうる各々のVPSサーバ30の内部処理等が、端末10や連携装置20の側から見た際にブラックボックス化されていても、動作可能である。（ただし、エリア記憶部21に記憶しておく、各々のVPSサーバ30がカバーする概略的な地図情報の範囲の情報は必要となる。）各々のVPSサーバ30では、端末10において撮影された画像（及び測位情報）を受信し、位置及び向きの推定結果（及び推定精度など）を返信すればよい。推定部31での個別の推定アルゴリズムや点群記憶部32で記憶しておく詳細な3D点群情報などはブラックボックス化されていてもよく、各々のVPSサーバ30ごとに異なるアルゴリズム等が実装されていてもよい。

【0065】

（Ｅ） 決定部22において成功画像クラスタとの類似度判定等に基づいて、画像送信して測位を依頼する対象となるVPSサーバ30を決定した後に、このVPSサーバ30における測位処理の負荷を低減させることが可能となるように、次の（Ｅ１），（Ｅ２）のような追加処理を行うようにしてもよい。

【0066】

（Ｅ１） 決定部22では、撮影部11より受け取った画像（「現在画像」とする）を、決定されたVPSサーバ30に関して判定結果記憶部23で記憶されている成功画像クラスタ（当該クラスタに所属する各画像を「過去画像」とする）に対して検索し、現在画像に類似すると判定される１つ以上の過去画像を決定し、この過去画像に関して、前述のデータD1として紐づけられている位置及び向きの情報（過去時点においてVPSサーバ30の推定部31で推定に成功したものとして記憶されている位置及び向きの情報）を取得し、VPSサーバ30の推定部31に対して、現在画像（及び現在の測位部11の概略的な測位情報）に追加で、この過去画像の位置及び向きの情報も送信する。

【0067】

なお、現在画像と過去画像との類似判定には、VPSサーバ30を決定した際と同様の画像特徴等を用いればよい。

【0068】

（Ｅ２） 推定部31では、決定部22から追加で送信された過去画像の位置及び向きの情報を利用することにより、点群記憶部32に記憶されている3D点群の全体を、現在画像の位置及び向きの推定対象とするのではなく、過去画像（１つ以上の場合、少なくとも１つの過去画像）の位置及び向きに近いと判定される一部分の3D点群のみを、現在画像の位置及び向きの推定対象として利用する。

【0069】

すなわち、この追加処理により、推定部31では点群記憶部32で記憶しておく3D点群の全部ではなく一部のみを、現在画像との照合対象として限定することが可能となるため、推定部31の測位処理の負荷を低減することが可能となる。（Ｄ）として説明したように、各々のVPSサーバ30の内部処理の詳細はブラックボックス化されていてもよいが、この追加処理を行う場合は、推定対象となる撮影画像による端末10の位置及び向きが、（Ｅ１）の処理により送信された過去画像の位置及び向きの近傍にある旨の指示情報を明示的に受け取ることにより、VPSサーバ30の推定部31において（Ｅ２）の負荷低減処理を行うことが可能となる。

【0070】

（Ｆ） 図７は、一般的なコンピュータ装置70におけるハードウェア構成の例を示す図である。VPSシステム100における端末10、連携装置20及びVPSサーバ30はそれぞれ、このような構成を有する１台以上のコンピュータ装置70として実現可能である。なお、２台以上のコンピュータ装置70で端末10、連携装置20又はVPSサーバ30を実現する場合、ネットワーク経由で処理に必要な情報の送受を行うようにしてよい。コンピュータ装置70は、所定命令を実行するCPU（中央演算装置）71、CPU71の実行命令の一部又は全部をCPU71に代わって又はCPU71と連携して実行する専用プロセッサとしてのGPU（グラフィックス演算装置）72、CPU71（及びGPU72）にワークエリアを提供する主記憶装置としてのRAM73、補助記憶装置としてのROM74、通信インタフェース75、ディスプレイ76、マウス、キーボード、タッチパネル等によりユーザ入力を受け付ける入力インタフェース77、撮影部12をハードウェアとして構成するカメラ78及び測位部11をハードウェアとして構成するセンサ79と、これらの間でデータを授受するためのバスBSと、を備える。

【0071】

端末10、連携装置20及びVPSサーバ30の各機能部は、各部の機能に対応する所定のプログラムをROM74から読み込んで実行するCPU71及び／又はGPU72によって実現することができる。なお、CPU71及びGPU72は共に、演算装置（プロセッサ）の一種である。ここで、表示関連の処理が行われる場合にはさらに、ディスプレイ76が連動して動作し、データ送受信に関する通信関連の処理が行われる場合にはさらに通信インタフェース75が連動して動作する。点群処理システム100による処理結果等はディスプレイ76で表示して出力してよい。UI部13をハードウェアとして構成するのは入力インタフェース77であってよい。

【符号の説明】

【0072】

100…VPSシステム、10…端末、11…測位部、12…撮影部、13…UI部、20…連携装置、21…エリア記憶部、22…決定部、23…判定結果記憶部、24…判定部、30…VPSサーバ、31…推定部、32…点群記憶部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】