JP4257067B2

JP4257067B2 - ハンドヘルドデバイスの能力拡張方法及びシステム

Info

Publication number: JP4257067B2
Application number: JP2002090210A
Authority: JP
Inventors: ザングジュンビアーオ
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2001-09-18
Filing date: 2002-03-28
Publication date: 2009-04-22
Anticipated expiration: 2022-03-28
Also published as: US20030054794A1; JP2003091341A; US7536182B2

Description

【０００１】
【発明の属する技術分野】
本発明は、ハンドヘルドデバイスに関し、特に、付近のデバイスを使用することによりハンドヘルドデバイスの拡張するためのヘルパー環境に関する。
【０００２】
【従来の技術】
ディジタルハンドヘルドデバイス、例えば、以下のものには限定されないが、携帯情報端末（ＰＤＡ）、携帯電話機、ディジタルカメラおよびポータブルＭＰ３プレーヤなどは、われわれの日常生活の一部となっている。各種のハンドヘルドデバイスはそれぞれ固有の特性を有するが、それらは一般に、サイズが小さいこと、モバイル環境で利用されること、および、データ処理エンジンを含むことというような共通の特徴を共有する。これらの共通の特徴は、ハンドヘルドデバイスを非常に有用できわめて人気のあるものにしているが、これらのデバイスにとってよい前兆ではないもう１つの共通性がある。すなわち、これらのデバイスは一般に、能力が制限され、特に、ディスプレイ画面、記憶スペースおよびネットワークアクセスに関して制限されることである。小さい画面サイズのような、これらの制限のうちのいくつかは、これらのデバイスの利用法モデルが与えられている場合には、改善するのが本質的に困難である。しばしば、ハンドヘルドデバイスは、上記の制限を受けない固定デバイスの近くで使用される。したがって、この技術分野で必要とされているのは、ハンドヘルドデバイスが、その小さいサイズやモビリティのような好ましい特性を犠牲にすることなく、付近の固定デバイスの高い能力を利用するためのフレームワークである。
【０００３】
ハンドヘルドデバイスと付近の固定デバイスとの間のインタラクションを促進することに向けて、これまでにいくつかの試みがある。例えば、ＡＴ＆Ｔ^TM研究所は、アプリケーションが動作するコンピュータではなく、アプリケーションインタフェースが移動することができるような、テレポーティングシステム(teleporting system)を開発した。テレポーティングシステムは、プロキシサーバを用いて実装される。ユーザのアプリケーションはすべて、正規のサーバの代わりにこのプロキシサーバに接続される。これにより、プロキシサーバは、ユーザ入出力を、ユーザの要求に従って異なるディスプレイに転送(reroute)することができる。テレポーティングモデルのもう１つの改良点は、ユーザ位置を識別するために、複数の部屋でセンサとともにディジタルバッジを使用することである。これにより、ユーザディスプレイは、ユーザに最も近いディスプレイに自動的に転送されることが可能となる。
【０００４】
その後、より一般化された形のテレポーティングであるＶＮＣ(Virtual Network Computing)プラットフォームが開発されている。これは、テレポーティングシステムを相異なるウィンドウズ（登録商標）環境に拡張することによって、クロスプラットフォーム動作をサポートしている。テレポーティングモデルとＶＮＣプラットフォームはいずれも、ユーザが、コンピューティング「デスクトップ」環境を、それが動作しているマシン上でのみならず、モバイルデバイスからも見ることができるような、リモートディスプレイシステムに焦点を当てている。
【０００５】
テレポーティングモデルおよびＶＮＣプラットフォームの両方の欠点は、これらがユーザインタフェースを、もとのデバイスと同様の能力を有するディスプレイデバイスに移行（マイグレーション）するように設計されていることである。テレポーティングモデルおよびＶＮＣプラットフォームの両方のもう１つの欠点は、これらがディスプレイマイグレーションを実行するだけであることである。
【０００６】
カーネギーメロン大学のPebblesプロジェクトは、ハンドヘルドデバイスと付近の固定デバイスとの間のインタラクションを促進することに向けたもう１つの試みを代表するものである。Pebblesプロジェクトは、ネットワーク環境における固定コンピュータへのアジャンクト（付属装置）としてＰＤＡを使用する可能性を探求している。プロジェクトの一部として、いくつかのアプリケーションが開発されている。例えば、SlideShow Commanderアプリケーションは、ＰＤＡが、ＰＤＡからのプレゼンテーションを管理するリモートコントロールデバイスとして作用することを可能にする。リモートクリップボードやリモートマウスのような他のアプリケーションも、必要なソフトウェアパッケージをＰＤＡおよびコンピュータの両方にインストールすることによって使用可能である。
【０００７】
【発明が解決しようとする課題】
Pebblesプロジェクトはヘルパー概念を具現化しているが、ヘルパーの役割は、ＰＤＡによって果たされている。ＰＤＡは、固定デバイスにとって有益な周辺デバイスとして使用されている。一般に、PebblesプロジェクトにおけるＰＤＡは、制御の目的のために使用される。Pebblesプロジェクトの欠点は、新たなアプリケーションを追加する場合に、ＰＤＡおよび固定デバイスの両方に追加ソフトウェアをインストールすることが必要なことである。
【０００８】
【課題を解決するための手段】
したがって、本発明の目的および効果は、ハンドヘルドモバイルデバイスが、その制限された能力を拡張するために、その環境、その周りのデバイスを識別し利用することができるようなフレームワークを提供することである。このようなフレームワークを「ヘルパー環境」といい、ヘルパー環境によって提供されるサービスを「ヘルパーサービス」あるいは「拡張サービス」といい、このようなサービスを提供するデバイスを「ヘルパーサーバ」という。ヘルパー環境において実行されるタスクを一般に「拡張タスク」という。
【０００９】
本発明のもう１つの目的および効果は、ハンドヘルドデバイスが制御およびデータの両方について中心となるような、表示、印刷、記憶およびネットワーキングなどのさまざまな能力拡張をサポートする一般的フレームワークを提供することである。
【００１０】
本発明のもう１つの目的および効果は、供給されるヘルパーサービスに対する固有のあるいは特定のリモート制御インタフェースをヘルパーサーバが管理するため、固有のあるいは特定のリモート制御インタフェースをハンドヘルドデバイスが管理する必要のない、一般的なリモート制御メカニズムを提供することである。ヘルパーサービスを利用するとき、ハンドヘルドデバイスは、ヘルパーサーバによって供給されるインタフェース記述に基づいて、アプリケーション固有のインタフェースを構成することができる。また、ハンドヘルドデバイスのインタフェースとのユーザインタラクションは、ハンドヘルドデバイスによって解釈されるのではなく、解釈のためにヘルパーサーバに返される。その結果、ヘルパーサーバに対するヘルパーサービスの追加や変更は、ハンドヘルドデバイス上のアプリケーションの追加や変更を必要としない。
【００１１】
本発明のもう１つの目的および効果は、ハンドヘルドデバイスに影響を及ぼすことなく、新たなヘルパーサービスがヘルパーサーバで容易に追加されることが可能であるとともに、既存のヘルパーサービスが拡張されることが可能であるような、スケーラブルなヘルパー環境を提供することである。
【００１２】
以上の目的を達成するため、本発明は、付近の固定デバイスを用いてハンドヘルドデバイスの能力を拡張する方法において実現される。本発明はまた、上記方法を実現するシステムに関する。
【００１３】
本発明の第１の観点による、ハンドヘルドデバイスの１つ以上の能力を拡張する方法は、（ａ）前記ハンドヘルドデバイスが、少なくとも１つのリソースを提供するヘルパーデバイスを検出するステップと、（ｂ）前記ヘルパーデバイスが、前記少なくとも１つのリソースのうちの選択されたリソースを提供するかどうかを判断するステップと、ただし、前記少なくとも１つのリソースのうちの前記選択されたリソースは、前記ハンドヘルドデバイスの前記１つ以上の能力を拡張するように選択され、前記ハンドヘルドデバイスは独立の動作が可能であり、かつ、前記ヘルパーデバイスは前記選択されたリソースへのアクセスを制御するように設定され、（ｃ）前記ハンドヘルドデバイスが、前記ヘルパーデバイスに対して前記選択されたリソースを要求するステップと、（ｄ）前記ヘルパーデバイスが前記ハンドヘルドデバイスに前記選択されたリソースへのアクセスを許可したことに応じて、前記ハンドヘルドデバイスから前記ヘルパーデバイスにデータを転送するステップと、（ｅ）前記ヘルパーデバイスが、前記選択されたリソースを用いて、転送されたデータを処理するステップと、を有し、前記ステップ（ｃ）の要求に対して前記ヘルパーデバイスが前記リソースへの前記ハンドヘルドデバイスのアクセスを拒否したときには、異なるヘルパーデバイスで前記ステップ（ｂ）へ戻り、前記選択されたリソースは、前記ハンドヘルドデバイスの前記独立の動作によっては十分に提供されないものであり、前記ハンドヘルドデバイスの前記１つ以上の能力は、前記ヘルパーデバイスの前記選択されたリソースの動作を通じて拡張される、ことを特徴とする。
【００１４】
本発明の第２の観点による、ハンドヘルドデバイスの１つ以上の能力を拡張する方法は、（ａ）前記ハンドヘルドデバイスが、それぞれ少なくとも１つのリソースを提供する複数のヘルパーデバイスを検出するステップと、（ｂ）前記ヘルパーデバイスのうちのいずれかが、前記少なくとも１つのリソースのうちの選択されたリソースを前記ハンドヘルドデバイスに提供することが可能かどうかを判断するステップと、ただし、前記少なくとも１つのリソースのうちの前記選択されたリソースは、前記ハンドヘルドデバイスの前記１つ以上の能力を拡張するように選択され、前記ハンドヘルドデバイスは独立の動作が可能であり、前記ヘルパーデバイスは前記選択されたリソースへのアクセスを制御するように設定され、（ｃ−１）前記ハンドヘルドデバイスが、前記選択されたリソースを提供する前記ヘルパーデバイスのそれぞれに対して前記選択されたリソースを要求するステップと、（ｃ−２）前記ヘルパーデバイスのそれぞれは、前記リソースが一時的に利用不能である場合には前記要求をキューイングするステップと、（ｄ）前記選択されたリソースが、前記要求をキューイングした前記ヘルパーデバイスのうちの１つのヘルパーデバイスで利用可能になったとき、前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスが、前記ハンドヘルドデバイスに前記リソースへのアクセスを許可し、前記要求をキューイングした他のヘルパーデバイスでは前記リソースに対するすべてのキューイングされた要求を無視するステップと、（ｅ）前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスが前記ハンドヘルドデバイスに前記選択されたリソースへのアクセスを許可したことに応じて、前記ハンドヘルドデバイスから前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスにデータを転送するステップと、（ｇ）前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスが、前記選択されたリソースを用いて、前記データを処理するステップと、を有し、
前記選択されたリソースに対するすべての要求は、前記ハンドヘルドデバイスからの要求をキューイングした他のヘルパーデバイスでは無視され、前記選択されたリソースは、前記ハンドヘルドデバイスの前記独立の動作によっては十分に提供されないものであり、前記ハンドヘルドデバイスの前記１つ以上の能力は、前記ヘルパーデバイスの前記選択されたリソースの動作を通じて拡張されることを特徴とする。
【００１５】
本発明の第３の観点による、モバイルデバイスの１つ以上の能力を拡張するシステムは、独立の動作が可能なハンドヘルドデバイスと、それぞれ少なくとも１つの拡張サービスを提供する複数のヘルパーデバイスと、を有し、
前記ハンドヘルドデバイスは、前記ヘルパーデバイスのそれぞれと通信して、前記ヘルパーデバイスのうちのいずれかが、前記少なくとも１つの拡張サービスのうちの選択された拡張サービスを前記ハンドヘルドデバイスに提供することが可能かどうかを判断し、前記ヘルパーデバイスは前記選択された拡張サービスへのアクセスを制御するように設定され、
前記ハンドヘルドデバイスは、前記ヘルパーデバイスのそれぞれに対して前記選択された拡張サービスを要求し、前記ヘルパーデバイスのそれぞれは、前記選択された拡張サービスが一時的に利用不能である場合には前記要求をキューイングし、
前記選択された拡張サービスが、前記要求をキューイングした前記ヘルパーデバイスのうちの１つのヘルパーデバイスで利用可能になったとき、前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスは、前記ハンドヘルドデバイスに前記選択された拡張サービスへのアクセスを許可し、前記ハンドヘルドデバイスからの要求をキューイングした他のヘルパーデバイスでは前記選択された拡張サービスに対するすべてのキューイングされた要求は無視され、
前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスが前記ハンドヘルドデバイスに前記選択された拡張サービスへのアクセスを許可したことに応じて、前記ハンドヘルドデバイスは前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスにデータを転送し、
前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスは、前記選択された拡張サービスを用いて、前記データを処理し、
前記ヘルパーデバイスのそれぞれが、前記選択された拡張サービスへの前記ハンドヘルドデバイスのアクセスを拒否したとき、前記ハンドヘルドデバイスは、前記ヘルパーデバイスのそれぞれとの前記通信を終了し、
前記選択された拡張サービスは、前記ハンドヘルドデバイスの前記独立の動作によっては十分に提供されないものであり、前記ハンドヘルドデバイスの前記１つまたは複数の能力は、前記ヘルパーデバイスの前記選択された拡張サービスの動作を通じて拡張される、ことを特徴とする。
【００１６】
本発明の第４の観点による、ハンドヘルドデバイスの１つ以上の能力を拡張するシステムは、少なくとも１つのリソースにアクセスする第１手段と、前記少なくとも１つのリソースへのアクセスを制御する第２手段と、前記第１手段と前記第２手段の間の通信を行う第３手段と、を有し、
前記第１手段は、前記第３手段を用いて、前記第２手段が、前記少なくとも１つのリソースのうちの選択されたリソースを前記第１手段に提供することが可能かどうかを判断し、
前記第１手段は、前記第３手段を用いて、前記第２手段に対して前記選択されたリソースを要求し、前記第２手段は、前記選択されたリソースが一時的に利用不能である場合には前記要求をキューイングし、
前記選択されたリソースが、前記第２手段で利用可能になったとき、前記第２手段は、前記第１手段に前記選択されたリソースへのアクセスを許可し、前記第１手段からの前記選択されたリソースに対する他のキューイングされた要求は無視され、
前記第２手段が前記第１手段に前記選択されたリソースへのアクセスを許可したことに応じて、前記第１手段は前記第３手段を用いて前記第２手段にデータを転送し、
前記第２手段は、前記選択されたリソースを用いて前記データを処理し、
前記第１手段は移動可能であり独立の動作が可能であり、前記選択されたリソースは、前記第１手段の前記独立の動作によっては十分に提供されないものであり、前記第１手段の前記１つまたは複数の能力は、前記第２手段の前記選択されたリソースの動作を通じて拡張されることを特徴とする。
【００１７】
本発明のその他の目的および効果は、明細書および図面の記載から、当業者には明らかとなるはずである。
【００１８】
【発明の実施の形態】
図１に、２個のモバイルデバイス、すなわち、ＰＤＡ３０および携帯（セルラ）電話機３２と、ヘルパーサービスを提供する４個のヘルパーサーバ、すなわち、記憶デバイス２２、表示デバイス２４、印刷デバイス２６および音響（オーディオ）デバイス２８、とからなる例示的なヘルパー環境３４を示す。ヘルパー環境３４は、モバイルデバイスがその周りのデバイスを利用してその制限された能力を拡張することができるフレームワークを提供する。
【００１９】
例えば、ＰＤＡユーザが、ＰＤＡが表示できないか、非常にプリミティブな品質でしか表示できないデータを見ようとしている場合を考える。ヘルパー環境３４内では、ＰＤＡ３０は、大きな画面を有しコンテンツを表示することができる付近のヘルパーサーバ２４を自動的に探索する。その後、ＰＤＡ３０は、ヘルパーサーバ２４とのコネクションを確立し、表示のために、ヘルパーサーバ２４へコンテンツを転送する。さらに、ＰＤＡ３０は、ヘルパーサーバ２４上のコンテンツの表示を制御するリモート制御デバイスとなる。この例では、ＰＤＡ３０の表示能力は、ヘルパー環境３４の利用を通じて大幅に拡張される。
【００２０】
上の例に示されているように、ハンドヘルドデバイスによって、そのヘルパー環境と相互作用するためにとられる本質的なステップは次の通りである。
【００２１】
（１）デバイス発見：ハンドヘルドデバイスは、付近のヘルパーサーバを識別する。
【００２２】
（２）サービス問合せ：ハンドヘルドデバイスは、識別されたヘルパーサーバに対して、それがヘルパーサービスを提供することができるかどうかを判断するために問合せを行う。
【００２３】
（３）要求転送：ハンドヘルドデバイスは、ヘルパーサーバを選択し、それにタスクを委任する。
【００２４】
（４）リモート制御：ヘルパーサーバは、ハンドヘルドデバイスに、リモート制御インタフェース記述を返す。ハンドヘルドデバイスは、このインタフェース記述からグラフィカルユーザインタフェース（ＧＵＩ）を構成し、ハンドヘルドデバイスとのユーザインタラクションに従って、ヘルパーサーバ上のタスクをリモート制御する。
【００２５】
図４に、これらの４つの本質的ステップを具体化した方法の概略を示す。まず、ヘルパーサービスを提供するローカルデバイスを見つける（Ｓ４００）。ローカルデバイスが、ハンドヘルドデバイスによって必要とされるヘルパーサービスを提供するかどうかを判断するために、ローカルデバイスに問合せを行う（Ｓ４０２）。ローカルデバイスが、必要とされるヘルパーサービスを提供しない場合、ハンドヘルドデバイスは、サービスを提供する他のローカルデバイスを探索することを試み（Ｓ４１０）、何も見つからなければ終了する（Ｓ４１２）。
【００２６】
ローカルデバイスが、必要とされるヘルパーサービスを提供する場合、ハンドヘルドデバイスは、ヘルパーサービスを要求する（Ｓ４０４）。ローカルデバイスが要求を拒否した場合、ハンドヘルドデバイスは、ヘルパーサービスを提供する他のローカルデバイスを探索することを試み（Ｓ４１０）、何も見つからなければ終了する（Ｓ４１２）。ローカルデバイスが要求を許可した場合、ハンドヘルドデバイスは、ローカルデバイスへのデータの転送を開始する（Ｓ４０６）。最後に、ローカルデバイスは、受け取ったデータに対する操作を行う（Ｓ４０８）。
【００２７】
図５もまた、これらの４つの本質的ステップを具体化した方法の概略を示すが、図５の方法はさらに、一時的に利用不能なサービスに対する要求のキューイング（待ち合わせ）をサポートする。まず、ヘルパーサービスを提供するローカルデバイスを見つける（Ｓ５００）。ローカルデバイスが、ハンドヘルドデバイスによって必要とされるヘルパーサービスを提供するかどうかを判断するために、ローカルデバイスに問合せを行う（Ｓ５０２）。ローカルデバイスが、必要とされるヘルパーサービスを提供しない場合、ハンドヘルドデバイスは、サービスを提供する他のローカルデバイスを探索することを試み（Ｓ５１０）、何も見つからなければ終了する（Ｓ５１２）。
【００２８】
ローカルデバイスが、必要とされるヘルパーサービスを提供する場合、ハンドヘルドデバイスは、ヘルパーサービスを要求する（Ｓ５０４）。ローカルデバイスが要求を拒否した場合、ハンドヘルドデバイスは、ヘルパーサービスを提供する他のローカルデバイスを探索することを試み（Ｓ５１０）、何も見つからなければ終了する（Ｓ５１２）。
【００２９】
ヘルパーサービスが一時的に利用不能であることをローカルデバイスが示した場合、要求はキューイングされる（Ｓ５０４）。ヘルパーサービスが再び利用可能になったとき（Ｓ５１４）、ローカルデバイスは、ハンドヘルドデバイスが依然としてサービスを必要としているのであれば、要求を許可する（Ｓ５１６）。ハンドヘルドデバイスがもはやヘルパーサービスを必要としていない場合（Ｓ５１６）、ローカルデバイスは、そのキュー内の次の要求の処理に進み（Ｓ５１８）、キューがからであれば終了する（Ｓ５１２）。
【００３０】
ローカルデバイスが要求を許可した場合、ハンドヘルドデバイスは、ローカルデバイスへのデータの転送を開始する（Ｓ５０６）。最後に、ローカルデバイスは、受け取ったデータに対する操作を行う（Ｓ５０８）。
【００３１】
ハンドヘルドデバイスは、ヘルパーサービスにアクセスする手段を表す。このようなモバイルデバイスには、例として、以下のものには限定されないが、ＰＤＡ、ディジタルカメラ、ＭＰ３プレーヤおよび携帯電話機がある。ヘルパーサーバは、ヘルパーサービスへのアクセスを制御する。このようなヘルパーサーバには、例として、以下のものには限定されないが、表示デバイス、印刷デバイス、スキャンデバイス、記憶デバイス、ネットワークデバイス、および音響デバイスがある。ヘルパー環境概念の全体のフレームワークはまた、ヘルパー環境内のこれらのモバイルデバイスとヘルパーサーバの間の通信手段も必要とする。
【００３２】
フレームワークは、多くのさまざまな種類の通信媒体の上に構築することができる。そのような通信媒体には、例として、以下のものには限定されないが、Ｂｌｕｅｔｏｏｔｈ^TMワイヤレステクノロジー、ＩＥＥＥ８０２．１１ワイヤレスＬＡＮ、赤外線、ＨｏｍｅＲＦ^TMがあり、Ｅｔｈｅｒｎｅｔ(登録商標）のような有線ネットワークでもよい。Ｂｌｕｅｔｏｏｔｈ^TMワイヤレステクノロジーのように、これらの媒体のうちには、ヘルパー環境を構成する際に利用可能なリンク層デバイス発見およびサービス問合せメカニズムをサポートするものがある。これらの利点およびその他の利点のため、実施例では、リンク層としてＢｌｕｅｔｏｏｔｈ^TMワイヤレステクノロジーを用いて説明する。しかし、注意すべき点であるが、全体のシステムフレームワークは、相異なるリンク層プロトコルを通じて同一のままである。
【００３３】
Ｂｌｕｅｔｏｏｔｈ^TM（米国Bluetooth SIG, Inc.の登録商標）ワイヤレステクノロジーは、主として短いケーブルを置き換えるように設計された短距離無線技術である。これは、Bluetooth Special Interest Groupによって標準化されている。Ｂｌｕｅｔｏｏｔｈ^TMデバイスは、免許不要の２．４ＧＨｚ帯で送信を行い、１ＭＨｚ間隔の７９ホップ（一部の国では２３ホップ）の周波数ホッピング型スペクトラム拡散技術を使用する。省電力モードでは、その到達範囲は１０メートルまでであり、７２０Ｋｂｐｓまでのデータレートを提供する。その低消費電力と比較的シンプルな技術のため、Ｂｌｕｅｔｏｏｔｈ^TM仕様を実装するチップセットはきわめて手ごろな価格になると期待される。デバイスが互いに（見通し線）向き合うことが要求される赤外線とは異なり、Ｂｌｕｅｔｏｏｔｈ^TMワイヤレステクノロジーは、壁やその他の非金属障壁を通過することができる全方向電波を使用する。これらのすべてのことにより、Ｂｌｕｅｔｏｏｔｈ^TMワイヤレステクノロジーは、デスクトップコンピュータのケーブル置き換えに適するとともに、特に、小型のモバイルデバイスのユビキタス接続に適している。
【００３４】
Ｂｌｕｅｔｏｏｔｈ^TM仕様は、プロトコルスタックと利用プロファイルという２つの部分からなる。図２に、プロトコルスタックを示す。Ｂｌｕｅｔｏｏｔｈ^TM ＲＦ４８、ベースバンド４６およびリンクマネージャプロトコル（ＬＭＰ：Link Manager Protocol）４４は、物理層およびリンク層のプロトコルを規定し、これらは、リンクの設定および制御とともに、無線伝送、デバイス発見およびアドレシングを含む。これらは全体として、上位層プロトコルへのホストコントローラインタフェース（ＨＣＩ：host controller interface）６６を提供する。論理リンク制御・アダプテーションプロトコル（Ｌ２ＣＡＰ：Logical Link Control and Adaptation Protocol）４２は、上位レベルのプロトコル多重化、パケットの分解および再組み立て、ならびに、サービス品質情報の伝達をサポートする。ＲＦＣＯＭＭプロトコル５０は、Ｌ２ＣＡＰ層４２上で、ＲＳ−２３２（ＥＩＡＴＩＡ−２３２−Ｅ）シリアルポートの９個の回路をエミュレートする。これは、ケーブル置き換えメカニズムが提供されるところである。
【００３５】
サービスディスカバリ（発見）プロトコル（ＳＤＰ：Service Discovery Protocol）４０もまた、Ｌ２ＣＡＰ４２上に構成され、Ｂｌｕｅｔｏｏｔｈ^TMデバイスが、互いに提供するサービスについて問合せを行うために使用される。サービスは、ＳＤＰ４０に登録され、他のデバイスによる問合せのためにサービスディスカバリデータベース（ＳＤＤＢ：Service Discovery Database）（図示せず）に入れられる。プロトコルスタックは、ＰＰＰ５２、ＩＰ５４、ＵＤＰ／ＴＣＰ５６、ＷＡＰ５８、ＯＢＥＸ６４およびｖＣａｒｄ／ｖＣａｌ６２のような、他のハイレベルプロトコルを含む。
【００３６】
Ｂｌｕｅｔｏｏｔｈ^TMプロファイルは、Ｂｌｕｅｔｏｏｔｈ^TMワイヤレステクノロジーを使用するアプリケーションの利用形態を記述する。各プロファイルは、プロトコルスタック内のプロトコルコンポーネントがまとまってあるタスクを実行するためにどのように使用されるかを説明する。例えば、ＬＡＮアクセスプロファイル（ＬＡＰ：LAN Access Profile）は、デバイスがＬＡＮアクセスポイントとＰＰＰコネクションをどのようにして確立することができるかを規定する。
【００３７】
仕様によって現在規定されている他のいくつかのプロファイルには次のものがある。
【００３８】
・汎用アクセスプロファイル（ＧＡＰ：Generic Access Profile）は、デバイス発見およびリンク管理の一般的手順を規定し、他のすべてのプロファイルの基礎を提供する。
【００３９】
・サービスディスカバリアプリケーションプロファイル（ＳＤＡＰ：Service Discovery Application Profile）は、一般的なサービス発見手順を規定する。
【００４０】
・シリアルポートプロファイル（ＳＰＰ：Serial Port Profile）は、エミュレートされたシリアルケーブル接続を設定するための要件を規定する。
【００４１】
・汎用オブジェクト交換プロファイル（ＧＯＥＰ：Generic Object Exchange Profile）は、同期、ファイル転送、あるいはオブジェクトプッシュモデルのための手順を規定する。
【００４２】
・オブジェクトプッシュプロファイル（ＯＰＰ：Object Push Profile）は、Ｂｌｕｅｔｏｏｔｈ^TMデバイス間のデータオブジェクトのプッシュ／プルのための要件を規定する。
【００４３】
・ファイル転送プロファイル（ＦＴＰ：File Transfer Profile）は、ファイル転送利用モデルを提供するアプリケーションのための要件を規定する。
【００４４】
・同期プロファイル（ＳＰ：Synchronization Profile）は、データ同期を提供するアプリケーションのための要件を規定する。
実施例では、ヘルパー環境は、新たなＢｌｕｅｔｏｏｔｈ^TMプロファイルとして構築される。これは、便宜上、プロトコルスタックと、いくつかのプロファイル、特に、ＳＤＡＰおよびＬＡＰプロファイルに基づくことになる。
【００４５】
代表的なヘルパー環境は、要求を受け付け、通信媒体の動作範囲内のクライアントにヘルパーサービスを提供するいくつかのヘルパーサーバからなる。ヘルパー環境の適切な動作を保証するため、クライアントおよびサーバにおけるプロトコルスタックは、クライアントとサーバの間のインタラクションについて規定されなければならない。
【００４６】
フレームワークは、例として、限定はされないが、ＴＣＰ／ＩＰの上に構築することができる。これは、モバイルデバイスが、ヘルパーデバイスとのＲＦＣＯＭＭリンク（シリアルケーブルエミュレーション）上にＰＰＰコネクションを確立することを要求する。いくつかのアプリケーションについては、ＯＢＥＸのような、よりシンプルなプロトコルでも十分であるが、ＩＰベースの解決法のほうが、より一般的であり、ネットワークアクセスのような新たなアプリケーションを収容するのが容易であるため、好ましい。
【００４７】
図３において、ヘルパークライアント９２は、ハンドヘルドデバイス１１４上で動作しているプロセスである。これは、デーモンとして動作することも可能であり、あるいは、オンデマンドでアクティベートされることも可能である。これは、ＰＰＰプロトコルスタック８８上のＴＣＰ／ＩＰ９０とやりとりする。ヘルパークライアント９２は、本質的にリモートプロシージャコール（ＲＰＣ）クライアントスタブと類似しており、Ｂｌｕｅｔｏｏｔｈ^TMワイヤレステクノロジーのインクワイアリ１０８およびサービスディスカバリ１１０を通じて「環境能力」(environment capability)テーブルを管理する。このテーブルは、周期的に、または、ハンドヘルドデバイス１１４の使用によりオンデマンドで、リフレッシュされる。ヘルパークライアント９２はまた、ハンドヘルドデバイス１１４上のすべてのヘルパー要求１１２を、選択されたヘルパーサーバ９４に転送することによって処理し、キューイングされた要求についてのサービス利用可能性に関してユーザに通知し、ユーザインタラクションをリモート制御コマンドに翻訳してそれをヘルパーサーバ９４に送り、ユーザの要求に基づいてヘルパーセッションを終了する。
【００４８】
ヘルパーサーバ９４は、ヘルパーデバイス１１６上で動作する別個のプロセスである。ヘルパーサーバ９４は、ＰＰＰプロトコルスタック９８上のＴＣＰ／ＩＰ９６とやりとりする。ヘルパーサーバ９４は、本質的にリモートプロシージャコール（ＲＰＣ）サーバスタブと類似しており、その存在および能力について、Ｂｌｕｅｔｏｏｔｈ^TMサービスディスカバリデータベース（ＳＤＤＢ）に登録する。ヘルパーサーバ９４はまた、受付制御、要求キューイング１１２およびクライアント通知を処理し、クライアント要求を受け付けてクライアントデータを表示し、リモート制御インタフェース記述をクライアントに返し、データ／ＵＲＬ(Uniform Resource Locator)転送およびリモート制御インタラクション交換のためのヘルパープロトコルを通じてクライアントと通信し、クライアントの要求に基づいてセッションを終了する。
【００４９】
図６および図７に、ヘルパー環境の実施例内にあるハンドヘルドデバイスおよびヘルパーデバイスの両方での制御フローを示す。ハンドヘルドデバイスは、拡張タスクを開始しようとする前に、まず、その環境内に、要求されるタスクを実行できるヘルパーデバイスがあるかどうかを判断しなければならない。これを実現するため、実際には次の３つのステップが含まれる。すなわち、（１）付近のデバイスを探索し、（２）要求されるヘルパーサービスの存在についてそれらのデバイスに問い合わせ、（３）ヘルパーデバイスが現在の要求をサービスすることができるかどうかを判断する。
【００５０】
Ｂｌｕｅｔｏｏｔｈ^TMサービスディスカバリデータベースはサービス利用可能性についてのレコードを含むことができるだけであるため、ステップ２および３は分けられている。より複雑なサービス受付制御およびサービスキューイングは、アプリケーション層でのみ行うことができる。Ｂｌｕｅｔｏｏｔｈ^TMサービスディスカバリアプリケーションプロファイルは、最初の２つのステップを実行するための手順を含む。
【００５１】
まず、ヘルパークライアントは、Ｂｌｕｅｔｏｏｔｈ^TMベースバンドに、インクワイアリ状態に入るように命令することによって、デバイス発見プロセスを開始する。環境内でヘルパーサービスを提供することができるすべてのデバイスは、インクワイアリスキャン状態においてコネクションを待機しており（Ｓ６４４）、デバイスインクワイアリ（Ｓ６４２）に応答すると仮定される。このため、ハンドヘルドデバイスは、その環境内のデバイスを識別することができ、それらのデバイスのアドレスを知ることができる（Ｓ６００）。次に、ハンドヘルドデバイスは、リンク層コネクションを確立するために、これらのデバイスのそれぞれに対するページングプロセスを試みる。コネクションが設定された後、ハンドヘルドデバイスは、接続されたデバイスが要求されるヘルパーサービスを提供するかどうかを判断するために、接続されたデバイスへのサービスインクワイアリを開始する（Ｓ６０６）。ヘルパーフレームワークは、対応するプロファイルを有し、固有のプロファイルＩＤが割り当てられているはずである一方、それぞれの特定のヘルパーサービスは、プロファイル内の対応するアトリビュートによって識別される（Ｓ６４０）。各ヘルパーサーバは、ヘルパープロファイルＩＤと、その提供するサービスを反映するアトリビュートで、サービスディスカバリデータベース（ＳＤＤＢ）を更新しなければならない。
【００５２】
要求されるヘルパーサービスを有するデバイスが発見された場合、ハンドヘルドデバイスは、ＬＡＮアクセスプロファイルを開始し、ヘルパーデバイスとのＰＰＰコネクションを確立することができる（Ｓ６０８）。ＰＰＰコネクションが確立されると、ヘルパークライアントは、ＴＣＰを通じてヘルパーサーバに接続し、そのサービス要求を送ることができる。要求は、サーバ受付制御のための次のような情報を含むことが可能である。その情報はすなわち、ユーザデータのＭＩＭＥタイプ、データに対して要求されるサービス（例えば、表示、印刷あるいは記憶）、実データまたはＵＲＬのいずれが続くかを示すフラグ、データのバイト長、サービスの予想継続時間、および、オプションとして、認証情報である。
【００５３】
クライアントデータは、実際のデータであることも、データへのＵＲＬであることも可能である。ネットワーク環境では、ＵＲＬがしばしば使用されることが予想される。ＵＲＬの使用のほうがずっと効率が良く高速である。その理由は、モバイルデバイスがデータを取得してヘルパーデバイスに送る必要がないからである。ワイヤレスアプリケーションプロトコル（ＷＡＰ：Wireless Application Protocol）電話機のように非常に小さいメモリサイズしか有しないハンドヘルドデバイスの場合、ＵＲＬは、データを表示するための唯一の方法であり得る。
【００５４】
サーバは、受付判定を行い（Ｓ６４８）、クライアントに対して、そのサービス要求を直ちに許可することができるか、キューイングしなければならないか、それとも、拒否されるか（例えば、サーバ上の全リソースが十分でない、あるいは、認証失敗）を通知する（Ｓ６４６）。図５に示されるように、要求がキューイングされなければならないとき、クライアントには、後でサービスが利用可能になった時点で通知されることになる（Ｓ５１４）。この場合を扱うために、クライアントは、複数のサーバと連絡を取ることも可能である。サーバのうちの１つが要求に対するサービスを開始したら直ちに、クライアントは、他のキューイングしているサーバがあればそれに対して、そのキューから同一のサービス要求を削除するよう通知する。
【００５５】
クライアント要求がサービスキューに入ったあとは、クライアントがサーバとＰＰＰコネクションを維持するのは現実的でない。クライアントは、複数の要求を相異なるヘルパーに送ることがあり得るからである。あまり多くのＰＰＰコネクションを維持することは、モバイルデバイス上で多量の電力を消費することがある。代わりに、いったんクライアント要求がサーバキューに入ったら、クライアントとサーバの間のＰＰＰコネクションを破棄することができる。クライアントのＢｌｕｅｔｏｏｔｈ^TMアドレスＩＤを含むクライアント情報はサーバキューに格納されるため、サーバは、クライアント要求がサービス可能になったらページングプロセスを開始することができる。クライアントがしなければならないことは、ページングスキャンモードで待機することだけである。サーバがクライアントのページングを開始したら直ちに、クライアントは、ページング信号を受け取り、サーバとのＰＰＰセッションを再確立することになる。
【００５６】
クライアントは、要求するサービスを取得した後は、単に、他のサーバからのページングを無視することができる。これらのサーバについては、ページング失敗は、クライアントが、もはやそのサービスに興味がないか、または、到達範囲外に移動したかのいずれかを意味する。それらのサーバは、その後、それらのキュー内の次の要求に対するサービスを開始することができる。なお、クライアントは、要求するサービスをあるサーバから取得したら他のすべてのサーバに通知することも可能である。これを行うためには、これらのそれぞれのサーバをページングし、ＰＰＰコネクションを確立してそのサーバに通知しなければならない。このような方式は、サーバページングメカニズムよりも処理量がずっと多いため、あまり好ましくない。
【００５７】
サービス要求がヘルパーサーバによって受け付けられると（Ｓ６５０）、クライアントに通知され（Ｓ６１０）、クライアントは、サービスデータをサーバに転送することを開始することができる（Ｓ６１２）。クライアントがサービスデータの転送に失敗した場合（Ｓ６１４）、ハンドヘルドデバイスは、その環境内の別のデバイスを識別しようと試みる（Ｓ６０２，Ｓ６０４）。ヘルパーサーバは、ヘッダおよびデータを受け取った後、適当なアプリケーションを開始して、要求されたようにデータに対する操作を行う（Ｓ６５２）。データに対するヘルパーサーバの操作中にエラーに遭遇した場合（Ｓ６５４）、クライアントに通知され（Ｓ６６２）、コネクションは切断される（Ｓ６６４）。その後、クライアントは、エラー情報に基づくアクションをとることができる。例えば、エラーが、データが壊れていて表示できないことを示している場合、クライアントは、コネクションを切断すべきである。
【００５８】
図６および図７には示されていないが、クライアントとサーバの間のＴＣＰコネクションが切断したときの異常状態に対する遷移がある。これは、コネクションが確立された後のいずれのステップでも起こる可能性があり、クライアントがサーバの通信到達範囲外に移動したことによる可能性が高い。この異常状態を処理する１つの方法は、クライアントが「デバイス探索」ステップＳ６００に戻る一方、サーバが「クライアントコネクション待機」ステップＳ６４４に戻ることである。
【００５９】
ユーザデータがヘルパーデバイス上に表示される場合、ユーザは、ハンドヘルドデバイスおよびＢｌｕｅｔｏｏｔｈ^TMコネクションを用いて、データの表示をリモート制御することができる（Ｓ６１６，Ｓ６１８，Ｓ６２０，Ｓ６２２）。例えば、データをストリーミングする場合、ユーザは、「停止」(stop)、「再開」(resume)および「早送り」(fast forward)コマンドをサーバへ送ることが可能である。リモート制御のアプリケーション固有の性質のため、ハンドヘルドデバイスおよびヘルパーデバイスは、互いに協調して制御を実行しなければならない。ヘルパーサービスの多様な性質のため、クライアントデバイスは、各サービスアプリケーションごとにリモート制御インタフェースを記憶してしないことが好ましい。そのようなことをすると、新たなサービスの追加や既存のサービスの改良が非常に困難となる。それにはハンドヘルドデバイスに対する変更が必要となるからである。
【００６０】
図８に示すように、好ましいアプローチは、サーバが、図４のステップＳ４０８または図５のステップＳ５０８で、受け取ったデータに対する操作を開始した後、アプリケーション固有の制御インタフェースをクライアントに引き渡す（Ｓ７００）ことである。このアプローチは、クライアントが、各サービスアプリケーションごとに固有のインタフェースを記憶する必要がないことを保証する。サーバからクライアントに送られるインタフェース記述は、汎用のマークアップ言語、例えば、以下のものには限定されないが、ＸＭＬやＨＴＭＬで規定することができる。この記述は、ボタンやメニューのようなグラフィカルインタフェース表示とともに、特定のボタンが押された場合に"page down"メッセージを送信するというようなユーザインタラクションを含む。次に、クライアントデバイスは、その記述を解釈し、ユーザインタフェースを表示する（Ｓ７０２）。インタフェースとのユーザインタラクションは（Ｓ７０４）、ハンドヘルドデバイスによっては解釈されず、その代わりに、サーバへ返され、サーバが、個々のアプリケーションに従ってそれを解釈する（Ｓ７０６）。さらにカスタマイズするためには、クライアントは、サービス要求を発行するときにデバイスの能力についてサーバに通知することも可能である。これにより、サーバは、例えば、グラフィカルインタフェースあるいはテキストベースのインタフェースを返すことが可能となる。
【００６１】
このアプローチをさらに詳しく説明するため、図７にあるような、ヘルパーサーバ上のビデオ表示アプリケーションを考える。サーバは、アプリケーションを開始した後（Ｓ６５２）、図６のクライアントに、クライアントのデバイスタイプに従ったインタフェースを返す。例えば、クライアントデバイスがＰＤＡである場合、「再生」(play)、「一時停止」(pause)および「早送り」(fast forward)のような制御ボタンを有するシンプルなグラフィカルインタフェースとなる。クライアントデバイスがシンプルなＷＡＰ電話機である場合、サーバは、制御コマンド（例えば、"play"や"pause"）でマークされたリンクを有するＷＭＬページを返すことが可能である。これらのリンクのうちの１つをアクティベートする（Ｓ６１６，Ｓ６１８，Ｓ６２０）ことにより、サーバは、制御コマンドを受け取った後、適当なアクションをとる（Ｓ６５６，６５８，６６０）ことになる。
【００６２】
アプリケーション固有のインタフェースはヘルパーサーバに記憶されてハンドヘルドデバイスには記憶されないため、また、ハンドヘルドデバイスはヘルパーサーバによって提供されるインタフェース記述に基づいてアプリケーション固有のインタフェースを構成するため、さらに、構成されたインタフェースとのユーザインタラクションの解釈はヘルパーサーバで行われるため、ハンドヘルドデバイスに対する変更を必要とせずに、新たなヘルパーサービスを追加したり、既存のヘルパーサービスを変更したりすることができる。
【００６３】
ヘルパー環境は、ハンドヘルドデバイスの能力の拡張である。すなわち、ヘルパー環境は、ハンドヘルドデバイス上の既存のアプリケーションが、あるデータコンテンツを適切に処理することができないときに呼び出される。したがって、ほとんどの場合、ハンドヘルドデバイスへのヘルパーサポートの統合のために、既存のアプリケーションを変更する必要がない。ヘルパーを認識するアプリケーションは、ハンドヘルドデバイス上のレガシーアプリケーションと共存することになる。いくつかのアプリケーション、特にウェブ閲覧ツールは、ヘルパーサービスを利用するために変更を必要とする。ヘルパーメカニズムが相異なるＯＳプラットフォーム上でこれらの相異なるツールにどのようにして統合されることが可能かを調べれば、ヘルパー環境がさまざまなオペレーティングシステムのもとで実装可能であることが例証される。
【００６４】
例えば、次のものには限定されないが、Ｗｉｎｄｏｗｓ(登録商標）ＣＥ^TMが動作するプラットフォームへのヘルパーの統合は比較的容易である。Ｗｉｎｄｏｗｓ（登録商標）ＣＥ^TMは、ファイルの概念を保持し、ファイルタイプとそれに対応するアプリケーションとの間の関連づけを維持している。ヘルパー環境を要求するファイルのタイプをサポートするために、ファイルタイプとヘルパークライアントの間の関連づけを設定することができる。この関連づけは、ウェブ閲覧に有効であるだけでなく、Ｗｉｎｄｏｗｓ（登録商標）ＣＥ^TM環境全体にも適用される。
【００６５】
これに対して、ＰａｌｍＯＳ^TMでは、上記のようなある種のシームレスなヘルパー統合は困難である。ＰａｌｍＯＳ^TMにはファイルシステムがないからである。例として、次のものには限定されないが、クエリアプリケーションおよびウェブクリッピングを通じてサポートされるウェブ閲覧にヘルパー概念を統合するというアプローチを考える。ＨＴＭＬページ内の関連する静的なコンテンツはアプリケーション（ＰａｌｍＯＳ^TMではＰａｌｍ^TMクエリアプリケーション(Palm^TM Query Application)という）へとコンパイルされた後、Ｐａｌｍ^TMデバイスにインストールされる。アプリケーション内部でＵＲＬに相当するものは、アプリケーション内のデータを指すことが可能であり、この場合、リンクは直ちに取得することができる。アプリケーションの外部のリンクについては、プロキシサーバを用いて、正規のウェブコンテンツをＰａｌｍ^TMクエリアプリケーション表示可能フォーマットに変換する。このプロセスをウェブクリッピングという。ウェブクリッピングにより、コンテンツ（例えば、Ｊａｖａ（登録商標）アプレット）がフィルタリングにより除去されることがある。ヘルパーサービスを統合するためには、ある一定のタイプのコンテンツがヘルパークライアント手続きを通して処理されるように、アプリケーションコンパイラを変更する必要がある。プロキシサーバでは、ウェブクリッピングは、フィルタリングおよび変換を行うときに、Ｐａｌｍ^TMデバイス上のアプリケーションがヘルパー能力を有するかどうかを考慮に入れる必要がある。
【００６６】
最後に、ＷＡＰへのヘルパー統合は、Ｐａｌｍ^TMクエリアプリケーションの場合と同様である。ＷＡＰブラウザは、より複雑なタイプをサポートするようにヘルパークライアント機能で改良される必要がある。
【００６７】
ＴＣＰは、少なくとも次の３つの理由で、ヘルパークライアントとヘルパーサーバの間のコネクションに対する好ましいプロトコルである。
【００６８】
（１）それぞれの拡張タスクについて、セッションが維持される必要がある。このセッションは、クライアント要求がサーバによって受け入れられたときに開始し、ユーザがヘルパーサービスの使用を終了したときに終了する。セッション中、データおよび制御の両方の情報が交換される。ヘルパーモデルがシンプルであるため、各セッションは、クライアントとサーバの間のＴＣＰコネクションに自然に対応する。
【００６９】
（２）ＴＣＰは、クライアントとサーバの間に、シーケンシャルで信頼性の高いトランスポートチャネルを提供する。これは特に、コマンド転送、すなわち、コマンドがサーバに確実に、かつ、ユーザによって発行されたのと同じ順序で、転送されることを、クライアントが確かめる必要がある場合に、重要である。
【００７０】
（３）クライアントの移動性のため、クライアントとサーバの両方が、依然として通信の到達範囲内にあることを定常的に確かめる必要がある。ＴＣＰコネクション切断は、到達範囲外（したがってサービス範囲外）状態について、クライアントおよびサーバに自動的に通知する。
【００７１】
しかし、本発明は、ＴＣＰを使用することに限定されない。例えば、ＵＤＰを用いた別の実施例では、ＵＤＰのkeep-aliveメッセージが、クライアントとサーバの間で定期的に交換されなければならない。
【００７２】
セキュリティの維持もまた、ヘルパー環境フレームワークの重要な側面である。ヘルパーサービスはヘルパーサーバによって完全に制御されるため、モバイルクライアントは、サーバ上のセキュリティを弱めることはできない。どのヘルパー要求も、受付制御を通らなければならず、サーバによって提供される制御されたサービスのセットにのみアクセスすることができる。リモート制御インタフェースもまたサーバによって提供され、制御コマンドはサーバによって解釈される。さらに、ヘルパー環境の主要な目的は、データの処理および表示を支援することである。したがって、クライアントは、任意のプログラムをサーバ上で実行することができるのではなく、サーバ上にある既存のプログラムをクライアントデータで呼び出すことができるだけである。
【００７３】
セキュリティのもう１つの側面は、クライアント認証および課金である。公開のヘルパー環境では、ペイパーユース(pay-per-use)方式はユーザにとって非常に不便であり、環境の有用性を大きく制限する。Ｂｌｕｅｔｏｏｔｈ^TMワイヤレステクノロジーを用いたわれわれの実施例では、認証およびセキュリティは、２つの通信デバイスに共通のＰＩＮ（暗証番号）をインストールすることを通じて実現することができる。モバイルクライアントがヘルパーサービスを利用するときには常に、この共通のＰＩＮがまずインストールされなければならない（手動で、または、第三者による複雑な相互認証プロセスを通じて）のであれば、わずかのユーザしかヘルパーサービスを利用したいとは思わないであろう。
【００７４】
この問題点を解決するため、ヘルパー環境フレームワークの実施例は、「認証１回・利用多数回」(authenticate once, use many times)方式を採用する。ユーザは、公開のファシリティでヘルパー環境を利用することを決定すると、手動のＰＩＮ設定（例えば、コーリングカードメカニズムと同様に、ユーザＩＤおよびＰＩＮ番号を購入する）、または、第三者を利用した複雑な相互認証プロセスを用いて、いずれかのヘルパー環境で認証を行うことができる。認証の結果、ユーザは、そのファシリティのヘルパー環境で使用可能な固有のＩＤおよびＰＩＮを取得する。
【００７５】
ファシリティの中央データベースが、ユーザＩＤとそれに対応するＰＩＮ番号を格納するために使用される。ユーザは、異なるヘルパー環境の利用を開始するとき、可能性のあるヘルパーデバイスとのコネクションを確立しようとする。まず、そのデバイスに自己のユーザＩＤを告げる。次に、デバイスは、このＩＤを用いて、データベースからＰＩＮをフェッチし、そのＰＩＮをサーバに設定する。すると、サーバとユーザデバイスの間に安全なリンクを確立することができる。
【００７６】
上記の実施例に対する最後の考慮点として、モバイルユーザの移動可能性は、ヘルパー環境内で維持される。ノマディック(nomadic)かつシームレス(seamless)な移動可能性が考慮される。ノマディックな移動可能性を有する実施例では、代表的な利用場面は次のようなものである。モバイルユーザはヘルパー環境に移動し、ヘルパーサーバ上のサービスを開始する。ユーザが移動し、サーバを変えることに決めると、到達範囲内の別のヘルパーサーバで新たなセッションが開始される前に、現在のサービスセッションをまず終了させる。これらの２つのサービスセッションの間に連続性はない。
【００７７】
シームレスな移動可能性をサポートする代替実施例では、ユーザが移動してサーバの変更を生じるときに、状態情報が保持される。この状態情報は、新たなヘルパーサーバが、保存された状態情報に示されたデータに対するヘルパーサービスの提供を再開することができるように、新たなヘルパーサーバに渡される。このシームレスな移動可能性は、例えば、ビデオストリームが表示連続性を伴ってあるヘルパーから別のヘルパーに移動するようなストリーミングの場合に、特に有用となる。
【００７８】
本発明は、その技術的範囲あるいは本質的な特性から離れることなく、他の具体的形態でも実施可能である。上記の実施例は、すべての点において、単なる例示であって限定的なものではないとみなされるべきである。特許請求の範囲の意味および均等の範囲に入るすべての変形例は、その技術的範囲に包含される。
【００７９】
【発明の効果】
本発明によれば、ハンドヘルドデバイスがリソースを提供するヘルパーデバイスを検出し、ヘルパーデバイスが拡張リソースを提供するかどうかを判断する。ハンドヘルドデバイスがヘルパーデバイスに対して拡張リソースを要求し、これが許可された場合には、ハンドヘルドデバイスからヘルパーデバイスにデータが転送される。その後、ヘルパーデバイスが、拡張リソースを用いて、転送されたデータを処理する。データに対する拡張リソースの動作は、ハンドヘルドデバイスによって制御される。
【００８０】
これによって、ハンドヘルドデバイスが、その制限された能力を拡張するために、その周りのデバイスを識別し利用することができるフレームワークを提供することができる。
【図面の簡単な説明】
【図１】ヘルパー環境の概念図である。
【図２】Ｂｌｕｅｔｏｏｔｈ^TMプロトコルスタックを示す図である。
【図３】実施例において、ヘルパークライアントおよびヘルパーサーバに属するヘルパー環境プロトコルスタックと、２つのプロトコルスタックの間のさまざまな通信パスとを示す図である。
【図４】リソースにリモートアクセスする方法を示す流れ図である。
【図５】リソースにリモートアクセスするとともに、一時的に利用不能なリソースのキューイングを行う方法を示す流れ図である。
【図６】ヘルパーデバイスからヘルパーサービスを取得するハンドヘルドデバイス（クライアント）上での制御フローを示す図である。
【図７】ヘルパーサービスをハンドヘルドデバイスに提供するヘルパーデバイス（サーバ）上での制御フローを示す図である。
【図８】ハンドヘルドデバイスが、ヘルパーサーバによって提供される記述に基づいて制御インタフェースを構成するステップを示す図である。
【符号の説明】
２２記憶デバイス
２４表示デバイス
２６印刷デバイス
２８音響デバイス
３０ＰＤＡ
３２携帯電話機
３４ヘルパー環境
４０サービス発見プロトコル（ＳＤＰ）
４２論理リンク制御・アダプテーションプロトコル（Ｌ２ＣＡＰ）
４４リンクマネージャプロトコル（ＬＭＰ）
４６ベースバンド
４８Ｂｌｕｅｔｏｏｔｈ^TM ＲＦ
５０ＲＦＣＯＭＭプロトコル
５２ＰＰＰ
５４ＩＰ
５６ＵＤＰ／ＴＣＰ
５８ＷＡＰ
６２ｖＣａｒｄ／ｖＣａｌ
６４ＯＢＥＸ
６６ホストコントローラインタフェース（ＨＣＩ）
８８ＰＰＰプロトコルスタック
９０ＴＣＰ／ＩＰ
９２ヘルパークライアント
９４ヘルパーサーバ
９６ＴＣＰ／ＩＰ
９８ＰＰＰプロトコルスタック
１０８インクワイアリ
１１０サービスディスカバリ
１１２ヘルパー要求
１１４ハンドヘルドデバイス
１１６ヘルパーデバイス

Claims

ハンドヘルドデバイスの１つ以上の能力を拡張する方法において、
（ａ）前記ハンドヘルドデバイスが、少なくとも１つのリソースを提供するヘルパーデバイスを検出するステップと、
（ｂ）前記ヘルパーデバイスが、前記少なくとも１つのリソースのうちの選択されたリソースを提供するかどうかを判断するステップと、
ただし、前記少なくとも１つのリソースのうちの前記選択されたリソースは、前記ハンドヘルドデバイスの前記１つ以上の能力を拡張するように選択され、前記ハンドヘルドデバイスは独立の動作が可能であり、かつ、前記ヘルパーデバイスは前記選択されたリソースへのアクセスを制御するように設定され、
（ｃ）前記ハンドヘルドデバイスが、前記ヘルパーデバイスに対して前記選択されたリソースを要求するステップと、
（ｄ）前記ヘルパーデバイスが前記ハンドヘルドデバイスに前記選択されたリソースへのアクセスを許可したことに応じて、前記ハンドヘルドデバイスから前記ヘルパーデバイスにデータを転送するステップと、
（ｅ）前記ヘルパーデバイスが、前記選択されたリソースを用いて、転送されたデータを処理するステップと、
を有し、
前記ステップ（ｃ）の要求に対して前記ヘルパーデバイスが前記リソースへの前記ハンドヘルドデバイスのアクセスを拒否したときには、異なるヘルパーデバイスで前記ステップ（ｂ）へ戻り、
前記選択されたリソースは、前記ハンドヘルドデバイスの前記独立の動作によっては十分に提供されないものであり、
前記ハンドヘルドデバイスの前記１つ以上の能力は、前記ヘルパーデバイスの前記選択されたリソースの動作を通じて拡張される、
ことを特徴とするハンドヘルドデバイスの能力拡張方法。
（ｆ）前記ハンドヘルドデバイスが前記データに対する前記選択されたリソースの動作を制御するステップをさらに有することを特徴とする請求項１記載の方法。
（ｆ）前記ヘルパーデバイスが、前記ハンドヘルドデバイスにインタフェース記述を送信するステップと、
（ｇ）前記ハンドヘルドデバイスが、前記インタフェース記述から制御インタフェースを構成し表示するステップと、
（ｈ）前記ハンドヘルドデバイスが、前記制御インタフェースとの処理されたユーザインタラクションを前記ヘルパーデバイスに転送するステップと、
（ｉ）前記ヘルパーデバイスが、前記選択されたリソースに基づいて前記ユーザインタラクションを解釈するステップと、
をさらに有し、
前記ハンドヘルドデバイスは、前記ユーザインタラクションに基づいて前記ヘルパーデバイスを操作し、
前記ハンドヘルドデバイスに対する変更を必要とせずに、新たなリソースの追加および既存のリソースの変更の少なくとも一方が可能であることを特徴とする請求項１記載の方法。
（ｆ）前記ヘルパーデバイスが、前記データに対する前記選択されたリソースの動作のステータス報告を前記ハンドヘルドデバイスに送信するステップと、
（ｇ）前記ハンドヘルドデバイスが、前記ステータス報告に基づいてアクションをとるステップと、
をさらに有することを特徴とする請求項１記載の方法。
ハンドヘルドデバイスの１つ以上の能力を拡張する方法において、
（ａ）前記ハンドヘルドデバイスが、それぞれ少なくとも１つのリソースを提供する複数のヘルパーデバイスを検出するステップと、
（ｂ）前記ヘルパーデバイスのうちのいずれかが、前記少なくとも１つのリソースのうちの選択されたリソースを前記ハンドヘルドデバイスに提供することが可能かどうかを判断するステップと、
ただし、前記少なくとも１つのリソースのうちの前記選択されたリソースは、前記ハンドヘルドデバイスの前記１つ以上の能力を拡張するように選択され、前記ハンドヘルドデバイスは独立の動作が可能であり、前記ヘルパーデバイスは前記選択されたリソースへのアクセスを制御するように設定され、
（ｃ−１）前記ハンドヘルドデバイスが、前記選択されたリソースを提供する前記ヘルパーデバイスのそれぞれに対して前記選択されたリソースを要求するステップと、
（ｃ−２）前記ヘルパーデバイスのそれぞれは、前記リソースが一時的に利用不能である場合には前記要求をキューイングするステップと、
（ｄ）前記選択されたリソースが、前記要求をキューイングした前記ヘルパーデバイスのうちの１つのヘルパーデバイスで利用可能になったとき、前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスが、前記ハンドヘルドデバイスに前記リソースへのアクセスを許可し、前記要求をキューイングした他のヘルパーデバイスでは前記リソースに対するすべてのキューイングされた要求を無視するステップと、
（ｅ）前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスが前記ハンドヘルドデバイスに前記選択されたリソースへのアクセスを許可したことに応じて、前記ハンドヘルドデバイスから前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスにデータを転送するステップと、
（ｇ）前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスが、前記選択されたリソースを用いて、前記データを処理するステップと、
を有し、
前記選択されたリソースに対するすべての要求は、前記ハンドヘルドデバイスからの要求をキューイングした他のヘルパーデバイスでは無視され、
前記選択されたリソースは、前記ハンドヘルドデバイスの前記独立の動作によっては十分に提供されないものであり、
前記ハンドヘルドデバイスの前記１つ以上の能力は、前記ヘルパーデバイスの前記選択されたリソースの動作を通じて拡張されることを特徴とするハンドヘルドデバイスの能力拡張方法。
前記ハンドヘルドデバイスと前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスとの間のステップ（ｅ）の通信が、前記ハンドヘルドデバイスが前記選択されたリソースの利用を完了する前に切断されたとき、ステップ（ａ）を繰り返すことを特徴とする請求項５記載の方法。
（ｆ）前記ハンドヘルドデバイスが前記データに対する前記選択されたリソースの動作を制御するステップをさらに有することを特徴とする請求項５記載の方法。
（ｇ）ステップ（ｅ）の後、前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスが、前記ハンドヘルドデバイスにインタフェース記述を送信するステップと、
（ｈ）前記ハンドヘルドデバイスが、前記インタフェース記述から制御インタフェースを構成し表示するステップと、
（ｉ）前記ハンドヘルドデバイスが、前記制御インタフェースとのユーザインタラクションを処理するステップと、
（ｊ）前記ハンドヘルドデバイスが、前記ユーザインタラクションに基づいて前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスを操作するステップと、
をさらに有することを特徴とする請求項５記載の方法。
（ｇ）ステップ（ｅ）の後、前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスが、前記データに対する前記選択されたリソースの動作のステータス報告を前記ハンドヘルドデバイスに送信するステップと、
（ｈ）前記ハンドヘルドデバイスが、前記ステータス報告に基づいてアクションをとるステップと、
をさらに有することを特徴とする請求項５記載の方法。
モバイルデバイスの１つ以上の能力を拡張するシステムにおいて、
独立の動作が可能なハンドヘルドデバイスと、
それぞれ少なくとも１つの拡張サービスを提供する複数のヘルパーデバイスと、
を有し、
前記ハンドヘルドデバイスは、前記ヘルパーデバイスのそれぞれと通信して、前記ヘルパーデバイスのうちのいずれかが、前記少なくとも１つの拡張サービスのうちの選択された拡張サービスを前記ハンドヘルドデバイスに提供することが可能かどうかを判断し、前記ヘルパーデバイスは前記選択された拡張サービスへのアクセスを制御するように設定され、
前記ハンドヘルドデバイスは、前記ヘルパーデバイスのそれぞれに対して前記選択された拡張サービスを要求し、前記ヘルパーデバイスのそれぞれは、前記選択された拡張サービスが一時的に利用不能である場合には前記要求をキューイングし、
前記選択された拡張サービスが、前記要求をキューイングした前記ヘルパーデバイスのうちの１つのヘルパーデバイスで利用可能になったとき、前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスは、前記ハンドヘルドデバイスに前記選択された拡張サービスへのアクセスを許可し、前記ハンドヘルドデバイスからの要求をキューイングした他のヘルパーデバイスでは前記選択された拡張サービスに対するすべてのキューイングされた要求は無視され、
前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスが前記ハンドヘルドデバイスに前記選択された拡張サービスへのアクセスを許可したことに応じて、前記ハンドヘルドデバイスは前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスにデータを転送し、
前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスは、前記選択された拡張サービスを用いて、前記データを処理し、
前記ヘルパーデバイスのそれぞれが、前記選択された拡張サービスへの前記ハンドヘルドデバイスのアクセスを拒否したとき、前記ハンドヘルドデバイスは、前記ヘルパーデバイスのそれぞれとの前記通信を終了し、
前記選択された拡張サービスは、前記ハンドヘルドデバイスの前記独立の動作によっては十分に提供されないものであり、
前記ハンドヘルドデバイスの前記１つまたは複数の能力は、前記ヘルパーデバイスの前記選択された拡張サービスの動作を通じて拡張される、
ことを特徴とするモバイルデバイスの１つ以上の能力を拡張するシステム。
前記データに対する前記選択された拡張サービスの動作は、前記ハンドヘルドデバイスによって制御されることを特徴とする請求項１０記載のシステム。
前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスは、前記ハンドヘルドデバイスにインタフェース記述を送信し、
前記ハンドヘルドデバイスは、前記インタフェース記述から制御インタフェースを構成し表示し、
前記ハンドヘルドデバイスは、前記制御インタフェースとの処理されたユーザインタラクションを前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスに転送し、
前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスは、前記選択された拡張サービスに基づいて前記ユーザインタラクションを解釈し、
前記ハンドヘルドデバイスは、前記ユーザインタラクションに基づいて前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスを操作し、
前記ハンドヘルドデバイスに対する変更を必要とせずに、新たな拡張サービスの追加または既存の拡張サービスの変更が可能である、
ことを特徴とする請求項１０記載のシステム。
前記インタフェース記述は、マークアップ言語で規定されることを特徴とする請求項１０記載のシステム。
前記ヘルパーデバイスのそれぞれによって提供される前記少なくとも１つの拡張サービスについてのサービス情報を記憶する記憶デバイスをさらに有することを特徴とする請求項１０記載のシステム。
前記ハンドヘルドデバイスに関連する認証データを記憶するアクセスデータベースをさらに有し、
前記ヘルパーデバイスは、前記認証データを用いて前記選択された拡張サービスへのアクセスを制御することを特徴とする請求項１０記載のシステム。
前記ハンドヘルドデバイスから転送される前記データは１つのＵＲＬからなることを特徴とする請求項１０記載のシステム。
前記ハンドヘルドデバイスから転送される前記データは１つまたは複数のＵＲＬを含むことを特徴とする請求項１０記載のシステム。
前記ハンドヘルドデバイスは、オンデマンドでアクティベートされて前記ヘルパーデバイスのそれぞれと通信するクライアントを有することを特徴とする請求項１０記載のシステム。
前記ハンドヘルドデバイスは、デーモンとして動作して前記ヘルパーデバイスのそれぞれと通信するクライアントを有することを特徴とする請求項１０記載のシステム。
前記ヘルパーデバイスのうちの前記１つのヘルパーデバイスは、前記データに対する前記選択された拡張サービスの動作のステータス報告を前記ハンドヘルドデバイスに送信し、
前記ハンドヘルドデバイスは、前記ステータス報告に基づいてアクションをとることを特徴とする請求項１０記載のシステム。
ハンドヘルドデバイスの１つ以上の能力を拡張するシステムにおいて、
少なくとも１つのリソースにアクセスする第１手段と、
前記少なくとも１つのリソースへのアクセスを制御する第２手段と、
前記第１手段と前記第２手段の間の通信を行う第３手段と、
を有し、
前記第１手段は、前記第３手段を用いて、前記第２手段が、前記少なくとも１つのリソースのうちの選択されたリソースを前記第１手段に提供することが可能かどうかを判断し、
前記第１手段は、前記第３手段を用いて、前記第２手段に対して前記選択されたリソースを要求し、前記第２手段は、前記選択されたリソースが一時的に利用不能である場合には前記要求をキューイングし、
前記選択されたリソースが、前記第２手段で利用可能になったとき、前記第２手段は、前記第１手段に前記選択されたリソースへのアクセスを許可し、前記第１手段からの前記選択されたリソースに対する他のキューイングされた要求は無視され、
前記第２手段が前記第１手段に前記選択されたリソースへのアクセスを許可したことに応じて、前記第１手段は前記第３手段を用いて前記第２手段にデータを転送し、
前記第２手段は、前記選択されたリソースを用いて、前記データを処理し、
前記第１手段は、移動可能であり、独立の動作が可能であり、
前記選択されたリソースは、前記第１手段の前記独立の動作によっては十分に提供されないものであり、
前記第１手段の前記１つまたは複数の能力は、前記第２手段の前記選択されたリソースの動作を通じて拡張されることを特徴とする、ハンドヘルドデバイスの１つまたは複数の能力を拡張するシステム。
前記データに対する前記リソースの動作は、前記第１手段によって前記第３手段を用いて制御されることを特徴とする請求項２１記載のシステム。
前記第２手段は、前記第３手段を用いて、前記第１手段にインタフェース記述を送信し、
前記第１手段は、前記インタフェース記述から制御インタフェースを構成し表示し、
前記第１手段は、前記第３手段を用いて、前記制御インタフェースとのユーザインタラクションを前記第２手段に転送し、
前記第２手段は、前記選択されたリソースに基づいて前記ユーザインタラクションを解釈し、
前記第１手段は、前記第３手段を用いて、前記ユーザインタラクションに基づいて前記第２手段を操作し、
前記第１手段に対する変更を必要とせずに、新たなリソースの追加または既存のリソースの変更が可能であることを特徴とする請求項２１記載のシステム。
前記インタフェース記述は、マークアップ言語で規定されることを特徴とする請求項２３記載のシステム。
前記リソースに対する要求は、前記第１手段に関連する能力情報を含み、
前記能力情報は、前記第２手段によって、前記第１手段へ送信する適当なインタフェース記述を決定するために使用されることを特徴とする請求項２３記載のシステム。
前記第１手段からの前記リソースに対する要求は、転送されるデータのタイプおよび該データのサイズを含むことを特徴とする請求項２１記載のシステム。
前記第１手段から転送される前記データは１つのＵＲＬからなることを特徴とする請求項２１記載のシステム。
前記第１手段から転送される前記データは１つまたは複数のＵＲＬを含むことを特徴とする請求項２１記載のシステム。
前記第１手段は、オンデマンドでアクティベートされて前記少なくとも１つのリソースにアクセスするクライアントを有することを特徴とする請求項２１記載のシステム。
前記第１手段は、デーモンとして動作して前記少なくとも１つのリソースにアクセスするクライアントを有することを特徴とする請求項２１記載のシステム。
前記第２手段は、前記第３手段を用いて、前記データに対する前記リソースの動作のステータス報告を前記第１手段に送信し、
前記第１手段は、前記ステータス報告に基づいてアクションをとることを特徴とする請求項２１記載のシステム。