JP6499622B2 - 事業者間一括サービス構築装置及び事業者間一括サービス構築方法 - Google Patents

Description

本発明は、卸サービス事業者毎に提供される１つの通信サービスを組合せた連携サービスを一括で構築し、保守及び運用を可能とする事業者間一括サービス構築装置及び事業者間一括サービス構築方法に関する。

現在、ネットワーク（ＮＷ）サービス、クラウドサービス、及びアプリケーション（ＡＰＬ）サービスといった各種サービスを提供している卸サービス事業者が出て来ている。これに伴い、エンドユーザにサービスを提供するサービス事業者は、自社で資産を保有せずに卸サービス事業者が提供するサービスを組合せてサービス事業者の独自サービスを提供する形態が出て来ている。ＮＷサービスは、広域Ｌ２（イーサネット「登録商標」）サービス、ＩＰ−ＶＰＮ(Internet Protocol Virtual Private Network)サービス、ＭＮＶＯ(Mobile Virtual Network Operator)等のネットワークを利用したサービスである。クラウドサービスは、ＩａａＳ(Infrastructure as a Service)基盤等によるサービスである。ＡＰＬサービスは、必要な通信に係る機能を必要な分だけサービスとして利用するようにしたソフトウェアの提供形態によるサービスである。

各々の卸サービス事業者は、１つの通信サービスをＡＰＩ（Application Programming Interface）で公開している。このため、ユーザに通信サービスを提供するサービス事業者が、例えばＮＷサービスの通信機能を使用したい場合は、ＮＷサービスを公開するＡＰＩにアクセスし、クラウドサービスの通信機能を使用したい場合はクラウドサービスを公開するＡＰＩにアクセスし、ＡＰＬサービスの通信機能を使用したい場合はＡＰＬサービスを公開するＡＰＩにアクセスするようになっている。このようにサービス事業者は、１つの卸サービス事業者が公開する１つの通信サービスを利用してユーザに提供している。

この種の技術として特許文献１に、ある通信ネットワーク内のセッション情報をＷｅｂサービスで容易に利用できるようにする技術が開示されている。
また、業界団体The Parlay GroupにてParlay X 2.0という規格が策定されており、第３者による呼制御（3rdParty Call Control）機能の端末機の位置情報に関する機能を、データ変換及びプロトコル変換し、ＡＰＩとして提供するＡＰＩ定義が定められている。

特開２００９−０４２８２９号公報

ところで、特許文献１の技術においては、単一の通信ＮＷの情報及び機能を情報システムから利用可能とする方式について述べられている。このような単一の通信ＮＷの情報及び機能である例えばＮＷサービスを、上述した規格のＡＰＩでサービス事業者に提供することは可能である。言い換えれば、個々の卸サービス事業者が公開する各通信サービスのＡＰＩを、サービス事業者が個別に利用することは可能である。しかし、ＮＷサービス、クラウドサービス及びＡＰＬサービス等の複数の通信サービスを連携させて一括でサービス事業者に提供することは現時点では行われていない。このため、サービス事業者が複数の通信サービスを一括で利用したい場合、複数の卸サービス事業者の各種通信サービスを手間暇かけて連携させて一括で利用する必要があった。

本発明は、このような事情に鑑みてなされたものであり、通信のサービス事業者のオーダ要求に応じて、複数の卸サービス事業者の各種通信サービスを組合せた連携サービスを一括で構築して提供することができる事業者間一括サービス構築装置及び事業者間一括サービス構築方法を提供することを課題とする。

上記課題を解決するための手段として、請求項１に係る発明は、ユーザに通信を提供する端末機からの通信サービス利用のためのオーダ要求に応じて、卸サービス事業者毎に通信サービスＡＰＩで公開される各々異なる１つの通信サービスを１又は複数一括して提供する事業者間一括サービス構築装置であって、通信の卸サービスの仕様が記述されたカタログと、各種の通信サービスの連携を定めた連携ルールとを保持し、前記端末機から複数の通信サービス利用のオーダ要求があった場合に、前記保持されたカタログ及び連携ルールに基づき、オーダ要求された複数の通信サービスに対応する前記通信サービスＡＰＩを一括に連携させて連携サービスを構築し、この構築された連携サービスを前記端末機へ提供する一括構築機能部と、前記連携サービスの構築時に、連携対象の通信サービスＡＰＩ毎に、当該通信サービスＡＰＩを制御するサーバ機能の監視項目における動的に決定される固有の値を、監視項目値としてリストに設定する監視項目値自動連携機能部とを備え、前記一括構築機能部は、前記各種の通信サービスが連携に必要な共通情報を持たない場合、当該共通情報を持たない通信サービスを提供する各通信サービスＡＰＩと、各通信サービスＡＰＩに個別に接続された各アダプタとの間に接続された各ゲートウェイに、前記連携サービスの構築時に動的に決まる調停情報としての同一ＩＤ（IDentifier）を用いて調停を行い、調停成立後に各通信サービスＡＰＩを紐付けて連携を取ることを特徴とする事業者間一括サービス構築装置である。

請求項５に係る発明は、ユーザに通信を提供する端末機からの通信サービス利用のためのオーダ要求に応じて、卸サービス事業者毎に通信サービスＡＰＩで公開される各々異なる１つの通信サービスを１又は複数一括して提供する事業者間一括サービス構築装置による事業者間一括サービス構築方法であって、前記事業者間一括サービス構築装置は、通信の卸サービスの仕様が記述されたカタログと、各種の通信サービスの連携を定めた連携ルールとを保持しており、前記端末機から複数の通信サービス利用のオーダ要求があった場合に、前記保持されたカタログ及び連携ルールに基づき、オーダ要求された複数の通信サービスに対応する前記通信サービスＡＰＩを一括に連携させて連携サービスを構築するステップと、前記構築された連携サービスを前記端末機へ提供するステップと、前記連携サービスの構築時に、連携対象の通信サービスＡＰＩ毎に、当該通信サービスＡＰＩを制御するサーバ機能の監視項目における動的に決定される固有の値を、監視項目値としてリストに設定するステップと、前記各種の通信サービスが連携に必要な共通情報を持たない場合、当該共通情報を持たない通信サービスを提供する各通信サービスＡＰＩと、各通信サービスＡＰＩに個別に接続された各アダプタとの間に接続された各ゲートウェイに、前記連携サービスの構築時に動的に決まる調停情報としての同一ＩＤ（IDentifier）を用いて調停を行い、調停成立後に各通信サービスＡＰＩを紐付けて連携を取るステップとを実行することを特徴とする事業者間一括サービス構築方法である。

請求項１の構成及び請求項５の方法によれば、通信のサービス事業者の端末機から複数の通信サービスを利用するためのオーダ要求に応じて、複数の卸サービス事業者の各種の通信サービスを組合せた連携サービスを一括で構築して提供することができる。このため、サービス事業者は複数の通信サービスを一括利用したい場合、卸サービス事業者の各種通信サービスを手間暇かけて連携させて一括で利用するといった必要が無くなり、簡単に複数の通信サービスを一括で利用することができる。また、監視項目のリストという具体的なＡＰＩができるので、このＡＰＩにアクセスして構築時の具体的な値である監視項目値を取得することができる。また、構築系機能から監視という保全系機能へ、構築時に決まった値（監視項目値）を自動的に引き継ぐことは今迄存在しなかったが、本実施形態では、監視項目値を自動的に引き継ぐことができる。

