JP2020135477A - サービス配置選定方法およびサービス配置選定プログラム - Google Patents

Abstract

【課題】様々なサービスを実行するアプリケーションソフトウェア、コンピュータ、およびデバイスの組合せを選定する際に環境が大きく変動する状況でも、サービスの目的を達成できる可能性を高くしてサービスの目的を達成するまでの所要時間を短縮すること。【解決手段】通信ネットワーク上における特定アプリｘ、特定デバイスｚの組合せに関するデータ有効度期待値Ｊ（ｘ，ｚ）を算出し、このデータ有効度期待値および特定コンピュータｙをパラメータとして含む評価値Ｆ（ｘ，ｙ，ｚ）を計算し、その結果に基づき適切な組合せ（ｘ，ｙ，ｚ）を選定する。実績データからデータ有効度期待値を算出する。古いデータと新しいデータに重み付けしてデータ有効度期待値を算出する。特定アプリｘと類似した他のアプリの実績値も利用してデータ有効度期待値を算出する。【選択図】図７

Description

本発明は、通信ネットワーク上でユーザ端末などに対して様々なサービスを提供するために利用可能なサービス配置選定方法およびサービス配置選定プログラムに関する。

例えば、特許文献１の図１に示されたライブデータ検索システムは、リソース検索装置と、複数のサーバと、複数のリソースと、複数のルータとを備えている。ここで、複数のリソースのそれぞれは、カメラ、マイク、ウェアラブル端末などのようにライブデータを出力可能なデバイスに相当する。また、リソース検索装置は、通信可能に接続されているユーザ端末に対して複数のリソースを用いた所定のサービスを提供するための機能を有する。

また、特許文献１の段落００２２に記載されているように、リソース検索装置は、ユーザ端末からリソース検索要求を受信すると、複数のサーバの少なくとも１つに検索プログラムを配置する。サーバは、検索プログラムに従い、サーバ自身と同じ個別ネットワークに配置されているリソースからライブデータを収集する。サーバは、収集したライブデータを解析し、解析結果をリソース検索装置に送信する。

特許文献１は、複数のネットワークに接続されているリソースを用いて実現するサービスを利用するユーザ端末に送信する情報のリアルタイム性を向上させるための技術を示している。具体的には、リソース検索装置が、複数のネットワークの各々に配置されているサーバの位置情報を記憶しており、ユーザ端末からリソース検索要求を取得し、取得したリソース検索要求に含まれる位置情報に対応するサーバを特定する。また、リソース検索要求に含まれる検索プログラムを、特定したサーバに配置し、検索プログラムが配置されたサーバから、当該サーバが配置されているネットワークに配置されているリソースが配信するライブデータを収集し、リソース検索要求に含まれる検索対象の認識の一致度が所定値以上となるライブデータを配信するリソースを検索し、検索したリソースへのアクセス情報をユーザ端末に送信する。

特開２０１８−８１５１５号公報

特許文献１に示されたようなネットワークシステムにおいては、ユーザなどの要求に対して、ネットワーク上の様々な位置に配置されたサーバなどの複数のコンピュータを用いて、検索機能を有するアプリケーションソフトウェアを実行できる。また、ネットワーク上の様々な位置に配置された複数のデバイスをデータ発生源として利用できる。

しかしながら、実際にアプリケーションソフトウェアを実行する特定のコンピュータと、データ発生源として使用するデバイスとの距離が大きく離れている場合には、このサービスによってネットワーク上を通過するパケットなどのトラヒックが増大し、ネットワークの負荷が大きくなる。

また、例えば既に稼働率が高くなっている状態の特定のコンピュータを選択して、このコンピュータで目的のアプリケーションソフトウェアを更に実行させる場合には、該当するアプリケーションソフトウェアが目的の処理を完了するまでの所要時間が長くなる。

また、例えば複数のデバイスの中から選択した特定デバイスの出力する情報の種類や特性が、目的の検索サービスの実行に対してあまり有効でない場合には、特定デバイスから得られた情報を解析しても要求されたサービスの目的を達成できない可能性が高い。その場合は、アプリケーションが終了した後で、特定デバイスの選択を変更して、再び情報の取得と解析とを行う必要がある。そのため、サービスの目的を達成するまでの所要時間が長くなり、通信ネットワークの負荷やコンピュータの負荷も大きくなる。

また、ネットワーク上に接続されている各デバイスが出力する情報の種類や特性については、例えば、時間帯の違い、曜日の違い、デバイス自体の移動に伴う位置の変化などに伴って日常的に大きく変動する可能性が高い。したがって、例えばサービスの目的毎に、有効なデータを出力可能な適切なデバイスを、特定デバイスとして事前に決めておくことはできない。

本発明は、上記の状況に鑑みてなされたものであり、様々なサービスを実行する際のアプリケーションソフトウェア、コンピュータ、およびデバイスの組合せを選定するにあたり、環境が大きく変動する状況においても、サービスの目的を達成できる可能性が高く、サービスの目的を達成するまでの所要時間を短縮するための適正化が可能な、サービス配置選定方法およびサービス配置選定プログラムを提供することを目的とする。

（１）少なくともデータ出力が可能な複数のＩｏＴデバイスと、前記各ＩｏＴデバイスの出力データを扱う複数のアプリケーションソフトウェアの実行が可能な複数のコンピュータとが、それぞれ所定の通信ネットワークを介して互いに異なる位置で接続されている環境下で、
新たなアプリケーションソフトウェアを特定アプリｘとして起動しようとする際に、前記特定アプリｘと、前記複数のコンピュータの中から選択される１つの特定コンピュータｙと、前記複数のＩｏＴデバイスの中から選択される１つ以上の特定デバイスｚとの適正化された組合せを決定するためのサービス配置選定方法であって、
前記特定アプリｘと、前記特定デバイスｚとの組合せに関するデータ有効度期待値Ｊ（ｘ，ｚ）を算出し、
少なくとも前記データ有効度期待値Ｊ（ｘ，ｚ）と、前記特定コンピュータｙとをパラメータとして含む評価値Ｆ（ｘ，ｙ，ｚ）を計算し、
前記評価値Ｆ（ｘ，ｙ，ｚ）を利用して、前記特定アプリｘ、前記特定コンピュータｙ、および前記特定デバイスｚの組合せを選定する、
ことを特徴とする。

このサービス配置選定方法によれば、前記データ有効度期待値Ｊ（ｘ，ｚ）を算出し、これを評価した結果を選定に反映するので、前記特定アプリｘと前記特定デバイスｚとを組合せてサービスを実行する場合に、サービスの目的を短時間で達成できる可能性が高まる。また、前記特定デバイスｚを変更してサービスを繰り返し実行する可能性も小さくなる。また、前記評価値Ｆ（ｘ，ｙ，ｚ）で特定コンピュータｙも評価するので、例えば負荷の小さいコンピュータを選択することにより、サービスの処理完了までにかかる時間の短縮が可能になる。

（２）上記（１）に記載のサービス配置選定方法において、
前記複数のアプリケーションソフトウェアのそれぞれについて、そのサービス実行結果を表す実績データを前記各ＩｏＴデバイス毎に保存して管理し、
前記データ有効度期待値Ｊ（ｘ，ｚ）を、前記実績データに基づいて算出する、
ことを特徴とする。

