(57)【要約】  信号強度が弱い又は断続的である条件下において、有線及び無線の電気通信を提供するシステム、ソフトウェア、及び装置と、このような条件下における、特に断続的な又は低信頼性の通信リンクを含む各種の通信リンク間におけるデータ及びワークフローの調整及び同期化と、このような環境における、ワイヤレスモバイルアプリケーションの管理。本明細書における本発明の技術は、コンピュータ科学、電気通信、及びデータ管理の分野に関する。
2012503449.tif 000002
【特許請求の範囲】
【請求項１】
通信経路の利用可能性が連続性を欠く、場所から場所へと変化する、時間若しくは場所によって異なる手段を使用して利用可能になる、のいずれか又は全ての場合に、成功裏に通信する可能性を高めつつ、モバイル／ポータブルデバイス（１１１０）と通信するための方法であって、
第１の通信経路（１２００）を通じてモバイル／ポータブルデバイス（１１１０）との通信を可能にすることと、
前記第１の通信経路（１２００）と少なくとも部分的に異なる第２の通信経路（１２００）を通じて前記モバイル／ポータブルデバイス（１１１０）との通信を可能にすることと、
ノード構造の少なくとも第１の部分を表わす信号を前記第１の通信経路（１２００）を通じて通信することと、
前記ノード構造の少なくとも第２の部分を表わす信号を前記第２の通信経路（１２００）を通じて通信することと、
を特徴とし、
更に、前記ノード構造の成功裏の通信の可能性を高めるために、前記第１の通信経路（１２００）を通じて送信された前記信号及び前記第２の通信経路（１２００）を通じて送信された前記信号を使用し、該使用は、前記第１の及び第２の通信経路（１２００）を通じて運ばれた重複する情報を調整することを含むことを特徴とする方法。
【請求項２】
請求項１に記載の方法であって、更に、
前記同じノード構造の異なる部分について、あまり好ましくない通信経路（１２００）よりも好ましい通信経路（１２００）を状況に応じて使用するために、前記第１の通信経路と前記第２の通信経路と（１２００）の間で選択を行うことを特徴とする方法。
【請求項３】
請求項１ないし２のいずれかに記載の方法であって、更に、
前記第１の通信経路と前記第２の通信経路と（１２００）の間で動的に切り替えを行うことを特徴とする方法。
【請求項４】
請求項１ないし３のいずれかに記載の方法であって、更に、
前記第１の及び第２の通信経路（１２００）を一度に１本ずつ使用することを特徴とする方法。
【請求項５】
請求項１ないし４のいずれかに記載の方法であって、更に、
前記ノード構造の前記同じ部分又は異なる部分に対し、前記第１の及び第２の通信経路（１２００）の両方を同時に使用することを特徴とする方法。
【請求項６】
請求項１ないし５のいずれかに記載の方法であって、更に、
前記第１の及び第２の通信経路（１２００）は、異なる特性を有することを特徴とする、方法。
【請求項７】
請求項６に記載の方法であって、更に、
前記第１の及び第２の通信経路（１２００）は、異なる速度／帯域幅特性を有することを特徴とする、方法。
【請求項８】
請求項６に記載の方法であって、更に、
前記第１の及び第２の通信経路（１２００）は、異なる信頼性を有することを特徴とする、方法。
【請求項９】
請求項６に記載の方法であって、更に、
前記第１の及び第２の通信経路（１２００）は、異なる使用コストを有することを特徴とする、方法。
【請求項１０】
請求項６に記載の方法であって、更に、
前記第１の及び第２の通信経路（１２００）は、異なる通信プロトコルを使用することを特徴とする、方法。
【請求項１１】
請求項６に記載の方法であって、更に、
前記第１の及び第２の通信プロトコルは、異なる伝送媒体を使用することを特徴とする、方法。
【請求項１２】
請求項１ないし１１のいずれかに記載の方法であって、更に、
前記データ項目を好ましい通信経路（１２００）以外の時間、順序、手段のいずれか又は全てによって送信するために帯域外伝送を使用することを特徴とする方法。
【請求項１３】
請求項１ないし１２のいずれかに記載の方法であって、更に、
前記送信されるべきデータ項目の特性に一部基づいて伝送方法が決定される優先メッセージングを提供することを特徴とする方法。
【請求項１４】
請求項１ないし１３のいずれかに記載の方法であって、更に、
重複の発生が偶発的であれ意図的であれ、重複するノード構造及びデータ項目を検出して排除することを特徴とする方法。
【請求項１５】
請求項１ないし１４のいずれかに記載の方法であって、更に、
送り手が受け手に連絡を取ってノード構造の転送を開始させるプッシュモード伝送モデルを使用することを特徴とする方法。
【請求項１６】
請求項１ないし１５のいずれかに記載の方法であって、更に、
送り手が受け手に連絡を取り、プルモードセッションを開始させるように前記受け手に要求するコマンドを含むノード構造を送信する協調プッシュモード伝送モデルを使用すること特徴とする方法。
【請求項１７】
請求項１ないし１６のいずれかに記載の方法であって、更に、
前記送り手の要求及び前記受け手のプルモードセッションは、異なる通信経路（１２００）上で発生することを特徴とする方法。
【請求項１８】
請求項１ないし１７のいずれかに記載の方法であって、更に、
前記デバイス（１１１０）と別のデバイス（１１１０）との間でノード構造を送信するためにピア・ツー・ピア（Ｐ２Ｐ）ノード構造伝送モデルを使用することを特徴とし、更に、前記デバイスは、一方が通信を開始させることができ、一方又は両方が他方にノード構造を伝送することができることを特徴とする方法。
【請求項１９】
請求項１ないし１８のいずれかに記載の方法であって、更に、
１つ又は複数の特定されたタスクの割り当てを受け入れる意思がある１人又は複数人のユーザを特定し、それらに前記タスクを提供するために、告知及び受け入れ（Ａ＆Ａ）メカニズムを使用することを特徴とする方法。
【請求項２０】
請求項１ないし１９のいずれかに記載の方法であって、更に、
サーバの助けによって又はよらずに第１のデバイス（１１１０）から第２のデバイス（
１１１０）にタスクを転送するために、タスクデリゲートを使用することを特徴とする方法。
【請求項２１】
請求項１ないし２０のいずれかに記載の方法であって、更に、
データ項目、データ項目群、デバイス（１１１０）、又はサーバに対するアクセス、使用、又は変更の制限を可能にする柔軟なセキュリティモデルを使用することを特徴とする方法。
【請求項２２】
請求項１ないし２１のいずれかに記載の方法であって、更に、
第１のデバイス（１１１０）のカタログと第２のデバイス（１１１０）のカタログとの間の相違を識別及び解消することを特徴とする方法。
【請求項２３】
通信経路（１２００）の利用可能性が連続性を欠く、場所から場所へと変化する、時間若しくは場所によって異なる手段を使用して利用可能になる、のいずれか又は全ての場合に、成功裏に通信する可能性を高める構成を含む、モバイル／ポータブルデバイス（１１１０）であって、
第１の通信経路（１２００）を通じて通信を可能にする第１の通信インターフェースと、
前記第１の通信経路（１２００）と少なくとも部分的に異なるの第２の通信経路（１２００）を通じて通信を可能にする第２の通信インターフェースと、
を特徴とし、更に、
ノード構造の少なくとも第１の部分を表わす信号を前記第１の通信経路（１２００）を通じて通信し、前記ノード構造の少なくとも第２の部分を表わす信号を前記第２の通信経路（１２００）を通じて通信する通信コントローラと、
前記ノード構造の成功裏の通信の可能性を高めるために、前記第１の通信経路（１２００）を通じて送信された前記信号及び前記第２の通信経路（１２００）を通じて送信された前記信号を使用し、該使用は、前記第１の及び第２の通信経路（１２００）を通じて運ばれた重複する情報を調整することを含む、プロセッサと、
を特徴とするデバイス。
【請求項２４】
請求項２３に記載のデバイス（１１１０）であって、更に、
前記同じノード構造の異なる部分について、あまり好ましくない通信経路（１２００）よりも好ましい通信経路（１２００）を状況に応じて使用するために、前記第１の通信経路と前記第２の通信経路と（１２００）の間で選択を行うための手段を特徴とするデバイス。
【請求項２５】
請求項２３ないし２４のいずれかに記載のデバイス（１１１０）であって、更に、
前記第１の通信経路と前記第２の通信経路と（１２００）の間で動的に切り替えを行うように構成されたスイッチを特徴とするデバイス。
【請求項２６】
請求項２３ないし２５のいずれかに記載のデバイス（１１１０）であって、
更に、前記第１の及び第２の通信インターフェースは、前記第１の及び第２の通信経路（１２００）を一度に１本ずつ使用するように構成されることを特徴とする、デバイス。
【請求項２７】
請求項２３ないし２６のいずれかに記載のデバイス（１１１０）であって、
更に、前記第１の及び第２の通信インターフェースは、前記ノード構造の前記同じ部分又は異なる部分に対し、前記第１の及び第２の通信経路（１２００）の両方を同時に使用するように構成されることを特徴とする、デバイス。
【請求項２８】
請求項２３ないし２７のいずれかに記載のデバイス（１１１０）であって、
更に、前記第１の及び第２の通信経路（１２００）は、異なる特性を有することを特徴とする、デバイス。
【請求項２９】
請求項２８に記載のデバイス（１１１０）であって、
更に、前記第１の及び第２の通信経路（１２００）は、異なる速度／帯域幅特性を有することを特徴とする、デバイス。
【請求項３０】
請求項２８に記載のデバイス（１１１０）であって、
更に、前記第１の及び第２の通信経路（１２００）は、異なる信頼性を有することを特徴とする、デバイス。
【請求項３１】
請求項２８に記載のデバイス（１１１０）であって、
前記第１の及び第２の通信経路（１２００）は、異なる使用コストを有する、デバイス。
【請求項３２】
請求項２８に記載のデバイス（１１１０）であって、更に、
前記第１の及び第２の通信経路（１２００）は、異なる通信プロトコルを使用することを特徴とする、デバイス。
【請求項３３】
請求項２８に記載のデバイス（１１１０）であって、更に、
前記第１の及び第２の通信プロトコルは、異なる伝送媒体を使用することを特徴とする、デバイス。
【請求項３４】
請求項２３ないし３３のいずれかに記載のデバイス（１１１０）であって、更に、
前記第１及び前記第２の通信インターフェースは、好ましい通信経路（１２００）以外の時間、順序、手段のいずれか又は全てによって前記データ項目を送信するために帯域外伝送を使用するように構成されることを特徴とする、デバイス。
【請求項３５】
請求項２３ないし３４のいずれかに記載のデバイス（１１１０）であって、更に、
送信されるべきデータ項目の特性に一部基づいて伝送技術を決定することによる優先メッセージングを提供するノード構造優先付けモジュールを特徴とするデバイス。
【請求項３６】
請求項２３ないし３５のいずれかに記載のデバイス（１１１０）であって、更に、
前記プロセッサは、重複の発生が偶発的であれ意図的であれ、重複するノード構造及びデータ項目を検出して排除することを特徴とする、デバイス。
【請求項３７】
請求項２３ないし３６のいずれかに記載のデバイス（１１１０）であって、更に、
前記通信コントローラは、送り手が受け手に連絡を取ってノード構造の転送を開始させるプッシュモード伝送モデルを使用することを特徴とする、デバイス。
【請求項３８】
請求項２３ないし３７のいずれかに記載のデバイス（１１１０）であって、更に、
前記通信コントローラは、送り手が受け手に連絡を取り、プルモードセッションを開始させるように前記受け手に要求するコマンドを含むノード構造を送信する協調プッシュモード伝送モデルを使用すること特徴とする、デバイス。
【請求項３９】
請求項３８に記載のデバイス（１１１０）であって、更に、
前記送り手の要求及び前記受け手のプルモードセッションは、異なる通信経路（１２００）上で発生することを特徴とする、デバイス。
【請求項４０】
請求項２３ないし３９のいずれかに記載のデバイス（１１１０）であって、更に、
前記通信コントローラは、前記デバイス（１１１０）と別のデバイス（１１１０）との間でノード構造を送信するためにピア・ツー・ピア（Ｐ２Ｐ）ノード構造伝送モデルを使用し、前記デバイスは、いずれも通信を開始させることができ、いずれも他方にノード構造を伝送することができることを特徴とする、デバイス。
【請求項４１】
請求項２３ないし４０のいずれかに記載のデバイス（１１１０）であって、更に、
１つ又は複数の特定されたタスクの割り当てを受け入れる意思がある１人又は複数人のユーザを特定し、それらに前記タスクを提供するための、告知及び受け入れ（Ａ＆Ａ）メカニズムを特徴とするデバイス。
【請求項４２】
請求項２３ないし４１のいずれかに記載のデバイス（１１１０）であって、更に、
サーバの助けによって又はよらずに第１のデバイス（１１１０）から第２のデバイス（１１１０）にタスクを転送するタスクデリゲートモジュールを特徴とするデバイス。
【請求項４３】
請求項２３ないし４２のいずれかに記載のデバイス（１１１０）であって、更に、
データ項目、データ項目群、デバイス（１１１０）、又はサーバに対するアクセス、使用、又は変更の制限を可能にする柔軟なセキュリティ構成を特徴とするデバイス。
【請求項４４】
請求項２３に記載のデバイス（１１１０）であって、更に、
第１のデバイス（１１１０）のカタログと第２のデバイス（１１１０）のカタログとの間の相違を識別及び解消するカタログモジュールを特徴とするデバイス。
【請求項４５】
タスク選択を提供する方法であって、
タスク割り当てを第１のデバイス（１１１０）から第２のデバイス（１１１０）に転送することと、
前記タスク割り当てがキャンセルされたことを前記第２のデバイス（１１１０）に通知することと、
第１のデバイス（１１１０）のカタログと第２のデバイス（１１１０）のカタログとの間の相違を識別及び解消することと、
を特徴とする方法。
【請求項４６】
手持ち式のポータブルメッセージング／タスキングデバイス（１１１０）であって、
手持ち式のケースと、
前記ケース上に配されたディスプレイと、
前記ケース内に配され、前記ディスプレイに結合されたプロセッサと、
前記ケース内に配され、前記プロセッサに結合されたワイヤレス通信構成であって、第１のワイヤレスプロトコルを使用して第１のワイヤレス経路（１２００）を通じて通信するための第１のワイヤレス通信インターフェースと、前記第１のワイヤレスプロトコルと異なる第２のワイヤレスプロトコルを使用して第２のワイヤレス経路（１２００）を通じて通信するための第２のワイヤレス通信インターフェースとを含むワイヤレス通信構成と、
を特徴とし、更に、
前記ワイヤレス通信構成を介してノードの同期化に関連したメッセージングを通信するノードプロセッサであって、前記ワイヤレス通信構成に、前記第２の通信経路（１２００）を通じて通信された情報に重複するノード情報を前記第１の通信経路（１２００）を通じて通信させることによって、同期化されたノード通信が成功裏になされる可能性を高め、前記ディスプレイに、前記同期化されたノードに少なくとも部分的に対応するタスキング／メッセージング情報を表示させるノードプロセッサを特徴とするデバイス。
【請求項４７】
請求項４６に記載のデバイス（１１１０）であって、更に、
前記ノードプロセッサは、前記第１の及び第２の通信経路（１２００）を通じて運ばれる重複する情報を調整することを特徴とする、デバイス。
【請求項４８】
請求項４６に記載のデバイス（１１１０）であって、更に、
前記第１のプロトコルは、セルラ方式のワイヤレステレフォニを含むこと、及び前記第２のプロトコルは、Ｂｌｕｅｔｏｏｔｈを含むことを特徴とする、デバイス。
【請求項４９】
請求項４６に記載のデバイス（１１１０）であって、更に、
前記第１のプロトコルは、８０２．１１を含むこと、及び前記第２のプロトコルは、Ｂｌｕｅｔｏｏｔｈを含むことを特徴とする、デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願の相互参照］
本出願は、２００５年６月２９日に出願された同時係属米国特許出願第１１／１６９，１４９号の一部継続出願であり、２００８年９月２２日に出願された仮出願第６１／０９８，８８６号の利益を主張する。これらの各先願は、あらゆる目的のために参照によって全体を本明細書に組み込まれる。
【０００２】
［技術分野］
本明細書における技術は、なかでも特に、信号強度が乏しい又は断続的である条件下において、有線及び無線の電気通信を提供するシステム、ソフトウェア、及び装置に関する。本明細書における典型的で例示的で非限定的な技術は、なかでも特に、このような条件下における、特に断続的な又は低信頼性の通信リンクを含む各種の通信リンク間におけるデータ及びワークフローの調整及び同期化と、このような環境における、ワイヤレスモバイルアプリケーションの管理とを提供する。本明細書における技術は、更に、より広くは、コンピュータ科学、電気通信、及びデータ管理の分野に関する。
【発明の概要】
【０００３】
［背景および概要］
一般的なワイヤレス通信
ワイヤレス通信（「ワイヤレス」）では、２つ又は３つ以上の電子デバイスがそれらの間に物理的接続（すなわち、ワイヤ又はケーブル）を必要とすることなく情報を交換できる。ワイヤレスは、固定されていてもよいし、モバイル／ポータブルであってもよい。概して、固定ワイヤレスは、１つの固定位置から別の固定位置への又は固定位置とモバイル／ポータブルデバイスとの間のワイヤレス通信を可能にする。モバイル／ポータブルワイヤレスは、固定（例：中央）サイトと可動デバイスとの間、及び／又は２つ若しくは３つ以上のモバイル／ポータブルデバイスの間の通信を可能にする。固定ワイヤレス環境における２つのサイト間の接続性のレベル（例：信号強度及びその他の関連パラメータ）は、いずれのサイトもいかなる時も移動しないゆえに、通例、（天候及びその他の条件が一定であると仮定すれば）かなり一定である。しかしながら、モバイルワイヤレスにおける接続性のレベルは、例えば、ワイヤレスデバイスの位置、モバイルワイヤレス通信のトランスミッタ、レシーバ、及び／又はトランシーバの相対的位置、並びに木、建物、山、又はマルチパス若しくはその他の干渉を生じ得る若しくはそれ以外のやり方でワイヤレス信号の伝搬を変化させ得るその他の物体若しくは現象に依存して、大幅に変化する可能性がある。
【０００４】
モバイルワイヤレスデバイス（本明細書ではワイヤレスデバイス又はモバイルデバイスとも称される）のほんの幾つかの例として、ポケットベル、モバイルフォン、及びモバイルフォン、ポケットベル、携帯情報端末（ＰＤＡ）の機能性を含む組み合わせデバイスが挙げられる。これらのデバイスは、文字情報の交換（例：ポケットベル、携帯電話、又はＰＤＡを使用）はもちろん、音声及びデータの交換（例：携帯電話及びＰＤＡを使用）も可能にすることができる。現在のワイヤレスデバイスの多くは、例えばテレフォニデータ（例：ＧＰＲＳ、ＥＤＧＥなど）、ワイヤレスローカルエリアネットワーク（ＬＡＮ）（例：Ｗｉ−Ｆｉ）、及び短距離デバイス相互接続（例：Ｂｌｕｅｔｏｏｔｈ）のような、複数の通信インターフェースに対するサポートを組み入れている。複数の通信インターフェースは、伝送要件と通信経路の特性及び特徴とがベストマッチする（１本又は複数本の）通信経路の選択によって、通信経路使用の最適化を可能することができるが、このような最適化は、必ずしも一般的ではない、又はデバイスのメーカによって提供される事前定義されたプリファレンスを使用してなされる。１つの通信インターフェースのみをサポートするデバイスは、通常、このような最適化に対応することができない。ワイヤレスデバイスは、また、最近では、グローバルポジショニングシステム（ＧＰＳ）アクセス、カメラ、スキャナ（無線自動識別（ＲＦＩＤ）及びバーコードを処理可能なスキャナを含む）、並びに磁気／光データストレージカードなどの有用な特徴と統合されている。これらのタイプのデバイスは、人々が旅行中又は作業中も複数のリモート位置から互いに連絡を取り合うことを可能にし、複数のタイプのデータの収集を容易にした。更に、人々の間で交換される情報は、今述べられた特徴の統合及び集約の伸展ゆえに、近年著しく豊富になっている。
【０００５】
モバイルワイヤレスデバイスは、通常、電波などを非限定例として挙げられる電磁波を使用して通信する。トランスミッタは、ワイヤレス通信のアクセスポイント（point-of-presence）からワイヤレスデバイスに信号を送信し、レシーバは、アクセスポイントで受信されたデバイスからの信号を処理する。トランシーバは、送信及び受信の両方を行う。この状況下では、アクセスポイントは、モバイルワイヤレスデバイスと通信することができる１つ又は複数のトランスミッタ、レシーバ、及び／又はトランシーバを含む。例えば、携帯電話ネットワークの通信塔や、コーヒーショップにあるワイヤレスＬＡＮ接続が、アクセスポイントの非限定例として挙げられる。アクセスポイントのネットワークと連絡している中央サイトは、デバイスと適切なアクセスポイントとの間の通信を制御することができる。アクセスポイントは、場合によっては、デバイスの移動に伴い連続した通信を可能にするために、互いのサービスエリアが一部重なるように相隔てられる。アクセスポイントとモバイルワイヤレスデバイスとの間で接続がなされている限り、デバイスの能力に相応して情報の送受信を行うことができる。しかしながら、多くの環境では、アクセスポイントの圏内に入らないエリアが存在するゆえに、そして土地の起伏、建物の建築材、又はその他の要因が信号に干渉し得るゆえに、アクセスポイントとの間にこのような一定の連絡を維持することが不可能である。その結果、ポケットベルが数分間若しくは数時間にわたって圏外になったり、モバイルフォンの通話が会話の途中で途切れたり、データサービスが通信のシーケンス及びトランザクションを部分的に完了させることしかできず、その結果、データが損失されたりする可能性がある。現在は、ワイヤレスデバイスを互いに接続する又はワイヤレスデバイスを非モバイルデバイス若しくはインターネットに接続するために、各種の特性を持つ様々なサービスが用いられている。
【０００６】
セルラ方式の通信
携帯電話会社は、多くの場合、その加入者に、音声通話サービスはもちろんデータサービスも提供している。このようなデータサービスの例として、ＣＳＤ（Circuit Switched
Data）、ＧＰＲＳ（General Packet Radio Service）、及びＥＤＧＥ（Enhanced Data rates for GSM Evolution）又はＥＧＰＲＳ（Enhanced GPRS）などの拡張ヴァージョンはもちろん、ＵＭＴＳ（Universal Mobile Telecommunications System）などの「次世代」システムが挙げられる。このようなシステムは、サポートされているデバイスと、インターネット又は携帯電話会社によって提供されるＳＭＳ（Short Message Service）などのシステムとの間のデータ接続性を提供するために、無線リンクを通じて動作する。これらの各サービスの実装形態の詳細は多様であるが、大半のユーザにとっては透過的である。最も明らかな相違は、各自が提供する帯域幅又はデータ速度である。使用されているシステムに応じ、データ速度は、目下のところＣＳＤの９．６キロビット／秒とＵＭＴＳの１６メガビット／秒との間である。例えば、いわゆる３Ｇモバイル通信規格は、通話サービス及びデータサービスの同時使用と、ダウンリンクで最大１４．０メガビット／秒及びアップリンクで最大５．８メガビット／秒のデータ速度とを可能にする。より高速な技術が、開発中である。場合によっては、これらのサービスは、携帯電話以外のＰＤＡなどのデバイスによって直接的に使用される、又はアダプタカードの使用若しくはデータ通信デバイスとしてつなげた携帯電話若しくはその他のデバイスの使用を通してノートパソコンなどのデバイスによって間接的に使用される。
【０００７】
セルラ方式のデータサービスは、通例ＴＣＰ／ＩＰを含む各種のデータプロトコルを、携帯電話会社のデータネットワークを通じて、そして多くはゲートウェイを通してインターネット上のシステムへとサポートしている。このような接続は、有線技術と比べて低速であると考えられ、また、プロバイダによって月額固定料金だったり伝送データバイト数に基づいて課金されたりするゆえに、高価であるとも考えられる。これらのサービスのサービスエリアは、同じ携帯電話会社を通した音声通話のサービスエリアよりも限られることがあるが、通常は、大半の都市及び都市間の主要ルート沿いにおいて利用可能である。ＴＣＰ／ＩＰに使用される（１つ又は複数の）アドレス指定体系及びモバイルデバイスでよく使用される（１つ又は複数の）実装方法では、デバイスは、多くの場合、ネットワークに接続するたびに、及び場合によっては接続中でも、異なるネットワークアドレスを割り当てられ（「動的ＩＰ」）、デバイスのアドレスはわからないうえに頻繁に変わり得るので、ＴＣＰ／ＩＰを使用して他のデバイスからモバイルデバイスに接続することは、ときによっては困難である。場合によっては、特定の固定ネットワークアドレス（「静的ＩＰ」）をデバイスに割り当てるなど、このような接続を可能にする特殊な措置をサービスプロバイダに講じることができるが、このようなやり方は、一般的でないことが多く、費用の増大を伴うのが通常である。ＴＣＰ／ＩＰ接続は、したがって、モバイルデバイスから発せられるのが通常である。なぜならば、モバイルデバイスのみが、自身の現在のＴＣＰ／ＩＰアドレスを承知して、それを、ＴＣＰ／ＩＰプロトコルによる必要に応じてＴＣＰ／ＩＰデータパケットヘッダに含ませることができるからである。また、ホットスポットプロバイダのなかには、そのホットスポット内の全てのデバイスが１つのＩＰアドレスを共有可能であるように、ＮＡＴ（Network Address Translation）と呼ばれる技術を使用するものがある。通例の実装方式では、ＮＡＴは、ホットスポット内のデバイスから最初に接続を確立しない限り、ホットスポットを使用しているデバイスへのホットスポットの外のデバイスからの接続を阻み、たとえ許可された場合でも、ホットスポット内のデバイスへの接続は、ＦＴＰ（File Transfer Protocol）などの特定のプロトコルに限定され得る。接続は、ひとたび形成されれば、双方向であるのが通常であり、モバイルデバイスに対し、サーバデバイスに対し、又は別のモバイルデバイスに対してデータの送受信が行われる。これらのプロトコル及びインフラの制限は、モバイルデバイスへのＴＣＰ／ＩＰプッシュモード接続を阻み、モバイルデバイスにサーバ又は別のモバイルデバイスからデータを送信したいときにシステム全体の応答性を低下させる可能性がある。
【０００８】
モバイルデバイス及びモバイルデバイスに接続するサービスには、ＴＣＰ／ＩＰに加えて、又はＴＣＰ／ＩＰの代わりに、ＳＭＳ（Short Message Service）又はＭＭＳ（Multimedia Messaging Service）などの他のデータプロトコルをサポートするものがある。これらのプロトコルは、プッシュモードを使用してモバイルデバイスに送信する能力などのＴＣＰ／ＩＰに優る利点と、伝送が遅れる、メッセージサイズが限られる、コンテンツに制限がある、及びコストが高い（例：メッセージごとに数セント（約数円））などの欠点とを有すると考えられる。データの配信は、配信が試行されるが保証はされないＳＭＳ及びその「最善努力（best attempt）」配信などのように、多くの場合、信頼できない。
【０００９】
ピア・ツー・ピア通信
１つの非サーバデバイスが別の非サーバデバイスにデータを送信するときに、その交換は、「ピア・ツー・ピア」（Ｐ２Ｐ）と称される。これは、ＴＣＰ／ＩＰ、Ｂｌｕｅｔｏｏｔｈ、ＳＭＳ、Ｅｔｈｅｒｎｅｔ（登録商標）などの、各種のプロトコル及び通信メカニズムを使用して達成される。しかしながら、メカニズム又はプロトコルのなかには、ほかよりもこの使用に問題のあるものがある。例えば、多くのモバイルＴＣＰ／ＩＰサポートデバイスによって使用される動的なアドレス割り当ては、インターネットに接続するたびに異なるＴＣＰ／ＩＰアドレスを有する結果となり、他のデバイスは、このアドレスを知る方法がなく、ゆえに、このデバイスとの接続を開始させることができず、したがって、どちらのデバイスも接続することができるシステムが一方又は両方のデバイスにアドレス情報を供給するための調整役として機能することができる場合を除いて、ＴＣＰ／ＩＰを使用したＰ２Ｐ接続は阻まれる。このような調整を実現するためのよくある１つの方法は、Ｄｙｎａｍｉｃ  ＤＮＳ（Dynamic Domain Name System）の使用であり、この方法では、デバイスは、自身のアドレスをＤＮＳサーバに登録し、そのアドレスを他のデバイスが学んで自身との通信を開始させることを可能にするが、情報のキャッシングゆえに、そしてときには、１つのホットスポットから別のホットスポットへと短時間に移動することがあるモバイルデバイスによくあるアドレスの急な変化ゆえに、この解決策は、信頼できないことが多く、全く役に立たないことさえある。一部のプロトコルに内在するアドレス指定の問題に加えて、Ｐ２Ｐには、デバイスの発見及び認証の問題もある。デバイスは、状況によっては、他のデバイスの存在に関する情報はもちろん、それらの他のデバイスとの通信を確立するために必要な方法又は情報を取得するように求められることがある。この情報を提供又は取得する手段が有用であると考えられる。
【００１０】
デバイスには、Ｂｌｕｅｔｏｏｔｈ又はその他の短距離デバイス接続を使用した接続をサポートできるものがある。Ｂｌｕｅｔｏｏｔｈは、ＧＰＲＳなどの技術から遮断されているエリア（すなわち、工場若しくは大きな建物などの構造物の内部、又は地中深くにある地下）や、Ｗｉ−Ｆｉが実用的でない又は望ましくないエリアに、接続性を拡張するのに有用でありうる。例えば、Ｗｉ−Ｆｉの範囲の広さがセキュリティ懸念を生じ得る場合に車両リンクを通してポータブルデバイスを接続する場合や、デバイスがデータの交換を必要としておりＢｌｕｅｔｏｏｔｈのピア・ツー・ピア能力ではこれが可能だが、モバイルデバイスに対するＷｉ−ＦｉのＴＣＰ／ＩＰアドレス指定の制限がこれを阻む場合などである。Ｂｌｕｅｔｏｏｔｈは、また、リモートデバイスに接続するための、ダイヤルアップモデム、Ｅｔｈｅｒｎｅｔインターフェース、Ｔｏｋｅｎ  Ｒｉｎｇ  Ａｄａｐｔｅｒなどの方法をサポートしているデバイスへのリンクとしても、よく使用される。このようなリンクは、考えられる複数の通信経路の第１の又はその他のリンクとして機能することによって、Ｂｌｕｅｔｏｏｔｈ対応デバイスのための通信の選択肢を広げることができる。
【００１１】
Ｂｌｕｅｔｏｏｔｈ対応デバイスは、ピコネットとして知られる短距離アドホックネットワークを通して無線リンク上でワイヤレスで接続及び通信することができる。標準的な一実装形態では、各デバイスは、１つのピコネット内で最大７つの他のデバイスと通信することができ、ここでは、１つのデバイスが「マスタ」として機能し、その他のデバイスが「スレーブ」として機能する。各デバイスは、また、同時に幾つかのピコネットに属することもできる。ピコネットは、Ｂｌｕｅｔｏｏｔｈ対応デバイスが電波近接エリアに出入りするときに、動的に且つ自動的に確立される。電波近接エリアは、関係しているデバイスのクラスに応じて、１、２フィートから数百フィートまでの幅がある。ピコネットは、また、それらの間の橋渡しとして機能するシステムによってつなぐこともできる。このような構成は、「スキャッタネット」として知られる。
【００１２】
Ｂｌｕｅｔｏｏｔｈデバイスは、干渉に対して耐性があり尚且つデータの暗号化及び他のデバイスの暗号識別を含むことができる方法によって、一部のデバイスでのＴＣＰ／ＩＰを含む各種のプロトコルを使用して、７２１キロビット／秒の速度でデータを転送する。全てのＢｌｕｅｔｏｏｔｈデバイスが同じプロトコルをサポートしているわけではなく、多くは、ノード又はその他の外部供給プログラミングの使用をサポートしていないヘッドフォンやバーコードリーダなどの特殊用途のデバイスである。しかしながら、その他のＢｌｕｅｔｏｏｔｈデバイスは、ネットワークインターフェースとして機能することを意図されており、Ｂｌｕｅｔｏｏｔｈ対応ＰＤＡ、コンピュータ、又は同様のその他のデバイスの、ＬＡＮ又はインターネットへの接続をサポートすることができる。また、２つ又は３つ以上のＰＤＡ、ノートパソコン、又はその他のＢｌｕｅｔｏｏｔｈ対応デバイスが、ピア・ツー・ピア方式でデータを交換することも可能である。Ｂｌｕｅｔｏｏｔｈ又はその他の基準の具体的にどのプロトコル及び機能が所定のデバイスによってサポートされているかは、そのデバイスのメーカによって決定され、場合によっては、少なくとも一部のデバイスでは後から変更不可能である。
【００１３】
Ｗｉ−Ｆｉ通信
ワイヤレスデバイスには、Ｗｉ−Ｆｉ（Wireless Fidelity）を使用するものなどのように、ワイヤレスＬＡＮへの接続をサポートしているものがある。Ｗｉ−Ｆｉは、ＩＥＥＥ  ８０２．１１規格に基づいてワイヤレスＬＡＮ製品の相互運用性を向上させる目的でＷｉ−Ｆｉ  Ａｌｌｉａｎｃｅによって所有されているワイヤレス技術のブランド名である。Ｗｉ−Ｆｉ  Ａｌｌｉａｎｃｅは、ＩＥＥＥ  ８０２．１１規格シリーズに基づく一連の共通の相互運用可能製品に合意する個々の企業の集団である。ノートパソコン、携帯電話、又はＰＤＡなどのＷｉ−Ｆｉデバイスは、ＬＡＮに接続されたワイヤレスネットワークアクセスポイント（ＷＡＰ）の領域内にあるときに、そのネットワークに接続することができる。もしそのネットワークがインターネットに接続されているならば、Ｗｉ−Ｆｉデバイスは、ネットワークのゲートウェイ又はその他の手段を通してインターネットにアクセスすることができる。相互接続された１つ又は複数のアクセスポイントによってカバーされたエリアを、「ホットスポット」と呼ぶ。ホットスポットは、小さくは一部屋ほどの領域を、又は大きくはアクセスポイントの重なり合いを使用して数平方マイルもの領域をカバーすることができる。ホットスポットは、多くの企業、家庭、及び公共施設（空港など）で利用可能であり、地域によっては、街や大学構内の全体をカバーするＷｉ−Ｆｉネットワークを実装しているところもある。
【００１４】
概して、Ｗｉ−Ｆｉは、デバイスどうしの直接接続を可能にするピア・ツー・ピア（ワイヤレスアドホックネットワーク）モードでの接続も可能にするが、この能力は、セキュリティ上の理由でしばしば無効にされる。アドホックワイヤレスネットワークは、例えば、２つ又は３つ以上のデバイスがネットワーク接続を共有しているが外部サーバ又はインターネットへのアクセスを必要としないときなどに、有利である。
【００１５】
Ｗｉ−Ｆｉは、最大で数メガビット／秒又は多メガビット／秒の帯域幅をサポートすることができ、尚且つ大半の民間のホットスポットが固定使用料を課している又は顧客を引き付ける手段として無料アクセスを提供しているため、安価又は無料であり、尚且つ遅延がごく小さく且つ信頼性に優れている。多くの又は大半のケースでは、サービスエリアが狭い領域に限られ、サービスエリアから離れると、通例ほとんど又は全く警告なく接続性が断ち切られる。また、携帯電話ネットワーク上におけるＴＣＰ／ＩＰと同様に、Ｗｉ−Ｆｉホットスポットで使用されるアドレス指定方法は、ホットスポットのＬＡＮ上にないデバイスからモバイルデバイスに接続することを不可能にし、接続は、通常、モバイルデバイス発信でなければならない。これは、Ｗｉ−Ｆｉを使用してサーバへの連絡を開始するようにモバイルデバイスに送信又は要求するために使用されるＳＭＳなどの別の連絡方法がない限り、Ｗｉ−Ｆｉを使用してモバイルデバイスに送信するときのサーバ発信伝送モードを使用不可にする。このサーバプッシュ可能通信経路を使用して、サーバプッシュ可能でない異なる通信経路を使用したサーバへの接続を開始するようにモバイルデバイスに要求することは、「協調プッシュ」と称されることがある。サーバは、協調プッシュ交換を開始させるために、任意のサーバプッシュ可能通信経路を用いることができる。
【００１６】
複数通信インターフェース
デバイスには、２つ以上の通信インターフェースをサポートする能力を有するものがある。例えば、デバイスには、２つ又は３つ以上のインターフェースを同時にサポートでき
るものがある。その他のデバイスは、異なる時間に異なるインターフェースをサポートすることができる。このような実装形態は、通常、特定デバイスの設計及び構成によって決定される。複数の通信インターフェースをサポートすることができるデバイスは、通常、これらのインターフェースの使用を様々なやり方で管理する。一部の典型的な実装形態では、デバイスは、所定の時間にどの（１つ又は複数の）インターフェースを使用するかを、ユーザプリファレンスを定めた構成設定を使用して自動的に選ぶことができる。その他のデバイスでは、通信インターフェースの選択は、ユーザによって手動で、又はアプリケーションソフトによって、又はデバイス若しくはそのオペレーティングシステムの設計によってなされる。一例として、カリフォルニア州クパチーノのＡｐｐｌｅ  ＣｏｍｐｕｔｅｒによるＡｐｐｌｅ  ｉＰｈｏｎｅなどの先行技術システムは、何らかの形態の通信を維持することができるように、デバイス上で実行されているアプリケーションソフトに対して透過的なやり方で通信インターフェースを自動的に切り替えることができるデバイス実装形態を提供する。その他の先行技術システムは、通信経路の切り替えを透過的には行わず、アプリケーションによって使用されている通信インターフェースが接続可能性を失うときに、アプリケーションソフトが特定のアクションをとって通信インターフェースを切り替える必要がある。これらのアクションは、モバイルデバイスの設計又は構成によって異なると考えられ、例えば、利用可能な接続性を持つ通信インターフェースをデバイスに見つけさせるために接続の再確立を試みること、まだ利用可能なもののなかから新しい通信インターフェースを選んでサーバ接続を再確立すること、又は特定のデバイス実装形態を熟知した者によく知られているその他のアクションをとることなどが挙げられる。接続可能性の損失を検出するデバイスは、通常、最も近いアクセスポイントへの接続性リンクの信号強度、ポーリング、又はその他の特性に基づいてそれを行うのであって、アクセスポイントからサービスプロバイダのインフラへの接続又はサービスプロバイダからインターネットへの接続における故障などのような、接続のその他のセグメントで生じる接続性の損失は必ずしも検出しない。信号損失以外の損失が起きても、大半のデバイスでは必ずしも代わりのインターフェースへフェイルオーバするわけではない。これは、モバイルデバイスと異種のデバイス又はサーバとの間の通信に悪影響を及ぼす可能性がある。
【００１７】
複数の通信インターフェースをサポートすることができるデバイスには、検出可能な接続性の損失が生じるまでは、必ずしも通信インターフェースの切り替えを行わないものがある。このようなデバイスには、インターフェース接続の可用性が変化しても、必ずしも利用可能インターフェース間で動的に切り替えを行わないものがある。これは、より効率的なインターフェースが利用可能になった後も、あまり効率的でない通信インターフェースが使用され続ける結果を招く可能性がある。これは、コストが高い、データ伝送が遅い、ユーザへの応答性が遅い、及びその他の望ましくない結果を招く可能性がある。
【００１８】
デバイスが１つの通信インターフェースから別の通信インターフェースに変更するときに、その変更は、一部のアプリケーションに混乱をきたす可能性がある。これは、アプリケーションが、障害迂回のために選ばれた通信インターフェースによって提供されない通信インターフェースの機能性又は特性に依存しているときに、最も明らかである。例えば、インタラクティブ応答性（実施に通信を必要とするアクションがとられてからそのアクションの結果が現れるまでの時間の長さ）及び所要の帯域幅が、このような特性の例である。ストリーミングビデオや画像データへのデータベースアクセスなどの一部のアプリケーションは、応答性及び帯域幅の両方が機能していることを必要とする。異なる通信インターフェースは、例えば、Ｗｉ−Ｆｉは十分な帯域幅を提供できるがＥＤＧＥはできないなどのように、異なる特性を有することがある。Ｗｉ−Ｆｉホットスポットでストリーミングビデオを受信中のデバイスが、そのホットスポットのサービスエリアから出て、Ｗｉ−Ｆｉサービスを伴わないエリアに入ったときは、デバイスは、ＥＤＧＥの使用に切り替えることができるが、ストリーミングビデオアプリケーションは、Ｗｉ−Ｆｉのときと同じ忠実度及び特徴ではＥＤＧＥを使用して機能しない。別の例として、ｅ−ｍａｉｌメッ
セージをダウンロードするなどの断続的なタスクは、大抵の場合、必ずしも多くの帯域幅を必要としない。断続的に接続されるｅ−ｍａｉｌアプリケーションは、通信インターフェースにおけるこのような変更によって混乱をきたす可能性は低く、バックグラウンドで再試行及び通信を行って、より大容量の又はより多くのｅ−ｍａｉｌメッセージをダウンロードすることができる。帯域幅は、通常、特定の通信インターフェースをその他の通信インターフェースよりも好ましくする又は通信インターフェースの選択に応じて特定のアプリケーションに制約を加える数多くの特性の１つに過ぎず、これらの例の一部として、コスト、信頼性、帯域外（out-of-band）サポート、伝送遅延、地理的分布、及びサービスの期間が挙げられる。利用可能な通信インターフェース、並びにそれらの特性及び特徴を承知し、伝送又は受信されるべきデータのタイプに適したインターフェースを選択する能力は、多くの場合、使用可能な全ての通信インターフェースを最も効率良く活用するのに有用である。
【００１９】
現在のワイヤレスアプリケーションは、多くの場合、モバイルユーザが好ましいとするよりも困難で且つ時間を食い、接続性が断続的なエリア内で実行されたときに予想外の形で障害を生じる可能性がある。デバイスが同時に又は時間とともに順番に複数通信インターフェースを活用する能力は、この問題の影響を抑えることができるが、現在のデバイスは、通常又は大抵は、複数通信インターフェースを使用しない又は効率良く活用することができない。
【００２０】
ワイヤレスアプリケーション
現在のワイヤレスプロトコルによって課される制限及び内蔵デバイスサポートの欠如ゆえに、ワイヤレスデバイスのための信頼でき効率的なデータ伝送を提供する負担はプログラマに課される。プログラマは、接続性の損失に関連した問題、伝送されるべきデータのタイプに関わる各種の通信インターフェースの効率、又は大量のデータブロックのダウンロードの待機を予測しなければならなくなる。しかしながら、このような考慮は、一部には、多くのプログラマがワイヤレスアプリケーションに未熟であるため、及び多くのプロジェクトに関連したリリース期限が厳しいために、適切になされないことが非常に多い。したがって、プログラマは次のようなワイヤレスアプリケーションを作成してしまうことがある。すなわち、接続性が断続的なエリア内で実行されたときに予想外の形で障害を生じてしまったり、利用可能な帯域幅を過剰に使用してしまったり、見込みよりも費用がかさんだり、利用可能な通信能力及び保存能力を効率的に活用できなかったり、ユーザが長時間のデータ伝送に耐えなければならないようなワイヤレスアプリケーションを作成してしまうことがある。場合によっては、このような問題は非常に深刻であり、モバイルユーザはデバイス及びアプリケーションを全く使用しなくなってしまう。デバイスが複数通信インターフェースを、同時に又は時間とともに順番に、信頼できかつ容易な方法で活用できれば、この問題の影響を抑えることができる。
【００２１】
ワイヤレスアプリケーションに関係するもう１つの問題は、モバイルデバイスのストレージ内に保持されるデータを、サーバ上又は他のデバイス上に維持されるデータと同期化させることである。一部のアプリケーションは、接続性が常に又はほぼ常に維持されることを想定して作成され、そのようなアプリケーションは、単純に、必要なデータを求めてサーバ又は他のデバイスに随時アクセスする。モバイルデバイスのクラスには、サーバ又は他のデバイスに頻繁に接続できないものがあり、重要なアプリケーションがほとんどの間使用できなくなっている。その他のアプリケーションは、通信が頻繁に利用不可になることが想定して作成されるが、アプリケーションが所要のサーバ又はその他のデバイスと多くの間通信できるくらい十分な頻度で接続性が存在することが想定される。このようなアプリケーションは、再び必要になる見込みがあるデータを、接続性を利用できない短期間の間の使用に備えてデバイスのストレージに保持するために、データをその使用と同時にキャッシュに入れることができる。接続が利用できない期間が長くなったり、データの
使用パターンが同じデータを繰り返し使用しないものであったりすると、この解決策では、欠点が露呈される。このような通信停止がモバイルデバイスユーザに及ぼす影響を抑えるには、接続性のない期間に必要になる見込みがあるデータを、接続性のある期間を使用してキャッシュするための、より良い方法が有用であると考えられる。
【００２２】
関連の問題は、警告なく接続性が現れたり消えたりする環境において、ローカルなキャッシュされたデータを更新の実施することである。失効した情報の使用を回避するには、モバイルデバイス上に保存されるデータを、モバイルデバイスとサーバとの間であれ、２つのモバイルデバイス間であれ、ピア・ツー・ピア又はその他の接続を使用して同期化する方法が有用だと考えられる。データ蓄積を同期化する多くの方法は、データのブロック、又はデータのブロックから計算されたチェックサムなどの値を比較して相違を検出すること、及び、次いで、異なることがわかった全てのデータを転送してこれらの相違を調和（reconcile）することを伴う。このようなプロセスに対する割り込みは、接続性が再確立されたときにプロセスをやり直しさせる結果になる可能性がある。プロセスがどのように実施されているか、及びどれくらいの量のデータが関与しているかに応じて、このような伝送の繰り返しによって、大量の帯域幅が無駄にされる可能性がある。これらの問題は、データを同期化状態に維持する必要があるデバイスの数が多く、かつデバイス間の接続性が断続的であるときに、増幅される可能性がある。この問題に対する解決策として考えられるものに、マサチューセッツ州ボストンのＡｄｅｓｓｏ  Ｓｙｓｔｅｍｓの「Ｔｕｂｅｓ」製品などがある。Ｔｕｂｅｓは、複数のデバイス上のデータ群を、どのデバイス上のデータに加えられた変更でもその他の全てのデバイスに伝搬されるように維持するネットワークベースのサービスである。データは、各デバイス上に維持されるので、デバイスが接続性を有する又は有さないにかかわらず、使用可能である。もし同期化が完了する前に接続性が損失したならば、ソフトウェアは、接続性が復活したときに自動的にタスクを再開させる。
【００２３】
当業者ならば、メッシュネットワーキングの概念も熟知している。メッシュネットワーキングは、フルメッシュトポロジ又は部分メッシュトポロジの２つのノード接続構成の１つを利用する。フルメッシュトポロジでは、各ノードは、互いに直接接続されている。部分メッシュトポロジでは、その他の全てのノードに接続可能なノードもあれば、大半のデータを交換する相手先ノードにのみ接続されるノードもある。接続は、有線又は無線であってよい。簡単に言うと、メッシュネットワークは、ノード間でデータ、音声、及び／又は命令をルーティングし、宛先ノードに到達するまでノードからノードへとデータを引き渡す（「ホップする」）ことによって連続的な継続及び破壊経路又は遮断経路を迂回する再構成を可能にする。概して、メッシュネットワークは、複数のホップを介して全ての構成部分が互いに接続可能であるという点で、その他のネットワークと異なる。メッシュネットワークは、当初、軍事用途のために開発され、提示される更なる能力及び挑戦ゆえに大きな注目と実験とを集めてきた。例として、参照によって本明細書に組み込まれるWang
et alによるWireless Mesh Networks (Advanced Texts in Communications and Networking) (Wiley 2009) including Chapter 7 ("mobility management")を参照せよ。
【００２４】
分散アプリケーションの管理のためのシステム
以上の問題の多くは、参照によって本明細書に組み込まれた出願人の同時係属共同所有米国特許出願第１１／１６９，１４９号で取り組まれている。非限定的な例として、譲受人Ｊｕｍｐｓｔａｒｔによって市販されている技術は、分散アプリケーションを管理するための数多くの有用な技術を提供しており、例えば、たとえデバイス間の通信が信頼できず、断続的であるとき、若しくは帯域幅が限られるときでも、又はデバイスのうちの１つ若しくは複数のデバイスのリソースが限られるときでも、異なるデバイスのユーザ間に信頼性の高い相互作用の方法を提供できるように、デバイス間において「ノード」、コマンド、及びその他のデータを交換する方法が挙げられる。ノードは、非限定的な例として、
プロセスを構成する少なくとも１つのアクション又は少なくとも１つの特質とを記述したデータ及び／又は命令と、ノード自体の処理、順序付け、識別、伝送、及び取り扱いを可能にする情報とを含むことができる。ノードの基本的な作成、取り扱い、保存、伝送、構造、及び処理に関する’１４９出願における記載は、参照によって本明細書に組み込まれる。
【００２５】
ノードは、定義された構成と可変のコンテンツとを有するデータの集合でありうる。これらのデータはデバイスによって作成され、保存され、デバイス間で転送される。ノードは、例えば、デバイスによるデータ及びプログラム命令の処理を制御することによって、デバイスを制御することができる。この技術は、テキスト、画像（単一の画像及び一連の画像の両方）、署名情報、音声を符号化したデータ、入力デバイスからのデータ（例：バーコード、光データ、無線自動識別（ＲＦＩＤ）、及び磁気カードスキャナ）、磁性材料から得られた情報（例：クレジットカード若しくは身分証明書）、印刷機器に送信される情報、地理的な位置に関連した情報（例：全地球測位システム「ＧＰＳ」）、並びにその他の構成を非限定例として挙げられる多様なデータタイプを管理するように構成することができる。技術の典型的な一実装形態にしたがうと、このような様々なデータタイプの管理は、定められたノードタイプを使用して実装されるが、当業者ならば、通常の技術及び知識を使用して更に他のノードタイプが定義及び実装されることがわかる。
【００２６】
図１に示されるように、典型的で例示的で非限定的な実装形態は、１つ又は複数のワイヤレスネットワーク（１２００ａ、１２００ｂ）を通してモバイルワイヤレスデバイス（１１１０）に接続されたＴＭＣデバイス（１３００ａ）（サーバ）を含む。ノード及びコマンドが、ノードマネージャ（１５７０）によってサーバのノードストレージ（１５４０）から検索され、通信インターフェース（不図示）を通して、ワイヤレスネットワーク（１２００ａ又は１２００ｂ）上を送信され、ワイヤレスモバイルデバイスの通信インターフェース（２２１０、２２２０、又は２２３０）に達する。通信インターフェースを管理するワイヤレスデバイスのオペレーティングシステムは、ワイヤレスモバイルデバイスのディスパッチモジュール（２３１０）にノードを送信し、ディスパッチモジュールは、それらを処理し、それらが保存される又は処理されるノードストレージモジュール（２３３０）又はディスプレイモジュール（２３２０）に引き渡す。
【００２７】
Ｊｕｍｐｓｔａｒｔによってこれまでに市場に提供されてきた有用な技術にもかかわらず、依然、ある場所へのワイヤレス接続性は断続的であるがその場所のすぐ近くにいるユーザはローカルワイヤレスアクセスを利用可能であるような状況に対して利益をもたらす必要性が残っている。例えば、ある建設現場が１台又は複数台のトレーラを含み、各トレーラが、自身の内で利用可能であるがその直近の現場にも及ぶＷｉ−Ｆｉ又はその他の通信を有することがある。（１台又は複数台の）トレーラと、より常設的な場所（例：中央オフィス）との間のワイヤレス接続性は、接続性の断続性に見舞われるが、ローカルワイヤレス通信は、実質的に全部でなくとも大半の現場に及ぶことができ、上述のデバイス及びシステムを使用する作業員によってアクセスされる。このようなケースでは、このような更なるデバイスまでサービスを広げて更なる能力を提供することが有益であると考えられる。
【００２８】
典型的で例示的で非限定的な実施形態は、たとえ、ワイヤレスネットワークデバイスと、より強固なその他のネットワークデバイスとの間の通信に信頼がなく、断続的であり、帯域幅が限られるときでも、又はデバイスのうちの１つ若しくは複数のデバイスのリソースに限りがあるときでも、ローカルワイヤレス接続を確立することができる、信頼性の高い相互作用の方法を、第１のデバイスのユーザと第２のデバイスのユーザとの間に提供できるように、デバイス間における「ノード」、コマンド、及びその他のデータ項目の交換を可能にするためのシステムと、装置と、ソフトウェアと、その他の構成とを提供する。
一部の実施形態では、本明細書で提供される技術の実装形態は、ユーザによって必要に応じて使用される中央設備によってワイヤレスインフラ、モバイルデバイス、及び各種の統合サーバが提供されるホスト型サービスプロバイダビジネスモデルを使用して提供される。このようなやり方での技術の提供は、ユーザがインフラ構成要素の配備及び管理ではなく自身のビジネスに焦点を当てることを可能にする。このアーキテクチャの性質は、異なる企業からの複数のユーザが互いを妨げることなく共通のインフラを透過的に共有することを可能にする。或いは、この技術は、１つの企業がインフラを所有してその従業員に上記インフラへのアクセスを提供するような、当業者に馴染みのその他のモデルを使用して実装される。
【００２９】
本明細書における技術の典型的で例示的で非限定的な一実装形態では、システム、ソフトウェア、及び装置は、各通信経路の利用可能性が予期せず変化し尚且つ各種の通信経路が異なる容量、信頼性、能力、及び動作方式を有する環境でアプリケーションが通信を行うことを可能にできるように、一度に１つずつ（例：順次）であれ又は一度に２つ以上（例：並行）であれ尚且つ帯域内伝送を提供するものであれ且つ／又は帯域外伝送を提供するものであれ１つ又は複数の伝送技術（すなわち、通信経路）を使用して、２つ又は３つ以上のデバイス間におけるデータ項目の伝送を可能にする。デバイス間でのデータ項目の同期化は、１本又は複数本の通信経路が断続的に中断される状態において、１本または複数本の通信経路をシリアルまたはパラレルに利用して利用可能な通信経路上で実施され、これにより、システムの少なくとも１つの特質を実装するのに有用なデータ項目（例：テンプレート、ノード、又はノードスタック）が損失や検出できない重複無しに通信される。一部の通信経路に関連した予期不能な遅延を補償し、ユーザに気付かれる伝送遅延を可能な限り減らすために、データ項目は、第１のデバイスによって意図的に複数の通信経路を使用して送信される。第２のデバイスは、このような伝送による方式で複製されたデータ項目を検出し、複製コピーは、重複として削除される。
【００３０】
本明細書に記載される技術の典型的で例示的で非限定的な別の実装形態は、第１のデバイスと第２のデバイスとの間におけるデータ項目の伝送を開始させるために第２のデバイスが第１のデバイスをポーリングすることに依存する（「プルモード」）先行技術のデバイス及びシステムとは対照的に、第１のデバイスから第２のデバイスへの伝送を開始させるための手段（「プッシュモード」）を提供する。本明細書における技術の典型的で例示的な実装形態による「プッシュモード」の使用は、直接的または「協調プッシュモード」において間接的に実施される。直接的な実施では、第１のデバイスが伝送を開始し、伝送を開始するために使用したのと同じ通信経路を使用してデータ項目を送信する。「協調プッシュモード」での間接的な実施は、第１のデバイスがプッシュノードを使用して（１つ若しくは複数の）データ項目の第１の部分を伝送し、該部分は、（１つ若しくは複数の）データ項目の第２の部分の移動をサポートすることはできるがデータ項目全体若しくはデータ項目群全体についてプッシュモードをサポートするために必要とされる特性には欠ける、若しくは広帯域幅、高信頼性、若しくは低コストなどのその他の望ましい特性を有する、同じ若しくは異なる伝送技術を使用して、（１つ若しくは複数の）データ項目の第２の部分を転送するために、第２のデバイスがプルモード通信セッションを開始させるための要求として第２のデバイスによって使用される。一部の典型的な実装形態では、第１のデバイスは、第２のデバイスのデバイスタイプに関する既知の情報をデバイス能力情報のデータベースと併せて使用し、第２のデバイスがプッシュモードをサポートしているかどうかを、又はそのような能力が存在するところに存在し得る制限を決定する。例えば、デバイスタイプによっては、音声通話の進行中又は特定のアプリケーションの実行中は、プッシュモード接続を受け付けないものがある。その他のデバイスタイプは、このような制限を有さない。同様に、第１の通信経路のプッシュモード特性は、第２の通信経路のプッシュモード特性と異なることがある。例えば、ＳＭＳメッセージは、送信後、数秒で配信されることもあれば数時間で配信されることもあり、あるいは送り手に対する通知のない
まま全く配信されないことがある。一方、ＴＣＰソケット伝送は、数秒以内に成功又は失敗し、伝送システムは、その成功又は失敗についてほぼ直ちに知らされる。本明細書における技術の典型的で例示的な実装形態は、適切な通信経路が利用可能なときに、プルモード、プッシュモード、協調プッシュモード、又はそれらの任意の組み合わせを使用することができる。本明細書における典型的で例示的な実装形態は、代替の通信経路を使用できる。これらの代替の通信経路は、それぞれ独自の特定の特性（例：コスト、帯域幅、プッシュモードサポート、伝送遅延、信頼性、可用性など）を有する。本明細書における典型的で例示的な技術は、１つ又は複数の通信技術を一度に使用すること、利用可能な通信技術間で適宜切り替えを行うこと、最も適した機能を求めて異種の通信技術を使用すること、それぞれ異なるデバイス通信技術を活用することができる複数本の通信経路を使用してデータ項目を重複して送信すること、又は当業者に明らかなその他の手段によって、コスト、スループット、信頼性、可用性、伝送遅延、インタラクティブ応答性、又はその他などの、デバイスについての１つ又は複数の通信特質を随意に且つ動的に最適化できるように複数通信技術を管理する手段を提供する。これらの拡張能力は、例えば、デバイスが、特定の通信経路を使用した通信が損失したときに代わりの通信経路に切り替えること、又は複数通信経路を同時に使用することによって全体のスループットを高めることを可能にすることができる。
【００３１】
一部の典型的で例示的で非限定的な実装形態では、サポートされている利用可能な通信技術によって確立された通信経路は、その管理及び使用のための更なるメカニズムを規定するように構成される。例えば、通信経路を通じて送信されるデータ項目は、暗号化される、圧縮される、又はチェックサム若しくはその他のメカニズムの使用を通して改ざん若しくは損傷から保護される。このような更なる随意のメカニズムは、第１のデバイスから第２のデバイスへの通信経路の一部で使用されてその他の部分では使用されない、又はそのような通信経路の全体で使用される。複数のこのような随意のメカニズムが、同時に使用される。例えば、チェックサムが計算され、データ項目に追加されたとき、それらのデータ項目及びチェックサムは、次いで、圧縮及び伝送され、そのとき、それらの圧縮されたデータ項目及びチェックサムは、通信経路の一セグメント上を移送されるときに露見しないように、その通信経路セグメントによって暗号化及び復号化を施される。
【００３２】
本明細書における典型的で例示的な技術によって提供されるデータ項目の転送は、ＧＰＲＳ／ＥＤＧＥを使用したワイヤレステレフォニ、ＥＶＤＯ、８０２．１１（Ｗｉ−Ｆｉ）を使用したワイヤレスネットワーキング、又はその他の無線及び有線の手段などの、１つ又は複数の通信技術を使用して、デバイスによって実施される。一部の典型的で例示的で非限定的な実装形態では、デバイスは、サーバやデスクトップ型若しくはノート型パソコンなどの標準的なコンピュータ、携帯電話やＰＤＡなどのワイヤレスポータブルデバイス、エミュレートデバイス、又はこれらの任意の数の組み合わせである。
【００３３】
上述された各種の通信方法を使用することによって、本明細書における典型的で例示的な技術は、ピア・ツー・ピア（Ｐ２Ｐ）メッセージ交換と、サーバの助けによる又はよらない第１のデバイスから第２のデバイスへのタスクのデリゲートと、複数のデバイスへの有効タスクの告知、応答の収集、肯定的に応答するもののなかからの、タスクの割り当て先となる１つ又は複数のデバイスの選択、（１つ又は複数の）選択されたデバイスへのタスクの割り当て、及びデリゲートの連鎖に沿った、タスク完了又はタスクキャンセルデータ項目の伝搬と、サーバの介在を受けた又は受けないデバイス間におけるカタログデータ項目の同期化と、デバイスによるデータ項目、データ項目群、又は通信方法の使用に対する制限及び許可の柔軟な規定を可能にするセキュリティテンプレートと、などを可能にする更なる能力と機能とを提供する。非直接的なクライアント−サーバアーキテクチャを使用して複雑なノード構造を管理する能力は、Ｊｕｍｐｓｔａｒｔがこれまでに市場に提供してきた有用な技術にはなく、ノードベースのタスク、情報の収集、及びその他のタスク
を管理するための、デバイスの有用性及び適用性を大幅に拡張させる。典型的で例示的で非限定的な更なる特徴及び利点には、以下のものがある。
・一度に１本ずつであれ、一度に２本以上であれ、そして、速度／帯域幅、信頼性、コスト、プロトコル、伝送媒体、又はその他の特性などの各通信経路の特性の違いにかかわらず、第１のデバイスから第２のデバイスへのメッセージの転送のために複数通信経路を使用すること。複数通信経路は、通信経路の可用性が連続的でないときや、場所から場所へと変化するときや、時間若しくは場所によって異なる手段を使用して利用可能にされるときに、デバイスがサーバ又は他のデバイスとの通信を確立することができる可能性を増大させる。特に、これは、最も有利な利用可能通信経路上におけるノードベース構造の移動に対処し、デバイスの能力を各種の動作条件で動作するように拡張する。
・複数の利用可能通信経路のどれを特定の時間に所定のデータ項目のために用いるかを決定するための方法。通信経路は、能力、コスト、現デバイス位置に基づく固有の制限、セキュリティ制約、並びに／又は配信の速度及び保証がそれぞれ異なっており、これに、転送するノード及びカタログの選択を加味すると、限られたリソースのポータブルデバイス上で使用するのに十分に効率的な適切な経路を所定のノード群（関連の優先度、サイズ、タイプなどを伴う）に合わせて選ぶことは難題である。
・１つ又は複数のノード構造の複数コピーを基本的に並行して運ぶために、複数通信経路を使用すること。複数通信は、ノード構造の効果的使用を可能にするのに十分なノード構造が、起こり得る通信経路の破壊にかかわらず宛先で受信される機会を増やすとともに、その時点でどの通信経路が最速であるかに関する知識を必要とすることなく、移送遅延を最速通信経路のそれと同程度に抑える。しかしながら、これは、受信デバイスにおいて複製コピーを排除してノード構造を再構築しなくてはならないという面倒を増加させる。
・ノード構造の第１の部分を運ぶために第１の通信経路を使用し、同じノード構造の第２の部分を運ぶために第１の通信経路と少なくとも部分的に異なる第２の通信経路を使用すること。これは、通信に携わっているデバイスが、メッセージの送信済み部分を再伝送する必要なく、また見た目の帯域幅を増やすとともに受け手においてノード構造の受信に要する合計時間を短くするために複数の通信経路を通じてノード構造の部分を並行して送信する必要もなく、通信経路を切り替えることを可能にする。受け手は、所定のノード構造を伝送するためにどれほど多くの異なる通信経路が使用されたかに関係なく、その所定のノード構造の部分を認識し、それらを正しい順序に再構築し、起こり得るノード構造部分の重複受信に対処する能力を有する。これは、やはり、各通信経路によって伝送されるノード構造の部分を伝送デバイスが選択する必要があるという面倒を増加させる。
・あまり好ましくない通信経路よりも好ましい通信経路の使用を増やすための、随意的な、動的な通信経路切り替え。このような切り替えは、通信経路が利用可能になる又は機能しなくなるときに、デバイスが、利用可能な通信経路を最適に使用することを可能にする。最適な使用は、伝送の速度、コストの削減、デバイスユーザに対する応答性の向上、セキュリティの向上、又はその他の要因に関連する。これは、やはり、各経路によって転送されるノード構造の部分をデバイスが選択可能であることを必要とする。
・好ましい通信経路以外の時間、順序、又は手段によってデータ項目が送信される（例：Ｗｉ−Ｆｉ上でＴＣＰ／ＩＰを使用する代わりにＧＰＲＳ上でＭＭＳを使用して送信される、又は予定されるポーリング時間の合間に送信される）帯域外（ＯＯＢ）伝送。ＯＯＢ伝送は、ユーザに対する応答性の向上、及び優先度の高いデータの、より適時な伝送を可能にする。
・送信されるべきデータ項目の又はその一部の特性に一部基づいて伝送方法が決定される優先メッセージング。ノード伝送優先度は、複数の利用可能通信経路のどれを使用するか、通信経路を動的に切り替えるかどうか、データをＯＯＢ送信するかどうか、及びデータ項目を送信するためにどの伝送モードが許可されるかを決定する要因である。ノード構造の伝送の優先順位付けは、全体であれ一部であれ、コストの削減、相互作用タスクにおける応答性の向上、及びタスク実装における柔軟性を可能にすることができる。
・重複の発生が偶発的であれ意図的であれ、重複するノード構造を検出して排除するこ
と。通信経路の動的切り替えは、受け手にノード構造又はノード構造部分の重複が見える結果を招くことがあり、したがって、これに対処するための方法が提供される。これらの方法は、また、ノード構造の更新ヴァージョンが同じノード構造の古いヴァージョンの送信後に送信される可能性、及びそれらが任意の順番又は任意のタイミングで受信デバイスに到達する可能性にも対処する。
・送り手が受け手に連絡を取ってメッセージの転送を開始させる、「プッシュモード」伝送モデル。これは、従前の定期的ポーリング、すなわち「プルモード」伝送モデルと比べて通信遅延を短縮させ尚且つデバイスユーザに対する応答性を向上させることができる「非同期」通信モデルを可能にする。伝送されるべきデータがないときにポーリング要求を排除することを通じて帯域幅の使用を減らすことも可能であり、これは、幾らかの通信経路と相まってコストの削減をもたらすことができる。
・１つ又は複数のノード及び／又はノード構造を転送するために、送り手が受け手に連絡を取り、プルモードセッションを開始させるように受け手に要求するコマンドを内包するメッセージを送信する、「協調プッシュモード」伝送モデル。送り手の要求及び受け手のプルモードセッションは、異なる通信経路上で発生することができる。協調プッシュモード伝送は、プッシュモードをサポートしていない通信経路を通じた非同期伝送を可能にし、ノード構造の重要部分の伝送を加速させるのに効果的である。プッシュモード要求は、ＯＯＢ送信することができる、配信を確実にするために複数の通信経路を通じて一度に送信することができる、尚且つ１つ又は複数のノード及び／又はノード構造の伝送のためのその他のサポート能力を活用することができる。協調プッシュモード方式の伝送における困難の１つは、移動されるべきノード及び／又はノード構造を、受け手が要求できるように特定することである。
・一方が通信を開始させることができ尚且つ一方又は両方が他方にノード及び／又はノード構造を伝送することができる２つのデバイス間でノード及び／又はノード構造を送信するための「ピア・ツー・ピア」（Ｐ２Ｐ）ノード伝送モデル。この能力は、デバイスが、各デバイスがサーバへのアクセスを有するという要件を伴わずともやり取りすることを可能にし、複数のデバイスが、任意の特定のデバイスの通信経路リソースを共有することを許可し、そうして、通信の接続性に限りがある環境における全体的な接続性及び効率を向上させる。Ｐ２Ｐ環境の困難は、ノード構造の再構築及びそれに続く使用のために、（１つ又は複数の）デバイスがノード構造の一意インスタンスの認識を失うことなく複数の通信経路及びトポロジに沿ってノード構造を更新すること並びに報告を返信することが可能であるようにノードを一意的に識別することを中心に展開する。
・１つ又は複数の指定タスクの割り当てを受け入れる意思がある１人又は複数人のユーザを特定し、それらにタスクを提供するための、「告知及び受け入れ」（Ａ＆Ａ）メカニズム。この能力は、ノード及び／又はノード構造を複数のデバイスに送信することができるブロードキャスト能力に依存する。このようなブロードキャストは、複数の異なる通信経路又は通信経路タイプを使用してなすことができ、通信経路によって１対多の伝送能力をサポートされていない各デバイスに個々の伝送を送ることによってシミュレートすることができる。Ａ＆Ａメカニズムは、ノード及びノード構造によって表わされるタスクの選択及び受け入れ、並びにそれに続く選択、優先順位付け、及び利用可能通信経路を通じた伝送、並びにそれに続く再構築及び使用報告活動を解決するにあたって課題を提供する。
・サーバの助けによって又はよらずに、ノード又はノード構造によって表わされるタスクを第１のデバイスから第２のデバイスに転送するための、タスクデリゲート方法。サーバによる転送の仲介を必要としないタスク転送を可能にすることによって、一方又は両方のデバイスに対してサーバ通信を確立又は維持することができない場面（通信経路の障害があるとき）における効率が向上される。サーバ又は他のデバイスへの最終通知に備えてタスクの所有を追跡するための、及びサーバが関与していないときでもデバイス間のタスクの転送を制限するための方法が必要とされる。このような方法は、タスクがアクティブである間にどのパターンでデバイス対デバイス又はデバイス対サーバの通信経路が存在するかにかかわらず、機能しなければならない。第２のデバイスへの転送のために第１のデ
バイスによってノードを符号化するための、及び第２のデバイスによる受信後にノードを復号し、それらを第２のデバイスに機能的に組み込み可能にするための、更なる方法が必要とされる。
・タスクのキャンセルを適切なデバイスに通知するための、タスキャンセル配布方法。この方法は、タスクデリゲートの結果として生じる複雑性、及びサーバによる介在なしにデバイス間でなされるタスクデリゲートをサポートする。このような方法は、タスクがアクティブである間にどのようなパターンでデバイス対デバイス又はデバイス対サーバの通信経路が存在するかにかかわらず、機能しなければならず、多くの場合、その他のノード伝送要件よりも高い優先度でのキャンセル情報選択を必要とする。
・第１のデバイスのカタログと第２のデバイスのカタログとの間の相違を識別及び解消するための、カタログ同期化方法。このような方法は、２つ又は３つ以上のデバイスがサーバと通信していないときに、尚且つデバイスに加えられる更新の順序に関係なく、デバイスのカタログ間の相違の解消をサポートしなければならない。特定のデバイス又は特定のクラスのデバイスへのカタログデータの転送に対する制限は、たとえサーバが関与しておらず、転送がデバイス間であるときでも、維持されなければならない。
・データ項目、データ項目群、デバイス、又はサーバに対するアクセス、使用、又は変更の制限を可能にする、柔軟なセキュリティモデルの提供。このような制限は、サーバ又は第３のデバイスへの通信経路を有する第１のデバイスが、このような通信経路を有さない第２のデバイスのためにデータ項目を中継することに適用される。
・たとえ、ワイヤレスネットワークデバイスと、より強固なその他のネットワークデバイスとの間の通信が非信頼性であるとき、断続的であるとき、帯域幅が限られるときでも、又はデバイスのうちの１つ若しくは複数のデバイスのリソースに限りがあるときでも、ローカルワイヤレス接続を確立することができる、信頼性の高い相互作用の方法を、第１のデバイスのユーザと第２のデバイスのユーザとの間に提供できるように、デバイス間における「ノード」、コマンド、及びその他のデータ項目の交換を可能にするための、システム。
・たとえ、ワイヤレスネットワークデバイスと、より強固なその他のネットワークデバイスとの間の通信が非信頼性であるとき、断続的であるとき、帯域幅が限られるときでも、又はデバイスのうちの１つ若しくは複数のデバイスのリソースに限りがあるときでも、ローカルワイヤレス接続を確立することができる、信頼性の高い相互作用の方法を、第１のデバイスのユーザと第２のデバイスのユーザとの間に提供できるように、デバイス間における「ノード」、コマンド、及びその他のデータ項目の交換を可能にするための、方法。
【００３４】
これらの及びその他の特徴及び利点は、典型的で非限定的で例示的な実施形態の以下の詳細な説明を図面と併せて参照することによって、より良く且つより完全に理解される。
【図面の簡単な説明】
【００３５】
【図１】参照によって本明細書に組み込まれる共同所有の米国特許出願第１１／１６９，１４９号に記載される技術にしたがった、サーバデバイスと、クライアントデバイスと、それらの間のネットワーク接続とを含むネットワークの概略図を示している。
【図２】２つのサーバデバイスと、３つのモバイルクライアントデバイスと、それらの間のネットワーク接続とを含む、デバイス＆ネットワーク構成の概略図を示している。
【図３】協調プッシュモード通信の実装を目的とした、データ項目の送信及びコマンドの送信の両方における典型的で例示的で非限定的なプッシュモード使用を示したフローチャートである。
【図４】ＳＭＳを使用した協調プッシュモード通信における典型的で例示的で非限定的なデバイス−サーバ相互作用を示している。
【図５】通信経路を選択するための方法の典型的で例示的で非限定的な実装形態を示したフローチャートである。
【図６】本明細書における典型的で例示的で非限定的な技術にしたがった、複数の通信インターフェースを通して様々な他のデバイスに到達可能な複数の通信経路を有する典型的で例示的で非限定的なデバイスの概略図である。
【図７】伝送されるメッセージに対するプロトコルマネージャによる処理の典型的で例示的で非限定的な実装形態を示したフローチャートである。
【図８】受信中のメッセージに対するプロトコルマネージャによる処理の典型的で例示的で非限定的な実装形態を示したフローチャートである。
【図９】告知及び受け入れ（Ａ＆Ａ）プロセス及びカタログ同期化プロセスにおける典型的で例示的で非限定的なメッセージフローを示している。
【図１０】Ａ＆Ａ手続きを実施するための及び十分な肯定応答の不足に対処するための方法の典型的で例示的で非限定的な実装形態を示したフローチャートである。
【図１１】Ａ＆Ａメッセージに対する応答を収集及び処理するための方法の典型的で例示的で非限定的な実装形態を示したフローチャートである。
【図１２】割り当てられたタスクを第１のデバイスから第２のデバイスにデリゲートする方法の典型的で例示的で非限定的な実装形態を示したフローチャートである（方法１）。
【図１３】方法１又は方法２のいずれかを使用したタスクデリゲートのための典型的で例示的で非限定的なメッセージフローを示している。
【図１４】割り当てられたタスクを第１のデバイスから第２のデバイスにデリゲートする方法の典型的で例示的で非限定的な実装形態を示したフローチャートである（方法２）。
【図１５】典型的で例示的で非限定的なセキュリティ規定を示している。
【発明を実施するための形態】
【００３６】
用語の定義
［ＯＯＢ］：「帯域外（Out Of Band）」。好ましくない通信経路を通じて行われるデータ項目伝送。例えば、接続ベースのプロトコルではなく接続のないプロトコルを使用する伝送、予定されるポーリング間隔以外の時間に行う伝送、優先度の高いデータ項目が優先度の低いデータ項目よりも先に送信するなどのデータ項目の送信が要求される順序以外の順序で実施される伝送。
【００３７】
［データ項目］：典型的な実装形態が正常に機能するために必要とされるデータオブジェクト（例：ノード、ノードスタック、カタログ、タスク、又はこれらの組み合わせ）。
【００３８】
［デバイス］：本明細書で使用される「デバイス」は、典型的で例示的で非限定的な一実装形態では、少なくとも１つのプロトコルマネージャ及び少なくとも１つの通信インターフェースを更に含む（後述のような）ディスパッチマネージャを含むように構成されたコンピュータである。一部の典型的なデバイス実装形態には、プロトコルマネージャ及び通信インターフェースが複数提供される。動作にあたり、メッセージは、１本又は複数本の通信経路を通じて第１のデバイスから第２のデバイスに伝送される。デバイス内のハードウェア及びソフトウェアの構成は、たとえデバイス間に強固な通信経路がない場合でもデバイス間における効率的なメッセージ伝送を可能にするために、上記デバイス上のプログラム及びデータ項目の動作の特質を制御する。更に、デバイスは、例えばワイヤレス技術を使用して接続されユーザとともに移動するデバイスなどのモバイルデバイス、固定位置を有するデバイス（例：デスクトップ型コンピュータ若しくはサーバ、若しくは自動販売機若しくは圧力モニタなどの別のメカニズムに埋め込まれたコンピュータ）、又はエミュレートデバイスのいずれかである。モバイルデバイスは、時折若しくは常に有線接続を使用することができる、ワイヤレス接続をサポートすることができる、又はその両方である。
【００３９】
［カタログ］：類似構造のデータ項目の集合（例：データ表、パーツリスト、ジョブコードリスト、コストコードリスト、終了コードリスト）。
【００４０】
［コマンド］：バイトの順序付き配列であり、一部は特定の値を有し、第２のデバイスに所望のアクションをとらせる意図を持って第１のデバイスから第２のデバイスに送信される。
【００４１】
［メッセージセグメント］：メッセージの断片であり、所定のメッセージを構成する全ての断片をそのメッセージに再構築することを可能にするとともに完全なメッセージの再構築に必要とされるこのようなメッセージ断片の数を記述する情報が付随している。
【００４２】
［通信経路］：第１のデバイスから第２のデバイスへのメッセージ又はメッセージセグメントの送信を可能にする技術の又は組み合わせ技術の実装形態。
【００４３】
［プルモード］：受け手が送り手に連絡を取ってメッセージの転送を要求する伝送モデル。
【００４４】
［プッシュモード］：送り手が受け手に連絡を取ってメッセージの転送を開始させる伝送モデル
【００４５】
［協調プッシュモード］：送り手が受け手に連絡を取り、プルモードセッションを開始させるように受け手に要求するコマンドを含むメッセージを送信する伝送モデル。送り手による要求及び受け手によるプルモードセッションは、異なる通信経路上で発生することができる。
【００４６】
［Ｐ２Ｐ］：「ピア・ツー・ピア」。一方が通信を開始させることができ尚且つ一方又は両方が他方にメッセージを伝送することができる２つのデバイス間におけるメッセージ伝送モデルを指して使用される。
【００４７】
［タスク］：デバイス上で実施されるべき作業の個別的単位であり、１つ又は複数のデータ項目によって定義される。
【００４８】
［ＬＡＮ］：「ローカルエリアネットワーク（Local Area Network）」。ＬＡＮは、互いに近くに位置するとともにＥｔｈｅｒｎｅｔ、Ｗｉ−Ｆｉ、Ｔｏｋｅｎ  Ｒｉｎｇなどの１つ又は複数のネットワーキング技術によって接続される２つ又は３つ以上のデバイスからなる。
【００４９】
［ＤＮＳ］：「ドメイン名システム（Domain Name System）」。「anycompany.com」など人間が読み取れるアドレスを、インターネットソフトウェアがデータ項目の送信のために使用可能なＴＣＰ／ＩＰバイナリアドレスに変換するために使用される、分散型データベースを含むインターネットシステム。
［ノード］：本明細書で使用される「ノード」とは、米国特許出願第１１／１６９，１４９号によって定められたノードと同様のデータ項目であり、本明細書では、後述のように、データフィールド及びノードタイプを追加で含ませることによって拡張される。
［セキュリティ規定］：一部特定の又は限られた範囲の値を有するバイトのルール正しい配列であり、データ項目、データ項目群、デバイス、又はサーバに関連付けられ、データ項目、データ項目群、通信経路、デバイス、又はサーバのアクセス、使用、又は変更に対する許可及び／又は制約を規定するために使用される。
【００５０】
概要
典型的で例示的で非限定的な現実装形態は、非限定例として以下に挙げられるこれまで利用できなかった重要な能力を伴う通信システム及び通信デバイスを提供する。
・一度に１本ずつであれ一度に２本以上であれ、そして、速度／帯域幅、信頼性、コスト、プロトコル、伝送媒体、又はその他の特性などの各通信経路の特性の違いにかかわらず、第１のデバイスから第２のデバイスにメッセージを転送するために複数通信経路を使用すること。
・あまり好ましくない通信経路よりも好ましい通信経路の使用を増やすための随意的で動的な通信経路切り替え。
・好ましい通信経路以外の時間、順序、又は手段によってデータ項目が送信される（例：Ｗｉ−Ｆｉ上でＴＣＰ／ＩＰを使用する代わりにＧＰＲＳ上でＭＭＳを使用して送信される、又は予定されるポーリング時間の合間に送信される）帯域外（ＯＯＢ）伝送。
・送信されるべきデータ項目の特性に一部基づいて伝送方法が決定される優先メッセージング。
・重複の発生が偶発的であれ意図的であれ、重複するメッセージ及びデータ項目を検出して排除すること。
・送り手が受け手に連絡を取ってメッセージの転送を開始させる「プッシュモード」伝送モデル。
・送り手が受け手に連絡を取り、プルモードセッションを開始させるように受け手に要求するコマンドを内包するメッセージを送信する「協調プッシュモード」伝送モデル。送り手の要求及び受け手のプルモードセッションは、異なる通信経路上で発生することができる。
・一方が通信を開始させることができ尚且つ一方又は両方が他方にメッセージを伝送することができる２つのデバイス間でメッセージを送信するための「ピア・ツー・ピア」（Ｐ２Ｐ）メッセージ伝送モデル。
・１つ又は複数の指定タスクの割り当てを受け入れる意思がある１人又は複数人のユーザを特定し、それらにタスクを提供するための「告知及び受け入れ」（Ａ＆Ａ）メカニズム。
・サーバの助けによって又はよらずに第１のデバイスから第２のデバイスにタスクを転送するためのタスクデリゲート方法。
・タスクのキャンセルを適切なデバイスに通知するためのタスキャンセル配布方法。
・第１のデバイスのカタログと第２のデバイスのカタログとの間の相違を識別及び解消するためのカタログ同期化方法。
・データ項目、データ項目群、デバイス、又はサーバのアクセス、使用、又は変更に対する制限を可能にする柔軟なセキュリティモデルの提供。
【００５１】
本明細書に記載されるデバイスは、無線デバイス、有線デバイス、エミュレートデバイス、サーバ（ＴＰＣ）デバイス、及びその他のデバイスを含む。典型的で例示的な技術の態様は、例えば、企業ＬＡＮに断続的に接続されるノート型パソコン及びＰＤＡ、ワイヤレス信号を利用できない場所にあることがあるモバイルデバイス、又は信頼性の高い通信可用性を有さない固定位置デバイスなど、接続性の断続性などに見舞われるあらゆるクラスのデバイスに対して等しく適用可能である。また、本明細書に記載されるように、当業者ならば、本明細書における技術にしたがって任意の数のデバイスが互いに通信し合えることがわかる。
【００５２】
データ項目は、通信経路を使用してデバイス間で転送される。通信経路は、デバイスによってサポートされる任意の通信技術からなってよく、非限定例として、従来のセルラ方式若しくはその他のワイヤレステレフォニデータ（例：ＧＰＲＳ、ＥＤＧＥ、ＥＶＤＯ、ＳＭＳ）、ローカライズドワイヤレスネットワーク（例：ワイヤレスフィデリティ（例：Ｗｉ−Ｆｉ、８０２．１１ｘ）若しくはＢｌｕｅｔｏｏｔｈ）、有線データメカニズム（Ｅｔｈｅｒｎｅｔ、ＰＳＴＮ、シリアル若しくはパラレルなデータケーブル、ダイヤルア
ップモデム、ＤＳＬなど）、又はこれらの任意の組み合わせであってメッセージ若しくはメッセージセグメントを１つのデバイスから別のデバイスへ転送する能力を有する追加の若しくはその他のプロトコルを伴う若しくは伴う組み合わせが挙げられる。通信経路は、順次に又は並行して使用され第１のデバイスから第２のデバイスにメッセージ又はメッセージセグメントを転送するのに有効な１つ又は複数の通信技術の実装形態を含む。通信経路は、速度／帯域幅、プロトコル、信頼性、可用性、コスト、又はその他の特性などが異なってよい。典型的で例示的で非限定的な実装形態の各種の実装形態は、特定の通信経路の使用を制限又は促進を、データ項目のタイプ、データ項目のサイズ、データ項目の優先度によって、又はセキュリティ規定による許可若しくは制限によって、又は当業者によって適切であると判断されるその他の任意の特性に基づいて行うことができる。通信経路及びそれらの使用に関する更なる説明は、以下で見られる。
【００５３】
本明細書における技術の典型的で例示的で非限定的な実装形態は、ユーザによって必要に応じて使用される中央設備によってワイヤレスインフラ、モバイルデバイス、及び各種の統合サーバが提供されるホスト型サービスプロバイダビジネスモデルを使用して提供される。このようなやり方での技術の提供は、ユーザがインフラ構成要素の配備及び管理ではなく自身のビジネスに焦点を当てることを可能にする。このアーキテクチャの性質は、異なる企業からの複数のユーザが互いを妨げることなく共通のインフラを透過的に共有することを可能にする。或いは、この技術は、１つの企業がインフラを所有してその従業員及びデバイスに上記インフラへのアクセスを提供する従来のモデルに実装される。当業者ならば、更にその他の適切なモデルも明らかである。
【００５４】
本明細書における技術の典型的で例示的で非限定的な実装形態は、一度に１本ずつ（例：複数本の通信経路の順次使用）であれ、一度に２本以上（例：並行使用）であれ、サーバを終端としない通信経路を通じてであれ、複数本の通信経路を使用して、デバイス間におけるメッセージ又はメッセージセグメントの伝送を可能にする。また、この改善されたシステムは、各通信経路の利用可能性が予期せず変化し尚且つ各種の通信経路が異なる容量、信頼性、能力、及び動作方式を有する環境での通信を可能にできるように帯域内伝送及び／又は帯域外伝送を提供する伝送技術をサポートする。１つ又は複数の通信経路が断続的に中断される状態で、利用可能な通信経路を順番に又は並列に用いて、デバイス間の同期化を行われるように、伝送データの調整を利用可能な通信経路上で行う。これは、本システムの少なくとも１つの特質を実装するために必要とされるデータ項目及び／又はコマンドが、損失又は未検出の重複を伴うことなく通信されるように実施される。第１のデバイスは、一部の通信経路に関連した予期不能な遅延を補償するために、又は一部の通信経路によるメッセージ損失の影響を抑えるために、又はユーザに気付かれる伝送遅延を可能な限り減らすために、又はその他の任意の目的のために、特定のメッセージを複数の通信経路を使用して送信することによって意図的に複製することができる。このような伝送による方式で複製されたメッセージ又はデータ項目は、第２のデバイスによって検出され、これらの複製コピーは、重複として削除される。
【００５５】
図２に示されるように、典型的で例示的で非限定的な現在の実装形態のサーバデバイス（２５００ａ、２５００ｂ）（例：ＴＰＣデバイス）及びワイヤレスモバイルデバイス（２１１０ａ、２１１０ｂ、２１１０ｃ）は、複数の方式で互いに接続することができる。例えば、サーバデバイス（２５００ｂ）は、テレフォニベースのＥＤＧＥ通信経路などの単一の通信経路（２６００ｃ）を通じてワイヤレスモバイルデバイス（２１１０ｃ）に接続することができる。或いは、サーバ（ＴＰＣ）デバイス（２５００ａ）は、ＥＤＧＥ（２６００ｃ）、Ｗｉ−Ｆｉ（２６００ｂ）、及びＳＭＳ（２６００ａ）などの複数の通信経路（２６００ａ、２６００ｂ、２６００ｃ）を通じて複数のワイヤレスモバイルデバイス（２１１０ａ、２１１０ｂ、２１１０ｃ）に接続される。更に、サーバ（ＴＰＣ）デバイス（２５００ａ）は、単一の通信経路（２６００ｂ）を通じて複数のワイヤレスモバイルデバイス（２１１０ｂ、２１１０ｃ）に接続される。また、ワイヤレスモバイルデバイス（２１１０ｃ）は、１本又は複数本の通信経路を使用して複数のサーバ（ＴＰＣ）デバイス（２３００ａ、２３００ｂ）に接続される。更に他の典型的で例示的で非限定的な実装形態では、第１のワイヤレスモバイルデバイス（２１１０ａ）は、１つ又は複数のピア・ツー・ピア（Ｐ２Ｐ）技術を使用し、Ｂｌｕｅｔｏｏｔｈ又はアドホックネットワーキングモードのＷｉ−ＦｉなどのＰ２Ｐ通信経路（２６００ｄ）を通して第２のワイヤレスモバイルデバイス（２１１０ｂ）に接続される。利用可能通信経路の使用は、各経路上をどのタイプのデータが送信されるかを制御するために、セキュリティテンプレートに基づいて制限することができる。例えば、パーツ番号のカタログをパブリック共有Ｗｉ−Ｆｉ接続を通じて送信することは許容されるが、個人情報である従業員の給与データを送信することは許容されない。このような場合、Ｗｉ−Ｆｉ通信経路についてのデバイスのセキュリティ規定は、それが低いセキュリティレベルを有することを規定し、パーツ番号データ及び給与データについてのセキュリティ規定は、それらがそれぞれ低レベル及び高レベルのセキュリティを必要とすることを規定すると考えられる。パーツ番号データは、そのセキュリティ要件がＷｉ−Ｆｉ経路のセキュリティレベルに一致すると考えられ、したがって、Ｗｉ−Ｆｉ経路上で送信されてよいが、給与データは、その高レベルのセキュリティ要件によって、Ｗｉ−Ｆｉ経路を通じて送信されることを禁じられ、したがって、有線のＥｔｈｅｒｎｅｔ接続又は暗号化された短距離Ｂｌｕｅｔｏｏｔｈリンクなどの適切にセキュリティ保証された通信経路が給与システムまで利用可能になるまで保持されると考えられる。
【００５６】
複数の通信経路をサポートすることに加えて、本明細書に記載される技術の典型的で例示的で非限定的な実装形態は、第１のデバイスが自身から第２のデバイスへの伝送を開始させるための手段（「プッシュモード」）を提供する。当業者ならば理解できるように、本明細書に定められ記載される「プッシュモード」の使用は、第１のデバイスが通信経路を使用して伝送を開始して１つ又は複数のメッセージを送信するときに実施される。受信に際し、第２のデバイスは、これらの伝送を受信しそれらのコンテンツを使用してそれらに作用する（例：「コマンド」）又はのちの使用に備えてそれらを（例：ノード若しくはカタログのように）保存する。或いは、デバイスは、「協調プッシュ」モードで動作する。このモードでは、第１のデバイスは、プッシュモードを使用して（１つ又は複数の）データ項目の第１の部分を伝送し、該部分は、同じ又は異なる通信経路を使用して同（１つ又は複数の）データ項目の第２の部分を転送するために第２のデバイスが第１のデバイス又は第３のデバイスのいずれかへの「プルモード」通信を開始させるための要求として第２のデバイスによって（例：コマンドとして又は更なるデータ項目を参照する（１つ若しくは複数の）データ項目として））使用される。使用する通信経路の選択は、それぞれの通信経路及びそれらを通じて移動されるべきデータ項目の１つ又は複数の特性に基づいてなされ、例えば、（１つ若しくは複数の）データ項目の第２の部分の移動をサポートすることはできるがデータ項目群全体についてプッシュモードをサポートするために必要とされる特性には欠ける、又は広帯域幅、高信頼性、若しくは低コストなどのその他の望ましい特性を有する、（１本又は複数本の）通信経路を選択することが挙げられる。本明細書における技術の典型的で例示的な実装形態は、適切な通信手段が利用可能なときに、プルモード、プッシュモード、協調プッシュモード、又はそれらの任意の組み合わせ又は同時に複数を使用することができる。
【００５７】
状況によっては、プッシュモード伝送を開始するために、第１のデバイスが第２のデバイスのユーザを巻き込んで参加させる必要がある。例えば、第２のデバイスがスリープモードに置かれている場合、又はプッシュモード伝送技術が機能できる場所に第２のデバイスが現時点では位置していない場合、ユーザは、第２のデバイスにそのプッシュモード通信（いわゆる「プッシュレジストリ」）を呼び出させる、振動させる、作成若しくは録音された音声メッセージ若しくは適切で且つ利用可能なその他の信号を再生させる、又は当
業者に明らかなこれらの若しくはその他のプロンプトの何らかの組み合わせなどを発生させる、ページ又はＳＭＳメッセージなどの手段を通して、第２のデバイスをアクティブにする又は配置しなおすように促される。
【００５８】
本明細書における典型的で例示的な実装形態は、それぞれが独自の特性（例：コスト、帯域幅、プッシュモードサポート、伝送遅延、信頼性、可用性など）を有する代わりの通信経路の使用も提供する。本明細書における典型的で例示的な実装形態は、１本又は複数本の通信経路を一度に使用すること、利用可能な通信経路間で適宜切り替えを行うこと、最も適した機能を求めて異種の通信経路を使用すること、複数本の通信経路を使用してデータ項目を重複して送信すること、又は当業者に明らかなその他の手段によって、コスト、スループット、信頼性、可用性、伝送遅延、インタラクティブ応答性、又はその他などの、デバイスについての１つ又は複数の通信特質を随意に且つ動的に最適化できるように複数通信経路を管理する手段を提供する。これらの拡張能力は、例えば、デバイスが、特定の通信経路を使用した通信が損失したときに代わりの通信経路に切り替えること、又は複数通信経路を同時に使用することによって全体のスループットを高めることを可能にすることができる。
【００５９】
典型的な実装形態は、典型的なアーキテクチャ内で動作する新しい方法に加えて、多数の新しい接続経路及び接続経路トポロジをサポートする。これらの新しい技術の幾つかの例が、以下で説明される。
【００６０】
一部の典型的で例示的で非限定的な実装形態では、通信経路は、その管理及び使用のための更なるメカニズムを規定するように構成される。例えば、通信経路を通じて送信されるデータ項目は、暗号化、圧縮、チェックサムまたはその他のメカニズムの使用を通して改ざん若しくは損傷から保護される。このような更なる随意のメカニズムは、第１のデバイスから第２のデバイスへの通信経路の一部で使用されてその他の部分では使用されない、又はそのような通信経路の全体で使用される。複数のこのような随意のメカニズムが、同時に使用される。例えば、チェックサムが計算され、データ項目に追加されたとき、それらのデータ項目及びチェックサムは、次いで、圧縮及び伝送され、そのとき、それらの圧縮されたデータ項目及びチェックサムは、通信経路のセグメント上を移送されるときに露見しないように、その通信経路セグメントによって暗号化及び復号化を施される。一部の典型的な実装形態では、暗号化又は改ざんチェックのようなデータ保護メカニズムの使用を決定するために、セキュリティ規定が使用される。例えば、高セキュリティで送信するときは、データは、暗号化され、改ざんの有無をチェックされる。低セキュリティでデータを送信するときは、このような手段は、計算のオーバーヘッドを抑えるために省略される。暗号化、改ざんチェック、又はその他のデータ保護方法の使用によって、通信経路の有効セキュリティレベルを上げることができる。例えば、パブリック共有Ｗｉ−Ｆｉホットスポットは、他者によってデータを傍受される可能性ゆえに、低セキュリティの通信経路であるが、もしデータが強力に暗号化されるならば、中程度の又はひいては高いセキュリティを必要とするデータをこのような経路を通じて送信することが可能である。
【００６１】
各種の利用可能通信経路を使用することによって、本明細書における典型的で例示的な技術は、ピア・ツー・ピア（Ｐ２Ｐ）メッセージ交換と、帯域外通信と、サーバ（ＴＰＣ）デバイスの助けによる又はよらない第１のデバイスから第２のデバイスへのタスクのデリゲートと、複数のデバイスへの有効タスクの告知、応答の収集、告知に応答するもののなかからの、タスクの割り当て先となる１つ又は複数のデバイスの選択、及び選択されたデバイスへのタスクの割り当てと、サーバ（ＴＰＣ）の介在を受けた又は受けないデバイス間におけるカタログデータ項目の同期化と、などを可能にする更なる能力と機能とを提供する。
【００６２】
典型的で例示的で非限定的な現在の実装形態は、デバイス間におけるデジタルデータのブロックの送信を可能にする任意のデータ転送の技術又は組み合わせ技術（通信経路）を通じて実装される。一部の典型的で非限定的な例は、ＧＰＲＳ、ＥＤＧＥ、Ｗｉ−Ｆｉ、又はＥｔｈｅｒｎｅｔを通じたＴＣＰ／ＩＰプロトコル、テレフォニデータ通信経路上のＳＭＳ又はＭＭＳ、及びＢｌｕｅｔｏｏｔｈ又はＷｉ−Ｆｉ「アドホック」ネットワーキングなどのピア・ツー・ピアリンクを含むが、当業者ならば、現時点で存在しているものであれ、将来的に開発されるものであれ、その他の技術によって置き換え可能であることが容易にわかる。
【００６３】
セキュリティ規定の例
典型的な実装形態は、「セキュリティ規定」の使用を伴う柔軟で且つ拡張可能なセキュリティ能力をサポートする。セキュリティ規定は、一部特定の又は限られた範囲の値を有するバイトの順序付き配列であり、データ項目、データ項目群、デバイス、又はサーバなどのエンティティに関連付けられ、該関連付けられたエンティティのアクセス、使用、又は変更に対する許可及び／又は制約を規定するために使用される。
【００６４】
セキュリティ規定は、各種の方式でエンティティに関連付けられる。データ項目（例：ノード）などの一部のエンティティの場合、セキュリティ規定は、エンティティに、その通常の特質として埋め込まれる。通信経路、ユーザ、又はデバイス／サーバなどのその他のエンティティの場合、セキュリティ規定は、エンティティから離れて位置しており、名前、ＩＤ、又はエンティティに適用可能なセキュリティ規定の発見若しくは識別を可能にするその他の参照によって、エンティティに関連付けられる。エンティティに埋め込まれない場合のセキュリティ規定は、カタログ、ＢＬＯＢノード、外部データベース、ファイル、又は当業者によって適切であると判断されるその他の場所などに保存される。所定のエンティティについて外部に位置するセキュリティ規定を見つけるために使用される方法は、選択された保存の場所及び方法に依存する。例えば、ユーザ、デバイス、又は通信経路などのエンティティのためのセキュリティ規定がリレーショナルデータベースに保存されている場合、そのセキュリティ規定は、そのセキュリティ規定を含む記録に対するキーとしてのエンティティＩＤを伴って保存され、該エンティティＩＤを使用することでセキュリティ規定の検索できる。当業者にならば、その他の保存及び検索の方法が自明である。
【００６５】
セキュリティ規定は、様々な方式で作成される。セキュリティ規定がノードなどのエンティティに埋め込まれる場合、そのセキュリティ規定は、ノードを作成するＦＤＬの規定から、ノード作成プロセスの一環として生成されるなどのように、エンティティを生成する方法によって生成される。一部の典型的実装形態では、セキュリティ規定は、ＦＤＬ規定からであれそれ以外からであれ、エンティティとは別に作成され、別のステップでエンティティに挿入される。セキュリティ規定が、その関連付け先であるエンティティとは別に作成される場合、セキュリティ規定の作成の方法は、ＦＤＬ規定を利用する、又はユーザコマンドラインオプションやグラフィカルユーザインターフェースウィジェット（例：ボタン、テキストフィールド、チェックボックス、ラジオボタン、ドロップダウンリスト、メニューなど）などのその他の入力からセキュリティ規定を作成可能なソフトウェアアプリケーションを利用する、テキスト、ＸＭＬ、若しくはＳＱＬなどのその他のフォーマットによるセキュリティ規定の記述を、スクリプト若しくはテンプレートの使用を通じて利用する、又は既存のセキュリティ規定を参照にする、又はこれらのいずれか若しくは全部の組み合わせを使用することができる。例えば、ＭｙＳＱＬなどのリレーショナルデータベースに保存されるべきセキュリティ規定は、グラフィカルユーザインターフェースを通じたユーザ入力に基づいて作成することができ、これらの入力は、ＳＱＬコマンドの保存テンプレートからＳＱＬコマンドを作成するスクリプトのコマンドライン呼び出しを生成するために使用され、結果得られたＳＱＬコマンドは、ＭｙＳＱＬデータベースソフト
にＭｙＳＱＬデータベース内にセキュリティ規定の記録を作成させるために使用される。
【００６６】
典型的なセキュリティ規定は複数の要素からなり、関連エンティティのＩＤ（セキュリティ規定がエンティティに埋め込まれない場合）、関連エンティティのためのセキュリティレベル規定、関連エンティティによって保持されるセキュリティタグ、及び関連エンティティに対して保持、使用、変更、転送、又はその他のアクションの実施を許可されるために第２のエンティティが保持していなければならない１つ又は複数のタグを記述したゼロ又は１つ以上のルールを含む。
【００６７】
典型的なセキュリティ規定が、図１５に示されている。典型的なセキュリティ規定を構成する項目には、随意の関連エンティティ（associated entity）ＩＤ（１５１００）、関連エンティティセキュリティレベル（１５２００）、関連エンティティタグ（１５３００）、及びゼロ又は１つ以上のアクション／ルールペア（１５４０５／１５４１０、１５４１５／１５４２０、１５４２５／１５４３０）を含む随意のアクション／ルール組み合わせセクション（１５４００）を含む。
【００６８】
関連エンティティＩＤ（１５１００）は、関連エンティティとは別に保存されるセキュリティ規定に存在し、関連エンティティに埋め込まれるセキュリティ規定には随意として存在する。関連エンティティＩＤ（１５１００）は、特定のセキュリティ規定インスタンスに関連付けられたエンティティを特定するために使用される。関連エンティティＩＤ（１５１００）は、デバイス若しくはサーバのＩＤ、通信経路の指定、ユーザ名若しくはログインＩＤ、ノードＩＤ、カタログＩＤ、又は当業者によって有用であると判断されうるその他のエンティティ識別子を含むことができる。
【００６９】
関連エンティティセキュリティレベル（１５２００）は、関連エンティティタグ（１５３００）又はアクション／ルールペア（１５４００）によって記述されるようなセキュリティ規定の詳細にかかわらず、セキュリティ規定をグループ分けするための一般的なセキュリティ分類を指定する。一部の典型的で例示的な実装形態では、関連エンティティセキュリティレベル（１５２００）は、大きい値ほど高いセキュリティレベルを示し、小さい値ほど低いセキュリティレベルを示す数値である。その他の典型的で例示的な実装形態では、関連エンティティセキュリティレベル（１５２００）は、「高」、「中」、「低」など、いずれかの指標が高いセキュリティレベルを示し、その他のいずれか指標が低いセキュリティレベルを示す階層を想定した、固定のセキュリティレベル指標群の１つである。選択される実装形態にかかわらず、高いセキュリティレベルのセキュリティ規定は、その高いセキュリティレベルを受信エンティティが有しているときは、より低いセキュリティレベルを有するセキュリティ規定に適合可能（compatible）であると見なされるが、受信エンティティが低いセキュリティレベルを有しているときはそうは見なされない。これらの制約は、データが、そのセキュリティ規定によって要求されるよりも安全なエンティティに移る又は安全な通信経路を通ることはできるが、それよりも安全ではないエンティティに移る又は安全ではない通信経路を通ることはできないことを保証する。データが転送されるには、送信エンティティ、受信エンティティ、使用される通信経路、及び転送されるデータの全てのセキュリティ規定が適合していなければならない。
【００７０】
関連エンティティタグ（１５３００）は、関連エンティティセキュリティレベル（１５２００）項目によって提供されるよりも細かいセキュリティアクセス許可の規定に使用される。関連エンティティタグ（１５３００）は、ゼロ又は１つ以上の「タグ」を含む。タグは、典型的な実装形態を背景にしたときに特定の意味を有する数字、文字、又はその他のデータオブジェクトである。セキュリティ規定の関連エンティティタグ（１５３００）項目には、任意の数及びタイプのタグを含めることができる。これらは、後述のように、第２のセキュリティ規定のアクション／ルールペア（１５４００）と組み合わされたとき
に関連エンティティに特定の一連の許可又は制約を提供するために使用される。
【００７１】
セキュリティ規定は、ゼロ又は１つ以上のアクション／ルールペア（１５４００）を含むことができる。第１のエンティティのセキュリティ規定内のルール（１５４１０、１５４２０、１５４３０）は、指定のアクション（１５４０５、１５４１５、１５４２５）を実行する目的に対して第２のエンティティが第１のエンティティと適合可能であると見なされるために、第２のエンティティのセキュリティ規定に含まれなければならない又は含まれることができない関連エンティティタグ（１５３００）を規定するために使用される。アクション（１５４０５、１５４１５、１５４２５）は、典型的で例示的で非限定的な実装形態を背景としたときに特定の意味を有する数字、文字、又はその他のデータオブジェクトを含み、実行可能な各種のアクション（特定のデータ項目を保持する、データ項目を別のデバイスに転送する、ノード群を実行する、デバイス上のカタログを更新するなど）を指定するために使用される。指定可能な一連の特定のアクションは、実装形態に依存する。ルール（１５４１０、１５４２０、１５４３０）は、第２のエンティティが第１のエンティティと適合可能であるために、第２のエンティティの関連エンティティタグ（１５３００）内になければならない又はあってはならない１つ又は複数のタグを規定する。ルールは、当業者によく知られた方式でタグの組み合わせ又はタグの欠如を任意に指定することを可能にするブール表現である。例えば、第２のエンティティが、マシンのメインテナンスが必要な旨の警告などの関連のアクションを実行する目的と適合可能であるためには、第２のエンティティが「ＭＡＩＮＴＥＮＡＮＣＥ」タグ及び「ＭＡＮＡＧＥＲ」タグを保持していなければならないが「ＤＩＲＥＣＴＯＲ」タグは保持してはいけないことをルールで規定できる。このようなルールは、このような警告がメインテナンスの取締役（director）に送信されることは阻止するが、メインテナンス部門の別の管理者（manager）に送信されることは許可すると考えられ、すると、管理者は、例えば、マシンの修理にあたらせるためにタスクを作成して作業員に割り当てることができる。
【００７２】
ルールの評価を推進するアクション／ルールペア（１５４００）及び関連エンティティタグ（１５３００）は、関連エンティティセキュリティレベルが適合可能である場合にのみチェックされる。これらは、割り当てられたセキュリティレベルによって指定された適合性に対する制約を覆すために使用することはできない。これらは、適合可能なセキュリティレベル関係内で細かい適合性の管理を提供するために使用することができ、例えば、管理者が自分の監督下にある従業員に関するデータを人材システムから受信することは許可するが同じ管理者が自分の監督下にない従業員に関するデータを受信することは許可しない、又は作業員が自分に割り当てられたとあるタスクをキャンセルすることは許可するがその他のタスクのキャンセルは許可しない、などである。セキュリティレベルの割り当て、並びに各種エンティティに対するタグ及びアクション／ルールペアを注意深く使用することによって、データの移動及び使用のあらゆるパターン、データの移動の方法、並びにデータの移動又は使用に対する制約を確立することができる。
【００７３】
通信方法の例
典型的な先行技術デバイスによってサポートされるプルモードの動作に加えて、典型的なデバイスは、プッシュモード、協調プッシュモード、帯域外伝送、及び通信経路切り替えをサポートすることができる。
【００７４】
［ピア・ツー・ピア通信］
前述のように、ピア・ツー・ピア（Ｐ２Ｐ）通信は、サーバ又はその他のデバイスによって通信を可能にする必要性を伴わない、２つ又は３つ以上のデバイス間における直接的な接続に関わる。この接続のモードをサポートできるものに、Ｂｌｕｅｔｏｏｔｈ、又は「アドホック」モードでのＷｉ−Ｆｉなどの、複数の技術がある。一部の実施形態では、Ｐ２Ｐは、ひとまとまりの作業を表わすデータ項目を第１のデバイスが第２のデバイスに
送信することを可能にするなどのように、サーバに接続する必要なくデバイス間におけるメッセージ及びメッセージセグメントの伝送を可能にするために使用される。これは、監督者が部下にタスクを割り当てることを可能にするため又は作業員が同僚にタスクを引き渡すためなどのように、多くのやり方で有利である。
【００７５】
Ｐ２Ｐ通信は、また、サーバデバイスへの利用可能通信経路を有するデバイスが、このような接続性を持たないモバイルデバイスのために「データ項目キャッシュ」として機能するためにも有利である。例えば、有線Ｅｔｈｅｒｎｅｔ接続などの高速接続経路を有する第１のデバイスにデータ項目が送信され、位置又は信号遮蔽などの環境的要因ゆえにサーバに対する接続性を有さない第２のデバイス又はその他のデバイスのために保持される。第２のデバイス又はその他のデバイスは、それらのデータ項目の第２のデバイス又はその他のデバイスへの転送のために、Ｂｌｕｅｔｏｏｔｈ、又は「アドホック」モードでのＷｉ−ＦｉなどのＰ２Ｐ技術によって、第１のデバイスに接続することができる。第２のデバイス又はその他のデバイスからサーバデバイスに送信されなければならないデータ項目は、第１のデバイスに送信される。第１のデバイスは、それらのデータ項目を、別の通信経路、又は以下で説明される方法によるなど適切であると判断されるその他の接続によって、サーバに転送する。
【００７６】
Ｐ２Ｐを使用してデバイス間で通信が開始されるとき、それらのデバイスは、互いを認識及び発見する方法を有してなければならない。一部の典型的な実装形態では、これは、情報がカタログの形態でデバイスに配布されることによって達成される。Ｂｌｕｅｔｏｏｔｈ既知のデバイスＩＤ、アドホックＷｉ−Ｆｉネットワークの名称及びアドレス、並びにデバイス認証材料はもちろん、Ｐ２Ｐ通信方法を使用しているデバイス間における発見、接続、及び認証に有用なその他の情報を含有するカタログは、サーバによって配布及び更新され、必要になるまでデバイスに保存される。或いは、第１のデバイスが、アドホックＷｉ−Ｆｉネットワーク又はＢｌｕｅｔｏｏｔｈデバイスなどの通信経路を認識するとき、第１のデバイスのユーザは、上記通信経路の使用を許可するように、又はこのような経路を割り当てるための特性（例：通信経路を動的に選択するために使用される重み付け係数）を指定するように、又は上記通信経路を使用するために必要とされる認証材料（例：ユーザ名、パスワード、若しくはクレジットカード番号）を提供するように、促されることがある。通信経路についてのセキュリティ規定は、大抵の場合、サーバによって供給される。適切に特権付与されたセキュリティ規定がユーザに関連付けられているときは、ユーザも、通信経路又はその他のエンティティについてのセキュリティ規定情報を供給することができる。
【００７７】
［プッシュモード及び協調プッシュモード］
図３のフローチャートに示されるように、プッシュモードは、協調プッシュモード通信を実装できるようにデータ項目の送信及びコマンドの送信の両方を行うために使用される。記載される典型的な手続きは、ＳＭＳメッセージを受信可能であり尚且つＷｉ−Ｆｉホットスポットに位置するときにＷｉ−Ｆｉリンクを確立可能である典型的なデバイスにデータ項目を送信することを含む。典型的なデバイスは、データ項目が送信されなければならない時点でＷｉ−Ｆｉホットスポットに位置していない、そのＩＰアドレスが送り手に知られていない、又はデバイスへの接続を阻むファイアウォール、ルータ、若しくはその他のコンポーネントがある、のいずれかである。
【００７８】
一実施形態では、デバイスへのデータ項目の送信における第１のステップは、送信されるデータ項目の特性を決定することである（３０１０）。ＳＭＳは、帯域幅が非常に限られ尚且つメッセージサイズの制限があり、これは、大きな伝送を一連のセグメントに分割し、各セグメントを別々のＳＭＳメッセージで送信することを必要とする可能性がある。ＳＭＳは、送信されるメッセージの数によってコストが変わることがあるので、多くの場
合、ＳＭＳを使用して送信するデータ項目の数を制限することが望まされる。
【００７９】
送信されるべきデータ項目が、１つのＳＭＳメッセージに収めるのに十分な小ささである場合は、又はその他の理由でＳＭＳを使用して送信されるべきであると判断される場合（３０２０）、データ項目を含む１つ又は複数のＳＭＳメッセージが構築され（３０３０）、デバイスに送信され（３０４０）、プロセスが完了する。
【００８０】
送信されるべきデータ項目が、ＳＭＳを使用して送信するのに適していないと判断される場合（３０２０）は、プッシュモードではなく協調プッシュモードが使用され、通信要求コマンド（後述される）が構築されてＳＭＳメッセージ内に配され（３０５０）、該メッセージは、次いで、デバイスに送信され（３０４０）、プロセスが完了する。後者の場合、実際のデータ項目は、デバイスが通信要求コマンドに応答し、プルモード通信セッションを実施するときに伝送される。これは、図４（４１００）に概述され、ここでは、通信要求メッセージは、サーバからデバイスに送信される（４１１０）。デバイスは、Ｗｉ−Ｆｉなどの適切な通信経路上にプルモード接続を確立することによって応答し（４１２０）、サーバは、この通信経路を使用して待機データ項目をデバイスに送信する（４１３０）。当業者にならば明らかなように、通信要求コマンドを運ぶためにＳＭＳを使用することは、例示に過ぎず、デバイスへのプッシュモードが可能な任意の通信経路で置き換え可能である。例えば、ＭＭＳメッセージ、既存のＰ２Ｐ接続又はＷｉ−Ｆｉ接続、任意の利用可能インターフェース上のＴＣＰ／ＩＰがある（例：ソケット接続を通したＴＣＰパケット、ＵＤＰパケット、ＩＰｖ６やＩＰｖ４あるいはその他のＷｉ−Ｆｉ上のプロトコルを使用したマルチキャストパケット若しくはブロードキャストパケット、有線ＥｔｈＥｅｒｎｅｔインターフェースへのＢｌｕｅｔｏｏｔｈリンク、ＳＬＩＰやＰＰＰ若しくはその他のプロトコルを使用したダイヤルアップモデム）。
【００８１】
任意の形態の通信と同様に、（サーバであれ、モバイルデバイスであれ、又はその他のデバイスであれ）第１のデバイスは、第２のデバイスにどのように連絡を取るかを知るための情報を有していなければならない。一部の典型的な実装形態では、デバイス自身のユーザによって、又はサーバデバイスがカタログ若しくはその他の手段を使用して最新のアドレス及びその他の必要なデータ項目で定期的に更新することによって、第１のデバイスが、第２のデバイスのアドレスやサポートされている通信経路などに関する所要のデータを有するように構成される。その他の典型的実装形態では、第１のデバイスは、ＬＤＡＰ（Lightweight Directory Access Protocol）若しくはＤＮＳ（Domain Name System）などの既知のサービスから、又はＡＲＰ（Address Resolution Protocol）などと同様に要求をブロードキャストし、第２のデバイス若しくは異種のデバイスから応答を受信することによって、第２のデバイスに関する所要の情報を得る。一部の典型的な実装形態では、アドレス及びその他の所要の情報は、オペレータがデータ項目を入力することを通じて手動でサーバに提供され、一方で、その他の典型的な実装形態では、デバイスは、ダイナミックＤＮＳ（Dynamic DNS）、カタログ更新、又は当業者によって有効であると判断されるその他の方法などの方法を使用して、自身のアドレス及びその他の所要の情報に関する最新の情報にサーバを自動的に更新する。デバイスは、ＴＣＰ／ＩＰアドレスを決定するためにＤＮＳを使用する、及びＳＭＳアドレッシング情報のために保存カタログを使用するなどのように、異種のデバイスに関するアドレス又はその他の必要な情報を決定するために、複数の情報源を使用することができる。
【００８２】
［帯域外伝送（ＯＯＢ）］
複数通信経路能力は、帯域外（ＯＯＢ）伝送の更なる機会を提供する。帯域外伝送では、好ましい経路以外の通信経路を通して又は予定されるポーリング期間若しくは定期的な連絡以外の時間にデータ項目が交換される。一部の実施形態では、ＯＯＢは、高優先度伝送を提供するために使用される。高優先度伝送は、例えば、緊急警報、ソフトウェア若し
くはデータ項目の更新、ユーザ間でのタスクの調整、あるいは、デバイスが次のポーリング間隔で接続したり、ユーザが次に好ましい通信経路のサービスを利用可能なアクセスポイントに行くのを待つべきではない急を要する事柄などである。
【００８３】
その他の実施形態では、ＯＯＢは、サーバがクライアントへの接続を開始させるプッシュモード転送を実施するためにも使用される。内在する設計上の制限ゆえに、必ずしも全ての通信経路がプッシュモードの使用を許可するわけではなく、そのような通信経路の幾つかは、広い帯域幅ゆえに、好ましく又は主に使用される経路である傾向がある（例：Ｗｉ−Ｆｉや有線Ｅｔｈｅｒｎｅｔなど）。この場面では、即刻のプルモード接続を要求するコマンドが、プッシュモードを許可する通信経路（例：ＳＭＳ又はＭＭＳ）を通じてＯＯＢ送信される。受信デバイスは、すると、プルモードセッションを開始させ、サーバは、上述のように選択された好ましい接続を通じて所要のデータ項目を転送する。一部の典型的実装形態では、アプリケーションソフトは、可能になり次第、ホットスポットに移動する、有線Ｅｔｈｅｒｎｅｔポートに接続するなどによってこのような接続を可能にするように、ユーザに対して要求することができる。
【００８４】
当業者ならば以上からわかるように、典型的で例示的で非限定的な実装形態によって可能にされるＯＯＢは、あるデバイスが、好ましい通信経路を通じて接続するための容量に限界があり、現時点でその容量を使い尽くす方式で接続されているが、現時点で接続されていない別のデバイスから優先度の高いメッセージの送信を受けなければならないような状況で、有用である。例えば、あるデバイスが、一度に１つのＢｌｕｅｔｏｏｔｈ接続に限られ、現時点ではサーバに接続されてメッセージを交換している場合、そのデバイスのための優先度の高いメッセージを持つ第２のサーバは、それを送るためにＢｌｕｅｔｏｏｔｈを通じてデバイスに接続することができないであろう。この場面では、サーバは、ＳＭＳ又はＭＭＳを使用してメッセージをＯＯＢ送信し、そうして、Ｂｌｕｅｔｏｏｔｈ接続の限界を回避することができる。
【００８５】
通信経路には、それらの設計及びよくあるそれらの実装方式ゆえに、プッシュモード伝送に対応可能でないものがある。例えば、インターネットは、ＴＣＰ／ＩＰプロトコルを使用しており、これは、接続する側のデバイスが、接続される側のデバイスのネットワークアドレスを指定する必要がある。サーバデバイスは、通常、知られている、又はＤＮＳ（Domain Name System）などのシステムを通じて他のデバイスによって学習される、固定のアドレスを有しており、これは、他のデバイスがサーバへの接続を開始することを可能にする。大半のモバイルデバイスを含む非サーバデバイスは、通常、固定のアドレスを与えられておらず、ネットワークに接続されるときに、必要に応じて（ＤＨＣＰ（Dynamic Host Configuration Protocol）などの手段を通じて）一時的なアドレスを要求する。したがって、このようなデバイスは、アドレスを知られていないために接続を受けることはできないが、知られているアドレスを有するサーバデバイス又は他のデバイスに自身が接続することはできる。どのデバイスでも接続することができる通信経路は、プッシュモード伝送に対応可能であり、前述のように、たとえ容量に限りがある通信経路でも、それ自身はプッシュモードをサポートしていない更に有能な通信経路を通したプルモードセッションを開始させるように別のデバイスに要求するために、プッシュモードで使用することができる。
【００８６】
［通信経路の構成］
Ｐ２Ｐ技術や特定の民間のＷｉ−Ｆｉホットスポットなどを使用するデバイスによる通信経路の使用を可能にするには、このような通信経路を使用するデバイスが、任意のアドレス指定、デバイスＩＤ、暗号化キー、認証情報、又は通信経路を通したデバイス間における発見、接続、及び信頼できる通信の確立に必要とされるその他のデータを伴うように構成されなければならない。このような構成情報は、デバイスのメーカによってデバイス
に含められたり、デバイスのユーザによって追加されたり、サーバデバイスから（例：構成メッセージ若しくはカタログデータ項目として）送信されたり、使用される特定の通信技術の標準的な特質であったりし、又はこれらの任意の組み合わせである。構成情報に対する更新は、デバイスのユーザによってなされたり、サーバデバイスから送信されたり、使用される特定の通信技術の標準装備であったりし、又はこれらの組み合わせである。例えば、Ｂｌｕｅｔｏｏｔｈ  Ｐ２Ｐ通信の場合、Ｂｌｕｅｔｏｏｔｈピコネットの確立は、ピコネットに参加しているデバイスがピコネットのメンバによって使用される無線周波数の変化のパターンを計算してそれらのメンバとの連絡を維持することを可能にする情報の交換を伴う。このような情報交換は、Ｂｌｕｅｔｏｏｔｈ技術プロトコルの標準部分である。別の例では、「アドホック」Ｗｉ−Ｆｉネットワークに加入しているデバイスは、同ネットワークの他のメンバの識別を可能にしてそれらのメンバとの通信を許可するためのネットワーク名データ（例：「ＳＳＩＤ」）及びアクセス情報（例：「ＷＡＰキー」）を必要とするであろう。このような情報は、ユーザがデバイス構成に情報を入力したりサーバが構成情報をデバイスに送信したりするなど「アドホック」Ｗｉ−Ｆｉネットワーク以外の手段によって、デバイスに提供されなければならない。民間のＷｉ−Ｆｉホットスポットの使用などの非Ｐ２Ｐ場面では、構成情報は、アカウントログイン及びパスワード値、又はその他の形態の識別及び認証からなることができ、或いは、ＳＭＳの場合は、連絡を取るべき異種デバイスの電話番号からなることができる。
【００８７】
Ｗｉ−Ｆｉ  ＳＳＩＤや関連の認証材料などのネットワークアクセス情報を収集及び配布する方法の、典型的で非限定的な一例は、このような情報をカタログに保存し、該カタログを、特定のネットワークアクセスを使用してアクセスを付与される全てのデバイスに配布することである。例えば、モバイルデバイスは、特定の接続技術を使用して接続を確立するためにセッションマネージャによって使用可能なＳＳＩＤと関連のアクセスキー（例：ＷＡＰキー、アカウント／パスワードペア）とのセットを含む、ワイヤレス「ホットスポット」をサポートしている接続情報のカタログを受信することができる。異なる通信技術は、異なるカタログを有することができる（例：技術ごとに１つのカタログ）、又は１つのカタログが、複数の通信技術についての情報を含むことができる。また、ユーザは、特定のユーザ／デバイスに付与されるアクセス権及び接続性に応じて異なる（１つ又は複数の）カタログを自身のデバイスに提供されて有することができる。一実装形態では、これらの通信技術カタログは、共通のサーバ（ＴＰＣ）デバイス上に維持され、必要に応じてモバイルデバイスに配布される。これらのカタログの、使用に先立つ配布及びキャッシュは、モバイルデバイスが領域内にあるときにこれらのカタログのコンテンツが使用されることを可能にし、サポートされている通信経路間におけるデバイスのシームレス移行を可能にする。或いは、デバイスは、特定の場所で特定の通信技術がアクティブであることが識別されたときに、その技術のカタログを求めて共通のサーバデバイスに問い合わせることができる。問い合わせに対する応答は、サーバデバイスが、１つ若しくは複数のカタログ、又は１つ若しくは複数のカタログの一部を構成する１つ若しくは複数のデータ項目を要求デバイスに送信するためのものである。
【００８８】
代替の典型的で非限定的な例では、カタログ配布メカニズムは、既知のデバイスＩＤ、ユーザＩＤ、並びに既知のデバイス及びユーザの承認材料を配布するために使用される。モバイルデバイスは、ピア・ツー・ピアネットワーク上の又はサーバデバイスへの接続に依存しないその他のネットワーク上の第２のモバイルデバイスを識別すると、両デバイス間に通信経路を確立するために、デバイスＩＤ及び承認材料を使用することができる。例えば、フレッドのデバイスが、デバイスＩＤ  １と、所要の認証文字列「秘密」とを有する場合、スーのデバイスは、フレッドを識別するカタログ要素、すなわちフレッドのデバイスＩＤ（例：１）と、認証材料（例：「秘密」）とを含むカタログを受信することができる。フレッドは、スーを識別する同じ（又は異なる）コピー、すなわちスーのデバイスＩＤ（例：２）と、所要の認証材料（例：「スーの秘密」）とを受信するであろう。ネッ
トワーク上のデバイスをデバイス２として認識するにあたり、フレッドのデバイスは、ユーザ（スー）を検索し、スーのデバイスに送信するメッセージがあるかどうかを判断する。もしあるならば、フレッドのデバイスは、相手方のデバイスが真正であって尚且つ接続の開始を承認されていることを両エンドポイントが請け合うことができるように、認証材料を使用して、フレッドのデバイスとスーのデバイスとの間に通信経路を作成することができる。一部の代替の実施形態では、カタログから選択されたユーザ、デバイス、及び認証材料の要素のみが、特定のデバイスに転送される。デバイスに配布されるカタログ要素を制限することによって、配布されたカタログ要素は、第１のデバイスが第２のデバイスに接続するための承認フォームとして使用される。双方のデバイスが、自身についての及び接続デバイスについての両方のカタログ要素を有さないときの接続試行は、認証材料の欠如ゆえに失敗する。この技術は、ＢｌｕｅｔｏｏｔｈやアドホックＷｉ−Ｆｉを使用して作成されるなどのピア・ツー・ピア接続に有利である。セキュリティ規定は、データのタイプ、特定のデータ項目、又は今述べられた認証方法とは独立にデバイス間でデータを伝送するために使用可能な通信経路を更に限定するために使用することができる。例えば、フレッドのデバイスとスーのデバイスとが秘密を交換して互いを認識した後も、スーのデバイスは、依然、デバイスどうしのセキュリティ規定要件の一致の欠如ゆえに、又はデバイス間の通信経路に関連付けられたセキュリティのレベルゆえに、高いセキュリティレベルを持つ又は特定の受け手に制限される利益率データや給与情報などの特定のデータをフレッドのデバイスに送信することを、禁じることができる。
【００８９】
接続及びアクセスの構成に加えて、各通信経路は、各通信経路の特性（速度、コスト、信頼性など）及び各通信経路によってサポートされる機能（プッシュモード若しくは大メッセージサイズなど）を特定するための追加の情報若しくは設定、又は各種の可用性、データ項目優先度、若しくはその他の要因の条件下でどの通信経路を使用するかを決定するために使用されるプリファレンス設定、又は当業者によって適切であると見なされるその他の通信経路構成も伴うように構成される。
【００９０】
モバイルデバイスが、Ｗｉ−Ｆｉアクセスポイントを使用して割り当てられるＩＰアドレスなどの一時的な通信アドレスを使用して動作しているときは、この現在の通信アドレスは、異種デバイスがこの現在の通信アドレスを使用して第１のモバイルデバイスに連絡するために必要とされる。一実施形態では、サーバ（ＴＰＣ）デバイスは、モバイルデバイスからのメッセージの受信をもって、デバイス通信アドレスのカタログを更新する。（１つ又は複数の）更新されたカタログ要素は、必要に応じてその他のデバイスに配布される。或いは、モバイルデバイスは、一時的な通信アドレスを割り当てる通信技術への接続を確立するにあたり、デバイス上に保存されている自身のカタログ要素を更新し、次いで、そのカタログ要素をサーバデバイス（又は通信先の任意の他のデバイス）と同期化させることができる。これは、２つのデバイスが、ピア・ツー・ピア通信経路を使用して低帯域幅の接続を確立すること、現時点で接続されている高帯域幅のネットワークのための一時的な通信アドレスを交換し合うこと、及び次いで、デバイス間に高帯域幅の通信経路を確立することを可能にする。更に別の実施形態では、モバイルデバイスは、一時的な通信アドレスを受信するときに、ＤＤＮＳなどの標準的な動的アドレス指定プロトコルを使用して中央サービスを更新することができる。これは、カタログ要素を一時的な通信アドレスと同期化させる必要性を排除するが、利用可能通信経路を標準的な動的アドレス指定プロトコルを使用して解決される通信経路に限定する。
【００９１】
［通信経路の切り替え］
上述のように、全ての通信経路は、接続性の途絶及び損失に曝される。接続性の損失は、経路上の複数の地点で起こり得る。デバイスがその通信ハードウェアの障害に見舞われたり、接続の損失が（Ｗｉ−Ｆｉホットスポットから去るときなどに）信号レベルで生じたり、通信インフラの一部が利用可能でなくなったり（例：携帯電話会社におけるサービ
スの途絶、インターネットにおける接続性の停止、ＳＭＳサーバのオーバーロードなど）、デバイスの通信相手であるサーバが利用可能でなくなったりする可能性がある（例：電源異常、システムメインテナンス、ソフトウェアエラーなど）。１本の通信経路上における接続性の損失は、必ずしもそのデバイスのための全ての通信経路が利用可能でなくなることを意味しない。利用可能な通信経路が複数あり、そのうちの１本又は２本以上が何らかの理由で使用できなくなったときに、デバイスは、可用性を維持している通信経路に切り替える選択肢を有することができる。デバイスは、また、利用可能な通信経路の使用を最適化し、速度、信頼性、若しくは応答性などの特質を向上させる又はコスト若しくは遅延などの特質を低減させることができるように、接続性の損失を伴わなくても通信経路を切り替えることができる。デバイスは、障害が発生したときにのみ、又は設定で変えられる若しくはハードコーディングされた基準で定期的に、又は新しい通信経路が利用可能になったときに、又はこれらの任意が組み合わさるときに、又は当業者によって適していると判断されるその他の選択肢で、自身による利用可能通信経路の使用を再評価することができる。
【００９２】
一部の典型的なデバイスは、通信経路の自動選択をサポートする。ここでは、通信経路の切り替えは、ユーザ側におけるアクションを伴わずに、尚且つ一部の実装形態では、アプリケーションソフト側におけるアクションも伴わずに、通信経路の切り替えがなされる。このような典型的なデバイスは、デバイスのオペレーティングシステムが通信経路を選択し、アプリケーションソフトは現時点で選択されている通信経路を常に使用し、デバイスの指示にしたがって通信経路を変更するように、設計される。このような切り替えは、一部の典型的実装形態では、ユーザ又はアプリケーションソフトに対して透過的であり、その他の実装形態では、ユーザ又はアプリケーションソフトによって検出可能である。
【００９３】
その他の典型的デバイスでは、デフォルトで使用される通信経路はデバイスのオペレーティングシステムによって決定されるが、アプリケーションソフトがそれを覆し、オペレーティングシステムにそのメーカによって供給されるメカニズムの使用を通して代わりの通信経路を使用することが可能である。
【００９４】
例えば、一部の実装形態では、切り替えは、既存の通信経路上における接続性の損失に対するフェイルオーバ応答としてなされる、又は切り替えは、現時点で使用されている通信経路よりも別の通信経路が好ましいと判断されたときに随時なされる（経路の最適化）。通信経路の障害がデバイスにローカルな要因に起因しない一部の状況では、自動的に切り替えを行うデバイスでも、別の通信経路への切り替えをアプリケーションによって推し進められる必要があることがある。例えば、デバイスがＷｉ−Ｆｉ通信経路を使用しており、ホットスポットファイヤウォールのＷｉ−Ｆｉ構成に対して変更がなされた結果、デバイスの接続先であるサーバのアドレスに対するアクセスが遮断された場合、デバイスは、依然、Ｗｉ−Ｆｉ信号を検出してＴＣＰ／ＩＰパケットの送受信を行うことができるので、Ｗｉ−Ｆｉ接続を使用してサーバに到達することができないという事実にもかかわらず、別の通信経路に自動的に切り替わらない。このような場面では、デバイスのアプリケーションソフトが、ＧＰＲＳ又はＥＤＧＥなどの別の通信経路への切り替えを推し進めることによって、サーバへの通信を再確立することができる。
【００９５】
一部の実施形態では、通信経路の障害の結果として通信経路を切り替えるための方法は、幾つかの段階を伴う。第１に、接続性の損失が検出される。第２に、代わりの通信経路が選択される。第３に、新しい通信経路を通じて接続性が確立される。より具体的な実施形態では、経路の最適化が使用されているとき、デバイスは、このプロセスの第２のステップを実施して、１本又は複数本の通信経路を選択し、もし、（１本又は複数本の）選択された経路が目下好ましいとされている（１本又は複数本の）経路と異なるならば、デバイスは、（１本又は複数本の）選択された経路を目下好ましいとされる（１本又は複数本
の）経路にすることができるように、通信経路の切り替えを開始する。
【００９６】
当業者ならばわかるように、接続損失の検出は、通信経路によって容易であったり困難であったりする。例えば、ＴＣＰ／ＩＰ通信経路上のＴＣＰパケットなどの接続指向プロトコルを使用するときは、これがＷｉ−Ｆｉ、Ｂｌｕｅｔｏｏｔｈ、又はその他の何らかの手段のいずれを使用してなされるものであれ、パケットが宛先システムによって受信されたときは肯定応答が返され、再伝送を繰り返した後も肯定応答が受信されなかった場合は、接続の損失を意味する。このケースでは、経路沿いのどこで障害が発生したかに関係なく、接続の損失が検出可能である。ＴＣＰ／ＩＰ上のＵＤＰパケットやＳＭＳなどのその他のプロトコルの場合は、伝送プロトコルの一環に肯定応答が含まれず、もし問題がデバイスにローカルでない場合は、アプリケーションレベルのプロトコルが通信問題の検出のための何らかの形態のフィードバックを含まない限り、検出が不可能である。例えば、サーバからクライアントにメッセージを送信するためにＵＤＰ又はＳＭＳが使用される場合は、クライアントは、メッセージが受信されたときにＵＤＰ又はＳＭＳメッセージをサーバに返すことによって、メッセージの到着を肯定することができる。もし移動中にメッセージが損失された場合は、肯定応答パケットはなく、サーバは、クロックチップ、ループカウンタ、又はプログラム可能な割り込み機能などの適切なメカニズムによって決定される適切な時間の経過後に、メッセージを再送信することができる。もし移動中に肯定応答パケットが損失された場合は、サーバは、メッセージを再送信し、クライアントは、更なるコピーを受信し、その受信を再び肯定することができる。これは、メッセージが受信され、サーバがメッセージ受信の肯定応答を得るまで、又は接続が利用不可能であると見なされるのに十分な試行が失敗に終わるまで続く。重複するメッセージ及びノードが検出され、後述の手段によって無視される。通信経路が利用不可能であると判断されたときは、もし適切な代わりの通信経路が利用可能であれば、フェイルオーバ経路切り替えが実施される。
【００９７】
配信の成功又は障害を示すフィードバックメカニズムをプロトコルが含む場合でも、接続の損失が検出されるまでには遅延がある。ＴＣＰ接続の場合、これは、損失された接続が検出されるまでに数分間を要することがあり、接続が利用可能でないと決定されるまでに再伝送が何度も試行される。デバイスハードウェアの問題又は信号の損失は、少なくとも場合によっては、使用されているプロトコルにかかわらず、デバイスのオペレーティングシステムによって検出可能で尚且つアプリケーションに報告可能である。ハードウェア若しくはデバイスオペレーティングシステムによるエラー報告を通してであれ、又は肯定応答が受信されることなく超過時間が経過することを通してであれ、又は当業者によって一般的になされるその他の何らかの手段によってであれ、接続性の損失は、最終的には認識される。
【００９８】
接続性の損失が発生したとき、デバイスは、送信待ちしているデータ項目を、接続性が回復されるまで保持してもよく、接続性を有する若しくは有するかもしれない別の通信経路に切り替えてもよい。デバイスは、両方を行うこともできる。すなわち、一部のデータ項目を後の伝送のために保持し、それ以外のデータ項目を接続性を有する通信経路を通じて送信してもよい。データ項目を、後の伝送試行のために保持するか、代わりの通信経路を通じて送信するかに関する判断は、データ項目の優先度、代わりの通信経路のコスト、代わりの通信経路の能力、又は当業者によって適切であると判断されるその他の要因などの要因に基づいてなされる。
【００９９】
デバイスは、また、一部の典型的実装形態では、より好ましい通信経路が利用可能になったときに、又は伝送されるべきデータ項目の優先度などの特性が、本来ならば使用のために選択されないであろう通信経路の使用を許可したときなどに、現在の通信経路の可用性の損失を伴うことなく先を見越して通信経路の切り替えを行う。例えば、もしデバイス
が、接続が確立されたときに最も好ましい利用可能な通信経路であったという理由でＧＰＲＳを使用する通信経路によって接続されており、ユーザが、そのデバイスを、より好ましいＷｉ−Ｆｉホットスポットなどの通信経路を利用可能なエリアに移動させた場合は、デバイスは、そのより好ましい方の通信経路を通じて新しい接続を確立し、より好ましくない方の経路を、たとえそれがまだ利用可能であっても終了させることができる。これは、コストの削減、速度若しくは信頼性の向上、又はその他の任意の理由のためになされる。別の典型的実施形態では、もしデータ項目が、（例：構成設定によって決定された）過度の時間にわたって伝送待ちしている場合に、これらのデータ項目の優先度が引き上げられる。待機中のデータ項目の優先度の値が新しくされた結果、当初は選択されなかった代わりの通信経路が選択され、待機中のデータ項目の伝送を可能にするためにその通信経路への切り替えがなされる。
【０１００】
デバイスの構成に基づく許容可能な通信経路がないゆえに、利用可能な通信経路が存在しない場面では、伝送されるべきデータ項目の優先度の変更、デバイスの通信経路構成設定の変更、通信経路若しくは送信されるべきデータ項目に関連付けられたセキュリティ規定の変更、又はこれまでは許容可能でなかった通信経路を許容可能にするその他の変更によって、デバイスは、異なる通信経路からの切り替えを伴うことなく新しい許容可能な通信経路を使用することが可能になる。
【０１０１】
フェイルオーバモードであれ、経路最適化のためであれ、どの代わりの通信経路に切り替えるかの選択時には、同様の要因が関わっている。デバイスは、代わりの通信経路を選ぶために使用される優先度体系を組み込まれて有することができる、又は様々な要因（非限定例として、コスト、速度、信頼性、ユーザプリファレンス、サポートされている特徴（プッシュモードなど）、若しくは転送されるべきデータ項目の数及びタイプなど）をバランスさせるためのルールを使用して動的にそれを行うことができる、又はユーザに選択を行うように求めることができる。判定は、一部の典型的実装形態では、デバイスオペレーティングシステムによってなされ、その他の典型的実装形態では、アプリケーションソフトに委ねられる。デバイスオペレーティングシステムが通信経路の判定を行う実装形態では、オペレーティングシステムによってより好ましいとされる通信経路を無効にするようにデバイスの構成設定を変更し、特定の通信経路の使用を推し進めることも可能である。
【０１０２】
考えられる典型的な一実装形態では、コスト、速度、及び信頼性などの各通信経路特性には、選択優先度調整値が割り当てられる。選択優先度調整値は、重要な要因の場合は大きく、あまり重要でない要因の場合は小さく、無関係な要因にはゼロ調整値が割り当てられる。調整値を足し合わせることによって、各利用可能通信経路についての選択優先度点数が計算され、望ましい特性の調整値は正として、望ましくない特性の調整値は負としてそれぞれ処理され、最も高い選択優先度点数を持つ（１本又は複数本の）通信経路が使用のために選択される。当業者によく知られている選択優先度点数調整値の適切な選択により、選ばれる通信経路は、所定の通信経路の選択をもしその経路が利用可能であるならば推し進めるために、又は所定の通信経路の使用を阻むために、又は代わりになる経路がない場合以外は所定の通信経路の使用を阻むために、任意の特性又は特徴による影響を最大又は最小にできるように制御される。一部の典型的実装形態では、差し迫った伝送の通信経路の能力又は特性の要件を、利用可能な通信経路の能力と比較するための初期計算が別途なされ、所要の能力をサポートしていないプッシュモードなどの通信経路は、選択優先度点数が計算される前に検討対象から除外される。
【０１０３】
使用のために（１本又は複数本の）通信経路を選択するための典型的な一プロセスが、図５のフローチャートに示される。プロセスは、現時点で利用可能な全ての通信経路を挙げたリストを構築することから開始する（５０００）。一部の典型的なデバイスでは、こ
れは、ＳＭＳ、ＥＤＧＥ、及びＷｉ−Ｆｉなどの、デバイスによってサポートされている全ての通信経路からなる。その他の典型的なデバイスでは、インターフェースが信号を検出しているかどうかを決定し、現時点で信号を受信していないインターフェースを使用している通信経路を除外することが可能である（例：もしテレフォニデータインターフェースが信号を有していない場合は、ＳＭＳ通信経路もＥＤＧＥ通信経路も利用可能でない）。一部の典型的なデバイスでは、Ｗｉ−Ｆｉを通じて既知のＴＣＰ／ＩＰアドレスにＩＣＭＰ「エコー」パケット（「ピング」）を送信して応答を待つなどによって、通信経路の接続性をテストすることが可能である。前述のように、接続性は、１本の通信経路の一部分には存在するがその他の部分には存在せずに、その通信経路の使用を妨げることがある。例えば、サービスプロバイダに送信されたＷｉ−Ｆｉ信号及び「ピング」に対する応答の検出は、Ｗｉ−Ｆｉを通じてサーバ又は他のデバイスに到達可能であることを意味しない。現時点で利用可能な通信経路のリストを作成するにあたり、デバイスは、利用可能でないと確実に決定することができない経路も実質的に全て含んでいる。この目的のために、デバイスは、以前伝送されたデータ項目に対する受信確認の欠如ゆえに利用可能でないと同デバイスによって最近決定された通信経路のリストを維持することができる。これは、信号の存在、「ピング」の返信、又はその他の手段によって利用可能であるように見えるが近接過去（recent past）においてデータ項目を転送させるのに失敗した好ましい通信経路を回避する（ここで、「近接過去」は、構成設定によって決定された、又はデバイス若しくはアプリケーションソフトに設計によって組み込まれた期間である）。このような通信経路の検討対象からの除外は、本来であれば選ばれないであろう好ましさは劣るがより有用である可能性のある通信経路の選択を可能にする。
【０１０４】
待機データの伝送に有用であるために求められるセキュリティ規定特性を保持していない通信経路は、通信経路の選択の目的上、利用可能でないと見なされる。経路選択の目的がプルモードセッションの実施（例：待機データ又は待機メッセージを求めてサーバをポーリングすること）にあるときは、セキュリティ規定特性は、通信経路の除外には使用されないが、一部の典型的実装形態では、一部の通信経路をその他の通信経路よりも好ましいものとして扱うために使用される（例：セキュリティレベルの高い経路をセキュリティレベルの低い経路よりも好ましいものとする）。
【０１０５】
もし利用可能な通信経路がリストに含まれない場合（５０１０）は、プロセスは、「利用可能な経路無し」の結果で終了する（５０２０）。この場合、デバイスは、現時点及び現場所では通信することができない。一部の典型的なデバイスは、更なる通信経路を利用可能な場所にユーザがデバイスを移動させることができるように、ユーザにこの状況について警告することができる。典型的なデバイスは、また、利用可能な通信経路が現れるまで選択プロセスを定期的に繰り返すこともできる。
【０１０６】
もし利用可能通信経路のリストが、少なくとも１本の通信経路を含む場合は、選択プロセスの次のステップは、全ての所要の能力をサポートしていない通信経路を全てリストから外すことである（５０３０）。例えば、もしプッシュモード伝送が求められる場合は、プッシュモードをサポートしていないどの通信経路も利用可能通信経路のリストから排除される。このような通信経路の除外が完了したら、そのリストが少なくとも１本の通信経路を含むかどうかが再チェックされる（５０４０）。もし含まない場合は、プロセスは、「利用可能な経路無し」の結果で終了する（５０２０）。所要の能力に欠ける通信経路を除外した結果、ちょうど所要の本数（これは、通常は１本であるが、一部の典型的なデバイスは一度に２本以上の通信経路を使用することがあり、したがって、複数本の通信経路の選択を求めることがある）の通信経路がリストに含まれるようになった場合、経路のリストは返され、プロセスは完了する。
【０１０７】
もし利用可能通信経路のリストが、所要よりも多い本数の利用可能通信経路を含む場合
は、そのリストのなかから（１本又は複数本の）最も好ましい経路を選択する必要がある。典型的な一実施形態では、リスト中の各経路は、初期選択優先度値であるゼロを与えられる。各経路の選択優先度値は、次いで、経路に関連した望ましくない特性ごとに、その特性について構成設定によって決定された量だけ下方調整される（５０７０）。例えば、もし低帯域幅が望ましくないと見なされ、調整値３を有する場合は、選択優先度値は、低帯域幅という特性を有するリスト中の全ての通信経路について３だけ減少される。選択優先度値は、符号付きの数字であり、負であってもよい。選択優先度のこのような減少は、もしそれぞれ３及び５の調整値を持つ低帯域幅及び非信頼性の両方が望ましくないと見なされる場合、低帯域幅を有する非信頼性の通信経路（例：ＳＭＳ）はその選択優先度値を８だけ減少されるという意味で、蓄積的でもある。
【０１０８】
選択優先度値は、次いで、経路に関連した望ましい特性ごとに、その特性について構成設定によって決定された量だけ上方調整される（５０８０）。例えば、低コストが望ましいと見なされ、調整値６を有する場合、選択優先度値は、低コストという特性を有するリスト中の全ての通信経路について６だけ増加される。選択優先度のこのような増加は、もしそれぞれ６及び４の調整値を持つ低コスト及び高帯域幅の両方が望ましいと見なされる場合、低コスト及び高帯域幅を有する通信経路（例：Ｗｉ−Ｆｉ）はその選択優先度値を１０だけ増加されるという意味で、蓄積的でもある。
【０１０９】
代案として今述べられた選択優先度調整は、当業者にならば明らかなように、一部の典型的実装形態では、符号付きの調整値を使用して１つのステップとして実施される。
【０１１０】
選択優先度調整が完了したら、最も高い選択優先度値を持つ（１本又は複数本の）通信経路が選択されて（５０９０）返され（５０６０）、プロセスは完了する。
【０１１１】
構成に含ませる特性の選択、所定のデバイスによってサポートされる各通信方法に対する特性の割り当て、並びに各特性について選択される優先度の増加値及び減少値は、様々な状況下における通信経路に対するプリファレンスを必要なだけいくらでも調整するために使用することができる。代表的な場面の一例に、３つの通信方法：ＧＰＲＳ、Ｗｉ−Ｆｉ、及びＢｌｕｅｔｏｏｔｈに対応可能なデバイスが、ＧＰＲＳ（ＴＣＰ／ＩＰ及びＳＭＳの両プロトコル）並びにＷｉ−Ｆｉの両方を利用可能であるがＢｌｕｅｔｏｏｔｈは利用可能でない主要都市の公共のＷｉ−Ｆｉホットスポットに位置している場合がある。ユーザは、デバイス設定を、高帯域幅（−１０、＋３）、低伝送遅延（−１、＋５）、及び低コスト（−１、＋１）を好むように構成しており、これは、もし通信経路が低帯域幅を有するならば優先度が１０だけ減少され、もし高帯域幅を有するならば優先度が３だけ増加され、伝送遅延及びコストについても同様の調整がなされることを意味する。ＧＰＲＳ−ＴＣＰ／ＩＰは、低帯域幅、低伝送遅延、及び高コストを有するものとして構成される。ＧＰＲＳ−ＳＭＳは、低帯域幅、高伝送遅延、及び高コストを有するもとして構成される。Ｗｉ−Ｆｉは、高帯域幅、低伝送遅延、及び低コストを有するものとして構成される。Ｂｌｕｅｔｏｏｔｈは利用可能でないので、その構成は無関係である。どちらの利用可能通信経路も、同じセキュリティ規定特性を有するので、これは、それらの間で判定を下すための関連要因ではない。デバイスは、現時点ではプッシュモードを必要としておらず、したがって、この能力に対するサポートの欠如もまた、無関係である。計算は、各方法について以下の点数：ＧＰＲＳ−ＴＣＰ／ＩＰ（−６）、ＧＰＲＳ−ＳＭＳ（−１２）、及びＷｉ−Ｆｉ（＋９）を得た。Ｗｉ−Ｆｉ通信経路が、使用のために選択される。
【０１１２】
考えられる別の典型的な実装形態では、通信経路についてのプリファレンス点数の合計が、その通信経路が使用されるための指定の合計数を超えていなければならず、送信されるべきデータ項目の優先度又は最後の接続から経過した時間が、別の要因として合計点数に追加される。このようにすると、十分な必要性があり（例：優先度の高いデータ項目が
待機している又は所定の時間内に更新を探してポーリングする必要がある）尚且つより良い利用可能通信経路がない場合に、普通の状況下で使用するにはコストが高すぎる通信経路が使用のために選択される。一部の典型的な実装形態では、データ項目優先度は、データ項目のタイプによって異なってよい。例えば、要求に対するユーザの応答が、緊急警報の通知もそうであるように、非常に高い優先度を与えられるであろう一方で、画像データ項目を先取りするための要求又は所定のノード群が利用可能な更新を有するかどうかをチェックするための要求は、より低い優先度を与えられると考えられる。典型的な一実装形態では、優先度値は、ノードタイプに関連付けられ、別の典型的な実装形態では、優先度は、データ項目が伝送のためにサブミットされる時点で送信ソフトによって指定される、又はデータ項目を含むノードの自己記述データの一部としてデータ項目自体に記録される、又は当業者によって適切だと判断されるその他のやり方で処理される。
【０１１３】
代替の典型的な実施形態では、最も好ましい１本又は複数本の通信経路の選択は、上述のようにはなされず、例えば、目標探索ルールベースシステム、推論法、ニューラルネットワーク、及び通信経路の利用可能性、ユーザの選択、又はその他のデータなどに関する履歴データを使用したパターン認識法など、人工知能手法を伴うなどの、より複雑な方法を使用して実施される。これらの又はその他の方法の組み合わせもまた、使用することができる。このタイプの典型的な方法は、「プリファレンス関数」の使用を伴う。「プリファレンス関数」は、保留中の各データ項目について、それが各利用可能通信経路を通じて送信された場合の「プリファレンス値」を計算するように実装される。プリファレンス関数は、利用可能通信経路の能力、送信されるべきデータ項目のサイズ、データ項目の優先度、利用可能通信経路の伝送時間遅延の最新履歴、通信経路のコスト（一部の場面では、これは、場所、時間帯、データ項目のサイズ、所定の時間内に送信されたデータの合計、若しくはその他の要因に応じて調整可能である）を記述したパラメータ、又は当業者によく理解されるその他のパラメータを使用する。データ項目と通信経路との各組み合わせについてプリファレンス値を計算した後、算出されたプリファレンス値が指定の閾値を超える任意の通信経路が、関連のデータ項目を送信するために選択される。プリファレンス値は、その計算に使用されるパラメータの変化に伴って再計算される。この方法は、コスト、速度、伝送遅延、又はその他などの選択された要因を最適化することができるように、指定の時間に特定のデータ項目を送信するのにどの１本又は複数本の通信経路が好ましいかに関する判定に到達するために任意の数の異なる要因を組み合わせることを可能にする。この方法は、上述のような単純な重み付け係数よりも複雑なプリファレンス関数の使用を可能にする。計算されたプリファレンス値を他の閾値と比較することによって、この方法は、データ項目をどのように送信するかのみならず、データ項目をいつ帯域外送信するかなどのその他の判断を解決するためにも使用することができる。
【０１１４】
代わりの通信経路が選択されたら、その経路を通じて通信を確立しなければならない。接続のないＳＭＳなどの一部の通信経路の場合、これは、今後の伝送に新しい通信経路を使用する問題に過ぎないが、場合によっては、通信経路のフォーマット制約に適合させるためにデータ項目の再フォーマットが必要になることがある。データ項目の送信に先立つ接続の確立に依存するその他の通信経路の場合、通信経路の切り替えは、データ項目が送信される前に新しい接続が確立されていることを必要とする。一部のデバイスでは、このタスクは、デバイスオペレーティングシステムによって、アプリケーションソフトに対して透過的に処理される。その他のデバイス実装形態では、アプリケーションソフトがこのタスクを扱うように求められる。いずれの場合も、アプリケーションソフトは、データ項目伝送の再開前に、認証データの提供又はセッションコンテキストの再確立などのハンドシェーキングタスクを完了させるように求められる。
【０１１５】
一部の実施形態では、アプリケーションによる通信経路の切り替えを生じさせるために使用されるメカニズムは、典型的なデバイスの設計によって決定される。現時点で、様々
なデバイスメーカによって様々な方法が使用されており、将来のデバイスでは、更なる方法が可能であるとともに期待できる。Ｂｌａｃｋｂｅｒｒｙなどの一部の典型的なデバイスでは、アプリケーションは、接続されているデバイスのアドレス（ＵＲＬ）にパラメータを付加し、これを接続対象の「オープン」メソッドに引き渡すことによって、所定の接続のために使用されるべき通信経路を指定する。このようなデバイス上で通信経路を切り替えるには、アプリケーションは、既存の接続を閉じて、代わりの通信経路を指定する異なるパラメータを使用して新しい接続を開く。その他の典型的なデバイスでは、デバイスによってサポートされている各通信方法に対して異なる接続方法が使用され、アプリケーションソフトは、既存の通信経路が必要としていた方法を使用してその接続を閉じ、新しい通信経路が必要とする方法を使用してその上に新しい接続を開くことができる。更にその他の典型的なデバイス実装形態では、通信経路の選択は、物理的制御又はオペレーティングシステムユーティリティソフトを通じたデバイスユーザによる制御下にあり、アプリケーションソフトは、ユーザとやり取りして、異なる通信経路への変更を要求しなければならない。
【０１１６】
機能性の損失なく任意の適切な通信経路を通じてメッセージ及びメッセージセグメントを送信するための、並びにセグメント化されたメッセージの送信の途中でプロセスの中断なく通信経路の切り替えを行うための能力は、デバイスが、最速の利用可能通信経路を常時選択することによってスループットを最大に且つ応答遅延を最小にすること、使用中の通信経路が接続性を損失したときに代わりの通信経路にフェイルオーバすることによって信頼性を向上させること、送信されているデータ項目のタイプに適した通信経路を選択することによってコストを最小に抑えること、並びに例えばプッシュモードが求められ、全ての利用可能通信経路がこの動作方法をサポートしているのではないときなどに、通信経路の能力に基づく通信経路の選択及び使用を可能にすることによって機能性を向上させることを可能にする。
【０１１７】
［複数経路データルーティング］
一部の典型的なデバイス実装形態では、一度に２本以上の通信経路を使用することが可能である。例えば、デバイスは、データ項目をＷｉ−Ｆｉを通じて交換しつつＳＭＳを送信若しくは受信することができる、又は有線Ｅｔｈｅｒｎｅｔポートを通して接続しつつＢｌｕｅｔｏｏｔｈリンクによってデータ項目を転送することができる。１本の通信経路の使用についての上述された問題及び解決策は、接続性を損失したときの通信経路の切り替えや、利用可能な選択肢から適切な通信経路を選択する方法などを含むが、これら全ては複数の通信経路の使用にも当てはまる。複数の通信経路の使用は、しかしながら、更なる能力と、検討されなければならない更なる問題とをもたらす。
【０１１８】
複数の通信経路を同時に使用すると、全ての利用可能な通信経路を通じてデータ項目が送信されるので、デバイスの総帯域幅が増す。受信システム上のノード蓄積部は、損なわれずに到着する全てのデータ項目を保存しつつ、あらゆる重複を排除し、通ってきた通信経路に関係なくそれらを合体させる。ひとたび受信されれば、ノード構造又はコンテンツに違いはないので、所定のデータ項目がどの通信経路を通して送信されたかで違いはなく、通信経路が時間の経過とともに接続性を損失したり獲得しても、メッセージは接続性を維持するとともに、特性についての要件、優先度の要件、又は本明細書に記載されるその他の要因を満足させる他の任意の通信経路を通じて送受信され続けることができる。
【０１１９】
送信デバイスは、各通信経路を通してどのデータ項目を送信するかを選択するために、幾つかの異なる手続きを使用することができる。考えられる手続きの例は以下の通りである。空きができてデータ項目を受け入れ可能になった第１の通信経路を通じて次のデータ項目を１つずつ列にして送信する。データ項目の特性を通信経路の特性と一致させる（例：大きいデータ項目を高帯域幅通路を通じて送信して小さいデータ項目を低帯域幅通路を
通じて送信する、若しくはプッシュモードで送信されなければならないデータ項目を、プッシュモードをサポートしていない通信経路ではなくプッシュモードをサポートしている通信経路を通じて送信する）。優先度の最も高いデータ項目を優先度の低いデータ項目よりも先にして、優先度順にデータ項目を送信する。プルモード要求に応答して送信されているデータ項目をある通信経路を通じて送信し、別の通信経路をプッシュモード交換のためにとっておく。また、これらの手続き若しくは当業者によって適切だと判断されるその他の手続きの任意の組み合わせ。手続きは、スループットを最大にすること、ユーザに対する応答性を向上させること、コストを最小にすること、アプリケーション開発者にとっての柔軟性を最大にすること、又はこれらの若しくはその他の目的の任意の組み合わせを達成するように選択される。一部の典型的な実装形態では、どの通信経路を使用するかを決定するために、上述された優先度調整方法に基づく方法が使用される。各利用可能通信方法について優先度値が決定されると、設定値を上回る点数を有するものが使用される。設定値を下回るものは使用されない。或いは、設定値を下回る点数を有するものは、通信の必要があり（メッセージが送信待ちしている又は予定されるポーリングの時間である）尚且つより高い点数の利用可能な方法がない事態にならない限り、使用されない。一部の典型的な実装形態では、ユーザは、設定閾値を下回る点数を持つ通信方法の使用を明示的に承認する必要がある。これは、デバイスをＷｉ−Ｆｉホットスポットに移すこと、デバイスを有線Ｅｔｈｅｒｎｅｔに接続すること、又はその他の手段を通して別の通信方法を代わりに利用可能にする機会を提供する。
【０１２０】
全ての利用可能通信経路が、信頼性がなかったり配信の発生までに時折大きな遅延を伴ったりする傾向が場合は、配信の機会を最大限にするため及び配信の発生までの時間を最短にするために、同じデータ項目を２本以上の通信経路を通じて送信することができる。この場面では重複配信が起こり得るが、上述された重複の検出及び取り扱いの手続きがこの問題を処理し、これらの重複を保存前に排除する。一部の典型的な実装形態では、このようなデータ項目の重複送信は、優先度の高いデータ項目に限られ、より優先度の低いデータ項目は、１本の通信経路を通じてのみ送信され、アプリケーションレベルのプロトコルが、損失された又は破壊されたデータ項目を上述のようなやり方で処理する。
【０１２１】
デバイスの例
図６は、図１に提示された典型的なアーキテクチャのような通信システムアーキテクチャと適合可能なデバイスの通信部分の典型的で非限定的な実装形態を示しており、第１のデバイス（６０００）は、特定の通信経路インスタンス（６７１０、６７２０）を通して１つ又は複数の他のデバイス（６６１０、６６２０）と通信する。このような各デバイスは、一連の利用可能通信技術の少なくとも１つにアクセス可能な１つ又は複数の通信インターフェース（６３００ａ、６３００ｂ）を含む。典型的なデバイスは、更に、少なくとも１つのプロトコルマネージャ（６２１０ａ、６２１０ｂ）を更に含むディスパッチマネージャ（６２２０）と、少なくとも１つのセッションマネージャ（６２００）と、ノード蓄積・キャッシュ部（６５００）とを含む。プロトコルマネージャは、通信インターフェース（６３００ａ、６３００ｂ）によって使用される通信技術の実装形態によって必要とされるとおりにデータ項目のフォーマット及びコンテンツを変更するために、デバイス上に提供される。デバイス６０００は、コンピュータプログラムコードデバイス（本明細書では「ノード」と称される）を使用して指定のアプリケーションタスクを処理し、これらのタスクは、第２のデバイス上における受信及び処理のために第１のデバイスから伝送されるように構成される。
【０１２２】
［セッションマネージャ］
セッションマネージャコンポーネントは、プロトコルマネージャのアクティビティを管理し、他のデバイスからの接続を受け入れるかどうか、データ項目をどのようにルーティングするかに関する判定を下し、関連の機能性をデバイスに提供する。
【０１２３】
デバイスの典型的で非限定的な実装形態が複数の通信経路の使用をサポートしているときは、利用可能なもののなかから使用のために１本又は複数本の通信経路を選択するメカニズムがセッションマネージャの一部として供給される。これは、本明細書では「選択アルゴリズム」と称される。各通信経路の特性を選択アルゴリズムが使用して、１本又は複数本の通信経路の使用を好ましいものとして確立し、またその他の（１本又は複数本の）特定の通信経路の使用を回避する。選択アルゴリズムは、また、好ましい１本又は複数本の通信経路を選択する際の要因として、優先度、サイズ、又は伝送を待機している時間などの、送信されるべきメッセージの特性も使用することができる。例えば、ビデオクリップなどの非常に大きいメッセージが送信されるときは、ＳＭＳ又はＭＭＳなどの帯域幅の限られた通信経路を通じてではなく、Ｗｉ−Ｆｉなどの帯域幅の大きい通信経路を通じてメッセージを送信することが好ましい。一方の通信経路が固定費用で使い放題である一方で、他方の通信経路が伝送ごとに料金を課す場合は、固定費用の経路を優先的に使用し、伝送ごとに課金される経路は、固定費用の経路が利用可能でないときにのみ使用する、又は伝送ごとに課金される経路の使用を完全に回避する、又はその使用を優先度の高いメッセージだけに制限することが望ましい。プッシュモード伝送が必要とされる別の例では、このモードをサポートしている通信経路が使用されなくてはならず、実装方式ゆえにこのモードをサポートすることができない通信経路は使用することができない。場合によっては、複数通信経路を協調プッシュモードで使用すると有利であり、この場合は、プッシュモードをサポートしているがそれ以外では伝送用として不適切な選択である利用可能通信経路が、協調プッシュモード補助機能を伴った通信要求コマンドを含むメッセージなどの要求を、受け手デバイスに送信するために使用される。この要求メッセージは、要求デバイスがメッセージを伝送することが可能な適切な通信経路を使用して、要求デバイスとのプルモード接続を開始するように、受け手デバイスを促す。
【０１２４】
伝送する１つ又は複数のメッセージをデバイスが有し、しかしながら、使用中の通信経路が何らかの理由で適切でないときは、デバイスは、適切な通信経路が利用可能になるまで（１つ又は複数の）メッセージを保存することができる。もしメッセージの１つ又は複数が十分に高い優先度を有し、現時点では使用されていないが利用可能ではある適切な通信経路があるならば、デバイスは、一部の典型的な実装形態では、通信経路を切り替えて待機メッセージを送信するように構成することができる。一部の典型的な実装形態では、ユーザはできるだけ早く適切な通信経路をサポートして伝送を達成することができる場所にデバイスを移動させるように、ＳＭＳメッセージ又は音声メッセージなどの適切な手段によって要求される。
【０１２５】
一部の典型的な実装形態では、所定の通信経路を使用するかどうかを判断するときのプリファレンス計算に、一部の伝送に関連した優先度が組み込まれる。例えば、優先度の高い伝送は、好ましくない通信経路が唯一の利用可能な経路である場合、又は好ましくない通信経路が特定の伝送に有利な特性（プッシュモードに対するサポートなど）を有する一方でその他の利用可能通信経路がその所要特性を有さない場合に、結果として、その好ましくない通信経路を使用することがある。複数通信経路の同時使用をサポートしているデバイスでは、このような優先度の高い伝送をＯＯＢで行い、優先度の低い伝送は好ましい通信経路を使用したり好ましい通信経路が利用可能になるまで遅延させたりする。伝送優先度値は、構成設定によって、又は伝送の要求時にユーザからの入力によって、又は伝送手続きの設計によって、又は当業者によって適切だと判断されるその他の手段によって確立される。伝送優先度値は、伝送要求を実装する手続きによって、関数パラメータ、参照データ構造、又はその他のよく使用される方法などの手段を通じて伝送に関連付けられる。伝送優先度値は、伝送されるメッセージに組み込まれた優先度値の使用によって、又は優先度値をこのようなメッセージに非直接的な手段を通して（例：優先度の高い伝送を高優先伝送待ち行列に入れ、優先度の低い伝送を低優先伝送待ち行列に入れることによって
）関連付けることによって、又はその他の任意の適切なメカニズムによって運ばれる。
【０１２６】
その他に、所定の通信経路を特定の目的で使用することを不可能にする特性がある。例えば、Ｗｉ−Ｆｉ通信経路の場合、Ｗｉ−Ｆｉサービスを通して接続されるデバイスは、通常、サービスに接続するごとに異なるネットワークアドレスを付与される。したがって、Ｗｉ−Ｆｉ接続デバイスが接続を確立する（プルモード）までそのＷｉ−Ｆｉ接続デバイスにデータ項目を送信することができない。他のデバイスは、それ以外の時間にＷｉ−Ｆｉ接続デバイスに到達するすべがない。しかしながら、ＳＭＳ又はＭＭＳなどの他の通信経路の場合、デバイスは、固定のアドレスを有しており、そのアドレスへのアクセスを有する他の任意のデバイスによって到達する（プッシュモード）ことが可能である。一部の通信経路は、実施されるべき動作がその通信経路によってサポートされている特性を必要とするときは、たとえ他の通信経路のほうが大量のデータ項目伝送に好ましい場合でも使用のために選択されることがある。
【０１２７】
複数の利用可能通信経路があるときは、デバイスは、１本又は複数本を使用のために選択することができ、好ましい１本若しくは複数本の経路が利用可能でなくなったときに（経路損失切り替え）、又はあるときは速度、応答性、コスト、信頼性、若しくはその他の各種の通信特質を最適化するために（最適化切り替え）、通信経路間で切り替えを行うことができる。経路損失を検出するため及び好ましい経路を決定するためなどの幾つかの典型的な方法の詳細な説明が、以下で提供される。
【０１２８】
通信経路を個別に使用したのでは実施が不可能だと考えられる特定の動作を実行するために、異なる複数の通信経路を共同で使用することができる。典型的で例示的な一実装形態では、デバイスは、Ｗｉ−Ｆｉ及びＳＭＳの両能力を有する。Ｗｉ−Ｆｉ接続性は、大帯域幅を有し、固定費用でデータを転送し放題であるが、「ホットスポット」と呼ばれる局所的な領域内でのみ尚且つモバイルクライアントデバイスが接続を開始させる必要がある「プルモード」でのみ動作する。ＳＭＳ接続性は、小帯域幅を有し、伝送ごとに費用を課されるが、より広範囲のサービス可用性を有し、サーバ又はクライアントが通信を開始させることができる「プッシュモード」で動作することができる。クライアントデバイスが接続されておらず、尚且つ普通は接続を開始させないと考えられるときに、そのクライアントデバイスにサーバデバイスがデータ項目を転送する必要がある状況では、サーバデバイスは、ＳＭＳを使用して、コマンドを含むメッセージをプッシュモードでクライアントに送信することができ、すると、クライアントデバイスは、Ｗｉ−Ｆｉを通じてサーバへのＯＯＢ接続を開始させる。Ｗｉ−Ｆｉは、次いで、より高速で且つより安価なＷｉ−Ｆｉ接続を通じてデータ項目を転送するために使用される。一部の典型的な実装形態では、ＳＭＳ通信経路を通じてメッセージが送信された結果、ユーザは、もしデバイスがまだＷｉ−Ｆｉホットスポットにない場合にデバイスをＷｉ−Ｆｉサービスを利用可能な場所に移動させるように要求されることがある。
【０１２９】
プッシュモードは、また、一部の典型的で例示的な実装形態では、告知及び受け入れ（Ａ＆Ａ）を実装するためにも使用される。Ａ＆Ａは、実施されるべきタスクがあり、そのタスクを実施可能であると考えられるユーザが複数あり、しかしながら、どの（１人又は複数人の）ユーザが対応可能で、その意思があり、尚且つその能力があるかがわからないときのプロセスである。プロセスは、場所、職務、名前、又はその他の手段に起因してタスクを実施する有力候補として選ばれた１人又は複数人のユーザに関連付けられた１つ又は複数のデバイスに告知メッセージを送信すること、ユーザ応答を収集すること、それらを要求サーバに返すこと、及びタスクの実施に対して肯定的に応答するもののなかから１人又は複数人を選ぶことを含む。タスクの実施は、更なるＡ＆Ａやり取り、１つ若しくは複数のタスクに関連付けられたデータ項目をダウンロードすること、デバイス上に既に存在しているプリキャッシュデータ項目を使用すること、又はその他のプロセスを含むこと
ができる。
【０１３０】
一部の典型的で例示的な実装形態では、正常機能は、デバイスからサーバデバイスに対するポーリングを、定期的に、又は更新されたデータ項目を要求したり応答ノードを送信したりする必要があるとき随時に、又はデバイスが特定種類の通信経路の利用可能性を検出したときに、行うことを含む。例えば、１０分に一度、又はユーザが伝送するべきデータ項目を入力するとき随時に、又は利用可能なＷｉ−Ｆｉ通信経路があるとき随時になどである。これは、大半の状況では十分であるが、なかには、デバイスがサーバに接続されていないときにこのデバイスに対して送信する必要のあるデータ項目をサーバデバイスが有しているときや、デバイスに転送するべきデータ項目又はその他のデータを第２の非サーバデバイスが有している（Ｐ２Ｐ）ときがある。例えば、カタログのデータ項目が変更されたときや、監督者のデバイスが一連のノードで表わされたタスクを有し、再割り当てのためにそれを作業員のデバイスに転送しなければならないときなどのように、デバイスに事前に送信されているノードの更新ヴァージョンが利用可能であって、尚且つその更新ヴァージョンのノードをできるだけ早く取得できるようにデバイスが同期化される必要があるときなどがある。このような状況では、プッシュモードの使用が求められるが、プッシュモードを上述のように使用してプルモード接続をトリガすることは、可能でない又は最適でないことがある。例えば、もし、プルモード接続のために使用するように設定されたどの通信経路も利用可能でない場合は、デバイスは、このような通信経路が利用可能になるまでトリガに対する応答を遅延させることがある。デバイスを同期化する必要性が緊急であるとき、又はプルモードが更新ヴァージョンのノードなしでは機能できない（例：注文書の価格情報を更新する若しくはサーバアドレス情報が変更された）場合、更新を必要とするノードは、プッシュモード又は協調プッシュモードで送信される。この伝送は、コストの増加又はデータ項目の伝送に要する時間にかかわらず、このような転送のために優先的に使用されていた以外の通信経路を通じて（例：Ｗｉ−Ｆｉ又はＢｌｕｅｔｏｏｔｈではなくＳＭＳ又はＭＭＳを通じて）行うことができる。
【０１３１】
一部の典型的な実装形態では、デバイスは、一度に１つの所定のタイプの通信経路を通じた単一の接続に限られており、異なる通信経路を使用するＯＯＢ伝送の使用は、更なる接続を実装するため又は全帯域幅を増やすために使用される。一部の通信経路は、伝送中に許容できない遅延を含む又は信頼性が低く若しくは断続的になりえるので、場合によっては、所定のデータ項目を幾本かの通信経路によって一挙に送信することが望ましいとされる。このような冗長性（redundancy）は、レシーバにおいてデータ項目が適時に受信される機会を増やすが、伝送を重複させる可能性もある。ノードは、一意のノードＩＤ及びヴァージョン情報を有するので、レシーバは、このような重複を認識して廃棄したり、伝送が遅れた期限切れのノードを認識して廃棄したりすることができる。
【０１３２】
メッセージ又はメッセージセグメントを交換するためには、デバイスが有していなければならない情報は、どの通信経路がサポートされているかに関する情報、どの受け手指定情報を提供するかに関する情報であり、更に、一部の典型的な実装形態では、認証証明、暗号化キー、ポーリング予定、又は通信経路へのアクセスを得て、対象とされる受け手へデータ項目をルーティングし、それらを所要の形態で送信するために必要とされるその他の情報も有していなければならない。デバイスは、そのメーカ、ユーザ、又はその他によって、少なくとも１つのサーバに接続すること並びにそのサーバとデータ項目及びコマンドを交換することを可能にする十分な情報を持つように、初期構成される。随意として、デバイスは、更なる初期構成情報を持つように構成される。デバイスは、他のデバイスとデータ項目を交換するために必要とされる情報を指定する更なる通信構成情報を、（１つ又は複数の）初期構成されたサーバから、そしてその後は上記他のデバイスから取得することができる。取得される更なる情報としては、デバイスＩＤ、デバイスユーザ名、他のデバイスによってサポートされている通信経路、ＴＣＰ／ＩＰアドレス、携帯電話番号、
若しくはＢｌｕｅｔｏｏｔｈデバイス情報などのデータルーティング情報、Ｗｉ−Ｆｉホットスポットログインアカウント及びパスワード情報などの認証情報、ＳＭＳ、ＤＮＳ、若しくはｅ−ｍａｉｌなどサービスのためのサーバアドレス、予定されるポーリング間隔若しくは時間データ、通信経路プリファレンス構成データ、伝送待機中のデータの優先度に基づいて通信経路の使用を調整するために使用されるデータ優先度構成データ、又はデバイス間の通信に関連したその他の情報が挙げられる。
【０１３３】
［プロトコルマネージャ］
伝送及び受信に関する上記の説明では、典型的で例示的で非限定的な現実装形態の典型的なプロトコルマネージャによる処理について言及されている。プロトコルマネージャは、伝送されるデータ項目に対して通信経路に特有な変更を加えるため及び受信の際にそれらの変更を元に戻すために使用される。変更は、データ表現、メッセージサイズ、又は伝送されるデータ項目のその他の特性に対する制限に対処するために、一部の通信経路にとって必要である。
【０１３４】
図７は、ディスパッチマネージャによって伝送されているデータ項目に対してプロトコルマネージャによってなされる処理を示したフローチャートである。ディスパッチマネージャは、伝送されるデータを含むデータブロックをプロトコルマネージャに引き渡す（７０００）。プロトコルマネージャは、プロトコルマネージャによってサポートされている通信経路との適合性についてデータバイトをチェックする（０７１０）。
【０１３５】
適合していない場合（７０２０）、データブロックは、その不適合性を取り除くために符号化される。データを符号化する方法は、当業者によく知られており、問題のあるバイトを「エスケープ」する、すなわち、タグバイトを使用して問題のあるバイトの位置を識別し、問題のあるバイトの値を特定する適合するバイトで置き換えるなどの技術がある。
【０１３６】
結果として得られたデータブロックが、プロトコルマネージャに関連付けられた通信経路を通じて一度に伝送するには大きすぎる場合（７０４０）、データブロックは、受け手のプロトコルマネージャによる元のデータブロックへの再構築を可能にするセグメントヘッダデータの追加した後でも、通信経路の最大伝送単位サイズを超えないような、複数のセグメントに分割される（７０３０）。
【０１３７】
送信するセグメント又はデータブロックが残っている間（７０６０）は、それらを送信し（７０５０）、その後は、プロセスは終了し、ディスパッチマネージャに制御を返される。
【０１３８】
図８は、受け手のセッションマネージャによるデータ項目の処理に使用されているときのプロトコルマネージャによってなされる処理を示したフローチャートである。プロトコルマネージャは、通信インターフェースを通して受信された状態でメッセージ又はメッセージセグメントを与えられる（８０００）。より大きいメッセージの一セグメントを与えられた場合（８０１０）、プロトコルマネージャは、そのセグメントをメッセージバッファに加え、それを、これまでに受信された同じメッセージのセグメントに関連付ける（８０２０）。
【０１３９】
完全なメッセージが受信されたがゆえに、又はより大きいメッセージの全てのセグメントが受信されたがゆえに、完全なメッセージが得られた場合（８０３０）、プロトコルマネージャは、問題のあるデータバイトの符号化、圧縮、暗号化、又はその他など、送り手のプロトコルマネージャによってなされたあらゆる伝送変更を排除して、元のデータブロックを復元する（８０４０）。このデータブロックは、通信経路に依存しない更なる処理のためにディスパッチマネージャに引き渡され、プロセスは終了する。
【０１４０】
データ項目は、受信された後、重複ノードを除外するためにチェックされ、もし（本明細書で説明されるように）唯一である又は既存ノードに対する更新であるとわかった場合は、デバイスのノード蓄積部（Node Store）に置かれる。これは、データ項目が、任意の利用可能通信経路を通じて又は同時に複数の通信経路を通じて送信されることを可能にし、使用中の又は使用のために利用可能な（１本又は複数本の）通信経路についてディスパッチマネージャ以外のコンポーネントが心得ている必要性を生み出すことなく必要に応じて各種の通信経路間で切り替えを行うことを可能にする。これは、ノード蓄積部及びデータ項目処理コンポーネントの実装を単純にする。
【０１４１】
［ノード蓄積・キャッシュ部］
図６によって示された実施形態に再び言及すると、ノード蓄積部（６５００）は、デバイスに送信されたデータ項目、デバイスから送信されるのを待っているデータ項目、及びデバイスから送信されるのを待っているコマンドの、保存とアクセスとをサポートしている。データ項目は、デバイスに適したフォーマットで保存される。データ項目には、ノードを含むものがある。ノードは、ユーザデータ要素、ユーザインターフェース命令（視覚的な行為又はインタラクティブな行為）、及び実行可能なビジネスロジックを表わすことができる。好ましい典型的で例示的で非限定的な実装形態では、ノード蓄積部は、ノード属性を保存に関連した属性に維持し、暗号化、圧縮、又はその他の保護を加える。
【０１４２】
代替の典型的で例示的で非限定的な一実装形態では、データ項目は、通信ネットワークを通じて転送される形式と同様のフラットファイル内に（ただし、セグメント化、特殊な文字処理、圧縮、又は暗号化フィルタリングを施されずに）ＡＳＣＩＩ文字列として保存される。この典型的で例示的で非限定的な実装形態では、フラットファイルは、特定のノード又はノード内の特定のフィールドを突き止める又は置き換えるために、順次検索される。代替の典型的で例示的で非限定的な実装形態では、ノードは、ノード識別子によって索引を付けられてデータベースに保存される。好ましくは、データ項目のキャッシュは、ノードであれ又はその他のタイプのデータ項目であれ、このモジュールによってサポートされている動作のパフォーマンスを向上させるためにローカルメモリ内に維持される。
【０１４３】
保存のフォーマットにかかわらず、ノード蓄積モジュールは、ディスパッチモジュール及びディスプレイモジュールからのデータ項目の保存、更新、及びアクセスのためのインターフェースを提供する。好ましくは、このインターフェースによってサポートされる動作は、保存されているノードを新しいノードで置き換えること、ノード群を追加する若しくは置き換えること、ノードを削除すること、特定のノードを得ること、所定のノードの親ノード、次ノード、若しくは子ノードを見つけること、所定のノード内の１つ又は複数のフィールドを得ること、及び所定のノード内の１つ又は複数のフィールドを変更することを含む。
【０１４４】
データ項目は、伝送を待っている間又はデバイスに受信された後、ノード蓄積部内に保持され、ノード蓄積部によって管理される。ノード蓄積部は、ノードの保存、維持、検索、削除、及び管理のために様々な手段を使用することができる。ノード蓄積部内のデータ項目は、そのノード蓄積部内において唯一であり、データ項目のいかなる複製コピーの保存も受け付けられない。データ項目の唯一性は、一部の典型的なシステムでは、各データ項目を構成するノードのノードＩＤ及びノードヴァージョン情報を比較するなどの手段を通して判断される。このような典型的なシステムでは、同一のノードＩＤを持つがノードヴァージョン値が高いノードは、「更新されたノード」と見なされ、一致するノードＩＤを持つがより低いノードヴァージョン値を有するノードに取って代わる。当業者にならば明白なように、ノードの唯一性を比較するその他の手段も実装可能である。
【０１４５】
ノードは、伝送を待っている間、デバイスによる処理を待っている間、デバイスによる後処理の間、又は将来生じ得る使用のために保存されているときも、ノード蓄積部内に保持される。ノード蓄積部は、非限定例として、「フラットファイル」、又はＩＳＡＭファイル、又はリレーショナル若しくはその他のデータベース、又はインメモリデータ構造、又はウェブブラウザ「クッキー」、又はノードのコンテンツ及び論理構造を維持できる方式でノードを保存すること、どのノードが保存されているかを決定すること、並びに必要に応じて特定のノードを検索することを可能にする任意のその他の形式などの、数多くの方式で実装される。ノード蓄積部は、必要な保存及びそのように保存されたノードに対する検索動作を可能にする限り、様々なデバイス上で様々な方式で実装される。ノード蓄積部は、もしデバイスがそのように構成されていれば、同期化データベース技術を使用してデバイス間で共有することができる。
【０１４６】
データ項目は、伝送を待っている間、ノード蓄積部内に保持される。伝送を待つ原因としては、他のデータ項目が先に送信されている（例：他のデータ項目が高い伝送優先度を有する若しくは待ち行列の前の方に入っている）、利用可能な通信経路が遅延データ項目に適していない（例：データ項目が大きく、低い優先度で送信されるべきであるが、利用可能な通信経路は低速で且つ高価である）、利用可能な通信経路がない、データ項目がデバイスポーリング間隔の合間の待ち行列に入っている、又はその他の要因などがある。伝送を待っているデータ項目は、どの通信経路を通じて送信予定であるかにかかわらず、１つのノード蓄積部に保存される。デバイスによって受信されたデータ項目は、どの通信経路を通って到着したかにかかわらず、１つのノード蓄積部内に保存される。ノード蓄積部は、それが含むデータ項目について、保存されているノード自体の一部ではない更なるデータを取り込むことができる。このデータは、特定のデータ項目がどのデバイスに送信される予定か、そのデータ項目のヴァージョンは何か、データ項目がノード蓄積部に入れられたのはいつか、所定のデータ項目が送信された先はどのデバイスであるかおよび送信されたのはいつであるか、成功裏になされなかったデータ項目伝送の試行回数、又は当業者がシステムの機能若しくはその監視にとって妥当で且つ適切だと見なす任意のその他のデータなどの情報を含むことができる。
【０１４７】
モバイルクライアントデバイスは、将来必要とされる見込みがあるデータ項目をデバイスリソースが許す限り多くノード蓄積部内に維持することによって、ユーザに対する応答性を向上させることができる。このような見込みの兆候には、非限定例として、現在使用中のアプリケーションの一部であること、頻繁に使用されるアプリケーションの一部であること、複数のアプリケーションによって必要とされるデータ項目（例：サーバアドレス、企業ロゴ、アドレス帳情報、パーツリスト、価格リスト、請求コードリストなど）を含むこと、又はもし可能ならば保持されることが望ましい旨を示すようにタグ付けされていることなどがある。このようなデータ項目をデバイスのノード蓄積部内に維持することによって、その後の伝送で伝送されなければならないデータ項目の数が減らされ、利用可能な通信経路がない期間中にデバイスが所要の機能を実施できる見込みが高まる。このようなデータ項目を、それらの伝送に最適な通信経路が利用可能なときに伝送することによって、それらを最適でない通信経路を通じてのちに伝送する必要性が回避される。ノード蓄積部は、自身のコンテンツを、経時（aging）、優先順位、待ち行列などの、当業者によく知られているメカニズムを通して管理する。
【０１４８】
特定のデータ項目が特定のデバイスによって必要とされそうだということが、その必要性が現れる前に予測され、そのデバイスが、現時点でその特定のデータ項目の伝送に適した通信経路を利用可能であるときは、一部の典型的な実装形態は、有用である又は必要であると予測されるそれらのデータ項目を、先を見越してデバイスに送信することができる。或いは、デバイスは、適切な通信経路が利用可能でないときに必要とされることを見越してデータ項目を「先取り（pre-fetch）」することができる。このような必要性が予見
される一例は、所定のタスクを定める１つ又は複数のノードによって必要とされる画像、音声、又は書式定義データ項目を送信するときである。データ項目の必要性が予見される別の例は、特定の時間に又は特定の間隔で実施されるタスクのリストを維持するサーバである。データ項目の必要性が予見される更に別の例は、複数のタスクによって必要とされるデータ項目の取得である。このようなサーバは、実施を予定されているタスクを先読みし、それらのタスクの実施に必要とされるデータ項目を、先を見越して予定のデバイスに送信することができる。どれくらいの量のデータをこの方式で扱えるかは、デバイスリソースの限界に制限される可能性があるが、当業者によく知られた代表的なキャッシングアルゴリズムが、デバイスにとって有利に利用可能リソースを管理するために使用される。アルゴリズムの例として、最長時間未使用（Least Recently Used, LRU）法、最短時間未使用（Most Recently Used, MRU）法、最低頻度使用（Least Frequently Used, LFU）法、又は適応性置換キャッシュ（Adaptive Replacement Cache, ARC）法が挙げられる。典型的な実装形態のために選ばれたキャッシング法は、随意として、データ項目を再取得する費用又は難しさ（例：利用可能性に限界がある高帯域幅の通信経路を通じて送信される画像若しくは音声データなどの大ノードｖｓ任意の通信経路を通じて送信される短いテキスト文字列若しくはコマンド）、所定のノードを参照するその他のノードの数、又はその他の要因などの要因を考慮することができる。このような処理によって効率を高められる、コストを削減できる、又はその他の形で有益であり得る更なる例に、複数のグループノードによってリストに挙げられる、又はサーバアドレス、アドレス帳、若しくはその他のデータを含むカタログを形成する、頻繁に使用されるデータ項目又はノードを更新するときがある。
【０１４９】
複数の通信経路を通じて送信されるノードの重複に対処するために、及びその他の目的のために、各ノードは、その構造の一部として定められた一意ＩＤ及びヴァージョン情報を有する。ノードヴァージョン情報は、典型的な実装形態のメッセージフォーマットのＦＤＬヴァージョン情報と混合されるべきでない。ノードヴァージョン情報は、特定のノードが、同じノードＩＤのノードの更新ヴァージョンとして、又は同じノードＩＤのノードと同一であるとして、又は同じノードＩＤのノードに取って代わられるものとして認識されるように、そのノードのヴァージョンを特定する。ノードヴァージョン情報は、一部の典型的な実装形態では、単独であれ、又はサーバ識別子若しくはメーカコードなどのその他の情報との組み合わせとしてであれ、タイムスタンプ、インクリメントする若しくはデクリメントする数値、又はその他の適切な値から成る。一部の典型的な実装形態では、ノードヴァージョン情報は、ノード内の個別のフィールドから成ることができる、又はシリアル番号をユーザ若しくはカタログのＩＤ値と組み合わせた連結などの、ノード内の複数フィールドの組み合わせから成ることができる。デバイスは、ノードを受信するときに、自身のノード蓄積部を検索し、そのノードＩＤを持つノードを既に有しているかどうかを決定することができる。もしそのノードＩＤを持つノードを有していない場合は、新しいノードは重複ではなく、使用に備えて保存される。もしそのノードＩＤを持つノードが既にノード蓄積部内にある場合は、どちらのノードが他方のノードに優先するかを決定するために、ノードのヴァージョン情報が比較され、古い方のノードが削除され、新しい方のノードが使用に備えて保存される。もしノードＩＤ及びヴァージョン情報がともに同じである場合は、これらのノードは同一であり、重複ノードは削除される。ノードを伝送するために使用された通信経路は、この手続きに影響を及ぼさない。ノードの一意性、又はそれが新ヴァージョンに取って代わられたかどうかを決定するために必要とされるのは、ノードをデバイスに転送する方法ではなく、ノードに含まれるデータのみである。もし、１つのノードがＷｉ−Ｆｉを通じて送信された一方で、同じノードの別のコピーがＳＭＳを通して又はＢｌｕｅｔｏｏｔｈリンクを通じて送信された場合、ノードＩＤ及びヴァージョン情報は、依然存在しており、ノードが重複であるかどうか、又はもし同一のノードＩＤを有するならばどちらがどちらに優先するかを決定するために使用される。通信経路の切り替えは、デバイス間におけるデータ項目の移動及び重複する伝送の検出を妨げない。
【０１５０】
ノード蓄積部に入れるステップの前又はそのステップの一環として重複ノードを排除することで、所定のデータ項目を同時に複数の通信経路を通じて伝送して、データ項目を受信デバイスに到達させる際の遅延を、各種の通信経路に生じている現遅延に関するいかなる情報も必要とすることなく減らせることができる。データ項目の送信時に最も伝送遅延が短い通信経路が、そのデータ項目を受信デバイスに到達させ、他の全ての通信経路を通じて伝送されたデータ項目は、到着時に重複として扱われ、無視される。
【０１５１】
ノード蓄積部は、ノード処理に応えて提供されるユーザデータを含む応答ノードを、これらのノードが伝送されるときまで保持するためにも使用される。ノード蓄積部は、このようなデータ項目が伝送を待っている時間を追跡し、もしこの遅延が指定の閾値を超えた場合に、適切な通信経路の欠如についてユーザの注意を喚起することができる。ユーザは、すると、デバイスをホットスポットに移動させる、又は構成設定を変更し、そうでなければ不適切とされる通信経路の使用を可能にする、又はその他の何らかのやり方で接続及びデータ項目の伝送を可能にすることによって、適切な通信経路を用意することができる。或いは、デバイスは、伝送遅延の閾値を超えたときに、１つ又は複数のノードのために代わりの、恐らくはより高価な通信経路を選ぶことなどのその他のアクションをとることができる。
【０１５２】
典型的なノード拡張及びノード追加
典型的で例示的で非限定的な現デバイスのノードの詳細は、米国特許出願第１１／１６９，１４９号に記載されているが、以下のように更なる属性及びタイプを有する。
【０１５３】
典型的で例示的で非限定的な一実装形態は、典型的で例示的で非限定的な現実装形態の更なる目的を達成する必要に応じて、新しいノードタイプを定めるために、又は他の典型的で例示的な実装形態によってこれまでに定められたノードの構造を拡張するために、この能力を活用することができる。例えば、例示的で非限定的な現実装形態の一例は、デバイスに送信され、そのデバイスに、使用中のアプリケーションの通常の流れを中断することなくユーザの照会を行わせるための１つのノードタイプと、ユーザの応答を返させるための第２のノードタイプとを作成することができる。いずれか一方又は両方のノードが、好ましい通信経路を介して帯域内送信される、代わりの通信経路を通じて送信される、又は帯域外通信経路を使用して送信される。このような能力の一用途は、この特定の実装形態によって定められた論理にしたがって、タスクを１人又は複数人の引き受けユーザの予定に入れ、指定の期間内に拒絶した若しくは応答しなかったユーザの予定には入れないことを可能にできるように、タスク告知を、恐らくは複数の通信経路を使用して複数のデバイスに当時にブロードキャストするために、及びタスクを許容可能であるか否かを示す応答を返すために（Ａ＆Ａ）使用される。典型的で例示的で非限定的な実装形態のこの態様の更なる詳細は、以下で見られる。
【０１５４】
［更なる典型的なノード属性］
好ましい典型的で例示的で非限定的な実装形態では、各ノードは、ノードヴァージョン値を特定している。デバイスノード蓄積部内の第２のノードに優先するべき第１のノードは、第２のノードと同じノードＩＤ値と、第２のノードのノードヴァージョン値よりも大きいノードヴァージョン値とを有するべきである。第２のノードが第１のノードに対する更新として作成され、第１のノードを前に受信しているデバイスに送信されたときのように、一デバイス上に両方のノードが存在する状況では、デバイスは、ノードＩＤ及びノードヴァージョン値を比較し、ノードヴァージョン値が大きい方を選んで古い方を削除することによって、どのノードを保存してどのノードを削除するかを決定することができる。所定のノードＩＤを持つ２つ以上のノードが存在するときにどのノードが有効であるかを決定する能力は、伝送遅延を減らすために同時に複数の通信経路を使用してノードが送信
され、２つ以上のコピーがデバイスに送られる状況などで必要とされる。
【０１５５】
典型的で例示的で非限定的な好ましい実装形態は、また、各ノードについてのノード伝送優先度値も含む。ノード伝送優先度の使用は、より高い伝送優先度を有するノードがより低い伝送優先度を有するノードよりも先に送信されるようにノードの伝送順序を調整するため、又はどの通信経路がノードの送信に適しているかを決定することを助けるため、又は伝送優先度の低いノードのみが送信を待っている場合には選択されないであろう通信経路を伝送優先度の高いノードのために使用することを可能にするため、又は伝送優先度の高いノードを同時に複数の通信経路を通じて送信することを可能にするため、又は当業者によって適切だと見なされるその他の目的のためである。一部の典型的な実装形態では、ノードがノード蓄積部に入れられる前に削除されることを保証するために、「ノード削除」ノードがその他のノードに先立って送信されるなど、ノードタイプに基づいて、一部のノードがその他のノードに先立って送信される。これによって、保存能力に限界があるデバイス上におけるリソースの使用が減らされる。このような実装形態では、ノードタイプによる伝送の順序付けが、ノード伝送優先度に基づく順序付けに優先する。
【０１５６】
一部の典型的で例示的で非限定的な実装形態は、各ノードについてのノードキャッシュ優先度値を含む。ノードキャッシュ優先度は、その他の要因が全て等しいときに、どのノードを保持してどのノードを追い出すかを決定するときにノード蓄積部によって検討される材料として使用される。ノードキャッシュ優先度は、このような判定を下すときに検討される唯一の要因である。
【０１５７】
［更なる典型的なノードタイプ］
一部の典型的で例示的で非限定的な実装形態は、「配布リストノード」ノードタイプを含む。これは、デバイスのリスト、すなわちデバイスのカタログへの参照と、各デバイスについての連絡方法のリスト、すなわち各デバイスについての連絡方法を含む１つ又は複数のカタログへの参照とを含む。連絡方法は、各デバイスによってサポートされている通信経路のみならず、そのデバイスと連絡を取るときに通信経路を活用するために必要とされるあらゆる関連アドレス、承認、認証、暗号化、又はその他の情報も含む。随意として、配布リストノードは、リストに挙げているデバイスのユーザに関する情報（例：名前、シフト、職種、監督者の名前など）及び／又はデバイス自体に関する情報（例：デバイスのタイプ、場所など）を含むことができる。配布リストノードは、タスクのデリゲートを特定のデバイス群に制限するとき又はカタログを同期化させるときなど、複数のデバイス及び連絡方法が特定されなければならないあらゆる手続きに有用である。これは、サーバを利用できないＢｌｕｅｔｏｏｔｈ又は「アドホック」Ｗｉ−ＦｉなどのＰ２Ｐ技術を使用してなされるときに、特に当てはまる。
【０１５８】
一部の典型的で非限定的な実装形態は、後述のように、告知及び受け入れの能力を実装するのに有用なノードタイプ「Ａ＆Ａ」を提供する。Ａ＆Ａノードは、サーバのＵＩによって、又はサーバのＵＩ以外の各種のソフトウェアシステムによるＡ＆Ａノードの形成を可能にするように設計されたアプリケーションプログラミングインターフェース（ＡＰＩ）の使用によって作成される。Ａ＆Ａノードは、タスクについてのＦＤＬ規定、若しくはこのような規定への参照、タスクをオファーされるデバイスを含む（配布リストノードの形での）「候補リスト」、必要な受け入れデバイス数の規定、肯定的に応答するデバイスのなかから必要数のデバイスを選ぶために使用される手続きの規定、肯定的に応答するデバイスの数が必要な受け入れデバイス数未満である場合にとられるアクションの規定、及び応答を待つ最長時間の随意規定を含む。Ａ＆Ａノードの処理は、「候補リスト」内の各デバイスに告知メッセージを送信すること、待ち時間が長くなりすぎる場合に随意としてタイムアウトを付けて待ちつつ、その間に、デバイスが自身のユーザに告知を提示し、肯定又は否定の応答を収集し、それをサーバに返すこと、及び必要数の肯定応答デバイスを
選び、選択された各デバイスについてＦＤＬをもとにノードを作成し、結果得られたデータ項目を待ち行列に入れること、又は、肯定応答デバイスの数が必要数より少ない場合に指定のアクションをとることを含む。
【０１５９】
一部の典型的で例示的で非限定的な実装形態は、「カタログ同期化ノード」を含み、これは、第１のデバイス上のカタログのコンテンツを第２のデバイス上のカタログのコンテンツと突き合わせ、両デバイスが同じデータ項目を含むカタログを有し、それらのデータ項目がどちらのデバイスも利用可能な最新のものであるように、違いを解消することを可能にするために使用される。一部の典型的な実装形態は、カタログのコピーを有しており同期化を必要とすると考えられる複数のデバイスを指定するために、配布リストノードをカタログ同期化ノードに関連付けることを可能にする。このような配布リストノードは、ピア・ツー・ピアの手法を通して第１のデバイスが１つ又は複数の第２のデバイスのカタログに同期化することを可能にすることができる。これは、第２のデバイスがサーバへの利用可能通信経路を有さない場面で有用である。
【０１６０】
［典型的なノード構造］
以下の表は、典型的で非限定的な一実装形態によって定義される、ノードの構造を構成するフィールドを説明している。フィールドの説明文が米国特許出願第１１／１６９，１４９号のそれと同一である箇所は、明瞭化を期するために省略されている。以下の各フィールドの説明文には、米国特許出願第１１／１６９，１４９号によって説明された構造又は用途への追加及び拡張のみが含まれている。ただし、前後関係のため、フィールドの名称及びタイプは全て残されている。
【表１Ａ】
2012503449.tif 000003
【表１Ｂ】
2012503449.tif 000004
【表１Ｃ】
2012503449.tif 000005
【０１６１】
典型的なメッセージ拡張
典型的で例示的で非限定的な実装形態は、同時係属米国特許出願第１１／１６９，１４９号に記載されたメッセージタイプ及びメッセージフォーマットはもちろん、以下に記載される更なる能力及び特徴の実装を可能にするための拡張も含んでよい。
【０１６２】
［構成データ］
通信経路、並びにそれらに関連したアドレス、認証、セキュリティ規定、優先度、プリファレンス、及びその他のデータはもちろん、通信又はその他のデバイス行為の特質を制御するために使用されるその他のデータを表わす構成データが、更新デバイス設定メッセージ（タイプ３）を使用して送信される。更新デバイス設定メッセージは、デバイスについての一連のプリファレンス又は構成設定を更新する。このメッセージタイプの各記録は、米国特許出願第１１／１６９，１４９号に記載されたようなフィールドと、以下の更なるパラメータ及び関連属性とを含む。
【０１６３】
パラメータ（２桁の数字）−更新されるパラメータ
・０６−通信経路選択プリファレンス（プリファレンスのＸＭＬ記述を含む文字列として指定される。）
・０７−通信経路特性
・０８−動的経路選択
【０１６４】
値（文字列）−パラメータのための新しい値
【０１６５】
「０６」パラメータに関連付けられた値は、設定又は変更される通信経路選択プリファレンスのＸＭＬ記述を含む文字列を含む。例えば、以下のようである。
【表２】
2012503449.tif 000006
【０１６６】
「０７」パラメータに関連付けられた値は、設定又は変更される通信経路特性のＸＭＬ記述を含む文字列を含む。例えば、以下のようである。
【表３】
2012503449.tif 000007
【０１６７】
「０８」パラメータに関連付けられた値は、もし動的経路選択がアクティブにされるならば「１」を、もし動的経路選択が非アクティブにされるならば「０」を含む文字列を含む。
【０１６８】
更新デバイス設定メッセージの場合は、ディスパッチモジュールは、提供されるデバイス設定を決定し、所定の設定を新しい値に変更する。
【０１６９】
［通信要求］
通信供給メッセージ（タイプ９）は、協調プッシュ、「返信」（ピング）、「接続維持」（キープアライブ）、又はその他などの各種の通信関連アクションが受信デバイスによってとられるように要求するために使用される。通信要求メッセージは、以下の情報フィールドを含んでよい。
・要求タイプ（２桁の数字）−なされている要求のタイプ。
・要求デバイスアドレス（文字列）−要求デバイスのアドレス。
・要求ＩＤ（１２桁の数字）−ＹＹＭＭＤＤＨＨＭＭＳＳフォーマットで表わされる要求の要求元相対ＩＤ。
・要求優先度（３桁の数字）−要求の優先度。ノード伝送優先度に等しい。
・関連データ（文字列）−特定の要求タイプに関連付けられたデータ。
【０１７０】
典型的な実装形態では、要求タイプフィールドは、以下の値の１つを含むことができる。
・０１−協調プッシュ
・０２−ピング要求
・０３−ピング応答
・０４−キープアライブ
【０１７１】
協調プッシュ要求の場合は、要求デバイスアドレスは、要求を送信するために使用される通信経路上の要求デバイスのアドレスを含む。要求ＩＤは、要求が送信された時間である。関連データ文字列は、要求元に到達するために使用することができる各種の通信経路のアドレスのリストと、一部の典型的実装形態では、その通信経路上の要求元のアドレスや使用されるプロトコルなどの、各通信経路についての更なる情報とを含む。
【０１７２】
ピング要求の場合は、要求デバイスアドレスは、要求をなすために使用された通信経路上の要求デバイスのアドレスである。これは、もし可能であれば、応答メッセージを送信するために使用されるアドレス及び通信経路でもある。要求優先度は、通信経路の設定及び選択プリファレンスに応じ、状況によっては一部の通信経路の使用を制限することができる。要求されるアクションは、要求デバイスへのピング応答メッセージの送信である。ピング応答メッセージは、要求タイプがピング応答（「０３」）であること、及び要求デバイスアドレスが応答デバイスであることを除けば、ピング要求メッセージと同じフィールド値を有している。
【０１７３】
キープアライブメッセージは、通信経路がアイドル状態であるゆえに閉じられることのないように維持するために、及び要求デバイスがまだ接続状態にあることを他のデバイスに知らせるために送信される。要求デバイスアドレスは、その他の要求タイプの場合と同様に設定され、その他のフィールドは使用されない。キープアライブ要求メッセージの受け手の側では、接続性を追跡するためにメッセージの受信を記録すること以外のアクションは不要である。
【０１７４】
［タスクデリゲート］
タスクデリゲート（タイプ１０）メッセージボディは、デバイスに依存しない方式で符号化された、１つのタスクに対応する一連の材料を定めている。受信デバイスが、タスクのノードの配置及び順序をタスクデリゲートメッセージに指定されたのと同じに維持しつつ、ノード処理の必要に応じてノードどうしの繋がりを変換することができるように、タスクに相対的に、ノード参照がなされている。
【０１７５】
一部の典型的な実装形態では、タスクデリゲートメッセージのための記録フォーマットは、受信デバイスによって設定されるあらゆるフィールドを排除するように最適化される。特に、CompletionStatusFlagは、常に０（不完全）であることが望ましく、応答テキストは、常に空であることが望ましい。この典型的で例示的で非限定的な実装形態では、利用可能なスペースを最適化できるように、これらのようなフィールドは、通信ネットワークを通じて送信されるメッセージに含まれず、このようなフィールドは、むしろ、デバイスがメッセージを受信した後に、タスクデリゲートメッセージの処理の一環として自動的に挿入される。
【０１７６】
典型的なカタログ同期化
図９に示されるように、カタログ同期化（９２００）は、更新メッセージがサーバから複数のクライアントデバイスに送信されること（９２１０、９２３０）、第１のデバイスと第２のデバイスとの間で送信されること（９２２０）、及びクライアントデバイスからサーバに送信されること（９２４０）を含むことができる。図に示された交換では、サーバは、第２のデバイスと連絡している第１のデバイスにカタログ更新Ａを送信する（９２２０）。サーバは、このＰ２Ｐ接続に気付いていない。カタログ更新Ａメッセージは、第１のデバイス及び第２のデバイスがこの更新を受信すると望ましいことを指定した配布ノードを含む。第１のデバイスは、自身のカタログを更新し、デバイスどうしが同期化された状態であり続けることを保証するために、配布ノードリスト内のその他のデバイス（第２のデバイス）にカタログ更新Ａを送信する（９２２０）。サーバは、第１のデバイスがカタログ更新Ａを受信した元であり、ゆえに、既にその更新を有すると考えられるので、
第１のデバイスは、カタログ更新をサーバには送信しない。一部の典型的な実装形態では、サーバは、配布ノードリストに含まれない。
【０１７７】
一方で、サーバは、カタログ更新Ａを第２のデバイスにも送信している（９２３０）。第２のデバイスに対する更新の重複性は、本文書の他の箇所に記載されたように扱われ、更新の少なくとも１つのコピーが最短の遅延で第２のデバイスに到着することが保証される。
【０１７８】
第２のデバイスは、カタログ更新Ａを受信すると（９２２０又は９２３０）、恐らくは、第２のデバイスのアドレスが最近変更されたゆえに、又は第２のデバイスへの通信経路の可用性が損失されたゆえに、又はその他の何らかの理由ゆえに、更新に含まれるデータ項目が既に無効であることを発見する。第２のデバイスは、カタログ更新Ｂを作成し、それを第１のデバイスに（９２４０）及びサーバに（９２５０）送信する。サーバは、すると、カタログ更新Ｂに含まれる配布ノードにしたがって、カタログ更新Ｂを第１のデバイスに送信する（９２６０）。
【０１７９】
典型的な告知＆受け入れ
Ａ＆Ａは、タスクを実施する候補であるユーザに関連付けられた複数のデバイスに同時にタスク告知を送信すること、それらのユーザからの応答、又は随意として誰が時間制限内に応答したかを収集することからなり、告知されたタスクに対してどのユーザが受け入れる意思及び能力を有するかを決定する。候補ユーザは、タスク作成者によって又は外部システムによって指定され、現在の場所、職種、作業予定、現在のタスク負荷、経験レベル、最近のタスク負荷、タスクの作成者による明示的リスト、又はこれらの若しくは当業者によって適切だと判断されるその他の基準の任意の組み合わせに基づいて特定される。候補ユーザの選択、及びどのデバイスがどの候補ユーザに関連付けられているか（「候補ユーザのデバイス」）の決定は、ノード蓄積部やデータベースなどの所要のデータソースへのアクセスを有する自動システムによって、又はタスクを作成するユーザによってユーザインターフェースを通じて、又はこれらの組み合わせによって実施される。（タスク作成者によって決定された）適切な数だけ肯定的に応答する者が選ばれ、タスクを割り当てられる。プッシュモードは、告知＆受け入れの使用を可能にするためには必要とされないが、全候補に告知を伝送するために必要とされる遅延を減らすことによってプロセスを向上させることができる。
【０１８０】
図１０に示されるように、Ａ＆Ａプロセスは、一部の典型的な実装形態では、サーバのユーザインターフェース（ＵＩ）との相互作用によって、又は規定のアプリケーションプログラムインターフェース（ＡＰＩ）を通した外部プログラム相互作用によって、開始される。相互作用がＵＩによってであれ、ＡＰＩによってであれ、所要の情報が提供される（１００００）。この情報に含まれるのは、割り当てられるべきタスク（例：ＦＤＬ規定、このような規定への参照、若しくはシステム内にハードコードされたタスクへの参照として提供される）、タスクを実施する候補であるユーザの記述であり、タスク告知の送り先となるデバイスを参照するための配布リストノードを作成できるようにそれらのデバイスの識別を可能にする記述、タスクに必要とされるユーザの数、肯定的に応答するユーザのなかから必要数のユーザを選ぶために使用される方法、応答が返されるのを待つ随意の最長時間、又は待つのを止める時間、並びに肯定的に応答するユーザの数が必要なユーザ数よりも少ない場合にとるべきアクションである。
【０１８１】
タスクを実施する候補であるユーザを指定するために使用される方法は、選択のためのチェックボックスを伴う従業員リスト、又は職種のプルダウンメニュー、又は場所、職業技能、勤務シフト、経験レベル、若しくはその他などの詳しい要件を指定する各種のフィールドを伴う記入フォーム、又はこれらの方法若しくは当業者によく知られるその他の方
法の任意の組み合わせからなることができる。或いは、Ａ＆Ａ手続きで使用するためにＡＰＩを通して提供されるユーザ及び関連データのリストを作成するために、各種のデータベース、ソフトウェアシステム、及びユーザ相互作用を含む外部システムが使用される。一部の典型的な実装形態では、外部システムは、「発注−作業命令−売掛金」システムなどの完全ビジネス方法の一環としてＡ＆Ａプロセスを自動的に開始及び完了させるために必要とされる全ての入力を提供することができる。
【０１８２】
肯定的に応答するユーザのなかから必要数のユーザを選ぶために使用される方法は、「応答の早い順」、「割り当て済みタスク数の少ない順」、「経験の多い順」、「距離の近い順」、「タスク無し時間の長い順」などの幾つかの自動的な方法のうちの１つとして、又はタスク作成者への肯定応答者リストの提示及びその作成者によってなされる被選択ユーザの入力を含む手動の方法として指定される。肯定応答の数が、Ａ＆Ａプロセスの開始時に指定された必要なユーザの数に等しい場合は、選択は不要であり、応答ユーザは自動的に選ばれる。一部の典型的な実装形態では、これらのユーザの選択を、上述のような手動の方法を使用して確認する必要がある。
【０１８３】
肯定応答ユーザの数が必要なユーザ数よりも少ない場合にとられるべきアクションは、Ａ＆Ａ要求のキャンセル、肯定的に応答した（一人若しくは複数人の）ユーザへのタスクの割り当て、肯定的に応答したユーザ及び適切な選択方法（候補ユーザを選ぶために使用された方法のいずれか）を使用して選ばれた追加ユーザへの割り当て、要求の繰り返し、又はその他の任意の適切なアクションとして指定される。
【０１８４】
図１１の線図に示されるように、必要な情報がサーバに供給されたら（１１０００）、デバイス通知（タイプ２）メッセージが、そのメッセージの優先度に適した通信経路を使用して、全ての被選択候補ユーザデバイスに送信される（１１０１０）。好ましい典型的な実装形態では、このメッセージは、高い優先度を有しており、１本又は複数本の利用可能通信経路によって、できるだけ早く送信される。これには、プッシュモードが好ましいが、プッシュモードが利用できないときは、代わりに協調プッシュモード、又はひいてはプルモードが使用される。サーバは、通知を受けたデバイスからの応答を待つ、又は指定の期限が経過するのを待つ（１１０２０）。
【０１８５】
各受信デバイスのディスプレイマネージャは、デバイスのユーザインターフェース上にメッセージを出現させ、広告されたタスクを受け入れるか否かに関するユーザからの入力を要求することによって、デバイス通知コマンドに応答する。ディスプレイマネージャは、ユーザの応答を収集し、それを、返されるデータ項目の優先度に相応の通信経路及び利用可能な通信経路を使用してサーバに返信する。
【０１８６】
通知を受けた全てのデバイスが応答したら（１１０５０）、又は通知を受けた全てのデバイスが応答する前に指定の期限が経過したら（１１０３０）、受信された肯定応答の数が必要なユーザ数よりも多いかどうかがチェックされる（１１０８０）。もし肯定応答の数が必要なユーザ数を超える場合は、肯定的に応答しているそれらのなかから必要数のユーザを選ぶために、指定の選択アルゴリズムが使用される（１１１００）。もし肯定的に応答しているユーザの数（１１０８０）が必要なユーザ数に等しい場合（１１１１０）は、肯定的に応答しているそれらのユーザが選ばれる（１１１２０）。もし肯定的に応答しているユーザの数が必要なユーザ数未満である場合は、指定のアクションが実施される（１１０９０）。図１０に示されるように、これは、Ａ＆Ａのキャンセル手続き（１００２５）、再度尋ねたらより多くのユーザが肯定的に応答することを期待した要求プロセスの繰り返し（１００３０）、要求されたよりも数が小さいにもかかわらず肯定的に応答したユーザの選択（１００３５）、第三者（管理者若しくは監督者）への通知、又は何らかの適切な手段による追加ユーザの選択の強制を含むことができる。その他の典型的な実装形
態は、当業者にならば自明のように、更なる又は異なるアクションを提供することができる。もしＡ＆Ａ手続きがキャンセルも繰り返しもされなかった場合、選ばれたユーザは指定のタスクを割り当てられ（１００１５）、手続きは完了する。
【０１８７】
再び図１１を参照し、もし指定された選択方法が「応答の早い順」又は対応可能なユーザの必要数のみに依存する別の方法である場合（１１０６０）は、サーバは、必要数のユーザが肯定的に応答するまで待つだけで、それらを選択する（１１０７０）。それ以外の場合は、サーバは、全ての候補ユーザが応答するまで待つ（１１０５０）、又は随意の最長待機時間が経過するまで待つ、又は待ち時間になるまで待つ（１１０３０）のいずれかであり、もし肯定的に応答したユーザの数が必要なユーザ数よりも多い場合（１１０８０）は、そのなかから選択を行い、もし肯定的に応答したユーザの数が必要なユーザ数に等しい場合は、それらのユーザを返し（１１１２０）、又はもし肯定的に応答したユーザの数が不十分である場合は、上記のように、指定のアクションをとる（１１０９０）。
【０１８８】
（一人又は複数人の）ユーザが選ばれたら、それらにタスクが割り当てられる。これは、指定のＦＤＬを使用して、各ユーザに適したデータ項目を作成し、もしそれらのデータ項目がユーザのデバイス上に既にプリキャッシュされていなければ、ユーザのデバイスに伝送するためにそれらのデータ項目を待ち行列に入れることを含む。或いは、タスクを構成する材料を要求するようにユーザのデバイスに促すためのメッセージが送信される。
【０１８９】
図９に戻り、Ａ＆Ａメッセージ交換（９０００）は、サーバから第１のデバイスへのデバイス通知メッセージ（９０１０）と、サーバから第２のデバイスへのデバイス通知メッセージ（９０２０）とを含む。当業者ならば誰でも、デバイス通知メッセージが任意の数のデバイスに送信できること、及びサーバと、第１のデバイスと、第２のデバイスとを伴う最も単純なケースがより多くのデバイスを伴うケースの全ての特質を代表できることが明らかである。第１のデバイス及び第２のデバイスは、デバイス通知メッセージに対するそれぞれのデバイスのユーザ入力を表わす応答をサーバに送信する（９０３０及び９０４０）。図に示された交換では、第２のデバイスは、肯定的に応答する。第１のデバイスは、場面次第で、否定的に応答する、又はデバイス通知メッセージに応答しない、又は許容時間内に応答しない、又は肯定的に応答するがサーバの選択方法によって選ばれない。ノード更新コマンドなどのタスク割り当てメッセージがサーバから第２のデバイスに送信され（９０５０）、Ａ＆Ａ交換は完了する。
【０１９０】
Ａ＆Ａ能力は、特定のサービスアクション（「ポンプ＃１２のフィルタを交換せよ」、「通路６を清掃せよ」、「マシン＃３４の警報に対処せよ」）を要求するため、何らかの任務への志願（「今晩残業する人が必要だ」、「土曜日に作業できる人はいるか？」）を要求するため、情報（「ＭＩＧ溶接機がどこにあるかわかる人？」、「テスト−このメッセージを読める人はいますか？」）を要求するため、又はその他のあらゆる適切な目的のために使用される。
【０１９１】
典型的なタスクデリゲート
一部の場面では、割り当てられたタスクをサーバの介在によって又はよらずに別のデバイスに移行可能にすると有利である。例えば、一部の典型的な実装形態では、監督者にそのグループ用の全てのタスクを割り当てられ、対応可能になった部下にそれらのタスクをデリゲートすることができる、又はサーバに対して有線Ｅｔｈｅｒｎｅｔなどの高信頼性の通信経路を持つデバイスが、Ｐ２Ｐ通信経路を使用してモバイルデバイスにタスクを転送するためにタスクのローカルリポジトリとして機能することができる、又は何らかの理由でタスクを完了させることができない作業員が、完了させることができる同僚にそのタスクを転送することができる。
【０１９２】
一部の典型的な実施形態では、タスクは、複数のユーザ又はデバイスへの順次割り当てを必要とすることがある。例えば、タイムカードの記入などの時間追跡タスクが、作業員に割り当てられることがある。作業員が、働いた時間数を記入することによってタスクの作業員部分を完了させたら、タスクは、検証及び認可のために作業員の監督者に再割り当てされる。もし問題がある場合は、タスクは、修正のために作業員に再割り当てすることができる。このパターンは、監督者がタイムカードを承認し、それをサーバに送り返してタスクを完了させるまで、複数回にわたって繰り返すことができる。タイムカードタスクのプロセスを、サーバを介してなされる一連の異なるタスク（すなわち、「作業員タイムカード記入」タスク、「監督者認可」タスク、随意の「作業員タイムカード修正」タスクなど）として扱うのではなく、タスクデリゲートを使用することによって、認可されたタイムカードデータをサーバに到達させるプロセスをサーバとの連絡にほぼ依存することなく完了させることができる。作業チームが、遠く離れた現場、採掘場、又はデータを完全保護された設備など、十分なサーバ通信能力を持たないエリアで過ごしているときに、デバイス間タスクデリゲートのこの能力は、効率を向上させるとともにコストを削減することができる。例えば、作業員のタイムカードタスクを監督者に割り当てて、その監督者が、完了されたタスクをサーバに送り返す用意が整うまで作業員とやり取りすれば、監督者だけがサーバとの通信を必要とするだけで済む。サーバとの通信を確立するために、たとえ衛星電話又は配線Ｅｔｈｅｒｎｅｔ接続などの特殊な通信ハードウェアへのアクセスが必要であれ、設備がある場所への移動が必要であれ、このような接続を各作業員が個々に行う必要があるのではないことによって、タスクを完了させるのに必要な時間が短縮され、更なる通信ハードウェアの必要が回避されえる。
【０１９３】
デリゲートに適格なタスクには、上述のように、タスクの転送先にできるデバイスに接続するために必要な情報と、随意として、それらのデバイスのユーザに関する情報とを含む、「配布リストノード」がある。
【０１９４】
一部の典型的な実装形態では、タスクを構成するノードは、第１のデバイスに固有の参照すなわちノードＩＤを使用して互いにリンクし合う。このようなノードを第２のデバイスに転送するためには、ノード参照を、第１のデバイス内に存在するノードに相対的ではなく、タスク自体に相対的にしなくてはならない。これは、「ノードツリーパック化（Node Tree Packing）」と称される。転送後、（１つ又は複数の）転送されたノードは、自身のノード参照を、第２のデバイス上における固有なアドレス指定すなわちノードＩＤに調整されなければならない。これは、「ノードツリーパック解凍（Node Tree Unpacking）」と称される。このようなノードツリーパック化がタスクのノードに対して実施されたことを示し、受信デバイスが適切なノードツリーパック解凍を実施できるようにするためには、デリゲートされるタスクは、タスクデリゲートメッセージによって転送される。
【０１９５】
第１のデバイスから第２のデバイスにタスクをデリゲートするための第１の典型的な手続き（方法１）が、図１２に示されている。第１のデバイスのユーザは、デリゲートする割り当てタスクを選択するために、第１のデバイスのディスプレイマネージャとやり取りする（１２０００）。一部の典型的な実装形態における選択の方法は、割り当てタスクのメニューであり、そこから選択が行われる。その他の典型的な実装形態では、タスクは、望ましいタスクが見つかるまで一度に１つずつタスクを提示することによって選択される、又はタスクは、指定の順序で若しくはその他の何らかの手段によって処理されなければならないことがある。
【０１９６】
タスクが指定されたら、他のどのデバイスをタスクのデリゲート先にできるかを決定するために、タスクの配布リストノードが参照される（１２００５）。配布リストノードは、タスクのデリゲート先にできるデバイス及び各デバイスのための通信経路情報を指定する、データ及び／又はデータを含むカタログへの参照を含む。データは、特定のタスクに
固有である、又は、例えば、一群のデバイスが一監督者の部下によって使用され、その監督者がそれらの部下にタスクを定期的にデリゲートするときなど、複数のタスク間で共有することができる。タスクのデリゲート先にできるデバイスは、適切なやり方で第１のデバイスのユーザに提供される（１２０１０）。一部の典型的な実装形態では、表示は、通信経路の記述と、デバイスのアドレスとからなることができる。その他の典型的な実装形態では、表示は、デバイスに関連付けられたユーザ名からなることができる。その他の典型的な実装形態では、勤務シフト、経験レベル、最後にいたことがわかっている場所、サポートされている通信経路、又はその他の情報など、ユーザに関する更なるデータが表示される。一部の典型的な実装形態では、このようなその他の情報は、配布リストノードに含まれる特定のタスク配布情報を利用することができる特定のデバイス又はデバイス群の規定などのように、配布情報の使用に対する制限を含むことがある。例えば、タスクの割り当て先として可能性のある複数のデバイスを指定する配布リストノードを伴うタスクが、第１のデバイスから第２のデバイスにデリゲートされるときに、第１のデバイスは、第２のデバイスが使用することができる唯一の利用可能配布情報が第１のデバイスを指定するように、配布リストノードのコンテンツを変更することができる。これは、第１のデバイスによる再デリゲートに制約を加えることなく、第２のデバイスによるタスクの再デリゲートを制限し、第２のデバイスがタスクを第１のデバイスに戻す再デリゲートしかできないようにする。残りの配布情報を配布リストノードから除去することなく第２のデバイスによるこのような残りの配布情報の使用を不可にすることによって、第１のデバイスは、恐らくは第２のデバイスによるタスクの部分的完了後にタスクが第１のデバイスに再デリゲートされること、及びタスクが再デリゲートされるときに、配布リストノード情報が依然、第１のデバイスによって使用可能なようにタスクに関連付けられており、第２のデバイスを指定する制限によって制約されないことを、保証する。
【０１９７】
第１のデバイスのユーザは、タスクのデリゲート先にする受け手を選択し（１２０１５）、タスクは、伝送に合わせてパッケージ化される（１２０２０）。伝送に合わせたタスクのパッケージ化は、一部の典型的な実装形態では、ノードツリーパック化を含むことができる。一部の典型的な実装形態では、現行のデリゲート手続きに使用されている配布リストノードとは異なる配布リストノードが、タスクパッケージに追加される（例：監督者が、タスクの再デリゲートを制限したい又は禁止したい場合など）。タスクパッケージは、符号化される、圧縮される、暗号化される、又は各種の典型的な実装形態においてその他の処理を施される。
【０１９８】
配布リストノード内の通信経路情報を使用して（１２０２５）、タスクは、第２のデバイスに伝送され（１２０３０）、第２のデバイスは、タスクの受け入れを承認し（１２０３７）、サーバは、デリゲートの通知を送信される（１２０３５）。サーバに送信された通知は、随意として、タスクが完了されその完了についての通知をサーバが受けたときにサーバがそれを第１のデバイスに通知するように要求してもよい。一部の典型的な実装形態では、タスクが第１のデバイスから第２のデバイスにデリゲートされるときに、第１のデバイスは、タスク及び第２のデバイスを識別するのに十分な情報を記録する永続記録を、ＢＬＯＢノードの使用などによって作成する。この記録は、本明細書では「デリゲート記録」と称される。デリゲート記録は、サーバによってであれ、又は別のデバイスからのデリゲートによってであれ、タスクを割り当てられた各デバイスに、タスクキャンセル情報を伝搬させるのに有用である。
【０１９９】
第２のデバイスによってタスクが受信されると、タスクは、パッケージ解凍され、第２のデバイスにインストールされる（１２０４０）。これは、一部の典型的な実装形態では、第１のデバイスによってタスクに施された圧縮、暗号化、又はその他の動作を逆行させること、ノード参照を、タスクに相対的な形態からタスクの処理に必要な形態に変換すること（ノードツリーパック解凍）、及びタスクをタスクリスト、タスクマネージャ、又はタスクを管理するために第２のデバイスによって使用されるその他の構造、システム、若しくは手続きにタスクをリンクさせることを含むことができる。
【０２００】
第２のデバイスのユーザによってタスクが完了されたら（１２０４５）、サーバは、タスクの完了について通知され、サーバは、タスクの完了について、もしそのような通知が要求された場合（１２０５０）に第１のデバイスに通知する（１２０５５）。第１のデバイスは、タスクがデリゲートされたときに作成されたデリゲート記録を削除し（１２０６０）、プロセスは完了する。
【０２０１】
図１３に示されるように、第１の方法によるタスクデリゲート（１３１００）におけるメッセージ交換は、サーバから第１のデバイスへのタスクの初期割り当てを伴う（１３１１０）。第１のデバイスは、すると、タスクを第２のデバイスにデリゲートし（１３１２０）、第２のデバイスは、デリゲートを承認し（１３１２５）、第１のデバイスは、タスクデリゲートについてサーバに通知する（１３１３０）。タスクが完了すると、第２のデバイスは、サーバに通知し（１３１４０）、サーバは、（もし通知が要求された場合は）第１のデバイスに通知する（１３１５０）。
【０２０２】
第１のデバイスから第２のデバイスにタスクをデリゲートするための第２の典型的な手続き（方法２）が、図１４に示されている。第２の典型的な手続きの初期のステップ、すなわち、第１のデバイスのユーザが、デリゲートする割り当てタスクを選択するために、第１のデバイスのディスプレイマネージャとやり取りするステップ、タスクのデリゲート先にできるデバイスを決定するために、タスクの配布リストノードが参照されるステップ、ユーザが、デリゲート先にするデバイスを選択するステップ、及びタスクが、伝送に合わせてパッケージ化されるステップは、第１の典型的な手続きと同じである（１４５００）。タスクパッケージは、やはり方法１と同じ方式で伝送され（１４５１０）、やはり方法１と同様に、委託先のデバイスは、タスクの受け入れを承認し（１４５３５）、サーバは、デリゲート元のデバイスによってデリゲートの通知を送信される（１４５１５）。方法２では、しかしながら、デリゲート元のデバイスは、割り当てタスクを委託先が完了させたことの通知を方法１のように送信されない。代わりに、デリゲート元のデバイスは、割り当てタスクを保留中であるものとしてログに記録し（１４５２０）、一意ＩＤを含むチェックポイントメッセージを委託先のデバイスに送信し（１４５２５）、その後、手続きは、一意ＩＤを持つチェックポイントメッセージがサーバから受信されるまで一時停止する（１４５３０）。この一時停止は、例示のステップにおける概念的な一時停止であり、デリゲート元のデバイス上における処理が文字通り一時停止することではなく、その他の作業の処理は正常に続けられる。保留中のタスクのログは、タスクのデリゲート先の各デバイスについて維持される。これらのログは、論理的には区別されるが、各ログが別々の順次編成ファイル内若しくは索引ファイル内にある、全てのログが１つの順次編成ファイル内若しくは索引ファイル内にある、各ログがリレーショナルデータベースシステムの別々のテーブル内にある、全てのログがリレーショナルデータベースの１つのテーブル内にある、ログが１つのカタログ内若しくは複数のカタログ内に保持される、ログがＢＬＯＢノード内に維持されるなど、当業者によって適切だと判断される任意の方式で実装される。
【０２０３】
第２のデバイスによってタスクが受信されると、それは、デリゲート元のデバイスに対して承認され（１４５３５）、タスクは、パッケージ解凍されて、第２のデバイスにインストールされる（１４５４０）。一意ＩＤを伴うチェックポイントメッセージとともに（１４５５０）、タスク受け入れメッセージもサーバに送信される（１４５４５）。サーバは、チェックポイントメッセージを受信すると、それをデリゲート元のデバイスに転送し（１４５５５）、これは、委託先のデバイスがサーバと連絡していたこと、及びそれゆえにサーバがタスクデリゲートについて知らされていたことを、デリゲート元のデバイスに
知らせ、委託先のデバイスについてのデリゲートログは、そのデリゲートされたタスクを含むところまで消去される（１４５６０）。タスクが完了したら、委託先のデバイスは、方法１と同様に、タスクの完了を報告するためにサーバに連絡を取り（１４５６５）、プロセスは完了する。
【０２０４】
図１３に示されるように、第２の方法によるタスクデリゲート（１３２００）におけるメッセージ交換は、サーバから第１のデバイスへのタスクの初期割り当てを伴う（１３２１０）。第１のデバイスは、すると、タスクを第２のデバイスにデリゲートし（１３２２０）、第２のデバイスによるデリゲートの受け入れの承認を受信し（１３２３０）、タスクデリゲートについてサーバに通知する（１３２４０）。第１のデバイスは、次いで、チェックポイントメッセージ（１３２５０）を第２のデバイスに送信する。第２のデバイスは、タスクデリゲート通知を第１のデバイスに送信し（１３２６０）、チェックポイントメッセージをサーバに転送する（１３２７０）。サーバは、チェックポイントメッセージを受信すると、それを第１のデバイスに転送する（１３２８０）。タスクが完了したら、第２のデバイスは、サーバに通知し（１３２９０）、プロセスは完了する。
【０２０５】
タスクデリゲートのための方法１は、少なくとも第１のデバイスがサーバと通信状態にあり、第２のデバイスへのタスクのデリゲートがサーバに確実に通知されるときに、有用である。これが当てはまらない場面では、方法１は、もし第１のデバイスに割り当てられたタスクについて、サーバが第２のデバイスからのタスク完了の旨を受け入れる用意があれば、依然として使用することができる。これは、第１のデバイスが第２のデバイスへのタスクのデリゲートについてサーバに通知する前に、第２のデバイスがタスクを完了してその旨をサーバに送信する状況に対処している。代替の典型的な実装形態では、第２のデバイスは、タスク完了の旨を第１のデバイスに送信し、第１のデバイスは、次いで、そのタスク完了の旨をサーバに送信する。第２のデバイスから第１のデバイスへの連鎖を通して行われるタスク完了の旨のこのような中継は、当業者にならば自明であるように、任意の数のデバイスに対してなすことができる。各第１のデバイスは、タスクが第２のデバイスにデリゲートされるときに、デリゲート記録を作成し、タスク完了の旨が返され、連鎖を遡って中継され、そのタスクのための処理が完了されるときに、デリゲート記録を削除する。デリゲート記録は、タスク完了の旨が第２のデバイスから送信されていることを各第１のデバイスが立証することを可能にする。
【０２０６】
もしサーバにおいてタスクがキャンセルされた場合は、そのキャンセルは、タスクを割り当てられた先の（１つ又は複数の）第１のデバイスに送信される。もし第１のデバイスが第２のデバイスにタスクをデリゲートした場合は、第１のデバイスは、タスクキャンセルの旨を受信し次第、タスクがデリゲートされたときに作成されたデリゲート記録を使用して第２のデバイスにキャンセルの旨を転送する。もし第２のデバイスが第３のデバイスにタスクをデリゲートした場合は、第２のデバイスは、第１のデバイスからタスクキャンセルの旨を受信し次第、自身のデリゲート記録を使用して第３のデバイスにタスクキャンセルの旨を転送する。当業者にならば明らかなように、このプロセスは、第４のデバイスへ、第５のデバイスへなどのように、任意の数のデリゲートに対して続けることができる。各デリゲート元デバイスは、タスクキャンセルの旨の転送を完了した時点で、そのタスクについてのデリゲート記録を削除する。
【０２０７】
もしタスクを割り当てられた先のデバイスにおいてタスクがキャンセルされた場合は、キャンセルの旨は、サーバに送信され、サーバは、タスクを割り当てられた先の第１のデバイスにキャンセルの旨を転送する。第１のデバイスは、第２のデバイスにキャンセルの旨を転送し、そのタスクに関する自身のデリゲート記録を削除する。転送プロセスは、もしタスクが複数回にわたって再デリゲートされた場合は、第３のデバイスへ、第４のデバイスへなどのように繰り返すことができる。代替の実装形態では、キャンセル元のデバイ
スが、自身がタスクを割り当てた先のデバイスにキャンセルの旨を送信する。すなわち、第２のデバイスが、第１のデバイスにキャンセルの旨を送信し、第１のデバイスは、自身のデリゲート記録を削除し、サーバにキャンセルの旨を転送する。このキャンセルプロセスもやはり、任意の数のデリゲートに対して実施することができる（例：キャンセルの旨は、第４のデバイスから第３のデバイスへ、そして第２のデバイスへ、そして第１のデバイスへ転送され、第１のデバイスによって、サーバに転送される）。
【０２０８】
タスクのキャンセルは、タスクが別のタスクの複製である（自動機器が故障を検出したために修理タスクを生成したが、同じ誤動作が複数の故障イベントを発生させたときに起こり得る）、タスクが誤って生成された（例：組み立てラインの始動時に、特定の一連の機械の起動がデバイス故障を示すように見えるが、実際は何も問題なく、全ての機械が動き始めれば安定化するとき）、又はタスクが別のタスクに内包される（例：機械に対してメインテナンスを実施するためのタスクが生成されたが、引き続き同機械に故障が発生した結果、別のタスクが取って代わり、メインテナンスタスクを不要にした）などの多くの理由によって必要とされ得る。
【０２０９】
タスクデリゲートの方法２は、両デバイスがＧＲＰＳ、Ｗｉ−Ｆｉ、及びサーバとのその他の通信方法から隔離されている間に、デバイス間においてＰ２Ｐリンクを使用してデリゲートがなされたときに起こり得るような、デリゲートの時点で少なくとも第１のデバイスがサーバと通信状態にないときに、有用である。第１のデバイスによって第２のデバイスに送信されたチェックポイントメッセージが、サーバから第１のデバイスに送信されれば、第２のデバイスがサーバと連絡しており、ゆえに、たとえ第１のデバイスがタスクデリゲート通知を送信する機会が無かった場合でも、サーバがタスクデリゲートについて通知されていたこと、及び第１のデバイスがもうデリゲートタスクを追跡する必要がなくなり、ゆえに、受信されたチェックポイントメッセージに関連付けられたタスクを含むところまでそのログエントリを消去できることが、明らかである。
【０２１０】
したがって、以上から理解されるように、典型的で例示的で非限定的な実装形態は、たとえ、ワイヤレスネットワークデバイスと、より強固なその他のネットワークデバイスとの間の通信が非信頼性であるとき、断続的であるとき、帯域幅が限られるときでも、又はデバイスのうちの１つ若しくは複数のデバイスのリソースに限りがあるときでも、ローカルワイヤレス接続を確立することができる、信頼性の高い相互作用の方法を、第１のデバイスのユーザと第２のデバイスのユーザとの間に提供できるように、デバイス間における「ノード」、コマンド、及びその他のデータ項目の交換を可能にするための、システムと、装置と、ソフトウェアとを提供する。本明細書に記載される方法、システム、及び装置を使用すれば、より効率的な、通信、リソース割り当て、及びタスクデリゲートを達成することができる。
【０２１１】
本明細書における技術は、典型的で例示的で非限定的な実施形態との関連で説明されてきたが、発明は、この開示に限定されない。発明は、特許請求の範囲によって定められること、及び本明細書に具体的に開示されたものであれ、そうでないものであれ、相応の及び等価のあらゆる構成を網羅することを、意図されている。
【図１】
2012503449.tif 000008
【図２】
2012503449.tif 000009
【図３】
2012503449.tif 000010
【図４】
2012503449.tif 000011
【図５】
2012503449.tif 000012
【図６】
2012503449.tif 000013
【図７】
2012503449.tif 000014
【図８】
2012503449.tif 000015
【図９】
2012503449.tif 000016
【図１０】
2012503449.tif 000017
【図１１】
2012503449.tif 000018
【図１２】
2012503449.tif 000019
【図１３】
2012503449.tif 000020
【図１４】
2012503449.tif 000021
【図１５】
2012503449.tif 000022
【手続補正書】
【提出日】平成23年5月23日(2011.5.23)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
遠隔コンピュータデバイスとの間でのノード構造通信方法であって
ノード構造の少なくとも第１の部分を表わす第１の信号を選択し、前記選択された第１の信号を第１のコンピュータデバイスと遠隔の第２のコンピュータデバイスとの間で第１の通信経路を通じて通信するステップと、
前記ノード構造の少なくとも第２の部分を表わす第２の信号を選択し、前記選択された第２の信号を第１のコンピュータデバイスと遠隔の第２のコンピュータデバイスとの間で、第１の通信経路と少なくとも部分的に異なる第２の通信経路を通じて通信するステップと、
を含み、
前記ノード構造は、ノード構造を受信及び処理するように構成された少なくとも１つの受信遠隔コンピュータデバイスによって実施されるアプリケーションと、前記アプリケーションの実施に関連する少なくとも幾つかのデータとに関する統合された定義を提供し、
前記ノード構造の第１の及び第２の部分は、前記少なくとも１つの受信遠隔コンピュータデバイスによって統合された定義に調和可能であり、
調和されたノード構造の少なくとも一部は、その後、前記受信遠隔コンピュータデバイスと少なくとも１つのノード送信デバイスとの間で同期化される、
ことを特徴とするノード構造通信方法。
【請求項２】
前記第１の通信経路は、前記第２の通信経路と実質的に異なる帯域幅を有し、
前記選択は、更に、前記ノード構造の異なる部分を通信するために、優先度に基づいて前記第１の経路と前記第２の経路との間で選択を行う、
ことを特徴とする、請求項１に記載のノード構造通信方法。
【請求項３】
ノード構造の受信後、前記遠隔の受信デバイスとの更なる通信を必要とすることなく、前記遠隔の受信デバイス上で前記アプリケーションを実施する、
ことを特徴とする請求項１又は２に記載のノード構造通信方法。
【請求項４】
前記同じノード構造の異なる部分について、あまり好ましくない通信経路よりも好ましい通信経路を状況に応じて使用するために、前記第１の通信経路と前記第２の通信経路との間で選択を行うこと、
前記第１の通信経路と前記第２の通信経路との間で動的に切り替えを行うこと、
前記第１の及び第２の通信経路を一度に１本ずつ使用すること、
前記第１の及び第２の通信経路の両方を同時に使用すること、
の少なくとも１つを特徴とする、請求項１から３のいずれかに記載のノード構造通信方法。
【請求項５】
前記第１及び第２の通信経路は異なる特性を有し、
該異なる特性は、異なる速度／帯域幅特性、異なる信頼性、異なる使用コスト、異なる通信プロトコル、及び異なる伝送媒体からなる群より選択される特性の集合である、
ことを特徴とする、請求項１から４のいずれかに記載のノード構造通信方法。
【請求項６】
前記ノード構造の少なくとも一部分の通信は、
帯域外伝送、
前記ノード構造の特性に部分的に基づいて決定される優先メッセージングにしたがうこと、又は
ノード構造及び該ノード構造に含まれるデータ項目の重複を検出して排除した後に機能性が保たれるように冗長性を提供すること、
の少なくとも１つによることを特徴とする、請求項１から５のいずれかに記載のノード構造通信方法。
【請求項７】
前記遠隔受信デバイスとの通信は、
プッシュモード伝送、
協調プッシュモード伝送、
要求／プルモード伝送、
プルモード伝送、及び
ピア・ツー・ピア（Ｐ２Ｐ）ノード構造伝送
の少なくとも１つを含むことを特徴とする、請求項１から６のいずれかに記載のノード構造通信方法。
【請求項８】
前記遠隔受信デバイスとの通信は、更に、告知及び受け入れ（Ａ＆Ａ）メカニズムによって前記ノード構造を複数の遠隔受信デバイスにブロードキャストすることを含むことを特徴とする、請求項１から７のいずれかに記載のノード構造通信方法。
【請求項９】
前記遠隔受信デバイスとの通信は、前記第１のコンピュータデバイスと１つ又は複数の遠隔の第２のコンピュータデバイスとの間でサーバの助けによらずにタスクを直接的に転送するためにタスクデリゲートを使用することによる通信を含むことを特徴とする、請求項１から８のいずれかに記載のノード構造通信方法。
【請求項１０】
前記遠隔コンピュータデバイスとの通信は、前記遠隔コンピュータデバイスに対して作用し前記ノード構造の要素のアクセス、使用、又は変更に対する制限を可能にする柔軟なセキュリティモデルを使用することを特徴とする、請求項１から９のいずれかに記載のノード構造通信方法。
【請求項１１】
第１のコンピュータデバイスから遠隔の第２のコンピュータデバイスにタスク割り当てを転送することと、
転送されたタスクが完了されたことを遠隔コンピュータデバイスに通知することと、
複数の異なる遠隔コンピュータデバイス上に保存されているカタログ間の相違を識別及び解消することと、
を特徴とする、請求項１から１０のいずれかに記載のノード構造通信方法。
【請求項１２】
前記第１の経路は、携帯無線電話ネットワーク経路を含むこと、及び
前記第２の経路は、Ｂｌｕｅｔｏｏｔｈネットワーク経路を含むこと、
を特徴とする、請求項１から１１のいずれかに記載のノード構造通信方法。
【請求項１３】
第１のワイヤレス通信経路を通じて通信を可能にする第１の通信インターフェースと、
前記第１のワイヤレス通信経路と少なくとも部分的に異なる第２のワイヤレス通信経路を通じて通信を可能にする第２の通信インターフェースと、
ノード構造の少なくとも第１の部分を表わす信号を前記第１の通信経路を通じて受信し、前記ノード構造の少なくとも第２の部分を表わす信号を前記第２の通信経路を通じて受信する通信コントローラと、
前記第１及び第２の通信インターフェースのそれぞれと通信可能であり、前記第１及び第２のワイヤレス通信経路を通じて他の遠隔コンピュータデバイスとノード構造を交換するように構成されたノードプロセッサと、
を備え、
前記ノード構造は、遠隔コンピュータデバイス上で実施されるアプリケーションと、前記アプリケーションの実施に関連する少なくとも幾つかのデータとに関する統合された定義を含み、
前記ノード構造の第１及び第２の部分は、前記リモートコンピュータデバイスによって統合された定義に調和可能であり、その後、少なくとも１つのノード送信デバイスと同期化される、
ことを特徴とするコンピュータデバイス。
【請求項１４】
前記第１及び第２の通信インターフェース、前記通信コントローラ、並びに前記ノードプロセッサを収容する手持ち式のケースと、
前記手持ち式のケースに関連付けられ、前記通信コントローラに結合されたディスプレイと、
を更に備えることを特徴とする、請求項１３に記載のコンピュータデバイス。
【請求項１５】
前記第１の通信インターフェース及び前記第２の通信インターフェースは、
異なる通信プロトコル、及び
異なる電波周波数、
のいずれかで動作することを特徴とする、請求項１３又は１４に記載のコンピュータデバイス。
【請求項１６】
前記第１の通信インターフェース及び前記第２の通信インターフェースは、  
携帯無線電話ネットワーク、
Ｂｌｕｅｔｏｏｔｈを含むワイヤレスプロトコル、及び
Ｗｉ−Ｆｉを含むワイヤレスプロトコル、
のいずれかで動作することを特徴とする、請求項１３から１５のいずれかに記載のコンピュータデバイス。
【請求項１７】
前記第１の通信インターフェース及び前記第２の通信インターフェースのそれぞれは、異なる携帯無線電話ネットワークプロトコルで動作することを特徴とする、請求項１３から１６のいずれかに記載のコンピュータデバイス。                        
【国際調査報告】
2012503449.tif 000023
2012503449.tif 000024
2012503449.tif 000025