JP2013513295A - 移動体通信デバイスのアプリケーションのためのシステムおよび方法 - Google Patents

Abstract

スマートフォンアプリケーションの機能は、データシンセサイザがデータポイントを必要としたベーシックフォンにデータシンセサイザを提供することにより、ベーシックフォン、すなわち特定のスマートフォン機能を備えていない電話機に拡張されてもよい。データシンセサイザは、近隣のスマートフォンと通信して、位置またはモーションデータのような関連するデータポイントを収集することができる。ベーシックフォンのデータポイントは、収集されたデータポイントから計算されてもよい。ベーシックフォンのアプリケーションがデータを要求すると、データプロバイダプロキシはデータシンセサイザから合成データポイントを取り出すことができる。１つの例において、ＧＰＳまたは類似する位置モジュールを備えていないベーシックフォンは、近隣のスマートフォンからの位置データを平均化することによりマッピングアプリケーションを実行することができる。

Description

本開示は、移動体通信デバイスのアプリケーションに関し、特に、限定されることなく位置データセンサを含む、データセンサからのデータを使用するアプリケーションに関する。

最新の携帯電話は、多くの場合、携帯電話内の拡張データセンサに依存するさまざまな拡張データアプリケーションが備えられている。そのような拡張データは、位置情報（たとえば、全地球測位システム（ＧＰＳ：Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）からの）、加速度計データ、および多くの場合スマートフォンと称される携帯電話がマッピングアプリケーションのようなさまざまなスマートアプリケーションを実行できるようにする他のタイプのデータを含むことができる。スマートフォンは、ますます広く普及が進んでいる。対照的に、ベーシックフォンおよびフィーチャーフォンは多くのスマートフォンの機能を備えていないので、多くの高機能アプリケーションに関与することもできず、そのユーザが多くの高機能アプリケーションの恩恵を受けることも不可能である。

この問題に対する従来の業界の解決策は、現在の回転率を約１８ヶ月としてデバイスの買い換えを待つことであり、必要な機能を備えるスマートフォンがさらに多く採用されるよう望むことである。代替的な解決策は、ブルートゥースＧＰＳデバイス、外部加速度計などのような、センサ／機能のための外部ハードウェアを追加することである。

必要とされるのは、さらに多数の移動体通信デバイスに拡張アプリケーションを提供するための改良されたアプリケーション、デバイス、および方法である。

本開示の１つの態様において、ベーシック移動体通信デバイスにおいてアプリケーションを実行するための方法が提供される。方法は、データ要求を生成するステップと、データ要求を少なくとも１つの拡張移動体通信デバイスに伝送するステップと、少なくとも１つの拡張移動体通信デバイスからデータを受信するステップと、ベーシック移動体通信デバイスの少なくとも１つのアプリケーションにおいてデータを処理するステップとを備える。

本開示の１つの態様において、少なくとも１つのアプリケーションと、少なくとも１つのデータシンセサイザとを備えるベーシック移動体通信デバイスが提供される。データシンセサイザは、少なくとも１つの移動体通信デバイスにデータを要求し、少なくとも１つの拡張移動体通信デバイスからデータを受信し、受信したデータから少なくとも１つのデータポイントを生成し、少なくとも１つのデータポイントをアプリケーションに提供するように構成されてもよい。

本開示の１つの態様において、少なくとも１つのデータセンサと、データプロバイダとを備える拡張移動体通信デバイスが提供される。データプロバイダは、ベーシック移動体通信デバイスからデータ要求を受信し、少なくとも１つのデータセンサからベーシック移動体通信デバイスにデータを提供するように構成されてもよい。

これ以降、ほんの一例として、具体的な実施形態および添付の図面が参照される。

複数のスマートフォンの近傍にあるベーシックフォンを示す図である。 ベーシックフォンでアプリケーションを実行するための方法を示す図である。 ベーシックフォンのコンポーネントおよびスマートフォンのコンポーネントを示す図である。 ベーシックフォンで実行しているアプリケーションにデータポイントを提供するためのプロセスを示す図である。 近隣のスマートフォンからデータポイントを収集するためのプロセスを示す図である。 データポイント要求メッセージの例示的な形式を示す図である。 データポイント応答メッセージの例示的な形式を示す図である。 ディスカバリ要求メッセージの例示的な形式を示す図である。 ディスカバリ応答メッセージの例示的な形式を示す図である。 近隣のスマートフォンのディスカバリのためのプロセスを示す図である。 ディスカバリ要求に応答するためのプロセスを示す図である。 データポイント要求に応答するためのプロセスを示す図である。 位置情報レコードの例示的な形式を示す図である。 加速度計情報レコードの例示的な形式を示す図である。

