(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-03-23
(54)【発明の名称】マップ画像を提供するためのサービスを定義するための方法およびシステム
(51)【国際特許分類】
G06F 16/909 20190101AFI20220315BHJP
G09B 29/00 20060101ALI20220315BHJP
H04L 67/02 20220101ALI20220315BHJP
【FI】
G06F16/909
G09B29/00 Z
H04L67/02
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2021545382
(86)(22)【出願日】2020-01-30
(85)【翻訳文提出日】2021-09-29
(86)【国際出願番号】 AU2020000011
(87)【国際公開番号】W WO2020160591
(87)【国際公開日】2020-08-13
(32)【優先日】2019-02-04
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
(71)【出願人】
【識別番号】521113184
【氏名又は名称】ニアマップ オーストラリア ピーティーワイ リミテッド
(74)【代理人】
【識別番号】100107766
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ゼヴァカ,イゴル
(72)【発明者】
【氏名】コクラン,サイモン ジョン
【テーマコード(参考)】
2C032
5B175
【Fターム(参考)】
2C032HB05
5B175DA03
5B175FB03
5B175JA02
(57)【要約】
APIまたはAPIテンプレートを生成するシステムまたは方法。API、たとえばURLは、WMSまたはWMTSサーバーによって呼び出されると、一つまたは複数の関心領域(AOI)の集合および一つまたは複数の日付範囲のためのメタデータを生成させる。メタデータは、サーベイのデータセットへのアクセスを提供する。APIは、AOIの集合および日付範囲において新たなサーベイが追加されたときはいつでもデータセットが自動的に更新されるという意味で動的である。APIテンプレートはTMSサービスのためであり、中身を入れられると、AOIの集合および日付範囲における何らかのタイル化されたマップを表示させる。
【特許請求の範囲】
【請求項1】
マップ画像を得ることを可能にするようサーバー処理システムを動作させる方法であって、当該方法は:
クライアント処理システムから、一つまたは複数の領域の集合の定義を受け入れる段階であって、各領域は、関連する関心領域(「AOI」)および一つまたは複数の関連する日付を有する、段階と;
一つまたは複数の領域の前記集合についてのAPIまたは前記集合についてのAPIテンプレートを生成して、前記クライアント処理システムに送る段階であって、送られるAPIまたはAPIテンプレートの効果は、前記集合のそれぞれの領域のそれぞれのAOIが、サーベイ・プロバイダーによって利用可能にされた新たなコンテンツを有するときはいつでも自動的に更新される、段階とを含み、
(a)前記APIが送られ、該送られたAPIをマップ・サービス・クライアントによって使用することにより、前記マップ・サービス・クライアントがマップ・サービスのためのマップ・サービス・サーバーに要求し、該要求に応答して前記マップ・サービス・サーバーから、各領域について一つまたは複数のそれぞれのマップ表示APIを提供するメタデータを取得し、提供されたそれぞれのマップ表示APIを使用してマップ画像を取得する機構が提供される、または
(b)前記APIテンプレートが送られ、該送られたAPIテンプレートに中身を入れることにより、前記集合内の一つまたは複数のそれぞれの領域のための一つまたは複数のタイル化されたマップ表示APIを形成し、該一つまたは複数のマップ表示APIは、タイル化されたマップを提供するサービスからタイル化されたマップ画像を得るために使用可能であり、
前記APIまたはAPIテンプレートを使用することは、前記マップ表示APIのために、前記集合の領域における前記新たなコンテンツのいずれかを表示する能力を提供する、
方法。
【請求項2】
受け入れられる定義は、一つまたは複数の領域の前記集合についてのユーザー定義されたサービスの定義であり、サービスについてのユーザー指定された命名規約(「サービス命名規約」)を使用して前記ユーザー定義されたサービスについてのサービス名を含み、
前記ユーザー定義されたサービスの各領域は、名前を付けられた関連付けられた関心領域(AOI)をもち、
前記一つまたは複数の関連する日付は、単一の関連付けられた日付または関連付けられた日付の範囲である、
請求項1に記載の方法。
【請求項3】
前記APIが送られ、前記マップ・サービス・クライアントはウェブ・マップ・サービス(WMS)クライアントであり、前記マップ・サービス・サーバーはWMSサーバーであり、送られたAPIを前記WMSクライアントによって使用することによって、前記WMSクライアントがメタデータをWMSサーバーから要求し、該要求に応答して前記WMSサーバーから取得するための機構が提供され、該メタデータは、各領域について一つまたは複数のそれぞれのマップ表示APIを提供し、提供されたそれぞれのマップ表示APIを使用してマップ画像を得る、
請求項1または2に記載の方法。
【請求項4】
送られるAPIは、GetCapabilities要求として前記WMSクライアントによって使用可能なURLの形である、請求項3に記載の方法。
【請求項5】
それぞれのマップ表示APIは、WMS GetMap要求についてのそれぞれのURLである、請求項3または4に記載の方法。
【請求項6】
前記WMSクライアントの機能は前記クライアント処理システムにおいて実行される、請求項3ないし5のうちいずれか一項に記載の方法。
【請求項7】
前記APIが送られ、前記マップ・サービス・クライアントはウェブ・マップ・タイル・サービス(WMTS)・クライアントであり、前記マップ・サービス・サーバーはWMTSサーバーであり、送られたAPIを前記WMTSクライアントが使用することによって、前記WMTSクライアントがメタデータを前記WMTSサーバーから要求し、該要求に応答して前記WMTSサーバーから取得するための機構が提供され、前記メタデータは、各領域について一つまたは複数のそれぞれのタイル化されたマップ表示APIを提供し、提供されたそれぞれのタイル化されたマップ表示APIを使用して、タイル化されたマップ画像を得る、請求項2または3に記載の方法。
【請求項8】
前記APIは、GetCapabilities要求として前記WMTSクライアントによって使用可能なURLの形である、請求項7に記載の方法。
【請求項9】
それぞれのタイル化されたマップ表示APIは、WMTS GetTile要求についてのそれぞれのURLである、請求項7または8に記載の方法。
【請求項10】
前記WMTSクライアントの機能は前記クライアント処理システムにおいて実行される、請求項7ないし9のうちいずれか一項に記載の方法。
【請求項11】
前記メタデータがXML構造の形である、請求項3ないし10のうちいずれか一項に記載の方法。
【請求項12】
前記APIテンプレートが前記サーバー処理システムから送られ、前記マップ・サービス・クライアントはタイル・マップ・サービス(TMS)クライアントであり、前記マップ・サービス・サーバーはTMSサーバーであり、受け入れられたAPIテンプレートに中身を入れることにより、前記集合内の一つまたは複数のそれぞれの領域のための一つまたは複数のタイル化されたマップ表示APIを形成し、該一つまたは複数のタイル化されたマップ表示APIは、タイル化されたマップ画像を得るために使用可能である、請求項1または2に記載の方法。
【請求項13】
送られるAPIテンプレートはURLテンプレートの形である、請求項12に記載の方法。
【請求項14】
それぞれのタイル化されたマップ表示APIは、TMSタイル化されたマップ表示要求についてのそれぞれのURLである、請求項12または13に記載の方法。
【請求項15】
前記TMSクライアントの機能は前記クライアント処理システムにおいて実行される、請求項12ないし14のうちいずれか一項に記載の方法。
【請求項16】
各領域が一つまたは複数のユーザー定義された関連するフィルタを有しており、該フィルタは、前記クライアント処理システムによって前記サーバー処理システムに送られる、請求項18ないし33のうちいずれか一項に記載の方法。
【請求項17】
処理システムの一つまたは複数のプロセッサで実行されたときに請求項1ないし16のうちいずれか一項に記載の方法を実行する命令を有する非一時的な機械可読媒体。
【請求項18】
一つまたは複数のプロセッサおよび記憶サブシステムを有する処理システムであって、前記記憶サブシステムは、少なくとも一つのプロセッサまたは前記プロセッサによって実行されたときに請求項1ないし16のうちいずれか一項に記載の方法を実行する命令を有する、処理システム。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願
本開示は、2019年2月4日に出願された米国仮特許出願第62/800569号の優先権の利益を主張するものであり、その内容は参照により本明細書に組み込まれる。参照による組み込みが認められない管轄区域においては、出願人は、前記米国仮特許出願第62/800569号の内容の一部または全部を本明細書への付録として追加する権利を留保する。
【0002】
発明の分野
本発明は、地理情報システム(geographic information system、GIS)、特に、一組のサーベイのマップを表示するためのスクリプトを自動的に決定するためのシステムおよび方法に関する。ここで、前記一組のサーベイは一つまたは複数のユーザー定義された関心領域および一つまたは複数の日付の範囲によって制限され、そのような一組のサーベイが、スクリプトが使用されるたびに自動的に更新される。
【背景技術】
【0003】
ウェブ・マップ・サービス(Web Map Service、WMS)は、サーベイ、たとえばフォトマップ(写真による地図および一つまたは複数のレイヤーの集合)を地理情報システム(GIS)ツールに統合するために使用されることができる、地理的参照(geo-referenced)マップ画像を提供するための、一般的に使用されるオープン地理空間コンソーシアム(Open Geospatial Consortium、OGC)の標準ウェブ・プロトコルである。WMSサーバーは、いくつかの異なるサーバーからのデータの使用を許容し、クライアントがカスタマイズされたマップを構築できるもとになる諸マップ・サーバーのネットワークの生成を可能にする。WMSサーバーは、HTTPプロトコルを使用するAPIを介してクライアントと対話する。すなわち、それらのAPIはURLの形である。WMS準拠のサーバーは、少なくとも次の2つの型のWMSリクエストを扱うことができる:WMSサーバーの情報に関してXML文書の形でメタデータを返すGetCapabilities〔機能取得〕要求と、ユーザーのニーズに応じてマップの画像を返すGetMap〔マップ取得〕要求である。WMSサーバーは、画像を求める各クライアント要求のためにマップ画像を生成する。本発明の文脈において、WMSサーバーとは、たとえプロトコルがOGC WMS標準に厳密に準拠していなくても、本明細書に記載されるリポジトリを含むWMS様サーバーを意味する。
【0004】
タイル化されたマップまたはタイル・マップ(ラスタまたはベクトル)は、ネットワーク、たとえばインターネットを通じて、何十もの個々に要求された画像タイルをシームレスに結合することによって、たとえばブラウザにおいて、表示されるマップである。
【0005】
WMS標準は、クライアントが任意の領域を要求することを許容する。WMSサーバーに結合されているクライアントがタイルを望む場合、クライアントはタイル化されたパターンにおいてその諸要求をすることができるが、WMSサーバーはそうなっていることを知るすべがない。サーバーがマップを自分自身の諸タイルとして記憶する場合、サーバーはクライアントにタイル配置がどうなっているかを知らせるすべはない。
【0006】
ウェブ・マップ・タイル・サービス(Web Map Tile Service、WMTS)は、インターネットを通じて、事前にレンダリングされた、またはランタイムで計算された地理的参照マップ・タイルを提供するためのOGCプロトコルである。タイル(典型的には、256×256)は、キャッシュされるか、または事前にレンダリングされるため、WMTSは、領域の画像をずっと高速に提供することができる。ここで、たとえば、事前レンダリングは別々にまたは並列に行われる。
【0007】
WMTSでは、機能構造は、TileMatrixSetを記述する。これは、TileMatrix(ズームレベル)、行番号(X次元)、列番号(Y次元)のような量子化された整数座標の集合であり、これらが、タイル化された画像を要求するために使用されることができる。画像タイルは、常に同じ地理的領域を参照する3つの整数座標を使用して要求される。WMTSでは、GetMap要求が任意のバウンディングボックスを記述できるWMSとは異なり、WMTS GetTile要求はTileMatrixSet仕様に従って行われる。要求のバウンディングボックスは、GetTile座標から計算できる。
【0008】
より以前の、広く採用されていたタイル・マップ用のプロトコルは、タイル・マップ・サービス(Tile Map Service、TMS)と呼ばれ、オープンソース地理空間財団(Open Source Geospatial Foundation、GeoOS)によるもので、WMTSと同様に、インターネットを通じて、事前にレンダリングされた、またはランタイムで計算された地理的参照マップ・タイルを提供するために使用される。これはWMTSほど複雑な仕様ではないが、タイル化されたマップを指定するためには同様のパラメータを使用する。TMSは、特定のグリッドに整列するバウンディングボックスを要求することをクライアントに求めるのではなく、諸タイルのための整数インデックスを使用する。TMSに類似した別のサービスは、オープンストリートマップ(OpenStreetMap)であり、これはここでは、TMSの変形と見なされる。
【0009】
ユーザーは、個々のWMS、TMS、またはWMTSサービスを作成しうる。そのようなサービスは、名前、レイヤー名フォーマット、および一つまたは複数の関心領域(area of interest、AOI)の集合を有することができる。クライアント、たとえば、WMS、TMS、またはWMTSクライアントは、WMS、TMS、またはWMTSサーバーにそれぞれ結合され、ディスプレイ上にマップ画像を表示することができるクライアント・システムである。
【0010】
本発明の文脈において、WMSクライアントとは、たとえ使用されるプロトコルがOGC WMS標準に厳密に準拠していなくても、WMS様サーバーに結合するWMS様クライアントを意味する。同様に、TMSまたはWMTSクライアントとは、たとえ使用されるプロトコルがTMS仕様またはOGC WMTS標準に厳密に準拠していなくても、それぞれTMS様またはWMTS様サーバーに結合するTMS様またはWMTS様クライアントを意味する。
【0011】
地理情報システム(GIS)におけるデータセットは、典型的には、一度作成されたら変わらないという意味で静的である。空間的データを複製することなく、また、一つまたは複数のユーザー定義された関心領域および日付/時刻に限定された、各サービスの基礎になるデータのリポジトリへのアクセスを提供するサービスを作成できることが有利であろう。また、データセットが動的であるGISを有することも有利であろう。動的とは、GISに追加された、前記一つまたは複数のユーザー定義された関心領域および日付/時刻内の新しいサーベイまたはタイル、たとえば、一つまたは複数の日付/時間の範囲内のある新しい特定の時刻において撮影された、ある位置での航空写真があるときはいつでも自動的に更新されるという意味においてである。次にユーザーが前記日付/時刻範囲内で前記特定の位置にアクセスするときに、前記新たに追加されたサーベイがユーザーのために自動的に利用可能となることが有利であろう。
【図面の簡単な説明】
【0012】
以下の図面および関連する説明は、本開示の実施形態を例示するために提供され、本発明の範囲を限定するものではなく、範囲は特許請求の範囲によって定義される。添付の図面との関連で参酌される以下の詳細な説明を参照することにより、これらの諸側面および利点がよりよく理解されるにつれて、本開示の諸側面および利点はより容易に理解されるようになるであろう。
【0013】
【
図1】本発明のいくつかの実施形態が動作しうる要素を有する例示的なシステムの簡略化された概略図を示す。
【0014】
【
図2】本発明のいくつかの実施形態により、たとえばユーザー指定されたサービスのためのURLの形の、ユーザーのためにAPIを得るための方法の簡略化されたフローチャートを示す。
【0015】
【
図3】本発明の何らかの実施形態により、
図2の例示的なフローチャートで生成されたAPIが、ユーザーのためのXML機能応答を生成するためにどのように使用されることができるかを示す、諸方法の簡略化されたフローチャートを示す。XML機能応答は、マップ画像を得るための各領域についてのそれぞれのURLを含む。
【0016】
【
図4】本発明のある実施形態により、WMSクライアント・システムのスクリーン上に新しい表示を生成するためにGetMap要求がどのように実装されるかを示す、諸方法の簡略化されたフローチャートを示す。
【0017】
【
図5】本発明のある実施形態により、WMTSクライアント・システムのスクリーン上に新しい表示を生成するためにGetTile要求がどのように実装されるかを示す、諸方法の簡略化されたフローチャートを示す。
【発明を実施するための形態】
【0018】
概観
本明細書に記載されているのは、GISサービスおよびそのためのAPI、たとえばURLを生成するためのシステムおよび方法である。該APIは、呼び出されたときに、そのための一つまたは複数の関心領域(AOI)および一つまたは複数の日付範囲の集合についての機能API(capabilities API)、たとえば機能XML(capabilities XML)を生成させ、それがサーベイのデータセットへのアクセスを提供する。APIによってアクセスされるサーベイのデータセットは動的であり、動的とは、GISに追加された、AOIおよび日付範囲の前記集合内の特定の位置における新たなサーベイ、たとえば、前記データ範囲の1つの中の新しい特定の時刻において撮影されたAOI内のある領域の空中写真があったときはいつでも自動的に更新されるという意味においてである。それにより、ユーザーが次にその特定の位置にアクセスするときに、その追加されたサーベイがユーザーにとって利用可能である。日付は日付と時刻の組み合わせであってもよく、そのため同じ日だが異なる「日付」に2つのサーベイがあってもよい。
【0019】
本発明の実施形態を使用すると、ユーザーは、たとえば一つまたは複数の日付範囲(日付は時刻の組み合わせを含んでいてもよい日付〔日時〕である)における一つまたは複数のAOIの、ユーザーによって所望されるデータのみを含む動的なWMS、TMS、および/またはWMTSサービスを作成することができる。本発明のある実施形態を使用して、サーバーは、マップ・サービス(サーベイ・プロバイダー)にアクセスして所望されるAOI(単数または複数)および日付(単数または複数)範囲(単数または複数)のみを抽出し、それを記憶し、記憶されたデータおよびその周囲のサービスを提供する。ある実施形態では、WMSサービスは、URLの形であってもよいAPIを含む。そのようなAPIは、本発明の実施形態において生成される。
【0020】
本発明のある実施形態は、WMS標準に少なくとも部分的に準拠するWMSサーバーが使用されうるように、標準的なWMS機能(またはWMS様の機能)を使用する。本発明の別の実施形態は、少なくとも部分的にWMTS標準に準拠するWMTSサーバーが使用されうるように、標準的なWMTS機能(またはWMTS様の機能)を使用する。さらに別の実施形態は、TMS機能を使用する。いくつかの実施形態は、WMSサーバー、WMTSサーバー、およびTMSマップ・プロバイダーのうちの2つ以上の組み合わせとして動作することができる組み合わされたサーバーを含む。他の実施形態は、当業者には明らかであろう。
【0021】
実施形態の第1の集合は、マップ画像を得ることを可能にするようクライアント処理システムを動作させる方法を含む。本方法は、下記を含む:
【0022】
一つまたは複数の領域の集合の定義をユーザーから受け入れる段階であって、各領域は、関連した関心領域(「AOI」)および一つまたは複数の関連した日付を有する、段階;
【0023】
ネットワークによってクライアント処理システムに結合されたサーバー処理システムに、前記一つまたは複数の領域の受け入れられた定義に関する情報を送信する段階;
【0024】
サーバー処理システムから、一つまたは複数の領域の集合についてのAPI、または前記集合についてのAPIテンプレートを受け入れる段階であって、前記APIまたはAPIテンプレートはサーバーで決定され、受け入れたAPIは、前記集合のそれぞれの領域のそれぞれのAOIがサーベイ・プロバイダーによって利用可能にされた新しいコンテンツをもつときはいつでも自動的に更新される。
【0025】
(a)APIが受け入れられ、該受け入れたAPIをマップ・サービス・クライアントによって使用することにより、マップ・サービス・クライアントがマップ・サービスのためのマップ・サービス・サーバーから要求し、該要求に応答してマップ・サービス・サーバーから、各領域について一つまたは複数のそれぞれのマップ表示APIを提供するメタデータを取得し、提供されたそれぞれのマップ表示APIを使用してマップ画像を取得する機構が提供される、または
【0026】
(b)APIテンプレートが受け入れられ、受け入れられたAPIテンプレートに中身を入れることにより、集合内の一つまたは複数のそれぞれの領域のための一つまたは複数のタイル化されたマップ表示APIを形成する。該一つまたは複数のタイル化されたマップ表示APIは、タイル化された地図を提供するサービスからタイル化されたマップ画像を得るために使用可能である。
【0027】
第1のバージョンでは、サーバー処理システムから受け入れられるのはAPIであり、マップ・サービス・クライアントはウェブ・マップ・サービス(WMS)クライアントであり、マップ・サービス・サーバーはWMSサーバーである。そのような第1のバージョンでは、受け入れられたAPIをWMSクライアントが使用することによって、WMSクライアントがメタデータをWMSサーバーから要求し、該要求に応答してWMSサーバーから取得するための機構が提供される。該メタデータは、各領域について一つまたは複数のそれぞれのマップ表示APIを提供し、提供されたそれぞれのマップ表示APIを使用してマップ画像を得る。受け入れられたAPIは、GetCapabilities要求としてWMSクライアントによって使用可能なURLの形であってもよく、メタデータは、XML構造の形であってもよく、それぞれのマップ表示APIは、WMS GetMap要求についてのそれぞれのURLであってもよい。
【0028】
第2のバージョンでも、サーバー処理システムから受け入れられるのはAPIである。そのような第2のバージョンでは、マップ・サービス・クライアントはウェブ・マップ・タイルサービス(WMTS)・クライアントであり、マップ・サービス・サーバーはWMTSサーバーである。受け入れられたAPIをWMTSクライアントが使用することによって、WMTSクライアントがメタデータをWMTSサーバーから要求し、該要求に応答してWMTSサーバーから取得するための機構が提供される。該メタデータは、各領域について一つまたは複数のそれぞれのタイル化されたマップ表示APIを提供し、提供されたそれぞれのタイル化されたマップ表示APIを使用して、タイル化されたマップ画像を得る。受け入れられたAPIは、GetCapabilities要求としてWMTSクライアントによって使用可能なURLの形であってもよく、メタデータは、XML構造の形であってもよく、それぞれのタイル化されたマップ表示APIは、WMTS GetTile要求についてのそれぞれのURLであってもよい。
【0029】
第3のバージョンでは、サーバー処理システムから受け入れられるのはAPIテンプレートであり、マップ・サービス・クライアントはタイル・マップ・サービス(TMS)クライアントであり、マップ・サービス・サーバーはTMSサーバーである。受け入れられたAPIテンプレートに中身を入れることにより、集合内の一つまたは複数のそれぞれの領域についての一つまたは複数のタイル化されたマップ表示APIを形成する。該一つまたは複数のタイル化されたマップ表示APIは、タイル化されたマップ画像を得るために使用可能である。送られたAPIテンプレートは、URLテンプレートの形であってもよく、それぞれのタイル化されたマップ表示APIは、TMSタイル化されたマップ表示要求についてのそれぞれのURLである。
【0030】
実施形態の第2の集合は、マップ画像を得ることを可能にするようサーバー処理システムを動作させる方法を含む。本方法は、下記を含む:
【0031】
クライアント処理システムから、一つまたは複数の領域の集合の定義を受け入れる段階であって、各領域は、関連する関心領域(「AOI」)および一つまたは複数の関連する日付を有する、段階;
【0032】
一つまたは複数の領域の前記集合についてのAPIまたは前記集合についてのAPIテンプレートを生成して、前記クライアント処理システムに送る段階であって、送られるAPIまたはAPIテンプレートはサーバーで決定され、送られるAPIは、前記集合のそれぞれの領域のそれぞれのAOIが、サーベイ・プロバイダーによって利用可能にされた新たなコンテンツを有するときはいつでも自動的に更新される、段階。
【0033】
(a)APIが送られ、該送られたAPIをマップ・サービス・クライアントによって使用することにより、マップ・サービス・クライアントがマップ・サービスのためのマップ・サービス・サーバーから要求し、該要求に応答してマップ・サービス・サーバーから、各領域について一つまたは複数のそれぞれのマップ表示APIを提供するメタデータを取得し、提供されたそれぞれのマップ表示APIを使用してマップ画像を取得する機構が提供される、または
【0034】
(b)APIテンプレートが送られ、送られたAPIテンプレートに中身を入れることにより、集合内の一つまたは複数のそれぞれの領域のための一つまたは複数のタイル化されたマップ表示APIを形成する。該一つまたは複数のマップ表示APIは、タイル化された地図を提供するサービスからタイル化されたマップ画像を得るために使用可能である。
【0035】
いくつかのバージョンでは、受け入れられる定義は、一つまたは複数の領域の前記集合についてのユーザー定義されるサービスの定義であり、サービスについてのユーザー指定された命名規約(「サービス命名規約」)を使用するユーザー定義されたサービスについてのサービス名を含む。ユーザー定義されるサービスの各領域は、名前を付けられた関連付けられたAOIをもち、前記一つまたは複数の関連する日付は、単一の関連付けられた日付または関連付けられた日付の範囲である。
【0036】
第1のバージョンでは、送られるのはAPIであり、マップ・サービス・クライアントはウェブ・マップ・サービス(WMS)クライアントであり、マップ・サービス・サーバーはWMSサーバーである。そのような第1のバージョンでは、送られたAPIをWMSクライアントが使用することによって、WMSクライアントがメタデータをWMSサーバーから要求し、該要求に応答してWMSサーバーから取得するための機構が提供される。該メタデータは、各領域について一つまたは複数のそれぞれのマップ表示APIを提供し、提供されたそれぞれのマップ表示APIを使用してマップ画像を得る。送られたAPIは、GetCapabilities要求としてWMSクライアントによって使用可能なURLの形であってもよく、メタデータは、XML構造の形であってもよく、それぞれのマップ表示APIは、WMS GetMap要求についてのそれぞれのURLであってもよい。
【0037】
第2のバージョンでも、送られるのはAPIである。そのような第2のバージョンでは、マップ・サービス・クライアントはウェブ・マップ・タイルサービス(WMTS)・クライアントであり、マップ・サービス・サーバーはWMTSサーバーである。送られたAPIをWMTSクライアントが使用することによって、WMTSクライアントがメタデータをWMTSサーバーから要求し、該要求に応答してWMTSサーバーから取得するための機構が提供される。該メタデータは、各領域について一つまたは複数のそれぞれのタイル化されたマップ表示APIを提供し、提供されたそれぞれのタイル化されたマップ表示APIを使用して、タイル化されたマップ画像を得る。送られたAPIは、GetCapabilities要求としてWMTSクライアントによって使用可能なURLの形であってもよく、メタデータは、XML構造の形であってもよく、それぞれのタイル化されたマップ表示APIは、WMTS GetTile要求についてのそれぞれのURLであってもよい。
【0038】
第3のバージョンでは、送られるのはAPIテンプレートであり、マップ・サービス・クライアントはタイル・マップ・サービス(TMS)クライアントであり、マップ・サービス・サーバーはTMSサーバーである。送られたAPIテンプレートに中身を入れることにより、集合内の一つまたは複数のそれぞれの領域についての一つまたは複数のタイル化されたマップ表示APIを形成する。該一つまたは複数のタイル化されたマップ表示APIは、タイル化されたマップ画像を得るために使用可能である。送られたAPIテンプレートは、URLテンプレートの形であってもよく、それぞれのタイル化されたマップ表示APIは、TMSタイル化されたマップ表示要求についてのそれぞれのURLである。
【0039】
実施形態の諸集合の上記の各バージョンのいくつかでは、WMSクライアント、WMTSクライアント、またはTMSクライアントの機能は、クライアント処理システムにおいて実行されてもよい。
【0040】
実施形態の諸集合の上記の各バージョンのいくつかでは、各領域は、クライアント処理システムによってサーバー処理システムに送信される一つまたは複数のユーザー生成された関連フィルタを有してもよい。
【0041】
上記の実施形態の諸集合では、受け入れられる定義は、一つまたは複数の領域の前記集合についてのユーザー定義されるサービスの定義であってもよく、サービスについてのユーザー指定された命名規約(「サービス命名規約」)を使用するユーザー定義されたサービスについてのサービス名を含む。ユーザー定義されるサービスの各領域は、名前を付けられた関連付けられたAOIを有してもよく、前記一つまたは複数の関連する日付は、単一の関連付けられた日付または関連付けられた日付の範囲でありうる。
【0042】
具体的な実施形態は、処理システムの一つまたは複数のプロセッサ上で実行されたときに方法を実行する命令を含む非一時的な機械可読媒体を含む。種々の実施形態において、本方法は、方法実施形態の上記の諸集合の任意のバージョンに記載されている。よって、方法実施形態のどの集合かに依存して、処理システムはクライアント処理システムであってもよく、または処理システムはサーバー処理システムであってもよい。
【0043】
具体的な実施形態は、一つまたは複数のプロセッサおよび記憶サブシステムを備える処理システムを含み、記憶サブシステムは、少なくとも1つまたは前記のプロセッサによって実行されるときに方法を実行する命令を含んでいる。種々の実施形態において、本方法は、上記の方法実施形態の任意のバージョンに記載されているようなものである。よって、処理システムはクライアント処理システムであってもよく、または処理システムはサーバー処理システムであってもよい。
【0044】
具体的な実施形態は、これらの側面、特徴、または利点のすべてを提供してもよく、一部を提供してもよく、またはいずれも提供しなくてもよい。具体的な実施形態は、一つまたは複数の他の側面、特徴、または利点を提供してもよく、そのうちの一つまたは複数は、本願の図面、説明、および特許請求の範囲から当業者に容易に明白となりうる。
【0045】
用語集
以下は、本明細書および特許請求の範囲において使用され、地理情報システム(GIS)においても一般的に使用される用語の集合である。
【0046】
関心領域(AOI)-ユーザーにとって関心のある地理的領域。典型的には名前をもち、バウンディングポリゴンによって定義される。
【0047】
領域〔エリア〕-典型的には、それぞれの名前と日付または日付の範囲とをもつAOI。日付には時刻を含んでいてもよい。
【0048】
API:オペレーティングシステム、アプリケーション、または他のサービスの機能またはデータにアクセスするアプリケーションの作成を可能にする機能および手順の集合。本発明の文脈においては、APIは、個々のWMSサービスまたはWMTSサービスを呼び出すための機構である(WMSおよびWMTSについては下記参照)。
【0049】
バウンディングボックス(bボックス)-対角線の両端にある2点によって定義される長方形の地理的領域。長方形の他の頂点は暗示されるまたは容易に計算される。もちろん、4つの頂点すべてが明示的に指定されてもよい。
【0050】
バウンディングポリゴン-点の集合によって定義される任意の多角形の形状。
【0051】
日付(Date)-日付は時系列的な日付であり、時刻を含んでいてもよい。そのため、本開示の文脈では、同じ日の2つの時刻が2つの異なる日付を定義することがある。
【0052】
空間的交わり-2つの領域の空間的交わりは、両方の領域に共通する領域である。
【0053】
サービス-ユーザーが領域を定義するために作成しうる個々のWMSまたはWMTSサービス(WMSおよびWMTSについては下記参照)。サービスは、名前、レイヤー名フォーマット、一つまたは複数の領域(AOIおよび日付範囲)の集合をもちうる。本発明のいくつかの実施形態では、サービスは、それについて、URLの形で機能APIを生成していてもよい。
【0054】
サービス・リポジトリ:ユーザーが作成したサービスの、データベース(DB)。
【0055】
サーベイ-地理的領域(地域)の単一の捕捉。典型的には1日以内に捕捉される。サーベイは、関連する地域名、州、国、バウンディングポリゴン、捕捉の日付、および可能性としてはサーベイに関する他のメタデータを有していてもよい。
【0056】
サーベイ・リポジトリ-サーベイのデータベース。各サーベイはメタデータとして:関連地域名、州、国、バウンディングポリゴン、捕捉の日付、および可能性としては他のメタデータを有していてもよい。サーベイ・プロバイダーは、サーベイを、サーベイ・リポジトリにとって利用可能にする。
【0057】
タイル-地理的領域の事前レンダリングされた、たとえば256×256ピクセルの画像。マップは、タイルを結合することによって構成されてもよく、そのため、タイル化されたマップは、ズームレベルを示す数、たとえば、1辺あたりのタイルの数によって指定されてもよい。タイル化されたマップは、関連する領域名、州、国、X座標(たとえば整数)、Y座標(たとえば整数)、捕捉の日付、および可能性としてはタイル化されたマップに関する他のメタデータを有していてもよい。
【0058】
タイル・リポジトリ-タイルのデータベース。タイルは、サーベイ・プロバイダーによって、タイル・リポジトリにとって利用可能にされる。
【0059】
投影-地球上の点を平面地図上の点に系統的に変換すること。1つの例は、ウェブ・メルカトル投影法である。本発明のいくつかの実施形態では、投影は、名前、コード、たとえば、空間的基準系識別子(Spatial Reference System Identifier、SRID)コード、bボックス、および変換パラメータの集合を有する。SRIDコードは、典型的には、SRS(spatial reference system[空間的基準系])またはCRS(coordinate system reference[座標系基準])パラメータを介してWMSサーバーに渡される。この文脈において、SRID、SRS、およびCRSは、交換可能に使用されうる。
【0060】
投影リポジトリ-名前、コード、およびバウンディングボックスによって定義される空間的投影のデータベース。
【0061】
ウェブ・マップ・サービス(Web Map Service、WMS)-サーベイ、たとえばフォトマップ(写真による地図および一つまたは複数のレイヤーの集合)を地理情報システム(GIS)ツールに統合するために使用されることができる、地理的参照(geo-referenced)マップ画像を提供するための、オープン地理空間コンソーシアム(Open Geospatial Consortium、OGC)の標準ウェブ・プロトコル。本発明の文脈において、WMSは、OGC WMSまたはWMS様サービスを意味し、使用されるプロトコルが厳密にOGC WMS標準に準拠していなくてもよい。
【0062】
WMSサーバー-WMSサーバーは、いくつかの異なるサーバーからのデータの使用を許容し、クライアントがそこからカスタマイズされたマップを構築できるもとになる諸マップ・サーバーのネットワークの作成を可能にする。WMSサーバーは、HTTPプロトコルを使用するAPIを介してクライアントと対話する。すなわち、APIはURLの形である。多くの場合、WMSサーバーは、共通ゲートウェイインターフェース(Common Gateway Interface、CGI)プログラムである。WMS仕様は、いくつかの要求タイプを定義し、そのそれぞれについて、問い合わせパラメータおよび関連する挙動の集合を定義する。WMSサーバーは、画像を求める各クライアント要求についてマップ画像を生成する。WMS準拠のサーバーは、少なくとも次の2つの型のWMS要求を扱うことができる:WMSサーバーの関連する情報のメタデータを返すGetCapabilities〔機能取得〕(返されるメタデータはXML文書の形)と、ユーザーのニーズに応じてマップの画像を返すGetMap〔マップ取得〕である。本発明の文脈において、WMSサーバーは、たとえプロトコルがOGC WMS標準に厳密に準拠していなくても、本明細書に記載されるリポジトリを含むWMSまたはWMS様サーバーを意味する。
【0063】
WMSクライアント-WMSクライアント・システム、または単に「WMSクライアント」とは、WMSサーバーに結合され、ディスプレイ上にマップ画像を表示することができるクライアント・システムである。用語「WMSクライアント」はまた、クライアント処理システム上で動作するソフトウェアであって、動作時に、クライアント処理システムをWMSクライアント・システムとして行動させるソフトウェアを指してもよい。WMSクライアントという用語がシステムを指すのか、ソフトウェアを指すのかは、文脈から明らかであろう。本発明の文脈において、WMSクライアントとは、使用されるプロトコルがOGC WMS標準に厳密に準拠していなくても、WMS様サーバーに結合されるWMSまたはWMS様クライアントを意味する。
【0064】
ウェブ・マップ・タイル・サービス(Web Map Tile Service、WMTS)-インターネットを通じて、事前にレンダリングされた、またはランタイムで計算された地理的参照マップ・タイル(典型的には256×256)を提供するためのOGCプロトコル。典型的には256×256のタイルは、キャッシュされるか、または事前にレンダリングされる。たとえば、事前レンダリングは別々にまたは並列に行われる。本発明の文脈において、WMTSは、使用されるプロトコルがOGC WMS標準に厳密に準拠していなくても、OGC WMTSまたはWMTS様サービスを意味する。
【0065】
WMTSサーバー-WMTSサーバーは、いくつかの異なるサーバーからのデータの使用を許容し、クライアントがそこからカスタマイズされたマップを構築できるもとになる諸マップ・サーバーのネットワークの作成を可能にする。WMTSサーバーは、HTTPプロトコルを使用するAPIを介してクライアントと対話する。すなわち、APIはURLの形である。多くの場合、WMTSサーバーは、共通ゲートウェイインターフェース(Common Gateway Interface、CGI)プログラムである。WMTS仕様は、いくつかの要求タイプを定義し、そのそれぞれについて、問い合わせパラメータおよび関連する挙動の集合を定義する。WMTSサーバーは、タイル化されたマップ画像を求める各クライアント要求についてタイル化されたマップ画像を生成する。WMTS準拠のサーバーは、少なくとも次の2つの型のWMTS要求を扱うことができる:WMTSサーバーの関連する情報のメタデータを返すGetCapabilities〔機能取得〕(返されるメタデータはXML文書の形)と、GetTile〔タイル取得〕である。GetTileは、より大きなマップ画像を構築するためにアプリケーションが合成しうるGetTile要求によって指定された領域内の単一のタイル画像を返す。本発明の文脈において、WMTSサーバーは、たとえプロトコルがOGC WMS標準に厳密に準拠していなくても、本明細書に記載されるリポジトリを含むWMTSまたはWMTS様サーバーを意味する。
【0066】
WMTSクライアント-WMTSクライアント・システム、または単に「WMTSクライアント」とは、WMTSサーバーに結合され、ディスプレイ上にマップ画像を表示することができるクライアント・システムである。用語「WMTSクライアント」はまた、クライアント処理システム上で動作するソフトウェアであって、動作時に、クライアント処理システムをWMTSクライアント・システムとして行動させるソフトウェアを指してもよい。WMTSクライアントという用語がシステムを指すのか、ソフトウェアを指すのかは、文脈から明らかであろう。本発明の文脈において、WMTSクライアントとは、使用されるプロトコルがOGC WMTS標準に厳密に準拠していなくても、WMTS様サーバーに結合されるWMTSまたはWMTS様クライアントを意味する。
【0067】
タイル・マップ・サービス(Tile Map Service、TMS)-オープンソース地理空間財団(Open Source Geospatial Foundation、GeoOS)によるプロトコルで、WMTSと同様に、インターネットを通じて、事前にレンダリングされた、またはランタイムで計算された地理的参照マップ・タイルを提供するために使用され、タイル化されたウェブ・マップのための仕様である。これはWMTSほど複雑な仕様ではないが、タイル化されたマップを指定するために同様のパラメータを使用する。TMSは、特定のグリッドに整列するバウンディングボックスを要求することをクライアントに要求するWMTSとは異なり、諸タイルのための整数インデックスを使用する。TMSはGetCapabilities要求を定義したり、機能応答を提供したりしない。しかしながら、タイル化された画像を表示するためのURLをいかにして構築するかについては、人間が読むことができる文書が存在する。本発明の文脈において、TMSとは、OSGeo TMSまたはOSGeo仕様に厳密に準拠していなくてもよいTMS様のサービスを意味する。
【0068】
詳細な説明
例示的なシステム・アーキテクチャー
図1は、本発明の実施形態が動作する要素を有する例示的なシステム100の簡略化された概略図を示している。要素101、131、151および171は、ネットワーク191、たとえばインターネットを介して結合されて示されている。多くのバージョンにおいて、要素101および131は、1つの処理システム101に結合される。
【0069】
システム100は、一つまたは複数のプロセッサ152および記憶153を含むサーバー処理システム151を含む。記憶153は、実行されたときに、本発明の実施形態のサーバー側の諸側面を実行し、ある実施形態では、WMSサーバーの機能を実行するプログラム命令155を含む。代替的な実施形態では、別個の処理システムがWMSサーバーとして動作する。
【0070】
ユーザーは、クライアント処理システム101上で、サーバー処理システム151と対話することができる。クライアント処理システム101は、一つまたは複数のプロセッサ102、ディスプレイ107、記憶サブシステム103(メモリを含む)、およびユーザーがクライアント処理システム101に情報を入力することを可能にするサブシステムを形成する一つまたは複数のユーザー入力装置106を含む。クライアント処理システム101によって実行される機能は、記憶サブシステム103に記憶された命令108に記述されている。ユーザーは、それぞれのユーザー・インターフェース(UI)を介してクライアント処理システム101を操作することができる。UIは、任意的に、ブラウザ、他のネットワーク資源ビューア、専用アプリケーション、または他の入力手段を使用して、クライアント処理システム101を介して呈示される。一般に、人(ユーザー)は、特定のアイテムの上でホバリングする、特定のアイテムをポインティングする、もしくは特定のアイテムをクリックすること、マイクロフォンを介して口頭で命令を与えることのうちの少なくとも1つによってクライアント処理システムに情報を入力してもよい。人は、タッチスクリーンに触れてもよく、人は他の仕方で情報を提供してもよい。よって、一つまたは複数のユーザー・インターフェースが、ユーザー処理システム101上に呈示されてもよい。システム101は、ラップトップコンピュータ、デスクトップコンピュータ、ユーザー端末、タブレットコンピュータ、スマートフォン、または他の端末タイプであってもよい。ユーザー入力装置は、一つまたは複数のタッチスクリーン、マイクロフォン、タッチパッド、キーボード、マウス、スタイラス、カメラ等を含んでいてもよい。
【0071】
ユーザーは、WMS、WMTS、および/またはTMSクライアント処理システム131(WMS、WMTS、および/またはTMSクライアント133)上でサーバー処理システム151と対話してもよい。該クライアント処理システムは、一つまたは複数のプロセッサ132、ディスプレイ137、記憶サブシステム133(メモリを含む)、およびユーザーが画像を表示し、表示された画像内に一つまたは複数の幾何学的フィーチャーをポイントしたり可能性としては描いたりすることを可能にするサブシステムを形成する一つまたは複数のユーザー入力装置136を含む。本発明のある実施形態におけるサーバー処理システム・プログラム命令156は、サーバー処理システム151がWMSサーバーとして行動することを可能にする命令を含む。別の実施形態では、プログラム命令156は、サーバー処理システム151がWMTSサーバーとして行動することを可能にする命令を含む。さらに別の実施形態では、プログラム命令156は、サーバー処理システム151がWMTSサーバーおよびWMTSサーバーとして行動することを可能にする命令を含む。さらに別の実施形態では、プログラム命令156は、サーバー処理システム151がTMSサーバーとして行動することを可能にする命令を含む。WMS、WMTS、および/またはTMSクライアント処理システム131によって実行される機能は、記憶サブシステム133に記憶された命令138に記述されている。WMSクライアントは、WMSサーバーと対話することができ、OGC WMS規格に準拠するシステムである。OGC WMSおよびWMTS(またはTMS)標準は、それぞれ、ある実施形態ではインターネット(HTTP)を介してオンライン・マップおよびタイル化されたマップを取得するために使用される。マップは、ウェブサイトからリンクされることも、プロフェッショナルGISクライアントを用いてナビゲートされることも、あるいはモバイル装置上で使用されることもできる。マップ画像(またはタイル化された諸画像)を必要とする任意のアプリケーションは、マップ(またはタイル化された諸マップ)を取得するためにOGC WMS(またはWMTSまたはTMS)標準を使用できる。また、これらは広く受け入れられている業界標準であるため、ほとんどすべてのマップ生成または使用ソフトウェアは、OGC WMSまたはWMTS、またはOSGeo TMSが「通じる」。それにより、基礎となるソフトウェア実装に関係なく、いくつかの源からのマップを組み合わせることができる。よって、WMSクライアントは、任意の処理システム上で動作するWMSクライアント・ソフトウェアを指すことができる。ユーザーは、それぞれのユーザー・インターフェース(UI)を介してWMSクライアント処理システム131を操作することができる。典型的には、ブラウザ、他のネットワーク資源ビューア、専用アプリケーション、または他の入力手段を使用して、クライアント処理システム131を介してWMSクライアントUIが呈示される(そして人の命令が受領されうる)。よって、同様に、WMTSクライアントは、任意の処理システム上で動作するWMTSクライアント・ソフトウェアを指すことができる。ユーザーは、それぞれのユーザー・インターフェース(UI)を介して、WMTSクライアント処理システム131を操作することができる。典型的には、ブラウザ、他のネットワーク資源ビューア、専用アプリケーション、または他の入力手段を使用して、クライアント処理システム131を介して、WMTSクライアントUIが呈示される(そして人の命令が受領されうる)。よって、同様に、TMSクライアントは、任意の処理システム上で動作するTMSクライアント・ソフトウェアを指すことができる。ユーザーは、それぞれのユーザー・インターフェース(UI)を介してTMSクライアント処理システム131を操作することができる。典型的には、ブラウザ、他のネットワーク資源ビューア、専用アプリケーション、または他の入力手段を使用して、クライアント処理システム131を介して、TMSクライアントUIが提示される(そして人の命令が受領されうる)。
【0072】
いくつかの実施形態では、WMS、WMTSおよび/またはTMSクライアント・ソフトウェアは、記憶103内の命令108の一部としてクライアント処理システム101に組み込まれてもよく、それにより、WMS、WMTSおよび/またはTMSクライアント・システム131がクライアント処理システム101に組み込まれる。
【0073】
ある実施形態では、サーベイは、カメラ・システム(図示せず)によって捕捉され、画像記憶サーバー171に、または他の実施形態では本発明の実施形態が動作するサーバー処理システム151上に記憶される。いくつかのバージョンでは、カメラ・システムは、カメラ識別情報、カメラ位置、画像についてのタイムスタンプ、カメラの向き/回転、カメラ解像度、および他のカメラ・パラメータ(カメラ・モデルと総称される)などのカメラ・パラメータを各サーベイとともに含んでいてもよい。いくつかの実施形態では、画像177は、画像記憶サーバー171にすでに記憶されているものと想定される。
【0074】
画像記憶サーバーは、一つまたは複数のプロセッサと、メモリおよび一つまたは複数の他の記憶媒体を含む記憶サブシステム177とを含む。一つまたは複数の画像が、たとえばネットワーク191と、ネットワーク・インターフェースのような入力ポートとを介して、サーバー処理システム151に受け入れられる。
【0075】
いくつかの実施形態では、画像記憶サーバー171は、事前にレンダリングされた画像タイルを記憶する。
【0076】
図1に示される要素は、単にシステム・アーキテクチャーの一例をなすものである。いくつかの実施形態では、サーバー処理システムは、たとえば一つまたは複数のウェブエージェントとしてウェブにおいて動作してもよい。よって、そのようなエージェントはプログラム命令(155として示される)を含み、そのようなプログラミング命令は機械上で動作するが、機械は、必ずしも、
図1に示されるような個々の処理システムとして分割されるわけではない。さらに、機械は、クラウド内でインスタンス化された仮想マシンであってもよい。同様に、画像記憶サーバーは、クラウド内のウェブ・サービスとして提供されてもよい。
【0077】
他の実施形態では、画像記憶サーバー171の機能は、画像に関する捕捉された画像およびメタデータ177を記憶するために、記憶サブシステム153を使用してサーバー処理システム151に組み込まれてもよい。
【0078】
サービス、サーベイ、領域、および投影の典型的な属性
下記の表は、本発明のある実施形態において、サービス(以下に記載されるようなユーザー定義されるサービス)、サーベイ、領域(AOIおよび日付範囲)、および投影について、どのような属性が使用されるかを示す。もちろん、他の実施形態は、より多数の、またはより少数の属性を使用することがある。
【表1】
【0079】
タイル化されたマップ
本発明のいくつかの実施形態は、タイル化されたマップを提供するためのものである。
【0080】
WMS標準は、クライアントが任意の地域を要求することを許容する。クライアントがタイルを望む場合、クライアントはタイル化されたパターンにおいてその要求を作成することができるが、サーバーはそのようなことが起きていることを知るすべはない。サーバーがマップを自分自身のタイルとして保存していても、クライアントにタイル配置がどうなっているかを知らせるすべはない。WMTS標準は、マップではなくタイル化されたマップを提供できるサービスの定義を与える。WMTSにおけるCapabilities構造は、TileMatrixSetを記述する。これは、TileMatrix(ズームレベル)、行番号(X次元)、列番号(Y次元)などの量子化された整数座標の集合であり、これらは、GetTile要求を用いてタイル化された画像を要求するために使用できる。GetTile要求における3つの整数座標は、常に同じ地理的領域を参照する。GetMap要求が任意のbボックスを記述できるWMSとは異なり、WMTSのGetTile要求はTileMatrixSet仕様に従って作成される必要がある。要求のバウンディングボックスは、GetTile座標から計算できる。
【0081】
TMS標準は、タイル化されたマップのための、ずっと単純なプロトコルである。TMSは、クライアントが特定のグリッドに整列するバウンディングボックスを要求する必要があるのではなく、タイルのための整数インデックスを使用する。
【0082】
いくつかの例示的なフローチャート
図2は、本発明のWMS実施形態による、ユーザーによって命令されるクライアント・システム101における方法と、クライアント・システム101に結合されたサーバー・システム151における方法とを含む諸方法200の簡略化されたフローチャートを示している。これらの方法は、ユーザー指定されたサービスのための、URLの形でのAPIを、ユーザーのために取得するように動作する。ここで、いくつかの領域(各領域は単一の名前を付けられた関連したAOIである)についてのユーザー指定されたサービス命名規約、一つまたは複数の日付の関連した範囲、および任意的には一つまたは複数の他のユーザー生成された関連したフィルタを使用する。ユーザー指定されたサービスについてのこのようにして得られたURLは、WMSクライアントによって、GetCapabilities要求として使用可能であり、結合されたWMSサーバーが、前記領域についての、たとえばXML文書の形でのメタデータを返すことができるようにする。該メタデータが、WMSクライアントがマップ画像を得ることを可能にする。この方法は、動的でユーザー指定可能なサービスをユーザーに提供する。動的とは、結果として得られるAPIが、新しい個別のAOIが、サーベイ・プロバイダーによって利用可能にされた新しいコンテンツをもつときはいつでも、AOI(単数または複数)内の任意のサーベイが自動的に更新されることを提供することを意味する。このAPIをWMSクライアントとともに使用すると、WMSクライアントについて、機能応答が提供される。該機能応答はたとえば、提供されたGetMap URLを使用してマップ画像を取得するために、各領域(それぞれの名前を付けられたAOIと関連する日付範囲)についてそれぞれのAPIを(GetMapについてのそれぞれのURLとして)含む前記XMLである。
【0083】
このフローチャートはまた、WMTSの実施形態にも適用可能であり、またTMSの実施形態にも適用可能である。
【0084】
203では、クライアント・システム101は、ユーザーから、(たとえば定義として)一つまたは複数の領域の集合を記述する情報を受け入れる。各領域は、関連した関心領域(「AOI」)および一つまたは複数の関連した日付を有する。ある実施形態では、該情報は、いくつかの領域について、ユーザー生成されたサービス名と、ユーザー定義された命名規約との形であり、各領域は、単一のユーザー命名されたAOIと、関連する日付範囲を有する。203は、クライアント・システムがこの情報をサーバー・システム151に送信することを含む。
【0085】
ここから先、このフローチャートは、該情報がサービスの定義の形であると想定する。
【0086】
サーバー・システム151では、205において、サーバー・システムは、一意的な識別子(「サービスID」)をもつ新しいサービス定義を受け入れ、サーバー処理システム151の記憶サブシステム153内に維持されているサーバー・システムのサービス・リポジトリ156内に保存する。サービス・リポジトリ156は、ユーザー定義されたサービスの集合を含む。
【0087】
クライアント・システムによって送信される前記いくつかの領域のそれぞれについて、207において、サーバー・システム151は、初期には最初の、後には次のユーザー供給される領域名、その領域の関連するユーザー命名されたAOI、その領域の関連する日付範囲、およびその領域の他の関連するユーザー定義されたフィルタのいずれかを受け入れる。あるバージョンでは、ステップ207は、209において、すべての領域が受け入れられたかどうかをチェックすることによって繰り返される。もしそうでなければ、システムは反復207する。これは、次のユーザー供給される領域名、関連するAOI、関連する日付範囲、他のユーザー定義されたフィルタを受け入れることを含む。
【0088】
ひとたびすべてのユーザー指定された領域がサービスのために受け入れられたら、サーバー・システムは、211において、たとえばユーザーのためのURLの形で、APIを生成する。該APIは、たとえばWMSまたはWMTSサーバーからのXML文書の形のメタデータを得るために、たとえばWMS(またはWMTS)クライアントにおいてGetCapabilities要求としてユーザーが使用することができる。APIは、213でクライアント・システムに送信される。
【0089】
クライアント・システムは、215において、API、たとえば、GetCapabilities要求をWMSまたはWMTSサーバーに送信するために使用可能なURLを受け入れる。いくつかの実施形態では、クライアント・システムはまた、クライアント・システムのユーザーに対して該URLを表示する。
【0090】
WMTS実施形態およびTMS実施形態の最初の部分も、相違点を修正して、
図2のフローチャートに従う。WMTS実施形態は、図に含まれている。WMTS実施形態はまた、WMS実施形態を含んでいてもよく、すなわち、同じシステムがWMSまたはWMTSのいずれかで動作してもよい。たとえば、211において、WMTSの場合、サーバー・システムはAPI、たとえば、WMTS GetCapabilities要求として使用可能なURLを生成する。TMSの場合、211において、サーバー・システムはAPIのためのテンプレートを生成し、たとえば、関連情報を入れられたときにタイル化された画像を得るために直接使用可能なURLテンプレートを生成する。
【0091】
図3は、本発明のWMS(またはWMTS)実施形態により、方法300の簡略化されたフローチャートを示している。このフローチャートは、API,たとえば方法200において生成されたURLが、メタデータ、たとえば結合されているWMS(またはWMTS)サーバーからのユーザーのためのXML機能応答を生成するために、GetCapabilities要求として、WMS(またはWMTS)クライアントにおいてどのように使用されるかを示す。XML機能応答は、たとえばWMS(またはWMTS)クライアント・システム上で、マップ画像を得るために、各領域についてのそれぞれのURLを含む。方法300は、WMSクライアント、たとえばWMSクライアント131、およびWMSサーバー、たとえばサーバー・システム151に含まれるようなWMSサーバーにおいて実行される方法ステップを含む。WMTS実施形態は、当業者には明らかであろう差異の詳細を除いて、同様である。
【0092】
303では、WMS(またはWMTS)クライアント131は、ユーザーからAPI、たとえば
図2に示されるフローチャートに従って生成されたURLを受け入れる。305では、WMS(またはWMTS)クライアントは、このAPI、たとえばURLを、GetCapabilities要求として、サーバー処理システム151内のWMS(またはWMTS)サーバーに送信する。
【0093】
307では、WMS(またはWMTS)サーバーは、API,たとえばURL(GetCapabilities要求)を受け入れ、該API(GetCapabilities要求)からサービスIDを抽出する。サービスIDは、サービスAOI、関連する日付範囲、およびサービス・リポジトリ156内の任意の関連付けられたフィルタを照会するために309において使用される。ひとたびAOIが利用可能になると、311において、各AOIについて、最初のAOIから始めて、すべてのAOIが照会されるまで次のAOIに続き、WMSサーバー、たとえば、サーベイ・プロバイダーのものが、記憶サブシステム153内のサーベイ・リポジトリ156内に維持されているサーベイを照会して、AOIと交わり、AOIの関連する日付範囲内の日付を有し、AOIに関連付けられた他のフィルタがあればそれにマッチするサーベイを見出す。このようにして、本発明のある側面は、ひとたびユーザーが203において、いくつかの領域についてのユーザー生成されたサービス名およびユーザー定義された命名規約を指定したら(各領域は、単一のユーザー命名されたAOIおよび関連する日付範囲を有する)、本発明の方法およびシステムは、動的に、ユーザー指定された基準を満たす現在利用可能なサーベイを得ることができるということである。同様に、ステップ313において、WMSサーバーは、このAOIと交わるすべての投影について投影リポジトリに照会する。ステップ311および313は、すべてのAOIについて繰り返される。たとえば、ステップ315において、すべてのAOIについてのサーベイおよび投影が見出されているかどうかを確認するためにチェックが行われる。そうでない場合、ステップ311および313は、次のAOIについて繰り返され、それ以外の場合は、プロセスは次のステップ317に進む。
【0094】
次回には、
図2および
図3のプロセス(WMSおよびWMTS実施形態の場合)において、交わりのあるサーベイの集合および投影は、日付範囲および他の基準内に一つまたは複数の追加的なサーベイがあることがあり、以前に見出されたサーベイのいくつかがもはや利用可能でないという意味で、異なっていることがありうる。
【0095】
ステップ317では、方法およびサーバーは、命名規約を使って構造、たとえばツリー構造を構築する。サービス名をノードとし、AOI名をサービス名ノードの子とし、各AOI名について、そのAOIについてのレイヤー名がそのAOI名ノードの子とする。もちろん、ツリー構造以外の構造が使用されてもよい。このデータを使用して、ステップ319において、方法(およびシステム)は、ユーザーのためのXML機能応答、すなわち、マップ画像を得ることを可能にする各AOIについてのそれぞれのURLを含むXML機能応答を生成する。WMSサーバーは、XML機能応答をWMSクライアント131に送信する。
【0096】
321では、WMSクライアントはXML機能応答を受け入れて処理し、いくつかのバージョンでは、ユーザーがWMSクライアント上に表示するマップを選択できるようにするために、ツリー構造をユーザーに対して表示する。
【0097】
さらに、サーバーはレイヤー識別子からサービス識別子および領域識別子を抽出する。表示されるべき画像を要求することの一部として、本発明のある実施形態は、投影識別子を提供する。これは通常、クライアント・ソフトウェアにおいて一度設定され、WMSへのすべての要求はその投影を使用して行われる。
【0098】
WMSおよびWMTS実施形態を続けると、WMTS実施形態における
図2の方法によって提供されるAPIを使用することも、当業者には明らかであろう差異を修正して、
図3のフローチャートに従う。第1に、WMTS実装は、クライアント・システム131であってもよいWMTSクライアントに関わりうる。よって、ステップ303、305、および321は、たとえばネットワーク191(たとえば、インターネット)を介して、たとえばサーバー151内のWMTSサーバーに結合されるWMTSクライアントにおいて実行される。ブロック307、309、311、313、315、317、および319は、そのようなWMTSサーバーにおいて実行される。ステップ317において、構築されたツリー構造は、タイル化されたマップ・サービスのためのものである。319において生成された機能XMLは、整数座標のTileMatrixSetを記述するWMTS機能XMLである。
【0099】
WMTS実施形態は図に含まれる。WMTS実施形態はまた、WMS実施形態を含んでいてもよく、すなわち、同じシステムがWMSまたはWMTSのいずれかで動作してもよい。
【0100】
TMSは、GetCapabilities要求やXML機能応答は含まない。したがって、
図3のプロセスは適用できない。しかしながら、
図2に記載された方法200によって、タイル画像を表示するためのTMS APIのためのテンプレートの形で提供される情報で、ユーザーまたはクライアント・アプリケーションは、APIを構造化し、よってタイル化されたマップを得るのに十分な情報を有する。
【0101】
図4は、本発明のWMS実施形態により、GetMap要求がどのように実装されるかを示す方法400の簡略化されたフローチャートを示している。GetMapは、WMSクライアント・システム131のスクリーン上の新しい表示、たとえばズーム、パンなどが望まれるときはいつでも発生する。WMSクライアント131においては、ステップ321でツリー構造が表示される結果、403において、ユーザーはツリー構造からレイヤーを選択する。405では、WMSクライアントは、GetMap要求を実行するために、機能XMLにおいてGetMap URLを使用する。(サーバー・システム151における)WMSサーバーでは、407は、WMSサーバーがレイヤーについてのGetMap要求を受け入れ、GetMap要求の「サービス」および「領域」識別子、「レイヤー」識別子およびバウンディングボックスを抽出することを含む。409では、WMSサーバーは、AOIを取得するためにサービス・リポジトリ156に照会する。WMSサーバーは、411において、サーベイの属性、たとえばバウンディングポリゴンを取得するために、サーベイ・リポジトリ159に照会する。この情報は、413において、GetMap要求のサーベイ境界、AOI、およびbボックスの交わりに基づいてマップ画像を作成するために、WMSサーバーによって使用される。作成されたマップ画像は415においてWMSクライアントに送信される。
【0102】
WMSクライアント・システムでは、417は、WMSクライアントがマップ画像を受け入れ、ユーザーに対して表示することを含む。
【0103】
図5は、本発明のWMTS実施形態により、GetTile要求がどのように実装されるかを示す方法500の簡略化されたフローチャートを示す。GetTileは、WMTSクライアント・システム131のスクリーン上の新しいタイル化されたマップ表示、たとえばズーム、パンなどが望まれるときはいつでも発生する。WMTSクライアント131においては、ステップ321でツリー構造が表示される結果、503において、ユーザーはツリー構造からレイヤーを選択する。505では、WMTSクライアントは、GetTile要求を実行するために、機能XMLにおいてGetTile URLを使用する。GetTile要求は、「サービス」および「領域」ID、「レイヤー」IDおよびTileMatrixSet座標を含む。
【0104】
WMTSサーバーでは、サーバーは、レイヤーについてのGetTile要求を受け入れ、該要求の「サービス」および「領域」ID、「レイヤー」IDおよびタイル・マトリクス座標を抽出する。
【0105】
(サーバー・システム151における)WMTSサーバーでは、507は、WMTSサーバーがレイヤーについてのGetTile要求を受け入れ、GetTile要求の「サービス」および「領域」識別子、「レイヤー」識別子、およびTileMatrixSet座標を抽出することを含む。508は、TileMatrixSet座標をbボックスに変換することを含む。509では、WMTSサーバーは、AOIを取得するためにサービス・リポジトリ156に照会する。WMTSサーバーは、511において、タイル・リポジトリ(159において想定される)に照会して、サーベイの属性、たとえばバウンディングポリゴンを取得する。この情報は、513において、GetTile要求のサーベイ境界、AOI、およびbボックスの交わりに基づいてタイル画像を作成するために、WMTSサーバーによって使用される。作成されたタイル化されたマップ画像は、515においてWMTSクライアントに送信される。
【0106】
WMTSクライアント・システムでは、517は、WMTSクライアントがタイル化されたマップ画像をユーザーに受け入れて、ユーザーに対して表示することを含む。
【0107】
図5のフローチャートは、クライアントがTMSクライアント・システムであり、サーバー・システムがTMSサーバーであるTMSバージョンを扱うために、当業者によって容易に修正されうる。TMSはレイヤーをサポートしないので、
図5の表示方法は、ステップ505のTMS修正で始まる。この場合、
図2で提供されたAPIテンプレートは、WMTS GetTile要求に類似の要求をするために使用される。サーバー側では、指定されたレイヤーがないため、フローチャートの一部が簡略化されている。他の点では、TMSサーバー上での本方法は、TMSの限界を考慮しつつ、ほぼ、WMTSサーバーのためのステップに従う。
【0108】
このように、ユーザーは、
図2に示されるように、クライアント・システムで開始し、一つまたは複数のユーザー定義されたAOI/日付範囲の組み合わせのためのサービスを定義し、WMSおよびWMTSの場合には、たとえばURLの形のAPIを取得する。該APIは、その後、
図3により、WMSまたはWMTS準拠の第2のAPIを取得するためにWMSクライアントまたはWMTSクライアントを介してGetCapabilities要求として使用されることができる。該第2のAPIは、前記一つまたは複数のユーザー定義されたAOI/日付範囲の組み合わせ内で利用可能なサーベイをユーザーに対して表示することができる機能XMLの形である。ユーザーは、次いで、WMS端末またはWMTS端末上に表示するマップを選択することができる(
図3)。前記一つまたは複数のユーザー定義されたAOI/日付範囲の組み合わせ内で利用可能なサーベイに対する変更があれば該変更で自動的に更新された新しい機能XMLを生成するために、異なる時点において使用されることができる。それにより、前記一つまたは複数のAOI/日付範囲の組み合わせ内で新しく追加されたサーベイ内のマップ(単数または複数)が閲覧できるようになる。TMSの場合、ユーザーは、
図2に示されるようにクライアント・システムで開始し、一つまたは複数のユーザー定義されたAOI/日付範囲の組み合わせのためのサービスを定義し、APIのためのテンプレートを取得する。該テンプレートは、たとえば、中身を入れられたときにタイル化された画像(単数または複数)を表示できるURLテンプレートの形である。
【0109】
いくつかの実施形態では、サーバーは、WMS、TMS、およびWMTSのいずれか1つを使用して、事前にレンダリングされたタイルをサポートする。
【0110】
そのようなサーバーの1つは、GeoServer、Web Mapping Service-Cached(WMS-C)、またはGeoWebCacheを使用する、従来のWMSサーバーの前にキャッシュプロキシを含んでいてもよい。
【0111】
GeoServerは、OGCによって規定されたオープン規格を用いて、地理空間データを閲覧および編集することをユーザーに許容するJavaベースのサーバーである。
【0112】
Web Mapping Service-Cached(WMS-C)は、マップ・クライアントが既存のWMSサーバーからタイルを取得することができる何らかの手段を提供する。そのためには、画像がサーバー上、または中間位置にキャッシュされたり、あるいは望むなら完全に事前生成されることができる。WMS-C(Web Mapping Service-Cachedの場合と同様)は、制約されたプロファイルのWMSとして、中間的な点においてタイルがキャッシュされるおとを許容する。WMS-Cサービスは、所与の長方形の原点およびグリッドに整列されたバウンディングボックスのために、特定の諸スケールレベルでのみ画像を配信のでもよい。
【0113】
GeoWebCacheは、OGC Web Map Service(WMS)などの多様なソースに由来するマップ・タイルをキャッシュするために使用されるJavaウェブ・アプリケーションであり、さまざまなサービス・インターフェース(WMS-C、WMTS、TMS、Google Maps KML、Virtual Earthなど)を実装する。
【0114】
本稿では、サーバー・システムへの領域(単数または複数)を最初に定義することから返されるメタデータは、XML文書の形式であるが、代替的な実施形態では、たとえばJSONを使用して、異なるフォーマットがクライアント処理システムに返されてもよい。
【0115】
本明細書では、WMSおよび/またはWMTSに従って動作する方法、システム、および非一時的なコンピュータ読み取り可能媒体について説明したが、本発明の実施形態は、Google Maps KML、Virtual Earthなどの他の既知のサービス・インターフェースにも適用可能である。記載された方法、システム、および非一時的なコンピュータ読み取り可能媒体のいずれかを、他のそのような既知のサービスに適合させるように修正することは、当業者にとってはストレートなことであろう。当業者は不相応な実験を行うことなくそのような他の既知のサービス・インターフェースとともに本発明を製造し、使用することができる。
【0116】
一般
本明細書で使用されるところでは、日付範囲は、必ずしも日の粒度をもつ一つまたは複数の日付の範囲に限定されるものではなく、むしろ、日付および時刻の組み合わせの範囲であってもよい。したがって、日付範囲は、単一日付内の単一の日付および2つの時刻である可能性がある。
【0117】
特に断りのない限り、以下の議論から明らかなように、本明細書を通じて、「処理」、「コンピューティング」、「計算」、「決定」などの用語を使用する議論は、ホスト装置または計算システム、または同様の電子計算装置のアクションおよび/またはプロセスであって、電子的な量のような物理的な量として表わされるデータを操作および/または変換して、物理的な量として同様に表わされる他のデータにするものを指すことが理解される。
【0118】
同様に、用語「プロセッサ」は、たとえばレジスタおよび/またはメモリからの電子データを、該電子データを、たとえばレジスタおよび/またはメモリに記憶されうる他の電子データに変換するために処理する任意の装置または装置の一部分を指してもよい。
【0119】
本明細書に記載される方法論は、ある実施形態では、たとえばファームウェアまたはソフトウェアとしての機械読み取り可能な命令を受け入れる一つまたは複数のプロセッサによって実行可能である。該命令は、前記プロセッサの一つまたは複数によって実行されると、本明細書に記載の方法の少なくとも1つを実行する。そのような実施形態では、実行されるべきアクションを指定する一組の命令(逐次的またはそれ以外)を実行することができる任意のプロセッサが含まれてもよい。よって、一例はプログラマブルDSP装置である。別の例は、マイクロプロセッサまたは他のコンピュータ装置のCPU、またはより大きなASICの処理部分である。処理システムは、メインRAMおよび/またはスタティックRAMおよび/またはROMを含むメモリ・サブシステムを含んでいてもよい。構成要素間で通信するためのバスサブシステムが含まれてもよい。処理システムはさらに、たとえばネットワークによって無線またはその他の仕方で諸プロセッサが結合された、分散式の処理システムであってもよい。処理システムがディスプレイを必要とする場合、そのようなディスプレイが含まれてもよい。いくつかの構成の処理システムは、音声入力装置、音声出力装置、およびネットワーク・インターフェース装置を含んでいてもよい。よって、メモリ・サブシステムは、機械読み取り可能な非一時的媒体を含み、該媒体は、一つまたは複数のプロセッサによって実行されると、本明細書に記載された方法の一つまたは複数を実行させる一組の命令がコードされている、すなわち記憶されている。方法がいくつかの要素、たとえば、いくつかのステップを含む場合、特に断わりのない限り、そのような要素の順序付けは含意されないことに留意されたい。命令は、ハードディスク内に存在してもよく、あるいは、システムによる実行中、完全にまたは少なくとも部分的に、RAM内におよび/またはプロセッサ内の他の要素内に存在してもよい。よって、メモリおよびプロセッサはまた、命令を有する非一時的な機械読み取り可能媒体を構成する。
【0120】
さらに、非一時的な機械読み取り可能媒体は、ソフトウェア製品を形成することができる。たとえば、方法の一部を実行する、よって本発明のシステムまたは装置の全部または一部の要素を形成する命令が、ファームウェアとして格納されてもよい。ファームウェアを含むソフトウェア製品が利用可能であってもよく、ファームウェアを「フラッシュ(flash)」するために使用されてもよい。
【0121】
いくつかの図は、単一のプロセッサおよび機械読み取り可能な命令を記憶する単一のメモリを示すだけであるが、当業者は、上述した構成要素の多数が含まれるが、発明側面を埋没させないために明示的に図示または記載されないことを理解するであろうことに留意されたい。たとえば、単一の機械のみが示されているが、用語「機械」は、本明細書で議論される方法論のいずれか一つまたは複数を実行するための命令のセット(または複数のセット)を個別にまたは共同で実行する機械の任意の集まりをも含むと解釈される。
【0122】
このように、本明細書に記載された各方法の一実施形態は、一つまたは複数のプロセッサ、たとえばペンストローク捕捉システムを形成する受信機の一部である一つまたは複数のプロセッサ上で実行するための命令のセットをコードされた、すなわち記憶している、非一時的な機械可読媒体の形である。
【0123】
当技術分野において理解されるように、本発明の一つまたは複数の側面を実行するための特定用途向けファームウェアを備えた機械が、本発明の一つまたは複数の側面を実行するためにファームウェアによって修正された特別目的機械になることに留意されたい。これは、機械が特に前記一つまたは複数の側面を実行するように構成されているので、ソフトウェアを使用する汎用処理システムとは異なる。さらに、当業者には知られているように、製造されるユニットの数がコストを正当化する場合、プロセッサなどの要素と組み合わされた命令の任意のセットは、専用ASICまたはカスタム集積回路に容易に変換することができる。たとえば処理エンジン131の一組の命令および詳細を受け入れ、自動的にまたはほぼ自動的に専用ハードウェアの設計を生成する、たとえば、ゲートアレイまたは類似のプログラマブル論理を修正するための命令を生成するか、または一組の命令によって以前に実行された機能を実行するための集積回路を生成する方法論およびソフトウェアが、何年にもわたって存在してきた。よって、当業者には理解されるように、本発明の実施形態は、方法、特殊目的装置のような装置、データDSP装置にファームウェアを加えたような装置、または非一時的な機械読み取り可能媒体として具現されてもよい。機械可読担体媒体は、一つまたは複数のプロセッサ上で実行されたときに該プロセッサに方法を実施させる命令のセットを含むホスト装置可読コードを担持する。よって、本発明の諸側面は、方法、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、またはソフトウェアとハードウェアの側面を組み合わせる実施形態の形をとることができる。さらに、本発明は、機械実行可能命令をエンコードされた非一時的な機械読み取り可能記憶媒体上のコンピュータプログラム製品の形をとることができる。
【0124】
本明細書を通じて「一つの実施形態」または「ある実施形態」への言及は、その実施形態に関連して記載される特定の特徴、構造または特性が、本発明の少なくとも1つの実施形態に含まれることを意味する。よって、本明細書を通じて随所で「一実施形態において」または「ある実施形態において」という句が出現することは、必ずしもすべてが同じ実施形態を指しているわけではない。ただし、同じ実施形態を指すこともありうる。さらに、特定の特徴、構造または特性は、本開示から当業者に明らかなように、一つまたは複数の実施形態において、任意の好適な仕方で組み合わされうる。
【0125】
同様に、本発明の例示的実施形態の上記の説明において、開示の流れをよくし、さまざまな発明側面の一つまたは複数の理解を助ける目的で、本発明のさまざまな特徴が、単一の実施形態、図面、またはその説明にまとめられることがある。しかしながら、この開示方法は、特許請求される発明が、各請求項において明示的に記載されているよりも多くの特徴を必要とするという意図を反映するものと解釈されるべきではない。むしろ、以下の特許請求の範囲が表わすように、発明側面は、単位の上記の開示された実施形態のすべての特徴よりも少ないものにある。よって、詳細な説明に続く特許請求の範囲は、ここに、この詳細な説明に明示的に組み込まれ、各請求項がそれ自身で本発明の別個の実施形態として自立する。
【0126】
さらに、本明細書に記載されるいくつかの実施形態は、他の実施形態に含まれるいくつかの特徴を含み、他の特徴は含まないものの、異なる実施形態の特徴の組み合わせは、当業者によって理解されるように、本発明の範囲内であり、異なる実施形態を形成することが意図されている。たとえば、以下の請求項では、請求項に記載された実施形態の任意のものが、任意の組み合わせで使用できる。
【0127】
さらに、いくつかの実施形態は、ホスト装置システムのプロセッサによって、または機能を実行する他の手段によって実装できる方法または方法の要素の組み合わせとして、本明細書に記載される。よって、そのような方法または方法の要素を実行するための必要な命令を有するプロセッサは、該方法または方法の要素を実行するための手段を形成する。さらに、装置実施形態の本明細書に記載されている要素は、本発明を実行する目的のために該要素によって実行される機能を実行するための手段の例である。
【0128】
本明細書で提供される説明において、多数の個別的な詳細が記載されている。しかしながら、本発明の実施形態が、こうした個別的な詳細なしで実施されうるということが理解される。他方では、周知の方法、構造および技術は、本稿の理解を曖昧にしないために詳細には示されていない。
【0129】
本明細書中で使用されるところでは、特に断わりのない限り、共通の対象を記述するための序数形容詞「第1の」、「第2の」、「第3の」などの使用は、単に、類似の態様の異なるインスタンスが言及されていることを示し、そのように記載された対象が、時間的に、空間的に、ランク付けにおいて、または任意の他の仕方で、所与の序列になければならないことを意味することを意図したものではない。
【0130】
本明細書に引用されているすべての刊行物、特許および特許出願は、ここに参照により組み込まれる。
【0131】
本明細書における先行技術のいかなる議論も、そのような先行技術が広く知られている、公然知られている、または当該分野における一般的知識の一部を形成しているという自認だと考えられるべきではない。
【0132】
以下の請求項および本明細書における説明において、有する、含むまたは備えるという用語のうちの任意のものが、少なくとも示された要素/特徴を含むが、他のものを除外はしないことを意味するオープンな用語である。よって、特許請求の範囲において使用される場合、有する/含むという用語は、挙げられている手段または要素またはステップに限定されるものとして解釈されるべきではない。たとえば、AおよびBを有する装置は、要素AおよびBのみからなる装置に限定されるべきではない。本明細書において使用されるところ含むまたは含んでいるという用語のうちの任意のものも、少なくとも示された要素/特徴を含むが、他のものを除外はしないことを意味するオープンな用語である。よって、含むは有すると同義であり、有するを意味する。
【0133】
同様に、結合されたという用語は、請求項において使用される場合、直接接続のみに限定されるものとして解釈されるべきではないことを注意しておく。用語「結合される」および「接続される」ならびにそれらの派生形が使用されることがある。これらの用語が、互いの同義語として意図されていないことが理解されるべきである。よって、装置Bに結合された装置Aという表現の範囲は、装置Aの出力が装置Bの入力に直接接続された装置またはシステムに限定されるべきではない。Aの出力とBの入力との間に、他の装置または手段を含む経路であってもよい経路が存在することを意味する。「結合された」という用語は、2つ以上の要素が、直接、物理的または電気的に接触していること、または2つ以上の要素が、互いに直接接触してはいないが、それでも互いと協働または相互作用することを意味しうる。
【0134】
このように、本発明の好ましい実施形態であると考えられるものが記載されているが、当業者であれば、本発明の精神から逸脱することなく、他のさらなる修正がそれに加えられてもよく、本発明の範囲に含まれるすべてのそのような変更および修正を請求することが意図されることを認識するであろう。たとえば、上記で与えた公式は、単に使用されうる手順を表わすに過ぎない。ブロック図から機能を追加または削除することができ、機能ブロック間で動作が交換されてもよい。ステップは、本発明の範囲内で、記載される方法に追加または削除されうる。
【0135】
本明細書に添付された請求項は、明細書の一部をなすものであり、よって、参照により明細書に組み込まれることに留意されたい。各請求項が一つまたは複数の実施形態の異なるセットをなす。引用によるそのような組み込みを認めない管轄区域においては、出願人は、補正により、かかる請求項を明細書に挿入する権利を留保する。各請求項は、1つの実施形態をなし、複数従属請求項が使用される場合にはいくつかの請求項は二つ以上の実施形態をなす。そのような補正は新規事項ではない。
【国際調査報告】