上記（２）のサービス配置選定方法によれば、アプリケーションソフトウェア毎に、過去に実施したサービスにおけるＩｏＴデバイス毎の実績データが得られるので、前記特定アプリｘと、前記特定デバイスｚとの組合せにおける実績データを用いて、前記データ有効度期待値Ｊ（ｘ，ｚ）を正しく評価することが可能になる。すなわち、前記特定アプリｘと前記特定デバイスｚとを組合せてサービスを実行する場合に、前記特定デバイスｚの出力するデータが、本サービスの目的を達成するために有効であるかどうかを、過去の実績データに基づき正しく評価できる。

（３）上記（２）に記載のサービス配置選定方法において、
前記実績データとして、取得した時点が古い第１の実績データと、取得した時点が新しい第２の実績データとをそれぞれ保存して管理し、
前記第１の実績データと前記第２の実績データとにそれぞれ重み付けを行って前記データ有効度期待値Ｊ（ｘ，ｚ）を算出する、
ことを特徴とする。

このサービス配置選定方法によれば、前記第１の実績データと前記第２の実績データとにそれぞれ重み付けを行って前記データ有効度期待値Ｊ（ｘ，ｚ）を算出するので、より精度の高い評価を行うことが可能になる。例えば、古くなった前記第１の実績データは、環境変動の影響による誤差が大きい可能性があるが、例えば平均化したり、重みを小さくすることにより、前記データ有効度期待値Ｊ（ｘ，ｚ）を正しく算出するために役立てることができる。また、時間的に新しい前記第２の実績データは、有効なデータ数が少ない可能性があるが、環境変動の影響による誤差が小さいので、重みを大きくすることにより前記データ有効度期待値Ｊ（ｘ，ｚ）を正しく算出するために役立つ。

（４）上記（２）に記載のサービス配置選定方法において、
前記実績データとして、前記特定アプリｘおよび前記特定デバイスｚの組合せに対して検出された第３の実績データと、前記特定アプリｘと類似性のある第２の特定アプリと前記特定デバイスｚとの組合せに対して検出された第４の実績データとをそれぞれ取得し、
前記第３の実績データおよび前記第４の実績データに基づいて前記データ有効度期待値Ｊ（ｘ，ｚ）を算出する、
ことを特徴とする。

このサービス配置選定方法によれば、例えば前記特定アプリｘおよび前記特定デバイスｚの組合せに対して検出された前記第３の実績データが全く存在しない場合でも、サービスの特性における前記特定アプリｘとの類似性を考慮して、前記第２の特定アプリを抽出し、前記第４の実績データを得ることができる。したがって、前記第４の実績データを利用して前記データ有効度期待値Ｊ（ｘ，ｚ）を算出できる。

（５）上記（１）に記載のサービス配置選定方法において、
選定した前記特定アプリｘを起動した後で、前記特定アプリｘがサービスの目的を達成できなかった場合には、前記データ有効度期待値Ｊ（ｘ，ｚ）の算出、および前記評価値Ｆ（ｘ，ｙ，ｚ）の算出を周期的に繰り返し、前記特定デバイスｚの選定の見直しを実施する、
ことを特徴とする。

このサービス配置選定方法によれば、前記特定アプリｘがサービスの目的を達成できなかった場合に、より適切な組合せの前記特定デバイスｚを選定することが可能になる。例えば、時間の経過や各デバイスの移動に伴って、前記データ有効度期待値Ｊ（ｘ，ｚ）を算出する場合の条件が変化することが想定される。したがって、ある程度時間が経過した場合には、前記特定デバイスｚの選定を見直すことにより、サービスの目的を達成するまでの所要時間を短縮できる。

（６）上記（１）に記載のサービス配置選定方法において、
前記特定アプリｘが、前記特定コンピュータｙ、および前記特定デバイスｚの組合せでサービスを実施する場合に予想される処理時間増加量期待値Ｇ（ｘ，ｙ，ｚ）を、前記データ有効度期待値Ｊ（ｘ，ｚ）に基づいて算出し、
前記特定アプリｘが、前記特定コンピュータｙ、および前記特定デバイスｚの組合せでサービスを実施する場合に予想されるトラヒック増加量期待値Ｈ（ｘ，ｙ，ｚ）を算出し、
前記処理時間増加量期待値Ｇ（ｘ，ｙ，ｚ）および前記トラヒック増加量期待値Ｈ（ｘ，ｙ，ｚ）に重み付けをして前記評価値Ｆ（ｘ，ｙ，ｚ）を算出する、
ことを特徴とする。

このサービス配置選定方法によれば、前記データ有効度期待値Ｊ（ｘ，ｚ）に基づいて予想される処理時間の増加量を評価することが可能になる。また、例えば前記特定アプリｘが配置される前記特定コンピュータｙと、前記特定デバイスｚとの距離の長短を考慮して、予想されるトラヒック増加量を評価することができる。したがって、予想される処理時間の増加量が少なく、しかも予想されるトラヒック増加量が小さい組合せを、前記評価値Ｆ（ｘ，ｙ，ｚ）を用いて選定できる。

（７）上記（１）に記載のサービス配置選定方法において、
選定した組合せにおける前記特定アプリｘが、前記特定コンピュータｙ上に存在しない場合には、所定のサーバから前記特定コンピュータｙ上に前記特定アプリｘを配信する、
ことを特徴とする。

このサービス配置選定方法によれば、前記特定アプリｘを必要な時に前記特定コンピュータｙ上に配信できるので、様々なアプリケーションソフトウェアをそれぞれのコンピュータ上に常時配置しておく必要がない。したがって、限られたコンピュータ資源を有効に活用できる。

（８）少なくともデータ出力が可能な複数のＩｏＴデバイスと、前記各ＩｏＴデバイスの出力データを扱う複数のアプリケーションソフトウェアの実行が可能な複数のコンピュータとが、それぞれ所定の通信ネットワークを介して互いに異なる位置で接続されている環境下で、新たなアプリケーションソフトウェアを特定アプリｘとして起動しようとする際に、前記特定アプリｘと、前記複数のコンピュータの中から選択される１つの特定コンピュータｙと、前記複数のＩｏＴデバイスの中から選択される１つ以上の特定デバイスｚとの適正化された組合せを決定するための、所定のコンピュータで実行可能なサービス配置選定プログラムであって、
前記特定アプリｘと、前記特定デバイスｚとの組合せに関するデータ有効度期待値Ｊ（ｘ，ｚ）を算出する手順と、
少なくとも前記データ有効度期待値Ｊ（ｘ，ｚ）と、前記特定コンピュータｙとをパラメータとして含む評価値Ｆ（ｘ，ｙ，ｚ）を計算する手順と、
前記評価値Ｆ（ｘ，ｙ，ｚ）を利用して、前記特定アプリｘ、前記特定コンピュータｙ、および前記特定デバイスｚの組合せを選定する手順と、
を有することを特徴とする。