スマートフォンは、他の近隣のベーシックフォンが備えていないセンサデータを有することができる。「スマートフォン」（または拡張デバイス）、および「ベーシックフォン」（またはベーシックデバイス）という用語は、この状況を表すために使用される。すなわち、ベーシックフォンは、他の近隣の電話機（スマートフォン）で利用可能な一部の機能（拡張機能）またはセンサデータ（拡張データ）を備えていないが、任意の関与するデバイスがデバイスの一般的な説明においてスマートフォンであると見なされうることを理解されたい。

図１において、ベーシックフォン２０と比較して各々拡張機能を有するスマートフォン１２、１３、１４のグループ１８を有するシステム１０が示される。ベーシックフォン２０は、たとえばブルートゥース、ＷｉＦｉ、アドホックＷｉＦｉ、ＷｉＦｉ Ｄｉｒｅｃｔ、または一部の類似する狭域プロトコルを介してスマートフォン１２、１３、１４と直接通信することができるように構成されてもよい。本開示の実施形態は、ベーシックフォン２０が、どのようにして、近隣のスマートフォンからさまざまなデータ（たとえば、ＧＰＳ）を取得して、近隣のスマートフォンから受信した統計総合データに基づいて各自のデータを推論または合成することができるかを説明する。

本開示による、図２の流れ図１００に示される１つの方法において、ステップ１０１で、データ要求が生成され、狭域プロトコルを使用して１つまたは複数の近隣の拡張移動体通信デバイスに伝送される（ステップ１０２）。データは、拡張デバイスから受信され（ステップ１０３）、処理のためにアプリケーションに供給される（ステップ１０４）。

図３に示される１つの実施形態において、ベーシックフォン２０は、任意の数の拡張サービスアプリケーション２１で構成されてもよい。アプリケーション２１は、データプロバイダプロキシ２２を介して拡張サービスデータを要求することができる。データプロバイダプロキシ２２は、最近の収集データポイントリポジトリ２５、最近の合成データポイントリポジトリ２６、および近隣ノードリストリポジトリ２７を含むデータリポジトリを含むデータシンセサイザ２３から要求されたデータを取り出す。これらのリポジトリ２５、２６、２７は、たとえばデータベースのような、ローカルメモリまたは永続的ストレージであってもよい。

後段においてさらに詳細に説明されるように、データシンセサイザ２３は、本明細書においてスマートフォンと称され、ネットワークアクセスモジュール２９を介して通信する、近隣の拡張サービスフォンから受信したデータからアプリケーション２１のためのデータポイントを受信または生成する。１つのそのようなスマートフォン１２は図３において示されるが、任意の数のスマートフォンが、ベーシックフォン２０の近隣であると見なされてもよい。スマートフォン１２は、スマートフォンで実行するアプリケーション（図示せず）の拡張データを提供するために使用されるデータプロバイダ１６を含む。データプロバイダ１６は、ローカル環境データを記録するための１つまたは複数のセンサを組み入れることができる。センサの例は、位置センサ（たとえば、ＧＰＳモジュール）、モーションまたはデバイス方位センサ（たとえば、加速度計、デジタルコンパス、またはジャイロ）、温度センサ、画像センサ（たとえば、写真またはビデオ）、バイオメトリックセンサ（体温、脈拍数、血中酸素飽和度など）などを含むことができる。具体的な実施形態は、位置データおよび加速度計データを参照して説明されるが、本明細書において説明されるセンサのタイプの代替として、またはこれに加えて、多くの異なるタイプのセンサが使用されてもよいことが、当業者には明らかであろう。

前述のように、データプロバイダ１６は、ＧＰＳユニットまたは加速度計のような、位置を認識するモジュールであってもよいか、または任意の他の適切なデータプロバイダであってもよい。本開示の実施形態において、スマートフォン１２は、データプロバイダ１６から、ベーシックフォン２０のような近隣のベーシックフォンに拡張データを提供するように構成されるデータレスポンダ１７で構成されてもよい。データレスポンダ１７は、最近の応答リポジトリ１８、およびプライバシーポリシー１９で構成されてもよい。

図３の構成おいて、ベーシックフォン２０のアプリケーション２１は、通常はベーシックフォン２０では使用できない拡張サービスデータを要求することができる。たとえば、ＧＰＳに対応していないベーシックフォンは、十分なスマートフォンと近隣のコンタクトをとっている間、近隣のスマートフォンから必要なＧＰＳデータを合成するアプリケーション（たとえば、マッピングプログラム）を実行することができる。それにより、通常であれはベーシックフォン２０のユーザには利用できないマッピングアプリケーションがベーシックフォン２０で使用可能になる。

近隣の電話機は、動的に識別されてもよく、識別は、近傍にある期間にわたり存続することができる。さまざまな実施形態において、識別は匿名であってもよい、すなわち、近隣のスマートフォンが一部のデータの着信要求に応答する際に一意のＩＤを生成することができ、（フォローアップ要求のない）十分な時間の経過後に、近隣のスマートフォンがそのＩＤを削除して再使用できないようにすることができる。そのような実施形態により、スマートフォンは、受信側に過剰な情報をもたらすことなく、有用なデータ（たとえば、ＧＰＳ、加速度計など）を共有することができる。

