JP6778145B2 - 通信サービス管理装置及び通信サービス管理方法 - Google Patents

Description

本発明は、通信サービスを卸す複数の卸元事業者が提供する各種の通信サービスを連携させて紐付け、これを１つの連携サービスとして利用者に提供する通信サービス管理装置及び通信サービス管理方法に関する。

従来、上述した連携サービスを構成する技術として、非特許文献１に記載のＢ２Ｂ２Ｘ（Business to Business to X）における複数事業者間サービス設定連携方式がある。なお、Ｂ２Ｂ２Ｘの先頭のＢ（ファーストＢ）は卸元事業者であり、真中のＢ（ミドルＢ）は卸先事業者である。Ｘは、当該Ｘが例えばＣ(Consumer)の場合は消費者となる。

非特許文献１の連携方式では、通信の卸サービスの仕様が記述されたカタログを作成し、卸元事業者からの連携させたい卸サービスの組み合わせと要望に応じて、複数事業者（複数の卸元事業者）を統合的に制御するカタログドリブンアーキテクチャを構成している。この構成によって複数の通信の卸サービスを連携させて紐付けた連携サービスを利用者に提供することを可能としている。

しかし、上記の非特許文献１の連携方式では、複数の通信の卸サービス（単に、サービスともいう）の障害発生時の対応については規定されていない。この障害発生時の対応について規定された技術として、特許文献１に記載の技術がある。この技術は、コンピュータシステムによるサービスの障害が検出された場合に、障害情報が記載されたトラブルチケット（障害電子票）を発行する等の対応策を行うようになっている。

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

高橋謙輔、他４名、「Ｂ２Ｂ２Ｘにおける複数事業者間サービス設定連携方式」、２０１６年ソサイエティ大会講演論文集、一般社団法人電子情報通信学会、２０１６年９月２０日発表、Ｂ−１４−１０

しかしながら、特許文献１に記載されたサービスの障害情報及び復旧情報を利用者等に提供するトラブルチケット発行による障害管理は、単一卸元事業者内のサービスを対象にしている。このため、複数の卸元事業者の通信サービスを連携させて紐付けた連携サービスの障害情報及び復旧情報を利用者等に提供する障害管理ができないという問題がある。

本発明は、このような事情に鑑みてなされたものであり、通信サービスを卸す複数の卸元事業者が提供する各種の通信サービスを連携させて紐付けた１つの連携サービスの障害情報及び復旧情報を利用者等に提供することができる通信サービス管理装置及び通信サービス管理方法を提供することを課題とする。

上記課題を解決するために、請求項１に係る発明は、通信サービスを卸す複数の卸元通信装置が提供する各種の通信サービスとしての子サービスを連携させて紐付けた１つの親サービスを利用者のユーザ端末機に提供する通信サービス管理装置であって、前記卸元通信装置を含む通信システムの通信に係る操作が行われるオペレータ端末機、前記ユーザ端末機、前記卸元通信装置の何れか１つから送信されてくる障害申告を受け付けると共に、前記子サービス及び前記親サービスの障害情報及び復旧情報を前記オペレータ端末機、前記ユーザ端末機、前記卸元通信装置へ提供する業務ＡＰＩ部と、前記業務ＡＰＩ部で受け付けられた障害申告に応じて、障害情報が記載されるトラブルチケット発行の制御内容が記載されたシナリオを記憶部に記憶するシナリオ管理部と、前記卸元通信装置が前記子サービスを提供し、前記親サービスに紐付けられた複数の当該子サービスの情報を、当該親サービス毎に記憶部に記憶し、前記業務ＡＰＩ部で受け付けられた障害申告に係る前記親サービス又は前記子サービスの情報を当該記憶部から検索し、この検索された親サービスの障害電子票である親トラブルチケットと、子サービスの障害電子票である子トラブルチケットとを、前記シナリオに従って発行して記憶部に保持する業務リソース管理部とを備えることを特徴とする通信サービス管理装置である。

請求項９に係る発明は、通信サービスを卸す複数の卸元通信装置が提供する各種の通信サービスの子サービスを連携させて紐付けた１つの親サービスを利用者のユーザ端末機に提供する通信サービス管理装置による通信サービス管理方法であって、通信サービス管理装置は、受け付けた障害申告に応じて障害情報が記載されるトラブルチケット発行の制御内容が記載されたシナリオを記憶すると共に、前記卸元通信装置が前記子サービスを提供し、前記親サービスに紐付けられた複数の当該子サービスの情報を、当該親サービス毎に記憶する記憶部を備え、前記卸元通信装置を含む通信システムの通信に係る操作が行われるオペレータ端末機、前記ユーザ端末機、前記卸元通信装置の何れか１つから送信されてくる障害申告を受け付けるステップと、前記受け付けられた障害申告に係る前記親サービス又は前記子サービスの情報を前記記憶部から検索するステップと、前記検索された親サービスの障害電子票である親トラブルチケットと、子サービスの障害電子票である子トラブルチケットとを、前記シナリオに従って発行して前記記憶部に保持するステップと、前記子サービス及び前記親サービスの障害情報及び復旧情報を前記オペレータ端末機、前記ユーザ端末機、前記卸元通信装置へ提供するステップとを実行することを特徴とする通信サービス管理方法である。

上記請求項１の構成及び請求項９の方法によれば、卸元通信装置が子サービスを提供し、親サービスに紐付けられた複数の子サービスの情報を、親サービス毎に記憶して管理している。障害申告があった際に、シナリオに従って、その記憶された親サービスの親トラブルチケットと、子サービスの子トラブルチケットとを発行するようにした。このため、各卸元通信装置における各種の通信サービスである子サービスを連携させて紐付けた１つの連携サービスとしての親サービスの障害を、利用者、全体の通信システムのオペレータ、卸元通信装置を所持する卸元事業者等へ提供することができる。

請求項２に係る発明は、前記業務リソース管理部が、前記業務ＡＰＩ部が前記卸元通信装置からの障害申告を受け付けた際に、当該障害申告を行った卸元通信装置の子サービスを検索し、検索された子サービスに紐付けられた親サービスを検索し、この検索された親サービスに対する前記親トラブルチケットと、当該親サービスに紐付けられた子サービスに対する前記子トラブルチケットとを、前記シナリオに従って発行し、この発行された子トラブルチケットに係る子サービスを提供する卸元通信装置の障害が発生中であれば当該子トラブルチケットを障害に応じて更新しながら発行を継続し、復旧していれば当該子トラブルチケットを削除し、この削除された子トラブルチケットに紐付けられた親トラブルチケットに係る親サービスを提供する卸元通信装置の障害が発生中であれば当該親トラブルチケットを障害に応じて更新しながら発行を継続し、復旧していれば当該親トラブルチケットを削除する処理を行うことを特徴とする請求項１に記載の通信サービス管理装置である。

この構成によれば、まず、業務リソース管理部は、卸元通信装置から障害申告があった際に、障害申告を行った卸元通信装置の子サービスを検索し、検索された子サービスに紐付けられた親サービスを検索する。次に、業務リソース管理部は、検索された親サービスに対する親トラブルチケットと、その親サービスに紐付けられた子サービスに対する子トラブルチケットとを障害に応じて更新しながら発行又は削除して、親サービス及び子サービスの障害情報及び復旧情報を管理することができる。

請求項３に係る発明は、前記業務リソース管理部が、前記親サービスを利用する前記ユーザ端末機からの障害申告を受け付けた際に、当該親サービスに対する前記親トラブルチケットを前記シナリオに従って発行し、前記親サービスに紐付けられた前記子サービスの情報を前記記憶部から検索し、この検索された子サービスに対する前記子トラブルチケットを前記シナリオに従って発行し、この発行された子トラブルチケットに係る子サービスを提供する卸元通信装置に障害が発生中であれば障害が復旧するまで障害状況を問合せ、障害に応じて前記子トラブルチケットを更新しながら発行を継続し、復旧すれば当該子トラブルチケットを削除し、この削除された子トラブルチケットに紐付けられた親トラブルチケットに係る親サービスを提供する卸元通信装置の障害が発生中であれば当該親トラブルチケットを障害に応じて更新しながら発行を継続し、復旧していれば当該親トラブルチケットを削除する処理を行うことを特徴とする請求項１に記載の通信サービス管理装置である。

