(57)【特許請求の範囲】
【請求項１】
物理層を含むモバイル環境内において統一ネットワーキングを提供するデバイスであっ
て、前記デバイスは、１台以上のメモリー装置を含み、
前記１台以上のメモリー装置には、
前記物理層の上に積み重ねられたリンク層と、
前記リンク層の上に積み重ねられたネットワーク層と、
前記ネットワーク層の上に積み重ねられたトランスポート層と、
前記トランスポート層の上に積み重ねられたアプリケーション層と、
前記物理層と前記リンク層との間における物理制御機能（ｐｈｙｓｉｃａｌ  ｃｏｎ
ｔｒｏｌ  ｆｕｎｃｔｉｏｎ、ＰＣＦ）であって、スペクトルチャンネル設定を管理する
物理制御機能と、
前記リンク層と前記ネットワーク層との間のリンク制御機能（ｌｉｎｋ  ｃｏｎｔｒ
ｏｌ  ｆｕｎｃｔｉｏｎ、ＬＣＦ）であって、ｍａｃアドレス及びルックアップテーブル
の制御、リンク状態情報、制御情報、パフォーマンス情報、ネットワークパケットルック
アップ、ネットワークからのデバイスの発見及び認証、ハンドオーバー遅延の最適化、及
び仮想インターフェース設定の制御のうち１以上を提供し、前記デバイスの近傍において
各インターフェースの接続に利用可能なアクティブなネットワークのロジカルインターフ
ェイスプールの制御を提供するリンク制御機能と、
前記ネットワーク層と前記トランスポート層との間のネットワーク制御機能（ｎｅｔ
ｗｏｒｋ  ｃｏｎｔｒｏｌ  ｆｕｎｃｔｉｏｎ、ＮＣＦ）であって、ルーティングテーブ
ル制御機能、マルチホーミング機能、モビリティ機能、マルチパス機能、及びオンデマン
ドエンド・ツー・エンドセキュリティ機能のうち１以上を提供するネットワーク制御機能
と、
前記アプリケーション層と前記トランスポート層との間の制御ミドルウェアであって
、１以上のフローのマッピングを保持し、１以上のポリシーを保持し、前記１以上のポリ
シーに基づいたフロー制御決定を実行する制御ミドルウェアと、
を記憶させていることを特徴とするデバイス。
【請求項２】
前記制御ミドルウェアは、物理、リンク及びネットワーク制御機能を管理するように構
成されていることを特徴とする請求項１のデバイス。
【請求項３】
前記制御ミドルウェアは、マルチホーミング、モビリティ、マルチパス、サービス共有
、途絶耐性、ネットワーク、デバイス及び利用可能な物理スペクトルチャンネルの発見の
管理、並びにこれらの組み合わせのうち１以上を提供するように構成されていることを特
徴とする請求項１のデバイス。
【請求項４】
前記制御ミドルウェアは、ネットワークアクセス制御のためにサービスアクセスマネー
ジャーと通信するように構成されていることを特徴とする請求項１のデバイス。
【請求項５】
前記ＮＣＦは、前記フローの存在期間内においてはモビリティイベントの場合でさえも
変化しないフロー識別子を前記トランスポート層に提供するように構成されていることを
特徴とする請求項１のデバイス。
【請求項６】
ＮＣＦは、モビリティイベントを処理するために、モビリティマネージャーと通信する
ように構成されていることを特徴とする請求項１のデバイス。
【請求項７】
ＬＣＦは、利用可能なネットワークの情報を提供するネットワーク情報マネージャーと
通信するように構成されていることを特徴とする請求項１のデバイス。
【請求項８】
ＰＣＦは、トランシーバースペクトル設定のために、スペクトルデータベースマネージ
ャーと通信するように構成されていることを特徴とする請求項１のデバイス。
【請求項９】
前記制御ミドルウェアは、ネットワークマネージャーモジュールと、ロケーションマネ
ージャーモジュールと、セキュリティマネージャーモジュールと、キューマネージャーモ
ジュールと、サービス共有マネージャーモジュールと、システムマネージャーモジュール
と、データストアと、ハンドオーバーをいつ実行するかを決定するポリシーエンジンとを
含むことを特徴とする請求項１のデバイス。
【請求項１０】
モバイル環境におけるデバイスの統一ネットワーキング方法であって、
１以上のアクティブなネットワークインターフェースを監視することと、
前記デバイスのロケーションを監視することと、
前記デバイスのネットワークアクセスセキュリティを管理することと、
１以上のアクティブなアプリケーションセッションに対するシステムパラメーターを管
理することと、
前記１以上のアクティブなアプリケーションセッションに対応する１以上のフローに対
するマッピングを保持し、１以上のポリシーを保持し、前記ポリシーに基づいたフロー制
御決定を行うことと、
スペクトル可用性情報、ロケーション情報、リソース情報、待機時間情報、帯域幅情報
、並びに、システム及びネットワーク使用情報のうちの１以上を含む過去のネットワーク
情報を含む知識ベースを保持することと、
前記知識ベースを用いてフロー制御決定を行うことと、
を含むことを特徴とする方法。
【請求項１１】
前記１以上のフローの各々は、前記デバイスと通信ノードとの間にデータパイプを含み
、前記１以上のフローの各々は、ハンドオーバーの場合でさえも不変であるフロー識別子
によって識別されることを特徴とする請求項１０の方法。
【請求項１２】
ハンドオーバーの場合に中断されて再構成される少なくとも一つのＩＰアドレスによっ
て識別される１以上のサブフローを更に含むことを特徴とする請求項１０の方法。
【請求項１３】
ポリシーエンジンを用いてリアルタイムでフロー制御決定を行い、既存のフローを補完
するか否かを決定することを更に含むことを特徴とする請求項１０の方法。
【請求項１４】
第１のネットワークインターフェースにより提供される第１のフローは、第２のネット
ワークインターフェースに移動させられることを特徴とする請求項１０の方法。
【請求項１５】
ポリシーエンジンを用いてリアルタイムでフロー制御決定を行い、パラレル補助接続に
よって既存のフローを補完するか否かを決定することを更に含むことを特徴とする請求項
１０の方法。
【請求項１６】
第１のフローは、第１のネットワークインターフェースにより提供される第１のサブフ
ローと、第２のネットワークインターフェースにより提供される第２のサブフローとを同
時に含むことを特徴とする請求項１０の方法。
【請求項１７】
複数のフローが保持され、前記複数のフローの各々は、１以上の対応するネットワーク
インターフェースを有することを特徴とする請求項１０の方法。
【請求項１８】
途絶耐性サポートは、ネットワーク接続性が無い場合、又はポリシーがネットワークの
使用を強いない場合に提供されることを特徴とする請求項１０の方法。
【請求項１９】
フロー制御決定を行うことは、ロケーション、時間、ネットワークコスト、ネットワー
ク帯域幅、ネットワーク待機時間、ネットワークの存在、ネットワークセキュリティ、デ
バイスセンサーデータ、アプリケーションリソース使用度、またはこれらの組み合わせか
らなる群から選択される現在の属性を評価するためにポリシーエンジンを用いることを含
むことを特徴とする請求項１０の方法。
【請求項２０】
前記システムパラメーターのうちの１以上が、１以上のアプリケーションに対する閾
値を超える場合に、該アプリケーションの実行をクラウドへとオフロードすることを更に
含むことを特徴とする請求項１０の方法。
【請求項２１】
１以上のアプリケーションが追加のリソースを必要とする場合に、該アプリケーション
の実行をクラウドへとオフロードすることを更に含むことを特徴とする請求項１０の方法
。
【請求項２２】
インターフェース情報、時間情報、ロケーション情報、リソース情報、帯域幅情報、及
びネットワーク使用情報のうちの１以上を含む過去のネットワーク及びシステム情報を含
む知識ベースを保持し更新することを更に含むことを特徴とする請求項１０の方法。
【請求項２３】
前記知識ベースを用いて地理ネットワークアクセスマップを作成し、当該地理ネットワ
ークアクセスマップを用いてフロー制御決定を行いハンドオーバー待機時間を減少させる
ことを特徴とする請求項２２の方法。
【請求項２４】
信号強度、待機時間、利用可能帯域幅、ネットワークの存在、セキュリティパラメータ
ー及びこれらの組み合わせからなる群から選択されるネットワークパフォーマンス属性を
監視することと、前記ネットワークパフォーマンス属性のうちの１以上が所定の閾値を超
える場合に、ネットワークイベントを作成することとを更に含むことを特徴とする請求項
１０の方法。
【請求項２５】
ポリシーエンジンに前記ネットワークイベントに関する信号を送ることと、各アクティ
ブアプリケーションフローに関するポリシーを評価し、第１のネットワークインターフェ
ースから第２のネットワークインターフェースへのハンドオーバーを実行するか否かを決
定することとを更に含むことを特徴とする請求項２４の方法。
【請求項２６】
サービス共有及びセッションモビリティを可能にすることを更に含み、前記サービス共
有を可能にすることは、デバイス上に登録済みサービスを保持するためにサービス登録を
提供することと、サービスリクエストを評価することと、フロー移行を実行して１つのデ
バイスから他のデバイスへのセッションモビリティを可能にすることとを含むことを特徴
とする請求項１０の方法。
【請求項２７】
サービス登録を提供することは、
ポリシーエンジンにおいてサービスに対するサービス登録リクエストを受け取ることと
、
前記サービス登録リクエストをサービス共有マネージャーに渡すことと、
前記サービスを前記サービス共有マネージャー内のサービス登録テーブルに登録するこ
とと、
前記サービスを複数の接続済みデバイスに同時に配信することと、
を含むことを特徴とする請求項２６の方法。
【請求項２８】
サービスリクエストを評価することは、
ポリシーエンジンにおいて、アプリケーションからサービスに関するサービスリクエス
トを受け取ることと、
前記サービスリクエストをサービス共有マネージャーに渡すことと、
前記サービスについて前記サービス共有マネージャー内のサービス登録テーブルを調べ
ることと、
前記サービス登録テーブル内に前記サービスが見つかった場合に、サービスを評価して
サービススコアが閾値を超えているか否かを決定することと、
前記サービススコアが前記閾値を超えている場合、前記アプリケーションに前記サービ
スについて通知することと、
を含むことを特徴とする請求項２６の方法。
【請求項２９】
フロー移行を実行することは、
ポリシーエンジンにおいて、アプリケーションからサービス移行リクエストを受け取る
ことと、
前記サービス移行リクエストをサービス共有マネージャーに渡すことと、
前記サービス移行リクエストを調べ、前記サービス共有マネージャー内のサービス登録
テーブルからデバイス詳細を取得することと、
サービス共有マネージャーによって第２のデバイスへの前記フロー移行を開始すること
と、
前記デバイスおよび前記第２のデバイスにおいてフローを同期させることと、
前記アプリケーションに移行結果を通知することと、
を含むことを特徴とする請求項２６の方法。
【請求項３０】
前記デバイスは、サーバー、ルーター、スイッチ、並びに、ストレージ及びネットワー
ク能力を有するコンピュータノードからなる群から選択されるネットワークエレメントで
あることを特徴とする請求項１０の方法。
【請求項３１】
前記ネットワークエレメントにおいてサービスリクエストを受け取ることと、サービス
マッチに関してサービステーブルを調べることと、マッチが見つかった場合にサービス応
答を返すことと、マッチが見つからなかった場合に、サービスリクエストを転送すること
とを更に含むことを特徴とする請求項３０の方法。
【請求項３２】
複数のデバイスに関する過去のネットワーク及びサービスアクセスデータを含む知識ベ
ースを保持し更新することを更に含むことを特徴とする請求項３０の方法。
【請求項３３】
前記知識ベースを用いて、前記過去のネットワーク及びサービスアクセスデータに基づ
き、デバイスに事前にサービスを提供することを特徴とする請求項３２の方法。
【請求項３４】
前記サービスは、分散型サービス拒否攻撃を検出するセキュリティ対策、セキュリティ
イベントを理解するためのフォレンジクス、ネットワーク内でのＵＥの詳細な行動の提供
、ロケーションベースサービス、及びサービス負荷のバランシングのうちの１以上を含む
ことを特徴とする請求項３３の方法。
【請求項３５】
モバイル環境内でデバイスを動作させるための、コンピューターが実行可能な命令を記
録又は記憶する非一時的コンピューター可読媒体であって、前記命令は、実行時に、１以
上のデバイスに統一ネットワーキングの方法を実行させ、
前記方法は、
アクティブなネットワークインターフェースを監視することと、
前記デバイスのロケーションを監視することと、
前記デバイスのネットワークアクセスセキュリティを管理することと、
１以上のアクティブなアプリケーションセッションに対するシステムパラメーターを管
理することと、
前記１以上のアクティブなアプリケーションセッションに対応する１以上のフローに対
するマッピングを保持し、１以上のポリシーを保持し、前記ポリシーに基づいたフロー制
御決定を行うことと、
スペクトル可用性情報、ロケーション情報、リソース情報、待機時間情報、帯域幅情報
、並びに、システム及びネットワーク使用情報のうちの１以上を含む過去のネットワーク
情報を含む知識ベースを保持することと、
前記知識ベースを用いてフロー制御決定を行うことと、
を含むことを特徴とするコンピュータ可読媒体。
【請求項３６】
モバイル環境においてデバイスに対するネットワーク接続を管理するシステムであって
、
前記システムは、
１以上のアクティブなアプリケーションセッションに対応する１以上のフローに対する
マッピングを保持し、フロー制御決定を実行するための、ポリシーベースの一組のルール
が記憶された一台以上のストレージデバイスであって、前記一組のルールは、帯域幅の使
用度、ネットワークコスト、ネットワーク帯域幅、ネットワーク待機時間、スペクトル可
用性、ロケーション、時間、及び、デバイスタイプのうちの１以上を含む一台以上のスト
レージデバイスと、
少なくとも一つのネットワークと連結されて通信する一台以上のトランシーバーと、
前記一台以上のストレージデバイス及び前記一台以上のトランシーバーに連結されて動
作する一台以上のプロセッサーと、
を含み、
前記一台以上のプロセッサーは、
前記デバイスのロケーション及びアクティブなネットワークインターフェースに関する
、帯域幅パラメーター、コストパラメーター、及び待機時間パラメーターのうちの１以上
を含む情報を受け取ることと、
前記一組のルールと、前記デバイスの前記ロケーション及びアクティブなネットワーク
インターフェースに関して受け取った前記情報とに基づいてフロー制御決定を実行するこ
とと、
前記フロー制御決定の結果に基づいて、１以上のアクティブなアプリケーションセッシ
ョンに対応する１以上のフローのマッピングを更新することと、
を行うように構成されていることを特徴とするシステム。
【請求項３７】
前記一台以上のプロセッサーは、ネットワーク接続性が無い場合、又はポリシーがネッ
トワークの使用を強いない場合に、アプリケーションに対する途絶耐性サポートを可能に
するように更に構成されていることを特徴とする請求項３６に記載のシステム。
【請求項３８】
前記一台以上のプロセッサーは、アプリケーションシステムリソース使用度、時間、及
びデバイスタイプのうちの１以上に基づいてフロー制御決定を行うように更に構成されて
いることを特徴とする請求項３６に記載のシステム。
【請求項３９】
前記フロー制御決定を行うための前記一組のルールは、システム固有ポリシーであるこ
とを特徴とする請求項３６に記載のシステム。
【請求項４０】
前記フロー制御決定を行うための前記一組のルールは、アプリケーション固有ポリシー
であることを特徴とする請求項３６に記載のシステム。
【請求項４１】
前記フロー制御決定を行うための前記一組のルールは、グループ固有ポリシーであるこ
とを特徴とする請求項３６に記載のシステム。
【請求項４２】
複数のデバイスによるサービスの共有を可能にすることを更に含み、前記サービスの共
有は、アプリケーションサービス、及び前記複数のデバイスのハードウェアコンポーネン
トに関連するシステムサービスを前記複数のデバイスによって共有することを含み、１つ
のデバイスで実行される前記サービスのそれぞれは、対応する統一資源識別子に関連する
ことを特徴とする請求項１０に記載の方法。
【請求項４３】
前記フロー制御決定は、ポリシーエンジンを用いて行われ、前記ポリシーエンジンは、
前記デバイスを含むネットワークで分散され、前記ポリシーエンジンは、前記デバイスで
利用可能な第１の情報と、サービスプレーンにおける他のネットワークノードからの第２
の情報とに基づいて、前記フロー制御決定を行うことを特徴とする請求項１０に記載の方
法。
【請求項４４】
少なくとも１以上の前記システムパラメーターが閾値を超える場合に、１以上のアプリ
ケーションサービスの実行をクラウド環境へとオフロードすることを更に含むことを特徴
とする請求項４２に記載の方法。
【請求項４５】
少なくとも１以上の追加のリソース及びアプリケーションポリシー要件のために、１以
上のアプリケーションサービスの実行をクラウド環境へとオフロードすることを更に含む
ことを特徴とする請求項４３に記載の方法。
【請求項４６】
フロー制御決定を行うために、前記知識ベースに記憶されたデータを解析するための学
習アルゴリズムを用いることを更に含むことを特徴とする請求項１０に記載の方法。
【請求項４７】
前記学習アルゴリズムは、人工神経網ベースのアルゴリズム、及び、隠れマルコフベー
スのアルゴリズムのうちの少なくとも１つを含むことを特徴とする請求項４６に記載の方
法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、２０１２年６月６日に出願された米国仮特許出願第６１／６５６，１７６号及び２０１３年２月１２日に出願された米国仮特許出願第６１／７６３，６６５号に対する優先権を主張するものであり、これら仮出願は、全体として本明細書に参照により援用される。
【背景技術】
【０００２】
開示されている主題は、モバイル環境におけるネットワーキングシステムに関する。人々は、以前よりも一段と繋がり合うようになってきている。移動体通信及びインターネットは、この現象の中核をなすものである。モバイル環境は、種々のネットワークアクセス技術と、日常的に使用されているモバイルデバイス等の通信デバイスとの組み合わせとして定義され得る。モバイルアプリケーションは異なるネットワーク技術間で利用可能であり、また種々のネットワーキング、コンピューティング及び入出力機能を有する複数のデバイスからも利用可能である。ユーザーは、モバイルアプリケーションが複数のネットワーク技術間又は管理サービスドメイン間でシームレスに動作し、利用可能な最良のネットワークに常に接続され、また異なる通信デバイス間に接続されることを望むことがある。モバイルデバイスの増加とともに、より良いユーザーエクスペリエンスを提供するために、サービスプロバイダーはインフラストラクチャネットワークリソースを管理し、モバイルブロードバンドトラフィックを効率的に処理する必要にも駆られている。
【０００３】
例えばスマートフォン、タブレット及びラップトップ等、特定の通信デバイスは、通話、計算、動画及びデータ通信を提供する高い処理能力と移動性を有する。これらのデバイスは、Ｗｉ−Ｆｉ、ＷｉＭＡＸ、ＬＴＥ、場合によっては有線ＬＡＮ等、複数のネットワークインターフェースを有し得る。セルラーネットワークは、広範囲にわたる移動性を提供し、この移動性の適用範囲は、提供される適用範囲が限られたものにすぎないＷｉ−Ｆｉ等の他のネットワークと比べて広い。また、世界の殆どの地域において、同一の地理的領域に複数のサービスプロバイダーが存在し得る。しかしながら、通信デバイスには、一度に一つのネットワークインターフェースのみに接続され及び／又は一つのサービスプロバイダーのみに登録されるという制限があり得る。ある種のアプリケーションは、異種ネットワーク間でのシームレスなハンドオーバーを提供できるが、ユーザーは、特定のアプリケーション又はデータタイプに対しどのネットワークインターフェースを用いるかを制御できず、この機能を全てのアプリケーションに対して提供する一般的なフレームワークは存在しない。
【０００４】
通信、ストリーミング、オンラインゲーム、コラボレーションアプリケーション等のインターネットサービス、またデスクトップアプリケーションは、スマートフォン、タブレット、ラップトップ、また同様にＷｉ−Ｆｉ対応テレビ等、画面サイズ、処理能力、バッテリー要件の異なる種々のデバイスからアクセスすることができる。一つのアプリケーションを複数のデバイスに対応させることは、セッション及びパーソナルモビリティを必要とする。例えば、ユーザーは、ユーザーエクスペリエンスを改善するため又はバッテリーの問題のため、アクティブなセッションをスマートフォンからデスクトップＰＣに、又はビデオ通話をＷｉ−Ｆｉ対応画面や卓上電話に移動させたいことがある。しかしながら、移動性を有する場合、信号強度の減少、物理チャンネルの渋滞及び／又はネットワーク利用不能などといったために、一時的な通信の途絶を生じることがある。
【０００５】
ユーザーは、無線インターネットアクセスの全くない場所、又は、例えば外国旅行中等、どのネットワークにも簡単にはアクセスできない場所に移動することもある。従って、接続は断続的となることもあり、途絶は数秒、数時間、又は数日にもなり得る。ネットワーク接続が無い場合、デバイスソフトウェアは、適切なネットワークが見つかるまで、データの送信を遅らせることができる、即ち途絶耐性がある。ある種のアプリケーションはこの機能を使用するが、ユーザーは、特定のアプリケーション又はデータタイプに対してどのネットワークインターフェースを用いるのかを制御できず、この機能を全てのアプリケーションに対して提供する一般的なフレームワークは存在しない。
【０００６】
従って、シームレスなユーザーエクスペリエンスを提供し、複数のサービスプロバイダー及び／又は複数のネットワークインターフェースを使用することによりネットワークの全体的な堅牢性を改善し、シームレスなデバイス間通信を可能にするネットワーキングシステムが必要とされている。
【発明の概要】
【０００７】
開示されている主題の一態様によると、異種モバイル環境において統一ネットワーキングを提供するデバイスが提供される。このデバイスは、物理層を含むネットワークハードウェアと、１台以上のメモリー装置とを含む。１台以上のメモリー装置には、前記物理層の上に積み重ねられたリンク層と；前記リンク層の上に積み重ねられたネットワーク層と；前記ネットワーク層の上に積み重ねられたトランスポート層と；前記トランスポート層の上に積み重ねられたアプリケーション層と；前記物理層と前記リンク層との間における物理制御機能（ｐｈｙｓｉｃａｌ  ｃｏｎｔｒｏｌ  ｆｕｎｃｔｉｏｎ、ＰＣＦ）であって、スペクトルチャンネル設定を管理する物理制御機能と；前記リンク層と前記ネットワーク層との間のリンク制御機能（ｌｉｎｋ  ｃｏｎｔｒｏｌ  ｆｕｎｃｔｉｏｎ、ＬＣＦ）であって、ｍａｃアドレス及びルックアップテーブルの制御、リンク状態情報、制御情報、パフォーマンス情報、ネットワークパケットルックアップ、ネットワークからのデバイスの発見及び認証、ハンドオーバー遅延の最適化、及び仮想インターフェース設定の制御のうち１以上を提供するリンク制御機能と；前記ネットワーク層と前記トランスポート層との間のネットワーク制御機能（ｎｅｔｗｏｒｋ  ｃｏｎｔｒｏｌ  ｆｕｎｃｔｉｏｎ、ＮＣＦ）であって、ルーティングテーブル制御機能、マルチホーミング機能、モビリティ機能、マルチパス機能、及びオンデマンドエンド・ツー・エンドセキュリティ機能のうち１以上を提供するネットワーク制御機能と；前記アプリケーション層と前記トランスポート層との間の制御ミドルウェアであって、１以上のフローのマッピングを保持し、１以上のポリシーを保持し、前記１以上のポリシーに基づいたフロー制御決定を実行する制御ミドルウェアと、が記憶されている。
【０００８】
ある実施形態においては、前記制御ミドルウェアは、前記物理、リンク及びネットワーク制御機能を管理するように構成され得る。前記制御ミドルウェアは、マルチホーミング、モビリティ、マルチパス、サービス共有、途絶耐性、及びこれらの組み合わせのうち１以上を提供するように構成され得る。また、前記制御ミドルウェアは、ネットワーク、デバイス及び利用可能な物理スペクトルチャンネルの発見を管理するように構成され得る。前記制御ミドルウェアは、ネットワークアクセス制御のために、サービスアクセスマネージャーと通信するように構成され得る。前記制御ミドルウェアは、ネットワークマネージャーモジュールと、ロケーションマネージャーモジュールと、セキュリティマネージャーモジュールと、キューマネージャーモジュールと、サービス共有マネージャーモジュールと、システムマネージャーモジュールと、データストアと、ハンドオーバーをいつ実行するかを決定するポリシーエンジンと、を含み得る。
【０００９】
ある実施形態においては、前記ＮＣＦは、前記フローの存在期間内においてはモビリティイベントの場合でさえも変化しないフロー識別子を前記トランスポート層に提供するように構成され得る。前記ＮＣＦは、モビリティイベントを処理するために、モビリティマネージャーと通信するように構成され得る。前記ＬＣＦは、利用可能なネットワークの情報を提供するネットワーク情報マネージャーと通信するように構成され得る。前記ＰＣＦは、トランシーバースペクトル設定のために、スペクトルデータベースマネージャーと通信するように構成され得る。
【００１０】
開示されている主題の一態様によると、異種モバイル環境におけるデバイスの統一ネットワーキング方法が提供される。この方法は、アクティブなネットワークインターフェースを保持及び監視することと、前記デバイスのロケーションを管理することと、ネットワークアクセスセキュリティを管理することと、アプリケーションに対する途絶耐性サポートを可能にすることと、サービス共有及びセッションモビリティを可能にすることと、１以上のアクティブなアプリケーションセッションに対するシステムパラメーターを管理することと、１台以上のメモリー装置のストレージ機能を管理することと、前記１以上のアクティブなアプリケーションセッションに対応する１以上のフローに対するマッピングを保持し、１以上のポリシーを保持し、ポリシーエンジンを用いて前記ポリシーに基づいたフロー制御決定を行うことと、を含む。
【００１１】
ある実施形態においては、前記１以上のフローの各々は、前記デバイスと第２通信ノードとの間にデータパイプを含むことができ、前記１以上のフローの各々は、モビリティイベントの場合さえも不変であるフロー識別子によって識別される。本方法は、モビリティイベントの場合に中断されて再構成される少なくとも一つのＩＰアドレスによって識別される１以上のサブフローを更に含み得る。
【００１２】
ある実施形態においては、本方法は、前記ポリシーエンジンを用いてリアルタイムでフロー制御決定を行い、既存のフローを補完するか否かを決定することを更に含み得る。第１のネットワークインターフェースにより提供される第１のフローは第２のネットワークインターフェースに移動させることができる。
【００１３】
ある実施形態においては、本方法は、前記ポリシーエンジンを用いてリアルタイムでフロー制御決定を行い、パラレル補助接続によって既存のフローを補完するか否かを決定することを更に含み得る。第１のフローは、第１のネットワークインターフェースにより提供される第１のサブフローと、第２のネットワークインターフェースにより提供される第２のサブフローとを同時に含み得る。複数のフローを保持することができ、前記複数のフローの各々は、対応するネットワークインターフェースを有し得る。
【００１４】
ある実施形態においては、前記途絶耐性サポートは、ネットワーク接続性が無い場合、又はポリシーがネットワークの使用を強いない場合に提供され得る。前記ポリシーエンジンを使うことは、アクティブフローテーブルと、ポリシーテーブルと、エバリュエーターとを用いることを更に含み得る。
【００１５】
ある実施形態においては、前記ポリシーエンジンを用いて前記フロー決定を行うことは、ロケーション、時間、ネットワークコスト、ネットワーク帯域幅、ネットワーク待機時間、ネットワークの存在、ネットワークセキュリティ、デバイスセンサーデータ、アプリケーションリソース使用度、及びこれらの組み合わせからなる群から選択される現在の属性を評価することを含み得る。
【００１６】
ある実施形態においては、本方法は、前記システムパラメーターのうちの１以上が、１以上のアプリケーションに対する閾値を超える場合に、該アプリケーションの実行をクラウドへとオフロードすることを更に含み得る。それに加え又はその代わりとして、本方法は、１以上のアプリケーションが追加のリソースを必要とする場合に、該アプリケーションの実行をクラウドへとオフロードすることを更に含み得る。
【００１７】
ある実施形態においては、本方法は、インターフェース情報、時間情報、ロケーション情報、リソース情報、及び帯域幅情報のうちの１以上を含む過去のネットワーク情報を含む知識ベースを保持し更新することを更に含み得る。前記知識ベースを用いて地理ネットワークアクセスマップを作成し、当該地理ネットワークアクセスマップを用いてフロー決定を行いハンドオーバー待機時間を減少させ得る。
【００１８】
ある実施形態においては、ネットワークアクセスセキュリティを管理することは、資格情報を記憶し管理すること、複数のネットワークインターフェース及びデバイスに対してアクセスサービス認証を提供すること、セキュリティで保護されたモバイルハンドオーバーを提供すること、及びセキュリティで保護されたエンド・ツー・エンド通信を提供すること、のうちの１以上を含み得る。ネットワークアクセスに関する認証資格情報は、複数のネットワークインターフェース間でのリンク及びネットワーク制御機能プロトコルに対して再利用でき、更に、各アプリケーション毎に機密エンド・ツー・エンド通信パスを設定するために、汎用認証フレームワークを複数のネットワークインターフェース間で用いることができる。
【００１９】
ある実施形態においては、本方法は、信号強度、待機時間、利用可能帯域幅、ネットワークの存在、セキュリティパラメーター及びこれらの組み合わせからなる群から選択されるネットワークパフォーマンス属性を監視することと、前記ネットワークパフォーマンス属性のうちの１以上が所定の閾値を超える場合に、ネットワークイベントを作成することとを更に含み得る。前記ポリシーエンジンには、前記ネットワークイベントに関する信号を送ることができ、各アクティブアプリケーションセッションに関するポリシーを評価し、第１のネットワークインターフェースから第２のネットワークインターフェースへのハンドオーバーを実行するか否かを決定することができる。ハンドオーバー決定がなされた場合に、前記第２のネットワークインターフェースに対応する擬似アイデンティティ、認証メカニズム、及び資格情報を選択することを含むセキュリティマネージャーによって事前認証を実行することができる。ネットワーク認証リクエストは、前記セキュリティマネージャーによってリンク制御機能に対して伝えることができ、前記リンク制御機能によってネットワークアクセスプロシージャを実行することができ、認証結果を前記セキュリティマネージャーに返すことができる。前記認証結果を前記ポリシーエンジンに伝えることができ、前記デバイスが認証された場合に、前記第２のネットワークインターフェースに対するハンドオーバーを実行することができる。前記リンク制御機能は、再認証の生存時間を含むセッションキートークンを記憶することができ、前記生存時間は、前記デバイスの過去のネットワークアクセスパターンに基づいて調節することができる。
【００２０】
ある実施形態においては、サービス共有を可能にすることは、前記デバイス上に登録済みサービスを保持するためにサービス登録を提供することと、サービスリクエストを評価することと、フロー移行を実行して前記デバイスから他のデバイスへのセッションモビリティを実行することとを含み得る。サービス登録を提供することは、前記ポリシーエンジンにおいてサービスに対するサービス登録リクエスト受け取ることと、前記サービス登録リクエストをサービス共有マネージャーに渡すことと、前記サービスを前記サービス共有マネージャー内のサービス登録テーブルに登録することと、前記サービスを複数の接続済みデバイスに同時に配信することとを含み得る。サービスリクエストを評価することは、前記ポリシーエンジンにおいて、アプリケーションからサービスに関するサービスリクエストを受け取ることと、前記サービスリクエストをサービス共有マネージャーに渡すことと、前記サービスについて前記サービス共有マネージャー内のサービス登録テーブルを調べることと、前記サービス登録テーブル内に前記サービスが見つかった場合に、サービスを評価してサービススコアが閾値を超えているか否かを決定することと、前記サービススコアが前記閾値を超えている場合、前記アプリケーションに前記サービスについて通知することとを含み得る。フロー移行を実行することは、前記ポリシーエンジンにおいて、アプリケーションからサービス移行リクエストを受け取ることと、前記サービス移行リクエストをサービス共有マネージャーに渡すことと、前記サービス移行リクエストを調べ、前記サービス共有マネージャー内のサービス登録テーブルからデバイス詳細を取得することと、サービス共有マネージャーによって第２のデバイスへの前記フロー移行を開始することと、前記デバイスと前記第２のデバイスとにおいてフローを同期させることと、前記アプリケーションに移行結果を通知することとを含み得る。
【００２１】
ある実施形態においては、前記デバイスは、サーバー及びルーターからなる群から選択されるネットワークエレメントであってもよい。本方法は、前記ネットワークエレメントにおいてサービスリクエストを受け取ることと、サービスマッチに関してサービステーブルを調べることと、マッチが見つかった場合にサービス応答を返すことと、マッチが見つからなかった場合に、前記サービスリクエストを転送することとを更に含み得る。本方法は、複数のデバイスに関する過去のネットワークアクセスデータを含む知識ベースを保持し更新することを更に含み得る。前記知識ベースを用いて、前記過去のネットワークアクセスデータに基づき、デバイスに事前にサービスを提供できる。前記サービスは、分散型サービス拒否攻撃を検出するセキュリティ対策、セキュリティイベントを理解するためのフォレンジクス、前記ネットワーク内でのユーザー装置（ｕｓｅｒ  ｅｑｕｉｐｍｅｎｔ、ＵＥ）の詳細な行動の提供、ロケーションベースサービス、及びフォレンジクスのうちの１以上を含み得る。
【００２２】
開示されている主題の一態様によると、コンピューターが実行可能な命令を含む、異種モバイル環境内でデバイスを動作させるための非一時的コンピューター可読媒体が提供され、前記命令は、実行時に、１以上のデバイスに統一ネットワーキングの方法を実行させる。前記方法は、アクティブなネットワークインターフェースを保持及び監視することと、前記デバイスのロケーションを管理することと、ネットワークアクセスセキュリティを管理することと、アプリケーションに対する途絶耐性サポートを可能にすることと、サービス共有及びセッションモビリティを可能にすることと、１以上のアクティブなアプリケーションセッションに対するシステムパラメーターを管理することと、１台以上のメモリー装置のストレージ機能を管理することと、前記１以上のアクティブなアプリケーションセッションに対応する１以上のフローに対するマッピングを保持し、１以上のポリシーを保持し、ポリシーエンジンを用いて前記ポリシーに基づいたフロー制御決定を行うことと、を含む。前記非一時的コンピューター可読媒体は、前述のデバイス及び方法における付加的特徴のいずれをも含み得る。
【００２３】
開示されている主題の一態様によると、異種モバイル環境においてデバイスに対するネットワーク接続を管理するシステムが提供される。前記システムは、１以上のアクティブなアプリケーションセッションに対応する１以上のフローに対するマッピングを保持し、フロー制御決定を実行するための一組のルールが記憶された一台以上のストレージデバイスを含む。前記一組のルールはポリシーベースである。前記システムは、少なくとも一つのネットワークと連結されて通信をする一台以上のトランシーバーと、前記一台以上のストレージデバイス及び前記一台以上のトランシーバーに連結されて動作する一台以上のプロセッサーとを更に含む。前記一台以上のプロセッサーは、前記デバイスのロケーション及びアクティブなネットワークインターフェースに関する、帯域幅パラメーター、コストパラメーター及び待機時間パラメーターのうちの１以上を含む情報を受け取り、前記一組のルールと、前記デバイスの前記ロケーション及びアクティブなネットワークインターフェースに関して受け取った前記情報と、アプリケーションシステムリソース使用度、時間、及びデバイスタイプのうちの１以上とに基づいてフロー制御決定を実行し、前記フロー制御決定の結果に基づいて、１以上のアクティブなアプリケーションセッションに対応する１以上のフローのマッピングを更新するように構成される。本システムは、各アプリケーション毎に、ネットワークアクセスのより細分化された制御をもたらすことができる。本システムは、前述のデバイス、方法、及び／又は非一時的コンピューター可読媒体における付加的特徴のいずれをも含み得る。
【図面の簡単な説明】
【００２４】
【図１】開示されている主題の一態様における、２つの通信ノード間のフローを示す図。
【図２】開示されている主題の一態様における、変更されたインターネットプロトコルスイートを例示する図である。
【図３】開示されている主題の一態様における、マルチホーミングの例を示す図。
【図４】開示されている主題の一態様における、ターミナルモビリティイベントの例を示す図。
【図５】開示されている主題の一態様における、ネットワークモビリティイベントの例を示す図。
【図６】開示されている主題の一態様における、セッションモビリティイベントの例を示す図。
【図７】開示されている主題の一態様における、マルチパス機能を例示する図。
【図８】開示されている主題の一態様における、ネットワーク制御機能の例を示す図。
【図９】開示されている主題の一態様における、ネットワーク制御機能プロトコルの受動的選択を例示する図。
【図１０】開示されている主題の一態様における、アイデンティティ・ロケーション解決を例示する図。
【図１１】開示されている主題の一態様における、リンク制御機能の例を示す図。
【図１２】開示されている主題の一態様における、物理制御機能の例を示す図。
【図１３】開示されている主題の一態様における、装置にスペクトル可用性情報を提供する基地局の例を示す図。
【図１４】開示されている主題の一態様における、ネットワーキングスタックの例を示す図。
【図１５】開示されている主題の一態様における、種々のサービスドメインを示す図。
【図１６】開示されている主題の一態様における、複数のインフラストラクチャプロバイダーを有するＩＳＰのサービス・インフラストラクチャプレーンの例を示す図。
【図１７】開示されている主題の一態様における、制御ミドルウェアの例を示す図。
【図１８】開示されている主題の一態様における、データストアの例を示す図。
【図１９】開示されている主題の一態様における、データストアのサブモジュールの例を示す図。
【図２０】開示されている主題の一態様における、ロケーションマネージャーの例を示す図。
【図２１】開示されている主題の一態様における、ネットワークマネージャーの例を示す図。
【図２２】開示されている主題の一態様における、セキュリティマネージャーの例を示す図。
【図２３】開示されている主題の一態様における、キューマネージャーの例を示す図。
【図２４】開示されている主題の一態様における、システムマネージャーの例を示す図。
【図２５】開示されている主題の一態様における、グローバルＩＤ及びアプリケーションＩＤの例を示す図。
【図２６】開示されている主題の一態様における、ポリシーエンジンの例を示す図。
【図２７】開示されている主題の一態様における、例示的制御ミドルウェアによって制御されたデータフローパイプを示す図。
【図２８】開示されている主題の一態様における、ポリシーを定義できる種々のレベルを示す図。
【図２９】開示されている主題の一態様における、ユーザー空間制御ミドルウェアライブラリ用のソケットプロキシ機能を例示する図。
【図３０】開示されている主題の一態様における、ソケットプロキシサーバー及びクライアントの例を示す図。
【図３１】開示されている主題の一態様における、データストア内の集中ストレージの例を示す図。
【図３２】開示されている主題の一態様における、分散ストレージを例示する図。
【図３３】開示されている主題の一態様における、スキーマベース及びドキュメントベースストレージの例を示す図。
【図３４】開示されている主題の一態様における、モジュール固有データ及びアルゴリズムを例示する図。
【図３５】開示されている主題の一態様における、ミドルウェア最適化のために解析済みデータを用いた例を示す図。
【図３６】開示されている主題の一態様における、日常的経路を用いたネットワーク選択の最適化の例を示す図。
【図３７】開示されている主題の一態様における、知識プレーンの例を示す図。
【図３８】開示されている主題の一態様における、サービス及びインフラストラクチャ論理プレーンの例を示す図。
【図３９】開示されている主題の一態様における、モバイルハンドオーバー及び例示的制御ミドルウェアを示す図。
【図４０】開示されている主題の一態様における、ＥＡＰ−ＡＫＡ交換の例を示す図。
【図４１】開示されている主題の一態様における、サービス共有マネージャーの例を示す図。
【図４２】開示されている主題の一態様における、サービス登録の例を示す図。
【図４３】開示されている主題の一態様における、デバイス発見及びメタデータ共有を例示する図。
【図４４】開示されている主題の一態様における、サービスリクエスト及び解決を例示する図。
【図４５】開示されている主題の一態様における、サービスコントローラー及びサービステーブルを例示する図。
【図４６】開示されている主題の一態様における、サービスルーターの構成を例示する図。
【図４７】開示されている主題の一態様における、アプリケーション、セッション状態転送の例を示す図。
【図４８】開示されている主題の一態様における、フロー移行の例を示す図。
【図４９】開示されている主題の一態様における、サービスルーティング及びパケットルーティングの例を示す図。
【図５０】開示されている主題の一態様における、データセンターにおけるサービスルーティングの例を示す図。
【図５１】開示されている主題の一態様における、ルーターにおけるサービス及びパケットルーティングの例を示す図。
【図５２】開示されている主題の一態様における、ネットワークインフラストラクチャにおけるサービスルーティングの例を示す図。
【図５３】開示されている主題の一態様における、サービスリクエストフローの例を示す図。
【図５４】開示されている主題の一態様における、モビリティ及びサービスゲートウェイの例を示す図。
【図５５】開示されている主題の一態様における、ネットワークサービスクラウドの例を示す図。
【図５６】開示されている主題の一態様における、ネットワーククラウドを用いたＡＳＰの例を示す図。
【図５７】開示されている主題の一態様における、サービスロケーションに基づいたネットワーク待機時間を例示する図。
【図５８】開示されている主題の一態様における、ネットワークアクセスログサービスを例示する図。
【図５９】開示されている主題の一態様における、知識プレーンの例を示す図。
【図６０】開示されている主題の一態様における、ネットワーク内データマイニングの例を示す図。
【図６１】データストアの動作例を示すフローチャート。
【図６２】ロケーションマネージャーの動作例を示すフローチャート。
【図６３】ネットワークマネージャーの動作例を示すフローチャート。
【図６４】セキュリティマネージャーの動作例を示すフローチャート。
【図６５】キューマネージャーの動作例を示すフローチャート。
【図６６】システムマネージャーの動作例を示すフローチャート。
【図６７】ポリシーエンジンの動作例を示すフローチャート。
【図６８】サービス共有マネージャーの動作例を示すフローチャート。
【発明を実施するための形態】
【００２５】
開示されている主題の一態様は、ネットワーク及びユーザー機器の双方とは独立し得る、異種モバイル環境における統一ネットワーキングシステム用のソフトウェアアーキテクチャに関する（本明細書において、以下の用語「ユーザー機器」、「ＵＥ」、「デバイス」、「モバイルノード」及び「ＭＮ」は区別なく用いられる）。このアーキテクチャは、コンテキストアウェア制御ミドルウェア（Ｃｏｎｔｅｘｔ  ａｗａｒｅ  Ｃｏｎｔｒｏｌ  Ｍｉｄｄｌｅｗａｒｅ、ＣＣＭ）と称される制御ミドルウェアを、アプリケーション層とトランスポート層との間に含むことができ、このミドルウェアは、全ネットワークインターフェースの統一された抽象的概念をアプリケーション層へ提供する。このミドルウェアは、マルチホーミング機能、モビリティ機能（例えば、端末、ネットワーク及びセッションモビリティ機能）、マルチパス機能、サービス共有機能及び途絶耐性機能を抽象化することができる。また、本アーキテクチャは、（現時点での及び将来的な）トランスポート、ネットワーク、リンク及び物理層プロトコルのいずれとも独立したものとすることができる。本アーキテクチャによると、アプリケーションを、デバイス−デバイス間、ネットワークデバイス間、又はデバイス−ネットワーク間通信における複雑性を処理することから解放することができる。
【００２６】
開示されている主題の一態様において、本アーキテクチャは、フローの概念を、それぞれのフロー識別子（ＩＤ）により識別される２つの通信ノード間の論理データパイプとして定義する。これらフロー識別子は、フローの存在期間中は不変である。トランスポートプロトコルは、通信のためにＩＰアドレスではなくフロー識別子を用いることができる。サブフローは、２つの通信ノード間の、ＩＰアドレスを用いた接続として定義することができる。フローは多数のサブフローを含み得る。ＩＰアドレスのうちのいずれかが変わった場合、サブフローは中断され再構成される（例えば停止及び／又は移行される）。ＩＤはフローの存在期間中は不変であるため、デバイスモビリティイベントのためにＩＰアドレスが変わってしまった場合であっても、トランスポートプロトコルセッションは有効であり続けられる。図１は、２つの接続（即ち、サブフロー１及びサブフロー２）を有する論理フローを示すが、これは限定をするのではなく説明を目的とするものである。両端におけるＩＤ（即ち、ＩＤ１及びＩＤ２）はフローの存在期間中は不変である。
【００２７】
開示されている主題の他の態様によると、図２に限定をするのではなく説明を目的として示すように、その他の独立した制御機能又は層が、インターネットプロトコルスイート内のトランスポート層２０１、ネットワーク層２０２、リンク層２０３及び物理層２０４の間に提供される。トランスポート層２０１とアプリケーション層２０６との間に位置する制御ミドルウェア２０５はこれらの機能を管理することができる。ミドルウェア２０５は複数のインターフェースを管理でき、モビリティ決定を行うことができ、アプリケーション及びデバイスリソース共有を可能とし、途絶耐性サポートを提供でき、ネットワーク、デバイス及び利用可能な物理スペクトルチャンネルの発見を管理できる。制御ミドルウェア２０５は、ポリシーベースモジュール意志決定システムを提供でき、これは既存のフローに適当なパラレル補助接続を追加又は補完し、ユーザーエクスペリエンス、性能及び信頼性を改善する。
【００２８】
図２に示すように、ネットワーク制御機能（Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ、ＮＣＦ）２０７はトランスポート層２０１とネットワーク層２０２とを機能的に分離し、これにより、上位層に変更を加えることなく任意の将来的なネットワークプロトコルをネットワーキングスタックに追加可能としている。ＮＣＦ２０７は、例えば、ルーティングテーブル制御機能、マルチホーミング機能、モビリティ機能及びマルチパス機能を可能にすることができる。
【００２９】
図３に限定をするのではなく説明を目的として示すように、マルチホーミングは、個々のフローに対して異なるインターフェースを使用する機能を提供することができる。マルチホーミングにおいて、フローとインターフェースは一対一に対応する。図３Ａに示すように、ポート８０、４４３及び２３における３個のフローはそれぞれ異なるインターフェースを使用している。即ち、８０はＬＴＥを使用し、４４３はＷｉＦｉを使用し、２３はイーサーネットを使用している。一例として、図３Ｂに示すように、ＬＴＥインターフェースが使用不可となった場合（例えば、ネットワークの有効範囲外である場合）、ポート８０のフローをＷｉ−Ｆｉインターフェースに転じることができる。
【００３０】
ＮＣＦ２０７は３種のモビリティ、即ちターミナル、ネットワーク及びセッションモビリティを可能にする。モビリティは同種、つまり同一の技術内のものであってもよく、また異種、つまり異なる技術に亘るもの（技術間モビリティ）であってもよい。図４に限定をするのではなく説明を目的として示すように、ターミナルモビリティとは、ユーザー機器（ｕｓｅｒ  ｅｑｕｉｐｍｅｎｔ、ＵＥ）が一つのネットワークから他へと移動することを意味する。図４Ａにおいて、ＵＥはＬＴＥインターフェースを使用しているが、図４Ｂにおいて全トラフィックはＷｉ−Ｆｉに移行している。ネットワークモビリティは、１以上のＵＥがルーターに接続され、ルーターが、ＵＥ−ルーター接続に影響を及ぼすこと無くターミナルモビリティを実行することを意味する。
【００３１】
図５はネットワークモビリティイベントを示すが、これは限定をするのではなく説明を目的とするものである。図５Ａにおいて、ＵＥ１及びＵＥ２は、Ｗｉ−Ｆｉインターフェースを利用してモバイルルーターに接続され、ルーターは、ＬＴＥインターフェースを利用してインターネットに接続されている。図５Ｂにおいて、モバイルルーターはターミナルモビリティを実行しＷｉ−Ｆｉへと移行するが、ＵＥとモバイルルーター間の全接続は依然としてＷｉ−Ｆｉインターフェースを使用している。セッションモビリティとは、フローが一つのＵＥから他のＵＥに完全に移行することを意味し、ＵＥ間でアプリケーション固有セッションデータの同期が必要とされる。
【００３２】
図６は、ＵＥ１とＵＥ２との間でのセッションモビリティを示すが、これは限定をするのではなく説明を目的とするものである。図６Ａにおいて、ＵＥ２はＷｉ−Ｆｉインターフェースを介してサーバーと接続されている。ＵＥ１は近くにあり、ＵＥ２は、アクティブなセッションをＵＥ１に移行することを決定する。セッションモビリティの後、このセッションはサーバーとポート８０上で実行されているアプリケーションとの間で依然としてアクティブであるが、図６Ｂに示すように、このアクティブなセッションは、ＬＴＥインターフェースを介してＵＥ１上にある。セッションモビリティは、ネットワーク制御機能における不変フロー識別子を用いて実現することができ、更なる詳細は後述するが、この識別子はデバイス間で共有することができる。
【００３３】
マルチホーミングの場合、フローとインターフェースとの間には、常に一対一の関係があるが、マルチパスの場合、フローは異なるインターフェースを有する複数のサブフローを有することができ、フローとデバイスインターフェースとの間には一対多数の関係が生じる。図７はマルチパス機能を示すが、これは限定をするのではなく説明を目的とするものである。ここで、ポート８０上で実行されるフローは、ＬＴＥとＥＴＨインターフェースを同時に使用している。
【００３４】
ＮＣＦ２０７は、上層、即ちトランスポート層に対して、不変フロー識別子（ｉｄｅｎｔｉｆｉｅｒ、ＩＤ）を提供でき、この識別子はフローの存在期間中は不変である。この識別子は、動的に生成でき、ローカルに設定でき、アプリケーション固有（例えば、フローを生成する際に、各アプリケーションはそれ自身の識別子を提供する）であるか又はサードパーティーによって割り当てることができる。各ＵＥに対して複数の識別子を設定することができる。動的識別子の場合、これらはフローの作成時に生成することができる。
【００３５】
図８は、ＩＰアドレスプール８０２を制御するＮＣＦ８０１セマンティクスを示すが、これは限定をするのではなく説明を目的とするものである。ＮＣＦ８０１は、トランスポート層８０３とネットワーク層８０４との間に位置する。モビリティサポートを提供するため（例えば両通信ノードがモバイルである場合）、モビリティマネージャー（ｍｏｂｉｌｉｔｙ  ｍａｎａｇｅｒ、ＭＭ）８０５ネットワークエレメントが設けられ、二つの通信ノードのランデブーポイントとして働く。別法として、ＭＭサポートが無い場合、ＵＥは日和見（ｏｐｐｏｒｔｕｎｉｓｔｉｃ）モードで動作し、このモードにおいて、ＵＥはモビリティイベントの更新を、全てのアクティブな接続関係にあるノード（ｃｏｒｒｅｓｐｏｎｄｅｎｔ  ｎｏｄｅ、ＣＮ）に対して直接送信する。図８に示すように、コントローラー８０６は、制御プレーンをデータプレーンから分離して、オペレーティングシステムのユーザー空間又はカーネル空間に実装することができる。カーネル空間メモリーは、オペレーティングシステムによって排他的に管理でき、ＯＳカーネル、カーネルエクステンション、及びデバイスドライバーを実行するために使用でき、ランタイムパフォーマンスの改善を提供することができる。ユーザー空間メモリーは、ソフトウェアに対しより高い柔軟性を提供する。例えばメモリーは、プログラムの実行に基づきディスクにスワップできる。更に、ＮＦＣは、ローカルコントローラーによって制御でき、又はリモートシステムから制御でき、結果として制御はローカルデバイスから更に分離される。
【００３６】
一実施形態によると、既存のＩＰｖ６ネーム空間（１２８ビット）を、現時点で利用可能な技術、例えばホストアイデンティティプロトコル（Ｈｏｓｔ  Ｉｄｅｎｔｉｔｙ  Ｐｒｏｔｏｃｏｌ、ＨＩＰ）やモバイルＩＰｖ６（ＭＩＰｖ６）と組み合わせて用いることができる。制御ミドルウェアは、接続関係にあるノード（ｃｏｒｒｅｓｐｏｎｄｅｎｔ  ｎｏｄｅ、ＣＮ）の行先アドレスに基づいてＮＣＦプロトコルを動的に選択できる。
【００３７】
ＮＣＦプロトコルの選択は、能動及び受動モードで行うことができる。能動モードにおいて、制御ミドルウェアは、設定制御パケットをＣＮに送信し、次いでＣＮは自身の設定を返答する。図９に限定をするのではなく説明を目的として示すように、受動モードにおいて、制御ミドルウェアは、ホストアイデンティティタグ（Ｈｏｓｔ  Ｉｄｅｎｔｉｔｙ  Ｔａｇ、ＨＩＴ）に対するＤＮＳクエリー応答を傍受し、ＤＮＳ解決がＨＩＴタグを含む場合には、ＤＮＳ解決をアプリケーションへ渡し、アプリケーションにＨＩＰを既定として使用することを強いる。ＨＩＴは、公開−秘密鍵ペアのハッシュを利用して、一意なアイデンティティを各ＵＥに与えることができる新たなネーム空間を提供する。これらのＨＩＴタグは、ＮＣＦ識別子８０７（図８）として使用することができる。ＩＰｖ６ネーム空間に対応するために、ＨＩＴタグは１２８ビット長であってよく、ＩＰｖ４トランスポートプロトコルに対応するために、ＨＩＴタグは３２ビット長であってもよい。更に、アプリケーションはそれら自身を変更して、受動及び能動モードのいずれをも用いずに優先度をＨＩＴタグに与えることができる。ＣＮがＮＣＦプロトコルに対応していない場合、ＣＮは普通のＴＣＰ／ＩＰプロトコルに戻ることができる。
【００３８】
図１０は、開示されている主題の一態様におけるアイデンティティ及びロケーション解決を示すが、これは限定をするのではなく説明を目的とするものである。ネットワーク内のアイデンティティ解決システム（Ｉｄｅｎｔｉｔｙ  Ｒｅｓｏｌｕｔｉｏｎ  Ｓｙｓｔｅｍ、ＩＲＳ）（例えば、ＤＮＳ及び分散ハッシュテーブル（Ｄｉｓｔｒｉｂｕｔｅｄ  Ｈａｓｈ  Ｔａｂｌｅ、ＤＨＴ）解決）に対するサポートがある場合、アプリケーションはＨＩＰプロトコルを既定として利用できる。ＩＲＳは、完全修飾ドメイン名（Ｆｕｌｌｙ  Ｑｕａｌｉｆｉｅｄ  Ｄｏｍａｉｎ  Ｎａｍｅ、ＦＱＤＮ）からアイデンティティ（１２８ビット）への解決を行い、例えばｗｗｗ．ｃｏｌｕｍｂｉａ．ｅｄｕ（ＦＱＤＮ）から２００１：２０：：２（アイデンティティ）を得ることができる。ロケーション解決に関しては、ＤＮＳシステムを使用することできる（例えば、クエリーはアイデンティティとしてｗｗｗ．ｃｏｌｕｍｂｉａ．ｅｄｕの代わりにキー２００１：２０：：２を持つこともできる）。
【００３９】
一実施形態において、リンク層１１０１（図１１）は、インターフェースを提供し、種々の物理ネットワーク、例えばイーサーネット、Ｗｉ−Ｆｉ、ＬＴＥ、ＷｉＭＡＸ等１１０２（図１１）を利用した接続を可能にする。開示されている主題によると、リンク制御機能（Ｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ、ＬＣＦ）１１０３は、ネットワークとリンク層１１０１とを機能的に分離する。リンク制御機能は、図１１に示されているが、これは限定をするものではなく説明を目的とするものである。ＬＣＦ１１０３は、例えば、ｍａｃアドレス及びルックアップテーブル制御、同種及び異種ネットワークにおけるハンドオーバー遅延の最適化、リンク状態情報（例えばアップ又はダウン）、リンク制御情報（例えばオン、オフ又はスタンバイ）、リンクパフォーマンス情報、ネットワークパケットルックアップ、ネットワーク／デバイスの発見及び認証、及び仮想インターフェース（即ち単一の物理ネットワークインターフェースを利用して同時に複数のネットワークに接続する場合であって、これは並列ネットワークアクセスを可能にする）設定のための制御を提供可能である。任意の（現時点での又は将来の）リンク層技術を、上位層に変更を加えることなく追加できる。図１１に示すように、ネットワーク情報マネージャー（Ｎｅｔｗｏｒｋ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｍａｎａｇｅｒ、ＮＩＭ）１１０４ネットワークエレメントを用いて、ハンドオーバー決定を下すために、近接ネットワーク情報（例えば、帯域幅、コスト等）をＬＣＦコントローラー１１０５に提供する。コントローラー１１０５は、コマンドを送信し、ＬＣＦ制御イベントを受信する。ＬＣＦはローカルコントローラーによって制御でき、又はリモートシステムから制御でき、制御はローカルデバイスから更に分離される。ＮＩＭ１１０４が設定されていない場合、ＬＣＦ１１０３は、日和見モードで動作し近接ネットワーク情報を収集する。ＮＣＦにおけるＩＰアドレスプールと同様に、ＬＣＦもロジカルインターフェースプール１１０６の制御を提供する。ロジカルインターフェースプール１１０６は、デバイスの近傍において、各インターフェース（例えば物理又は仮想インターフェース）の接続に利用可能なアクティブなネットワークの組を表す。一実施形態においては、ＩＥＥＥ８０２．２１ＭＩＨフレームワークを使用して複数のリンクインターフェースを管理する。これはインターフェース可用性情報、リンク層情報（例えば、信号強度）、ネットワーク事前認証を提供し、モバイルハンドオーバーを実行する。
【００４０】
開示されている主題の一態様において、図１２は、（図２における）ＰＣＦ２０９機能を示すが、これは限定をするものではなく説明を目的とするものである。物理制御機能（Ｐｈｙｓｉｃａｌ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ、ＰＣＦ）１２０１は、物理層１２０２とリンク層とを機能的に分離し、ＲＦトランシーバー制御を提供して最適なスペクトルチャンネル選択を可能とするが、これはリンクインターフェース技術に特有なものである。スペクトルデータベースマネージャー（Ｓｐｅｃｔｒｕｍ  Ｄａｔａｂａｓｅ  Ｍａｎａｇｅｒ、ＳＤＭ）１２０３は、ロケーションベースのスペクトル可用性を管理することができ、スペクトル設定をコントローラー１２０４に提供することができる。例えば、ＴＶホワイトスペーススペクトルを使用する場合、ＵＥがニューヨーク市にあるときは、４５０ＭＨｚチャンネルが使用できる。ＵＥがＤＣエリアに移動したときは、ＳＤＭによって４７５ＭＨｚチャンネルが動的に設定され得る。ＳＤＭサポートが無い場合、ＵＥは日和見モードで動作し、最適なチャンネル使用決定を下すために、現在のロケーションに関するスペクトル情報を収集する。日和見的なスペクトルの使用はコグニティブ無線として知られている。これはワイヤレススペクトル内の利用可能なチャンネルを自動的に検知しそれに応じて自身の送信又は受信パラメーターを変更するトランシーバーであり、その地点で与えられたスペクトル帯域においてより多くの無線通信を同時に実行可能にする。このプロセスは、動的スペクトル管理としても知られている。コントローラーは、制御プレーンアクセスを提供し、トランシーバースペクトル設定のためにＳＤＭと通信する。ＰＣＦはローカルコントローラーによって制御でき、又はリモートシステムから制御でき、制御はローカルデバイスから更に分離される。図１２に示すように、ＮＣＦにおけるＩＰアドレスプールと同様に、ＰＣＦは、各ネットワークインターフェースにおいて利用可能なスペクトルチャンネル用のロジカルスペクトルチャンネルプール１２０５を制御する。
【００４１】
インフラストラクチャプロバイダーがＳＤＭをＵＥに公開したくない場合、各基地局は、物理的ロケーションベースのスペクトル可用性情報を含むことができ、これはＳＤＭを介して得ることができる。基地局は、スペクトル可用性の変化に伴い動的に設定することができる。例えば、図１３に限定をするのではなく説明を目的として示すように、ロケーション１にある基地局は、５８０〜６００ＭＨｚチャンネルを使用するトランシーバーを有し、ＳＤＭスペクトルデータベースから自身のロケーションに対するスペクトル変化を受け取っている。６４０〜６６０ＭＨｚチャンネルが一時的に利用不可となった場合、スペクトル変化イベントが基地局に配信され、ＵＥのＰＣＦによって新しいチャンネルが設定され、これにより同時通信用に両チャンネルが開放される。
【００４２】
開示されている主題によると、ネットワーク、リンク及び物理層の分離は、対応する制御機能によって行うことができる。制御ミドルウェアは、個々のコントローラーを管理するが、これらのコントローラーは、各制御機能に対応したネットワークエレメント、即ちＮＣＦ用としてモビリティマネージャー、ＬＣＦ用としてネットワーク情報マネージャー、及びＰＣＦ用としてスペクトルデータベースマネージャー、と通信する。これらのネットワークエレメントは、物理的に独立した複数のサーバーに配置でき、又は一台の物理的マシン上の個々のサーバープロセスに配置することもできる。これらは分散した形で実装、配置することもでき、例えば、モビリティマネージャーは、ＵＥの地理的ロケーションに基づいてＵＥを取り扱う、分散クラスターベースシステムであり得る。
【００４３】
開示されている主題によると、一実施形態において、ＵＥは、ネットワークエレメントが存在しない場合であっても動作可能である。この場合、ＵＥは日和見モードで独立して動作する。制御機能も互いに独立であり、一つの制御機能の存在は、他の制御機能に影響を及ぼさない。ネットワーク制御機能は、ＵＥに対して、例えばルーティングテーブル制御、モビリティ、マルチホーミング、マルチパス及びアイデンティティを提供できる。リンク制御機能は、ｍａｃアドレステーブル及びルックアップテーブルの制御、並びにハンドオーバーの最適化を管理でき、ネットワークインターフェース情報、リンク状態（アップ／ダウン）、リンク制御（オン／オフ／スタンバイ）、リンクパフォーマンス情報、ネットワークパケットルックアップ、ネットワークからのデバイスの発見及び認証、及び仮想インターフェース設定のための制御を提供する。物理制御機能は、スペクトルチャンネル設定（リンク技術固有）を管理することができる。制御ミドルウェアは、ＮＣＦ、ＬＣＦ及びＰＣＦコントローラーとともに、全てのアクティブなフローを管理し、データパスと制御パスとの分離を可能とする。
【００４４】
図１４は、開示されている主題におけるネットワーキングスタックの全体をネットワークエレメントとともに示すが、これは限定をするのではなく説明を目的とするものである。制御ミドルウェアは、ＧＵＩを介してユーザーから入力（例えばポリシー）を取得し、ＡＰＩを介してアプリケーションを取得し、サービスアクセスマネージャー（ｓｅｒｖｉｃｅ  ａｃｃｅｓｓ  ｍａｎａｇｅｒ、ＳＡＭ）を介してサービスプロバイダーを取得できる。
【００４５】
開示されている主題の一態様によると、サービスドメインはインフラストラクチャプロバイダーとして定義され、これは一種類の技術（例えばＬＴＥ、ＷｉＭＡＸ、又はＷｉ−Ｆｉ）又は複数の技術（例えばＬＴＥ及びＷｉ−Ｆｉ）を用いたネットワークアクセスを提供する。ＵＥは、ドメイン内又はドメイン間の技術間モビリティを有し得る。ドメイン間モビリティは、同一技術内のものであってもよい。図１５は、ドメイン及び技術を二軸に沿って示し、３種の異なるドメイン、即ちＬＴＥ及びＷｉ−Ｆｉアクセスを提供するドメイン１、ＬＴＥアクセスを提供するドメイン２、及びＷｉ−Ｆｉアクセスを提供するドメイン３、が示されているが、これは限定をするのではなく説明を目的とするものである。
【００４６】
一実施形態において、例えば図１４に示す開示されている主題のネットワークエレメントを用いて、モジュラーインターネットサービスプロバイダー（Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ、ＩＳＰ）アーキテクチャを作成することができる。開示されている主題において、本物理ネットワークインフラストラクチャを２個の論理プレーン、即ちサービスプレーン及びインフラストラクチャプレーンに分離することができる。サービスプレーンは、ネットワークサービスに焦点を合わせたものとすることができ、全ＵＥのアクセスコントロール、モビリティ、及び異種サービスドメイン間でのＵＥのアクセスコントロールの任を負うことができる。サービスプレーンは、提案されたアーキテクチャにおける全ネットワークエレメント（即ちＳＡＭ１４１０、ＭＮ１４１１、ＮＩＭ１４１２及びＳＤＭ１４１３）を含み得る。ＳＡＭはネットワークアクセスを制御、管理し、ＭＮはモビリティを処理し、ＮＩＭはハンドオーバー決定のために追加のネットワーク情報を提供し、ＳＤＭは、ロケーションベーススペクトル可用性を管理し、スペクトル設定をＵＥに提供する。
【００４７】
図１６は、複数のインフラストラクチャプロバイダー（即ちプロバイダー１  １６０１及びプロバイダー２  １６０２）を有するＩＳＰのサービスプレーン及びインフラストラクチャプレーンを示すが、これは限定をするのではなく説明を目的とするものである。インフラストラクチャプレーン１６０３は、物理ネットワークインフラストラクチャに焦点を合わせたものである。このようにして、サービスプロバイダーを物理インフラストラクチャプロバイダーから分離でき、サービスプロバイダーがサービスを複数のインフラストラクチャプロバイダー間で提供可能となり、その結果、よりスケーラブルなネットワークサービスが得られる。また、複数のサービスプロバイダーは、一実施形態においてはソフトウェア・デファインド・ネットワーク（ｓｏｆｔｗａｒｅ  ｄｅｆｉｎｅｄ  ｎｅｔｗｏｒｋ、ＳＤＮ）メカニズムを用い、同一の物理インフラストラクチャリソースを共有することができる。ＳＤＮは、制御プレーンをデータプレーンから分離することによりコンピューターネットワークを構築可能とし、ネットワークをオンデマンドで設定、管理できる。サービスプレーン及びインフラストラクチャプレーンは、サービスゲートウェイ１６０４、及びインフラストラクチャコントローラー１６０６と対をなすインフラストラクチャゲートウェイ１６０５コンポーネントを用いて相互に通信可能である。これらのゲートウェイは、ＩＳＰ管理機能の制御プレーンとデータプレーンとを分離可能である。この分離により、サービスプレーン１６０７（ＭＭ１６０８、ＳＡＭ１６０９、及びＮＩＭ１６１０を含む）が、例えばインフラストラクチャ（例えばＩＳＰ）内又はリモートのデータセンター（例えばクラウド）等、物理的にどこにあってもよくなる。
【００４８】
開示されている主題の一態様によると、コンテキストアウェア制御ミドルウェア（Ｃｏｎｔｅｘｔ  ａｗａｒｅ  Ｃｏｎｔｒｏｌ  Ｍｉｄｄｌｅｗａｒｅ、ＣＣＭ）がポリシーベースモジュール意志決定システムを提供し、これは既存のフローに可能なパラレル接続を追加又は補完しユーザーエクスペリエンス、性能及び信頼性を改善することができる。ＣＣＭは、マルチホーミング及びマルチパスサポートのために、複数のアクセス技術インターフェース（例えばＬＴＥ、Ｗｉ−Ｆｉ、及びＷｉＭＡＸ）上のアクティブなフローを制御でき、ターミナル及びネットワークモビリティ決定を実行し、アプリケーション及びデバイスリソース共有を可能にし、セッションモビリティ及び途絶耐性サポートを提供し、ネットワーク、デバイス、及び利用可能な物理スペクトルチャンネルの発見を管理する。ＣＣＭは、既存のプログラミングパラダイムを変更することなしに、全てのネットワーク複雑性をアプリケーションに対して隠蔽することができる。ＣＣＭは、ポリシー及びアプリケーション要件に基づいてトランスポート、ネットワーク及びリンクプロトコルの動的選択を実行でき、その結果、より細分化されたネットワークリソースの制御が得られる。
【００４９】
図１７はミドルウェアを示すが、これは限定をするのではなく説明を目的とするものである。ＣＣＭは、トランスポート、ネットワーク及びリンク層プロトコルのいずれに対しても独立であり得る。ＣＣＭは、レガシーアプリケーション１７０１（即ち、変更を加えられておらず、ネットワーキング用に既定ＢＳＤソケット１７０２ＡＰＩを用いるアプリケーション）及びネイティブアプリケーション１７０３（即ち、提案する再設計されたネットワーキングスタックによって提供される追加の機能を有するネットワーキングＡＰＩ１７０４を用いるアプリケーション）の両者にも対応し得る。マネージャーからの種々の入力及びポリシーに基づいて、ポリシーエンジン１７０５は、アクティブなフローに対してネットワークインターフェースを追加する及び／又は消去するかについての決定を下す。各マネージャーは独立したタスクを実行するように設計することができる。ミドルウェアの種々なマネージャーが図１７に示されており、これらはデータストア１７０６、ネットワークマネージャー１７０７、ロケーションマネージャー１７０８、セキュリティマネージャー１７０９、キューマネージャー１７１０、サービス共有マネージャー１７１１、システムマネージャー１７１２、及びポリシーエンジン１７０５を含み得る。
【００５０】
データストア１７０６は、各モジュール用のストレージ機能を管理できる。ネットワークマネージャー１７０７は、アクティブなネットワークインターフェースを維持し監視でき、ポリシーエンジン１７０５の動作を実行できる。ロケーションマネージャー１７０８は、デバイスのロケーションを管理できる。例えば、ユーザーは、ＧＰＳ座標又は屋内測位システムに基づいて特定のロケーションを自宅又はオフィスとして指定できる。セキュリティマネージャー１７０９は、ネットワークアクセスセキュリティ（例えば、異種ネットワーク間での認証）を管理できる。キューマネージャー１７１０は、ネットワーク接続性が無い場合又はポリシーがネットワークの使用を強いない場合に、アプリケーションに対する途絶耐性サポートを可能にできる。後により詳細に説明するが、サービス共有マネージャー１７１１は、サービス共有及びセッションモビリティを複数のデバイス間で可能とし、後の使用のためにデバイスデータをローカルに保存することができる。後により詳細に説明するが、システムマネージャー１７１２は、各アクティブなアプリケーションセッションに関するＣＰＵ、帯域幅、バッテリー使用度等のシステムパラメーターを管理できる。ポリシーエンジンは、各アプリケーションに対応する全てのアクティブなソケット接続（即ちフロー）に対するマッピングを維持でき、他のマネージャーからの入力に基づいてフロー制御決定を行うことができる。
【００５１】
ある実施形態においては、ミドルウェアは、限定するものではないがセンサーマネージャー等の他のモジュールによって拡張することができる。センサーマネージャーは、パケットフロー制御に影響を及ぼし得るデバイスの全てのセンサー、例えば加速度計や磁力計等、を管理できる。例えば、Ｗｉ−Ｆｉは、ＵＥが高速で移動する際には数回の引き渡しを実行し、通信を低下させることがある。このため、ユーザーが高速で移動する場合、センサーマネージャーは、全ポリシーを無効としてＬＴＥインターフェースを使用することによりＵＥの引き渡し遅延を最適化するために、信号を出すことができる。
【００５２】
開示されている主題の一態様によると、データストア（ｄａｔａ  ｓｔｏｒｅ、ＤＳ）モジュールは、システムに対する、及びインストール済みの各アプリケーションに対する、ユーザー、ネットワーク、アプリケーションポリシーをポリシーストアに記憶している。後により詳細に説明するが、ＤＳは、制御ミドルウェアにおける各モジュールに対して、モジュール固有ストレージを提供することもできる。図１８はＤＳセマンティクスを示すが、これは限定をするのではなく説明を目的とするものである。図示のように、データストアは、ポリシーストア及び複数のモジュールストアを含み得る。ポリシーストアは、ポリシー固有ストレージ動作を実行できる。モジュール情報ストアは、モジュール固有動作の任を負うことができる。
【００５３】
図１９はＤＳのサブモジュールを示すが、これは限定をするのではなく説明を目的とするものである。ＤＳは、ローカル（例えば、人間及びアプリケーション）ユーザー１９０１及びリモート（例えばサービスプロバイダー）ユーザー１９０２と接続することができる。通信サブモジュール１９０３は、イベントを送受信でき、受信チャンネル上のイベントをリッスンできる。任意の新しいリクエストイベントをコントローラー１９０４に渡すことができ、コントローラー１９０４は（例えばユーザー特権及びモジュール特権に基づいて）リクエストを処理するか否かを決定できる。次いでコントローラーは、リクエストをストレージサブモジュール１９０５に送ることができ、ストレージサブモジュール１９０５は、作成（Ｃｒｅａｔｅ）、読込み（Ｒｅａｄ）、更新（Ｕｐｄａｔｅ）、及び削除（Ｄｅｌｅｔｅ）（ＣＲＵＤ）動作のうちのいずれか一つを各モジュールストア１９０６上で実行できる。ＤＳはデータストアサブスクライバーテーブル１９０７を含み得る。
【００５４】
図６１はＤＳの動作のフローチャートを例示しているが、これは限定をするのではなく説明を目的とするものである。ＤＳは、ローカル設定及びデータストアイベントの全サブスクライバーによって初期化することができる  ６１−０１。コントローラーは、ネットワークストレージ設定に関して調べることができ、設定が存在する場合、ネットワークストレージを接続することができる  ６１−０２。コントローラーは、ストレージイベントのリッスンを開始できる  ６１−０３。イベントが生じると、このイベントは評価することができる  ６１−０４。生じたイベントは、作成（Ｃｒｅａｔｅ）６１−０５イベント、更新（Ｕｐｄａｔｅ）６１−０６イベント、読込み（Ｒｅａｄ）６１−０７イベント、消去（Ｄｅｌｅｔｅ）６１０８イベント、及び加入（Ｓｕｂｓｃｒｉｂｅ）６１−０９イベントのうちの１以上に関し評価できる。イベント判定の後、これらのイベントはコントローラーによって処理できる  ６１−１０。ネットワークストレージが設定されている場合  ６１−１１、コントローラーは、ローカルのメモリー内データキャッシュを保持でき、データをネットワークに流すためのタイムアウトタイマーを保持することができる  ６１−１２。コントローラーは、タイマーのタイムアウトを調べることができ、限度内である場合、データイベントはローカルで処理できる  ６１−１４。タイマーが限度を超えた場合、キャッシュデータは、データイベント処理によって流し出され、タイマーをリセットすることができる  ６１−１３。コントローラーは、データ属性変更イベントを作成し、これを全サブスクライバーに発行することができる  ６１−１５。イベントが、加入（Ｓｕｂｓｃｒｉｂｅ）である場合、コントローラーはこのサブスクライバーをデータストアサブスクライバーテーブルに記憶する  ６１−１６。最後に、コントローラーは、イベントソースに対して応答を送信することができ  ６１−１７、次のイベントをリッスンすることに戻ることができる。
【００５５】
開示されている主題の一態様によると、ロケーションマネージャー（ｌｏｃａｔｉｏｎ  ｍａｎａｇｅｒ、ＬＭ）はＵＥのロケーションを監視する。ＬＭのコンポーネントの例を図２０に示すが、これは限定をするのではなく説明を目的とするものである。ＬＭは、３種の例示的なサービスを提供できる。（１）ロケーションリクエストテーブル（Ｌｏｃａｔｉｏｎ  Ｒｅｑｕｅｓｔ  Ｔａｂｌｅ、ＬＲＴ）２００１を用いたロケーションリクエストの（例えば、永続的又は非永続的な）記憶、（２）デバイスが要求されたロケーションに到達した時に、コントローラー２００２を介してサブスクライバーに通知、（３）デバイスの現在位置の提供。ポリシーエンジンは、ＬＭの永続的なストレージを用い、ユーザーの自宅、オフィス、又は事前に定義された環境のロケーションの追跡を要求することができる。ユーザーが要求されたロケーションの近傍に到着する度、ポリシーエンジンに、属性変更イベントパラメーターによって通知をすることができる。例示的実施形態において、ＬＭは、デバイスのロケーションに基づいて、屋内測位システム（Ｉｎｄｏｏｒ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ、ＩＰＳ）２００３及び／又は屋外測位システム（ｏｕｔｄｏｏｒ  ｐｏｓｉｔｉｏｎｉｎｇ  ｓｙｓｔｅｍ、ＯＰＳ）２００４を含む２個の異なる測位システムを活用し、通信ブロック２００５を介して他のＣＣＭマネージャーと通信することができる。ＩＰＳ２００３は、Ｗｉ−Ｆｉベースのものであってもよい（又は地球の磁場の変化を用いてビル内のモバイルデバイスの位置を特定してもよい）。ＬＭは、デバイスの設定に基づき、ＧＰＳ（米国）／ＧＬＯＮＡＳＳ（ロシア）／Ｇａｌｉｌｅｏ（ヨーロッパ）を用いることができる。ロケーション管理ＧＵＩ２００６は、デバイスロケーション名を設定するために使用でき、ユーザーはロケーションの座標に名前を付けることができる。
【００５６】
図６２はロケーションマネージャーの動作の例示的フローチャートであるが、これは限定をするのではなく説明を目的とするものである。ロケーションマネージャーは初期化でき、そのサブスクライバーに通知することができる  ６２−０１。コントローラーは新しいイベントのリッスンを開始できる  ６２−０２。新しいイベントが生じた場合、そのイベントを評価することができる  ６２−０３。コントローラーは、データストアが設定されているかを確認し、設定が存在する場合は、イベントデータを記憶することができる  ６２−０４。イベントの評価後、コントローラーは、例えば、現在のロケーション  ６２−０５、新しいロケーション設定  ６２−０７、ロケーション更新  ６２−０８、ロケーション削除  ６２−０９、及びロケーションの問合わせ  ６２−１０等のロケーションコマンドを確認することができる。コントローラーは、これらのコマンドを処理しポリシーエンジンに応答を送ることができる  ６２−１３。コントローラーは、常にロケーションを監視し  ６２−０６、ロケーションが閾値内である場合、ロケーションイベントを記憶することができ  ６２−１１、サブスクライバーに通知することができる  ６２−１２。
【００５７】
開示されている主題の一態様において、ネットワークマネージャー（ｎｅｔｗｏｒｋ  ｍａｎａｇｅｒ、ＮＭ）のコンポーネントの例が図２１に示されているが、これは限定をするのではなく説明を目的とするものである。ＮＭは、ネットワークのコントローラー（２１０１、２１０２、及び２１０３）、リンク及び物理制御機能プロトコル（２１０４、２１０５及び２１０６）を制御することができる。インターフェース制御に加え、ＮＭはＣＣＭにおける４種のサービスを提供することができる：（１）ネットワーク情報の提供、（２）通信ブロック２１０７を介した近接するアクティブなネットワークの監視、（３）ＩＰアドレスを獲得するためにネットワーク設定２１０８を提供、（４）特定のネットワークが近接する度に、コントローラー２１０９を介してサブスクライバーに警告。ポリシーエンジンは４種のサービスの全てを使用できる。ＮＭは、選択済みネットワーク及び近接ネットワークに関するネットワーク情報を、ＤＳ２１１０のモジュール情報ストア内に保持できる。これにより、将来のネットワーク選択最適化を支援することができる。例えば、ＮＭは、対応するロケーションを有する選択済みネットワークを記憶し、データマイニング技術を用いて、ユーザーの日々の職場への移動に関する地理的地図を作成でき、このユーザーに対して予測された経路に基づき、ネットワーク選択を最適化できる。ネットワークサブスクライバーテーブル（Ｎｅｔｗｏｒｋ  Ｓｕｂｓｃｒｉｂｅｒ  Ｔａｂｌｅ、ＮＳＴ）２１１１は、ＮＭのサブスクライバーを記憶することができる。
【００５８】
ＮＭモジュールは、ネットワークインターフェースを保持し、常にＬＣＦを介して監視することができる。例えば、ＮＭは、信頼済みアクセスサービス（Ｔｒｕｓｔｅｄ  Ａｃｃｅｓｓ  Ｓｅｒｖｉｃｅ、ＴＡＳ）テーブル２１１２を保持することができる。ＴＡＳは、サービスプロバイダー又はユーザーによって動的に更新することができる。ＴＡＳは、例えばｉｄ、認証プロシージャ、デバイスタイプ、資格情報、コスト、帯域幅、及びアクセス履歴等のアクセスサービス情報を記憶することができる。ＮＭは、更に２個のテーブル、即ちアクティブアクセスサービス（Ａｃｔｉｖｅ  Ａｃｃｅｓｓ  Ｓｅｒｖｉｃｅ、ＡＡＳ）２１１３及び候補アクセスサービス（Ｃａｎｄｉｄａｔｅ  Ａｃｃｅｓｓ  Ｓｅｒｖｉｃｅ、ＣＡＳ）２１１４を保持することができる。ＡＡＳテーブルは、現在接続中のアクセスサービスのリストを保持することができる。ＣＡＳテーブルは、信頼済みアクセスサービスの有効リストを保持することができる。
【００５９】
開示されている主題の一態様によると、ネットワーク情報サービスは、ローカル情報（例えばリアルタイム情報）を用いて及び／又はＬＣＦを介したネットワークベース情報マネージャーを用いることにより提供される。ネットワーク設定サービスは、ネットワークアクセスを提供でき、例えば、一旦ネットワークインターフェースが立ち上がると、ＤＨＣＰリクエストが送られ、ネットワークアクセスのためのＩＰアドレスが獲得される。ＮＣＦコントローラーは、ネットワーク制御機能プロトコルを制御でき、静的フロー識別子を設定でき、ハンドオーバー決定をＮＣＦプロトコルに中継する。ＬＣＦコントローラーは、リンク制御機能プロトコルを制御することができ、これは、リンク状態（アップ又はダウン）、リンク制御（オン、オフ、またはスタンバイ）、リンクパフォーマンス情報、及び仮想インターフェース（即ち、一つの物理ネットワークインターフェースを用いて複数のネットワークに同時に接続する場合の）設定を中継することを含むが、これらに限定されるものではない。ＰＣＦコントローラーは、物理制御機能プロトコルを制御でき、物理制御機能プロトコルは、最適スペクトルチャンネル（例えば技術に固有なもの）を設定するのに用いられる。デバイスのセキュリティの理由からも、ＰＣＦは、制御機能を直接公開できない。ＰＣＦは、物理層を制御するために、インターフェース固有ＬＣＦ  ＡＰＩを使用できる。
【００６０】
図６３は、ネットワークマネージャーの動作のフローチャートを例示するが、これは限定をするのではなく説明を目的とするものである。ネットワークマネージャーを初期化することができ、サブスクライバーに通知することができる  ６３−０１。コントローラーは、新しいイベントを待機することができる６３−０２。新しいイベントが生じた場合、そのイベントを評価することができる  ６３−０３。データストアが設定されている場合、イベントデータを、後の使用のために記憶することができる  ６３−０４。コントローラーは、イベントタイプを評価することができる。イベントタイプは、例えば、ＬＣＦ  ６３−０５、ＰＣＦ  ６３−０９、ＮＣＦ  ６３−１０、ネットワーク設定  ６３−１２、ネットワーク加入  ６３−１５、及びネットワーク追加  ６３−１６である。「ネットワーク発見」においては、ＬＣＦから近接するネットワークを返すことができる  ６３−０６。「ネットワーク情報リクエスト」においては、要求したネットワークのネットワーク情報を返すことができる  ６３−０７。「新しいネットワーク情報」においては、候補サービスアクセステーブルを更新することができる  ６２−０８。「インターフェース設定」６３−１８においては、物理無線パラメーターを設定できる。「ハンドオーバー」６３−１１によって、モバイルハンドオーバーが生じ得る。コントローラーは、ネットワークデータが無い場合、アクティブアクセスサービステーブル及び信頼済みアクセスサービステーブルを更新することができる。これらのローカルテーブルを更新後、コントローラーは、ハンドオーバー信号を各ＮＣＦプロトコルに送信することができる。「ネットワーク設定」においては、最初に、ユーザーが承認されているかを確認し、承認されている場合、ネットワークを設定することができる  ６３−１３。「ネットワーク加入」６３−１５において、コントローラーは、ネットワーク加入テーブル（ｎｅｔｗｏｒｋ  ｓｕｂｓｃｒｉｂｅ  ｔａｂｌｅ、ＮＳＴ）内に項目を作成することができる  ６３−１４。「ネットワーク追加」６３−１６において、ネットワークを、信頼済みネットワークテーブルに追加することができる。サブスクライバーには、イベント処理結果を通知することができる  ６３−１７。
【００６１】
開示されている主題の一態様において、セキュリティマネージャー（Ｓｅｃｕｒｉｔｙ  Ｍａｎａｇｅｒ、ＳＭ）は、以下のセキュリティ動作を提供する：資格情報管理、ネットワーク及びデバイスアクセスの制御、及びセキュリティで保護されたエンド・ツー・エンド通信。図２２は、セキュリティマネージャーのコンポーネントの例を示すが、これは限定をするのではなく説明を目的とするものである。資格情報管理のため  ２２０１、ＳＭは種々のネットワークに関する資格情報を管理することができる。ネットワークアクセスのため、ＳＭは、モバイルノードのインフラストラクチャプロバイダーに対する認証  ２２０２の任を負い、サービスプロバイダーからのネットワークアクセスの承認の任を負うことができる。デバイスアクセスのため、ＳＭは信頼済みデバイスのテーブルを記憶でき  ２２０３、デバイス間での認証と承認の任を負う。ＳＭは、ネットワークマネージャーに対して資格情報を公開することができ、これはセキュリティで保護された接続を確立するために必要とされ得る。エンド・ツー・エンド通信のために、ＳＭは、ＮＣＦプロトコルパラメーターを用いた、セキュリティで保護されたエンド・ツー・エンド通信を可能にすることにより、データ機密性２２０５を提供できる。セキュリティ管理ＧＵＩ２２０６は、資格情報がユーザーの管理下にある場合に、ネットワークアクセス資格情報を設定するために使用することができる。
【００６２】
ＳＭは、ネットワーク及びデバイスアクセス資格情報を管理することができる。これら資格情報は、ＳＭモジュール情報ストア又はユニバーサル集積回路カード（Ｕｎｉｖｅｒｓａｌ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ  Ｃａｒｄ、ＵＩＣＣ）内のサブスクライバー識別モジュール（Ｓｕｂｓｃｒｉｂｅｒｓ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  Ｍｏｄｕｌｅ、ＳＩＭ）アプリケーションにも記憶できる。ＳＭ情報ストアは以下の情報を含むことができる：（１）資格情報のタイプ（例えば、証明書、事前共有キー又はログイン／パスワード）、（２）資格情報の使用（例えばＨＩＰプロトコル、ネットワークアクセス）、（３）追加情報（例えば、資格情報がアクセスを与えるネットワークの名前とタイプ）、及び（４）資格情報。データストア２２０４のストレージは、デバイス独立ストレージを提供するためにサービスプロバイダーがネットワークベースデータストアを提供できるように、デバイスに依存したものであり得る。
【００６３】
図６４は、ＳＭの動作のフローチャートを例示するが、これは限定をするのではなく説明を目的とするものである。セキュリティマネージャーは、ローカル及びＵＩＣＣストレージによって初期化できる  ６４−０１。ネットワークストレージ設定を確認することができ  ６４−０２、設定が存在する場合、ネットワークストレージを接続することができる。コントローラー２２０７は、新しいイベントを待機する  ６４−０３。新しいイベントが生じた場合、そのイベントを評価することができる  ６４−０４。記憶されたローカルデータを設定する場合  ６４−０５、イベントデータを記憶することができる。コントローラーは、例えば、資格情報を記憶６４−０６、ネットワーク認証６４−０７、デバイス認証６４−０８、データ機密性６４−０９及び承認ユーザーに対するネットワーク資格情報クエリー６４−１０等のイベントタイプに基づいて種々の機能を実行できる。資格情報タイプは評価することができ  ６４−１１、資格情報のタイプ毎に記憶できる。コントローラーは、ネットワーク／デバイス認証を実行でき  ６４−１２、結果をポリシーエンジンに返すことができる  ６４−１４。「データ機密性」に関し、コントローラーは、ＮＣＦ設定を設定し、現在のフローのデータパスの暗号化を可能とすることができる。承認されたユーザーは、記憶済み資格情報を照会することができる  ６４−１０。全イベントに関して、コントローラーは、通知をポリシーエンジンに返すことができる  ６４−１４。
【００６４】
開示されている主題の一態様によると、キューマネージャー（ｑｕｅｕｅ  ｍａｎａｇｅｒ、ＱＭ）モジュールは、フロー固有パケットストレージの管理のために使用できる。図２３にＱＭコンポーネントの例を示すが、これは限定をするのではなく説明を目的とするものである。ＱＭは、データフロー固有メッセージキュー２３０１、２３０２、２３０３、及び２３０４を管理でき、ミドルウェア内に２種のサービス：（１）データストア２３０５を介したパケットストレージと（２）コントローラー２３０６及び通信ブロック２３０７を介したキューオーバーフロー警告と、を提供できる。ユーザーは、キューのためにアプリケーション又はフロー優先度を設定することもできる。例えば、ＨＴＴＰトラフィックにはビットトレントトラフィックよりも高い優先度を与ることができる。
【００６５】
アプリケーションデータトランスファー用のアクティブなインターフェースが存在しない場合、ポリシーエンジンは、ネットワーク可用性が無いことをアプリケーションに通知するか、又はＱＭにデータパケットを記憶することができる。ポリシーエンジンは、各フローに対して新しいキューをリクエストでき、キューが正常に生成された後、ＱＭは、アクティブフローテーブル（Ａｃｔｉｖｅ  Ｆｌｏｗ  Ｔａｂｌｅ、ＡＦＴ）に記憶されているキューｉｄを返すことができる。後により詳しく論じるが、ＡＦＴはポリシーエンジンによって保持されている。ポリシーエンジンに新しいインターフェースイベントが配信されると常に、対応するキューを、可能なネットワーク送信に関して調べることができる。
【００６６】
フロー固有キューは、例えば大きいファイルの転送において、データ転送用のストレージ限度を超えることがあり、これはキューオーバーフローを生じる。ＱＭは、ポリシーエンジンに対してキューオーバーフローに関して警告を出すことができ、これは、イベントチャンネルが設定されている場合、アプリケーションに警告を出すこととなり得る。
【００６７】
図６５は、キューマネージャーの動作の例示的フローチャートであるが、これは限定をするのではなく説明を目的とするものである。キューマネージャーは、データストア及びサブスクライバーを初期化できる  ６５−０１。ネットワークストレージが設定されている場合、コントローラーは、ネットワークストレージサーバーとの新しい接続を作成することができる  ６５−０２。コントローラーは、新しいイベントを待機することができる  ６５−０３。新しいイベントが生じると、そのイベントを評価することができる  ６５−０４。コントローラーは、ローカルデータストア設定を調べることができ、設定が存在する場合、ローカルイベントを記憶することができる  ６５−０５。イベントタイプを評価することができる。例えば、「新しいキュー」６５−０６においては、新しいキューを作成でき、キューｉｄをポリシーエンジンに返すことができる  ６５−０７。「キューを転送」６５−０８において、データはキューからネットワークへと流すことができる。キューオーバーフロー（６５−０９）エラーがある場合、ポリシーエンジンに通知することができる。コントローラーは、書き込み障害がある場合にも、ポリシーエンジンに通知をすることができる。
【００６８】
開示されている主題の一態様によると、制御ミドルウェア内のシステムマネージャー（Ｓｙｓｔｅｍ  Ｍａｎａｇｅｒ、ＳｙｓＭ）モジュールは、ローカル環境において、アプリケーションリソース監視及びアプリケーション管理サービスの任を負う。図２４は、システムマネージャーのコンポーネントの例を示すが、これは限定をするのではなく説明を目的とするものである。リソースリクエストテーブル２４０１は、任意のインストール済みアプリケーションに対するリクエストを記憶できる。リクエストが実行されると、ＳｙｓＭは、リソースの実行をサブスクライバーに通知できる。例えば、ユーザーは、アプリケーション１に対する帯域幅の限度を１００ＭＢに設定でき、ポリシーエンジンは、アプリケーション１がこの限度に達した場合に、ＳｙｓＭに対して、ユーザーに通知をするようにリクエストできる。アクティブアプリケーションテーブル（Ａｃｔｉｖｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｔａｂｌｅ、ＡＡＴ）２４０２は、全てのアクティブな実行中のアプリケーションの情報を保持することができる。アプリケーションエバリュエーター２４０３は、リソース最適化のためにアプリケーションの呼び出しグラフ（即ちコンピュータープログラムにおけるサブルーチン間の呼び出し関係を表す有向グラフ）を監視することができる。例えば、モジュラーアプリケーションにおいて、一つの特定なモジュールがＣＰＵの８０％を消費していることがあり、リソースの活用を改善するため、システムマネージャーは、このモジュールの実行を接続されたクラウドへとオフロードすることができる。リソースメーター２４０４は、アプリケーションＣＰＵ、メモリー、ストレージ、バッテリー、帯域幅の使用度等を監視できる。コントローラー２４０５は、この情報を、将来のアプリケーションオフロード決定のためにデータストア２４０６に記憶できる。インストール済みアプリケーションテーブル（Ｉｎｓｔａｌｌｅｄ  Ａｐｐｌｉｃａｔｉｏｎ  Ｔａｂｌｅ、ＩＡＴ）２４０７は、各デバイス上にインストールされた全アプリケーションの情報を保持できる。
【００６９】
図６６は、システムマネージャーの動作の例示的フローチャートであるが、これは限定をするのではなく説明を目的とするものである。システムマネージャーは、モジュール及びサブスクライバーを初期化できる  ６６−０１。コントローラーは、新しいイベントを待機することができる  ６６−０２。新しいイベントが生じた場合、そのイベントを評価することができる  ６６−０３。コントローラーはローカルデータストアを調べることができ、存在する場合、イベントを記憶することができる  ６６−０４。コントローラーはイベントのタイプを調べることができ、それに応じてコマンドを実行することができる。新規リソースリクエスト通知リクエスト６６−０５において、リソースリクエストテーブルに項目を追加できる。リソース閾値到達イベント６６−０６において、サブスクライバーにリソースを通知できる。新しいアプリケーションが開始される場合  ６６−０７、システムマネージャーはアプリケーションの監視を開始することができ、アクティブアプリケーションテーブルに項目を追加することができる。アプリケーションの状態が変化した場合  ６６−０８、例えばアプリケーションがインストール／アンインストール／移動された場合、コントローラーは、インストール済みアプリケーションテーブルを更新できる。コントローラーは、特定のアプリケーション又は全アプリケーションに対するアプリケーションリソースクエリーを受け入れることができる  ６６−０９。コントローラーは、各イベントを処理した後にサブスクライバーに対して通知を送ることができる。
【００７０】
開示されている主題の一例示的実施形態によると、ＣＣＭに必要とされるモジュールは、ポリシーエンジン（Ｐｏｌｉｃｙ  Ｅｎｇｉｎｅ、ＰＥ）と、セキュリティマネージャーと、ロケーションマネージャーと、ネットワークマネージャーと、データストアとを含む。ポリシーエンジンは、ＣＣＭ内のこれらマネージャーからの入力を取得することができる。これらの入力とポリシーに基づき、ＰＥは、アクティブなフローに対するネットワークインターフェースを追加／削除するか、又は新しいフローを作成するかの決定を下すことができる。
【００７１】
ＰＥは、全てのアクティブな接続に対するマッピングを保持できる。例えば、ＰＥは、２個のテーブル、アクティブフローテーブル（Ａｃｔｉｖｅ  Ｆｌｏｗ  Ｔａｂｌｅ、ＡＦＴ）及びポリシーテーブル（Ｐｏｌｉｃｙ  Ｔａｂｌｅ、ＰＴ）、を保持できる。ＡＦＴは、各新規フローを保持でき、このフローは、ソケット記述子、アプリケーションｉｄ、アクティブインターフェース、ソース＆行先フロー識別子、現在のポリシーｉｄ、キューｉｄ、及び単方向イベントチャンネルポインターを含む。セキュリティ上の理由のため、イベントチャンネルは、一方向（即ちミドルウェアからアプリケーションへ）の通信のみに対応できる。ＣＣＭは、このイベントチャンネルを用いてイベントをユニキャスト又はブロードキャストできる。ＰＴは、各アプリケーションに関連した全てのポリシー及びグローバルシステムポリシーを保持できる。接続情報を保持することにより、ミドルウェアによるアプリケーションポリシー選択の最適化を支援できる。制御ミドルウェアは、２種の高レベルサービス：（１）接続レコード用の作成、読込み、更新及び／又は削除（ＣＲＵＤ）と（２）アプリケーションＩＤ、インターフェースタイプ等を含むレコードパラメーターに基づいた接続レコードの照会と、を提供できる。属性変更イベントがあると常に（即ち、属性の値が変化すると常に）、このイベントを、更なる処理のために、新旧の属性値と任意の制御ミドルウェアモジュールからのソースモジュール情報とを含むイベントオブジェクトを介してポリシーエンジンへと渡すことができる。例えば、インターフェースの追加又は削除、及びＵＥのロケーションの変更は、属性変更イベントであり、ポリシーエンジンに通知され、ＣＭの接続レコード内の対応するマッピングが更新される。
【００７２】
開示されている主題の一態様によると、ポリシーは、条件のリスト及びそれらに対応する取るべき動作を含む。各条件はバイナリ演算であることができ、これは真又は偽と評価される。対応するポリシーに対する動作は、全条件を満たす場合、即ち真と評価される場合にのみ取られる。ポリシーは、ユーザー、インストール済みアプリケーションによってローカルにＵＥ上において、又はサービスプロバイダーによってリモートで生成することができる。ポリシー管理ツールは、データフローの挙動を変更できる属性（例えばミドルウェアにおける種々のモジュール）を表示することができる。ポリシーは、種々の優先度を用い、各アプリケーション毎に又はグローバルネットワークアクセスに対して定義できる。アプリケーション毎に定義できるポリシーは、アプリケーションｉｄによって識別できる。全てのグローバルポリシーに対応する一意なグローバルＩＤが一つ存在する。一実施形態において、各ＩＤはルックアップテーブルに記憶でき、そこにおいてグローバルＩＤは、制御ミドルウェア内では知られた定数である。図２５に限定をするのではなく説明を目的として示すように、個々のアプリケーションＩＤは、アプリケーションがＵＥにインストールされたときに生成される。
【００７３】
開示されている主題の一態様によると、アプリケーションｉｄは、２種：アプリケーションパスベースｉｄ及び／又はアプリケーション依存ｉｄ、のうちの一つであり得る。アプリケーションパスベースアプリケーションｉｄは、アプリケーションインストールパスに基づいたものであってよく、アプリケーションインストールパスは、各アプリケーションに対して一意なものである。このアプリケーションは、ローカルに生成され、一意なパスにマップされたＩＤによって識別される。アプリケーションが通信ソケットを開いた場合、アプリケーションパスを調べることができ、対応するポリシーを取得しロードすることができる。アプリケーション依存アプリケーションｉｄは、インストールタイプに依存する。このアプリケーションｉｄは、ユニバーサル一意識別子（Ｕｎｉｖｅｒｓａｌｌｙ  Ｕｎｉｑｕｅ  Ｉｄｅｎｔｉｆｉｅｒ、ＵＵＩＤ）又はオペレーティングシステムによってＵＵＩＤにマップされた一意アプリケーションＵＲＩであることができる。アプリケーションは、各ソケットコール毎に、アプリケーションｉｄを制御ミドルウェアに供給できる。一実施形態において、グローバル及びアプリケーションｉｄ名空間は、各ＵＥにおいて一意である必要がある。
【００７４】
開示されている主題の一態様によると、ポリシーは、ポリシーストア（即ち、データストアのサブモジュール）にローカルに記憶される。それに加え又はその代わりとして、ポリシーは、サービスプロバイダーによってリモートで記憶することもでき（例えばネットワークアクセスポリシー）、ＵＥのポリシーストアリポジトリーへとダウンロードできる。例えば、サービスプロバイダーの既定のネットワークアクセスポリシーは、電話アプリケーションは常にＬＴＥを使用すること及び／又は、ユーザーが自宅にいる場合、ウェブブラウジングアプリケーションはＷｉ−Ｆｉを使用することとを含むことができる。これらのポリシーは、ユーザーが変更できないようにするため、読み取り専用とすることができる。サービスプロバイダーがネットワークアクセスポリシーを隠匿したい場合、読取許可を拒絶することができる。
【００７５】
ポリシーリポジトリーに対する任意の変更は、イベントを生じ、ポリシーエンジン（ｐｏｌｉｃｙ  ｅｎｇｉｎｅ、ＰＥ）に変更を通知することができる。ポリシーリポジトリーは、加入機能を提供できる。即ちＰＥはアクティブなアプリケーションｉｄのみに加入でき、これらのアプリケーションポリシーに対する変更のみが、ＰＥに通知される。
【００７６】
開示されている主題の一態様によると、ＵＥ内のインストール済みの各アプリケーションは、関連するアプリケーションＩＤを有する。アプリケーションは、ソケットを開放でき、このアプリケーションＩＤをソケットパラメーターの一つとして渡すことができる。このＩＤは、ポリシーデータストアに照会しアプリケーションに関連した対応するポリシーを取得するために用いることができる。
【００７７】
ポリシーは、システムの現在の属性値、例えば、アクティブなネットワークインターフェース、ネットワーク帯域幅、帯域幅のコスト、現在のロケーション及びシステムリソース（ＣＰＵ、メモリー、バッテリーパワー、帯域幅の使用度等）を用いて評価できる。真と評価され、最も高い評価スコアを有するポリシーが選択され、対応する動作が実行される。
【００７８】
ポリシーの結果として２種の実行可能な動作があることもある。第一に、新しいインターフェースを用いて新しいフローを作成又は既存のフローを更新するために用いられるネットワークインターフェースが利用可能となる（即ち、削除及び／又は追加される）。第２に、適切なネットワークインターフェースが利用可能ではなくなり（例えば、ポリシーのため又は有効範囲にないため）、データは、先入れ先出し（Ｆｉｒｓｔ  ｉｎ  Ｆｉｒｓｔ  ｏｕｔ、ＦＩＦＯ）方式を用いてキューマネージャーに一時記憶される。アプリケーションには、イベントを介してネットワークインターフェースの特定の状態又はキューの状態を通知することができる。
【００７９】
図２６は、ポリシーエンジンの内部コンポーネントを示すが、これは限定をするのではなく説明を目的とするものである。コントローラーは、アプリケーションＩＤ、ソースネットワーク制御機能（Ｎｅｔｗｏｒｋ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ、ＮＣＦ）ＩＤ、行先ＮＣＦ  ＩＤ、ソースポート、行先ポート、アクティブなサブフローの詳細（例えば、インターフェース、ソース及び行先ＩＰアドレス）、現在のアクティブなポリシー等のフロー属性を有するアクティブフローテーブル（Ａｃｔｉｖｅ  Ｆｌｏｗ  Ｔａｂｌｅ、ＡＦＴ）を保持する。リスナー機能を、別個の独立した実行コンピューターユニットで走らせることができ、ＣＣＭ内での全イベントをリッスンできる。エバリュエーター機能は、新しい接続が作成された場合又はイベントを介して何らかの変更が生じた場合に、各アプリケーションに関する全てのポリシーを評価することができる。コントローラーは、実施ポイント（例えばネットワークマネージャー）を介してポリシーの動作を実行できる。
【００８０】
ＵＥ上のポリシーエンジンは分散することができる。例えば、ネットワークベースポリシーエンジンを、ＵＥのローカル制御ミドルウェアイベントに加入させることができる。サービスプレーンからのサービスアクセスマネージャー（Ｓｅｒｖｉｃｅ  Ａｃｃｅｓｓ  Ｍａｎａｇｅｒ、ＳＡＭ）は、各ＵＥに対して、ネットワークベースのデータストレージとセッション管理、及びネットワーク情報マネージャー（Ｎｅｔｗｏｒｋ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｍａｎａｇｅｒ、ＮＩＭ）ＬＣＦネットワーク情報サービスを提供できる。
【００８１】
図２７に限定をするのではなく説明を目的として示すように、制御ミドルウェアは、データフローパイプを制御することができる。制御ミドルウェアは、自身の入力変数として種々の属性を有することができ、これらはアクティブなデータフローの挙動に影響を及ぼす。ポリシーの動作は、例えばリンク又は物理層等ネットワークの制御に変化を生じ得る。換言すれば、制御ミドルウェアは、データフローパイプに対する制御センターとして動作することができ、他の制御機能、即ちネットワーク、リンク、物理層、は接続された制御ノブである。
【００８２】
図２８は、ポリシーを定義することのできる種々のレベルを示すが、これは限定をするのではなく説明を目的とするものである。スペクトルポリシー２８０１は、（例えば、ライセンスされた又はライセンスされていない）最適化スペクトルを使用するように定義することができる。物理層コントローラー（例えば、ＮＭによって制御される、異なるシステム）が、現在のロケーションに基づいた最適化スペクトル設定を送信できるか、又はＵＥがコグニティブ無線技術を用いてスペクトル選択決定を補足することができるかである。コグニティブ無線はトランシーバーであり、これは無線スペクトル内の利用可能なチャンネルを自動的に検知し、それにより送信又は受信パラメーターを変更し、一ロケーションにおいて与えられたスペクトルバンド内でより多くの無線通信が同時に行えるようになる。このプロセスは、動的スペクトル管理としても知られている。インターフェース選択ポリシー２８０２は、データ通信のためにどのネットワークインターフェースを選択するのかを決定することができる。
【００８３】
アプリケーションポリシー２８０３は、どの決定がなされるかに基づいて、帯域幅の使用度、ロケーション、時間、デバイスタイプ等の種々の属性を提供できる。ユーザーは、これら全てのポリシーを変更でき、必要に応じて新しいポリシーを追加できる。更に、将来のアプリケーションのために、ユーザー及びアプリケーションの開発者は、トランスポート層ポリシー２８０４及びネットワーク層ポリシー２８０５を定義でき、これらは、アプリケーションがどのトランスポート及びネットワーク層プロトコルを、ネットワーキング環境に基づいてデータ通信用に用いることができるかを定義することができる。例えば、ＵＥのアプリケーションとのネットワーク接続が断続的である場合、ＵＥはポリシーとして、ＴＣＰ又はＵＤＰの代わりに途絶耐性トランスポートプロトコルを用いることができる。
【００８４】
図６７は、ポリシーエンジンの動作の例示的フローチャートであるが、これは限定をするのではなく説明を目的とするものである。制御ミドルウェアは、ポリシーエンジンを初期化でき、サブスクライバーを設定できる  ６７−０１。サービスアクセスマネージャーが設定されている場合、ポリシーエンジンコントローラーはサービスアクセスマネージャーとの接続を作成することができる  ６７−０２。コントローラーは、新しいイベントを待機することができる  ６７−０３。新しいイベントが生じると、コントローラー６７−０４はそのイベントを評価することができる。イベントタイプがソケットである場合  ６７−０５、フローテーブルを調べてソケットが既に存在するかを決定することができ、存在する場合、対応するソケット動作を実行することができる  ６７−０６。ソケットが存在しない場合、新しいソケットを作成することができる  ６７−０７。コントローラーは、ソケットイベントにおけるアプリケーションＩＤの存在を調べることができ  ６７−０８、存在する場合、新しいフローテーブル項目を作成できる  ６７−１２。コントローラーはポリシーストアを照会し、アプリケーションポリシーをロードし評価を実行することができる  ６７−１３。アプリケーションＩＤが存在しない場合、コントローラーは、固有アプリケーションインストレーションパスを解決しようと試みることができ、解決した場合、関連するアプリケーションＩＤを用いて、新しいテーブルフローを作成することができる。アプリケーションパスから正常なアプリケーションＩＤが得られない場合  ６７−０９、グローバルポリシーを用いて新しいフロー項目を作成することができる  ６７−１１。ポリシー選択の後、コントローラーは、ネットワークインターフェースを決定でき  ６７−１４、ネットワークインターフェースが選択された場合、フローテーブル項目を更新できる  ６７−１５。モバイルハンドオーバー決定がなされた場合、コントローラーは、ネットワーク認証が必要かを調べ、必要な場合、コントローラーは認証工程を実行することができる  ６７−１７。認証が成功すると、制御ミドルウェアはモバイルハンドオーバーを実行し  ６７−２１、イベント処理を完了することができる。インターフェースの利用不能又はポリシーによる強制のためにネットワークインターフェースが選択されない場合、コントローラーは、キューマネージャーの可用性を調べ  ６７−１８、存在する場合、新しいキューをキューマネージャーから要求することができる  ６７−１９。キューの作成が成功すると  ６７−２０、キューＩＤを用いてフローテーブル項目を更新でき  ６７−２２、対応するアプリケーションに、フローイベント単方向イベントチャンネルを用いて通知することができる  ６７−２３。
【００８５】
開示されている主題の一態様によると、ＣＣＭは、少なくとも２種の異なる方法でオペレーティングシステムにインストールでき、これらは例えば、カーネル及びユーザー空間へのインストールである。両インストールタイプは、異なる通信フローを有することができる。カーネル空間制御ミドルウェアにおいて、制御ミドルウェア内のネットワーキングＡＰＩは、現行のＢＳＤソケットＡＰＩに対して下位互換であり得る。現行のアプリケーション（即ちレガシー）は、新しいネットワーキングＡＰＩとシームレスで動作する。新しいアプリケーション（即ちネイティブアプリケーション）は、アプリケーションｉｄ及びイベントチャンネルを含むｓｅｔｓｏｃｋｏｐｔソケットＡＰＩを用いて制御ミドルウェア固有属性を設定することができる。アプリケーションｉｄは、アプリケーション固有ポリシーを選択するために用いることができる。この属性は、制御ミドルウェアに誰がソケットを開けているかを教えることができる。イベントチャンネル属性は、制御ミドルウェアがアプリケーションにネットワークイベントを通知することができる通信チャンネルを定義する。
【００８６】
アプリケーションは、制御ミドルウェアによって提供されるネットワーキングＡＰＩを用いてネットワークにアクセスできる。ネイティブアプリケーションをＣＮ上のネットワーキングスタックに基づいてＣＮと通信可能とするフロー設定には、異なる３種がある。第１に、制御ミドルウェア対応ＣＮの場合、制御ミドルウェアは、ＨＩＰプロトコルをホスト間の通信のためのＮＣＦとして選択することができる。ＩＰｖ６対応ＣＮの場合、制御ミドルウェアは、モバイルＩＰｖ６（ＭＩＰｖ６）プロトコルをＮＣＦとして選択することができる。ＩＰｖ４対応ＣＮの場合、制御ミドルウェアは、普通のＴＣＰ／ＩＰｖ４スタックに戻ることができる。
【００８７】
ユーザー空間制御ミドルウェアにおいて、制御ミドルウェアは、カーネル空間ＢＳＤソケットＡＰＩに何ら変更を加えずに、ＵＥにユーザー空間ライブラリとしてインストールできる。ネイティブアプリケーションは、このライブラリをネットワーク通信のために用いることができる。レガシーアプリケーションに関して、ネイティブソケットプロキシ（これは、クライアント及びサーバー間でネットワークパケットを転送するプロキシとして機能し、認証を提供して承認ユーザーのみがサーバーへアクセスできるようにする）サーバーアプリケーションをＵＥ上でローカルに実行することができる。レガシーアプリケーションは、ｓｏｃｋｅｔ＿ｐｒｏｘｙ＿ｃｌｉｅｎｔアプリケーションの内部で実行でき、これは全てのＢＳＤソケットコールを取り込み、コールをローカルに実行されるソケットプロキシサーバーへと転送する。図２９は、ユーザー空間制御ミドルウェアライブラリ用のソケットプロキシ機能を示すが、これは限定をするのではなく説明を目的とするものである。
【００８８】
ＣＮは、制御ミドルウェアが無くても、ＩＰｖ６又はＩＰｖ４サポートを有すことができる。ＵＥが制御ミドルウェアを用いて常にＣＮに接続されているようにするため、ソケットプロキシは、ネットワーク側で用いることができ、これは制御ミドルウェアネットワーキングスタックをサポートしている。ネットワーク側のソケットプロキシコンポーネントは、サーバーとして用いることができ、制御ミドルウェア内のＡＦＴを有するポリシーコントローラーはソケットプロキシクライアントとして機能する。図３０はソケットプロキシ機能を示すが、これは限定をするのではなく説明を目的とするものである。第１に、アプリケーションは、ＩＰｖ４又はＩＰｖ６ソケットを開放することができる。第２に、ポリシーコントローラーは、ソケットプロキシクライアントとして機能でき、リクエストをネットワーク内のソケットプロキシサーバーへと転送することができる。ソケットプロキシサーバーは、ネイティブとしてソケットプロキシクライアントに接続できる。第３に、ソケットプロキシサーバーは、ＣＮ用のＩＰクライアントとして機能でき、全レスポンスパケットをソケットプロキシクライアントに転送できる。ソケットプロキシは、ソケットリレーシステムとして効果的に機能することができ、これは、ローカルのネットワーキングスタック上ではなくサーバーにおいて、要求されたアプリケーションソケットを開放する。
【００８９】
開示されている主題の一態様によると、上述のポリシーエンジンは、付加的な情報によって強化することができる。学習モデルベースの、イベント駆動制御ミドルウェアを提供することができ、これにより、よりよい決定が下されシステム及びネットワークリソースを最適化する。ミドルウェアの種々のモジュールは、生成されたデータを二つの異なる方法で独立に記憶できる。図３１に限定をするのではなく説明を目的として示すように、集中ストレージにおいて、各モジュールは、データストアの各モジュール情報ストアに情報を記憶できる。図３２に限定をするのではなく説明を目的として示すように、分散ストレージにおいて、各モジュール（例えば、キューマネージャー３２０１、サービス共有マネージャー３２０２、セキュリティマネージャー３２０３、ロケーションマネージャー３２０４、システムマネージャー３２０５、ネットワークマネージャー３２０６及びポリシーエンジン３２０７）はデータをローカルで管理することができる。これらのモジュールは、少なくとも２種の異なる方法、スキーマベースストレージ及びドキュメントベースストレージ、でデータを記憶することができる。スキーマ（これはどのようにデータを記憶するかの青写真を作成するためのデータ構成を意味する）ベースストレージにおいて、各モジュールは、ベーススキーマファイルを定義することができ、これはデータをどのように記憶するかを記載するものである。図３３（Ａ）に限定をするのではなく説明を目的として示すように、一つのベース構造ファイル及び複数のデータファイルがあってもよい。データベースターミノロジーにおいて、テーブルは一回定義でき、複数のレコードをテーブルに記憶できる。ドキュメントベースストレージにおいて、データは直接、独立したドキュメントファイルに記憶できる。図３３（Ｂ）に限定をするのではなく説明を目的として示すように、構造及びデータの両者が同一ファイル上にあってもよい。
【００９０】
各モジュールは、独立にそれぞれのスキーマを定義できる。ミドルウェアを他のモジュールによって拡張できるように、モジュール情報ストアも拡張することができる。情報ストアは、キー値ハッシュテーブルベースシステム、フラットファイルベースシステム、又はローカルにインストールされた又はリモートサーバー上の関係データベース管理システム（ｒｅｌａｔｉｏｎａｌ  ｄａｔａｂａｓｅ  ｍａｎａｇｅｍｅｎｔ  ｓｙｓｔｅｍ、ＲＤＢＭＳ）であり得る。
【００９１】
記憶されたデータを解析して、デバイスと通信する際又はネットワーク選択をする際により良い決定を下してリソースを最適化することができる。各モジュール毎に別々にデータを生成し記憶できるため、実行時間はモジュールに依存し得る。
【００９２】
学習の場合、事前に問題が知られており、学習アルゴリズムは、所定のデータ、即ちトレーニングセット（即ち、予測し得る関係を見出すために情報科学の様々な分野で用いられるデータのセット）、を用いてモデルを作成でき、これにより知識ベースが形成される。例えば、制約なしに、人工神経網（Ａｒｔｉｆｉｃｉａｌ  Ｎｅｕｒａｌ  Ｎｅｔｗｏｒｋｓ、ＡＮＮ）及び隠れマルコフモデル（Ｈｉｄｄｅｎ  Ｍａｒｋｏｖ  ｍｏｄｅｌｓ、ＨＭＭ）を用いることができる。知識ベースは、上記の問題に答えるために使用することができる。マイニングの場合、問題は当初、定義されていない。マイニングアルゴリズムは、例えば分類及びクラスター化アルゴリズムを用いて、所定のデータのセット内でパターンを捜すことができる。
【００９３】
開示されている主題の一態様によると、図３４に限定をするのではなく説明を目的として示すように、解析アルゴリズムは、学習又はマイニングベースであり得る。学習ベースのアルゴリズム（例えば、図３４におけるアルゴリズム１  ３４０１及びアルゴリズム２  ３４０２）において、決定は、記憶済み知識ベース（例えば、知識ベース１  ３４０３及び知識ベース２  ３４０４）に基づいて行うことができる。これらのアルゴリズムは、リアルタイムデータ３４０５に基づいて、次の属性値を予測することができる。例えば、「次のＷｉ−Ｆｉホットスポットは高い帯域幅可用性を有するか」という問題に対し、アルゴリズムは、Ｗｉ−Ｆｉパフォーマンスパラメーター、アクセス時間、及びロケーション等の記憶済みデータから学習をする  ３４０６及び３４０７。一旦知識ベースが作成されると、アルゴリズムは、リアルタイムデータ３４０５を入力として用い、高帯域幅Ｗｉ−Ｆｉホットスポット可用性を予測することができる。
【００９４】
モジュール３４０８は、この有用なデータを将来においても用いることができる。図３５に限定をするのではなく説明を目的として示すように、モジュールが情報をポリシーエンジンに提供する場合、ポリシーエンジン及び／又はモジュールは、上記有用なデータをより良い決定を下すために用いることができる。例えば、ネットワークマネージャー（ｎｅｔｗｏｒｋ  ｍａｎａｇｅｒ、ＮＭ）は、事前に記憶済みのデータを直接用いて、スキャンされた４個の近接ネットワークのうち信頼性の最も高いネットワークを返すことができる。
【００９５】
マイニングベースのアルゴリズム（例えば、図３４に示す３４０９）において、有用なパターン３４１０は、事前に記録されたデータから調べることができる  ３４１１。これらのパターンは、よりよいユーザーエクスペリエンス及びデバイス性能を提供できる。例えば、ＮＭは、例えばネットワークプロバイダー、パフォーマンスパラメーター、ネットワークコスト、帯域幅及びロケーション等の選択済みネットワーク情報を将来的な引き渡し遅延の最適化のために記録することができる。
【００９６】
開示されている主題の一態様によると、ＮＭは、マイニングアルゴリズムを用いて、ユーザーの日常経路の地理的地図を作成するために、ネットワークアクセスデータを解析する。この地図は、ポリシーエンジンがネットワークアクセス決定を下す際に役立たせることができる。例えば、エンジンが、５分以内に安価なＷｉ−Ｆｉネットワークが得られることを知っている場合、データアップロードのためにＬＴＥを使用することをやめ、Ｗｉ−Ｆｉネットワークを待つことができる。図３６は、ネットワーク選択最適化のための、ユーザーの自宅からオフィスまでの日常経路を示すが、これは限定をするのではなく説明を目的とするものである。ＮＭは、経路をＵＥのロケーションに基づいて異なるゾーンに分割することができる。図３６に示すように、ゾーン１、２、４、及び５はＷｉ−Ｆｉに対応しており、ゾーン３はＬＴＥのみに対応している。ユーザーは、ネットワーク１（Ｎ１）と契約しているため、ＵＥは、Ｎ１に属する全てのアクセスポイント（ＡＰ）のｍａｃアドレスを保管している。ＵＥがこの経路に沿って移動すると、ポリシーエンジンによるゾーン内の他のネットワークの探索を行うこと無しに、引き渡しを直接行うことができる。
【００９７】
各モジュールは、種々の属性を記憶することができる。例えば、ロケーションマネージャーは、毎日の往復、ロケーション、ＧＰＳ座標、及び時間を記憶することができる。ネットワークマネージャーは、ネットワークＳＳＩＤ、ロケーション、時間、パフォーマンス、有効時間（Ｔｉｍｅ  ｔｏ  Ｌｉｖｅ、ＴＴＬ）、近接ネットワーク、及びコストを記憶することができる。セキュリティマネージャーは、ネットワーク資格情報、デバイス資格情報、ローカルアイデンティティ、資格情報のＴＴＬ、ユーザー資格情報を記憶することができる。サービス共有マネージャーは、デバイス、ロケーション、共有サービス、サービスアクセス時間、及びユーザーｉｄを記憶することができる。システムマネージャーは、アプリケーションＣＰＵ、メモリー、ネットワーク使用度（セッション時間）、及びバッテリー使用度を記憶することができる。これらの値に基づいて、ポリシーエンジンは、クラウドプラットフォームに接続されたアプリケーションの負荷を動的に移動することができ、これにより、例えば後により詳細に説明するが、マシンビジョン、リアルタイム画像処理及びゲーム等においてＵＥに対する負荷を減少させる。
【００９８】
開示されている主題の一態様によると、制御ミドルウェアモジュールは、制御データを記憶し、デバイスネットワーキング使用パターンを推測し知識ベースを作成する。この知識ベースは、通信ネットワークにおける従来の制御プレーン及びデータプレーンの上位の知識プレーンとして見ることができる。知識プレーンは、よりよい決定を下すために制御プレーンに対して入力を提供することができ、決定に引き続き学習をする。
【００９９】
図３７は、知識プレーン機能を示すが、これは限定をするのではなく説明を目的とするものである。制御プレーンは、該プレーンによって下された制御決定に関連する全てのデータを記憶することができる。認知プレーンは、記憶済み生データを取得することができ、学習又はマイニングアルゴリズムを用いて取得データを処理する。処理したデータは、知識ベースとして再び記憶することができる。知識ベース情報は、よりよい決定を下すために制御プレーンに戻すことができる。
【０１００】
開示されている主題の他の態様によると、異種ネットワーキング環境におけるネットワークアクセス及びエンド・ツー・エンド（ｅｎｄ−ｔｏ−ｅｎｄ、Ｅ２Ｅ）通信用の、セキュリティ保護された統一通信フレームワークが、共通アクセスパターンを抽出することにより提供される。このアーキテクチャは、上述の再設計されたモビリティ対応ネットワーキングスタックを使用でき、図１６に示すように、ネットワークインフラストラクチャは、サービスプレーンとインフラストラクチャプレーンとに論理的に分離されている。サービスプレーンは、ネットワークサービス及びアプリケーションに焦点を合わせたものとすることができる。サービスアクセスマネージャー（Ｓｅｒｖｉｃｅ  Ａｃｃｅｓｓ  Ｍａｎａｇｅｒ、ＳＡＭ）ネットワークエレメントは、モバイルノード（ｍｏｂｉｌｅ  ｎｏｄｅ、ＭＮ）セキュリティ管理（例えば、認証及び承認）、及び異なる管理ドメイン及び／又は異種技術に対するアクセス制御の実行の任を負うことができる。インフラストラクチャプレーンは、物理ネットワークインフラストラクチャ管理に対し、独自に焦点を合わせたものとすることができる。
【０１０１】
ネットワークマネージャー（Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｒ、ＮＭ）モジュールは、全てのアクティブなネットワークインターフェースの情報を保持、監視でき、ネットワークイベントをポリシーエンジン（Ｐｏｌｉｃｙ  Ｅｎｇｉｎｅ、ＰＥ）へと配信することができる。ＳＭモジュールは、全アクセス資格情報の各々を管理し記憶することができる。ＳＭは、ネットワーク及びデバイスの両者に対して、異種モバイル環境でのＭＮのアクセスサービス認証を提供することができる。次いで、ポリシーエンジン（Ｐｏｌｉｃｙ  Ｅｎｇｉｎｅ、ＰＥ）は、モバイルハンドオーバー決定を安全な方法で下すために、ＳＭ及びＮＭと共同で作業をすることができる。
【０１０２】
図１６に示すように、ネットワークに関して、サービスプレーンは、ＮＣＦプロトコルに対するモビリティマネージャーサービス、ＬＣＦプロトコルに対するＭＮアイデンティティ及びネットワーク情報サービス、及びＰＣＦプロトコルに対するスペクトルデータベースサービスを管理でき、ＭＮのアクセス制御をサービスプロバイダーに提供することができる。ユーザーは、これらのサービスを別途サードパーティープロバイダーから利用することもできる。インフラストラクチャプレーンは、ＬＣＦプロトコルと通信し、ネットワークリソースへのアクセスの許可の前に信頼を確立できる。この信頼は、サービスプレーン認証を用いて間接的に確立することができる。デバイスに関して、インフラストラクチャプレーンは、技術固有であってよく、デバイス発見及びデバイス間の信頼の確立を提供することができる。制御ミドルウェアは、ローカルで実行中のサービスのアクセス制御をユーザーに提供する論理サービスプレーンであり得る。セキュリティで保護されたアクセスフレームワークは、資格情報管理、セキュリティで保護されたネットワークに対する資格情報の使用、及びデバイス認証を提供でき、更には、アプリケーションの要求に基づいて、セキュリティで保護されたエンド・ツー・エンドデータ通信チャンネル機能を提供することができる。
【０１０３】
ＭＮが新しいサービスドメインに入ると、正常なネットワークアクセスのために、適切なネットワークアクセス資格情報を有することが要求され得る。各サービスドメインに対して要求されるアクセス資格情報は、関与しているサービスドメイン間のサービス協約によって異なることがあるが、全ての場合において、これら資格情報は「ユーザーアイデンティティ」と関連付けらており、この「ユーザーアイデンティティ」は、ネットワークアクセス資格情報によって、セキュリティで保護されたチャンネルを作成した後に検証される。サービスプロバイダーは、例えば、国際移動体サブスクライバー識別番号（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ、ＩＭＳＩ）等のユーザーアイデンティティをＵＩＣＣにインストールされたＵＳＩＭアプリケーションによって発行することができる。ネットワークアクセス技術は、ユーザーアイデンティティの確認及びアクセス制御のために、それぞれの資格情報タイプを有する異なるタイプの認証メカニズムを有することもできる。
【０１０４】
無線通信において、固定ユーザーアイデンティティは、エアインターフェースにおけるセキュリティで保護された機密チャンネルを確立した後に、ネットワークとのみ共有することができる。ＭＮは、ノード認証の後に共有シークレットを確立することによって機密リンク層一時チャンネルを作成する必要があり、ネットワークにおいてそのアイデンティティを共有する。ＬＴＥの場合、セキュリティで保護されたチャンネルは、後により詳しく論じるが、ＥＡＰ−ＡＫＡプロシージャ（ＫＡＳＭＥ）によって生成されるマスターセッションキーを用いて作成することができる。Ｗｉ−Ｆｉネットワークにおいて、セキュリティで保護されたチャンネルは、セッションマスターキー（ｍａｓｔｅｒ  ｋｅｙ、ＭＫ）を用いて確立でき、ＭＫは２種の方法で生成できる。ＷＰＡ２パーソナルモードにおいて、ユーザーは両側、即ち、デバイス及びネットワーク、の制御を有するため、ＭＫを、対称共有シークレット（例えば、パスフレーズ及び／又はパスワード）を用いて生成することができる。ＷＰＡ２エンタープライズモードにおいて、ＭＫは、正常なクライアント認証の後に生成でき、このクライアント認証は、ＥＡＰフレームワークを用いて行うことができる。異なるサービスドメイン及びアクセス技術（例えばＬＴＥ又はＷｉ−Ｆｉ）間で同一の発行済み資格情報を再使用できるようにするため、ターゲットサービスドメインは、互換性のある認証フレームワーク及びメカニズムに対応する必要がある。例えば、ＥＡＰフレームワーク及びＡＫＡ認証メカニズムは、ＬＴＥ及びＷｉ−Ｆｉネットワーク間での認証のためにＵＩＣＣに記憶済みの同一な資格情報の再使用を可能にする。
【０１０５】
サービスプロバイダーが発行し、ＵＩＣＣによって配布されたユーザーアイデンティティ（例えばＩＭＳＩ）は、アイデンティティを連合した形で管理するために用いることができる。サービスプレーンは、ＭＮを異なるインフラストラクチャプロバイダー間で認証でき、セキュリティで保護された通信のために、インフラストラクチャ−プレーンとＭＮとの間での信頼の確立を可能とすることができる。標準連合アイデンティティ管理スキーマと同様に、サービスプレーンは、他の自律セキュリティ管理ドメイン間における、ＭＮのアイデンティティ情報のポータビリティを可能とすることができる。更に、ＭＮのプライバシーを維持するために、別の擬似アイデンティティを作成し、元のアイデンティティの完全性を保つことができる。擬似アイデンティティメカニズムは、元のアイデンティティにマップされた別のアイデンティティを作成することができる。擬似アイデンティティは、ネットワーク間で共有される唯一のアイデンティティであることができ、元のアイデンティティは不変のままとされる。アイデンティティが盗難された場合、新しいアイデンティティを、元のアイデンティティを危険にさらすこと無く作成できる。また、迅速な再認証のため、複数の擬似アイデンティティを作成し、各インフラストラクチャプロバイダーで事前に共有できる。
【０１０６】
開示されている主題の一態様によると、セキュリティで保護された通信で必要となる資格情報は、訪問したネットワーク又は他のノードに対するノードアイデンティティ（認証）の検証のため、サードパーティーによってリモートで生成できる。セルラーネットワークに関し、資格情報は、サービスプロバイダーによって生成することができ、ＵＩＣＣカードを用いて物理的に配布することができる。Ｗｉ−Ｆｉネットワークの場合、認証のために、異なる実装固有クライアントアプリケーションを用いてユーザー資格情報を記憶することができ、又はＵＩＣＣ資格情報をＥＡＰフレームワーク内で再利用できる。
【０１０７】
一実施形態において、ノード認証は、非対称公開鍵暗号メカニズム（例えば証明書）を用いて行うことができ、これはサードパーティー認証局（Ｃｅｒｔｉｆｉｃａｔｅ  Ａｕｔｈｏｒｉｔｙ、ＣＡ）エンティティの使用を必要とする。サービスアクセスマネージャー（Ｓｅｒｖｉｃｅ  Ａｃｃｅｓｓ  Ｍａｎａｇｅｒ、ＳＡＭ）ネットワークエレメントは、信頼を任意の２個の通信ノード間で確立するために、このサードパーティーＣＡ機能を提供することもできる。他の実施形態において、ＣＡ機能は、サードパーティーによって外部から提供されてもよい。
【０１０８】
ハンドオーバー遅延を減少し、かつ付加的なネットワーク情報を得るために、ある実施形態においては、ＬＣＦプロトコルは、ネットワーク情報マネージャーから近接ネットワークの付加的な情報を得るために、外部のネットワークエレメントのサポートを必要とし得る。ＮＩＭに対してセキュリティで保護された通信が必要な場合、ＬＣＦプロトコルは、ノード認証のためにＳＡＭによって発行され、この通信用のセキュリティで保護されたチャンネルを確立するための証明書を用いることができる。複数のネットワークエレメントが、同一のインフラストラクチャプロバイダーの制御下にある場合、リンク層アクセス用に生成されたセッション資格情報は、ＬＣＦプロトコルに対して再利用することができ、資格情報管理の複雑さが減少する。
【０１０９】
ノード間通信パス又はノードからモビリティマネージャーへの通信に関し、ネットワーク層暗号化方法は、証明書ベースのアルゴリズムをも必要とし得る。ネットワーク層においてセキュリティで保護されたＥ２Ｅ通信チャンネルを確立するために、ＩＰｓｅｃは、ノード認証のためにＣＡが発行した証明書を活用することができる。また、複数のＮＣＦモビリティプロトコルも、同一のＣＡが発行した証明書も活用し、モビリティマネージャーとのセキュリティで保護されたチャンネルを確立することができる。従って、セキュリティフレームワークは、ＣＡが発行した資格情報を、ＬＣＦとネットワーク情報サーバーとの通信、ＮＣＦとモビリティマネージャーとの通信、及びＥ２Ｅアプリケーションデータ機密性に対して再利用することにより資格情報の複雑さを減少させることができる。
【０１１０】
開示されている主題の他の態様によると、上記図２２に示すように、ＳＭモジュールは、ＭＮのサービスドメイン（例えば、自宅、オフィス及び／又はホットスポット）の制御下に無いネットワークに対するユーザー固有資格情報を含む全てのネットワークアクセス資格情報を記憶し管理することができる。ＬＣＦ及びＮＣＦプロトコル資格情報もＳＭ内に記憶することができる。ＳＭは、セキュリティで保護されたストレージのためにオペレーティングシステムの資格情報管理機能を活用できる。十分な容量がある場合、ＳＭは、ローカルディスク又はＵＩＣＣカードストレージに格納されたメモリーベースデータストアキャッシュを保持することができる。ＵＩＣＣは、単一の物理モバイルデバイスからユーザー資格情報ストレージを分離でき、これにより同一のＵＩＣＣカードを異なるデバイスで使用可能となる。更に、資格情報は、バックアップ用のクラウドベースサービスに記憶することもでき、これにより、ＵＩＣＣを必要とせずに複数のデバイス上で資格情報が利用可能となる。
【０１１１】
開示されている主題の一態様によると、セキュリティマネージャーモジュールは、ネットワークアクセス資格情報を管理し、インフラストラクチャプレーンに対するセキュリティで保護されたアイデンティティの公開による、ＳＡＭを用いたサービスプレーン認証及び承認を実行し、セキュリティで保護されたＥ２Ｅ通信セットアップの確立のために資格情報を提供する。ＳＭモジュールは、以下の情報を有する資格情報テーブルを保持できる：資格情報ｉｄ、資格情報のタイプ（例えば、証明書、事前共有鍵及び／又はログインとパスワードの組み合わせ）、資格情報の使用（例えばＨＩＰプロトコル、ネットワークアクセス）、アクセスサービスｉｄ、及び付加的情報（例えば、ネットワークの名前及びタイプ、ロケーション等）。モビリティイベントに関して、ＳＭは、ＮＭと連係して働き認証プロシージャを実行することもでき、結果をＰＥに返すことができ、ＰＥはＮＭにハンドオーバーを実行するように指示する。
【０１１２】
開示されている主題の一態様によると、制御ミドルウェアは、サービスプレーンとインフラストラクチャプレーンとの間での認証機能の論理的な分離を可能とすることができる。サービスプロバイダーは、インフラストラクチャアクセスが認可される前に、ＭＮを認証し承認する必要がある。図３８は、ネットワークアクセスを得るために必要な２段階のプロシージャを示すが、これは限定をするのではなく説明を目的とするものである。
【０１１３】
第１段階において、ＳＭは、ＭＮの擬似アイデンティティを安全に仮のアクセスチャンネルを通じてインフラストラクチャプロバイダーに提供することができる。仮のアクセスチャンネルは、ユーザーと対応するサービスプロバイダーとを結び付けている。第２段階において、ＳＭは、インフラストラクチャプロバイダーのリソースを用い、事前に確立された仮のアクセスチャンネルを通じて、ＭＮのサービスプロバイダーによる認証及び承認を実行することができる。例えば、ＬＴＥの場合、非アクセス階層（Ｎｏｎ  Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ、ＮＡＳ）チャンネルは、ＭＮとＭＭＥとの間の制御プレーンセキュリティコンテキストを作成することができる。Ｗｉ−Ｆｉの場合、セキュリティコンテキストは、ＭＮ及びＷｉ−Ｆｉ認証サーバーに関連したマスターキー（ｍａｓｔｅｒ  ｋｅｙ、ＭＫ）の対を用いて作成することができる。インフラストラクチャプロバイダーは承認プロシージャに関わっていないので、資格情報に対する実際のアクセスを持たない。正常な承認の後、インフラストラクチャプロバイダーはネットワークアクセスポリシーを得ることができる。
【０１１４】
サービスプレーンとインフラストラクチャプレーンとの間での通信は、安全とみなすことができ、これらの間には事前に確立された信頼関係がある。通常、サービスプロバイダーは、標準認証メカニズムに対応したインフラストラクチャプロバイダーの各々とサービス協約をしている。
【０１１５】
一旦ＭＮがＳＡＭによって認証され承認されると、ＭＮは、物理インフラストラクチャプレーンアクセスプロシージャを開始し、ＩＰネットワーク接続性を得ることができる。仮のセキュリティコンテキストは、制御及びデータプレーンの両者に対して、ＭＮと、ネットワーク接続点（Ｐｏｉｎｔ  ｏｆ  Ａｔｔａｃｈｍｅｎｔ、ＰｏＡ）との間に作成できる。例えば、ＬＴＥの場合、ＡＳ機能層は、ＭＮとｅＮＢとの間にセキュリティコンテキストを作成できる。Ｗｉ−Ｆｉの場合、二つ一組のマスターキー（ｐａｉｒｗｉｓｅ  ｍａｓｔｅｒ  ｋｅｙ、ＰＭＫ）がＭＮとＡＰとの間にセキュリティコンテキストを提供できる。
【０１１６】
開示されている主題の一態様によると、ＮＣＦプロトコルは、アプリケーション要件に基づいて、セキュリティで保護されたＥ２Ｅ通信チャンネルを作成するために用いることができる。制御ミドルウェアは、ＣＮの行先アドレス（例えば、ＨＩＴタグ又はＩＰアドレス）に基づいてＮＣＦプロトコルを選択できる。既定では、ＮＣＦはＨＩＰを選択できるが、これは両通信ノードがＨＩＰに対応している場合である。ＨＩＰは、以下に詳細を論じるディフィー・ヘルマン（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）メカニズムを用いてベース交換プロセスを実行し共有シークレットを確立できる。機密性を提供するために、共有シークレットを用い、データ及び制御パケットの両者を暗号化することができる。アプリケーションがデータ機密性を必要としない場合は、制御パケットのみを暗号化することができる。行先アドレスがＩＰｖ６に対応している場合、制御ミドルウェアは、ＭＩＰｖ６  ＮＣＦプロトコルを選択でき、アプリケーション層プロトコルに基づいて、ＴＬＳ又はＩＰｓｅｃ通信チャンネルを確立することができる。ＣＮがＨＩＰにもＩＰｖ６にも対応していない場合、ミドルウェアは、事前に定義されたセキュリティメカニズムを用いずに、ＮＣＦ用のＩＰｖ４機能に戻ることができる。
【０１１７】
開示されている主題の一態様によると、制御ミドルウェアは、ＳＭによって提供されるネットワークアクセス資格情報を用いた事前認証を実行することができる。図３９に限定をするのではなく説明を目的として示すように、新しいＩＰアドレスを安全に獲得した後、制御ミドルウェアは、各ＮＣＦプロトコルに信号を送り各アクティブなフローに対するモバイルハンドオーバーを実行する。
【０１１８】
制御ミドルウェアのネットワークマネージャー（Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｒ、ＮＭ）モジュールは、ネットワークインターフェースを保持し、ＬＣＦを介して常時監視することができる。ＮＭは、信頼済みアクセスサービス（Ｔｒｕｓｔｅｄ  Ａｃｃｅｓｓ  Ｓｅｒｖｉｃｅ、ＴＡＳ）テーブルを保持でき、このテーブルは、サービスプロバイダー又はユーザーによって動的に更新することができる。ＴＡＳは、例えばｉｄ、認証プロシージャ、デバイスタイプ、資格情報、コスト、帯域幅、及びアクセス履歴等のアクセスサービス情報を記憶することができる。ＮＭはまた、２種の追加テーブル、即ちアクティブアクセスサービス（Ａｃｔｉｖｅ  Ａｃｃｅｓｓ  Ｓｅｒｖｉｃｅ、ＡＡＳ）テーブル及び候補アクセスサービス（Ｃａｎｄｉｄａｔｅ  Ａｃｃｅｓｓ  Ｓｅｒｖｉｃｅ、ＣＡＳ）テーブル、を保持することができる。ＡＡＳテーブルは、現在接続されているアクセスサービスのリストを保持することができる。ＣＡＳテーブルは、利用可能な信頼済みアクセスサービスのリストを保持することができる。
【０１１９】
最適なネットワーク接続性に関し、ＮＭは、例えば信号強度、待機時間、及び利用可能帯域幅等の関連ネットワーク性能属性を、ＬＣＦインターフェースを用いて監視することができる  ３９−０１。属性値のいずれかが閾値を超えると、ネットワークイベント警告が生じる。ＮＭは、ＣＡＳテーブルからのｔｏｐ−ｋアクセスサービスによってネットワークイベントオブジェクトを作成することができ、ポリシーエンジン（ｐｏｌｉｃｙ  ｅｎｇｉｎｅ、ＰＥ）モジュールに信号を送ることができる  ３９−０２。ＰＥは、各アプリケーションに対する現在のポリシーを評価でき、ハンドオーバー（もしもある場合には）のためのネットワーク選択の決定を下すことができる。ネットワークハンドオーバー決定がなされた場合、ＰＥは、アクセスサービス識別子を用いてＳＭに信号を送り  ３９−０３、事前認証を行うことができる。ＳＭは、アクセスサービスのために（もしも利用可能な場合）、対応する擬似アイデンティティ、認証メカニズム、及び資格情報を選択することができる  ３９−０４。ＳＭは、ネットワーク認証リクエストをＬＣＦに対して送ることができ  ３９−０５、ＬＣＦはネットワークアクセスプロシージャを実行し  ３９−０６、認証結果をＳＭに返すことができ  ３９−０７、次いでＳＭは認証結果をＰＥへと送ることができる  ３９−０８。認証結果に基づき、ＰＥは、ＮＭに信号を送りモバイルハンドオーバーを実行することができる  ３９−０９。
【０１２０】
ＭＮは、ロケーションの更新を、各ＮＣＦプロトコルに対するＭＭに送信できる  ３９−１０。ＭＩＰｖ６の場合、バインディングアップデートメッセージを送信し、ＩＰｓｅｃによって保護されたＨＡキャッシュを更新することができ、ＲＲ確認機能により保護された全てのフローに対してＲＯを実行できる。ＨＩＰの場合、ＭＮは、送信者の秘密鍵によって署名されたＵＰＤＡＴＥメッセージを用いてＲＶＳとＣＮの両者に通知することができ、送信者のＨＩ（公開鍵）によって確認できる。ＭＮの新しいロケーションは、ＵＰＤＡＴＥメッセージのＬＯＣＡＴＯＲパラメーター内に置くことができる。ＵＰＤＡＴＥメッセージは、初期のＢＥＸメカニズムからの事前に確立され、セキュリティで保護されたチャンネルを用いて送信することができる。
【０１２１】
訪問したネットワークが、ＭＮのサービスプロバイダーと事前サービス協約を有する場合、ＵＳＩＭ資格情報を再利用してＥＡＰフレームワークを用いたノード認証を提供することができる。更に、例えば、自宅、オフィス又は公のホットスポットにおけるＷｉ−Ｆｉ等の独立ネットワークに関して、ＳＭモジュールは、認証時に、各資格情報を記憶し選択することができる。図４０は、ＵＳＩＭ資格情報を再利用して、Ｗｉ−ＦｉインフラストラクチャプロバイダーのＡＡＡサーバーによってＭＮのアクセスを認証するＳＡＭサーバーを示すが、これは限定をするのではなく説明を目的とするものである。ＬＣＦは、Ｗｉ−ＦｉリンクＳＡＰを用いて認証リクエストを開始することができ、ＥＡＰ−ＡＫＡ法を用いてネットワーク認証を実行することができる。正常な認証の後、ＳＡＭは、訪問したネットワークのＡＡＡサーバーに対してマスターセッションキーを返すことができ、ＭＮも、同じマスターセッションキーを独立に生成することができる。更には、訪問したネットワークのＡＡＡサーバーは、将来のセッションの有効性のために、セッションキートークンを新規に接続されたＭＮに対して送信することができる。
【０１２２】
ＬＣＦリンクＳＡＰは、セッションキートークンを記憶することができ、これらトークンはインフラストラクチャプロバイダーとＭＮとの間で共有される。セッションキートークンは、高速な再認証プロシージャのための最適な有効時間（Ｔｉｍｅ−Ｔｏ−Ｌｉｖｅ、ＴＴＬ）を提供することができる。ＴＴＬの値は、ＭＮのアクセスパターンに基づき更に最適化できる。これにより、ＭＮが頻繁に同一のインフラストラクチャプロバイダー、例えば都市圏Ｗｉ−Ｆｉネットワークプロバイダー、にアクセスする場合、認証時間を低減することができる。
【０１２３】
開示されている主題の一態様によると、制御ミドルウェアは、サービスアクセス制御用の一般的なプラットフォームも提供することができ、ローカルネットワーク内のセキュリティで保護されたデバイスサービスの共有を可能にする。デバイスは、ピア・トゥ・ピア又は集中プロトコルを用いて発見することができる。デバイスサービスの共有により、デバイスの無承認使用、悪意のあるデバイスによるサービス途絶、盗聴等、セキュリティが脅威にも晒され得る。従って、サービスは認証され且つ承認される必要があり、Ｅ２Ｅ通信は暗号化される必要がある。ネットワークアクセスと同様に、デバイスアクセスも２種の論理ステップ、即ちインフラストラクチャ及びサービスプレーンアクセス、に抽象化することができる。インフラストラクチャプレーンアクセスは、デバイスアクセス用の認証を提供することができる。サービスプレーンは、サービスアクセス承認を提供することができる。
【０１２４】
開示されている主題の一態様によると、デバイスに関して、インフラストラクチャ−プレーンは、技術に固有なものであり、デバイス発見及びデバイス間の信頼確立を提供する。制御ミドルウェアは、ローカルに実行されているサービスのアクセス制御をユーザーに提供する論理サービスプレーンであり得る。デバイスアイデンティティは、例えば、ＭＡＣアドレス等のリンク層アクセス技術を用いて、記憶済みの資格情報からローカルで生成でき、またサードパーティーによって事前に割り当ることもできる。
【０１２５】
ＮＭはＬＣＦと連係して働き、ユーザー設定認証方法及び対応する資格情報を用いてデバイス発見及び信頼確立を行うために、仮のデバイスアクセスチャンネルを提供することができる。信頼済みデバイスの識別のために、ＮＭモジュールは、アクセスサービスタイプをデバイスとし、ＴＡＳテーブルを用いることができる。各テーブル項目は、アクセスサービスｉｄ、認証プロシージャ、タイプ、及び対応している動作を含むことができる。資格情報管理の複雑さを減少させるため及びピア・トゥ・ピア接続性のために、各アクセス技術インターフェースの認証資格情報は、ユーザーによってローカルで生成することもでき、又は事前に割り当てることもできる。
【０１２６】
正常な信頼確立の後、ＰＥは、デバイス可用性に関する信号を実行中のサービスに対して送ることができ、アプリケーション固有ユーザーポリシーを実施しアクセス制御を提供する。
【０１２７】
開示されている主題の一態様によると、サービスに安全にアクセスするために、制御ミドルウェアは、既定では、ＨＩＰを使用することができる。ローカル環境において、デバイス発見プロセスは、ＣＮのＩＰアドレスによってＮＭを提供することができる。ＣＮのアイデンティティが事前に分からない場合、ＭＮは、ＨＩＰ  ＢＥＸプロセスを日和見モード（例えばＣＮのＨＩＴタグがＮＵＬＬ）で使用することができる。正常なＢＥＸの後、Ｄ−Ｈメカニズムを用いて、共有シークレットを確立でき、セキュリティで保護された通信を作成することができる。
【０１２８】
開示されている主題の他の態様によると、制御ミドルウェアは、セキュリティで保護された信頼済み環境において、複数のデバイス間でのサービス共有のために汎用プラットフォームを提供する。サービス共有マネージャー（ｓｅｒｖｉｃｅ−ｓｈａｒｉｎｇ  ｍａｎａｇｅｒ、ＳＳＭ）は、制御ミドルウェアにデバイス間での新しいフローを作成させることができ、又はデバイスを追加及び／又は削除することにより既存のフローを変更することができる。
【０１２９】
開示されている主題の一態様によると、ＳＳＭは、新しいサービス共有ＡＰＩを用いて、信頼済みネットワーキング環境におけるサービス共有を可能とする。ＳＳＭモジュールは、３種のサービス：（１）サービス登録、（２）サービスリクエスト及び（３）フロー移行、を提供できる。図４１は、ＳＳＭの内部コンポーネントの例を示すが、これは限定をするのではなく説明を目的とするものである。これらのコンポーネントは、ＳＳＭコントローラー４１０１、通信ブロック４１０２、及びデータストア４１０３を含む。サービス評価コンポーネント４１０４は、サービスリクエストに基づいて、類似したサービスを評価、採点できる。フロー移行コンポーネント４１０５は、一つのデバイスから他のデバイスへのセッションモビリティを実行できる。サービス登録テーブル４１０６は、デバイス上に登録されたサービスを保持でき、サービスリクエストテーブル４１０７は、ネットワーク内におけるリクエストされたサービスを保持し、監視することができる。接続済みデバイステーブル４１０８は、アクティブな接続済みデバイスのリストを、対応するロケーションの詳細（例えば、ＩＰアドレス、ネットワークＳＳＩＤ、デバイスタイプ等）とともに保持することができる。
【０１３０】
開示されている主題の一態様によると、ミドルウェアは、２種のサービス、即ちシステムサービス及びアプリケーションサービス、を定義することができる。システムサービスは、カメラ、ビデオディスプレイ、オーディオスピーカー、マイク、センサー等の周知のハードウェアサービスであることができる。アプリケーションサービスは、ユーザーアプリケーションによって定義することができる。アプリケーションは、自身のサービスをプライベートで（同一アプリケーション内で）又は公開で共有することができる。ルーティング、ストレージ、及び計算等の公開サービスは、他のアプリケーションによって使用することができる。
【０１３１】
ソケット上でサービスが定義されている場合、そのサービスはリクエストのリッスンを開始でき、ＩＰアドレス及びポート番号によって識別することができる。他のピア又はクライアントは、このＩＰアドレス及びポート番号を用いてサービスと直接通信することができる。このモデルにおいて、クライアントは、サービスリクエストをする前に、サービスのロケーションを知る必要がある。サービスアイデンティティとロケーションとを分離するため、新しいネットワーキングＡＰＩ、即ちサービス＆クエリー、を導入することができる。サービスＡＰＩは、実行中のサービスの種々の属性、例えば、サービスＩＤ、ＵＲＩ、コンテキスト、記述等を指定することができる。クライアントは、サービスロケーションに関する知識無しに、属性を指定することにより、必要なサービスを照会することができる。
【０１３２】
サービスＡＰＩは、アプリケーションサービスを（例えばローカルに又はグローバルに）登録するために使用することができる。アプリケーションは、サービス属性の記述を入力パラメーターとしてサービスＡＰＩに渡すことができる。これらの属性は、サービス登録テーブル（Ｓｅｒｖｉｃｅ  Ｒｅｇｉｓｔｒａｔｉｏｎ  ｔａｂｌｅ、ＳＲｅｇ）に記憶できる。サービスに対して定義された属性は、Ｓｅｒｖｉｃｅ  ＩＤ、ＵＲＩ、Ｃｏｎｔｅｘｔ、Ｓｃｏｐｅ、Ａｃｔｉｏｎ、及びＤｅｓｃｒｉｐｔｉｏｎであり得る。Ｓｅｒｖｉｃｅ  ＩＤは、実行中のサービスに対して一意な識別子を提供することができる。これは、実行中のアプリケーションによって割り当てることができ又はソケットの生存期間に対して動的に生成できる。ＵＲＩは、実行中のサービスの統一資源識別子（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ、ＵＲＩ）を定義することができる。これは、サービスを一意的に定義するために使用できる。例えば、ｅｄｕ．ｃｏｌｕｍｂｉａ．ｃｓ．ｉｒｔ．ｓｉｎｅはｓｉｎｅサービスを一意的に定義する。ＵＲＩはワイルドカードとともに用いることもできる。例えば、ｅｄｕ．ｃｏｌｕｍｂｉａ．ｃｓ．ｉｒｔ．＊は、ｉｒｔからの全てのサービスを定義する。Ｃｏｎｔｅｘｔは、ソケットが定義されているロケーション、例えばローカルサブネット、室内、組織又はグローバル（例えば公共のインターネット）等、を定義することができる。Ｓｃｏｐｅは、例えば、ｐｕｂｌｉｃ、ｐｒｉｖａｔｅ、又はｐｒｏｔｅｃｔｅｄ等、サービスのスコープを定義できる。Ｐｒｉｖａｔｅにおいて、同一のアプリケーションのみがこのサービスにアクセスできる。これは、サービスＵＲＩによって識別することができる。例えば、ＵＲＩがｅｄｕ．ｃｏｌｕｍｂｉａ．ｃｓ．ｉｒｔ．ｓｉｎｅであるサービスは、異なるデバイス上で実行中の同一のＵＲＩサービスのみから見ることができる。アプリケーションが全サービスを共有したい場合、例えばｅｄｕ．ｃｏｌｕｍｂｉａ．ｃｓ．＊のように、ワイルドカードを用いることができる。Ｐｕｂｌｉｃにおいて、サービスは、どのアプリケーションもが利用できるパブリックサービスである。アプリケーションは、その設計にもよるが、使用前に認証することができる。Ｐｒｏｔｅｃｔｅｄにおいて、同一グループ内のサービスが、このサービスにアクセスすることができる。モバイルデバイスユーザーがログインした場合、このユーザーのグループは、全てのアクティブなサービスに対する既定のグループであってよい。Ａｃｔｉｏｎは、クエリーリクエストが届いた場合に取られる動作を定義することができる。ＳＳＭコントローラーは、各登録済みサービスの動作を定義することができる。現在の定義済み動作状態は、ＦＯＲＷＡＲＤ、ＤＥＬＩＶＥＲ、ＤＥＬＡＹ、及びＤＲＯＰを含む。ＦＯＲＷＡＲＤにおいて、サービスクエリーリクエストは、アドレスフィールド内の割当て値に対して転送することができる。アドレスフィールドは、複数のアドレスを有することができ、ＳＳＭコントローラーは、設定に基づき、任意の一アドレス、２個以上又は全てを選ぶことができる。ＤＥＬＩＶＥＲにおいて、サービスクエリーを、ソケット上でリッスンしているサービスに対してローカルで配信することができる。アプリケーションがソケット上でｓｅｒｖｉｃｅ（）コールを呼び出した場合、既定の項目を、ＤＥＬＩＶＥＲ動作によって、対応するサービスｉｄとともに加えることができる。ＤＥＬＡＹにおいて、サービスクエリー解決を、動作の動的処理のために遅延させることができる。例えば、サービスがローカルにホストされていない場合、そのサービスはオンデマンドで配置できる。ＤＲＯＰにおいて、サービスクエリーは、ドロップすることができる。Ｄｅｓｃｒｉｐｔｉｏｎは、ソケットによりホストされるサービスの細分化詳細を定義することができる。例えば、ビデオディスプレイシステムサービスは、ビデオスクリーンサイズ：２３”、解像度：１９２０×１０８０画素、色域サポート：９８％等の詳細を提供することができる。アプリケーションがサービスをリクエストした場合、これらのパラメーターを照会することができる。これらは、実装に基づきＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ（ＪＳＯＮ）又はＸＭＬフォーマットで渡すことができる。
【０１３３】
サービス登録の機能フローを説明するために、例としてシステムアプリケーションは、ローカルネットワーク内でビデオディスプレイを共有するようにサービスを定義することができる。サービスセマンティクスは、ＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ表記法（ＪＳＯＮ）を用いて以下のように定義できる。
0006363999.tif 000002
【０１３４】
図４２は、サービス登録プロセスを示すが、これは限定をするのではなく説明を目的とするものである。アプリケーションは、ｓｏｃｋｅｔ．ｓｅｒｖｉｃｅ（ＪＳＯＮ）を呼び出し、サービスを制御ミドルウェアに登録することができる。ポリシーエンジンは、新しいサービス登録リクエストをＳＳＭへと渡すことができる。ＳＳＭ通信モジュールは、リクエストをコントローラーに渡すことができる。コントローラーは、サービスをＳＲＴに登録できる。成功時に、コントローラーは、ＳＲＴ項目の行番号を通信モジュールに返すことができる。失敗時には、ゼロを返すことができる。コントローラーは、新しいサービスを全ての接続済みデバイスに同時に配信することができる。ポリシーエンジンは、リクエストに対する応答を受信することができる。応答はアプリケーションに返すことができる。サービスがＳＳＭから削除された場合、同様なステップを用いることができる。サービスクラッシュの場合、ポリシーエンジンはサービスの削除を指示することができる。
【０１３５】
開示されている主題の一態様によると、デバイスは、ピア・トゥ・ピア又は集中型方式で、互いに見つけ合うことができる。ＳＳＭモジュールは、それ自身をＳＲｅｇテーブルにパブリックサービスとして登録できる。一旦デバイスが見つけられ、それらの間に事前に確立済みの信頼が存在すると、制御ミドルウェアネットワークマネージャー（ｎｅｔｗｏｒｋ  ｍａｎａｇｅｒ、ＮＭ）は、ポリシーエンジンにデバイスの存在に関する信号を送ることができる。ＰＥは、第１デバイスのローカルＳＳＭに信号を送ることができ、次いでこのローカルＳＳＭは第２デバイスのＳＳＭに接続することができ、信頼済み通信チャンネルを確立する。ＳＳＭは、サービス登録メタデータを互いに共有でき、従ってＳＲｅｇテーブルを更新することができる。
【０１３６】
各サービスは、優先度番号を有するように定義された記述内の属性に応じて採点することができる。複数のサービスが各サービスリクエストに対して見つかった場合、エバリュエーターモジュールは、リクエストされたサービス記述に基づきサービススコアを計算することができる。アプリケーションは、サービス可用性イベントを配信する際に、閾値を設定することができる（例えば、記述内に設定）。例えば、閾値は、スコアが７０％より大きい場合のみであって、サービスを３回評価した後のみ、又は最後のサービスが見つかってから２０秒後に初めて新しいサービスを評価した後のみとすることができる。エバリュエータースコアモデルは、設定可能である。正常な評価後、ＳＳＭは、ポリシーエンジンを介して全ての待機アプリケーションに対して新しいサービスの通知を送ることができる。各アプリケーションは、新たに見つかったサービスとの通信をそれぞれ独立に開始できる。
【０１３７】
図４３は、デバイス発見後のサービス解決のフローを示すが、これは限定をするのではなく説明を目的とするものである。ＮＭ４３０１は、デバイス情報を有する新規デバイス信号をポリシーエンジン４３０２に対して送ることができる（１）。ポリシーエンジン４３０２は、この新規デバイス信号をＳＳＭ４３０３に送ることができる（２）。ＳＳＭコントローラー４３０４は、セキュリティで保護されたチャンネルを確立でき、それらのサービスメタデータを共有でき、接続済みデバイステーブル４３０５に項目を追加することができる（３）。コントローラー４３０４は、任意のサービスマッチについて、サービス登録テーブル４３０６及びサービスリクエストテーブル４３０７を調べることができる（４及び４’）。サービスが見つかった場合、エバリュエーター機能４３０８を呼び出すことができる（５）。サービススコアが閾値を超える場合、サービス情報を、通信コンポーネント４３０９に渡すことができる（６）。ポリシーエンジン４３０２は、単方向イベントチャンネルを用いて、新規サービスに関してアプリケーション４３１０に通知することができる（７）。
【０１３８】
開示されている主題の一態様によると、アプリケーションが、あるサービスをローカルで又はグローバルで使用しようとした場合、アプリケーションはサービスロケーションを知らないため、ｑｕｅｒｙ（）ＡＰＩを用いることができる。アプリケーションがｑｕｅｒｙ（）ＡＰＩを呼び出した場合、リクエストを、リクエストの種類、即ちブロック化又は非ブロック化、に基づいて、サービスリクエスト（Ｓｅｒｖｉｃｅ  Ｒｅｑｕｅｓｔ、ＳＲｅｑ）テーブルに記憶することができる。ブロック化リクエストにおいて、アプリケーションは、即座のサービス解決を見込むことができる。非ブロック化リクエストにおいて、アプリケーションは即座の応答を見込まない。アプリケーションは、リクエストされたサービスがネットワーク内で利用可能である場合は、単方向イベントチャンネルを介してこのサービスに関して通知を受けることができる。アプリケーションは、それ自身のＵＲＩを用いてネットワーク内をそれ自身に関して照会することができる。
【０１３９】
サービスリクエストの機能フローを説明するために、例としてアプリケーションは、ローカルネットワーク内のビデオシステムサービスに対してリクエストをすることができる。サービスに対するＪＳＯＮオブジェクトは以下の通りであり得る。
0006363999.tif 000003
【０１４０】
図４４は、非ブロック化サービスクエリーフローを示すが、これは限定をするのではなく説明を目的とするものである。アプリケーション４４０１は、サービスリクエストに対するｓｏｃｋｅｔ．ｑｕｅｒｙ（ＪＳＯＮ）４４０２ＡＰＩを呼び出すことができる（１）。ポリシーエンジン４４０３は、ＳＳＭ４４０４に対して、対応するアプリケーションに関するサービスクエリーリクエストを行うことができる（２）。ＳＳＭの通信モジュール４４０５は、リクエストをコントローラー４４０６に渡すことができる（３）。コントローラー４４０６は、ＳＲｅｇテーブル４４０７サービス項目、即ち、サービス項目発見（Ｓｅｒｖｉｃｅ  Ｅｎｔｒｙ  Ｆｏｕｎｄ）及びサービス項目無（Ｎｏ  Ｓｅｒｖｉｃｅ  Ｅｎｔｒｙ）、を調べることができる（４及び４’）。サービス項目発見（Ｓｅｒｖｉｃｅ  Ｅｎｔｒｙ  Ｆｏｕｎｄ）において、サービスエバリュエーター４４０８を呼び出すことができる。サービススコアが閾値を超える場合、アプリケーションに、ＳＲＴテーブル行番号とともにサービス（例えば、サービスＩＤ、サービスタイプ、ＩＰアドレス）を通知することができる。サービス項目無において（Ｎｏ  Ｓｅｒｖｉｃｅ  Ｅｎｔｒｙ）、クエリータイプが非ブロック化である場合、コントローラー４４０６は、サービスリクエストテーブル４４０９に項目を追加することができる（４’）。この場合、コントローラーは、ネットワーク内で発見される新しいデバイスを待機することができる。クエリーがブロック化である場合、コントローラー４４０６は、ゼロを返すことができる。コントローラー４４０６は、デバイスの詳細とともにリクエストテーブル項目行番号を、又は失敗の場合、ゼロを応答として通信モジュール４４０５に返すことができる（５）。行番号は、ポリシーエンジン４４０３に送ることができる（６）。ＰＥは、デバイスの詳細とともに行番号をアプリケーション４４０１に返すことができる（７）。
【０１４１】
ブロック化サービスクエリーにおいて、サービス検索結果は、即座にアプリケーションに返すことができる。サービスがサービス登録テーブル内で見つかった場合、サービスの詳細をアプリケーションに返すことができる。サービスクエリーコンテキストがグローバルである場合、クエリーを次のサービスルーターに渡すことができる（後により詳細に説明する）。サービスに対するＪＳＯＮオブジェクトは以下のようであり得る。
0006363999.tif 000004
【０１４２】
開示されている主題の一態様によると、図４５に限定をするのではなく説明を目的として示すように、制御パスとデータパスとを明確に分離するために、サービス共有テーブルはコントローラーと分離することができる。この分離は、より高い性能のためのサービステーブルのカーネル空間実装を可能とし得る。他のＳＳＭコンポーネントはユーザー空間に存在でき、ユーザー空間からカーネル空間への通信ＡＰＩを用いてサービステーブルを制御することができる。更に、ルーティング及びＭＡＣテーブルと同様に、サービステーブルもハードウェア内に実装可能となる。
【０１４３】
開示されている主題の一態様によると、デバイスは既存のフローから削除することができる。デバイスクラッシュ又はスイッチオフの場合、ＳＳＭは、ローカルサービスのサービス利用不能又はサービスリクエストタイムアウトを全ての接続済みデバイスに通知できる。アプリケーションクラッシュの場合、ＳＳＭは、この特定のサービスのサービス利用不能を全ての接続済みデバイスに通知でき、登録項目を削除することができる。
【０１４４】
開示されている主題の一態様によると、制御ミドルウェアはデバイスには依存しないため、ルーターにインストールできる（即ち、制御ミドルウェアネットワーク構成）。このネットワーク構成において、デバイス発見は中央で行うことができ、各デバイスは、ルーターの制御ミドルウェアと通信することができ、これによりＵＥのバッテリーパワーを節約する。図４６は、発見エージェントホームルーター構成を示すが、これは限定をするのではなく説明を目的とするものである。ホームルーター発見エージェントは、集中発見エージェントとして機能でき、全ＵＥは、サービス発見のためにホームルーターと接続することができる。ホームルーターは、ローカルネットワーク全体のためのグローバルサービス登録テーブルを保持することができる。ＳＳＭコントローラーは、ＳＲＴ変更をホームルーターにのみプッシュすることができる。ＵＥは、ホームルーターＳＲＴを参照することのみによってサービスリクエストクエリーを完成することができる。
【０１４５】
開示されている主題の一態様によると、アプリケーションはネットワーク内の新しいサービスの可用性について通知を受けるので、アプリケーションは、現行のサービスセッションをローカルデバイスから新しく見つかったデバイスへと移行させる決定を下すことができる。フローをあるデバイスから他のデバイスへと移行するには２種の方法：ソース−シンクモデル、ソース−行先モデル、があり得る。ソース−シンクモデルにおいて、デバイス１（即ちソース）は、ビデオパケットをデバイス２（即ちシンク）に転送することができる。この場合、デバイス１はデータパケットのソースとして機能し、デバイス２はデータパケットのシンクとして機能する。換言すれば、データは、第２デバイスに送られるが、制御は第１デバイスに残ったままである。ソース−行先モデルにおいて、デバイス１（即ちソース）は、フロー全体のデバイス１からデバイス２（即ち行先）への完全な移行を開始できる。この場合、セッション共有アプリケーションは、フロー移行に対応している必要があり、これは、あるデバイスから他のデバイスへとアプリケーションコンテキストを移動する機能である。この機能に対応するために、ネットワーク制御機能のフロー識別子（ＮＣＦは、上位層、即ちトランスポート層、に不変識別子を提供する。この識別子はフローの存在期間中には不変である）は通信デバイス間で共有でき、また、ＳＳＭは、アプリケーションに基づき、セッション状態をあるデバイスから他のデバイスに移すことができる。
【０１４６】
移行ＡＰＩは、フロー移行を提供するために、両モデルに対して用いることができる。ソース−行先モデルに関して、アプリケーションセッション状態は、移行ＡＰＩを呼び出す前に同期させる必要がある。
【０１４７】
事前移行ステップにおいて、行先アプリケーション（デバイス２上）は、ソケットを作成でき、ファイル記述子をソースアプリケーション（デバイス１上）に返すことができる。必要に応じて、アプリケーションは、セッションデータを共有でき、これはセッションクッキー、資格情報、及びアプリケーション状態属性を含む。図４７は、デバイス１（即ちソース）上のアプリケーション１からデバイス２（即ち行先）上のアプリケーション２へのアプリケーションセッション状態の転送を示すが、これは限定をするのではなく説明を目的とするものである。各アプリケーションが状態を共有した後、移行先はリモートソケットファイル記述子を返すことができ、これは移行後の新しいフローエンドポイントとして使用することができる。
【０１４８】
一旦アプリケーションセッション状態が転送されると、アプリケーション１は、ｓｅｒｖｉｃｅ＿ｉｄ、移行のタイプ、及びオプションのｒｅｍｏｔｅ＿ｓｏｃｋｅｔ＿ｆｄパラメーター（例えば、どのサービス、リモートデバイスのどこで、及びどのように）を用いて移行ＡＰＩを呼び出すことができる。オプションのｒｅｍｏｔｅ＿ｓｏｃｋｅｔ＿ｆｄが渡されなかった場合、リモートフロー移行モジュールは、ｒｅｍｏｔｅ＿ｓｏｃｋｅｔ＿ｆｄを一つ動的に作成できる。ソース及びシンクに関して、パケットをＳＳＭフロー移行モジュールに配信することができ、ＳＳＭフロー移行モジュールはパケットをリモートデバイスサービスに転送する。このサービスに対するＪＳＯＮオブジェクトは以下の通りであり得る。
0006363999.tif 000005
【０１４９】
図４８はフロー移行動作ポイントを示すが、これは限定をするのではなく説明を目的とするものである。アプリケーション１は、ｓｏｃｋｅｔ．ｍｉｇｒａｔｅ（ＪＳＯＮ）ＡＰＩを呼び出し、呼び出しソケットのためにフロー移行を開始することができる。ポリシーエンジンは、フローの詳細を用いてＳＳＭに対してフロー移行をリクエストできる。リクエストはコントローラーに渡すことができる。コントローラーは、サービス移行リクエストを調べ、ＳＲｅｇテーブル項目から必要なデバイスの詳細を取得することができる。コントローラーは、フロー移行を開始することができる。デバイスを接続することができ、フローの状態を２個のデバイス間で同期することができる。コントローラーは、ポリシーエンジンに、移行結果、即ち成功又は失敗、を通知することができる。ポリシーエンジンには、移行結果を通知することができる。ポリシーエンジンは、アプリケーションに移行結果を通知することができる。
【０１５０】
図６８は、サービス共有マネージャーの動作の例示的フローチャートであるが、これは限定をするのではなく説明を目的とするものである。制御ミドルウェアは、サービス共有マネージャー（ｓｅｒｖｉｃｅ−ｓｈａｒｉｎｇ  ｍａｎａｇｅｒ、ＳＳＭ）を初期化することができる  ６８−０１。ＳＳＭコントローラーは、新しいイベントを待機することができる  ６８−０２。新しいイベントが生じると、そのイベントを評価することができる  ６８−０３。ローカルデータストアが設定されている場合、コントローラーは、イベントデータを保存することができる  ６８−０４。コントローラーは、イベントタイプ、例えば新しいサービス  ６８−０５、新しいデバイス  ６８−０６、サービスクエリー  ６８−０７、フロー移行  ６８−０８及びサービスルーティング制御  ６８−０９等、を処理することができる。新しいサービスイベントを処理する場合、コントローラーは、登録テーブル項目が存在しない場合、この項目を作成でき、接続デバイステーブル項目に基づいて全ての接続済みデバイスに通知することができる  ６８−１０。新しいデバイスイベントを処理する場合、コントローラーは、イベントデータ内のルーター設定を調べることができる  ６８−１１。新しいデバイスがルーターとして設定されている場合、接続済みデバイステーブルをフラッシュすることができ、登録テーブルを更新することができる  ６８−１２。新しいデバイス（ルーター）の詳細は、接続済みデバイステーブルに加えることができる。新しいデバイスがルーターではない場合、デバイスの詳細は、接続済みデバイステーブルに加えることができ、登録テーブル項目を更新することができる  ６８−１３。コントローラーは、任意のサービスマッチに対してリクエストテーブル項目を調べることができ  ６８−１４、見つかった場合、サービスを評価することができる  ６８−１７。サービススコアが設定閾値スコアを超える場合、ポリシーエンジンに通知することができ、次いで各アプリケーションに通知することができる。サービスクエリーイベントを処理する場合  ６８−０７、コントローラーは登録テーブルを調べることができる。サービスが見つかった場合、サービスを評価することができ、閾値に達している場合、情報をポリシーエンジンに送信することができる  ６８−１７。サービスが見つからなく、クエリーが非ブロック化である場合、クエリーリクエストを、将来の実行のためにリクエストテーブルに追加することができる  ６８−１６。クエリーがブロック化である場合、コントローラーはクエリーを次の接続済みルーターに転送でき、応答を待機することができる。応答が見つかると、ポリシーエンジンには、サービス情報を通知することができる。
【０１５１】
開示されている主題の他の態様によると、コンテキストアウェア制御ミドルウェア（Ｃｏｎｔｅｘｔ  ａｗａｒｅ  Ｃｏｎｔｒｏｌ  Ｍｉｄｄｌｅｗａｒｅ、ＣＣＭ）はデバイスには依存しないため、計算及びストレージ能力を有するサーバーやルーター等のネットワークエレメント上にインストールできる。ネットワークエレメント（例えばルーター）がネットワークインフラストラクチャ内に配置される場合、これらはネットワークベース動的計算プラットフォームを作りだすことができる。各動的サービス対応ルーター（例えばサービスルーター）は、制御ミドルウェアのサービス共有マネージャー（ｓｅｒｖｉｃｅ−ｓｈａｒｉｎｇ  ｍａｎａｇｅｒ、ＳＳＭ）を用いて、ピア・トゥ・ピア又は集中方式で、互いに情報を発見、共有及び交換することができる。サービスルーター（Ｓｅｒｖｉｃｅ  Ｒｏｕｔｅｒ、ＳＲ）は、ネットワークの基本抽象的概念としてサービスを提供できる。
【０１５２】
開示されている主題の一態様によると、パケットルーティングネットワークにおいて、ルーターは、ルーティングテーブルに基づいてパケットを転送することができる。サービスルーティングを用いると、ＳＳＭコントローラーは、サービスクエリーリクエストを受信した場合、サービステーブル（例えばＳＳＭ−ＳＲｅｇテーブル）の検索及び制御によるサービスルーティングを実行することができる。図４９は、サービス及びパケットルーティングプレーンとこれらを制御する対応したテーブルを示すが、これは限定をするのではなく説明を目的とするものである。コントローラーがサービスマッチを見つけた場合、サービスクエリー応答を返すことができる。サービスマッチが見つからない場合、ＳＲｅｇテーブル項目に基づいてサービスクエリーリクエストを転送することができる。サービスルーティング及びパケットルーティングは、それぞれ独立であることができる。
【０１５３】
開示されている主題の一態様によると、サービスルーティングは、アプリケーションが独立してサービステーブルを更新できるようにすることにより、分散負荷バランスをネイティブに提供する。アプリケーションサービスが多数のリクエストを受けている場合、サービスはネットワーク内で冗長性を有すると仮定すると、サービステーブルのＡＣＴＩＯＮ属性を、ＤＥＬＩＶＥＲからＦＯＲＷＡＲＤへと変更することができる。アプリケーションは、ソケット上のサービスＡＰＩコールを用いサービスを定義することができる、また任意のサービス変更を実行することができる。サービス動作状態を変更するために、サービスコールは，ｓｅｒｖｉｃｅ＿ｉｄ及び新しいａｃｔｉｏｎ＿ｓｔａｔｅを含むＪＳＯＮ引数を取得することができる。ポリシーエンジンは、リクエストをＳＳＭに渡すことができ、これによりサービス状態を変更できる。アプリケーションがサービスを監視したくない場合、ポリシーエンジンは、アプリケーションのシステムリソース使用度（ＣＰＵ、メモリー、帯域幅使用度等）に基づいて、ＳＲｅｇ項目を動的に更新することができる。このサービスに対するＪＳＯＮオブジェクトは以下であり得る。
0006363999.tif 000006
【０１５４】
開示されている主題の一態様によると、制御ミドルウェアがデータセンターサーバーにインストールされている場合、アプリケーションサービスプロバイダー（ａｐｐｌｉｃａｔｉｏｎ  ｓｅｒｖｉｃｅ  ｐｒｏｖｉｄｅｒ、ＡＳＰ）は、サービスをホストすることができ、何ら特別なハードウェアを用いること無く、負荷を動的にバランスをとることができる。図５０は、ＡＳＰのインフラストラクチャ内にインストールされた動的サービスルーティングクラスターを示すが、これは限定をするのではなく説明を目的とするものである。クラスターは、マスター−スレーブ又は階層等の異なったトポロジーを用いてスケールされるように構成できる。クライアント、例えばモバイル、ラップトップやデスクトップクライアントは、ブロック化クエリーＡＰＩを用いてこのサービスルーティング環境を利用することができる。ブロック化クエリーは、サービス解決結果を即座に返すことができる。非ブロック化クエリーの場合、サービス解決は任意で即座に起こり得るが、アプリケーションは、サービス可用性をリッスンすることができる。クライアントアプリケーションは、例えば以下のＪＳＯＮクエリーリクエストによってｓｏｃｋｅｔ．ｑｕｅｒｙ（）ＡＰＩを呼び出すことができる。
0006363999.tif 000007
【０１５５】
ｓｅｒｖｉｃｅ＿ｉｄ属性は、どのサービスをクライアントアプリケーションが接続したいのかを定義することができる。ｓｅｒｖｉｃｅ＿ｎｏｄｅは、クライアントがサービスにその存在を見込む行先ノードであることができ、実際のサービスはこのノード上で随意にホストすることができる。例えば、コロンビアドキュメントサービス、即ちｗｗｗ．ｄｏｃｓ．ｃｏｌｕｍｂｉａ．ｅｄｕ、は、異なるデータセンターでホストされることができるが、クライアントアプリケーションはそのことを意識することはない。ｈｏｐ＿ｃｏｕｎｔ属性は、クエリーリクエストがトラバースすることができる最大のサービスノードを定義することができる。ａｕｔｏ＿ｃｏｎｎｅｃｔ属性は、制御ミドルウェアに指示をして、ｓｏｃｋｅｔ．ｃｏｎｎｅｃｔ（）機能を呼び出すことなしに、解決済みのサービスロケーションに自動的に接続することができる。
【０１５６】
開示されている主題の一態様によると、ネットワーク待機時間、アプリケーション信頼性及び可用性を改善するために、ＡＳＰはサービスをネットワークインフラストラクチャ内に配置することができる。この場合、サービスルーターは、パケットルーティング及びサービスルーティングの両者の上で動作することができる。図５１は、パケットルーティングの上位のサービスルーティングを示すが、これは限定をするのではなく説明を目的とするものである。各サービスルーターは、ピア・トゥ・ピアで又は集中型サービスコントローラーを用いて互いを発見することができる。
【０１５７】
ＵＥに関して、最近接サービスルーターは、ネットワークベース集中型サービスによって又はＳＳＭ設定に基づいた制御プローブメッセージを用いて日和見的に、ＳＳＭ内に設定することができる。クライアントアプリケーションは、サービス解決のためにクエリーＡＰＩコールを発行でき、これによりサービス配置ロケーションは独立したものとなる。図５２に限定をするのではなく説明を目的として示すように、サービスがネットワーク内でホストされていない場合、サービスクエリーリクエストは、最初にサービスルーター内で処理され、次いで指定のサービスノードに送ることができる。このネットワーク内サービスプラットフォームは、動的サービス対応ネットワークを作成することができる。
【０１５８】
開示されている主題の一態様によると、各ＡＳＰサービスは、ｓｅｒｖｉｃｅ（）ＡＰＩを用いてサービステーブルに登録され、独立して管理される。各サービスは、１以上の一意識別子（例えばサービスＩＤ及びＵＲＩ）を登録することができる。ＩＰテーブルと同様に、サービステーブルもグローバルであり得る。複数のＡＳＰからのサービスｉｄ間の競合を解消するために、各ＡＳＰの一意的ＩＤを、サービスｉｄを有するプレフィックス、例えばＨＩＴ：：サービス−ＩＤ、として用いることができる。登録済みサービスは、ＳＲＴテーブル内に既定動作ＤＥＬＩＶＥＲを有することができる。ＳＲＴテーブル内のサービスＩＤ及びＵＲＩは、ワイルドカードを用いることができる。例えば、２５６ビットサービスＩＤ、２００１：：０２：：＊、は、２００１：：０２から始まる１２８ビットアイデンティティを有するＡＳＰ用の全サービスリクエストを入手することができる。ワイルドカードは、ＵＲＩ上でも用いることができる。例えば、ＵＲＩ  ｗｗｗ．ｄｏｃｓ．ｃｏｌｕｍｂｉａ．ｅｄｕ／＊がサービステーブルに記憶されている場合、コロンビアドキュメントサービスに関する全サービスリクエストが入手される。
【０１５９】
一旦サービスがサービスルーターに登録されると、サービス発見エージェントは、ネットワーク内にサービスを公開できる。例えば集中型、クラスターベース、フラッディングをはじめとする実装に基づき又は分散ハッシュテーブル法を用いて、種々の方法によってサービスを公開できる。サービスの発見後、サービステーブル項目には、そのサービスに応じて、ＤＥＬＩＶＥＲ、ＦＯＲＷＡＲＤ、ＤＲＯＰ、及びＤＥＬＡＹ動作を記載することができる。ルーター上でサービスが実行されていない場合、既定項目［＊｜ＦＯＲＷＡＲＤ｜次のサービスルーターロケーションアドレス］を実行することができる。
【０１６０】
開示されている主題の一態様によると、ＵＥは、ネットワークインフラストラクチャ内の、例えばサービスゲートウェイ（ｓｅｒｖｉｃｅ  ｇａｔｅｗａｙ、ＳＧ）（各ＵＥに接続された第１サービスルーターはサービスネットワーク全体に対するゲートウェイとして機能するためサービスゲートウェイと呼ばれ、機能サービスゲートウェイは他のサービスルーターと同一である）等の最近接サービスルーターと接続される。クライアントは、クエリーＡＰＩを用いてサービスをリクエストでき、ローカルＳＳＭコントローラーはリクエストを接続済みＳＧに渡すことができる。サービスルーター上のＳＳＭコントローラーは、サービステーブル項目内でサービスクエリー、例えばサービスｉｄ／ＵＲＩ、を調べることができる。ＤＥＬＩＶＥＲ動作を有する項目が見つかった場合、サービス応答を、解決済みサービスのロケーションアドレス及びポート番号とともに送ることができる。ＦＯＲＷＡＲＤ動作が見つかった場合、リクエストを、次の設定済みサービスルーターのＩＰアドレスに転送することができる。マッチした項目が見つからない場合、リクエストは既定項目［＊｜ＦＯＲＷＡＲＤ｜次のサービスルーターロケーション］を介して転送される。
【０１６１】
図５３に限定をするのではなく説明を目的として示すように、ＵＥは、サービスゲートウェイ「Ａ」に接続することができる。ＵＥは、ｉｄ＝４（即ちクエリー１）を用いてサービスを照会することができる。リクエストはＡに到達し、サービステーブル項目を調べた後に、リクエストをサービスルーターＣに転送することができる。ルーターＣにおけるＳＳＭコントローラーはサービスを見つけ、サービス情報をＵＥに返すことができる。第２のサービスクエリーに関し、リクエストはサービスルーターＡに到達し、次いでネットワーク内での正常なサービス解決無しに、サービスルーターＤに到達する。サービスルーターＤは、リクエストをサービスリクエストクエリーのｓｅｒｖｉｃｅ＿ｎｏｄｅ属性値に渡すことができる。サービスリクエストクエリーは、ＡＳＰアプリケーションによって作成されるため、ロケーションベース及び／又は高帯域幅サービスに照会することができる。例えば、ネットフリックス（Ｎｅｔｆｌｉｘ）は、高帯域幅サービスをベライゾン（Ｖｅｒｉｚｏｎ）のニューヨークネットワーク内に供給でき、サービスリクエストクエリーコールは、ｌｏｃａｔｉｏｎ＝ＮＹＣ及びｂａｎｄｗｉｄｔｈ＝５Ｍｂｐｓを追加パラメーターとして加えることができる。
【０１６２】
開示されている主題の一態様によると、ＵＥが一つのロケーションから他のロケーションへと動いている時、ＳＧもＵＥのロケーションに基づいて、動的に設定することができる。図５４は、ＵＥがマンハッタンからブロンクスエリアに移動する際の動的なＳＧの設定を示すが、これは限定をするのではなく説明を目的とするものである。マンハッタンにおいて、ＭＮはＳＧ１に接続され、ＭＮがブロンクスエリアに移動した際には、ＳＧ２を動的に選択することができる。
【０１６３】
開示されている主題の一態様によると、クラウドコンピューティング環境において、異なるユーザーからのアプリケーション（例えばＡＳＰ、企業、又は政府）は、仮想マシン（ｖｉｒｔｕａｌ  ｍａｃｈｉｎｅ、ＶＭ）抽象的概念によって、互いに分離されセキュリティで保護される。ネットワーク構成内に設定された制御ミドルウェアを有するハイパーバイザー（即ち一つのコンピューターソフトウェア、ファームウェア又はＶＭを実行するのに用いるハードウェア）は、データセンターサーバー又はサービスルーター上にインストールすることができ、動的サービス−計算プラットフォームが作成される。
【０１６４】
このネットワーク構成において、ハイパーバイザー内の制御ミドルウェアは、ローカルで実行されている全てのＶＭに対する集中サービス発見マネージャーとして機能することができる。各ハイパーバイザー自身は、独立のピアとして機能し、他のピアと通信する。図５５は、ハイパーバイザー対応サービスルーターを用い、ネットワーク内に配置されたサービスクラウドを示すが、これは限定をするのではなく説明を目的とするものである。ＯｐｅｎＳｔａｃｋ（即ちｈｔｔｐ：／／ｗｗｗ．ｏｐｅｎｓｔａｃｋ．ｏｒｇ／）又はＯｐｅｎＮｅｂｕｌａ（即ちｈｔｔｐ：／／ｏｐｅｎｎｅｂｕｌａ．ｏｒｇ／）等のクラウドプラットフォームは、サービスルーター上に配置されたＶＭを管理することができる。例えば、ｗｗｗ．ｇｏｏｇｌｅ．ｃｏｍは、ローカルユーザートラフィック使用度に基づいて、ネットワーク内に仮想マシンを供給することができる。Ｇｏｏｇｌｅアプリケーションは、そのサービスを制御ミドルウェア及びＶＭ制御ミドルウェアに登録でき、更にはローカルハイパーバイザーのサービステーブルを更新することができる。
【０１６５】
同様に、種々のプログラミング言語（例えばＪａｖａ、Ｒｕｂｙ、Ｐｙｔｈｏｎ、ＰＨＰ等）用の汎用プラットフォームを、これらのサービスルーター上に配置しプラットフォーム・アズ・ア・サービス（ｐｌａｔｆｏｒｍ−ａｓ−ａ−ｓｅｒｖｉｃｅ、ＰａａＳ）クラウドを形成できる。例えばＦａｃｅｂｏｏｋ、Ｔｗｉｔｔｅｒ、Ｇｏｏｇｌｅ等のインターネットアプリケーションサービスプロバイダーは、サービスをユーザーの近くに配置できるため、このプラットフォームを活用して待機時間及び負荷バランスを改善でき、また元のサーバーの負荷を低減することもできる。例えば、図５６に限定をするのではなく説明を目的として示すように、Ｔｗｉｔｔｅｒ．ｃｏｍ等のインターネットアプリケーションプロバイダー（即ちＪＡＶＡプラットフォーム）が、ニューヨーク地域からの重いトラフィックのためサービス停止となっている場合、そのサービス（ＶＮ全部の代わりに）をネットワークプロバイダーのＮＹＣ地域内のネットワーク内に直接配置しサービス負荷を低減することができる。この例においては、ＮＹ地域からのＴｗｉｔｔｅｒ．ｃｏｍのトラフィックの全てをネットワーク自身内で処理する。
【０１６６】
図５７に限定をするのではなく説明を目的として示すように、ローカルネットワーク、データセンター内及び（上述のような）ネットワークインフラストラクチャ内部へサービスを配置することは、特に、ローカルネットワークがデータセンターに向けて動くにつれてネットワーク待機時間が徐々に増加するという状況のもと有利となり得る。例えば、スマートフォン、タブレット及びラップトップ等の新しいモバイルデバイス及びモバイルブロードバンドアクセスを用いると、ユーザーは、より多くのモバイルコンテンツを消費する。ユーザーのロケーション又はデバイス環境に基づいてサービスにシームレスにアクセスするための、またこれらのロケーションにおいてサービスをシームレスに管理するためのインテリジェンスによって、付加価値、リソース節約及び新しいビジネスモデルを加えることができる。
【０１６７】
現在のネットワーキングインフラストラクチャは、パケット転送機能のみを提供している。計算及びストレージコストの低下にともない、また開示されている主題によると、ネットワーキングインフラストラクチャは、上述のように、サービスルーターを用いて計算プラットフォームを提供することができる。これらのサービスルーターは、将来的によりよいサービスを提供するために、ユーザーネットワークアクセスログを計算し記憶することができる。ネットワークインフラストラクチャ内に計算及びストレージ機能があると、「メモリー付ネットワーク」システムを作成でき、これは過去のネットワークアクセスデータからネットワーク内でのＵＥの行動を記憶している。メモリー付ネットワークを有すると、サービス不能（Ｄｅｎｉａｌ−ｏｆ−Ｓｅｒｖｉｃｅ、ＤｏＳ）攻撃の停止、セキュリティイベントを理解するためのフォレンジクス、ネットワーク内でのＵＥの詳細な行動の提供、及びトラフィック分類法に基づいたより良いユーザーネットワークサービスの提供に役立たせることができる。
【０１６８】
開示されている主題の一態様によると、ネットワークアクセス履歴（Ｎｅｔｗｏｒｋ  Ａｃｃｅｓｓ  Ｈｉｓｔｏｒｙ、ＮＡＨ）システムは、ＩＳＰに対するネットワークアクセス履歴を管理する。このサービスは、ネットワークサービスルーターの上位に分散させることができる。データは、サービスルーター上で実行されるサービス共有マネージャー（Ｓｅｒｖｉｃｅ  Ｓｈａｒｉｎｇ  Ｍａｎａｇｅｒ、ＳＳＭ）ＡＰＩを用いて、ＮＡＨサービスによって集計することができる。大きいデータセットは、ユーザー、アプリケーション、及びサービス使用度トラフィックに関連するネットワーク内に提供することができる。データセットは、個人情報保護アルゴリズムを用いて記憶でき、匿名性をユーザー及びアプリケーションサービスプロバイダーに提供することができる。ＮＡＨサービスによって生成されたデータセットは、ネットワークサービスクラウドの計算能力を用いて、データマイニング（例えば、異常、傾向、パターン及び相関の検出）のために使用することができる。例えば、あるユーザーの使用パターンを追跡、解析し（地理データを上述のように用いネットワークの使用を最適化するように）、ユーザーに事前にサービス、例えば、ホットスポットの検出及びアプリケーションの実行の抑制によるバッテリーパワーの節約、を提供することができる。サービス使用度を、よりよいサービスを提供するために予測することができる。
【０１６９】
図５８はＮＡＨサービスを示すが、これは限定をするのではなく説明を目的とするものである。ＮＡＨマネージャーは、分散されたＮＡＨエージェントを管理でき、これらはアクセスログをローカルに記憶する。例えば、ＵＥ１、２及び３は、ネットワークからローカルにサービスにアクセスし、ＵＥ４はデータセンターからサービスにアクセスすることができる。
【０１７０】
開示されている主題の一態様によると、アクセスログを記憶して、ＵＥに関する有益な情報のログをマイニングすることによって、上述のＵＥ用の知識プレーンに類似した知識プレーンがネットワークインフラストラクチャ内に作成される。図５９は、制御及びデータプレーンの上の知識プレーンを示すが、これは限定をするのではなく説明を目的とするものである。知識プレーンのマイニング及び／又は学習アルゴリズムは、ネットワークアクセスログを処理でき、結果は知識ベースに記憶することができる。知識ベースは、ネットワークがそれ自身のメモリーを持つことを可能とする。ＵＥからの将来のネットワークアクセスリクエストに関して、知識ベースを参照することによりアクセスを許可又は拒否でき、各フローに対するＱｏＳを設定することができる。
【０１７１】
開示されている主題の一態様によると、ＮＡＨマネージャーは、サービスルーターの上に分散マップリデュース（ｍａｐ−ｒｅｄｕｃｅ）サービスを配置しデータマイニングを実行する。マップリデュースとは、大きいデータセットを処理するためのプログラミングモデルである。「マップ」ステップにおいて、マスターノードは入力を受け入れることができ、それを小さなサブプロブレムに分割でき、それらをワーカーノードに配布することができる。次いでワーカーノードは、この手順を再び行うことができ、マルチレベルツリー構造となる。ワーカーノードは、この小さいプロブレムを処理でき、答えをマスターノードに渡すことができる。「リデュース」ステップにおいて、マスターノードは、全サブプロブレムの答を回収し、これらを何らかの方法で組み合わせて出力、即ち最初に解こうとしていた問題の答、を形成する。
【０１７２】
図６０は、分散マップ・リデュースフレームワークを示すが、これは限定をするのではなく説明を目的とするものである。ＮＡＨマネージャーは、マスターとして機能でき、リデュースステップを実行することができ、サービスルーター上の分散プロセスは、処理マップステップを実行することができる。
【０１７３】
上述の事項は、単に開示されている主題の原理を示すものである。説明した実施形態に対する種々の変更及び改変は、本明細書の教示を考慮して当業者には明らかであろう。例えば、寸法、電磁特性、温度、及び時間をはじめとする種々の値及び範囲は、例示的実施形態の説明に提供されており、当業者は、これら値及び範囲を、特定の用途での使用において、開示されている主題の範囲内で変更できる。当業者は、本明細書では明確に述べてはいないが、原理を具現し、且つ開示されている主題の精神と範囲内にある多数の変更を考案することができるのは勿論である。
【図１】
0006363999.tif 000008
【図２】
0006363999.tif 000009
【図３】
0006363999.tif 000010
【図４】
0006363999.tif 000011
【図５】
0006363999.tif 000012
【図６】
0006363999.tif 000013
【図７】
0006363999.tif 000014
【図８】
0006363999.tif 000015
【図９】
0006363999.tif 000016
【図１０】
0006363999.tif 000017
【図１１】
0006363999.tif 000018
【図１２】
0006363999.tif 000019
【図１３】
0006363999.tif 000020
【図１４】
0006363999.tif 000021
【図１５】
0006363999.tif 000022
【図１６】
0006363999.tif 000023
【図１７】
0006363999.tif 000024
【図１８】
0006363999.tif 000025
【図１９】
0006363999.tif 000026
【図２０】
0006363999.tif 000027
【図２１】
0006363999.tif 000028
【図２２】
0006363999.tif 000029
【図２３】
0006363999.tif 000030
【図２４】
0006363999.tif 000031
【図２５】
0006363999.tif 000032
【図２６】
0006363999.tif 000033
【図２７】
0006363999.tif 000034
【図２８】
0006363999.tif 000035
【図２９】
0006363999.tif 000036
【図３０】
0006363999.tif 000037
【図３１】
0006363999.tif 000038
【図３２】
0006363999.tif 000039
【図３３】
0006363999.tif 000040
【図３４】
0006363999.tif 000041
【図３５】
0006363999.tif 000042
【図３６】
0006363999.tif 000043
【図３７】
0006363999.tif 000044
【図３８】
0006363999.tif 000045
【図３９】
0006363999.tif 000046
【図４０】
0006363999.tif 000047
【図４１】
0006363999.tif 000048
【図４２】
0006363999.tif 000049
【図４３】
0006363999.tif 000050
【図４４】
0006363999.tif 000051
【図４５】
0006363999.tif 000052
【図４６】
0006363999.tif 000053
【図４７】
0006363999.tif 000054
【図４８】
0006363999.tif 000055
【図４９】
0006363999.tif 000056
【図５０】
0006363999.tif 000057
【図５１】
0006363999.tif 000058
【図５２】
0006363999.tif 000059
【図５３】
0006363999.tif 000060
【図５４】
0006363999.tif 000061
【図５５】
0006363999.tif 000062
【図５６】
0006363999.tif 000063
【図５７】
0006363999.tif 000064
【図５８】
0006363999.tif 000065
【図５９】
0006363999.tif 000066
【図６０】
0006363999.tif 000067
【図６１】
0006363999.tif 000068
【図６２】
0006363999.tif 000069
【図６３−１】
0006363999.tif 000070
【図６３−２】
0006363999.tif 000071
【図６４】
0006363999.tif 000072
【図６５】
0006363999.tif 000073
【図６６】
0006363999.tif 000074
【図６７−１】
0006363999.tif 000075
【図６７−２】
0006363999.tif 000076
【図６８−１】
0006363999.tif 000077
【図６８−２】
0006363999.tif 000078