請求項２に係る発明は、前記監視項目値自動連携機能部は、前記連携サービスの構築時に、通信サービスＡＰＩを制御するサーバ機能の内の動的に決定される監視項目値を判別可能な監視項目リストを保持しておき、前記連携サービスの構築時に動的に決定された値が、当該監視項目リストから監視項目値と判別された際に、この判別された監視項目値を当該監視項目リストのＩＤとして登録することを特徴とする請求項１に記載の事業者間一括サービス構築装置である。

請求項３に係る発明は、前記一括構築機能部は、前記オーダ要求に基づく卸サービス事業者毎の複数の通信サービスＡＰＩの連携依頼時に、卸サービス事業者のサーバにアクセスして当該複数の通信サービスＡＰＩを連携させる前記各アダプタを有するアダプタ部を備えることを特徴とする請求項１に記載の事業者間一括サービス構築装置である。

請求項４に係る発明は、前記監視項目値を取得し、この取得された監視項目値で連携されている前記卸サービス事業者毎の通信サービスの固有情報を取得し、この取得された各固有情報を紐付けて連携固有情報として保持する一括監視機能部を更に備え、前記一括監視機能部は、前記保持された連携固有情報を前記端末機へ提供することにより、当該端末機に当該提供された連携固有情報で前記卸サービス事業者毎の通信サービスを一括監視可能とさせることを特徴とする請求項１〜３の何れか１項に記載の事業者間一括サービス構築装置である。

請求項６に係る発明は、前記事業者間一括サービス構築装置は、記監視項目値を取得し、この取得された監視項目値で連携されている前記卸サービス事業者毎の通信サービスの固有情報を取得し、この取得された各固有情報を紐付けて連携固有情報として保持するステップと、前記保持された連携固有情報を前記端末機へ提供することにより、当該端末機に当該提供された連携固有情報で前記卸サービス事業者毎の通信サービスを一括監視可能とさせるステップとを実行することを特徴とする請求項５に記載の事業者間一括サービス構築方法である。

請求項４の構成及び請求項６の方法によれば、サービス事業者は端末機により、利用中の複数の卸サービス事業者の通信サービスを一括監視することができる。

本発明によれば、通信のサービス事業者のオーダ要求に応じて、複数の卸サービス事業者の各種通信サービスを組合せた連携サービスを一括で構築して提供することができる事業者間一括サービス構築装置及び事業者間一括サービス構築方法を提供することができる。

本発明の実施形態に係る事業者間一括サービス構築装置を有する通信ネットワークシステムの構成を示すブロック図である。 事業者間一括サービス構築装置の構成を示すブロック図である。 （ａ）業務ＡＰＩ部に備えられるＡＰＩを示す図、（ｂ）シナリオ管理実行部に備えられるシナリオを示す図、（ｃ）は業務リソース管理部に備えられるカタログ及び連携ルールを示す図である。 事業者間一括サービス構築がカタログドリブンにより構築される概念を示すブロック図である。 事業者間一括サービス構築の概念を示すブロック図である。 事業者間一括サービス構築時に動的に決定される監視項目値を示す図である。 一括監視動作の第１の概念を示す図である。 一括監視動作の第２の概念を示す図である。 事業者間一括サービス構築の動作を説明するための第１のシーケンス図である。 事業者間一括サービス構築の動作を説明するための第２のシーケンス図である。 事業者間一括サービス構築の動作を説明するための第３のシーケンス図である。 事業者間一括サービス構築の動作を説明するための第４のシーケンス図である。 監視項目値自動連携の動作を説明するためのシーケンス図である。 一括監視の動作を説明するための第１のシーケンス図である。 一括監視の動作を説明するための第２のシーケンス図である。

以下、本発明の実施形態を、図面を参照して説明する。
＜実施形態の構成＞
図１は、本発明の実施形態に係る事業者間一括サービス構築装置を有する通信ネットワークシステムの構成を示すブロック図である。
図１に示す通信ネットワーク（ＮＷ）システム１０は、サービス事業者２０のパーソナルコンピュータ等の端末機２１と、事業者間一括サービス構築装置３０と、複数の卸サービス事業者４０，５０，６０のサーバ４１，５１，６１とが、ＧＷ（ゲートウェイ）７１，７２，７３，７４，７５，７６，７７，７８を介したＮＷ（ネットワーク）８１，８２，８３，８４で接続されて構成されている。なお、事業者間一括サービス構築装置３０を、一括サービス構築装置３０とも称す。

サービス事業者２０の端末機２１は、ＮＷ８１及びＧＷ７１を介して一括サービス構築装置３０に接続され、一括サービス構築装置３０は、ＮＷ８２及びＧＷ７２，７３，７４を介して各卸サービス事業者４０，５０，６０のサーバ４１，５１，６１に接続されている。卸サービス事業者４０，５０，６０間は、サーバ４１とサーバ５１とがＧＷ７５、ＮＷ８３及びＧＷ７６を介して接続され、サーバ５１とサーバ６１とがＧＷ７７、ＮＷ８４及びＧＷ７８を介して接続されている。

端末機２１と一括サービス構築装置３０間のＧＷ７１は、端末機２１からの通信サービスの注文であるオーダ要求が予め許可された要求か否かを判断する処理を行う。許可されたオーダ要求の場合、一括サービス構築装置３０は、そのオーダ要求に応じた１又は複数の通信サービスを取得する等の要求をサーバ４１，５１，６１へ送信する。
一括サービス構築装置３０と各卸サービス事業者４０，５０，６０間のＧＷ７２，７３，７４は、上記サーバ４１，５１，６１への要求が、予め許可された一括サービス構築装置３０からの要求であるか否かを判断する処理を行う。
各サーバ４１，５１，６１間のＧＷ７５〜７８は、各サーバ４１，５１，６１をＮＷ８３，８４で接続するための認証処理を行う。

各卸サービス事業者４０，５０，６０は、各々が異なる通信サービスをＡＰＩで公開している。卸サービス事業者４０のサーバ４１には、ＮＷサービスを公開するＮＷサービスＡＰＩ４１ａが搭載されている。卸サービス事業者５０のサーバ５１には、クラウドサービスを公開するクラウドサービスＡＰＩ５１ａが搭載されている。卸サービス事業者６０のサーバ６１には、ＡＰＬ（アプリケーション）サービスを公開するＡＰＬサービスＡＰＩ６１ａが搭載されている。

サービス事業者２０は、各卸サービス事業者４０，５０，６０が公開する各種の通信サービスを１又は複数利用して独自の通信サービスをユーザに提供する。サービス事業者２０が通信サービスを利用する場合、一括サービス構築装置３０に１又は複数の通信サービスを取得するためのオーダ要求を行って通信サービスを取得する。

一括サービス構築装置３０は、一括構築機能部３０ａと、監視項目値自動連携機能部（自動連携機能部ともいう）３０ｂと、一括監視機能部３０ｃとを備える。
一括構築機能部３０ａは、通信の卸サービスの仕様が記述されたカタログに基づく、連携させたい卸サービスの組合せと、各通信サービスのパラメータとなるインプットパラメータとの要求に応じて、各種通信サービスのＡＰＩ４１ａ，５１ａ，６１ａを統合的に制御することで、各種通信サービスを組合せた連携サービスを一括で構築する。

自動連携機能部３０ｂは、連携サービスの構築時に動的に決定される固有の値（後述）を監視項目に引き継ぐ処理を行う。
一括監視機能部３０ｃは、複数の卸サービス事業者４０，５０，６０の連携サービスとして構築された卸サービス状態情報を取得して監視する処理を行う。

