JP7259738B2 - 制御装置、制御システム、制御装置の制御方法及びプログラム - Google Patents

Description

（関連出願についての記載）
本発明は、日本国特許出願：特願２０１７－０４２０３９号（２０１７年３月６日出願）の優先権主張に基づくものであり、同出願の全記載内容は引用をもって本書に組み込み記載されているものとする。
本発明は、制御装置、制御システム、制御装置の制御方法及びプログラムに関する。

アプリケーションロジックを複数の異なる端末に分散して配備し、各端末が、ネットワークを介して相互に接続する、ネットワーク化システムと呼ばれるシステムの構成手法がある。ネットワーク化システムにおいては、各端末に配備された、各アプリケーションロジックは、ネットワークを介して相互に情報を交換することで、相互に連携する。その結果、相互に連携した複数のアプリケーションロジックは、ネットワーク化システム全体において、単一のアプリケーションとしての動作を実現する。

ここで、ネットワーク化システムにおいては、各アプリケーションロジック間において、ネットワークを介して通信が行われるので、ネットワークにおける帯域幅、遅延等のＱｏＳ要件が、アプリケーションのＱｏＥに大きな影響を及ぼす。

そこで、ネットワークを介して通信を行うアプリケーションの体感品質（ＱｏＥ（Quality of Experience））を保証するための要素技術として、ネットワークＱｏＳ（Quality of Service）保証技術がある。ＱｏＳ保証技術を用いることで、各アプリケーションに対して帯域幅、遅延等を保証した回線を提供できる。つまり、ＱｏＳ保証技術を用いることは、アプリケーションのターンアラウンドタイム等の体感品質（ＱｏＥ）を保証するために有効である。

特許文献１において、通信網に接続された端末において実行中のアプリケーションと、網の使用状態とに応じて、通信品質を制御し、アプリケーションのＱｏＥを向上させるシステムが記載されている。特許文献１に記載されたシステムは、アプリケーション毎の通信の優先度に応じて、アプリケーション毎の通信品質を決定することで、ＱｏＥを保証する。

特許文献２においては、動画配信アプリケーションにおいて、端末における動画再生状態に応じたＱｏＳ制御を行うシステムが記載されている。特許文献２に記載されたシステムにおいては、配信サーバが、エミュレータを用いて、端末の動画再生状態を推定し、推定した状態に基づいて、配信サーバと端末間の通信における帯域を制御することで、ＱｏＥを保証する。

特許文献３において、端末の通信ペイロードに含まれる情報に基づいて、ユーザの状態を識別し、識別したユーザの状態に基づいて、通信ペイロードに含まれる情報から、ユーザに提供するネットワークサービスを決定するシステムが開示されている。特許文献３に記載されたシステムは、通信ペイロードに基づいて推定したアプリケーションの現在の状態に対応する、ネットワークＱｏＳ制御を行う。

特開２０１１－１５５６００号公報 特開２０１６―１４３９８０号公報 特表２０１３－５３５０４１号公報

なお、上記先行技術文献の開示を、本書に引用をもって繰り込むものとする。以下の分析は、本発明の観点からなされたものである。

上述の通り、ネットワークのＱｏＳ要件は、アプリケーションのＱｏＥに大きな影響を及ぼす。換言すると、ネットワークのＱｏＳ要件が変化した場合、アプリケーションのＱｏＥも変化する。

ここで、アプリケーションの時系列的な動作状態の変化に応じて、ＱｏＳ要件が動的に変化する場合がある。例えば、ＩｏＴ（Internet of Things）の分野等においては、間欠的なセンサデータの送受信が発生する。また、サーバ／クライアント型の画像認識システムにおいては、転送データのサイズの変動が発生する。しかし、アプリケーションの時系列的な動作状態が変化した場合であっても、アプリケーションのＱｏＥが保証されることが好ましい。

特許文献１に記載されたシステムにおいては、各アプリケーションにおける実行中の動作状態に応じて、アプリケーション毎の通信の優先度を決定し、アプリケーション毎の通信品質を決定する。そのため、特許文献１に記載されたシステムにおいては、アプリケーションの動作状態の遷移に伴い、ＱｏＳを変更する処理を適時に実行できない（処理が間に合わない）状況が発生する。そのため、特許文献１に記載されたシステムにおいては、アプリケーションの動作状態の遷移に伴い、ＱｏＥの劣化が発生する恐れがある。

特許文献２に記載されたシステムにおいては、動画配信等、サーバ側で、クライアント側（端末）の動画再生状態をエミュレート可能であると共に、アプリケーションの動作モードの遷移が確定的に予測可能であるアプリケーションを前提としている。そのため、アプリケーションの動作モードが確率的に遷移するアプリケーションに対して、特許文献２に記載されたシステムを適用できない。例えば、端末側でカメラを用いて画像を撮影し、撮影された画像情報に基づいて、アプリケーションの動作モードを決定する場合、アプリケーションの動作モードは確率的に遷移し、確定的に決定できない。そのため、そのようなアプリケーションに対して、特許文献２に記載されたシステムを適用できない。

特許文献３に記載されたシステムは、アプリケーションが通信を行ったときのペイロード情報に基づいて、アプリケーションの状態推定を行う。そのため、特許文献３に記載されたシステムは、実際にアプリケーションが通信を行うまでは、ユーザが使用する装置はアプリケーションの状態変化を検出できない。その結果、特許文献３に記載されたシステムにおいては、アプリケーションの動作モードが切り替わる際に発生した通信の一部が、ＱｏＳを保証するために利用されない。その結果、特許文献３に記載されたシステムにおいては、アプリケーションの状態変化に応じて、ＱｏＳを変更する場合、実際に行われる通信に対して、ＱｏＳを変更する処理を適時に実行できない（処理が間に合わない）状況が発生する。例えば、間欠的に、少量のデータを送信するアプリケーション等においては、特許文献３に記載されたシステムは、実際に行われる通信に対して、ＱｏＳを変更する処理を適時に実行できない恐れがある。その結果、特許文献３に記載されたシステムにおいては、アプリケーションの状態変化に応じて、ＱｏＳを変更する場合、ＱｏＥの劣化が発生する恐れがある。

そこで、本発明は、アプリケーションの動作状態の遷移に伴い、ＱｏＥが低下することを抑制することに貢献する制御装置、制御システム、制御装置の制御方法及びプログラムを提供することを目的とする。

第１の視点によれば、制御装置が提供される。該制御装置は、２以上の端末から、アプリケーションの動作状況を、第１の動作状況として受信する、第１の動作状況受信部を備える。
さらに、該制御装置は、前記各端末に関して、前記第１の動作状況受信部が受信する前記第１の動作状況に基づいて、端末優先度と、前記第１の動作状況から遷移する第２の動作状況と、を推定する、第２の動作状況推定部を備える。
さらに、前記端末優先度と、前記第２の動作状況とに基づいて、動作状況が変化する前に、動作状況が変化したと見做して制御する端末を、制御対象端末として特定する、見做し判断部を備える。
さらに、前記制御対象端末の動作状況が変化する前に、該制御対象端末の動作状況が、前記第２の動作状況推定部が推定した前記第２の動作状況に変化したと見做して、所定の処理を実行する、見做し制御部を備える。

第２の視点によれば、制御システムが提供される。該制御システムは、２以上の端末と、ネットワークを介して、前記端末と接続する制御装置と、を含んで構成される。
前記端末は、アプリケーションの動作状況を、前記制御装置に送信する、第１の動作状況送信部を備える。
前記制御装置は、前記各端末から、アプリケーションの動作状況を、第１の動作状況として受信する、第１の動作状況受信部を備える。
さらに、前記制御装置は、前記各端末に関して、前記第１の動作状況受信部が受信する前記第１の動作状況に基づいて、端末優先度と、前記第１の動作状況から遷移する第２の動作状況と、を推定する、第２の動作状況推定部を備える。
さらに、前記制御装置は、前記端末優先度と、前記第２の動作状況とに基づいて、動作状況が変化する前に、動作状況が変化したと見做して制御する端末を、制御対象端末として特定する、見做し判断部を備える。
さらに、前記制御装置は、前記制御対象端末の動作状況が変化する前に、該制御対象端末の動作状況が、前記第２の動作状況推定部が推定した前記第２の動作状況に変化したと見做して、所定の処理を実行する、見做し制御部を備える。

第３の視点によれば、制御装置の制御方法が提供される。該制御方法は、前記端末から、アプリケーションの動作状況を、第１の動作状況として受信する工程を含む。
さらに、該制御方法は、前記各端末に関して、受信された前記第１の動作状況に基づいて、端末優先度と、前記第１の動作状況から遷移する第２の動作状況と、を推定する工程を含む。
さらに、該制御方法は、前記端末優先度と、前記第２の動作状況とに基づいて、動作状況が変化する前に、動作状況が変化したと見做して制御する端末を、制御対象端末として特定する工程を含む。
さらに、該制御方法は、前記制御対象端末の動作状況が変化する前に、該制御対象端末の動作状況が、推定された前記第２の動作状況に変化したと見做して、所定の処理を実行する工程を含む。
なお、本方法は、ネットワークを介して２以上の端末と通信制御装置という、特定の機械に結び付けられている。

第４の視点によれば、プログラムが提供される。該プログラムは、ネットワークを介して２以上の端末と通信する制御装置を制御するコンピュータに実行させる。
該プログラムは、前記端末から、アプリケーションの動作状況を、第１の動作状況として受信する処理を、前記コンピュータに実行させる。
さらに、該プログラムは、前記各端末に関して、受信された前記第１の動作状況に基づいて、端末優先度と、前記第１の動作状況から遷移する第２の動作状況と、を推定する処理を、前記コンピュータに実行させる。
さらに、該プログラムは、前記端末優先度と、前記第２の動作状況とに基づいて、動作状況が変化する前に、動作状況が変化したと見做して制御する端末を、制御対象端末として特定する処理を、前記コンピュータに実行させる。
さらに、該プログラムは、前記制御対象端末の動作状況が変化する前に、該制御対象端末の動作状況が、推定された前記第２の動作状況に変化したと見做して、所定の処理を実行する処理を、前記プログラムに実行させる。
なお、本プログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transient）なものとすることができる。本発明は、コンピュータプログラム製品として具現することも可能である。

各視点によれば、アプリケーションの動作状態の遷移に伴い、ＱｏＥが低下することを抑制することに貢献する制御装置、制御システム、制御装置の制御方法及びプログラムが提供される。