この構成によれば、業務リソース管理部は、親サービスを利用するユーザ端末機から障害申告があった際に、障害申告に係る親サービスに対する親トラブルチケットと、その親サービスに紐付けられた子サービスに対する子トラブルチケットとを発行する。業務リソース管理部は、この発行された子トラブルチケットに係る子サービスを提供する卸元通信装置に障害が発生中であれば障害が復旧するまで障害状況を問合せ、障害に応じてその子トラブルチケットを更新しながら発行を継続する。このため、どの子サービスに障害が発生しているか分からない場合でも、子サービスの障害が復旧するまで子トラブルチケットで障害を管理することができる。

請求項４に係る発明は、前記業務リソース管理部が、前記親トラブルチケットの発行時に、この発行された親トラブルチケットに紐付けられた前記子トラブルチケットを障害に基づき発行した後、親トラブルチケットに紐付けられた全ての子トラブルチケットの障害が復旧する毎に、発行された全ての親トラブルチケットに係る故障が復旧されたか否かを判定し、当該全ての親トラブルチケットに係る故障が復旧していれば当該全ての親トラブルチケットを削除することを特徴とする請求項２又は３に記載の通信サービス管理装置である。

この構成によれば、業務リソース管理部は、親トラブルチケットの発行時に、この発行された親トラブルチケットに紐付けられた子トラブルチケットを障害に基づき発行することで、親トラブルチケットの障害状態の更新を行うことができる。また、業務リソース管理部は、親トラブルチケットに紐付けられた全ての子トラブルチケットの障害が復旧する毎に、発行された全ての親トラブルチケットに係る故障が復旧されたか否かを判定し、全ての親トラブルチケットに係る故障が復旧していれば全ての親トラブルチケットを削除するので、上記のように障害状況の更新が行われながら発行されている全ての親トラブルチケットを、全ての復旧後に確実に削除することができる。

請求項５に係る発明は、前記業務リソース管理部が、前記子トラブルチケット及び前記親トラブルチケットであるトラブルチケット情報の閲覧者に応じた閲覧制限を保持する保持部を備え、前記オペレータ端末機、前記ユーザ端末機、前記卸元通信装置及び卸先端末機の何れか１つの閲覧端末機から送信されてくるトラブルチケット情報の閲覧要求を受け付けた際に、当該閲覧要求の送信元の閲覧端末機に係る閲覧者に対応付けられた閲覧制限を前記保持部から検索し、この検索された閲覧制限に応じたトラブルチケット情報を前記業務ＡＰＩ部を介して当該閲覧端末機へ提供する処理を行うことを特徴とする請求項１〜４の何れか１項に記載の通信サービス管理装置。

この構成によれば、連携された各種の通信サービスを閲覧するシステムのオペレータ、卸元事業者及びエンドユーザ等の閲覧者の閲覧を、異なる立場に応じて制限することができる。

請求項６に係る発明は、前記業務リソース管理部が、前記閲覧端末機に提供される前記親サービスに紐付く複数の前記子サービスの内、何れかの子サービスに障害が発生し、冗長化している子サービスにおいて1つの子サービスでも正常であれば、当該子サービスは正常とみなし、その障害発生中の子サービスに対して発行した前記子トラブルチケットのみを、当該閲覧端末機に対して閲覧不可能に制限する処理を行うことを特徴とする請求項５に記載の通信サービス管理装置である。

この構成によれば、複数の子サービスを閲覧可能な閲覧端末機の利用者は、冗長化している子サービスにおいて1つの子サービスでも正常であれば、当該子サービスは正常とみなし、その障害発生中の子サービスに対して発行した子トラブルチケットのみを、閲覧不可能とすることができる。

請求項７に係る発明は、前記業務リソース管理部が、前記卸元通信装置からの障害申告に係るトラブルチケット情報の発行時に、この発行されたトラブルチケット情報の閲覧を前記閲覧端末機に許可し、前記親サービスを利用する前記ユーザ端末機からの障害申告に係るトラブルチケット情報の発行時に、前記閲覧端末機への閲覧を制限した後、トラブルチケット発行対象の卸元通信装置に問合せを行い、正常であることが確認された卸元通信装置についてはトラブルチケット削除後、問合せ処理を停止し、障害が発生している卸元通信装置に対する障害を確定後に、この確定された障害に係る子トラブルチケットが紐付けられた親トラブルチケットの閲覧を当該閲覧端末機に許可する処理を行うことを特徴とする請求項５に記載の通信サービス管理装置である。

従来、親サービスを利用するユーザ端末機からの障害申告があった場合、どの子サービスに障害が発生しているか不明な状況である。この状況下で、他のユーザ端末機の利用者が閲覧要求を行った場合、障害が生じていない子サービスに対してもトラブルチケット情報が一時的に発行されてしまう場合がある。この場合、障害が発生していないにも関わらず、障害が発生したとのトラブルチケット情報を閲覧させる不具合が生じる可能性がある。しかし、本発明の構成によれば、業務リソース管理部が、トラブルチケット発行対象の卸元通信装置に問合せを行い、正常であることが確認された卸元通信装置についてはトラブルチケット削除後、問合せ処理を停止し、障害が発生している卸元通信装置に対する障害を確定後に、この確定された障害に係る子トラブルチケットが紐付けられた親トラブルチケットに係る閲覧を許可するので、上記不具合が生じないようにすることができる。

請求項８に係る発明は、インターネットから、前記卸元通信装置が提供する子サービスの障害情報を収集し、予め設定された障害名と卸元事業者名とのアンド条件に適合して検索された障害情報を、特定時間内にカウントし、このカウント数が予め定められた閾値を超えた際に障害発生と判定する障害情報収集判定部を更に備え、前記業務リソース管理部は、前記障害情報収集判定部で障害発生と判定された際に、前記業務ＡＰＩ部が前記卸元通信装置又は前記ユーザ端末機からの障害申告を受け付けた際の障害に係る処理と同様の処理を行うことを特徴とする請求項２〜７の何れか１項に記載の通信サービス管理装置である。

この構成によれば、障害情報収集判定部によって、卸元通信装置からの障害申告を受け付けなくとも、インターネットから、卸元通信装置が提供する子サービスの障害情報を収集することができる。

本発明によれば、通信サービスを卸す複数の卸元事業者が提供する各種の通信サービスを連携させて紐付けた１つの連携サービスの障害情報及び復旧情報を利用者等に提供する通信サービス管理装置及び通信サービス管理方法を提供することができる。

本発明の実施形態に係る通信サービス管理装置の構成を示すブロック図である。 通信サービス管理装置による卸元事業者契機の障害申告時のトラブルチケット発行を説明するためのシーケンス図である。 通信サービス管理装置による卸元事業者契機の障害申告時のトラブルチケット発行を説明するためのブロック図である。 通信サービス管理装置による卸元事業者契機の障害申告時に発行された親ＦＴトラブルチケットの状態を更新する動作を説明するためのフローチャートである。 通信サービス管理装置による卸元事業者契機の障害申告時に発行されたトラブルチケット情報の閲覧を説明するためのブロック図である。 通信サービス管理装置によるＦＰ利用者契機の障害申告時のトラブルチケット発行を説明するためのシーケンス図である。 通信サービス管理装置によるＦＰ利用者契機の障害申告時のトラブルチケット発行を説明するためのブロック図である。 通信サービス管理装置によるＦＰ利用者契機の障害申告時に発行されたトラブルチケット情報の閲覧を説明するためのブロック図である。 通信サービス管理装置による閲覧端末機へのトラブルチケット情報の閲覧制限を説明するためのシーケンス図である。 通信サービス管理装置によるユーザ端末機、オペレータ端末機、卸元端末機及び卸先端末機へのトラブルチケット情報の第１の閲覧制限を説明するためのブロック図である。 通信サービス管理装置によるユーザ端末機、オペレータ端末機及び卸元端末機へのトラブルチケット情報の閲覧提供を説明するためのブロック図である。 通信サービス管理装置によるユーザ端末機、オペレータ端末機及び卸元端末機へのトラブルチケット情報の第２の閲覧制限を説明するためのブロック図である。 通信サービス管理装置によるインターネットを介した卸元通信装置の障害を収集する動作を説明するためのシーケンス図である。 通信サービス管理装置によるインターネットを介した卸元通信装置の障害を収集する構成を説明するためのブロック図である。

以下、本発明の実施形態を、図面を参照して説明する。
＜実施形態の構成＞
図１は、本発明の実施形態に係る通信サービス管理装置の構成を示すブロック図である。
図１に示す通信サービス管理装置（管理装置ともいう）１０は、通信サービスを卸す複数の卸元事業者が提供する各種の通信サービスを連携させて紐付けた１つの連携サービスの障害情報及び復旧情報を利用者等に提供する障害管理を行う。また、各種の通信サービスを閲覧する異なる閲覧者のコンピュータ等の端末機に、その異なる立場に応じて閲覧を制限する処理を行うことが可能となっている。

