(57)【要約】  位置情報サービスを実施するための方法、装置、およびシステムが開示される。この方法は、ターゲット位置情報を含む位置決め要求を受信した後に、ターゲットグリッドを決定するステップを含む。ターゲットグリッドは、ターゲット位置情報に対応するグリッドと、ターゲット位置情報に対応するグリッドから離れた設定範囲内の距離に位置するグリッドとを含み、これらグリッドは、マップを正方形に分割することによって取得される。また、この方法は、ターゲットグリッドが属する位置情報サービス記憶デバイスを決定し、この位置におけるデータ記憶を実行し、決定された位置に、ターゲットグリッドに対応する端末情報を問い合わせる。
2017511066.tif 000002
【特許請求の範囲】
【請求項１】
位置情報サービスを実施するための方法であって、
ターゲット位置情報を含む位置決め要求を受信するステップと、
ターゲットグリッドを決定するステップであって、前記ターゲットグリッドは、前記ターゲット位置情報に対応するグリッドと、前記ターゲット位置情報に対応する前記グリッドから離れた設定範囲内の距離に位置するグリッドとを含み、これらグリッドは、マップを正方形に分割することによって取得される、ステップと、
前記ターゲットグリッドが属する位置情報サービス記憶デバイスを決定するステップと、
キーワードとしてグリッド番号を使用し、値として端末情報を使用することによって、前記位置情報サービス記憶デバイスにおけるデータ記憶を実行するステップであって、各位置情報サービス記憶デバイスにおける記憶の最小粒度は、前記グリッドに対応する正方形の側面長さのM倍であり、Mは2以上である、ステップと、
前記ターゲットグリッドに対応する端末情報を、決定された前記位置情報サービス記憶デバイスに問い合わせるステップと、
問い合わせた前記端末情報を、前記位置決め要求の送信元に送信するステップと
を有する方法。
【請求項２】
端末によってレポートされた位置情報および端末情報を受信し、前記位置情報が属するグリッドを決定し、決定された前記グリッドが属する位置情報サービス記憶デバイスを決定するステップと、
前記端末によってレポートされた前記位置情報および端末情報を、記憶のために、決定された前記位置情報サービス記憶デバイスに送信するステップと
をさらに有する、請求項1に記載の方法。
【請求項３】
データ記憶はまた、キーワードとして端末情報を使用し、値としてグリッド番号を使用することによって、位置情報サービス記憶デバイスにおいて実行され、
前記方法は、
記憶された前記端末情報に対応する位置情報を消去するように、位置情報を消去するための命令を、決定された前記位置情報サービス記憶デバイス以外の位置情報サービス記憶デバイスに送信するステップをさらに有する、請求項2に記載の方法。
【請求項４】
前記グリッドは、マップを正方形に分割することによって取得され、地理的位置のシーケンスに従って付番され、
位置情報サービス記憶デバイスにおける最小粒度のグリッドと、位置情報サービス記憶デバイスとの対応性は、ハッシュアルゴリズムのルールに従い、
前記ターゲットグリッドが属する位置情報サービス記憶デバイスを決定する前記ステップは、前記ターゲットグリッドが属する位置情報サービス記憶デバイスを決定するように、前記ターゲットグリッドを使用してハッシュ探索を実行するステップを含む、請求項1に記載の方法。
【請求項５】
前記ターゲットグリッドが2つ以上の位置情報サービス記憶デバイスに分散されている場合、
前記位置情報サービス記憶デバイスに問い合わせた前記端末情報のパケット組立てを実行するステップをさらに有する、請求項4に記載の方法。
【請求項６】
端末から別の位置決め要求が受信される場合、
前回の位置決め要求後の時間インターバルが所定のしきい値を超えているか否かを判定し、前記時間インターバルが前記所定のしきい値を超えている場合に、位置決めの実行を拒否するステップをさらに有する、請求項1に記載の方法。
【請求項７】
ターゲットグリッドを決定する前記ステップは、
先ず、試験グリッドに、端末情報を含む試験グリッドを問い合わせるステップであって、前記試験グリッドは、前記ターゲット位置情報に対応する試験グリッドであり、前記試験グリッドは、マップを、前記グリッドの側面長さよりも長い側面長さを有する正方形に分割することによって取得される、ステップと、
問い合わせた前記試験グリッドに含まれるグリッドが前記ターゲットグリッドであると決定するステップと
を含む、請求項1に記載の方法。
【請求項８】
位置決めサーバであって、
ターゲット位置情報を含む位置決め要求を受信した後に、ターゲットグリッドを決定するように構成されたグリッド決定ユニットであって、前記ターゲットグリッドは、前記ターゲット位置情報に対応するグリッドと、前記ターゲット位置情報に対応する前記グリッドから離れた設定範囲内の距離に位置するグリッドとを含み、これらグリッドは、マップを正方形に分割することによって取得される、グリッド決定ユニットと、
ターゲットグリッドが属する位置情報サービス記憶デバイスを決定するように構成されたデバイス決定ユニットであって、データ記憶は、キーワードとしてグリッド番号を使用し、値として端末情報を使用することによって、前記位置情報サービス記憶デバイスにおいて実行され、各位置情報サービス記憶デバイスにおける記憶の最小粒度は、前記グリッドに対応する正方形の側面長さのM倍であり、Mは2以上である、デバイス決定ユニットと、
決定された前記位置情報サービス記憶デバイスに、前記ターゲットグリッドに対応する端末情報を問い合わせるように構成された問合せユニットと、
問い合わせた前記端末情報を、前記位置決め要求の送信元に送信するように構成された情報送信ユニットと
を備える位置決めサーバ。
【請求項９】
端末によってレポートされた位置情報および端末情報を受信するように構成された情報受信ユニットをさらに備える、請求項8に記載の位置決めサーバ。
【請求項１０】
前記グリッド決定ユニットが、前記位置情報が属するグリッドを決定するようにさらに構成される、請求項9に記載の位置決めサーバ。
【請求項１１】
前記デバイス決定ユニットが、前記グリッド決定ユニットによって決定された前記グリッドが属する位置情報サービス記憶デバイスを決定するようにさらに構成される、請求項10に記載の位置決めサーバ。
【請求項１２】
前記情報送信ユニットが、前記端末によってレポートされた位置情報および端末情報を、記憶のために、決定された前記位置情報サービス記憶デバイスに送信するようにさらに構成される、請求項11に記載の位置決めサーバ。
【請求項１３】
データ記憶はまた、キーワードとして端末情報を使用し、値としてグリッド番号を使用することによって、位置情報サービス記憶デバイスにおいて実行され、
前記情報送信ユニットが、記憶された前記端末情報に対応する位置情報を消去するように、位置情報を消去するための命令を、決定された前記位置情報サービス記憶デバイス以外の位置情報サービス記憶デバイスに送信するようにさらに構成される、請求項9に記載の位置決めサーバ。
【請求項１４】
前記グリッドは、マップを正方形に分割することによって取得され、地理的位置のシーケンスに従って付番され、
位置情報サービス記憶デバイスにおける最小粒度のグリッドと、位置情報サービス記憶デバイスとの対応性は、ハッシュアルゴリズムのルールに従い、
前記デバイス決定ユニットが、前記ターゲットグリッドが属する位置情報サービス記憶デバイスを決定するように、前記ターゲットグリッドを使用してハッシュ探索を実行するようにさらに構成される、請求項8に記載の位置決めサーバ。
【請求項１５】
前記ターゲットグリッドが2つ以上の位置情報サービス記憶デバイスに分散されている場合、
前記位置決めサーバは、
前記位置情報サービス記憶デバイスに問い合わせた前記端末情報のパケット組立てを実行するように構成されたパケット組立てユニットと、
前記パケット組立てユニットのパケット組立て結果を、前記位置決め要求の送信元に送信するように構成された前記情報送信ユニットと
を備える、請求項14に記載の位置決めサーバ。
【請求項１６】
端末から別の位置決め要求が受信される場合、前回の位置決め要求後の時間インターバルが所定のしきい値を超えているか否かを判定し、前記時間インターバルが、前記所定のしきい値を超えている場合に、位置決めの実行を拒否するように構成された位置決め制御ユニットをさらに備える、請求項8に記載の位置決めサーバ。
【請求項１７】
前記グリッド決定ユニットが、先ず、試験グリッドに、端末情報を含む試験グリッドを問い合わせるようにさらに構成され、
前記試験グリッドは、前記ターゲット位置情報に対応する試験グリッドであり、
前記試験グリッドは、マップを、前記グリッドの側面長さよりも長い側面長さを有する正方形に分割することによって取得され、
前記グリッド決定ユニットが、問い合わせた前記試験グリッドに含まれるグリッドが前記ターゲットグリッドであると判定するようにさらに構成される、請求項8に記載の位置決めサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、通信技術の分野に関し、特に、位置情報サービスを実施するための方法、装置、およびシステムに関する。
【背景技術】
【０００２】
位置決めサービスとも称される位置情報サービス(Location Based Service，LBS)は、位置決め技術の集合を使用することによってモバイル端末の位置情報(たとえば、経度および緯度座標データ)を取得するため、および、モバイルユーザ、他の人、または通信システムのための位置情報を提供するために、モバイル通信ネットワークとグローバル位置決めシステムとを組み合わせることによって提供される一種の付加価値サービスであり、これによって、様々な位置関連サービスを実施する。本質的に、位置情報サービスは、広い概念を有し、空間的な位置に関連している、一種の新たなサービスビジネスである。
【０００３】
位置情報サービスは、健康、仕事、および私生活のような異なる分野に適用され得る。サービスは、たとえば、最も近いATMの位置、または、友人または同僚の現在の位置を決定し、クライアントの現在の位置に従って、ダイレクトなモバイル電話広告、個別化された天気情報、および、ローカル化されたゲームまでも提供するように、人または物体の位置を特定するために使用され得る。
【０００４】
現在、地理的位置情報は、経度および緯度を使用することによって表現され、記憶される。これによって、端末の場所は、精度の利点によって、便利に決定され得るようになる。しかしながら、近傍の端末の位置決め処理中、経度および緯度を使用することによる距離の計算の計算量は大きい。したがって、位置決めサーバの応答速度は、非常に遅くなる。
【発明の概要】
【課題を解決するための手段】
【０００５】
本発明の一実施態様は、位置情報サービスを実施するための方法を提供し、この方法は、
ターゲット位置情報を含む位置決め要求を受信した後に、ターゲットグリッドを決定するステップであって、ターゲットグリッドは、ターゲット位置情報に対応するグリッドと、ターゲット位置情報に対応するグリッドから離れた設定範囲内の距離に位置するグリッドとを含み、これらグリッドは、マップを正方形に分割することによって取得される、ステップと、
ターゲットグリッドが属する位置情報サービス記憶デバイスを決定し、キーワードとしてグリッド番号を使用し、値として端末情報を使用することによって、位置情報サービス記憶デバイスにおけるデータ記憶を実行するステップであって、各位置情報サービス記憶デバイスにおける記憶の最小粒度は、グリッドに対応する正方形の側面長さのM倍であり、Mは2以上である、ステップと、
決定された位置情報サービス記憶デバイスに、ターゲットグリッドに対応する端末情報を問い合わせ、問い合わせた端末情報を、位置決め要求の送信元に送信するステップとを有する。
【０００６】
本発明の一実施態様は、位置決めサーバをさらに提供し、この位置決めサーバは、
ターゲット位置情報を含む位置決め要求を受信した後に、ターゲットグリッドを決定するように構成されたグリッド決定ユニットであって、ターゲットグリッドは、ターゲット位置情報に対応するグリッドと、ターゲット位置情報に対応するグリッドから離れた設定範囲内の距離に位置するグリッドとを含み、これらグリッドは、マップを正方形に分割することによって取得される、グリッド決定ユニットと、
ターゲットグリッドが属する位置情報サービス記憶デバイスを決定するように構成されたデバイス決定ユニットであって、データ記憶は、キーワードとしてグリッド番号を使用し、値として端末情報を使用することによって、位置情報サービス記憶デバイスにおいて実行され、各位置情報サービス記憶デバイスにおける記憶の最小粒度は、グリッドに対応する正方形の側面長さのM倍であり、Mは2以上である、デバイス決定ユニットと、
決定された位置情報サービス記憶デバイスに、ターゲットグリッドに対応する端末情報を問い合わせるように構成された問合せユニットと、
問い合わせた端末情報を、位置決め要求の送信元に送信するように構成された情報送信ユニットとを備える。
【０００７】
本発明の実施形態における技術的解決策をより明確に記述するために、以下では、実施形態を記述するために必要とされる添付図面を簡潔に紹介する。当然ながら、以下の記述における添付図面は、本発明のいくつかの実施形態だけを図示するのであって、当業者は、創造的な労力なしに、これら添付図面から他の図面をさらに導出し得る。
【図面の簡単な説明】
【０００８】
【図１】既存の技術に従うシステムの概略的な構成図である。
【図２】本発明の一実施形態に従う方法の概略的なフローチャートである。
【図３】本発明の一実施形態に従う方法の概略的なフローチャートである。
【図４】本発明の一実施形態に従うシステムの概略的な構成図である。
【図５】本発明の一実施形態に従う空間データモデルの概略図である。
【図６】本発明の一実施形態に従うグリッド分割の概略図である。
【図７】本発明の一実施形態に従うグリッド探索の概略図である。
【図８】本発明の一実施形態に従うデータ記憶の概略図である。
【図９】本発明の一実施形態に従ってプレーヤの地理的情報をレポートするための方法の概略的なフローチャートである。
【図１０】本発明の一実施形態に従って情報を記憶および消去するためのシステムの概略的な構成図である。
【図１１】本発明の一実施形態に従ってplayerID 3を消去するためのデータ探索処理の概略図である。
【図１２】本発明の一実施形態に従うハッシュテーブルの概略的な構成図である。
【図１３】本発明の一実施形態に従うplayerIDからGridGIDへの逆インデックスの概略的な構成図である。
【図１４】本発明の一実施形態に従うバケットベースの規則的クリーニングの概略図である。
【図１５】本発明の一実施形態に従う位置決めサーバの概略的な構成図である。
【図１６】本発明の一実施形態に従う位置決めサーバの概略的な構成図である。
【図１７】本発明の一実施形態に従う位置決めサーバの概略的な構成図である。
【図１８】本発明の一実施形態に従う位置決めサーバの概略的な構成図である。
【図１９】本発明の一実施形態に従う位置情報サービス記憶デバイスの概略的な構成図である。
【図２０】本発明の一実施形態に従う位置情報サービス記憶デバイスの概略的な構成図である。
【図２１】本発明の一実施形態に従う位置情報サービス記憶デバイスの概略的な構成図である。
【図２２】本発明の一実施形態に従う位置情報サービス記憶デバイスの概略的な構成図である。
【図２３】本発明の一実施形態に従う位置情報サービスシステムの概略的な構成図である。
【図２４】本発明の一実施形態に従うサーバの概略的な構成図である。
【発明を実施するための形態】
【０００９】
本開示の目的、技術的解決策、および利点をより明確にするために、以下では、添付図面を参照してより詳細に本開示を記述する。当然ながら、記述された実施形態は、本発明の実施形態のうちのいくつかに過ぎず、これら実施形態のすべてではない。創造的な労力なしに本発明の実施形態に基づいて当業者によって得られるその他すべての実施形態は、本開示の保護範囲内にあるものとする。
【００１０】
現在、消費者の個人的な要求の知的情報化に基づいて、位置情報サービスを求める要求が、位置決め技術およびワイヤレスネットワークアクセス技術の発展によって、大きなマージンで増加傾向を示している。LBSは、企業の運用およびサービスレベルを向上し得るのみならず、車両に搭載された位置決め技術の、ユーザのためのより多様化された便利なサービスをも提供し得る。位置決め技術のユーザのために、アドレスポイントのナビゲーションから、興味のあるポイントのサービスまで、および、リアルタイムの道路状況に関する技術の適用まで、位置情報サービスは、ユーザが近くの製品およびサービスを発見することを導くのみならず、ユーザに、より高い利便性および安全性を提供し得る。
【００１１】
現在、位置情報サービスは、車両に搭載された位置決め技術製品に適用されている。LBSアプリケーションを深化させて行く過程中に、インタラクションが車両搭載ナビゲーションに統合されたアイデアが、位置決め技術市場から理解されている。フォトナビゲーションおよび目的マップのようなユニークな機能モジュールの増加および拡張によって、ユーザは、最新の個別化されたナビゲーションサービスを楽しんだり、ナビゲーション機器を使用することによって世界中の有名な観光地、ホテル、レストラン、ガソリンスタンド等に関する豊富な情報をダイレクトに問い合わせたり、ワンキーナビゲーションを達成したりすることが可能になったのみならず、ユーザは、ネットワークに基づいてデータをダウンロードおよびアップロードしたり、他のユーザとのインタラクションおよび通信を達成したりすることも可能となった。これらは、将来における、発展方向の1つになるであろう。それに加えて、位置決め技術の使用はまた、個人ユーザまたはグループユーザに、特別な情報および警戒サービスをも提供し得る。たとえば、社会活動を実行するため近くの人を探索する、または、(たとえば、同じ趣味を持つ、同じゲームをプレイする等)関連付けられている近くの人を探索する等、近くのユーザを探索する際に、端末ユーザによって、位置決めサーバも使用されている。
【００１２】
既存の位置情報サービスシステムは一般に、図1に図示されているような構造を採用している。ここでは、位置決めサーバが、端末から地理的位置情報を受信し、この地理的位置情報を、第1乃至第nの位置情報サービス記憶デバイスに記憶する。位置決めサーバが、地理的位置情報を解析する必要があるのであれば、位置決めサーバはまた、この地理的位置情報を、マップサーバに送信し、マップサーバから、地理的位置情報の解析結果を取得し得る。既存の位置では、地理的位置情報は、経度と緯度とを使用することによって表現され、記憶される。しかしながら、近傍の端末の位置決め処理中、経度と緯度とを使用することによって距離を計算する計算量は膨大であり、したがって、位置決めサーバの応答速度は非常に遅くなる。
【００１３】
これを考慮して、本発明の一実施形態は、位置情報サービスを実施するための方法を提供する。図2に図示されるように、この方法は、以下を含む。
【００１４】
ステップ201:ターゲット位置情報を含む位置決め要求を受信した後に、ターゲットグリッドを決定する。ターゲットグリッドは、ターゲット位置情報に対応するグリッドと、ターゲット位置情報に対応するグリッドから離れた設定範囲内の距離に位置するグリッドとを含み、これらグリッドは、マップを正方形に分割することによって取得される。
【００１５】
本発明のこの実施形態では、グリッドは、マップを分割することによって取得される。つまり、グリッドは、実際の地理的位置に対応している。実際、グリッドの側面長さは、グリッドに対応する地理的位置の側面長さである。グリッドの側面長さがより短くなれば、最終的な位置決めの精度はより高くなるであろう。また、グリッドの側面長さがより長くなれば、記憶されるグリッドの数はより少なくなり、探索に使用される時間はより短くなり得る。本発明のこの実施形態において、具体的な長さは限定されず、100mが側面長さとして推奨され得る。
【００１６】
ステップ202:ターゲットグリッドが属する位置情報サービス記憶デバイスを決定し、キーワードとしてグリッド番号を使用し、値として端末情報を使用することによって、位置情報サービス記憶デバイスにおけるデータ記憶を実行する。各位置情報サービス記憶デバイスにおける記憶の最小粒度は、グリッドに対応する正方形の側面長さのM倍であり、Mは2以上である。
【００１７】
Mの具体的な値は、本明細書において、当業者によって設定され得る。2kmである最大範囲内の周囲の端末情報が探索されているのであれば、この値は、100、50等に設定され得、その具体的な値は、本発明のこの実施形態では限定されない。
【００１８】
ステップ203:決定された位置情報サービス記憶デバイスに、ターゲットグリッドに対応する端末情報を問い合わせ、問い合わせた端末情報を、位置決め要求の送信元に送信する。
【００１９】
本発明のこの実施形態では、地理的位置は、グリッド方式で分割され、分割後に取得されたグリッドは、位置情報の記憶のために使用され、位置情報サービスの処理中、計算量を低減するように、経度と緯度とは、距離を計算するために必要とされず、したがって、サーバ応答速度を向上させる。それに加えて、グリッドが位置情報サービス記憶デバイスに割り当てられた場合、使用される最小粒度は、グリッドよりも大きい。これによって、より多くの隣接グリッドが同じ位置情報サービス記憶デバイスに割り当てられるようになり、決定されたターゲットグリッドは、少数の位置情報サービス記憶デバイスに集中するようになる。したがって、位置情報サービス記憶デバイスの呼び出しを減らし、位置情報サービス記憶デバイスの計算負荷を低下させ、これに伴って、位置情報サービス全体のシステムパフォーマンスをさらに向上させる。それに加えて、位置決め精度を高め、単一のグリッドの著しく大量の位置情報によって引き起こされる衝突を低減するように、グリッドのサイズが小さくなるように設定され得る。
【００２０】
本発明のこの実施形態では、位置情報サービス記憶デバイスにおける位置情報は、別のサーバによって収集された情報をソースとし得、位置決めサーバによってダイレクトに収集された情報をもソースとし得る。本発明の一実施形態は、端末の位置情報を取得し記憶するための具体的な実施解決策を提供する。詳細は以下の通りである。さらに、方法はまた、
端末によってレポートされた位置情報および端末情報を受信し、位置情報が属するグリッドを決定し、決定されたグリッドが属する位置情報サービス記憶デバイスを決定するステップと、
端末によってレポートされた位置情報および端末情報を、記憶のために、決定された位置情報サービス記憶デバイスに送信するステップと、を含む。
【００２１】
本発明の一実施形態は、好適な記憶解決策をさらに提供する。それは、記憶されたデータのオーバレイおよび後続するデータ衝突の状態を回避し得る。詳細は以下の通りである。データ記憶はまた、キーワードとして端末情報を使用し、値としてグリッド番号を使用することによって、位置情報サービス記憶デバイスにおいて実行される。この方法は、
記憶された端末情報に対応する位置情報を消去するように、位置情報を消去するための命令を、決定された位置情報サービス記憶デバイス以外の位置情報サービス記憶デバイスに送信するステップをさらに含む。
【００２２】
本発明のこの実施形態では、位置情報を消去するための命令は、決定された位置情報サービス記憶デバイス以外の位置情報サービス記憶デバイスに送信される。具体的な送信解決策は、端末の位置情報の独自性をサーバ側において維持するように、ブロードキャスト方式を採用し得る。
【００２３】
本発明のこの実施形態では、問合せ中の問合せ速度を向上させ、さらに、位置情報サービス記憶デバイスのその後の拡張を容易にするように、分割後にグリッドが付番され、その後、これらグリッドを位置情報サービス記憶デバイスに割り当てるために、ハッシュアルゴリズムが採用される。具体的には、これらグリッドは、マップを正方形に分割することによって取得され、地理的位置のシーケンスに従って付番される。そして、位置情報サービス記憶デバイスにおける最小粒度のすべてのグリッドと、位置情報サービス記憶デバイスとの間の対応性は、ハッシュアルゴリズムのルールに従う。
【００２４】
ターゲットグリッドが属する位置情報サービス記憶デバイスを決定するステップは、ターゲットグリッドが属する位置情報サービス記憶デバイスを決定するように、ハッシュ探索を実行するためにターゲットグリッドを使用するステップを含む。
【００２５】
本発明のこの実施形態では、位置情報サービス記憶デバイスの呼び出しは低減され得るが、1つの位置情報サービス記憶デバイスにおいて位置決めサーバの機能が完了され得ることを保証することはできない。したがって、ターゲットグリッドは、複数の位置情報サービス記憶デバイス内に分散される可能性があり、これに基づいて、本発明の一実施形態は、以下のようなさらなる実施解決策を提供する。さらに、ターゲットグリッドが、2つ以上の位置情報サービス記憶デバイス内に分散されているのであれば、方法は、位置情報サービス記憶デバイスに問い合わせた端末情報のパケット組立てを実行するステップをさらに含む。
【００２６】
端末ユーザが端末を使用することによって連続的に位置決め要求を送信し得るので、各位置決め要求が位置決めとともに処理されるのであれば、大きな負荷がサーバにもたらされるであろう。さらに、時間インターバルが非常に短いのであれば、位置決め結果は、一般に、めったに変更されない。したがって、そのような頻繁な位置決めは必要ではない。サーバの負荷を低下させ、かつ不必要な位置決め演算を低減するために、本発明の一実施形態は、以下のような解決策を提供する。端末から別の位置決め要求が受信されると、この方法は、前回の位置決め要求後の時間インターバルが、あらかじめ決定されたしきい値を超えたか否かを判定するステップと、時間インターバルがあらかじめ決定されたしきい値を超えているのであれば、位置決めの実行を拒否するステップと、をさらに含む。
【００２７】
本発明のこの実施形態では、マップがグリッドに分割される。グリッドの側面長さがより短くなれば、位置決め精度はより高くなるが、計算量がより多くなり、グリッドの側面長さがより長くなれば、計算量はより少なくなり、応答速度はより速くなる。両方の利点を組み合わせるために、本発明の一実施形態は、以下のような解決策を提供する。ターゲットグリッドを決定するステップは、先ず、試験グリッド内の、端末情報を含む試験グリッドを問い合わせるステップであって、試験グリッドは、ターゲット位置情報に対応する試験グリッドであり、試験グリッドは、グリッドの側面長さよりも長い側面長さを有する正方形にマップを分割することによって取得される、問い合わせるステップと、問い合わせた試験グリッドに含まれるグリッドが、ターゲットグリッドであると判定するステップと、を含む。
【００２８】
本発明のこの実施形態では、試験グリッドの側面長さはより長く、これによって、大きなグリッドは、先ず、ターゲットグリッド内の、位置情報のないグリッドをフィルタアウトし、不必要な探索を回避するために使用され得る。したがって、探索量を低減し、システム応答速度を向上させる。
【００２９】
本発明の一実施形態は、図3に図示されるような位置情報サービスを実施するための別の方法をさらに提供する。この方法は以下を含む。
【００３０】
ステップ301:位置情報サービス記憶デバイスによって、位置決めサーバから、問合せ要求を受信する。問合せ要求は、問合せ対象のターゲットグリッドを含む。データ記憶は、キーワードとしてグリッド番号を使用し、値として端末情報を使用することによって、位置情報サービス記憶デバイスにおいて実行される。各位置情報サービス記憶デバイスにおける記憶の最小粒度は、グリッドに対応する正方形の側面長さのM倍であり、Mは2以上であり、これらグリッドは、マップを正方形に分割することによって取得される。
【００３１】
本発明のこの実施形態では、グリッドはマップを分割することによって取得される。すなわち、グリッドは、実際の地理的位置に対応している。実際、グリッドの側面長さは、グリッドに対応する地理的位置の側面長さである。グリッドの側面長さがより短くなれば、最終的な位置決めの精度はより高くなるであろう。また、グリッドの側面長さがより長くなれば、記憶されるグリッドの数はより少なくなり、探索に使用される時間はより短くなり得る。本発明のこの実施形態において、具体的な長さは限定されず、100mが側面長さとして推奨され得る。
【００３２】
Mの具体的な値は、本明細書において、当業者によって設定され得る。2kmである最大範囲内の周囲の端末情報が探索されているのであれば、この値は、100、50等に設定され得、その具体的な値は、本発明のこの実施形態では限定されない。
【００３３】
選択的に、本発明の一実施形態は、位置情報サービス記憶デバイスにおけるグリッドの分散と、グリッド内のデータ記憶とのために、以下のような具体的な実施解決策をさらに提供する。位置情報サービス記憶デバイスに記憶された多くのグリッドは、ハッシュアルゴリズムのルールに従って記憶され、ハッシュバケットを使用することによってシーケンス化される。
【００３４】
ステップ302:ターゲットグリッドの番号を使用することによって問合せを行い、問合せ対象のターゲットグリッドに対応する端末情報を取得する。
【００３５】
ステップ303:取得された端末情報を、位置決めサーバに送信する。
【００３６】
本発明のこの実施形態では、地理的位置は、グリッド方式で分割され、分割後に取得されるグリッドは、位置情報の記憶のために使用され、位置情報サービスの処理中、計算量を低減するように、経度と緯度とは、距離を計算するために必要とされず、したがって、サーバ応答速度を向上させる。それに加えて、グリッドが位置情報サービス記憶デバイスに割り当てられた場合、使用される最小粒度は、グリッドよりも大きくなる。これによって、より多くの隣接グリッドが同じ位置情報サービス記憶デバイスに割り当てられるようになり、決定されたターゲットグリッドは、少数の位置情報サービス記憶デバイスに集中するようになる。したがって、位置情報サービス記憶デバイスの呼び出しを減らし、位置情報サービス記憶デバイスの計算負荷を下げ、これによって、位置情報サービス全体のシステムパフォーマンスを向上させる。それに加えて、位置決め精度を高め、単一のグリッドの著しく大量の位置情報によって引き起こされる衝突を低減するように、グリッドのサイズが小さくなるように設定され得る。
【００３７】
本発明のこの実施形態では、位置情報サービス記憶デバイスにおける位置情報は、別のサーバによって収集された情報をソースとし得、位置決めサーバによってダイレクトに収集された情報をもソースとし得る。本発明の一実施形態は、端末の位置情報を取得し、記憶するための具体的な実施解決策を提供し、さらに、位置情報の独自性を維持するための具体的な実施解決策を提供する。詳細は以下の通りである。さらに、方法はまた、
位置決めサーバによって送信された端末情報および位置情報を受信し、端末情報に対応する位置情報が存在しているか否かを判定するために探索し、存在しているのであれば、位置情報を消去するステップと、
位置情報が存在していないか、または、完全に消去されているのであれば、端末情報を、位置情報に対応するグリッドに記憶し、ハッシュテーブルを使用することによって位置情報を記憶するステップと、を含む。
【００３８】
本発明の一実施形態は、位置情報を記憶するための具体的な解決策をさらに提供する。本発明のこの実施形態では、位置情報は、リンクリストの先頭に挿入することによって記憶される。これによって、位置情報は、時間シーケンスで記憶され得るようになり、したがって、無効なデータの後続する消去を容易にする。詳細は以下の通りである。選択的に、ハッシュテーブル値は、リンクリストのデータ構造を採用し、端末情報を位置情報に対応するグリッドに記憶するステップは、位置情報をリンクリストの先頭に挿入することによって、位置情報に対応するグリッドのリンクリストに挿入するステップを含む。
【００３９】
端末の位置情報(地理的情報)は、タイムリミットを有するので、端末の位置情報は、端末の地理的位置が変化すると、無効になり得る。その結果、位置情報サービス記憶デバイスに記憶された位置情報のために、期限切れになった位置情報が削除される必要がある。これは、位置決め精度を高めるのみならず、計算量を低減し、システム応答速度をも向上させる。さらに、この方法はまた、
グリッドの復元時間をフェッチし、復元時間と現在時間との間の時間インターバルがあらかじめ決定されたしきい値を超えているのであれば、リンクリストの後ろから順に前へと、期限切れになった位置情報を消去するステップを含む。
【００４０】
位置情報サービス記憶デバイスは、記憶された多くのグリッドを有し、また多くのハッシュバケットをも有し得る。したがって、期限切れになったデータの各削除が、位置情報サービス記憶デバイスにおけるすべてのグリッドにおいて実行されるのであれば、多くの時間を必要とし得る。そして、この期間中、位置決めサーバは、動作が停滞し、位置決めサーバを不安定に導く。位置情報サービスの安定性を高めるために、期限切れになったデータの削除の処理は、段階的に実行され得る。詳細は以下の通りである。選択的に、グリッドの復元時間をフェッチするステップは、
復元時間をフェッチするように、あらかじめ決定されたシーケンスに従って、すべてのグリッドから、あらかじめ決定された数のグリッドを選択するステップを含む。
【００４１】
本発明のこの実施形態では、あらかじめ決定された数のグリッドがランダムに設定され得る。また、システムのビジーまたはアイドルの程度に依存して調節され得る。たとえば、システムがよりビジーになれば、この数はより少なくなり、システムがよりアイドルになれば、この数はより多くなる。本発明のこの実施形態における解決策が採用されれば、位置情報サービスの停滞は、引き起こされることはないであろう。そして、位置情報サービスの安定性が向上され得る。
【００４２】
本発明のこの実施形態では、位置情報および他のデータは、共有メモリに記憶され得る。共有メモリクリーニングの処理が実行されると、データ復元が必要とされ得る。その結果、本発明の一実施形態は、以下のようなデータ復元の解決策をさらに提供する。さらに、この方法はまた、
ローカルエンド動作サポートシステムログへの位置情報の挿入動作および消去動作を記録し、ローカルエンド動作サポートシステムログが期限切れになった後、期限切れになったローカルエンド動作サポートシステムログを消去するステップと、
クリーニングされたメモリ復元の処理の間、ローカルエンド動作サポートシステムログの記録の時間シーケンスに従って、ローカルエンド動作サポートシステムログになされたレコードを読み取り、動作サポートシステムログに記録された動作を実行するステップと、を含む。
【００４３】
本発明のこの実施形態におけるデータ記憶構造およびデータ復元解決策に基づいて、本発明の一実施形態は、以下のような、位置情報サービス記憶デバイスの拡張中のデータ復元の具体的な解決策をさらに提供する。さらに、この方法はまた、
位置情報サービス記憶デバイスの拡張中、すべての位置情報サービス記憶デバイスの動作サポートシステムログを取得し、動作サポートシステムログにおいて取得されたレコードをフェッチし、現在フェッチされているレコードがローカルエンド位置情報サービス記憶デバイスに属しているのであれば、現在フェッチされているレコードに対応する動作を実行するステップを含む。
【００４４】
以下の一実施形態は、本発明のこの実施形態のアプリケーション処理およびシステム実施処理を、例として、近くのプレーヤを探索するためにモバイル電話を用いるゲームプレーヤのアプリケーションシナリオを用いて詳細に記述するであろう。
【００４５】
I.  システム本体構造，図4を参照されたい
【００４６】
位置情報サービス(Lbs)サーバは、主として2つの機能を有する。1つの機能は、プレーヤの空間的な地理的情報(すなわち、端末に位置するアカウント番号に対応するプレーヤのための、実際の端末の地理的情報)を記憶することであり、他の機能は、たとえば、プレーヤの周囲2km以内に位置するプレーヤのように、あるプレーヤの近くのプレーヤを問い合わせることである。
【００４７】
Lbsサーバは、プレーヤの地理的情報の外部アクセスのためのインターフェースを提供し、プレーヤの地理的情報を記憶するための、個々のサービスとして存在する。
【００４８】
Lbsサーバは、プレーヤの近くのプレーヤを迅速に探索すること、および、プレーヤの地理的情報を設定することのような需要をサポートするように、プレーヤの地理的情報を適切かつ効率的に整理する必要がある。図4は、Lbsサーバの一般的な構成図である。
【００４９】
図4に図示されるように、本発明のこの実施形態のシステムでは、ゲームサーバ(GameServer)は、位置情報サービスサーバ(Lbsservice)とのみ通信する。GameServerは、プレーヤの地理的情報を設定し、プレーヤの地理的情報の要求は、Lbsserviceによって処理される。Lbsserviceは、GameServerの要求を分析し、適切な位置情報サービス記憶デバイスに要求メッセージを送信することを担当する。
【００５０】
GameServerによって発行され、解析される必要のある地理的情報のために、Lbsserviceは、HTTPハイパテキスト伝送プロトコルによってSOSO MAPサーバに解析結果を要求し、それに従って処理を実行する。
【００５１】
図4に図示されるようなシステム構造では、Lbsserviceは、エージェントの機能を実施し、位置情報サービス記憶デバイス(Lbsstore)は、データ記憶を担当する。LbsserviceとLbsstoreとの間の通信チャネルは、tbusを使用することよって実装され得る。
【００５２】
II.  Lbs空間データモデル
【００５３】
範囲問合せをサポートすることは、たとえば、中心としてのポイントから離れたある距離における人を探索するような、位置情報の記憶のための重要なポイントである。サーバ側では、データ記憶構造は、そのような問合せモードを効果的にサポートするものとする。このポイントに基づいて、世界地図が、2次元的に処理された後、N*M個のグリッドに分割され得る。各グリッドは、同じサイズの正方形である。図5に図示されるように、プレーヤの地理的情報は、プレーヤの現在の2次元座標(x,y)に従って、異なるグリッドに記憶される。
【００５４】
プレーヤのあるポイント近くのプレーヤを探索するアプリケーションでは、以下の手順が実行され得る。
【００５５】
1.  先ず、中心としてプレーヤの地理的位置(x,y)と、半径として距離rを使用することによって、円を得る。
【００５６】
2.  円に囲まれた正方形を決定するための計算をする。
【００５７】
3.  囲まれた正方形にどのグリッドが含まれるのかを決定するための計算をする。半径r内に位置するすべてのプレーヤの情報は、これらグリッド内に記憶される。
【００５８】
4.  条件を満たすプレーヤを見つけるために、これらのグリッドを検索する。
【００５９】
図5に図示されるように、半径r内に位置するグリッドは、グリッド1、2、3、4、5、6、7、8および9を含む。したがって、情報がこれら9個のグリッドに記憶されているすべてのプレーヤを発見し、その後、各プレーヤが、円に囲まれた正方形内に位置しているのか否かを決定するために計算することのみが必要である。正方形内に位置するプレーヤは、条件を満たすプレーヤである。このように、ポイント(x,y)から離れた距離r内に位置するプレーヤは、これらの9個のグリッドのプレーヤの横断によってのみ問い合わせられ得る。
【００６０】
空間的なデータモデルに関する前述した要件に基づいて、本発明の一実施形態は、以下のような詳細な設計解決策を提供する。
【００６１】
2.1  地球ベースの座標の2次元処理
【００６２】
地球は、40,076kmの長さの赤道および40,009kmの長さの子午線を有する、わずかにフラットな球体である。地球は、(我々によって壁に掛けられている世界地図を参照して)赤道を長方形の長辺側として粗く使用することによって、長方形に変換される。したがって、長方形の長さは、赤道の長さに等しい。40,000kmが長方形の長さとして使用されるのであれば、幅は20,000kmである。
【００６３】
経度1度について、表される長さは、単純に、40,000km/360とみなされ、また、緯度1度について、表される長さは、20,000km/180である。
【００６４】
北緯90度東経180度に位置するポイントは、原点として選択され、経度の線はX軸を表し、その正方向は、東から西である。緯度の線はY軸を表し、その正方向は、北から南である。たとえば、北緯40度東経170度の座標は、2次元的にx=(180-170)*40,000km/360,y=(90-40)*20,000km/180へと処理される。
【００６５】
2.2  グリッド分割
【００６６】
本発明のこの実施形態の解決策では、グリッドは、幅100mを有する正方形であり得る。すなわち、地球は、2次元的に処理された後に、幅100mを有する複数の正方形に分割される。プレーヤの情報が位置するグリッドは、プレーヤの座標(x,y)に従う計算によって決定され、その後、データが、グリッドに記憶される。各グリッドは、ユニークな番号GridGIDを有する。図6に図示されるように、番号GridGIDは変更される。
【００６７】
図6は、400m*400mの範囲内のグリッドの番号変更の状況を示す。図6に図示されるような地理的エリアは、4*4個のグリッドに分割される。したがって、ナンバリングは、原点のポイントから始まり、番号は、X軸の方向に沿って増加される。
【００６８】
2次元的に処理された地球に対応して、2次元的に処理された後の長方形マップの長さは40,000kmであり、その幅は20,000kmであることが知られている。それに加えて、グリッドの幅は、100mである。ポイント(x,y)について、対応するGridGIDを計算するために使用される式は、以下の通りである。
GridGID(x,y)=((40000*1000)/100)*(y/100)+x/100+1
【００６９】
したがって、ポイント(x,y)に位置するプレーヤについて、そのGridGIDは、上記のGridGID計算式に従って計算され得る。
【００７０】
2.3  グリッド探索
【００７１】
グリッド探索は、図7に図示されるように、スパイラル探索アルゴリズムを使用し得る。Aが中心探索ポイント(プレーヤが位置するグリッド)であれば、Aの近くの人の探索は、矢印の方向に沿ったシーケンスで実行される。
【００７２】
2.4  データ記憶
【００７３】
前述した実施形態では、地球は、100mの側面長さを有するグリッドに分割され、プレーヤの情報は、その位置に従って、異なるグリッドに記憶される。具体的には、プレーヤの地理的情報が記憶された場合、図8に図示されるように、GridGIDがキー(キー値、しばしば、キーワードとも称される)として選択され、グリッド内のプレーヤの情報が、値としてハッシュテーブル内に記憶される。
【００７４】
近くのプレーヤについて問い合わせた場合、グリッド番号が、2.2において記録された式に従って計算され、その後、プレーヤの情報が、グリッド番号に従って、ハッシュテーブルからフェッチされ、条件を満たすプレーヤが、その後、計算によって決定される。
【００７５】
III.  位置決めサーバおよび位置情報サービス記憶装置のデータ記憶の設計および処理フロー
【００７６】
Lbsは、主として2つの部分、すなわち、LbsserviceとLbsstoreとを含む。外部アクセスのインターフェースを提供するためのエージェントとして動作し、外部環境は、Lbsserviceとのみ通信する。
【００７７】
Lbsstoreは、プレーヤの空間的な地理的情報の整理と、プレーヤの空間的な地理的情報の記憶とを担当する。Lbsstoreへのデータ記憶中、データは、共有メモリに記憶され、プレーヤの情報は、クリーニングされた共有メモリがリスタートされる場合に、データ復元を実行する利便性のために、動作サポートシステム(OSS)内に記録される。
【００７８】
以下は、これら2つの部分を詳細に記述する。
【００７９】
3.1  Lbsserviceの詳細設計
【００８０】
エージェントとして動作するLbsserviceは、GameServer、Lbsstore、およびSOSO Map Server間の通信の調整を担当する。前述したように、Lbsサーバの機能は、プレーヤの空間的な地理的情報を記憶し、プレーヤの近くのプレーヤを問い合わせることであると知られている。
【００８１】
プレーヤの空間的情報を記憶する機能のために、プレーヤの地理的情報をレポートすることのフローチャートである図9を参照されたい。
【００８２】
先ず、プレーヤが、クライアントからGameServerに、個人の地理的位置情報を送信し、次に、GameServerが、受信した地理的位置情報をLbsserviceに転送する。地理的情報を受信した後、Lbsserviceは、地理的位置情報をSOSO MAP Server(マップサーバ)に送信し、地理的情報の解析を要求する(HTTPが使用され、プログラムでは、HTTP要求を送信し、HTTPデータを受信するために、CURL(URL文法を使用することによってコマンドライン方式で動作するオープンソースファイル伝送ツール)が使用される)。SOSO MAP Serverは、地理的情報を解析した結果をLbsserviceに返信し、Lbsserviceは、位置情報を解析し、位置情報が記憶されるべきLbsstoreサーバの番号を決定するための計算を行い、その後、計算によって決定されたLbsstoreに、プレーヤの地理的情報を送信する。Lbsstoreは、プレーヤの地理的情報およびデータを記憶し、将来、リスタート中に、データ復元を実行する利便性のために、OSSログに書き込む。記憶の完了後、Lbsstoreは、記憶が正しく完了したか否かをLbsserviceに通知するために、記憶結果応答をLbsserviceに送信し、その後、Lbsserviceは、受信した記憶結果応答をゲームサーバに転送する。
【００８３】
上記実施形態によって、各プレーヤの位置情報が収集され、その後、プレーヤの近くのプレーヤを取得する機能が実施され得る。この処理は、以下のように記述される。
【００８４】
先ず、プレーヤが、GameServerを介してLbsserviceにメッセージ要求を送信する。このメッセージの内容は、プレーヤ自身の位置情報を含み、位置情報は、2次元座標であり得る。また、SOSO MAP Serverによって解析される必要のある位置文字列であり得る。それに加えて、メッセージパケットは、近くの距離範囲(radious)、および、タイムアウトリミット(expireTm、すなわち、一定の時間インターバル内で更新されたプレーヤの情報のみが必要とされる)をさらに含む。
【００８５】
プレーヤの位置情報が、SOSO MAP Serverによって解析される必要のあるキャラクタ文字列であれば、Lbsserviceは、先ず、SOSO MAP ServerにHTTPメッセージを送信し、その後、SOSO MAP Serverは、プレーヤの2次元座標を取得するために、位置解析を実行する。
【００８６】
Lbsserviceが、プレーヤの2次元座標(x,y)を取得した後、円に囲まれた正方形は、原点のポイントとして座標(x,y)、および、半径としてradiousを有するポイントを使用することによって、計算によって決定される。したがって、近くのプレーヤのデータはすべて、囲まれた正方形に含まれたグリッドに位置する。計算は、どのグリッドが、囲まれた正方形に含まれているのかを判定するために、そして、その後、どのLbsstoreが、記憶された対応するグリッドのデータを有しているのかを判定するために、実行される。その後、これらLbsstoreに要求が送信される。図5を参照されたい。
【００８７】
図5から、近くのプレーヤが、番号1乃至9のグリッドに含まれていることが認識され得る。番号1乃至9のグリッドに含まれるデータは、3つのLbsstore、すなわち、N1、N2、N3内に分散されると仮定される。その後、これらグリッド内のプレーヤの情報を要求するために、問合せ要求が3つのLbsstoreに送信される。したがって、プレーヤの近くのプレーヤの情報を取得する。
【００８８】
上記の実施形態では、Lbsstoreは、近くのプレーヤを決定するために、半径およびプレーヤの座標点に従って、計算を実行し、その後、結果をLbsserviceに返す。Lbsserviceは、その後、Lbsstoreによって返された結果を組み立てて、組み立てた結果を、GameServerに送信し、GameServerは、さらなる処理を実行する。GameServerによる受信結果の処理は、本発明のこの実施形態において限定されない。
【００８９】
以下は、Lbsserviceの機能に関するLbsserviceの設計解決策を紹介する。
【００９０】
3.1.1  プレーヤの反復される地理的情報の削除
【００９１】
プレーヤの地理的情報の設定中、期限切れになった地理的情報によって引き起こされるデータエラーを阻止し、位置決めサービスの精度を高めるように、プレーヤによって以前にレポートされた地理的情報は、削除される必要がある。Lbsserviceは、記憶されたプレーヤの以前の地理的情報をどのLbsstoreが有しているのかを知らないので、現在の地理的情報が記憶されているLbsstoreを決定するための計算後、Lbsserviceは、地理的情報の記憶を実施するように、設定された命令のメッセージをLbsstoreに送信する。プレーヤの地理的情報を消去するように消去動作を実行するために、その後、消去命令のメッセージが、他のすべてのLbsstoreにブロードキャスト方式で送信される。図10を参照されたい。
【００９２】
図11は、playerID 3を消去する概要図を図示する。プレーヤのplayerID(プレーヤ識別子)は、消去メッセージパケットに含まれる。キーとしてのplayerIDおよび値としてのGridGIDを有するハッシュテーブルが、Lbsstore上で確立される。消去中、消去メッセージがブロードキャストされた場合、GridGIDは、playerIDに従って、最大でも1つのLbsstoreでしか発見されない。プレーヤの情報は、地理的情報が記憶されているハッシュテーブルから、GridGIDに従って消去され、その後、playerIDとGridGIDとの間のインデックス関係が消去される。
【００９３】
3.1.2  グリッドが属するLbsstoreの番号の決定
【００９４】
本発明の一実施形態では、地球は100*100個のグリッドに分割され、各グリッドがGridGIDを有する。プレーヤの情報を記憶するための複数のLbsstoreが存在し、グリッド番号GridGID 1を有するプレーヤの情報のために、プレーヤの情報が具体的に記憶されるLbsstoreを決定する必要がある。
【００９５】
N個のLbsstoreサーバが存在すると仮定して、グリッドGridGID 1のデータが記憶されるLbsstoreの番号M1のために、以下の計算が単純に実行され得る。
【００９６】
M1=ハッシュ(GridGID 1)%N
【００９７】
しかしながら、たとえば、我々がプレーヤの周囲1km以内の近くのプレーヤを探索するつもりならば、それは欠点を有しており、探索対象のグリッドの数は、おおよそ2000/100*2000/100=400であり、ハッシュアルゴリズムを使用することによって、400個のグリッドが記憶されているLbsstoreの計算数の結果は、すべてのLbsstoreを含み得る。すなわち、近くの人を探索する演算は、すべてのLbsstoreにデータを要求する必要がある。これは、Lbsstoreに対し、非常に大きなデータ処理負荷をもたらし得る。
【００９８】
近くの人の探索を求める単一の要求が実施され、データのほとんどが少数のマシンに集中するのであれば、Lbsstoreに対するデータ処理負荷は、大幅に低減されるであろう。本発明のこの実施形態では、範囲内のデータは、より大きな粒度を使用することによって、集中方式で同じマシンに記憶され得る。すなわち、同じマシンの範囲内の記憶の最小粒度は、100mよりも大きくなるべきである。その理由は、分割後のグリッドのサイズが100*100であるからである。本発明のこの実施形態では、地球は、前の分割解決策に従って、10,000*10,000のサイズを有するグリッドにさらに分割される(もしも、10,000が極めて大きいのであれば、それは調節され、100の整数倍が実現可能である)。このように、大きなグリッドのデータは分散され、同じマシンに記憶され得る。
【００９９】
大きなグリッドのサイズが10,000*10,000である場合、大きなグリッドは、10,000個の小さなグリッドを含む。すなわち、10,000個の小さなグリッドのすべてのデータが、同じマシンに記憶される。大きな各グリッドはまた、小さなグリッドのための前のルールに従って付番され、その番号は、VirtualMachineGridGIDと称され、以下、GridGIDと称される。
【０１００】
VirtualMachineGridGID(GridGID)が属するLbsstoreの番号は、以下のように、座標点(x,y)に関する計算によって決定される。
【０１０１】
先ず、VirtualMachineGridGIDが以下のように計算される。
VirtualMachineGridGID=((40000*1000)/10000)*(y/10000)+x/10000+1
N個のLbsstoreが存在すると仮定し、記憶された座標点(x,y)が位置するLbsstoreの番号M1は、以下のように計算される。
M1=ハッシュ(VirtualMachineGridGID)%N
【０１０２】
Lbsserviceがプレーヤの地理的情報を記憶している場合、プレーヤの地理的情報が記憶されているLbsstoreの番号Mは、上記方式で計算され、その後、プレーヤの地理的情報がLbsstoreに配信される。その後、Lbsstoreは、GridGIDを計算し、ハッシュテーブルにデータを記憶する。
【０１０３】
先ず、円に囲まれた正方形が、プレーヤの座標および半径に従って計算によって決定され、その後、どの大きなグリッドが、囲まれた正方形に含まれているのかが判定される(以前と同じ計算方式が使用されるが、グリッドの側面長さが増加される)。大きなグリッドのVirtualMachineGridGID(GridGID)が取得された後、対応するLbsstoreの場号が、上記式に従って計算され得る。
【０１０４】
当然ながら、本発明のこの実施形態では、近くの人を探索する要求を満たすように、範囲内のデータは、大きな粒度を使用することによって、集中方式で、同じマシンに記憶される(近くの人を探索するための範囲は、無限に大きくはならないであろう。無限に大きければ、意味はなく、その範囲は、現在のプログラムにおいて制限されるように、最大2kmである)。近くの人を探索する現在の単一の要求は、集中方式で、1つまたは2つのLbsstoreに配信され、最大でも4つのLbsstoreに配信され得る。このようにして、この要求によってもたらされるLbsstoreへの負荷が大幅に低減され得る。
【０１０５】
3.3.3  Lbsserviceによるデータアセンブル
【０１０６】
近くのプレーヤを要求する場合、近くのプレーヤの情報は、複数のLbsstore内に分散され得る。すなわち、Lbsserviceは、完全な問合せ結果を取得し、その後、データの多数のピースを組み立てて、組み立てたデータをGameServerに返すように、複数のLbsstoreによって返されたデータを受信する必要がある。
【０１０７】
以下のデータ構造が、Lbsserviceにおいて定義され得る。
struct tagNearPlayersInfo
{
int iUpdateTm; //タイムアウト処理に使用される要求の送信時間
int iNeedDataParts; //受信されるべきデータの総量
int iReceivedDataPart; //受信されたデータの総量
int iPosX; //プレーヤのX座標
int iPosY; //プレーヤのY座標
int iSeq; //シリアル番号
uint32_t dwBusID; //メッセージを送信するGameSvrのバスアドレス
int iPlayerCnt; //プレーヤの総数
tagplayerDetail stPlayerList[MAX_LBS_PLAYER_LIST_NUM];
};
【０１０８】
それに加えて、キーとしてのplayerID、および値としてのtagNearPlayersInfoを有するハッシュテーブルが確立される。Lbsserviceが、近くのプレーヤの情報を求める要求を、複数のLbsstoreに送信した場合、Lbsserviceは、キーとしてplayerIDを有するデータのピースを、マップ(テキストファイルのタイプ)に挿入する。ここでは、挿入時間、受信されたデータ、受信されるべきデータ(すなわち、この要求が配信されるLbsstoreの数)、メッセージのシリアル番号等が記録される。Lbsserviceが、Lbsstoreから応答されたデータのピースを受信した場合、iReceivedDataPartが、1ずつ増加され、iNeedDataPartsがiReceivedDataPartに等しい(すなわち、完全なデータが受信された)か、または、時間が期限切れになったのであれば、受信されたデータが、GameServerに送信される。
【０１０９】
Mapを使用することはまた、プレーヤによる要求の頻度を制御する機能をも有効にし得る。たとえば、プレーヤが、近くのプレーヤの情報の取得を求める第1の要求を送信し、直ちに、もう1つの要求を送信すると、このプレーヤの情報は、Mapに含められるべきであり、よって、第2の要求はダイレクトに拒否され得る。サーバ側では、タイムアウトリミットが10秒として定義される。すなわち、プレーヤが、10秒以内に、近くのプレーヤの情報の取得を求めるための2つの要求を送信すると、最初に送信された要求のみが処理される。
【０１１０】
3.3.4  プログラムによって使用されるハッシュ関数
【０１１１】
前述した実施形態の記述では、virtualMachineGridGIDにおいてハッシュ処理が実行されると、プレーヤの情報が位置するLbsstoreの番号が計算される。
【０１１２】
データが、LbsstoreにおけるプレーヤのGridGIDに従って、ハッシュテーブルに挿入された場合、先ず、ハッシュ(GridGID)が計算され、ハッシュ(GridGID)%hashnumを使用することによって、データが位置するハッシュバケットの番号(ハッシュバケットシーケンス)が取得される。その理由は、GridGIDの計算ルールが非常に厳しいからである。これは、いくつかのグリッドのデータを、同じハッシュバケット内に集中させ得る。したがって、本発明のこの実施形態では、GridGIDは、データのランダム性を高めるように、ハッシュ処理を再度さらに提供され得る。
【０１１３】
地球全体が2次元的に処理された後、グリッドの総数は、800億個となる。異なるグリッドを識別するために、uint64_tタイプ(64ビットの無符号整数)のデータが、GridGIDを記憶するために使用され得る。GridGIDのより良好な分散パフォーマンスを達成するために、以下のWang/Jenkinsハッシュアルゴリズムが、GridGIDに対してハッシュ処理を実行するために採用される。
uint64_t CLbsPosConvert::hash64shift(uint64_t ullKey)
{
ullKey=(~ullKey)+(ullKey<<21);
ullKey=ullKey^(ullKey>>24);
ullKey=(ullKey+(ullKey<<3))+(ullKey<<8);
ullKey=ullKey^(ullKey>>14);
ullKey=(ullKey+(ullKey<<2))+(ullKey<<4);
ullKey=ullKey^(ullKey>>28);
ullKey=ullKey+(ullKey<<31);
return ullKey;
}
【０１１４】
3.2  Lbsstoreの詳細設計
【０１１５】
Lbsstoreは、プレーヤの地理的情報を記憶するために使用される。本発明のこの実施形態では、共有メモリ上のハッシュテーブルが、プレーヤの地理的情報を記憶するために使用され得る。地球は、100*100個のグリッドに分割され、プレーヤの情報は、そのようなグリッドに記憶される。ハッシュテーブルのキーは、グリッドのGridGIDであり、その値は、グリッドにおけるプレーヤ情報である。プレーヤの数は、いくつかのグリッドにおいて非常に多く、他のグリッドにおいて、非常に少ないことがあり得る。したがって、ハッシュテーブルは、グリッドにおいて、異なる数のプレーヤを記憶することをサポートする必要がある。値のためにアレイが使用されるのであれば、共有メモリの利用率が低下する可能性があり、グリッド内のプレーヤの最大数を推定することが不可能になるので、アレイのサイズが問題になる。
【０１１６】
したがって、本発明のこの実施形態では、値は、リンクリストを使用することによって記憶され、グリッド内のプレーヤは、リンクリストの形式でリンクされる。直近にレポートされたデータが、リンクリストの前面に配置されることを保証するために、そして、リンクリスト内のデータが、レポート時間に従ってシーケンス付けられることを論理的に保証するために、リンクリストの先頭に挿入する方法が採用される。この特徴は、プレーヤの情報ガーベッジ収集(GC、すなわち、プレーヤの、期限切れになった情報の削除)中、および、近くのプレーヤの探索中に時間ポイント内で地理的情報をレポートするプレーヤのみが問合せを受ける場合、有用である。
【０１１７】
図12は、プレーヤの情報を記憶するためのハッシュテーブルの構成図である。
【０１１８】
図12では、GridIndexNodeは、グリッドを表し、3つのグリッドノードのリンクは、ハッシュ(キー)衝突を表す。衝突は、リンクリスト方式で解決され得る。プレーヤノードの情報、すなわち、PlayerNodeは、各グリッドノード、すなわち、GridIndexNode、にリストされ得る。グリッドに位置するプレーヤの数は、グリッド内のPlayerNodeの数を示す。PlayerNodesは、リンクリストの形式でリンクされる。
【０１１９】
GridIndexNodeの構成形式は以下の通りである。
struct tagCGridIndexNodeInfo
{
int iPlayerNum; //グリッド内のプレーヤの数
int iPlayerIndex; //プレーヤの共有プールにおけるプレーヤのインデックス
int iLastGcTm; //前回のGCの時間(プレーヤの期限切れになった情報の消去時間)
void Init()
{
iPlayerIndex=NIL_PLAYER_INDEX;
iPlayerNum=0;
iLastGcTm=0;
}
};
【０１２０】
ここで、iPlayerNumは、グリッド内のプレーヤの総数を維持するために使用され、iLastGcTmは、GC処理の効率の向上のために使用される、前回のグリッドGCの時間であり、不必要な反復GCを回避する。
【０１２１】
PlayerNodeの構成形式は以下の通りである。
//プレーヤの地理的情報
struct tagCPlayerPosInfo
{
int iUpdateTm; //更新情報の時間、絶対時間
int iXpos; //X座標、単位:m
int iYpos; //Y座標、単位:m
uint32_t uiPlayerID; //プレーヤのID
int iNextPlayerPos; //共有メモリプールにおける同じグリッドの次のプレーヤのインデックス
void Init()
{ iUpdateTm=0;
iXpos=-1;
iYpos=-1;
uiPlayerID=0;
iNextPlayerPos=NIL_PLAYER_INDEX;
}
};
【０１２２】
それに加えて、Lbsstoreにおけるプレーヤの情報の独自性を維持するために、図13に図示されるように、各Lbsstoreは、playerIDからGridGIDへの逆インデックスを有する。
【０１２３】
したがって、プレーヤの情報がLbsstoreに追加された場合、先ず、逆インデックスリストにおいて探索が実行され、プレーヤの情報が存在しているのであれば、情報のピースが消去され、その後、プレーヤの新たな地理的情報が、共有メモリに挿入される。
【０１２４】
逆インデックス構造におけるデータは、以下のように1つのgridGIDのみを含む。
//プレーヤのインデックス情報
struct tagCPlayerIndexInfo
{
uint64_t ullGridGid;
void Init()
{
ullGridGid=0;
}
};
【０１２５】
3.2.1  期限切れになったデータのLbsstoreによる処理、すなわち、GC処理
【０１２６】
プレーヤの地理的情報は、タイムリミットを有しているので、プレーヤの地理的位置が変わると、プレーヤの地理的情報は無効になるであろう。したがって、Lbsstoreに記憶されたデータに関し、プレーヤの期限切れになった地理的情報は削除される必要がある。解決策では、Lbsstoreにおけるプレーヤの期限切れになった地理的情報を削除するために、バケットベースの規則的なクリーニング方式が採用される。図14を参照されたい。
【０１２７】
ハッシュテーブルは、プレーヤの情報の、何十万もの記憶されたピースを有し、また、何十万ものバケットも存在する。各規則的なクリーニング中に、ハッシュテーブルに対してフルスキャンが実行されると仮定される。時間持続期間がtであれば、Lbsstoreは、tの期間内に、外部サービスの能力を失うであろう。それに加えて、プレーヤの情報に対するタイムアウトリミットは、数時間であり得る。これによって、ワンステップで、すべてのデータを処理することは不要となる。
【０１２８】
上記の理由に基づいて、Lbsstoreは、バケットベースの規則的なクリーニング方式を採用する。すなわち、毎回、制限された数のハッシュバケットのみを処理し、次のティックにおいて処理される必要のあるバケットの番号を記録する。図14を参照されたい。
【０１２９】
m個のバケットが毎回処理され、ハッシュテーブル全体でN個のバケットを有し、ティックの時間インターバルは、Tであり、プレーヤの情報のタイムアウトリミットは、Lであり、テーブルの各スキャンの時間は、Total=(N/m)*Tである。Total<=Lである限り、期限切れになったデータがタイムリーに削除され得る。外部サービスにおけるLbsstoreの能力に影響を与えることなく、期限切れになったデータがLbsstoreによってタイムリーに削除されることを保証するために、mおよびTの適切な値が設定され得る。たとえば、各ティックにおいて処理されるバケットの数は500であり得る。図14では、各ティックにおいて処理されるバケットは、3バケット以内の値である。
【０１３０】
3.2.2  Lbsstoreにおける近くの人の探索の方式
【０１３１】
前述した実施形態において記録されたデータモデルから、近くの人を探索する場合、正方形内のグリッド内のどのデータが条件を満たしているのかを判断するように、半径として近くの範囲を持つ円に囲まれた正方形が、先ず取得され、次に、正方形内のグリッドが識別されることが知られ得る。それは、距離の計算に関連している。
【０１３２】
分割によって取得されたグリッドは小さく、具体的には、100*100のサイズしかない。その結果、近くの範囲内の囲まれた正方形は、計算によって決定され、正方形に含まれるグリッドが決定される。正方形にグリッドが含まれている限り、グリッド内のすべてのプレーヤの情報は、近くの範囲に属し、誤差は、100mを超えず、それは許容可能であるとみなされる。図5を参照されたい。図5において、半径r内の近くのプレーヤは、赤い正方形内に位置するが、グリッド1、2、3、4、6、7および9におけるプレーヤは、この範囲内に位置すると、単純にみなされ得る。グリッドのサイズは、100*100であるので、ある誤差、すなわち、100m未満が許容される。グリッドの側面長さが与えられているのであれば、この誤差は、グリッドの側面長さ未満である。
【０１３３】
上記計算方式を使用することによって、距離計算が省略され得る。それは単に、正方形に含まれるグリッドを発見し、グリッド内のプレーヤのデータを出力することのみが必要であり、これによって、計算量が大幅に低減されるであろう。
【０１３４】
上記解決策は、第1レベルのハッシュに基づくが、2km(最大許容可能範囲は2km)内に位置する近くのプレーヤを探索する場合、探索される必要のあるグリッドの数は、(4000/100+1)*(4000/100+1)=1681である。すなわち、1681個のグリッド内のいくつのグリッドが、データを有しているかに拘わらず、1600サイクルが必要とされる。ハッシュテーブルから、値(キー値)、すなわち、getvalue(key)を取得する1600回のために、探索の回数は膨大になるであろう。
【０１３５】
探索の回数が膨大になるという問題を解決するために、本発明の一実施形態は、単一のグリッドの側面長さを増加させる解決策を提供する。たとえば、単一のグリッドの側面長さが200*200であれば、探索の回数は400に変更される。しかしながら、グリッド内のデータが、4倍まで拡張されるのであれば、プログラムのGCが影響されるか否か等を考慮する必要がある。同じグリッドが、大量のデータを有し得る。そして、より多くのデータ衝突が、ハッシュバケットにおいて生じるであろう。
【０１３６】
本発明の一実施形態によって提供される別の解決策は以下の通りである。第2レベルのハッシュを確立するために、マップが、1km*1kmのグリッドに分割される。そして探索中、第1レベルのハッシュ、すなわち、1km*1kmのグリッドが探索され、データを有するグリッドを記録するために、100のサイズを有するアレイが、大きなグリッド内に配置される。2kmの範囲内では、必要とされる大きなグリッドの数は、最大でも(4km/1km+1)*(4km/1km+1)=25である。記憶されたデータを有するグリッドはその後、25個の大きなグリッドから発見され、プレーヤのデータは、これらグリッドから発見される。記憶されたデータを有するグリッドがほとんどないのであれば、このようにして、循環回数が大幅に低減され得る。確かに、この方式におけるメンテナンスは複雑であり、データ追加または消去の間、インデックスのためのメンテナンスが時間を必要とする。第1レベルのハッシュを採用する効果が満足を得るものではないのであれば、この解決策が考慮され得る。
【０１３７】
3.2.3  Lbsstoreのクリーニングされた共有メモリのデータ復元
【０１３８】
Lbsstoreでは、データは、共有メモリに記憶される。したがって、クリーニングされたメモリ復元の問題が考慮される必要がある。本発明のこの実施形態における解決策は、OSSログ内にレコードを作ることを採用し得る。共有メモリがクリーニングされた場合、復元のために、各レコードが、OSSログから連続的にフェッチされる。レコードがOSSログ内に作られた場合、Lbsstoreは、全体で、2つのタイプのデータ動作、すなわち、挿入と消去とを有する。挿入動作または消去動作(GC中のデータ消去を含まない)は、おのおの、OSSログ内に記録され、プレーヤの詳細情報が、挿入ログおよび消去ログに記録される。ログのピースは、1時間毎に記録され得る。ログは、(プレーヤの地理的情報のタイムアウトリミットに従って)ある時間に期限切れになると、削除される。
【０１３９】
クリーニングされた共有メモリのリスタート中、OSSログが、先ず、日付順に並べられ、最も早い時間に記録されたOSSログを読み取ることから、ファイル読取が開始される。それが挿入動作であれば、レコードが挿入され、それが消去動作であれば、レコードが消去される。データの独自性を保証するように、Lbsstoreは、playerIDからGridGIDへの逆インデックスを有しており、それに加えて、最も早期のファイルからデータ読取が開始される。これは、プレーヤの最終的な情報が、直近の情報であることを保証し得る。それに加えて、ログファイルは、数時間であるタイムアウトリミットを有するので、ファイルレコードの数は、過度に大きくなるべきではない。
【０１４０】
3.2.4  Lbsstoreのデータ拡張中のデータ復元
【０１４１】
プレーヤの位置情報のデータが増加された場合、Lbsstoreの数も増加され得る。LbsserviceによるLbsstoreへのデータ配信の前述した解決策に従って、モジュラス演算方式が採用される。その結果、Lbsstoreの数が増加された場合、共有メモリ内のデータは無効になり得る。したがって、プレーヤの情報は、拡張中にリロードされる必要があり、この処理は、本質的に、クリーニングされた共有メモリのリスタートの処理である。
【０１４２】
相違点は、そのようなケースでは、クリーニングされた共有メモリがリスタートされた場合、読取のために、すべてのLbsstoreのOSSログが、各Lbsstoreの読取ディレクトリの下に配置される必要があることである。ファイル読取は未だに、最も早期のファイルから開始されているが、プレーヤの座標(x,y)(座標はOSSに記録される)に従ってvirtualMachineGIDが計算されねばならず、次に、virualMachineGID% LbsstoreNumが計算される。その番号が、現在のLbsstoreの番号と一致していれば、データは、現在のLbsstoreに属しており、OSSログのレコードに従って、レコードが挿入または消去され、一致していなければ、レコードは破棄され、処理されない。
【０１４３】
Lbsstoreを増加させ、クリーニングされた共有メモリをリスタートさせる処理のために、時間長さが、Lbsstore全体における効果的なOSSレコードの合計量に関連付けられる。地理的情報がレポートされた場合にのみ、OSSログにレコードが生成され、挿入動作および消去動作の頻度は、非常に高い訳ではない。それに加えて、データ読取中、データが磁気ディスクから連続的に読み取られ、磁気ディスク等によるプリフェッチによって、その効率が保証され得る。
【０１４４】
現在は、この解決策が採用されている。そして、データ量が、後の段階において、著しく膨大な量になれば、拡張中にマシンを増やすことは、単に1つのマシンの内容の価値をなくすことに繋がり、フェッチされたレコードの番号も、1つのLbsstoreのデータ量にのみ関連付けられることを保証するように、Lbsserviceは、Lbsstoreに記憶されたデータを配信するための一貫したハッシュ方式を採用することを考慮し得る。しかしながら、一貫したハッシュは、1つのマシンの過度に重い負荷を解決することを目的とし、すべての負荷が、等しく分散されるべきであるか、複数のLbsstoreが増加される必要があるか、または、仮想ノードの概念が採用されているのであれば、複雑さを増し、再構成中のファイル配信の複雑さを、比較的高くする。
【０１４５】
本発明の一実施形態は、
ターゲット位置情報を含む位置決め要求を受信した後に、ターゲットグリッドを決定するように構成されたグリッド決定ユニット1501であって、ターゲットグリッドは、ターゲット位置情報に対応するグリッドと、ターゲット位置情報に対応するグリッドから離れた設定範囲内の距離に位置するグリッドとを含み、これらグリッドは、マップを正方形に分割することによって取得される、グリッド決定ユニット1501と、
ターゲットグリッドが属する位置情報サービス記憶デバイスを決定するように構成されたデバイス決定ユニット1502であって、データ記憶は、キーワードとしてグリッド番号を使用し、値として端末情報を使用することによって、位置情報サービス記憶デバイスにおいて実行され、各位置情報サービス記憶デバイスにおける記憶の最小粒度は、グリッドに対応する正方形の側面長さのM倍であり、Mは2以上である、デバイス決定ユニット1502と、
決定された位置情報サービス記憶デバイスに、ターゲットグリッドに対応する端末情報を問い合わせるように構成された問合せユニット1503と、
問い合わせた端末情報を、位置決め要求の送信元に送信するように構成された情報送信ユニット1504と、を含む、図15に図示されたような位置決めサーバをさらに提供する。
【０１４６】
本発明のこの実施形態では、グリッドは、マップを分割することによって取得される。つまり、グリッドは、実際の地理的位置に対応している。実際、グリッドの側面長さは、グリッドに対応する地理的位置の側面長さである。グリッドの側面長さがより短くなれば、最終的な位置決めの精度はより高くなるであろう。また、グリッドの側面長さがより長くなれば、記憶されるグリッドの数はより少なくなり、探索に使用される時間はより短くなり得る。本発明のこの実施形態において、具体的な長さは限定されず、100mが側面長さとして推奨され得る。
【０１４７】
Mの具体的な値は、本明細書において、当業者によって設定され得る。2kmである最大範囲内の周囲の端末情報が探索されているのであれば、この値は、100、50等に設定され得、その具体的な値は、本発明のこの実施形態では限定されない。
【０１４８】
本発明のこの実施形態では、地理的位置は、グリッド方式で分割され、分割後に取得されるグリッドは、位置情報の記憶のために使用され、位置情報サービスの処理中、計算量を低減するように、経度と緯度とは、距離を計算するために必要とされず、したがって、サーバ応答速度を向上させる。それに加えて、グリッドが位置情報サービス記憶デバイスに割り当てられた場合、使用される最小粒度は、グリッドよりも大きくなる。これによって、より多くの隣接グリッドが同じ位置情報サービス記憶デバイスに割り当てられるようになり、決定されたターゲットグリッドは、少数の位置情報サービス記憶デバイスに集中するようになる。したがって、位置情報サービス記憶デバイスの呼び出しを減らし、位置情報サービス記憶デバイスの計算負荷を下げ、これによって、位置情報サービス全体のシステムパフォーマンスを向上させる。それに加えて、位置決め精度を高め、単一のグリッドの著しく大量の位置情報によって引き起こされる衝突を低減するように、グリッドのサイズが小さくなるように設定され得る。
【０１４９】
本発明のこの実施形態では、位置情報サービス記憶デバイスにおける位置情報は、別のサーバによって収集された情報をソースとし得、位置決めサーバによってダイレクトに収集された情報をもソースとし得る。本発明の一実施形態は、端末の位置情報を取得し、記憶するための具体的な実施解決策を提供し、詳細は以下の通りである。さらに、図16に図示されるように、位置決めサーバは、
端末によってレポートされた位置情報および端末情報を受信するように構成された情報受信ユニット1601と、
位置情報が属するグリッドを決定するようにさらに構成されたグリッド決定ユニット1501と、
グリッド決定ユニット1501によって決定されたグリッドが属する位置情報サービス記憶デバイスを決定するようにさらに構成されたデバイス決定ユニット1502と、
端末によってレポートされた位置情報および端末情報を、記憶のために、決定された位置情報サービス記憶デバイスに送信するようにさらに構成された情報送信ユニット1504と、をさらに含む。
【０１５０】
本発明の一実施形態は、好適な記憶解決策をさらに提供する。これは、記憶されたデータオーバレイと、その後のデータ衝突とを回避し得る。その詳細は、以下の通りである。さらに、データ記憶はまた、キーワードとしての端末情報、および、値としてのグリッド番号を使用することによって、位置情報サービス記憶デバイスにおいて実行される。位置決めサーバは、
記憶された端末情報に対応する位置情報を消去するように、位置情報を消去するための命令を、決定された位置情報サービス記憶デバイス以外の位置情報サービス記憶デバイスに送信するように構成された情報送信ユニット1504をさらに含む。
【０１５１】
本発明のこの実施形態では、位置情報を消去するための命令は、決定された位置情報サービス記憶デバイス以外の位置情報サービス記憶デバイスに送信される。具体的な送信解決策は、端末の位置情報の独自性をサーバ側において維持するように、ブロードキャスト方式を採用し得る。
【０１５２】
本発明のこの実施形態では、問合せ中の問合せ速度を向上させ、また、位置情報サービス記憶デバイスのその後の拡張を容易にするように、分割後、グリッドが付番され、その後、グリッドを別の位置情報サービス記憶デバイスに割り当てるためのハッシュアルゴリズムが採用される。詳細は以下の通りである。選択的に、グリッドは、マップを正方形に分割することによって取得され、地理的情報のシーケンスに従って付番される。そして、位置情報サービス記憶デバイスにおける最小粒度のグリッドと、位置情報サービス記憶デバイスとの対応性は、ハッシュアルゴリズムのルールに従う。
【０１５３】
デバイス決定ユニット1502は、ターゲットグリッドが属する位置情報サービス記憶デバイスを決定するように、ハッシュ探索を実行するためにターゲットグリッドを使用するように構成されている。
【０１５４】
本発明のこの実施形態では、位置情報サービス記憶デバイスの呼び出しが低減され得るが、位置決めサーバの機能が1つの位置情報サービス記憶デバイスによって完了され得ることを保証することはできない。したがって、ターゲットグリッドが複数の位置情報サービス記憶デバイス内に分散される可能性があり、これに基づいて、本発明の一実施形態は、以下のような実施解決策をさらに提供する。さらに、図17に図示されるように、ターゲットグリッドが2つ以上の位置決めベースのサービス記憶デバイス内に分散されるのであれば、位置決めサーバは、
位置情報サービス記憶デバイスに問い合わせた端末情報のパケット組立てを実行するように構成されたパケット組立てユニット1701と、
パケット組立てユニットのパケット組立て結果を、位置決め要求の送信元に送信するように構成された情報送信ユニット1504と、をさらに含む。
【０１５５】
端末ユーザは、端末を用いることによって、位置決め要求を連続的に送信し得るので、各位置決め要求が位置決めとともに処理されるのであれば、大きな負荷がサーバにもたらされるであろう。それに加えて、時間インターバルが非常に短ければ、位置決め結果は、一般に、まれにしか変更されない。したがって、そのような頻繁な位置決めは必要ではない。サーバの負荷を低下させ、かつ、不必要な位置決め演算を低減するために、本発明の一実施形態は、以下のような解決策を提供する。さらに、図18に図示されるように、位置決めサーバは、
端末から別の位置決め要求が受信されると、前回の位置決め要求後の時間インターバルがあらかじめ決定されたしきい値を超えているか否かを判定し、時間インターバルがあらかじめ決定されたしきい値を超えているのであれば、位置決めの実行を拒否するように構成された位置決め制御ユニット1801、をさらに含む。
【０１５６】
本発明のこの実施形態では、マップは、グリッドに分割される。グリッドの側面長さが、より短くなれば、位置決めの精度はより高くなるが、計算量がより多くなる。また、グリッドの側面長さがより長くなれば、計算量はより少なくなり、応答速度はより速くなる。両方の利点を組み合わせるために、本発明の一実施形態は、以下のような解決策を提供する。選択的に、グリッド決定ユニット1501は、先ず、試験グリッド内に端末情報を含む試験グリッドを問い合わせるように構成され、試験グリッドは、ターゲット位置情報に対応する試験グリッドであり、試験グリッドは、前述したグリッドの側面長さよりも長い側面長さを有する正方形にマップを分割することによって取得され、グリッド決定ユニット1501は、問い合わせた試験グリッドに含まれるグリッドが、ターゲットグリッドであると判定するようにさらに構成される。
【０１５７】
本発明のこの実施形態では、試験グリッドの側面長さはより長い。これによって、大きなグリッドは、先ず、ターゲットグリッド内の位置情報なしで、グリッドをフィルタアウトし、不必要な探索を回避するために使用され得るようになり、したがって、探索量を減らし、システム応答速度を向上させる。
【０１５８】
本発明の一実施形態は、
位置決めサーバから問合せ要求を受信するように構成された要求受信ユニット1901であって、問合せ要求は、問合せ対象のターゲットグリッドを含む、要求受信ユニット1901と、
キーワードとしてグリッド番号を使用し、値として端末情報を使用することによってデータ記憶を実行するように構成されたデータ記憶ユニット1902であって、各位置情報サービス記憶デバイスにおける最小の記憶粒度は、グリッドに対応する正方形の側面長さのM倍であり、Mは2以上であり、グリッドは、マップを正方形に分割することによって取得される、データ記憶ユニット1902と、
ターゲットグリッドの番号を使用することによって問合せを行い、問合せ対象のターゲットグリッドに対応する端末情報を取得するように構成された問合せユニット1903と、
取得した端末情報を位置決めサーバに送信するように構成された情報送信ユニット1904と、を含む、図19に図示されるような位置情報サービス記憶デバイスをさらに提供する。
【０１５９】
本発明のこの実施形態では、グリッドは、マップを分割することによって取得される。つまり、グリッドは、実際の地理的位置に対応している。実際、グリッドの側面長さは、グリッドに対応する地理的位置の側面長さである。グリッドの側面長さがより短くなれば、最終的な位置決めの精度はより高くなるであろう。また、グリッドの側面長さがより長くなれば、記憶されるグリッドの数はより少なくなり、探索に使用される時間はより短くなり得る。本発明のこの実施形態において、具体的な長さは限定されず、100mが側面長さとして推奨され得る。
【０１６０】
Mの具体的な値は、本明細書において、当業者によって設定され得る。2kmである最大範囲内の周囲の端末情報が探索されているのであれば、この値は、100、50等に設定され得、その具体的な値は、本発明のこの実施形態では限定されない。
【０１６１】
本発明のこの実施形態では、地理的位置は、グリッド方式で分割され、分割後に取得されるグリッドは、位置情報の記憶のために使用され、位置情報サービスの処理中、計算量を低減するように、経度と緯度とは、距離を計算するために必要とされず、したがって、サーバ応答速度を向上させる。それに加えて、グリッドが位置情報サービス記憶デバイスに割り当てられた場合、使用される最小粒度は、グリッドよりも大きく、これによって、より多くの隣接グリッドが同じ位置情報サービス記憶デバイスに割り当てられるようになり、決定されたターゲットグリッドは、少数の位置情報サービス記憶デバイスに集中するようになる。したがって、位置情報サービス記憶デバイスの呼び出しを減らし、位置情報サービス記憶デバイスの計算負荷を下げ、これによって、位置情報サービス全体のシステムパフォーマンスを向上させる。それに加えて、位置決め精度を高め、単一のグリッドの著しく大量の位置情報によって引き起こされる衝突を低減するように、グリッドのサイズが小さくなるように設定され得る。
【０１６２】
選択的に、本発明の一実施形態は、以下のような、位置情報サービス記憶デバイスにおけるグリッドの分散と、グリッド内のデータ記憶とのための具体的な実施解決策をさらに提供する。データ記憶ユニット1902では、位置情報サービス記憶デバイスに記憶されたグリッドの番号が、ハッシュアルゴリズムのルールに従って記憶され、ハッシュバケットを使用することによってシーケンス化される。
【０１６３】
本発明のこの実施形態では、位置情報サービス記憶デバイスにおける位置情報は、別のサーバによって収集された情報をソースとし得、位置決めサーバによってダイレクトに収集された情報をもソースとし得る。本発明の一実施形態は、端末の位置情報を取得し記憶するための具体的な実施解決策を提供し、また、位置情報の独自性を維持するための具体的な実施解決策を提供する。詳細は以下の通りである。さらに、図20に図示されるように、位置情報サービス記憶デバイスは、
位置決めサーバによって送信された端末情報および位置情報を受信するように構成された情報受信ユニット2001と、
端末情報に対応する位置情報が存在しているか否かを判定するための探索を実行するようにさらに構成された問合せユニット1903と、
問合せユニット1903によって取得された問合せ結果が「存在している」であれば、発見された位置情報を消去するように構成されたデータ消去ユニット2002と、
問合せユニット1903によって取得された問合せ結果が「存在していない」であるか、または、データ消去ユニット2002が消去を完了しているのであれば、端末情報を位置情報に対応するグリッドに記憶し、ハッシュテーブルを使用することによって、位置情報を記憶するように構成されたデータ記憶ユニット1902と、をさらに含む。
【０１６４】
本発明の一実施形態は、位置情報を記憶するための具体的な解決策をさらに提供する。本発明のこの実施形態では、位置情報は、リンクリストの先頭に挿入することによって記憶される。これによって、位置情報は、時間シーケンスで記憶されるようになり、したがって、無効なデータのその後の消去を容易にする。詳細は以下の通りである。選択的に、ハッシュテーブル値は、リンクリストのデータ構造を採用し、
データ記憶ユニット1902は、位置情報をリンクリストの先頭に挿入することによって、位置情報に対応するグリッドのリンクリストに挿入するように構成される。
【０１６５】
端末の位置情報(地理的情報)はタイムリミットを有しているので、端末の位置情報は、端末の地理的位置が変化すると、無効になり得る。その結果、位置情報サービス記憶デバイスに記憶された位置情報に関し、期限切れになった位置情報は、削除される必要がある。これは、位置決め精度を高めるのみならず、計算量を低減し、システム応答速度を向上させる。さらに、図21に図示されるように、位置情報サービス記憶デバイスは、
グリッドの復元時間をフェッチし、復元時間と現在時間との間の時間インターバルが、あらかじめ決定されたしきい値を超えているのであれば、リンクリストの後ろから順に前へと、期限切れになった位置情報を消去するように構成されたタイムアウトクリーニングユニット2101をさらに含む。
【０１６６】
位置情報サービス記憶デバイスは、記憶された多くのグリッドを有し、また、多くのハッシュバケットを有し得る。したがって、位置情報サービス記憶デバイスにおけるすべてのグリッドにおいて、各期限切れになったデータの削除が実行されるのであれば、多くの時間を必要とし得る。そして、この期間中、位置決めサーバは、動作が停滞し得る。これは、位置決めサーバを不安定に導く。位置情報サービスの安定性を高めるために、期限切れになったデータ削除の処理は、段階的に実行される。詳細は以下の通りである。選択的に、タイムアウトクリーニングユニット2101は、復元時間をフェッチするように、あらかじめ決定されたシーケンスに従って、すべてのグリッド内の、あらかじめ決定された数のグリッドを選択するように構成される。
【０１６７】
本発明のこの実施形態では、あらかじめ決定された数のグリッドがランダムに設定され得、また、システムのビジーまたはアイドルの程度に依存して調節され得る。たとえば、システムがよりビジーになれば、この数はより少なくなり、システムがよりアイドルになれば、この数はより多くなる。本発明のこの実施形態における解決策を採用することにより、位置情報サービスの停滞が引き起こされることがなくなり、位置情報サービスの安定性を高め得る。
【０１６８】
本発明のこの実施形態では、位置情報および他のデータは、共有メモリに記憶され得る。共有メモリクリーニングの処理が実行されているのであれば、データ復元が必要とされ得る。その結果、本発明の一実施形態は、以下のようなデータ復元の解決策をさらに提供する。さらに、図22に図示されるように、位置情報サービス記憶デバイスは、
位置情報の、ローカルエンド動作サポートシステムログへの挿入動作および消去動作を記録するように構成されたログ記録ユニット2201と、
ローカルエンド動作サポートシステムログが期限切れになった後、期限切れになったローカルエンド動作サポートシステムログを消去するように構成されたログクリーニングユニット2202と、
クリーニングされたメモリ復元の処理中、ローカルエンド動作サポートシステムログにおける記録の時間シーケンスに従って、ローカルエンド動作サポートシステムログになされたレコードを読み取り、動作サポートシステムログに記録された動作を実行するように構成されたリカバリ制御ユニット2203と、をさらに含む。
【０１６９】
データ記憶構造およびデータ復元解決策に基づいて、本発明の一実施形態は、位置情報サービス記憶デバイスの拡張中、データ復元の解決策をさらに提供する。これは、具体的に以下のように記述される。さらに、リカバリ制御ユニット2203はまた、すべての位置情報サービス記憶デバイスの動作サポートシステムログを取得し、動作サポートシステムログの、取得されたレコードをフェッチし、フェッチされた現在のレコードがローカルエンド動作ベースのサービス記憶デバイスに属するのであれば、フェッチされた現在のレコードに対応する動作を実行するように構成される。
【０１７０】
本発明の一実施形態は、位置決めサーバ2301と位置情報サービス記憶デバイス2302とを含む、図23に図示されるような位置情報サービスシステムをさらに提供する。位置決めサーバ2301は、通信方式で、位置情報サービス記憶デバイス2302に接続されている。位置決めサーバ2301は、本発明の実施形態によって提供される位置決めサーバのうちの任意の1つであり、位置情報サービス記憶デバイス2302は、本発明の実施形態によって提供される、位置情報サービス記憶デバイス2302のうちの任意の1つである。
【０１７１】
本発明のこの実施形態では、地理的位置は、グリッド方式で分割され、分割後に取得されるグリッドは、位置情報の記憶のために使用される。そして、位置情報サービスの処理中、計算量を低減するように、緯度および経度は、距離を計算するために必要とされない。したがって、サーバ応答速度を向上させる。それに加えて、グリッドが位置情報サービス記憶デバイスに割り当てられている場合、使用される最小粒度は、グリッドよりも大きくなり、これによって、より多くの隣接グリッドが同じ位置情報サービス記憶デバイスに割り当てられるようになり、決定されたターゲットグリッドは、少数の位置情報サービス記憶デバイスに集中する。したがって、位置情報サービス記憶デバイスの呼び出しを減らし、位置情報サービス記憶デバイスの計算負荷を下げ、これによって、位置情報サービス全体のシステムパフォーマンスを向上させる。それに加えて、位置決め精度を高め、過度に大量の、単一のグリッドの位置情報によって引き起こされる衝突を低減するように、グリッドのサイズが小さくなるように設定され得る。
【０１７２】
図24は、本発明の一実施形態によって提供されるサーバの概要構成図である。サーバ2400は、異なる構成またはパフォーマンスを備えるように大きく変動し得、1つまたは複数の中央処理ユニット(CPU)2422、メモリ2432、および、アプリケーションプログラム2422またはデータ2444を記憶するための1つまたは複数の記憶媒体2430(たとえば、1つまたは複数の大容量記憶デバイス)を含み得る。メモリ2432および記憶媒体2430は、一時的または恒久的な記憶を提供し得る。記憶媒体2430に記憶されたアプリケーションプログラムは、1つまたは複数のモジュール(図面に図示せず)を含み得る。また、各モジュールは、サーバの一連の命令動作を含み得る。さらに、中央処理ユニット2422は、記憶媒体2430と通信するように設定され得る。そして、サーバ2400は、記憶媒体2430における一連の命令動作を実行する。
【０１７３】
サーバ2400は、1つまたは複数の電源2426、1つまたは複数の有線または無線ネットワークインターフェース2450、1つまたは複数の入力/出力インターフェース2458、および/または、たとえば、Windows Server(登録商標)、Mac OS X(登録商標)、Unix(登録商標)、Linux(登録商標)、FreeBSD(登録商標)等の1つまたは複数のオペレーティングシステム2441をさらに含み得る。
【０１７４】
前述した実施形態では、位置決めサーバまたは位置情報サービス記憶デバイスによって実行されるステップは、図24に図示されるようなサーバ構造に基づき得る。
【０１７５】
位置決めサーバおよび位置情報サービス記憶デバイスの前述した実施形態では、含まれるユニットが論理的な機能に基づいて分割されるが、対応する機能が実施され得る限り、ユニットの分割は、それに限定されないことが注目されるべきである。それに加えて、各機能ユニットの具体的な名称は、互いの識別を容易にするためだけのものであり、本発明の保護範囲を限定することは意図されていない。
【０１７６】
それに加えて、当業者であれば、前述した方法実施形態のステップのすべてまたはいくつかが、関連するハードウェアに命令するプログラムによって実施され得ることを理解することができる。プログラムは、コンピュータ可読記憶媒体に記憶され得る。記憶媒体は、読取専用メモリ、磁気ディスク、光ディスク等であり得る。
【０１７７】
以上の記載は、本開示のいくつかの好適で具体的な実施方式を図示しているに過ぎず、本開示の保護範囲を限定することは意図されていない。本発明の実施形態において開示された技術的範囲内において、当業者によって容易に得られるいかなる変更または置換も、本開示の保護範囲以内にあるものとする。したがって、本開示の保護範囲は、特許請求の範囲の保護範囲に従うものとする。
【符号の説明】
【０１７８】
1501  グリッド決定ユニット
1502  デバイス決定ユニット
1503  問合せユニット
1504  情報送信ユニット
1601  情報受信ユニット
1701  パケット組立てユニット
1801  位置決め制御ユニット
1901  要求受信ユニット
1902  データ記憶ユニット
1903  問合せユニット
1904  情報送信ユニット
2001  情報受信ユニット
2002  データ消去ユニット
2101  タイムアウトクリーニングユニット
2201  ログ記録ユニット
2202  ログクリーニングユニット
2203  リカバリ制御ユニット
2301  位置決めサーバ
2302  位置情報サービス記憶デバイス
2400  サーバ
2422  中央処理ユニット
2426  電源
2430  記憶媒体
2432  メモリ
2441  オペレーティングシステム
2442  アプリケーションプログラム
2444  データ
2450  有線または無線ネットワークインターフェース
2458  入力/出力インターフェース
【図１】
2017511066.tif 000003
【図２】
2017511066.tif 000004
【図３】
2017511066.tif 000005
【図４】
2017511066.tif 000006
【図５】
2017511066.tif 000007
【図６】
2017511066.tif 000008
【図７】
2017511066.tif 000009
【図８】
2017511066.tif 000010
【図９】
2017511066.tif 000011
【図１０】
2017511066.tif 000012
【図１１】
2017511066.tif 000013
【図１２】
2017511066.tif 000014
【図１３】
2017511066.tif 000015
【図１４】
2017511066.tif 000016
【図１５】
2017511066.tif 000017
【図１６】
2017511066.tif 000018
【図１７】
2017511066.tif 000019
【図１８】
2017511066.tif 000020
【図１９】
2017511066.tif 000021
【図２０】
2017511066.tif 000022
【図２１】
2017511066.tif 000023
【図２２】
2017511066.tif 000024
【図２３】
2017511066.tif 000025
【図２４】
2017511066.tif 000026
【国際調査報告】
2017511066.tif 000027
2017511066.tif 000028