一実施形態の概要を説明するための図である。 ネットワーク化システムの全体構成の一例を示す図である。 第１の実施形態に係る端末１０３の内部構成の一例を示すブロック図である。 第１の実施形態に係るＱｏＥ保証装置１０１の内部構成の一例を示すブロック図である。 モード遷移確率ＤＢ３０５の一例を示す図である。 モードＤＢ３０６の一例を示す図である。 インフラリソースＤＢ３０７の一例を示す図である。 モード要件ＤＢ３０８の一例を示す図である。 第１の実施形態に係る端末１０３の動作の一例を示すフローチャートである。 第１の実施形態に係るＱｏＥ保証装置１０１の動作の一例を示すフローチャートである。 第１の実施形態に係るＱｏＥ保証装置１０１の動作の一例を示すフローチャートである。 第１の実施形態に係るＱｏＥ保証装置１０１の動作の一例を示すフローチャートである。 第１の実施形態に係るＱｏＥ保証装置１０１の動作の一例を示すフローチャートである。 第２の実施形態に係る端末１３０１の内部構成の一例を示すブロック図である。 第２の実施形態に係るＱｏＥ保証装置１４０１の内部構成の一例を示すブロック図である。 モード履歴ＤＢ１４１１の一例を示すブロック図である。 第２の実施形態に係る端末１３０１の動作の一例を示すフローチャートである。 第２の実施形態に係るＱｏＥ保証装置１４０１の動作の一例を示すフローチャートである。 第３の実施形態に係る端末１８０１の内部構成の一例を示すブロック図である。 第３の実施形態に係るＱｏＥ保証装置１９０１の内部構成の一例を示すブロック図である。 第３の実施形態に係る端末１８０１の動作の一例を示すフローチャートである。 第３の実施形態に係るＱｏＥ保証装置１９０１の動作の一例を示すフローチャートである。

初めに、図１を用いて一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、各ブロック図のブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。

上述の通り、アプリケーションの動作状態の遷移に伴い、ＱｏＥが低下することを抑制することに貢献する制御装置が望まれる。

そこで、一例として、図１に示す制御装置１を提供する。制御装置１は、第１の動作状況受信部１１と、第２の動作状況推定部１２と、見做し判断部１３と、見做し制御部１４とを備える。

第１の動作状況受信部１１は、２以上の端末から、アプリケーションの動作状況を、第１の動作状況として受信する。ここで、アプリケーションとは、アプリケーションソフトウェアである。そして、各端末は、アプリケーションを実行することで、処理を実行しているものとする。

第２の動作状況推定部１２は、各端末に関して、第１の動作状況受信部１１が受信する第１の動作状況に基づいて、端末優先度と、第１の動作状況から遷移する第２の動作状況と、を推定する。ここで、端末の優先度とは、端末上で動作する、アプリケーションの動作状況が変化する前に、動作状況が変化したと見做して制御する、端末の優先度を意味する。

見做し判断部１３は、端末優先度と、第２の動作状況とに基づいて、動作状況が変化する前に、動作状況が変化したと見做して制御する端末を、制御対象端末として特定する。

見做し制御部１４は、制御対象端末の動作状況が変化する前に、該制御対象端末の動作状況が、第２の動作状況推定部１２が推定した第２の動作状況に変化したと見做して、所定の処理を実行する。ここで、所定の処理とは、ＱｏＥを保証するための処理を含むものとする。

従って、制御装置１は、端末の動作状況が変化する前に、動作状況が変化したと見做して所定の処理を実行することで、アプリケーションの動作状態の遷移に伴い、ＱｏＥが低下することを抑制することに貢献する。

［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。以下の説明においては、上記の制御装置を、ＱｏＥ保証装置とも呼ぶ。また、以下の説明においては、上記の第１の動作状況に対応する動作モードを、現在モードとも呼ぶ。また、以下の説明においては、上記の第２の動作状況に対応する動作モードを、見做しモードとも呼ぶ。また、以下の説明においては、動作モードを識別する情報を、動作モードＩＤと呼ぶ。また、以下の説明においては、動作モードＩＤ（Identifier）のうち、特に、現在モードを識別する情報、見做しモードを識別する情報を、夫々、現在モードＩＤ、見做しモードＩＤと呼ぶ。

また、以下の説明においては、上記の第１の動作状況受信部、第２の動作状況推定部、見做し制御部を、夫々、モード情報受信部、優先度算出部、制御情報送信部と呼ぶ。

図２は、本実施形態に係るネットワーク化システムの全体構成の一例を示すブロック図である。本実施形態に係るネットワーク化システムは、ＱｏＥ保証装置１０１と、１又は２以上の端末（１０３ａ～１０３ｃ）と、インフラ制御装置１０４と、コンピューティングインフラ１０５と、を含んで構成される。そして、端末（１０３ａ～１０３ｃ）は、ネットワークインフラ１０２及びインフラ制御装置１０４を介して、ＱｏＥ保証装置１０１、及びコンピューティングインフラ１０５と接続する。なお、以下の説明では、端末（１０３ａ～１０３ｃ）は、夫々、区別する必要が無い場合には、端末１０３と表記する。また、図２は、３つの端末（１０３ａ～１０３ｃ）を示すが、これは、端末１０３の数を３つに限定する趣旨ではない。本実施形態に係るネットワーク化システムは、１又は２、又は４以上の端末１０３を含んで構成されても良い。また、以下の説明においては、ネットワークインフラ１０２及びコンピューティングインフラ１０５を、単に「インフラ」とも呼ぶ。

ＱｏＥ保証装置１０１は、ネットワーク化システムにおいて実行されるアプリケーションにおける、ＱｏＥを保証するための処理を実行、制御する装置（コンピュータ）である。ＱｏＥ保証装置１０１は、ＣＰＵ（Central Processing Unit）、メモリ、通信手段等を含んで構成される。ＱｏＥ保証装置１０１の詳細は後述する。

端末１０３は、ユーザが使用する装置（コンピュータ）である。端末１０３は、ＣＰＵ、メモリ、通信手段等を含んで構成される。また、端末１０３は、１又は２以上のアプリケーションソフトウェア（図２に示すクライアントサイドアプリケーション１０７ａ～１０７ｃ）を備え、該アプリケーションソフトウェアを実行する。端末１０３の詳細は後述する。なお、以下の説明では、クライアントサイドアプリケーション１０７ａ～１０７ｃは、夫々、区別する必要が無い場合には、クライアントサイドアプリケーション１０７と表記する。

ネットワークインフラ１０２は、ネットワーク機能を実行、及び制御する、１又は２以上のネットワーク機器（ルータ、ゲートウェイ、ファイアウォール、ロードバランサ等）を含んで構成される。

コンピューティングインフラ１０５は、端末１０３に対してアプリケーションを提供するサーバとして機能する、１又は２以上の装置（コンピュータ）を含んで構成される。コンピューティングインフラ１０５を構成する各装置は、ＣＰＵ、メモリ、通信手段等を含んで構成される。また、コンピューティングインフラ１０５を構成する各装置は、１又は２以上のアプリケーションソフトウェア（図２に示すサーバサイドアプリケーション１０６）を備え、該アプリケーションソフトウェアを実行する。

インフラ制御装置１０４は、コンピューティングインフラ１０５及びＱｏＥ保証装置１０１と、ネットワークインフラ１０２間の処理を中継、制御する装置（コンピュータ）である。インフラ制御装置１０４は、ＣＰＵ、メモリ、通信手段等を含んで構成される。

サーバサイドアプリケーション１０６及びクライアントサイドアプリケーション１０７は、複数（２以上）の動作モードを含んで構成されるものとする。サーバサイドアプリケーション１０６及びクライアントサイドアプリケーション１０７は、動作モードに基づいて、実行する処理を決定するものとする。なお、以下の説明においては、「動作モードを変更する」ことを、「動作モードを遷移する」と表現する。

また、各動作モードは、他の動作モードに対して、独立していても良い。さらに、サーバサイドアプリケーション１０６及びクライアントサイドアプリケーション１０７は、確率的に、動作モードを遷移するものとする。即ち、コンピューティングインフラ１０５及び端末１０３は、動作モードの状態遷移確率を推定可能であるものとする。

次に、端末１０３の内部構成について詳細に説明する。

図３は、本実施形態に係る端末１０３の内部構成の一例を示すブロック図である。端末１０３は、アプリケーション部２０１と、モード情報送信部（第１の動作状況送信部とも呼ぶ）２０２と、を含んで構成される。なお、図３は、本実施形態に係る端末１０３に関係するモジュールを示す。端末１０３は、図示しないモジュールを含んでも良いことは勿論である。

例えば、端末１０３が備える記憶装置（図示せず）が、クライアントサイドアプリケーション１０７を記憶しても良い。記憶装置は、磁気ディスク装置や光ディスク装置、半導体メモリによって実現される。

端末１０３は、ＣＰＵを用いて、アプリケーション部２０１、モード情報送信部２０２を実現しても良い。さらに、例えば、端末１０３は、ＮＩＣ（Network Interface Card）を用いて、他の装置（ＱｏＥ保証装置１０１、ネットワークインフラ１０２、コンピューティングインフラ１０５）とのデータ（情報）の送受信を実現しても良い。

アプリケーション部２０１は、端末１０３上で動作するアプリケーションソフトウェア（クライアントサイドアプリケーション１０７）を実行、制御する。具体的には、アプリケーション部２０１は、端末１０３が備える記憶装置（図示せず）から、クライアントサイドアプリケーション１０７を呼び出し、該クライアントサイドアプリケーション１０７を実行、制御する。

また、アプリケーション部２０１は、ネットワークインフラ１０２を介して、サーバが実行するアプリケーション（サーバサイドアプリケーション１０６）と、データの送受信（情報交換）を行う。

なお、以下の説明においては、端末１０３上で実行されているアプリケーションソフトウェア（クライアントサイドアプリケーション１０７）の動作モードを、「アプリケーション部２０１の動作モード」と表現する。つまり、アプリケーション部２０１の実行中の動作モードは、上記の現在モードに相当する。

モード情報送信部２０２は、アプリケーション部２０１の動作状況を、第１の動作状況として、ＱｏＥ保証装置１０１に通知する。ここで、動作状況とは、アプリケーションの複数の離散的な動作モードを含むものとする。

そして、第１の動作状況とは、アプリケーションにおいて実行中の動作モード（現在モード）と、動作モード間の状態遷移確率とを含むものとする。

つまり、モード情報送信部２０２は、現在モード、及び動作モード間の状態遷移確率を、第１の動作状況として、ＱｏＥ保証装置１０１に通知する。具体的には、モード情報送信部２０２は、現在モード、及び動作モード間の状態遷移確率を収集する。そして、モード情報送信部２０２は、ネットワークインフラ１０２を介して、ＱｏＥ保証装置１０１に対して、収集した動作モード、及び動作モード間の状態遷移確率を通知する。

次に、ＱｏＥ保証装置１０１の内部構成について詳細に説明する。

