JP6463702B2 - サービス予約装置およびサービス予約方法 - Google Patents

Description

本発明は、複数のネットワークサービスを組み合わせたサービスの提供に関する。

動画配信サービス等の複数のネットワークサービスが組み合わされて提供されるサービスは、組み合わされるネットワークサービスの構成や価格、ＳＬＡ（Service Level Agreement：サービス品質保証）に基づいて、様々なネットワークサービスが組み合わされて提供されている。
例えば、特許文献１には、所望の通信のサービス品質（ＱｏＳ：Quality of Service）レベルを選択し、ＱｏＳパラメータを満たすために必要なネットワークサービス（リソース）の予約を行って、マルチメディアストリームの配信を行うサービスを提供することが開示されている。

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

上記の先行技術によれば、サービスに適したリソース予約が可能となる。
しかし、ネットワーク事業者が、サービス事業者に、複数のネットワークサービスを組み合わせてサービス提案を行うような場合には、複数のネットワーク（以下、ＮＷと記す場合がある）構成案を提案する場合が多く、それぞれのＮＷ構成で提供するサービス提供性を担保するためには、提案前に全てのネットワークサービス（リソース）の予約を行う必要がある。

このため、採用される可能性が低いネットワークサービス（リソース）も予約占有することになり、必要なネットワークサービス（リソース）容量が大きくなる。このため、場合によっては、同時に提案可能なＮＷ構成案が制限されたり、提案可能なサービス事業者の数に影響することがある。
また、提案するサービス事業者数やＮＷ構成案の数に比例してネットワークサービス（リソース）予約数が増大し、ＮＷ事業者の申込みオペレーションシステム（以下、ＯｐＳ：Operation Systemと記す場合がある）の処理負荷が大きくなる問題がある。

本発明の目的は、ネットワークサービスの予約時の使用可能性の低いリソースの占有やＮＷ事業者のＯｐＳの処理負荷の増大を回避して、サービス（リソース）予約を可能とするサービス予約装置やサービス予約方法を提供することにある。

前記課題を解決するため、請求項１に記載のサービス予約装置は、複数のネットワークサービスから構成される提案サービスの構成情報が入力される提案構成入力部と、前記構成情報とネットワークサービスの利用の見込み率に基づいてネットワークサービスの予約必要数を求めるサービス予約必要数計算部と、前記予約必要数と累積予約必要数とからネットワークサービスの追加予約を判断するサービス追加予約判断部と、前記サービス追加予約判断部の判断に基づいてネットワークサービスを制御するオペレーションシステムに追加のサービス予約を行うサービスオーダ処理部を備えるようにした。
これにより、ネットワークサービスの利用の見込み率によりサービス予約の予約必要数を求めて追加予約されるので、サービス予約に無用な予約が低減し、サービス予約の予約占有を小さくすることができる。また、サービス予約の回数が減るので、申込ＯｐＳの処理負荷を低減できる。

また、請求項２に記載のサービス予約装置は、ネットワークサービス毎に前記累積予約必要数を記憶する予約管理情報記憶部を備え、前記累積予約必要数は、前記予約必要数が加算されて更新されるようにした。
これにより、既に予約したネットワークサービスの数を管理することができる。

また、請求項３に記載のサービス予約装置は、前記サービス予約必要数計算部は、サービス事業者ごとの成約確率または構成の提案優先度の少なくとも一方を前記見込み率として、前記予約必要数を求めるようにした。
これにより、予約を行うネットワークサービスの使用の見込み数の精度が向上する。

また、請求項４に記載のサービス予約装置は、前記サービス予約必要数計算部が、サービス事業者ごとの成約確率と構成の提案優先度との積を前記見込み率とし、前記予約必要数を求め、前記累積予約必要数に前記予約必要数を加算した値を整数値に切り上げた値と、前記予約必要数を加算する前の前記累積予約必要数を整数値に切り上げた値との差を求めて、サービス予約の追加数とするようにした。
これにより、予約単位を個数とするネットワークサービスにおいても、無用なサービス予約を少なくすることができる。