一括サービス構築装置３０は、一括構築機能部３０ａ、自動連携機能部３０ｂ及び一括監視機能部３０ｃの各機能処理を実現するために、図２に示すように、業務ＡＰＩ部３１と、シナリオ管理実行部３２と、業務リソース管理部３３と、卸サービス事業者ＡＰＩアダプタ部（アダプタ部ともいう）３４とを備えて構成されている。

一括構築機能部３０ａは、業務ＡＰＩ部３１と、シナリオ管理実行部３２と、業務リソース管理部３３と、アダプタ部３４とを用いて後述の機能を実現する。自動連携機能部３０ｂは、シナリオ管理実行部３２と、業務リソース管理部３３と、アダプタ部３４とを用いて後述の機能を実現する。一括監視機能部３０ｃは、業務リソース管理部３３と、アダプタ部３４とを用いて後述の機能を実現する。

アダプタ部３４は、ＮＷサービス用アダプタ３４ａと、クラウドサービス用アダプタ３４ｂと、ＡＰＬサービス用アダプタ３４ｃとを備える。これらを単に、アダプタ３４ａ，３４ｂ，３４ｃともいう。

アダプタ３４ａはＮＷ搭載サーバ４１に接続され、アダプタ３４ｂはクラウド搭載サーバ５１に接続され、アダプタ３４ｃはＡＰＬ搭載サーバ６１に接続されている。但し、図２では、図１に示したＮＷ８２〜８４及びＧＷ７２〜７８は省略してある。また、業務ＡＰＩ部３１とサービス事業者２０の端末機２１間のＮＥ８１及びＧＷ７１も省略してある。

図３（ａ）に業務ＡＰＩ部３１に備えられるＡＰＩを示し、（ｂ）にシナリオ管理実行部３２に備えられるシナリオを示し、（ｃ）に業務リソース管理部３３に備えられるカタログ及び連携ルールを示す。

業務ＡＰＩ部３１は、カタログ管理ＡＰＩ３１ａ、サービスオーダ実行ＡＰＩ３１ｂ、トラブルチケット管理ＡＰＩ３１ｃ、ＳＬＡ（Service. Level Agreement）管理ＡＰＩ３１ｄ、性能管理ＡＰＩ３１ｅ、顧客管理ＡＰＩ３１ｆ、組織管理ＡＰＩ３１ｇ、利用状況管理ＡＰＩ３１ｈ、課金管理ＡＰＩ３１ｉ、サービス状態管理ＡＰＩ３１ｊ等のＡＰＩを備える。これらは単に、ＡＰＩ３１ａ〜３１ｊとも称す。

シナリオ管理実行部３２は、一括構築シナリオ３２ａ、監視項目値自動連携シナリオ３２ｂ、一括監視シナリオ３２ｃ、使用量確認機能シナリオ３２ｄ等を備える。これらは単に、シナリオ３２ａ〜３２ｄとも称す。各シナリオ３２ａ〜３２ｄは、ＡＰＩで実現される。

業務リソース管理部３３は、カタログ管理部３６及び連携ルール管理部３５を備える。カタログ管理部３６は、連携カタログとして、ＮＷサービスＡ−クラウドサービスＡカタログ３３ａ、ＮＷサービスＢ−クラウドサービスＡカタログ３３ｂ、ＮＷサービスＣ−クラウドサービスＢカタログ３３ｃ等を備える。また、通信サービスの元となるカタログとして、ＮＷサービスＡカタログ３３ｄ、クラウドサービスＡカタログ３３ｅ、ＮＷサービスＢカタログ３３ｆ、クラウドサービスＢカタログ３３ｇ等を備える。これらは単に、カタログ３３ａ〜３３ｇとも称す。各カタログ３３ａ〜３３ｇは、図示せぬメモリやハードディスク等の記憶装置に記憶されており、シナリオ管理実行部３２での実行処理時に用いられる。また、新規通信サービスの追加があった場合は、その追加サービスの内容がカタログで記述され、このサービス内容が記述されたカタログが追加されるようになっている。

連携ルール管理部３５は、ＮＷサービスＡ−クラウドサービスＡ連携ルール３５ａ、ＮＷサービスＡ−クラウドサービスＢ連携ルール３５ｂ、ＮＷサービスＢ−クラウドサービスＢ連携ルール３５ｃ、ＮＷサービスＢ−クラウドサービスＡ連携ルール３５ｄ等を備える。これらは単に、連携ルール３５ａ〜３５ｄとも称す。各連携ルール３５ａ〜３５ｄは図示せぬ記憶装置に記憶されており、シナリオ管理実行部３２での実行処理時に用いられる。

図２に示すように、業務ＡＰＩ部３１は、サービス事業者２０や図示せぬ他システムからのオーダ要求を受け付け、要求内容に応じたＡＰＩ３１ａ〜３１ｊ｛図３（ａ）｝の処理により、シナリオ管理実行部３２で適切なシナリオ３２ａ〜３２ｄが実行されるようにする。例えば、オーダ要求が複数の通信サービスの利用申込である場合、サービスオーダ実行ＡＰＩ３１ｂ｛図３（ａ）｝の処理により、一括構築シナリオ３２ａ｛図３（ａ）｝が実行されるようにする。

ここで、業務ＡＰＩ部３１に搭載されたカタログ管理ＡＰＩ３１ａは、カタログを作るためのＡＰＩである。本例では、ＮＷサービス、クラウドサービス、ＡＰＬサービス等の仕様を記述したカタログを作成する。このカタログは、例えばＮＷサービスＡであれば、どの値段で、どの地域で提供されており、サービススペックとして例えば音声サービスが可能といった内容が記載されている。

シナリオ管理実行部３２は、上述のオーダ要求に応じた業務シナリオの実行を管理する。例えば、業務ＡＰＩ部３１のサービスオーダ実行ＡＰＩ３１ｂで、サービス事業者２０からのオーダ要求（例えば、ＮＷサービス及びクラウドサービスの利用要求）に応じたサービスオーダが実行されると、一括構築シナリオ３２ａが用いられる。一括構築シナリオ３２ａは、ＮＷサービスＡ及びクラウドサービスＡを連携させるので、業務リソース管理部３３にアクセスしてＮＷサービスＡ−クラウドサービスＡカタログ３３ａ｛図３（ｃ）｝を取得する。この取得したカタログ３３ａのサービススペックを読み取り、どの様な内容を実行するかを一括構築シナリオ３２ａで判断する。この場合は、ＮＷサービス及びクラウドサービスの双方を連携させるといった判断となる。

シナリオ管理実行部３２は、その判断を基に、卸サービス事業者４０，５０のＮＷサービスＡＰＩ４１ａ及びクラウドサービスＡＰＩ５１ａに対して、上記双方のサービスが連携されるように、卸サービス事業者ＡＰＩアダプタ部３４に依頼する。アダプタ部３４は、ＮＷサービス用アダプタ３４ａ及びクラウドサービス用アダプタ３４ｂにより、卸サービス事業者４０，５０のサーバ４１，５１にアクセスして、ＮＷサービスＡＰＩ４１ａ及びクラウドサービスＡＰＩ５１ａの双方を連携させる。