ベーシックフォン２０のデータシンセサイザ２３は、ベーシックフォン２０のさまざまなアプリケーション２１によって使用されるデータポイントを収集、格納、および／または合成する。ベーシックフォン２０のアプリケーション２１にデータポイントを提供するための例示的なプロセスは、図４の流れ図２００に示される。ステップ２０１において、アプリケーション２１は、拡張データの要求を行なう。拡張データはベーシックフォン２０では使用できないので、データプロバイダプロキシ２２は、要求をデータシンセサイザ２３に転送する（ステップ２０２）。データシンセサイザ２３は、要求を受信し（ステップ２０３）、最近の収集データポイントリポジトリ２５から最近の収集データポイントのサブセットを選択する（ステップ２０４）。最近の収集データポイントの選択は、データポイントがどの程度最近であるか（たとえば、タイムスタンプから決定される）、データポイントの多様性（複数の近隣デバイスからデータポイントを収集）、およびデータポイント自身の特性（たとえば、ＧＰＳデータポイントが、ｉ）選択セット内のデータポイント、またはｉｉ）以前合成されたデータポイント、もしくはその組み合わせに対してどの程度近いか／遠いか）のような基準に基づいてもよい。ステップ２０５において、一部の最近合成されたデータポイントは、オプションで、最近合成されたデータポイントリポジトリ２６からの選択に追加されてもよい。次いで、データシンセサイザは、選択されたデータポイントのセットを評価して（ステップ２０６）、データポイントの品質が十分に高いか、および古すぎないかどうかを決定する。データポイントの評価が要求を満たす場合、新しいデータポイントが、収集されたデータポイントから合成されてもよい（ステップ２０７）。たとえば、新しい位置データポイントは、近隣デバイスから収集された位置データポイントの平均位置により計算されてもよい。新しい加速度計データポイントは、最長でベーシックフォンの近傍にあった近隣デバイスから最新の加速度計データポイントを複製することによって計算されてもよい。新しいデータポイントは、データプロバイダプロキシ２２を介して合成されたデータポイントを要求側アプリケーション２１に返す（ステップ２０９）前に、最近合成されたデータポイント２６のリポジトリに追加され（ステップ２０８）、その後プロセスは終了する２１０。

ステップ２０６において、選択されたデータポイントの評価が品質の要件を満たさない場合、データポイント選択基準を拡大しようとする試みが行なわれてもよい（ステップ２１１）。選択基準が拡大される場合、プロセスは、データポイントの新しい選択を生成するためにステップ２０４に戻る。それ以外の場合、最近合成されたデータポイントリポジトリ２６からの最新に合成されたデータポイントが十分に新しいものであると決定される場合（ステップ２１２）、このデータポイントがアプリケーションに返されてもよい（ステップ２１３）。最新の合成されたデータポイントが古すぎる場合、データシンセサイザは、アプリケーション２１によりそのプログラミングに従って処理されうるエラーを返す（ステップ２１４）。

近隣ノードからデータポイントを収集するためのプロセスは、図５の流れ図３００に示される。ステップ３０１において、データポイント収集が、たとえばタイムアウト、最近収集されたデータポイントの経過時間、アプリケーション要求などに基づいてトリガされる。次いで、データシンセサイザは、たとえば近隣ノードリスト２７から、近隣ノードを選択する（ステップ３０２）。選択されるノードの数を制限するために、ノードからの最新の応答の時間のような基準は確立されてもよい。基準はまた、連続する一貫性のあるデータポイントのストリームを収集するために、以前の応答性に優れたノードを含めるように偏らせることもできる。ノードの数を制限することで、データポイントを合成するためにわずかなノードしか必要とされない場合に過剰なノードにコンタクトがとられることを防ぐ。

ステップ３０３において決定されるように、選択セットに十分なノードがある場合、データポイント要求メッセージはそれらのノードの各々に送信される（ステップ３０４）。データポイント要求メッセージ（Ｄａｔａｐｏｉｎｔ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅ）６０の例を図６に示す。データポイント要求メッセージ６０は、ベーシックフォンＩＤ６１、すなわち要求側電話機のＩＤ、要求ＩＤ６２、および位置データポイント、加速度計データなどのような要求データポイントタイプ６３の指示を含む。データシンセサイザ２３は、以下でさらに詳細に説明される、データポイント要求メッセージ６０に応答してデータポイント応答メッセージ７０（図７）を受信し、ステップ３０５において、受信される各データポイントは、最近の収集データポイントリポジトリ２５に記録される。任意の非応答ノードは、プロセスが終了する３０７前に、ステップ３０６において、近隣ノードリスト２７からオプションで削除されてもよい。ステップ３０３で、選択されたノードセットに十分なノードがないと決定する場合、近隣ノードを再選択する前に、選択基準は、近隣ノードリスト２８から拡大されてもよい（ステップ３０８）。ノード選択基準の拡大が可能ではない場合、すべてのノードが選択され、データポイント要求メッセージの送信（ステップ３０４）に進む前に、データシンセサイザ２３は、使用可能なノードを拡大するために、近隣ノードディスカバリプロセス（以下で説明）がデータ収集プロセスにより要求されることを記録することができる。