また、請求項５に記載のサービス予約方法は、複数のネットワークサービスから構成されるサービスの構成情報が入力されるステップと、前記構成情報のネットワークサービス毎に、サービス事業者の成約確率と、構成の提案優先度の積を求めて予約必要数を算出するステップと、累積予約必要数に前記予約必要数を加算した値を整数値に切り上げた値と、前記予約必要数を加算する前の前記累積予約必要数の値を整数値に切り上げた値との差を求めて、サービス予約の追加のサービス数を求めるステップと、前記ネットワークサービスの制御部にサービス予約を追加するステップを含むようにした。
これにより、サービス事業者の成約確率と構成の提案優先度の積を求めてサービス予約の予約必要数を求めて追加予約を行うので、サービス予約の無用な予約を少なくし、サービス予約の予約占有を小さくすることができる。また、サービス予約の回数が減るので、申込ＯｐＳの処理負荷が低減する。

また、請求項６に記載のサービス予約方法は、前記累積予約必要数に前記予約必要数を加算して、前記累積予約必要数を更新するステップを含むようにした。
これにより、既に予約したネットワークサービスの数を管理することができる。

本発明によれば、サービス（リソース）を提供するネットワーク事業者の負荷を低減し、ネットワークサービスの提案に係るサービス（リソース）予約を容易に行うことができる。

実施形態のサービス予約装置が適用されるサービス予約システムの構成を示す図である。 サービスの提案構成の一例を説明する図である。 サービス予約システムの比較例の全体シーケンス図である。 実施形態のサービス予約システムの全体シーケンス図である 実施形態のサービス予約装置の構成を示す図である。 成約確率情報の構成を示す図である。 累積予約必要数の構成を示す図である。 ネットワークサービスの予約必要数の算出処理を説明する図である。 ネットワークサービスの追加予約数の算出処理を説明する図である。 サービス予約処理のフロー図である。

以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
図１は、実施形態のサービス予約装置１が適用されるサービス予約システムの構成を示す図である。
ＮＷ構成提案装置２は、サービス事業者に複数のネットワークワービスから構成されるサービスの提案を行う際に、提案するＮＷ構成情報を入力し、サービス予約を行う端末である。

サービス１申込ＯｐＳ３ａとサービス２申込ＯｐＳ３ｂとサービス３申込ＯｐＳ３ｃは、ネットワークサービスを提供するネットワーク事業者のＯｐＳであり、ネットワークサービスの在庫確認や利用予約や利用申込を処理するシステムになっている。以下、サービス１申込ＯｐＳ３ａとサービス２申込ＯｐＳ３ｂとサービス３申込ＯｐＳ３ｃを総称して、サービス申込ＯｐＳ３と記すことがある。

実施形態のサービス予約装置１は、ＮＷ構成提案装置２から、サービス事業者１のサービスの提案構成やサービス事業者２のサービスの提案構成やサービス事業者３のサービスの提案構成が入力され、それぞれの提案構成に基づいて、提案構成に含まれるネットワークサービスの在庫確認と予約とを行う。そして、サービス事業者への提案が成約した際には、提案構成のネットワークサービスの申込が行われる。
提案の段階で、サービス予約装置１が提案構成によりネットワークサービスの予約を行うことで、サービスの提供可能性を担保している。

つぎに、図２により、サービスの提案構成の一例を説明する。
図２（ａ）は、サービス事業者１向けの提案ＮＷ構成を示している。提案には、案１と案２の２つのＮＷ構成が含まれている。具体的には、案１では、Ａ−Ｂの区間では通信回線によるサービス１を実施し、Ｂ−Ｃの区間では通信回線によるサービス２を実施する提案となっている。また、案２では、Ａ−Ｂの区間では通信回線によるサービス１を実施し、Ｂ−Ｃの区間では通信回線によるサービス３を実施する提案となっている。