この連携には、連携させたい各通信サービスが、連携に必要な共通情報を持たない場合、各通信サービスの調停を必要とする場合がある。各アダプタ３４ａ，３４ｂと各ＡＰＩ４１ａ，ＡＰＩ５１ａとの間には、ＧＷ７２，７３（図１参照）がある。各ＧＷ７２，７３を接続して連携する場合、例えば、ＮＷ方式の１つであるＶＬＡＮ（Virtual LAN）で接続する場合は、双方のＧＷ７２，７３に同じＶＬＡＮ ＩＤ（IDentifier）を設定する必要がある。これが各通信サービスの調停を行うことである。そのＩＤは、前述した連携サービスの構築時に動的に決定される値（固有値）であり、この値を調停情報として用いる。

調停は次のように行われる。即ち、シナリオ管理実行部３２が、一括構築シナリオ３２ａを基に、業務リソース管理部３３から調停の必要処理が書かれたＮＷサービスＡ−クラウドサービスＡ連携ルール３５ａを読み取り、この連携ルール３５ａを基に上記調停を実行して、ＮＷサービスとクラウドサービスの連携を取るようにアダプタ部３４を制御する。

次に、本実施形態の一括サービス構築装置３０の特徴処理機能（１）〜（４）について説明する。
（１）一括サービス構築装置３０は、業務リソース管理部３３に登録されたカタログ３３ａ〜３３ｇを起点として動くカタログドリブンにより、各種通信サービスの一括構築のための連携サービスを行う。例えば、図４に示すように、サービス事業者２０Ａが端末機２１Ａにより、ＮＷサービスＡ、クラウドサービスＡ、ＡＰＬサービスＡを連携させた連携サービスカタログＡの情報と、各通信サービスのパラメータとなるインプットパラメータとによるオーダ要求を一括サービス構築装置３０へ送信したとする。これにより、一括サービス構築装置３０では、業務リソース管理部３３内に示すように、ＮＷサービスＡカタログ、クラウドサービスＡカタログ、ＡＰＬサービスＡカタログを連携させた連携サービスカタログＡが登録される。

一方、サービス事業者２０Ｂが端末機２１Ｂにより、ＮＷサービスＡ、クラウドサービスＢ、ＡＰＬサービスＡを連携させた連携サービスカタログＢの情報と、その連携を示唆するインプットパラメータとによるオーダ要求を一括サービス構築装置３０へ送信したとする。これにより、一括サービス構築装置３０では、業務リソース管理部３３内に示すように、ＮＷサービスＡカタログ、クラウドサービスＢカタログ、ＡＰＬサービスＡカタログを連携させた連携サービスカタログＢが登録される。

この場合、図示左側の連携サービスカタログＡのクラウドサービスＡカタログを、クラウドサービスＢカタログに置き換えたい場合、右側のクラウドサービスＢカタログに置き換える処理を行えばよい。

また、連携サービスカタログＡを用いて通信サービスの一括構築を行えば、矢印Ｙ１で示すように、サービス事業者２０Ａは、ＮＷサービスＡ、クラウドサービスＡ、ＡＰＬサービスＡを連携させた連携サービスを利用することができる。一方、連携サービスカタログＢを用いて通信サービスの一括構築を行えば、矢印Ｙ２で示すように、サービス事業者２０Ｂは、ＮＷサービスＡ、クラウドサービスＢ、ＡＰＬサービスＡを連携させた連携サービスを利用することができる。

（２）一括構築機能部３０ａ（図１）が、図５に示すように、サービス事業者２０の端末機２１からのオーダ要求である連携サービスカタログ２３と、要求時のインプットパラメータ２４と、連携ルール３５ｒとを用いて複数の卸サービス事業者４０，５０，６０の各種通信サービスを連携して一括で構築する。

この一括構築は、サービス事業者２０の端末機２１からオーダ要求が有ると、図５に示すステップＳ１において、業務ＡＰＩ部３１（図２）がオーダチェックする。これは、オーダの書式や指定された連携サービスカタログ及びインプットパラメータ等が合っているか否かをチェックする処理である。

次に、ステップＳ２において、シナリオ管理実行部３２（図２）がオーダ抽出分解処理を行う。例えば、上記オーダ要求が、ＮＷサービスＡ＋クラウドサービスＡのオーダである場合、ＮＷサービスＡとクラウドサービスＡとを抽出して分解する処理を行う。次に、シナリオ管理実行部３２は、ステップＳ３において、オーダパラメータ補完を行う。オーダ要求の中に必要なパラメータが入っているので、ＮＷサービスＡ用のパラメータと、クラウドサービスＡ用のパラメータとを分解して設定する際に、必要なパラメータを補完して設定する。

次に、シナリオ管理実行部３２は、ステップＳ４において、卸サービス生成要求を行う。この要求は、アダプタ部３４（図２）に対して、ＮＷサービスＡオーダ要求及びクラウドサービスＡオーダ要求で、連携サービスを行うことを依頼するものである。

アダプタ部３４は、ステップＳ５において、卸サービス生成処理を行う。これは、アダプタ部３４が各卸サービス事業者４０，５０のサーバ４１，５１（図２）にアクセスして、ＮＷサービスＡＰＩ４１ａ及びクラウドサービスＡＰＩ５１ａで公開しているＮＷサービスＡ及びクラウドサービスＡを取得する。

ＮＷサービスＡでは、例えば、卸サービス事業者４０がＭＶＮＯ（仮想移動体通信事業者：Mobile Virtual Network Operator）のモバイルである場合に、ユーザ（サービス事業者２０に該当）からのＳＩＭ(Subscriber Identity Module Card)カードの購入が、オーダ要求となる。

クラウドサービスＡでは、メモリ４ＧＢ、ハードディスク容量１ＴＢのコンピュータリソースを構築して下さい、これに対してネットワークのルーツ設定は、ネットワークレスで誘導設定して下さい、ＶＰＮで繋ぎたいのでＶＰＮを設定して下さい、といった内容がオーダ要求となる。

また、上記ステップＳ５の連携サービスで、ステップＳ５ａに示すように、シナリオ管理実行部３２による調停処理が必要となるケースがある。つまり、ＮＷサービスＡとクラウドサービスＡとを紐付ける（連携する）ために調停処理が必要となる場合がある。これは、前述したように、各アダプタ３４ａ，３４ｂと各ＡＰＩ４１ａ，ＡＰＩ５１ａとの間のＧＷ７２，７３に、構築時に動的に決まる調停情報としての同一ＩＤを入れて調停を行う。ＧＷ７２，７３の調停情報が合えば各ＡＰＩ４１ａ，ＡＰＩ５１ａを紐付けて連携することができる。

このように、ステップＳ１〜Ｓ５，Ｓ５ａの一括構築機能部３０ａの処理により、サービス事業者２０がＮＷサービスＡとクラウドサービスＡとの連携サービスを使用したいといった簡単なオーダ要求で、複数卸サービス事業者間一括サービス構築（一括サービス構築）を実現可能となっている。

（３）自動連携機能部３０ｂ（図１）が一括サービス構築時に動的に決定される値（変数）を監視項目に引き継ぐ監視項目値自動連携の処理を行う。これは、上記構築時に動的に決定される値を監視項目の値に自動で引き継ぐことで、一括サービス構築を行う機能である建設系機能から、監視する機能の保全系機能への連携自動化を実現する処理である。

