"明細書に記載の発明。発明の要旨本発明の1つ以上の実施形態が、多くの移動デバイスキャリアおよび/またはファジー論理を用いて、デバイスのロケーションを決定し、ユーザのプロファイル/個人情報に基く特定のユーザのためのロケーションベースのサービスをカスタマイズするための、方法、システム、装置、および製造品を提供する。デバイスロケータデバイスロケータアダプタとも呼ばれるが、ユーザのために、共通の一様なアプリケーションプログラムインターフェースAPIを提供する。デバイスのロケーションを割り出しているとき、APIは、アプリケーション開発者を切り離し、かつそれら開発者が特定の移動デバイスキャリアを無視できるようにする。デバイスロケータは、キャリアからリクエストされると、特定のキャリアの位置標定サーバ、およびデバイスを識別する異なる方法例えば、携帯電話番号、無線用途リクエストのcookie中に符号化されるMSISDNmobilesubscriberinternationalsubscriberdirectorynumber、リクエストヘッダの中に符号化されるIPアドレス、またはユーザプロファイルデータベースの中の事前に格納されたデフォルトと相互作用する。さらに、デバイスロケータは、キャリアのプロトコルの相違例えば、HTTP,HTTPS,などに対処する。デバイスロケータは、キャリア基盤内のネットワークの不安定さに対処することによってロバスト性を提供する。ロケーションベースサービスは、アプリケーションおよび内容が自動的にユーザの現在の活動プロファイルと整合するように作成される場合、ユーザにとっての価値が非常に上がり得る。例えば、通勤客は、列車やバスの駅、および目的地に早く到着するための別の経路を詳しく見ることに興味を持ち得るが、一方、レジャーの旅行者は、旅行者にとっての目標地点touristlandmarksへの簡単なアクセスを望む。したがって、一旦APIを介してデバイスの近似ロケーションが決定されると、その近似ロケーションは1つ以上の思考モデルを適用して移動位置標定サーバによって修正され得る。例えば、近似ロケーションは、市街ネットワーク上の最短地点へと素早く動かされ得るか、または近隣のランドマーク、または見どころへと素早く動かされ得る。あるいは、その修正は、近似ロケーションの近隣で、例えば、ユーザプロファイルの履歴を調べることによって移動デバイスユーザが最近訪れたロケーションを探し得る。さらに、近似ロケーションは、移動デバイスユーザによってブックマークされたお気に入りのロケーションを調べることによって、および近似のデバイスロケーションの近隣に何らかのお気に入りのロケーションがあるかどうかを決定することによって、修正され得る。さらに、新しいキャリアを利用するために、またはシステムに常駐するキャリアを修正するために、単に、新しいアダプタが追加されるだけである。アプリケーション開発者の立場からするとAPIは同じままであり、全システムの新しいバージョンが配備される必要はない。したがって、本発明では、新しいアダプタが、動的に配備され使用される。さらに、ユーザの現在ロケーションのインテリジェント推論および活動プロファイルまたは意図が不必要な内容の排除を助け、無線アクセスのコスト、時間および性能が向上する。本発明の1つ以上の実施形態は、ユーザの現在ロケーションについてインテリジェント推量をするために、ファジー論理推論と呼ばれる人工知能の分岐ブランチを使用し、かつ例えば、このユーザはビジネスの旅行者か職場の近くにいるかまたは列車の駅の近くにいる通勤客かなどユーザの現在の活動プロファイルの意図を推論する。本明細書に説明するモデルは、曖昧で、不正確で、重複し、競合する入力を捕捉するための正式な構造を提供する。例えば、このモデルは、ユーザの現在の活動はレジャーの旅行客のプロファイルと整合するかとの質問に、純然たるはい/いいえに対して、多分整合するまたははっきりしないという答えを作成し得るという事実を処理し得る。同様に、このモデルは、ユーザの現在の活動は、ビジネスの旅行者のプロファイルおよびレジャーの旅行者のプロファイルの両方に整合し得るという事実も考慮し得る。入力は、空間的、時間的時間に関連した、空間的-時間的速度ベクター、および活動プロファイルのインジケータを含む。このモデルは、入力の参加の度合いたとえば、ことによるとperhaps=0.4、おそらくlikely=0.6、非常にあり得るverylikely=0.8を決定する自然な言語の記述すなわち入力を翻訳するメンバーシップ関数を提供する。さらに、このモデルは、問題に対する現在の理解状況を、入力および出力に関係する直観的な、人の言語の規則ベースで表し得る。例えば、規則は、仮にXおよびYとすると、その場合はZである例えば、もし曇りおよび外套なら、雨であり得るという形式であり得る。すべての規則を含む規則ベースは、例えば、中央アメリカのシエスタ昼寝の時間中の施設の閉鎖を考慮するなど地域的、社会的、または人口統計学的動向を反映するように、簡単に構成され得る。メンバーシップ関数の評価に基いて規則を入力に適用することによって、推論エンジンが、規則を処理し、明確な答えを修正されたロケーションとして提供する。この答えは、アプリケーションによって要求されるように、1つの修正されたロケーションまたは候補地リストであり得る。その結果、ユーザの現在のロケーションが推理、推論され得、いくつかの活動プロファイルの1つに分類され得る。このことによって、次に、アプリケーションが、無線キャリアによって蓄積された膨大な量のプロファイル情報の価値を高め得、アプリケーションおよび無線デバイスに配信された内容の両方を個人化することによって、利用者に提供されるサービスの価値が向上する。一旦ロケーションが修正されると、ロケーションベースサービスはユーザのプロファイル/個人情報に基きカスタマイズされ得る。従来技術のロケーションベースサービスのカスタマイズのために、キャリアによって保持されているデータベースは、データがまだ正確であることを確実にするために、たびたびローカルにコピーされ、頻繁にリロードされた。本発明の1つ以上の実施形態では、すべてのレコードがデータベースの中に残りローカルにコピーされないが、アプリケーションによって他地域/外部データベースにアクセスし得る。実施形態は、外部プロファイルデータベースへのコンパクトLBSブリッジを設計し、実行する。このLBSブリッジは、属性の名前、種類、および制約を含む外部データベースのコンパクトスキーマ定義を含む。LBSブリッジはまた、例えば外部データベースとの接続および通信の方法などのデータソース情報およびスキーマ定義に対応する、データソースからプロパティを抽出するSQLステートメントを含む。LBSデータベース内のテーブルにある各レコードに対する外部キーを格納することによって、外部データソースのレコードが識別される。さらに、外部レコードからのロケーション情報が、抽出/獲得され、ジオコードインデックスとしてテーブルに格納されるそのようにして、外部データベースをLBSイネーブルとする。サービスの収集が、システムインテグレータへの外部アプリケーションプログラミングインターフェースの形で、こうして利用可能となる。LBSブリッジの結果、ロケーションベースサービスは、無線キャリア、電話会社などによって蓄積された大量のプロファイル情報に拡張し得、それが今度は、それらのサービスを、さらに個人化された、エンドユーザにとってさらに価値のあるものにする。したがって、本発明のロケーションの実施形態は、外部のデータベースおよびポータルなどにあるユーザプロファイル情報を可能とし、かつ内部および外部のプロファイル情報の両方を使用してシームレスなロケーションサービスの提供を可能とする。今度は、図面を参照するが、全体を通して、同様の参照番号は対応する部分を表す。以下の説明において、本明細書の一部を形成する添付の図面を参照するが、その図面には、実施例として、本発明のいくつかの実施形態が示される。別の実施形態が使用され得、かつ構造的変更が本発明の範囲から逸脱することなくなされ得ることが理解される。APIによって、移動デバイスキャリアにかかわらず、ロケーションベースサービスアプリケ―ションがデバイスのロケーションを決定し得る。キャリアの位置標定サーバ、移動デバイス識別方法、およびプロトコルの特性は、APIの方法によって内部的に処理される。したがって、アプリケーションは隔離され、キャリアの特定の細部が透明となる。さらに、ヒューリスティックスを使用して、デバイスの近似ロケーションが修正され得る。さらに、本発明の1つ以上の実施形態が、デバイスの近似ロケーションを修正するためにファジー論理推論を用いるための方法を提供する。種々の不正確な入力が、メンバーシップ関数によって処理され、間隔0、1に沿って3つの真の値が割り当てられる。この真の値が入力の規則への参加の度合いを定義する。その後、1つ以上の規則を含む規則ベースを介し、推論エンジンが真の値に従って入力を処理する。各規則は、真の値を使用し得る前件および修正されたロケーションを特定する後件とを有する。それらのルールが、後件のための真の値を定義する各規則のために0から1の間隔内で論理演算結果を生成する。方法は、その後、論理演算結果に基く適切な修正されたロケーションの選択に使用される。さらに、アプリケーションプログラミングインターフェースを使用して、外部データベースのスキーマの定義と、いかに外部データベースと接続しかつ通信するかを記述するデータソース情報と、実行後すぐに、スキーマ定義に対応するプロパティを外部データベースから抽出するデータベースクエリステートメントとを含むLBSブリッジが作成される。ロケーション情報および外部データベースにある各レコードのための外部キーがテーブルに格納され、どのレコードが、所望のロケーション内にあり、カスタマイズされたロケーションベースサービスの提供のために取り出される必要があるかを決定するのに使用される。一旦特定されると、データベースクエリステートメントと外部データベースから所望の情報を取り出すためのスキーマ定義に記述された情報とを用いて、テーブルのキーが使用される。したがって、LBSブリッジが、アプリケーションプログラミングインターフェースを介してユーザの個人情報にアクセスするための方法、機器、および製造品を提供する。ハードウェア環境図2は、本発明の1つ以上の実施形態に従って使用されるハードウェアおよびソフトウェア環境の概略を示す。典型的な分散型データ処理方式のコンピュータシステム200は、例えば携帯電話、PDA、WINCE、またはPALMデバイスの移動デバイスクライアント204、または例えばブラウザを走らせているコンピュータシステムなどのデスクトップクライアントを利用する技術者とサーバコンピュータ206とを接続するために、インターネットなどのネットワーク202を利用する。移動デバイスクライアント204は、HPChandheldpersonalcomputer、ハンドヘルドパソコン、PPCpalm-heldpersonalcomputer,パームヘルドパソコンまたはPDA、携帯電話、スマート電話smartphoneなど任意の種類の移動デバイスを含み得る。しかし、本発明の実施形態は、デスクトップクライアントにも同様に実行され得る。本明細書ではこれ以降、移動デバイスクライアント204およびデスクトップクライアントは取り替え可能に用いられ得、かつ全種類のクライアント/クライアントコンピュータシステムを参照する。システム200に使用されるリソースの典型的な組み合わせは、携帯電話網、インターネット、LAN,WANなどのネットワーク200、移動デバイス204、デスクトップクライアント、およびパソコン、ワークステーション、ミニコンピュ―タまたはメインフレームのサーバ206を含み得る。ネットワーク202は、移動デバイスクライアント204またはサーバコンピュータ206に対し適切なソフトウェアアプリケーションを実行しているデスクトップクライアントと接続する。サーバコンピュータ206は、例えばWebサーバのサーバアプリケーション208、LBSアプリケーション210、MapGuideサービス212、および/またはservlet214などを含む種々のアプリケーションを実行し得る。MapGuideサーバ212およびservlet214は、サーバアプリケーション208内またはその部分に常駐し得る。サーバ206およびそのコンポーネントはまた、バックオフィスシステムbackofficesystemとも呼ばれる。そのようなバックオフィスシステムは企業データベース、同期ユーティリティなどへのアクセスを保持する。サーバアプリケーション208は、通常、UNIX登録商標ApacheWebサーバまたはMicrosoft’sInternetInformationServerなどのプログラムである。servlet214は、クライアント204によってリクエストされた任意の追加の処理がservlet214によって実行され得るように、サーバアプリケーション208を介してクライアント204と通信を行い得る。ロケーションベースサービスを提供する地理情報システムGISにおいて、servlet214は、必要な地図データ/情報を入手するために、MapGuideサーバ212と通信を行い得る。さらに、servlet214は、マップウィンドウファイルMWF216にアクセスし、関連データを入手する。MapGuideサーバ212または別のアプリケーションはまた、データベース管理システムDBMS218と相互作用し得る。このDBMS218は、SDFSpetialDataFilesデータ大量のデータを素早くイントラネットまたはインターネット上に配信するための特別なデータ形式、ラスターrasterデータ、OpenDataBaseConnectivityODBCデータなどの関連する地図データをデータベース220から取り出すために使用される。さらに、クライアント204は、デバイス204のロケーションを決定し追加のロケーションベースサービスを提供するための一様なインターフェースを提供するアプリケーションプログラミングインテーフェースAPIを介して、LBSアプリケーション210とインターフェースで連結する。クライアントデバイス204のロケーションを決定するために、LBSアプリケーションは、様々な移動デバイスキャリア226の異なるプロトコルそれぞれに対する1つ以上のアダプタ224を使用し得る。キャリア226はまた、1つ以上のデータベース228から230にユーザプロファイル情報を保持し得る。上記のように、LBSアプリケーション210はまた、例えば、情報のローカル格納のためのLBSデータベース232を保持し得る。上記のように従来技術では、ユーザプロファイル情報はたびたびLBSデータベース232にリロードされる。LBSアプリケーション210は、外部データベース228から230へのコンパクトLBSブリッジを実行する。LBSブリッジを実行するために、LBSアプリケーション210は、外部データベース228から230のそれぞれのスキーマのコンパクト定義234を保持する。スキーマは以下に詳しく説明される。さらに、API222がファジー論理を用いてデバイスのロケーションの修正のためのインターフェースを提供し得る。概して、コンポーネント204から234のすべてが、例えば、データ格納デバイス、データ通信デバイス、ネットワークまたは別のデータコミュニケーションデバイスを介してコンピュータに接続されるリモートコンピュータまたはデバイスなど、デバイス、媒体、信号またはキャリアにおいて具体化されるまたはデバイスから取り出し得るロジックおよび/またはデータを含む。さらに、このロジックおよび/またはデータは、読まれ、実行され、および/または翻訳処理されるとき、実施されている本発明の実行および/または使用に必要なステップを生じる結果となる。したがって、本発明の実施形態が、ソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組み合わせを製造するための標準プログラムおよび/または工学技術を使用する、方法、装置、または製造品として実施され得る。本明細書において使用される用語製造品articleofmanufactureまたは、その代わりにコンピュータプログラム製品は、任意の、コンピュータを使用し得る、デバイス、キャリアまたは媒体からアクセス可能なロジックおよび/またはデータが含まれることが意図される。当業者は、本発明の範囲から逸脱することなく、この例示的環境に対し、多くの改変がなされ得ることを認識する。例えば、当業者は、上記のコンポーネントの任意の組み合わせ、または、異なるロジック、データ、異なる周辺装置、および異なるデバイスを含むかなり多くの異なるコンポーネントの任意の組み合わせが、それによって同様の機能が実行される限り、本発明の実行のために使用され得ることを理解する。移動デバイスロケータアダプタシステムデバイスロケータアプリケーションは、特定の移動デバイスクライアント204のロケーションの決定のために、クライアント204またはサーバ206上で実行し得る。デバイスロケータアプリケーションは、特定の移動デバイスクライアント204のロケーションの決定のために、クライアント204またはサーバ206上で実行し得る。移動デバイスクライアント204のロケーションの決定のために、デバイス専用アイデンティフィケーションがデバイスロケータに提供される。例えば、MSISDNmobilesubscriberinternationalsubscriberdirectorynumberディレクトリナンバー例えば、GSM登録商標-globalsystemformobilecommunicationsnumberまたはGSM登録商標加入者に接続するためのナンバー1ダイアルがデバイスロケータアプリケーション210に提供され得る。そのようなMSISDNは、無線アプリケーションリクエストのcookieの中に符号化され得る。あるいは、デバイスは、リクエストヘッダに符号化されたIPインターネットプロトコルアドレスによって識別され得るか、またはユーザプロファイルデータベース228から230に事前に格納されたデフォルトによって識別され得る。デバイスロケータ210によってその結果提供されるロケーションは、デバイス204の座標、デバイス204のSRSspatialreferencesystem空間基準システムおよび座標の正確さに関する情報を含む。デバイスロケータ210が、ネットワークが提供するデバイス204のロケーションへのアクセスのためのインターフェース222を提供する。例えばSIMカードを介して自身のロケーションを提供するデバイス204に対し、アプリケーション開発者は、すでにデバイス204の座標を有しており、デバイスロケータ210を使用する必要がない。デバイスロケータ210は、ユーザに、デバイス204のロケーションの決定のための一様のAPI222を提供する。デバイスロケータ210は、デバイス204のロケーションをLDTthird-partylocationdeterminationtechnologyサードパーティロケーション決定技術プロバイダ226から取り出す。このLDTのそれぞれは、例えば、HTTP、HTTPSなどの異なるプロトコルをサポートし得る。LDTは、デバイス204のロケーション情報を内部および外部のシステムに提供する、キャリアネットワークベースサービスを表す一般的な用語である。LDTアダプタ224は、特定のキャリア226によって供給され得、ロケーション情報の提供に使用され得る。供給されるLDTアダプタ224以外のソースから得られる任意のロケーションは、ロケーションパラメータを要求する任意のアプリケーションプログラム情報APIの呼び出しにおいて、GISアプリケーションのすべてを通じて、なお使用され得る。上記のように、LDTプロバイダ/キャリア226は、それぞれ、リクエストの形式、応答の形式、および応答の正確さに関して異なる、違ったプロトコルをサポートし得る。移動システムが所在する、地理的地域のみを提供し得るサービスもあれば、特定の座標を提供し得るサービスもある。デバイスロケータインターフェースすなわちAPI222は、個々のLDPプロバイダ226の特定のAPIからアプリケーションコードを隔離する。アプリケーション開発者は、プロバイダのAPIまたはプロトコルを理解する必要がない。かわりに、LDTアダプタ224が特定のプロバイダのAPIを、デバイスロケータ210としてアプリケーションに与えられた一般的なAPI222に翻訳する。LDTアダプタ224は、したがって、HTTPhypertexttransferprotocol、HTTPSsecurehypertexttransferprotocolなどのプロトコルの違いからアプリケーションを隔離する。そのようなアーキテクチャはまた、将来、アプリケーションAPI222を変更することなく、追加のLDTプロバイダ226をサポートし得る。新しいLDTプロバイダ226のために、ただ、LDTアダプタ224が書かれる必要があるのみである。図3は、本発明の1つ以上の実施形態による、デバイスロケータ210をサポートするアーキテクチャを簡単に表したものである。例示するように、アーキテクチャがいくつかの層302から308を有する。デバイス204のロケーション情報を入手するために、アプリケーション層302の中のアプリケーションコード310が、プラットフォームAPI層304で、一様なAPI222を介して、例えば、LbsDeviceLocatorManagerのデバイスロケータ312とインターフェースで連結される。キャリアに特有のインプリメンテ―ションを用いてロケーション情報を取り出すために、デバイスロケータ312は、内部層306の特定のキャリアLDTアダプタ224に記述される個々のキャリアプロトコルとインターフェースで結合される。キャリアLDTアダプタ224は、リモートLDTプロバイダ層308のサーバコード318と通信するクライアントコード316と相互作用する。デバイス204のロケーションのクエリを行うために、アプリケーションコード310が、例えば、LbsDeviceLocatorManagerのデバイスロケータオブジェクト312の事例を取り出す。デバイスのidが与えられたデバイス204のロケーションを入手するために、アプリケーションコード310は、その後、デバイスロケータ312を使用し得る。上記のように、デバイスのidの形式は、LDTの実行によって異なり得る。デバイス204のロケーションのクエリが失敗した場合、デバイスロケータ312が例外を生成し得る。クエリが成功した場合、ロケーションオブジェクトはアプリケーション層302に戻され得る。上記のように、その結果としてのロケーションオブジェクトは、デバイスのロケーションを表す座標を含むPoint/Coordinateオブジェクト、関連する空間基準システムを記述するSRSオブジェクト、および座標の正確さを記述するPrecisionオブジェクトを含む。本発明の1つ以上の実施形態では、デバイスロケータマネージャが、個々のキャリア226のために/によって実行される特定のgetLocation方法にAPI222およびデリゲートコールを提供する。個々のキャリア226がそのようなgetLocation方法を実行するのを確実にするために、例えば、デバイスロケータインターフェースなどのインターフェースが特定のデバイスロケータアダプタ224によって実行され得る。EricssonTM実施上記のように、様々なアダプタ224がLBSアプリケーション210によって利用さ得る。各アダプタ224は、特定のセルラーキャリア226として構成され得る。以下の記載は、EricssonTM用に実施されたアダプタ224実施をサポートすることに特定されている。EricssonTMでは、デバイスidは、MSISDNとして表されている。EricssonTM実施は、セル内にデバイス204を位置付けて、セルタワーからのおおよその距離を決定可能である。セルは、基地局を取り囲むか、基地局に直ぐ近くの地理上の領域である。このロケーションは、図4に示された円弧でモデリングされ得る。例えば、ロケーションオブジェクトの一部として戻された点オブジェクトは、円弧の地理的中心を表し、アプリケーション層302は、内径d1および外径d2を取り出し得る。角度θ1およびθ2は、北向きから時計回りに計測される度数である。デバイスロケータ312がデバイス204のロケーションを決定できない場合、デバイスロケータ312は、所定/特定の回数だけリクエストをリトライする。特定のリトライ数の後、このデバイスロケータ312が依然としてロケーションを決定できない場合、例外が投げられる。通常、例外は、LDTプロバイダ226/アダプタ224とインターフェースするときに起こる。LDTプロバイダ226が例外を生成する場合、プロバイダ226によって提供された任意のさらなる情報エラーコードおよびメッセージ等がエラーログファイルに書き込まれ得る。デバイスロケータ312のエラーコードをエラーコードのリストと比較することによって、デバイスロケータ312により例外が投げられたことを決定し得る。以下の表は、EricssonTMの実施によって戻されたエラーコードを説明している。このエラーコードは、エラーログファイルに現れる。この表において、用語統一システムは、ロケーションを特定するシステムに関する。EricssonTMPositioningProtocolEricssonTMは、モバイルポジショニングセンターとインタフェースするEricssonによって開発されたHTTP/HTTPSベースの規格に関する。IDMS0は、縦または横を特定するフォーマットに関する。ここで、Iは主軸方向、Dは角度2または3桁、Mは分2桁、Sは秒2桁、および0は小数点以下が無いことを示す例えば、E153806またはN603758。さらに、モバイルポジショニングセンターMPCは、EricssonTMによって用いられる用語であり、アプリケーションをモバイルステーションポジション情報にアクセス可能にするポジショニングゲートウェイを説明している。さらに、モバイルポジショニングシステムMPSは、EricssonTMによって用いられる用語であり、LDTに対するMPPを実施することを説明している。このエラーコードは、EricssonTMMPSSDKのバージョン3.0を表している。表1‐EricssonTM汎用エラーコード表2‐EricssonTMシンタックスエラーコード表3‐EricssonTM認証エラーコード表4‐EricssonTMオーソリティエラーコード表5‐EricssonTMポジショニングエラーコード表6‐EricssonTMネットワークエラーコード表7‐EricssonTMMPS1.1エラーコードアダプタシステムフロー図5は、本発明の1つ以上の実施形態によるモバイルデバイスロケータアダプタシステム200でAPIを用いることを示すフローチャートである。図2および図5の両方を参照すると、モバイルデバイスロケータアダプタシステム200では、コンピュータシステム200の新規のバージョンを展開deployすることなく、アプリケーション200すなわち、デバイスロケータは、コンピュータシステム200内で動的に展開され得る。一度アプリケーションプログラム210が展開されると、アプリケーションプログラム210のAPI222の単純化プロシージャがステップ500で呼び出され得る。単純化プロシージャは、ステップ502において、例えば、モバイルデバイス204の同定を用いてモバイルデバイス204のロケーションを得る。ロケーションを得るために、呼び出されたプロシージャは、ステップ504でキャリアアダプタ224と相互作用する。キャリアアダプタ224が特定のキャリア206に対してカスタマイズされるため、特定の情報および方法が利用され得る。例えば、呼び出されたプロシージャは、キャリア226のモバイルポジショニングサーバの詳細、およびキャリア226によって必要とされるデバイス204を識別する異なる方法と相互作用し得る。さらに、呼び出されたプロシージャは、ステップ506において、デバイス204のロケーションに関連する空間参照システムspatialreferencesystemを得てもよい。ステップ502で得られたモバイルデバイス204のロケーションは、セルラーホン番号、MSISND、リクエストヘッダまたは予め格納されたデフォルトでエンコードされたインターネットプロトコルアドレスを含んでもよい。さらに上述されるように、ステップ504で1つ以上のキャリアアダプタ224と相互作用することによって、呼び出されたプロシージャは、キャリア226によって提供された異なるプロトコルと相互作用する。一度、ステップ506でロケーションが得られると、そのロケーションは、ステップ508でさらにリファインrefineされ得る。ロケーションをリファインするために、1つ以上のヒューリスティックスが適用され得る。例えば、そのロケーションは、ストリートネットワークの最も近い点、近傍の該当点または目印、ユーザの履歴を調査することによるモバイルデバイスユーザが最近訪ねたロケーションの近傍のロケーション、または、モバイルデバイスユーザがお気に入りロケーションとしてブックマークに入れたロケーションの近傍のロケーションにスナップsnapされ得る。あるいは、ファジーロジックは、デバイス204のロケーションをリファインするために用いられてもよい。ロケーションリファインメント一度デバイス204のロケーションが得られると、本発明の1つ以上の実施形態は、いくつかのヒューリスティックスを適用することによって、および/または、ファジーロジックを適用することによって、近似ロケーションをリファインしてもよい。ユーザまたはアプリケーションは、このようなロケーションリファインメントが起こるときを特定し得る。例えば、ブールREFINE値は、リファインメントが所望である場合、TRUEに設定され得る。従って、上記のように一度ロケーションが特定されると、ブール値は、さらなるリファインメントが実施されるべきかどうかを決定するように試験され得る。ユーザは、デバイス204のロケーションをリファインする所望の方法論を特定するように許可され得る。このような異なる方法論は、リファインメントプロセスで用いられるルールのセットを構成することによって特定され得る。さらに、このようなルールは、ルール構成ファイルの表に格納され得る。異なる方法論は、ストリートネットワークの最も近い点、目印、またはその近傍の該当する点にロケーションをスナップすることを含み得る。あるいは、アプリケーションは、モバイルデバイスユーザが最近訪ねた近似ロケーションの近傍のロケーションを探しすなわち、ユーザプロフィールの履歴を調査する、ロケーションを特定のロケーション例えば、最後に訪ねた最も近いロケーションにスナップし得る。さらに、アプリケーションは、モバイルデバイスユーザによってブックマークに入れられたお気に入りロケーションを調査して、いずれかのこのようなお気に入り位置が近似デバイスロケーションの近傍にあるかどうかを判定し得る。その後、近似位置が最も近いお気に入りロケーションにスナップし得る。さらに、ファジーロジックは、以下に詳細に説明されるように位置をリファインするように用いられ得る。例えば、ロケーションリファインメントへの単純な解決方法では、正確なポリゴン形状の図心が、x=DoubleIntegralxdxdy/DoubleIntegraldxdy、およびy=DoubleIntegralydxdy/DoubleIntegraldxdyによって規定される。図心のこのような定義を用いることによって、精密なポリゴン例えば、102の些細なリファインメントが提供される。しかし、図心は、実際にロケーションをリファインしない。それにもかかわらず、このような図心は、精密なポリゴン102内の真のtrueロケーションの均一分配の最良の平均エラーを提供し得る。ロケーションリファインメントの別の例では、ユーザプロファイルおよび局地的なコンテンツがリファインメントに影響を与えるために用いられる。このようなリファインメントでは、無線キャリア226、プロファイルデータベース228~230、無線ポータル例えば、アダプタ224およびローカルユーザプロファイルデータベース例えば、LBSデータベース232は、共に、非常に特別なプロファイル情報へのアクセスを有する。このようなアクセスは、NemmaraChithambaramらによる、LOCATIONBASEDSERVICESBRIDGETOEXTERNALDATASOURCESと称され、同時係属中で、同一人に譲渡され、2001年12月26日に出願された米国特許出願第10/034,440号アトーニードケットNo.GC30566.204-US-01に記載されており、提供され得る。この情報は、LBSサービスまたはLBSアプリケーション210をより多く用いることによって、次第に豊かにより、かつより正確になり得る。LBSアプリケーション210をさらに用いることによって得られるデータは、最近訪ねたロケーションの履歴、および/または最近実行したクエリ例えば、最も近い博物館を訪ねるに基づいて、ユーザの一般的人口統計分類、民族分類、ユーザのロケーションパターン例えば、家、オフィス、お気に入りロケーションおよび/またはユーザの現在の活動プロファイルに関連する洞察を提供し得る。さらなるこのようなプロファイル情報はまた、ユーザがブックマークに入れたお気に入りロケーションの近傍にいるかどうか、または、ユーザがロケーション履歴に最近記録されたロケーションの近傍にいるかどうか等の質問に答えるために用いられ得る。これらの条件のうちの1つが正しいと判明する場合、リファインされたロケーション用の候補としてのお気に入りロケーション、またはユーザプロファイルロケーション履歴のロケーションが容易に提供され得る。しかし、LBSサービスは、ユーザが家庭または仕事から離れており、不慣れな地域にいることが多い場合に、より一般的に用いられる。このような場合、近傍の該当する目立ったランドマーク単数または複数あるいは点単数または複数は、リファインされたロケーション単数または複数として提供され得る。さらに、選択された該当するランドマークまたは点のカテゴリーは、ユーザプロファイルおよびロケーションコンテンツデータベース232に基づいて、ユーザの現在の活動のプロファイルを聡明に推量することに依存し得る。このような入力は、ロケーション局面例えば、ユーザのお気に入りルートであるロケーション、活動プロファイルインジケータ単数または複数例えば、この人はビジネスビジターかまたは、最後のファインダークエリが最も近い博物館を見つけるであった、および/または一時的な局面例えば、典型的なビジターアトラクションはこの地域でどれくらい遅れてオープンしたのかの組み合わせを含み得る。さらに、ユーザのお気に入りは、ユーザに対してテーラリングされた、高度にパーソナライズされたサービスを伝達するように推論され得る。例えば、アプリケーションの動作からコンテンツのフィルタリング用のスライライジングまでどんなものでも特定のユーザの対してパーソナライズされ得る。デバイス204の近似ロケーションをリファインするために、ロケーションリファインメントマネージャが利用され得る。このロケーションリファインメントマネージャは、ロケーションリファインメントのための最初の点であり得、ロケーションリファインメントマネージャの方法が1つのリファインされたロケーション例えば、最良推定、リファインされた候補ロケーションのソート済みリスト、または、ソースによって分類されたリファインメント候補のいくつかのリスト例えば、ユーザプロファイルお気に入り、ユーザプロファイル履歴、ビジターランドマーク等を返し得る。リファインされた位置の各リストは、実行された特定のリファインメントに基づき得る。例えば、あるリストがお気に入りに基づき得て、第2のリストが履歴に基づき得て、第3のリストがランドマークに基づき得る。さらに、各リストは、図心または近似位置からの距離に基づいてソーティングされ得る。一度リファインされたロケーションのリストが得られると、ユーザは、LBSアプリケーション210と相互作用して、ユーザの正確な位置を計算し得る。この相互作用は、例えば、リファインされたロケーションの1つの承認を含み得、候補リストからの選択を可能にし得る。1つ以上の候補ロケーションを使用することがユーザの真のロケーションを方向付けて、位置を特定可能となる。さらに、このプロセス中に、全てのリストは、1つのリスト内に分割され得る。例えば、各リストの各ロケーションは、図心からの距離によってソーティングされた1つのリストに組み合わせられ得る。さらに、それぞれのリストまたは1つの解決したリストは、特定のポリゴン内のロケーションのみがリターンされるようにフィルタリングされ得る。さらに、個々のリストまたは1つの解決されたリストに基づいて、1つのリファインされたリストがリターンされ得る。従って、ロケーションリファインメントマネージャの実施に基づいて、ユーザは、1つのリファインされたロケーション位置、リファインされたロケーションのリストまたはリファインされたロケーションのリストのリストによって提示され得る。それにもかかわらず、ロケーションリファインメントマネージャによって、デバイス204の近似の位置は、ユーザによって選択可能であり得る様々な因子に基づいてリファインされることが可能となる。ファジーロジックリファインメント本発明の1つ以上の実施形態は、ファジーロジックを用いてデバイスロケーションをリファインする製作者の方法、装置および商品を提供する。このファジーロジックリファインメントプロセスは、ロケーションリファインメントマネージャによって初期化され得る。ファジーロジックを利用して、デバイスの位置をリファインするために、多くの理由が存在する。最大限の利益を提供するために、いくつかの質問および情報が必要であり得る。例えば、必要な情報は、現在の活動プロファイルがコンピュータプロファイル、ビジネスビジタープロファイル、レジャービジタープロファイル、これらのプロファイルのうちの1つ以上とマッチするか、これらのプロファイルと全くマッチしないかどうかを含んでもよい。しかし、このような質問に答えるとともに、多くの問題が生じ得る。例えば、この問題の定義があいまいであってもよい。言い換えると、この問題は、正確な定量的な定義には適切ではないかもしれない例えば、~の近傍、~の近く、~から離れた、おそらく、等の非定量的な用語が頻繁に用いられてもよい。さらに、リファインされたロケーションに対するランドマークの特定のカテゴリーがいつ用いられるべきか主体的問題を決定することは困難であり得る。さらに、境界がぼやけていてもよい。例えば、現在の活動はレジャービジターのプロファイルにマッチしているかという質問に対する答えは、たぶんまたは不確か対はい/いいえであり得る。さらに、入力が不正確でも、衝突していても、および/またはオーバーラップしていてもよい。例えば、現在の活動プロファイルは、レジャー中の夕方を過ごしているビジネスビジターを表す。これらの問題は、入力に固有のあいまいなこと、不正確なこと、およびぼやけた境界を取り扱うシステムを要求する。さらに、システムは、このような不正確かつ衝突している情報がいかに捕えられて、処理されるか、使用法および展開が上昇した問題の理解が深まったという連続的な沈思を可能にするか、そして、決定的な結論を提供するかどうかを定式化するべきである。本発明の1つ以上の実施形態は、このような問題を解決するファジーロジックと呼ばれる人工知能AIの分野を利用する。ファジーロジックは、部分的に真完全に真と完全に偽との間の真の値であるという概念を取り扱うために拡張された従来のブールロジックの上位集合である。ファジーロジックでは、連続的な真値は、システム変数が、厳密なバイナリ真および偽決定および割り当てではなく、区間[0,1]における真値のメンバーシップの連続的な範囲を取り得るように認められる。例えば、曇りcloudyおよび曇っているovercast場合、その記述雨が降っているは、0.8の真値であろうし、偽値は0.25でもあろう。同様に、記述現在のユーザはビジターであるは、非常に確からしい場合0.9の値を有し、あまり確からしくない場合0.1の値を有し、その答えがたぶんmaybeである場合0.5の値を有する。ファジーロジックを用いると、ロケーションリファインメント問題が再定義され得る。このような問題の再定義が図6に示され得る。この図6は、再定義されたロケーションを重み付き入力のファジー図心として示す。図6では、ロケーション精度ポリゴン102は、近似のデバイス204ロケーションとして与えられる幾何学的な図心100を含む。リファインされた位置104は、様々な異なる可能性602~614から選択されてもよい。しかし、様々な異なる可能性602~614は、リファインされたロケーションをファジー図心104として決定するために重み付けされて組み合わされ得る。様々なファジーメンバーシップセット602~614は、ロケーションをリファインするために、用いられて重み付けされ得る。異なるタイプのファジーメンバーシップセット602~614は、重み付け計算に利用され得る。例えば、ファジーメンバーシップセット602~614は、ユーザプロファイルロケーションの様々なカテゴリー例えば、最も近いユーザプロファイルお気に入り602、ユーザプロファイル履歴604等に対する近似として利用され得る。さらに、ファジーメンバーシップセット602~614は、現在の活動例えば、ビジネスビジタープロファイル、通勤者プロファイル、レジャービジタープロファイル等、拡大解釈すると、異なる種類のランドマーク例えば、最も近いロギングランドマーク606、最も近いビジターランドマーク608、最も近いビジネスランドマーク610、最も近いストリートインターセクション612、最も近い通勤者ランドマーク614等に対する重み付け近似を記述し得る。ファジーメンバーシップセットに基づくと、リファインされたロケーションは、これらの重み付け入力のファジー図心104として推論され得る。本発明のファジーロジック推論は、任意の数の正確または不正確な入力単数または複数センサが可能であるように、様々な数の不正確な入力を可能にする。例えば、以下の一つ以上のものがデバイスロケーションをリファインするために入力センサとして用いられ得る:お気に入り、ビジネスビジタープロファイルインジケータ、レジャープロファイルインジケータ等の近似。本発明のファジーロジック推論は、IFXandYthenZの形式の入力/出力関係を定義する直感的なルールセットを定義するルールベースを含む。例えば、以下のルールのうちの1つ以上は、本発明のルールベース内に定義され得る。Ifローカルお気に入りロケーションに近いthenClosestFavorite、または、Ifお気に入りから遠いand現在の活動がビジターランドマークにマッチするthenClosestVisitorLandmark。メンバーシップ関数は、ロケーションを決定する際に各入力の関与の程度を定義する。例えば、メンバーシップ関数は、現在の活動プロファイルがレジャービジタープロファイルにマッチするかどうかという疑問を評価し得る。最も確からしいmostlikelyという答えは、そうかもしれないcouldbeという答えに対して、より高度なメンバーシップ関数、およびロケーション決定により良好に関与しているという結果となる。最後に、本発明のファジーロジック推論は、これらのルールの各々の論理積を計算する推定エンジンを含む。例えば、推定エンジンは、XANDY=MINX,YYORY=MAXX,Yのように論理積を決定し得る。この論理積は、その後、最終的な答えを生むために組み合わせられる。図7は、本発明の1つ以上の実施形態によるファジーロジック推論プロセスの概観である。図示されるように、ファジー入力702すなわち、様々な数の不正確な入力は、各入力702の関与の程度を定義する一つ以上のメンバーシップ関数704によって処理される。その後、一つ以上のルールを含むルールベース706は、推定エンジン708によって処理される。この推定エンジン708では、一つ以上のルールに対する論理積が計算される。この論理積は、各ルールに対して真のレベルすなわち、区間[0,1]の値を提供する。その後、推定エンジンは、一つ以上の異なる方法を用いてリファインされたロケーションを選択する。例えば、最大論理積または二乗平均平方根値710が適切な最終出力712すなわち、リファインされたロケーションを決定するために利用され得る。従って、ファジー入力702は、メンバーシップ関数704によって処理される場合クリスプcrisp形式からファジー形式へと移行する。ここでは、それらは、推定エンジン708によって処理される。この推定エンジン708は、論理積を識別して、適切な論理積および出力712に対する対応するリファインされたロケーションを選択する所望の方法論710を用いることによって、クリスプ形式に逆に処理される。3つのタイプの入力センサファジー入力702が利用され得る:ロケーションまたは近似ベース、時間ベースおよび活動プロファイルベース。ロケーションまたは近似ベース入力702は、特定のロケーションへの近似を決定する。例えば、ロケーションベース入力702は、例えば、自宅、オフィス、健康クラブ等に近似のお気に入り、および例えば、ユーザプロファイル履歴の最近訪ねたロケーションに近似の履歴を含み得る。活動プロファイルベース入力702は、現在のユーザの活動が特別に確立されたプロファイルにマッチする、類似するかどうかを判定するために評価される。例えば、確立されたプロファイルは、ビジネスビジタープロファイル例えば、現在の活動がビジネスビジターのプロファイルにマッチしているか、レジャービジター活動プロファイル例えば、現在の活動がレジャービジターのプロファイルにマッチしているか、および通勤者活動プロファイル例えば、現在の活動が通勤者のプロファイルにマッチしているかを含み得る。一時入力702は、現在の時間が特別な一時領域またはプロファイル内にあるかどうかに基づいている。例えば、ビジネス稼働時間の一時入力702を運転しているビジネスは、現在の時間がビジネス稼動時間内であるかどうかを判定し得る。あるいは、レジャー稼動時間一時入力702は、現在の時間がレジャー稼動時間内であるかどうかを判定する。方向または行程を示す速度ベクトル等の他のシナリオ-一時入力702が入力702として加えられ得る/利用され得る。その後、ファジーロジックは、入力702を処理して、出力712を作る。この出力712は、一つの値を含んでもよいし、複数の候補が必要である場合値のセットを含んでもよい。出力は、最も近いお気に入りロケーション602、最も近い履歴604、最も近いレジャーランドマーク608、最も近いビジネスランドマーク610、最も近いロギングランドマーク606例えば、ホテル、最も近い通勤者ランドマーク614、最も近い交差点612等を含んでもよい。メンバーシップ関数704は、各入力の関与の程度を定義するために利用される。言い換えると、メンバーシップ関数704は、入力702の評価を作成して、インターフェースエンジン708にどれくらい入力702が用いられるかを決定する。3つの値のセットは、各入力/メンバーシップ関数704として用いられ得る。真値に対してはPすなわちポジティブ、偽値に対してはNすなわちネガティブ-およびいずれかの方向にも向かうことができるか、不確かさを反映することができる値に対してはZすなわちゼロ0である。各セットは、近いセット/区間[0,1]から値を取ることができる。例えば、入力関数LeisureVisitorActivityProfileは、以下のようにファジー化されることが可能である。最も確からしいMostLikelyレジャービジター→P=0.8あまり確からしくないUnlikelyレジャービジター→N=0.8そうであるかもしれないし、そうではないかもしれないMayormaynotbe不確かである→Z=0.8同様に、P,NおよびZ値は、全ての他の入力702に対して定義され得る例えば、近い=P,遠い=N,不確か=Z。表1は、入力702の関与に対する異なる値を格納するために用いられ得る入力メンバーシップ表の例である。メンバーシップ関数704は、P,NおよびZに対する適切な値で埋める。メンバーシップ関数704を通して入力702を処理することに続いて、入力702は、メンバーシップ関数704によって提供される関与すなわち、P,NおよびZ値の程度に従って、ルールベース706に対して推定エンジン708によって処理される。このルールベース706が単に推定エンジン708によって適用されるため、ルールベース706は、より多くの経験的データが集められるにつれて、進歩的にリファインされ得る。さらに、デフォルトルールが特定され得る。このデフォルトルールは、推定エンジン708が、衝突しているルールまたは入力702が原因により結果を作り出すことができない場合/ときに用いられる。従って、ルールベース706がフェイルセーフである。あまりにも多くの衝突する入力702のために、このファジー推論が結果を出すことができない場合、このデフォルトルールが適用される例えば、デフォルトルールがこのように提供する場合、最も近い交差点を答える。さらに、変化するルールおよび入力702に基づいて作られる出力712で実験すると、ルールのインクルージョンinclusionおよびエクスクルージョンexclusionは、実験に影響され得る。このような実験に対して、ルールが論理積を用いること、および、非ゼロの論理積のみが最終的な推定に寄与することを提供する。例えば、メンバーシップ関数704がゼロであるP,NおよびZ値を提供する場合、入力702は、大きさを有せず、ルールに参加することができない。さらに、論理演算が実行されるため、ゼロ値が用いられる場合、ルールにおける積の結果は、また、ゼロであるこれにより、不適切な出力712を作る。従って、関数704のP,NおよびZ値に対して0.0の値を初期設定することによって、論理積ルールの結果として寄与することから、ルールが排除される0.0であるために、X=0.0である。従って、ルールの数、ルールの複雑さ、および推定エンジン708が例えば、世界の異なる部分に対して適応して、あるいは、より豊かなユーザプロファイルデータベースに対して構成され得る。表2は、ルール番号、先行詞antecedent、およびルールベース706に対する結果を含むルールベース706の表を示す。テーブル2は、どのようにして、入力メンバーシップテーブルすなわち、テーブル1中の値が規則のセット中で利用されるかを示す。例えば、規則3では、4つの条件が入力702に基づいて処理され、最も近いビジネスランドマークを生成する。4つの規則は、論理AND演算を使用して、前件の規則を評価する。お気に入りへの接近度がNまたはZ、履歴への接近度がNまたはZ、ビジネス旅行者プロファイルがP、およびビジネス活動時間がPである場合、規則3では、最も近いビジネスランドマークが、後件であるすなわち、出力612。さらなる規則の各々は、それが組み合わされた場合、特定の後件を生成する1セットの前件/状態を有する。一旦、規則ベース706が確立された例えば、規則ベーステーブルに置かれた場合、推論エンジン708は、ファジー重心104を計算するために使用される。推論エンジン708を使用する場合、各規則例えば、テーブル2の規則1~8の論理演算結果が処理される。この処理は、各規則に対して0~1の値を生成する。論理演算結果を処理する場合、前件のXおよびYおよびZは、X、Y、およびZの内の最小物すなわち、MINX,Y,Zと等価である。同様に、前件のXまたはYまたはZは、X、Y、およびZの内の最大物すなわち、MAXX,Y,Zと等価である。各規則に対する論理演算結果間隔0,1の値を有するは、その規則の参加の度合いを示す0は参加がないことを示す。この推論は、そのMAXを選択し、平均するかまたは2乗平均平方根710を使用することを含む非ゼロの度合いの規則の重みつき重心104を計算する異なるメソッドを使用し得る。1つ以上の実施形態では、最も大きい論理演算結果を有する規則が選択されるように、MAX規則が常に利用される。例えば、テーブル2の規則5がもっとも大きい論理演算結果、例えば、0.9を生み出す場合、修正された位置は、ClosestLodgingLandmarkである。さらに、規則を適用する際、複数の候補または複数のリストが必要とされる場合、最大2または3の論理演算結果からの第1のn個の要素が選択される。例えば、テーブル2の規則5および7が最大値を生み出す場合、ClosestLodgingLandmarkおよびClosestCommuterLandmarkを表す2つのリストが修正候補として提供され得る。ファジー論理修正の例示的なアプリケーション例1簡単な例簡単な例では、ユーザは、任意のお気に入りのロケーションに非常に近いところに居ないかもしれないが、ユーザのプロファイル履歴におけるロケーションに非常に近い。このような例では、入力メンバーシップテーブルは、テーブル3に示されるような値を有する。この例では、テーブル4に示されたように、規則テーブルの中で非ゼロ論理演算結果を生み出す規則は規則1および2のみである。Max規則を用いるとすなわち、最大論理演算結果を有する規則を取る、規則2が優勢になり、修正されたロケーションに対する出力712は最も近い履歴である例えば、ユーザの履歴の内、最新のロケーション。最も近い履歴が予測される答えである。例2この例では、ユーザはお気に入りから遠く離れており、履歴から遠く離れており、現在の活動プロファイルは、ユーザがビジネス旅行者プロファイルに整合することを示し、現在の活動プロファイルは、ユーザがまた、レジャー旅行者プロファイルに整合し得ることを示し、時刻は、平日の午後8時である。メンバーシップ関数704でのこれらの値の処理は、テーブル5の入力メンバーシップ関数に対する値を生じ得る。これらのメンバーシップ値に対する非ゼロの度合いの規則およびその論理演算結果は、以下のテーブル6に示される。最大の論理演算結果は、規則5および4に対するものである。従って、この例についての修正に対する候補は、ClosestLodgingLandmarkおよびClosestLeisureLandmarkを含む。利点および利益デバイス204のロケーションを修正するためのファジー論理推理の使用は、ロケーションおよび修正に対する入力、ならびにその修正を計算するために使用される規則の両方に関連した多くの不確実性を処理する。さらに、ファジー論理推理は、不正確/あいまいさ/重複/競合する入力ファジーを表す正式な構成論理を提供する。また、ファジー論理推理は、ユーザの相互作用の最小化を望むアプリケーションのために最良の推理および数個の優性度の高い候補を提供する。さらに、本明細書中で説明されたように、ファジー論理推理モデルが適応できる。言い換えれば、このモデルは、推論の複雑性の制御を可能にする。例えば、規則3~7の推論を拒否することは、お気に入りへの近接度、ロケーションの履歴、およびデフォルトのClosstStreetIntersectionのみを使用する簡単なモデルを提供する。一方で、規則は、地域情報等のさらなる情報を提供するように容易に微調整され得る。規則ベース706、および推論エンジン708は、同調して実行され得る最も簡単に開始する。さらにその処理は、入力がキャリアプロファイルデータベース228~230から取り出されることを可能にし、ロケーション情報がユーザの嗜好を推論しアプリケーションの挙動、コンテンツのフィルタリング等に影響を与えることを可能にする。キャリアプロファイルデータベース228~230の使用は、ユーザのプロファイルおよびロケーションに合わせられた、高度に個人化されたアプリケーションの提供を支援する。さらに、キャリアによって収集されるプロファイル情報の価値は、アプリケーション挙動の個人化にそれを使用することによって増大する。ファジー論理推理フロー図8は、本発明の1つ以上の実施形態による、デバイス204のロケーションを修正するためのファジー論理推理の使用を示すフローチャートである。ステップ800では、デバイス204のおよそのロケーションが決定される。ステップ802では、秩序化された規則の集合を含む規則ベース706がメモリに読み出されるかまたは例えば、データベース232のデータベースからロードされる。規則ベース706は、経時的に収集される経験的なデータに基づいて漸進的に修正され得る。さらに、規則ベース706は、推論が結果を生成しない場合に使用するデフォルト規則を特定し得る。さらに、規則ベース706は、それが地域動向、社会動向、または人口統計動向を反映するように構成され得るように、適応可能であり得る。このような適応可能性は、ユーザによって制御可能であり得、ユーザは、推理をカスタマイズ/個人化するために、規則ベースを追加、削除、および編集し得る。規則ベース706内にある規則は、1つ以上の条件を有する前件、およびその結果としての後件によって定義される。さらに、その前件は、論理演算結果を利用してもよいし、それを処理してもよい。ステップ804では、種々の不正確な入力/入力センサが捕捉される。上述のように、典型的には、3つのタイプの入力センサが使用される。すなわち、地域的、活動プロファイルベース、および時間ベースのタイプである。さらに、空間-時間的な入力が使用され得る。ステップ806では、その入力は、1つ以上のメンバーシップ関数で処理される。メンバーシップ関数は、規則内の各入力の参加の度合いを定義する。ファジー論理推理に従って、その参加の度合いは、0~10,1の間隔内に存在し得る。メンバーシップ関数は、各入力に対して3つの値のセットを定義し得る。このような3つの値のセットは、真の値、偽の値、および不確定な値それらの値は、間隔0,1に沿って定義されるを含み得る。ステップ808では、各規則に対して論理演算結果を生成するために、参加の度合いに基づいて、規則が入力に適用される。本発明のファジー論理推理を用いて、論理演算結果は、その後件の適用の可能性を表す、0~1の真の値を含み得る。その後件は、修正されたロケーション例えば、最も近いレジャーランドマーク、最も近い宿泊ランドマーク等を特定/説明する。従って、前件は、種々の入力の値を利用してメンバーシップ関数によって処理されるように、後件の真を表す論理演算結果を生成する。ステップ810では、修正されたロケーションがその論理演算結果に基づいて計算される。言い換えれば、種々の真の値/論理演算結果がステップ808において特定されたので、実際の修正されたロケーション重み付き重心104とも呼ばれるとしてどの後件を利用するかに関する決定がなされる。上述のように、論理演算結果に基づいて修正されたロケーションを計算する異なるメソッドが使用され得る。例えば、最大論理演算結果が選択され得、次いで、その修正されたロケーションを決定するために、それに対応する後件が選択/使用され得る。あるいは、平均例えば、2乗平均平方根計算がそのロケーションを修正するために使用され得る。例えば、論理演算結果が平均化され得、かつその平均に最も近い論理演算結果を有する後件が、修正されたロケーションとして選択され得る。あるいは、多くの異なる候補ロケーションが使用され得、これらのロケーションの全ての間にあるロケーションが提供され得る。しかし、修正されたロケーションまたは修正されたロケーションのリストを選択するために、任意の利用可能なメソッドが使用され得る。さらに、返される修正されたロケーションは、単一のものすなわち、単一の修正されたロケーションを含んでもよいし、ユーザが選択し得る候補ロケーションのリストを含んでもよい。外部データソースへの位置ベースサービスブリッジ上述のように、LBSアプリケーション210は、ユーザのプロファイル情報に基づいて特定のユーザに対して高度にカスタマイズされ得る。ユーザプロファイル情報は、リレーショナルデータベース、ポータル等において、ユーザごとに維持される任意のデータである。このようなユーザプロファイル情報が、ローカルに例えば、LBSデータベース232においてまたは外部に例えば、外部データソース228~230において格納され得る。従来技術では、外部プロファイル情報は、しばしば、LBSアプリケーション210のLBSデータベース232にリロードされ、それにより、コストの増大、同期化問題、データフォーマットの不一致、および問題のある非LBS認識データが生じる。例えば、ユーザプロファイル情報の多大な量がキャリアの外部データベース228~230に格納され得る。従来技術では、このようなプロファイル情報を利用するために、全ての情報がLBSサービスプロバイダのローカルデータベース232にコピーされる。しかし、キャリア226は、種々の理由のためにこのようなコピーを許容し得ない。このような問題を克服するために、本発明の1つ以上の実施形態は、外部プロファイルデータベース228~230へのコンパクトLBSブリッジを利用する。このLBSブリッジは、データが外部データベース228~230に残っていることを可能にするが、依然として、同じ、位置ベースサービスを提供し、そのデータを利用する。さらに、データがローカル/内部、または外部にあるのかは、なお、ユーザに対して透明であり、アプリケーション例えばロケーションサービスに対してシームレスである。LBSブリッジは、属性、タイプ、および制限の名前を含む外部データベース228~230のスキーマ234データリンクテーブルとも呼ばれるのコンパクトな定義を提供する。このスキーマ内部では、データソース情報例えば、どのようにして外部データベース228~230に接続し、それらと通信するのか、およびスキーマ234の記述に対応するデータソースから関連するプロパティを抽出するSQLstructuredquerylanguage選択ステートメントが提供される。さらに、SQLステートメントは、外部データベース228~230の、固有識別レコードのためのキーを識別する外部foreignキーカラム名前に関する情報を含む。位置ベースのサービスを提供するために使用されるさらなる情報は、ユーザプロファイルプロパティテーブルUPPTデータブリッジテーブルとも呼ばれるの形式でLBSデータベース232に格納され得る。UPPTテーブルは、ローカルに格納される既存のユーザプロファイル情報であってもよいし、外部データソース228~230にアクセスするために特別に作成されてもよい。通常、UPPTは、ローカルデータストア232から外部に格納される、空間的に認識しているユーザプロファイルアイテムに関する情報を維持する。外部データソース228~230の各レコードは、LBSデータベース232のUPPTのレコードのための外部キーを格納することによって識別される。さらに、各外部レコードに対する位置情報が獲得/抽出され、ジオコーディング/空間インデックスとしてUPPT内に格納されるそれにより、外部データベース228~230LBSをイネーブルにする。さらに、必要ならば、非座標位置情報例えば、テキストの道路アドレス、ランドマーク等が、ジオコーディング/空間インデックスを作成するためにジオコーディングされ、UPPTに格納される。従って、あるリンク/関係が、ローカルUPPTレコードと外部データベース228~230に格納されるレコード/アイテムとの間で確立される。このUPPTは、外部データソース228~230の各レコード、または外部データソース228~230のレコードのサブセットに対するレコードを含んでもよい。これらのサービスの集合は、システムインテグレータのために、外部API222の形式で利用可能にされる。このような外部API222はまた、ユーザプロファイルルマネージャと呼ばれ得る。一般的なLBSブリッジの結果として、LBSアプリケーション210は、無線キャリア230、電話会社228等によって蓄積される大量のプロファイル情報に拡張され得る。この拡張は、LBSサービスをより個人化し、エンドユーザにとってより価値があるものにする。図9は、本発明の1つ以上の実施形態による、外部データベース228~230のためのスキーマ234の構造を示す。上述のように、スキーマ定義234は、外部データソース228~230に関する情報を維持する。LBSアプリケーション210によって格納される各スキーマ234の定義は、外部データベース228~230の各オブジェクトについての記述を提供する。言い換えると、外部データベース228~230の各オブジェクトのために、対応するスキーマ234が存在する。例えば、外部データベース228~230のアドレスオブジェクトは、対応するスキーマ定義234を有する。さらに、オブジェクトの中の各フィールド/属性のために、対応する属性定義902がスキーマ234と共に格納される。例えば、アドレスオブジェクトは、名前、数、道路名、都市、州、およびジップzip等の複数のフィールド/属性を有する。各フィールド/属性に対して、スキーマ属性定義902がスキーマ234と共に格納される。スキーマ234の中のデータベース904のタイプすなわち、itemType:String;例えば、Addressは、外部データベース228~230のオブジェクトに対するタイプまたは名前を提供する。データソース情報906すなわち、jdbcDataSource:Stringは、どのようにして、外部データベース228~230に接続し、それと通信するかに関する情報を提供する。このような情報は、データベース228~230、そのロウrow、およびそのカラムcolumnを含むデータが存在するロケーションを完全に定義し得る。例えば、どのキャリア226が特定のデータベース228~230をホストしているのか、およびどのようにしてデータベース228~230と通信するのかに関する情報が格納される。上述のように、属性のリスト908がスキーマ234において説明される。各属性に対して、属性定義902は、属性の名前、属性のタイプ、および属性の制限を提供する。従って、各スキーマ234に対して、単一のリスト908は、複数の属性定義902にマッピングする。SQL選択ステートメント910例えば、WHERE節は、データソース228~230から関連するプロパティ例えば、ロウまたはレコードを抽出するためのコマンドを提供する。従って、スキーマ234は、外部データベース228~230のオブジェクトに対する全ての定義情報を含む。上述のように、API222ユーザプロファイルマネージャ1000とも呼ばれるは、スキーマ234の情報、およびスキーマ属性定義902の情報を維持するため、ならびに外部データベース228~230から詳細な情報すなわち、ユーザプロファイル情報にアクセス/取り出すために利用され得る。さらに、APIは、UPPTから特定のエントリを追加または削除する等、UPPTを保持するために利用され得る。さらに、UPPTを保持する場合であっても、データがローカルデータソースから来るのか、または外部データソース228~230から来るのかは、ユーザにとってなお透明なままである。図10は、本発明の1つ以上の実施形態による、ユーザプロファイルマネージャを示す。外部データベース228~230がアクセスされ得るようにスキーマ定義234をシステム200に追加するために、ユーザプロファイルマネージャ1000のinsertSchemaメソッド1002が利用され得る。アプリケーションプロバイダまたはキャリア226は、この目的のためにinsertSchemaメソッド1002を利用し得る。スキーマを追加するために、スキーマのためのスキーマ定義およびタイプ情報がユーザプロファイルマネージャ1000に提供される。一旦、スキーマ定義234がシステム200に追加された場合、スキーマ234の名前およびスキーマ情報が、外部アイテムタイプのスキーマ定義と呼ばれるスキーマ234のリストに追加される。表7は、本発明の1つ以上の実施形態による、すなわち、insertSchemaメソッド1002を用いてシステム200に追加されたスキーマ234に関する情報を含む外部アイテムタイプのスキーマ定義を示す。表7に示されるように、アドレスオブジェクト、カスタマーオブジェクト、およびtype_xxオブジェクトは全て、LBSアプリケーション210によって維持されるスキーマ定義234を有する。エントリを外部アイテムのタイプのスキーマ定義に追加するために、itemType904を特定しつつ、insertSchemaメソッド1002が使用され得る。上述のように、UPPTは、ローカルデータベース232から外部に格納される空間的に認識しているユーザプロファイルアイテムについての情報を維持する。UPPTで維持される個々のアイテムは、メソッド1004~1008を用いて位置づけられかつ維持され得る。例えば、アイテム/レコードについてのデータリンクをUPPTテーブルに設定するために、メソッド1004~1008の内の1つは、1つ以上の以下のパラメータユーザId、タイプ情報、アイテムについての名前、アイテムプロパティ値、オプションのジオコードされたロケーションを用いて利用され得る。位置ベースのサービスは、システム200によって提供されているので、メソッド1010~1014は、位置情報を利用する。しかし、外部データベース228~230内のオブジェクト/レコードは、イネーブルのLBSではない場合もある。例えば、ロケーション情報すなわち、空間/ジオコードインデックスは、オブジェクトに関連しない場合もある。にもかかわらず、外部データベース228~230内に格納されたほとんどのオブジェクトは、ロケーションのようなプロパティを有し得る。例えば、外部データベース228~230は、ホームアドレスの空間のロケーションを識別する空間インデックスではなく、携帯電話の加入者のホームアドレスを含み得る。メソッド1010~1014が位置情報を利用することを可能にするために、データベース228~230の各レコードに対する位置情報は、ユーザプロファイルマネージャ1000およびメソッド1004~1008を用いてLSBデータベース232内のUPPTに格納され得る。従って、UPPTの各レコードは、キーによって固有に識別され、そのレコードに対する位置情報をジオコードされた位置等の空間インデックスの形式で含む。本発明のシステム200を展開する場合、空間インデックスは、外部データベース228~230内の各オブジェクトの各レコードに対して獲得され得る。したがって、この空間インデックス情報は、各レコードを識別するためのキーと共にUPPTに格納される。あるいは、UPPT内の個々のアイテム/特徴/レコードが、所望される場合、適切な位置情報を用いて追加されてもよいし、削除されてもよい。モバイルデバイス204とは異なり、外部データソース228~230に格納される情報および関連した位置情報は、まれに変化する。したがって、UPPT内の情報の更新は、頻繁に発生する必要がなく、より長い間隔でスケジューリングされ得る。一旦、スキーマ定義がシステム200内で初期化され、UPPTが位置づけられると、ユーザプロファイルマネージャ1000は、外部データベース228~230から関連する情報を取り出すために利用され得る。メソッド1010~1014は、この情報を見つけ出し、かつ取り出すために利用され得る。表8は、本発明の1つ以上の実施形態による、ユーザプロファイルマネージャ1000によって作成されるユーザプロファイルプロパティテーブルを示す。表8の各ロウ/エントリは、外部データベース228~230内のアドレスオブジェクトのレコードを表す。メソッド1004~1008が、UPPTの部分レコードに対するロケーションプロパティおよび属性を設定するために利用され得るが、insertPropertyメソッド1016が、新しいエントリ例えば、アドレスエントリをUPPTに追加するために利用される。insertPropertyメソッド1016を用いて、すなわち、表7の外部アイテムタイプスキーマ定義において説明されたようにユーザIDが、誰がその情報を入力しているかを識別し、タイプフィールドが、入力されている情報のタイプを示す。ForeignKeyValueカラムは、外部データベース内の、そのユーザのための実際のアドレスデータのための外部キーを含む。しかし、本発明では、ユーザプロファイルプロパティテーブルにおけるアイテム値が0に設定される。なぜなら、データが外部データベース228~230に格納されるためである。従って、実際のアドレスデータは、UPPT内に格納されない。キーは、そのエントリのための固有の識別子を識別する。このようなキーは、ハッシュアルゴリズムを用いて設定されてもよいし、ユーザによって設定されてもよいし、カラム/プロパティの組み合わせであってもよいし、データベース228~230のオブジェクトのレコードを固有に識別し得る任意の他のメソッドを用いて設定されてもよい。例えば、表8では、キーは、ユーザの名前例えば、Raju、Scott、またはTimによって、エントリを固有に識別する。表8のジオメトリフィールドは、ジオコーディングインデックスとして格納される外部データベース228~230からの選択的な位置情報を含む。このような位置情報の使用は、外部データベース228~230のLBSをイネーブルにし、それにより、空間クエリが、データ上で実行されることを可能にする。上述のように、システム200が展開される場合、この位置情報が獲得され、データベース228~230のレコードから抽出され得る。その後、位置情報は、UPPTに格納される。従って、位置情報は、外部データベース228~230に格納される情報の位置を含む。例えば、ジオコードされるロケーションは、1つ以上のカスタマーのホームアドレスのロケーションを識別し得る。一旦獲得されると、UPPTにおけるロケーションは、次いで、高度にカスタマイズされたサービスを提供するためにLBSサービスによって使用され得る。例えば、特定のカスタマーのホームアドレスのジオコードされるロケーションを用いて、カスタマーが家に向かって移動する場合、カスタマーの家の近くのレストランが決定され得る。さらに、このようなレストランの電話番号および営業時間、または実際のホームアドレスに基づくレストランへの地図が、カスタマーに提供され得る。メソッド1010~1014およびUPPTを用いて、適切な追加のおよび所望の情報アイテムまたはフィーチャとも呼ばれるは、外部データベース228~230から獲得され得る。メソッド1010~1014は、例えば、findItems1010を用いて複数のアイテム/フィーチャ、例えば、findItemsClosestTo1012およびLocationを特定することを用いて特定のロケーションに最も近いアイテム/フィーチャ、または例えば、findItemsWithin1014および領域を識別するPolygonを特定することを用いて所定の定義された領域内のアイテム/フィーチャを見つけ出すために使用され得る。例えば、現在のユーザに最も近いアイテム/フィーチャを見つけ出すために、LBSアプリケーションは、findItemsClosestToメソッド1012を利用し、モバイルデバイス204にロケーションを提供する。次いで、メソッド1012は、最も近いロケーションを特定するためにUPPTジオメトリカラムを検討する。一旦適切なエントリが識別されると、エントリ内のキーが、外部データベース228~230中の適切なエントリを識別する。次いで、そのメソッドは、例えば、jdbcDataSourceのメソッド906を用いて外部データベース228~230とどのようにして通信するかを決定するため、および、すなわち、sqlSelect910を用いて情報を取り出すために使用する適切なSQL選択ステートメントを決定するためにスキーマ234にアクセスする。UPPTからのキーは、外部データベース228~230からのさらなるプロファイル情報を取り出すために、SQL選択ステートメントと共に使用される。同様に、findItemsWithinメソッド1014によって、ユーザは、エントリを見つけ出すべきポリゴンを特定し得る。そのメソッド1014は、特定されたポリゴン内部のロケーションの位置を特定するためにUPPTジオメトリプロパティを調べる。一旦適切なエントリが識別されると、適切なキーと共にsqlSelectステートメント910を用いて、さらなる情報が外部データベース228~230から取り出され得る。従って、複数のスキーマの定義234は、各外部データベース228~230の定義を説明する。ユーザプロファイル情報にアクセスするために、そのスキーマは、スキーマのリストに追加されるすなわち、外部アイテムタイプのスキーマ定義。初期化される場合、ユーザのプロファイル情報の部分が抽出され、ユーザプロファイルプロパティテーブルに格納される。APIを介して、例えば、標準クエリメカニズムを用いてクエリがデータを取り出すために実行され得る。データがローカルで利用可能である場合、単に取り出されるだけである。しかし、ローカルで利用不可能な、拡張されたプロパティは、スキーマ234およびUPPTからのデータを使用して、クエリ例えば、JDBC登録商標[Java登録商標DataBaseConnectivity]コールを発行することによって、内部に取り出される。JDBC登録商標コールは、ユーザが、Java登録商標プログラミング言語から任意のテーブル状のデータソースに仮想的にアクセスすることを可能にするAPIコールである。例えば、ユーザプロファイルプロパティマネージャは、UPPTにアクセスし、外部データベース228~230からさらなるユーザプロファイル情報を取り出すために利用され得る。ユーザプロファイルプロパティテーブルを使用することによって、実際の情報すなわち、アイテム情報は、外部データベース228~230に残っている。次いで、SQLステートメント910は、所望された場合、特定のデータソース906から情報を取り出すために使用され得る。さらに、UPPTにロケーション情報を格納することによって、位置ベースのサービスは、外部データベース228~230からユーザプロファイル情報の全てを取り出すことなく提供され得る。例えば、ロケーション情報がユーザのロケーションを識別する場合、ロケーション情報は、近くにある特定のロケーション例えば、ランドマーク等を取り出すために、findItemsClosestToメソッド1012において利用され得る。さらに、例えば、上述のようにロケータアダプタベースのシステムを用いてユーザのロケーションが既知であるために、既知のデバイスのロケーションは、カスタマイズされたサービスをユーザに提供するように、さらなるプロファイル情報の取り出しと組み合わせて使用され得る。従って、LBSブリッジは、無線キャリア、電話会社等によって蓄積された大量のプロファイル情報への位置ベースのサービスの拡張を可能にし、次いで、そのサービスをより個人化にし、かつエンドユーザにとって価値あるものにする。LBSブリッジの例ユーザが、LBSにイネーブルされたデータとは別にリレーショナルデータベース228~230に格納されるアドレスブック/コンタクトリストおよび他の情報、ならびに/あるいは、ローカルに格納されたユーザプロファイル情報を有する場合、LBSブリッジの使用の例が生じる。ユーザは、コンタクトリスト中のユーザのコンタクトの全てを、見ること、検索すること、位置確認することを望み得る。これらの能力を提供するためには、リンクが、ローカルに格納されたアイテムと外部データソース228~230のアイテムとの間にセットアップされる。このようなリンクは、ユーザプロファイルマネージャ1000を用いて確立され得る。アドレスブックアイテムのための空間エントリすなわち、ロケーション情報は、空間クエリをイネーブルするように明瞭に追加される必要があり得る。リンクの確立の後、アイテムは、ユーザプロファイルプロパティテーブル中のロウである。ロウにアクセスするために、ユーザidログインID、アイテムタイプ例えば、adressList1、およびアイテムID例えば、友人1が使用され得る。外部データソースアイテムは、外部データソース中のロウに残っている。外部データソースのロウにアクセスするために、例えば、JDBC登録商標データソースを識別する外部データソース名、例えば、データソースからロウを抽出するSQL選択ステートメントが必要であり、これらはすべてスキーマ定義134に格納される。222APIを使用することによって、全てのリソースのリレーショナルおよび空間クエリが実行され得る。APIが利用されるので、データがローカルデータソースから例えば、LBSデータベース232内から来るのか、またはデータが外部データソース228~230から来るのかはユーザにとって透明である。このシステムを用いる際、ユーザは、スキーマおよびデータリンクの管理、各レコードに対する空間情報を含むユーザプロファイルプロパティテーブルの位置づけ、および必要な場合は空間情報の更新に対し責任を負い得る。LBSブリッジフロー図11は、本発明の1つ以上の実施形態に従った、外部データソースへのLBSブリッジの利用を示すフローチャートである。ステップ1100において、スキーマ定義234は、システム200に挿入される。スキーマ定義234は、システム200の外部データベース228~230を利用することを望む通信事業者226または任意の他のパーティによって挿入され得る。上述されるように、スキーマ定義は、1つ以上のスキーマ属性、実行時に外部データベース228~230からプロパティを抽出するSQL選択文、および、外部データベースと接続および通信する方法を記述するデータソース情報を含む。該スキーマ定義の挿入はまた、ステップ1102においてスキーマ234リスト外部アイテムタイプスキーマ定義と呼ばれるの生成を含み得る。このようなスキーマ234リストは、スキーマ234情報/定義ならびにスキーマ234のネームまたはリファレンスを有するテーブルを含む。ステップ1104において、システムのLBSブリッジは、展開/開始される。システムの展開は、ステップ1106において外部データベース228~230スキーマ定義234によって表現されるのデータの各レコードについて、位置情報を取得することを含む。各レコードについての取得した位置情報およびキーは、その後、ステップ1108のLBSデータベース232内のUPPTにローカルに格納される。ステップ1110において、外部データベース228~230の情報にアクセスするためにブリッジを利用するためのAPIが、提供される。情報にアクセスするために、APIのメソッドが利用される。メソッドは、UPPTを評価して、UPPT内に格納される位置情報に基づいて取り出すべき適切なレコードを決定する。適切なレコード単数または複数のキーは、その後、外部データベース228~230からより詳細なプロファイル情報を取り出すために利用される。メソッドは、データソース情報およびSQL選択文を含むスキーマ定義234からのこのような情報と通信し、かつ、これらを取り出す方法を知っている。結論これで、本発明の好ましい実施形態の説明を終わる。以下は、本発明を達成するいくつかの別の実施形態を含む。例えば、メインフレーム、ミニコンピュータ、またはパーソナルコンピュータ等の任意のタイプのコンピュータ、あるいは、タイムシェアリングメインフレーム、ローカルエリアネットワーク、またはスタンドアローンパーソナルコンピュタ等のコンピュータ構成、あるいは、セルラーフォン、ラップトップコンピュータ、パーソナルデジタルアシスタント等の任意のタイプのモバイルデバイスが、本発明とともに利用され得る。本発明の好ましい実施形態の以下の説明は、図示および説明のために提示された。網羅的であること、または、開示された正確な形式に本発明を限定することは意図されない。多くの改変および変更が、上述の教示を理解することから可能である。本発明の範囲は、この詳細な説明ではなく、添付の特許請求の範囲によって制限されることが意図される。"