図２（ｂ）は、サービス事業者２向けの提案ＮＷ構成を示し、図２（ｃ）は、サービス事業者３向けの提案ＮＷ構成を示している。提案するネットワーク構成は、図２（ａ）の構成と同じ構成が提案されるものとする。もちろん、他のネットワーク構成であってもよい。

ここで、サービス予約装置１が、後述する実施形態と異なる他のサービス予約処理を行う例を、比較例として、図２のサービスの提案構成に基づいて説明する。
図３は、サービス予約システムの比較例の全体シーケンス図である。図３のサービス予約装置１は、ＮＷ構成提案装置２からサービスの提案構成が入力され、それぞれの提案構成に定義されているネットワークサービスに基づいて、ネットワークサービスを提供するネットワーク事業者のサービス申込ＯｐＳのそれぞれに、サービス予約を行う。

詳しくは、サービス予約装置１は、図２（ａ）に示したサービス事業者１向けＮＷ提案構成を受信する（Ｓ３０１）。そして、サービス事業者１向けＮＷ提案構成の案１に定義されているサービス１を提供するネットワーク事業者のサービス１申込ＯｐＳ３ａに、サービス予約を通知する（Ｓ３０２）。つぎに、案１のサービス２について、サービス２申込ＯｐＳ３ｂにサービス予約を通知する（Ｓ３０３）。
案２についても、サービス１申込ＯｐＳ３ａにサービス１に対応するサービス予約を行い（Ｓ３０４）、サービス３申込ＯｐＳ３ｃにサービス３に対応するサービス予約を行う（Ｓ３０５）。

サービス予約装置１が、図２（ｂ）に示したサービス事業者２向けＮＷ提案構成を受信すると（Ｓ３０６）、サービス事業者２向けＮＷ提案構成に定義されているサービス１、２、３のそれぞれサービスについて、サービス申込ＯｐＳに対してサービス予約を行う（Ｓ３０７〜Ｓ３１０）。
サービス予約装置１が、図２（ｃ）に示したサービス事業者３向けＮＷ提案構成を受信すると（Ｓ３１１）、サービス事業者３向けＮＷ提案構成に定義されているサービス１、２、３のそれぞれサービスについて、サービス申込ＯｐＳに対してサービス予約を行う（Ｓ３１２〜Ｓ３１５）。

このように、比較例のサービス予約装置１では、サービスの提案構成に定義されるネットワークサービスのそれぞれについて、サービス予約を行っている。
しかし、サービス事業者１、２、３への全ての提案が成約しない場合もある。また、成約できたとしても、案１と案２のいずれかの構成が採用される。つまり、サービス予約が過多な状態となっている。

このため、サービス予約がネットワーク事業者のサービス提供容量を超える場合もある。この場合には、サービス予約を受付できなくなり、サービス事業者への提案機会の損失になってしまう。
また、過多なサービス予約は、ネットワーク事業者のサービス申込ＯｐＳの処理負荷となるとともに、ネットワーク事業者の設備過剰にも繋がる。

これに対して、本実施形態のサービス予約装置１は、サービス事業者ごとの提案の成約確率情報と、ＮＷ構成の提案優先度を設けて、必要なサービス予約のみを行うようにしたものである。
これにより、サービス予約数を大幅に削減することができる。

図４は、本実施形態のサービス予約システムの全体シーケンス図である。図４のサービス予約装置１は、ＮＷ構成提案装置２からサービスのＮＷ提案構成が入力されると、提案構成に定義されているネットワークサービスを基に、必要なサービス予約数を計算し、追加するサービス予約を判定する。そして、判定したネットワークサービスを提供するネットワーク事業者のサービス申込ＯｐＳに、サービス予約を行う。