図６に枠５３で示すように、シナリオ管理実行部３２（図２）が、クラウドサービスＡの監視対象のＶＭ（仮想マシン）を立てたとする。この場合、卸サービス事業者５０のサーバ５１（図２）は、枠５４で示すように、監視項目としてのＣＰＵ使用率「／ｖｍ／｛ＩＤ｝／ｃｐｕ」、メモリ使用率「／ｖｍ／｛ＩＤ｝／ｍｅｍｏｒｙ」、ＨＤＤ使用率「／ｖｍ／｛ＩＤ｝／ｈｄｄ」を取得できるクラウドサービスＡＰＩ５１ａを公開していることが分かっている。各使用率のＩＤが、構築時に動的に決定される固有の監視項目値（変数）である。

しかし、各使用率の監視項目値（ＩＤ）は、構築時に決まるので事前には分からない。そこで、各使用率の数値の内、どこが監視項目値「ＩＤ」で、どこが固定値「ｖｍ／ｈｄｄ」であるかが判別可能なリストを、一括サービス構築装置３０の図示せぬ記憶装置に保持しておく。例えば、一括サービス構築時に、枠５５に示すように、動的に決定される値（ＩＤ）として、ＶＭ_aaaaが決まったとする。「aaaa」が監視項目値（ＩＤ）である。ここで、例えば「aaaa」を各使用率のＩＤに入れなさいといったルールが記載された連携ルール３５ｅが、連携ルール管理部３５｛図３（ｃ）｝に保持されているとする。

シナリオ管理実行部３２（図２）は、連携ルール３５ｅに従って、枠５６に示すように、各使用率のＩＤに「aaaa」を入れる。これによって、枠５６に示す監視項目リストという具体的なＡＰＩができる。このようにＡＰＩが作成された以降は、アダプタ部３４（図２）が、そのＡＰＩにアクセスすれば、構築時に動的に決定されるべき、監視項目値「aaaa」が取得できる。つまり、オーダ要求が同様な複数の通信サービスの連携要求であれば、シナリオ管理実行部３２は、監視項目リストに登録済みの監視項目値「aaaa」を取得して複数の通信サービスの監視を行えばよい。

（４）一括監視機能部３０ｃが、構築された複数の卸サービス事業者４０，５０，６０（図２）の卸サービス状態情報の取得を行う。従来は、各卸サービスを１つずつ作っていた場合、１つずつの監視を行っており、サービス事業者２０は、各卸サービスを１つずつ要求して取得していた。本実施形態では、一括監視機能部３０ｃが、監視項目値を取得し、この取得された監視項目値で連携されている卸サービス事業者４０，５０，６０毎の通信サービスの固有ＩＤを取得し、この取得された各固有ＩＤを紐付けて連携固有情報としての連携サービスＩＤとして保持する。一括監視機能部３０ｃは、その保持された連携固有情報を端末機２１へ提供することにより、当該端末機２１に、その提供された連携固有情報で卸サービス事業者４０，５０，６０毎の通信サービスを一括監視可能とさせるようになっている。

本実施形態では、図７に示すように、サービス事業者２０Ａが端末機２１Ａにより、ＮＷサービスＡ、クラウドサービスＡ、ＡＰＬサービスＡを連携させた連携サービスカタログＡの情報と、各通信サービスのパラメータとなるインプットパラメータとによるオーダ要求を一括サービス構築装置３０（図２）へ送信する。これにより、一括サービス構築装置３０の業務リソース管理部３３に登録された連携サービスカタログＡに応じて、各卸サービス事業者４０，５０，６０のＮＷサービスＡ、クラウドサービスＡ、ＡＰＬサービスＡが連携されて連携サービスとして一括構築される。この場合、ＮＷサービスＡの卸サービスＩＤ「１」と、クラウドサービスＡの卸サービスＩＤ「２」と、ＡＰＬサービスＡの卸サービスＩＤ「３」とが連携サービスＩＤ「aaa」で紐付けられて連携され、卸サービス状態情報として管理されている。なお、卸サービスＩＤは、請求項記載の通信サービスの固有情報である。なお、連携サービスＩＤは、請求項記載の連携固有情報である。

図８に示すように、サービス事業者２０Ａが端末機２１Ａにより、卸サービスの状態を要求（状態要求）する。この要求時には、連携サービスＩＤ「aaa」で紐づいている各卸サービスは、ＩＤ「１」、ＩＤ「２」、ＩＤ「３」と既に定まっている。このため、３つの卸サービスであるＮＷサービスＡ、クラウドサービスＡ、ＡＰＬサービスＡが一括サービス構築装置３０で取得（状態取得→状態応答）され、端末機２１Ａへ返信（状態応答）される。これにより、端末機２１Ａでは、ＮＷサービスＡ、クラウドサービスＡ、ＡＰＬサービスＡが一括で監視可能となる。

＜実施形態の動作＞
本実施形態の一括サービス構築装置３０による一括構築動作、監視項目値自動連携動作、一括監視動作を、図９〜図１５に示すシーケンス図を参照して説明する。

最初に、一括構築動作について説明する。
図９に示すステップＳ１１において、サービス事業者２０の端末機２１からオーダ要求としてＮＷサービス、クラウドサービス及びＡＰＬサービスの何れか複数を利用する際の構築要求が行われたとする。この構築要求は業務ＡＰＩ部３１に通知される。業務ＡＰＩ部３１は、ステップＳ１２において振分先決定の処理を行う。この処理は、通知された構築要求を各ＡＰＩ３１ａ〜３１ｊ｛図３（ａ）｝の何れの機能を使用するかを決定するものである。ここでは、サービスオーダ実行ＡＰＩ３１ｂ｛図３（ａ）｝を使用することに決定されたとする。業務ＡＰＩ部３１は、ステップＳ１３において、サービスオーダ要求を実行する。

業務ＡＰＩ部３１は、ステップＳ１４において、業務リソース管理部３３にオーダチェックルールの要求を行う。この要求に応じて、業務リソース管理部３３は、ステップＳ１５において、業務ＡＰＩ部３１にオーダチェックルールを通知する応答を行う。この応答を受けた業務ＡＰＩ部３１は、ステップＳ１６において、そのオーダチェックルールに基づき、上記構築要求が正しいか否かのオーダチェックを行う。このチェック結果が正しい場合、業務ＡＰＩ部３１は、ステップＳ１７において、サービスオーダ受領応答を生成し、ステップＳ１８において、ＨＴＴＰ(Hypertext Transfer Protocol)生成により構築要求が正しいことを知らせる応答情報を作成する。この応答情報を、ステップＳ１９において、構築受領応答として端末機２１へ返信する。

また、業務ＡＰＩ部３１は、上記ステップＳ１７のサービスオーダ受領応答の生成後に、ステップＳ２０において、業務リソース管理部３３にオーダ状態が上記構築要求であることの登録を行う。また、ステップＳ２１において、オーダリソース情報の登録を行う。次に、業務ＡＰＩ部３１は、ステップＳ２２においてシナリオを決定する。即ち、カタログ管理ＡＰＩ３１ａの各シナリオ３２ａ〜３２ｄ｛図３（ｂ）｝から何れのシナリオを使用するかを決定する。ここでは、一括構築シナリオ３２ａが決定されたとする。