上述した複数の卸元事業者が提供する各種の通信サービスとは、言い換えれば、ネットワーク・クラウドサービス（Source Product:ＳＰ）であり、管理装置１０は、そのＳＰを連携させ、１つの連携サービス（Federated Product:ＦＰ）としてエンドユーザ等の利用者に提供する。つまり、親子関係で捉えると、子であるＳＰサービスを連携させて１つの親であるＦＰサービスに紐付けて一体に構築し、このＳＰサービスが紐付けられたＦＰサービスを提供するようになっている。この親子関係を明確にするために、以降、ＳＰサービスを子ＳＰサービスとも称し、ＦＰサービスを親ＦＰサービスとも称す。なお、子ＳＰサービスは請求項記載の子サービスであり、親ＦＰサービスは請求項記載の親サービスである。

管理装置１０は、子ＳＰサービスに何らかの障害が発生した際に、その障害情報が記載された障害管理票であるトラブルチケット（SP Trouble ticket:ＳＴ）を発行する。また、親ＦＰサービスに何らかの障害が発生した際に、そのサービスのトラブルチケット（FP Trouble ticket:ＦＴ）を発行する。つまり、親子関係で捉えると、子であるＳＴトラブルチケットの少なくとも１つを、１つの親であるＦＴトラブルチケットに紐付けて一体に構築し、これを発行するようになっている。この親子関係が分かるように、以降、ＳＴトラブルチケットを子ＳＴトラブルチケットとも称し、ＦＴトラブルチケットを親ＦＴトラブルチケットとも称す。なお、子ＳＴトラブルチケットは請求項記載の子トラブルチケットであり、親ＦＴトラブルチケットは請求項記載の親トラブルチケットである。

管理装置１０は、業務ＡＰＩ(Application Programming Interface)部１１と、シナリオ管理部１２と、業務リソース管理部１３と、障害情報収集判定部１４と、卸元事業者ＡＰＩアダプタ部（アダプタ部ともいう）１５とを備えて構成されている。

アダプタ部１５は、通信装置を接続するための複数の第１ＩＦ(インタフェース)１５ａ、第２ＩＦ１５ｂ、…、第ｎＩＦ１５ｎを備える。第１ＩＦ１５ａには、各種通信サービスを利用者等に提供する第１卸元事業者の第１卸元通信装置２０ａが接続され、第２ＩＦ１５ｂには第２卸元事業者の第２卸元通信装置２０ｂが接続され、…、第ｎＩＦ１５ｎには、第ｎ卸元事業者の第ｎ卸元通信装置２０ｎが接続されている。

業務ＡＰＩ部１１には、卸元事業者の通信サービス（ＦＰ）を利用する利用者のユーザ端末機（端末機ともいう）２１と、通信システムの通信に係る操作を行うオペレータが利用するオペレータ端末機（端末機ともいう）２２と、複数の卸元事業者が所有する卸元端末機（端末機ともいう）２３とが接続されている。但し、卸元端末機２３は、図では１つしか表記していないが、第１〜第ｎ卸元事業者が各々所有するものであり、卸元通信装置２０ａ〜２０ｎ毎に備えられているものとする。各端末機２１，２２，２３は、パーソナルコンピュータ等の通信を行うコンピュータである。

ユーザ端末機２１は、親ＦＰサービスの障害申告や障害等の閲覧要求を管理装置１０へ送信したり、閲覧要求に応じた障害情報を表示したりする処理を行う。

オペレータ端末機２２は、管理装置１０に対して子ＳＰサービスや親ＦＰサービスに係る各トラブルチケットの削除処理等の操作や、各トラブルチケットに係る閲覧要求や故障情報（障害情報）を表示したりする処理を行う。

卸元端末機２３は、子ＳＰサービスや親ＦＰサービスの障害申告や閲覧要求を管理装置１０へ送信したり、閲覧要求に応じた障害情報を表示したりする処理を行う。但し、卸元端末機２３に代え、当該卸元端末機２３が接続されている卸元通信装置２０ａ〜２０ｎにおいて、障害申告や閲覧要求が送信されたり、閲覧要求に応じた障害情報を表示したりする処理が行われてもよい。

業務ＡＰＩ部１１は、各端末機２１，２２，２３から送信されてくるトラブルチケット管理要求や障害状況閲覧要求を受け付ける。トラブルチケット管理要求部３１は、複数の卸元事業者の各種通信サービス（子ＳＰサービス）を連携させて紐付けた連携サービス（親ＦＰサービス）の障害情報及び復旧情報を利用者等に提供する障害管理を行う。障害状況閲覧要求部３２は、通信サービスを閲覧する異なる閲覧者の端末機２１，２２，２３に、その異なる立場に応じて閲覧を制限する処理を行う。閲覧者とは、エンドユーザ等の利用者、通信システムのオペレータ、複数の卸元事業者等である。

シナリオ管理部１２は、トラブルチケット管理要求及び障害状況閲覧要求に応じて、トラブルチケットを発行するための制御内容が記載されたトラブルチケットシナリオ（シナリオともいう）３３を図示せぬ記憶部に記憶して保持する。この保持されたシナリオ３３に従って、トラブルチケットの発行処理が行われる。

業務リソース管理部１３は、各端末機２１，２２，２３からの子ＳＰサービスや親ＦＰサービスの障害申告時に、トラブルチケットの発行や、通信サービスの運用状態や障害状態の閲覧処理等の管理を行う。この業務リソース管理部１３は、トラブルチケット管理部１３ａと、サービス状態管理部１３ｂと、組織管理部１３ｃと、顧客管理部１３ｄとを備える。なお、組織管理部１３ｃ及び顧客管理部１３ｄによって、請求項記載の保持部を構成する。

サービス状態管理部１３ｂは、現在提供中の通信サービスの内容の実態を管理する。例えば、親ＦＰサービス（ＦＰ１）と、この下に紐付く子ＳＰサービス（ＳＰ１，ＳＰ２，ＳＰ３）とがある場合、ＦＰ１と、この下に紐付くＳＰ１，ＳＰ２，ＳＰ３との情報を図示せぬ記憶部に保持して管理する。

トラブルチケット管理部１３ａは、ユーザ端末機２１や卸元端末機２３からの子ＳＰサービス又は親ＦＰサービスの障害申告時に、シナリオ管理部１２からシナリオ３３を読み込んで、サービス状態管理部１３ｂから子ＳＰサービスを検索後に、子ＳＴトラブルチケット及び親ＦＴトラブルチケットを発行して図示せぬ記憶部に保持する処理を行う。

組織管理部１３ｃは、トラブルチケット情報の閲覧制限を行うための、卸元事業者等の組織が何をする組織か等の組織の内容情報を図示せぬ記憶部に保持して管理する。顧客管理部１３ｄは、トラブルチケット情報の閲覧制限を行うための、利用者の個人情報を図示せぬ記憶部に保持して管理する。

障害情報収集判定部１４は、インターネット３０を介して卸元通信装置２０ａ〜２０ｎの障害情報の収集を行い、この収集された障害情報から障害を判定してトラブルチケットを発行可能とする処理を行う。その障害判定のロジックは、予め設定された「障害名」と「卸元事業者名」によるアンド条件で障害情報を検索し、６０分以内等の特定時間内に検索された障害情報をカウントし、このカウント数が閾値を超えた際に障害発生と判定する。なお、アンド条件の設定は、オペレータ等が行う。

＜卸元事業者契機の障害申告＞
卸元事業者から障害申告があった場合の管理装置１０によるトラブルチケット発行及び障害の閲覧提供について、図２〜図４を参照して説明する。

図２のステップＳ１において、例えば卸元通信装置２０ａに係る卸元端末機２３からＳＰ２（図３参照）の障害申告が、管理装置１０の業務ＡＰＩ部１１に送信されたとする。業務ＡＰＩ部１１は、ステップＳ２において、その障害申告に応じたシナリオ３３の呼出しをシナリオ管理部１２に行う。この呼出しを受けたシナリオ管理部１２は、ステップＳ３において、トラブルチケット発行要求を業務リソース管理部１３に行う。この際、業務リソース管理部１３のトラブルチケット管理部１３ａでシナリオ３３が読み込まれる。

ここで、業務リソース管理部１３は、図３に示すように、サービス状態管理部１３ｂに複数の卸元事業者が提供する３つの子ＳＰサービス（ＳＰ１，ＳＰ２，ＳＰ３）が連携された１つの親ＦＰサービスが、ＦＰ１，ＦＰ２，…，ＦＰｎで示すように親ＦＰサービス毎に保持されているとする。