詳しくは、サービス予約装置１は、図２（ａ）に示したサービス事業者１向けＮＷ提案構成を受信する（Ｓ４０１）。そして、サービス予約装置１は、図２（ｂ）に示したサービス事業者２向けＮＷ提案構成を受信し（Ｓ４０２）、サービス予約装置１は、図２（ｃ）に示したサービス事業者３向けＮＷ提案構成を受信する（Ｓ４０３）。

以上の、シーケンスＳ４０１，Ｓ４０２，Ｓ４０３により、同時に提案するサービス事業者向けのＮＷ構成情報が入力された後に、入力されたＮＷ構成に基づいて、サービス事業者ごとの提案の成約確率情報とＮＷ構成の提案優先度を参照して、サービス予約の予約必要数を計算し、追加するサービス予約を判定する（Ｓ４０４）。そして、必要なサービス予約のみを行うようにした（Ｓ４０５）。なお、図４のシーケンスＳ４０５では、サービス１申込ＯｐＳ３ａにのみサービス予約を通知しているが、これに限定されず、シーケンスＳ４０４の判定結果に応じて、サービス予約が通知されるサービス申込ＯｐＳは変わる。
シーケンスＳ４０４の詳細は後述する。

本実施形態のサービス予約装置１により、使用される可能性の高い必要最低限のサービス予約を行うことで、使用可能性の低いネットワークサービスの占有を回避し、また、ネットワーク事業者のサービス申込ＯｐＳの処理負荷の増大を回避する。

本実施形態のサービス予約装置１の構成を、図５により説明する。
図５の提案構成入力部５１には、サービス事業者に提案するサービスの提案構成が入力される。複数の構成が提案される場合には、構成案のそれぞれの提案優先度が入力される。より具体的には、入力される提案構成は、提案するサービス事業者を識別するサービス事業者ＩＤと、複数の構成を提案する際の構成Ｎｏと、複数の構成を提案する際のそれぞれの構成の提案優先度と、提案するネットワークサービスの区間と、ネットワークサービスのサービスＩＤと、ネットワークサービスの品目と、ネットワークサービスが使用する回線数等のサービス数から構成される。

サービス予約必要数計算部５２は、提案構成入力部５１に入力された提案構成と、後述する提案に対するサービス事業者の成約確率情報５５１から、ネットワークサービスの予約必要数を算出する。詳しくは、ネットワークサービスの予約必要数は、提案するネットワークサービス毎に、ネットワークサービスが使用する回線数等のサービス数と提案優先度と成約確率を乗じて算出する。

ここで、図５では、サービス事業者の成約確率情報５５１は、提案構成の入力とは別に、予約管理情報記憶部５５に格納されている構成を示しているが、提案優先度と同じ様に、提案構成の一部の情報としてもよい。
図５のように、予約管理情報記憶部５５に成約確率情報５５１として格納することで、複数回の提案の成約状況に応じて、成約確率情報５５１を更新し、精度を向上することができる。

サービス追加予約判断部５３は、サービス予約必要数計算部５２で算出したネットワークサービスの予約必要数を、ネットワークサービス毎に集計して総予約必要数を求める。そして、ネットワークサービス毎に、つぎのようにして、サービス予約の追加判断を行う。

まず、ネットワークサービス毎に以前のサービス予約処理で求めた累積予約必要数５５２を予約管理情報記憶部５５から取得する。以前のサービス予約処理では、この累積予約必要数５５２の値を整数値に切り上げた値の数のサービス予約が行われている（以下、このサービス予約数を既サービス予約数と記す）。このように、予約管理情報記憶部５５に累積予約必要数５５２を記憶することで、既に予約されたネットワークサービスの数を管理する。

つぎに、累積予約必要数５５２の値に総予約必要数を加算し、加算した結果の値を整数値に切り上げてサービス予約数を得る（以下、このサービス予約数を実サービス予約数と記す）。この既サービス予約数と実サービス予約数を比較して、サービス予約の追加判断を行う。
詳しくは、実サービス予約数が既サービス予約数より大であれば、追加のサービス予約を行うと判断する。実サービス予約数と既サービス予約数が等しければ、追加のサービス予約は不要と判断する。