このサービス配置選定プログラムを所定のコンピュータで実行する場合には、前記データ有効度期待値Ｊ（ｘ，ｚ）を算出し、これを評価した結果を選定に反映するので、前記特定アプリｘと前記特定デバイスｚとを組合せてサービスを実行する場合に、サービスの目的を短時間で達成できる可能性が高まる。また、前記特定デバイスｚを変更してサービスを繰り返し実行する可能性も小さくなる。また、前記評価値Ｆ（ｘ，ｙ，ｚ）で特定コンピュータｙも評価するので、例えば負荷の小さいコンピュータを選択することにより、サービスの処理完了までにかかる時間の短縮が可能になる。

本発明のサービス配置選定方法およびサービス配置選定プログラムによれば、様々なサービスを実行する際のアプリケーションソフトウェア、コンピュータ、およびデバイスの組合せを選定するにあたり、環境が大きく変動する状況においても、サービスの目的を達成できる可能性が高く、サービスの目的を達成するまでの所要時間を短縮するための適正化が可能になる。

本発明が適用される通信システムの構成例を示すブロック図である。 本発明を実施するネットワークサービス管理装置の機能の概要を示すブロック図である。 マシンテーブルの構成例を示す模式図である。 デバイステーブルの構成例を示す模式図である。 ＡＰＬ使用情報ＤＢの構成例を示す模式図である。 リクエスト送信部およびサービス開始判断部の動作の概要を示すシーケンス図である。 ロケーション判断部、ＡＰＬ制御部、およびＤＢ管理部の動作の概要を示すシーケンス図である。 サービス配置選定に影響を及ぼす要素を示すブロック図である。 協調フィルタリングを用いてデータ有効度期待値を取得する際に用いるテーブルの構成例を示す模式図である。

本発明の実施形態について各図を参照しながら以下に説明する。
＜通信システムの構成例＞
本発明が適用される通信システムの構成例を図１に示す。
図１に示した例では、通信ネットワークＮＷを介して、ネットワークサービス管理装置１０、複数のユーザ端末２１、２２、２３、および２４、複数の物理マシンリソース３１、３２、および３３、複数の物理デバイスリソース４１、４２、および４３が通信可能な状態で接続されている。

通信ネットワークＮＷとしては、例えばインターネットが想定される。したがって、物理デバイスリソース４１〜４３は、生成したデータをインターネットに送出可能なＩｏＴ（Internet of Things）デバイスとして利用できる。

各ユーザ端末２１〜２３を操作するユーザ、あるいは図示しないポータルサイトのサーバは、必要に応じて、様々なネットワークサービスの実施を要求することができる。想定されるネットワークサービスの具体例としては、次の（１）〜（３）に示すものが考えられる。
（１）東京などある地域における女子高生１００人のファッションチェックを行う。
（２）特定の迷子猫の行方を探す。
（３）猫のよく居る場所を探す。

各ユーザやポータルサイトからのサービス要求は、例えばネットワークサービス管理装置１０によって受け付けられ、これにより該当するネットワークサービスが実行される。そして、ネットワークサービスの実行結果を表す情報が要求元に提供される。

各物理マシンリソース３１〜３３は、それぞれ様々な場所で通信ネットワークＮＷに接続されているコンピュータやサーバに相当する。つまり、各物理マシンリソース３１〜３３は、ＣＰＵ（Central Processing Unit）コア、メモリ、ストレージのような計算機リソースを必要に応じて提供可能な物理装置である。

前述のネットワークサービスを実施する場合には、各物理マシンリソース３１〜３３のいずれか１つ、又は複数を同時に用いて、該当するサービスに対応したアプリケーションソフトウェアを実行することにより実現できる。

各アプリケーションソフトウェアは、様々な場所に配置されている様々な種類の物理デバイスリソース４１〜４３のそれぞれを必要に応じて選択し、選択した物理デバイスリソース４１〜４３からデータを取得して分析する。これにより、各アプリケーションソフトウェアは、サービスの目的を達成することが可能である。

物理デバイスリソース４１の具体例としては、特定の場所に設置されたカメラ、車両などに搭載された移動カメラ、様々な人物が所持している携帯型のカメラなどが想定される。また、物理デバイスリソース４２の具体例としては、特定の場所に設置された温度計、車両などに搭載された移動温度計、様々な人物が所持している携帯型の温度計などが想定される。また、物理デバイスリソース４３の具体例としては、特定の場所に設置された固定マイク、車両などに搭載された移動マイク、様々な人物が所持している携帯型のマイクなどが想定される。

したがって、あるネットワークサービスを実行する場合、ネットワークサービス管理装置１０は、該当するサービスを実行可能な特定のアプリケーションソフトウェアを選択する。また、ネットワークサービス管理装置１０は、前記特定のアプリケーションソフトウェアを実際に実行するマシンを、利用可能な物理マシンリソース３１〜３３の中から選択する。また、ネットワークサービス管理装置１０は、前記特定のアプリケーションソフトウェアが使用するデータを提供する特定デバイスを、利用可能な物理デバイスリソース４１〜４３の中から選択する。また、選択したマシン上に該当するアプリケーションソフトウェアが存在しない場合、ネットワークサービス管理装置１０は、所定のサーバから該当するマシンに対して、該当するアプリケーションソフトウェアを転送してその場所にアプリケーションソフトウェアを配置する必要がある。

＜サービス配置の説明＞
図１に示した通信システムのような環境においては、実際にネットワークサービスを実行する際に、特定のアプリケーションソフトウェアｘ、該当するアプリケーションソフトウェアを実行する計算機リソースが存在する特定マシンｙ、および該当するアプリケーションソフトウェアが使用する特定デバイスｚの組合せ（ｘ，ｙ，ｚ）がいろいろと考えられる。

しかし、実際に特定のアプリケーションソフトウェアｘを実行する特定マシンｙと、データ発生源として使用する特定デバイスｚとの距離が大きく離れている場合には、このサービスによって通信ネットワークＮＷ上を通過するパケットなどのトラヒックが増大し、ネットワークの負荷が大きくなる。したがって、特定マシンｙと特定デバイスｚとの位置関係を考慮することは非常に重要である。

また、例えば既に稼働率が高くなっている状態の特定マシンｙの計算機リソースを選択して、この計算機リソースで特定のアプリケーションソフトウェアｘを更に実行させる場合には、該当する特定のアプリケーションソフトウェアｘが目的の処理を完了するまでの所要時間が長くなる。したがって、選択対象の特定マシンｙにおける計算機リソースの負荷などを考慮することは非常に重要である。

また、複数のデバイスの中から選択した特定デバイスｚの出力する情報の種類や特性が、目的の検索サービスの実行に対してあまり有効でない場合には、特定デバイスｚから得られた情報を解析しても要求されたサービスの目的を達成できない可能性が高い。その場合は、アプリケーションが終了した後で、特定デバイスｚの選択を変更して、再び情報の取得と解析とを行う必要がある。そのため、サービスの目的を達成するまでの所要時間が長くなり、通信ネットワークＮＷの負荷やコンピュータの負荷も大きくなる。したがって、選択対象の特定デバイスｚが適切かどうかを考慮することは非常に重要である。