これ以降、近隣ノードを検出するための例示的なプロセスが、図１０の流れ図４００を参照して説明される。ステップ４０１において、ノードディスカバリプロセスは、タイムアウト、イベント（たとえば、データ合成処理からの）によって、または近隣ノードリスト２７のノードが少なすぎることなどにより、トリガされる。データシンセサイザ２３は、ディスカバリ要求メッセージ（Ｄｉｓｃｏｖｅｒｙ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅ）を生成し、その例示的な形式８０が図８に示される。ディスカバリ要求メッセージ８０は、ベーシックフォンＩＤ８１、要求ＩＤ８２、要求データポイントプロバイダタイプ（Ｄａｔａｐｏｉｎｔ Ｐｒｏｖｉｄｅｒ Ｔｙｐｅｓ）フィールド８３、および既存データプロバイダタイプ（Ｅｘｉｓｔｉｎｇ Ｄａｔａｐｏｉｎｔ Ｐｒｏｖｉｄｅｒ Ｔｙｐｅｓ）フィールド８４を含む。ノードディスカバリ要求は、１ホップしか離れていないスマートフォンを見つけるためにルーティング不可能であるように構成されるが、要求はブロードキャスト、マルチキャスト、またはユニキャストされてもよい。ディスカバリ要求メッセージ８０は、ネットワークアクセスモジュール２９により、ブルートゥース、ＷｉＦｉ、アドホックＷｉＦｉ、ＷｉＦｉ Ｄｉｒｅｃｔなどのような、ローカルネットワークタイプを介して送信されてもよい。

上記で説明されるプロセスは一般に、ベーシックフォン２０の観点から説明される。これ以降、スマートフォンの観点からプロセスが説明される。

これ以降、スマートフォンによりディスカバリ要求に応答するためのプロセスが、図１１の流れ図５００を参照して説明される。ディスカバリ要求メッセージ８０は、ステップ５０１において、スマートフォン１２のデータレスポンダ１７によってベーシックフォンから受信される。データレスポンダ１７は、ディスカバリ要求メッセージ８０のベーシックフォンＩＤ８１および要求ＩＤ８２を検討し、以前受信した要求の重複があるかどうか決定する（ステップ５０２）。重複のシナリオがある場合、アクションは行なわれず、プロセスは終了する（ステップ５１０）。それ以外の場合、データレスポンダ１７は、最近の応答リスト１８の検討に進み、要求メッセージ８０のベーシックフォンＩＤ８１がリスト１８にある場合（ステップ５０３）、応答メッセージ９０で同じ応答側電話機ＩＤが再使用される（ステップ５０４）。ベーシックフォンＩＤが存在しない場合、データレスポンダ１７は、新しい応答側電話機ＩＤを生成し（ステップ５１１）、ディスカバリ応答メッセージ９０の応答側電話機ＩＤ（Ｒｅｓｐｏｎｄｉｎｇ Ｐｈｏｎｅ ＩＤ）フィールド９２にこのＩＤを追加する。次いで、データレスポンダ１７は、要求メッセージ８０が要求データポイントプロバイダタイプフィールド８３を含むかどうか決定する（ステップ５０５）。このフィールドは、どの特定のデータポイントタイプをベーシックフォンが要求しているか（たとえば、位置タイプデータ（ＧＰＳまたは同様のもの）、加速度計タイプデータなどを示す。データレスポンダ１７は、ステップ５０６において、任意の要求されたデータポイントプロバイダを、ディスカバリ応答メッセージ９０のフィールド９３に追加する。ディスカバリ応答メッセージ９０が空ではない、すなわち現在任意のデータポイントプロバイダを含む場合（ステップ５０７）、メッセージ９０はベーシックフォンに送信され（ステップ５０８）、送信されたメッセージは、プロセスが完了する（ステップ５１０））前に最近の応答リスト１８に記録される（ステップ５０９）。ステップ５０７において、データポイントプロバイダが追加されていない場合、データレスポンダ１７は、プロセスが完了する（ステップ５１０）前にローカルクリーンアップ以外のアクションをそれ以上は行なわない（ステップ５１４）。