サービスオーダ処理部５６は、追加のサービス予約を行うと判断した場合に、ネットワークサービス毎に対応するサービス申込ＯｐＳに、実サービス予約数から既サービス予約数を減じた数の追加のサービス予約を行う。

予約情報管理部５４は、サービス予約必要数計算部５２とサービス追加予約判断部５３とを制御するとともに、予約管理情報記憶部５５に記憶されている前述の成約確率情報５５１と累積予約必要数５５２の読み出し・更新を制御する。
累積予約必要数５５２の更新は、前述の総予約必要数を加算することにより行われる。

図６は、成約確率情報５５１の構成を示す図である。
成約確率情報５５１には、サービス事業者ＩＤ（６１）毎に、サービス提案の成約確率６２が記録されている。この成約確率６２は、サービス提案の成約結果に応じて、更新するとよい。

図７は、累積予約必要数５５２の構成を示す図である。
累積予約必要数５５２には、ネットワーク事業者のネットワークサービスに対応するサービスＩＤ（７１）毎に、累積予約必要数７２が記録される。この累積予約必要数７２は、サービス申込ＯｐＳ３に既にサービス予約された、サービス予約の見込み数である。サービス申込ＯｐＳ３には、累積予約必要数７２の値を整数に切り上げた値（既サービス予約数）の数のサービス予約が行われる。この累積予約必要数７２は、サービス提案が成約した際に、当該サービスに対応する予約必要数が減じられる。
また、累積予約必要数５５２に、ネットワークサービス毎の既サービス予約数７３を記録するようにしてもよい。

つぎに、追加の予約サービスを行う処理のより詳細な例を、図２に示したサービスの提案構成に従って説明する。
図８により、提案サービスの構成情報に基づいて個々のネットワークサービス毎に予約必要数８８を算出する
提案サービスの構成情報は、サービス事業者ＩＤ（８１）と構成案Ｎｏ（８２）とで表わされる提案の識別情報と、区間８４、サービスＩＤ（８５）、品目８６、回線数等のサービス数８７とで表わされる提案するネットワークサービス内容から成る。

提案優先度８３は、同一事業者への提案の構成案Ｎｏ（８２）の間の優先度を表わすもので、提案成約時の構成案の採択率を表わしている。つまり、提案優先度とサービス数の積の値が、サービスの使用見込み数となり、サービス提供性を担保するために予約が必要となる。
そこで、サービス事業者ＩＤ（８１）の値ごとに図６に示したサービス事業者ＩＤ毎の成約確率を参照して、ネットワークサービスが使用する回線数等のサービス数と提案優先度と成約確率を乗じて、ネットワークサービス毎の予約必要数８８を算出する。

つぎに、図９に示すように、図８で求めたネットワークサービス毎の予約必要数８８を、ネットワークサービス（サービスＩＤ（９１））毎に集計して、総予約必要数９４を求める。そして、総予約必要数９４と累積予約必要数９５から追加予約数９８を求める。ここで、図９の品目９２と区間９３は、ネットワークサービスの詳細情報を示している。
より詳細には、例えば、サービスＩＤ（９１）がＳ０１の場合（図２のサービス１）には、図８のサービスＩＤ（８５）欄がＳ０１の予約必要数８８の値を集計して１．３０を得て、総予約必要数９４とする。

そして、図７に示した累積予約必要数５５２を参照し、サービスＩＤ（９１）に対応する図９の累積予約必要数９５の値０．３０を得る。この値は、以前に追加の予約サービスを行った際に求めた予約必要数の累積あり、この値を整数に切り上げた値を既サービス予約数９７に“１”を記憶する。サービス申込ＯｐＳには、既サービス予約数９７の数のサービス予約が既に行われている。