図４は、本実施形態に係るＱｏＥ保証装置１０１の内部構成の一例を示すブロック図である。ＱｏＥ保証装置１０１は、モード情報受信部（第１の動作状況受信部）３０１と、優先度算出部（第２の動作状況推定部）３０２と、見做し判断部３０３と、制御情報送信部（見做し制御部）３０４と、を含んで構成される。さらに、ＱｏＥ保証装置１０１は、モード遷移確率ＤＢ（Database）（動作モード遷移確率データベースとも呼ぶ）３０５と、モードＤＢ（動作モードデータベースとも呼ぶ）３０６と、インフラリソースＤＢ（インフラリソースデータベースとも呼ぶ）３０７と、モード要件ＤＢ（動作モード要件データベースとも呼ぶ）３０８と、を含んで構成される。

例えば、ＱｏＥ保証装置１０１が備える記憶装置（図示せず）が、モード遷移確率ＤＢ３０５と、モードＤＢ３０６と、インフラリソースＤＢ３０７と、モード要件ＤＢ３０８とを格納しても良い。記憶装置は、磁気ディスク装置や光ディスク装置、半導体メモリによって実現される。

また、ＱｏＥ保証装置１０１は、ＣＰＵを用いて、モード情報受信部３０１、優先度算出部３０２、見做し判断部３０３、制御情報送信部３０４を実現しても良い。さらに、例えば、ＱｏＥ保証装置１０１は、ＮＩＣを用いて、他の装置（端末１０３、インフラ制御装置１０４等）とのデータ（情報）の送受信を実現しても良い。

モード遷移確率ＤＢ３０５は、端末１０３を識別する情報と、動作モードを識別する情報と、該動作モードに遷移する状態遷移確率と、を対応付けて格納する。換言すると、モード遷移確率ＤＢ３０５は、端末１０３毎に、アプリケーション部２０１の可能な動作モード、及び当該各動作モードへ遷移する確率（状態遷移確率）とを対応付けて格納する。

図５は、モード遷移確率ＤＢ３０５の一例を示す図である。具体的には、図５は、端末ＩＤ４０１と、遷移先モードＩＤ４０２と、状態遷移確率４０３とを対応付けたテーブルを示す。端末ＩＤ４０１は、端末１０３を識別する情報である。遷移先モードＩＤ４０２は、アプリケーション部２０１の可能な動作モードを識別する情報である。状態遷移確率４０３は、端末ＩＤ４０１に対応する端末１０３において、アプリケーション部２０１の動作モードが、遷移先モードＩＤ４０２に対応する動作モードになる（動作モードに遷移する）確率を示す。ここで、図５に示すモード遷移確率ＤＢ３０５は、端末ＩＤ４０１と、遷移先モードＩＤ４０２と、状態遷移確率４０３とを対応付けたエントリ４１１～４１６を示す。

例えば、図５に示すエントリ４１１は、端末ＩＤが「１」である端末１０３において、遷移先モードＩＤが「１」の動作モードに遷移する確率が、「０．２」であることを示す。

モードＤＢ３０６は、端末１０３を識別する情報と、第１の動作状況の動作モード（現在モード）と、第２の動作状況の動作モード（見做しモード）と、端末優先度と、該端末が制御対象端末であるか否かを示す情報（以下、見做しフラグと呼ぶ）と、を対応付けて格納する。上記の通り、端末優先度とは、動作状況が変化する前に、動作状況が変化したと見做して制御する、端末１０３の優先度である。端末優先度の高い端末１０３ほど、優先して制御対象端末として選択されることが好ましいことを示す。以下の説明では、制御対象端末であることを示す見做しフラグの値を、「Ｙ」と表記する。一方、以下の説明では、制御対象端末ではないことを示す見做しフラグの値を、「Ｎ」と表記する。

図６は、モードＤＢ３０６の一例を示す図である。具体的には、図６は、端末ＩＤ５０１と、現在モードＩＤ５０２と、見做しモードＩＤ５０３と、端末優先度５０４と、見做しフラグ５０５とを対応付けたテーブルを示す。ここで、図６に示すモードＤＢ３０６は、端末ＩＤ５０１と、現在モードＩＤ５０２と、見做しモードＩＤ５０３と、端末優先度５０４と、見做しフラグ５０５とを対応付けたエントリ５１１、５１２を含む。

例えば、図６に示すエントリ５１１は、端末ＩＤが「１」である端末１０３に関して、現在モードＩＤが「１」の動作モードで動作しており、当該動作モードから遷移する動作モードが、見做しモードＩＤが「２」の動作モードであることを示す。さらに、図６に示すエントリ５１１は、端末ＩＤが「１」である端末１０３に関して、動作状況が変化する前に、動作状況が変化したと見做して制御する、端末１０３の優先度（端末優先度）が「０．７」であることを示す。さらに、図６に示すエントリ５１１は、端末ＩＤが「１」である端末１０３が、制御対象端末ではないことを示す。

インフラリソースＤＢ３０７は、ネットワークインフラ１０２、及び／又はコンピューティングインフラ１０５のリソースに関する情報を格納する。「及び／又は」とは、少なくともいずれかを含むことを意味する。具体的には、インフラリソースＤＢ３０７は、ネットワークインフラ１０２、及び／又はコンピューティングインフラ１０５毎に、リソース総量と、リソース使用量（またはリソース残量）を対応付けて格納する。

図７は、インフラリソースＤＢ３０７の一例を示す図である。具体的には、図７は、リソースＩＤ６０１と、リソース総量６０２と、リソース使用量６０３とを対応付けたテーブルを示す。ここで、リソースＩＤとは、リソースを識別する情報である。そして、図７に示すインフラリソースＤＢ３０７は、リソースＩＤ６０１と、リソース総量６０２と、リソース使用量６０３とを対応付けたエントリ６１１、６１２を含む。なお、リソース使用量６０３の単位は、対応するリソースの種類に応じて異なることは勿論である。

例えば、図７に示すエントリ６１１は、リソースＩＤ６０１が「１」であるリソースに関して、リソース総量が「１３０」であり、リソース使用量が「３５」であることを示す。

モード要件ＤＢ３０８は、アプリケーション部２０１の動作モードに関して、当該動作モードを実行するために必要な要件に関する情報を格納する。具体的には、モード要件ＤＢ３０８は、動作モードを識別する情報（動作モードＩＤ）と、リソースを識別する情報（リソースＩＤ）と、該動作モードを実行するために必要な該リソースの量と、を対応付けて格納する。以下の説明では、動作モードを実行するために必要な該リソースの量を、要求リソース量と呼ぶ。

図８は、モード要件ＤＢ３０８の一例を示す図である。具体的には、図８は、動作モードＩＤ７０１と、リソースＩＤ７０２と、要求リソース量７０３とを対応付けたテーブルを示す。そして、図８に示すモード要件ＤＢ３０８は、動作モードＩＤ７０１と、リソースＩＤ７０２と、要求リソース量７０３とを対応付けたエントリ７１１～７１６を含む。なお、要求リソース量７０３の単位は、対応するリソースの種類に応じて異なることは勿論である。

例えば、図８に示すエントリ７１１は、動作モードＩＤが「１」である動作モードにおいて、リソースＩＤが「１」であるリソースに関して、「１０」の量のリソースを必要とする（要求する）ことを示す。さらに、図８に示すエントリ７１２は、動作モードＩＤが「１」である動作モードに関して、リソースＩＤが「２」であるリソースに関して、「２０」の量のリソースを必要とすることを示す。

モード情報受信部３０１は、１又は２以上の端末１０３から、アプリケーションの動作状況を、第１の動作状況として受信する。具体的には、モード情報受信部３０１は、１又は２以上の端末１０３から、第１の動作状況として、現在モード、及び動作モード間の状態遷移確率を受信する。そして、モード情報受信部３０１は、受信した現在モード及び状態遷移確率を、モード遷移確率ＤＢ３０５及びモードＤＢ３０６に格納する。そして、モード情報受信部３０１は、現在モード及び状態遷移確率を受信したことを、優先度算出部３０２に対して通知する。

優先度算出部３０２は、各端末１０３に関して、モード情報受信部３０１が受信する第１の動作状況に基づいて、端末優先度と、第１の動作状況から遷移する第２の動作状況と、を推定する。具体的には、優先度算出部３０２は、モード情報受信部３０１が受信する動作モード間の状態遷移確率に基づいて、端末優先度と、第２の動作状況とを推定する。

ここで、第２の動作状況とは、アプリケーション部２０１において、現在モードから遷移する動作モードを含む。上記の通り、第２の動作状況に対応する動作モードを、見做しモードと呼ぶ。そのため、優先度算出部３０２は、各端末１０３に関して、現在モード、及び動作モード間の状態遷移確率に基づいて、端末優先度と、見做しモードを推定する。

より具体的には、優先度算出部３０２は、モード遷移確率ＤＢ３０５及びモードＤＢ３０６を参照し、モード情報受信部３０１が受信する現在モード、及び動作モード間の状態遷移確率に基づいて、端末優先度及び見做しモードを推定（計算）する。そして、優先度算出部３０２は、推定（計算）した端末優先度、及び見做しモードを識別する情報（見做しモードＩＤ）を、モード遷移確率ＤＢ３０５及びモードＤＢ３０６に格納する。つまり、優先度算出部３０２は、モード遷移確率ＤＢ３０５及びモードＤＢ３０６に格納される、端末優先度及び見做しモードＩＤを更新する。そして、優先度算出部３０２は、モード遷移確率ＤＢ３０５及びモードＤＢ３０６を更新したことを、見做し判断部３０３に通知する。

見做し判断部３０３は、端末優先度と、第２の動作状況とに基づいて、動作状況が変化する前に、動作状況が変化したと見做して制御する端末を、制御対象端末として特定する。具体的には、見做し判断部３０３は、端末優先度と、見做しモードとに基づいて、動作状況が変化する前に、動作状況が変化したと見做して制御する端末を、制御対象端末として特定する。

より具体的には、見做し判断部３０３は、モードＤＢ３０６と、インフラリソースＤＢ３０７と、モード要件ＤＢ３０８とを参照する。そして、見做し判断部３０３は、端末優先度と見做しモードとに基づいて、各端末１０３に関して、動作状況が変化する前に、動作状況が変化したと見做して制御するか否かを判断する。

そして、見做し判断部３０３は、動作状況が変化する前に、動作状況が変化したと見做して制御する端末１０３（制御対象端末）であるか否かを示すフラグ（見做しフラグ）を、モードＤＢ３０６に登録する。つまり、見做し判断部３０３は、モードＤＢ３０６内の見做しフラグを更新する。そして、見做し判断部３０３は、モードＤＢ内の見做しフラグを更新したことを、制御情報送信部３０４に通知する。

制御情報送信部３０４は、制御対象端末の動作状況が変化する前に、該制御対象端末の動作状況が、優先度算出部３０２が推定した第２の動作状況に変化したと見做して、所定の処理を実行する。具体的には、制御情報送信部３０４は、制御対象端末の動作状況が変化する前に、該制御対象端末の動作モードが、対制御対象端末に対応する見做しモードに変化したと見做して、所定の処理を実行する。