しかし、通信ネットワークＮＷ上に接続されている各物理デバイスリソース４１〜４３が出力する情報の種類や特性については、例えば、時間帯の違い、曜日の違い、デバイス自体の移動に伴う位置の変化などに伴って日常的に大きく変動する可能性が高い。したがって、例えばサービスの目的毎に、有効なデータを出力可能な適切なデバイスを、特定デバイスｚとして事前に決めておくことはできない。

図１に示したネットワークサービス管理装置１０は、例えば通信ネットワークＮＷ上で新たにサービスを実行する特定のアプリケーションソフトウェアｘを追加しようとする場合に、前記組合せ（ｘ，ｙ，ｚ）を適正化するために役立つ機能を特徴的な機能として具備している。この機能は、必要に応じて、或いは周期的に繰り返し実施することが想定される。また、通信ネットワークＮＷ上で実行するアプリケーションソフトウェアの種類や数は、例えばユーザ数の増減や、ネットワークなどの負荷の増減に応じて適宜増減することが想定される。

＜ネットワークサービス管理装置の機能の概要＞
本発明を実施するネットワークサービス管理装置１０の機能の概要を図２に示す。
図２に示したネットワークサービス管理装置１０は、主要な機能として、サービス開始判断部１１、ロケーション判断部１２、ＡＰＬ（アプリケーションソフトウェア）制御部１３、ＤＢ（データベース）管理部１４、およびＡＰＬサーバ１５を備えている。

なお、上記各機能は、実際には所定のコンピュータ上に配置される１つ又は複数の管理用のアプリケーションソフトウェアの実行により実現する。勿論、各機能を専用のハードウェアで実現することも可能である。

サービス開始判断部１１は、サービス要求元７０から入力されるサービスリクエスト情報７１に基づき、サービスの開始および終了の判断を実施する。また、サービス開始判断部１１はロケーション判断部１２に計算指示１１ａを与え、ＡＰＬ制御部１３に終了指示１１ｂを与える。

ＤＢ管理部１４は、ネットワークサービス管理装置１０が利用可能なデータベースであるＡＰＬ使用情報ＤＢ５０、および設備情報ＤＢ６０のデータをそれぞれ管理している。また、ＤＢ管理部１４は各ＡＰＬの動作結果の履歴を保存したり、各マシンの情報を収集して各データベースの内容を更新するための管理を行う。

ロケーション判断部１２は、入力される計算指示１１ａに従い、適切なロケーションの判断を実施する。すなわち、目的のサービスを実施するために必要な特定ＡＰＬｘと、互いにロケーションが異なる複数の物理マシンリソース３１〜３３の中から選択した特定マシンｙと、互いにロケーションが異なる複数の物理デバイスリソース４１〜４３の中から選択した特定デバイスｚとの組合せを適切に決定する。また、適切な組合せを決定するために、ロケーション判断部１２はＤＢ管理部１４を介してＡＰＬ使用情報ＤＢ５０および設備情報ＤＢ６０の内容を参照する。ロケーション判断部１２は、決定した組合せの特定マシンｙおよび特定デバイスｚをそれぞれ特定するロケーションの情報１２ａをＡＰＬ制御部１３へ与える。

ＡＰＬ制御部１３は、ロケーション判断部１２の決定に従い、指示された特定ＡＰＬｘを、ＡＰＬサーバ１５を利用して通信ネットワークＮＷ上の特定マシンｙ宛てに配信したり、特定ＡＰＬｘを特定マシンｙ上で実行するための管理を実施する。

ＡＰＬサーバ１５は、様々なＡＰＬ自体の情報、すなわち様々な実行可能なプログラムおよびそれが扱うデータの組合せを保持し、ＡＰＬ制御部１３の指示に従って選択された特定マシンｙへ特定ＡＰＬｘを配信する。

図２に示した例では、ＡＰＬ使用情報ＤＢ５０は過去実績データ５１および直近データリスト５２を含んでいる。また、設備情報ＤＢ６０はマシンテーブル６１、デバイステーブル６２、およびロケーションテーブル６３を含んでいる。ロケーションテーブル６３の中には、各マシンのネットワーク上の場所、および各デバイスのネットワーク上の場所を表すデータが含まれている。

＜マシンテーブルの構成例＞
マシンテーブル６１の構成例を図３に示す。
図３に示したマシンテーブル６１は、複数のマシン、すなわちコンピュータのそれぞれについて、マシンを特定する情報６１ａ、ＣＰＵコア数６１ｂ、メモリ容量情報６１ｃ、ストレージ容量情報６１ｄ、ＣＰＵ使用率情報６１ｅ、およびメモリ使用率情報６１をそれぞれ保持する領域を有している。

したがって、図３のマシンテーブル６１を参照することにより、ネットワークサービス管理装置１０は、マシン毎の処理能力、ＣＰＵおよびメモリの使用率、および残りの処理能力を把握できる。また、各マシン、例えば図１中の物理デバイスリソース４１〜４３の所在を表すロケーション情報については、図２中に示したロケーションテーブル６３から取得できる。

＜デバイステーブルの構成例＞
デバイステーブル６２の構成例を図４に示す。
図４に示したデバイステーブル６２は、複数のデバイスのそれぞれについて、デバイスを特定する情報６２ａ、およびデバイスの種別を表す情報６２ｂを保持する領域を有している。

したがって、図４のデバイステーブル６２を参照することにより、ネットワークサービス管理装置１０は、各デバイスから得られるデータの種別を把握できる。また、各デバイス、例えば図１中の物理デバイスリソース４１〜４３の所在を表すロケーション情報については、図２中に示したロケーションテーブル６３から取得できる。

＜ＡＰＬ使用情報ＤＢの構成例＞
ＡＰＬ使用情報ＤＢ５０の構成例を図５に示す。
図５に示したＡＰＬ使用情報ＤＢ５０は、１番目、２番目、および３番目のそれぞれのアプリケーションソフトウェアＡＰＬ１、ＡＰＬ２、およびＡＰＬ３に対応する独立したＡＰＬテーブル５０ａ、５０ｂ、および５０ｃを備えている。

各ＡＰＬテーブル５０ａ〜５０ｃは、当該ＡＰＬの過去実績値（第１の実績データ）５１ａ、過去実行時間累計値５１ｂ、アプリケーション現在値の直近データリスト（記第２の実績データ）５２、およびリソース使用情報５３のデータをデバイス毎に個別に保持する領域を有している。

当該ＡＰＬの過去実績値５１ａおよび直近データリスト５２は、当該ＡＰＬを実行した際のサービスの結果として得られた実績値を反映している。また、当該ＡＰＬの過去実績値５１ａの内容は、過去の多数の実績値を平均化して得られた平均値を表している。また、直近データリスト５２の内容は、比較的新しいデータであって、直近の６回分のサービスの実績値の一覧を表している。

ネットワークサービス管理装置１０が管理している各ＡＰＬについては、例えば検索サービス、特定のパターンを認識して抽出するサービスのように、サービスの実行結果として、ある目的を達成できたかどうかを把握できる種類のものを想定している。したがって、各サービスを実行すると、その結果として実績値が得られる。あるいは、サービスを開始してから目的を達成するまでにかかった所要時間の長さを実績値として管理することも考えられる。

