(57)【要約】【課題】歩行者環境についての推奨をランク付けするための方法、装置、及びコンピュータ可読記録媒体を提供する。【解決手段】本明細書で開示する主題はロケーションアウェア推奨エンジンに関する。推奨要求に応答して、ユーザの現在のロケーション、エンティティに関連するロケーション、および/またはアクセス可能性基準に基づいて、関連性のある推奨がランク付けされ得る。【選択図】図７
2014160093.tif 000002
【特許請求の範囲】
【請求項１】
歩行者環境についての推奨をランク付けするためのコンピュータ実装方法であって、
処理ユニットが、複数の時間的制約のある要求に関連する完了時刻を示す少なくとも1つの時間的制約に関連付けられた前記複数の時間的制約のある要求を含む検索要求を受信するステップと、
前記検索要求に応答して、
前記処理ユニットが、前記歩行者環境に関連する検索結果を判断するステップと、
前記処理ユニットが、前記検索要求に関連する移動局のロケーションを判断するステップと、
前記処理ユニットが、前記移動局の前記ロケーションと、前記検索結果の少なくとも一部分に関連するロケーションと、前記複数の時間的制約のある要求と、アクセス可能性基準とに少なくとも部分的に基づいて、前記検索結果の前記少なくとも一部分をランク付けするステップであって、前記アクセス可能性基準が、前記歩行者環境に関連するルート複雑性基準およびルート移動時間基準を含み、前記ルート複雑性基準が、前記歩行者環境を通るルートに複雑性を加える、通過するべき1つまたは複数の障害の存在に関連し、前記ルート移動時間基準が、前記歩行者環境を通るルートに関連する前記1つまたは複数の障害を通過するための時間量に関連する、ランク付けするステップと
を含む、方法。
【請求項２】
前記検索要求が、ユーザ入力および/または自動検索要求のうちの少なくとも1つを含む、請求項1に記載の方法。
【請求項３】
前記処理ユニットが、前記検索結果のうちの少なくとも1つまでのナビゲーション案内を与えるステップをさらに含む、請求項1に記載の方法。
【請求項４】
前記検索結果を判断するステップが、
前記検索要求の属性を判断するステップと、
前記検索要求の前記属性を、前記歩行者環境に関連する1つまたは複数のエンティティの属性と照合するステップと、
各照合されたエンティティを前記検索結果中に挿入するステップと
を含む、請求項1に記載の方法。
【請求項５】
前記アクセス可能性基準が利用可能性基準をさらに含む、請求項1に記載の方法。
【請求項６】
各アクセス可能性基準が重みを割り当てられる、請求項1に記載の方法。
【請求項７】
前記ルート移動時間基準が、
前記移動局の前記ロケーションと、前記検索結果の少なくとも一部分の各々に関連する前記ロケーションとの間のルート距離、
移動速度、
前記ルート上の混雑、
階段での時間、
エスカレータでの時間、および/または
エレベータでの時間
のうちの少なくとも1つを含む、請求項1に記載の方法。
【請求項８】
前記ルート複雑性基準は、
ルートがエスカレータを含むかどうか、
前記ルートが階段を含むかどうか、
前記ルートがエレベータを含むかどうか、
現在の移動方向、および/または
前記ルートが現在のベニューを離れることを含むかどうか
のうちの少なくとも1つを含む、請求項1に記載の方法。
【請求項９】
前記利用可能性基準は、
前記歩行者環境に関連するエンティティが開いているのか閉まっているのか、
前記エンティティがアクセス制限を有するかどうか、
前記エンティティにおいて必要とされる金額、および/または
前記エンティティにおいて必要とされる時間
のうちの少なくとも1つを含む、請求項5に記載の方法。
【請求項１０】
前記移動局が前記歩行者環境において位置を変更するにつれて、前記処理ユニットが、前記検索結果の前記ランク付けされた一部分を動的に並べ替えるステップをさらに含む、請求項1に記載の方法。
【請求項１１】
前記移動局の前記ロケーションに少なくとも部分的に基づいて、前記検索結果の少なくとも一部分をランク付けするステップが、
前記移動局の移動方向を判断するステップと、
前記移動局の前記移動方向に少なくとも部分的に基づいて、前記検索結果をランク付けするステップであって、前記移動局の前記移動方向に沿っていると共に前記移動局の前記移動方向から所定の角度内にある検索結果が、前記移動局の前記移動方向に沿っていないと共に前記移動局の前記移動方向から所定の角度内にない他の検索結果よりも、より高い順位と関連付けられる、ランク付けするステップと
をさらに含む、請求項1に記載の方法。
【請求項１２】
前記検索結果が金銭的制約を含み、
前記検索結果の前記少なくとも一部分をランク付けするステップが、前記移動局の前記ロケーションと、前記検索結果の前記少なくとも一部分に関連する前記ロケーションと、前記アクセス可能性基準と、前記金銭的制約とに少なくとも部分的に基づいて、前記検索結果の前記少なくとも一部分をランク付けするステップを含む、請求項1に記載の方法。
【請求項１３】
歩行者環境についての推奨をランク付けするための装置であって、
複数の時間的制約のある要求に関連する完了時刻を示す少なくとも1つの時間的制約に関連付けられた前記複数の時間的制約のある要求を含む検索要求を受信することと、
前記検索要求に応答して、
前記歩行者環境に関連する検索結果を判断することと、
前記検索要求に関連する移動局のロケーションを判断することと、
前記移動局の前記ロケーションと、前記検索結果の少なくとも一部分に関連するロケーションと、前記複数の時間的制約のある要求と、アクセス可能性基準とに少なくとも部分的に基づいて、前記検索結果の前記少なくとも一部分をランク付けすることであって、前記アクセス可能性基準が、前記歩行者環境に関連するルート複雑性基準およびルート移動時間基準を含み、前記ルート複雑性基準が、前記歩行者環境を通るルートに複雑性を加える、通過するべき1つまたは複数の障害の存在に関連し、前記ルート移動時間基準が、前記歩行者環境を通るルートに関連する前記1つまたは複数の障害を通過するための時間量に関連する、ランク付けすることと
を行うように構成された処理ユニット
を含む、装置。
【請求項１４】
前記検索要求が、ユーザ入力および/または自動検索要求のうちの少なくとも1つを含む、請求項13に記載の装置。
【請求項１５】
前記処理ユニットが、前記検索結果のうちの少なくとも1つまでのナビゲーション案内を与えるようにさらに構成された、請求項13に記載の装置。
【請求項１６】
前記処理ユニットが、
前記検索要求の属性を判断することと、
前記検索要求の前記属性を、前記歩行者環境に関連する1つまたは複数のエンティティの属性と照合することと、
各照合されたエンティティを前記検索結果中に挿入することと
を行うようにさらに構成された、請求項13に記載の装置。
【請求項１７】
前記アクセス可能性基準が利用可能性基準をさらに含む、請求項13に記載の装置。
【請求項１８】
各アクセス可能性基準が重みを割り当てられる、請求項13に記載の装置。
【請求項１９】
前記ルート移動時間基準が、
前記移動局の前記ロケーションと、前記検索結果の前記少なくとも一部分の各々に関連する前記ロケーションとの間のルート距離、
移動速度、
前記ルート上の混雑、
階段での時間、
エスカレータでの時間、および/または
エレベータでの時間
のうちの少なくとも1つを含む、請求項13に記載の装置。
【請求項２０】
前記ルート複雑性基準は、
ルートがエスカレータを含むかどうか、
前記ルートが階段を含むかどうか、
前記ルートがエレベータを含むかどうか、
現在の移動方向、および/または
前記ルートが現在のベニューを離れることを含むかどうか
のうちの少なくとも1つを含む、請求項13に記載の装置。
【請求項２１】
前記利用可能性基準は、
前記歩行者環境に関連するエンティティが開いているのか閉まっているのか、
前記エンティティがアクセス制限を有するかどうか、
前記エンティティにおいて必要とされる金額、および/または
前記エンティティにおいて必要とされる時間
のうちの少なくとも1つを含む、請求項17に記載の装置。
【請求項２２】
前記処理ユニットは、前記移動局が前記歩行者環境において位置を変更するにつれて、前記検索結果の前記ランク付けされた一部分を動的に並べ替えるようにさらに構成された、請求項13に記載の装置。
【請求項２３】
歩行者環境についての推奨をランク付けするための装置であって、
複数の時間的制約のある要求に関連する完了時刻を示す少なくとも1つの時間的制約に関連付けられた前記複数の時間的制約のある要求を含む検索要求を受信するための手段と、
前記検索要求に応答して、前記歩行者環境に関連する検索結果を判断するための手段と、
前記検索要求に関連する移動局のロケーションを判断するための手段と、
前記移動局の前記ロケーションと、前記検索結果の少なくとも一部分に関連するロケーションと、前記複数の時間的制約のある要求と、アクセス可能性基準とに少なくとも部分的に基づいて、前記検索結果の前記少なくとも一部分をランク付けするための手段であって、前記アクセス可能性基準が、前記歩行者環境に関連するルート複雑性基準およびルート移動時間基準を含み、前記ルート複雑性基準が、前記歩行者環境を通るルートに複雑性を加える、通過するべき1つまたは複数の障害の存在に関連し、前記ルート移動時間基準が、前記歩行者環境を通るルートに関連する前記1つまたは複数の障害を通過するための時間量に関連する、ランク付けするための手段と
を含む、装置。
【請求項２４】
前記検索要求が、ユーザ入力および/または自動検索要求のうちの少なくとも1つを含む、請求項23に記載の装置。
【請求項２５】
前記検索結果のうちの少なくとも1つまでのナビゲーション案内を与えるための手段をさらに含む、請求項23に記載の装置。
【請求項２６】
前記検索結果を判断するための前記手段が、
前記検索要求の属性を判断するための手段と、
前記検索要求の前記属性を、前記歩行者環境に関連する1つまたは複数のエンティティの属性と照合するための手段と、
各照合されたエンティティを前記検索結果中に挿入するための手段と
を含む、請求項23に記載の装置。
【請求項２７】
前記アクセス可能性基準が利用可能性基準をさらに含む、請求項23に記載の装置。
【請求項２８】
各アクセス可能性基準が重みを割り当てられる、請求項23に記載の装置。
【請求項２９】
前記ルート移動時間基準が、
前記移動局の前記ロケーションと、前記検索結果の前記少なくとも一部分の各々に関連する前記ロケーションとの間のルート距離、
移動速度、
前記ルート上の混雑、
階段での時間、
エスカレータでの時間、および/または
エレベータでの時間
のうちの少なくとも1つを含む、請求項23に記載の装置。
【請求項３０】
前記ルート複雑性基準は、
ルートがエスカレータを含むかどうか、
前記ルートが階段を含むかどうか、
前記ルートがエレベータを含むかどうか、
現在の移動方向、および/または
前記ルートが現在のベニューを離れることを含むかどうか
のうちの少なくとも1つを含む、請求項23に記載の装置。
【請求項３１】
前記利用可能性基準は、
前記歩行者環境に関連するエンティティが開いているのか閉まっているのか、
前記エンティティがアクセス制限を有するかどうか、
前記エンティティにおいて必要とされる金額、および/または
前記エンティティにおいて必要とされる時間
のうちの少なくとも1つを含む、請求項27に記載の装置。
【請求項３２】
前記移動局が前記歩行者環境において位置を変更するにつれて、前記検索結果の前記ランク付けされた一部分を動的に並べ替えるための手段をさらに含む、請求項23に記載の装置。
【請求項３３】
歩行者環境についての推奨のランク付けを実行するように処理ユニットに指示するように適応された命令を記録するコンピュータ可読記録媒体であって、前記命令が、
複数の時間的制約のある要求に関連する完了時刻を示す少なくとも1つの時間的制約に関連付けられた前記複数の時間的制約のある要求を含む検索要求を受信するためのコードと、
前記検索要求に応答して、
前記歩行者環境に関連する検索結果を判断することと、
前記検索要求に関連する移動局のロケーションを判断することと、
前記移動局の前記ロケーションと、前記検索結果の少なくとも一部分に関連するロケーションと、前記複数の時間的制約のある要求と、アクセス可能性基準とに少なくとも部分的に基づいて、前記検索結果の前記少なくとも一部分をランク付けすることであって、前記アクセス可能性基準が、前記歩行者環境に関連するルート複雑性基準およびルート移動時間基準を含み、前記ルート複雑性基準が、前記歩行者環境を通るルートに複雑性を加える、通過するべき1つまたは複数の障害の存在に関連し、前記ルート移動時間基準が、前記歩行者環境を通るルートに関連する前記1つまたは複数の障害を通過するための時間量に関連する、ランク付けすることと
を行うためのコードと
を含む、
コンピュータ可読記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
米国特許法第119条に基づく優先権の主張
本出願は、本出願の譲受人に譲渡され、参照により本明細書に明確に組み込まれる、2010年1月22日に出願された「Location-aware Ordering of Search Results」と題する仮特許出願第61/297,666号の優先権を主張する。
【０００２】
本明細書で開示する主題は、一般にロケーションアウェア推奨エンジンに関する。
【背景技術】
【０００３】
セルフォン、タブレット、携帯情報端末(PDA)、電子ブックリーダー、スマートブック、ネットブック、または他の移動局(MS)など、MSのロケーションを判断するために様々な方法が利用され得る。たとえば、一部のMSは、それらのロケーションを判断するために、全地球測位システム(GPS)などの衛星測位システム(SPS)、またはSPSとセルラー基地局との組合せを利用し得る。
【０００４】
多くの移動局は、たとえば、ウェブベースの検索エンジンまたはマッピングアプリケーションを介して、場所の検索を行う能力を有する。検索エンジンによって返信される検索結果は、関連性(relevancy)の順に表示され得る。たとえば、「ファストフード」の検索文字列により、レストランＡの公式ウェブアドレス、およびおそらくユーザの全体的なメトロポリタンエリア中のいくつかのファストフードレストランなど、ファストフードレストランに関する一般的な情報が返信され得る。この情報は、モールまたは遊園地内におり、ランチタイムに食べ物を探している歩行者にとって、直接役立たないことがある。マッピングアプリケーションは、マップ上のユーザの現在のロケーションをマークし、たとえば、ユーザの2マイル以内にあるファストフードレストランを与え得、その場合、特定のファストフードレストランのロケーションとユーザのロケーションとの間の直線距離を使用して、そのレストランとユーザとの間の距離が判断される。この場合も、そのような結果は、たとえば、空港内におり、飛行機に間に合うように10分で食べ物を得ようとしている歩行者にとって、役立たないことがある。
【発明の概要】
【課題を解決するための手段】
【０００５】
1つの特定の設計では、歩行者環境についての推奨をランク付けするための方法を提供する。検索要求が受信され得る。検索要求に応答して、歩行者環境に関連する1つまたは複数の検索結果が判断され得、検索要求に関連する移動局のロケーションが判断され得、移動局のロケーションと、1つまたは複数の検索結果の少なくとも一部分に関連するロケーション、および/またはアクセス可能性基準のうちの少なくとも1つとに少なくとも部分的に基づいて、1つまたは複数の検索結果の少なくとも一部分がランク付けされ得る。ただし、これは例示的な設計にすぎず、請求する主題はこの点について限定されないことを理解されたい。
【０００６】
以下の図を参照しながら非限定的で非網羅的な特徴について説明し、様々な図の全体を通して、同様の参照番号は同様の部分を指す。
【図面の簡単な説明】
【０００７】
【図１Ａ】屋内ショッピングベニューの1(地上)階と、移動局を携帯し、ベニュー内で移動するユーザとを示す図である。
【図１Ｂ】図1Aの屋内ショッピングベニューの2階を示す図である。
【図２】ショッピングベニュー中のおよびショッピングベニューの近くのエンティティと、それらのエンティティに関する情報とを記載するデータベースを示す図である。
【図３】屋内ショッピングベニューについての推奨のロケーションアウェア順序付けを表示する移動局を示す図である。
【図４】図3の推奨のロケーションアウェア順序付けを生成するための方法を示す図である。
【図５】推奨のロケーションアウェア順序付けの別の例を表示する移動局を示す図である。
【図６】推奨のロケーションアウェア順序付けのさらに別の例を表示する移動局を示す図である。
【図７】推奨のロケーションアウェア順序付けを生成するための例示的な図である。
【図８】移動局と通信するためのシステムのブロック図である。
【発明を実施するための形態】
【０００８】
本明細書全体にわたる「一例」、「1つの特徴」、「例」または「特徴」という言及は、その特徴および/または例に関連する説明が、請求する主題の少なくとも1つの特徴および/または例に含まれ得ることを意味する。したがって、本明細書全体にわたる様々な箇所におけるそのような句の出現は、必ずしもすべてが同じ特徴および/または例を指すとは限らない。特徴、例、および/または機能についての特定の説明は、1つまたは複数の特徴、例、および/または機能において組み合わせられ得る。本明細書では、「ロケーション」および「位置」という用語は互換的に使用され得る。本明細書では、「検索要求」および「推奨要求」という用語は互換的に使用され得、「検索結果」および「推奨結果」という用語は互換的に使用され得る。
【０００９】
歩行者環境とは、歩行者がアクセス可能な環境またはエリアを指し得る。たとえば、歩行者が、歩き、走り、車椅子に乗り、自転車に乗り、あるいはあるロケーションから別のロケーションに物理的に移動し得るエリアは、歩行者環境を含み得る。歩行者環境の例は、屋内環境および屋外環境を含み得る。屋内歩行者環境の例は、多くの考えられる例のうちほんのいくつかの例を挙げれば、オフィスビル、ホテル、ショッピングモール、倉庫、食品雑貨店、カジノ、ミュージアム、交通機関のターミナル(たとえば、空港、地下鉄の駅、フェリー/クルーズのターミナルなど)、コンベンションセンター、およびスポーツスタジアムなど、密閉建造物を含む。屋外歩行者環境の例は、多くの考えられる例のうちほんのいくつかの例を挙げれば、ビーチ、ボードウォーク、遊園地、動物園、屋外ショッピングモール/通り、屋外市場、公園を含み、および歩道などの歩行者がアクセス可能なパスを有するエリアを含む。
【００１０】
屋内環境などにおける歩行者のためのナビゲーションは、車の運転者のためのナビゲーションとは異なる手法を必要とし得る。たとえば、GPS信号またはセルラー信号などの信号は、屋内建造物(たとえば、ショッピングモール、空港、オフィスビルなど)中で、またはそのような信号の送信機へのクリアな視界が遮断され得るマンハッタンミッドタウンなどの屋外ビルの谷間において、劣化しており、信頼できないことがある。さらに、歩行者ベニューは、しばしば、階段、エレベータ、およびエスカレータなどの障害、ならびにナビゲーションに複雑性を加え得る制限付きアクセスエリアなどの障壁を提示する。階段、エレベータ、およびエスカレータは、歩行者のパスにおける物理的障害を提示するだけでなく、歩行者の現在のフロア/ロケーションコンテキストから歩行者を切り離し得るフロア変更であって、新しいおよび場合によっては不慣れなフロア/ロケーションコンテキストに歩行者を置き得るフロア変更をも表す。乗り物と比較して限定された歩行者の移動範囲を仮定すれば、レストラン、店舗、劇場、化粧室、または歩行者にとっていつでもアクセス可能な他のエンティティなど、当該ポイント(POI)の量は、歩いて行ける便利な距離内のエリアに限定され得る。したがって、歩行者がその人の移動局上の検索アプリケーションにおいて検索要求を入力したとき、検索結果中のPOIを、歩いて行ける便利な距離(または、歩行者が車椅子に乗っている場合は移動距離)内にあるPOIに限定し、たとえば、アクセス可能性の容易さの順に検索結果をランク付けすることが有用であり得る。
【００１１】
図1Aに、屋内ショッピングモールの1階と、移動局100を携帯し、モール内で移動する歩行者ユーザとを示す。図1Bに、ショッピングモールの2階を示す。GPSなどのSPSからのナビゲーション信号がモール内で利用可能でないことがある。SPS信号が利用不可能であるエリア内で移動局100のロケーションが判断され得る方法があり得る。そのエリア内に位置し、知られている固定のロケーションを有するデバイスがあり得る。たとえば、固定の知られているロケーションをもつワイヤレスデバイスが、図1Aおよび図1Bのモール全体にわたって分散していることがある。そのようなワイヤレスデバイスは信号を送信し得、そのような信号に基づく三辺測量によって移動局のロケーションが判断され得る。SPS信号が利用不可能であるエリアでは、たとえば、移動局が、近くのワイヤレスデバイスに関与する信号を利用することによって移動局のロケーションを推定し得る。そのような信号は、たとえば、米国電気電子技術者協会(IEEE)802.11準拠(Wi-Fi)信号、フェムトセルに関与する信号、Bluetooth(登録商標)信号などを含み得る。
【００１２】
歩行者ベニュー事業者は、屋内歩行者環境において劣化しているかまたは信頼できないことがあるセルラータワー信号の拡張または代替としてボイスまたはデータネットワークへの接続性を与えるために、Wi-Fiアクセスポイントなどのワイヤレスデバイスまたはフェムトセルをますます展開していることがある。たとえば、(図1Aおよび図1Bに示されていない)Wi-Fiアクセスポイントがショッピングモール全体にわたって展開され得る。ユーザの移動局の(および、したがってユーザの)位置は、たとえば、Wi-Fi信号を利用した三辺測量によって判断され得る。移動局100は、たとえば、それ自体で計算を実行することによって、またはロケーション判断要求をサーバに送り、サーバから計算されたロケーションを受信することによって、移動局100のロケーションを判断し得る。ユーザがモールに入ると、移動局100は、モール内のWi-Fiアクセスポイントと通信し始め得、Wi-Fi信号を利用した位置判断により、MS100がモール内にあることが示され得る。MS100がモール内にあると判断されると、ユーザが存在するフロアのマップ(たとえば、図1A)が、サーバからMS100によってプルされるか、またはサーバからMS100にプッシュされ、MS100のスクリーン上に表示され得る。代替的に、たとえば、マップは、ユーザがモールに入るより前に、MS100上にプリロードされ得る。モール中のユーザのロケーションは、MS100のスクリーン上のマップ上のシルエット形状(たとえば、図1A)によって示され得る。図1A中のユーザはエレベータの方向に移動している。
【００１３】
エンティティのロケーションとモール内の建造物とは座標系によって示され得、その座標系は、ローカル座標系、またはGPSとともに使用されるWGS84座標系などの一般化されたグローバル座標系であり得る。明快のために、図1Aおよび図1Bではローカル座標系が利用されおり、座標は(x,y,z)形式での座標であり、xは、図1Aおよび図1Bで水平軸に沿ってエンティティ、建造物などの位置を表し、yは、図1Aおよび図1Bで垂直軸に沿ってエンティティまたは建造物の位置を表し、zはショッピングモールの階を表し、1は1(地上)階を示し、2は2階を示す。たとえば、ユーザの位置は(18,9,1)によって示され得、モールの入口/出口1は(18,10,1)によって示され得、モール1階のレストランＢの入口/出口は(7,9,1)によって示され得、1階と2階を接続するエスカレータ2の入口/出口ポイントは、1階では(8,3,1)によって示され、2階では(8,3,2)によって示され得、モール2階のレストランＣの入口/出口は(18,7,2)によって示され得る。そのような入口/出口と、廊下の交点、たとえば、(7,3,1)とは、ルーティンググラフの頂点として働き得、そのような頂点間の距離は、たとえば、ルーティンググラフのエッジとして働き得る。
【００１４】
図2に、ショッピングモール中のおよびショッピングモールの近くのエンティティおよび建造物と、それらのエンティティおよび建造物に関する情報とを記載するデータベース200を示す。たとえば、そのようなデータベースは、ショッピングモールによって制御されるサーバに記憶され得る。データベース200は1つの設計に従ってユーザのMS100に送信され得る。データベース200の第1の列は、エンティティまたは建造物の名前を示す。データベース200の第2の列は、第1の列中の対応するエンティティおよび建造物のカテゴリーを示す。第3の列は、対応するエンティティおよび建造物の任意のサブカテゴリーを示す。第4の列は、対応するエンティティおよび建造物の入口/出口のロケーションを示す。第5の列は、対応するエンティティおよび建造物の他の属性を示す。
【００１５】
たとえば、レストランＤは、「フード」カテゴリーと、「ファストフード」および「メキシコ料理」サブカテゴリーとの中にある。レストランＤの入口/出口は(6,3,2)に位置する(図2B)。エレベータは、「建造物」カテゴリーと、「フロア変更」サブカテゴリーとの中にある。エレベータの入口/出口は、1階では(18,14,1)に位置し、2階では(18,14,2)に位置する。エレベータは、「他の属性」列によって示されるように、身障者/車椅子アクセス可能である。モール中の大型エンティティ(アイススケートリンク、映画館、およびショップＡ)の場合、「他の属性」列は、これらのエンティティの境界をマークする座標を含んでいる。化粧室3は「ロケーション」列によって示されるように、映画館内に位置し、「他の属性」列によって示されるように、制限付きアクセスを有し、映画の観客のみが利用可能である。化粧室4は、「ロケーション」列によって示されるように、ショップＡ中(モールの2階)に位置し、「他の属性」列によって示されるように、一度に1人用の単一の化粧室を含むにすぎない。ショップＡは、「他の属性」列によって示される様々な商品を販売する。映画館またはショップＡなどの大型エンティティは、ユーザが映画館またはショップＡに入ったときにMS100に送信され得る、大型エンティティ自体のマップを有し得る。レストランＥは、「サブカテゴリー」列によって示されるように、高級料理を提供し、「他の属性」列によって示されるように、モール営業時間とは異なる特別な営業時間を有する。データベース200は、図2に示す情報よりも多い情報、少ない情報、または図2に示す情報とは異なる情報を有し得る。たとえば、データベース200は、レストランの場合はメニュー選択肢/価格、および店舗の場合は在庫品目/価格に関する詳細情報を有し得る。POI属性が変化する(たとえば、ある店舗がモールから出て別の店舗が入る、店舗が休暇シーズン中の店舗の営業時間を延長する、など)と、データベース200は新しい情報を反映するために更新され得る。ユーザがモールに入ったときはいつでも、データベース200の現行バージョンあるいはデータベース200へのリンクまたはポインタが(たとえば、Wi-Fiを介して)MS100に送信され得る。データベース200は、単一のデータベース/データ構造、
または複数のデータベース/データ構造の組合せであり得る。
【００１６】
図3に、ショッピングモールについての推奨のロケーションアウェア順序付けを表示する移動局を示す。MS100のディスプレイ302に、ウィンドウ304中のユーザ入力を受信し、それに応答してロケーションアウェア推奨のランク付けされたリストを与える、ロケーションアウェア推奨アプリケーションを示す。別の設計では、ロケーションアウェア推奨インターフェースは従来の検索エンジンインターフェースに組み込まれ得る。ユーザは、キーボード316を介して、オンスクリーンキーボード(図示せず)を介して、MS100の音声テキスト機能などを介して、ウィンドウ304中に推奨要求を入力し得る。検索要求を入力した後に、ユーザは、たとえば、リターンキーを入力することによって、またはディスプレイ302上の「推奨」という単語をクリックすることによって、推奨プロセスをアクティブにし得る。別の設計では、自動推奨要求が受信され得る。たとえば、MS100またはサーバは、説明したようにMS100がモール内にあると判断しており、カレンダーアプリケーションにアクセスし、休暇シーズンであることを発見し、「ホリデーギフト」の推奨要求を自動的に入力し得る。
【００１７】
図3の例では、現在時刻はディスプレイ302上に示すように午後1時15分であり、推奨要求「チーズバーガー」が入力されている。それに応答して、ロケーションアウェア推奨エンジンは、ユーザの現在のロケーション、ユーザの歩いて行ける便利な距離内でチーズバーガーを販売し得るレストランに関連するロケーション、および/またはアクセス可能性基準に基づいて、たとえば、最もアクセス可能なものから最もアクセス可能でないものへと、アクセス可能性の順にランク付けされた上記レストランのリストを与える。
【００１８】
アクセス可能性基準は、目的地までのルートの長さ、ルートの複雑性、目的地までのルートにおける階段、エレベータ、またはエスカレータなどの障害の関与、転回/方向反転する必要、ルートの混雑、目的地が営業中であるかまたは制限付きアクセスを有するかどうか、目的地において必要とされる時間または金額、ルートが現在のベニューを離れることに関与するかどうか、などを含み得る。図3の推奨のロケーションアウェア順序付けを生成するための方法については、図4に関して以下で詳細に説明する。
【００１９】
図3にとどまって、以下で、ディスプレイ302上の様々なアイコンについて説明する。この例では、レストランＦがチーズバーガーについての最上位の推奨としてランク付けされており、MS100の配向に対して前方向の矢印を有するアイコン306は、ユーザがレストランＦへの途上でユーザの現在のロケーションから前方に移動し続けるべきであることをユーザに示している。第2位にランク付けされたレストランＧはモールの2階にあり、したがって、レストランＧまでのルートにおける階段の使用を示すアイコン308と、レストランＧまでのルートにおけるエレベータの使用を示すアイコン310とが表示されている。ユーザがエスカレータを介して2階に到達することもできるが、ユーザに最も近いエスカレータであるエスカレータ1は、ショップＡ内にあり、レストランＧに着くためにショップＡ内を移動する複雑性をはらむことになるので、エスカレータのアイコンは表示されていない。したがって、階段およびエレベータは最もアクセス可能なオプションとして示されている。第3位にランク付けされたレストランＨはモールの1階にあるが、そのルートは、アイコン312によって示されるように、ユーザの現在の方向を反転させることに関与する。ユーザの現在の方向は、たとえば、加速度計などのMS100中の1つまたは複数のセンサを介して検出され得る。たとえば、MS100によって示唆される目的地までの歩行指示に基づくパスがユーザの現在の方向の+/-15度の角度内にある場合、そのパスはユーザの現在のパスと同じ方向にあると仮定され得る。第4位にランク付けされたレストランＩはモール外にあり、したがって、レストランＩが現在のベニュー外にあることを示すためのアイコン314が表示されている。最初の4つのレストランの推奨の隣のアイコン318は、それらが適当な選択肢であることを示している。第5位にランク付けされたレストランＥは、データベース200中の情報に基づいて現在時刻では閉店しており、したがって、アイコン320は、レストランＥが不適当な選択肢であることを示している。レストランＥは現在閉店しているが、リスト中に含まれており、なぜなら、レストランＥは将来のチーズバーガーの別のオプションをユーザに提示し得、ユーザはディスプレイ302上のレストランＥのリンクをクリックすることによってレストラ
ンＥに関する営業時間などのより多くの情報を発見し得るからである。
【００２０】
適当な選択肢の各々に関する追加情報を見つけるために、ユーザはディスプレイ302上の対応するレストラン名のリンクをクリックし得る。これらのレストランのうちの1つのメニューを見るために、これらのレストランのうちの1つに電話をかけるために、またはこれらのレストランのうちの1つまでのマップ/歩行指示を起動するために、ユーザはディスプレイ302上の対応するリンクをクリックし得る。たとえば、レストランＦのマップ/歩行指示リンクをクリックした後に、図1Aなどのマップが、たとえば、ディスプレイ302上に与えられ、ユーザの現在のロケーションがシルエット形状によって示され得る。レストランＦまでのルートは、たとえば、図4に関する以下の説明に基づいて、ロケーションアウェア推奨エンジンによって判断され得る。ナビゲーション案内が与えられ得る。たとえば、ルートは、黄色などの極めて目立つ色によって、ルートを点滅させることによって、レストランＦまでのルートに沿って配置された一連の流れる矢印などによって、強調され得る。別の例として、たとえば、ディスプレイ302を介して視覚的におよび/またはMS100のスピーカーデバイスを介して可聴的に、「そのまま直進」、「交点で左折」、「そのまま直進」、「化粧室1で左折」、「そのまま直進」、および「右折してレストランＦへ」などのナビゲーション命令も与えられ得る。ディスプレイ302上の推奨スクリーンが与えられた後にユーザが選択を行わない場合、MS100は、デフォルト設定として、最高ランクの推奨が、この場合はレストランＦが目的地であると仮定し得る。したがって、ユーザがモール中を移動するにつれて、アイコン306の矢印は、レストランＦに到達するルートをたどるためにユーザが移動すべきである方向を指すように方向を変更し得る。ただし、ユーザが、選択を行うことなしに、検索要求が入力されたロケーションから著しい距離を移動する場合、推奨のランキングは、推奨エンティティのロケーションに対する移動局100の変更されたロケーション(および、したがってユーザの変更されたロケーション)を反映するために動的に並べ替えられ得る。
【００２１】
チーズバーガーの推奨要求が受信されると、歩行者環境に関連する1つまたは複数の検索結果を判断するための検索が起動され得る。この例では、ロケーションアウェア推奨エンジンは、歩行者の現在のロケーションに基づいて、チーズバーガーを販売し、歩行者によって便利にアクセス可能であるレストランについて、推奨が行われるべきであると判断し得る。MS100の現在のロケーション(および、したがってユーザの現在のロケーション)がモール中にあると判断されるので、チーズバーガーを販売し得る、モール中のまたはモールの近くの1つまたは複数のエンティティの関連性リストを判断するための検索が起動され得る。この検索は、どのエンティティがチーズバーガーを販売することに関連性があるかを判断するためにデータベース200中の情報を利用し得る関連性検索アルゴリズム(たとえば、従来の検索エンジンによって採用される関連性検索アルゴリズム)を使用して実行され得る。ロケーションアウェア推奨エンジンは、(たとえば、関連性検索アルゴリズムを起動することによって)モールに関連する1つまたは複数の検索結果を判断し、それらの検索結果にロケーションアウェア基準を適用して、ディスプレイ302上に示すようにランク付けされた結果リストを生成し得る。関連性検索アルゴリズムは検索要求の属性を判断し得る。たとえば、検索要求「チーズバーガー」の属性は、「ファストフード」、「ハンバーガー」などであると判断され得る。関連性検索アルゴリズムは、(たとえば、データベース200中の情報を利用して)検索要求の判断された属性を、歩行者環境に関連する1つまたは複数のエンティティの属性と照合し、各照合されたエンティティを1つまたは複数の検索結果のリスト中に挿入し得る。この例では、関連性検索アルゴリズムは、レストランＦ、レストランＨ、レストランＩ、レストランＥ、およびレストランＧを含む、照合されたエンティティのリストを返信し得る。関連性検索アルゴリズムは、レストランＦ、レストランＨ、レストランＩ、およびレストランＧはファストフードハンバーガーレストランであるので、これらのエンティティを最も関連性のあるものとしてランク付けし、レストランＥは高級レストランであり、ハンバーガーを販売することがレストランＥの本業でないことがあるので、レストランＥを部分的に関連性のあるものとしてランク付けし得る。したがって、関連性検索は、レストランＦ、レストランＨ、レストランＩ、およびレストランＧを、関連性に関して等しいランクのものであると判断し、検索結果においてそれらをレストランＥの前に名前でアルファベット順に挿入し得る。たとえば、「チーズバーガー」の代わりに「スシ」の推奨要求が入力された場合、関連性検索は、検索要求の属性を「スシ」および「日本食」であると判断し、スシまたは日本食を提供する、モール中のまたはモールの近くのエンティティがないと判断し得る。関連性検索は、スシについて一致するものが見つからなかったことを示す検索結果を与え得、この検索結果に基づいて、推奨エンジンは、ディスプレイ302上に表示するために「このベニューにおいてスシは入手不可能です」という結果を与え得る。この場合、与えられるナビゲーション案内は「該当するマップ/指示がありません��であり得る。たとえば、「チーズバーガー」の代わりに「ステーキ」の推奨要求が入力された場合、関連性検索は、レストランＥが、モール中のまたはモールの近くの唯一の関連性のあるエンティティであると判断し得、推奨エンジンは、レストランＥについての(たとえば、図4に関して説明する)総パスコスト判断をスキップし、レストランＥを最上位の推奨としてランク付けし得る。
【００２２】
次に、図3の推奨のロケーションアウェア順序付けを生成するための方法を示す図4に関して、関連性検索からの検索結果のリストにロケーションアウェア基準を適用することについて説明する。本方法は、検索結果中のエンティティまでの最短パスを判断し、たとえば、パスの特定のセグメントまたはパス全体に重みを適用し得る。最短パスは、たとえば、開始点としてのユーザの現在のロケーションと、目的地としてのエンティティの入口ロケーションとを用いた従来の最短パスアルゴリズムに基づいて、判断され得る。たとえば、ダイクストラ法(Dijkstra's algorithm)のバージョンが利用され得る。説明したように、ユーザの現在のロケーションは、たとえば、Wi-Fiアクセスポイントまたはフェムトセルなどの信号源に基づく三辺測量を利用して、判断され得る。適用される重みは、ルート移動時間基準、ルート複雑性基準、および/または利用可能性基準を含み得る、様々なアクセス可能性基準に基づき得る。
【００２３】
ルート移動時間基準は、移動局のロケーションと各検索結果に関連するロケーションとの間のルート距離、移動速度、ルート上の混雑、階段での時間、エスカレータでの時間、および/またはエレベータでの時間のうちの少なくとも1つを含み得る。
【００２４】
ルート複雑性基準は、ルートが階段を含むかどうか、ルートがエスカレータを含むかどうか、ルートがエレベータを含むかどうか、現在の移動方向、および/またはルートが現在のベニューを離れることを含むかどうかのうちの少なくとも1つを含み得る。
【００２５】
利用可能性基準は、歩行者環境に関連するエンティティが開いているのか閉まっているのか、上記エンティティがアクセス制限を有するかどうか、上記エンティティにおいて必要とされる時間、および/または上記エンティティにおいて必要とされる金額のうちの少なくとも1つを含み得る。各個の基準は重み値を割り当てられ得る。重み値はパス長と組み合わせられて、総パスコストが判断され得る。各推奨の総パスコストに基づいて推奨がランク付けされ得る。場合によっては、ユーザの現在の方向からエンティティまでの1つまたは複数のパスが、最短パスと同様のまたは最短パスに近いパス長を有すると判断され得る。1つの設計では、これらの代替パスの各々について総パスコストが判断され得、最低総パスコストをもつパスが、検索結果のロケーションアウェアランク付けにおいて利用されることになる。別の設計では、好適な数(たとえば、2つまたは3つ)の、同様の総パスコストをもつ代替パスが、検索結果のロケーションアウェアランク付けにおいて利用され得る。
【００２６】
レストランＦの場合、データベース200は、レストランＦの専用入口が(7,7,1)にあることを示す。図1A中の現在のユーザロケーション(18,9,1)から(7,7,1)までの最短パスは、図1Aのローカル座標マップを利用して(18,9,1)の開始点と(7,7,1)の終了点とを用いた従来の最短パスアルゴリズムを適用することによって判断され得る。このパスは、(18,9,1)->(18,12,1)->(13,12,1)->(7,12,1)->(7,7,1)であると判断され得る。パスセグメントの長さは、(18,9,1)と(18,12,1)との間では3ユニットであり、(18,12,1)と(13,12,1)との間では5ユニットであり、(13,12,1)と(7,12,1)との間では6ユニットであり、(7,12,1)と(7,7,1)との間では5ユニットである。使用される座標系に応じて、ユニットは、たとえば、距離の任意の好適な測定値、たとえば、メートル、10メートル、ヤード、10ヤード、フィート、10フィートなどであり得る。パスの長さはセグメントの長さの和であると判断され得、その和は、この例では19である。各セグメントまたはパス全体に重みが適用され得る。この例では、ユーザの現在のロケーションからレストランＦの入口までのパスは、たとえば、階段、エレベータ、エスカレータ、混雑、モールを離れること、アクセス制限などを含まず、したがって重みの好適なベース値(たとえば、1)が各セグメントに適用され得る。たとえば、階段または混雑を含むセグメントは、ベース値よりも高い好適な重み値(たとえば、階段の場合は20、および混雑の場合は15)を割り当てられ得る。階段と混雑の両方を含むセグメントは、階段の重み値と混雑の重み値との和である重み値(たとえば、35)を割り当てら得る。一方、歩行者移動を支援する建造物など(たとえば、空港における乗客用の電動コンベアベルト)を含むセグメントは、ベース値よりも低い重み値(たとえば、0または-1)を割り当てられ得る。このレストランＦの例では、各セグメントに重みを適用することは、各セグメントの長さに重み値を乗算することを含むが、重みを適用するための任意の好適な演算が使用され得る。重み値の適用を含む、得られる総パスコストは、3*WBK1+5*WBK2+6*WBK3+5*WBK4=3*1+5*1+6*1+5*1=19であり得る(WBK1は、レストランＦまでのパスのセグメント1の重み値を示し、WBK2は、レストランＦまでのパスのセグメント2の重み値を示す、など)。
【００２７】
レストランＨの場合、ユーザの現在のロケーションからの最短パスは(18,9,1)->(18,3,1)->(10,3,1)であると判断され、このパス長は6+8=14であると判断される(図4)。レストランＨまでのパス長はレストランＦまでのパス長よりも短いが、(18,9,1)から(18,3,1)までのセグメントは、転回することと、ユーザが現在移動している方向と反対である方向に移動することとに関与する。歩行者移動は、多くの観光およびウィンドウショッピングを特徴とすることがある。方向の反転により、ユーザは、ユーザが今しがた移動したのと同じルートを介して戻ることを強いられ、ユーザが今しがた見たのと同じ観光地および店舗を見ることを強いられるので、方向の反転は歩行者環境において理想的でないことがある。方向の反転の重み値は10を割り当てられ得る。移動局100は、たとえば、モールに入ってから移動局100が移動したパスを記憶する機能に基づいて、ユーザが今しがた(18,3,1)から(18,9,1)まで移動したと判断し得る。したがって、(18,9,1)から(18,3,1)までのセグメントは重み値10を割り当てられ得る。(18,3,1)から(10,3,1)までのセグメントの重み値は、(レストランＦに関して上記で説明したように)ベース値1を割り当てられ得る。したがって、レストランＨについて得られる総パスコストは6*10+8*1=68である。別の設計では、セグメント長6に重み値10を乗算する代わりに、方向を反転することについてのペナルティとして好適な重み値が総パスコストに追加され得る。
【００２８】
レストランＩの場合、ユーザの現在のロケーションからの最短パスは(18,9,1)->(18,10,1)->(21,10,1)->(21,7,1)であると判断され、パス長は1+3+3=7であると判断される(図4)。レストランＩまでのパス長は比較的短いが、レストランＩがモール外にあるので、(18,10,1)から(21,10,1)までのセグメントは、モールを離れることに関与する。たとえば、ユーザの現在のベニューからこのように出ることにより、ユーザは、ユーザがよく知っていることがあるベニューを離れることを強いられ、外で場合によっては異なる気象条件に直面することを強いられるので、ユーザの現在のベニューからこのように出ることは歩行者環境において理想的でないことがある。現在のベニューを離れることについての重み値は30を割り当てられ得る。したがって、(18,10,1)から(21,10,1)までのセグメントは重み値30を割り当てられ得る。他のセグメントの重み値は(レストランＦに関して上記で説明したように)ベース値1を割り当てられ得る。得られる総パスコストは1*1+3*30+3*1=94である。
【００２９】
レストランＧの場合、ユーザの現在のロケーションからの最短パスは(18,9,1)->(18,12,1)->(13,12,1)->(13,12,2)->(11,12,2)であると判断され、パス長は3+5+1+2=11であると判断される(図4)。レストランＧまでのパス長は比較的短いが、レストランＧがモールの2階にあるので、(13,12,1)から(13,12,2)までのセグメントは階段に関与する。ショッピングモールの場合、特にユーザがショッピングバッグを携帯しているとき、階段は、関与する身体運動により、歩行者環境における障害を提示し得る。階段に割り当てられる重み値は、20であり得、たとえば、階段の段数に応じて、変動し得る。データベース200は、階段が40段を有することを示す。そのような多数の段を仮定すれば、30などの比較的高い重み値が割り当てられ得る。したがって、(13,12,1)から(13,12,2)までのセグメントは、重み値30を割り当てられ得る(車椅子のユーザの場合、階段の重み値は、極めて高い値、たとえば、100を割り当てられ得る)。他のセグメントの重み値は(レストランＦに関して上記で説明したように)ベース値1を割り当てられ得る。得られる総パスコストは3*1+5*1+1*30+2*1=40である。
【００３０】
レストランＧの場合、ユーザの現在のロケーションからの代替パスがあり、そのパスも比較的短い。そのパスは(18,9,1)->(18,14,1)->(18,14,2)->(18,12,2)->(11,12,2)であると判断され、パス長は5+1+2+7=15であると判断される(図4)。レストランＧまでの代替パスのパス長は比較的短いが、(18,14,1)から(18,14,2)までのセグメントはエレベータに関与する。エレベータは、たとえば、エレベータを待つことに関与する遅延のために、歩行者環境における障害を提示し得る。エレベータに割り当てられる重み値は20であり得る。したがって、(18,14,1)から(18,14,2)までのセグメントは重み値20を割り当てられ得る。ただし、車椅子のユーザの場合、エレベータは、フロアを変更するための唯一の実際的な方法であり得、したがってこの場合、エレベータの重み値は、より低い値(たとえば、10)を割り当てられ得る。レストランＧまでのこの代替パス上の他のセグメントの重み値は(レストランＦに関して上記で説明したように)ベース値1を割り当てられ得る。得られる総パスコストは5*1+1*20+2*1+7*1=34である。この代替パスの総パスコストは、最短パス長をもつパスよりも低いので、この代替パスはオプションとしてユーザに与えられ得る。ユーザがレストランＧのマップ/歩行指示を選択した場合、階段に関与するパスのオプションと、エレベータに関与するパスのオプションとが与えられ得る。
【００３１】
レストランＥの場合、データベース200は、レストランＥの営業時間が午後5時〜午後10時(月曜日〜土曜日)であることを示し、午後1時15分の現在時刻を仮定すれば、レストランＥは、閉店しており、長時間開店しないことになる。したがって、ロケーションアウェア推奨エンジンは、総パスコスト判断をスキップし、単に、レストランＥに、たとえば、最も高い可能な総パスコスト(たとえば、無限大)を割り当て得る。別の設計では、ロケーションアウェア推奨エンジンは、レストランＥについての総パスコスト判断を完全にスキップし、ランク付けされるべき推奨のリストからレストランＥを除外し得る。別の例では、現在の曜日/時刻が土曜日の午後4時50分(レストランＥが開店する10分前)である場合、ロケーションアウェア推奨エンジンは、レストランＥについての総パスコスト判断を進め、レストランＥが午後5時に開店することになることをディスプレイ302上に示し得る。
【００３２】
関連性検索によって返信された、現在のユーザロケーションから各エンティティまでのパス長は、レストランＦ(18)、レストランＨ(14)、レストランＩ(7)、レストランＧ(11)、レストランＥ(該当なし。レストラン閉店)である。図4に関して説明した方法に基づくアクセス可能性基準を考慮に入れた後、各結果の総パスコストは、レストランＦ(18)、レストランＨ(68)、レストランＩ(94)、レストランＧ(階段の場合は40、エレベータの場合は34)、レストランＥ(無限大)である。これらの総パスコストに基づいて、ロケーションアウェア推奨エンジンは、それらの結果を最低総パスコストから最高総パスコストへの順にランク付けし(すなわち、レストランＦ、レストランＧ、レストランＨ、レストランＩ、レストランＥ)、このランク付けされたリストを、たとえば、ディスプレイ302上に表示されるように与え得る。設計に応じて、図4に関して説明した機能および本明細書で説明する他の機能が、MS100、1つまたは複数のサーバ(たとえば、MS100と直接または間接通信しているサーバ)、またはMS100と1つまたは複数のサーバとの組合せによって実行され得る。
【００３３】
図5に、推奨のロケーションアウェア順序付けの別の例を表示する移動局を示す。この例では、現在の曜日/時刻は土曜日の午後6時15分であり、ユーザはモール中のロケーション(18,9,1)にいる(図1A)。ユーザは、午後7時の映画を見る前にテニスラケットを買い、夕食を食べる必要がある。ユーザは、ロケーションアウェア推奨アプリケーションのウィンドウ502中に推奨要求「午後7時の映画の前にテニスラケット、食べ物」を入力する。推奨エンジンは、たとえば、従来の検索エンジンによって利用される構文解析アルゴリズムを介して、入力された情報を解析し、ユーザがテニスラケットを買うための場所と食べ物を得るための場所とについての推奨の時間的制約のある要求を有すると判断し得る。推奨エンジンは、現在時刻が午後6時15分であり、ユーザがテニスラケットと食べ物とを得るためにせいぜい45分しか有しないと判断し得る。「テニスラケット」についての関連性検索が行われ、その結果は、テニスラケットが販売されているエンティティとしてショップＢおよびショップＡを含む。関連性検索は、前に説明したようにデータベース200中の情報に基づき得る。ショップＢが、スポーツ用品を専門に扱い、より多くのテニスラケットと、より良い購買アドバイスとを提供し得るので、関連性検索は、ショップＢがショップＡよりも関連性があると判断し得る。
【００３４】
しかしながら、時間的制約を仮定すれば、推奨エンジンは、たとえば、MS100の歩数計機能によって判断され得るユーザの平均移動速度に基づいて、現在のユーザロケーションからショップＢまでの最短パス長が、あまりに多くの移動時間を要することになると判断し得る。図4に関して上記で説明した方法は、要求の時間的制約のある性質を仮定すれば、ショップＢの欠点を強調するために、たとえば、ショップＢについての総パスコスト判断の最後に好適な値を追加のペナルティとして追加することによって、移動時間を考慮に入れ得る。上記方法は、ショップＡがユーザの現在のロケーションの極近傍にあることに基づいて、テニスラケットを買うための第1位の推奨としてショップＡをランク付けし、ショップＡをアイコン504とともにディスプレイ302上に表示し得、アイコン504は、ユーザが左折してショップＡに到達することができることをユーザに示す、左向き矢印を示している。ショップＡの推奨の隣のアイコン318は、ショップＡが適当な選択肢であることを示している。ディスプレイ302は、テニスラケットを買うための次の推奨としてショップＢを表示し得る。ショップＢの推奨の隣のアイコン320は、ショップＢが適当な選択肢でないことを示し得、アイコン506は、ユーザがショップＢに行こうとする場合、ユーザが急がなければならないことを示し得る。ショップＡの推奨とショップＢの推奨との両方の下の「テニスラケット」リンクは、そのリンクを選択することによって、それぞれの店舗におけるテニスラケットに関するより多くの情報にアクセスし得ることを示し得る。モール中のエンティティにおいて利用可能なテニスラケットおよび他の品目に関する情報は、該当する場合、ブランド、モデル、ピクチャ、価格などを含み、データベース200に記憶され得る。この例における時間的制約がない場合、ロケーションアウェア推奨エンジンは、たとえば、ショップＢのより高い関連性により、ショップＢをショップＡよりも高くランク付けし得る。別の例では、推奨要求は、「5ドルの食べ物」の推奨要求など、金銭的制約に関連し得る。この場合、推奨エンジンは、データベース200のファストフードサブカテゴリー中のレストランが関連性があると判断し得る。ファストフードサブカテゴリー中にないレストランの場合、推奨エンジンは、たとえば、データベース200中の、メニュー/価格情報に基づいて、これらのレストランにおいて必要とされる金額を判断し得る。これらのレストランのうちの1つが、たとえば、5ドル以下である、メニュー上の適当な数の選択肢を有する場合、推奨エンジンは、そのレストランを推奨要求に関連性があると判断し得る。推奨エンジンは、たとえば、図4に関して説明した方法に基づいて、関連性のあるレストランをランク付けし、ランク付けされた結果をMS100上に表示されるように与え得る。推奨エンジンは、他の推奨要求、または推奨要求の組合せ(たとえば、「午後7時の映画の前に50ドル未満のテニスラケット、5ドルの食べ物」など)を処理し得、請求する主題はこの点について限定されない。
【００３５】
図5の例を続けると、食べ物の関連性検索により、等しい関連性がある多くのエンティティが返信され得、なぜなら、それらはすべてモールにおいて食べ物を販売しているからである。ユーザが食べ物を得た後に別の目的地(映画館)を有すると仮定すれば、推奨エンジンは、異なる方法で、図4に関して説明した総パスコスト方法を適用し得る。ここで、ユーザのロケーションを起点として、およびレストランのロケーションを目的地として利用する方法を適用する代わりに、推奨エンジンは、たとえば、ユーザの最終目的地である映画館までの最低総パスコストを有するレストランにユーザを案内することが、時間の最も効率的な使用となるので、レストランのロケーションを起点として、および映画館のロケーションを目的地として利用する方法を適用し得る。午後7時の時間的制約がない場合、上記方法のこの特定の適用例は、レストランＥが現在開店しており、レストランＧおよびレストランＥが映画館までの最低総パスコストを有すると判断し得る。時間的制約に応答して、上記方法は、さらに、レストランＥが高級料理レストランであり、そこで食べ物を得るのに長くかかりすぎることがあると判断し得る。上記方法は、食べ物を得るためのより長い時間を反映するためのペナルティとしてレストランＥの総パスコストに好適な重み値を適用し得る。たとえば、レストランＥにおいて顧客によって必要とされる時間が長くなると、レストランＥはレストランＧよりも利用可能性が少なくなるので、重み値は利用可能性基準の一部として適用され得る。したがって、推奨エンジンは、映画の前に食べ物を得るための第1位の選択肢としてレストランＧを推奨し得る。アイコン508は、ユーザの現在のロケーションからレストランＧに到達することが階段の使用に関与することを示し得る。ディスプレイ302上のアイコン318は、レストランＧが適当な選択肢であることを示し得る。ディスプレイ302上のアイコン320は、レストランＥが適当な選択肢でないことを示し得る。アイコン510は、レストランＥが高級料理レストランであり、したがって時間がかかることを示し得る。
【００３６】
図6に、推奨のロケーションアウェア順序付けの別の例を表示する移動局を示す。この例では、ユーザは、モール中のロケーション(18,9,1)におり(図1A)、化粧室を使用する必要がある。ユーザは周囲を見回し、近傍に化粧室が見つからず、したがって、ユーザはロケーションアウェア推奨アプリケーションのウィンドウ602中に「化粧室」を入力する。推奨エンジンは、入力された情報を解析し、ユーザが最も近い化粧室を探していると判断し、暗黙的にこの要求を時間的制約のあるものとして解釈し得る。関連性検索結果は、すべて等しい関連性をもつ、モール内の4つの化粧室を含み得る。推奨エンジンは、図4に関して説明した総パスコスト方法を関連性検索結果のリストに適用し得る。
【００３７】
化粧室1までの最短パスは、(18,9,1)->(18,12,1)->(7,12,1)であり、パス長が3+11=14であると判断され得る。この例では、化粧室1(7,12,1)への入口の近くに大勢の人々がおり、MS100は、(7,12,1)の近くの推定される位置を有する移動局の数(および、したがって人々の数)によって示されるように、化粧室1への入口の近くに混雑があると判断し得る。MS100は、それが通信しているワイヤレスアクセスポイントを介してこの情報をサーバから受信し得る。したがって、ロケーションアウェア推奨エンジンは、化粧室1の待ち行列があると判断し、化粧室1についての総パスコスト判断に混雑の好適な重み値を追加し得る。化粧室1におけるこの混雑以外に、化粧室1の総パスコストに重み値が適用され得る追加のアクセス可能性基準はない。たとえば、好適な重み値(たとえば、50)が混雑のペナルティとして追加され得、化粧室1の総パスコストは3*1+11*1+50=64であると判断され得る。異なる例では、ユーザが(18,9,1)にいるときにメキシコ料理の推奨要求が入力され得る。関連性検索は、レストランＪおよびレストランＤをメキシコ料理に等しく関連性のあるものとして判断し得る。休暇シーズンであることがあり、アイススケートのパフォーマンスを見るためにアイススケートリンクの周りに集まった大群衆がいることがある。ロケーションアウェア推奨エンジンは、アイススケートリンクの周りの混雑が、レストランＪにつながるパスと干渉することになると判断し、混雑のペナルティとして好適な重み値を適用し得る。レストランＤは、2階にあり、レストランＤに到達するためのフロア変更に関与するが、レストランＤは、この場合、最上位の推奨として判断され得る。
【００３８】
図6の化粧室の例に戻ると、化粧室2までの最短パスは、階段を含むパスであり、すなわち、(18,9,1)->(18,12,1)->(13,12,1)->(13,12,2)->(7,12,2)であり、パス長が3+5+1+6=15であると判断され得る。図4に関して上記で説明したように、階段の重み値は30であり得る。したがって、このパスの総パスコストは3*1+5*1+1*30+6*1=44であり得る。エレベータを含むパスを採用する場合、そのパスは、(18,9,1)->(18,14,1)->(18,14,2)->(18,12,2)->(7,12,2)であり、パス長が5+1+2+11=19であると判断され得る。図4に関して説明したように、エレベータの重み値は20であり得る。したがって、このパスの総パスコストは5*1+1*20+2*1+11*1=38であり得る。しかしながら、エレベータに関与するパスは、エレベータの予測不可能な待ち時間に関与し得、この推奨要求の時間的制約のある性質を仮定すれば、推奨エンジンは、エレベータに関与する化粧室2までのパスを提示しないことがあり、なぜなら、総パスコストはやや高くなるが、移動時間はより予測可能である、(階段を介した)化粧室2までの別のパスが存在するからである。
【００３９】
化粧室3の場合、データベース200は、化粧室3が映画館中に位置し、映画の観客のみがアクセスを有することを示す。したがって、ロケーションアウェア推奨エンジンは、化粧室3についての総パスコスト判断をスキップし、単に、化粧室3に、たとえば、最も高い可能なパスコスト(たとえば、無限大)を割り当て得る。別の例では、ロケーションアウェア推奨エンジンは、ユーザが次の目的地を有し、それが映画館である(たとえば、ユーザが映画を見るつもりである)と判断した場合、化粧室3についての総パスコスト判断を進め得る。さらに別の例では、データベース200は、化粧室が清掃のために閉まっている時間を示し得る。推奨エンジンは、化粧室が清掃のために現在閉まっていると判断した場合、化粧室についての総パスコスト判断をスキップし、単に、化粧室に、たとえば、最も高い可能なパスコスト(たとえば、無限大)を割り当て、ディスプレイ302上に好適なアイコンを表示して、化粧室が閉まっていることを示し得る。同様に、データベース200は、エンティティのうちの1つ(たとえば、エレベータまたはエスカレータ2)が非稼働中であることを示し得、推奨エンジンは、非稼働中のエンティティを利用するパスを回避し得る。
【００４０】
化粧室4までの最短パスは、ショップＡに入ること、ならびにショップＡ内のエスカレータ1を利用することを含むパスであると判断され得る。この例では、ショップＡは、ローカル座標を用いて店舗の内部のマップを表示することができるショップＡ自体のサーバを有する。したがって、データベース200は、化粧室4への入口の座標なしに、化粧室4がモールの2階のショップＡ中にあり、化粧室4が単一の化粧室であるという情報を有するにすぎない。ここで、ロケーションアウェア推奨エンジンは、データベース200によって示されるショップＡの境界に基づいて化粧室4までのパス長を推定し得る。データベース200に基づいて、ショップＡの1階は、座標(13,12,1),(18,12,1),(18,3,1)および(13,3,1)をもつ長方形によって境界を画定され、ショップＡの2階は、座標(13,12,2),(18,12,2),(18,3,2)、および(13,3,2)をもつ長方形によって境界を画定される。これらの境界座標に基づいて、ショップＡは、9ユニット長および5ユニット幅であると推定され得る。したがって、ショップＡの内部を移動する際の最悪のシナリオは、ショップＡの1つの角から対角の角に達することであり、最悪のパス長は9+5=14であり得る(ショップＡの長さ全体に沿って移動し、次いで幅全体に沿って移動する)。この例における最短パスは、(18,9,1)->(18,8,1)->[(ショップＡ1階)->(エスカレータ1)->(ショップＡ2階)]=1+[ショップＡ内で移動]であると判断され得る。この例では、最短パスは、ショップＡの長さに沿ったほぼ中間点である(18,8,1)にある入口を介してショップＡに入るようにユーザを導き得る。したがって、ショップＡ内の任意のポイントまでのユーザにとって最悪の移動距離は、1/2*(ショップＡの長さ)+(ショップＡの幅)=1/2*9+5≒11であると推定され得る。1階のユーザの現在のロケーションからショップＡの2階の化粧室4まで移動することは、エスカレータ1とエスカレータ1に関連する重み値とに関与する。この例では、エスカレータ1は、関与するフロア変更のペナルティとして重み値10を割り当てられ得る。エスカレータは、階段を登ることなどの身体運動、またはエレベータなどを待つことに関与しないので、エスカレータの重み値は、階段およびエレベータの重み値よりも低いことがある。さらに、ショップＡのような大型エンティティの内部を移動することの複雑性のペナルティとして好適な重み値(たとえば、10)が追加され得る。したがって、化粧室4の推定される総パスコストは11+10+10=31であると判断され得る。ユーザがショップＡに入ると、ショップＡのマップがディスプレイ302上に表示されて、化粧室4までのターンバイターン指示が与えられ得る。
【００４１】
化粧室1(64)、化粧室2(44)、化粧室3(無限大)、および化粧室4(31)の総パスコストに基づいて、ロケーションアウェア推奨エンジンは、最低総パスコストから最高総パスコストへの順に、すなわち、化粧室4、化粧室2、化粧室1、および化粧室3の順に化粧室をランク付けし得、化粧室4が最も高く推奨される。検索結果のこのロケーションアウェアランク付けされたリストはディスプレイ302に与えられ得る。ディスプレイ302のアイコン604は、化粧室4までのパスがエスカレータを含むことを示し得る。アイコン318は、化粧室4が適当な選択肢であることを示し得る。アイコン608は、化粧室2までのパスが階段を含むことを示し得る。アイコン606は、推奨要求の時間的制約のある性質を仮定すれば、ユーザが化粧室2に到達するために急ぐ必要があり得ることを示し得る。アイコン320は、化粧室2が適当な選択肢でないことを示し得る。アイコン610は、化粧室1においてまたは化粧室1までのパス上に混雑があることを示し得る。アイコン320は、化粧室1が適当な選択肢でないことを示し得る。アイコン612は、化粧室3が制限付きアクセスを有することを示し得る。アイコン320は、化粧室3が適当な選択肢でないことを示し得る。
【００４２】
いくつかの設計では、ロケーションアウェア推奨エンジンは、たとえば、ユーザアプリケーション中の構成メニューを介して、MS100またはサーバによる自動構成などを介して、構成可能であり得る。たとえば、車椅子のユーザは、ユーザが車椅子に乗っていることを示し得る。それに応答して、推奨エンジンは、ユーザと同じ階/フロアにあるエンティティを、階/フロア変更を必要とし得るエンティティよりも高くランク付けし得る。また、ユーザは、様々なアクセス可能性基準に割り当てられる重み値をカスタマイズし得る。たとえば、ユーザは、推奨されるエンティティに到達するために方向を反転するのを気にしないことがあり、したがって、ユーザは、現在の方向を反転することに関連するデフォルト重み値を好適な値に下げ得る。各推奨に関連する総パスコストは、ある推奨が、たとえば、総パスコストの観点からリスト上の次の推奨に、どのくらい近いかに関する情報をユーザに与えるために、ディスプレイ302上に表示されるように構成され得、これにより、ユーザは、どの推奨を追求すべきかに関してより多くの情報に基づく決定を行うことが可能になり得る。関連性の強調、または推奨結果のロケーションアウェアネスの強調は調整され得る。たとえば、デフォルト設定は、すべての推奨が、たとえば、図4に関して説明した方法に基づいて判断された、総パスコストに従ってランク付けされるべきであることを示し得る。(たとえば、エンティティが閉まっていること、制限付きアクセスを有すること、または要求の時間的制約により、エンティティがアクセス可能でない場合を除いて)すべての推奨が、関連性検索によって判断された、推奨要求との関連性に従ってランク付けされ、最も関連性のある結果が最上位の推奨として記載されるように、また、等しく関連性のある結果が総パスコストに基づいてランク付けされ得るように、ユーザは設定を再構成し得る。別の例として、ユーザは、推奨されるエンティティに到達するためにユーザが移動するのをいとわない最大移動距離を構成し得、最大移動距離よりも長いユーザの現在位置からの総パス長を有するどのエンティティも推奨として含まれないことがある。同様に、ユーザは、エンティティに到達するためにユーザが負うのをいとわない最大総パスコストを構成し得る。1つの設計では、ロケーションアウェア推奨エンジンは、たとえば、ユーザの現在位置に基づく好適なまたはユーザ構成された総パス長/総パスコスト内にある、1つまたは複数のエンティティを判断するようにとの推奨要求を受信すると、ロケーションアウェア検索を実行し、推奨要求との1つまたは複数のエンティティの関連性に基づいてそれらのエンティティをランク付けし得る。
【００４３】
いくつかの設計では、ロケーションアウェア推奨エンジンはそれの設定を自動的に調整し得る。たとえば、ロケーションアウェア推奨エンジンは、ユーザ履歴から、ユーザがレストランＦ、レストランＨ、またはレストランＩよりも頻繁にレストランＧを選択していると判断し、レストランＧをモール中のユーザのお気に入りのハンバーガーレストランであると判断し得る。次回、レストランＧが関連性検索結果の中にあるとき、推奨エンジンは、たとえば、レストランＧの総パスコストを減少させることによって、レストランＧのランクを上げて、レストランＧが適当な代替案の中にある可能性を向上させ得る。別の例として、推奨エンジンは、ユーザ履歴から、ユーザがモールを訪問するときはいつでも、MS100のロケーションがショップＡの境界座標内にあることがしばしば判明したと判断し得る。推奨エンジンは、ショップＡがユーザのお気に入りの店舗のうちの1つであると判断し得、たとえば、ショップＡに立ち寄り、内部を見て歩くための機会をユーザに与えるために、推奨されるエンティティにつながるパスがショップＡの入口のうちの1つの近くにユーザを案内するように、それらのパスの好適な調整を行い得る。
【００４４】
図7は、歩行者環境についての推奨のロケーションアウェア順序付けを生成するための例示的な図である。ブロック701において、検索要求を受信する。ブロック702において、歩行者環境に関連する1つまたは複数の検索結果を判断する。ブロック703において、検索要求に関連する移動局のロケーションを判断する。たとえば、検索要求に関連する移動局は、ユーザが推奨要求を入力するための移動局、または自動推奨要求が入力される移動局などであり得る。たとえば、ブロック703は、ブロック702の前にまたはブロック702と同時に実行され得る。ブロック704において、MSのロケーションと、1つまたは複数の検索結果に関連するロケーション、および/またはアクセス可能性基準のうちの少なくとも1つとに基づいて、1つまたは複数の検索結果の少なくとも一部分をランク付けする。
【００４５】
図8に、ロケーションアウェア推奨エンジンとともに利用され得る移動局と通信するためのシステムのブロック図を示す。MS100は、送信機/受信機(TMTR/RCVR)802と、処理ユニット804と、メモリ806と、センサ/カメラ808と、入力810と、出力812とを含み得る。サーバ800は、処理ユニット820と、メモリ822と、送信機/受信機(TMTR/RCVR)824とを含み得る。サーバ800は、図1Aおよび図1Bのモールなどの歩行者ベニューによって管理され得る。MS100とサーバ800とは、ワイヤレスネットワーク、たとえば、Wi-Fiネットワークなどのワイヤレスローカルエリアネットワークを介して、通信し得る。
【００４６】
MS100は、たとえば、シグナリング、データ、およびメッセージを他のデバイスに送信し、たとえば、シグナリング、データ、およびメッセージを送信機/受信機802を介して他のデバイスから受信し得る。送信機/受信機802は、Wi-Fiトランシーバ、セルラートランシーバ、GPS受信機、Bluetooth(登録商標)トランシーバ、USBトランシーバなどを含み得る。メモリ806は、ロケーションアウェア推奨エンジンとともに、ベニューのマップ(たとえば、図1Aおよび図1B)、データベース200、ロケーションアウェア推奨アプリケーション、ユーザ履歴など、情報とコードとを記憶し得る。設計に応じて、処理ユニット804は、たとえば、メモリ806に記憶されたコードの指示に基づいて、図7に示す様々な機能と、本明細書で説明する他の機能とを実行するか、またはそれらの機能の実行を指示し得る。センサ/カメラ808は、加速度計、ジャイロスコープ、高度計、温度センサ、周辺光センサ、(たとえば、高精細度画像および映像が可能な)デジタルカメラなどを含み得る。入力810は、マイクロフォンシステム(たとえば、雑音消去マイクロフォンシステム)、キーパッド/キーボード(たとえば、キーパッド/キーボード316)、タッチ/感知機能をもつディスプレイスクリーン(たとえば、ディスプレイ302)、ノブ/ホイール、HDMI(登録商標)受信機などを含み得る。出力812は、スピーカー、ディスプレイスクリーン(たとえば、ディスプレイ302)、プロジェクタ、ぶれ/振動生成器、HDMI(登録商標)送信機などを含み得る。MS100は、説明したようにMS100の現在のロケーションを判断し、MS100の現在のロケーションをサーバ800に送信し得る。
【００４７】
サーバ800は、たとえば、シグナリング、データ、およびメッセージを他のデバイスに送信し、たとえば、シグナリング、データ、およびメッセージを送信機/受信機824を介して他のデバイスから受信し得る。送信機/受信機824は、Wi-Fiトランシーバ、イーサネット(登録商標)接続、Bluetooth(登録商標)トランシーバ、USBトランシーバなどを含み得る。メモリ822は、ロケーションアウェア推奨エンジンとともに、ベニューのマップ(たとえば、図1Aおよび図1B)、データベース200、およびベニュー中のWi-Fiアクセスポイント/フェムトセルのロケーションなど、情報とコードとを記憶し得る。設計に応じて、処理ユニット820は、たとえば、メモリ822に記憶されたコードの指示に基づいて、図7に示す様々な機能と、本明細書で説明する他の機能とを実行するか、またはそれらの機能の実行を指示し得る。
【００４８】
本明細書で使用する移動局(MS)は、セルラーまたは他のワイヤレス通信デバイス、パーソナル通信システム(PCS)デバイス、パーソナルナビゲーションデバイス(PND)、個人情報マネージャ(PIM)、携帯情報端末(PDA)、ラップトップ、タブレット、ネットブック、スマートブック、あるいはワイヤレス通信および/またはナビゲーション信号を受信することが可能な他の適切なモバイルデバイスなどのデバイスを指す。また、「移動局」という用語は、衛星信号受信、支援データ受信、および/または位置に関係する処理が当該デバイスにおいて行われるかパーソナルナビゲーションデバイス(PND)において行われるかにかかわらず、短距離ワイヤレス、赤外線、ワイヤライン接続、または他の接続などによってPNDと通信するデバイスを含むものとする。また、「移動局」は、衛星信号受信、支援データ受信、および/または位置に関係する処理が当該デバイスにおいて行われるか、サーバにおいて行われるか、またはネットワークに関連する別のデバイスにおいて行われるかにかかわらず、インターネット、Wi-Fi、または他のネットワークなどを介してサーバとの通信が可能である、ワイヤレス通信デバイス、コンピュータ、ラップトップなどを含むすべてのデバイスを含むものとする。上記の任意の動作可能な組合せも「移動局」と見なされる。
【００４９】
本明細書で説明する方法は、適用例に応じて様々な手段によって実装され得る。たとえば、これらの方法は、ハードウェア、ファームウェア、ソフトウェア、またはそれらの任意の組合せで実装され得る。ハードウェアに関与する実装形態の場合、処理ユニットは、1つまたは複数の特定用途向け集積回路(ASIC)、デジタル信号プロセッサ(DSP)、デジタル信号処理デバイス(DSPD)、プログラマブル論理デバイス(PLD)、フィールドプログラマブルゲートアレイ(FPGA)、プロセッサ、コントローラ、マイクロコントローラ、マイクロプロセッサ、電子デバイス、本明細書で説明する機能を実行するように設計された他の電子ユニット、またはそれらの組合せの中で実装され得る。
【００５０】
ファームウェアおよび/またはソフトウェアに関与する実装形態の場合、本方法は、本明細書で説明する機能を実行するモジュール(たとえば、プロシージャ、機能など)を用いて実装され得る。命令を有形に実施するいずれの機械可読媒体も、本明細書で説明する方法の実装において使用され得る。たとえば、ソフトウェアコードは、メモリに記憶され、処理ユニットによって実行され得る。メモリは、処理ユニットの内部または処理ユニットの外部に実装され得る。本明細書で使用する「メモリ」という用語は、長期メモリ、短期メモリ、揮発性メモリ、不揮発性メモリ、または他のメモリのいずれかのタイプを指し、メモリの特定のタイプまたはメモリの数、あるいはメモリが記憶される媒体のタイプに限定されない。
【００５１】
ファームウェアおよび/またはソフトウェアに関与する実装形態の場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶され得る。例としては、データ構造で符号化されたコンピュータ可読媒体、およびコンピュータプログラムで符号化されたコンピュータ可読媒体がある。コンピュータ可読媒体は製造品の形態をとり得る。コンピュータ可読媒体は物理的コンピュータ記憶媒体を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。限定ではなく、例として、そのようなコンピュータ可読媒体は、RAM、ROM、EEPROM、CD-ROMまたは他の光ディスク(disk)ストレージ、磁気ディスク(disk)ストレージ、半導体ストレージ、または他の記憶デバイス、あるいは命令またはデータ構造の形態で所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を含むことができ、本明細書で使用するディスク(disk)およびディスク(disc)は、コンパクトディスク(disc)(CD)、レーザディスク(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フレキシブルディスク(disk)およびブルーレイディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。
【００５２】
コンピュータ可読媒体上での記憶に加えて、命令および/またはデータは通信装置中に含まれる伝送媒体上の信号として与えられ得る。たとえば、通信装置は、命令とデータとを示す信号を有するトランシーバを含み得る。命令およびデータは、1つまたは複数の処理ユニットに、特許請求の範囲で概説する機能を実装させるように構成される。すなわち、通信装置は、開示する機能を実行するための情報を示す信号をもつ伝送媒体を含む。初めに、通信装置中に含まれる伝送媒体は、開示する機能を実行するための情報の第1の部分を含み得、次に、通信装置中に含まれる伝送媒体は、開示する機能を実行するための情報の第2の部分を含み得る。
【００５３】
発明を実施するための形態のいくつかの部分は、特定の装置あるいは専用コンピューティングデバイスまたはプラットフォームのメモリ内に記憶される2値デジタル信号に対する演算のアルゴリズムまたは記号表現に関して提示された。本明細書のコンテキストでは、特定の装置、専用装置などの用語は、プログラムソフトウェアからの命令に従って特定の機能を実行するようにプログラムされた後の汎用コンピュータを含む。アルゴリズムの説明または記号表現は、信号処理または関連技術において当業者が、それらの仕事の本質を他の当業者に伝達するために使用する技法の例である。アルゴリズムは、本明細書では、また一般に、所望の結果をもたらす自己無撞着な一連の演算または同様の信号処理であると考えられる。このコンテキストでは、演算または処理は物理量の物理操作に関与する。必ずしもそうとは限らないが、一般に、そのような量は、記憶、転送、組合せ、比較、または他の操作が可能な、電気信号または磁気信号の形態をとり得る。
【００５４】
主に一般的な用法という理由で、そのような信号をビット、データ、値、要素、記号、文字、項、数、数字などと呼ぶことは時々便利であることがわかっている。ただし、これらおよび同様の用語はすべて、適切な物理量に関連すべきものであり、便利なラベルにすぎないことを理解されたい。別段に明記されていない限り、本明細書全体にわたって、「処理する」、「算出する」、「計算する」、「判断する」などの用語を利用する説明は、専用コンピュータまたは同様の専用電子コンピューティングなど、特定の装置のアクションまたはプロセスを指すことを諒解されたい。したがって、本明細書のコンテキストでは、専用コンピュータまたは同様の専用電子コンピューティングデバイスは、専用コンピュータまたは同様の専用電子コンピューティングデバイスのメモリ、レジスタ、または他の情報記憶デバイス、送信デバイス、あるいは専用コンピュータまたは同様の専用電子コンピューティングデバイスのディスプレイデバイス内の電子的または磁気的な物理量として一般に表される信号を操作または変換することが可能である。たとえば、特定のコンピューティング装置、専用装置などは、1つまたは複数の特定の機能を実行するための命令を用いてプログラムされた処理ユニットを含み得る。
【００５５】
本明細書で言及する「命令」は、1つまたは複数の論理演算を表す表現に関係する。たとえば、命令は、1つまたは複数のデータオブジェクトに対して1つまたは複数の演算を実行するために機械によって解釈可能であることによって「機械可読」であり得る。ただし、これは命令の一例にすぎず、請求する主題はこの点について限定されない。別の例では、本明細書で言及する命令は、符号化コマンドを含むコマンドセットを有する処理ユニットによって実行可能である符号化コマンドに関係し得る。そのような命令は、処理ユニットによって理解される機械語の形態で符号化され得る。この場合も、これらは命令の例にすぎず、請求する主題はこの点について限定されない。
【００５６】
別段に記載されていない限り、本明細書で説明する本発明の実施形態による特許請求の範囲の機能、ステップおよび/またはアクションは特定の順序で実行される必要はない。さらに、本発明の要素は、単数形で説明または請求されていることがあるが、単数形に限定することが明示的に述べられていない限り、複数形が企図される。現在例示的な特徴と考えられていることを例示し説明したが、請求する主題を逸脱することなく、様々な他の変更が行われ得、均等物が代用され得ることが、当業者には理解されよう。さらに、本明細書で説明する中心概念から逸脱することなく、請求する主題の教示に特定の状況を適合させるために多くの変更が行われ得る。したがって、請求する主題は、開示された特定の例に限定されず、そのような請求する主題は、添付の特許請求の範囲内に入るすべての態様、およびその均等物をも含み得る。
【符号の説明】
【００５７】
100  移動局
200  データベース
302  ディスプレイ
304  ウィンドウ
316  キーパッド/キーボード
502  ウィンドウ
602  ウィンドウ
800  サーバ
802  送信機/受信機(TMTR/RCVR)
804  処理ユニット
806  メモリ
808  センサ/カメラ
810  入力
812  出力
820  処理ユニット
822  メモリ
824  送信機/受信機(TMTR/RCVR)
【図１Ａ】
2014160093.tif 000003
【図１Ｂ】
2014160093.tif 000004
【図２】
2014160093.tif 000005
【図３】
2014160093.tif 000006
【図４】
2014160093.tif 000007
【図５】
2014160093.tif 000008
【図６】
2014160093.tif 000009
【図７】
2014160093.tif 000010
【図８】
2014160093.tif 000011