移動デバイスロケータシステム
【課題】デバイスの位置をリファインするコンピュータ実行方法を提供すること。
【解決手段】移動デバイス（２０４）は、アプリケーションプログラミングインターフェース（ＡＰＩ）（２２２）を介して配置され得る。デバイスのロケーションはファジー理論を用いてリファインされ得る。不正確な入力（７０２）は、規則ベース（７０６）において特定の大きさを決定するよう進められる。規則ベースにおける規則は、大きさに基づき適用され、正確なロケーションを計算するために利用される論理演算結果を作成する。さらに、外部データベースにおけるユーザのプロファイル情報は、ロケーションをイネーブルにされ得る。データベース、外部キー、位置情報からプロパティを抽出するユーザのプロファイル情報、データソース情報、ＳＱＬ命令文を有するスキーマ定義がデータベースに格納され、格納された情報へのアクセスが提供される。
【解決手段】移動デバイス（２０４）は、アプリケーションプログラミングインターフェース（ＡＰＩ）（２２２）を介して配置され得る。デバイスのロケーションはファジー理論を用いてリファインされ得る。不正確な入力（７０２）は、規則ベース（７０６）において特定の大きさを決定するよう進められる。規則ベースにおける規則は、大きさに基づき適用され、正確なロケーションを計算するために利用される論理演算結果を作成する。さらに、外部データベースにおけるユーザのプロファイル情報は、ロケーションをイネーブルにされ得る。データベース、外部キー、位置情報からプロパティを抽出するユーザのプロファイル情報、データソース情報、ＳＱＬ命令文を有するスキーマ定義がデータベースに格納され、格納された情報へのアクセスが提供される。
【発明の詳細な説明】
【技術分野】
【０００１】
関連する出願の相互参照
本願は、以下の同時係属中かつ同一人に譲渡された特許出願に基きその優先権を主張するものであり、それらの出願は本明細書において参照のため援用する。
【０００２】
米国特許出願第１０／０３７，８０５号、 Ｎｅｍｍａｒａ ＣｈｉｔｈａｍｂａｒａｍおよびＪｏｈｎ Ｒｉｃａｒｄｏ ＤｅＡｇｕｉａｒによる、名称「ＭＯＢＩＬＥ ＤＥＶＩＣＥ ＬＯＣＡＴＯＲ ＡＤＡＰＴＥＲ ＳＹＳＴＥＭ ＦＯＲ ＬＯＣＡＴＩＯＮ ＢＡＳＥＤ ＳＥＲＶＩＣＥＳ」、代理人整理番号第Ｇ＆Ｃ３０５６６．２０１−ＵＳ−０１号、２００１年１２月２６日出願、
米国特許出願第１０／０３４，４４０号 Ｎｅｍｍａｒａ ＣｈｉｔｈａｍｂａｒａｍおよびＳｃｏｔｔ Ｄｉｎｇによる、名称「ＬＯＣＡＴＩＯＮ ＢＡＳＥＤ ＳＥＲＶＩＣＥＳ ＢＲＩＤＧＥ ＴＯ ＥＸＴＥＲＮＡＬ ＤＡＴＡ ＳＯＵＲＣＥＳ」、代理人整理番号第Ｇ＆Ｃ３０５６６．２０４−ＵＳ−０１号、２００１年１２月２６日出願、
米国特許出願第１０／０３４，４４２号 Ｎｅｍｍａｒａ Ｃｈｉｔｈａｍｂａｒａｍによる、名称「ＦＵＺＺＹ ＬＯＧＩＣ ＲＥＡＳＯＮＩＮＧ ＦＯＲ ＩＮＦＥＲＲＩＮＧ ＵＳＥＲ ＬＯＣＡＴＩＯＮ ＰＲＥＦＥＲＥＮＣＥＳ」、代理人整理番号第３０５６６．２０５−ＵＳ−０１号、２００１年１２月２６日出願。
【０００３】
本願は、以下の同時係属中かつ同一人に譲渡された特許出願に関し、本明細書においてそれらを参照のため援用する。
【０００４】
米国特許出願第０９／６２９，１１５号 Ｎｅｍｍａｒａ Ｃｈｉｔｈａｍｂａｒａｍらによる、名称「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＰＲＯＶＩＤＩＮＧ ＡＣＣＥＳＳ ＴＯ ＭＡＰＳ ＯＮ Ａ ＰＥＲＳＯＮＡＬ ＤＩＧＩＴＡＬ ＡＳＳＩＳＴＡＮＴ（ＰＤＡ）」、代理人整理番号第３０５６６．９６ＵＳＵ１号，２０００年７月３１日出願、
米国特許出願第０９／６２８，８５１号 Ｅｄｗａｒｄ Ｊ．Ｃｏｎｎｏｒらによる、名称「ＧＥＯＧＲＡＰＨＩＣＡＬ ＤＡＴＡ ＭＡＲＫＵＰ ＯＮ Ａ ＰＥＲＳＯＮＡＬ ＤＩＧＩＴＡＬ ＡＳＳＩＳＴＡＮＴ（ＰＤＡ）」代理人整理番号第３０５６６．９７ＵＳＵ１号、２０００年７月３１日出願、
米国特許出願第０９／６２８，８５０号 Ｎｅｍｍａｒａ Ｃｈｉｔｈａｍｂａｒａｍらによる、名称「ＧＥＮＥＲＡＬＩＺＥＤ，ＤＩＦＦＥＲＥＮＴＩＡＬＬＹ ＥＮＣＯＤＥＤ，ＩＮＤＥＸＥＤ ＲＡＳＴＥＲ ＶＥＣＴＯＲ ＤＡＴＡ ＡＮＤ ＳＣＨＥＭＡ ＦＯＲ ＭＡＰＳ ＯＮ Ａ ＰＥＲＳＯＮＡＬ ＤＩＧＩＴＡＬ ＡＳＳＩＳＴＡＮＴ」、代理人整理番号第３０５６６．９８ＵＳＵ１号、２０００年７月３１日出願、
米国出願第０９／７９５，７１９号 Ｔｉｍｏｔｈｙ Ｊｏｈｎ Ｎｅｌｓｏｎらによる、名称「ＩＮＴＥＲＰＲＯＣＥＳＳ ＡＰＰＬＩＣＡＴＩＯＮ ＰＲＯＧＲＡＭＭＩＮＧ ＩＮＴＥＲＦＡＣＥ ＦＯＲ ＰＥＲＳＯＮＡＬ ＤＩＧＩＴＡＬ ＡＳＳＩＳＴＡＮＴ ＡＰＰＬＩＣＡＴＩＯＮＳ」、代理人整理番号第３０５６６．１１０ＵＳＵ１号、２００１年２月２８日出願、
米国出願第０９／７９５，８９０号 Ｎｅｍｍａｒａ Ｃｈｉｔｈａｍｂａｒａｍらによる、名称「ＳＩＮＧＬＥ ＧＥＳＴＵＲＥ ＭＡＰ ＮＡＶＩＧＡＴＩＯＮ ＧＲＡＰＨＩＣＡＬ ＵＳＥＲ ＩＮＴＥＲＦＡＣＥ ＦＯＲ Ａ ＰＥＲＳＯＮＡＬ ＤＩＧＩＴＡＬ ＡＳＳＩＳＴＡＮＴ」、代理人整理番号第３０５６６．１１１ＵＳＵ１号、２００１年９月５日出願、
米国特許出願第０９／６２９，１１７号 Ｈｏｗａｒｄ Ｍａｒａｎｔｚらによる、名称「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＯＢＴＡＩＮＩＮＧ Ａ ＳＥＴ ＯＦ ＭＡＰＳ」、代理人整理番号第３０５６６．１１２ＵＳＵ１号、２０００年７月３１日出願、
特許協力条約出願番号ＰＣＴ／ＵＳ００／２６４３６号 Ｎｅｍｍａｒａ Ｃｈｉｔｈａｍｂａｒａｍらによる、名称「ＧＥＯＧＲＡＰＨＩＣ ＭＡＰＳ ＯＮ Ａ ＰＥＲＳＯＮＡＬ ＤＩＧＩＴＡＬ ＡＳＳＩＳＴＡＮＴ（ＰＤＡ）ＡＮＤ ＳＥＲＶＥＲ」、代理人整理番号第３０５６６．１２４−ＷＯ−Ｉ１号、２０００年９月２６日出願、
米国特許出願第０９／４１１，５０６号 Ｇｒｅｇｏｒｙ Ａ．Ｒｏｙらによる、名称「ＶＥＣＴＯＲ−ＢＡＳＥＤ ＧＥＯＧＲＡＰＨＩＣ ＤＡＴＡ」、代理人整理番号第３０５６６．１７ＵＳＣ１号、１９９９年１０月４日出願。これは、Ｇｒｅｇｏｒｙ Ａ．Ｒｏｙらによる、「ＶＥＣＴＯＲ−ＢＡＳＥＤ ＧＥＯＧＲＡＰＨＩＣ ＤＡＴＡ」という名称の、１９９９年１０月１２日に付与された米国継続特許第５，９６６，１３５号（１９９６年１０月３０日出願の出願第０８／７５７，７０６号）である。
【０００５】
（技術分野）
本発明は、一般に、ロケーションベースのサービスに関し、特に、移動デバイスのロケーションを検出しロケーションの精度をあげるための方法、装置、および製造品（ａｒｔｉｃｌｅ ｏｆ ｍａｎｕｆａｃｔｕｒｅ）に関する。
【背景技術】
【０００６】
（関連技術の説明）
（例えば、携帯電話、ＰＤＡ（ｐｅｒｓｏｎａｌ ｄａｔａ ａｓｓｉｓｔａｎｔ 携帯情報端末機器）などの）移動デバイスのロケーションの検出は、ＬＢＳ（ｌｏｃａｔｉｏｎ ｂａｓｅｄ ｓｅｒｖｉｃｅｓ ロケーションベースのサービス）の提供にとって基本的なものである。ロケーションベースのサービスは、デバイス／（例えば、携帯電話、ＰＤＡなどの）移動デバイスを利用するかまたはそれに基く、アプリケーション／サービスである。例えば、ユーザが最も近い娯楽の選択肢を要求する場合、デバイスが特定の通り（例えばＭｃＩｎｎｉｓ Ｐａｒｋｗａｙ）に位置することを検出することで、ＬＢＳアプリケーションが、（例えば、Ｎｏｒｔｈｇａｔｅ Ｍａｌｌ Ｃｉｎｅｍａなどの）近くの劇場を提供し得る。ＬＢＳアプリケーションのさらなる例として、交通情報の更新、ロケーションが重要である広告、隊の管理、および、資産と人々の追跡を含む、
しかし、ロケーション情報の提供に、異なるプロトコルが異なる携帯電話キャリアによって使用され得る。したがって、従来技術では、ロケーション情報を提供するために、ＬＢＳアプリケーションが、それぞれの携帯電話キャリアのために個々に構成されなければならない。そのような構成のカスタマイズは、ＬＢＳのプロバイダにとって、時間がかかり、絶え間ない複数の修正／更新、およびわずらわしさが必要となる。
【０００７】
さらに、個々のユーザにとっては、ユーザに関して知られている情報に基くＬＢＳアプリケーションのカスタマイズが望ましい。しかし、そのような情報は、たびたび地域的に使用できず、アクセスすることが困難であるかまたは不可能である。したがって、必要とされるのは、ユーザの個人情報にアクセスし使用し得ることである。
【０００８】
さらに、現在、従来技術の無線キャリアによって提供されるデバイスのロケーションは、おおざっぱな（例えば、精度に、数百メートルから１０００メートル以上の幅がある）ものである。したがって、ＬＢＳサービスは、そのサービスを価値のあるものとするために、このロケーションの精度を上げることが必要である。
【０００９】
これらの問題は、従来技術のロケーション検出および個人情報の使用についての説明によって、よりよく理解され得る。
【００１０】
（従来技術のロケーション検出）
上記のように、デバイスのロケーションを決定し、ＬＢＳアプリケーションにデバイスのロケーションを提供するために、数多くの方法／プロトコルが移動デバイスキャリアによって使用される。例えば、デバイスの認識のために、異なる方法が使用され得る。さらに、キャリアの移動位置標定サーバ（ＭＰＳ）との通信のために、異なるプロトコルが使用され得る。移動位置標定サーバとリクエスト／応答を交換するための異なる形式がまた使用され得る。さらに、異なるレベルの、ロバスト性、エラー処理、およびネットワーク基盤の安定性がある。
【００１１】
ＭＰＳによって提供されるロケーションは、しばしば、精度／正確さのレベルが異なっている。例えば、ほとんどのロケーション技術はセルセクタベース（つまり、ロケーションは、単に、ある特定のセルセクタ内にあるとして識別される）である。したがって、ＭＰＳによって提供される近似のロケーションは、１５０メートルから数百メートル、または１０００メートル以上も、デバイスの実際のロケーションから離れていることもあり得る。したがって、ほとんどのＭＰＳサービスは、非常に不正確な、移動デバイスがその範囲内にいる、地理的地域を提供するのみである。
【００１２】
そのように異なる方法の使用は、ＬＢＳプロバイダにとって問題を含む。ほとんどのＬＢＳプロバイダの興味の中心は、デバイスのロケーションを利用するアプリケーション／ビジネスロジックにある。しかし、多くの環境およびプラットフォームで使用されるアプリケーションにとって、各セルラープロバイダのためにアプリケーションをカスタマイズするには、かなりの時間とプログラミングが必要である。
【００１３】
さらに、ロケーションの不正確さが、ユーザにとってのＬＢＳアプリケーションの価値に影響を及ぼす。例えば、ビジネス／娯楽検索、友人探し、および／またはルート検索などの、より人気のあるＬＢＳアプリケーションは、近似現在ロケーションがさらに正確な場合、ユーザにとって、さらに非常に価値のあるものであり得る。したがって、必要とされるのは、近似ロケーションを、より正しくユーザの真の居所を表すロケーションへ、またはユーザがすぐに識別し得るユーザの近くの著名な目標物（ｌａｎｄｍａｒｋ）へと、さらに詳細に修正する性能である。
【００１４】
図１は、近似ロケーションと、ロケーションの不正確さを表すエラー多角形を示す。デバイスの近似ロケーションは円１００として示される。エラー多角形１０２はロケーションの不正確さを表す。従来技術における問題は、ユーザの真のロケーションを表す可能性のある、修正されたロケーションの生成にある。さらに、その修正は、ユーザの現在ロケーションの近傍にあり、ユーザによって直ぐに識別されるのに十分に顕著である、ロケーション１０４を生成することが期待される。さらに、最も最良の場合、この修正されたロケーション１０４がユーザの真のロケーションと等しい。
【００１５】
（従来技術のユーザカスタマイズ）
ＬＢＳアプリケーションは、ユーザについての個人情報（つまり、ユーザのプロファイルの情報）を用いて、個々のユーザのためにカスタマイズがなされ得る。例えば、このユーザのプロファイル情報には、ユーザ名、自宅／職場住所、および、料理、旅行の好みなどに関する嗜好でさえ含み得る。この情報を、（例えば携帯電話の）無線デバイスに送信することによって、ＬＢＳアプリケーションは、ユーザの好みに適するように、高度にカスタマイズされ得る。この個人化されたデータは、現在、電話交換機、無線キャリアデータベースなどから入手し得、たびたび、ＬＢＳデータベースにリロードされる。例えば、携帯電話キャリアによって保存されているプロファイル情報を利用するために、全てのデータベースが送られ得、かつローカルに格納され得る。
【００１６】
個人化された情報のそのようなリロードは、コストの増加（つまり、時間、努力、金銭）、同期化問題（つまり、時間の経過によって、ソースおよびＬＢＳデータベースに複製されたデータとの間に差が出来上がる。さらに、データは、異なる製造元の異なるデータベースから、または、異なるオペレーションシステムの異なるファイルから、異なる形式で、異なるスキーマで入ってき得、顧客データは、ＬＢＳを認識しない（つまり、ロケーション要素を有さない）。さらに、移動電話キャリアが、データベースの送信を許可しないこともあり得る。
【発明の概要】
【課題を解決するための手段】
【００１７】
（発明の要旨）
本発明の１つ以上の実施形態が、多くの移動デバイスキャリアおよび／またはファジー論理を用いて、デバイスのロケーションを決定し、ユーザのプロファイル／個人情報に基く特定のユーザのためのロケーションベースのサービスをカスタマイズするための、方法、システム、装置、および製造品を提供する。
【００１８】
デバイスロケータ（デバイスロケータアダプタとも呼ばれる）が、ユーザのために、共通の一様なアプリケーションプログラムインターフェース（ＡＰＩ）を提供する。デバイスのロケーションを割り出しているとき、ＡＰＩは、アプリケーション開発者を切り離し、かつそれら開発者が特定の移動デバイスキャリアを無視できるようにする。デバイスロケータは、キャリアからリクエストされると、特定のキャリアの位置標定サーバ、およびデバイスを識別する異なる方法（例えば、携帯電話番号、無線用途リクエストの「ｃｏｏｋｉｅ」中に符号化されるＭＳＩＳＤＮ（ｍｏｂｉｌｅ ｓｕｂｓｃｒｉｂｅｒ ｉｎｔｅｒｎａｔｉｏｎａｌ ｓｕｂｓｃｒｉｂｅｒ ｄｉｒｅｃｔｏｒｙ ｎｕｍｂｅｒ）、リクエストヘッダの中に符号化されるＩＰアドレス、またはユーザプロファイルデータベースの中の事前に格納されたデフォルト）と相互作用する。さらに、デバイスロケータは、キャリアのプロトコルの相違（例えば、ＨＴＴＰ，ＨＴＴＰＳ，など）に対処する。デバイスロケータは、キャリア基盤内のネットワークの不安定さに対処することによってロバスト性を提供する。
【００１９】
ロケーションベースサービスは、アプリケーションおよび内容が自動的にユーザの現在の活動プロファイルと整合するように作成される場合、ユーザにとっての価値が非常に上がり得る。例えば、通勤客は、列車やバスの駅、および目的地に早く到着するための別の経路を詳しく見ることに興味を持ち得るが、一方、レジャーの旅行者は、「旅行者にとっての目標地点（ｔｏｕｒｉｓｔ ｌａｎｄｍａｒｋｓ）」への簡単なアクセスを望む。
【００２０】
したがって、一旦ＡＰＩを介してデバイスの近似ロケーションが決定されると、その近似ロケーションは１つ以上の思考モデルを適用して移動位置標定サーバによって修正され得る。例えば、近似ロケーションは、市街ネットワーク上の最短地点へと素早く動かされ得るか、または近隣のランドマーク、または「見どころ」へと素早く動かされ得る。あるいは、その修正は、近似ロケーションの近隣で、（例えば、ユーザプロファイルの「履歴」を調べることによって）移動デバイスユーザが最近訪れたロケーションを探し得る。さらに、近似ロケーションは、移動デバイスユーザによってブックマークされた「お気に入り」のロケーションを調べることによって、および近似のデバイスロケーションの近隣に何らかの「お気に入り」のロケーションがあるかどうかを決定することによって、修正され得る。
【００２１】
さらに、新しいキャリアを利用するために、またはシステムに常駐するキャリアを修正するために、単に、新しいアダプタが追加されるだけである。アプリケーション開発者の立場からするとＡＰＩは同じままであり、全システムの新しいバージョンが配備される必要はない。したがって、本発明では、新しいアダプタが、動的に配備され使用される。
【００２２】
さらに、ユーザの現在ロケーションのインテリジェント推論および活動プロファイル（または意図）が不必要な内容の排除を助け、無線アクセスのコスト、時間および性能が向上する。本発明の１つ以上の実施形態は、ユーザの現在ロケーションについてインテリジェント推量をするために、ファジー論理推論と呼ばれる人工知能の分岐（ブランチ）を使用し、かつ（例えば、このユーザはビジネスの旅行者か？ 職場の近くにいるか？ または列車の駅の近くにいる通勤客か？など）ユーザの現在の活動プロファイルの意図を推論する。
【００２３】
本明細書に説明するモデルは、曖昧で、不正確で、重複し、競合する入力を捕捉するための正式な構造を提供する。例えば、このモデルは、「ユーザの現在の活動はレジャーの旅行客のプロファイルと整合するか？」との質問に、純然たる「はい」／「いいえ」に対して、「多分整合する」または「はっきりしない」という答えを作成し得るという事実を処理し得る。同様に、このモデルは、ユーザの現在の活動は、ビジネスの旅行者のプロファイルおよびレジャーの旅行者のプロファイルの両方に整合し得るという事実も考慮し得る。
【００２４】
入力は、空間的、時間的（時間に関連した）、空間的−時間的（速度ベクター）、および活動プロファイルのインジケータを含む。このモデルは、入力の参加の度合い（たとえば、ことによると（ｐｅｒｈａｐｓ）＝０．４、おそらく（ｌｉｋｅｌｙ）＝０．６、非常にあり得る（ｖｅｒｙ ｌｉｋｅｌｙ）＝０．８）を決定する自然な言語の記述（すなわち入力）を翻訳するメンバーシップ関数を提供する。
【００２５】
さらに、このモデルは、問題に対する現在の理解状況を、入力および出力に関係する直観的な、人の言語の規則ベースで表し得る。例えば、規則は、「仮にＸおよびＹとすると、その場合はＺである」（例えば、もし曇りおよび外套なら、雨であり得る）という形式であり得る。すべての規則を含む規則ベースは、（例えば、中央アメリカのシエスタ(昼寝）の時間中の施設の閉鎖を考慮するなど）地域的、社会的、または人口統計学的動向を反映するように、簡単に構成され得る。
【００２６】
メンバーシップ関数の評価に基いて規則を入力に適用することによって、推論エンジンが、規則を処理し、明確な答えを修正されたロケーションとして提供する。この答えは、アプリケーションによって要求されるように、１つの修正されたロケーションまたは候補地リストであり得る。
【００２７】
その結果、ユーザの現在のロケーションが推理、推論され得、いくつかの「活動プロファイル」の１つに分類され得る。このことによって、次に、アプリケーションが、無線キャリアによって蓄積された膨大な量のプロファイル情報の価値を高め得、アプリケーションおよび無線デバイスに配信された内容の両方を個人化することによって、利用者に提供されるサービスの価値が向上する。
【００２８】
一旦ロケーションが修正されると、ロケーションベースサービスはユーザのプロファイル／個人情報に基きカスタマイズされ得る。従来技術のロケーションベースサービスのカスタマイズのために、キャリアによって保持されているデータベースは、データがまだ正確であることを確実にするために、たびたびローカルにコピーされ、頻繁にリロードされた。本発明の１つ以上の実施形態では、すべてのレコードがデータベースの中に残りローカルにコピーされないが、アプリケーションによって他地域／外部データベースにアクセスし得る。
【００２９】
実施形態は、外部プロファイルデータベースへのコンパクトＬＢＳブリッジを設計し、実行する。このＬＢＳブリッジは、（属性の名前、種類、および制約を含む）外部データベースのコンパクトスキーマ定義を含む。ＬＢＳブリッジはまた、（例えば外部データベースとの接続および通信の方法などの）データソース情報およびスキーマ定義に対応する、データソースからプロパティを抽出するＳＱＬステートメントを含む。ＬＢＳデータベース内のテーブルにある各レコードに対する外部キーを格納することによって、外部データソースのレコードが識別される。さらに、外部レコードからのロケーション情報が、抽出／獲得され、ジオコードインデックスとしてテーブルに格納される（そのようにして、外部データベースをＬＢＳイネーブルとする）。サービスの収集が、システムインテグレータへの外部アプリケーションプログラミングインターフェースの形で、こうして利用可能となる。
【００３０】
ＬＢＳブリッジの結果、ロケーションベースサービスは、無線キャリア、電話会社などによって蓄積された大量のプロファイル情報に拡張し得、それが今度は、それらのサービスを、さらに個人化された、エンドユーザにとってさらに価値のあるものにする。したがって、本発明のロケーションの実施形態は、外部のデータベースおよびポータルなどにあるユーザプロファイル情報を可能とし、かつ内部および外部のプロファイル情報の両方を使用してシームレスなロケーションサービスの提供を可能とする。
【００３１】
今度は、図面を参照するが、全体を通して、同様の参照番号は対応する部分を表す。
【図面の簡単な説明】
【００３２】
【図１】図１は、近似ロケーションおよびロケーションの不正確さを表すエラー多角形を示す。
【図２】図２は、本発明の１つ以上の実施形態に従って使用される、ハードウェアおよびソフトウェアの環境の概略を示す。
【図３】図３は、本発明の１つ以上の実施形態による、デバイスロケータをサポートするアーキテクチャを簡単に表したものを示す。
【図４】図４は、本発明の１つ以上の実施形態による、アークとしてモデル化されたロケーションデータを示す。
【図５】図５は、本発明の１つ以上の実施形態による、移動デバイスロケータアダプタシステムのアプリケーションプログラミングインターフェースの使用を示すフローチャートである。
【図６】図６は、本発明の１つ以上の実施形態による、重みつき入力の曖昧な重心として修正されたロケーションを示す。
【図７】図７は、本発明の１つ以上の実施形態による、ファジー論理推論プロセスの概略を示す。
【図８】図８は、本発明の１つ以上の実施形態による、デバイスのロケーションを修正するためのファジー論理推論の使用を示すフローチャートである。
【図９】図９は、本発明の１つ以上の実施形態による、外部データベースのためのスキーマの構造を示す。
【図１０】図１０は、本発明の１つ以上の実施形態による、ユーザプロファイルマネージャを示す。
【図１１】図１１は、本発明の１つ以上の実施形態による、外部データソースへのロケーションベースサービスブリッジの使用を示すフローチャートである。
【発明を実施するための形態】
【００３３】
以下の説明において、本明細書の一部を形成する添付の図面を参照するが、その図面には、実施例として、本発明のいくつかの実施形態が示される。別の実施形態が使用され得、かつ構造的変更が本発明の範囲から逸脱することなくなされ得ることが理解される。
【００３４】
ＡＰＩによって、移動デバイスキャリアにかかわらず、ロケーションベースサービスアプリケ―ションがデバイスのロケーションを決定し得る。キャリアの位置標定サーバ、移動デバイス識別方法、およびプロトコルの特性は、ＡＰＩの方法によって内部的に処理される。したがって、アプリケーションは隔離され、キャリアの特定の細部が透明となる。さらに、ヒューリスティックスを使用して、デバイスの近似ロケーションが修正され得る。
【００３５】
さらに、本発明の１つ以上の実施形態が、デバイスの近似ロケーションを修正するためにファジー論理推論を用いるための方法を提供する。種々の不正確な入力が、メンバーシップ関数によって処理され、間隔「０、１」に沿って３つの真の値が割り当てられる。この真の値が入力の規則への参加の度合いを定義する。その後、１つ以上の規則を含む規則ベースを介し、推論エンジンが真の値に従って入力を処理する。各規則は、真の値を使用し得る前件および修正されたロケーションを特定する後件とを有する。それらのルールが、後件のための真の値を定義する各規則のために（０から１の間隔内で）論理演算結果を生成する。方法は、その後、論理演算結果に基く適切な修正されたロケーションの選択に使用される。
【００３６】
さらに、アプリケーションプログラミングインターフェースを使用して、外部データベースのスキーマの定義と、いかに外部データベースと接続しかつ通信するかを記述するデータソース情報と、実行後すぐに、スキーマ定義に対応するプロパティを外部データベースから抽出するデータベースクエリステートメントとを含むＬＢＳブリッジが作成される。ロケーション情報および外部データベースにある各レコードのための外部キーがテーブルに格納され、どのレコードが、所望のロケーション内にあり、カスタマイズされたロケーションベースサービスの提供のために取り出される必要があるかを決定するのに使用される。一旦特定されると、データベースクエリステートメントと外部データベースから所望の情報を取り出すためのスキーマ定義に記述された情報とを用いて、テーブルのキーが使用される。したがって、ＬＢＳブリッジが、アプリケーションプログラミングインターフェースを介してユーザの個人情報にアクセスするための方法、機器、および製造品を提供する。
【００３７】
（ハードウェア環境）
図２は、本発明の１つ以上の実施形態に従って使用されるハードウェアおよびソフトウェア環境の概略を示す。典型的な分散型データ処理方式のコンピュータシステム２００は、（例えば携帯電話、ＰＤＡ、ＷＩＮＣＥ、またはＰＡＬＭデバイスの）移動デバイスクライアント２０４、または（例えばブラウザを走らせているコンピュータシステムなどの）デスクトップクライアントを利用する技術者とサーバコンピュータ２０６とを接続するために、（インターネットなどの）ネットワーク２０２を利用する。
【００３８】
移動デバイスクライアント２０４は、ＨＰＣ（ｈａｎｄｈｅｌｄ ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ、ハンドヘルドパソコン）、ＰＰＣ（ｐａｌｍ−ｈｅｌｄ ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ，パームヘルドパソコン）またはＰＤＡ、携帯電話、スマート電話（ｓｍａｒｔ ｐｈｏｎｅ）など任意の種類の移動デバイスを含み得る。しかし、本発明の実施形態は、デスクトップクライアントにも同様に実行され得る。（本明細書では）これ以降、移動デバイスクライアント２０４およびデスクトップクライアントは取り替え可能に用いられ得、かつ全種類のクライアント／クライアントコンピュータシステムを参照する。システム２００に使用されるリソースの典型的な組み合わせは、携帯電話網、インターネット、ＬＡＮ，ＷＡＮなどのネットワーク２００、移動デバイス２０４、デスクトップクライアント、およびパソコン、ワークステーション、ミニコンピュ―タまたはメインフレームのサーバ２０６を含み得る。
【００３９】
ネットワーク２０２は、移動デバイスクライアント２０４またはサーバコンピュータ２０６に対し適切なソフトウェアアプリケーションを実行しているデスクトップクライアントと接続する。サーバコンピュータ２０６は、（例えばＷｅｂサーバの）サーバアプリケーション２０８、ＬＢＳアプリケーション２１０、ＭａｐＧｕｉｄｅサービス２１２、および／またはｓｅｒｖｌｅｔ２１４などを含む種々のアプリケーションを実行し得る。ＭａｐＧｕｉｄｅサーバ２１２およびｓｅｒｖｌｅｔ２１４は、サーバアプリケーション２０８内またはその部分に常駐し得る。サーバ２０６およびそのコンポーネントはまた、バックオフィスシステム（ｂａｃｋ ｏｆｆｉｃｅ ｓｙｓｔｅｍ）とも呼ばれる。そのようなバックオフィスシステムは企業データベース、同期ユーティリティなどへのアクセスを保持する。サーバアプリケーション２０８は、通常、ＵＮＩＸ（登録商標） Ａｐａｃｈｅ ＷｅｂサーバまたはＭｉｃｒｏｓｏｆｔ’ｓ Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｅｒなどのプログラムである。ｓｅｒｖｌｅｔ２１４は、クライアント２０４によってリクエストされた任意の追加の処理がｓｅｒｖｌｅｔ２１４によって実行され得るように、サーバアプリケーション２０８を介してクライアント２０４と通信を行い得る。
【００４０】
ロケーションベースサービスを提供する地理情報システム（ＧＩＳ）において、ｓｅｒｖｌｅｔ２１４は、必要な地図データ／情報を入手するために、ＭａｐＧｕｉｄｅサーバ２１２と通信を行い得る。さらに、ｓｅｒｖｌｅｔ２１４は、マップウィンドウファイル（ＭＷＦ）２１６にアクセスし、関連データを入手する。ＭａｐＧｕｉｄｅサーバ２１２（または別のアプリケーション）はまた、データベース管理システム（ＤＢＭＳ）２１８と相互作用し得る。このＤＢＭＳ２１８は、（ＳＤＦ（Ｓｐｅｔｉａｌ Ｄａｔａ Ｆｉｌｅｓ）データ（大量のデータを素早くイントラネットまたはインターネット上に配信するための特別なデータ形式）、ラスター（ｒａｓｔｅｒ）データ、Ｏｐｅｎ ＤａｔａＢａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ（ＯＤＢＣ）データなどの）関連する地図データをデータベース２２０から取り出すために使用される。
【００４１】
さらに、クライアント２０４は、デバイス２０４のロケーションを決定し追加のロケーションベースサービスを提供するための一様なインターフェースを提供するアプリケーションプログラミングインテーフェース（ＡＰＩ）を介して、ＬＢＳアプリケーション２１０とインターフェースで連結する。クライアントデバイス２０４のロケーションを決定するために、ＬＢＳアプリケーションは、様々な移動デバイスキャリア２２６の異なるプロトコルそれぞれに対する１つ以上のアダプタ２２４を使用し得る。キャリア２２６はまた、１つ以上のデータベース２２８から２３０にユーザプロファイル情報を保持し得る。上記のように、ＬＢＳアプリケーション２１０はまた、（例えば、情報のローカル格納のための）ＬＢＳデータベース２３２を保持し得る。（上記のように）従来技術では、ユーザプロファイル情報はたびたびＬＢＳデータベース２３２にリロードされる。
【００４２】
ＬＢＳアプリケーション２１０は、外部データベース２２８から２３０へのコンパクトＬＢＳブリッジを実行する。ＬＢＳブリッジを実行するために、ＬＢＳアプリケーション２１０は、外部データベース２２８から２３０のそれぞれのスキーマのコンパクト定義２３４を保持する。スキーマは以下に詳しく説明される。さらに、ＡＰＩ２２２がファジー論理を用いてデバイスのロケーションの修正のためのインターフェースを提供し得る。
【００４３】
概して、コンポーネント２０４から２３４のすべてが、例えば、データ格納デバイス、データ通信デバイス、ネットワークまたは別のデータコミュニケーションデバイスを介してコンピュータに接続されるリモートコンピュータまたはデバイスなど、デバイス、媒体、信号またはキャリアにおいて具体化されるまたはデバイスから取り出し得るロジックおよび／またはデータを含む。さらに、このロジックおよび／またはデータは、読まれ、実行され、および／または翻訳処理されるとき、実施されている本発明の実行および／または使用に必要なステップを生じる結果となる。
【００４４】
したがって、本発明の実施形態が、ソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組み合わせを製造するための標準プログラムおよび／または工学技術を使用する、方法、装置、または製造品として実施され得る。本明細書において使用される用語「製造品（ａｒｔｉｃｌｅ ｏｆ ｍａｎｕｆａｃｔｕｒｅ）」（または、その代わりに「コンピュータプログラム製品」）は、任意の、コンピュータを使用し得る、デバイス、キャリアまたは媒体からアクセス可能なロジックおよび／またはデータが含まれることが意図される。
【００４５】
当業者は、本発明の範囲から逸脱することなく、この例示的環境に対し、多くの改変がなされ得ることを認識する。例えば、当業者は、上記のコンポーネントの任意の組み合わせ、または、異なるロジック、データ、異なる周辺装置、および異なるデバイスを含むかなり多くの異なるコンポーネントの任意の組み合わせが、それによって同様の機能が実行される限り、本発明の実行のために使用され得ることを理解する。
【００４６】
（移動デバイスロケータアダプタシステム）
デバイスロケータアプリケーションは、特定の移動デバイスクライアント２０４のロケーションの決定のために、クライアント２０４またはサーバ２０６上で実行し得る。デバイスロケータアプリケーションは、特定の移動デバイスクライアント２０４のロケーションの決定のために、クライアント２０４またはサーバ２０６上で実行し得る。移動デバイスクライアント２０４のロケーションの決定のために、デバイス専用アイデンティフィケーションがデバイスロケータに提供される。例えば、ＭＳＩＳＤＮ（ｍｏｂｉｌｅ ｓｕｂｓｃｒｉｂｅｒ ｉｎｔｅｒｎａｔｉｏｎａｌ ｓｕｂｓｃｒｉｂｅｒ ｄｉｒｅｃｔｏｒｙ ｎｕｍｂｅｒ）（ディレクトリナンバー（例えば、ＧＳＭ（登録商標）−ｇｌｏｂａｌ ｓｙｓｔｅｍ ｆｏｒ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｎｕｍｂｅｒ）またはＧＳＭ（登録商標）加入者に接続するためのナンバー１ダイアル）がデバイスロケータアプリケーション２１０に提供され得る。そのようなＭＳＩＳＤＮは、無線アプリケーションリクエストのｃｏｏｋｉｅの中に符号化され得る。あるいは、デバイスは、リクエストヘッダに符号化されたＩＰ（インターネットプロトコル）アドレスによって識別され得るか、またはユーザプロファイルデータベース２２８から２３０に事前に格納されたデフォルトによって識別され得る。
【００４７】
デバイスロケータ２１０によってその結果提供されるロケーションは、デバイス２０４の座標、デバイス２０４のＳＲＳ（ｓｐａｔｉａｌ ｒｅｆｅｒｅｎｃｅ ｓｙｓｔｅｍ空間基準システム）および座標の正確さに関する情報を含む。
【００４８】
デバイスロケータ２１０が、ネットワークが提供するデバイス２０４のロケーションへのアクセスのためのインターフェース２２２を提供する。（例えばＳＩＭカードを介して）自身のロケーションを提供するデバイス２０４に対し、アプリケーション開発者は、すでにデバイス２０４の座標を有しており、デバイスロケータ２１０を使用する必要がない。
【００４９】
デバイスロケータ２１０は、ユーザに、デバイス２０４のロケーションの決定のための一様のＡＰＩ２２２を提供する。デバイスロケータ２１０は、デバイス２０４のロケーションをＬＤＴ（ｔｈｉｒｄ−ｐａｒｔｙ ｌｏｃａｔｉｏｎ ｄｅｔｅｒｍｉｎａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ サードパーティロケーション決定技術）プロバイダ２２６から取り出す。このＬＤＴのそれぞれは、（例えば、ＨＴＴＰ、ＨＴＴＰＳなどの）異なるプロトコルをサポートし得る。ＬＤＴは、デバイス２０４のロケーション情報を内部および外部のシステムに提供する、キャリアネットワークベースサービスを表す一般的な用語である。ＬＤＴアダプタ２２４は、特定のキャリア２２６によって供給され得、ロケーション情報の提供に使用され得る。供給されるＬＤＴアダプタ２２４以外のソースから得られる任意のロケーションは、ロケーションパラメータを要求する任意のアプリケーションプログラム情報（ＡＰＩ）の呼び出しにおいて、ＧＩＳアプリケーションのすべてを通じて、なお使用され得る。上記のように、ＬＤＴプロバイダ／キャリア２２６は、それぞれ、リクエストの形式、応答の形式、および応答の正確さに関して異なる、違ったプロトコルをサポートし得る。移動システムが所在する、地理的地域のみを提供し得るサービスもあれば、特定の座標を提供し得るサービスもある。
【００５０】
デバイスロケータインターフェース（すなわちＡＰＩ）２２２は、個々のＬＤＰプロバイダ２２６の特定のＡＰＩからアプリケーションコードを隔離する。アプリケーション開発者は、プロバイダのＡＰＩまたはプロトコルを理解する必要がない。かわりに、ＬＤＴアダプタ２２４が特定のプロバイダのＡＰＩを、デバイスロケータ２１０としてアプリケーションに与えられた一般的なＡＰＩ２２２に翻訳する。ＬＤＴアダプタ２２４は、したがって、ＨＴＴＰ（ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）、ＨＴＴＰＳ（ｓｅｃｕｒｅ ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）などのプロトコルの違いからアプリケーションを隔離する。そのようなアーキテクチャはまた、将来、アプリケーションＡＰＩ２２２を変更することなく、追加のＬＤＴプロバイダ２２６をサポートし得る。新しいＬＤＴプロバイダ２２６のために、ただ、ＬＤＴアダプタ２２４が書かれる必要があるのみである。
【００５１】
図３は、本発明の１つ以上の実施形態による、デバイスロケータ２１０をサポートするアーキテクチャを簡単に表したものである。例示するように、アーキテクチャがいくつかの層３０２から３０８を有する。デバイス２０４のロケーション情報を入手するために、アプリケーション層３０２の中のアプリケーションコード３１０が、プラットフォームＡＰＩ層３０４で、一様なＡＰＩ２２２を介して、（例えば、ＬｂｓＤｅｖｉｃｅＬｏｃａｔｏｒＭａｎａｇｅｒの）デバイスロケータ３１２とインターフェースで連結される。
【００５２】
キャリアに特有のインプリメンテ―ションを用いてロケーション情報を取り出すために、デバイスロケータ３１２は、内部層３０６の特定のキャリアＬＤＴアダプタ２２４に記述される個々のキャリアプロトコルとインターフェースで結合される。キャリアＬＤＴアダプタ２２４は、リモートＬＤＴプロバイダ層３０８のサーバコード３１８と通信するクライアントコード３１６と相互作用する。
【００５３】
デバイス２０４のロケーションのクエリを行うために、アプリケーションコード３１０が、（例えば、ＬｂｓＤｅｖｉｃｅＬｏｃａｔｏｒＭａｎａｇｅｒ）のデバイスロケータオブジェクト３１２の事例を取り出す。デバイスのｉｄが与えられたデバイス２０４のロケーションを入手するために、アプリケーションコード３１０は、その後、デバイスロケータ３１２を使用し得る。上記のように、デバイスのｉｄの形式は、ＬＤＴの実行によって異なり得る。デバイス２０４のロケーションのクエリが失敗した場合、デバイスロケータ３１２が例外を生成し得る。
【００５４】
クエリが成功した場合、ロケーションオブジェクトはアプリケーション層３０２に戻され得る。上記のように、その結果としてのロケーションオブジェクトは、デバイスのロケーションを表す座標を含むＰｏｉｎｔ／Ｃｏｏｒｄｉｎａｔｅオブジェクト、関連する空間基準システムを記述するＳＲＳオブジェクト、および座標の正確さを記述するＰｒｅｃｉｓｉｏｎオブジェクトを含む。
【００５５】
本発明の１つ以上の実施形態では、デバイスロケータマネージャが、個々のキャリア２２６のために／によって実行される特定のｇｅｔＬｏｃａｔｉｏｎ（）方法にＡＰＩ２２２およびデリゲートコールを提供する。個々のキャリア２２６がそのようなｇｅｔＬｏｃａｔｉｏｎ方法を実行するのを確実にするために、（例えば、デバイスロケータ インターフェースなどの）インターフェースが特定のデバイスロケータアダプタ２２４によって実行され得る。
【００５６】
（Ｅｒｉｃｓｓｏｎ（ＴＭ）実施）
上記のように、様々なアダプタ２２４がＬＢＳアプリケーション２１０によって利用さ得る。各アダプタ２２４は、特定のセルラーキャリア２２６として構成され得る。以下の記載は、Ｅｒｉｃｓｓｏｎ（ＴＭ）用に実施されたアダプタ２２４実施をサポートすることに特定されている。Ｅｒｉｃｓｓｏｎ（ＴＭ）では、デバイスｉｄは、ＭＳＩＳＤＮとして表されている。
【００５７】
Ｅｒｉｃｓｓｏｎ（ＴＭ）実施は、セル内にデバイス２０４を位置付けて、セルタワーからのおおよその距離を決定可能である。セルは、基地局を取り囲むか、基地局に直ぐ近くの地理上の領域である。このロケーションは、図４に示された円弧でモデリングされ得る。（例えば、ロケーションオブジェクトの一部として）戻された点オブジェクトは、円弧の地理的中心を表し、アプリケーション層３０２は、内径ｄ１および外径ｄ２を取り出し得る。角度θ１およびθ２は、北向きから時計回りに計測される度数である。
【００５８】
デバイスロケータ３１２がデバイス２０４のロケーションを決定できない場合、デバイスロケータ３１２は、所定／特定の回数だけリクエストをリトライする。特定のリトライ数の後、このデバイスロケータ３１２が依然としてロケーションを決定できない場合、例外が投げられる。通常、例外は、ＬＤＴプロバイダ２２６／アダプタ２２４とインターフェースするときに起こる。ＬＤＴプロバイダ２２６が例外を生成する場合、プロバイダ２２６によって提供された任意のさらなる情報（エラーコードおよびメッセージ等）がエラーログファイルに書き込まれ得る。
【００５９】
デバイスロケータ３１２のエラーコードをエラーコードのリストと比較することによって、デバイスロケータ３１２により例外が投げられたことを決定し得る。以下の表は、Ｅｒｉｃｓｓｏｎ（ＴＭ）の実施によって戻されたエラーコードを説明している。このエラーコードは、エラーログファイルに現れる。この表において、用語統一システムは、ロケーションを特定するシステムに関する。Ｅｒｉｃｓｓｏｎ（ＴＭ） Ｐｏｓｉｔｉｏｎｉｎｇ Ｐｒｏｔｏｃｏｌ（Ｅｒｉｃｓｓｏｎ（ＴＭ））は、モバイルポジショニングセンターとインタフェースするＥｒｉｃｓｓｏｎによって開発されたＨＴＴＰ／ＨＴＴＰＳベースの規格に関する。ＩＤＭＳ０は、縦または横を特定するフォーマットに関する。ここで、Ｉは主軸方向、Ｄは角度（２または３桁）、Ｍは分（２桁）、Ｓは秒（２桁）、および０は小数点以下が無いことを示す（例えば、Ｅ１５３８０６またはＮ６０３７５８）。さらに、モバイルポジショニングセンター（ＭＰＣ）は、Ｅｒｉｃｓｓｏｎ（ＴＭ）によって用いられる用語であり、アプリケーションをモバイルステーションポジション情報にアクセス可能にするポジショニングゲートウェイを説明している。さらに、モバイルポジショニングシステム（ＭＰＳ）は、Ｅｒｉｃｓｓｏｎ（ＴＭ）によって用いられる用語であり、ＬＤＴに対するＭＰＰを実施することを説明している。このエラーコードは、Ｅｒｉｃｓｓｏｎ（ＴＭ）ＭＰＳ ＳＤＫのバージョン３．０を表している。
【００６０】
表１‐Ｅｒｉｃｓｓｏｎ（ＴＭ）汎用エラーコード
【００６１】
【表１】
表２‐Ｅｒｉｃｓｓｏｎ（ＴＭ）シンタックスエラーコード
【００６２】
【表２】
表３‐Ｅｒｉｃｓｓｏｎ（ＴＭ）認証エラーコード
【００６３】
【表３】
表４‐Ｅｒｉｃｓｓｏｎ（ＴＭ）オーソリティエラーコード
【００６４】
【表４】
表５‐Ｅｒｉｃｓｓｏｎ（ＴＭ）ポジショニングエラーコード
【００６５】
【表５】
表６‐Ｅｒｉｃｓｓｏｎ（ＴＭ）ネットワークエラーコード
【００６６】
【表６】
表７‐Ｅｒｉｃｓｓｏｎ（ＴＭ）ＭＰＳ１．１エラーコード
【００６７】
【表７】
（アダプタシステムフロー）
図５は、本発明の１つ以上の実施形態によるモバイルデバイスロケータアダプタシステム２００でＡＰＩを用いることを示すフローチャートである。図２および図５の両方を参照すると、モバイルデバイスロケータアダプタシステム２００では、コンピュータシステム２００の新規のバージョンを展開（ｄｅｐｌｏｙ）することなく、アプリケーション２００（すなわち、デバイスロケータ）は、コンピュータシステム２００内で動的に展開され得る。
【００６８】
一度アプリケーションプログラム２１０が展開されると、アプリケーションプログラム２１０のＡＰＩ２２２の単純化プロシージャがステップ５００で呼び出され得る。単純化プロシージャは、ステップ５０２において、（例えば、モバイルデバイス２０４の同定を用いて）モバイルデバイス２０４のロケーションを得る。ロケーションを得るために、呼び出されたプロシージャは、ステップ５０４でキャリアアダプタ２２４と相互作用する。キャリアアダプタ２２４が特定のキャリア２０６に対してカスタマイズされるため、特定の情報および方法が利用され得る。例えば、呼び出されたプロシージャは、キャリア２２６のモバイルポジショニングサーバの詳細、およびキャリア２２６によって必要とされるデバイス２０４を識別する異なる方法と相互作用し得る。さらに、呼び出されたプロシージャは、ステップ５０６において、デバイス２０４のロケーションに関連する空間参照システム（ｓｐａｔｉａｌ ｒｅｆｅｒｅｎｃｅ ｓｙｓｔｅｍ）を得てもよい。
【００６９】
ステップ５０２で得られたモバイルデバイス２０４のロケーションは、セルラーホン番号、ＭＳＩＳＮＤ、リクエストヘッダまたは予め格納されたデフォルトでエンコードされたインターネットプロトコルアドレスを含んでもよい。さらに上述されるように、ステップ５０４で１つ以上のキャリアアダプタ２２４と相互作用することによって、呼び出されたプロシージャは、キャリア２２６によって提供された異なるプロトコルと相互作用する。
【００７０】
一度、ステップ５０６でロケーションが得られると、そのロケーションは、ステップ５０８でさらにリファイン（ｒｅｆｉｎｅ）され得る。ロケーションをリファインするために、１つ以上のヒューリスティックスが適用され得る。例えば、そのロケーションは、ストリートネットワークの最も近い点、近傍の該当点または目印、（ユーザの「履歴」を調査することによる）モバイルデバイスユーザが最近訪ねたロケーションの近傍のロケーション、または、モバイルデバイスユーザが「お気に入り」ロケーションとしてブックマークに入れたロケーションの近傍のロケーションにスナップ（ｓｎａｐ）され得る。あるいは、ファジーロジックは、デバイス２０４のロケーションをリファインするために用いられてもよい。
【００７１】
（ロケーションリファインメント）
一度デバイス２０４のロケーションが得られると、本発明の１つ以上の実施形態は、いくつかのヒューリスティックスを適用することによって、および／または、ファジーロジックを適用することによって、近似ロケーションをリファインしてもよい。ユーザまたはアプリケーションは、このようなロケーションリファインメントが起こるときを特定し得る。例えば、ブール「ＲＥＦＩＮＥ」値は、リファインメントが所望である場合、ＴＲＵＥに設定され得る。従って、（上記のように）一度ロケーションが特定されると、ブール値は、さらなるリファインメントが実施されるべきかどうかを決定するように試験され得る。
【００７２】
ユーザは、デバイス２０４のロケーションをリファインする所望の方法論を特定するように許可され得る。このような異なる方法論は、リファインメントプロセスで用いられるルールのセットを構成することによって特定され得る。さらに、このようなルールは、ルール構成ファイルの表に格納され得る。異なる方法論は、ストリートネットワークの最も近い点、目印、またはその近傍の「該当する点」にロケーションをスナップすることを含み得る。あるいは、アプリケーションは、モバイルデバイスユーザが最近訪ねた近似ロケーションの近傍のロケーションを探し（すなわち、ユーザプロフィールの「履歴」を調査する）、ロケーションを特定のロケーション（例えば、最後に訪ねた最も近いロケーション）にスナップし得る。さらに、アプリケーションは、モバイルデバイスユーザによってブックマークに入れられた「お気に入り」ロケーションを調査して、いずれかのこのような「お気に入り」位置が近似デバイスロケーションの近傍にあるかどうかを判定し得る。その後、近似位置が最も近い「お気に入り」ロケーションにスナップし得る。さらに、ファジーロジックは、以下に詳細に説明されるように位置をリファインするように用いられ得る。
【００７３】
例えば、ロケーションリファインメントへの単純な解決方法では、正確なポリゴン形状の図心が、
ｘ＝ＤｏｕｂｌｅＩｎｔｅｇｒａｌ（ｘ ｄｘ ｄｙ）／ＤｏｕｂｌｅＩｎｔｅｇｒａｌ（ｄｘ ｄｙ）、および
ｙ＝ＤｏｕｂｌｅＩｎｔｅｇｒａｌ（ｙ ｄｘ ｄｙ）／ＤｏｕｂｌｅＩｎｔｅｇｒａｌ（ｄｘ ｄｙ）
によって規定される。
図心のこのような定義を用いることによって、精密なポリゴン（例えば、１０２）の些細なリファインメントが提供される。しかし、図心は、実際にロケーションをリファインしない。それにもかかわらず、このような図心は、精密なポリゴン１０２内の真の（ｔｒｕｅ）ロケーションの均一分配の最良の平均エラーを提供し得る。
【００７４】
ロケーションリファインメントの別の例では、ユーザプロファイルおよび局地的なコンテンツがリファインメントに影響を与えるために用いられる。このようなリファインメントでは、無線キャリア２２６、プロファイルデータベース２２８〜２３０、無線ポータル（例えば、アダプタ２２４）およびローカルユーザプロファイルデータベース（例えば、ＬＢＳデータベース２３２）は、共に、非常に特別なプロファイル情報へのアクセスを有する。このようなアクセスは、Ｎｅｍｍａｒａ Ｃｈｉｔｈａｍｂａｒａｍらによる、「ＬＯＣＡＴＩＯＮ ＢＡＳＥＤ ＳＥＲＶＩＣＥＳ ＢＲＩＤＧＥ ＴＯ ＥＸＴＥＲＮＡＬ ＤＡＴＡ ＳＯＵＲＣＥＳ」と称され、同時係属中で、同一人に譲渡され、２００１年１２月２６日に出願された米国特許出願第１０／０３４，４４０号（アトーニードケットＮｏ．Ｇ＆Ｃ ３０５６６．２０４−ＵＳ−０１）に記載されており、提供され得る。
【００７５】
この情報は、ＬＢＳサービスまたはＬＢＳアプリケーション２１０をより多く用いることによって、次第に豊かにより、かつより正確になり得る。ＬＢＳアプリケーション２１０をさらに用いることによって得られるデータは、最近訪ねたロケーションの履歴、および／または最近実行したクエリ（例えば、「最も近い博物館を訪ねる」）に基づいて、ユーザの一般的人口統計分類、民族分類、ユーザのロケーションパターン（例えば、家、オフィス、お気に入りロケーション）および／またはユーザの「現在の活動プロファイル」に関連する洞察を提供し得る。
【００７６】
さらなるこのようなプロファイル情報はまた、ユーザがブックマークに入れたお気に入りロケーションの近傍にいるかどうか、または、ユーザがロケーション履歴に最近記録されたロケーションの近傍にいるかどうか等の質問に答えるために用いられ得る。これらの条件のうちの１つが正しいと判明する場合、リファインされたロケーション用の候補としてのお気に入りロケーション、またはユーザプロファイルロケーション履歴のロケーションが容易に提供され得る。
【００７７】
しかし、ＬＢＳサービスは、ユーザが家庭または仕事から離れており、不慣れな地域にいることが多い場合に、より一般的に用いられる。このような場合、近傍の該当する目立ったランドマーク（単数または複数）あるいは点（単数または複数）は、リファインされたロケーション（単数または複数）として提供され得る。さらに、選択された該当するランドマークまたは点のカテゴリーは、ユーザプロファイルおよびロケーションコンテンツデータベース２３２に基づいて、ユーザの「現在の活動のプロファイル」を「聡明に推量する」ことに依存し得る。このような入力は、ロケーション局面（例えば、ユーザのお気に入りルートであるロケーション）、活動プロファイルインジケータ（単数または複数）（例えば、この人はビジネスビジターか？または、最後のファインダークエリが「最も近い博物館を見つける」であった）、および／または一時的な局面（例えば、典型的なビジターアトラクションはこの地域でどれくらい遅れてオープンしたのか？）の組み合わせを含み得る。
【００７８】
さらに、ユーザのお気に入りは、ユーザに対してテーラリングされた、高度にパーソナライズされたサービスを伝達するように推論され得る。例えば、アプリケーションの動作からコンテンツのフィルタリング用のスライライジングまでどんなものでも特定のユーザの対してパーソナライズされ得る。
【００７９】
デバイス２０４の近似ロケーションをリファインするために、ロケーションリファインメントマネージャが利用され得る。このロケーションリファインメントマネージャは、ロケーションリファインメントのための最初の点であり得、ロケーションリファインメントマネージャの方法が１つのリファインされたロケーション（例えば、最良推定）、リファインされた候補ロケーションのソート済みリスト、または、ソースによって分類されたリファインメント候補のいくつかのリスト（例えば、ユーザプロファイルお気に入り、ユーザプロファイル履歴、ビジターランドマーク等）を返し得る。リファインされた位置の各リストは、実行された特定のリファインメントに基づき得る。例えば、あるリストがお気に入りに基づき得て、第２のリストが履歴に基づき得て、第３のリストがランドマークに基づき得る。さらに、各リストは、図心または近似位置からの距離に基づいてソーティングされ得る。
【００８０】
一度リファインされたロケーションのリストが得られると、ユーザは、ＬＢＳアプリケーション２１０と相互作用して、ユーザの正確な位置を計算し得る。この相互作用は、例えば、リファインされたロケーションの１つの承認を含み得、候補リストからの選択を可能にし得る。１つ以上の候補ロケーションを使用することがユーザの真のロケーションを方向付けて、位置を特定可能となる。さらに、このプロセス中に、全てのリストは、１つのリスト内に分割され得る。例えば、各リストの各ロケーションは、図心からの距離によってソーティングされた１つのリストに組み合わせられ得る。さらに、それぞれのリストまたは１つの解決したリストは、特定のポリゴン内のロケーションのみがリターンされるようにフィルタリングされ得る。さらに、個々のリストまたは１つの解決されたリストに基づいて、１つのリファインされたリストがリターンされ得る。従って、ロケーションリファインメントマネージャの実施に基づいて、ユーザは、１つのリファインされたロケーション位置、リファインされたロケーションのリストまたはリファインされたロケーションのリストのリストによって提示され得る。それにもかかわらず、ロケーションリファインメントマネージャによって、デバイス２０４の近似の位置は、ユーザによって選択可能であり得る様々な因子に基づいてリファインされることが可能となる。
【００８１】
（ファジーロジックリファインメント）
本発明の１つ以上の実施形態は、ファジーロジックを用いてデバイスロケーションをリファインする製作者の方法、装置および商品を提供する。このファジーロジックリファインメントプロセスは、ロケーションリファインメントマネージャによって初期化され得る。
【００８２】
ファジーロジックを利用して、デバイスの位置をリファインするために、多くの理由が存在する。最大限の利益を提供するために、いくつかの質問および情報が必要であり得る。例えば、必要な情報は、現在の活動プロファイルがコンピュータプロファイル、ビジネスビジタープロファイル、レジャービジタープロファイル、これらのプロファイルのうちの１つ以上とマッチするか、これらのプロファイルと全くマッチしないかどうかを含んでもよい。しかし、このような質問に答えるとともに、多くの問題が生じ得る。例えば、この問題の定義があいまいであってもよい。言い換えると、この問題は、正確な定量的な定義には適切ではないかもしれない（例えば、〜の近傍、〜の近く、〜から離れた、おそらく、等の非定量的な用語が頻繁に用いられてもよい）。さらに、リファインされたロケーションに対するランドマークの特定のカテゴリーがいつ用いられるべきか（主体的問題）を決定することは困難であり得る。さらに、境界がぼやけていてもよい。例えば、「現在の活動はレジャービジターのプロファイルにマッチしているか？」という質問に対する答えは、「たぶん」または「不確か」対「はい／いいえ」であり得る。さらに、入力が不正確でも、衝突していても、および／またはオーバーラップしていてもよい。例えば、現在の活動プロファイルは、レジャー中の夕方を過ごしているビジネスビジターを表す。
【００８３】
これらの問題は、入力に固有のあいまいなこと、不正確なこと、およびぼやけた境界を取り扱うシステムを要求する。さらに、システムは、このような不正確かつ衝突している情報がいかに捕えられて、処理されるか、（使用法および展開が上昇した）問題の理解が深まったという連続的な沈思を可能にするか、そして、決定的な結論を提供するかどうかを定式化するべきである。
【００８４】
本発明の１つ以上の実施形態は、このような問題を解決するファジーロジックと呼ばれる人工知能（ＡＩ）の分野を利用する。ファジーロジックは、部分的に真（「完全に真」と「完全に偽」との間の真の値である）という概念を取り扱うために拡張された従来の（ブール）ロジックの上位集合である。
【００８５】
ファジーロジックでは、連続的な真値は、システム変数が、厳密なバイナリ（真および偽）決定および割り当てではなく、区間［０，１］における真値のメンバーシップの連続的な範囲を取り得るように認められる。例えば、曇り（ｃｌｏｕｄｙ）および曇っている（ｏｖｅｒｃａｓｔ）場合、その記述「雨が降っている」は、０．８の真値であろうし、偽値は０．２５でもあろう。同様に、記述「現在のユーザはビジターである」は、非常に確からしい場合０．９の値を有し、あまり確からしくない場合０．１の値を有し、その答えが「たぶん（ｍａｙ ｂｅ）」である場合０．５の値を有する。
【００８６】
ファジーロジックを用いると、ロケーションリファインメント問題が再定義され得る。このような問題の再定義が図６に示され得る。この図６は、再定義されたロケーションを重み付き入力のファジー図心として示す。図６では、ロケーション精度ポリゴン１０２は、近似のデバイス２０４ロケーションとして与えられる幾何学的な図心１００を含む。リファインされた位置１０４は、様々な異なる可能性６０２〜６１４から選択されてもよい。しかし、様々な異なる可能性６０２〜６１４は、リファインされたロケーションをファジー図心１０４として決定するために重み付けされて組み合わされ得る。
【００８７】
様々なファジーメンバーシップセット６０２〜６１４は、ロケーションをリファインするために、用いられて重み付けされ得る。異なるタイプのファジーメンバーシップセット６０２〜６１４は、重み付け計算に利用され得る。例えば、ファジーメンバーシップセット６０２〜６１４は、ユーザプロファイルロケーションの様々なカテゴリー（例えば、最も近いユーザプロファイルお気に入り６０２、ユーザプロファイル履歴６０４等）に対する近似として利用され得る。さらに、ファジーメンバーシップセット６０２〜６１４は、現在の活動（例えば、ビジネスビジタープロファイル、通勤者プロファイル、レジャービジタープロファイル等）、拡大解釈すると、異なる種類のランドマーク（例えば、最も近いロギングランドマーク６０６、最も近いビジターランドマーク６０８、最も近いビジネスランドマーク６１０、最も近いストリートインターセクション６１２、最も近い通勤者ランドマーク６１４等）に対する重み付け近似を記述し得る。
【００８８】
ファジーメンバーシップセットに基づくと、リファインされたロケーションは、これらの重み付け入力のファジー図心１０４として推論され得る。
【００８９】
本発明のファジーロジック推論は、任意の数の正確または不正確な入力（単数または複数）センサが可能であるように、様々な数の不正確な入力を可能にする。例えば、以下の一つ以上のものがデバイスロケーションをリファインするために入力センサとして用いられ得る：お気に入り、ビジネスビジタープロファイルインジケータ、レジャープロファイルインジケータ等の近似。
【００９０】
本発明のファジーロジック推論は、
ＩＦ Ｘ ａｎｄ Ｙ ｔｈｅｎ Ｚ
の形式の入力／出力関係を定義する（直感的な）ルールセットを定義するルールベースを含む。例えば、以下のルールのうちの１つ以上は、本発明のルールベース内に定義され得る。Ｉｆ（ローカルお気に入りロケーションに近い）ｔｈｅｎ ＣｌｏｓｅｓｔＦａｖｏｒｉｔｅ、または、Ｉｆ（お気に入りから遠い）ａｎｄ（現在の活動がビジターランドマークにマッチする）ｔｈｅｎ ＣｌｏｓｅｓｔＶｉｓｉｔｏｒＬａｎｄｍａｒｋ。
【００９１】
メンバーシップ関数は、ロケーションを決定する際に各入力の関与の程度を定義する。例えば、メンバーシップ関数は、現在の活動プロファイルがレジャービジタープロファイルにマッチするかどうかという疑問を評価し得る。「最も確からしい（ｍｏｓｔ ｌｉｋｅｌｙ）」という答えは、「そうかもしれない（ｃｏｕｌｄ ｂｅ）」という答えに対して、より高度なメンバーシップ関数、およびロケーション決定により良好に関与しているという結果となる。
【００９２】
最後に、本発明のファジーロジック推論は、これらのルールの各々の論理積を計算する推定エンジンを含む。例えば、推定エンジンは、
Ｘ ＡＮＤ Ｙ ＝ ＭＩＮ（Ｘ，Ｙ）
Ｙ ＯＲ Ｙ ＝ ＭＡＸ（Ｘ，Ｙ）
のように論理積を決定し得る。
この論理積は、その後、最終的な答えを生むために組み合わせられる。
【００９３】
図７は、本発明の１つ以上の実施形態によるファジーロジック推論プロセスの概観である。図示されるように、ファジー入力７０２（すなわち、様々な数の不正確な入力）は、各入力７０２の関与の程度を定義する一つ以上のメンバーシップ関数７０４によって処理される。その後、（一つ以上のルールを含む）ルールベース７０６は、推定エンジン７０８によって処理される。この推定エンジン７０８では、一つ以上のルールに対する論理積が計算される。この論理積は、各ルールに対して真のレベル（すなわち、区間［０，１］の値）を提供する。その後、推定エンジンは、一つ以上の異なる方法を用いてリファインされたロケーションを選択する。例えば、最大論理積または二乗平均平方根値７１０が適切な最終出力７１２（すなわち、リファインされたロケーション）を決定するために利用され得る。従って、ファジー入力７０２は、（メンバーシップ関数７０４によって処理される場合）クリスプ（ｃｒｉｓｐ）形式からファジー形式へと移行する。ここでは、それらは、推定エンジン７０８によって処理される。この推定エンジン７０８は、論理積を識別して、適切な論理積および出力７１２に対する対応するリファインされたロケーションを選択する所望の方法論７１０を用いることによって、クリスプ形式に逆に処理される。
【００９４】
３つのタイプの入力センサ（ファジー入力７０２）が利用され得る：ロケーションまたは近似ベース、時間ベースおよび活動プロファイルベース。ロケーションまたは近似ベース入力７０２は、特定のロケーションへの近似を決定する。例えば、ロケーションベース入力７０２は、（例えば、自宅、オフィス、健康クラブ等に近似の）お気に入り、および（例えば、ユーザプロファイル履歴の最近訪ねたロケーションに近似の）履歴を含み得る。
【００９５】
活動プロファイルベース入力７０２は、現在のユーザの活動が特別に確立されたプロファイルにマッチする、類似するかどうかを判定するために評価される。例えば、確立されたプロファイルは、ビジネスビジタープロファイル（例えば、現在の活動がビジネスビジターのプロファイルにマッチしているか？）、レジャービジター活動プロファイル（例えば、現在の活動がレジャービジターのプロファイルにマッチしているか？）、および通勤者活動プロファイル（例えば、現在の活動が通勤者のプロファイルにマッチしているか？）を含み得る。
【００９６】
一時入力７０２は、現在の時間が特別な一時領域またはプロファイル内にあるかどうかに基づいている。例えば、ビジネス稼働時間の一時入力７０２を運転しているビジネスは、現在の時間がビジネス稼動時間内であるかどうかを判定し得る。あるいは、レジャー稼動時間一時入力７０２は、現在の時間がレジャー稼動時間内であるかどうかを判定する。
【００９７】
（方向または行程を示す）速度ベクトル等の他のシナリオ−一時入力７０２が入力７０２として加えられ得る／利用され得る。
【００９８】
その後、ファジーロジックは、入力７０２を処理して、出力７１２を作る。この出力７１２は、一つの値を含んでもよいし、（複数の候補が必要である場合）値のセットを含んでもよい。出力は、最も近いお気に入りロケーション６０２、最も近い履歴６０４、最も近いレジャーランドマーク６０８、最も近いビジネスランドマーク６１０、最も近いロギングランドマーク６０６（例えば、ホテル）、最も近い通勤者ランドマーク６１４、最も近い交差点６１２等を含んでもよい。
【００９９】
メンバーシップ関数７０４は、各入力の関与の程度を定義するために利用される。言い換えると、メンバーシップ関数７０４は、入力７０２の評価を作成して、インターフェースエンジン７０８にどれくらい入力７０２が用いられるかを決定する。
【０１００】
３つの値のセットは、各入力／メンバーシップ関数７０４として用いられ得る。真値に対してはＰすなわちポジティブ（＋）、偽値に対してはＮすなわちネガティブ（−）およびいずれかの方向にも向かうことができるか、不確かさを反映することができる値に対してはＺすなわちゼロ（０）である。各セットは、近いセット／区間［０，１］から値を取ることができる。
【０１０１】
例えば、入力関数ＬｅｉｓｕｒｅＶｉｓｉｔｏｒＡｃｔｉｖｉｔｙＰｒｏｆｉｌｅは、以下のようにファジー化されることが可能である。
【０１０２】
最も確からしい（Ｍｏｓｔ Ｌｉｋｅｌｙ）レジャービジター→Ｐ＝０．８
あまり確からしくない（Ｕｎｌｉｋｅｌｙ）レジャービジター→Ｎ＝０．８
そうであるかもしれないし、そうではないかもしれない（Ｍａｙ ｏｒ ｍａｙ ｎｏｔ ｂｅ）（不確かである）→Ｚ＝０．８
同様に、Ｐ，ＮおよびＺ値は、全ての他の入力７０２に対して定義され得る（例えば、近い＝Ｐ，遠い＝Ｎ，不確か＝Ｚ）。表１は、入力７０２の関与に対する異なる値を格納するために用いられ得る入力メンバーシップ表の例である。
【０１０３】
【表８】
メンバーシップ関数７０４は、Ｐ，ＮおよびＺに対する適切な値で埋める。メンバーシップ関数７０４を通して入力７０２を処理することに続いて、入力７０２は、メンバーシップ関数７０４によって提供される関与（すなわち、Ｐ，ＮおよびＺ値）の程度に従って、ルールベース７０６に対して推定エンジン７０８によって処理される。このルールベース７０６が単に推定エンジン７０８によって適用されるため、ルールベース７０６は、より多くの経験的データが集められるにつれて、進歩的にリファインされ得る。さらに、デフォルトルールが特定され得る。このデフォルトルールは、推定エンジン７０８が、衝突しているルールまたは入力７０２が原因により結果を作り出すことができない場合／ときに用いられる。従って、ルールベース７０６がフェイルセーフである。あまりにも多くの衝突する入力７０２のために、このファジー推論が結果を出すことができない場合、このデフォルトルールが適用される（例えば、デフォルトルールがこのように提供する場合、最も近い交差点を答える）。
【０１０４】
さらに、変化するルールおよび入力７０２に基づいて作られる出力７１２で実験すると、ルールのインクルージョン（ｉｎｃｌｕｓｉｏｎ）およびエクスクルージョン（ｅｘｃｌｕｓｉｏｎ）は、実験に影響され得る。このような実験に対して、ルールが論理積を用いること、および、非ゼロの論理積のみが最終的な推定に寄与することを提供する。例えば、メンバーシップ関数７０４がゼロであるＰ，ＮおよびＺ値を提供する場合、入力７０２は、大きさを有せず、ルールに参加することができない。さらに、論理演算が実行されるため、ゼロ値が用いられる場合、ルールにおける積の結果は、また、ゼロである（これにより、不適切な出力７１２を作る）。従って、関数７０４のＰ，ＮおよびＺ値に対して０．０の値を初期設定することによって、論理積ルールの結果として寄与することから、ルールが排除される（０．０であるために、Ｘ＝０．０である）。
【０１０５】
従って、ルールの数、ルールの複雑さ、および推定エンジン７０８が（例えば、世界の異なる部分に対して適応して、あるいは、より豊かなユーザプロファイルデータベースに対して）構成され得る。表２は、ルール番号、先行詞（ａｎｔｅｃｅｄｅｎｔ）、およびルールベース７０６に対する結果を含むルールベース７０６の表を示す。
【０１０６】
【表９】
テーブル２は、どのようにして、入力メンバーシップテーブル（すなわち、テーブル１）中の値が規則のセット中で利用されるかを示す。例えば、規則３では、４つの条件が入力７０２に基づいて処理され、最も近いビジネスランドマークを生成する。４つの規則は、論理ＡＮＤ演算を使用して、前件の規則を評価する。お気に入りへの接近度がＮまたはＺ、履歴への接近度がＮまたはＺ、ビジネス旅行者プロファイルがＰ、およびビジネス活動時間がＰである場合、規則３では、最も近いビジネスランドマークが、後件である（すなわち、出力６１２）。さらなる規則の各々は、それが組み合わされた場合、特定の後件を生成する１セットの前件／状態を有する。
【０１０７】
一旦、規則ベース７０６が確立された（例えば、規則ベーステーブルに置かれた）場合、推論エンジン７０８は、ファジー重心１０４を計算するために使用される。推論エンジン７０８を使用する場合、各規則（例えば、テーブル２の規則１〜８）の論理演算結果が処理される。この処理は、各規則に対して０〜１の値を生成する。論理演算結果を処理する場合、前件の「ＸおよびＹおよびＺ」は、Ｘ、Ｙ、およびＺの内の最小物（すなわち、ＭＩＮ（Ｘ，Ｙ，Ｚ））と等価である。同様に、前件の「ＸまたはＹまたはＺ」は、Ｘ、Ｙ、およびＺの内の最大物（すなわち、ＭＡＸ（Ｘ，Ｙ，Ｚ））と等価である。各規則に対する論理演算結果（間隔[０，１]の値を有する）は、その規則の参加の度合いを示す（０は参加がないことを示す）。この推論は、そのＭＡＸを選択し、平均するかまたは２乗平均平方根７１０を使用することを含む非ゼロの度合いの規則の重みつき重心１０４を計算する異なるメソッドを使用し得る。
【０１０８】
１つ以上の実施形態では、最も大きい論理演算結果を有する規則が選択されるように、ＭＡＸ規則が常に利用される。例えば、（テーブル２の）規則５がもっとも大きい論理演算結果、例えば、０．９を生み出す場合、修正された位置は、Ｃｌｏｓｅｓｔ Ｌｏｄｇｉｎｇ Ｌａｎｄｍａｒｋである。
【０１０９】
さらに、規則を適用する際、複数の候補または複数のリストが必要とされる場合、最大２または３の論理演算結果からの第１のｎ個の要素が選択される。例えば、（テーブル２の）規則５および７が最大値を生み出す場合、Ｃｌｏｓｅｓｔ Ｌｏｄｇｉｎｇ ＬａｎｄｍａｒｋおよびＣｌｏｓｅｓｔ Ｃｏｍｍｕｔｅｒ Ｌａｎｄｍａｒｋを表す２つのリストが修正候補として提供され得る。
【０１１０】
（ファジー論理修正の例示的なアプリケーション）
（例１（簡単な例））
簡単な例では、ユーザは、任意のお気に入りのロケーションに非常に近いところに居ないかもしれないが、ユーザのプロファイル履歴におけるロケーションに非常に近い。このような例では、入力メンバーシップテーブルは、テーブル３に示されるような値を有する。
【０１１１】
【表１０】
この例では、テーブル４に示されたように、規則テーブルの中で非ゼロ論理演算結果を生み出す規則は規則１および２のみである。
【０１１２】
【表１１】
Ｍａｘ規則を用いると（すなわち、最大論理演算結果を有する規則を取る）、規則２が優勢になり、修正されたロケーションに対する出力７１２は最も近い履歴である（例えば、ユーザの履歴の内、最新のロケーション）。最も近い履歴が予測される答えである。
【０１１３】
（例２）
この例では、ユーザはお気に入りから遠く離れており、履歴から遠く離れており、現在の活動プロファイルは、ユーザがビジネス旅行者プロファイルに整合することを示し、現在の活動プロファイルは、ユーザがまた、レジャー旅行者プロファイルに整合し得ることを示し、時刻は、平日の午後８時である。
【０１１４】
メンバーシップ関数７０４でのこれらの値の処理は、テーブル５の入力メンバーシップ関数に対する値を生じ得る。
【０１１５】
【表１２】
これらのメンバーシップ値に対する非ゼロの度合いの規則およびその論理演算結果は、以下のテーブル６に示される。
【０１１６】
【表１３】
最大の論理演算結果は、規則５および４に対するものである。従って、この例についての修正に対する候補は、ＣｌｏｓｅｓｔＬｏｄｇｉｎｇＬａｎｄｍａｒｋおよびＣｌｏｓｅｓｔＬｅｉｓｕｒｅＬａｎｄｍａｒｋを含む。
【０１１７】
（利点および利益）
デバイス２０４のロケーションを修正するためのファジー論理推理の使用は、ロケーションおよび修正に対する入力、ならびにその修正を計算するために使用される規則の両方に関連した多くの不確実性を処理する。さらに、ファジー論理推理は、不正確／あいまいさ／重複／競合する入力（ファジー）を表す正式な構成論理を提供する。また、ファジー論理推理は、（ユーザの相互作用の最小化を望むアプリケーションのために）最良の推理および数個の優性度の高い候補を提供する。
【０１１８】
さらに、本明細書中で説明されたように、ファジー論理推理モデルが適応できる。言い換えれば、このモデルは、推論の複雑性の制御を可能にする。例えば、規則３〜７の推論を拒否することは、（お気に入りへの近接度、ロケーションの履歴、およびデフォルトのＣｌｏｓｓｔＳｔｒｅｅｔＩｎｔｅｒｓｅｃｔｉｏｎのみを使用する）簡単なモデルを提供する。一方で、規則は、地域情報等のさらなる情報を提供するように容易に微調整され得る。
【０１１９】
規則ベース７０６、および推論エンジン７０８は、同調して実行され得る（最も簡単に開始する）。さらにその処理は、入力がキャリアプロファイルデータベース２２８〜２３０から取り出されることを可能にし、ロケーション情報がユーザの嗜好を推論しアプリケーションの挙動、コンテンツのフィルタリング等に影響を与えることを可能にする。キャリアプロファイルデータベース２２８〜２３０の使用は、ユーザのプロファイルおよびロケーションに合わせられた、高度に個人化されたアプリケーションの提供を支援する。さらに、キャリアによって収集されるプロファイル情報の価値は、アプリケーション挙動の個人化にそれを使用することによって増大する。
【０１２０】
（ファジー論理推理フロー）
図８は、本発明の１つ以上の実施形態による、デバイス２０４のロケーションを修正するためのファジー論理推理の使用を示すフローチャートである。ステップ８００では、デバイス２０４のおよそのロケーションが決定される。ステップ８０２では、秩序化された規則の集合を含む規則ベース７０６がメモリに読み出されるかまたは（例えば、データベース２３２の）データベースからロードされる。規則ベース７０６は、経時的に収集される経験的なデータに基づいて漸進的に修正され得る。さらに、規則ベース７０６は、推論が結果を生成しない場合に使用するデフォルト規則を特定し得る。さらに、規則ベース７０６は、それが地域動向、社会動向、または人口統計動向を反映するように構成され得るように、適応可能であり得る。このような適応可能性は、ユーザによって制御可能であり得、ユーザは、推理をカスタマイズ／個人化するために、規則ベースを追加、削除、および編集し得る。
【０１２１】
規則ベース７０６内にある規則は、１つ以上の条件を有する前件、およびその結果としての後件によって定義される。さらに、その前件は、論理演算結果を利用してもよいし、それを処理してもよい。
【０１２２】
ステップ８０４では、種々の不正確な入力／入力センサが捕捉される。上述のように、典型的には、３つのタイプの入力センサが使用される。すなわち、地域的、活動プロファイルベース、および時間ベースのタイプである。さらに、空間−時間的な入力が使用され得る。
【０１２３】
ステップ８０６では、その入力は、１つ以上のメンバーシップ関数で処理される。メンバーシップ関数は、規則内の各入力の参加の度合いを定義する。ファジー論理推理に従って、その参加の度合いは、０〜１（[０，１]）の間隔内に存在し得る。メンバーシップ関数は、各入力に対して３つの値のセットを定義し得る。このような３つの値のセットは、真の値、偽の値、および不確定な値（それらの値は、間隔[０，１]に沿って定義される）を含み得る。
【０１２４】
ステップ８０８では、各規則に対して論理演算結果を生成するために、参加の度合いに基づいて、規則が入力に適用される。本発明のファジー論理推理を用いて、論理演算結果は、その後件の適用の可能性を表す、０〜１の真の値を含み得る。その後件は、修正されたロケーション（例えば、最も近いレジャーランドマーク、最も近い宿泊ランドマーク等）を特定／説明する。従って、前件は、種々の入力の値を利用して（メンバーシップ関数によって処理されるように）、後件の真を表す論理演算結果を生成する。
【０１２５】
ステップ８１０では、修正されたロケーションがその論理演算結果に基づいて計算される。言い換えれば、種々の真の値／論理演算結果がステップ８０８において特定されたので、実際の修正されたロケーション（重み付き重心１０４とも呼ばれる）としてどの後件を利用するかに関する決定がなされる。上述のように、論理演算結果に基づいて修正されたロケーションを計算する異なるメソッドが使用され得る。例えば、最大論理演算結果が選択され得、次いで、その修正されたロケーションを決定するために、それに対応する後件が選択／使用され得る。あるいは、平均（例えば、２乗平均平方根計算）がそのロケーションを修正するために使用され得る。例えば、論理演算結果が平均化され得、かつその平均に最も近い論理演算結果を有する後件が、修正されたロケーションとして選択され得る。あるいは、多くの異なる候補ロケーションが使用され得、これらのロケーションの全ての間にあるロケーションが提供され得る。しかし、修正されたロケーション（または修正されたロケーションのリスト）を選択するために、任意の利用可能なメソッドが使用され得る。さらに、返される修正されたロケーションは、単一のもの（すなわち、単一の修正されたロケーション）を含んでもよいし、ユーザが選択し得る候補ロケーションのリストを含んでもよい。
【０１２６】
（外部データソースへの位置ベースサービスブリッジ）
上述のように、ＬＢＳアプリケーション２１０は、ユーザのプロファイル情報に基づいて特定のユーザに対して高度にカスタマイズされ得る。ユーザプロファイル情報は、リレーショナルデータベース、ポータル等において、ユーザごとに維持される任意のデータである。このようなユーザプロファイル情報が、ローカルに（例えば、ＬＢＳデータベース２３２において）または外部に（例えば、外部データソース２２８〜２３０において）格納され得る。従来技術では、外部プロファイル情報は、しばしば、ＬＢＳアプリケーション２１０のＬＢＳデータベース２３２にリロードされ、それにより、コストの増大、同期化問題、データフォーマットの不一致、および問題のある非ＬＢＳ認識データが生じる。例えば、ユーザプロファイル情報の多大な量がキャリアの外部データベース２２８〜２３０に格納され得る。従来技術では、このようなプロファイル情報を利用するために、全ての情報がＬＢＳサービスプロバイダのローカルデータベース２３２にコピーされる。しかし、キャリア２２６は、種々の理由のためにこのようなコピーを許容し得ない。
【０１２７】
このような問題を克服するために、本発明の１つ以上の実施形態は、外部プロファイルデータベース２２８〜２３０へのコンパクトＬＢＳブリッジを利用する。このＬＢＳブリッジは、データが外部データベース２２８〜２３０に残っていることを可能にするが、依然として、同じ、位置ベースサービスを提供し、そのデータを利用する。さらに、データがローカル／内部、または外部にあるのかは、なお、ユーザに対して透明であり、アプリケーション（例えばロケーションサービス）に対してシームレスである。
【０１２８】
ＬＢＳブリッジは、（属性、タイプ、および制限の名前を含む）外部データベース２２８〜２３０のスキーマ２３４（データリンクテーブルとも呼ばれる）のコンパクトな定義を提供する。このスキーマ内部では、データソース情報（例えば、どのようにして外部データベース２２８〜２３０に接続し、それらと通信するのか）、およびスキーマ２３４の記述に対応するデータソースから関連するプロパティを抽出するＳＱＬ（ｓｔｒｕｃｔｕｒｅｄ ｑｕｅｒｙ ｌａｎｇｕａｇｅ）選択ステートメントが提供される。さらに、ＳＱＬステートメントは、外部データベース２２８〜２３０の、固有識別レコードのためのキーを識別する外部（ｆｏｒｅｉｇｎ）キーカラム名前に関する情報を含む。
【０１２９】
位置ベースのサービスを提供するために使用されるさらなる情報は、ユーザプロファイルプロパティテーブル（ＵＰＰＴ）（データブリッジテーブルとも呼ばれる）の形式でＬＢＳデータベース２３２に格納され得る。ＵＰＰＴテーブルは、ローカルに格納される既存のユーザプロファイル情報であってもよいし、外部データソース２２８〜２３０にアクセスするために特別に作成されてもよい。通常、ＵＰＰＴは、ローカルデータストア２３２から外部に格納される、空間的に認識しているユーザプロファイルアイテムに関する情報を維持する。外部データソース２２８〜２３０の各レコードは、ＬＢＳデータベース２３２の（ＵＰＰＴの）レコードのための外部キーを格納することによって識別される。さらに、各外部レコードに対する位置情報が獲得／抽出され、ジオコーディング／空間インデックスとしてＵＰＰＴ内に格納される（それにより、外部データベース２２８〜２３０ＬＢＳをイネーブルにする）。さらに、必要ならば、非座標位置情報（例えば、テキストの道路アドレス、ランドマーク等）が、ジオコーディング／空間インデックスを作成するためにジオコーディングされ、ＵＰＰＴに格納される。従って、あるリンク／関係が、ローカルＵＰＰＴレコードと外部データベース２２８〜２３０に格納されるレコード／アイテムとの間で確立される。このＵＰＰＴは、外部データソース２２８〜２３０の各レコード、または外部データソース２２８〜２３０のレコードのサブセットに対するレコードを含んでもよい。
【０１３０】
これらのサービスの集合は、システムインテグレータのために、外部ＡＰＩ２２２の形式で利用可能にされる。このような外部ＡＰＩ２２２はまた、ユーザプロファイルルマネージャと呼ばれ得る。一般的なＬＢＳブリッジの結果として、ＬＢＳアプリケーション２１０は、無線キャリア２３０、電話会社２２８等によって蓄積される大量のプロファイル情報に拡張され得る。この拡張は、ＬＢＳサービスをより個人化し、エンドユーザにとってより価値があるものにする。
【０１３１】
図９は、本発明の１つ以上の実施形態による、外部データベース２２８〜２３０のためのスキーマ２３４の構造を示す。上述のように、スキーマ定義２３４は、外部データソース２２８〜２３０に関する情報を維持する。ＬＢＳアプリケーション２１０によって格納される各スキーマ２３４の定義は、外部データベース２２８〜２３０の各オブジェクトについての記述を提供する。言い換えると、外部データベース２２８〜２３０の各オブジェクトのために、対応するスキーマ２３４が存在する。例えば、外部データベース２２８〜２３０のアドレスオブジェクトは、対応するスキーマ定義２３４を有する。さらに、オブジェクトの中の各フィールド／属性のために、対応する属性定義９０２がスキーマ２３４と共に格納される。例えば、アドレスオブジェクトは、名前、数、道路名、都市、州、およびジップ（ｚｉｐ）等の複数のフィールド／属性を有する。各フィールド／属性に対して、スキーマ属性定義９０２がスキーマ２３４と共に格納される。
【０１３２】
スキーマ２３４の中のデータベース９０４のタイプ（すなわち、ｉｔｅｍＴｙｐｅ：Ｓｔｒｉｎｇ；例えば、Ａｄｄｒｅｓｓ）は、外部データベース２２８〜２３０のオブジェクトに対するタイプまたは名前を提供する。データソース情報９０６（すなわち、ｊｄｂｃＤａｔａＳｏｕｒｃｅ：Ｓｔｒｉｎｇ）は、どのようにして、外部データベース２２８〜２３０に接続し、それと通信するかに関する情報を提供する。このような情報は、データベース２２８〜２３０、そのロウ（ｒｏｗ）、およびそのカラム（ｃｏｌｕｍｎ）を含むデータが存在するロケーションを完全に定義し得る。例えば、どのキャリア２２６が特定のデータベース２２８〜２３０をホストしているのか、およびどのようにしてデータベース２２８〜２３０と通信するのかに関する情報が格納される。
【０１３３】
上述のように、属性のリスト９０８がスキーマ２３４において説明される。各属性に対して、属性定義９０２は、属性の名前、属性のタイプ、および属性の制限を提供する。従って、各スキーマ２３４に対して、単一のリスト９０８は、複数の属性定義９０２にマッピングする。
【０１３４】
ＳＱＬ選択ステートメント９１０（例えば、「ＷＨＥＲＥ」節）は、データソース２２８〜２３０から関連するプロパティ（例えば、ロウまたはレコード）を抽出するためのコマンドを提供する。従って、スキーマ２３４は、外部データベース２２８〜２３０のオブジェクトに対する全ての定義情報を含む。
【０１３５】
上述のように、ＡＰＩ２２２（ユーザプロファイルマネージャ１０００とも呼ばれる）は、スキーマ２３４の情報、およびスキーマ属性定義９０２の情報を維持するため、ならびに外部データベース２２８〜２３０から詳細な情報（すなわち、ユーザプロファイル情報）にアクセス／取り出すために利用され得る。さらに、ＡＰＩは、ＵＰＰＴから特定のエントリを追加または削除する等、ＵＰＰＴを保持するために利用され得る。さらに、ＵＰＰＴを保持する場合であっても、データがローカルデータソースから来るのか、または外部データソース２２８〜２３０から来るのかは、ユーザにとってなお透明なままである。
【０１３６】
図１０は、本発明の１つ以上の実施形態による、ユーザプロファイルマネージャを示す。外部データベース２２８〜２３０がアクセスされ得るようにスキーマ定義２３４をシステム２００に追加するために、ユーザプロファイルマネージャ１０００のｉｎｓｅｒｔＳｃｈｅｍａメソッド１００２が利用され得る。アプリケーションプロバイダまたはキャリア２２６は、この目的のためにｉｎｓｅｒｔＳｃｈｅｍａメソッド１００２を利用し得る。スキーマを追加するために、スキーマのためのスキーマ定義およびタイプ情報がユーザプロファイルマネージャ１０００に提供される。一旦、スキーマ定義２３４がシステム２００に追加された場合、スキーマ２３４の名前およびスキーマ情報が、外部アイテムタイプのスキーマ定義と呼ばれるスキーマ２３４のリストに追加される。
【０１３７】
表７は、本発明の１つ以上の実施形態による、（すなわち、ｉｎｓｅｒｔＳｃｈｅｍａメソッド１００２を用いて）システム２００に追加されたスキーマ２３４に関する情報を含む外部アイテムタイプのスキーマ定義を示す。
【０１３８】
【表１４】
表７に示されるように、アドレスオブジェクト、カスタマーオブジェクト、およびｔｙｐｅ＿ｘｘオブジェクトは全て、ＬＢＳアプリケーション２１０によって維持されるスキーマ定義２３４を有する。エントリを外部アイテムのタイプのスキーマ定義に追加するために、ｉｔｅｍＴｙｐｅ９０４を特定しつつ、ｉｎｓｅｒｔＳｃｈｅｍａメソッド１００２が使用され得る。
【０１３９】
上述のように、ＵＰＰＴは、ローカルデータベース２３２から外部に格納される空間的に認識しているユーザプロファイルアイテムについての情報を維持する。ＵＰＰＴで維持される個々のアイテムは、メソッド１００４〜１００８を用いて位置づけられかつ維持され得る。例えば、アイテム／レコードについてのデータリンクをＵＰＰＴテーブルに設定するために、メソッド１００４〜１００８の内の１つは、１つ以上の以下のパラメータ（ユーザＩｄ、タイプ情報、アイテムについての名前、アイテムプロパティ値、オプションのジオコードされたロケーション）を用いて利用され得る。
【０１４０】
位置ベースのサービスは、システム２００によって提供されているので、メソッド１０１０〜１０１４は、位置情報を利用する。しかし、外部データベース２２８〜２３０内のオブジェクト／レコードは、イネーブルのＬＢＳではない場合もある。例えば、ロケーション情報（すなわち、空間／ジオコードインデックス）は、オブジェクトに関連しない場合もある。にもかかわらず、外部データベース２２８〜２３０内に格納されたほとんどのオブジェクトは、ロケーションのようなプロパティを有し得る。例えば、外部データベース２２８〜２３０は、ホームアドレスの空間のロケーションを識別する空間インデックスではなく、携帯電話の加入者のホームアドレスを含み得る。
【０１４１】
メソッド１０１０〜１０１４が位置情報を利用することを可能にするために、データベース２２８〜２３０の各レコードに対する位置情報は、ユーザプロファイルマネージャ１０００およびメソッド１００４〜１００８を用いてＬＳＢデータベース２３２内のＵＰＰＴに格納され得る。従って、ＵＰＰＴの各レコードは、キーによって固有に識別され、そのレコードに対する位置情報を（ジオコードされた位置等の空間インデックスの形式で）含む。
【０１４２】
本発明のシステム２００を展開する場合、空間インデックスは、外部データベース２２８〜２３０内の各オブジェクトの各レコードに対して獲得され得る。したがって、この空間インデックス情報は、各レコードを識別するためのキーと共にＵＰＰＴに格納される。あるいは、ＵＰＰＴ内の個々のアイテム／特徴／レコードが、所望される場合、適切な位置情報を用いて追加されてもよいし、削除されてもよい。モバイルデバイス２０４とは異なり、外部データソース２２８〜２３０に格納される情報および関連した位置情報は、まれに変化する。したがって、ＵＰＰＴ内の情報の更新は、頻繁に発生する必要がなく、より長い間隔でスケジューリングされ得る。
【０１４３】
一旦、スキーマ定義がシステム２００内で初期化され、ＵＰＰＴが位置づけられると、ユーザプロファイルマネージャ１０００は、外部データベース２２８〜２３０から関連する情報を取り出すために利用され得る。メソッド１０１０〜１０１４は、この情報を見つけ出し、かつ取り出すために利用され得る。
【０１４４】
表８は、本発明の１つ以上の実施形態による、ユーザプロファイルマネージャ１０００によって作成されるユーザプロファイルプロパティテーブルを示す。
【０１４５】
【表１５】
表８の各ロウ／エントリは、外部データベース２２８〜２３０内のアドレスオブジェクトのレコードを表す。メソッド１００４〜１００８が、ＵＰＰＴの部分レコードに対するロケーションプロパティおよび属性を設定するために利用され得るが、ｉｎｓｅｒｔＰｒｏｐｅｒｔｙメソッド１０１６が、新しいエントリ（例えば、アドレスエントリ）をＵＰＰＴに追加するために利用される。ｉｎｓｅｒｔＰｒｏｐｅｒｔｙメソッド１０１６を用いて、（すなわち、表７の外部アイテムタイプスキーマ定義において説明されたように）ユーザＩＤが、誰がその情報を入力しているかを識別し、タイプフィールドが、入力されている情報のタイプを示す。Ｆｏｒｅｉｇｎ Ｋｅｙ Ｖａｌｕｅカラムは、外部データベース内の、そのユーザのための実際のアドレスデータのための外部キーを含む。しかし、本発明では、ユーザプロファイルプロパティテーブルにおけるアイテム値が０に設定される。なぜなら、データが外部データベース２２８〜２３０に格納されるためである。従って、実際のアドレスデータは、ＵＰＰＴ内に格納されない。
【０１４６】
キーは、そのエントリのための固有の識別子を識別する。このようなキーは、ハッシュアルゴリズムを用いて設定されてもよいし、ユーザによって設定されてもよいし、カラム／プロパティの組み合わせであってもよいし、データベース２２８〜２３０のオブジェクトのレコードを固有に識別し得る任意の他のメソッドを用いて設定されてもよい。例えば、表８では、キーは、ユーザの名前（例えば、Ｒａｊｕ、Ｓｃｏｔｔ、またはＴｉｍ）によって、エントリを固有に識別する。
【０１４７】
表８のジオメトリフィールドは、ジオコーディングインデックスとして格納される外部データベース２２８〜２３０からの選択的な位置情報を含む。このような位置情報の使用は、外部データベース２２８〜２３０のＬＢＳをイネーブルにし、それにより、空間クエリが、データ上で実行されることを可能にする。上述のように、システム２００が展開される場合、この位置情報が獲得され、データベース２２８〜２３０のレコードから抽出され得る。その後、位置情報は、ＵＰＰＴに格納される。従って、位置情報は、外部データベース２２８〜２３０に格納される情報の位置を含む。例えば、ジオコードされるロケーションは、１つ以上のカスタマーのホームアドレスのロケーションを識別し得る。
【０１４８】
一旦獲得されると、ＵＰＰＴにおけるロケーションは、次いで、高度にカスタマイズされたサービスを提供するためにＬＢＳサービスによって使用され得る。例えば、特定のカスタマーのホームアドレスのジオコードされるロケーションを用いて、カスタマーが家に向かって移動する場合、カスタマーの家の近くのレストランが決定され得る。さらに、このようなレストランの電話番号および営業時間、または実際のホームアドレスに基づくレストランへの地図が、カスタマーに提供され得る。
【０１４９】
メソッド１０１０〜１０１４およびＵＰＰＴを用いて、適切な追加のおよび所望の情報（アイテムまたはフィーチャとも呼ばれる）は、外部データベース２２８〜２３０から獲得され得る。メソッド１０１０〜１０１４は、（例えば、ｆｉｎｄＩｔｅｍｓ１０１０を用いて）複数のアイテム／フィーチャ、（例えば、ｆｉｎｄＩｔｅｍｓＣｌｏｓｅｓｔＴｏ１０１２およびＬｏｃａｔｉｏｎを特定することを用いて）特定のロケーションに最も近いアイテム／フィーチャ、または（例えば、ｆｉｎｄＩｔｅｍｓＷｉｔｈｉｎ１０１４および領域を識別するＰｏｌｙｇｏｎを特定することを用いて）所定の定義された領域内のアイテム／フィーチャを見つけ出すために使用され得る。
【０１５０】
例えば、現在のユーザに最も近いアイテム／フィーチャを見つけ出すために、ＬＢＳアプリケーションは、ｆｉｎｄＩｔｅｍｓＣｌｏｓｅｓｔＴｏメソッド１０１２を利用し、モバイルデバイス２０４にロケーションを提供する。次いで、メソッド１０１２は、最も近いロケーションを特定するためにＵＰＰＴジオメトリカラムを検討する。一旦適切なエントリが識別されると、エントリ内のキーが、外部データベース２２８〜２３０中の適切なエントリを識別する。次いで、そのメソッドは、（例えば、ｊｄｂｃＤａｔａＳｏｕｒｃｅのメソッド９０６を用いて）外部データベース２２８〜２３０とどのようにして通信するかを決定するため、および、（すなわち、ｓｑｌＳｅｌｅｃｔ９１０を用いて）情報を取り出すために使用する適切なＳＱＬ選択ステートメントを決定するためにスキーマ２３４にアクセスする。ＵＰＰＴからのキーは、外部データベース２２８〜２３０からのさらなるプロファイル情報を取り出すために、ＳＱＬ選択ステートメントと共に使用される。
【０１５１】
同様に、ｆｉｎｄＩｔｅｍｓＷｉｔｈｉｎメソッド１０１４によって、ユーザは、エントリを見つけ出すべきポリゴンを特定し得る。そのメソッド１０１４は、特定されたポリゴン内部のロケーションの位置を特定するためにＵＰＰＴジオメトリプロパティを調べる。一旦適切なエントリが識別されると、適切なキーと共にｓｑｌＳｅｌｅｃｔステートメント９１０を用いて、さらなる情報が外部データベース２２８〜２３０から取り出され得る。
【０１５２】
従って、複数のスキーマの定義２３４は、各外部データベース２２８〜２３０の定義を説明する。ユーザプロファイル情報にアクセスするために、そのスキーマは、スキーマのリストに追加される（すなわち、外部アイテムタイプのスキーマ定義）。初期化される場合、ユーザのプロファイル情報の部分が抽出され、ユーザプロファイルプロパティテーブルに格納される。ＡＰＩを介して、（例えば、標準クエリメカニズムを用いて）クエリがデータを取り出すために実行され得る。データがローカルで利用可能である場合、単に取り出されるだけである。しかし、ローカルで利用不可能な、拡張されたプロパティは、スキーマ２３４およびＵＰＰＴからのデータを使用して、クエリ（例えば、ＪＤＢＣ（登録商標）［Ｊａｖａ（登録商標） ＤａｔａＢａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ］コール）を発行することによって、内部に取り出される。ＪＤＢＣ（登録商標）コールは、ユーザが、Ｊａｖａ（登録商標）プログラミング言語から任意のテーブル状のデータソースに仮想的にアクセスすることを可能にするＡＰＩコールである。例えば、ユーザプロファイルプロパティマネージャは、ＵＰＰＴにアクセスし、外部データベース２２８〜２３０からさらなるユーザプロファイル情報を取り出すために利用され得る。
【０１５３】
ユーザプロファイルプロパティテーブルを使用することによって、実際の情報（すなわち、アイテム情報）は、外部データベース２２８〜２３０に残っている。次いで、ＳＱＬステートメント９１０は、所望された場合、特定のデータソース９０６から情報を取り出すために使用され得る。
【０１５４】
さらに、ＵＰＰＴにロケーション情報を格納することによって、位置ベースのサービスは、外部データベース２２８〜２３０からユーザプロファイル情報の全てを取り出すことなく提供され得る。例えば、ロケーション情報がユーザのロケーションを識別する場合、ロケーション情報は、近くにある特定のロケーション（例えば、ランドマーク等）を取り出すために、ｆｉｎｄＩｔｅｍｓＣｌｏｓｅｓｔＴｏメソッド１０１２において利用され得る。さらに、（例えば、上述のようにロケータアダプタベースのシステムを用いて）ユーザのロケーションが既知であるために、既知のデバイスのロケーションは、カスタマイズされたサービスをユーザに提供するように、さらなるプロファイル情報の取り出しと組み合わせて使用され得る。
【０１５５】
従って、ＬＢＳブリッジは、無線キャリア、電話会社等によって蓄積された大量のプロファイル情報への位置ベースのサービスの拡張を可能にし、次いで、そのサービスをより個人化にし、かつエンドユーザにとって価値あるものにする。
【０１５６】
（ＬＢＳブリッジの例）
ユーザが、ＬＢＳにイネーブルされたデータとは別にリレーショナルデータベース２２８〜２３０に格納されるアドレスブック／コンタクトリストおよび他の情報、ならびに／あるいは、ローカルに格納されたユーザプロファイル情報を有する場合、ＬＢＳブリッジの使用の例が生じる。ユーザは、コンタクトリスト中のユーザのコンタクトの全てを、見ること、検索すること、位置確認することを望み得る。
【０１５７】
これらの能力を提供するためには、リンクが、ローカルに格納されたアイテムと外部データソース２２８〜２３０のアイテムとの間にセットアップされる。このようなリンクは、ユーザプロファイルマネージャ１０００を用いて確立され得る。アドレスブックアイテムのための空間エントリ（すなわち、ロケーション情報）は、空間クエリをイネーブルするように明瞭に追加される必要があり得る。リンクの確立の後、アイテムは、ユーザプロファイルプロパティテーブル中のロウである。ロウにアクセスするために、ユーザｉｄ（ログインＩＤ）、アイテムタイプ（例えば、「ａｄｒｅｓｓＬｉｓｔ１」）、およびアイテムＩＤ（例えば、友人１）が使用され得る。
【０１５８】
外部データソースアイテムは、外部データソース中のロウに残っている。外部データソースのロウにアクセスするために、（例えば、ＪＤＢＣ（登録商標）データソースを識別する）外部データソース名、（例えば、データソースからロウを抽出する）ＳＱＬ選択ステートメントが必要であり、これらはすべてスキーマ定義１３４に格納される。
【０１５９】
２２２ＡＰＩを使用することによって、全てのリソースのリレーショナルおよび空間クエリが実行され得る。ＡＰＩが利用されるので、データがローカルデータソースから（例えば、ＬＢＳデータベース２３２内から）来るのか、またはデータが外部データソース２２８〜２３０から来るのかはユーザにとって透明である。
【０１６０】
このシステムを用いる際、ユーザは、スキーマ（およびデータリンク）の管理、（各レコードに対する空間情報を含む）ユーザプロファイルプロパティテーブルの位置づけ、および必要な場合は空間情報の更新に対し責任を負い得る。
【０１６１】
（ＬＢＳブリッジフロー）
図１１は、本発明の１つ以上の実施形態に従った、外部データソースへのＬＢＳブリッジの利用を示すフローチャートである。ステップ１１００において、スキーマ定義２３４は、システム２００に挿入される。スキーマ定義２３４は、システム２００の外部データベース２２８〜２３０を利用することを望む通信事業者２２６または任意の他のパーティによって挿入され得る。上述されるように、スキーマ定義は、１つ以上のスキーマ属性、実行時に外部データベース２２８〜２３０からプロパティを抽出するＳＱＬ選択文、および、外部データベースと接続および通信する方法を記述するデータソース情報を含む。該スキーマ定義の挿入はまた、ステップ１１０２においてスキーマ２３４リスト（外部アイテムタイプスキーマ定義と呼ばれる）の生成を含み得る。このようなスキーマ２３４リストは、スキーマ２３４情報／定義ならびにスキーマ２３４のネームまたはリファレンスを有するテーブルを含む。
【０１６２】
ステップ１１０４において、システムのＬＢＳブリッジは、展開／開始される。システムの展開は、ステップ１１０６において外部データベース２２８〜２３０（スキーマ定義２３４によって表現される）のデータの各レコードについて、位置情報を取得することを含む。各レコードについての取得した位置情報およびキーは、その後、ステップ１１０８のＬＢＳデータベース２３２内のＵＰＰＴにローカルに格納される。ステップ１１１０において、外部データベース２２８〜２３０の情報にアクセスするためにブリッジを利用するためのＡＰＩが、提供される。
【０１６３】
情報にアクセスするために、ＡＰＩのメソッドが利用される。メソッドは、ＵＰＰＴを評価して、（ＵＰＰＴ内に格納される位置情報に基づいて）取り出すべき適切なレコードを決定する。適切なレコード（単数または複数）のキーは、その後、外部データベース２２８〜２３０からより詳細なプロファイル情報を取り出すために利用される。メソッドは、データソース情報およびＳＱＬ選択文を含むスキーマ定義２３４からのこのような情報と通信し、かつ、これらを取り出す方法を知っている。
【０１６４】
（結論）
これで、本発明の好ましい実施形態の説明を終わる。以下は、本発明を達成するいくつかの別の実施形態を含む。例えば、メインフレーム、ミニコンピュータ、またはパーソナルコンピュータ等の任意のタイプのコンピュータ、あるいは、タイムシェアリングメインフレーム、ローカルエリアネットワーク、またはスタンドアローンパーソナルコンピュタ等のコンピュータ構成、あるいは、セルラーフォン、ラップトップコンピュータ、パーソナルデジタルアシスタント等の任意のタイプのモバイルデバイスが、本発明とともに利用され得る。
【０１６５】
本発明の好ましい実施形態の以下の説明は、図示および説明のために提示された。網羅的であること、または、開示された正確な形式に本発明を限定することは意図されない。多くの改変および変更が、上述の教示を理解することから可能である。本発明の範囲は、この詳細な説明ではなく、添付の特許請求の範囲によって制限されることが意図される。
【技術分野】
【０００１】
関連する出願の相互参照
本願は、以下の同時係属中かつ同一人に譲渡された特許出願に基きその優先権を主張するものであり、それらの出願は本明細書において参照のため援用する。
【０００２】
米国特許出願第１０／０３７，８０５号、 Ｎｅｍｍａｒａ ＣｈｉｔｈａｍｂａｒａｍおよびＪｏｈｎ Ｒｉｃａｒｄｏ ＤｅＡｇｕｉａｒによる、名称「ＭＯＢＩＬＥ ＤＥＶＩＣＥ ＬＯＣＡＴＯＲ ＡＤＡＰＴＥＲ ＳＹＳＴＥＭ ＦＯＲ ＬＯＣＡＴＩＯＮ ＢＡＳＥＤ ＳＥＲＶＩＣＥＳ」、代理人整理番号第Ｇ＆Ｃ３０５６６．２０１−ＵＳ−０１号、２００１年１２月２６日出願、
米国特許出願第１０／０３４，４４０号 Ｎｅｍｍａｒａ ＣｈｉｔｈａｍｂａｒａｍおよびＳｃｏｔｔ Ｄｉｎｇによる、名称「ＬＯＣＡＴＩＯＮ ＢＡＳＥＤ ＳＥＲＶＩＣＥＳ ＢＲＩＤＧＥ ＴＯ ＥＸＴＥＲＮＡＬ ＤＡＴＡ ＳＯＵＲＣＥＳ」、代理人整理番号第Ｇ＆Ｃ３０５６６．２０４−ＵＳ−０１号、２００１年１２月２６日出願、
米国特許出願第１０／０３４，４４２号 Ｎｅｍｍａｒａ Ｃｈｉｔｈａｍｂａｒａｍによる、名称「ＦＵＺＺＹ ＬＯＧＩＣ ＲＥＡＳＯＮＩＮＧ ＦＯＲ ＩＮＦＥＲＲＩＮＧ ＵＳＥＲ ＬＯＣＡＴＩＯＮ ＰＲＥＦＥＲＥＮＣＥＳ」、代理人整理番号第３０５６６．２０５−ＵＳ−０１号、２００１年１２月２６日出願。
【０００３】
本願は、以下の同時係属中かつ同一人に譲渡された特許出願に関し、本明細書においてそれらを参照のため援用する。
【０００４】
米国特許出願第０９／６２９，１１５号 Ｎｅｍｍａｒａ Ｃｈｉｔｈａｍｂａｒａｍらによる、名称「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＰＲＯＶＩＤＩＮＧ ＡＣＣＥＳＳ ＴＯ ＭＡＰＳ ＯＮ Ａ ＰＥＲＳＯＮＡＬ ＤＩＧＩＴＡＬ ＡＳＳＩＳＴＡＮＴ（ＰＤＡ）」、代理人整理番号第３０５６６．９６ＵＳＵ１号，２０００年７月３１日出願、
米国特許出願第０９／６２８，８５１号 Ｅｄｗａｒｄ Ｊ．Ｃｏｎｎｏｒらによる、名称「ＧＥＯＧＲＡＰＨＩＣＡＬ ＤＡＴＡ ＭＡＲＫＵＰ ＯＮ Ａ ＰＥＲＳＯＮＡＬ ＤＩＧＩＴＡＬ ＡＳＳＩＳＴＡＮＴ（ＰＤＡ）」代理人整理番号第３０５６６．９７ＵＳＵ１号、２０００年７月３１日出願、
米国特許出願第０９／６２８，８５０号 Ｎｅｍｍａｒａ Ｃｈｉｔｈａｍｂａｒａｍらによる、名称「ＧＥＮＥＲＡＬＩＺＥＤ，ＤＩＦＦＥＲＥＮＴＩＡＬＬＹ ＥＮＣＯＤＥＤ，ＩＮＤＥＸＥＤ ＲＡＳＴＥＲ ＶＥＣＴＯＲ ＤＡＴＡ ＡＮＤ ＳＣＨＥＭＡ ＦＯＲ ＭＡＰＳ ＯＮ Ａ ＰＥＲＳＯＮＡＬ ＤＩＧＩＴＡＬ ＡＳＳＩＳＴＡＮＴ」、代理人整理番号第３０５６６．９８ＵＳＵ１号、２０００年７月３１日出願、
米国出願第０９／７９５，７１９号 Ｔｉｍｏｔｈｙ Ｊｏｈｎ Ｎｅｌｓｏｎらによる、名称「ＩＮＴＥＲＰＲＯＣＥＳＳ ＡＰＰＬＩＣＡＴＩＯＮ ＰＲＯＧＲＡＭＭＩＮＧ ＩＮＴＥＲＦＡＣＥ ＦＯＲ ＰＥＲＳＯＮＡＬ ＤＩＧＩＴＡＬ ＡＳＳＩＳＴＡＮＴ ＡＰＰＬＩＣＡＴＩＯＮＳ」、代理人整理番号第３０５６６．１１０ＵＳＵ１号、２００１年２月２８日出願、
米国出願第０９／７９５，８９０号 Ｎｅｍｍａｒａ Ｃｈｉｔｈａｍｂａｒａｍらによる、名称「ＳＩＮＧＬＥ ＧＥＳＴＵＲＥ ＭＡＰ ＮＡＶＩＧＡＴＩＯＮ ＧＲＡＰＨＩＣＡＬ ＵＳＥＲ ＩＮＴＥＲＦＡＣＥ ＦＯＲ Ａ ＰＥＲＳＯＮＡＬ ＤＩＧＩＴＡＬ ＡＳＳＩＳＴＡＮＴ」、代理人整理番号第３０５６６．１１１ＵＳＵ１号、２００１年９月５日出願、
米国特許出願第０９／６２９，１１７号 Ｈｏｗａｒｄ Ｍａｒａｎｔｚらによる、名称「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＯＢＴＡＩＮＩＮＧ Ａ ＳＥＴ ＯＦ ＭＡＰＳ」、代理人整理番号第３０５６６．１１２ＵＳＵ１号、２０００年７月３１日出願、
特許協力条約出願番号ＰＣＴ／ＵＳ００／２６４３６号 Ｎｅｍｍａｒａ Ｃｈｉｔｈａｍｂａｒａｍらによる、名称「ＧＥＯＧＲＡＰＨＩＣ ＭＡＰＳ ＯＮ Ａ ＰＥＲＳＯＮＡＬ ＤＩＧＩＴＡＬ ＡＳＳＩＳＴＡＮＴ（ＰＤＡ）ＡＮＤ ＳＥＲＶＥＲ」、代理人整理番号第３０５６６．１２４−ＷＯ−Ｉ１号、２０００年９月２６日出願、
米国特許出願第０９／４１１，５０６号 Ｇｒｅｇｏｒｙ Ａ．Ｒｏｙらによる、名称「ＶＥＣＴＯＲ−ＢＡＳＥＤ ＧＥＯＧＲＡＰＨＩＣ ＤＡＴＡ」、代理人整理番号第３０５６６．１７ＵＳＣ１号、１９９９年１０月４日出願。これは、Ｇｒｅｇｏｒｙ Ａ．Ｒｏｙらによる、「ＶＥＣＴＯＲ−ＢＡＳＥＤ ＧＥＯＧＲＡＰＨＩＣ ＤＡＴＡ」という名称の、１９９９年１０月１２日に付与された米国継続特許第５，９６６，１３５号（１９９６年１０月３０日出願の出願第０８／７５７，７０６号）である。
【０００５】
（技術分野）
本発明は、一般に、ロケーションベースのサービスに関し、特に、移動デバイスのロケーションを検出しロケーションの精度をあげるための方法、装置、および製造品（ａｒｔｉｃｌｅ ｏｆ ｍａｎｕｆａｃｔｕｒｅ）に関する。
【背景技術】
【０００６】
（関連技術の説明）
（例えば、携帯電話、ＰＤＡ（ｐｅｒｓｏｎａｌ ｄａｔａ ａｓｓｉｓｔａｎｔ 携帯情報端末機器）などの）移動デバイスのロケーションの検出は、ＬＢＳ（ｌｏｃａｔｉｏｎ ｂａｓｅｄ ｓｅｒｖｉｃｅｓ ロケーションベースのサービス）の提供にとって基本的なものである。ロケーションベースのサービスは、デバイス／（例えば、携帯電話、ＰＤＡなどの）移動デバイスを利用するかまたはそれに基く、アプリケーション／サービスである。例えば、ユーザが最も近い娯楽の選択肢を要求する場合、デバイスが特定の通り（例えばＭｃＩｎｎｉｓ Ｐａｒｋｗａｙ）に位置することを検出することで、ＬＢＳアプリケーションが、（例えば、Ｎｏｒｔｈｇａｔｅ Ｍａｌｌ Ｃｉｎｅｍａなどの）近くの劇場を提供し得る。ＬＢＳアプリケーションのさらなる例として、交通情報の更新、ロケーションが重要である広告、隊の管理、および、資産と人々の追跡を含む、
しかし、ロケーション情報の提供に、異なるプロトコルが異なる携帯電話キャリアによって使用され得る。したがって、従来技術では、ロケーション情報を提供するために、ＬＢＳアプリケーションが、それぞれの携帯電話キャリアのために個々に構成されなければならない。そのような構成のカスタマイズは、ＬＢＳのプロバイダにとって、時間がかかり、絶え間ない複数の修正／更新、およびわずらわしさが必要となる。
【０００７】
さらに、個々のユーザにとっては、ユーザに関して知られている情報に基くＬＢＳアプリケーションのカスタマイズが望ましい。しかし、そのような情報は、たびたび地域的に使用できず、アクセスすることが困難であるかまたは不可能である。したがって、必要とされるのは、ユーザの個人情報にアクセスし使用し得ることである。
【０００８】
さらに、現在、従来技術の無線キャリアによって提供されるデバイスのロケーションは、おおざっぱな（例えば、精度に、数百メートルから１０００メートル以上の幅がある）ものである。したがって、ＬＢＳサービスは、そのサービスを価値のあるものとするために、このロケーションの精度を上げることが必要である。
【０００９】
これらの問題は、従来技術のロケーション検出および個人情報の使用についての説明によって、よりよく理解され得る。
【００１０】
（従来技術のロケーション検出）
上記のように、デバイスのロケーションを決定し、ＬＢＳアプリケーションにデバイスのロケーションを提供するために、数多くの方法／プロトコルが移動デバイスキャリアによって使用される。例えば、デバイスの認識のために、異なる方法が使用され得る。さらに、キャリアの移動位置標定サーバ（ＭＰＳ）との通信のために、異なるプロトコルが使用され得る。移動位置標定サーバとリクエスト／応答を交換するための異なる形式がまた使用され得る。さらに、異なるレベルの、ロバスト性、エラー処理、およびネットワーク基盤の安定性がある。
【００１１】
ＭＰＳによって提供されるロケーションは、しばしば、精度／正確さのレベルが異なっている。例えば、ほとんどのロケーション技術はセルセクタベース（つまり、ロケーションは、単に、ある特定のセルセクタ内にあるとして識別される）である。したがって、ＭＰＳによって提供される近似のロケーションは、１５０メートルから数百メートル、または１０００メートル以上も、デバイスの実際のロケーションから離れていることもあり得る。したがって、ほとんどのＭＰＳサービスは、非常に不正確な、移動デバイスがその範囲内にいる、地理的地域を提供するのみである。
【００１２】
そのように異なる方法の使用は、ＬＢＳプロバイダにとって問題を含む。ほとんどのＬＢＳプロバイダの興味の中心は、デバイスのロケーションを利用するアプリケーション／ビジネスロジックにある。しかし、多くの環境およびプラットフォームで使用されるアプリケーションにとって、各セルラープロバイダのためにアプリケーションをカスタマイズするには、かなりの時間とプログラミングが必要である。
【００１３】
さらに、ロケーションの不正確さが、ユーザにとってのＬＢＳアプリケーションの価値に影響を及ぼす。例えば、ビジネス／娯楽検索、友人探し、および／またはルート検索などの、より人気のあるＬＢＳアプリケーションは、近似現在ロケーションがさらに正確な場合、ユーザにとって、さらに非常に価値のあるものであり得る。したがって、必要とされるのは、近似ロケーションを、より正しくユーザの真の居所を表すロケーションへ、またはユーザがすぐに識別し得るユーザの近くの著名な目標物（ｌａｎｄｍａｒｋ）へと、さらに詳細に修正する性能である。
【００１４】
図１は、近似ロケーションと、ロケーションの不正確さを表すエラー多角形を示す。デバイスの近似ロケーションは円１００として示される。エラー多角形１０２はロケーションの不正確さを表す。従来技術における問題は、ユーザの真のロケーションを表す可能性のある、修正されたロケーションの生成にある。さらに、その修正は、ユーザの現在ロケーションの近傍にあり、ユーザによって直ぐに識別されるのに十分に顕著である、ロケーション１０４を生成することが期待される。さらに、最も最良の場合、この修正されたロケーション１０４がユーザの真のロケーションと等しい。
【００１５】
（従来技術のユーザカスタマイズ）
ＬＢＳアプリケーションは、ユーザについての個人情報（つまり、ユーザのプロファイルの情報）を用いて、個々のユーザのためにカスタマイズがなされ得る。例えば、このユーザのプロファイル情報には、ユーザ名、自宅／職場住所、および、料理、旅行の好みなどに関する嗜好でさえ含み得る。この情報を、（例えば携帯電話の）無線デバイスに送信することによって、ＬＢＳアプリケーションは、ユーザの好みに適するように、高度にカスタマイズされ得る。この個人化されたデータは、現在、電話交換機、無線キャリアデータベースなどから入手し得、たびたび、ＬＢＳデータベースにリロードされる。例えば、携帯電話キャリアによって保存されているプロファイル情報を利用するために、全てのデータベースが送られ得、かつローカルに格納され得る。
【００１６】
個人化された情報のそのようなリロードは、コストの増加（つまり、時間、努力、金銭）、同期化問題（つまり、時間の経過によって、ソースおよびＬＢＳデータベースに複製されたデータとの間に差が出来上がる。さらに、データは、異なる製造元の異なるデータベースから、または、異なるオペレーションシステムの異なるファイルから、異なる形式で、異なるスキーマで入ってき得、顧客データは、ＬＢＳを認識しない（つまり、ロケーション要素を有さない）。さらに、移動電話キャリアが、データベースの送信を許可しないこともあり得る。
【発明の概要】
【課題を解決するための手段】
【００１７】
（発明の要旨）
本発明の１つ以上の実施形態が、多くの移動デバイスキャリアおよび／またはファジー論理を用いて、デバイスのロケーションを決定し、ユーザのプロファイル／個人情報に基く特定のユーザのためのロケーションベースのサービスをカスタマイズするための、方法、システム、装置、および製造品を提供する。
【００１８】
デバイスロケータ（デバイスロケータアダプタとも呼ばれる）が、ユーザのために、共通の一様なアプリケーションプログラムインターフェース（ＡＰＩ）を提供する。デバイスのロケーションを割り出しているとき、ＡＰＩは、アプリケーション開発者を切り離し、かつそれら開発者が特定の移動デバイスキャリアを無視できるようにする。デバイスロケータは、キャリアからリクエストされると、特定のキャリアの位置標定サーバ、およびデバイスを識別する異なる方法（例えば、携帯電話番号、無線用途リクエストの「ｃｏｏｋｉｅ」中に符号化されるＭＳＩＳＤＮ（ｍｏｂｉｌｅ ｓｕｂｓｃｒｉｂｅｒ ｉｎｔｅｒｎａｔｉｏｎａｌ ｓｕｂｓｃｒｉｂｅｒ ｄｉｒｅｃｔｏｒｙ ｎｕｍｂｅｒ）、リクエストヘッダの中に符号化されるＩＰアドレス、またはユーザプロファイルデータベースの中の事前に格納されたデフォルト）と相互作用する。さらに、デバイスロケータは、キャリアのプロトコルの相違（例えば、ＨＴＴＰ，ＨＴＴＰＳ，など）に対処する。デバイスロケータは、キャリア基盤内のネットワークの不安定さに対処することによってロバスト性を提供する。
【００１９】
ロケーションベースサービスは、アプリケーションおよび内容が自動的にユーザの現在の活動プロファイルと整合するように作成される場合、ユーザにとっての価値が非常に上がり得る。例えば、通勤客は、列車やバスの駅、および目的地に早く到着するための別の経路を詳しく見ることに興味を持ち得るが、一方、レジャーの旅行者は、「旅行者にとっての目標地点（ｔｏｕｒｉｓｔ ｌａｎｄｍａｒｋｓ）」への簡単なアクセスを望む。
【００２０】
したがって、一旦ＡＰＩを介してデバイスの近似ロケーションが決定されると、その近似ロケーションは１つ以上の思考モデルを適用して移動位置標定サーバによって修正され得る。例えば、近似ロケーションは、市街ネットワーク上の最短地点へと素早く動かされ得るか、または近隣のランドマーク、または「見どころ」へと素早く動かされ得る。あるいは、その修正は、近似ロケーションの近隣で、（例えば、ユーザプロファイルの「履歴」を調べることによって）移動デバイスユーザが最近訪れたロケーションを探し得る。さらに、近似ロケーションは、移動デバイスユーザによってブックマークされた「お気に入り」のロケーションを調べることによって、および近似のデバイスロケーションの近隣に何らかの「お気に入り」のロケーションがあるかどうかを決定することによって、修正され得る。
【００２１】
さらに、新しいキャリアを利用するために、またはシステムに常駐するキャリアを修正するために、単に、新しいアダプタが追加されるだけである。アプリケーション開発者の立場からするとＡＰＩは同じままであり、全システムの新しいバージョンが配備される必要はない。したがって、本発明では、新しいアダプタが、動的に配備され使用される。
【００２２】
さらに、ユーザの現在ロケーションのインテリジェント推論および活動プロファイル（または意図）が不必要な内容の排除を助け、無線アクセスのコスト、時間および性能が向上する。本発明の１つ以上の実施形態は、ユーザの現在ロケーションについてインテリジェント推量をするために、ファジー論理推論と呼ばれる人工知能の分岐（ブランチ）を使用し、かつ（例えば、このユーザはビジネスの旅行者か？ 職場の近くにいるか？ または列車の駅の近くにいる通勤客か？など）ユーザの現在の活動プロファイルの意図を推論する。
【００２３】
本明細書に説明するモデルは、曖昧で、不正確で、重複し、競合する入力を捕捉するための正式な構造を提供する。例えば、このモデルは、「ユーザの現在の活動はレジャーの旅行客のプロファイルと整合するか？」との質問に、純然たる「はい」／「いいえ」に対して、「多分整合する」または「はっきりしない」という答えを作成し得るという事実を処理し得る。同様に、このモデルは、ユーザの現在の活動は、ビジネスの旅行者のプロファイルおよびレジャーの旅行者のプロファイルの両方に整合し得るという事実も考慮し得る。
【００２４】
入力は、空間的、時間的（時間に関連した）、空間的−時間的（速度ベクター）、および活動プロファイルのインジケータを含む。このモデルは、入力の参加の度合い（たとえば、ことによると（ｐｅｒｈａｐｓ）＝０．４、おそらく（ｌｉｋｅｌｙ）＝０．６、非常にあり得る（ｖｅｒｙ ｌｉｋｅｌｙ）＝０．８）を決定する自然な言語の記述（すなわち入力）を翻訳するメンバーシップ関数を提供する。
【００２５】
さらに、このモデルは、問題に対する現在の理解状況を、入力および出力に関係する直観的な、人の言語の規則ベースで表し得る。例えば、規則は、「仮にＸおよびＹとすると、その場合はＺである」（例えば、もし曇りおよび外套なら、雨であり得る）という形式であり得る。すべての規則を含む規則ベースは、（例えば、中央アメリカのシエスタ(昼寝）の時間中の施設の閉鎖を考慮するなど）地域的、社会的、または人口統計学的動向を反映するように、簡単に構成され得る。
【００２６】
メンバーシップ関数の評価に基いて規則を入力に適用することによって、推論エンジンが、規則を処理し、明確な答えを修正されたロケーションとして提供する。この答えは、アプリケーションによって要求されるように、１つの修正されたロケーションまたは候補地リストであり得る。
【００２７】
その結果、ユーザの現在のロケーションが推理、推論され得、いくつかの「活動プロファイル」の１つに分類され得る。このことによって、次に、アプリケーションが、無線キャリアによって蓄積された膨大な量のプロファイル情報の価値を高め得、アプリケーションおよび無線デバイスに配信された内容の両方を個人化することによって、利用者に提供されるサービスの価値が向上する。
【００２８】
一旦ロケーションが修正されると、ロケーションベースサービスはユーザのプロファイル／個人情報に基きカスタマイズされ得る。従来技術のロケーションベースサービスのカスタマイズのために、キャリアによって保持されているデータベースは、データがまだ正確であることを確実にするために、たびたびローカルにコピーされ、頻繁にリロードされた。本発明の１つ以上の実施形態では、すべてのレコードがデータベースの中に残りローカルにコピーされないが、アプリケーションによって他地域／外部データベースにアクセスし得る。
【００２９】
実施形態は、外部プロファイルデータベースへのコンパクトＬＢＳブリッジを設計し、実行する。このＬＢＳブリッジは、（属性の名前、種類、および制約を含む）外部データベースのコンパクトスキーマ定義を含む。ＬＢＳブリッジはまた、（例えば外部データベースとの接続および通信の方法などの）データソース情報およびスキーマ定義に対応する、データソースからプロパティを抽出するＳＱＬステートメントを含む。ＬＢＳデータベース内のテーブルにある各レコードに対する外部キーを格納することによって、外部データソースのレコードが識別される。さらに、外部レコードからのロケーション情報が、抽出／獲得され、ジオコードインデックスとしてテーブルに格納される（そのようにして、外部データベースをＬＢＳイネーブルとする）。サービスの収集が、システムインテグレータへの外部アプリケーションプログラミングインターフェースの形で、こうして利用可能となる。
【００３０】
ＬＢＳブリッジの結果、ロケーションベースサービスは、無線キャリア、電話会社などによって蓄積された大量のプロファイル情報に拡張し得、それが今度は、それらのサービスを、さらに個人化された、エンドユーザにとってさらに価値のあるものにする。したがって、本発明のロケーションの実施形態は、外部のデータベースおよびポータルなどにあるユーザプロファイル情報を可能とし、かつ内部および外部のプロファイル情報の両方を使用してシームレスなロケーションサービスの提供を可能とする。
【００３１】
今度は、図面を参照するが、全体を通して、同様の参照番号は対応する部分を表す。
【図面の簡単な説明】
【００３２】
【図１】図１は、近似ロケーションおよびロケーションの不正確さを表すエラー多角形を示す。
【図２】図２は、本発明の１つ以上の実施形態に従って使用される、ハードウェアおよびソフトウェアの環境の概略を示す。
【図３】図３は、本発明の１つ以上の実施形態による、デバイスロケータをサポートするアーキテクチャを簡単に表したものを示す。
【図４】図４は、本発明の１つ以上の実施形態による、アークとしてモデル化されたロケーションデータを示す。
【図５】図５は、本発明の１つ以上の実施形態による、移動デバイスロケータアダプタシステムのアプリケーションプログラミングインターフェースの使用を示すフローチャートである。
【図６】図６は、本発明の１つ以上の実施形態による、重みつき入力の曖昧な重心として修正されたロケーションを示す。
【図７】図７は、本発明の１つ以上の実施形態による、ファジー論理推論プロセスの概略を示す。
【図８】図８は、本発明の１つ以上の実施形態による、デバイスのロケーションを修正するためのファジー論理推論の使用を示すフローチャートである。
【図９】図９は、本発明の１つ以上の実施形態による、外部データベースのためのスキーマの構造を示す。
【図１０】図１０は、本発明の１つ以上の実施形態による、ユーザプロファイルマネージャを示す。
【図１１】図１１は、本発明の１つ以上の実施形態による、外部データソースへのロケーションベースサービスブリッジの使用を示すフローチャートである。
【発明を実施するための形態】
【００３３】
以下の説明において、本明細書の一部を形成する添付の図面を参照するが、その図面には、実施例として、本発明のいくつかの実施形態が示される。別の実施形態が使用され得、かつ構造的変更が本発明の範囲から逸脱することなくなされ得ることが理解される。
【００３４】
ＡＰＩによって、移動デバイスキャリアにかかわらず、ロケーションベースサービスアプリケ―ションがデバイスのロケーションを決定し得る。キャリアの位置標定サーバ、移動デバイス識別方法、およびプロトコルの特性は、ＡＰＩの方法によって内部的に処理される。したがって、アプリケーションは隔離され、キャリアの特定の細部が透明となる。さらに、ヒューリスティックスを使用して、デバイスの近似ロケーションが修正され得る。
【００３５】
さらに、本発明の１つ以上の実施形態が、デバイスの近似ロケーションを修正するためにファジー論理推論を用いるための方法を提供する。種々の不正確な入力が、メンバーシップ関数によって処理され、間隔「０、１」に沿って３つの真の値が割り当てられる。この真の値が入力の規則への参加の度合いを定義する。その後、１つ以上の規則を含む規則ベースを介し、推論エンジンが真の値に従って入力を処理する。各規則は、真の値を使用し得る前件および修正されたロケーションを特定する後件とを有する。それらのルールが、後件のための真の値を定義する各規則のために（０から１の間隔内で）論理演算結果を生成する。方法は、その後、論理演算結果に基く適切な修正されたロケーションの選択に使用される。
【００３６】
さらに、アプリケーションプログラミングインターフェースを使用して、外部データベースのスキーマの定義と、いかに外部データベースと接続しかつ通信するかを記述するデータソース情報と、実行後すぐに、スキーマ定義に対応するプロパティを外部データベースから抽出するデータベースクエリステートメントとを含むＬＢＳブリッジが作成される。ロケーション情報および外部データベースにある各レコードのための外部キーがテーブルに格納され、どのレコードが、所望のロケーション内にあり、カスタマイズされたロケーションベースサービスの提供のために取り出される必要があるかを決定するのに使用される。一旦特定されると、データベースクエリステートメントと外部データベースから所望の情報を取り出すためのスキーマ定義に記述された情報とを用いて、テーブルのキーが使用される。したがって、ＬＢＳブリッジが、アプリケーションプログラミングインターフェースを介してユーザの個人情報にアクセスするための方法、機器、および製造品を提供する。
【００３７】
（ハードウェア環境）
図２は、本発明の１つ以上の実施形態に従って使用されるハードウェアおよびソフトウェア環境の概略を示す。典型的な分散型データ処理方式のコンピュータシステム２００は、（例えば携帯電話、ＰＤＡ、ＷＩＮＣＥ、またはＰＡＬＭデバイスの）移動デバイスクライアント２０４、または（例えばブラウザを走らせているコンピュータシステムなどの）デスクトップクライアントを利用する技術者とサーバコンピュータ２０６とを接続するために、（インターネットなどの）ネットワーク２０２を利用する。
【００３８】
移動デバイスクライアント２０４は、ＨＰＣ（ｈａｎｄｈｅｌｄ ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ、ハンドヘルドパソコン）、ＰＰＣ（ｐａｌｍ−ｈｅｌｄ ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒ，パームヘルドパソコン）またはＰＤＡ、携帯電話、スマート電話（ｓｍａｒｔ ｐｈｏｎｅ）など任意の種類の移動デバイスを含み得る。しかし、本発明の実施形態は、デスクトップクライアントにも同様に実行され得る。（本明細書では）これ以降、移動デバイスクライアント２０４およびデスクトップクライアントは取り替え可能に用いられ得、かつ全種類のクライアント／クライアントコンピュータシステムを参照する。システム２００に使用されるリソースの典型的な組み合わせは、携帯電話網、インターネット、ＬＡＮ，ＷＡＮなどのネットワーク２００、移動デバイス２０４、デスクトップクライアント、およびパソコン、ワークステーション、ミニコンピュ―タまたはメインフレームのサーバ２０６を含み得る。
【００３９】
ネットワーク２０２は、移動デバイスクライアント２０４またはサーバコンピュータ２０６に対し適切なソフトウェアアプリケーションを実行しているデスクトップクライアントと接続する。サーバコンピュータ２０６は、（例えばＷｅｂサーバの）サーバアプリケーション２０８、ＬＢＳアプリケーション２１０、ＭａｐＧｕｉｄｅサービス２１２、および／またはｓｅｒｖｌｅｔ２１４などを含む種々のアプリケーションを実行し得る。ＭａｐＧｕｉｄｅサーバ２１２およびｓｅｒｖｌｅｔ２１４は、サーバアプリケーション２０８内またはその部分に常駐し得る。サーバ２０６およびそのコンポーネントはまた、バックオフィスシステム（ｂａｃｋ ｏｆｆｉｃｅ ｓｙｓｔｅｍ）とも呼ばれる。そのようなバックオフィスシステムは企業データベース、同期ユーティリティなどへのアクセスを保持する。サーバアプリケーション２０８は、通常、ＵＮＩＸ（登録商標） Ａｐａｃｈｅ ＷｅｂサーバまたはＭｉｃｒｏｓｏｆｔ’ｓ Ｉｎｔｅｒｎｅｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｒｖｅｒなどのプログラムである。ｓｅｒｖｌｅｔ２１４は、クライアント２０４によってリクエストされた任意の追加の処理がｓｅｒｖｌｅｔ２１４によって実行され得るように、サーバアプリケーション２０８を介してクライアント２０４と通信を行い得る。
【００４０】
ロケーションベースサービスを提供する地理情報システム（ＧＩＳ）において、ｓｅｒｖｌｅｔ２１４は、必要な地図データ／情報を入手するために、ＭａｐＧｕｉｄｅサーバ２１２と通信を行い得る。さらに、ｓｅｒｖｌｅｔ２１４は、マップウィンドウファイル（ＭＷＦ）２１６にアクセスし、関連データを入手する。ＭａｐＧｕｉｄｅサーバ２１２（または別のアプリケーション）はまた、データベース管理システム（ＤＢＭＳ）２１８と相互作用し得る。このＤＢＭＳ２１８は、（ＳＤＦ（Ｓｐｅｔｉａｌ Ｄａｔａ Ｆｉｌｅｓ）データ（大量のデータを素早くイントラネットまたはインターネット上に配信するための特別なデータ形式）、ラスター（ｒａｓｔｅｒ）データ、Ｏｐｅｎ ＤａｔａＢａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ（ＯＤＢＣ）データなどの）関連する地図データをデータベース２２０から取り出すために使用される。
【００４１】
さらに、クライアント２０４は、デバイス２０４のロケーションを決定し追加のロケーションベースサービスを提供するための一様なインターフェースを提供するアプリケーションプログラミングインテーフェース（ＡＰＩ）を介して、ＬＢＳアプリケーション２１０とインターフェースで連結する。クライアントデバイス２０４のロケーションを決定するために、ＬＢＳアプリケーションは、様々な移動デバイスキャリア２２６の異なるプロトコルそれぞれに対する１つ以上のアダプタ２２４を使用し得る。キャリア２２６はまた、１つ以上のデータベース２２８から２３０にユーザプロファイル情報を保持し得る。上記のように、ＬＢＳアプリケーション２１０はまた、（例えば、情報のローカル格納のための）ＬＢＳデータベース２３２を保持し得る。（上記のように）従来技術では、ユーザプロファイル情報はたびたびＬＢＳデータベース２３２にリロードされる。
【００４２】
ＬＢＳアプリケーション２１０は、外部データベース２２８から２３０へのコンパクトＬＢＳブリッジを実行する。ＬＢＳブリッジを実行するために、ＬＢＳアプリケーション２１０は、外部データベース２２８から２３０のそれぞれのスキーマのコンパクト定義２３４を保持する。スキーマは以下に詳しく説明される。さらに、ＡＰＩ２２２がファジー論理を用いてデバイスのロケーションの修正のためのインターフェースを提供し得る。
【００４３】
概して、コンポーネント２０４から２３４のすべてが、例えば、データ格納デバイス、データ通信デバイス、ネットワークまたは別のデータコミュニケーションデバイスを介してコンピュータに接続されるリモートコンピュータまたはデバイスなど、デバイス、媒体、信号またはキャリアにおいて具体化されるまたはデバイスから取り出し得るロジックおよび／またはデータを含む。さらに、このロジックおよび／またはデータは、読まれ、実行され、および／または翻訳処理されるとき、実施されている本発明の実行および／または使用に必要なステップを生じる結果となる。
【００４４】
したがって、本発明の実施形態が、ソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組み合わせを製造するための標準プログラムおよび／または工学技術を使用する、方法、装置、または製造品として実施され得る。本明細書において使用される用語「製造品（ａｒｔｉｃｌｅ ｏｆ ｍａｎｕｆａｃｔｕｒｅ）」（または、その代わりに「コンピュータプログラム製品」）は、任意の、コンピュータを使用し得る、デバイス、キャリアまたは媒体からアクセス可能なロジックおよび／またはデータが含まれることが意図される。
【００４５】
当業者は、本発明の範囲から逸脱することなく、この例示的環境に対し、多くの改変がなされ得ることを認識する。例えば、当業者は、上記のコンポーネントの任意の組み合わせ、または、異なるロジック、データ、異なる周辺装置、および異なるデバイスを含むかなり多くの異なるコンポーネントの任意の組み合わせが、それによって同様の機能が実行される限り、本発明の実行のために使用され得ることを理解する。
【００４６】
（移動デバイスロケータアダプタシステム）
デバイスロケータアプリケーションは、特定の移動デバイスクライアント２０４のロケーションの決定のために、クライアント２０４またはサーバ２０６上で実行し得る。デバイスロケータアプリケーションは、特定の移動デバイスクライアント２０４のロケーションの決定のために、クライアント２０４またはサーバ２０６上で実行し得る。移動デバイスクライアント２０４のロケーションの決定のために、デバイス専用アイデンティフィケーションがデバイスロケータに提供される。例えば、ＭＳＩＳＤＮ（ｍｏｂｉｌｅ ｓｕｂｓｃｒｉｂｅｒ ｉｎｔｅｒｎａｔｉｏｎａｌ ｓｕｂｓｃｒｉｂｅｒ ｄｉｒｅｃｔｏｒｙ ｎｕｍｂｅｒ）（ディレクトリナンバー（例えば、ＧＳＭ（登録商標）−ｇｌｏｂａｌ ｓｙｓｔｅｍ ｆｏｒ ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｎｕｍｂｅｒ）またはＧＳＭ（登録商標）加入者に接続するためのナンバー１ダイアル）がデバイスロケータアプリケーション２１０に提供され得る。そのようなＭＳＩＳＤＮは、無線アプリケーションリクエストのｃｏｏｋｉｅの中に符号化され得る。あるいは、デバイスは、リクエストヘッダに符号化されたＩＰ（インターネットプロトコル）アドレスによって識別され得るか、またはユーザプロファイルデータベース２２８から２３０に事前に格納されたデフォルトによって識別され得る。
【００４７】
デバイスロケータ２１０によってその結果提供されるロケーションは、デバイス２０４の座標、デバイス２０４のＳＲＳ（ｓｐａｔｉａｌ ｒｅｆｅｒｅｎｃｅ ｓｙｓｔｅｍ空間基準システム）および座標の正確さに関する情報を含む。
【００４８】
デバイスロケータ２１０が、ネットワークが提供するデバイス２０４のロケーションへのアクセスのためのインターフェース２２２を提供する。（例えばＳＩＭカードを介して）自身のロケーションを提供するデバイス２０４に対し、アプリケーション開発者は、すでにデバイス２０４の座標を有しており、デバイスロケータ２１０を使用する必要がない。
【００４９】
デバイスロケータ２１０は、ユーザに、デバイス２０４のロケーションの決定のための一様のＡＰＩ２２２を提供する。デバイスロケータ２１０は、デバイス２０４のロケーションをＬＤＴ（ｔｈｉｒｄ−ｐａｒｔｙ ｌｏｃａｔｉｏｎ ｄｅｔｅｒｍｉｎａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ サードパーティロケーション決定技術）プロバイダ２２６から取り出す。このＬＤＴのそれぞれは、（例えば、ＨＴＴＰ、ＨＴＴＰＳなどの）異なるプロトコルをサポートし得る。ＬＤＴは、デバイス２０４のロケーション情報を内部および外部のシステムに提供する、キャリアネットワークベースサービスを表す一般的な用語である。ＬＤＴアダプタ２２４は、特定のキャリア２２６によって供給され得、ロケーション情報の提供に使用され得る。供給されるＬＤＴアダプタ２２４以外のソースから得られる任意のロケーションは、ロケーションパラメータを要求する任意のアプリケーションプログラム情報（ＡＰＩ）の呼び出しにおいて、ＧＩＳアプリケーションのすべてを通じて、なお使用され得る。上記のように、ＬＤＴプロバイダ／キャリア２２６は、それぞれ、リクエストの形式、応答の形式、および応答の正確さに関して異なる、違ったプロトコルをサポートし得る。移動システムが所在する、地理的地域のみを提供し得るサービスもあれば、特定の座標を提供し得るサービスもある。
【００５０】
デバイスロケータインターフェース（すなわちＡＰＩ）２２２は、個々のＬＤＰプロバイダ２２６の特定のＡＰＩからアプリケーションコードを隔離する。アプリケーション開発者は、プロバイダのＡＰＩまたはプロトコルを理解する必要がない。かわりに、ＬＤＴアダプタ２２４が特定のプロバイダのＡＰＩを、デバイスロケータ２１０としてアプリケーションに与えられた一般的なＡＰＩ２２２に翻訳する。ＬＤＴアダプタ２２４は、したがって、ＨＴＴＰ（ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）、ＨＴＴＰＳ（ｓｅｃｕｒｅ ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）などのプロトコルの違いからアプリケーションを隔離する。そのようなアーキテクチャはまた、将来、アプリケーションＡＰＩ２２２を変更することなく、追加のＬＤＴプロバイダ２２６をサポートし得る。新しいＬＤＴプロバイダ２２６のために、ただ、ＬＤＴアダプタ２２４が書かれる必要があるのみである。
【００５１】
図３は、本発明の１つ以上の実施形態による、デバイスロケータ２１０をサポートするアーキテクチャを簡単に表したものである。例示するように、アーキテクチャがいくつかの層３０２から３０８を有する。デバイス２０４のロケーション情報を入手するために、アプリケーション層３０２の中のアプリケーションコード３１０が、プラットフォームＡＰＩ層３０４で、一様なＡＰＩ２２２を介して、（例えば、ＬｂｓＤｅｖｉｃｅＬｏｃａｔｏｒＭａｎａｇｅｒの）デバイスロケータ３１２とインターフェースで連結される。
【００５２】
キャリアに特有のインプリメンテ―ションを用いてロケーション情報を取り出すために、デバイスロケータ３１２は、内部層３０６の特定のキャリアＬＤＴアダプタ２２４に記述される個々のキャリアプロトコルとインターフェースで結合される。キャリアＬＤＴアダプタ２２４は、リモートＬＤＴプロバイダ層３０８のサーバコード３１８と通信するクライアントコード３１６と相互作用する。
【００５３】
デバイス２０４のロケーションのクエリを行うために、アプリケーションコード３１０が、（例えば、ＬｂｓＤｅｖｉｃｅＬｏｃａｔｏｒＭａｎａｇｅｒ）のデバイスロケータオブジェクト３１２の事例を取り出す。デバイスのｉｄが与えられたデバイス２０４のロケーションを入手するために、アプリケーションコード３１０は、その後、デバイスロケータ３１２を使用し得る。上記のように、デバイスのｉｄの形式は、ＬＤＴの実行によって異なり得る。デバイス２０４のロケーションのクエリが失敗した場合、デバイスロケータ３１２が例外を生成し得る。
【００５４】
クエリが成功した場合、ロケーションオブジェクトはアプリケーション層３０２に戻され得る。上記のように、その結果としてのロケーションオブジェクトは、デバイスのロケーションを表す座標を含むＰｏｉｎｔ／Ｃｏｏｒｄｉｎａｔｅオブジェクト、関連する空間基準システムを記述するＳＲＳオブジェクト、および座標の正確さを記述するＰｒｅｃｉｓｉｏｎオブジェクトを含む。
【００５５】
本発明の１つ以上の実施形態では、デバイスロケータマネージャが、個々のキャリア２２６のために／によって実行される特定のｇｅｔＬｏｃａｔｉｏｎ（）方法にＡＰＩ２２２およびデリゲートコールを提供する。個々のキャリア２２６がそのようなｇｅｔＬｏｃａｔｉｏｎ方法を実行するのを確実にするために、（例えば、デバイスロケータ インターフェースなどの）インターフェースが特定のデバイスロケータアダプタ２２４によって実行され得る。
【００５６】
（Ｅｒｉｃｓｓｏｎ（ＴＭ）実施）
上記のように、様々なアダプタ２２４がＬＢＳアプリケーション２１０によって利用さ得る。各アダプタ２２４は、特定のセルラーキャリア２２６として構成され得る。以下の記載は、Ｅｒｉｃｓｓｏｎ（ＴＭ）用に実施されたアダプタ２２４実施をサポートすることに特定されている。Ｅｒｉｃｓｓｏｎ（ＴＭ）では、デバイスｉｄは、ＭＳＩＳＤＮとして表されている。
【００５７】
Ｅｒｉｃｓｓｏｎ（ＴＭ）実施は、セル内にデバイス２０４を位置付けて、セルタワーからのおおよその距離を決定可能である。セルは、基地局を取り囲むか、基地局に直ぐ近くの地理上の領域である。このロケーションは、図４に示された円弧でモデリングされ得る。（例えば、ロケーションオブジェクトの一部として）戻された点オブジェクトは、円弧の地理的中心を表し、アプリケーション層３０２は、内径ｄ１および外径ｄ２を取り出し得る。角度θ１およびθ２は、北向きから時計回りに計測される度数である。
【００５８】
デバイスロケータ３１２がデバイス２０４のロケーションを決定できない場合、デバイスロケータ３１２は、所定／特定の回数だけリクエストをリトライする。特定のリトライ数の後、このデバイスロケータ３１２が依然としてロケーションを決定できない場合、例外が投げられる。通常、例外は、ＬＤＴプロバイダ２２６／アダプタ２２４とインターフェースするときに起こる。ＬＤＴプロバイダ２２６が例外を生成する場合、プロバイダ２２６によって提供された任意のさらなる情報（エラーコードおよびメッセージ等）がエラーログファイルに書き込まれ得る。
【００５９】
デバイスロケータ３１２のエラーコードをエラーコードのリストと比較することによって、デバイスロケータ３１２により例外が投げられたことを決定し得る。以下の表は、Ｅｒｉｃｓｓｏｎ（ＴＭ）の実施によって戻されたエラーコードを説明している。このエラーコードは、エラーログファイルに現れる。この表において、用語統一システムは、ロケーションを特定するシステムに関する。Ｅｒｉｃｓｓｏｎ（ＴＭ） Ｐｏｓｉｔｉｏｎｉｎｇ Ｐｒｏｔｏｃｏｌ（Ｅｒｉｃｓｓｏｎ（ＴＭ））は、モバイルポジショニングセンターとインタフェースするＥｒｉｃｓｓｏｎによって開発されたＨＴＴＰ／ＨＴＴＰＳベースの規格に関する。ＩＤＭＳ０は、縦または横を特定するフォーマットに関する。ここで、Ｉは主軸方向、Ｄは角度（２または３桁）、Ｍは分（２桁）、Ｓは秒（２桁）、および０は小数点以下が無いことを示す（例えば、Ｅ１５３８０６またはＮ６０３７５８）。さらに、モバイルポジショニングセンター（ＭＰＣ）は、Ｅｒｉｃｓｓｏｎ（ＴＭ）によって用いられる用語であり、アプリケーションをモバイルステーションポジション情報にアクセス可能にするポジショニングゲートウェイを説明している。さらに、モバイルポジショニングシステム（ＭＰＳ）は、Ｅｒｉｃｓｓｏｎ（ＴＭ）によって用いられる用語であり、ＬＤＴに対するＭＰＰを実施することを説明している。このエラーコードは、Ｅｒｉｃｓｓｏｎ（ＴＭ）ＭＰＳ ＳＤＫのバージョン３．０を表している。
【００６０】
表１‐Ｅｒｉｃｓｓｏｎ（ＴＭ）汎用エラーコード
【００６１】
【表１】
表２‐Ｅｒｉｃｓｓｏｎ（ＴＭ）シンタックスエラーコード
【００６２】
【表２】
表３‐Ｅｒｉｃｓｓｏｎ（ＴＭ）認証エラーコード
【００６３】
【表３】
表４‐Ｅｒｉｃｓｓｏｎ（ＴＭ）オーソリティエラーコード
【００６４】
【表４】
表５‐Ｅｒｉｃｓｓｏｎ（ＴＭ）ポジショニングエラーコード
【００６５】
【表５】
表６‐Ｅｒｉｃｓｓｏｎ（ＴＭ）ネットワークエラーコード
【００６６】
【表６】
表７‐Ｅｒｉｃｓｓｏｎ（ＴＭ）ＭＰＳ１．１エラーコード
【００６７】
【表７】
（アダプタシステムフロー）
図５は、本発明の１つ以上の実施形態によるモバイルデバイスロケータアダプタシステム２００でＡＰＩを用いることを示すフローチャートである。図２および図５の両方を参照すると、モバイルデバイスロケータアダプタシステム２００では、コンピュータシステム２００の新規のバージョンを展開（ｄｅｐｌｏｙ）することなく、アプリケーション２００（すなわち、デバイスロケータ）は、コンピュータシステム２００内で動的に展開され得る。
【００６８】
一度アプリケーションプログラム２１０が展開されると、アプリケーションプログラム２１０のＡＰＩ２２２の単純化プロシージャがステップ５００で呼び出され得る。単純化プロシージャは、ステップ５０２において、（例えば、モバイルデバイス２０４の同定を用いて）モバイルデバイス２０４のロケーションを得る。ロケーションを得るために、呼び出されたプロシージャは、ステップ５０４でキャリアアダプタ２２４と相互作用する。キャリアアダプタ２２４が特定のキャリア２０６に対してカスタマイズされるため、特定の情報および方法が利用され得る。例えば、呼び出されたプロシージャは、キャリア２２６のモバイルポジショニングサーバの詳細、およびキャリア２２６によって必要とされるデバイス２０４を識別する異なる方法と相互作用し得る。さらに、呼び出されたプロシージャは、ステップ５０６において、デバイス２０４のロケーションに関連する空間参照システム（ｓｐａｔｉａｌ ｒｅｆｅｒｅｎｃｅ ｓｙｓｔｅｍ）を得てもよい。
【００６９】
ステップ５０２で得られたモバイルデバイス２０４のロケーションは、セルラーホン番号、ＭＳＩＳＮＤ、リクエストヘッダまたは予め格納されたデフォルトでエンコードされたインターネットプロトコルアドレスを含んでもよい。さらに上述されるように、ステップ５０４で１つ以上のキャリアアダプタ２２４と相互作用することによって、呼び出されたプロシージャは、キャリア２２６によって提供された異なるプロトコルと相互作用する。
【００７０】
一度、ステップ５０６でロケーションが得られると、そのロケーションは、ステップ５０８でさらにリファイン（ｒｅｆｉｎｅ）され得る。ロケーションをリファインするために、１つ以上のヒューリスティックスが適用され得る。例えば、そのロケーションは、ストリートネットワークの最も近い点、近傍の該当点または目印、（ユーザの「履歴」を調査することによる）モバイルデバイスユーザが最近訪ねたロケーションの近傍のロケーション、または、モバイルデバイスユーザが「お気に入り」ロケーションとしてブックマークに入れたロケーションの近傍のロケーションにスナップ（ｓｎａｐ）され得る。あるいは、ファジーロジックは、デバイス２０４のロケーションをリファインするために用いられてもよい。
【００７１】
（ロケーションリファインメント）
一度デバイス２０４のロケーションが得られると、本発明の１つ以上の実施形態は、いくつかのヒューリスティックスを適用することによって、および／または、ファジーロジックを適用することによって、近似ロケーションをリファインしてもよい。ユーザまたはアプリケーションは、このようなロケーションリファインメントが起こるときを特定し得る。例えば、ブール「ＲＥＦＩＮＥ」値は、リファインメントが所望である場合、ＴＲＵＥに設定され得る。従って、（上記のように）一度ロケーションが特定されると、ブール値は、さらなるリファインメントが実施されるべきかどうかを決定するように試験され得る。
【００７２】
ユーザは、デバイス２０４のロケーションをリファインする所望の方法論を特定するように許可され得る。このような異なる方法論は、リファインメントプロセスで用いられるルールのセットを構成することによって特定され得る。さらに、このようなルールは、ルール構成ファイルの表に格納され得る。異なる方法論は、ストリートネットワークの最も近い点、目印、またはその近傍の「該当する点」にロケーションをスナップすることを含み得る。あるいは、アプリケーションは、モバイルデバイスユーザが最近訪ねた近似ロケーションの近傍のロケーションを探し（すなわち、ユーザプロフィールの「履歴」を調査する）、ロケーションを特定のロケーション（例えば、最後に訪ねた最も近いロケーション）にスナップし得る。さらに、アプリケーションは、モバイルデバイスユーザによってブックマークに入れられた「お気に入り」ロケーションを調査して、いずれかのこのような「お気に入り」位置が近似デバイスロケーションの近傍にあるかどうかを判定し得る。その後、近似位置が最も近い「お気に入り」ロケーションにスナップし得る。さらに、ファジーロジックは、以下に詳細に説明されるように位置をリファインするように用いられ得る。
【００７３】
例えば、ロケーションリファインメントへの単純な解決方法では、正確なポリゴン形状の図心が、
ｘ＝ＤｏｕｂｌｅＩｎｔｅｇｒａｌ（ｘ ｄｘ ｄｙ）／ＤｏｕｂｌｅＩｎｔｅｇｒａｌ（ｄｘ ｄｙ）、および
ｙ＝ＤｏｕｂｌｅＩｎｔｅｇｒａｌ（ｙ ｄｘ ｄｙ）／ＤｏｕｂｌｅＩｎｔｅｇｒａｌ（ｄｘ ｄｙ）
によって規定される。
図心のこのような定義を用いることによって、精密なポリゴン（例えば、１０２）の些細なリファインメントが提供される。しかし、図心は、実際にロケーションをリファインしない。それにもかかわらず、このような図心は、精密なポリゴン１０２内の真の（ｔｒｕｅ）ロケーションの均一分配の最良の平均エラーを提供し得る。
【００７４】
ロケーションリファインメントの別の例では、ユーザプロファイルおよび局地的なコンテンツがリファインメントに影響を与えるために用いられる。このようなリファインメントでは、無線キャリア２２６、プロファイルデータベース２２８〜２３０、無線ポータル（例えば、アダプタ２２４）およびローカルユーザプロファイルデータベース（例えば、ＬＢＳデータベース２３２）は、共に、非常に特別なプロファイル情報へのアクセスを有する。このようなアクセスは、Ｎｅｍｍａｒａ Ｃｈｉｔｈａｍｂａｒａｍらによる、「ＬＯＣＡＴＩＯＮ ＢＡＳＥＤ ＳＥＲＶＩＣＥＳ ＢＲＩＤＧＥ ＴＯ ＥＸＴＥＲＮＡＬ ＤＡＴＡ ＳＯＵＲＣＥＳ」と称され、同時係属中で、同一人に譲渡され、２００１年１２月２６日に出願された米国特許出願第１０／０３４，４４０号（アトーニードケットＮｏ．Ｇ＆Ｃ ３０５６６．２０４−ＵＳ−０１）に記載されており、提供され得る。
【００７５】
この情報は、ＬＢＳサービスまたはＬＢＳアプリケーション２１０をより多く用いることによって、次第に豊かにより、かつより正確になり得る。ＬＢＳアプリケーション２１０をさらに用いることによって得られるデータは、最近訪ねたロケーションの履歴、および／または最近実行したクエリ（例えば、「最も近い博物館を訪ねる」）に基づいて、ユーザの一般的人口統計分類、民族分類、ユーザのロケーションパターン（例えば、家、オフィス、お気に入りロケーション）および／またはユーザの「現在の活動プロファイル」に関連する洞察を提供し得る。
【００７６】
さらなるこのようなプロファイル情報はまた、ユーザがブックマークに入れたお気に入りロケーションの近傍にいるかどうか、または、ユーザがロケーション履歴に最近記録されたロケーションの近傍にいるかどうか等の質問に答えるために用いられ得る。これらの条件のうちの１つが正しいと判明する場合、リファインされたロケーション用の候補としてのお気に入りロケーション、またはユーザプロファイルロケーション履歴のロケーションが容易に提供され得る。
【００７７】
しかし、ＬＢＳサービスは、ユーザが家庭または仕事から離れており、不慣れな地域にいることが多い場合に、より一般的に用いられる。このような場合、近傍の該当する目立ったランドマーク（単数または複数）あるいは点（単数または複数）は、リファインされたロケーション（単数または複数）として提供され得る。さらに、選択された該当するランドマークまたは点のカテゴリーは、ユーザプロファイルおよびロケーションコンテンツデータベース２３２に基づいて、ユーザの「現在の活動のプロファイル」を「聡明に推量する」ことに依存し得る。このような入力は、ロケーション局面（例えば、ユーザのお気に入りルートであるロケーション）、活動プロファイルインジケータ（単数または複数）（例えば、この人はビジネスビジターか？または、最後のファインダークエリが「最も近い博物館を見つける」であった）、および／または一時的な局面（例えば、典型的なビジターアトラクションはこの地域でどれくらい遅れてオープンしたのか？）の組み合わせを含み得る。
【００７８】
さらに、ユーザのお気に入りは、ユーザに対してテーラリングされた、高度にパーソナライズされたサービスを伝達するように推論され得る。例えば、アプリケーションの動作からコンテンツのフィルタリング用のスライライジングまでどんなものでも特定のユーザの対してパーソナライズされ得る。
【００７９】
デバイス２０４の近似ロケーションをリファインするために、ロケーションリファインメントマネージャが利用され得る。このロケーションリファインメントマネージャは、ロケーションリファインメントのための最初の点であり得、ロケーションリファインメントマネージャの方法が１つのリファインされたロケーション（例えば、最良推定）、リファインされた候補ロケーションのソート済みリスト、または、ソースによって分類されたリファインメント候補のいくつかのリスト（例えば、ユーザプロファイルお気に入り、ユーザプロファイル履歴、ビジターランドマーク等）を返し得る。リファインされた位置の各リストは、実行された特定のリファインメントに基づき得る。例えば、あるリストがお気に入りに基づき得て、第２のリストが履歴に基づき得て、第３のリストがランドマークに基づき得る。さらに、各リストは、図心または近似位置からの距離に基づいてソーティングされ得る。
【００８０】
一度リファインされたロケーションのリストが得られると、ユーザは、ＬＢＳアプリケーション２１０と相互作用して、ユーザの正確な位置を計算し得る。この相互作用は、例えば、リファインされたロケーションの１つの承認を含み得、候補リストからの選択を可能にし得る。１つ以上の候補ロケーションを使用することがユーザの真のロケーションを方向付けて、位置を特定可能となる。さらに、このプロセス中に、全てのリストは、１つのリスト内に分割され得る。例えば、各リストの各ロケーションは、図心からの距離によってソーティングされた１つのリストに組み合わせられ得る。さらに、それぞれのリストまたは１つの解決したリストは、特定のポリゴン内のロケーションのみがリターンされるようにフィルタリングされ得る。さらに、個々のリストまたは１つの解決されたリストに基づいて、１つのリファインされたリストがリターンされ得る。従って、ロケーションリファインメントマネージャの実施に基づいて、ユーザは、１つのリファインされたロケーション位置、リファインされたロケーションのリストまたはリファインされたロケーションのリストのリストによって提示され得る。それにもかかわらず、ロケーションリファインメントマネージャによって、デバイス２０４の近似の位置は、ユーザによって選択可能であり得る様々な因子に基づいてリファインされることが可能となる。
【００８１】
（ファジーロジックリファインメント）
本発明の１つ以上の実施形態は、ファジーロジックを用いてデバイスロケーションをリファインする製作者の方法、装置および商品を提供する。このファジーロジックリファインメントプロセスは、ロケーションリファインメントマネージャによって初期化され得る。
【００８２】
ファジーロジックを利用して、デバイスの位置をリファインするために、多くの理由が存在する。最大限の利益を提供するために、いくつかの質問および情報が必要であり得る。例えば、必要な情報は、現在の活動プロファイルがコンピュータプロファイル、ビジネスビジタープロファイル、レジャービジタープロファイル、これらのプロファイルのうちの１つ以上とマッチするか、これらのプロファイルと全くマッチしないかどうかを含んでもよい。しかし、このような質問に答えるとともに、多くの問題が生じ得る。例えば、この問題の定義があいまいであってもよい。言い換えると、この問題は、正確な定量的な定義には適切ではないかもしれない（例えば、〜の近傍、〜の近く、〜から離れた、おそらく、等の非定量的な用語が頻繁に用いられてもよい）。さらに、リファインされたロケーションに対するランドマークの特定のカテゴリーがいつ用いられるべきか（主体的問題）を決定することは困難であり得る。さらに、境界がぼやけていてもよい。例えば、「現在の活動はレジャービジターのプロファイルにマッチしているか？」という質問に対する答えは、「たぶん」または「不確か」対「はい／いいえ」であり得る。さらに、入力が不正確でも、衝突していても、および／またはオーバーラップしていてもよい。例えば、現在の活動プロファイルは、レジャー中の夕方を過ごしているビジネスビジターを表す。
【００８３】
これらの問題は、入力に固有のあいまいなこと、不正確なこと、およびぼやけた境界を取り扱うシステムを要求する。さらに、システムは、このような不正確かつ衝突している情報がいかに捕えられて、処理されるか、（使用法および展開が上昇した）問題の理解が深まったという連続的な沈思を可能にするか、そして、決定的な結論を提供するかどうかを定式化するべきである。
【００８４】
本発明の１つ以上の実施形態は、このような問題を解決するファジーロジックと呼ばれる人工知能（ＡＩ）の分野を利用する。ファジーロジックは、部分的に真（「完全に真」と「完全に偽」との間の真の値である）という概念を取り扱うために拡張された従来の（ブール）ロジックの上位集合である。
【００８５】
ファジーロジックでは、連続的な真値は、システム変数が、厳密なバイナリ（真および偽）決定および割り当てではなく、区間［０，１］における真値のメンバーシップの連続的な範囲を取り得るように認められる。例えば、曇り（ｃｌｏｕｄｙ）および曇っている（ｏｖｅｒｃａｓｔ）場合、その記述「雨が降っている」は、０．８の真値であろうし、偽値は０．２５でもあろう。同様に、記述「現在のユーザはビジターである」は、非常に確からしい場合０．９の値を有し、あまり確からしくない場合０．１の値を有し、その答えが「たぶん（ｍａｙ ｂｅ）」である場合０．５の値を有する。
【００８６】
ファジーロジックを用いると、ロケーションリファインメント問題が再定義され得る。このような問題の再定義が図６に示され得る。この図６は、再定義されたロケーションを重み付き入力のファジー図心として示す。図６では、ロケーション精度ポリゴン１０２は、近似のデバイス２０４ロケーションとして与えられる幾何学的な図心１００を含む。リファインされた位置１０４は、様々な異なる可能性６０２〜６１４から選択されてもよい。しかし、様々な異なる可能性６０２〜６１４は、リファインされたロケーションをファジー図心１０４として決定するために重み付けされて組み合わされ得る。
【００８７】
様々なファジーメンバーシップセット６０２〜６１４は、ロケーションをリファインするために、用いられて重み付けされ得る。異なるタイプのファジーメンバーシップセット６０２〜６１４は、重み付け計算に利用され得る。例えば、ファジーメンバーシップセット６０２〜６１４は、ユーザプロファイルロケーションの様々なカテゴリー（例えば、最も近いユーザプロファイルお気に入り６０２、ユーザプロファイル履歴６０４等）に対する近似として利用され得る。さらに、ファジーメンバーシップセット６０２〜６１４は、現在の活動（例えば、ビジネスビジタープロファイル、通勤者プロファイル、レジャービジタープロファイル等）、拡大解釈すると、異なる種類のランドマーク（例えば、最も近いロギングランドマーク６０６、最も近いビジターランドマーク６０８、最も近いビジネスランドマーク６１０、最も近いストリートインターセクション６１２、最も近い通勤者ランドマーク６１４等）に対する重み付け近似を記述し得る。
【００８８】
ファジーメンバーシップセットに基づくと、リファインされたロケーションは、これらの重み付け入力のファジー図心１０４として推論され得る。
【００８９】
本発明のファジーロジック推論は、任意の数の正確または不正確な入力（単数または複数）センサが可能であるように、様々な数の不正確な入力を可能にする。例えば、以下の一つ以上のものがデバイスロケーションをリファインするために入力センサとして用いられ得る：お気に入り、ビジネスビジタープロファイルインジケータ、レジャープロファイルインジケータ等の近似。
【００９０】
本発明のファジーロジック推論は、
ＩＦ Ｘ ａｎｄ Ｙ ｔｈｅｎ Ｚ
の形式の入力／出力関係を定義する（直感的な）ルールセットを定義するルールベースを含む。例えば、以下のルールのうちの１つ以上は、本発明のルールベース内に定義され得る。Ｉｆ（ローカルお気に入りロケーションに近い）ｔｈｅｎ ＣｌｏｓｅｓｔＦａｖｏｒｉｔｅ、または、Ｉｆ（お気に入りから遠い）ａｎｄ（現在の活動がビジターランドマークにマッチする）ｔｈｅｎ ＣｌｏｓｅｓｔＶｉｓｉｔｏｒＬａｎｄｍａｒｋ。
【００９１】
メンバーシップ関数は、ロケーションを決定する際に各入力の関与の程度を定義する。例えば、メンバーシップ関数は、現在の活動プロファイルがレジャービジタープロファイルにマッチするかどうかという疑問を評価し得る。「最も確からしい（ｍｏｓｔ ｌｉｋｅｌｙ）」という答えは、「そうかもしれない（ｃｏｕｌｄ ｂｅ）」という答えに対して、より高度なメンバーシップ関数、およびロケーション決定により良好に関与しているという結果となる。
【００９２】
最後に、本発明のファジーロジック推論は、これらのルールの各々の論理積を計算する推定エンジンを含む。例えば、推定エンジンは、
Ｘ ＡＮＤ Ｙ ＝ ＭＩＮ（Ｘ，Ｙ）
Ｙ ＯＲ Ｙ ＝ ＭＡＸ（Ｘ，Ｙ）
のように論理積を決定し得る。
この論理積は、その後、最終的な答えを生むために組み合わせられる。
【００９３】
図７は、本発明の１つ以上の実施形態によるファジーロジック推論プロセスの概観である。図示されるように、ファジー入力７０２（すなわち、様々な数の不正確な入力）は、各入力７０２の関与の程度を定義する一つ以上のメンバーシップ関数７０４によって処理される。その後、（一つ以上のルールを含む）ルールベース７０６は、推定エンジン７０８によって処理される。この推定エンジン７０８では、一つ以上のルールに対する論理積が計算される。この論理積は、各ルールに対して真のレベル（すなわち、区間［０，１］の値）を提供する。その後、推定エンジンは、一つ以上の異なる方法を用いてリファインされたロケーションを選択する。例えば、最大論理積または二乗平均平方根値７１０が適切な最終出力７１２（すなわち、リファインされたロケーション）を決定するために利用され得る。従って、ファジー入力７０２は、（メンバーシップ関数７０４によって処理される場合）クリスプ（ｃｒｉｓｐ）形式からファジー形式へと移行する。ここでは、それらは、推定エンジン７０８によって処理される。この推定エンジン７０８は、論理積を識別して、適切な論理積および出力７１２に対する対応するリファインされたロケーションを選択する所望の方法論７１０を用いることによって、クリスプ形式に逆に処理される。
【００９４】
３つのタイプの入力センサ（ファジー入力７０２）が利用され得る：ロケーションまたは近似ベース、時間ベースおよび活動プロファイルベース。ロケーションまたは近似ベース入力７０２は、特定のロケーションへの近似を決定する。例えば、ロケーションベース入力７０２は、（例えば、自宅、オフィス、健康クラブ等に近似の）お気に入り、および（例えば、ユーザプロファイル履歴の最近訪ねたロケーションに近似の）履歴を含み得る。
【００９５】
活動プロファイルベース入力７０２は、現在のユーザの活動が特別に確立されたプロファイルにマッチする、類似するかどうかを判定するために評価される。例えば、確立されたプロファイルは、ビジネスビジタープロファイル（例えば、現在の活動がビジネスビジターのプロファイルにマッチしているか？）、レジャービジター活動プロファイル（例えば、現在の活動がレジャービジターのプロファイルにマッチしているか？）、および通勤者活動プロファイル（例えば、現在の活動が通勤者のプロファイルにマッチしているか？）を含み得る。
【００９６】
一時入力７０２は、現在の時間が特別な一時領域またはプロファイル内にあるかどうかに基づいている。例えば、ビジネス稼働時間の一時入力７０２を運転しているビジネスは、現在の時間がビジネス稼動時間内であるかどうかを判定し得る。あるいは、レジャー稼動時間一時入力７０２は、現在の時間がレジャー稼動時間内であるかどうかを判定する。
【００９７】
（方向または行程を示す）速度ベクトル等の他のシナリオ−一時入力７０２が入力７０２として加えられ得る／利用され得る。
【００９８】
その後、ファジーロジックは、入力７０２を処理して、出力７１２を作る。この出力７１２は、一つの値を含んでもよいし、（複数の候補が必要である場合）値のセットを含んでもよい。出力は、最も近いお気に入りロケーション６０２、最も近い履歴６０４、最も近いレジャーランドマーク６０８、最も近いビジネスランドマーク６１０、最も近いロギングランドマーク６０６（例えば、ホテル）、最も近い通勤者ランドマーク６１４、最も近い交差点６１２等を含んでもよい。
【００９９】
メンバーシップ関数７０４は、各入力の関与の程度を定義するために利用される。言い換えると、メンバーシップ関数７０４は、入力７０２の評価を作成して、インターフェースエンジン７０８にどれくらい入力７０２が用いられるかを決定する。
【０１００】
３つの値のセットは、各入力／メンバーシップ関数７０４として用いられ得る。真値に対してはＰすなわちポジティブ（＋）、偽値に対してはＮすなわちネガティブ（−）およびいずれかの方向にも向かうことができるか、不確かさを反映することができる値に対してはＺすなわちゼロ（０）である。各セットは、近いセット／区間［０，１］から値を取ることができる。
【０１０１】
例えば、入力関数ＬｅｉｓｕｒｅＶｉｓｉｔｏｒＡｃｔｉｖｉｔｙＰｒｏｆｉｌｅは、以下のようにファジー化されることが可能である。
【０１０２】
最も確からしい（Ｍｏｓｔ Ｌｉｋｅｌｙ）レジャービジター→Ｐ＝０．８
あまり確からしくない（Ｕｎｌｉｋｅｌｙ）レジャービジター→Ｎ＝０．８
そうであるかもしれないし、そうではないかもしれない（Ｍａｙ ｏｒ ｍａｙ ｎｏｔ ｂｅ）（不確かである）→Ｚ＝０．８
同様に、Ｐ，ＮおよびＺ値は、全ての他の入力７０２に対して定義され得る（例えば、近い＝Ｐ，遠い＝Ｎ，不確か＝Ｚ）。表１は、入力７０２の関与に対する異なる値を格納するために用いられ得る入力メンバーシップ表の例である。
【０１０３】
【表８】
メンバーシップ関数７０４は、Ｐ，ＮおよびＺに対する適切な値で埋める。メンバーシップ関数７０４を通して入力７０２を処理することに続いて、入力７０２は、メンバーシップ関数７０４によって提供される関与（すなわち、Ｐ，ＮおよびＺ値）の程度に従って、ルールベース７０６に対して推定エンジン７０８によって処理される。このルールベース７０６が単に推定エンジン７０８によって適用されるため、ルールベース７０６は、より多くの経験的データが集められるにつれて、進歩的にリファインされ得る。さらに、デフォルトルールが特定され得る。このデフォルトルールは、推定エンジン７０８が、衝突しているルールまたは入力７０２が原因により結果を作り出すことができない場合／ときに用いられる。従って、ルールベース７０６がフェイルセーフである。あまりにも多くの衝突する入力７０２のために、このファジー推論が結果を出すことができない場合、このデフォルトルールが適用される（例えば、デフォルトルールがこのように提供する場合、最も近い交差点を答える）。
【０１０４】
さらに、変化するルールおよび入力７０２に基づいて作られる出力７１２で実験すると、ルールのインクルージョン（ｉｎｃｌｕｓｉｏｎ）およびエクスクルージョン（ｅｘｃｌｕｓｉｏｎ）は、実験に影響され得る。このような実験に対して、ルールが論理積を用いること、および、非ゼロの論理積のみが最終的な推定に寄与することを提供する。例えば、メンバーシップ関数７０４がゼロであるＰ，ＮおよびＺ値を提供する場合、入力７０２は、大きさを有せず、ルールに参加することができない。さらに、論理演算が実行されるため、ゼロ値が用いられる場合、ルールにおける積の結果は、また、ゼロである（これにより、不適切な出力７１２を作る）。従って、関数７０４のＰ，ＮおよびＺ値に対して０．０の値を初期設定することによって、論理積ルールの結果として寄与することから、ルールが排除される（０．０であるために、Ｘ＝０．０である）。
【０１０５】
従って、ルールの数、ルールの複雑さ、および推定エンジン７０８が（例えば、世界の異なる部分に対して適応して、あるいは、より豊かなユーザプロファイルデータベースに対して）構成され得る。表２は、ルール番号、先行詞（ａｎｔｅｃｅｄｅｎｔ）、およびルールベース７０６に対する結果を含むルールベース７０６の表を示す。
【０１０６】
【表９】
テーブル２は、どのようにして、入力メンバーシップテーブル（すなわち、テーブル１）中の値が規則のセット中で利用されるかを示す。例えば、規則３では、４つの条件が入力７０２に基づいて処理され、最も近いビジネスランドマークを生成する。４つの規則は、論理ＡＮＤ演算を使用して、前件の規則を評価する。お気に入りへの接近度がＮまたはＺ、履歴への接近度がＮまたはＺ、ビジネス旅行者プロファイルがＰ、およびビジネス活動時間がＰである場合、規則３では、最も近いビジネスランドマークが、後件である（すなわち、出力６１２）。さらなる規則の各々は、それが組み合わされた場合、特定の後件を生成する１セットの前件／状態を有する。
【０１０７】
一旦、規則ベース７０６が確立された（例えば、規則ベーステーブルに置かれた）場合、推論エンジン７０８は、ファジー重心１０４を計算するために使用される。推論エンジン７０８を使用する場合、各規則（例えば、テーブル２の規則１〜８）の論理演算結果が処理される。この処理は、各規則に対して０〜１の値を生成する。論理演算結果を処理する場合、前件の「ＸおよびＹおよびＺ」は、Ｘ、Ｙ、およびＺの内の最小物（すなわち、ＭＩＮ（Ｘ，Ｙ，Ｚ））と等価である。同様に、前件の「ＸまたはＹまたはＺ」は、Ｘ、Ｙ、およびＺの内の最大物（すなわち、ＭＡＸ（Ｘ，Ｙ，Ｚ））と等価である。各規則に対する論理演算結果（間隔[０，１]の値を有する）は、その規則の参加の度合いを示す（０は参加がないことを示す）。この推論は、そのＭＡＸを選択し、平均するかまたは２乗平均平方根７１０を使用することを含む非ゼロの度合いの規則の重みつき重心１０４を計算する異なるメソッドを使用し得る。
【０１０８】
１つ以上の実施形態では、最も大きい論理演算結果を有する規則が選択されるように、ＭＡＸ規則が常に利用される。例えば、（テーブル２の）規則５がもっとも大きい論理演算結果、例えば、０．９を生み出す場合、修正された位置は、Ｃｌｏｓｅｓｔ Ｌｏｄｇｉｎｇ Ｌａｎｄｍａｒｋである。
【０１０９】
さらに、規則を適用する際、複数の候補または複数のリストが必要とされる場合、最大２または３の論理演算結果からの第１のｎ個の要素が選択される。例えば、（テーブル２の）規則５および７が最大値を生み出す場合、Ｃｌｏｓｅｓｔ Ｌｏｄｇｉｎｇ ＬａｎｄｍａｒｋおよびＣｌｏｓｅｓｔ Ｃｏｍｍｕｔｅｒ Ｌａｎｄｍａｒｋを表す２つのリストが修正候補として提供され得る。
【０１１０】
（ファジー論理修正の例示的なアプリケーション）
（例１（簡単な例））
簡単な例では、ユーザは、任意のお気に入りのロケーションに非常に近いところに居ないかもしれないが、ユーザのプロファイル履歴におけるロケーションに非常に近い。このような例では、入力メンバーシップテーブルは、テーブル３に示されるような値を有する。
【０１１１】
【表１０】
この例では、テーブル４に示されたように、規則テーブルの中で非ゼロ論理演算結果を生み出す規則は規則１および２のみである。
【０１１２】
【表１１】
Ｍａｘ規則を用いると（すなわち、最大論理演算結果を有する規則を取る）、規則２が優勢になり、修正されたロケーションに対する出力７１２は最も近い履歴である（例えば、ユーザの履歴の内、最新のロケーション）。最も近い履歴が予測される答えである。
【０１１３】
（例２）
この例では、ユーザはお気に入りから遠く離れており、履歴から遠く離れており、現在の活動プロファイルは、ユーザがビジネス旅行者プロファイルに整合することを示し、現在の活動プロファイルは、ユーザがまた、レジャー旅行者プロファイルに整合し得ることを示し、時刻は、平日の午後８時である。
【０１１４】
メンバーシップ関数７０４でのこれらの値の処理は、テーブル５の入力メンバーシップ関数に対する値を生じ得る。
【０１１５】
【表１２】
これらのメンバーシップ値に対する非ゼロの度合いの規則およびその論理演算結果は、以下のテーブル６に示される。
【０１１６】
【表１３】
最大の論理演算結果は、規則５および４に対するものである。従って、この例についての修正に対する候補は、ＣｌｏｓｅｓｔＬｏｄｇｉｎｇＬａｎｄｍａｒｋおよびＣｌｏｓｅｓｔＬｅｉｓｕｒｅＬａｎｄｍａｒｋを含む。
【０１１７】
（利点および利益）
デバイス２０４のロケーションを修正するためのファジー論理推理の使用は、ロケーションおよび修正に対する入力、ならびにその修正を計算するために使用される規則の両方に関連した多くの不確実性を処理する。さらに、ファジー論理推理は、不正確／あいまいさ／重複／競合する入力（ファジー）を表す正式な構成論理を提供する。また、ファジー論理推理は、（ユーザの相互作用の最小化を望むアプリケーションのために）最良の推理および数個の優性度の高い候補を提供する。
【０１１８】
さらに、本明細書中で説明されたように、ファジー論理推理モデルが適応できる。言い換えれば、このモデルは、推論の複雑性の制御を可能にする。例えば、規則３〜７の推論を拒否することは、（お気に入りへの近接度、ロケーションの履歴、およびデフォルトのＣｌｏｓｓｔＳｔｒｅｅｔＩｎｔｅｒｓｅｃｔｉｏｎのみを使用する）簡単なモデルを提供する。一方で、規則は、地域情報等のさらなる情報を提供するように容易に微調整され得る。
【０１１９】
規則ベース７０６、および推論エンジン７０８は、同調して実行され得る（最も簡単に開始する）。さらにその処理は、入力がキャリアプロファイルデータベース２２８〜２３０から取り出されることを可能にし、ロケーション情報がユーザの嗜好を推論しアプリケーションの挙動、コンテンツのフィルタリング等に影響を与えることを可能にする。キャリアプロファイルデータベース２２８〜２３０の使用は、ユーザのプロファイルおよびロケーションに合わせられた、高度に個人化されたアプリケーションの提供を支援する。さらに、キャリアによって収集されるプロファイル情報の価値は、アプリケーション挙動の個人化にそれを使用することによって増大する。
【０１２０】
（ファジー論理推理フロー）
図８は、本発明の１つ以上の実施形態による、デバイス２０４のロケーションを修正するためのファジー論理推理の使用を示すフローチャートである。ステップ８００では、デバイス２０４のおよそのロケーションが決定される。ステップ８０２では、秩序化された規則の集合を含む規則ベース７０６がメモリに読み出されるかまたは（例えば、データベース２３２の）データベースからロードされる。規則ベース７０６は、経時的に収集される経験的なデータに基づいて漸進的に修正され得る。さらに、規則ベース７０６は、推論が結果を生成しない場合に使用するデフォルト規則を特定し得る。さらに、規則ベース７０６は、それが地域動向、社会動向、または人口統計動向を反映するように構成され得るように、適応可能であり得る。このような適応可能性は、ユーザによって制御可能であり得、ユーザは、推理をカスタマイズ／個人化するために、規則ベースを追加、削除、および編集し得る。
【０１２１】
規則ベース７０６内にある規則は、１つ以上の条件を有する前件、およびその結果としての後件によって定義される。さらに、その前件は、論理演算結果を利用してもよいし、それを処理してもよい。
【０１２２】
ステップ８０４では、種々の不正確な入力／入力センサが捕捉される。上述のように、典型的には、３つのタイプの入力センサが使用される。すなわち、地域的、活動プロファイルベース、および時間ベースのタイプである。さらに、空間−時間的な入力が使用され得る。
【０１２３】
ステップ８０６では、その入力は、１つ以上のメンバーシップ関数で処理される。メンバーシップ関数は、規則内の各入力の参加の度合いを定義する。ファジー論理推理に従って、その参加の度合いは、０〜１（[０，１]）の間隔内に存在し得る。メンバーシップ関数は、各入力に対して３つの値のセットを定義し得る。このような３つの値のセットは、真の値、偽の値、および不確定な値（それらの値は、間隔[０，１]に沿って定義される）を含み得る。
【０１２４】
ステップ８０８では、各規則に対して論理演算結果を生成するために、参加の度合いに基づいて、規則が入力に適用される。本発明のファジー論理推理を用いて、論理演算結果は、その後件の適用の可能性を表す、０〜１の真の値を含み得る。その後件は、修正されたロケーション（例えば、最も近いレジャーランドマーク、最も近い宿泊ランドマーク等）を特定／説明する。従って、前件は、種々の入力の値を利用して（メンバーシップ関数によって処理されるように）、後件の真を表す論理演算結果を生成する。
【０１２５】
ステップ８１０では、修正されたロケーションがその論理演算結果に基づいて計算される。言い換えれば、種々の真の値／論理演算結果がステップ８０８において特定されたので、実際の修正されたロケーション（重み付き重心１０４とも呼ばれる）としてどの後件を利用するかに関する決定がなされる。上述のように、論理演算結果に基づいて修正されたロケーションを計算する異なるメソッドが使用され得る。例えば、最大論理演算結果が選択され得、次いで、その修正されたロケーションを決定するために、それに対応する後件が選択／使用され得る。あるいは、平均（例えば、２乗平均平方根計算）がそのロケーションを修正するために使用され得る。例えば、論理演算結果が平均化され得、かつその平均に最も近い論理演算結果を有する後件が、修正されたロケーションとして選択され得る。あるいは、多くの異なる候補ロケーションが使用され得、これらのロケーションの全ての間にあるロケーションが提供され得る。しかし、修正されたロケーション（または修正されたロケーションのリスト）を選択するために、任意の利用可能なメソッドが使用され得る。さらに、返される修正されたロケーションは、単一のもの（すなわち、単一の修正されたロケーション）を含んでもよいし、ユーザが選択し得る候補ロケーションのリストを含んでもよい。
【０１２６】
（外部データソースへの位置ベースサービスブリッジ）
上述のように、ＬＢＳアプリケーション２１０は、ユーザのプロファイル情報に基づいて特定のユーザに対して高度にカスタマイズされ得る。ユーザプロファイル情報は、リレーショナルデータベース、ポータル等において、ユーザごとに維持される任意のデータである。このようなユーザプロファイル情報が、ローカルに（例えば、ＬＢＳデータベース２３２において）または外部に（例えば、外部データソース２２８〜２３０において）格納され得る。従来技術では、外部プロファイル情報は、しばしば、ＬＢＳアプリケーション２１０のＬＢＳデータベース２３２にリロードされ、それにより、コストの増大、同期化問題、データフォーマットの不一致、および問題のある非ＬＢＳ認識データが生じる。例えば、ユーザプロファイル情報の多大な量がキャリアの外部データベース２２８〜２３０に格納され得る。従来技術では、このようなプロファイル情報を利用するために、全ての情報がＬＢＳサービスプロバイダのローカルデータベース２３２にコピーされる。しかし、キャリア２２６は、種々の理由のためにこのようなコピーを許容し得ない。
【０１２７】
このような問題を克服するために、本発明の１つ以上の実施形態は、外部プロファイルデータベース２２８〜２３０へのコンパクトＬＢＳブリッジを利用する。このＬＢＳブリッジは、データが外部データベース２２８〜２３０に残っていることを可能にするが、依然として、同じ、位置ベースサービスを提供し、そのデータを利用する。さらに、データがローカル／内部、または外部にあるのかは、なお、ユーザに対して透明であり、アプリケーション（例えばロケーションサービス）に対してシームレスである。
【０１２８】
ＬＢＳブリッジは、（属性、タイプ、および制限の名前を含む）外部データベース２２８〜２３０のスキーマ２３４（データリンクテーブルとも呼ばれる）のコンパクトな定義を提供する。このスキーマ内部では、データソース情報（例えば、どのようにして外部データベース２２８〜２３０に接続し、それらと通信するのか）、およびスキーマ２３４の記述に対応するデータソースから関連するプロパティを抽出するＳＱＬ（ｓｔｒｕｃｔｕｒｅｄ ｑｕｅｒｙ ｌａｎｇｕａｇｅ）選択ステートメントが提供される。さらに、ＳＱＬステートメントは、外部データベース２２８〜２３０の、固有識別レコードのためのキーを識別する外部（ｆｏｒｅｉｇｎ）キーカラム名前に関する情報を含む。
【０１２９】
位置ベースのサービスを提供するために使用されるさらなる情報は、ユーザプロファイルプロパティテーブル（ＵＰＰＴ）（データブリッジテーブルとも呼ばれる）の形式でＬＢＳデータベース２３２に格納され得る。ＵＰＰＴテーブルは、ローカルに格納される既存のユーザプロファイル情報であってもよいし、外部データソース２２８〜２３０にアクセスするために特別に作成されてもよい。通常、ＵＰＰＴは、ローカルデータストア２３２から外部に格納される、空間的に認識しているユーザプロファイルアイテムに関する情報を維持する。外部データソース２２８〜２３０の各レコードは、ＬＢＳデータベース２３２の（ＵＰＰＴの）レコードのための外部キーを格納することによって識別される。さらに、各外部レコードに対する位置情報が獲得／抽出され、ジオコーディング／空間インデックスとしてＵＰＰＴ内に格納される（それにより、外部データベース２２８〜２３０ＬＢＳをイネーブルにする）。さらに、必要ならば、非座標位置情報（例えば、テキストの道路アドレス、ランドマーク等）が、ジオコーディング／空間インデックスを作成するためにジオコーディングされ、ＵＰＰＴに格納される。従って、あるリンク／関係が、ローカルＵＰＰＴレコードと外部データベース２２８〜２３０に格納されるレコード／アイテムとの間で確立される。このＵＰＰＴは、外部データソース２２８〜２３０の各レコード、または外部データソース２２８〜２３０のレコードのサブセットに対するレコードを含んでもよい。
【０１３０】
これらのサービスの集合は、システムインテグレータのために、外部ＡＰＩ２２２の形式で利用可能にされる。このような外部ＡＰＩ２２２はまた、ユーザプロファイルルマネージャと呼ばれ得る。一般的なＬＢＳブリッジの結果として、ＬＢＳアプリケーション２１０は、無線キャリア２３０、電話会社２２８等によって蓄積される大量のプロファイル情報に拡張され得る。この拡張は、ＬＢＳサービスをより個人化し、エンドユーザにとってより価値があるものにする。
【０１３１】
図９は、本発明の１つ以上の実施形態による、外部データベース２２８〜２３０のためのスキーマ２３４の構造を示す。上述のように、スキーマ定義２３４は、外部データソース２２８〜２３０に関する情報を維持する。ＬＢＳアプリケーション２１０によって格納される各スキーマ２３４の定義は、外部データベース２２８〜２３０の各オブジェクトについての記述を提供する。言い換えると、外部データベース２２８〜２３０の各オブジェクトのために、対応するスキーマ２３４が存在する。例えば、外部データベース２２８〜２３０のアドレスオブジェクトは、対応するスキーマ定義２３４を有する。さらに、オブジェクトの中の各フィールド／属性のために、対応する属性定義９０２がスキーマ２３４と共に格納される。例えば、アドレスオブジェクトは、名前、数、道路名、都市、州、およびジップ（ｚｉｐ）等の複数のフィールド／属性を有する。各フィールド／属性に対して、スキーマ属性定義９０２がスキーマ２３４と共に格納される。
【０１３２】
スキーマ２３４の中のデータベース９０４のタイプ（すなわち、ｉｔｅｍＴｙｐｅ：Ｓｔｒｉｎｇ；例えば、Ａｄｄｒｅｓｓ）は、外部データベース２２８〜２３０のオブジェクトに対するタイプまたは名前を提供する。データソース情報９０６（すなわち、ｊｄｂｃＤａｔａＳｏｕｒｃｅ：Ｓｔｒｉｎｇ）は、どのようにして、外部データベース２２８〜２３０に接続し、それと通信するかに関する情報を提供する。このような情報は、データベース２２８〜２３０、そのロウ（ｒｏｗ）、およびそのカラム（ｃｏｌｕｍｎ）を含むデータが存在するロケーションを完全に定義し得る。例えば、どのキャリア２２６が特定のデータベース２２８〜２３０をホストしているのか、およびどのようにしてデータベース２２８〜２３０と通信するのかに関する情報が格納される。
【０１３３】
上述のように、属性のリスト９０８がスキーマ２３４において説明される。各属性に対して、属性定義９０２は、属性の名前、属性のタイプ、および属性の制限を提供する。従って、各スキーマ２３４に対して、単一のリスト９０８は、複数の属性定義９０２にマッピングする。
【０１３４】
ＳＱＬ選択ステートメント９１０（例えば、「ＷＨＥＲＥ」節）は、データソース２２８〜２３０から関連するプロパティ（例えば、ロウまたはレコード）を抽出するためのコマンドを提供する。従って、スキーマ２３４は、外部データベース２２８〜２３０のオブジェクトに対する全ての定義情報を含む。
【０１３５】
上述のように、ＡＰＩ２２２（ユーザプロファイルマネージャ１０００とも呼ばれる）は、スキーマ２３４の情報、およびスキーマ属性定義９０２の情報を維持するため、ならびに外部データベース２２８〜２３０から詳細な情報（すなわち、ユーザプロファイル情報）にアクセス／取り出すために利用され得る。さらに、ＡＰＩは、ＵＰＰＴから特定のエントリを追加または削除する等、ＵＰＰＴを保持するために利用され得る。さらに、ＵＰＰＴを保持する場合であっても、データがローカルデータソースから来るのか、または外部データソース２２８〜２３０から来るのかは、ユーザにとってなお透明なままである。
【０１３６】
図１０は、本発明の１つ以上の実施形態による、ユーザプロファイルマネージャを示す。外部データベース２２８〜２３０がアクセスされ得るようにスキーマ定義２３４をシステム２００に追加するために、ユーザプロファイルマネージャ１０００のｉｎｓｅｒｔＳｃｈｅｍａメソッド１００２が利用され得る。アプリケーションプロバイダまたはキャリア２２６は、この目的のためにｉｎｓｅｒｔＳｃｈｅｍａメソッド１００２を利用し得る。スキーマを追加するために、スキーマのためのスキーマ定義およびタイプ情報がユーザプロファイルマネージャ１０００に提供される。一旦、スキーマ定義２３４がシステム２００に追加された場合、スキーマ２３４の名前およびスキーマ情報が、外部アイテムタイプのスキーマ定義と呼ばれるスキーマ２３４のリストに追加される。
【０１３７】
表７は、本発明の１つ以上の実施形態による、（すなわち、ｉｎｓｅｒｔＳｃｈｅｍａメソッド１００２を用いて）システム２００に追加されたスキーマ２３４に関する情報を含む外部アイテムタイプのスキーマ定義を示す。
【０１３８】
【表１４】
表７に示されるように、アドレスオブジェクト、カスタマーオブジェクト、およびｔｙｐｅ＿ｘｘオブジェクトは全て、ＬＢＳアプリケーション２１０によって維持されるスキーマ定義２３４を有する。エントリを外部アイテムのタイプのスキーマ定義に追加するために、ｉｔｅｍＴｙｐｅ９０４を特定しつつ、ｉｎｓｅｒｔＳｃｈｅｍａメソッド１００２が使用され得る。
【０１３９】
上述のように、ＵＰＰＴは、ローカルデータベース２３２から外部に格納される空間的に認識しているユーザプロファイルアイテムについての情報を維持する。ＵＰＰＴで維持される個々のアイテムは、メソッド１００４〜１００８を用いて位置づけられかつ維持され得る。例えば、アイテム／レコードについてのデータリンクをＵＰＰＴテーブルに設定するために、メソッド１００４〜１００８の内の１つは、１つ以上の以下のパラメータ（ユーザＩｄ、タイプ情報、アイテムについての名前、アイテムプロパティ値、オプションのジオコードされたロケーション）を用いて利用され得る。
【０１４０】
位置ベースのサービスは、システム２００によって提供されているので、メソッド１０１０〜１０１４は、位置情報を利用する。しかし、外部データベース２２８〜２３０内のオブジェクト／レコードは、イネーブルのＬＢＳではない場合もある。例えば、ロケーション情報（すなわち、空間／ジオコードインデックス）は、オブジェクトに関連しない場合もある。にもかかわらず、外部データベース２２８〜２３０内に格納されたほとんどのオブジェクトは、ロケーションのようなプロパティを有し得る。例えば、外部データベース２２８〜２３０は、ホームアドレスの空間のロケーションを識別する空間インデックスではなく、携帯電話の加入者のホームアドレスを含み得る。
【０１４１】
メソッド１０１０〜１０１４が位置情報を利用することを可能にするために、データベース２２８〜２３０の各レコードに対する位置情報は、ユーザプロファイルマネージャ１０００およびメソッド１００４〜１００８を用いてＬＳＢデータベース２３２内のＵＰＰＴに格納され得る。従って、ＵＰＰＴの各レコードは、キーによって固有に識別され、そのレコードに対する位置情報を（ジオコードされた位置等の空間インデックスの形式で）含む。
【０１４２】
本発明のシステム２００を展開する場合、空間インデックスは、外部データベース２２８〜２３０内の各オブジェクトの各レコードに対して獲得され得る。したがって、この空間インデックス情報は、各レコードを識別するためのキーと共にＵＰＰＴに格納される。あるいは、ＵＰＰＴ内の個々のアイテム／特徴／レコードが、所望される場合、適切な位置情報を用いて追加されてもよいし、削除されてもよい。モバイルデバイス２０４とは異なり、外部データソース２２８〜２３０に格納される情報および関連した位置情報は、まれに変化する。したがって、ＵＰＰＴ内の情報の更新は、頻繁に発生する必要がなく、より長い間隔でスケジューリングされ得る。
【０１４３】
一旦、スキーマ定義がシステム２００内で初期化され、ＵＰＰＴが位置づけられると、ユーザプロファイルマネージャ１０００は、外部データベース２２８〜２３０から関連する情報を取り出すために利用され得る。メソッド１０１０〜１０１４は、この情報を見つけ出し、かつ取り出すために利用され得る。
【０１４４】
表８は、本発明の１つ以上の実施形態による、ユーザプロファイルマネージャ１０００によって作成されるユーザプロファイルプロパティテーブルを示す。
【０１４５】
【表１５】
表８の各ロウ／エントリは、外部データベース２２８〜２３０内のアドレスオブジェクトのレコードを表す。メソッド１００４〜１００８が、ＵＰＰＴの部分レコードに対するロケーションプロパティおよび属性を設定するために利用され得るが、ｉｎｓｅｒｔＰｒｏｐｅｒｔｙメソッド１０１６が、新しいエントリ（例えば、アドレスエントリ）をＵＰＰＴに追加するために利用される。ｉｎｓｅｒｔＰｒｏｐｅｒｔｙメソッド１０１６を用いて、（すなわち、表７の外部アイテムタイプスキーマ定義において説明されたように）ユーザＩＤが、誰がその情報を入力しているかを識別し、タイプフィールドが、入力されている情報のタイプを示す。Ｆｏｒｅｉｇｎ Ｋｅｙ Ｖａｌｕｅカラムは、外部データベース内の、そのユーザのための実際のアドレスデータのための外部キーを含む。しかし、本発明では、ユーザプロファイルプロパティテーブルにおけるアイテム値が０に設定される。なぜなら、データが外部データベース２２８〜２３０に格納されるためである。従って、実際のアドレスデータは、ＵＰＰＴ内に格納されない。
【０１４６】
キーは、そのエントリのための固有の識別子を識別する。このようなキーは、ハッシュアルゴリズムを用いて設定されてもよいし、ユーザによって設定されてもよいし、カラム／プロパティの組み合わせであってもよいし、データベース２２８〜２３０のオブジェクトのレコードを固有に識別し得る任意の他のメソッドを用いて設定されてもよい。例えば、表８では、キーは、ユーザの名前（例えば、Ｒａｊｕ、Ｓｃｏｔｔ、またはＴｉｍ）によって、エントリを固有に識別する。
【０１４７】
表８のジオメトリフィールドは、ジオコーディングインデックスとして格納される外部データベース２２８〜２３０からの選択的な位置情報を含む。このような位置情報の使用は、外部データベース２２８〜２３０のＬＢＳをイネーブルにし、それにより、空間クエリが、データ上で実行されることを可能にする。上述のように、システム２００が展開される場合、この位置情報が獲得され、データベース２２８〜２３０のレコードから抽出され得る。その後、位置情報は、ＵＰＰＴに格納される。従って、位置情報は、外部データベース２２８〜２３０に格納される情報の位置を含む。例えば、ジオコードされるロケーションは、１つ以上のカスタマーのホームアドレスのロケーションを識別し得る。
【０１４８】
一旦獲得されると、ＵＰＰＴにおけるロケーションは、次いで、高度にカスタマイズされたサービスを提供するためにＬＢＳサービスによって使用され得る。例えば、特定のカスタマーのホームアドレスのジオコードされるロケーションを用いて、カスタマーが家に向かって移動する場合、カスタマーの家の近くのレストランが決定され得る。さらに、このようなレストランの電話番号および営業時間、または実際のホームアドレスに基づくレストランへの地図が、カスタマーに提供され得る。
【０１４９】
メソッド１０１０〜１０１４およびＵＰＰＴを用いて、適切な追加のおよび所望の情報（アイテムまたはフィーチャとも呼ばれる）は、外部データベース２２８〜２３０から獲得され得る。メソッド１０１０〜１０１４は、（例えば、ｆｉｎｄＩｔｅｍｓ１０１０を用いて）複数のアイテム／フィーチャ、（例えば、ｆｉｎｄＩｔｅｍｓＣｌｏｓｅｓｔＴｏ１０１２およびＬｏｃａｔｉｏｎを特定することを用いて）特定のロケーションに最も近いアイテム／フィーチャ、または（例えば、ｆｉｎｄＩｔｅｍｓＷｉｔｈｉｎ１０１４および領域を識別するＰｏｌｙｇｏｎを特定することを用いて）所定の定義された領域内のアイテム／フィーチャを見つけ出すために使用され得る。
【０１５０】
例えば、現在のユーザに最も近いアイテム／フィーチャを見つけ出すために、ＬＢＳアプリケーションは、ｆｉｎｄＩｔｅｍｓＣｌｏｓｅｓｔＴｏメソッド１０１２を利用し、モバイルデバイス２０４にロケーションを提供する。次いで、メソッド１０１２は、最も近いロケーションを特定するためにＵＰＰＴジオメトリカラムを検討する。一旦適切なエントリが識別されると、エントリ内のキーが、外部データベース２２８〜２３０中の適切なエントリを識別する。次いで、そのメソッドは、（例えば、ｊｄｂｃＤａｔａＳｏｕｒｃｅのメソッド９０６を用いて）外部データベース２２８〜２３０とどのようにして通信するかを決定するため、および、（すなわち、ｓｑｌＳｅｌｅｃｔ９１０を用いて）情報を取り出すために使用する適切なＳＱＬ選択ステートメントを決定するためにスキーマ２３４にアクセスする。ＵＰＰＴからのキーは、外部データベース２２８〜２３０からのさらなるプロファイル情報を取り出すために、ＳＱＬ選択ステートメントと共に使用される。
【０１５１】
同様に、ｆｉｎｄＩｔｅｍｓＷｉｔｈｉｎメソッド１０１４によって、ユーザは、エントリを見つけ出すべきポリゴンを特定し得る。そのメソッド１０１４は、特定されたポリゴン内部のロケーションの位置を特定するためにＵＰＰＴジオメトリプロパティを調べる。一旦適切なエントリが識別されると、適切なキーと共にｓｑｌＳｅｌｅｃｔステートメント９１０を用いて、さらなる情報が外部データベース２２８〜２３０から取り出され得る。
【０１５２】
従って、複数のスキーマの定義２３４は、各外部データベース２２８〜２３０の定義を説明する。ユーザプロファイル情報にアクセスするために、そのスキーマは、スキーマのリストに追加される（すなわち、外部アイテムタイプのスキーマ定義）。初期化される場合、ユーザのプロファイル情報の部分が抽出され、ユーザプロファイルプロパティテーブルに格納される。ＡＰＩを介して、（例えば、標準クエリメカニズムを用いて）クエリがデータを取り出すために実行され得る。データがローカルで利用可能である場合、単に取り出されるだけである。しかし、ローカルで利用不可能な、拡張されたプロパティは、スキーマ２３４およびＵＰＰＴからのデータを使用して、クエリ（例えば、ＪＤＢＣ（登録商標）［Ｊａｖａ（登録商標） ＤａｔａＢａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙ］コール）を発行することによって、内部に取り出される。ＪＤＢＣ（登録商標）コールは、ユーザが、Ｊａｖａ（登録商標）プログラミング言語から任意のテーブル状のデータソースに仮想的にアクセスすることを可能にするＡＰＩコールである。例えば、ユーザプロファイルプロパティマネージャは、ＵＰＰＴにアクセスし、外部データベース２２８〜２３０からさらなるユーザプロファイル情報を取り出すために利用され得る。
【０１５３】
ユーザプロファイルプロパティテーブルを使用することによって、実際の情報（すなわち、アイテム情報）は、外部データベース２２８〜２３０に残っている。次いで、ＳＱＬステートメント９１０は、所望された場合、特定のデータソース９０６から情報を取り出すために使用され得る。
【０１５４】
さらに、ＵＰＰＴにロケーション情報を格納することによって、位置ベースのサービスは、外部データベース２２８〜２３０からユーザプロファイル情報の全てを取り出すことなく提供され得る。例えば、ロケーション情報がユーザのロケーションを識別する場合、ロケーション情報は、近くにある特定のロケーション（例えば、ランドマーク等）を取り出すために、ｆｉｎｄＩｔｅｍｓＣｌｏｓｅｓｔＴｏメソッド１０１２において利用され得る。さらに、（例えば、上述のようにロケータアダプタベースのシステムを用いて）ユーザのロケーションが既知であるために、既知のデバイスのロケーションは、カスタマイズされたサービスをユーザに提供するように、さらなるプロファイル情報の取り出しと組み合わせて使用され得る。
【０１５５】
従って、ＬＢＳブリッジは、無線キャリア、電話会社等によって蓄積された大量のプロファイル情報への位置ベースのサービスの拡張を可能にし、次いで、そのサービスをより個人化にし、かつエンドユーザにとって価値あるものにする。
【０１５６】
（ＬＢＳブリッジの例）
ユーザが、ＬＢＳにイネーブルされたデータとは別にリレーショナルデータベース２２８〜２３０に格納されるアドレスブック／コンタクトリストおよび他の情報、ならびに／あるいは、ローカルに格納されたユーザプロファイル情報を有する場合、ＬＢＳブリッジの使用の例が生じる。ユーザは、コンタクトリスト中のユーザのコンタクトの全てを、見ること、検索すること、位置確認することを望み得る。
【０１５７】
これらの能力を提供するためには、リンクが、ローカルに格納されたアイテムと外部データソース２２８〜２３０のアイテムとの間にセットアップされる。このようなリンクは、ユーザプロファイルマネージャ１０００を用いて確立され得る。アドレスブックアイテムのための空間エントリ（すなわち、ロケーション情報）は、空間クエリをイネーブルするように明瞭に追加される必要があり得る。リンクの確立の後、アイテムは、ユーザプロファイルプロパティテーブル中のロウである。ロウにアクセスするために、ユーザｉｄ（ログインＩＤ）、アイテムタイプ（例えば、「ａｄｒｅｓｓＬｉｓｔ１」）、およびアイテムＩＤ（例えば、友人１）が使用され得る。
【０１５８】
外部データソースアイテムは、外部データソース中のロウに残っている。外部データソースのロウにアクセスするために、（例えば、ＪＤＢＣ（登録商標）データソースを識別する）外部データソース名、（例えば、データソースからロウを抽出する）ＳＱＬ選択ステートメントが必要であり、これらはすべてスキーマ定義１３４に格納される。
【０１５９】
２２２ＡＰＩを使用することによって、全てのリソースのリレーショナルおよび空間クエリが実行され得る。ＡＰＩが利用されるので、データがローカルデータソースから（例えば、ＬＢＳデータベース２３２内から）来るのか、またはデータが外部データソース２２８〜２３０から来るのかはユーザにとって透明である。
【０１６０】
このシステムを用いる際、ユーザは、スキーマ（およびデータリンク）の管理、（各レコードに対する空間情報を含む）ユーザプロファイルプロパティテーブルの位置づけ、および必要な場合は空間情報の更新に対し責任を負い得る。
【０１６１】
（ＬＢＳブリッジフロー）
図１１は、本発明の１つ以上の実施形態に従った、外部データソースへのＬＢＳブリッジの利用を示すフローチャートである。ステップ１１００において、スキーマ定義２３４は、システム２００に挿入される。スキーマ定義２３４は、システム２００の外部データベース２２８〜２３０を利用することを望む通信事業者２２６または任意の他のパーティによって挿入され得る。上述されるように、スキーマ定義は、１つ以上のスキーマ属性、実行時に外部データベース２２８〜２３０からプロパティを抽出するＳＱＬ選択文、および、外部データベースと接続および通信する方法を記述するデータソース情報を含む。該スキーマ定義の挿入はまた、ステップ１１０２においてスキーマ２３４リスト（外部アイテムタイプスキーマ定義と呼ばれる）の生成を含み得る。このようなスキーマ２３４リストは、スキーマ２３４情報／定義ならびにスキーマ２３４のネームまたはリファレンスを有するテーブルを含む。
【０１６２】
ステップ１１０４において、システムのＬＢＳブリッジは、展開／開始される。システムの展開は、ステップ１１０６において外部データベース２２８〜２３０（スキーマ定義２３４によって表現される）のデータの各レコードについて、位置情報を取得することを含む。各レコードについての取得した位置情報およびキーは、その後、ステップ１１０８のＬＢＳデータベース２３２内のＵＰＰＴにローカルに格納される。ステップ１１１０において、外部データベース２２８〜２３０の情報にアクセスするためにブリッジを利用するためのＡＰＩが、提供される。
【０１６３】
情報にアクセスするために、ＡＰＩのメソッドが利用される。メソッドは、ＵＰＰＴを評価して、（ＵＰＰＴ内に格納される位置情報に基づいて）取り出すべき適切なレコードを決定する。適切なレコード（単数または複数）のキーは、その後、外部データベース２２８〜２３０からより詳細なプロファイル情報を取り出すために利用される。メソッドは、データソース情報およびＳＱＬ選択文を含むスキーマ定義２３４からのこのような情報と通信し、かつ、これらを取り出す方法を知っている。
【０１６４】
（結論）
これで、本発明の好ましい実施形態の説明を終わる。以下は、本発明を達成するいくつかの別の実施形態を含む。例えば、メインフレーム、ミニコンピュータ、またはパーソナルコンピュータ等の任意のタイプのコンピュータ、あるいは、タイムシェアリングメインフレーム、ローカルエリアネットワーク、またはスタンドアローンパーソナルコンピュタ等のコンピュータ構成、あるいは、セルラーフォン、ラップトップコンピュータ、パーソナルデジタルアシスタント等の任意のタイプのモバイルデバイスが、本発明とともに利用され得る。
【０１６５】
本発明の好ましい実施形態の以下の説明は、図示および説明のために提示された。網羅的であること、または、開示された正確な形式に本発明を限定することは意図されない。多くの改変および変更が、上述の教示を理解することから可能である。本発明の範囲は、この詳細な説明ではなく、添付の特許請求の範囲によって制限されることが意図される。
【特許請求の範囲】
【請求項１】
明細書に記載の発明。
【請求項１】
明細書に記載の発明。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１２−９０２７８（Ｐ２０１２−９０２７８Ａ）
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願番号】特願２０１１−２４４８７２（Ｐ２０１１−２４４８７２）
【出願日】平成２３年１１月８日（２０１１．１１．８）
【分割の表示】特願２００７−１６９８０７（Ｐ２００７−１６９８０７）の分割
【原出願日】平成１４年１２月２６日（２００２．１２．２６）
【出願人】（５１０３２５８５７）ロングホーン アクイジション， エルエルシー (1)
【Ｆターム（参考）】
【公開日】平成２４年５月１０日（２０１２．５．１０）
【国際特許分類】
【出願日】平成２３年１１月８日（２０１１．１１．８）
【分割の表示】特願２００７−１６９８０７（Ｐ２００７−１６９８０７）の分割
【原出願日】平成１４年１２月２６日（２００２．１２．２６）
【出願人】（５１０３２５８５７）ロングホーン アクイジション， エルエルシー (1)
【Ｆターム（参考）】
[ Back to top ]