ステップ５０５において、ディスカバリ応答メッセージ９０が関連する要求データポイントプロバイダタイプフィールド８３も既存データポイントプロバイダタイプフィールド８４も含まないとデータレスポンダ１７が決定する場合、さらなるアクションは行なわれない（ステップ５１４）。既存データポイントプロバイダタイプ８４は、ベーシックフォンがどのデータセンサを既に有しているか（たとえば、位置（ＧＰＳまたは同様のもの）、加速度計など）を近隣のスマートフォンに知らせるこのフィールドを、ベーシックフォンが送出する代替のプロトコルを可能にするフィールドである。次いで、スマートフォンは、ベーシックフォンが有していない「任意の他のセンサタイプ」を有する場合、応答することが期待される。それにより、現時点で予測されていない未来のセンサタイプがスマートフォンデバイスに表示され、プロトコルを変更することなくベーシックフォンで新しいアプリケーションに組み入れられるようにすることができる。したがって、次いで、既存データポイントプロバイダタイプフィールド８４が指示される場合、既存データポイントプロバイダタイプ８４にまだリストされていない任意のデータポイントプロバイダタイプ（すなわち、ベーシックフォンが既存データポイントプロバイダタイプ８４に有すると指示したセンサタイプに加えて、スマートフォンが有するセンサタイプ）が追加され（ステップ５１３）、プロセスは上記で説明されるステップ５０７へと進む。

これ以降、データポイント要求に応答するためにスマートフォンまたはその他の拡張サービスデバイスによって行なわれるプロセスが、図１２の流れ図６００を参照して説明される。ステップ６０１において、スマートフォン１２のデータレスポンダ１７は、データポイント要求メッセージ６０をベーシックフォン２０から受信する。データレスポンダ１７は、要求メッセージ６０に指示されたベーシックフォンＩＤ６１を最近の応答リスト１８の中から探す。ベーシックフォンＩＤが見つからない場合、さらなるアクションは行なわれない（ステップ６０９）。このことはスマートフォンがまだ検出されていないか、またはスマートフォンが検出され、長期の非アクティブ状態を経て最近の要求がスマートフォンのリストから脱落した、ブロードキャスト／マルチキャストデータポイント要求を近隣のスマートフォンが受信している場合を表す。ベーシックフォンＩＤが見つからない場合に、最近の応答リストを確認して、さらなるアクションを行なわないことは、わずかなデータポイントしか必要とされない場合に、すべてのスマートフォンがブロードキャスト／マルチキャスト要求を受信して応答することを防ぐ。プロセス６００に図示されていないのは、図１１を参照して説明されるディスカバリ応答プロセス５００に関連して説明される重複検査と類似することもあるオプションの重複検査要求である。

ベーシックフォンＩＤが最近の応答リスト１８で識別される場合、データレスポンダ１７は、データポイント要求メッセージ６０のフィールド６２に示されるＩＤと同じ要求ＩＤ７１、および最近の応答リスト１８に指示されるＩＤと同じ応答側電話機ＩＤ７２を含むデータポイント応答メッセージ７０（図７）を生成する。ステップ６０４において決定されるように、要求６０のフィールド６３において指示されるデータポイントタイプのデータポイントが使用可能ではない場合、さらなるアクションは行なわれない（ステップ６０９）。要求されたタイプに対してデータポイントが使用可能である場合、データポイントがサンプリングされ、タイプフィールド７３、７４などのように、データポイント応答メッセージ７０に追加される（ステップ６０５）。追加されるデータポイントは、データレスポンダ１７がタイプのデータを定期的にサンプリングして、最新のデータポイントを保持する場合、（タイプごとに）単一データポイントであってよいし、または（タイプごとに）最近のデータポイントのリストであってもよい。データ応答メッセージ７０が完成すると、データ応答メッセージ７０はベーシックフォン２０に送信され（ステップ６０６）、プロセスが完了する（ステップ６０８）前に最近の応答リスト１８に記録される（ステップ６０７）。

データポイント要求メッセージ６０およびディスカバリ要求メッセージ８０は、ネットワークアクセスモジュール２９を介して、ベーシックフォンＩＤ２０のデータシンセサイザモジュール２３から拡張サービスデバイス１２のデータプロバイダ１７へと渡す。データポイント応答メッセージ７０およびディスカバリ応答メッセージ９０は、戻りの方向に渡す。これらのメッセージは、ユニキャスト電話間、マルチキャスト、またはブロードキャストのいずれかに合わせて設計されてもよい。要求がブロードキャストまたはマルチキャストされる場合、上記で別個に説明されているディスカバリ応答プロセス５００およびデータポイント応答プロセス６００は、単一のプロセスに結合されてもよい。そのような場合、ブロードキャスト／マルチキャスト要求は、暗黙的なディスカバリ要求として機能することができる。