図２に示すステップＳ４において、業務リソース管理部１３のトラブルチケット管理部１３ａが、上記のトラブルチケット発行要求時のシナリオ３３に応じて、サービス状態管理部１３ｂから申告元の卸元事業者のＳＰ情報（例えばＳＰ２）を検索して抽出する。更に、サービス状態管理部１３ｂは、ステップＳ５において、その検索されたＳＰ２に関連した（ＳＰ２が紐付けられた）ＦＰを検索して抽出する。ここでは、図３に示す子ＳＰサービス（ＳＰ２）が紐付けられた親ＦＰサービス（ＦＰ１，ＦＰ２，…，ＦＰｎ）が検索されて抽出される。

図２に示すステップＳ６において、トラブルチケット管理部１３ａは、上記ステップＳ５で抽出した全ての親ＦＰサービス（ＦＰ１，ＦＰ２，…，ＦＰｎ）に、親ＦＴトラブルチケット（ＦＴ１，ＦＴ２，…，ＦＴｎ）を発行する。更に、トラブルチケット管理部１３ａは、ステップＳ７において、各々の親ＦＴトラブルチケット（ＦＴ１，ＦＴ２，…，ＦＴｎ）（図３参照）に対して、子ＳＴトラブルチケット（ＳＴ２）を発行して紐付ける。

次に、ステップＳ８において、トラブルチケット管理部１３ａは、アダプタ部１５へ障害申告を行った例えば卸元通信装置２０ａを有する卸元事業者への障害問合せ要求を行う。続いて、アダプタ部１５は、ステップＳ９において、ＳＰ２を提供する卸元通信装置２０ａへ障害問合せを行う。卸元通信装置２０ａは、ステップＳ１０において、その障害問合せに応じた障害情報を応答する。この応答は、ステップＳ１１にてアダプタ部１５を介して業務リソース管理部１３のトラブルチケット管理部１３ａへ通知される。

次に、ステップＳ１２において、トラブルチケット管理部１３ａは、子ＳＴトラブルチケットの状態を更新する。これは、国際標準ＴＭＦ６２１での規定内容に従って、子ＳＴトラブルチケットが現在の障害や復旧等の状態に更新されることを意味する。

次に、ステップＳ１３において、トラブルチケット管理部１３ａが親ＦＴトラブルチケットの状態を次のように更新する。このＦＴの状態更新を図４を参照して説明する。

＜ＦＴの状態更新＞
図４に示すステップＳ２１において、トラブルチケット管理部１３ａは、親ＦＴトラブルチケットが発行できるか否かを判定する。この結果、ＦＴが発行できなかった場合（Ｎｏ）は、ステップＳ２２において、オペレータ端末機２２を利用するオペレータ操作により発行の拒否を行い、ＦＴの状態更新の処理を終了する。

一方、ＦＴが発行できた場合（Ｙｅｓ）は、ステップＳ２３において、トラブルチケット管理部１３ａは、ＦＴの発行を承認する。この承認後、ステップＳ２４において、トラブルチケット管理部１３ａは、親ＦＴトラブルチケットに紐付けられた子ＳＴトラブルチケットが発行できたか否かを判定する。この結果、ＳＴが発行できなかった場合（Ｎｏ）とは、一定時間後に再度、卸元事業者への問合せを行い、それでもＳＴが発行できない場合である。この場合、ステップＳ２２において発行の拒否を行い、ＦＴの状態更新の処理を終了する。

一方、上記ステップＳ２４の判定結果、ＳＴが発行できた場合（Ｙｅｓ）とは、ＳＴを紐付けたＦＴが発行できた場合であり、言い換えれば、ＦＴに故障があると応答があった場合である。この場合、ステップＳ２５におけるＳＴの状態更新の進行中に入る。この進行中とは、少なくとも１つの子ＳＴトラブルチケットの発行確認が、オペレータ端末機２２のオペレータ操作により行われる等の状態である。

ステップＳ２５ａにおいて、ＳＴが次の状態に更新できない場合は、オペレータ操作によりＳＴを次の状態へ更新する。一方、ステップＳ２５ｂは、卸元端末機２３の操作や、卸元通信装置２０ａのＳＴの障害等による申告者起因で故障に係る処理が止まっている状態を表す。例えば、卸元通信装置２０ａがＳＴの故障発生中の場合に、その故障の復旧対応が止まっている状態である。

次に、ステップＳ２５ｃにおいて、全てのＳＴの故障が復旧できたか否かを判定する。これは、後述の復旧確認を除き、ＳＴ上の故障がオペレータ等によって修復され、全ての子ＳＴトラブルチケットへの復旧対応が完了したことを判定する場合である。但し、復旧確認とは、ＳＴ上の故障がオペレータ等によって修復され、全ての子ＳＴトラブルチケットへの復旧対応が完了してはいるが、この復旧対応に対する確認は行われていない状態を指している。このステップＳ２５ｃの処理は、例えば、卸元事業者への復旧依頼中に、卸元事業者から復旧できた応答が通知されたことを判定する場合である。この判定結果、復旧できていない場合（Ｎｏ）は、上記ステップＳ２５ａ，Ｓ２５ｂに戻る。一方、復旧できた場合（Ｙｅｓ）は、ステップＳ２６に進む。

ステップＳ２６において、トラブルチケット管理部１３ａは、全ての親ＦＴトラブルチケットに係る故障が復旧したか否かを判定する。この結果、復旧していなければ（Ｎｏ）、上記ステップＳ２３へ戻る。復旧していれば（Ｙｅｓ）、ステップＳ２７において、その復旧した親ＦＴトラブルチケットを削除する。これにより、ＦＴの状態更新の処理が終了する。

なお、上記ステップＳ２３におけるＦＴの発行承認、又はステップＳ２５におけるＳＴの状態更新の進行中において、そのＦＴ又はＳＴの発行の契機となる故障が間違いである場合は、オペレータ端末機２２又は卸元端末機２３にてＦＴ又はＳＴのキャンセルが可能となっている。

図２に戻って、破線枠内のステップＳ８〜Ｓ１３の処理を繰り返し、全てのＳＴが復旧した後にＦＴが復旧すれば、卸元事業者から障害申告があった場合の管理装置１０によるトラブルチケット発行処理が終了する。

また、図５に示すように、トラブルチケット管理部１３ａは、複数の卸元事業者の卸元通信装置２０ａ〜２０ｎ（図５では卸元通信装置２０ａを代表して記載する）へ定期的に障害の問合せを行って、この結果に基づき、矢印Ｙ１で示すようにＳＴ２の状態を更新すると共に、矢印Ｙ２で示すようにＦＴ１の状態を更新する。この更新されたＳＴ２，ＦＴ１の状態は、各端末機２１，２２，２３へ提供して、利用者、オペレータ、卸元事業者に閲覧させる。

＜ＦＰ利用者契機の障害申告＞
親ＦＰサービスの利用者から障害申告があった場合の管理装置１０によるトラブルチケット発行及び障害の閲覧提供について、図６〜図８を参照して説明する。

図６のステップＳ３１において、親ＦＰサービス（ＦＰ１）を利用する利用者のユーザ端末機２１からＦＰ１（図７参照）の障害申告が、管理装置１０の業務ＡＰＩ部１１に送信されたとする。業務ＡＰＩ部１１は、ステップＳ３２において、その障害申告に応じたシナリオ３３の呼出しをシナリオ管理部１２に行う。この呼出しを受けたシナリオ管理部１２は、ステップＳ３３において、トラブルチケット発行要求を業務リソース管理部１３に行う。この際、業務リソース管理部１３のトラブルチケット管理部１３ａでシナリオ３３が読み込まれる。

ここで、業務リソース管理部１３は、図７に示すように、サービス状態管理部１３ｂに複数の卸元事業者が提供する３つの子ＳＰサービス（ＳＰ１，ＳＰ２，ＳＰ３）が連携された１つの親ＦＰサービス（ＦＰ１）が保持されているとする。

図６に示すステップＳ３４において、業務リソース管理部１３のトラブルチケット管理部１３ａが、上記のトラブルチケット発行要求時のシナリオ３３に応じて、サービス状態管理部１３ｂから申告元の利用者が利用する親ＦＰサービス情報（ＦＰ１）を検索して抽出する。更に、サービス状態管理部１３ｂは、ステップＳ３５において、その検索されたＦＰ１に関連した（ＦＰ２に紐付けられた）ＳＰ１，ＳＰ２，ＳＰ３を検索して抽出する。ここでは、図７に示す親ＦＰサービス（ＦＰ１）に紐付けられた子ＳＰサービス（ＳＰ１，ＳＰ２，ＳＰ３）が検索されて抽出される。