より具体的には、制御情報送信部３０４は、モードＤＢ３０６及びモード要件ＤＢ３０８を参照し、ネットワークインフラ１０２、及び／又はコンピューティングインフラ１０５を制御するためのパラメータを計算する。そして、制御情報送信部３０４は、ネットワークインフラ１０２、及び／又はコンピューティングインフラ１０５に対して、計算したパラメータ及びパラメータの更新指示を、制御情報として送信する。

次に、本実施形態に係るネットワーク化システムの動作に関して説明する。

まず、図９を参照しながら、端末１０３の動作について説明する。図９は、端末１０３の動作の一例を示すフローチャートである。

モード情報送信部２０２は、アプリケーションの動作状況を観測し、アプリケーションの現在モード、及び動作モード間の状態遷移確率を、ＱｏＥ保証装置１０１に対して送信する（ステップＳ８０１）。具体的には、モード情報送信部２０２は、アプリケーション部２０１において実行中の動作モードを、現在モードとして取得する。そして、モード情報送信部２０２は、取得した現在モードを識別する情報（現在モードＩＤ）、及び動作モード間の状態遷移確率を、ネットワークインフラ１０２を介して、ＱｏＥ保証装置１０１に対して送信する。

次に、図１０～図１３を参照しながら、ＱｏＥ保証装置１０１の動作について説明する。

なお、以下の説明においては、モード遷移確率ＤＢ３０５は、端末ＩＤと、遷移先モードＩＤと、状態遷移確率とを対応付けた、１又は２以上のエントリを格納するものとする。また、以下の説明においては、モードＤＢ３０６は、端末ＩＤと、現在モードＩＤと、見做しモードＩＤと、端末優先度と、見做しフラグとを対応付けた、１又は２以上のエントリを格納するものとする。また、以下の説明においては、インフラリソースＤＢ３０７は、リソースＩＤと、リソース総量と、リソース使用量とを対応付けた、１又は２以上のエントリを格納するものとする。また、以下の説明においては、モード要件ＤＢ３０８は、動作モードＩＤと、リソースＩＤと、要求リソース量とを対応付けた、１又は２以上のエントリを格納するものとする。

図１０は、ＱｏＥ保証装置１０１の動作の一例を示すフローチャートである。

ステップＳ９０１において、モード情報受信部３０１は、各端末１３０から受信した情報を、モード遷移確率ＤＢ３０５及びモードＤＢ３０６に格納し、情報を受信したことを優先度算出部３０２に通知する。具体的には、モード情報受信部３０１は、端末１０３において実行されるアプリケーションの現在モードを識別する情報（現在モードＩＤ）、及び動作モード間の状態遷移確率を、該端末１０３から受信する。そして、モード情報受信部３０１は、動作モード間の状態遷移確率を、モード遷移確率ＤＢ３０５に登録（又は更新）する。さらに、モード情報受信部３０１は、受信した現在モードＩＤを、モードＤＢ３０６に登録（又は更新）する。そして、モード情報受信部３０１は、現在モードＩＤ、動作モード間の状態遷移確率を受信したことを、優先度算出部３０２に通知する。

ステップＳ９０２において、優先度算出部３０２は、モード遷移確率ＤＢ３０５及びモードＤＢ３０６を参照し、端末優先度及び見做しモードＩＤを計算し、モードＤＢ３０６更新する。優先度算出部３０２の動作の詳細は、図１１を参照しながら後述する。

ステップＳ９０３において、見做し判断部３０３は、モードＤＢ３０６、インフラリソースＤＢ３０７、モード要件ＤＢ３０８を参照し、どの端末１０３を制御対象端末として見做すかを決定し、モードＤＢ３０６を更新する。見做し判断部３０３の動作の詳細は、図１２を参照しながら後述する。

ステップＳ９０４において、制御情報送信部３０４は、ＱｏＥを満たすために必要な処理を行うように、ネットワークインフラ１０２、及び／又はコンピューティングインフラ１０５を制御する。制御情報送信部３０４の動作の詳細は、図１３を参照しながら後述する。

次に、図１１を参照しながら、優先度算出部３０２の動作の詳細について説明する。図１１は、優先度算出部３０２の動作の一例を示すフローチャートである。

ステップ１００１において、優先度算出部３０２は、モードＤＢ３０６内に格納される全てのエントリに対して、「未処理」を示すフラグを設定する。具体的には、モードＤＢ３０６内に格納される全てのエントリを抽出する。そして、優先度算出部３０２は、抽出した全てのエントリに対して、「未処理」を示すフラグを設定する。なお、上述の通り、モードＤＢ３０６内に格納されるエントリとは、端末ＩＤと、現在モードＩＤと、見做しモードＩＤと、端末優先度と、見做しフラグとを対応付けた情報である。

ステップＳ１００２において、モードＤＢ３０６内のエントリのうち、未処理のエントリが存在するか否かを、優先度算出部３０２は判断する。つまり、モードＤＢ３０６内のエントリのうち、「未処理」のフラグが設定されたエントリが存在するか否かを、優先度算出部３０２は判断する。モードＤＢ３０６内のエントリのうち、未処理のエントリが存在する場合（ステップＳ１００２のＹｅｓ分岐）には、ステップＳ１００３に遷移する。一方、モードＤＢ３０６内のエントリのうち、未処理のエントリが存在しない場合（ステップＳ１００２のＮｏ分岐）には、優先度算出部３０２は、モードＤＢ３０６内のエントリを完了したと判断して、処理を終了する。そして、図１０に示すステップＳ９０３に遷移する。

ステップＳ１００３において、優先度算出部３０２は、モードＤＢ３０６から、未処理の一のエントリを選択し、選択したエントリの端末ＩＤに対応する、１又は２以上のエントリを、モード遷移確率ＤＢ３０５から抽出する。

例えば、優先度算出部３０２は、未処理のエントリとして、図６に示すエントリ５１１を、モードＤＢ３０６から抽出したとする。ここで、図６に示すエントリ５１１の端末ＩＤは、「１」である。そのため、優先度算出部３０２は、図５に示すモード遷移確率ＤＢ３０５から、端末ＩＤが「１」であるエントリを抽出する。具体的には、優先度算出部３０２は、図５に示すモード遷移確率ＤＢ３０５から、エントリ４１１～４１３を抽出する。

ステップＳ１００４において、優先度算出部３０２は、モード遷移確率ＤＢ３０５から抽出したエントリのうち、遷移先モードＩＤが、現在モードＩＤと異なる、１又は２以上のエントリを選択する。

例えば、ステップＳ１００３の処理において、優先度算出部３０２は、モードＤＢ３０６から、図６に示すエントリ５１１を抽出したとする。さらに、ステップＳ１００３の処理において、図５に示すモード遷移確率ＤＢ３０５から、エントリ４１１～４１３を抽出したとする。その場合、図６に示すエントリ５１１において、現在モードＩＤは、「１」である。そのため、ステップＳ１００４の処理において、優先度算出部３０２は、図５に示すモード遷移確率ＤＢ３０５から抽出した、エントリ４１１～４１３のうち、遷移先モードＩＤが、「１」以外のエントリを選択する。つまり、ステップＳ１００４の処理において、優先度算出部３０２は、図５に示すエントリ４１２、４１３を選択する。

ステップＳ１００５において、優先度算出部３０２は、選択したエントリから、状態遷移確率に基づいて、見做しモードＩＤを決定し、モードＤＢ３０６を更新する。例えば、優先度算出部３０２は、選択したエントリのうち、対応する状態遷移確率が最大の遷移先モードＩＤを、見做しモードＩＤとして決定してもよい。そして、優先度算出部３０２は、決定した見做しモードＩＤを、モードＤＢ３０６に登録する。なお、状態遷移確率が最大の遷移先モードＩＤを、見做しモードＩＤとして決定することは、見做しモードＩＤを決定する方法の一例であり、見做しモードＩＤを決定する方法を当該方法に限定する趣旨ではない。

例えば、ステップＳ１００４の処理において、図５に示すエントリ４１２、４１３を選択したとする。その場合、図５に示すエントリ４１２、４１３の状態遷移確率は、夫々、「０．７」、「０．１」である。ここで、優先度算出部３０２は、状態遷移確率が最大の遷移先モードＩＤを、見做しモードＩＤとして決定するとする。その場合、ステップＳ１００５の処理において、優先度算出部３０２は、エントリ４１２の遷移先モードＩＤ「２」を、見做しモードＩＤとして決定する。そして、図６に示すように、優先度算出部３０２は、決定した見做しモードＩＤ「２」を、エントリ５１１の見做しモードＩＤとして登録する。

ステップＳ１００６において、優先度算出部３０２は、見做しモードＩＤに対応する端末優先度を決定し、モードＤＢ３０６を更新する。例えば、優先度算出部３０２は、見做しモードＩＤの決定基準である状態遷移確率を、端末優先度として決定しても良い。なお、これは、端末優先度を決定する方法の一例であり、端末優先度を決定する方法を当該方法に限定する趣旨ではない。

例えば、ステップＳ１００５の処理において、優先度算出部３０２は、図５に示すエントリ４１２の遷移先モードＩＤ「２」を、見做しモードＩＤとして決定する。そして、優先度算出部３０２は、見做しモードＩＤの決定基準である状態遷移確率を、端末優先度として決定するとする。その場合、ステップＳ１００６の処理において、優先度算出部３０２は、図５に示すエントリ４１２の状態遷移確率「０．７」を、端末優先度として決定する。そして、優先度算出部３０２は、図６に示すように、エントリ５１１の端末優先度として、「０．７」を登録する。

そして、ステップＳ１００２に戻り、処理を継続する。つまり、モードＤＢ３０６内の全てのエントリに対して、処理済みのフラグを設定するまで、処理を継続する。優先度算出部３０２は、上記の処理（図１１に示す処理）を実行することで、モードＤＢ３０６に格納される、見做しモードＩＤ及び端末優先度を更新する。

次に、図１２を参照しながら、見做し判断部３０３の動作の詳細について説明する。図１２は、見做し判断部３０３の動作の一例を示すフローチャートである。

ステップＳ１１０１において、見做し判断部３０３は、モードＤＢ３０６内に格納される全てのエントリに対して、「未処理」を示すフラグを設定する。具体的には、モードＤＢ３０６内に格納される全てのエントリを抽出する。そして、優先度算出部３０２は、抽出した全てのエントリに対して、「未処理」を示すフラグを設定する。