データポイント要求メッセージ７０で搬送されるデータポイントの例を図１３および図１４に示す。位置情報レコード１３０は、位置データポイントを搬送することができ、応答側電話機ＩＤ１３１、ソースタイプ（たとえば、ＧＰＳ）１３２、タイムスタンプ１３３，経度１３４、緯度１３５、高度１３６、精度低下率１３７のフィールドを含むことができる。精度低下率１３７は、データ値の精度の可能なエラーに関連して増大する数値である。この値は、ｉ）センサデータタイププロバイダ「内部」情報（たとえば、位置情報レコードの場合、値はＧＰＳデータサンプルから導き出され、サンプルのデータを提供するＧＰＳ衛星の幾何学的方向に部分的に基づくＧＰＳ「精度低下率（ＤＯＰ）」値に対応してもよい）、またはｉｉ）データレスポンダ１７が、サンプリングされたデータ値の低下を生じる（たとえば、位置情報レコードの場合、経度１３４、緯度１３５、および／または高度１３６のサンプリングデータ値は、適用可能なプライバシーポリシー１９によりデータレスポンダ１７によって低下されることもあり、精度低下率１３７値が提供されてもよい）適用可能なプライバシーポリシー１９（たとえば、１０メートル未満の精度または２未満のＧＰＳ ＤＯＰ値を有するデータポイントを提供しないというプライバシーポリシーを有するＧＰＳ装備のスマートフォン）によりこの値を生成することができる、またはｉｉｉ）前述の両方（基礎となるセンサデータタイプが低下測度を提供し、適用可能なプライバシーポリシーによりレスポンダが追加のエラーをデータ値に追加する場合、データレスポンダはこの両者に基づいて精度の低下率を生成することができる）の結果得られてもよい。同様に、加速度計情報レコード１４０（図１４）は、応答側電話機ＩＤ１４１、ソースタイプ１４２、タイムスタンプ１４３、ｘ値１４４、ｙ値１４５、ｚ値１４６、および精度低下率１４７のフィールドを含むことができる。プライバシーポリシー１９によって導入された低下率の量は、ベーシックフォンの認証済みの識別に依存することができ、すなわち、ベーシックフォンがスマートフォンに以前登録した認証済みの識別を提供する場合、スマートフォンのプライバシーポリシー１９は低下をほとんど、または全く導入しない。

代替的な実施形態において、データプロバイダプロキシ２２およびデータシンセサイザモジュール２３は、各アプリケーション２１において組み入れられてもよい。これは一部の状況において最適ではない場合もあるが、電話オペレーティングシステムにそれらのモジュールを別個にインストールする必要がないので、一般的な実施態様としてアプリケーションで配置されてもよい。

代替的な実施形態において、サンプルデータは、合成データポイント（複数可）を計算するために、サーバ（または近隣のスマートフォン）に送信されてもよい。

上記で説明される機能を使用できるアプリケーションの例は、加速度計を必要とするエクササイズアプリケーションを含む。エクササイズアプリケーションは、ベーシックフォンのユーザが、スマートフォンを有する別のジョギングをする人の付近でジョギングをしている間、ベーシックフォンで動作することができる。加速度計データは、スマートフォンからベーシックフォンに転送されて、エクササイズアプリケーションが実行できるようにすることができる。さらなる例は、近隣のＧＰＳ装備のスマートフォン（ＧＰＳまたは類似する位置サービス）に基づいて高い精度でベーシックフォンで動作することができるマッピングアプリケーションである。さらなる例は、ベーシックフォンで動作し、レース参加者に気象データ（気温、風、降水量）およびルート状況（乾燥、湿気、凍結の表面条件、ルート障害物、競争者の位置）を表示するレース補助アプリケーションであり、サポートチームメンバーに携帯されるスマートフォンがそれらの位置、速度、画像、天気、およびビデオセンサからデータポイントを収集する。

拡張サービス電話からベーシックフォンに転送されうるその他のタイプのセンサデータは、イベント（たとえば、コンサート／講演）を記録するか、または背景騒音をサンプリングして環境を分類するためのオーディオ、フォトまたはビデオ（たとえば、ベーシックフォンがカメラ機能を有していないが、拡張サービスフォンからフォトまたはビデオデータを受信する場合）、デジタルコンパス、気温、周辺光赤外線センサ、およびネットワークレベルＩＤ（たとえば、ＷｉＦｉ対応ではないベーシックフォンは、近隣のスマートフォンのＷｉＦｉ信号を使用して、たとえば聴取したネットワークＳＩＤなど、ＷｉＦｉ信号に基づくマッピングを提供するアプリケーションを使用可能にすることができる）を含む。

すべての電話機が近隣のデータ（たとえば、近隣のスマートフォンのセンサデータ）をサンプリングできるようにすることにより、わずかな数のスマートフォンだけでそれらの機能を大きなグループに提供できるようになる。

新しい機能および高機能アプリケーションをベーシックフォンのユーザに提供することに加えて、特定のアプリケーションもまた、追加の参加ユーザを得ることによって上記で説明される実施形態から恩恵を受けることができる。たとえば、交通信号機における長い列、またはショッピングモールにおけるレジ順番待ちの列をレポートするアプリケーションは、アプリケーションに参加するデバイスのより大きな密度を達成することにより、待ち時間推定の精度を高めることができるので利益を得ることになる。具体的には、１０人が列に並んでいるが、そのうち３人だけが位置情報を備えるスマートフォンを有している場合、待ち時間推定は、それらの３人に基づいて計算される。しかし、他の７人が近隣のスマートフォンの位置機能を入手する場合、列に並ぶ１０人全員が含まれることになり、待ち時間推定はさらに精度が高まる。したがって、待ち時間推定を実行するこのアプリケーションは、スマートフォンおよびベーシックフォンの両方で実行することができる。

