(57)【要約】【課題】ユーザが通信サービスや通信サービス提供者、更にはアプリケーションに応じた通信サービスを意識することなく利用可能とすべく、異なる通信制御装置を統括して管理するサービスマネジメントシステム及び方法を提供する。【解決手段】本発明のサービスマネジメントシステム及び方法は、クライアント端末７ａからの１つのＸＭＬによるサービス要求を、プロバイダポリシ及びコントラクトポリシに基づいて、複数の分割サービス要求に分割し、当該分割サービス要求を各ネットワークマネジメントシステム４ａ，４ｂ，４ｃ・・・に送信し、その応答を合併することで上記サービス要求に対する応答を作成し、当該応答を上記クライアント端末７ａに送信するように統括管理するものである。【選択図】    図１
2004341566.tif 000002
【特許請求の範囲】
【請求項１】
クライアント端末からのＸＭＬによるサービス要求を通信手段にて受信し、当該サービス要求を、記憶手段に記憶されたプロバイダポリシ及びコントラクトポリシに基づいて、複数の分割サービス要求に分割し、当該分割サービス要求を通信手段を介して各ネットワークマネジメントシステムに送信し、各ネットワークマネジメントシステムからの応答を合併することで上記サービス要求に対する応答を作成し、当該応答を上記通信手段を介して上記クライアント端末に送信するように制御する制御手段を有することを特徴とするサービスマネジメントシステム。
【請求項２】
少なくとも通信利用者のクライアント端末、通信事業者のネットワークマネジメントシステムとの間で通信を行うものであり、上記クライアント端末からのＸＭＬによるサービス要求を受信する通信手段と、
上記通信事業者が予め登録したプロバイダポリシ、及び上記通信利用者が予め登録したコントラクトポリシを蓄積する記憶手段と、
上記プロバイダポリシ、コントラクトポリシに基づいて、上記サービス要求を関連する複数の分割サービス要求に分割し、それらを上記通信手段を介して各ネットワークマネジメントシステムに送信し、各ネットワークマネジメントシステムからの応答を合併することで上記サービス要求に対する応答を作成し、当該応答を上記通信手段を介して上記クライアント端末に送信するように制御する制御手段と、を具備することを特徴とするサービスマネジメントシステム。
【請求項３】
上記プロバイダポリシには、プロバイダＩＤ、ネットワークタイプ、ネットワークプロトコル、アクセスポイント、Ｑｏｓ、セキュリティポリシ、請求情報が少なくとも含まれており、上記コントラクトポリシには、コントラクトＩＤ、ユーザＩＤ、ネットワークタイプ、ネットワークプロトコル、アクセスポイント、セキュリティポリシ、支払情報が少なくとも含まれている、ことを更なる特徴とする請求項２に記載のサービスマネジメントシステム。
【請求項４】
上記ＸＭＬによるサービス要求に添付された電子署名に基づいて当該サービス要求の内容に関して正当性を検証することを更に特徴とする請求項２に記載のサービスマネジメントシステム。
【請求項５】
上記ＸＭＬによるサービス要求に添付された通信利用者のバイオメトリクスデータに基づいて、当該通信利用者を一意に特定することを更に特徴とする請求項２に記載のサービスマネジメントシステム。
【請求項６】
上記ＸＭＬによるサービス要求の少なくとも一部は共通鍵暗号方式又は公開鍵暗号方式のいずれかを用いて暗号化されており、当該サービス要求の機密性が保持されていることを更に特徴とする請求項２に記載のサービスマネジメントシステム。
【請求項７】
上記通信事業者のネットワークマネジメントシステムは異なる通信サービスを管理するためのものであり、当該通信サービスには専用線、波長ＶＰＮ、ＭＰＬＳ−ｂａｓｅｄ  ＶＰＮ、Ｌ２ＴＰ／ＩＰｓｅｃ−ｂａｓｅｄ  ＶＰＮ、ＩＰｓｅｃ−ｂａｓｅｄ  ＶＰＮの少なくともいずれかに係るサービスが含まれることを更に特徴とする請求項２に記載のサービスマネジメントシステム。
【請求項８】
複数の通信利用者のクライアント端末間での通信を制御するサービスマネジメントシステムにおいて、
上記送信元のクライアント端末からのＸＭＬによるサービス要求を受信し、当該サービス要求に基づいて送信先のクライアント端末に関わる他のゲートウェイ装置を探索し、当該サービス要求に基づいてオンデマンド接続ネットワークを利用するのか或いは常時接続ネットワークを利用するのかを判断するためのマネジャ部と、オンデマンド接続ネットワークを利用する場合にＸＢＳで制御されるＧＭＰＬＳノードと、常時接続ネットワークを利用する場合に通信制御を行うルータと、を含むゲートウェイ装置、
を有することを特徴とするサービスマネジメントシステム。
【請求項９】
上記サービス要求には、ソースノードＩＤ、デスティネーションノードＩＤ、アプリケーションタイプ、利用ネットワークタイプ、ユーザ情報、ＱｏＳ、セキュリティオプション、スケジュール情報、時刻証明書、電子証明書の少なくともいずれかを含むことを更なる特徴とする請求項１，２，８のいずれかに記載のサービスマネジメントシステム。
【請求項１０】
上記ＸＭＬによるサービス要求に含まれる時刻証明書に基づいて当該サービス要求の内容に関して正当性を検証することを更に特徴とする請求項２，８のいずれかに記載のサービスマネジメントシステム。
【請求項１１】
通信利用者のクライアント端末、通信事業者のネットワークマネジメントシステムとネットワークを介して通信自在に構成されたサービスマネジメントシステムによるサービスマネジメント方法において、
上記クライアント端末からのＸＭＬによるサービス要求を受け、上記通信事業者が予め登録するプロバイダポリシ、及び上記通信利用者が予め登録するコントラクトポリシに基づいて、当該サービス要求を関連する複数の分割サービス要求に分割し、それらを各ネットワークマネジメントシステムに送信し、各ネットワークマネジメントシステムからの応答を合併することで上記サービス要求に対する応答を作成し、当該応答を上記クライアント端末に送信する、ことを特徴とするサービスマネジメント方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えば通信回線を自動的に提供するシステムに適用されるものであり、特に異なる通信制御装置を統括して管理するサービスマネジメントシステム及びサービスマネジメント方法に関するものである。
【０００２】
【従来の技術】
従来、通信回線提供者は、顧客からの通信回線の設定や変更、削除に係る要求を書類で受け付け、それを基に人手で各種作業を行っているが、このような状況下では、顧客からの迅速な回線制御の要求に応えることができない。
【０００３】
さらに、ＧＭＰＬＳ（ｇｅｎｅｒａｌｉｚｅｄ  ｍｕｌｔｉｐｒｏｔｏｃｏｌ  ｌａｂｅｌ  ｓｗｉｔｃｈｉｎｇ）等に関する各種標準化団体でも回線設定の自動化に関する標準化作業に繋がったものの、これらに関する各種標準化団体で議論されている回線制御方式は、そのセキュリティの甘さとＯＳＳ（ｏｐｅｒａｔｉｏｎ  ｓｕｐｐｏｒｔ  ｓｙｓｔｅｍ）との連携を考慮に入れていないことが指摘されている。かかる点に鑑みて、顧客、通信機器、アプリケーションからの通信回線の設定や変更、削除に係る要求をＸＭＬ（ｅｘｔｅｎｓｉｂｌｅ  ｍａｒｋｕｐ  ｌａｎｇｕａｇｅ）データで受け付け、更にはセキュリティの確保等も図った自動通信回線提供システムが提案されている。
【０００４】
【発明が解決しようとする課題】
しかしながら、上記従来技術は、ポイントｔｏポイントの通信回線に係るものであり、マルチポイント通信回線の設定や変更、削除に係るものではない。そのために、顧客や通信機器、アプリケーション等がマルチポイントに通信回線を設定や変更、削除する要求を作成する場合には、ポイントｔｏポイントの通信回線の要求を複数用意する必要がある。また、それら複数の要求をグループ化して管理するためには、別のシステムを別途設けるか、或いは顧客や通信機器、アプリケーションといったユーザ側でグループ化して管理する必要がある。
【０００５】
さらに、上記従来技術では、ユーザが利用するアプリケーションに応じて動的に既存の通信サービスを選択することはできない。その為に予め広帯域のネットワークを購入するとコスト高になり、狭帯域のネットワークを購入するとその容量を越えるアプリケーションを利用できないといった問題が生じる。また、既存の通信サービスでは、サービス毎にマネジメントシステムが存在するため、通信サービス提供者に人件費やシステム開発等に係る負担がかかる。更に、ユーザが異なる通信サービス提供者を越えて通信サービスを利用することは、マネジメントシステムが異なる通信サービス提供者間で異なるため、困難である。
【０００６】
一方、従来技術に係るＸＭＬを用いた通信回線提供システムは、異なる通信サービスや異なる通信サービス提供者を越えて通信回線を提供するまでには至っていない。更に、異なる通信サービスや異なる通信サービス提供者を越える際に必要な一つのＸＭＬ文書を複数のＸＭＬ文書に分割し、それらを異なるマネジメントシステムのフォーマットに変換し、異なるマネジメントシステムからのリプライを受け付け、それらのリプライをマージする、システムは存在しない。
【０００７】
本発明は、このような問題に鑑みてなされたものであり、その目的とするところは、ユーザが通信サービスや通信サービス提供者、更にはアプリケーションに応じた通信サービスを意識することなく利用可能とすべく、異なる通信制御装置を統括して管理するサービスマネジメントシステム及びサービスマネジメント方法を提供することにある。
【０００８】
【課題を解決するための手段】
上記目的を達成するために、本発明の第１の態様に係るサービスマネジメントシステムは、クライアント端末からのＸＭＬによるサービス要求を通信手段にて受信し、当該サービス要求を、記憶手段に記憶されたプロバイダポリシ及びコントラクトポリシに基づいて、複数の分割サービス要求に分割し、当該分割サービス要求を通信手段を介して各ネットワークマネジメントシステムに送信し、各ネットワークマネジメントシステムからの応答を合併することで上記サービス要求に対する応答を作成し、当該応答を通信手段を介して上記クライアント端末に送信するように制御する制御手段を有することを特徴とする。
【０００９】
本発明の第２の態様に係るサービスマネジメントシステムは、少なくとも通信利用者のクライアント端末、通信事業者のネットワークマネジメントシステムとの間で通信を行うものであり、上記クライアント端末からのＸＭＬによるサービス要求を受信する通信手段と、上記通信事業者が予め登録したプロバイダポリシ、及び上記通信利用者が予め登録したコントラクトポリシを蓄積する記憶手段と、上記プロバイダポリシ、コントラクトポリシに基づいて、上記サービス要求を関連する複数の分割サービス要求に分割し、それらを上記通信手段を介して各ネットワークマネジメントシステムに送信し、各ネットワークマネジメントシステムからの応答を合併することで上記サービス要求に対する応答を作成し、当該応答を上記通信手段を介して上記クライアント端末に送信するように制御する制御手段と、を具備することを特徴とする。
【００１０】
この第２の態様において、上記プロバイダポリシには、プロバイダＩＤ、ネットワークタイプ、ネットワークプロトコル、アクセスポイント、Ｑｏｓ、セキュリティポリシ、請求情報が少なくとも含まれており、上記コントラクトポリシには、コントラクトＩＤ、ユーザＩＤ、ネットワークタイプ、ネットワークプロトコル、アクセスポイント、セキュリティポリシ、支払情報が少なくとも含まれている、ことを更なる特徴としてもよい。そして、この第２の態様において、上記ＸＭＬによるサービス要求に添付された電子署名に基づいて当該サービス要求の内容に関して正当性を検証することを更なる特徴としてもよい。
【００１１】
この第２の態様において、上記ＸＭＬによるサービス要求に添付された通信利用者のバイオメトリクスデータに基づいて、当該通信利用者を一意に特定することを更なる特徴としてもよい。そして、この第２の態様において、上記ＸＭＬによるサービス要求の少なくとも一部は共通鍵暗号方式又は公開鍵暗号方式のいずれかを用いて暗号化されており、当該サービス要求の機密性が保持されていることを更なる特徴としてもよい。更に、この第２の態様において、上記通信事業者のネットワークマネジメントシステムは異なる通信サービスを管理するためのものであり、当該通信サービスには専用線、波長ＶＰＮ、ＭＰＬＳ−ｂａｓｅｄ  ＶＰＮ、Ｌ２ＴＰ／ＩＰｓｅｃ−ｂａｓｅｄ  ＶＰＮ、ＩＰｓｅｃ−ｂａｓｅｄ  ＶＰＮの少なくともいずれかに係るサービスが含まれることを更なる特徴としてもよい。
【００１２】
本発明の第３の態様に係るサービスマネジメントシステムは、複数の通信利用者のクライアント端末間での通信を制御するサービスマネジメントシステムにおいて、上記送信元のクライアント端末からのＸＭＬによるサービス要求を受信し、当該サービス要求に基づいて送信先のクライアント端末に関わる他のゲートウェイ装置を探索し、当該サービス要求に基づいてオンデマンド接続ネットワークを利用するのか或いは常時接続ネットワークを利用するのかを判断するためのマネジャ部と、オンデマンド接続ネットワークを利用する場合にＸＢＳで制御されるＧＭＰＬＳノードと、常時接続ネットワークを利用する場合に通信制御を行うルータと、を含むゲートウェイ装置、を有することを特徴とする。
【００１３】
上記第１乃至第３の態様において、上記サービス要求には、ソースノードＩＤ、デスティネーションノードＩＤ、アプリケーションタイプ、利用ネットワークタイプ、ユーザ情報、ＱｏＳ、セキュリティオプション、スケジュール情報、時刻証明書、電子証明書の少なくともいずれかを含むことを更なる特徴としてもよい。また、上記第２及び第３の態様において、上記ＸＭＬによるサービス要求に含まれる時刻証明書に基づいて当該サービス要求の内容に関して正当性を検証することを更に特徴としてもよい。
【００１４】
本発明の第４の態様に係るサービスマネジメント方法は、通信利用者のクライアント端末、通信事業者のネットワークマネジメントシステムとネットワークを介して通信自在に構成されたサービスマネジメントシステムによるサービスマネジメント方法において、上記クライアント端末からのＸＭＬによるサービス要求を受け、上記通信事業者が予め登録するプロバイダポリシ、及び上記通信利用者が予め登録するコントラクトポリシに基づいて、当該サービス要求を関連する複数の分割サービス要求に分割し、それらを各ネットワークマネジメントシステムに送信し、各ネットワークマネジメントシステムからの応答を合併することで上記サービス要求に対する応答を作成し、当該応答を上記クライアント端末に送信する、ことを特徴とする。
【００１５】
【発明の実施の形態】
以下、図面を参照して、本発明の実施形態について説明する。
【００１６】
（第１の実施の形態）
先ず、本発明の第１の実施の形態に係るサービスマネジメントシステムの特徴を説明する。この発明の第１の実施の形態は、通信利用者が通信サービスや通信事業者を意識することなく、更にはアプリケーションに応じた通信サービスを意識せずに利用できるサービスマネジメントシステムに関する。つまり、本実施形態に係るサービスマネジメントシステムは、異なる通信サービスや異なる通信事業者を越えて、既存のマネジメントシステムを統括管理する。また、第１の実施の形態に係るサービスマネジメントシステムは、通信利用者からの要求をＸＭＬデータで受け付けることを可能とし、併せて暗号化技術やバイオメトリクス技術を用いてセキュリティの向上を図ることを可能とし、各種データベースの自動連携を図りつつ、サービス提供の迅速化と同時にセキュリティの確保を図るものである。また、一つのＸＭＬによるサービス要求を、利用する各通信サービス及び各通信事業者のマネジメントシステムヘの要求に分割し、それらのマネジメントシステムに適応した要求にフォーマットを変更し、個別に要求結果を受け付け、回線の提供が可能かどうかを判断し、異なる通信サービス、異なる通信事業者を越えて迅速且つセキュアに通信サービスを提供するものである。
【００１７】
ここで、今日では、専用線、波長ＶＰＮ、ＭＰＬＳ−ｂａｓｅｄ  ＶＰＮ、Ｌ２ＴＰ／ＩＰｓｅｃ−ｂａｓｅｄ  ＶＰＮ（Ｗｉｄｅ  Ｅｔｈｅｒｎｅｔ）、ＩＰｓｅｃ−ｂａｓｅｄ  ＶＰＮ等が個別にサービスに供されており、例えば波長ＶＰＮによれば、今までにない広帯域なネットワークをダイナミックにユーザに提供することができる。しかしながら、通信利用者にとってはそのような広帯域なネットワークが常に必要である訳ではない。そこで、現在のＶＰＮサービスと補完し合うサービスの実現が嘱望されているが、本実施形態に係るサービスマネジメントシステムによれば、まさに通信利用者のネットワーク需要若しくはアプリケーションに応じた快適なネットワーク利用が実現される。
【００１８】
尚、第１の実施の形態では、通信回線を使用する顧客、通信機器、アプリケーションからの通信回線の設定、変更、削除に係るサービス要求をＸＭＬデータで受け付けているが、ＸＭＬは、そのＸＭＬ文書から、特定データのみを抽出し、指定した順序で並べ替える等といった処理を容易に行うことができる、つまり再利用や加工が自由にできるデータとして扱うことができるメリットがある。
【００１９】
以下、このような特徴点をふまえて、第１の実施の形態について詳述する。
【００２０】
図１には、本発明の第１の実施の形態に係るサービスマネジメントシステム及びその周辺の概念図を示し、その構成及び作用を詳細に説明する。
【００２１】
この図１に示されるように、サービスマネジメントシステムに関する環境はマネジメントレイヤ１とネットワークレイヤ２に大別される。
【００２２】
先ず、マネジメントレイヤ１には、サービスマネジメントシステム（ＧＳＭＳ；Ｇｅｎｅｒａｌｉｚｅｄ  Ｓｅｒｖｉｃｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）３と、異なる通信サービス、異なる通信事業者のマネジメントシステムである複数のＮＭＳ４ａ，４ｂ，４ｃ・・・とが存在している。マネジメントレイヤ１のＧＳＭＳ３は、各ＮＭＳ４ａ，４ｂ，４ｃ・・・と既存のネットワーク８を介して通信自在となっている。
【００２３】
一方、ネットワークレイヤ２には、上記各ＭＮＳ４ａ，４ｂ，４ｃ・・・と対をなす複数のネットワーク５ａ，５ｂ，５ｃ・・・と、クライアント端末７ａ，７ｂ・・・と通信自在に接続されたクライアントゲートウェイ６ａ，６ｂ・・・とが存在している。クライアント端末７ａ，７ｂ・・・は、クライアントゲートウェイ６ａ，６ｂ・・・を介してマネジメントレイヤ１内のＧＳＭＳ３と通信自在となっている。クライアントゲートウェイ６ａ，６ｂ・・・は、クライアント宅内もしくは通信サービス提供者のネットワーク内に設置される。複数のネットワーク５ａ，５ｂ，５ｃ・・・は、それぞれネットワークプロトコル、或いはネットワーク事業者が異なる。
【００２４】
以下、ＮＭＳ４ａ，４ｂ，４ｃ・・・、ネットワーク５ａ，５ｂ，５ｃ・・・、クライアントゲートウェイ６ａ，６ｂ，６ｃ・・・、クライアント端末７ａ，７ｂ・・・を総称する場合には、それぞれ符号４，５，６，７を用いることにする。
【００２５】
尚、サービススペックとしてのプロバイダポリシには、プロバイダＩＤ、ネットワークタイプ（ワイヤレス、ケーブル、光ファイバ等）、ネットワークプロトコル（ＩＰｖ４、ＩＰｖ６、Ｌ２等）、アクセスポイント、Ｑｏｓ、セキュリティポリシ、証明情報等が含まれている。ユーザのコントラクトポリシには、コントラクトＩＤ、ユーザＩＤ、ネットワークタイプ、ネットワークプロトコル、アクセスポイント、セキュリティポリシ、支払情報等が含まれている。これらプロバイダポリシ、コントラクトポリシは、ＧＳＭＳ側に予め登録される。
【００２６】
ＧＳＭＳ３は、通信、認証、サービス要求分割、サービス要求フォーマット変換、サービス要求番号マネジメント、ＮＷシグナリング設定要求作成、ＮＷシグナリング設定要求番号マネジメント、サービス要求応答作成、電子署名作成の各機能を有している。但し、有する機能はこれらに限定されない。
【００２７】
クライアントＧＷ６からＧＳＭＳ３へのサービス要求は、ＸＢＳ（ＸＭＬ  Ｂａｓｅｄ  Ｓｉｇｎａｌｉｎｇ）により行われるが、このＸＢＳとはＸＭＬデータ形式の通信サービス要求／応答（シグナリング）に関するメッセージフォーマット、メッセージシーケンスを定義したものである。このＸＢＳによれば、ＰＫＩ導入等によるＧＭＰＬＳシグナリングのセキュリティ強化、ＸＭＬによるＯＳＳとの直接的連携、通信機器やアプリケーションの容易な連携・統合が実現される。
【００２８】
なお、第１の実施の形態では、上記ＸＭＬによるサービス要求に添付された電子署名に基づいて当該サービス要求の内容に関して正当性を検証することもできる。更に、第１の実施の形態では、上記ＸＭＬによるサービス要求に添付された通信利用者のバイオメトリクスデータに基づいて、より確実に、当該通信利用者を一意に特定することもできる。また、第１の実施の形態では、上記ＸＭＬによるサービス要求の少なくとも一部を共通鍵暗号方式又は公開鍵暗号方式のいずれかを用いて暗号化し、当該サービス要求の機密性を保持することもできる。
【００２９】
次に、図２には、先に図１に示した本発明の第１の実施の形態に係るＧＳＭＳ３を更に具現化した構成を示し詳細に説明する。
【００３０】
この図２に示されるように、第１の実施の形態に係るＧＳＭＳ３は、コミュニケーションレイヤ１１，１９、電子認証レイヤ１２、ＸＢＳハンドラ１３、ポリシハンドラ１４、ログストア部１５、ポリシストア部１６、ＸＢＳワーク部１７、電子署名レイヤ１８からなる。ＸＢＳワーク部１７は、各ＮＭＳ４ａ，４ｂ，４ｃ・・・に対応して、複数のＸＢＳワーク部１７ａ，１７ｂ，１７ｃ・・・に論理的に分割される。コミュニケーションレイヤ１１，１９は、例えばソケット、セキュアソケット、ＨＴＴＰ、ＲＭＩ、ＣＯＲＢＡ、ＳＯＡＰ等といった様々なコミュニケーションプロトコルをサポートしている。尚、請求項記載の通信手段とは上記コミュニケーションレイヤ１１，１９等に相当し、記憶手段とは上記ポリシストア部１６等に相当し、制御手段とは上記ＸＢＳワーク部１７等に相当するが、これらには限定されないことは勿論である。
【００３１】
このような構成において、ＸＢＳのサービス要求は、コミュニケーションレイヤ１１を介して電子認証レイヤ１２に送られる。電子認証レイヤ１２では、サービス要求に含まれるＸＭＬインスタンス、公開鍵に係る電子証明書、ＸＭＬ署名の有効性が確認される。各レイヤは、サービス要求をセキュアに実行、或いは通信するためのものである。ＸＢＳはサービス要求なので、複数に分割する。分割された要求を各ＮＭＳ４に対して送り、レスポンスを受ける必要があるので、ＸＢＳワーク部１７といったコンポーネントがダイナミックに生成される必要がある。ＸＢＳワーク部１７ａ，１７ｂ，１７ｃ・・・はＮＭＳ４ａ，４ｂ，４ｃ・・・に分割サービス要求を送り、そのレスポンスを受け、マージし、クライアントのサービス要求に対するレスポンスを作成し、それをクライアントに返す。
【００３２】
ポリシハンドラ１４は、ポリシストア部１６をハンドルするための種々のメソッドを有している。コントラクトポリシ、プロバイダポリシは、ポリシハンドラ１４にハンドルされ、ポリシストア部１６にストアされている。ＸＢＳハンドラ１３は、ポリシストア部１６にあるコントラクトポリシ、プロバイダポリシを参照し、両者の整合性をとった上でサービス要求を分割する。ポリシストア部１６との関係で、両ハンドラ１３，１４は接続されている。
【００３３】
次に、図３のフローチャートを参照して、本発明の第１の実施の形態に係るＧＳＭＳ３等による一連の処理を詳細に説明する。
【００３４】
ＧＳＭＳ３は、クライアントＧＷ６からのサービス要求をコミュニケーションレイヤ１１にて受け付けると（ステップＳ１）、先ず当該サービス要求に含まれている電子署名の検証を電子署名レイヤ１２にて行う（ステップＳ２）。
【００３５】
このステップＳ２で、電子署名が正しいものでない場合には所定のエラー処理を行う（ステップＳ３）。一方、電子署名が正しいものである場合には、アクセス権限の確認をポリシストア部１６のコントラクトポリシに基づいて行う（ステップＳ４）。このステップＳ４で、アクセス権限がないものと判断された場合には所定のエラー処理を行うことになる（ステップＳ５）。
【００３６】
続いて、ＧＳＭＳ３は、プロバイダポリシを見比べて実際にサービス要求を分割し（ステップＳ６）、ＸＢＳワーク部１７が分割サービス要求をネットワーク８を介してＮＭＳ４に送信する（ステップＳ７）。そして、ＧＳＭＳ３は、分割サービス要求に関するＮＭＳ４からの応答を待って、当該応答が確認されない場合には所定のエラー処理を行い、一方、全ての応答を取得した場合にはステップＳ１２に進むことになる（ステップＳ８乃至Ｓ１１）。
【００３７】
次いで、ＧＳＭＳ３は、ＮＷシグナリング設定要求を作成し、当該要求をＮＭＳ４に向けて送信する（ステップＳ１２）。次いで、ＧＳＭＳ３は、ＮＭＳ４からのＮＷシグナリング設定要求に関する応答を待って、応答が確認されない場合には所定のエラー処理を行い、一方、全ての応答を取得した場合にはステップＳ１７に進むことになる（ステップＳ１３乃至Ｓ１６）。次いで、ＧＳＭＳ３は、複数のＮＭＳからの応答をマージしてサービス要求応答を作成して（ステップＳ１７）、電子署名を添付し（ステップＳ１８）、当該電子署名が添付されたサービス要求応答をクライアントＧＷ６に送信する（ステップＳ１９）。
【００３８】
以下、図４のフローチャートを参照して、本発明の第１の実施の形態に係るＧＳＭＳ３及びその周辺機器による通信サービス開始までの一連の処理を説明する。尚、ここでは、クライアント端末７ａとクライアント端末７ｂは互いのアプリケーションを認知していることを前提としている。
【００３９】
クライアント端末７ａがサービス要求を作成し、クライアントＧＷ６ａに送信すると（＃１）、クライアントＧＷ６ａはＧＳＭＳ３にサービス要求を送信する（＃２）。ＧＳＭＳ３は、サービス要求の内容を検証後、当該サービス要求を分割して、分割サービス要求をＮＭＳ４ａ，４ｂ・・・に送信する（＃３，＃４）。
【００４０】
ＮＭＳ４ａ，４ｂは、分割サービス要求を検証し、設定可能かどうかを応答する（＃５，＃６）。この応答を受けると、ＧＳＭＳ３は、ＮＷシグナリング設定要求をＮＭＳ４ａ，４ｂに送信する（＃７，＃８）。続いて、ＮＭＳ４ａは、クライアントＧＷ６ａに対してシグナリング起動要求を送信する（＃９）。
【００４１】
このシグナリング起動要求を受けると、クライアントＧＷ６ａは、ＮＭＳ４ａ間でシグナリングを行う（＃１０）。ＮＭＳ４ａは、ＮＭＳ４ｂ間でシグナリングを行う（＃１１）。これに続いて、ＮＭＳ４ｂは、クライアントＧＷ６ｂ間でシグナリングを行う（＃１２）。クライアントＧＷ６ｂは、クライアントＧＷ６ａ間でシグナリングを行う（＃１３）。クライアントＧＷ６ａは、回線設定ＯＫというサービス要求応答をクライアント端末７ａに送信する（＃１４）。クライアントＧＷ６ａは、ＧＳＭＳ３に対して回線完了通知を送信する（＃１５）。こうして、クライアント端末７ａ，７ｂ間で通信が開始される（＃１６）。
【００４２】
最後に、図５（ａ），（ｂ）を参照して、上述した第１の実施の形態に係るＧＳＭＳ３の応用に係るサービスの一例について説明する。
【００４３】
先ず、各拠点間で既存のＶＰＮサービスを利用している場合、拠点Ａ乃至Ｄは大容量のトラフィックを発生していない（図５（ａ）参照）。
【００４４】
次に、拠点Ａ，Ｃ，Ｄで、例えば高解像度のテレビ会議を行う場合を想定すると、当該テレビ会議に係るアプリケーションのトラフィックは、既存のＶＰＮでは収まらない。そこで、クライアントＧＷ２０ａ，２０ｃ，２０ｄがそれを認知し、新たに波長ＶＰＮを拠点Ａ、Ｃ、Ｄ間に設定する。テレビ会議に係るアプリケーション終了後においては、自動的に波長ＶＰＮは廃棄され、既存のＶＰＮのみを利用した状態に戻ることになる（図５（ｂ）参照）。
このように、第１の実施の形態では、一つのＸＭＬによるサービス要求を、通信事業者が予めサービスマネジメントシステムに提供するプロバイダポリシ、及び通信利用者が予めサービスマネジメントシステムに提供するコントラクトポリシに基づき、関連する複数の分割サービス要求に分割し、それらを各通信事業者に送信し、そのレスポンスをマージすることで、クライアントからのサービス要求に対する応答を作成し、クライアントに送信する。
【００４５】
以上説明したように、本発明の第１の実施の形態によれば、通信回線提供者が、顧客や通信機器、アプリケーションからの通信回線の設定、変更、削除に係る要求から実際の回線操作完了までの時間を短縮することができる。特に、第１の実施の形態によれば、顧客や通信機器、アプリケーションは、マルチポイント通信回線の要求といった柔軟なサービス要求を作成することができる。さらに、通信回線提供者側で、通信プロトコルや通信事業者を超えてサービスマネジメントシステムを提供するため、ユーザ側では一元的なサービスとして利用することができる。さらには、通信機器やアプリケーションが動的に通信回線要求を発行することで、必要なときに必要なだけの通信帯域を確保することができる。
【００４６】
（第２の実施の形態）
前述した第１の実施の形態では、ＧＳＭＳとクライアントＧＷとを独立させていたが、第２の実施の形態では、当該構成を簡略化し、クライアントＧＷにＧＳＭＳの一部の機能をもたせている。ここで、一部とは、サービス要求を分割する機能は含まれず、サービス要求をＸＢＳ側のサービス要求に変更する機能が含まれる。さらに、第１の実施の形態では、ＸＢＳリクエストと称していたが、第２の実施の形態では、一のクライアント端末から他のクライアント端末へ送信されるものをＸＢＣＳリクエストとし、オンデマンド接続ネットワークが必要なときにはＸＢＳリクエストを作成し、ＸＢＳのネットワークマネージャに送るように構成されている。以下、第２の実施の形態について詳述する。
【００４７】
先ず、図６には、本発明の第２の実施の形態に係るサービスマネジメントシステム及びその周辺の概念図を示し、その構成及び作用を詳細に説明する。
【００４８】
この図６において、マネジメントレイヤ３１には、不図示のＮＭＳ等が存在している。一方、ネットワークレイヤ３２には、複数のネットワーク３７ａ，３７ｂ，３７ｃ・・・と、クライアント端末３６ａ，３６ｂ・・・と通信自在に接続されたソースＸＢＣＳ  ＧＷ３４、デスティネーションＸＢＣＳ  ＧＷ３５とが存在している。複数のネットワーク３７ａ，３７ｂ，３７ｃ・・・は、それぞれネットワークプロトコル、或いはネットワーク事業者が異なるものである。
【００４９】
この第２の実施の形態に係るサービスマネジメントシステムでは、ユーザニーズやユーザアプリケーションに応じて適切なネットワークを選択、提供可能とすべく、ＸＢＣＳ（ＸＭＬ−ｂａｓｅｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ）を採用する。
【００５０】
このＸＢＣＳとは、ＸＢＳがマネジメント可能なサービス（ＧＭＰＬＳベースのネットワークサービス）に、インターネット等を利用した常時接続ネットワークサービスを追加拡張したものである。このＸＢＣＳにおいて、異なるネットワークサービスとは、オンデマンド接続ネットワークサービス、及び常時接続ネットワークサービスに大別される。前者のオンデマンド接続ネットワークサービスはＸＢＳにより提供されるサービスであり、後者の常時接続ネットワークサービスはインターネットに代表されるパブリックなネットワークやＩＰ−ＶＡＮに代表されるセキュアなネットワークである。即ち、第２の実施の形態では、ＸＢＣＳユーザは、ＸＢＳベースのネットワークサービス、及びインターネットベースのネットワークサービスに常にアクセス可能であることを前提としている。
【００５１】
ところで、オンデマンド接続ネットワークサービスと常時接続ネットワークサービスの違いは、帯域保証とコストにある。通常、帯域保証とコストには、トレードオフの関係がある。また、ユーザのアプリケーションは、リアルタイムストリーミング系のアプリケーションや大容量ストレージのミラーリング等の特定アプリケーション用途以外は、特に低遅延且つ広帯域を保証する必要がある訳ではない。その為、ユーザにとっては、常時接続には安価なネットワークを様々なアプリケーションで共有し、必要に応じて必要なだけのネットワーク帯域をオンデマンドに確保することが、ネットワークの効率利用の観点からもコスト的にも好ましい。この点、第２の実施の形態が採用したＸＢＣＳによれば、このような要求を満たすサービスマネジメントシステムを実現することが可能となる。
【００５２】
上記ＸＢＣＳ  ＧＷ３４，３５の詳細な構成は、図７，８に示される。
【００５３】
すなわち、この図７，８はＸＢＣＳを用いたサービスイメージを示したものであり、図７に示される状態では、各拠点間は常時接続されている。この常時接続は、通常のインターネットアクセスサービスやＩＰｓｅｃ−ｂａｓｅｄ  ＶＰＮサービス等で実現されているものとする。次いで、常時接続ネットワークでは許容できない大容量ネットワークが必要なアプリケーションが各拠点で起動されると、図８に示されるように、各ＧＷ３４，３５がそれに応じてオンデマンドネットワーク上に新たなパスを設定する。尚、これについては後に詳述する。
【００５４】
これら図７，８に示されるように、各ＸＢＣＳ  ＧＷ３４，３５は、ＸＢＣＳマネージャ３４ａ，３５ａ、ＧＭＰＬＳノード３４ｂ，３５ｂ、ＩＰルータ３４ｃ，３５ｃからなる。尚、請求項記載のマネジャ部、ルータ、ノードとは、例えばＸＢＣＳマネージャ３４ａ，３５ａ、ＩＰルータ３４ｃ，３５ｃ、ＧＭＰＬＳノード３４ｂ、３５ｂ等に相当するが、これに限定されない。
【００５５】
このような構成のＸＢＣＳ  ＧＷ３４，３５では、ユーザのニーズもしくはユーザが利用するアプリケーションに応じて接続ネットワークを選択する。その為にユーザのニーズもしくはアプリケーションからどのようなサービスレベルが要求されるかを理解し、適切なネットワークに振り分ける機能が必要になる。
【００５６】
このような機能を実現する為に、この例では、ユーザもしくはアプリケーションが事前にＸＢＣＳリクエストをＸＢＣＳ  ＧＷ３４，３５に送信するプロセス、及びＴＣＰもしくはＵＤＰパケットをフォワードするプロセスを採用する。
【００５７】
ここで、ＸＢＣＳリクエストは、少なくとも、ソースノードＩＤ、デスティネーションノードＩＤ、アプリケーションタイプ、利用ネットワークタイプ、ユーザ情報、ＱｏＳ、セキュリティオプション、スケジュール情報、時刻証明書、電子署名のいずれかを含み、ユーザ、アプリケーションにより作成される。
【００５８】
詳細には、ソースノードＩＤとは、データを送受信するノード（クライアント端末３６ａ，３６ｂ）のうち、サービス要求を送信する側のノード（クライアント端末３６ａ）を特定するものである。デスティネーションノードＩＤとは、データを送受信するノード（クライアント端末３６ａ，３６ｂ）のうち、サービス要求がフォワードされてくる側のノード（クライアント端末３６ｂ）を特定するものである。アプリケーションタイプとは、アプリケーションの種別を記述する項目である。この例では、ＭＩＭＥＴＹＰＥのようなものを想定している。このアプリケーションタイプに応じて利用ネットワークを決定してもよい。
【００５９】
そして、利用ネットワークタイプは、利用ネットワークを記述する為の項目であり、オンデマンドか常時接続かのいずれかが記述される。ユーザ情報とは、ユーザに係る各種の情報をいう。ＱｏＳとは、ネットワーク帯域、許容遅延、許容パケット損失率など含むものである。そして、セキュリティオプションとは、セキュリティを高めるために用いるものであり、最低でもＩＰｓｅｃを利用するかどうかを記述する項目を含んでいる。なお、アクセスコントロールについても、このセキュリティオプションを用いて行うことが可能である。
【００６０】
このような内容のＸＢＣＳリクエストも、前述したＸＢＳと同様に、セキュリティ技術との親和性等の理由からＸＭＬを用いて記述されており、そのメッセージフォーマットについてはＸＭＬスキーマで定義されている。
【００６１】
以上説明したような構成において、ＸＢＣＳマネージャ３４ａは、クライアント端末３６ａからのＸＢＣＳリクエストを受け、当該ＸＢＣＳリクエストに応じて適切なネットワークを選択し、必要とあればＸＢＳのコネクション・クリエイト・リクエスト（Ｃｏｎｎｅｃｔｉｏｎ  Ｃｒｅａｔｅ  Ｒｅｑｕｅｓｔ）メッセージを作成し、ＧＭＰＬＳパスを設定する。このＧＭＰＬＳパスをアプリケーションが使う為に、ＸＢＣＳ  ＧＷ３４，３５には、ソースノードから送信されたＴＣＰ及びＵＤＰパケットをデスティネーションノード側に存在するデスティネーションＸＢＣＳ  ＧＷ３５にフォワードする機能、及びデスティネーションＸＢＣＳ  ＧＷ３４から送信されたＴＣＰ及びＵＤＰパケットをデスティネーションノードにフォワードする機能が必要となる。この機能をＸＢＣＳではリフレクタ（ｒｅｆｌｅｃｔｏｒ）と称し、ＴＣＰ及びＵＤＰパケットをＸＢＣＳ  ＧＷ３４，３５間でマネジメントするものと定義する。そして、この実施の形態では、上記リフレクタは、ＧＭＰＬＳノード３４ｂ，３５ｂ上に起動される（符号３４ｄ，３５ｄ）。
【００６２】
このように、各ＸＢＣＳ  ＧＷ３４，３５では、リフレクタを直接制御することで、ルーチング制御を行っている。すなわち、リフレクタは、ＴＣＰパケットもしくはＵＤＰパケットのデスティネーションアドレスをＸＢＣＳマネージャ３４ａ，３５ａからの要求に応じて変更している。尚、この他の手法として、ＩＰトンネリング技術を用いることも可能であることは勿論である。
【００６３】
以下、図９のフローチャートを参照して、本発明の第２の実施の形態に係るサービスマネジメントシステムの動作を詳細に説明する。
【００６４】
ここでは、クライアント端末３６ａがクライアント端末３６ｂとの間でオンデマンドネットワーク、若しくは常時接続ネットワークを利用してセキュアな通信を行う場合を想定して説明を進めることにする。
【００６５】
クライアント端末３６ａからのＸＢＣＳリクエストを受信したソースＸＢＣＳＧＷ３４のＸＢＣＳマネージャ３４ａは、電子署名やＸＭＬスキーマによる定義に基づいて当該ＸＢＣＳリクエストを検証する（ステップＳ２１）。
【００６６】
次いで、ソースＸＢＣＳ  ＧＷ３４は、クライアント端末３６ｂに係わるデスティネーションＸＢＣＳ  ＧＷ３５（ＸＢＣＳマネージャ３５ａ）を探索する（ステップＳ２２）。この例では、ＩＳＯ標準であるＸ．５００を簡略化したディレクトリ・アクセスのためのプロトコルであるＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｆｔ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）等といったディレクトリサービスを利用して、ＸＢＣＳリクエストに含まれるデスティネーションノードＩＤに基づいてデスティネーションＸＢＣＳ  ＧＷ３５（ＸＢＣＳマネージャ３５ａ）を探索し、ＸＢＣＳリクエストをデスティネーションＸＢＣＳ  ＧＷ３５にフォワードする（ステップＳ２３）。
【００６７】
その後、ソースＸＢＣＳ  ＧＷ３４のＸＢＣＳマネージャ３４ａは、オンデマンド接続ネットワークを利用するのか、或いは常時接続ネットワークを利用するのかを、ＸＢＣＳリクエストに含まれるアプリケーションタイプ及び利用ネットワークタイプに基づいて判断する（ステップＳ２４）。
【００６８】
前者（オンデマンド接続ネットワーク利用）である場合はＸＢＳパス作成リクエストを作成し、デスティネーションＸＢＣＳ  ＧＷ３５に送信し（ステップＳ２５）、ローカルのＧＭＰＬＳノード３４ｂにてリフレクタを起動する（ステップＳ２６）。一方、後者（常時接続ネットワーク利用）である場合は、セキュリティオプションの有無に応じてＩＰルータ３４ｃを制御して、例えばＩＰｓｅｃ等のトンネリングを張る（ステップＳ２７，Ｓ２８）。そして、いずれの場合も、デスティネーションＸＢＣＳ  ＧＷ３５（ＸＢＣＳマネージャ３５ａ）に当該ＸＢＣＳリクエストをフォワードし、その結果をユーザに返す（ステップＳ２９）。
【００６９】
一方、デスティネーションＸＢＣＳ  ＧＷ３５側では、ＸＢＣＳリクエストを受信すると、ＸＢＣＳマネージャ３５ａにて当該ＸＢＣＳリクエストを検証する（ステップＳ３０）。次いで、デスティネーションＸＢＣＳ  ＧＷ３５のＸＢＣＳマネージャ３５ａは、オンデマンド接続ネットワークを利用するのか、常時接続ネットワークを利用するのかをＸＢＣＳリクエストに含まれるアプリケーションタイプ及び利用ネットワークタイプから判断する（ステップＳ３１）。
【００７０】
前者（オンデマンド接続ネットワーク利用）である場合、デスティネーションＸＢＣＳ  ＧＷ３５では、ＧＭＰＬＳノード３５ｂにてリフレクタを起動する（ステップＳ３２）。後者（常時接続ネットワーク利用）である場合は、デスティネーションＸＢＣＳ  ＧＷ３５は、セキュリティオプションの有無に応じてＩＰルータ３５ｃを制御する（ステップＳ３３，Ｓ３４）。いずれの場合も、デスティネーションＸＢＣＳ  ＧＷ３５は、ソースＸＢＣＳ  ＧＷ３４（ＸＢＣＳマネージャ３４ａ）にレスポンスを送信する（ステップＳ３５）。こうして、クライアント端末３６ａと３６ｂとの間での通信が可能となる。
【００７１】
この第２の実施の形態においても、上記ＸＭＬによるサービス要求に添付された電子署名に基づいて当該サービス要求の内容に関して正当性を検証することもできる。更に、上記ＸＭＬによるサービス要求に添付された通信利用者のバイオメトリクスデータに基づいて、より確実に、当該通信利用者を一意に特定することもできる。また、上記ＸＭＬによるサービス要求の少なくとも一部を共通鍵暗号方式又は公開鍵暗号方式のいずれかを用いて暗号化し、当該サービス要求の機密性を保持することもできる。
【００７２】
以上説明したように、本発明の第２の実施の形態によれば、通信回線提供者が顧客や通信機器、アプリケーションからの通信回線の設定、変更、削除に係る要求から実際の回線操作完了までの時間を短縮することができる。特に、顧客や通信機器、アプリケーションは、マルチポイント通信回線の要求といった柔軟なサービス要求を作成することができる。さらに、通信回線提供者側で、通信プロトコルや通信事業者を超えてサービスマネジメントシステムを提供するため、ユーザ側では一元的なサービスとして利用することができる。さらには、通信機器やアプリケーションが動的に通信回線要求を発行することで、必要なときに必要なだけの通信帯域を確保することができる。
【００７３】
尚、第１，２の実施の形態においては、上記ＸＭＬによるサービス要求に含まれる時刻証明書に基づいて当該サービス要求の内容に関して正当性を検証することも可能である。
【００７４】
以上、本発明の実施形態について説明したが、本発明はこれに限定されることなく、その主旨を逸脱しない範囲で種々の改良・変更が可能である。
【００７５】
例えば、第２の実施の形態の変形例として、オンデマンド接続ネットワークサービス、及び常時接続ネットワークサービスの振り分けをＩＰルータの機能により行うことも可能である。この場合には、送信側でＩＰルータのルーティングテーブルのマネジメントを行うことが必要となる。
【００７６】
【発明の効果】
以上詳述したように、本発明によれば、ユーザが通信サービスや通信サービス提供者、更にはアプリケーションに応じた通信サービスを意識することなく利用可能とすべく、異なる通信制御装置を統括して管理するサービスマネジメントシステム及びサービスマネジメント方法を提供することができる。
【図面の簡単な説明】
【図１】本発明の第１の実施の形態に係るサービスマネジメントシステム及びその周辺機器の概念図である。
【図２】本発明の第１の実施の形態に係るサービスマネジメントシステム３を更に具現化した構成を示す図である。
【図３】本発明の第１の実施の形態に係るサービスマネジメントシステムによる一例の処理を詳細に示したフローチャートである。
【図４】本発明の第１の実施の形態に係るサービスマネジメントシステム及びその周辺機器による通信サービス開始までの一連の処理を示したフローチャートである。
【図５】（ａ），（ｂ）は本発明の第１の実施の形態に係るサービスマネジメントシステムの応用に係るサービスの一例を説明するための図である。
【図６】本発明の第２の実施の形態に係るサービスマネジメントシステム及びその周辺機器の概念図である。
【図７】本発明の第２の実施の形態に係るサービスマネジメントシステムを更に具現化した構成を示す図である。
【図８】本発明の第２の実施の形態に係るサービスマネジメントシステムを更に具現化した構成を示す図である。
【図９】本発明の第２の実施の形態に係るサービスマネジメントシステムによる一例の処理を詳細に示したフローチャートである。
【符号の説明】
１・・・マネジメントレイヤ、２・・・ネットワークレイヤ、３・・・ＧＳＭＳ、４・・・ＮＭＳ、５・・・ネットワーク、６・・・クライアントＧＷ、７・・・クライアント端末、８・・・ネットワーク
【図１】
2004341566.tif 000003
【図２】
2004341566.tif 000004
【図３】
2004341566.tif 000005
【図４】
2004341566.tif 000006
【図５】
2004341566.tif 000007
【図６】
2004341566.tif 000008
【図７】
2004341566.tif 000009
【図８】
2004341566.tif 000010
【図９】
2004341566.tif 000011