図６に示すステップＳ３６において、トラブルチケット管理部１３ａは、上記抽出した親ＦＰサービス（ＦＰ１）に、親ＦＴトラブルチケット（ＦＴ１）を発行する。更に、トラブルチケット管理部１３ａは、ステップＳ３７において、上記抽出した各々の子ＳＰサービス（ＳＰ１，ＳＰ２，ＳＰ３）（図７）に対して、子ＳＴトラブルチケット（ＳＴ１，ＳＹ２，…，ＳＴｎ）を発行して紐付ける。

次に、ステップＳ３８において、トラブルチケット管理部１３ａは、各々の卸元通信装置２０ａ〜２０ｎへ障害問合せ要求を行い、アダプタ部１５は、ステップＳ３９において、ＳＰ１，ＳＰ２，ＳＰ３を提供する各卸元通信装置２０ａ〜２０ｃへ障害問合せを行う。ステップＳ４０において、各卸元通信装置２０ａ〜２０ｃは、図７に示すように、その障害問合せに応じた障害情報を応答する。

ここで、ＳＰ２を提供する第２卸元通信装置２０ｂのみが×印で示すように障害が発生しており、この障害の発生が記載された障害情報を応答したとする。但し、その障害が発生していることは、その応答時点では管理装置１０は不明であるとする。次に、各々の応答は、図６のステップＳ４１にてアダプタ部１５を介して業務リソース管理部１３のトラブルチケット管理部１３ａへ通知される。

次に、ステップＳ４２において、トラブルチケット管理部１３ａは、子ＳＴトラブルチケットの状態を、上述した国際標準ＴＭＦ６２１での規定内容に従って更新する。ここでは、障害発生が判明した第２卸元通信装置２０ｂのみが、図８に○印で示すように障害が復旧するまで、ＳＴ２の状態が矢印Ｙ１１で示すように更新される。また、ＳＴ２の状態を更新後には、矢印Ｙ１２で示すようにＦＴ１の状態が更新される。この更新されたＳＴ２，ＦＴ１の状態は、各端末機２１，２２，２３へ提供して、利用者、オペレータ、卸元事業者に閲覧させる。なお、ステップＳ４３のＦＴ１の状態更新は、図４を参照して説明したように行われる。

また、図７に示す障害の無い子ＳＴトラブルチケット（ＳＴ１，ＳＴ３）は削除してＳＴの状態更新の処理を終了させる。障害の有る第２卸元通信装置２０ｂは、障害が復旧した時点でＳＴ２（図８）を削除してＳＴの状態更新の処理を終了させる。

＜トラブルチケット情報の閲覧１＞
ユーザ端末機２１、オペレータ端末機２２、卸元端末機２３、卸先端末機２６（図１０参照）からトラブルチケット情報の閲覧要求があった場合の第１の閲覧制限について、図９及び図１０を参照して説明する。図９に示す閲覧端末機２５は、図１０に示すように、卸元事業者から卸されたＦＰ１，ＦＰ３を利用する卸先自業者（上記ミドルＢ）の卸先端末機２６と、ＦＰ１を利用するユーザ端末機２１ａと、ＦＰ２を利用するユーザ端末機２１ｂと、オペレータ端末機２２と、ＳＴ２，ＳＴ５を卸す卸元通信装置２０ｂであるとする。

図９のステップＳ５１において、閲覧端末機２５から障害の閲覧要求が、管理装置１０の業務ＡＰＩ部１１に送信されたとする。即ち、図１０に示すように、卸先端末機２６、ユーザ端末機２１ａ、ユーザ端末機２１ｂ、オペレータ端末機２２及び卸元通信装置２０ｂの卸元端末機２３から障害の閲覧要求が業務ＡＰＩ部１１に送信されたとする。

業務ＡＰＩ部１１は、ステップＳ５２において、その閲覧要求を業務リソース管理部１３へ通知する。ステップＳ５３において、業務リソース管理部１３のトラブルチケット管理部１３ａは、組織管理部１３ｃ及び顧客管理部１３ｄから閲覧要求元の閲覧者に対応する閲覧者情報を検索する。閲覧者情報は、トラブルチケット情報の閲覧制限を行うために、組織管理部１３ｃに保持された卸元事業者等の組織が何をする組織か等の組織の内容を示す情報と、顧客管理部１３ｄに保持された利用者の個人情報である。このような閲覧者情報によって、閲覧要求を行った閲覧者への閲覧制限が掛けられる。

トラブルチケット管理部１３ａ（図１０）には、ＳＴ１，ＳＴ２，ＳＴ３が紐付けられたＦＴ１と、ＳＴ４，ＳＴ５，ＳＴ６が紐付けられたＦＴ２と、ＳＴ１，ＳＴ５，ＳＴ７が紐付けられたＦＴ３とが、トラブルチケット情報として保持されているとする。

ステップＳ５４において、トラブルチケット管理部１３ａは、上記で検索された閲覧者情報の閲覧制限に応じたトラブルチケット情報を、トラブルチケット管理部１３ａから検索して抽出する。例えば、卸先端末機２６に対しては、ＳＴ１，ＳＴ２，ＳＴ３が紐付けられたＦＴ１と、ＳＴ１，ＳＴ５，ＳＴ７が紐付けられたＦＴ３とが抽出される。ユーザ端末機２１ａに対してはＦＴ１が抽出される。ユーザ端末機２１ｂに対しては、後述するようにトラブルチケット情報が発行されるが、サービスが継続しているため、トラブルチケット情報が見えない状態とされる。オペレータ端末機２２に対しては、トラブルチケット管理部１３ａに保持された全てのＦＴ１，ＦＴ２，ＦＴ３が抽出される。卸元通信装置２０ｂには、ＳＴ２，ＳＴ５が抽出される。

ステップＳ５５において、トラブルチケット管理部１３ａは、上記抽出したトラブルチケット情報を業務ＡＰＩ部１１へ応答し、ステップＳ５６において、業務ＡＰＩ部１１はトラブルチケット情報を閲覧端末機２５へ提供（応答）する。

但し、図１０に枠４１で囲んで示すＦＰ１の実際のサービス状態は、ＦＰ１の利用者（例えば、ユーザ端末機２１）がＳＰ１，ＳＰ３の両系を利用しており、この際のＳＰ１，ＳＰ３の両系が故障しているものとする。なお、故障している状態を網掛けで示す。このＳＰ１，ＳＰ３の両系の故障により、ユーザ端末機２１に対するサービスは断となる。この場合、トラブルチケット管理部１３ａによって、トラブルチケット情報として、ＳＴ１，ＳＴ３が発行されることになる。

次に、枠４２で囲んで示すＦＰ２の実際のサービス状態は、ＦＰ１の利用者（例えば、ユーザ端末機２１）がＳＰ４，ＳＰ２２の両系を利用しており、この際のＳＰ４のみが故障しているものとする。このようにＳＰ４，ＳＰ２２の両系の内、ＳＰ４が故障している場合、ＳＰ２２は正常なので利用者に対するサービスは継続となる。この場合、上位の卸元事業者から見ると正常なＳＰ２２に対してはトラブルチケット情報は未発行だが、故障中のＳＰ４に対してはトラブルチケット情報のＳＴ４を発行する。このケースの場合、利用者（例えば、ユーザ端末機２１）へのサービスはＳＰ２２で継続しているので、トラブルチケット管理部１３ａは、ＳＰ４のトラブルチケット情報であるＳＴ４は見せない（閲覧制限する）ように処理する。

＜トラブルチケット情報の閲覧２＞
ユーザ端末機２１、オペレータ端末機２２、卸元端末機２３からトラブルチケット情報の閲覧要求があった場合の第２の閲覧制限について、図１１及び図１２を参照して説明する。
前提条件として、親ＦＰサービスを利用するユーザ端末機２１から障害申告があった場合、どの子ＳＰサービスに障害が発生しているか不明な状況である。この状況下で、他のユーザ端末機の利用者が閲覧要求を行った場合、障害が生じていない子ＳＰサービスに対してもトラブルチケット情報が一時的に発行されてしまうケースがある。このケースの場合、障害が発生していないにも関わらず、障害が発生したとのトラブルチケット情報を閲覧させる不具合が生じる可能性がある。第２の閲覧制限は、そのような不具合が生じることを無くす処理である。