過去実行時間累計値５１ｂは、当該ＡＰＬおよび当該デバイスの組合せで過去にサービスを実行した時間の累計値を表している。例えば、図５のＡＰＬテーブル５０ｃにおいて、アプリケーションソフトウェアＡＰＬ３、および「デバイス１」の組合せのサービスが累計で「５０日間・１２時間・３５分間」だけ過去に使用されたことが示されている。

リソース使用情報５３の内容は、当該ＡＰＬおよび当該デバイスの組合せで過去にサービスを実行した際の、直近実行日、および実行開始から終了までの時間帯を表している。つまり、当該ＡＰＬの実行により、このサービスがマシンおよびネットワークのリソースを消費していた日時をこの情報から知ることができる。

例えば、図５のＡＰＬテーブル５０ｃにおいて、アプリケーションソフトウェアＡＰＬ３、および「デバイス２」の組合せのサービスは、「２０１８／１２／４」の日付で、「１４：００〜１４：０５」の５分間だけ使用されたことが示されている。なお、図５のＡＰＬテーブル５０ｃにおいて、アプリケーションソフトウェアＡＰＬ３、および「デバイス１」の組合せにおけるリソース使用情報５３の内容に示されている「１３：００〜Ｎｏｗ」の「Ｎｏｗ」は、当該サービスを現在も実行中であることを表している。

＜ネットワークサービス管理装置１０の動作の概要＞
リクエスト送信部７５およびサービス開始判断部１１の動作の概要を図６に示す。なお、リクエスト送信部７５はサービス要求元７０となるユーザ端末２１〜２４や、ポータルサイトを提供するサーバに相当する。また、ロケーション判断部１２、ＡＰＬ制御部１３、およびＤＢ管理部１４の動作の概要を図７に示す。

図６、図７に示した動作について以下に説明する。
リクエスト送信部７５がステップＳ１１でサービス開始の要求をすると、情報ｉ０１がリクエスト送信部７５からサービス開始判断部１１に入力される。サービス開始判断部１１は、入力された情報ｉ０１に従い、ステップＳ２１でサービス開始の判断を実行する。その結果としてサービスを開始する場合には、サービス開始判断部１１が情報ｉ０２をロケーション判断部１２に送る。

ロケーション判断部１２は、入力された情報ｉ０２をサービス開始の指示とみなしてステップＳ３１以降の処理を実行する。ステップＳ３１では、ロケーション判断部１２からＤＢ管理部１４に情報ｉ０５を送り、ロケーションの判断に必要な情報の問い合わせを実施する。具体的には、以下の情報ｉ３１ａ〜ｉ３１ｄを問い合わせする。
ｉ３１ａ：設備情報ＤＢ６０の該当する内容。
ｉ３１ｂ：リソース使用情報５３。
ｉ３１ｃ：他ＡＰＬの実行結果を表す最新の実績値、つまり直近データリスト５２の最後尾の内容。
ｉ３１ｄ：当該ＡＰＬの過去実績値５１ａ、つまり過去実績の平均値。

ＤＢ管理部１４は、情報ｉ０５で問い合わせのあった各情報をステップＳ５１でＡＰＬ使用情報ＤＢ５０および設備情報ＤＢ６０から取得し、これらを情報ｉ０６としてロケーション判断部１２に返す。

ロケーション判断部１２は、問い合わせの結果を情報ｉ０６として受信すると、取得した情報に基づいてステップＳ３２で「サービス期待値」を算出する。この「サービス期待値」の具体例については後で説明する。

ロケーション判断部１２は、該当する特定ＡＰＬｘ、候補となる各特定マシンｙ、および候補となる各特定デバイスｚの組合せ（ｘ，ｙ，ｚ）のそれぞれを評価するために、ステップＳ３３で配信スコアＦ（ｘ，ｙ，ｚ）を組合せ毎に算出する。この配信スコアＦ（ｘ，ｙ，ｚ）は、上記ステップＳ３２で得られる「サービス期待値」をパラメータとして含むものである。配信スコアＦ（ｘ，ｙ，ｚ）の具体例については後で説明する。
また、ロケーション判断部１２はＳ３３で得られた組合せ毎の配信スコアＦ（ｘ，ｙ，ｚ）をステップＳ３４で比較して、配信スコアＦ（ｘ，ｙ，ｚ）が上位のいくつかの組合せ（ｘ，ｙ，ｚ）を選択し抽出する。

ロケーション判断部１２は、ステップＳ３４で抽出したいくつかの組合せ（ｘ，ｙ，ｚ）のそれぞれについて、該当する特定ＡＰＬｘの現在の状況をステップＳ３５で調査する。つまり、特定マシンｙ上で特定デバイスｚを使う特定ＡＰＬｘが実行されているか否かや、特定ＡＰＬｘが特定マシンｙ上に存在するか否かなどを、ＡＰＬ使用情報ＤＢ５０および設備情報ＤＢ６０の内容に基づいて識別する。

特定マシンｙ上で特定デバイスｚを使う特定ＡＰＬｘがまだ実行されていない場合は、ロケーション判断部１２はステップＳ３６からＳ３７の処理に進み、特定ＡＰＬｘのサービス開始を情報ｉ０７でＡＰＬ制御部１３へ指示する。また、特定マシンｙ上に特定ＡＰＬｘが存在しない場合は、ステップＳ３７で特定ＡＰＬｘの配信も指示する。

ＡＰＬ制御部１３は、受信した情報ｉ０７で指示された組合せ（ｘ，ｙ，ｚ）に従い、該当する特定ＡＰＬｘ自体を、ステップＳ４１でＡＰＬサーバ１５から特定マシンｙ上に配信する。なお、同じ特定ＡＰＬｘが既に特定マシンｙ上に存在する場合にはその配信は省略する。
また、ＡＰＬ制御部１３は、配信した特定ＡＰＬｘの実行開始をステップＳ４２で特定マシンｙに対して指示する。

ＡＰＬ制御部１３は、ステップＳ４３で特定ＡＰＬｘの実行結果を管理する。すなわち、特定ＡＰＬｘがサービスの結果として出力する実績値などの情報を取得する。また、ＡＰＬ制御部１３は、ステップＳ４４で特定ＡＰＬｘがサービスの結果として出力した情報に基づいて、ＡＰＬ使用情報ＤＢ５０の該当する内容が更新されるように、情報ｉ０８でＤＢ管理部１４に指示を与える。また、ＡＰＬ制御部１３は特定ＡＰＬｘのサービスの結果を情報ｉ０９によりサービス開始判断部１１に通知する。

ＤＢ管理部１４は、受信した情報ｉ０８に従い、ステップＳ５２でＡＰＬ使用情報ＤＢ５０の過去実績データ５１および直近データリスト５２の内容を更新する。また、ＤＢ管理部１４はステップＳ５３で設備情報ＤＢ６０の内容、およびリソース使用情報５３の内容を例えば定期的に更新する。

一方、サービス開始判断部１１は、ステップＳ２１で情報ｉ０２を送信した後、ステップＳ２２で該当するサービス（アプリケーションソフトウェア）の終了を待つ。該当するサービス（アプリケーションソフトウェア）が終了すると、ＡＰＬ制御部１３から情報ｉ０９が入力されるので、これに従いサービス開始判断部１１の処理はステップＳ２２からＳ２３に進む。