ステップＳ１１０２において、モードＤＢ３０６内のエントリのうち、未処理のエントリが存在するか否かを、見做し判断部３０３は判断する。つまり、モードＤＢ３０６内のエントリのうち、「未処理」のフラグが設定されたエントリが存在するか否かを、見做し判断部３０３は判断する。モードＤＢ３０６内のエントリのうち、未処理のエントリが存在する場合（ステップＳ１１０２のＹｅｓ分岐）には、ステップＳ１１０３に遷移する。一方、モードＤＢ３０６内のエントリのうち、未処理のエントリが存在しない場合（ステップＳ１１０２のＮｏ分岐）には、見做し判断部３０３は、モードＤＢ３０６内のエントリを完了したと判断して、処理を終了する。そして、図１０に示すステップＳ９０４に遷移する。

ステップＳ１１０３において、見做し判断部３０３は、モードＤＢ３０６内のエントリのうち、端末優先度が最も高く、且つ未処理であるエントリを抽出する。具体的には、見做し判断部３０３は、モードＤＢ３０６内のエントリのうち、「未処理」のフラグが設定されたエントリを抽出する。そして、見做し判断部３０３は、抽出したエントリのうち、端末優先度が最も高いエントリを、見做し対象エントリとして抽出する。

例えば、モードＤＢ３０６において、図６に示すように、端末ＩＤ、現在モードＩＤ、見做しモードＩＤ、端末優先度が設定されているとする。そして、図６に示すモードＤＢ３０６において、エントリ５１１、５１２に対して、「未設定」のフラグが設定されているとする。なお、ステップＳ１１０３において、モードＤＢ３０６の見做しフラグは、未設定であるものとする。ここで、図６に示す通り、エントリ５１１、５１２の端末優先度は、夫々、「０．７」、「０．８」である。そのため、見做し判断部３０３は、図６に示すエントリ５１２を、見做し対象エントリとして抽出する。

ステップＳ１１０４において、モード要件ＤＢ３０８において、抽出したエントリの見做しモードＩＤに対応する要求リソース量が、該エントリの現在モードＩＤに対応する要求リソース量を越えるか否かを、見做し判断部３０３は判断する。該エントリの見做しモードＩＤに対応する要求リソース量が、該エントリの現在モードＩＤに対応する要求リソース量を越える場合（ステップＳ１１０４のＹｅｓ分岐）には、ステップＳ１１０５に遷移する。一方、該エントリの見做しモードＩＤに対応する要求リソース量が、該エントリの現在モードＩＤに対応する要求リソース量以下である場合（ステップＳ１１０４のＮｏ分岐）には、見做し判断部３０３は、モードＤＢ３０６から抽出したエントリに対して、「処理済み」を示すフラグを設定する（ステップＳ１１０７）。そして、ステップＳ１１０２に戻り、処理を継続する。

例えば、見做し判断部３０３は、図６に示すエントリ５１２を、見做し対象エントリとして抽出したとする。その場合、抽出したエントリ５１２の現在モードＩＤ、見做しモードＩＤは、夫々、「２」、「３」である。

ここで、図８に示すモード要件ＤＢ３０８を参照すると、動作モードＩＤ「２」（図６に示すエントリ５１２の現在モードＩＤに相当）に対応する要求リソースの総量は、「３５」（エントリ７１３の要求リソース量「２５」＋エントリ７１４の要求リソース量「１０」）である。そのため、抽出したエントリの現在モードＩＤ「２」に対応する要求リソース量が「３５」である、と見做し判断部３０３は判断する。

同様に、図８に示すモード要件ＤＢ３０８を参照すると、動作モードＩＤ「３」（図６に示すエントリ５１２の見做しモードＩＤに相当）に対応する要求リソースの総量は、「１１０」（エントリ７１５の要求リソース量「１００」＋エントリ７１６の要求リソース量「１０」）である。そのため、抽出したエントリの見做しモードＩＤ「３」に対応する要求リソース量が「１１０」である、と見做し判断部３０３は判断する。

その結果、この場合には、モード要件ＤＢ３０８において、抽出したエントリの見做しモードＩＤに対応する要求リソース量が、該エントリの現在モードＩＤに対応する要求リソース量を越えると、見做し判断部３０３は判断する。そして、この場合、ステップＳ１１０５に遷移する。なお、要求リソース量の総量に基づく、上記の判断方法は、一例であり、ステップＳ１１０４の処理における判断方法を限定する趣旨ではない。

ステップＳ１１０５において、見做しモードを、現在のインフラ上で収容可能であるか否かを、見做し判断部３０３は判断する。ここで、見做しモードを、現在のインフラ上で収容可能とは、現在のインフラにおいて、該見做しモードに対応する動作モードを実行可能であることを意味する。ここで、現在のインフラとは、ネットワークインフラ１０２、及び／又はコンピューティングインフラ１０５を含むものとする。

具体的には、見做し候補エントリの端末ＩＤに対応する端末１０３に関して、インフラリソースＤＢ３０７及びモード要件ＤＢ３０８に基づいて、見做し候補エントリの見做しモードＩＤに対応する見做しモードを、現在のインフラにおいて実行可能であるか否かを、見做し判断部３０３は判断する。

例えば、見做しモードＩＤに対応する要求リソース量と、現在モードＩＤに対応する要求リソース量との差分に基づいて、見做しモードを、現在のインフラ上で収容可能であるか否かを、見做し判断部３０３は判断しても良い。その場合、該差分が、リソース残量以下である場合には、見做しモードを、現在のインフラ上で収容可能である、と見做し判断部３０３は判断しても良い。一方、該差分が、リソース残量を越える場合には、見做しモードを、現在のインフラ上で収容不可能である、と見做し判断部３０３は判断しても良い。なお、例えば、見做し判断部３０３は、図７に示すインフラリソースＤＢ３０７におけるリソース総量と、リソース使用量との差分に基づいて、リソース残量を計算しても良い。

見做しモードを、現在のインフラ上で収容可能である場合（ステップＳ１１０５のＹｅｓ分岐）には、ステップＳ１１０６に遷移する。一方、現在のインフラ上で収容可能ではない場合（ステップＳ１１０５のＮｏ分岐）には、見做し判断部３０３は、モードＤＢ３０６から抽出したエントリに対して、「処理済み」を示すフラグを設定する（ステップＳ１１０７）。そして、ステップＳ１１０２に戻り、処理を継続する。

例えば、見做し判断部３０３が、見做し候補エントリとして、図６に示すエントリ５１２を抽出したとする。そして、見做しモードＩＤに対応する要求リソース量と、現在モードＩＤに対応する要求リソース量との差分に基づいて、見做しモードを、現在のインフラ上で収容可能であるか否かを、見做し判断部３０３は判断するとする。

その場合、図８に示すモード要件ＤＢ３０８を参照すると、見做しモードＩＤ「３」に対応する、リソースＩＤ「１」の要求リソース量は、「１００」である。一方、図８に示すモード要件ＤＢ３０８を参照すると、現在モードＩＤ「２」に対応する、リソースＩＤ「１」の要求リソース量は、「２５」である。そのため、リソースＩＤ「１」のリソースに関して、見做しモードＩＤに対応する要求リソース量と、現在モードＩＤに対応する要求リソース量との差分は、「７５」である。

同様に、図８に示すモード要件ＤＢ３０８を参照すると、見做しモードＩＤ「３」に対応する、リソースＩＤ「２」の要求リソース量は、「１０」である。一方、図８に示すモード要件ＤＢ３０８を参照すると、現在モードＩＤ「２」に対応する、リソースＩＤ「２」の要求リソース量は、「１０」である。

また、図７に示すインフラリソースＤＢ３０７を参照すると、リソースＩＤ「１」のリソースのリソース残量（リソース総量からリソース使用量の差分値）は、「９５」である。同様に、図７に示すインフラリソースＤＢ３０７を参照すると、リソースＩＤ「２」のリソースのリソース残量は、「１１０」である。従って、この場合、見做しモードを、現在のインフラ上で収容可能である、と見做し判断部３０３は判断する。そして、ステップＳ１１０６に遷移する。

ステップＳ１１０６において、見做し判断部３０３は、モードＤＢ３０６において、抽出したエントリに対応する、見做しフラグを「Ｙ」として設定する。具体的には、見做し判断部３０３は、見做し対象エントリの端末ＩＤに対応する端末１０３を、動作状況が変化する前に、動作状況が変化したと見做して制御する、制御対象端末として決定する。そして、見做し判断部３０３は、モードＤＢ３０６において、該制御対象端末に対応する、見做しフラグを、「Ｙ」として設定する。一方、見做し判断部３０３は、モードＤＢ３０６において、制御対象端末以外の端末に対応する、見做しフラグを、「Ｎ」として設定する。そして、見做し判断部３０３は、モードＤＢ３０６から抽出したエントリに対して、「処理済み」を示すフラグを設定する（ステップＳ１１０７）。

そして、ステップＳ１１０２に戻り、処理を継続する。つまり、モードＤＢ３０６内の全てのエントリに対して、処理済みのフラグを設定するまで、処理を継続する。見做し判断部３０３は、上記の処理（図１２に示す処理）を実行することで、モードＤＢ３０６に格納される、見做しフラグを更新する。

次に、図１３を参照しながら、制御情報送信部３０４の動作の詳細について説明する。図１３は、制御情報送信部３０４の動作の一例を示すフローチャートである。

ステップＳ１２０１において、制御情報送信部３０４は、モードＤＢ３０６内に格納される全てのエントリに対して、「未処理」を示すフラグを設定する。具体的には、モードＤＢ３０６内に格納される全てのエントリを抽出する。そして、制御情報送信部３０４は、抽出した全てのエントリに対して、「未処理」を示すフラグを設定する。

ステップＳ１２０２において、モードＤＢ３０６内のエントリのうち、未処理のエントリが存在するか否かを、制御情報送信部３０４は判断する。つまり、モードＤＢ３０６内のエントリのうち、「未処理」のフラグが設定されたエントリが存在するか否かを、制御情報送信部３０４は判断する。モードＤＢ３０６内のエントリのうち、未処理のエントリが存在する場合（ステップＳ１２０２のＹｅｓ分岐）には、未処理のエントリのうち、一のエントリを抽出し、ステップＳ１２０３に遷移する。一方、モードＤＢ３０６内のエントリのうち、未処理のエントリが存在しない場合（ステップＳ１２０２のＮｏ分岐）には、制御情報送信部３０４は、モードＤＢ３０６内のエントリを完了したと判断して、処理を終了する。

ステップＳ１２０３において、モードＤＢ３０６内の未処理のエントリのうち、抽出したエントリに対応する端末１０３が、制御対象端末であるか否かを、制御情報送信部３０４は判断する。具体的には、図６に示すモードＤＢ３０６を参照する場合、モードＤＢ３０６内の未処理のエントリのうち、抽出したエントリの見做しフラグに基づいて、エントリに対応する端末１０３が、制御対象端末であるか否かを判断する。なお、抽出したエントリに対応する端末１０３とは、該エントリの端末ＩＤに対応する端末１０３である。