業務ＡＰＩ部３１は、ステップＳ２３において、その一括構築シナリオ３２ａをシナリオ管理実行部３２で呼び出すための処理を行う。この処理に応じて、シナリオ管理実行部３２は、ステップＳ２４において、業務リソース管理部３３から一括構築シナリオ３２ａに応じたカタログを要求する。この要求されたカタログは、例えば、ＮＷサービスＡ−クラウドサービスＡカタログ３３ａ｛図３（ｃ）｝であるとする。次に、ステップＳ２５において、その要求に応じたカタログ３３ａが業務リソース管理部３３からシナリオ管理実行部３２へ通知される応答が行われる。シナリオ管理実行部３２は、ステップＳ２６において、その通知されたカタログ３３ａからＮＷサービスＡ−クラウドサービスＡを抽出するオーダ要求を発行した後、ステップＳ２７において、図５のステップＳ２に示したようにＮＷサービスＡとクラウドサービスＡとを分解するオーダ分解処理を行う。

次に、図１０に示すように、シナリオ管理実行部３２は、ステップＳ２８において、オーダチェック及び補完ルールの要求を業務リソース管理部３３に行う。業務リソース管理部３３は、ステップＳ２９において、補完ルールを含むオーダチェックルールを通知する応答を行う。ここで、シナリオ管理実行部３２は、ステップＳ３０において、オーダチェックルールを基に、上記ステップＳ２７で分解したオーダのチェック、即ち、ＮＷサービスＡオーダとクラウドサービスＡオーダのチェックを行う。このチェック結果が正しければ、ステップＳ３１において、分解したオーダの補完、即ち、ＮＷサービスＡオーダとクラウドサービスＡオーダの補完を行う。この補完後に、ステップＳ３２において、分解したオーダの同期、非同期の制御を行う。ここでは、例えば図５のステップＳ３に示したように、ＮＷサービスＡオーダとクラウドサービスＡオーダとが別々に処理される非同期制御が行われるとする。なお、同期制御は、例えばＮＷサービスＡオーダの作成処理を終えた後に、クラウドサービスＡオーダの作成処理を行うといった具合に処理順番が決まった制御である。

次に、図１０に示すステップＳ３３において、シナリオ管理実行部３２はアダプタ部３４（図２）における利用アダプタ３４ａ〜３４ｃを決定する。この後、ステップＳ３４〜Ｓ３６において、アダプタ部３４の上記決定された各アダプタ３４ａ〜３４ｃへ一括構築のための（連携のための）オーダ要求が行われる。この要求された各アダプタ３４ａ〜３４ｃでは、ステップＳ３７〜Ｓ３９において、抽出分解を行う。これは、連携のためのオーダ要求が、卸サービス事業者の公開するＡＰＩのルールに則った内容であり、このため、オーダ要求が、例えば、認証、オーダ、確認といった指示要求から成るので、それらを一旦抽出した後、分解するといった処理である。この抽出分解処理後、各アダプタ３４ａ〜３４ｃは、ステップＳ４０〜Ｓ４２において、卸サービス事業者４０，５０，６０の各ＡＰＩ４１ａ，５１ａ，６１ａ（図２）に対して、各通信サービスの連携のためのオーダ要求を実行する。

一方、シナリオ管理実行部３２は、上記ステップＳ３４〜Ｓ３６のオーダ要求実行後に、ステップＳ４３において、業務リソース管理部３３の該当箇所のオーダ状態の更新を行う。この更新を受けた業務リソース管理部３３は、ステップＳ４４においてリスナ検索を行う。このリスナ検索は、上記オーダ状態更新の通知を受けるユーザ（サービス事業者２０）が業務リソース管理部３３に事前登録されているので、この登録されたサービス事業者２０を検索することである。この検索後、業務リソース管理部３３は、ステップＳ４５において、サービス事業者２０のオーダ状態が更新されたことを業務ＡＰＩ部３１へ通知する。

業務ＡＰＩ部３１は、ステップＳ４６において、ＨＴＴＰ生成によりオーダ状態更新による通信サービスの構築状態の応答情報を作成する。この構築状態情報を、図１１に示すステップＳ４７において端末機２１へ通知する。

一方、卸サービス事業者４０，５０，６０のＡＰＩ４１ａ，５１ａ，６１ａは、上記ステップＳ４０〜Ｓ４２（図１０）の各通信サービスの連携のためのオーダ要求を受けると、各通信サービスの利用を連携させる。この後、ステップＳ４８〜Ｓ５０において、その連携を完了したことを示すオーダ完了応答を各アダプタ３４ａ〜３４ｃへ通知する。各アダプタ３４ａ〜３４ｃは、ステップＳ５１〜Ｓ５３において、そのオーダ完了応答をシナリオ管理実行部３２へ通知する。

シナリオ管理実行部３２は、ステップＳ５４において、オーダ完了の受領をチェックし、次に、ステップＳ５５において、オーダ調停処理チェックを行う。これは、各通信サービスの連携に当たって調停が必要であるか否かをチェックする処理である。調停が必要な場合、ステップＳ５６〜Ｓ５７において、アダプタ部３４に調停用オーダ要求を行う。これは、各通信サービスに対する必要数分繰り返して行われる。例えば、図５のステップＳ５ａに示したように、ＮＷサービスとクラウドサービスに対して調停が必要な場合は、アダプタ３４ａ，３４ｂに対して、調停用オーダ要求が行われる。

この場合、図１１に示すアダプタ３４ａ，３４ｂが、ステップＳ５８，Ｓ５９において、調停用オーダ要求の抽出分解処理を行った後、ステップＳ６０，Ｓ６１において、卸サービス事業者４０，５０，６０の各ＡＰＩ４１ａ，５１ａに対して調停のオーダ要求を行う。ＡＰＩ４１ａ，５１ａは、その調停のオーダ要求を受けると、通信サービスの連携の調停を行う。この調停後、ステップＳ６２，Ｓ６３において、調停を完了したことを示すオーダ完了応答を各アダプタ３４ａ，３４ｂへ通知する。

各アダプタ３４ａ，３４ｂは、図１２に示すステップＳ６４，Ｓ６５において、調停用オーダ完了応答をシナリオ管理実行部３２へ通知する。シナリオ管理実行部３２は、ステップＳ６６において、その調停のオーダ完了の受領をチェックし、チェック結果が適正であれば、ステップＳ６７においてオーダ完了の応答を作成し、ステップＳ６８において、各通信サービスを連携して一括構築したことを示す構築サービスリソース登録を業務リソース管理部３３に通知する。業務リソース管理部３３は、ステップＳ６９において、その通知されたリソースを登録し、ステップＳ７０において、その登録したことを示す構築サービスリソース登録応答をシナリオ管理実行部３２へ返す。シナリオ管理実行部３２は、ステップＳ７１において、一括構築のオーダ状態が完了したことを業務リソース管理部３３に登録するように通知する。

この完了登録の通知を受けた業務リソース管理部３３は、ステップＳ７２において、リスナ検索、即ち該当のサービス事業者２０を検索する。この検索後、業務リソース管理部３３は、ステップＳ７３において、サービス事業者２０のオーダ要求に応じた複数通信サービスの一括構築による提供が完了したことを示すオーダ状態通知を業務ＡＰＩ部３１へ行う。

業務ＡＰＩ部３１は、ステップＳ７４において、ＨＴＴＰ生成によりオーダ状態通知による複数通信サービスの構築の完了情報を作成する。この構築完了情報をステップＳ７５において端末機２１へ通知する。これによって、サービス事業者２０が複数通信サービスを一括で利用可能となる。