サービス開始判断部１１は、ステップＳ２３で情報ｉ０９の内容を参照し、サービスの目的を達成できたか否かを識別する。サービスの目的を達成できた場合はステップＳ２３からＳ２６に進む。

また、サービスの目的を達成していない場合は、サービス開始判断部１１は次のステップＳ２４でサービス開始から一定時間が経過したか否かを識別する。まだ一定時間が経過してなければ、サービス開始判断部１１は再び情報ｉ０２をロケーション判断部１２に送り、ロケーションの判断、すなわち組合せ（ｘ，ｙ，ｚ）の見直しを指示する。

また、サービス開始から一定時間が経過した場合は、サービス開始判断部１１はステップＳ２５に進み、ＡＰＬエラーの応答処理を実施する。すなわち、サービス開始判断部１１は、エラーを示す情報ｉ０３をサービスの要求元であるリクエスト送信部７５に送る。

サービス開始判断部１１は、ステップＳ２６で該当するＡＰＬを用いたサービスの結果について出力の処理を実施する。すなわち、サービス開始判断部１１は、情報ｉ０４で結果をリクエスト送信部７５に通知する。それと同時に、サービス開始判断部１１は再び情報ｉ０２をロケーション判断部１２に送りサービス開始を指示する。

リクエスト送信部７５は、ステップＳ１２で、受信した情報ｉ０３に対してＡＰＬエラーの受信処理を実施する。
リクエスト送信部７５は、ステップＳ１３で、受信した情報ｉ０４を取り込んで、ＡＰＬを用いたサービスの結果に関する受信処理を実施する。

なお、ユーザ等が特定ＡＰＬｘを用いたサービスを終了する場合には、この終了の指示をネットワークサービス管理装置１０に入力する。その場合、ネットワークサービス管理装置１０内のサービス開始判断部１１が当該サービス（アプリケーションソフトウェア）の終了を判断してその結果をロケーション判断部１２に通知する。ロケーション判断部１２は、サービス開始判断部１１の通知内容に従い、当該ＡＰＬの終了をＡＰＬ制御部１３に対して指示する。ＡＰＬ制御部１３は、ロケーション判断部１２からの指示に従い、当該ＡＰＬｘを終了するための指示を特定マシンｙに送る。

＜サービス配置選定に影響を及ぼす要素＞
図６および図７に示した動作を実施する場合に、サービス配置選定に影響を及ぼす主要な要素を図８に示す。
図８に示した設備・マシン使用情報８２は、設備情報ＤＢ６０に登録されているマシンテーブル６１、デバイステーブル６２、およびロケーションテーブル６３の内容に相当する。

すなわち、図８に示したサービスリクエスト情報８１に応じて当該サービスを実行する特定ＡＰＬｘが定まると、複数の組合せ（ｘ，ｙ，ｚ）のそれぞれを評価する。この評価の際に、特定マシンｙの情報、マシンテーブル６１、およびロケーションテーブル６３に基づき、当該サービスのＡＰＬｘが実行されるマシンの位置、すなわち実行ロケーション情報８３を特定できる。また、特定デバイスｚの情報、デバイステーブル６２、およびロケーションテーブル６３に基づきデバイスロケーション情報８５が特定できる。

また、当該サービスのＡＰＬに対する有効度期待値８４は、特定ＡＰＬｘの情報およびＡＰＬ使用情報ＤＢ５０から取得可能な実績値により算出できる。
つまり、図２に示したネットワークサービス管理装置１０は、候補となる複数の組合せ（ｘ，ｙ，ｚ）のそれぞれについて、実行ロケーション情報８３、デバイスロケーション情報８５、および有効度期待値８４を評価することにより、適切な組合せ（ｘ，ｙ，ｚ）を選定することができる。この適切な組合せ（ｘ，ｙ，ｚ）の選定は、ＡＰＬの平均処理時間を短くするため、およびネットワーク全体のトラヒック量を低減するために効果的である。

＜配信スコアＦの算出＞
図７中の各ステップＳ３２、Ｓ３３の「サービス期待値」および配信スコアＦ（ｘ，ｙ，ｚ）の具体例について以下に説明する。

組合せ（ｘ，ｙ，ｚ）に対する配信スコアＦ（ｘ，ｙ，ｚ）は、以下の式（１）〜式（３）に基づき算出できる。
Ｆ(x,y,z)＝ｗ１・Ｇ(x,y,z)＋ｗ２・Ｈ(x,y,z) ・・・（１）
Ｇ(x,y,z)＝（Ｉ(x,y)／Ｊ(x,z)）＋Ｋ(x,y,z) ・・・（２）
Ｈ(x,y,z)＝ｗｉ(x,y,z)・Ｎ(x,y,z)＋ｗｏ(x,z)・Ｏ(x,y) ・・・（３）
Ｇ(x,y,z)：総サービス処理時間増加量期待値。
Ｈ(x,y,z)：総トラヒック増加量期待値。
ｗ１，ｗ２：サービス処理時間増加量およびトラヒック増加量のどちらを優先するかを定めるための重み。例えば、サービス処理時間に対するマシン利用コスト、ネットワークトラヒック利用量に対する通信料金コストに基づき、全体の料金が最小になるように重み付けすることが想定される。
Ｉ(x,y)：特定ＡＰＬｘを特定マシンｙ上で処理する際のマシン負荷を考慮した処理時間推測値。
Ｊ(x,z)：特定ＡＰＬｘが特定デバイスｚのデータを処理する場合に想定されるデータ有効度期待値。これがステップＳ３３の「サービス期待値」に相当する。
Ｋ(x,y,z)：特定ＡＰＬｘが特定マシンｙ上に載ることによる総マシン負荷影響量、つまり負荷変動の差分。
Ｎ(x,y,z)：特定デバイスｚのデータを特定マシンｙに転送する際のデータトラヒック量。
Ｏ(x,y)：特定ＡＰＬｘが特定マシンｙからサービス要求元に送る出力データのトラヒック量。
ｗｉ(x,y,z)，ｗｏ(x,z)：特定ＡＰＬｘに対する入力および出力のトラヒックへの重み。例えば、ネットワーク上のホップ数が大きくなるほど重みｗｉ、ｗｏを大きくすることで、ネットワーク上の距離が短くなるように調整したり、コアネットワークを用いるほど重みｗｉ、ｗｏを大きくしてなるべくエッジ側で処理させるように調整することが想定される。

したがって、配信スコアＦ（ｘ，ｙ，ｚ）が小さいことは、総サービス処理時間量増加期待値Ｇが小さく、総トラヒック増加量期待値Ｈも小さいことを意味し、高い評価を与えることができる。すなわち、配信スコアＦ（ｘ，ｙ，ｚ）の小さい組合せ（ｘ，ｙ，ｚ）が図７のステップＳ３４で抽出される。

実際には、例えば図１に示したような通信システムにおいて、ネットワーク上の各マシンに既にいくつかのＡＰＬが配信済みであるような状況で、ユーザ等のサービス要求に対応して、新しくもう１つの特定ＡＰＬｘを配信し実行しようとする場合が想定される。その場合に、ネットワークサービス管理装置１０が図６、図７に示した動作により適切な組合せ（ｘ，ｙ，ｚ）を選定することにより、ネットワーク全体におけるサービスの運用を適切に行うことが可能になる。