上記で説明される例から、高機能アプリケーションは、ベーシックフォンがスマートフォンに代替されるまで待つことなく、改良されうることがわかる。ベーシックフォンのユーザは、近隣のスマートフォンユーザの恩恵を受けることができる。

ベーシックフォン２０で実行するアプリケーションは、ベーシックフォン２０のデータ機能を認識していても、認識していなくてもよい。データプロバイダプロキシは、データ要求を処理するように構成されてもよく、一部のアプリケーションの場合、ローカルデータセンサからデータを取り出してもよく、また別のアプリケーションの場合、上記で説明される方法を使用してデータシンセサイザ２３を通じてデータを取り出してもよい。

システム１０のコンポーネントは、ハードウェア、ソフトウェア、ファームウェア、またはハードウェア、ソフトウェア、および／またはファームウェアの組み合わせで具現されてもよい。たとえば、アプリケーション２１は、読み取り専用メモリ（ＲＯＭ）またはフラッシュメモリのような、ベーシックフォン２０のメモリに格納されうるコンピュータ実行可能命令として提供されてもよい。ベーシックフォンは通常、ベーシックフォン２０の機能を実行するための少なくとも１つのプロセッサを含む。そのようなプロセッサはまた、アプリケーションの機能を実行するためのソフトウェア命令を実行することもできる。同様に、ベーシックフォンは、データプロバイダプロキシ２２およびデータシンセサイザ２３の機能を提供することができるソフトウェアを装備されてもよい。

同様の方法で、図３のスマートフォン１２のような拡張サービスを有する電話機は通常、少なくとも１つのプロセッサを含み、データレスポンダ１７の機能を提供するための実行可能命令を格納することができる。

ベーシックフォン２０は、本明細書において、最小の機能を有するものとして、および近隣のスマートフォンから拡張サービスデータを取り出すものとして説明されているが、ベーシックフォン２０はまた、ベーシックフォン内で各自のセンサによりローカルに生成されたデータを使用してそのユーザに一部の拡張データサービスを提供するスマートフォンであってもよい。しかし、スマートフォンは、特定のセンサで構成されなくてもよく、したがって必要とされるセンサを有する他の近隣のスマートフォンから特定のアプリケーションのためのデータポイントを生成することができる。１つの例は、デジタルコンパスセンサのないｉＰｈｏｎｅ ３Ｇであり、これは近隣のｉＰｈｏｎｅ ３ＧＳデバイスからのデジタルコンパスデータを使用することができる。このシナリオにおいて、いずれのデバイスも一般にスマートフォンと呼ばれているが、ｉＰｈｏｎｅ ３Ｇは、欠けている機能を提供することにより「スマートフォン」の役割を果たすｉＰｈｏｎｅ ３ＧＳ電話機に関して「ベーシックフォン」の役割にある。

本明細書の実施形態は、添付の図を参照して示され、前述の説明において述べられてきたが、本発明が開示される実施形態に限定されることはなく、多数の再編成、変更、および代替が、添付の特許請求の範囲に示され定義される発明の精神を逸脱することなく行なうことができることを理解されたい。たとえば、本発明の機能は、１つまたは複数のブロック、モジュール、プロセッサ、またはメモリによって完全に、および／または部分的に実行されてもよい。また、それらの機能は、現在の方法で、または分散の方法で、および情報を提供および／または受信することができる任意のデバイス上またはデバイスを介して実行されてもよい。さらに、特定の方法で示されているが、さまざまなモジュールまたはブロックは、本発明の範囲を逸脱することなく再配置されてもよい。さらになお、特定の方法で示されているが、本発明を達成するために、より多い数またはより少ない数のモジュールおよび接続が本発明で使用されて、本発明に追加の既知の特徴を提供することができる、および／または本発明をさらに効率的にすることができる。また、さまざまなモジュール間で送信される情報は、データネットワーク、インターネット、インターネットプロトコルネットワーク、無線ソース、および有線ソースのうちの少なくとも１つを介して、および複数のプロトコルを介して、モジュール間で送信されてもよい。

Claims (20)

1. ベーシック移動体通信デバイスでアプリケーションを実行するための方法であって、
   データ要求を生成するステップと、
   前記データ要求を、少なくとも１つの拡張移動体通信デバイスに伝送するステップと、
   データを前記少なくとも１つの拡張移動体通信デバイスから受信するステップと、
   前記データを前記ベーシック移動体通信デバイスの少なくとも１つのアプリケーションで処理するステップと
   を備えることを特徴とする方法。
