(57)【特許請求の範囲】
【請求項１】
複数の通信手段と、
アプリケーションとユーザとのインタラクションの有無および前記アプリケーションが要求する通信特性を保持する第１のデータベースと、
前記複数の通信手段の実際の通信特性を監視する端末コンテキストモニタ部と、
前記インタラクションの有無、前記アプリケーションが要求する通信特性、および、前記実際の通信特性に応じて、前記アプリケーションに割り当てる通信手段を前記複数の通信手段の中から選択するユーザ体感評価部と、を備える通信端末。
【請求項２】
前記端末コンテキストモニタ部は、前記実際の通信特性として、前記複数の通信手段による通信の遅延時間、通信帯域、接続の安定性、および、通信料金のうちの少なくともいずれかを監視する、
請求項１に記載の通信端末。
【請求項３】
前記ユーザ体感評価部は、複数のアプリケーションのうちのユーザとのインタラクションが有るアプリケーションに対して通信手段を優先的に割り当てる、
請求項１又は２に記載の通信端末。
【請求項４】
ユーザが通信の遅延時間、通信帯域、接続の安定性、および、通信料金のうちのいずれを重視するかを表す情報を保持する第２のデータベースを備え、
前記ユーザ体感評価部は、前記インタラクションの有無、前記アプリケーションが要求する通信特性、および、前記実際の通信特性、ならびに、前記第２のデータベースが保持する情報に応じて、前記アプリケーションに割り当てる通信手段を前記複数の通信手段の中から選択する、
請求項１ないし３のいずれか１項に記載の通信端末。
【請求項５】
複数の通信手段を備えた通信端末が、アプリケーションとユーザとのインタラクションの有無および前記アプリケーションが要求する通信特性を保持する第１のデータベースを参照するステップと、
前記複数の通信手段の実際の通信特性を監視するステップと、
前記インタラクションの有無、前記アプリケーションが要求する通信特性、および、前記実際の通信特性に応じて、前記アプリケーションに割り当てる通信手段を前記複数の通信手段の中から選択するステップと、を含む、
ことを特徴とする通信方法。
【請求項６】
複数の通信手段を備えた通信端末に設けられたコンピュータに、アプリケーションとユーザとのインタラクションの有無および前記アプリケーションが要求する通信特性を保持する第１のデータベースを参照する処理と、
前記複数の通信手段の実際の通信特性を監視する処理と、
前記インタラクションの有無、前記アプリケーションが要求する通信特性、および、前記実際の通信特性に応じて、前記アプリケーションに割り当てる通信手段を前記複数の通信手段の中から選択する処理と、を実行させる、
ことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信端末、通信方法、および、プログラムに関し、特に、複数の通信手段（例えば、複数の無線アクセス方式）で通信可能な通信端末、通信方法、および、プログラムに関する。
【背景技術】
【０００２】
複数の無線アクセス方式（ＲＡＴ：Radio Access Technology）を利用可能なモバイル環境では、無線通信端末がＲＡＴを適宜切り替えることでアクセス環境に適した通信を行うことができる。
【０００３】
ここで、ＲＡＴとして、例えば、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１１ｇ、ＩＥＥＥ８０２．１１ｎを含むＷＬＡＮ（Wireless Local Area Network）方式、または、ＵＴＲＡＮ（UMTS (Universal Mobile Telecommunications System) Terrestrial Radio Access Network）、ＬＴＥ（Long Term Evolution）を含む３ＧＰＰ（Third Generation Partnership Project）アクセス方式などがある。
【０００４】
以下では、ＷＬＡＮ方式の通信を無線ＬＡＮ通信という。一方、３ＧＰＰアクセス方式の通信をセルラ通信という。
【０００５】
関連技術として、特許文献１には、ユーザが利用するアプリケーションに最適なＲＡＴを自動的に選択して切り替える無線通信端末が開示されている。当該文献に記載された無線通信端末は、アプリケーションの利用頻度を計測し、利用頻度が高いアプリケーションに適したＲＡＴを選択する。
【０００６】
また、出願人による先の出願（出願日：平成２５年６月２８日）には、アプリケーションの通信パターンを元に、アプリケーションの通信フロー単位で複数のＲＡＴに振り分け制御を行う無線通信端末が開示されている。当該文献に記載された無線通信端末は、アプリケーションの通信フロー単位の通信パターン（例えば、小容量高頻度な通信、大容量通信、ストリーミング通信などの通信形態）に応じて、通信フロー単位で最適なＲＡＴを選択する。
【０００７】
さらに、非特許文献１にはAndroid OSのソフトウェアプラットフォームが記載され、非特許文献２にはiOSのソフトウェアプラットフォームが記載されている。また、非特許文献３には、集中制御型のネットワークアーキテクチャであるオープンフロー（OpenFlow）という技術が記載されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特許第５５１４７４８号公報
【非特許文献】
【０００９】
【非特許文献１】Jason Chen (Google), "An Introduction to Android (presentation slide)," p. 16, 2008, <URL: https://sites.google.com/site/io/an-introduction-to-android>
【非特許文献２】Apple Inc.,「ｉＯＳテクノロジーの概要」p. 8, 2014.09.17, <URL: https://developer.apple.com/jp/devcenter/ios/library/documentation/iPhoneOSTechOverview.pdf>
【非特許文献３】Open Networking Foundation, "OpenFlow Switch Specification, Version 1.4.0 (Wire Protocol 0x05)," October 14, 2013, <URL:https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.4.0.pdf>
【発明の概要】
【発明が解決しようとする課題】
【００１０】
上記特許文献および非特許文献の全開示内容は、本書に引用をもって繰り込み記載されているものとする。以下の分析は、本発明者によるものである。
【００１１】
特許文献１に記載された無線通信端末は、利用頻度の高いアプリケーションに適したＲＡＴを選択するにすぎない。かかる無線通信端末によると、端末上で現在動作している複数のアプリケーションのそれぞれの通信を考慮したＲＡＴ選択が行われない、という問題がある。
【００１２】
一方、出願人による先の出願に記載された無線通信端末は、アプリケーションの通信パターンを元に、アプリケーションの通信フロー単位で複数のＲＡＴに振り分け制御を行う。かかる無線通信端末によると、端末上で現在動作している複数のアプリケーションのそれぞれの通信を、通信フロー単位で複数のＲＡＴに振り分けることができる。しかしながら、それぞれのアプリケーションの通信フローの振り分けに際して、通信パターンを元に振り分け制御が行われるにすぎない。すなわち、振り分けた結果がユーザ体感の向上にどのように寄与するかを考慮した上で、ＲＡＴ選択が行われるわけではない。
【００１３】
ここで、ユーザ体感には、アプリケーションが通信を行い、その結果を何らかの手段を通してユーザに応答として返す際の応答時間や、その際の通信に要する料金などが含まれる。この応答時間は、主に通信に要する時間である。すなわち、応答時間は、アプリケーションの通信経路であるＲＡＴの通信遅延時間と通信利用可能帯域に依存する。
【００１４】
一例として、２つのアプリケーションＡ、Ｂが無線通信端末上で同時に動作している場合を考える。ここで、アプリケーションＡは、ディスプレイを介してユーザとインタラクションを行っているものとする。一方、アプリケーションＢは、ユーザとのインタラクションなしにバックグラウンドで動作しているものとする。また、アプリケーションＡ、Ｂは、いずれも同一のタイプの通信パターン（例えば、ストリーミング通信）を行っているものとする。
【００１５】
このとき、ユーザ体感の観点から、アプリケーションＡの通信に関する応答時間を短縮することが望ましい。そこで、ユーザとインタラクションを行っているアプリケーションＡの通信を優先し、アプリケーションＡに対して通信条件の良いＲＡＴを選択させることが考えられる。一方、ユーザとのインタラクションがないアプリケーションＢの通信に関しては、優先度を下げ、例えば、アプリケーションＡが利用しているＲＡＴとは別のＲＡＴを利用させて、アプリケーションＡの通信に影響がないように制御することが考えられる。
【００１６】
しかしながら、出願人による先の出願文献に記載された無線通信端末では、ユーザ体感への影響を考慮した振り分けを行っておらず、通信パターンのみでの通信フローの識別および振り分けを行っている。したがって、上記のようにユーザ体感の観点から、アプリケーションＡ、Ｂの通信を制御することができない。
【００１７】
したがって、現在無線通信端末上で動作している各アプリケーションの通信に対して、ユーザ体感への影響を判断した上で、ユーザ体感向上に寄与する通信制御を行うことが望まれる。
【００１８】
なお、以上の問題は、通信端末が複数の無線通信手段を有する場合に限らず、通信端末が複数の有線通信手段を有する場合や、通信端末が無線通信手段と有線通信手段を有する場合にも同様に生じ得る。
【００１９】
そこで、通信端末が複数の通信手段を有する場合に、ユーザの体感を向上させるように通信制御を行うことが課題となる。本発明の目的は、かかる課題解決に寄与する無線通信端末、無線通信方法、および、プログラムを提供することにある。
【課題を解決するための手段】
【００２０】
本発明の第１の態様に係る通信端末は、複数の通信手段と、アプリケーションとユーザとのインタラクションの有無を判別するユーザ操作モニタ部と、前記アプリケーションが要求する通信特性を判別する通信パターン識別部と、前記複数の通信手段の実際の通信特性を監視する端末コンテキストモニタ部と、前記インタラクションの有無、前記アプリケーションが要求する通信特性、および、前記実際の通信特性に応じて、前記アプリケーションに割り当てる通信手段を前記複数の通信手段の中から選択するユーザ体感評価部と、を備えている。
【００２１】
本発明の第２の態様に係る通信方法は、複数の通信手段を備えた通信端末が、アプリケーションとユーザとのインタラクションの有無を判別するステップと、前記アプリケーションが要求する通信特性を判別するステップと、前記複数の通信手段の実際の通信特性を監視するステップと、前記インタラクションの有無、前記アプリケーションが要求する通信特性、および、前記実際の通信特性に応じて、前記アプリケーションに割り当てる通信手段を前記複数の通信手段の中から選択するステップと、を含む。
【００２２】
本発明の第３の態様に係るプログラムは、複数の通信手段を備えた通信端末に設けられたコンピュータに対して、アプリケーションとユーザとのインタラクションの有無を判別する処理と、前記アプリケーションが要求する通信特性を判別する処理と、前記複数の通信手段の実際の通信特性を監視する処理と、前記インタラクションの有無、前記アプリケーションが要求する通信特性、および、前記実際の通信特性に応じて、前記アプリケーションに割り当てる通信手段を前記複数の通信手段の中から選択する処理と、を実行させる。なお、プログラムは、非一時的なコンピュータ可読記録媒体（non-transitory computer-readable storage medium）に記録されたプログラム製品として提供することもできる。
【発明の効果】
【００２３】
本発明に係る通信端末、通信方法、および、プログラムによると、通信端末が複数の通信手段を有する場合に、ユーザの体感の向上させるように通信制御を行うことが可能となる。
【図面の簡単な説明】
【００２４】
【図１】一実施形態に係る通信端末の構成を例示するブロック図である。
【図２】第１の実施形態に係る無線通信端末を備えた無線通信システムの構成を例示するブロック図である。
【図３】アプリケーション毎のＵＩデバイスの利用状況の監視結果を一例として示す図である。
【図４】アプリケーション毎の通信フローの蓄積情報を一例として示す図である。
【図５】アプリケーション毎のカテゴリ分類結果を一例として示す図である。
【図６】各ＲＡＴの実際の通信特性の監視結果を一例として示す図である。
【図７】第１の実施形態に係る無線通信端末の動作を例示するフローチャートである。
【図８】アプリケーション毎の各カテゴリが通信経路に要求する通信特性を一例として示す図である。
【図９】第２の実施形態に係る無線通信端末を備えた無線通信システムの構成を例示するブロック図である。
【図１０】第３の実施形態に係る無線通信端末を備えた無線通信システムの構成を例示するブロック図である。
【図１１】ユーザプリファレンス情報の構成を例示する図である。
【図１２】関連技術に係るオープンフロー（OpenFlow）に基づく通信システムの構成を例示する図である。
【図１３】オープンフローにおけるフローエントリ（Flow Entry）の構成を例示する図である。
【図１４】スマートフォンのソフトウェアプラットフォームの構成を抽象化して示す図である。
【図１５】第５の実施形態に係る無線通信端末（スマートフォンのソフトウェアプラットフォームに基づいて実装された端末）の構成を例示するブロック図である。
【発明を実施するための形態】
【００２５】
はじめに、一実施形態の概要について説明する。なお、この概要に付記する図面参照符号は、専ら理解を助けるための例示であり、本発明を図示の態様に限定することを意図するものではない。
【００２６】
図１は、一実施形態に係る通信端末１０の構成を例示するブロック図である。図１を参照すると、通信端末１０は、複数の通信手段１１、１２（通信端末１０が無線通信端末である場合、無線ＬＡＮ（Local Area Network）通信ＩＦ（Interface）、セルラ通信ＩＦなど）と、（例えば、ＵＩ（User Interface）デバイスの利用状況を監視することで）アプリケーションとユーザとのインタラクションの有無を判別するユーザ操作モニタ部１４と、（例えば、アプリケーションが発生させる通信フローの特徴に応じて）アプリケーションが要求する通信特性を判別する通信パターン識別部１５と、複数の通信手段の実際の通信特性（例えば、通信手段による通信の遅延時間、通信帯域、接続の安定性、および、通信料金）を監視する端末コンテキストモニタ部１６と、インタラクションの有無、アプリケーションが要求する通信特性、および、実際の通信特性に応じて、アプリケーションに割り当てる通信手段を複数の通信手段１１、１２の中から選択するユーザ体感評価部１７と、を備えている。
【００２７】
かかる通信端末１０によると、通信端末１０が複数の通信手段を有する場合に、ユーザの体感を向上させるように通信制御を行うことが可能となる。なぜなら、アプリケーションとユーザとのインタラクションの有無と、アプリケーションが要求する通信特性と、実際の通信特性に応じて、ユーザの体感の観点から好適な通信手段をアプリケーションに割り当てることができるからである。
【００２８】
次に、一実施形態に係る無線端末１０が無線通信端末である場合について、図面を参照して説明する。
【００２９】
図２は、一実施形態に係る無線通信端末１００の構成を例示するブロック図である。図２を参照すると、無線通信端末１００は、ユーザ操作モニタ部１４０、通信パターン識別部１５０、端末コンテキストモニタ部１６０、ユーザ体感評価部１７０、および、通信経路制御部１８０を備えている。
【００３０】
ユーザ操作モニタ部１４０は、無線通信端末１００上のＵＩ（User Interface）デバイスを通したユーザとアプリケーションとのインタラクションを監視する。
【００３１】
通信パターン識別部１５０は、無線通信端末１００上で動作する各アプリケーション（アプリケーション１９０〜１９Ｎ）の通信パターンを識別する。すなわち、通信パターン識別部１５０は、各アプリケーションの特徴的な通信パターンを識別する。
【００３２】
端末コンテキストモニタ部１６０は、無線通信端末１００上のＲＡＴ（Radio Access Technology）の状態を含む無線通信端末１００のコンテキストを監視する。すなわち、端末コンテキストモニタ部１６０は、無線ＬＡＮ通信、セルラ通信などの無線通信端末１００上のＲＡＴの状態を含む、無線通信端末１００のコンテキストを監視する。
【００３３】
ユーザ体感評価部１７０は、上記各部１４０、１５０、１６０の情報に基づき、アプリケーションの通信フロー単位で、通信の応答性、遅延、スループットなどの観点からユーザ体感への当該通信フローの影響度を判断する。すなわち、ユーザ体感評価部１７０は、ユーザ操作モニタ部１４０、通信パターン識別部１５０および端末コンテキストモニタ部１６０がそれぞれ監視、識別した情報に基づき、アプリケーションの通信フロー単位で、通信の応答性、遅延、スループットなどの観点から、ユーザ体感への当該通信フローの影響度を判断する。また、ユーザ体感評価部１７０は、端末コンテキストモニタ部１６０によるＲＡＴの状態を含む実際の端末コンテキストを元に、ユーザ体感の観点から好適な通信経路制御方式を決定する。
【００３４】
通信経路制御部１８０は、ユーザ体感評価部１７０によって決定された通信経路制御方式を当該通信フローに対して適用する。すなわち、通信経路制御部１８０は、ユーザ体感評価部１７０による通信フロー毎のユーザ体感への影響度と、端末コンテキストモニタ部１６０によるＲＡＴの状態を含む実際の端末コンテキスト、および、通信パターン識別部１５０による当該アプリケーションおよび通信フローの通信パターンを元に、ユーザ体感の観点から、好適な通信経路制御を行う。
【００３５】
以上より、ユーザ体感評価部１７０は、ユーザ操作モニタ部１４０で監視したアプリケーション毎のユーザとのインタラクションの有無と、通信パターン識別部１５０で識別したアプリケーション毎の通信パターン識別結果と、端末コンテキストモニタ部１６０による無線通信端末１００上のＲＡＴの状態を含む端末コンテキスト情報に基づき、今回新たに発生したあるアプリケーションの通信フローのユーザ体感への影響度を評価することになる。また、通信経路制御部１８０は、ユーザ体感評価部１７０による評価結果を元に、実際の端末のコンテキストに基づいた最適な通信経路制御を行う。
【００３６】
以上の構成を備えた無線通信端末１００によると、無線通信端末１００上の複数のアプリケーションから発生する複数の通信フローに対して、ユーザ体感への影響が大きい通信フローを通信品質の高いＲＡＴに優先的に経路制御する等の制御を行うことで、通信の応答性、遅延、スループットといった観点でのユーザ体感を向上させることが可能となる。すなわち、無線通信端末１００によると、無線通信端末上で実際に動作している各アプリケーションの通信に対して、ユーザ体感への影響を判断した上で、ユーザ体感向上に寄与する通信制御を行うことが可能となる。
【００３７】
以下では、実施形態に基づいて、本発明に係る通信端末について、さらに詳細に説明する。なお、以下の実施形態では、通信端末が無線通信端末であり、通信手段として複数の無線通信手段を有する場合を例として説明する。しかしながら、本発明の通信端末は、かかる例に限定されない。すなわち、本発明は、通信端末が複数の無線通信手段を有する場合に限らず、通信端末が複数の有線通信手段を有する場合や、通信端末が無線通信手段と有線通信手段とを併せ持つ場合にも同様に適用することができる。
【００３８】
＜実施形態１＞
次に、第１の実施形態に係る無線通信端末１００について、図面を参照して詳細に説明する。
【００３９】
図２は、本実施形態に係る無線通信端末１００を備えた無線通信システムの構成を例示するブロック図である。図２を参照すると、無線通信システムは、無線通信端末１００と、無線ＬＡＮ（Local Area Network）アクセスポイント２００と、セルラ基地局３００と、サーバ群４００とを備えている。
【００４０】
無線通信端末１００と無線ＬＡＮアクセスポイント２００は、無線ＬＡＮにて接続し、通信を行う。同様に、無線通信端末１００とセルラ基地局３００は、セルラ通信にて接続し、通信を行う。
【００４１】
無線ＬＡＮアクセスポイント２００とサーバ群４００は、無線または有線の通信手段にて接続されている。同様に、セルラ基地局３００とサーバ群４００は、無線または有線の通信手段にて接続されている。
【００４２】
無線通信端末１００は、無線ＬＡＮアクセスポイント２００を経由して、無線ＬＡＮ通信にてサーバ群４００と通信を行う。また、無線通信端末１００は、セルラ基地局３００を経由して、セルラ通信にてサーバ群４００と通信を行う。
【００４３】
無線通信端末１００は、無線ＬＡＮ通信ＩＦ（Interface）１１０、セルラ通信ＩＦ１２０、ＵＩ（User Interface）デバイス１３０、ユーザ操作モニタ部１４０、通信パターン識別部１５０、端末コンテキストモニタ部１６０、ユーザ体感評価部１７０、通信経路制御部１８０、および、アプリケーション１９０〜１９Ｎを備えている。
【００４４】
これらの各部は、それぞれ次のように動作する。
【００４５】
ユーザ操作モニタ部１４０は、無線通信端末１００上のＵＩデバイス１３０を通したユーザとアプリケーション１９０〜１９Ｎとのインタラクションを監視および解析する。
【００４６】
通信パターン識別部１５０は、無線通信端末１００上で動作するアプリケーション１９０〜１９Ｎから発生する通信フローを元にアプリケーション単位で通信パターンを識別する。
【００４７】
端末コンテキストモニタ部１６０は、無線通信端末１００上のＲＡＴ（Radio Access Technology）である無線ＬＡＮ通信ＩＦ１１０、セルラ通信ＩＦ１２０の状態を含む無線通信端末１００のコンテキストを監視する。
【００４８】
ユーザ体感評価部１７０は、ユーザ操作モニタ部１４０および通信パターン識別部１５０による解析結果および識別結果に基づき、アプリケーションの通信フロー単位で、通信の応答性、遅延、スループットなどの観点でのユーザ体感への当該通信フローの影響度を判断した上で、端末コンテキストモニタ部１６０による各ＲＡＴの状態を含む実際の端末コンテキスト情報を元に、ユーザ体感の観点から好適な通信経路制御方式を決定する。
【００４９】
通信経路制御部１８０は、ユーザ体感評価部１７０により決定された通信経路制御方式に従って、当該通信フローに対する通信経路制御を実施する。
【００５０】
次に、本実施形態に係る無線通信端末１００の動作について、より詳細に説明する。
【００５１】
まず、無線通信端末１００の無線ＬＡＮ通信およびセルラ通信の挙動について説明する。
【００５２】
無線通信端末１００は、無線ＬＡＮアクセスポイント２００の無線電波が到達可能なカバーエリア内に存在する場合、無線ＬＡＮ通信ＩＦ１１０を用いて無線ＬＡＮアクセスポイント２００と無線接続処理を行った後、無線ＬＡＮにて通信を行う。また、無線通信端末１００はセルラ通信機能も備えている。したがって、セルラ基地局３００の無線電波が到達可能なカバーエリア内に存在する場合、無線通信端末１００はセルラ通信ＩＦ１２０を用いてセルラ基地局３００とセルラ通信を行う。
【００５３】
無線通信端末１００上で動作するアプリケーション１９０〜１９Ｎがサーバ群４００とそれぞれ通信する際の各通信フローは、通信経路制御部１８０を通して無線ＬＡＮ通信ＩＦ１１０側またはセルラ通信ＩＦ１２０のいずれかの経路を通って、無線ＬＡＮ通信またはセルラ通信にて通信が行われる。
【００５４】
なお、無線通信端末１００の種別に応じて、無線ＬＡＮ通信とセルラ通信が排他利用となる場合と、両方同時に利用可能となる場合がある。本実施形態では、排他利用および同時利用の両者を対象とする。
【００５５】
まず、ユーザ操作モニタ部１４０は、無線通信端末１００上で動作するアプリケーション１９０〜１９Ｎの動作、特に、ＵＩデバイス１３０の利用状況を常時監視する。ＵＩデバイス１３０の具体例として、ディスプレイ、ハードウェアキーおよびボタン（キーボード、マウスなど）、タッチパネル、音声マイク、スピーカーなどが挙げられる。ユーザ操作モニタ部１４０は、この監視結果を、アプリケーション毎のＵＩデバイス１３０の利用状況の情報として保持する。
【００５６】
図３は、ユーザ操作モニタ部１４０が保持する情報を一例として示す。ユーザ操作モニタ部１４０は、アプリケーション名と、ＵＩデバイス１３０の利用の有無の情報を保持することが好ましい。さらに、ユーザ操作モニタ部１４０は、ＵＩデバイス１３０の種別や、利用時刻、アプリケーション起動時間に占めるＵＩデバイス利用時間の比率などの情報を保持してもよい。
【００５７】
一例として、あるアプリケーション（例えば、図３のブラウザＡ）がディスプレイに情報を表示し、ユーザはタッチパネルを操作して当該アプリケーションのＵＩ操作を行っている場合、ユーザ操作モニタ部１４０は、このアプリケーション名とともに、ＵＩデバイス利用がある旨の情報を保持し、ＵＩデバイスの詳細種別（例えば、ディスプレイ、タッチパネル）などの付随情報を保持する。
【００５８】
他の例として、あるアプリケーションがディスプレイに情報は表示せず、ディスプレイに情報を表示する別のアプリケーションのバックグラウンドで動作するとともに、音声マイクおよびスピーカーを利用している場合が考えられる。例えば、図３の音声通話アプリＣは、このように別のアプリケーションのバックグラウンドで動作し、ディスプレイを通したユーザへの情報提示を行わないものの、音声マイクやスピーカーを通してユーザとインタラクションを行う。このような場合にも、ユーザ操作モニタ部１４０は、このアプリケーションについてＵＩデバイスの利用があるものと判断し、その旨の情報を保持する。
【００５９】
さらに、ディスプレイを含む一切のＵＩデバイスを利用せず、ユーザとのインタラクションを行わないアプリケーション（例えば、図３のデータ同期アプリＢ）については、ユーザ操作モニタ部１４０はＵＩデバイスの利用無しとの情報を保持する。
【００６０】
このように、ユーザ操作モニタ部１４０は、無線通信端末１００上で動作するアプリケーション毎に、ユーザとのＵＩデバイスを通したインタラクションを行うものか否かの判別を、ＵＩデバイス１３０の利用状況の監視を通して実施し、その情報を常時更新しつつ保持する。
【００６１】
通信パターン識別部１５０は、無線通信端末１００上で動作するアプリケーション１９０〜１９Ｎから発生する通信フローを常時監視する。
【００６２】
ここで、通信フローとは、アプリケーション１９０〜１９Ｎとサーバ群４００との間で行われる通信であって、送信元のＩＰ（Internet Protocol）アドレスおよびポート番号、ならびに、送信先のＩＰアドレスおよびポート番号によって識別される２点間の通信の流れを指す。したがって、一般的に、１つのアプリケーションから複数の通信フローが発生する。また、アプリケーション１９０〜１９Ｎとサーバ群４００との通信は、無線通信端末１００上の無線ＬＡＮ通信ＩＦ１１０またはセルラ通信ＩＦ１２０を介して行われる。通信経路制御部１８０は、各通信フローをどちらの通信ＩＦを通して流すかを制御する。
【００６３】
通信パターン識別部１５０は、アプリケーション１９０〜１９Ｎから発生する各通信フローを監視し、アプリケーション毎の各通信フローの情報を蓄積する。通信パターン識別部１５０が蓄積する各通信フローの情報として、例えば、通信フローの継続時間、通信フローの時間当たりの通信量の変化および総通信量、１つのアプリケーションが同時刻に発生させた通信フローの数、通信フローの時間当たりの発生頻度などが挙げられる。これら以外の情報として、通信フローの情報は、送信先のＩＰアドレス、ポート番号などの情報を含んでいてもよい。
【００６４】
通信パターン識別部１５０は、これらの通信フローの情報を、例えば、自身に設けられたデータベースに蓄積してもよい。図４は、蓄積された通信フローの情報のデータ形式を一例として示す。
【００６５】
通信パターン識別部１５０は、蓄積された通信フローの情報を元に、アプリケーション１９０〜１９Ｎに対してアプリケーション単位で、その通信パターンを分類して、カテゴリ分けを行う。このカテゴリ分類方法について、以下に説明する。
【００６６】
通信パターン識別部１５０は、蓄積されたデータに対して、アプリケーション毎に、当該アプリケーションから発生した通信フローに関する情報の一覧を取得する。通信パターン識別部１５０は、これらの通信フロー情報の一覧を元に、アプリケーション毎の通信の使い方の分類を行う。
【００６７】
ここで、通信パターン識別部１５０は、例えば、次のような観点Ｕ１〜観点Ｕ５に従って分類を行う。
観点Ｕ１：アプリケーションが同時刻に発生させる通信フロー数、
観点Ｕ２：各通信フローの平均継続時間、
観点Ｕ３：各通信フローの時間当たりの通信量の変化、
観点Ｕ４：各通信フローの総通信量の平均、
観点Ｕ５：アプリケーションが発生させる通信フローの時間当たりの頻度
【００６８】
通信パターン識別部１５０は、観点Ｕ１に基づいて、同時に発生する通信フロー数が多い場合、当該アプリケーションがブラウザアプリケーションのように同時に多数の通信フローを発生させて、それぞれ個別の画像、テキストファイル、スクリプトなどのコンテンツを並列に取得するタイプのアプリケーションであると分類する。以下では、このように分類されたアプリケーションのカテゴリ名を「並列通信タイプ」とする。
【００６９】
通信パターン識別部１５０は、観点Ｕ２に基づいて、通信フローの継続時間が長い場合、当該アプリケーションがインターネットラジオや音声通話アプリケーションのようにストリーミング形式で１つの通信フローを維持したまま利用するタイプのアプリケーション、または、１つの通信フローを使って大容量のファイルをダウンロードするアプリケーションであると推定する。通信パターン識別部１５０は、観点Ｕ２と観点Ｕ３を組み合わせて、観点Ｕ２に基づいて通信フローの継続時間が長く、さらに、観点Ｕ３に基づいて通信フローの時間当たりの通信量の変化が一定である場合、ストリーミング形式で一定の通信レートでデータの受信を行う前者のアプリケーションであると判定する。以下では、このように分類されたアプリケーションのカテゴリ名を「ストリーミングタイプ」とする。
【００７０】
一方、通信パターン識別部１５０は、観点Ｕ４に基づいて各通信フロー当たりの総通信量が多く、観点Ｕ３に基づいて通信フロー当たりの通信量の変化が通信開始時に急激に増加し、終了時に急激に低下するような変化を示す場合、大容量のファイルをダウンロードするアプリケーションであると判定する。以下では、このように分類されたアプリケーションのカテゴリ名を「ファイルダウンロードタイプ」とする。
【００７１】
また、通信パターン識別部１５０は、観点Ｕ５に基づいて、当該アプリケーションが単位時間当たりに発生させる通信フローの頻度が多く、観点Ｕ２に基づいて通信フローの平均継続時間が短く、さらに、観点Ｕ４に基づいて１通信フロー当たりの総通信量が少ない場合、ユーザの現在の状態（例えば、無線通信端末１００を利用中か否かなどのプリファレンス情報）を定期的にサーバに通信し、または、ユーザ同士のショートメッセージを交換するようなＳＮＳ（Social Network Service）アプリケーションのような通信特徴を有するアプリケーションであると推定する。以下では、このように分類されたアプリケーションのカテゴリ名を「シグナリングタイプ」とする。
【００７２】
なお、上記の分類は通信フローの特徴を元にしたアプリケーションの通信の使い方に関する分類の一例にすぎず、本発明における分類方法はこれに限定されない。このようにアプリケーションの通信特性に基づいてカテゴリ分けすることで、後述する通信経路制御処理においてアプリケーションのカテゴリ毎にユーザ体感を向上させる観点で、それぞれ最適な通信経路制御を適用することが可能となる。
【００７３】
図５は、通信パターン識別部１５０がアプリケーション毎のカテゴリ分けを行った結果を例示する。通信パターン識別部１５０は、常時、通信フローの監視および解析を行い、アプリケーション毎のカテゴリ分け結果を追加、更新しつつ保持する。
【００７４】
端末コンテキストモニタ部１６０は、無線通信端末１００上のＲＡＴである無線ＬＡＮ通信ＩＦ１１０、および、セルラ通信ＩＦ１２０の状態を含む無線通信端末１００のコンテキストを常時監視する。
【００７５】
無線ＬＡＮ通信ＩＦ１１０の状態として、例えば、無線ＬＡＮアクセスポイント２００と接続中か否か、接続中である場合には、接続先の無線ＬＡＮアクセスポイントのＳＳＩＤ（Service Set Identifier）、無線ＬＡＮ電波の電界強度、無線ＬＡＮ通信のパケットロス率、接続中の無線ＬＡＮアクセスポイントを通した通信における遅延時間および利用可能通信帯域などが挙げられる。
【００７６】
一方、セルラ通信ＩＦ１２０の状態として、例えば、セルラ基地局３００と接続中か否か、接続中である場合には、セルラ通信の種別（例えば、３Ｇ、ＬＴＥなど）、さらにセルラ通信の電波強度、セルラ通信のパケットロス率、セルラ通信における遅延時間および利用可能通信帯域などが挙げられる。
【００７７】
ここで、端末コンテキストモニタ部１６０は、無線ＬＡＮ通信やセルラ通信の遅延時間および利用可能通信帯域に関して、無線ＬＡＮアクセスポイント２００またはセルラ基地局３００と接続した際に得られる、接続先の通信仕様および利用通信方式に基づく理論的な遅延時間および利用可能通信帯域値を用いてもよい。また、端末コンテキストモニタ部１６０は、遅延時間および帯域測定用の通信パケットを実際に通信経路上に送信して得られる実測値を用いてもよい。
【００７８】
端末コンテキストモニタ部１６０は、以上の各状態の監視結果を元に解析を行い、無線通信端末１００内の各ＲＡＴに対して、例えば、以下の観点Ｖ１〜Ｖ４から特性の分類を行う。
観点Ｖ１：通信の遅延時間、
観点Ｖ２：通信帯域、
観点Ｖ３：接続安定性、
観点Ｖ４：通信料金
【００７９】
端末コンテキストモニタ部１６０は観点Ｖ１、観点Ｖ２に関しては、端末コンテキストモニタ部１６０による前述の各ＲＡＴの状態監視結果に応じて分類する。
【００８０】
端末コンテキストモニタ部１６０は、例えば、観点Ｖ１の通信の遅延時間について、遅延時間が短いものから長いものまで数段階で分類する。
【００８１】
一方、端末コンテキストモニタ部１６０は、観点Ｖ２の通信帯域に関して、各ＲＡＴの通信帯域値をそのまま用いる。
【００８２】
また、端末コンテキストモニタ部１６０は、観点Ｖ３の接続安定性に関して、無線ＬＡＮまたはセルラ通信の電波強度、パケットロス率などを元に、安定性が高いものから低いものまで数段階で分類する。
【００８３】
さらに、端末コンテキストモニタ部１６０は、観点Ｖ４の通信料金に関して、無線ＬＡＮの場合、ＳＳＩＤを元に通信キャリア等が提供している公衆無線ＬＡＮ、または、自宅もしくは勤務先などに設置された無線ＬＡＮかを判別する。
【００８４】
端末コンテキストモニタ部１６０は、公衆無線ＬＡＮである場合、別途準備したＳＳＩＤとそれに対応する公衆無線ＬＡＮの料金体系情報（例えば、何ＧＢｙｔｅまでは１パケット当たり何円という一覧表）を元に、その通信料金を判断する。
【００８５】
一方、端末コンテキストモニタ部１６０は、自宅または勤務先などの無線ＬＡＮの場合、通信料金は無料と判断する。
【００８６】
なお、例外が存在する場合、端末コンテキストモニタ部１６０は、公衆無線ＬＡＮの場合と同様に、ＳＳＩＤと料金体系情報との一覧表を準備した上で、接続中のＳＳＩＤの通信料金を判別する。
【００８７】
図６は、無線通信端末１００に設けられたＲＡＴである、無線ＬＡＮ通信ＩＦ１１０とセルラ通信ＩＦ１２０に対して、端末コンテキストモニタ部１６０が特性の分類を行った結果を一例として示す。
【００８８】
これらの端末コンテキストは、時間経過とともに逐一変化するものである。そこで、端末コンテキストモニタ部１６０は、常時、上述のように無線通信端末１００上のコンテキストの監視および解析を行い、各ＲＡＴの特性の分類結果を随時更新しつつ保持する。
【００８９】
次に、上述したユーザ操作モニタ部１４０によるアプリケーション毎のユーザとのインタラクションの有無の情報と、通信パターン識別部１５０によるアプリケーション毎の通信パターンのカテゴリ分類情報と、端末コンテキストモニタ部１６０による無線通信端末１００の各ＲＡＴの特性分類情報とを元に、ユーザ体感向上の観点から好適な通信経路制御を行う処理について、図面を参照して説明する。
【００９０】
図７は、本実施形態に係る無線通信端末１００による、かかる処理を例示するフローチャートである。
【００９１】
図７を参照すると、まず、無線通信端末１００上で動作するアプリケーション１９０〜１９Ｎのいずれかのアプリケーションがサーバ群４００に対して通信を行うと、無線通信端末１００内で新たな通信フローが発生する（ステップＡ１）。
【００９２】
ユーザ体感評価部１７０は、当該通信フローの発生元アプリケーションを特定する（ステップＡ２）。
【００９３】
ユーザ体感評価部１７０は、通信フローから発生元アプリケーションの特定を行う方法として、次の方法を用いることができる。すなわち、ユーザ体感評価部１７０は、例えば、通信フローの送信元ポート番号を元に当該ポート番号を用いた通信を行っているプロセスを調べ、次に、プロセスが属するアプリケーション名を特定する。
【００９４】
これらのプロセスおよびアプリケーション名の識別は、ＯＳ（Operating System）の機能を用いることで実現することができる。ＯＳは当該ポート番号を用いて通信を行っているプロセスを把握しており、当該プロセスを生成したアプリケーションの実行ファイルのファイル名等も把握しているからである。
【００９５】
ユーザ体感評価部１７０は、得られた発生元アプリケーションに関して、当該アプリケーションのユーザとのインタラクションの有無をユーザ操作モニタ部１４０に問い合わせる（ステップＡ３）。
【００９６】
ユーザ操作モニタ部１４０は、問い合わせを受けたアプリケーション名に対して、自身が保持しているアプリケーション毎のユーザとのインタラクションの有無の情報の一覧（例えば、図３）を元に、ユーザとのインタラクションの有無をユーザ体感評価部１７０に返答する（ステップＡ４）。
【００９７】
次に、ユーザ体感評価部１７０は、当該アプリケーションの通信パターンのカテゴリ分類情報を通信パターン識別部１５０に問い合わせる（ステップＡ５）。
【００９８】
通信パターン識別部１５０は、問い合わせを受けたアプリケーション名に対して、自身が保持しているアプリケーション毎の通信パターンのカテゴリ分類結果の一覧（例えば、図５）を元に、カテゴリ分類結果をユーザ体感評価部１７０に返答する（ステップＡ６）。
【００９９】
次に、ユーザ体感評価部１７０は、現在の無線通信端末１００の各ＲＡＴの特性分類情報を端末コンテキストモニタ部１６０から取得する（ステップＡ７）。
【０１００】
次に、ユーザ体感評価部１７０は、ステップＳ３〜Ｓ７で得られた、今回発生した通信フローの発生元アプリケーションのユーザインタラクションの有無、発生元アプリケーションの通信パターンのカテゴリ分類結果、無線通信端末１００の各ＲＡＴの現在の特性分類情報を元に、今回発生した通信フローのユーザ体感への影響を考慮した通信経路制御方式を決定する（ステップＡ８）。
【０１０１】
ユーザ体感評価部１７０は、通信経路制御方式を決定する手順において、一例として、まず、発生元アプリケーションのユーザインタラクションの有無に応じて、当該通信フローの重要度を判断する。ユーザとのインタラクションがあるアプリケーションの通信は、一般にユーザ体感への影響が大きい。そこで、ユーザ体感評価部１７０は、例えば、ユーザとのインタラクションがある場合、重要度が高いものと判定し、それ以外の場合、重要度が低いものと判定する。
【０１０２】
さらに、ユーザ体感評価部１７０は、通信経路に対する要求を、発生元アプリケーションの通信パターンのカテゴリ分け結果に基づいて判断する。
【０１０３】
図８は、通信経路に要求される通信特性を、通信パターンのカテゴリ毎に例示する図である。図８に示す通信特性は、各カテゴリの通信フローの特徴を元に、ユーザ体感を向上させる観点から、通信経路に求められる通信特性を記述したものである。
【０１０４】
ストリーミングタイプは、一定の帯域で長時間通信を継続させる。そこで、ストリーミングタイプについては、通信経路に対して、一定以上の通信帯域と通信の安定性が求められる。
【０１０５】
一方、ファイルダウンロードタイプは、大容量のデータ受信を行う。そこで、ファイルダウンロードタイプについては、通信帯域が大きいほどよく、また、通信料金は比較的安いことが望ましい。
【０１０６】
また、シグナリングタイプは、少量のデータ通信を高頻度に行うものの、通信帯域および通信の安定性はいずれもあまり必要とされない。
【０１０７】
さらに、並列通信タイプは、多数の通信フローを同時に利用する。そこで、並列通信タイプについては、各通信フローを複数のＲＡＴに分散させることで、ＲＡＴ毎の負荷を分散させることが好ましい。
【０１０８】
ユーザ体感評価部１７０は、これらの当該通信フローの重要度および通信経路に対する要求と、実際の無線通信端末１００の各ＲＡＴの特性分類情報とを突き合わせて、好適なＲＡＴ選択、および、通信フローの優先度設定を行う。
【０１０９】
ユーザ体感評価部１７０は、例えば、通信フローがストリーミングタイプのアプリケーションから発生したものである場合、無線通信端末１００の各ＲＡＴのうちの接続安定性が高いＲＡＴを選択する。
【０１１０】
一方、ユーザ体感評価部１７０は、通信フローがダウンロードタイプのアプリケーションから発生したものである場合、無線通信端末１００の各ＲＡＴのうちの通信帯域が大きい方のＲＡＴを用いて通信することを選択する。また、ユーザ体感評価部１７０は、両方のＲＡＴが同一の通信帯域である場合、遅延時間や、接続安定性、料金の観点から、より良好な特性を示すＲＡＴを選択する。
【０１１１】
さらに、ユーザ体感評価部１７０は、通信フローがシグナリングタイプのアプリケーションから発生したものである場合、通信経路に対する特別な要求はないため、料金が安い方のＲＡＴ、または、他のアプリケーションが現在利用していないＲＡＴを選択する。
【０１１２】
また、ユーザ体感評価部１７０は、並列通信タイプのアプリケーションから発生した通信フローである場合、同一のアプリケーションから発生した通信フロー群が無線通信端末１００に設けられた各ＲＡＴに交互に振り分けられるように選択する。具体的には、ユーザ体感評価部１７０は、当該アプリケーションから前回発生した通信フローが無線ＬＡＮ通信ＩＦ１１０を用いるように選択した場合、今回発生した通信フローがセルラ通信ＩＦ１２０を用いるように選択する。
【０１１３】
さらに、ユーザ体感評価部１７０は、通信フローのユーザとのインタラクションの有無を元にした重要度に基づき、重要度が低い通信フローの場合、他の重要度が高い通信フローとは異なるＲＡＴを選択するように判断してもよい。
【０１１４】
一例として、ユーザとのインタラクションがあるストリーミングタイプのアプリケーションＡと、ユーザとのインタラクションがないダウンロードタイプのアプリケーションＢが、同時に起動して通信を行っている場合を考える。
【０１１５】
この場合、ユーザ体感評価部１７０は、ストリーミングタイプのアプリケーションＡから発生した通信フローを重要度が高い通信フローとみなし、このアプリケーションのカテゴリに合ったより条件の良いＲＡＴを用いるように選択する。一方、ユーザ体感評価部１７０は、ユーザとのインタラクションがないため、ダウンロードタイプのアプリケーションＢを重要度が低いものとみなす。また、ユーザ体感評価部１７０は、アプリケーションＢの通信フローに対して、アプリケーションＡの通信フローに対して選択したＲＡＴとは異なるＲＡＴを選択する。
【０１１６】
これによって、アプリケーションＡが利用しているＲＡＴに対して、アプリケーションＢが通信負荷をかけないことになる。したがって、ユーザとのインタラクションを持つ重要度の高いアプリケーションＡの通信フローの通信特性を向上させることができ、結果として、ユーザ体感を向上させることが可能となる。
【０１１７】
ここで、現在１つのＲＡＴしか通信可能な状態にない場合、または、すでに多数のアプリケーションの通信フローが発生しており、重要度の高い通信フローのみが特定の通信特性の良いＲＡＴを占有することができない場合、ユーザ体感評価部１７０は、他のアプリケーションの通信フローと同一のＲＡＴを選択した上で、重要度の高い通信フローに対して高優先で通信を行うような優先通信制御を行ってもよい。
【０１１８】
かかる優先通信制御の実現方式として、例えば、ＯＳが備えるネットワークのＱｏＳ（Quality of Service）処理機能を用いて実現することができる。例えば、Linux（登録商標）などのＯＳでは、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）通信に対するＱｏＳ処理実現のための機構として、パケットスケジューラやキュー管理機構を備えている。そこで、これらを用いることにより、特定の通信フローを構成する通信パケットに対して優先して通信するための制御を実現することができる。
【０１１９】
次に、通信経路制御部１８０は、ユーザ体感評価部１７０により決定された通信経路制御方式に従って、当該通信フローの通信経路制御を行う（ステップＡ９）。
【０１２０】
ここで、通信経路制御方式とは、上述の通り、ある通信フローに対して、いずれのＲＡＴを用いて通信するかの制御、および、特定通信フローの優先通信制御を指す。
【０１２１】
以上の動作の説明においては、アプリケーション単位で、ユーザインタラクションの有無を判断し、通信パターンをカテゴリ分けし、これに基づく通信経路制御を行うものとした。しかしながら、アプリケーション単位の代わりに、プロセス単位で以上の動作を行うようにしてもよい。
【０１２２】
プロセスとは、ＯＳ上の処理の実行単位である。また、アプリケーションは、１〜Ｎ個のプロセスから構成される。アプリケーションによっては、自身を構成するプロセス毎に異なる機能を担わせている場合がある。例えば、アプリケーションＡは、プロセスＡ１、Ａ２から構成されていることがある。ここで、プロセスＡ１は、ユーザとのインタラクションを持ち、ユーザの指示に従って随時通信をする。一方、プロセスＡ２は、ユーザとのインタラクションなしにバックグラウンドで動作し、アプリケーションの動作に必要な大量のデータをユーザの指示とは関係なくダウンロードするケースがある。
【０１２３】
プロセス単位でユーザインタラクションの有無の判断と通信パターンのカテゴリ分けを行うことにより、１つのアプリケーション内で複数のプロセスが互いに異なる役割を果たす場合にも、ユーザ体感向上につながる好適な通信制御を行うことが可能となる。
【０１２４】
次に、本実施形態に係る無線通信端末１００の効果について説明する。
【０１２５】
本実施形態の無線通信端末１００では、ユーザ操作モニタ部１４０が通信フローの発生元のアプリケーションによるユーザインタラクションの有無を判断し、通信パターン識別部１５０が通信パターンのカテゴリ分けを実施し、端末コンテキストモニタ部１６０が現在の無線通信端末１００のＲＡＴの状態を判断した上で、ユーザ体感評価部１７０が当該通信フローのユーザ体感への影響および通信経路へ要求する特性を元に好適な通信経路制御方式を決定し、通信経路制御部１８０がこれに基づいて通信制御を実施する。
【０１２６】
すなわち、本実施形態の無線通信端末１００では、アプリケーション毎のユーザとのインタラクションの有無、および、アプリケーション毎の通信経路への要求を無線通信端末１００上で発生する通信フローの解析により判断した上で、現在の無線通信端末１００上の各ＲＡＴの通信特性を元に、ユーザ体感評価部１７０にて通信応答性、通信接続安定性などのユーザ体感の観点から通信フロー単位で好適な通信経路制御を選択する。これにより、無線通信端末１００上の複数のアプリケーションから発生する複数の通信フローに対して、ユーザ体感への影響が大きい通信フローを通信品質の高いＲＡＴに優先的に経路制御する等の制御を行い、ユーザ体感を向上させることが可能となる。
【０１２７】
したがって、本実施形態の無線通信端末１００によると、無線通信端末１００上である通信フローが発生した際、その通信フローのユーザ体感への影響を考慮した好適な通信経路制御を行うことにより、当該通信フローの応答性および安定性を向上させ、結果として、通信に関わるユーザ体感を向上させることが可能となる。
【０１２８】
＜実施形態２＞
次に、第２の実施形態に係る無線通信端末１００について、図面を参照して説明する。図９は、本実施形態に係る無線通信端末１００の構成を例示するブロック図である。
【０１２９】
図９を参照すると、本実施形態に係る無線通信端末１００は、無線ＬＡＮ（Local Area Network）通信ＩＦ（Interface）１１０、セルラ通信ＩＦ１２０、ＵＩ（User Interface）デバイス１３０、アプリケーション情報データベース（ＤＢ：Database）１１００、端末コンテキストモニタ部１６０、ユーザ体感評価部１７０、通信経路制御部１８０、および、アプリケーション１９０〜１９Ｎを備えている。
【０１３０】
本実施形態に係る無線通信端末１００と第１の実施形態に係る無線通信端末１００とは、次の点で相違する。すなわち、本実施形態では、無線通信端末１００は、アプリケーション毎のユーザインタラクションの有無の情報、および、アプリケーション毎の通信パターンを元にしたカテゴリ分け結果の情報を、予めプロファイル情報としてアプリケーション情報データベース１１００内に保持する。
【０１３１】
アプリケーション情報ＤＢ１１００は、第１の実施形態に係る無線通信端末１００のユーザ操作モニタ部１４０および通信パターン識別部１５０が解析した結果と同様の情報を保持する。すなわち、アプリケーション情報ＤＢ１１００は、図３および図５に例示した情報を保持する。ここで、アプリケーション情報ＤＢ１１００への情報の入力方法として、無線通信端末１００に設けられたＵＩを介して情報を入力してもよい。また、無線通信端末１００の外部から、通信等の手段によって、ファイル等の形式で配布してもよい。
【０１３２】
ユーザ体感向上の観点から好適な通信経路制御を行う処理の流れ（図７のステップＡ１〜Ａ９）に関して、第１の実施形態に係る無線通信端末１００と本実施形態に係る無線通信端末１００では、次の点で相違する。
【０１３３】
すなわち、第１の実施形態において、ユーザ操作モニタ部１４０および通信パターン識別部１５０からそれぞれアプリケーション毎のユーザインタラクションの有無の情報、および、アプリケーション毎の通信パターンを元にしたカテゴリ分け結果の情報を取得する代わりに、本実施形態では、アプリケーション情報データベース１１００から、これらの情報を取得する。なお、その他の点については、第１の実施形態と本実施形態との間で、同様の処理が行われる。
【０１３４】
なお、本実施形態の無線通信端末１００によると、第１の実施形態とは異なり、ユーザ操作モニタ部１４０および通信パターン識別部１５０によるアプリケーション動作および通信フローの常時監視を行わない。したがって、本実施形態の無線通信端末１００によると、第１の実施形態に係る無線通信端末１００による効果を、より少ない消費電力で得ることができる。
【０１３５】
＜実施形態３＞
次に、第３の実施形態に係る無線通信端末１００について、図面を参照して説明する。図１０は、本実施形態に係る無線通信端末１００の構成を例示するブロック図である。
【０１３６】
図１０を参照すると、本実施形態に係る無線通信端末１００は、無線ＬＡＮ（Local Area Network）通信ＩＦ（Interface）１１０、セルラ通信ＩＦ１２０、ＵＩ（User Interface）デバイス１３０、ユーザ操作モニタ部１４０、通信パターン識別部１５０、端末コンテキストモニタ部１６０、ユーザ体感評価部１７０、通信経路制御部１８０、アプリケーション１９０〜１９Ｎ、および、ユーザプリファレンス情報データベース（ＤＢ：Database）１１１０を備えている。
【０１３７】
本実施形態に係る無線通信端末１００と第１の実施形態に係る無線通信端末１００との相違点として、次の点が挙げられる。すなわち、本実施形態では、ユーザプリファレンス情報ＤＢ１１１０は、ユーザが通信に関して何を重視するかのプリファレンス情報を保持する。また、ユーザ体感評価部１７０は、通信フローの通信制御方式を決定する際、このユーザプリファレンスで指定された要素を考慮した判断を行う。
【０１３８】
図１１は、ユーザプリファレンス情報ＤＢ１１１０が保持する情報を例示する。図１１に示すように、ユーザプリファレンス情報ＤＢ１１１０は、プリファレンス情報として、通信速度、接続安定性、料金などの要素に対して、それぞれ重視するかどうかを数段階で指定したものを保持する。これらの情報の入力方法として、例えば、無線通信端末１００に設けられたディスプレイ上のＵＩを通して、ユーザがそれぞれの要素に対して重視度合いを入力するようにしてもよい。
【０１３９】
本実施形態に係る無線通信端末１００の動作は、第１の実施形態に係る無線通信端末１００の動作と同様である。ただし、本実施形態に係る無線通信端末１００と第１の実施形態に係る無線通信端末１００との間で、ステップＡ８におけるユーザ体感評価部１７０による好適な通信経路制御の判断方式が相違する。
【０１４０】
本実施形態において、ユーザ操作モニタ部１４０の情報を元にした当該通信フローの重要度判断、ならびに、通信パターン識別部１５０の情報を元にした当該通信フローの通信経路に対する要求と実際の無線通信端末１００の各ＲＡＴの特性分類情報とを突き合わせて好適なＲＡＴ選択、および、通信フローの優先度設定を行う際、ユーザ体感評価部１７０は、さらに、ユーザプリファレンス情報ＤＢ１１１０に格納されたプリファレンス情報を考慮した判断を行う。
【０１４１】
例えば、ユーザプリファレンス情報において通信料金を重視する度合いが高い場合、ユーザ体感評価部１７０は各ＲＡＴの特性分類情報で通信料金が安い方のＲＡＴを優先して選択するように判断する。
【０１４２】
また、他の例として、ユーザプリファレンス情報において通信の接続安定性を重視する度合いが高い場合、ユーザ体感評価部１７０は各ＲＡＴの特性分類情報で接続安定性が高い方のＲＡＴを優先して選択するように判断する。
【０１４３】
さらに、ユーザプリファレンス情報において通信速度を重視する度合いが高い場合、ユーザ体感評価部１７０は各ＲＡＴの特性分類情報で遅延時間や通信帯域が優れたＲＡＴを優先して選択するように判断する。
【０１４４】
本実施形態に係る無線通信端末１００では、ユーザプリファレンス情報ＤＢ１１１０はユーザが重視する要素をユーザプリファレンス情報として保持し、ユーザ体感評価部１７０は通信経路制御方式の判断にユーザプリファレンス情報を反映させる。したがって、本実施形態の無線通信端末１００によると、第１および第２の実施形態に係る無線通信端末１００と比較して、よりユーザの意向に沿った通信経路制御が可能になる。
【０１４５】
＜実施形態４＞
次に、第４の実施形態に係る無線通信端末１００について、図面を参照して説明する。本実施形態の無線通信端末１００は、第１の実施形態の無線通信端末１００に対して、集中制御型のネットワークアーキテクチャであるオープンフロー（OpenFlow、非特許文献３）という技術を改良して適用したものである。なお、オープンフローは、第２および第３の実施形態に係る無線通信端末１００に対しても、同様に適用することができる。
【０１４６】
オープンフローは通信をエンドツーエンドのフローとして認識し、フロー単位で経路制御等を実行することを可能にする。まず、図１２および図１３を参照して、オープンフローについて説明する。
【０１４７】
図１２は、オープンフロー技術により構成された通信システムの構成を例示する図である。ここで、フローとは、所定の属性（例えば、通信の宛先や送信元等に基づいて識別される属性）を有する一連の通信パケット群を指す。
【０１４８】
オープンフロースイッチ（OpenFlow Switch）７１は、オープンフロー技術を採用したネットワークスイッチである。オープンフロースイッチ７１は、フローテーブル（Flow Table）７１０を備えている。オープンフローコントローラ（OpenFlow Controller）７０は、オープンフロースイッチ７１を制御する情報処理装置である。
【０１４９】
オープンフロースイッチ７１は、オープンフローコントローラ７０との間に設定されたセキュアチャネル（Secure Channel）７２を介して、オープンフローコントローラ７０と通信する。オープンフローコントローラ７０は、セキュアチャネル７２を介して、オープンフロースイッチ７１のフローテーブル７１０の設定を行う。なお、セキュアチャネル７２は、スイッチとコントローラ間の通信の盗聴や改ざん等を防止するための処置がなされた通信経路である。
【０１５０】
図１３は、フローテーブル７１０の各エントリ（フローエントリ、Flow Entry）の構成例を示す。フローエントリは、スイッチが受信したパケットのヘッダに含まれる情報（例えば、宛先ＩＰ（Internet Protocol）アドレスやＶＬＡＮ  ＩＤ（Virtual Local Area Network Identifier）等）と照合するためのマッチングルール（Matching RuleないしMatch Fields）と、パケットフロー毎の統計情報である統計情報（Counters）と、マッチングルールにマッチするパケットの処理方法を規定するインストラクション（InstructionsないしAction）とを含む。
【０１５１】
オープンフロースイッチ７１は、パケットを受信すると、フローテーブル７１０を参照する。オープンフロースイッチ７１は、受信したパケットのヘッダ情報にマッチするフローエントリを検索する。受信パケットのヘッダ情報にマッチするエントリが検索された場合、オープンフロースイッチ７１は、検索されたエントリのインストラクションフィールドに定義された処理方法に従って受信パケットを処理する。処理として、例えば、「受信パケットを所定のポートから転送する」、「受信したパケットを廃棄する」、「受信パケットのヘッダの一部を書き換えて、所定のポートから転送する」などが規定されている。
【０１５２】
一方、受信パケットのヘッダ情報にマッチするエントリが見つからない場合、オープンフロースイッチ７１は、例えば、セキュアチャネル７２を介して、オープンフローコントローラ７０に対して受信パケットを転送する。オープンフロースイッチ７１は、受信パケットを転送することにより、オープンフローコントローラ７０に対して、受信パケットの処理方法を規定したフローエントリの設定を要求する。なお、オープンフロースイッチ７１は、パケットの処理方法として、コントローラに要求を送信することを規定したフローエントリにパケットがマッチした場合、その処理方法に従って、コントローラに対してフローエントリの設定を要求してもよい。
【０１５３】
オープンフローコントローラ７０は、受信パケットの処理方法を決定し、決定した処理方法を含むフローエントリをフローテーブル７１０に設定する。その後、オープンフロースイッチ７１は、設定されたフローエントリにより、受信パケットと同一のフローに属する後続のパケットを処理する。
【０１５４】
以上のオープンフローの仕組みを用いることにより、第１の実施形態において説明した通信パターン識別部１５０および通信経路制御部１８０の動作を実現することができる。
【０１５５】
本実施形態では、一例として、オープンフロースイッチ７１を用いて通信パターン識別部１５０を実現し、オープンフローコントローラ７０を用いて通信経路制御部１８０を実現する。なお、具体的な実装方法として、いずれもハードウェアで構成されたスイッチおよびコントローラ装置を用いてもよいし、いずれもソフトウェアから成るスイッチおよびコントローラのソフトウェアモジュールを用いてもよい。
【０１５６】
次に、具体的な動作の一例を説明する。オープンフロースイッチにより実現された通信パターン識別部１５０は、第１の実施形態において無線通信端末１００上で動作するアプリケーション１９０〜１９Ｎから発生する通信フローを常時監視する際、オープンフロースイッチ７１を用いて通信フローの発生を監視する。通信パターン識別部１５０は、新たな通信フローが発生した際、オープンフロースイッチ７１が受信したパケットのヘッダに含まれる情報から当該通信フローの送信元ポート番号の情報を取得し、このポート番号を元に第１の実施形態で説明したように通信フローの発生元アプリケーションを特定する。また、通信パターン識別部１５０は、フローテーブル７１０のフローエントリ（図１３）に含まれるパケットフロー毎の統計情報を参照することにより、通信フロー毎の継続時間、通信量の変化等を記録する。
【０１５７】
また、第１の実施形態において、通信経路制御部１８０が通信フローの通信経路を制御する動作（図７のステップＡ９）は、次のように実現することができる。すなわち、オープンフローコントローラ７０により実現された通信経路制御部１８０は、特定のＲＡＴを用いた通信経路、例えば無線ＬＡＮ通信ＩＦ１１０またはセルラ通信ＩＦ１２０を出力先とするようなインストラクションを持つフローエントリをフローテーブル７１０に設定する。これにより、オープンフローコントローラ７０は、通信フロー単位の経路制御をオープンフロースイッチ７１に対して指示する。すると、オープンフロースイッチ７１は、指定された通信経路への振り分け制御を実施する。
【０１５８】
本実施形態に係る無線通信端末１００によると、集中制御型のネットワークアーキテクチャであるオープンフロー（OpenFlow、非特許文献３）に基づいて、第１の実施形態の無線通信端末１００を実現することができる。なお、第２および第３の実施形態に係る無線通信端末１００も、同様に、オープンフローに基づいて実現することができる。
【０１５９】
＜実施形態５＞
次に、第５の実施形態に係る無線通信端末１００について、図面を参照して説明する。本実施形態の無線通信端末１００は、第１の実施形態の無線通信端末１００をAndroid OSやiOSを搭載したスマートフォンに実装したものである。
【０１６０】
図１４は、スマートフォンのソフトウェアプラットフォームの構成を抽象化して示す図である。Android OSのソフトウェアプラットフォーム（非特許文献１）、iOSのソフトウェアプラットフォーム（非特許文献２）を参照してスマートフォンのソフトウェアプラットフォームを抽象化して表すと、図１４に示すように、ハードウェア層、ＯＳカーネル（Operating System Kernel）層、共通ライブラリ層、アプリケーションフレームワーク層、アプリケーション層のように分けられる。
【０１６１】
ハードウェア層は、スマートフォンのハードウェアである。ＯＳカーネル層はＯＳとしての基本機能を提供する。共通ライブラリ層は、上位層で共通的に利用される各種ライブラリ群を提供する層である。アプリケーションフレームワーク層は、下位層の機能を活用して、アプリケーションの開発に必要な機能をアプリケーション層に提供する。アプリケーション層は、アプリケーションフレームワーク層、共通ライブラリ層、ＯＳカーネル層、ハードウェア層を適宜利用して必要な機能を実装してアプリケーションを実現する。
【０１６２】
各層は、ＡＰＩ（Application Programming Interface）と呼ばれるＩＦ（Interface）によって、お互いの層の機能を利用可能となっている。
【０１６３】
図１５は、第１の実施形態に係る無線通信端末１００を抽象化されたソフトウェアプラットフォーム（図１４）に対して実装したときの構成を例示するブロック図である。
【０１６４】
本実施形態の無線通信端末１００における各部の機能、および、処理の流れは、第１の実施形態の無線通信端末１００と同様である。
【０１６５】
図１５を参照すると、第１の実施形態の無線通信端末１００におけるアプリケーション１９０〜１９Ｎはアプリケーション層に配置される。一方、無線ＬＡＮ（Local Area Network）通信ＩＦ１１０、セルラ通信ＩＦ１２０、および、ＵＩ（User Interface）デバイス１３０は、ハードウェア層に配置される。
【０１６６】
また、ユーザ操作モニタ部１４０、通信パターン識別部１５０、および、端末コンテキストモニタ部１６０は、共通ライブラリ層に配置される。
【０１６７】
さらに、ユーザ体感評価部１７０は、アプリケーションフレームワーク層に配置される。
【０１６８】
また、通信経路制御部１８０は、ＯＳカーネル層に配置される。
【０１６９】
各ユニットは自身の機能の一部を、配置された各層が他の層に公開するＡＰＩを通して、他のユニットに利用可能にする。
【０１７０】
ユーザ操作モニタ部１４０は、ハードウェア層およびＯＳカーネル層が提供するＡＰＩを通して、各アプリケーションのＵＩデバイス１３０の利用状況を監視することにより、第１の実施形態で説明した機能を実現する。
【０１７１】
また、通信パターン識別部１５０は、ハードウェア層、ＯＳカーネル層および通信経路制御部１８０の提供するＡＰＩを通して、各アプリケーションの通信フローの識別、情報取得を行うことにより、第１の実施形態で説明した機能を実現する。
【０１７２】
さらに、端末コンテキストモニタ部１６０は、ハードウェア層およびＯＳカーネル層が提供するＡＰＩを通して、無線ＬＡＮ通信ＩＦ１１０およびセルラ通信ＩＦ１２０の各種状態を取得することにより、第１の実施形態で説明した機能を実現する。
【０１７３】
また、ユーザ体感評価部１７０は、ユーザ操作モニタ部１４０、通信パターン識別部１５０、端末コンテキストモニタ部１６０の提供するＡＰＩを通して、それぞれアプリケーションのユーザインタラクションの有無、アプリケーションの通信パターンのカテゴリ分け結果、無線通信端末１００の各ＲＡＴの現在の通信特性情報を取得することにより、第１の実施形態で説明した機能を実現する。
【０１７４】
さらに、通信経路制御部１８０は、ユーザ体感評価部１７０からのＡＰＩを通した通信フローの通信経路制御指示を受け、ＯＳカーネル層およびハードウェア層の提供するＡＰＩを通して、アプリケーションの通信フローの通信経路制御を行う。
【０１７５】
本実施形態に係る無線通信端末１００によると、Android OSやiOSなどのスマートフォンのソフトウェアプラットフォーム上において、第１の実施形態に係る無線通信端末１００を実現することが可能となる。なお、第２および第３の実施形態に係る無線通信端末１００も、同様に、スマートフォンのソフトウェアプラットフォーム上において実現することができる。
【０１７６】
上記第１ないし第５の実施形態に係る無線通信端末１００は、例えば、複数の通信手段を搭載した端末において、通信手段を選択する際に適用することができる。
【０１７７】
なお、本発明において、下記の形態が可能である。
［形態１］
上記第１の態様に係る通信端末のとおりである。
［形態２］
前記通信パターン識別部は、前記アプリケーションが発生させる通信フローの特徴に応じて、前記アプリケーションを複数のカテゴリのいずれかに分類し、分類されたカテゴリに応じて前記アプリケーションが要求する通信特性を判別する、
形態１に記載の通信端末。
［形態３］
前記通信フローの特徴は、前記通信フローの継続時間、通信速度の変化の履歴もしくは総通信量、前記アプリケーションが同時に発生させる通信フローの数もしくは前記アプリケーションが発生させる通信フローの頻度、または、これらの２つ以上の組み合わせである、
形態２に記載の通信端末。
［形態４］
前記端末コンテキストモニタ部は、前記実際の通信特性として、前記複数の通信手段による通信の遅延時間、通信帯域、接続の安定性、および、通信料金のうちの少なくともいずれかを監視する、
形態１ないし３のいずれか一に記載の通信端末。
［形態５］
前記ユーザ体感評価部は、複数のアプリケーションのうちのユーザとのインタラクションが有るアプリケーションに対して通信手段を優先的に割り当てる、
形態１ないし４のいずれか一に記載の通信端末。
［形態６］
前記ユーザ操作モニタ部は、ＵＩ（User Interface）デバイスの利用状況を監視することで、前記アプリケーションと前記ユーザとのインタラクションの有無を判別する、
形態１ないし５のいずれか一に記載の通信端末。
［形態７］
前記ユーザ操作モニタ部および前記通信パターン識別部の替わりに、前記インタラクションの有無および前記アプリケーションが要求する通信特性を保持する第１のデータベースを備え、
前記ユーザ体感評価部は、前記実際の通信特性、ならびに、前記第１のデータベースが保持する前記インタラクションの有無および前記アプリケーションが要求する通信特性に応じて、前記アプリケーションに割り当てる通信手段を前記複数の通信手段の中から選択する、
形態１ないし６のいずれか一に記載の通信端末。
［形態８］
ユーザが通信の遅延時間、通信帯域、接続の安定性、および、通信料金のうちのいずれを重視するかを表す情報を保持する第２のデータベースを備え、
前記ユーザ体感評価部は、前記インタラクションの有無、前記アプリケーションが要求する通信特性、および、前記実際の通信特性、ならびに、前記第２のデータベースが保持する情報に応じて、前記アプリケーションに割り当てる通信手段を前記複数の通信手段の中から選択する、
形態１ないし７のいずれか一に記載の通信端末。
［形態９］
前記ユーザ体感評価部は、ユーザとのインタラクションがないアプリケーションに対して、ユーザとのインタラクションが有るアプリケーションに対して割り当てた通信手段とは異なる通信手段を割り当てる、
形態１ないし８のいずれか一に記載の通信端末。
［形態１０］
前記ＵＩデバイスは、ディスプレイ、キーボード、マウス、タッチパネル、マイク、および、スピーカーの少なくともいずれかである、
形態６に記載の通信端末。
［形態１１］
上記第２の態様に係る通信方法のとおりである。
［形態１２］
前記通信端末が、前記アプリケーションが発生させる通信フローの特徴に応じて、前記アプリケーションを複数のカテゴリのいずれかに分類するステップと、
分類されたカテゴリに応じて前記アプリケーションが要求する通信特性を判別するステップと、を含む、
形態１１に記載の通信方法。
［形態１３］
前記通信フローの特徴は、前記通信フローの継続時間、通信速度の変化の履歴もしくは総通信量、前記アプリケーションが同時に発生させる通信フローの数もしくは前記アプリケーションが発生させる通信フローの頻度、または、これらの２つ以上の組み合わせである、
形態１２に記載の通信方法。
［形態１４］
前記通信端末は、前記実際の通信特性として、前記複数の通信手段による通信の遅延時間、通信帯域、接続の安定性、および、通信料金のうちの少なくともいずれかを監視する、
形態１１ないし１３のいずれか一に記載の通信方法。
［形態１５］
前記通信端末は、複数のアプリケーションのうちのユーザとのインタラクションが有るアプリケーションに対して通信手段を優先的に割り当てる、
形態１１ないし１４のいずれか一に記載の通信方法。
［形態１６］
前記通信端末は、ＵＩ（User Interface）デバイスの利用状況を監視することで、前記アプリケーションと前記ユーザとのインタラクションの有無を判別する、
形態１１ないし１５のいずれか一に記載の通信方法。
［形態１７］
前記通信端末が、ユーザが通信の遅延時間、通信帯域、接続の安定性、および、通信料金のうちのいずれを重視するかを表す情報をデータベースに保持するステップと、
前記インタラクションの有無、前記アプリケーションが要求する通信特性、および、前記実際の通信特性、ならびに、前記データベースが保持する情報を参照して、前記アプリケーションに割り当てる通信手段を前記複数の通信手段の中から選択するステップと、を含む、
形態１１ないし１６のいずれか一に記載の通信方法。
［形態１８］
前記通信端末が、ユーザとのインタラクションがないアプリケーションに対して、ユーザとのインタラクションが有るアプリケーションに対して割り当てた通信手段とは異なる通信手段を割り当てるステップを含む、
形態１１ないし１７のいずれか一に記載の通信方法。
［形態１９］
上記第３の態様に係るプログラムのとおりである。
［形態２０］
前記アプリケーションが発生させる通信フローの特徴に応じて、前記アプリケーションを複数のカテゴリのいずれかに分類する処理と、
分類されたカテゴリに応じて前記アプリケーションが要求する通信特性を判別する処理と、を前記コンピュータに実行させる、
形態１９に記載のプログラム。
［形態２１］
前記通信フローの特徴は、前記通信フローの継続時間、通信速度の変化の履歴もしくは総通信量、前記アプリケーションが同時に発生させる通信フローの数もしくは前記アプリケーションが発生させる通信フローの頻度、または、これらの２つ以上の組み合わせである、
形態２０に記載のプログラム。
［形態２２］
前記実際の通信特性として、前記複数の通信手段による通信の遅延時間、通信帯域、接続の安定性、および、通信料金のうちの少なくともいずれかを監視する処理を、前記コンピュータに実行させる、
形態１９ないし２１のいずれか一に記載のプログラム。
［形態２３］
複数のアプリケーションのうちのユーザとのインタラクションが有るアプリケーションに対して通信手段を優先的に割り当てる処理を、前記コンピュータに実行させる、
形態１９ないし２２のいずれか一に記載のプログラム。
［形態２４］
ＵＩ（User Interface）デバイスの利用状況を監視することで、前記アプリケーションと前記ユーザとのインタラクションの有無を判別する処理を、前記コンピュータに実行させる、
形態１９ないし２３のいずれか一に記載のプログラム。
［形態２５］
ユーザが通信の遅延時間、通信帯域、接続の安定性、および、通信料金のうちのいずれを重視するかを表す情報をデータベースに保持する処理と、
前記インタラクションの有無、前記アプリケーションが要求する通信特性、および、前記実際の通信特性、ならびに、前記データベースが保持する情報を参照して、前記アプリケーションに割り当てる通信手段を前記複数の通信手段の中から選択する処理と、を前記コンピュータに実行させる、
形態１９ないし２４のいずれか一に記載のプログラム。
［形態２６］
ユーザとのインタラクションがないアプリケーションに対して、ユーザとのインタラクションが有るアプリケーションに対して割り当てた通信手段とは異なる通信手段を割り当てる処理を、前記コンピュータに実行させる、
形態１９ないし２５のいずれか一に記載のプログラム。
【０１７８】
なお、上記特許文献および非特許文献の全開示内容は、本書に引用をもって繰り込み記載されているものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。
【符号の説明】
【０１７９】
１０    通信端末
１１、１２    通信手段
１４    ユーザ操作モニタ部
１５    通信パターン識別部
１６    端末コンテキストモニタ部
１７    ユーザ体感評価部
７０    オープンフローコントローラ（ＯＦＣ：OpenFlow Controller）
７１    オープンフロースイッチ（ＯＦＳ：OpenFlow Switch）
７２    セキュアチャネル（Secure Channel）
１００    無線通信端末
１１０    無線ＬＡＮ通信ＩＦ
１２０    セルラ通信ＩＦ
１３０    ＵＩ（User Interface）デバイス
１４０    ユーザ操作モニタ部
１５０    通信パターン識別部
１６０    端末コンテキストモニタ部
１７０    ユーザ体感評価部
１８０    通信経路制御部
１９０〜１９Ｎ    アプリケーション
２００    無線ＬＡＮアクセスポイント
３００    セルラ基地局
４００    サーバ群
７１０    フローテーブル（Flow Table）
１１００    アプリケーション情報データベース
１１１０    ユーザプリファレンス情報データベース
【図１】
0006477040.tif 000002
【図２】
0006477040.tif 000003
【図３】
0006477040.tif 000004
【図４】
0006477040.tif 000005
【図５】
0006477040.tif 000006
【図６】
0006477040.tif 000007
【図７】
0006477040.tif 000008
【図８】
0006477040.tif 000009
【図９】
0006477040.tif 000010
【図１０】
0006477040.tif 000011
【図１１】
0006477040.tif 000012
【図１２】
0006477040.tif 000013
【図１３】
0006477040.tif 000014
【図１４】
0006477040.tif 000015
【図１５】
0006477040.tif 000016