＜配信スコアＦの各要素の計算に関する具体例＞
−＜Ｉ(x,y)：処理時間推測値＞
本例では、簡単のため次の条件が成立する場合を想定する。すなわち、同じマシン上にＮａ個のＡＰＬを配置して実行すると、ＡＰＬ数Ｎａの倍率に比例して処理時間がかかる。この場合、処理時間推測値Ｉ(x,y)は次の式（４）で求めることができる。
Ｉ(x,y)＝Ｉｏ×Ｎａ ・・・（４）
Ｉｏ：特定マシンｙ上で１個のＡＰＬが実行される場合に、他ＡＰＬの負荷の影響を受けずに処理する時間量。この時間量は、特定マシンｙ上での処理時間情報として、サービスカタログの内容、およびマシンテーブル６１の内容から算出できる。

−＜Ｊ(x,z)：データ有効度期待値＞
データ有効度期待値Ｊ(x,z)は次の式（５）で求めることができる。
Ｊ(x,z)＝ｗ３・Ｌ(x,z)＋ｗ４・Ｍ(x,z) ・・・（５）
Ｍ(x,z)：特定ＡＰＬｘ以外の現在稼働中のサービスから推測される特定ＡＰＬｘおよび特定デバイスｚのロケーションにおける現在の期待値（第２の実績データ、第４の実績データ）。例えば、特定ＡＰＬｘのサービスの目的が、「カメラ映像から女子高生のファッションチェックを行う」ものである場合は、現在のカメラ映像に映っている人の数などを期待値Ｍ(x,z)とすることができる。
Ｌ(x,z)：特定ＡＰＬｘおよび特定デバイスｚのロケーションにおける過去の実績値（第１の実績データ、第３の実績データ）。
ｗ３，ｗ４：現在と過去のそれぞれに対する重み。両者の和が「１」になるよう定める。

なお、ＡＰＬの種類によっては、同じ特定デバイスｚのデータに対して１度解析を行った後は、同じ解析を継続して行っても効果が小さいことが想定される。その場合は、解析を実行した後で、該当する期待値Ｍ(x,z)を下げることにより、他のデバイスのデータを解析するための組合せ（ｘ，ｙ，ｚ）の変更、つまりサービス配置見直しが容易になる。

上記各重みｗ３，ｗ４は、例えば次の式（６）、式（７）により算出できる。
ｗ３＝Ｐ１(Ｄ１)／(Ｐ２(Ｄ２)＋Ｐ１(Ｄ１)) ・・・（６）
ｗ４＝Ｐ２(Ｄ２)／(Ｐ２(Ｄ２)＋Ｐ１(Ｄ１)) ・・・（７）
Ｐ１，Ｐ２：Ｄ１，Ｄ２に対するポイント
Ｄ１：直近実行日時
Ｄ２：過去累計日時
上記ポイントＰ１、Ｐ２については、例えば次の（１）〜（３）のように定義する。
（１）累計時間の１時間につき１ポイント付与し、最大で１００ポイントとする。
（２）現在情報であれば最大の１００ポイントを付与する。
（３）１時間以上前の情報であれば０ポイントとする。

したがって、例えば図５に示したＡＰＬ使用情報ＤＢ５０におけるＡＰＬテーブル５０ｃの内容を利用すると、「デバイス１」、「デバイス２」、「デバイス３」に対するデータ有効度期待値Ｊ(x,z)はそれぞれ次の式（８）〜式（１０）で求めることができる。
「デバイス１」の場合：
Ｊ(x,z)＝{100/(100＋100)}×AVE(59,60,50,52,60,58)＋{100/(100＋100)}×60 ・・・(８)
AVE()：括弧内のデータリストの平均値
「デバイス２」の場合：
Ｊ(x,z)＝{58/(58＋4)}×AVE(24,23,22,43,21,24)＋{4/(58＋4)}×50 ・・・(９)
「デバイス３」の場合：
Ｊ(x,z)＝{0/(0＋61)}×AVE(31,35,47,24,36,35)＋{61/(0＋61)}×30 ・・・ (１０)

−＜Ｋ(x,y,z)：総マシン負荷影響量＞
本例では、簡単のため次の条件が成立する場合を想定する。すなわち、同じマシン上にＮａ個のＡＰＬを配置して実行すると、ＡＰＬ数Ｎａの倍率に比例して処理時間がかかる。ここで、特定マシンｙ上に２番目サービスの組合せ（ｘ２，ｙ，ｚ２）、および３番目サービスの組合せ（ｘ３，ｙ，ｚ３）が既に存在する場合に、特定ＡＰＬｘのサービスを追加すると、この追加により特定マシンｙ上のＡＰＬ総数が２個から３個に変わり、ＡＰＬ毎の処理時間推測値Ｉ(x,y)がそれぞれ１．５倍になる。したがって、その場合の総マシン負荷影響量Ｋ(x,y,z)は、以下の式（１１）で表される。
Ｋ(x,y,z)＝ｗ１(1.5-1)・((Ｉ２／Ｊ２)＋(Ｉ３／Ｊ３)) ・・・（１１）
Ｉ２：Ｉ(x2,y)
Ｊ２：Ｊ(x2,z2)
Ｉ３：Ｉ(x3,y)
Ｊ３：Ｊ(x3,z3)
ｘ２，ｘ３：２番目，３番目サービスの特定ＡＰＬ
ｚ２，ｚ３：２番目，３番目サービスの特定デバイス

＜変形例の説明＞
協調フィルタリングを用いて「データ有効度期待値」を取得する際に用いるテーブルの構成例を図９に示す。
図９に示したテーブルにおいては、特定ＡＰＬｘ、およびそれと類似性のある複数の類似ＡＰＬｘ２−１、ｘ２−２、・・・と、「デバイス１」〜「デバイス１０」のそれぞれとの組合せにおける実績値のデータが含まれている。また、テーブル右側の欄に相関値αが示されており、テーブル下側の欄にお勧め度Ｊ２（ｘ，ｚ）が示されている。

図９のテーブルにおいて、例えば特定ＡＰＬｘと「デバイス２」、「デバイス３」との組合せについては有効な実績値が登録されている。しかし、特定ＡＰＬｘと「デバイス４」〜「デバイス７」との組合せについては有効な実績値が存在しない。

一方、類似ＡＰＬｘ２−２〜ｘ２−５と「デバイス４」〜「デバイス７」との組合せについては有効な実績値が登録されている。また、特定ＡＰＬｘと類似ＡＰＬｘ２−３〜ｘ２−５との相関値αは比較的大きい。また、「デバイス５」についてはお勧め度Ｊ２（ｘ，ｚ）が非常に高い。

そこで、図９のテーブルのような状況では、特定ＡＰＬｘと「デバイス５」との組合せに関するデータ有効度期待値Ｊ(x,z)を算出する際に、特定ＡＰＬｘの実績値の代わりに、類似ＡＰＬｘ２−３〜ｘ２−５の実績値を採用する。または、特定ＡＰＬｘの実績値と共に、類似ＡＰＬｘ２−３〜ｘ２−５の実績値も採用する。これにより、適切なデータ有効度期待値Ｊ(x,z)が得られる可能性が高い。