抽出したエントリに対応する端末１０３が、制御対象端末である場合（ステップＳ１２０３のＹｅｓ分岐）には、制御情報送信部３０４は、見做しモードにおいて必要なパラメータ等と、抽出したエントリの端末ＩＤとを、インフラ制御装置１０４へ送信する（ステップＳ１２０４）。具体的には、制御情報送信部３０４は、モード要件ＤＢ３０８に基づいて、抽出したエントリに対応する端末１０３（即ち、制御対象端末）の見做しモードにおいて必要なパラメータ（制御情報）を計算する。例えば、制御情報送信部３０４は、モード要件ＤＢ３０８を参照し、見做しモードＩＤに対応するリソースＩＤ及び要求リソース量を抽出しても良い。そして、制御情報送信部３０４は、抽出したリソースＩＤ及び要求リソース量に基づいて、見做しモードにおいて必要なパラメータを計算しても良い。そして、制御情報送信部３０４は、算出したパラメータと、抽出したエントリの端末ＩＤ（即ち、制御対象端末の端末ＩＤ）とを、インフラ制御装置１０４へ送信する。そして、ステップＳ１２０２に戻り、処理を継続する。

一方、抽出したエントリに対応する端末１０３が、制御対象端末ではない場合（ステップＳ１２０３のＮｏ分岐）には、制御情報送信部３０４は、現在モードにおいて必要なパラメータと、抽出したエントリの端末ＩＤとを、インフラ制御装置１０４へ送信する（ステップＳ１２０５）。具体的には、制御情報送信部３０４は、モード要件ＤＢ３０８に基づいて、抽出したエントリに対応する端末１０３（即ち、制御対象端末以外の端末１０３）の現在モードにおいて必要なパラメータ（制御情報）を算出する。例えば、制御情報送信部３０４は、モード要件ＤＢ３０８を参照し、現在モードＩＤに対応するリソースＩＤ及び要求リソース量を抽出しても良い。そして、制御情報送信部３０４は、抽出したリソースＩＤ及び要求リソース量に基づいて、現在モードにおいて必要なパラメータ（制御情報）を計算しても良い。そして、制御情報送信部３０４は、算出したパラメータと、抽出したエントリの端末ＩＤとを、インフラ制御装置１０４へ送信する。そして、ステップＳ１２０２に戻り、処理を継続する。

インフラ制御装置１０４は、ＱｏＥ保証装置１０１から送信されたパラメータを、ネットワークインフラ１０２、及び／又はコンピューティングインフラ１０５を制御するために必要な情報（制御情報）として受信する。そして、インフラ制御装置１０４は、受信した制御情報に基づいて、ネットワークインフラ１０２、及び／又はコンピューティングインフラ１０５を制御する。

以上のように、本実施形態に係るＱｏＥ保証装置１０１は、複数（２以上）の端末１０３のうち、優先度が相対的に高い端末１０３を、動作状況（動作モード）の変化に先立って制御する制御対象端末として選択する。さらに、本実施形態に係るＱｏＥ保証装置１０１は、各端末１０３に関して、端末の動作状況（現在モード）から遷移する、次の動作状況（動作モード）を、見做しモードとして推定する。そして、本実施形態に係るＱｏＥ保証装置１０１は、選択した制御対象端末に関して、動作状況（動作モード）の変化前に、先立って制御するように、必要なパラメータ（制御情報）を、インフラ制御装置１０４に送信する。その結果、本実施形態に係るＱｏＥ保証装置１０１は、アプリケーションの動作状態の遷移に伴い、ＱｏＥが低下することを抑制することに貢献する。

［第２の実施形態］
次に、第２の実施形態について、図面を用いてより詳細に説明する。

本実施形態は、動作モードの履歴に基づいて、動作モード間の状態遷移確率を推定する形態である。なお、本実施形態における説明では、上記の実施形態と重複する部分の説明は省略する。さらに、本実施形態における説明では、上記の実施形態と同一の構成要素には、同一の符号を付し、その説明を省略する。また、本実施形態における説明では、上記の実施形態と同一の作用効果についても、その説明を省略する。以下、他の形態においても同様であるものとする。

本実施形態に係るネットワーク化システムの全体構成の一例は、図２に示す通りである。なお、本実施形態の説明においては、端末、ＱｏＥ保証装置を、夫々、端末１３０１、ＱｏＥ保証装置１４０１と表記する。

まず、本実施形態に係る端末１３０１について詳細に説明する。

図１４は、本実施形態に係る端末１３０１の内部構成の一例を示すブロック図である。本実施形態に係る端末１３０１は、アプリケーション部１３０２と、モード情報送信部１３０３とを含んで構成される。本実施形態に係るアプリケーション部１３０２は、第１の実施形態に係るアプリケーション部２０１と同様であるため詳細な説明を省略する。以下、本実施形態に係る端末１３０１と、第１の実施形態に係る端末１０３との相違点について説明する。

例えば、端末１３０１が備える記憶装置（図示せず）が、クライアントサイドアプリケーション１０７を記憶しても良い。記憶装置は、磁気ディスク装置や光ディスク装置、半導体メモリによって実現される。

端末１３０１は、ＣＰＵを用いて、アプリケーション部１３０２と、モード情報送信部１３０３を実現しても良い。さらに、例えば、端末１３０１は、ＮＩＣを用いて、他の装置（ＱｏＥ保証装置１４０１、ネットワークインフラ１０２、コンピューティングインフラ１０５）とのデータ（情報）の送受信を実現しても良い。

モード情報送信部１３０３は、アプリケーション部１３０２の動作状態を観測（監視）する。そして、モード情報送信部１３０３は、クライアントサイドアプリケーション１０７が内部的に切り替える動作モードを取得する。そして、モード情報送信部１３０３は、該動作モードに更新があった場合、ネットワークインフラ１０２を介して、ＱｏＥ保証装置１４０１に対して、該動作モードに更新があったことを通知する。

次に、本実施形態に係るＱｏＥ保証装置１４０１について詳細に説明する。

図１５は、本実施形態に係るＱｏＥ保証装置１４０１の内部構成の一例を示すブロック図である。本実施形態に係るＱｏＥ保証装置１４０１は、モード情報受信部１４０２と、優先度算出部１４０３と、見做し判断部１４０４と、制御情報送信部１４０５と、モード間遷移確率推定部（状態遷移確率推定部とも呼ぶ）１４１０とを含んで構成される。さらに、本実施形態に係るＱｏＥ保証装置１４０１は、モード遷移確率ＤＢ１４０６と、モードＤＢ１４０７と、インフラリソースＤＢ１４０８と、モード要件ＤＢ１４０９と、モード履歴ＤＢ１４１１と、を含んで構成される。図１５に示すＱｏＥ保証装置１４０１と、図４に示すＱｏＥ保証装置１０１との相違点は、図１５に示すＱｏＥ保証装置１４０１が、モード間遷移確率推定部１４１０と、モード履歴ＤＢ（動作モード履歴データベースとも呼ぶ）１４１１を含んで構成される点である。以下、本実施形態に係るＱｏＥ保証装置１４０１と、第１の実施形態に係るＱｏＥ保証装置１０１との相違点について詳細に説明する。

例えば、ＱｏＥ保証装置１４０１が備える記憶装置（図示せず）が、モード遷移確率ＤＢ１４０６と、モードＤＢ１４０７と、インフラリソースＤＢ１４０８と、モード要件ＤＢ１４０９と、モード履歴ＤＢ１４１１とを格納しても良い。記憶装置は、磁気ディスク装置や光ディスク装置、半導体メモリによって実現される。

また、ＱｏＥ保証装置１４０１は、ＣＰＵを用いて、モード情報受信部１４０２、優先度算出部１４０３、見做し判断部１４０４、制御情報送信部１４０５、モード間遷移確率推定部１４１０を実現しても良い。さらに、例えば、ＱｏＥ保証装置１４０１は、ＮＩＣを用いて、他の装置（端末１３０１、インフラ制御装置１０４等）とのデータ（情報）の送受信を実現しても良い。

モード遷移確率ＤＢ１４０６、モードＤＢ１４０７、インフラリソースＤＢ１４０８、モード要件ＤＢ１４０９が格納する情報は、第１の実施形態と同様であるため、詳細な説明は省略する。また、以下の説明においては、モード遷移確率ＤＢ１４０６、モードＤＢ１４０７、インフラリソースＤＢ１４０８、モード要件ＤＢ１４０９は、夫々、図５、図６、図７、図８に示す情報を格納するものとする。

モード履歴ＤＢ１４１１は、端末１３０１におけるアプリケーションの動作モードの履歴を格納する。具体的には、モード履歴ＤＢ１４１１は、端末を識別する情報と、該端末１３０１の第１の動作状況（実際の動作状況）の履歴情報とを対応付けて格納する。

図１６は、モード履歴ＤＢ１４１１の一例を示す図である。具体的には、図１６は、履歴ＩＤ１５０１と、端末ＩＤ１５０２と、過去の動作モードＩＤ１５０３とを対応付けたテーブルを示す。履歴ＩＤ１５０１は、端末１３０１におけるアプリケーションの動作モードの履歴を識別する情報である。端末ＩＤ１５０２は、端末１３０１を識別する情報である。過去の動作モードＩＤ１５０３は、端末１３０１におけるアプリケーションにおいて、実際に動作（遷移）した動作モードを識別する情報である。ここで、図１６に示すモード履歴ＤＢ１４１１は、履歴ＩＤ１５０１と、端末ＩＤ１５０２と、過去の動作モードＩＤ１５０３とを対応付けたエントリ１５１１～１５１６を示す。

例えば、図１６に示すエントリ１５１１、１５１２、１５１３、１５１４は、端末ＩＤが「１」である端末１３０１において、動作モードが「１」、「２」、「３」、「１」の順に遷移したことを示す。

本実施形態に係るモード情報受信部１４０２は、端末１０３１から送信された現在モードＩＤを、モードＤＢ１４０７に登録する。そして、モード情報受信部１４０２は、モードＤＢ１４０７を更新したことを、モード間遷移確率推定部１４１０に通知する。

モード間遷移確率推定部１４１０は、第１の動作状況の履歴情報に基づいて、状態遷移確率を計算する。具体的には、モード間遷移確率推定部１４１０は、モードＤＢ１４０７を参照し、モード履歴ＤＢ１４１１に、端末１３１０の第１の動作状況（実際の動作状況）の履歴情報を登録する。そして、モード間遷移確率推定部１４１０は、モード履歴ＤＢ１４１１を参照し、動作モード間の状態遷移確率を推定する。そして、モード間遷移確率推定部１４１０は、推定した状態遷移確率を、モード遷移確率ＤＢ１４０６に登録する。