卸元端末機２３からの障害申告の場合は、通信サービス提供元に障害が発生している。このため、トラブルチケット管理部１３ａは、図１１に示すように、全ての閲覧者、即ち、ユーザ端末機２１、オペレータ端末機２２、卸元端末機２３に、その障害のトラブルチケット情報を閲覧させる処理を行う。

一方、親ＦＰサービスを利用するユーザ端末機２１から障害申告があった場合、図１２に示すように、第２卸元通信装置２０ｂでのＳＰ２に×印で示す障害が発生しているが、この時点では、どの子ＳＰサービスに障害が発生しているか不明な状況である。言い換えれば、トラブルチケットを発行する際に障害箇所が確定していない。この場合、正常な子ＳＰサービスに対しても子ＳＴトラブルチケットを発行している場合がある。そこで、符号５１の禁止記号で示すように、閲覧者である全てのユーザ端末機２１、オペレータ端末機２２、卸元端末機２３へのトラブルチケット情報の閲覧を制限する。

この閲覧制限の後、トラブルチケット管理部１３ａは、図１２に矢印Ｙ２１で示すように、卸元通信装置２０ａ〜２０ｎに障害の問合せを行った後、正常な卸元通信装置２０ａ，２０ｎの通信サービスの検出をクローズする。この後、障害が発生している卸元通信装置２０ｂに対する障害を確定（障害箇所確定）する。この確定後、ＳＴ２が紐付けられたＦＴ１の閲覧を、閲覧者である全てのユーザ端末機２１、オペレータ端末機２２、卸元端末機２３へ提供する。

＜インターネット経由で障害情報収集＞
管理装置１０がインターネットを介して卸元通信装置２０ａ〜２０ｎの障害を収集する場合について、図１３及び図１４を参照して説明する。
図１３に示すステップＳ６１において、障害情報収集判定部１４がインターネット３０を経由して、卸元通信装置２０ａ〜２０ｎから子ＳＰサービス情報の定期収集を行う。この後、ステップＳ６２において、障害情報収集判定部１４は、収集した子ＳＰサービスにおいて、障害発生の判定を開始する。この判定は、まず、ステップＳ６３，Ｓ６４において、アダプタ部１５を介して卸元通信装置２０ａ〜２０ｎに障害の問合せ要求を行う。次に、その要求に応じて、ステップＳ６５において、卸元通信装置２０ａ〜２０ｎから応答が返信され、この障害問合せ結果が障害情報収集判定部１４に通知されることで判定が行われる。

その障害問合せの結果、図１４に×印で示すように、卸元通信装置２０ｂに障害が発生していたとする。障害情報収集判定部１４は、ステップＳ６７において、その障害発生を判定する。この障害発生の判定は、上述した障害申告に依存せず行われる。障害情報収集判定部１４は、予め設定された「障害名」と「卸元事業者名」とのアンド条件に適合して検索された障害情報を、例えば６０分の特定時間内にカウントし、このカウント数が、予め定められた閾値を超えたら障害発生と判定する。この判定後、障害情報収集判定部１４は、ステップＳ６８において、卸元通信装置２０ｂに係るトラブルチケットシナリオの呼出しをシナリオ管理部１２に行う。シナリオ管理部１２は、ステップＳ６９において、トラブルチケット発行要求を業務リソース管理部１３に行う。この際、業務リソース管理部１３のトラブルチケット管理部１３ａでシナリオ３３が読み込まれる。

ステップＳ７０において、業務リソース管理部１３のトラブルチケット管理部１３ａは、上記のトラブルチケット発行要求時のシナリオ３３に応じて、サービス状態管理部１３ｂから申告元の卸元事業者のＳＰ情報（ＳＰ２）を検索して抽出する。更に、サービス状態管理部１３ｂは、ステップＳ７１において、その検索されたＳＰ２が紐付けられたＦＰ１を検索して抽出する。

ステップＳ７２において、トラブルチケット管理部１３ａは、図１４に示すように、上記抽出した全ての親ＦＰサービスＦＰ１に、親ＦＴトラブルチケットＦＴを発行する。更に、トラブルチケット管理部１３ａは、ステップＳ７３において、ＦＴ１に対して、子ＳＴトラブルチケットＳＴ２を発行して紐付ける。

次に、ステップＳ７４において、トラブルチケット管理部１３ａは、アダプタ部１５へ障害申告を行った卸元通信装置２０ａを有する卸元事業者への障害問合せ要求を行い、アダプタ部１５は、ステップＳ７５において、ＳＰ２を提供する卸元通信装置２０ｂ（図１４参照）へ障害問合せを行う。卸元通信装置２０ａは、ステップＳ７６において、その障害問合せに応じた障害情報を応答する。この応答は、ステップＳ７７にてアダプタ部１５を介して業務リソース管理部１３のトラブルチケット管理部１３ａへ通知される。

次に、ステップＳ７８において、トラブルチケット管理部１３ａは、子ＳＴトラブルチケットＳＴ２の状態を国際標準ＴＭＦ６２１での規定内容に従って更新する。

次に、ステップＳ７９において、トラブルチケット管理部１３ａが親ＦＴトラブルチケットＦＴ１の状態を、前述で図４を参照して説明したように更新する。この破線枠内のステップＳ７４〜Ｓ７９の処理は、卸元通信装置２０ｂのＳＴ２，ＦＴ１が復旧するまで行われる。

＜実施形態の効果＞
以上説明したように、本実施形態の通信サービス管理装置１０は、通信サービスを卸す複数の卸元通信装置２０ａ〜２０ｎが提供する各種の通信サービスの子サービスを連携させて紐付けた１つの親サービスを利用者のユーザ端末機２１等に提供するものである。この管理装置１０を次のような特徴構成とした。
（１）管理装置１０を、業務ＡＰＩ部１１、シナリオ管理部１２、業務リソース管理部１３を備える構成とした。
業務ＡＰＩ部１１は、卸元通信装置２０ａ〜２０ｎを含む通信システムの通信に係る操作が行われるオペレータ端末機２２、ユーザ端末機２１、卸元通信装置２０ａ〜２０ｎ（卸元端末機２３）の何れか１つから送信されてくる障害申告を受け付ける。また、子ＳＰサービス及び親ＦＰサービスの障害情報及び復旧情報をオペレータ端末機２２、ユーザ端末機２１、卸元通信装置２０ａ〜２０ｎ（卸元端末機２３）へ提供する。

シナリオ管理部１２は、業務ＡＰＩ部１１で受け付けられた障害申告に応じて、障害情報が記載されるトラブルチケット発行の制御内容が記載されたシナリオ３３を記憶部に記憶する。

業務リソース管理部１３は、各種の通信サービスである子ＳＰサービスが連携されて紐付けられた１つの親ＦＰサービスの情報を、複数の卸元通信装置２０ａ〜２０ｎ毎に記憶部に記憶する。また、業務ＡＰＩ部１１で受け付けられた障害申告に係る親ＦＰサービス又は子ＳＰサービスの情報を記憶部から検索し、この検索された親ＦＰサービスの障害電子票である親ＦＴトラブルチケットと、子ＳＰサービスの障害電子票である子ＳＴトラブルチケットとを、シナリオに従って発行して記憶部に保持する。

この構成によれば、業務リソース管理部１３が、各種の通信サービスである子ＳＰサービスが連携されて紐付けられた親ＦＰサービスの情報を、複数の卸元通信装置２０ａ〜２０ｎ毎に記憶して管理している。そして、障害申告があった際に、シナリオ３３に従って、その記憶された親ＦＰサービスの親ＦＴトラブルチケットと、子ＳＰサービスの子ＳＴトラブルチケットとを発行するようにした。このため、各卸元通信装置２０ａ〜２０ｎの各種の通信サービスである子ＳＰサービスを連携させて紐付けた連携サービスとしての親ＦＰサービスの障害を、利用者、全体の通信システムのオペレータ、卸元通信装置２０ａ〜２０ｎを所持する卸元事業者等へ提供することができる。

（２）業務リソース管理部１３は、業務ＡＰＩ部１１が卸元通信装置２０ａ〜２０ｎからの障害申告を受け付けた際に、当該障害申告を行った卸元通信装置２０ａ〜２０ｎの子ＳＰサービスが紐付けられた親ＦＰサービスの情報を記憶部から検索し、この検索された親ＦＰサービスに対する親ＦＴトラブルチケットと、当該親ＦＰサービスに紐付けられた子ＳＰサービスに対する子ＳＴトラブルチケットとを、シナリオに従って発行する。この発行された子ＳＴトラブルチケットに係る子ＳＰサービスを提供する卸元通信装置２０ａ〜２０ｎの障害が発生中であれば当該子ＳＴトラブルチケットを障害に応じて更新しながら発行を継続し、復旧していれば当該子ＳＴトラブルチケットを削除する。更に、この削除された子ＳＴトラブルチケットに紐付けられた親ＦＴトラブルチケットに係る親ＦＰサービスを提供する卸元通信装置２０ａ〜２０ｎの障害が発生中であれば当該親ＦＴトラブルチケットを障害に応じて更新しながら発行を継続し、復旧していれば当該親ＦＴトラブルチケットを削除するようにした。