次に、監視項目値自動連携動作について説明する。
図１３に示すステップＳ７６において、シナリオ管理実行部３２は、上記ステップＳ１１〜Ｓ７５の一括構築機能実施後に、監視項目値自動連携機能を自動で呼び出す。即ち、ステップＳ７７において、一括構築機能実施完了に引き継ぎ監視項目値自動連携シナリオ３２ｂ｛図３（ｂ）｝を検索し、ステップＳ７８において、監視項目値自動連携シナリオ（監視項目連携シナリオ）３２ｂを呼び出す。次に、ステップＳ７９において、その呼び出したシナリオ３２ｂで、業務リソース管理部３３に対して構築サービスリソース要求を行う。

この要求は、前述の連携サービス一括構築時に動的に決定される固有の監視項目値（例えば「aaaa」）（図６参照）が業務リソース管理部３３に保持されているので、その監視項目値「aaaa」を要求することである。また、シナリオ管理実行部３２は、ステップＳ８０において、監視項目値自動連携の処理に必要な、通信の卸サービスの仕様が記述されたカタログを検索し、ステップＳ８１において、その検索したカタログを業務リソース管理部３３に要求する。

また、シナリオ管理実行部３２は、ステップＳ８２において、ＳＬＡ検索を行う。このＳＬＡ検索は、上記要求したカタログ中の監視項目値の要求項目を検索することである。その検索後に、ステップＳ８３において、監視項目値の要求のためのＳＬＡ要求を業務リソース管理部３３に行う。

次に、シナリオ管理実行部３２は、ステップＳ８４において、監視項目の検索を行う。これは、例えば図６に枠５４で示した卸サービス事業者５０のサーバ５１のＣＰＵ使用率「／ｖｍ／｛ＩＤ｝／ｃｐｕ」、メモリ使用率「／ｖｍ／｛ＩＤ｝／ｍｅｍｏｒｙ」、ＨＤＤ使用率「／ｖｍ／｛ＩＤ｝／ｈｄｄ」の監視項目を検索することである。次に、図１３に示すステップＳ８５において、その検索された監視項目の値の設定要求を業務リソース管理部３３に行う。業務リソース管理部３３は、ステップＳ８６において、監視項目値の設定を行う。これは、例えばシナリオ管理実行部３２が、図６の枠５６に示したように、各使用率のＩＤに「aaaa」を入れることである。この設定後に、図１３のステップＳ８７において、業務リソース管理部３３からシナリオ管理実行部３２に対して、監視項目値設定完了応答が行われる。これによって、監視項目値自動連携動作が完了する。

次に、一括監視動作について説明する。
図１４に示すステップＳ８８において、シナリオ管理実行部３２は、定期的に一括監視機能を自動で呼び出す。即ち、ステップＳ８９において、一括監視シナリオ３２ｃ｛図３（ｃ）｝を呼出し、ステップＳ９０において、上記ステップＳ８６で設定された監視項目値の取得の要求を業務リソース管理部３３に行う。

業務リソース管理部３３は、ステップＳ９１において、監視項目値「aaaa」を検索し、この検索した監視項目値「aaaa」を、ステップＳ９２において、シナリオ管理実行部３２へ通知する応答を行う。

シナリオ管理実行部３２は、ステップＳ９３において、一括構築シナリオ３２ａにより一括監視の実行を要求する。この要求により、ステップＳ９４において、監視項目値「aaaa」の分解を行う。この場合、上述した各使用率の監視項目に分解される。この分解に応じて、ステップＳ９５において、アダプタ部３４の利用アダプタ３４ａ〜３４ｃを決定する。

この決定後、シナリオ管理実行部３２は、ステップＳ９６〜Ｓ９８において、アダプタ部３４の上記決定された各アダプタ３４ａ〜３４ｃへ一括監視のための監視要求を行う。この要求された各アダプタ３４ａ〜３４ｃでは、ステップＳ９９〜Ｓ１０１において、前述した抽出分解を行う。この抽出分解処理後、各アダプタ３４ａ〜３４ｃは、ステップＳ１０２〜Ｓ１０４において、卸サービス事業者４０，５０，６０の各ＡＰＩ４１ａ，５１ａ，６１ａ（図２）に対して、一括監視を実行する。

一方、図１５に示すステップＳ１０５〜Ｓ１０７において、卸サービス事業者４０，５０，６０のＡＰＩ４１ａ，５１ａ，６１ａは、一括監視を実行したことを示す監視応答を各アダプタ３４ａ〜３４ｃへ通知する。各アダプタ３４ａ〜３４ｃは、ステップＳ１０８〜Ｓ１１０において、その監視完了応答をシナリオ管理実行部３２へ通知する。

シナリオ管理実行部３２は、ステップＳ１１１において、監視実行完了の応答を生成し、ステップＳ１１２において、構築サービス紐付処理を行う。これは、卸サービス事業者４０，５０，６０の各ＡＰＩ４１ａ，５１ａ，６１ａから通知された図８に示すＮＷサービスＡの卸サービスＩＤ「１」と、クラウドサービスＡの卸サービスＩＤ「２」と、ＡＰＬサービスＡの卸サービスＩＤ「３」とを紐付けて連携サービスＩＤ「aaa」とする処理である。この紐付けにより得られた連携サービスＩＤ「aaa」は、監視実行値となる。図１５に示すシナリオ管理実行部３２は、ステップＳ１１３において、監視実行値の登録要求を業務リソース管理部３３に行う。

業務リソース管理部３３は、ステップＳ１１４において、監視実行値を登録し、ステップＳ１１５において、監視実行値登録完了応答をシナリオ管理実行部３２に行う。これによって、一括監視動作が完了する。

＜実施形態の効果＞
以上説明したように、本実施形態の事業者間一括サービス構築装置３０を、次のような特徴構成とした。一括サービス構築装置３０は、ユーザに通信を提供するサービス事業者２０の端末機２１からの通信サービス利用のためのオーダ要求に応じて、卸サービス事業者４０，５０，６０毎に通信サービスＡＰＩ４１ａ，５１ａ，６１ａで公開される各々異なる１つの通信サービスを１又は複数一括して提供する。各々異なる通信サービスは、ＮＷサービス、クラウドサービス及びＡＰＬサービス等である。

（１）通信の卸サービスの仕様が記述されたカタログと、各種の通信サービスの連携を定めた連携ルールとを保持し、端末機２１から複数の通信サービス利用のオーダ要求があった場合に、保持されたカタログ及び連携ルールに基づき、当該オーダ要求された複数の通信サービスに対応する通信サービスＡＰＩを一括に連携させて連携サービスを構築し、この構築された連携サービスを端末機２１へ提供する一括構築機能部３０ａを備える構成とした。

この構成によれば、通信のサービス事業者２０の端末機２１から複数の通信サービスを利用するためのオーダ要求に応じて、複数の卸サービス事業者４０，５０，６０の各種の通信サービスを組合せた連携サービスを一括で構築して提供することができる。このため、サービス事業者２０は複数の通信サービスを一括利用したい場合、卸サービス事業者４０，５０，６０の各種通信サービスを手間暇かけて連携させて一括で利用するといった必要が無くなり、簡単に複数の通信サービスを一括で利用することができる。

（２）一括サービス構築装置３０は、連携サービスの構築時に、当該連携対象の通信サービスＡＰＩ４１ａ，５１ａ，６１ａ毎に、当該ＡＰＩを制御するサーバ機能の監視項目における動的に決定される固有の値を、監視項目値としてリストに設定する監視項目値自動連携機能部３０ｂを更に備える構成とした。