つぎに、累積予約必要数９５の値に総予約必要数９４の値を加算して“１．６０”を求め、累積予約必要数９５を更新する。
実サービス予約数９６には、先に総予約必要数９４の値を加算した累積予約必要数９５の値“１．６０”を整数に切り上げた値“２”を記録する。この実サービス予約数９６が、以前の提案を含む提案サービスをサービス事業者に提示するために、予約するネットワークサービスの見込み数となる。
今回のサービス提案に伴うネットワークサービスの追加のサービス予約数を表わす追加予約数９８は、実サービス予約数９６の“２”から既サービス予約数９７の“１”を減じて算出する。この追加予約数９８の値“１”の追加のサービス予約を行う。

上述で、実サービス予約数９６と既サービス予約数９７を整数に切り上げた値としているが、これは、ネットワークサービスの予約単位によるものである。このため、総予約必要数９４が小さい場合には、累積予約必要数９５の増加も小さくなり、実サービス予約数９６が変わらない場合もある。この場合には、追加のサービス予約は不要となる。
具体的には、サービスＩＤ（９１）がＳ０２とＳ０３の場合には、実サービス予約数９６と既サービス予約数９７が同値となり、追加予約数９８の値が“０”となり、追加のサービス予約は行わない。

図１０に、サービス予約装置１で実行されるサービス予約処理のフロー図を示す。
最初に、サービス予約装置１は、サービス事業者に提案するＮＷ構成提案装置２から、サービス事業者毎のＮＷサービスの提案構成を取得する（Ｓ１００１）。
そして、提案するサービス事業者毎に、つぎのステップＳ１００３，Ｓ１００４をサービス事業分繰り返し実行する（Ｓ１００２）。

ステップＳ１００３では、サービス事業者への提案の成約確率情報５５１を取得する。そしてステップＳ１００４で、ＮＷの提案構成案のサービス毎に、サービス数８７と提案優先度８３と成約確率情報５５１とを乗じて、サービスの使用見込みである予約必要数８８を計算する。
上記の処理を、サービス事業分繰り返し実行すると（Ｓ１００５）、ステップＳ１００６に進む。

ステップＳ１００６では、提案のネットワークサービスの全てについて、サービス毎の予約必要数８８を集計して、総予約必要数９４を求める。
そして、提案のネットワークサービスのそれぞれについて、ステップＳ１００８からステップＳ１０１６までの処理を行う（Ｓ１００７）。

ステップＳ１００８では、前回のサービス提案に伴うサービス予約の処理を行った際に求めた累積予約必要数９５を取得する。そして、取得した累積予約必要数９５に基づいて、既にサービス予約しているサービス数である既サービス予約数９７を算出する（Ｓ１００９）。
そして、累積予約必要数９５に総予約必要数９４を加算し（Ｓ１０１０）、この加算値からサービス提案に伴う実サービス予約数９６を取得する（Ｓ１０１１）。累積予約必要数９５は、この加算値に更新し、次回のサービス予約の処理で参照できるようにする（Ｓ１０１１）。

つぎに、実サービス予約数９６と既サービス予約数９７を比較し（Ｓ１０１２）、追加のサービス予約の要否を判断する（Ｓ１０１３）。つまり、実サービス予約数９６と既サービス予約数９７とが等しければ、追加のサービス予約は否（不要）と判断し、実サービス予約数９６が既サービス予約数９７より大であれば、追加のサービス予約が必要（要）と判断する。

追加の予約サービスが不要の場合には（Ｓ１０１３の否）、ステップＳ１００８に進み、つぎのネットワークサービスの処理に進む（Ｓ１０１７）。
追加の予約サービスが要の場合には（Ｓ１０１３の要）、ステップＳ１０１４に進み、ネットワークサービスに対応するサービス申込ＯｐＳ３にネットワークサービスの提供が可能な数（追加予約数）を確認するサービスの在庫確認を行い、追加の予約サービスの可否を確認する（Ｓ１０１５）。