これによって、まず、卸元通信装置２０ａ〜２０ｎから障害申告があった際に、障害申告を行った卸元通信装置２０ａ〜２０ｎの子ＳＰサービスが紐付けられた親ＦＰサービスを検索する。次に、検索された親ＦＰサービスに対する親ＦＴトラブルチケットと、その親ＦＰサービスに紐付けられた子ＳＰサービスに対する子ＳＴトラブルチケットとを障害に応じて更新しながら発行又は削除して、親ＦＰサービス及び子ＳＰサービスの障害情報及び復旧情報を管理することができる。

（３）業務リソース管理部１３は、親ＦＰサービスを利用するユーザ端末機２１からの障害申告を受け付けた際に、当該親ＦＰサービスに対する親ＦＴトラブルチケットをシナリオに従って発行する。また、親ＦＰサービスに紐付けられた子ＳＰサービスの情報を記憶部から検索し、この検索された子ＳＰサービスに対する子ＳＴトラブルチケットをシナリオに従って発行する。この発行された子ＳＴトラブルチケットに係る子ＳＰサービスを提供する卸元通信装置２０ａ〜２０ｎに障害が発生中であれば障害が復旧するまで障害状況を問合せ、障害に応じて子トラブルチケットを更新しながら発行を継続し、復旧すれば当該子ＳＴトラブルチケットを削除する。更に、その削除された子ＳＴトラブルチケットに紐付けられた親ＦＴトラブルチケットに係る親ＦＰサービスを提供する卸元通信装置２０ａ〜２０ｎの障害が発生中であれば当該親ＦＴトラブルチケットを障害に応じて更新しながら発行を継続し、復旧していれば当該親ＦＴトラブルチケットを削除するようにした。

これによって、親ＦＰサービスを利用するユーザ端末機２１から障害申告があった際に、障害申告に係る親ＦＰサービスに対する親ＦＴトラブルチケットと、その親ＦＰサービスに紐付けられた子ＳＰサービスに対する子ＳＴトラブルチケットとを発行する。この発行された子ＳＴトラブルチケットに係る子ＳＰサービスを提供する卸元通信装置２０ａ〜２０ｎに障害が発生中であれば障害が復旧するまで障害状況を問合せ、障害に応じて子ＳＴトラブルチケットを更新しながら発行を継続する。このため、どの子ＳＰサービスに障害が発生しているか分からない場合でも、子ＳＰサービスの障害が復旧するまで子ＳＴトラブルチケットで障害を管理することができる。

（４）業務リソース管理部１３は、親ＦＴトラブルチケットの発行時に、この発行された親ＦＴトラブルチケットに紐付けられた子ＳＴトラブルチケットを障害に基づき発行した後、発行された全ての親トラブルチケットに係る故障が復旧されたか否かを判定し、当該全ての親トラブルチケットに係る故障が復旧していれば当該全ての親トラブルチケットを削除するようにした。

これによって、親ＦＴトラブルチケットの発行時に、この発行された親ＦＴトラブルチケットに紐付けられた子ＳＴトラブルチケットを障害に基づき発行することで、親ＦＴトラブルチケットの障害状態の更新を行うことができる。また、親ＦＴトラブルチケットに紐付けられた全ての子ＳＴトラブルチケットの障害が復旧する毎に、発行された全ての親ＦＴトラブルチケットに係る故障が復旧されたか否かを判定し、全ての親ＦＴトラブルチケットに係る故障が復旧していれば全ての親ＦＴトラブルチケットを削除するので、上記のように障害状況の更新が行われながら発行されている全ての親ＦＴトラブルチケットを、全ての復旧後に確実に削除することができる。

（５）業務リソース管理部１３は、子ＳＴトラブルチケット及び親ＦＴトラブルチケットであるトラブルチケット情報の閲覧者に応じた閲覧制限を保持する保持部（組織管理部１３ｃ及び顧客管理部１３ｄ）を備える。そして、オペレータ端末機２２、ユーザ端末機２１、卸元通信装置２０ａ〜２０ｎ及び卸先端末機の何れか１つの閲覧端末機２５から送信されてくるトラブルチケット情報の閲覧要求を受け付けた際に、当該閲覧要求の送信元の閲覧端末機２５に係る閲覧者に対応付けられた閲覧制限を保持部から検索し、この検索された閲覧制限に応じたトラブルチケット情報を業務ＡＰＩ部１１を介して閲覧端末機２５へ提供するようにした。

これによって、連携された各種の通信サービスを閲覧するシステムのオペレータ、卸元事業者及びエンドユーザ等の閲覧者の閲覧を、異なる立場に応じて制限することができる。

（６）業務リソース管理部１３は、閲覧端末機２５に提供される親ＦＰサービスに紐付く複数の子ＳＰサービスの内、何れかの子ＳＰサービスに障害が発生している場合に、冗長化している子ＳＰサービスにおいて1つの子ＳＰサービスでも正常であれば、当該子ＳＰサービスは正常とみなし、その障害発生中の子ＳＰサービスに対して発行した子ＳＴトラブルチケットのみを、当該閲覧端末機２５に対して閲覧不可能に制限する処理を行うようにした。

これによって、複数の子ＳＰサービスを閲覧可能な閲覧端末機２５の利用者は、冗長化している子ＳＰサービスにおいて1つの子ＳＰサービスでも正常であれば、当該子ＳＰサービスは正常とみなし、その障害発生中の子ＳＰサービスに対して発行した子トラブルチケットのみを、閲覧不可能とすることができる。

（７）業務リソース管理部１３は、卸元通信装置２０ａ〜２０ｎからの障害申告に係るトラブルチケット情報の発行時に、当該発行されたトラブルチケット情報の閲覧を閲覧端末機２５に許可し、親ＦＰサービスを利用するユーザ端末機２１からの障害申告に係るトラブルチケット情報の発行時に、閲覧端末機２５への閲覧を制限した後、トラブルチケット発行対象の卸元通信装置に問合せを行う。この問合せで、正常であることが確認された卸元通信装置についてはトラブルチケット削除後、問合せ処理を停止し、障害が発生している卸元通信装置に対する障害を確定後に、この確定された障害に係る子ＳＴトラブルチケットが紐付けられた親ＦＴトラブルチケットの閲覧を当該閲覧端末機２５に許可するようにした。

ところで、親ＦＰサービスを利用するユーザ端末機２１からの障害申告があった場合は、どの子ＳＰサービスに障害が発生しているか不明な状況である。この状況下で、他のユーザ端末機２１の利用者が閲覧要求を行った場合、障害が生じていない子ＳＰサービスに対してもトラブルチケット情報が一時的に発行されてしまう場合がある。この場合、障害が発生していないにも関わらず、障害が発生したとのトラブルチケット情報を閲覧させる不具合が生じる可能性がある。しかし、本実施形態では、トラブルチケット発行対象の卸元通信装置に問合せを行い、正常であることが確認された卸元通信装置についてはトラブルチケット削除後、問合せ処理を停止し、障害が発生している卸元通信装置に対する障害を確定後に、この確定された障害に係る子ＳＴトラブルチケットが紐付けられた親ＦＴトラブルチケットに係る閲覧を許可するので、上記不具合が生じないようにすることができる。

（８）管理装置１０は、インターネットを介して卸元通信装置２０ａ〜２０ｎから子ＳＰサービスの障害情報を受信し、予め設定された障害名と卸元事業者名のアンド条件に適合して検索された障害情報を特定時間内にカウントし、このカウント数が予め定められた閾値を超えた際に障害発生と判定する障害情報収集判定部１４を更に備える。業務リソース管理部１３は、障害情報収集判定部１４で障害発生と判定された際に、業務ＡＰＩ部１１が卸元通信装置２０ａ〜２０ｎからの障害申告を受け付けた際の上述した障害に係る処理と同様の処理を行うようにした。

この構成によれば、卸元通信装置２０ａ〜２０ｎからの障害申告を受け付けなくとも、インターネットを介して卸元通信装置２０ａ〜２０ｎから障害情報を収集することができる。

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