例えば、特定ＡＰＬｘが提供するサービスの目的が、「特定の迷子猫を探すこと」である場合に、サービスの目的が「猫のよく居る場所を探すこと」である他の類似ＡＰＬの実績値を採用し、これに基づいてデータ有効度期待値Ｊ(x,z)を算出する。実際の実績値としては、過去の実績における平均値を用いることが想定される。

なお、本発明のサービス配置選定プログラムは、例えばネットワークサービス管理装置１０を構成するコンピュータの記憶装置上に予め保持しておいてもよいし、通信ネットワークＮＷを経由して所定のサーバからダウンロードしてネットワークサービス管理装置１０が実行してもよい。

１０ ネットワークサービス管理装置
１１ サービス開始判断部
１２ ロケーション判断部
１３ ＡＰＬ制御部
１４ ＤＢ管理部
１５ ＡＰＬサーバ
２１，２２，２３，２４ ユーザ端末
３１，３２，３３ 物理マシンリソース
４１，４２，４３ 物理デバイスリソース
５０ ＡＰＬ使用情報ＤＢ
５０ａ，５０ｂ，５０ｃ ＡＰＬテーブル
５１ 過去実績データ
５２ 直近データリスト
５３ リソース使用情報
６０ 設備情報ＤＢ
６１ マシンテーブル
６２ デバイステーブル
６３ ロケーションテーブル
７０ サービス要求元
７１，８１ サービスリクエスト情報
７５ リクエスト送信部
８２ 設備・マシン使用情報
８３ 実行ロケーション情報
８４ 有効度期待値
８５ デバイスロケーション情報
ＮＷ 通信ネットワーク

Claims (8)

1. 少なくともデータ出力が可能な複数のＩｏＴデバイスと、前記各ＩｏＴデバイスの出力データを扱う複数のアプリケーションソフトウェアの実行が可能な複数のコンピュータとが、それぞれ所定の通信ネットワークを介して互いに異なる位置で接続されている環境下で、
   新たなアプリケーションソフトウェアを特定アプリｘとして起動しようとする際に、前記特定アプリｘと、前記複数のコンピュータの中から選択される１つの特定コンピュータｙと、前記複数のＩｏＴデバイスの中から選択される１つ以上の特定デバイスｚとの適正化された組合せを決定するためのサービス配置選定方法であって、
   前記特定アプリｘと、前記特定デバイスｚとの組合せに関するデータ有効度期待値Ｊ（ｘ，ｚ）を算出し、
   少なくとも前記データ有効度期待値Ｊ（ｘ，ｚ）と、前記特定コンピュータｙとをパラメータとして含む評価値Ｆ（ｘ，ｙ，ｚ）を計算し、
   前記評価値Ｆ（ｘ，ｙ，ｚ）を利用して、前記特定アプリｘ、前記特定コンピュータｙ、および前記特定デバイスｚの組合せを選定する、
   サービス配置選定方法。
2. 請求項１に記載のサービス配置選定方法において、
   前記複数のアプリケーションソフトウェアのそれぞれについて、そのサービス実行結果を表す実績データを前記各ＩｏＴデバイス毎に保存して管理し、
   前記データ有効度期待値Ｊ（ｘ，ｚ）を、前記実績データに基づいて算出する、
   サービス配置選定方法。
3. 請求項２に記載のサービス配置選定方法において、
   前記実績データとして、取得した時点が古い第１の実績データと、取得した時点が新しい第２の実績データとをそれぞれ保存して管理し、
   前記第１の実績データと前記第２の実績データとにそれぞれ重み付けを行って前記データ有効度期待値Ｊ（ｘ，ｚ）を算出する、
   サービス配置選定方法。
4. 請求項２に記載のサービス配置選定方法において、
   前記実績データとして、前記特定アプリｘおよび前記特定デバイスｚの組合せに対して検出された第３の実績データと、前記特定アプリｘと類似性のある第２の特定アプリと前記特定デバイスｚとの組合せに対して検出された第４の実績データとをそれぞれ取得し、
   前記第３の実績データおよび前記第４の実績データに基づいて前記データ有効度期待値Ｊ（ｘ，ｚ）を算出する、
   サービス配置選定方法。
5. 請求項１に記載のサービス配置選定方法において、
   選定した前記特定アプリｘを起動した後で、前記特定アプリｘがサービスの目的を達成できなかった場合には、前記データ有効度期待値Ｊ（ｘ，ｚ）の算出、および前記評価値Ｆ（ｘ，ｙ，ｚ）の算出を周期的に繰り返し、前記特定デバイスｚの選定の見直しを実施する、
   サービス配置選定方法。
6. 請求項１に記載のサービス配置選定方法において、
   前記特定アプリｘが、前記特定コンピュータｙ、および前記特定デバイスｚの組合せでサービスを実施する場合に予想される処理時間増加量期待値Ｇ（ｘ，ｙ，ｚ）を、前記データ有効度期待値Ｊ（ｘ，ｚ）に基づいて算出し、
   前記特定アプリｘが、前記特定コンピュータｙ、および前記特定デバイスｚの組合せでサービスを実施する場合に予想されるトラヒック増加量期待値Ｈ（ｘ，ｙ，ｚ）を算出し、
   前記処理時間増加量期待値Ｇ（ｘ，ｙ，ｚ）および前記トラヒック増加量期待値Ｈ（ｘ，ｙ，ｚ）に重み付けをして前記評価値Ｆ（ｘ，ｙ，ｚ）を算出する、
   サービス配置選定方法。
7. 請求項１に記載のサービス配置選定方法において、
   選定した組合せにおける前記特定アプリｘが、前記特定コンピュータｙ上に存在しない場合には、所定のサーバから前記特定コンピュータｙ上に前記特定アプリｘを配信する、
   サービス配置選定方法。
8. 少なくともデータ出力が可能な複数のＩｏＴデバイスと、前記各ＩｏＴデバイスの出力データを扱う複数のアプリケーションソフトウェアの実行が可能な複数のコンピュータとが、それぞれ所定の通信ネットワークを介して互いに異なる位置で接続されている環境下で、新たなアプリケーションソフトウェアを特定アプリｘとして起動しようとする際に、前記特定アプリｘと、前記複数のコンピュータの中から選択される１つの特定コンピュータｙと、前記複数のＩｏＴデバイスの中から選択される１つ以上の特定デバイスｚとの適正化された組合せを決定するための、所定のコンピュータで実行可能なサービス配置選定プログラムであって、
   前記特定アプリｘと、前記特定デバイスｚとの組合せに関するデータ有効度期待値Ｊ（ｘ，ｚ）を算出する手順と、
   少なくとも前記データ有効度期待値Ｊ（ｘ，ｚ）と、前記特定コンピュータｙとをパラメータとして含む評価値Ｆ（ｘ，ｙ，ｚ）を計算する手順と、
   前記評価値Ｆ（ｘ，ｙ，ｚ）を利用して、前記特定アプリｘ、前記特定コンピュータｙ、および前記特定デバイスｚの組合せを選定する手順と、
   を有するサービス配置選定プログラム。

Images