この構成によれば、監視項目のリスト（監視項目リスト）という具体的なＡＰＩができるので、このＡＰＩにアクセスして構築時の具体的な値である監視項目値を取得することができる。また、構築系機能から監視という保全系機能へ、構築時に決まった値（監視項目値）を自動的に引き継ぐことは今迄存在しなかったが、本実施形態では、監視項目値を自動的に引き継ぐことができる。

（３）一括サービス構築装置３０は、監視項目値を取得し、この取得された監視項目値で連携されている卸サービス事業者４０，５０，６０毎の通信サービスの固有情報を取得し、この取得された各固有情報を紐付けて連携固有情報として保持する一括監視機能部３０ｃを更に備える。一括監視機能部３０ｃは、保持された連携固有情報を端末機２１へ提供することにより、当該端末機２１に当該提供された連携固有情報で卸サービス事業者４０，５０，６０毎の通信サービスを一括監視可能とさせる構成とした。

この構成によれば、サービス事業者２０は端末機２１により、利用中の複数の卸サービス事業者４０，５０，６０の通信サービスを一括監視することができる。

その他、具体的な構成について、本発明の主旨を逸脱しない範囲で適宜変更が可能である。

１０ 通信ネットワークシステム
２０ サービス事業者
２１ 端末機
３０ 事業者間一括サービス構築装置
３０ａ 一括構築機能部
３０ｂ 監視項目値自動連携機能部
３０ｃ 一括監視機能部
３１ 業務ＡＰＩ部
３２ シナリオ管理実行部
３２ａ 一括構築シナリオ
３２ｂ 監視項目値自動連携シナリオ
３２ｃ 一括監視シナリオ
３２ｄ 使用量確認機能シナリオ
３３ 業務リソース管理部
３４ 卸サービス事業者ＡＰＩアダプタ部
３４ａ ＮＷサービス用アダプタ
３４ｂ クラウドサービス用アダプタ
３４ｃ ＡＰＬサービス用アダプタ
４０，５０，６０ 卸サービス事業者
４１，５１，６１ サーバ
４１ａ ＮＷサービスＡＰＩ
５１ａ クラウドサービスＡＰＩ
６１ａ ＡＰＬ（アプリケーション）サービスＡＰＩ
７１，７２，７３，７４，７５，７６，７７，７８ ＧＷ（ゲートウェイ）
８１，８２，８３，８４ ＮＷ（ネットワーク）

Claims (6)

1. ユーザに通信を提供する端末機からの通信サービス利用のためのオーダ要求に応じて、卸サービス事業者毎に通信サービスＡＰＩで公開される各々異なる１つの通信サービスを１又は複数一括して提供する事業者間一括サービス構築装置であって、
   通信の卸サービスの仕様が記述されたカタログと、各種の通信サービスの連携を定めた連携ルールとを保持し、前記端末機から複数の通信サービス利用のオーダ要求があった場合に、前記保持されたカタログ及び連携ルールに基づき、オーダ要求された複数の通信サービスに対応する前記通信サービスＡＰＩを一括に連携させて連携サービスを構築し、この構築された連携サービスを前記端末機へ提供する一括構築機能部と、
   前記連携サービスの構築時に、連携対象の通信サービスＡＰＩ毎に、当該通信サービスＡＰＩを制御するサーバ機能の監視項目における動的に決定される固有の値を、監視項目値としてリストに設定する監視項目値自動連携機能部と
   を備え、
   前記一括構築機能部は、
   前記各種の通信サービスが連携に必要な共通情報を持たない場合、当該共通情報を持たない通信サービスを提供する各通信サービスＡＰＩと、各通信サービスＡＰＩに個別に接続された各アダプタとの間に接続された各ゲートウェイに、前記連携サービスの構築時に動的に決まる調停情報としての同一ＩＤ（IDentifier）を用いて調停を行い、調停成立後に各通信サービスＡＰＩを紐付けて連携を取る
   ことを特徴とする事業者間一括サービス構築装置。
2. 前記監視項目値自動連携機能部は、
   前記連携サービスの構築時に、通信サービスＡＰＩを制御するサーバ機能の内の動的に決定される監視項目値を判別可能な監視項目リストを保持しておき、前記連携サービスの構築時に動的に決定された値が、当該監視項目リストから監視項目値と判別された際に、この判別された監視項目値を当該監視項目リストのＩＤとして登録する
   ことを特徴とする請求項１に記載の事業者間一括サービス構築装置。
3. 前記一括構築機能部は、前記オーダ要求に基づく卸サービス事業者毎の複数の通信サービスＡＰＩの連携依頼時に、卸サービス事業者のサーバにアクセスして当該複数の通信サービスＡＰＩを連携させる前記各アダプタを有するアダプタ部
   を備えることを特徴とする請求項１に記載の事業者間一括サービス構築装置。
4. 前記監視項目値を取得し、この取得された監視項目値で連携されている前記卸サービス事業者毎の通信サービスの固有情報を取得し、この取得された各固有情報を紐付けて連携固有情報として保持する一括監視機能部
   を更に備え、
   前記一括監視機能部は、前記保持された連携固有情報を前記端末機へ提供することにより、当該端末機に当該提供された連携固有情報で前記卸サービス事業者毎の通信サービスを一括監視可能とさせる
   ことを特徴とする請求項１〜３の何れか１項に記載の事業者間一括サービス構築装置。
5. ユーザに通信を提供する端末機からの通信サービス利用のためのオーダ要求に応じて、卸サービス事業者毎に通信サービスＡＰＩで公開される各々異なる１つの通信サービスを１又は複数一括して提供する事業者間一括サービス構築装置による事業者間一括サービス構築方法であって、
   前記事業者間一括サービス構築装置は、
   通信の卸サービスの仕様が記述されたカタログと、各種の通信サービスの連携を定めた連携ルールとを保持しており、
   前記端末機から複数の通信サービス利用のオーダ要求があった場合に、前記保持されたカタログ及び連携ルールに基づき、オーダ要求された複数の通信サービスに対応する前記通信サービスＡＰＩを一括に連携させて連携サービスを構築するステップと、
   前記構築された連携サービスを前記端末機へ提供するステップと、
   前記連携サービスの構築時に、連携対象の通信サービスＡＰＩ毎に、当該通信サービスＡＰＩを制御するサーバ機能の監視項目における動的に決定される固有の値を、監視項目値としてリストに設定するステップと、
   前記各種の通信サービスが連携に必要な共通情報を持たない場合、当該共通情報を持たない通信サービスを提供する各通信サービスＡＰＩと、各通信サービスＡＰＩに個別に接続された各アダプタとの間に接続された各ゲートウェイに、前記連携サービスの構築時に動的に決まる調停情報としての同一ＩＤ（IDentifier）を用いて調停を行い、調停成立後に各通信サービスＡＰＩを紐付けて連携を取るステップと
   を実行することを特徴とする事業者間一括サービス構築方法。
6. 前記事業者間一括サービス構築装置は、
   前記監視項目値を取得し、この取得された監視項目値で連携されている前記卸サービス事業者毎の通信サービスの固有情報を取得し、この取得された各固有情報を紐付けて連携固有情報として保持するステップと、
   前記保持された連携固有情報を前記端末機へ提供することにより、当該端末機に当該提供された連携固有情報で前記卸サービス事業者毎の通信サービスを一括監視可能とさせる
   ステップと
   を実行することを特徴とする請求項５に記載の事業者間一括サービス構築方法。

Images