2. 前記少なくとも１つのアプリケーションは、マッピングアプリケーションを備え、前記データ要求は、位置データの要求を備えることを特徴とする請求項１に記載の方法。
3. 前記アプリケーションは、モーションアプリケーションを備え、前記データ要求は、モーションデータの要求を備えることを特徴とする請求項１に記載の方法。
4. 前記データ要求を生成するステップは、前記ベーシック移動体通信デバイスで使用可能ではない少なくとも１つの拡張データサービスのために拡張移動体通信デバイスから拡張データを要求するステップを備えることを特徴とする請求項１に記載の方法。
5. 前記ベーシック移動体通信デバイスにおいて１つまたは複数の拡張移動体通信デバイスから拡張データを受信するステップと、
   少なくとも１つのデータポイントを前記受信した拡張データから合成するステップと、
   前記少なくとも１つの合成されたデータポイントを前記アプリケーションで使用するステップと
   を備えることを特徴とする請求項４に記載の方法。
6. データポイントを合成するステップは、前記１つまたは複数の拡張移動体通信デバイスからの複数の受信したデータを平均化するステップを備えることを特徴とする請求項５に記載の方法。
7. １つまたは複数の近隣の拡張移動体通信デバイスを検出するステップを備えることを特徴とする請求項１に記載の方法。
8. 前記データ要求を伝送するステップは、狭域通信プロトコルにわたり前記データを伝送するステップを備えることを特徴とする請求項１に記載の方法。
9. 少なくとも１つのアプリケーションと、
   少なくとも１つの拡張移動体通信デバイスにデータを要求し、
   前記少なくとも１つの拡張移動体通信デバイスからデータを受信し、
   前記受信したデータから少なくとも１つのデータポイントを生成し、
   前記少なくとも１つのデータポイントを前記アプリケーションに提供する
   ように構成された少なくとも１つのデータシンセサイザと
   を備えることを特徴とするベーシック移動体通信デバイス。
10. 前記少なくとも１つのアプリケーションからデータ要求を受信し、
    前記データ要求を前記データシンセサイザに提供するように構成されたデータプロバイダプロキシを備えることを特徴とする請求項９に記載のベーシック移動体通信デバイス。
11. 前記データシンセサイザは、前記少なくとも１つの拡張移動体通信デバイスから受信した前記データから位置データポイントを生成するように構成されることを特徴とする請求項９に記載のベーシック移動体通信デバイス。
12. 前記データシンセサイザは、前記少なくとも１つの拡張移動体通信デバイスから受信した前記データからモーションデータポイントを生成するように構成されることを特徴とする請求項９に記載のベーシック移動体通信デバイス。
13. 前記データシンセサイザは、
    １つまたは複数の拡張移動体通信デバイスから受信した１つまたは複数のデータポイントを格納する収集データポイントリポジトリと、
    １つまたは複数の収集されたデータポイントから合成された１つまたは複数の合成データポイントを格納する合成データポイントリポジトリと
    を備えることを特徴とする請求項９に記載のベーシック移動体通信デバイス。
14. 前記データシンセサイザは、近隣の拡張移動体通信デバイスを検出し、前記近隣の拡張移動体通信デバイスの識別を格納するように構成されることを特徴とする請求項９に記載のベーシック移動体通信デバイス。
15. １つまたは複数の拡張移動体通信デバイスとの狭域通信のために構成されたネットワークアクセスモジュールを備えることを特徴とする請求項９に記載のベーシック移動体通信デバイス。
16. 前記少なくとも１つのアプリケーションは、前記少なくとも１つのデータシンセサイザを備えることを特徴とする請求項９に記載のベーシック移動体通信デバイス。
17. 少なくとも１つのデータセンサと、
    ベーシック移動体通信デバイスからデータ要求を受信し、
    前記少なくとも１つのデータセンサからデータを前記ベーシック移動体通信デバイスに提供する
    ように構成されたデータレスポンダと
    を備えることを特徴とする拡張移動体通信デバイス。
18. 前記少なくとも１つのデータセンサは、全地球測位システムモジュールおよび加速度計のうちの少なくとも１つを備えることを特徴とする請求項１７に記載の拡張移動体通信デバイス。
19. 前記データレスポンダは、応答側電話機識別を生成し、前記応答側電話機識別を前記ベーシック移動体通信デバイスに提供するように構成され、前記応答側電話機識別は動的識別であることを特徴とする請求項１７に記載の拡張移動体通信デバイス。
20. プライバシーポリシーを格納するように構成され、前記データレスポンダは、前記プライバシーポリシーを前記ベーシック移動体通信デバイスに適用するように構成され、前記プライバシーポリシーの前記適用は、前記ベーシック移動体通信デバイスに送信された前記データにエラーを導入することを特徴とする請求項１７に記載の拡張移動体通信デバイス。

Images