例えば、端末ＩＤが「１」である端末１３０１において、動作モードが「１」、「２」、「３」、「１」の順に遷移したとする。そして、モード履歴ＤＢ１４１１が、図１６に示すエントリ１５１１～１５１４を格納しているとする。その場合、モード間遷移確率推定部１４１０は、端末ＩＤが「１」である端末１３０１に関して、モード履歴ＤＢ１４１１から、図１６に示すエントリ１５１１～１５１４を、動作モードの履歴として抽出する。

そして、モード間遷移確率推定部１４１０は、抽出した、図１６に示すエントリ１５１１～１５１４に基づいて、動作モード間の状態遷移確率を推定する。例えば、モード間遷移確率推定部１４１０は、Hidden Markov Modelを用いて、動作モード間の関係性をモデリングし、Baum-Welch algorithm等を用いて、状態遷移確率を推定しても良い。なお、これは、状態遷移確率を推定する方法の一例であり、状態遷移確率を推定する方法を限定する趣旨ではない。

次に、本実施形態に係るネットワーク化システムの動作に関して説明する。

まず、図１７を参照しながら、端末１３０１の動作について説明する。図１７は、端末１３０１の動作の一例を示すフローチャートである。

ステップＳ１６０１において、モード情報送信部１３０３は、アプリケーションの状態を観測し、アプリケーションの現在の動作モードを、ＱｏＥ保証装置１４０１に対して送信する。具体的には、モード情報送信部１３０３は、クライアントサイドアプリケーション１０７が内部的に切り替える動作モードを取得し、該動作モードに更新があった場合、該動作モードを、ＱｏＥ保証装置１４０１に対して送信する。

次に、図１８を参照しながら、ＱｏＥ保証装置１４０１の動作について説明する。図１８は、ＱｏＥ保証装置１４０１の動作の一例を示すフローチャートである。

ステップＳ１７０１において、モード情報受信部１４０２は、各端末１３０１から受信した現在モードＩＤをモードＤＢ１４０７に格納し、受信した現在モードＩＤをモード間遷移確率推定部１４１０へ通知する。

ステップＳ１７１１において、モード間遷移確率推定部１４１０は、通知された現在モードＩＤをモード履歴ＤＢ１４１１に登録し、さらに、モード履歴ＤＢ１４１１を参照し、モード遷移確率ＤＢ１４０６を更新する。

そして、ＱｏＥ保証装置１４０１は、図１８に示すステップＳ１７０２～ステップＳ１７０４の処理を実行する。図１８に示すステップＳ１７０２～ステップＳ１７０４は、図１０に示すステップＳ９０２～Ｓ９０４と同じであるため、詳細な説明を省略する。

以上のように、本実施形態に係るＱｏＥ保証装置１４０１は、端末１３０１上で動作するアプリケーションの動作モードの履歴に基づいて、動作モード間の状態遷移確率を推定する。そのため、本実施形態に係るネットワーク化システムにおいては、端末１３０１が、動作モード間の状態遷移確率をＱｏＥ保証装置１４０１に対して送信できない場合であっても、ＱｏＥ保証装置１４０１が、動作モード間の状態遷移確率を推定（導出）できる。従って、本実施形態に係るネットワーク化システムにおいては、端末１３０１が、動作モード間の状態遷移確率をＱｏＥ保証装置１４０１に対して送信できない場合であっても、ＱｏＥ保証装置１４０１は、動作状況（動作モード）の変化前に、先立って制御するように、必要なパラメータ（制御情報）を、インフラ制御装置１０４に送信する。よって、本実施形態に係るネットワーク化システムは、端末１３０１が、動作モード間の状態遷移確率をＱｏＥ保証装置１４０１に対して送信できない場合であっても、アプリケーションの動作状態の遷移に伴い、ＱｏＥが低下することを抑制することに貢献する。

［第３の実施形態］
次に、第３の実施形態について、図面を用いてより詳細に説明する。

本実施形態は、端末の動作モードが変化する前に、動作モードが変化したと見做して、該端末上で動作するアプリケーションを制御する形態である。

本実施形態に係るネットワーク化システムの全体構成の一例は、図２に示す通りである。なお、本実施形態の説明においては、端末、ＱｏＥ保証装置を、夫々、端末１８０１、ＱｏＥ保証装置１９０１と表記する。

まず、本実施形態に係る端末１８０１について詳細に説明する。

図１９は、本実施形態に係る端末１８０１の内部構成の一例を示すブロック図である。本実施形態に係る端末１８０１は、アプリケーション部１８０２と、モード情報送信部１８０３と、制御情報受信部１８１１とを含んで構成される。図１９に示す端末１８０１と、図３に示す端末１０３との相違点は、図１９に示す端末１８０１は、制御情報受信部１８１１を含んで構成される点である。本実施形態に係るアプリケーション部１８０２、モード情報送信部１８０３は、第１の実施形態に係るアプリケーション部２０１、モード情報送信部２０２と同様であるため、詳細な説明を省略する。以下、本実施形態に係る端末１８０１と、第１の実施形態に係る端末１０３との相違点について説明する。

端末１８０１は、ＣＰＵを用いて、アプリケーション部１８０２、モード情報送信部１８０３、制御情報受信部１８１１を実現しても良い。さらに、例えば、端末１８０１は、ＮＩＣを用いて、他の装置（ＱｏＥ保証装置１９０１、ネットワークインフラ１０２、コンピューティングインフラ１０５）とのデータ（情報）の送受信を実現しても良い。

制御情報受信部１８１１は、ＱｏＥ保証装置１９０１から送信された制御情報（見做しモードにおいて必要なパラメータ等）を用いて、アプリケーション部１８０２の動作を制御する。具体的には、制御情報受信部１８１１は、ＱｏＥ保証装置１９０１から送信された制御情報を用いて、端末１８０１上で動作するアプリケーション（クライアントサイドアプリケーション１０７）を動作するためのパラメータを設定、変更する。その結果、制御情報受信部１８１１は、ＱｏＥ保証装置１９０１から送信された制御情報を用いて、端末１８０１上で動作するアプリケーションの動作モード及びパラメータを動的に変更する。

次に、本実施形態に係るＱｏＥ保証装置１９０１について詳細に説明する。

図２０は、本実施形態に係るＱｏＥ保証装置１９０１の内部構成の一例を示すブロック図である。ＱｏＥ保証装置１９０１は、モード情報受信部１９０２と、優先度算出部１９０３と、制御情報送信部１９０５とを含んで構成される。さらに、ＱｏＥ保証装置１９０１は、モード遷移確率ＤＢ１９０６と、モードＤＢ１９０７と、インフラリソースＤＢ１９０８とを含んで構成される。図２０に示すＱｏＥ保証装置１９０１と、図４に示すＱｏＥ保証装置１０１との相違点は、図２０に示すＱｏＥ保証装置１９０１においては、図４に示すＱｏＥ保証装置１０１から、見做し判断部３０３とモード要件ＤＢ３０８とが削除されている点である。

例えば、ＱｏＥ保証装置１９０１が備える記憶装置（図示せず）が、モード遷移確率ＤＢ１９０６と、モードＤＢ１９０７と、インフラリソースＤＢ１９０８とを格納しても良い。記憶装置は、磁気ディスク装置や光ディスク装置、半導体メモリによって実現される。

また、ＱｏＥ保証装置１９０１は、ＣＰＵを用いて、モード情報受信部１９０２、優先度算出部１９０３、制御情報送信部１９０５を実現しても良い。さらに、例えば、ＱｏＥ保証装置１９０１は、ＮＩＣを用いて、他の装置（端末１８０１、インフラ制御装置１０４等）とのデータ（情報）の送受信を実現しても良い。

本実施形態に係る制御情報送信部１９０５は、モードＤＢ１９０７及びインフラリソースＤＢ１９０８を参照し、制御情報を計算する。そして、制御情報送信部１９０５は、算出した制御情報を端末１８０１に送信する。ここで、制御情報送信部１９０５が送信する制御情報は、モードＤＢ１９０７に格納される見做しモードＩＤ及び端末優先度、及びインフラリソースＤＢ１９０８に格納されるリソースに関する情報を含む。

次に、本実施形態に係るネットワーク化システムの動作に関して説明する。

まず、図２１を参照しながら、端末１８０１の動作について説明する。図２１は、端末１８０１の動作の一例を示すフローチャートである。

ステップＳ２００１において、モード情報送信部１８０３は、アプリケーションの動作状況を観測し、アプリケーションの現在の動作モード、及び動作モード間の状態遷移確率を、ＱｏＥ保証装置１９０１に対して送信する。

ステップＳ２０１１において、制御情報受信部１８１１は、ＱｏＥ保証装置１９０１から送信された制御情報を用いて、アプリケーションの動作モードを制御する。具体的には、制御情報受信部１８１１は、ＱｏＥ保証装置１９０１から、インフラ（ネットワークインフラ１０２、及び／又はコンピューティングインフラ１０５）の使用状況を受信する。

例えば、制御情報受信部１８１１は、ネットワークインフラ１０２、コンピューティングインフラ１０５の使用状況に余裕がある場合、インフラ（ネットワークインフラ１０２、及び／又はコンピューティングインフラ１０５）に対して、データの送信頻度を高めるように、パラメータを設定しても良い。

また、制御情報受信部１８１１は、ＱｏＥ保証装置１９０１から、直接、見做しモードＩＤを受信しても良い。そして、制御情報受信部１８１１は、動作状況（動作モード）が変化する前に、先立って制御するように、必要なパラメータを設定しても良い。なお、これは、動作状況（動作モード）が変化する前に、先立って、端末１８０１を制御する方法の一例であり、動作状況が変化する前に、動作状況が変化したと見做して、端末１８０１を制御する方法を限定する趣旨ではない。

次に、図２２を参照しながら、ＱｏＥ保証装置１９０１の動作について説明する。図２２は、ＱｏＥ保証装置１９０１の動作の一例を示すフローチャートである。

ステップＳ２１０１において、モード情報受信部１９０２は、各端末１８０１から受信した情報を、モード遷移確率ＤＢ１９０６及びモードＤＢ１９０７に格納し、情報を受信したことを優先度算出部１９０３に通知する。

ステップＳ２１０２において、優先度算出部１９０３は、モードＤＢ１９０７及びモード遷移確率ＤＢ１９０６を参照し、各端末１８０１の端末優先度及び見做しモードＩＤを計算し、モードＤＢ１９０７を更新する。

ステップＳ２１０４において、制御情報送信部１９０５は、ＱｏＥを満たすために必要な処理を行うように、端末１８０１上のアプリケーションを制御する。具体的には、制御情報送信部１９０５は、モードＤＢ１９０７及びインフラリソースＤＢ１９０８を参照し、制御情報を計算する。そして、制御情報送信部１９０５は、算出した制御情報を端末１８０１に送信する。