ステップＳ１０１５で、サービス申込ＯｐＳ３から追加の予約サービスが可能であることの回答があれば（Ｓ１０１５のＹｅｓ）、実サービス予約数９６から既サービス予約数９７を減じた数の追加のサービス予約を行う（Ｓ１０１６）。
そして、ステップＳ１０１７に進み、つぎのネットワークサービスの処理に進む。

ステップＳ１０１５で、サービス申込ＯｐＳ３から追加の予約サービスが不可能であることの回答があれば（Ｓ１０１５のＮｏ）、ステップＳ１０１８に進む。
ステップＳ１０１８では、サービス予約が不可能であり提案サービスの提供性を担保できないため、サービス予約装置１からＮＷ構成提案装置２に、提案の構成変更が必要であることを通知し、ステップＳ１００１に進み、変更された提案ＮＷサービスの構成取得を行う。このとき、既に行った追加のサービス予約をキャンセルする。

以上の処理により、ネットワークサービスの予約時の使用可能性の低いリソースの占有やＮＷ事業者のＯｐＳの処理負荷の増大を回避して、サービス（リソース）予約を可能とする。

また、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。上記の実施例は本発明で分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。

１ サービス予約装置
２ ＮＷ構成提案装置
３、３ａ、３ｂ、３ｃ サービス申込ＯｐＳ
５１ 提案構成入力部
５２ サービス予約必要数計算部
５３ サービス追加予約判断部
５４ 予約情報管理部
５５ 予約管理情報記憶部
５５１ 成約確率情報
５５２ 累積予約必要数
５６ サービスオーダ処理部

Claims (6)

1. 複数のネットワークサービスから構成される提案サービスの構成情報が入力される提案構成入力部と、前記構成情報とネットワークサービスの利用の見込み率に基づいてネットワークサービスの予約必要数を求めるサービス予約必要数計算部と、前記予約必要数と累積予約必要数とからネットワークサービスの追加予約の要否を判断するサービス追加予約判断部と、前記サービス追加予約判断部の判断に基づいてネットワークサービスを制御するオペレーションシステムに追加のサービス予約を行うサービスオーダ処理部を備えたことを特徴とするサービス予約装置。
2. 請求項１に記載のサービス予約装置において、ネットワークサービス毎に前記累積予約必要数を記憶する予約管理情報記憶部を備えることを特徴とするサービス予約装置。
3. 請求項１または２に記載のサービス予約装置において、前記サービス予約必要数計算部は、サービス事業者ごとの成約確率または構成の提案優先度の少なくとも一方を前記見込み率として、前記予約必要数を求めることを特徴とするサービス予約装置。
4. 請求項１から３のいずれか一項に記載のサービス予約装置において、前記サービス予約必要数計算部は、サービス事業者ごとの成約確率と構成の提案優先度との積を前記見込み率とし、前記予約必要数を求め、前記累積予約必要数に前記予約必要数を加算した値を整数値に切り上げた値と、前記予約必要数を加算する前の前記累積予約必要数を整数値に切り上げた値との差を求めて、サービス予約の追加数とすることを特徴とするサービス予約装置。
5. 複数のネットワークサービスから構成されるサービスの構成情報が入力されるステップと、前記構成情報のネットワークサービス毎に、サービス事業者の成約確率と、構成の提案優先度の積を求めて予約必要数を算出するステップと、累積予約必要数に前記予約必要数を加算した値を整数値に切り上げた値と、前記予約必要数を加算する前の前記累積予約必要数の値を整数値に切り上げた値との差を求めて、サービス予約の追加のサービス数を求めるステップと、前記ネットワークサービスの制御部にサービス予約を追加するステップを含むことを特徴とするサービス予約方法。
6. 請求項５に記載のサービス予約方法において、さらに、前記累積予約必要数に前記予約必要数を加算して、前記累積予約必要数を更新するステップを含むことを特徴とするサービス予約方法。

Images