１０ 通信サービス管理装置
１１ 業務ＡＰＩ部
１２ シナリオ管理部
１３ 業務リソース管理部
１３ａ トラブルチケット管理部
１３ｂ サービス状態管理部
１３ｃ 組織管理部
１３ｄ 顧客管理部
１４ 障害情報収集判定部
１５ 卸元事業者ＡＰＩアダプタ部
２０ａ〜２０ｎ 卸元通信装置
２１ ユーザ端末機
２２ オペレータ端末機
２３ 卸元端末機
３０ インターネット

Claims (9)

1. 通信サービスを卸す複数の卸元通信装置が提供する各種の通信サービスとしての子サービスを連携させて紐付けた１つの親サービスを利用者のユーザ端末機に提供する通信サービス管理装置であって、
   前記卸元通信装置を含む通信システムの通信に係る操作が行われるオペレータ端末機、前記ユーザ端末機、前記卸元通信装置の何れか１つから送信されてくる障害申告を受け付けると共に、前記子サービス及び前記親サービスの障害情報及び復旧情報を前記オペレータ端末機、前記ユーザ端末機、前記卸元通信装置へ提供する業務ＡＰＩ部と、
   前記業務ＡＰＩ部で受け付けられた障害申告に応じて、障害情報が記載されるトラブルチケット発行の制御内容が記載されたシナリオを記憶部に記憶するシナリオ管理部と、
   前記卸元通信装置が前記子サービスを提供し、前記親サービスに紐付けられた複数の当該子サービスの情報を、当該親サービス毎に記憶部に記憶し、前記業務ＡＰＩ部で受け付けられた障害申告に係る前記親サービス又は前記子サービスの情報を当該記憶部から検索し、この検索された親サービスの障害電子票である親トラブルチケットと、子サービスの障害電子票である子トラブルチケットとを、前記シナリオに従って発行して記憶部に保持する業務リソース管理部と
   を備えることを特徴とする通信サービス管理装置。
2. 前記業務リソース管理部は、
   前記業務ＡＰＩ部が前記卸元通信装置からの障害申告を受け付けた際に、当該障害申告を行った卸元通信装置の子サービスを検索し、検索された子サービスに紐付けられた親サービスを検索し、この検索された親サービスに対する前記親トラブルチケットと、当該親サービスに紐付けられた子サービスに対する前記子トラブルチケットとを、前記シナリオに従って発行し、
   この発行された子トラブルチケットに係る子サービスを提供する卸元通信装置の障害が発生中であれば当該子トラブルチケットを障害に応じて更新しながら発行を継続し、復旧していれば当該子トラブルチケットを削除し、
   この削除された子トラブルチケットに紐付けられた親トラブルチケットに係る親サービスを提供する卸元通信装置の障害が発生中であれば当該親トラブルチケットを障害に応じて更新しながら発行を継続し、復旧していれば当該親トラブルチケットを削除する処理を行う
   ことを特徴とする請求項１に記載の通信サービス管理装置。
3. 前記業務リソース管理部は、
   前記親サービスを利用する前記ユーザ端末機からの障害申告を受け付けた際に、当該親サービスに対する前記親トラブルチケットを前記シナリオに従って発行し、
   前記親サービスに紐付けられた前記子サービスの情報を前記記憶部から検索し、この検索された子サービスに対する前記子トラブルチケットを前記シナリオに従って発行し、
   この発行された子トラブルチケットに係る子サービスを提供する卸元通信装置に障害が発生中であれば障害が復旧するまで障害状況を問合せ、障害に応じて前記子トラブルチケットを更新しながら発行を継続し、復旧すれば当該子トラブルチケットを削除し、
   この削除された子トラブルチケットに紐付けられた親トラブルチケットに係る親サービスを提供する卸元通信装置の障害が発生中であれば当該親トラブルチケットを障害に応じて更新しながら発行を継続し、復旧していれば当該親トラブルチケットを削除する処理を行う
   ことを特徴とする請求項１に記載の通信サービス管理装置。
4. 前記業務リソース管理部は、
   前記親トラブルチケットの発行時に、この発行された親トラブルチケットに紐付けられた前記子トラブルチケットを障害に基づき発行した後、親トラブルチケットに紐付けられた全ての子トラブルチケットの障害が復旧する毎に、発行された全ての親トラブルチケットに係る故障が復旧されたか否かを判定し、当該全ての親トラブルチケットに係る故障が復旧していれば当該全ての親トラブルチケットを削除する処理を行う
   ことを特徴とする請求項２又は３に記載の通信サービス管理装置。
5. 前記業務リソース管理部は、
   前記子トラブルチケット及び前記親トラブルチケットであるトラブルチケット情報の閲覧者に応じた閲覧制限を保持する保持部を備え、
   前記オペレータ端末機、前記ユーザ端末機、前記卸元通信装置及び卸先端末機の何れか１つの閲覧端末機から送信されてくるトラブルチケット情報の閲覧要求を受け付けた際に、当該閲覧要求の送信元の閲覧端末機に係る閲覧者に対応付けられた閲覧制限を前記保持部から検索し、この検索された閲覧制限に応じたトラブルチケット情報を前記業務ＡＰＩ部を介して当該閲覧端末機へ提供する処理を行う
   ことを特徴とする請求項１〜４の何れか１項に記載の通信サービス管理装置。
6. 前記業務リソース管理部は、
   前記閲覧端末機に提供される前記親サービスに紐付く複数の前記子サービスの内、何れかの子サービスに障害が発生し、冗長化している子サービスにおいて1つの子サービスでも正常であれば、当該子サービスは正常とみなし、その障害発生中の子サービスに対して発行した前記子トラブルチケットのみを、当該閲覧端末機に対して閲覧不可能に制限する処理を行う
   ことを特徴とする請求項５に記載の通信サービス管理装置。
7. 前記業務リソース管理部は、
   前記卸元通信装置からの障害申告に係るトラブルチケット情報の発行時に、この発行されたトラブルチケット情報の閲覧を前記閲覧端末機に許可し、
   前記親サービスを利用する前記ユーザ端末機からの障害申告に係るトラブルチケット情報の発行時に、前記閲覧端末機への閲覧を制限した後、トラブルチケット発行対象の卸元通信装置に問合せを行い、正常であることが確認された卸元通信装置についてはトラブルチケット削除後、問合せ処理を停止し、障害が発生している卸元通信装置に対する障害を確定後に、この確定された障害に係る子トラブルチケットが紐付けられた親トラブルチケットの閲覧を当該閲覧端末機に許可する処理を行う
   ことを特徴とする請求項５に記載の通信サービス管理装置。
8. インターネットから、前記卸元通信装置が提供する子サービスの障害情報を収集し、予め設定された障害名と卸元事業者名とのアンド条件に適合して検索された障害情報を、特定時間内にカウントし、このカウント数が予め定められた閾値を超えた際に障害発生と判定する障害情報収集判定部を更に備え、
   前記業務リソース管理部は、前記障害情報収集判定部で障害発生と判定された際に、前記業務ＡＰＩ部が前記卸元通信装置又は前記ユーザ端末機からの障害申告を受け付けた際の障害に係る処理と同様の処理を行う
   ことを特徴とする請求項２〜７の何れか１項に記載の通信サービス管理装置。
9. 通信サービスを卸す複数の卸元通信装置が提供する各種の通信サービスの子サービスを連携させて紐付けた１つの親サービスを利用者のユーザ端末機に提供する通信サービス管理装置による通信サービス管理方法であって、
   通信サービス管理装置は、
   受け付けた障害申告に応じて障害情報が記載されるトラブルチケット発行の制御内容が記載されたシナリオを記憶すると共に、前記卸元通信装置が前記子サービスを提供し、前記親サービスに紐付けられた複数の当該子サービスの情報を、当該親サービス毎に記憶する記憶部を備え、
   前記卸元通信装置を含む通信システムの通信に係る操作が行われるオペレータ端末機、前記ユーザ端末機、前記卸元通信装置の何れか１つから送信されてくる障害申告を受け付けるステップと、
   前記受け付けられた障害申告に係る前記親サービス又は前記子サービスの情報を前記記憶部から検索するステップと、
   前記検索された親サービスの障害電子票である親トラブルチケットと、子サービスの障害電子票である子トラブルチケットとを、前記シナリオに従って発行して前記記憶部に保持するステップと、
   前記子サービス及び前記親サービスの障害情報及び復旧情報を前記オペレータ端末機、前記ユーザ端末機、前記卸元通信装置へ提供するステップと
   を実行することを特徴とする通信サービス管理方法。

Images