以上のように、本実施形態に係るＱｏＥ保証装置１９０１は、見做しモードＩＤ及び端末優先度、及びインフラのリソースに関する情報を、制御情報として端末１８０１に送信する。そのため、本実施形態に係るネットワーク化システムにおいては、インフラを直接に制御できない場合であっても、端末１８０１が、受信した制御情報を用いて、端末１８０１上で動作するアプリケーションの動作モード及びパラメータを動的に変更する。よって、本実施形態に係るネットワーク化システムは、インフラを直接に制御できない場合であっても、アプリケーションの動作状態の遷移に伴い、ＱｏＥが低下することを抑制することに貢献する。

上述の実施形態の一部又は全部は、以下の形態のようにも記載され得るが、以下には限られない。

（形態１）上記第１の視点に係る制御装置の通りである。

（形態２）前記動作状況は、アプリケーションの複数の離散的な動作モードを含む制御装置。

（形態３）端末を識別する情報と、前記第１の動作状況の動作モードと、前記第２の動作状況の動作モードと、前記端末優先度と、該端末が前記制御対象端末であるか否かを示す情報と、を対応付けて格納する、動作モードデータベースをさらに備える制御装置。

（形態４）前記第１の動作状況は、アプリケーションにおいて実行中の動作モードと、動作モード間の状態遷移確率とを含む制御装置。

（形態５）前記第２の動作状況推定部は、動作モード間の前記状態遷移確率に基づいて、前記端末優先度と、前記第２の動作状況とを推定する制御装置。

（形態６）前記第１の動作状況の履歴情報に基づいて、動作モード間の前記状態遷移確率を導出する、状態遷移確率推定部をさらに備える制御装置。

（形態７）端末を識別する情報と、該端末の前記第１の動作状況の履歴情報とを対応付けて格納する、動作モード履歴データベースをさらに備える制御装置。

（形態８）端末を識別する情報と、動作モードを識別する情報と、該動作モードに遷移する状態遷移確率と、を対応付けて格納する、動作モード遷移確率データベースをさらに備える制御装置。

（形態９）前記見做し判断部は、ネットワークのリソース残量、及び／又はコンピューティングインフラのリソース残量に基づいて、前記制御対象端末を特定する制御装置。

（形態１０）動作モードを識別する情報と、リソースを識別する情報と、該動作モードを実行するために必要な該リソースの量と、を対応付けて格納する、動作モード要件データベースをさらに備える制御装置。

（形態１１）前記見做し制御部は、前記制御対象端末の動作状況が変化する前に、該制御対象端末の動作状況が、前記第２の動作状況推定部が推定した前記第２の動作状況に変化したと見做してネットワーク機器、サーバ、前記制御対象端末上で動作するアプリケーションの少なくともいずれかに対して、前記所定の処理を実行する制御装置。

（形態１２）上記第２の視点に係る制御システムの通りである。

（形態１３）上記第３の視点に係る制御装置の制御方法の通りである。

（形態１４）上記第４の視点に係るプログラムの通りである。

上記の形態１２～１４に示す形態は、形態１に示す形態と同様に、形態２～１１に示す形態に展開することが可能である。

なお、上記の特許文献の開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態の変更・調整が可能である。また、本発明の全開示の枠内において種々の開示要素（各請求項の各要素、各実施形態の各要素、各図面の各要素等を含む）の多様な組み合わせ、ないし、選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。特に、本書に記載した数値範囲については、当該範囲内に含まれる任意の数値ないし小範囲が、別段の記載のない場合でも具体的に記載されているものと解釈されるべきである。

１ 制御装置
１１ 第１の動作状況受信部
１２ 第２の動作状況推定部
１３、３０３、１４０４ 見做し判断部
１４ 見做し制御部
１０１、１４０１、１９０１ ＱｏＥ保証装置
１０２ ネットワークインフラ
１０３、１０３ａ～１３０ｃ、１３０１、１８０１ 端末
１０４ インフラ制御装置
１０５ コンピューティングインフラ
１０６ サーバサイドアプリケーション
１０７、１０７ａ～１０７ｃ クライアントサイドアプリケーション
２０１、１３０２、１８０２ アプリケーション部
２０２、１３０３、１８０３ モード情報送信部
３０１、１４０２、１９０２ モード情報受信部
３０２、１４０３、１９０３ 優先度算出部
３０４、１４０５、１９０５ 制御情報送信部
３０５、１４０６、１９０６ モード遷移確率ＤＢ
３０６、１４０７、１９０７ モードＤＢ
３０７、１４０８、１９０８ インフラリソースＤＢ
３０８、１４０９ モード要件ＤＢ
４０１、５０１、１５０２ 端末ＩＤ
４０２ 遷移先モードＩＤ
４０３ 状態遷移確率
４１１～４１６、５１１、５１２、６１１、６１２、７１１～７１６、１５１１～１５１６ エントリ
５０２ 現在モードＩＤ
５０３ 見做しモードＩＤ
５０４ 端末優先度
５０５ 見做しフラグ
６０１、７０２ リソースＩＤ
６０２ リソース総量
６０３ リソース使用量
７０１ 動作モードＩＤ
７０３ 要求リソース量
１４１０ モード間遷移確率推定部
１４１１ モード履歴ＤＢ
１５０１ 履歴ＩＤ
１５０３ 過去の動作モードＩＤ
１８１１ 制御情報受信部

Claims (6)

1. ２以上の端末から、アプリケーションの動作状況を、第１の動作状況として受信する、第１の動作状況受信部と、
   前記各端末に関して、前記第１の動作状況受信部が受信する前記第１の動作状況に含まれる、少なくとも現在のアプリケーションの動作モードと、動作モード間の状態遷移確率と、に基づいて、前記各端末で動作するアプリケーションの動作状況が変化したと見做して制御する端末の優先度である端末優先度と、前記第１の動作状況から遷移する第２の動作状況と、を推定する、第２の動作状況推定部と、
   前記端末優先度と、前記第２の動作状況とに基づいて、動作状況が変化する前に、動作状況が変化したと見做して制御する端末を、制御対象端末として特定する、見做し判断部と、
   前記制御対象端末の動作状況が変化する前に、該制御対象端末の動作状況が、前記第２の動作状況推定部が推定した前記第２の動作状況に変化したと見做して、端末、サーバ、装置が接続されネットワーク機能を実行及び制御するネットワーク機器、前記各端末に対してアプリケーションを提供するサーバ、前記制御対象端末上で動作するアプリケーションの少なくともいずれかに対して、所定の処理を実行する、見做し制御部と、
   を備える制御装置。
2. 前記第１の動作状況の履歴情報に基づいて、動作モード間の前記状態遷移確率を導出する、状態遷移確率推定部をさらに備える、請求項１に記載の制御装置。
3. 前記見做し判断部は、さらにネットワーク機能を実行、及び制御する、１又は２以上のネットワーク機器を含んで構成されるネットワークインフラのリソース残量、及び／又は端末に対してアプリケーションを提供するサーバとして機能する、コンピュータからなる１又は２以上の装置を含んで構成されるコンピューティングインフラのリソース残量に基づいて、前記制御対象端末を特定する、請求項１又は２に記載の制御装置。
4. ２以上の端末と、
   ネットワークを介して、前記端末と接続する制御装置と、
   を含んで構成される制御システムであって、
   前記端末は、
   アプリケーションの動作状況を、前記制御装置に送信する、第１の動作状況送信部を備え、
   前記制御装置は、
   前記各端末から、アプリケーションの動作状況を、第１の動作状況として受信する、第１の動作状況受信部と、
   前記各端末に関して、前記第１の動作状況受信部が受信する前記第１の動作状況に含まれる、少なくとも現在のアプリケーションの動作モードと、動作モード間の状態遷移確率と、に基づいて、前記各端末で動作するアプリケーションの動作状況が変化したと見做して制御する端末の優先度である端末優先度と、前記第１の動作状況から遷移する第２の動作状況と、を推定する、第２の動作状況推定部と、
   前記端末優先度と、前記第２の動作状況とに基づいて、動作状況が変化する前に、動作状況が変化したと見做して制御する端末を、制御対象端末として特定する、見做し判断部と、
   前記制御対象端末の動作状況が変化する前に、該制御対象端末の動作状況が、前記第２の動作状況推定部が推定した前記第２の動作状況に変化したと見做して、端末、サーバ、装置が接続されネットワーク機能を実行及び制御するネットワーク機器、前記各端末に対してアプリケーションを提供するサーバ、前記制御対象端末上で動作するアプリケーションの少なくともいずれかに対して、所定の処理を実行する、見做し制御部と、
   を備える、制御システム。
5. ネットワークを介して２以上の端末と通信する制御装置の制御方法であって、
   前記端末から、アプリケーションの動作状況を、第１の動作状況として受信する工程と、
   前記各端末に関して、受信された前記第１の動作状況に含まれる、少なくとも現在のアプリケーションの動作モードと、動作モード間の状態遷移確率と、に基づいて、前記各端末で動作するアプリケーションの動作状況が変化したと見做して制御する端末の優先度である端末優先度と、前記第１の動作状況から遷移する第２の動作状況と、を推定する工程と、
   前記端末優先度と、前記第２の動作状況とに基づいて、動作状況が変化する前に、動作状況が変化したと見做して制御する端末を、制御対象端末として特定する工程と、
   前記制御対象端末の動作状況が変化する前に、該制御対象端末の動作状況が、推定された前記第２の動作状況に変化したと見做して、端末、サーバ、装置が接続されネットワーク機能を実行及び制御するネットワーク機器、前記各端末に対してアプリケーションを提供するサーバ、前記制御対象端末上で動作するアプリケーションの少なくともいずれかに対して、所定の処理を実行する工程と、
   を含む制御方法。
6. ネットワークを介して２以上の端末と通信する制御装置を制御するコンピュータに実行させるプログラムであって、
   前記端末から、アプリケーションの動作状況を、第１の動作状況として受信する処理と、
   前記各端末に関して、受信された前記第１の動作状況に含まれる、少なくとも現在のアプリケーションの動作モードと、動作モード間の状態遷移確率と、に基づいて、前記各端末で動作するアプリケーションの動作状況が変化したと見做して制御する端末の優先度である端末優先度と、前記第１の動作状況から遷移する第２の動作状況と、を推定する処理と、
   前記端末優先度と、前記第２の動作状況とに基づいて、動作状況が変化する前に、動作状況が変化したと見做して制御する端末を、制御対象端末として特定する処理と、
   前記制御対象端末の動作状況が変化する前に、該制御対象端末の動作状況が、推定された前記第２の動作状況に変化したと見做して、端末、サーバ、装置が接続されネットワーク機能を実行及び制御するネットワーク機器、前記各端末に対してアプリケーションを提供するサーバ、前記制御対象端末上で動作するアプリケーションの少なくともいずれかに対して、所定の処理を実行する処理と、
   を前記コンピュータに実行させるプログラム。

Images