JP5946467B2 - 電気通信ネットワークにおけるサービスのオーケストレーションのための通信サービスブローカー - Google Patents

Description

著作権表示
この特許文献の開示の一部は、著作権保護の対象となる資料を含む。この特許文献または特許開示は特許商標庁の特許ファイルまたは記録に記載されているため、著作権者は、何人によるその複製に対して異議はないが、その他の場合には如何なるときもすべての著作権を保有する。

発明の分野
この発明はモバイル通信に関し、特に、電気通信ネットワークにおけるサービスオーケストレーションの提供に関する。

背景
無線通信および携帯通信における最近の劇的な成長を前提として、より多くの企業および他のエンティティが自らをモバイル機器技術と一体化させつつある。標準の音声機能に加え、現在の携帯電話および同様の機器は、インターネットアクセス、電子メール（ｅメール）、ショートメッセージングサービス（short messaging service：ＳＭＳ）メール作成、デジタルカメラ、マルチメディアメッセージングサービス（multimedia messaging service：ＭＭＳ）、ブルートゥース（登録商標）、ゲーム、さまざまなウェブベースのアプリケーションなどといった数えきれないほどの他のサービスを提供している。その結果、電気通信事業者およびネットワーク運営者は、自らの加入者により多くのサービス製品を提供するよう、より一層のプレッシャーを受けてきた。今日のネットワーク運営者は、既存の顧客を維持しつつ新規顧客を引付け、収益性の高い新規ビジネスモデルを開発し、利益を高め、新規サービスをできるだけ早く投入することを望んでいる。

これらの難題に直面して、たいていの運営者は、自らのコンテンツおよびアプリケーション製品の品揃えにおいて、サービスを劇的に向上させている。多くのそのような新製品は、運営者が、１回のコールにおいて複数の異なるアプリケーション間で調整および仲介し、異なるプロトコルでの通信間で変換し、起こり得る問題または不都合の解決を試みようとすることを必要とする。加えて、複数のタイプのネットワークおよび基礎技術からのサービスを利用するかもしれない多くの新規アプリケーションが出現している。必要なのは、これらの基礎技術およびアプリケーションのすべてを単一のまとまった態様で管理し調整する、改良された方法である。

簡単な概要
単一のコールまたはセッション用の複数のアプリケーションの編集を可能にするサービスのオーケストレーションを行なうサービスブローカーが説明される。特に、サービスブローカーは、サービスブローカーが単一の課金イベントを受信し、その課金イベントに応答した複数の課金サービスの起動間でオーケストレーションを行なうことを可能にする、課金オーケストレーションで拡張される。

この発明のさまざまな実施例に従ったサービスブローカーの図である。 この発明のさまざまな実施例に従った、通信サービスブローカーによって行なわれる課金オーケストレーションの図である。 この発明のさまざまな実施例に従ったオーケストレーションエンジンの図である。 この発明のさまざまな実施例に従った、課金オーケストレーションを行なうためのプロセスのフローチャート図である。 一実施例に従った、電気通信環境において課金オーケストレーションを行なうためのシステムの図である。

詳細な説明
この発明の実施例は、電気通信ネットワーク運営者によって利用可能な通信サービスブローカーのコンテキストにおいて存在する。サービスブローカーは、アプリケーション（サービス論理）間および異なるネットワーク間での仲介と、単一のコールまたはセッション用の複数のアプリケーションの編集を可能にするサービスのオーケストレーションとを行なう。仲介機能はアプリケーションに、異なるネットワークドメインにおけるスイッチングおよびセッションコール制御層へのアクセスを、必要なプロトコルとともに提供する。サービスのオーケストレーションは、異なるタイプのアプリケーションがともに働いて、単一のコールのコンテキストにおいて新しい複合サービス製品を構築することを可能にする。

一実施例によれば、サービスブローカーは、旧来のサービスとＩＰマルチメディアシステム（IP Multimedia System：ＩＭＳ）／ロングタームエボリューション（Long term evolution：ＬＴＥ）サービスとの組合せを含む異なる課金サービス間で、課金イベントのオーケストレーションを行なう能力で拡張される。これにより、サービスブローカーは、電気通信ネットワークから単一の課金イベントを受信し、サービス側での複数の課金サービスの起動のオーケストレーションを行なうことができる。一実施例によれば、課金オーケストレーションは、サービスブローカー内部のオーケストレーションエンジンで行なわれる。課金エンジンは、オーケストレーションエンジンによってローカルにまたはリモートでアクセス可能な拡張マークアップ言語（extensible markup language：ＸＭＬ）文書で記憶された課金論理を含んでいてもよい。一実施例では、オーケストレーションエンジンは、ネットワークから課金イベントを受信し、ＸＭＬファイルとイベントのパラメータとを検査し、この情報を加入者情報と組合せて使用して、オーケストレーションエンジンは、課金イベントに応答してどの課金サービスを呼出すか、オーケストレーションを行なう。

図１は、この発明のさまざまな実施例に従ったサービスブローカーの図である。この図は構成要素を論理的に別個のものとして示しているが、そのような図示は単に例示を目的とするものである。この図および他の図に示す構成要素が組合されてもよく、もしくは別個のソフトウェア、ファームウェア、および／またはハードウェアに分割されてもよいということは、当業者には明らかであろう。また、そのような構成要素は、それらが如何に組合され、または分割されていようと、同じコンピューティング機器上で実行されてもよく、もしくは１つ以上のネットワークまたは他の好適な通信手段によって接続された異なるコンピューティング機器中に分散されてもよいということも、当業者には明らかであろう。

図示されるように、サービスブローカー１００は、ゲートウェイＧＰＲＳサポートノード（Gateway GPRS Support Node：ＧＧＳＮ）１１８、モバイルスイッチングセンター（Mobile Switching Center：ＭＳＣ）１１９、サービススイッチングポイント（Service Switching Point：ＳＳＰ）１２０、コールセッション制御機能（call session control function：ＣＳＣＦ）１２２、およびソフトスイッチ（Soft Switch：ＳＳＷ）１２１といった電気通信ネットワークリソースと、サービス制御ポイント（service control point：ＳＣＰ）１１５、１１６、オンライン課金および格付けシステム１１４、およびアプリケーションサーバ（Application Server：ＡＳ）１１７といったさまざまな他のサービスとの間に位置付け可能である。一実施例によれば、サービスブローカーは、サービスと成長ネットワーク層との間でのサービス相互作用および合成を管理するために使用される。サービスブローカーは、旧来のプラットフォームからのサービスの移行、旧来のネットワークおよびＩＰネットワークをＩＴドメインを用いて融合する新規サービスの立上げ、ならびに複数のネットワークタイプ間でのサービスおよび課金プラットフォームの統合を助ける、オーケストレーションエンジンと１組の相互作用モジュールとを含む。ネットワーク運営者は、旧来のＩＮベースのネットワークから次世代のＩＰベースのネットワークへサービスを橋渡しするように、サービスブローカーを実現することができる。サービスブローカーは、さまざまなネットワークタイプ間でサービスを仲介し、リアルタイムで複数のサービスのオーケストレーションを行なって、融合されたサービスの創出を可能にする。

図示された実施例によれば、サービスブローカーの相互作用モジュール（Interworking Module：ＩＭ）構成要素は、冗長な旧来のサービスプラットフォームを削減するよう、複数のネットワークタイプ間でサービスを活用するための主要なＩＮオーケストレーション機能を提供する。ＩＭ構成要素は、モバイルおよび固定ネットワークプロトコル用の共通の制御モデルを提供して、オーケストレーションエンジン１０１がさまざまなネットワークドメイン間で提供されるサービスを制御することを可能にする。基礎ネットワーク間の違いをサポートするために、ネットワーク特有情報がＩＭ構成要素に封入され、既存の配備されたアプリケーションプラットフォームに中継される。図示された実施例によれば、サービスブローカーは、相互作用モジュールサービス制御機能（Interworking Module Service Control Function：ＩＭ−ＩＣＦ）１０８、１０９、１１０、１１１；相互作用モジュールサービススイッチング機能（Interworking Module Service Switching Function：ＩＭ−ＳＳＦ）１０２、１０３、１０４、１０５；相互作用モジュールオンライン課金機能（Interworking Module Online Charging Function：ＩＭ−ＯＣＦ）１０６；相互作用モジュールアプリケーションサーバ機能（Interworking Module Application Server Function：ＩＭ−ＡＳＦ）１０７；および逆相互作用モジュールアプリケーションサーバ機能（Reverse Interworking Module Application Server Function：Ｒ−ＩＭ−ＡＳＦ）１１２、１１３というＩＭ構成要素を提供する。ＩＮをサポートする相互作用モジュール（ＩＭ−ＳＣＦ、ＩＭ−ＳＳＦ）およびセッション初期化プロトコル（Session Initiation Protocol：ＳＩＰ）をサポートする相互作用モジュール（ＩＭ−ＡＳＦおよびＲ−ＩＭ−ＡＳＦ）の使用を組合せると、サービスブローカーは、ＩＭＳアプリケーションと既存の旧来のネットワークベースのアプリケーションとのオーケストレーションを提供可能である。加えて、サービスブローカー１００は、さまざまなサービスのオーケストレーションを制御するオーケストレーション論理プロセッサ（orchestration logic processor：ＯＬＰ）１２３を含む。

一実施例によれば、サービスブローカーは、専用のＩＭ−ＯＣＦモジュール１０６を通してリアルタイムの集中型課金能力をサポートする。他のＩＭモジュールと併用されると、ＩＭ−ＯＣＦ１０６は、ＩＮベースおよびＩＰベースのネットワーク双方における、ポストペイド、プリペイド、またはハイブリッド課金モデル用の共通のリアルタイム課金を可能にする。

図２は、この発明のさまざまな実施例に従った、通信サービスブローカーによって行なわれる課金オーケストレーションの図である。この図は構成要素を論理的に別個のものとして示しているが、そのような図示は単に例示を目的とするものである。この図および他の図に示す構成要素が組合されてもよく、もしくは別個のソフトウェア、ファームウェア、および／またはハードウェアに分割されてもよいということは、当業者には明らかであろう。また、そのような構成要素は、それらが如何に組合され、または分割されていようと、同じコンピューティング機器上で実行されてもよく、もしくは１つ以上のネットワークまたは他の好適な通信手段によって接続された異なるコンピューティング機器中に分散されてもよいということも、当業者には明らかであろう。

図示されるように、サービスブローカー２００は、課金オーケストレーションを含むサービスのオーケストレーションを担当するオーケストレーションエンジン２０６を含む。一実施例によれば、オーケストレーションエンジンは、ネットワークリソース（たとえば、ＳＳＷ／ＣＳＣＦ２０３）で生じるオーケストレーションイベントを検出可能であり、課金イベントに応答して呼出されるべきいくつかの課金サービス２０１、２０２のオーケストレーションを行なうことが可能である。一例として、課金イベントはＲ−ＩＭ−ＡＳＦ２０７経由で受信可能であり、課金サービスはＩＭ−ＳＳＦ ＩＮＡＰ ＣＳ１ ２０４およびＩＭ−ＳＳＦ ＣＡＰ２０５を通して呼出可能である。この特定の図では、課金サービスは、ＩＮＡＰプロトコルでのプリペイドＳＣＰ、およびＣＡＰプロトコルでのＶＰＮ ＳＣＰとして図示されている。代替的な実施例では、オーケストレーションは、さまざまなプロトコルでのさまざまな他の課金サービス間で行なうことができる。

一実施例によれば、オーケストレーションエンジンは、課金イベントを行なうための拡張マークアップ言語（ＸＭＬ）ベースの規則ファイルで構成される。オーケストレーションエンジンがネットワークからあるイベントを受信すると、それは、課金イベントのパラメータ（発信者、位置、時刻など）を検査し、オーケストレーションを行なうためのＸＭＬ規則を検査し、加入者の情報を検討し、これらすべての情報を用いてどの課金サービスが起動されるべきかを判断することができる。オーケストレーションエンジンは次に、課金イベントに応答したこれらの課金サービスの各々の起動のオーケストレーションを行なうことができる。

課金オーケストレーションについての１つの起こり得る使用事例は、プリペイドコールサービス用のスポンサーコードに関わる場合がある。典型的なプリペイドの筋書きでは、加入者がコールを行なうたびに、加入者の口座からそのコールに対する或る金額が差引かれる。スポンサーコードの筋書きでは、コールが行なわれると、その金額の一部分はある課金サービスを用いて加入者の口座から差引かれ、別の部分は異なる課金サービスを呼出すことによってスポンサーの口座から差引かれ得る。これにより、スポンサー会社は、課金サービスのオーケストレーションを利用することによって、コールベースの広告および他のマーケティングを行なうことができるようになる。代替的な他の実施例では、課金オーケストレーションは他の使用事例および目的に関連して使用可能である。

図３は、この発明のさまざまな実施例に従ったオーケストレーションエンジンの図である。この図は構成要素を論理的に別個のものとして示しているが、そのような図示は単に例示を目的とするものである。この図および他の図に示す構成要素が組合されてもよく、もしくは別個のソフトウェア、ファームウェア、および／またはハードウェアに分割されてもよいということは、当業者には明らかであろう。また、そのような構成要素は、それらが如何に組合され、または分割されていようと、同じコンピューティング機器上で実行されてもよく、もしくは１つ以上のネットワークまたは他の好適な通信手段によって接続された異なるコンピューティング機器中に分散されてもよいということも、当業者には明らかであろう。

図示されるように、オーケストレーションエンジン３００は、セッション毎の複数のサービスの提供を担当する。サービスオーケストレーションを行なうために、オーケストレーションエンジンはオーケストレーション論理を用いる。オーケストレーション論理は、オーケストレーションエンジンがセッションを扱うべきアプリケーションと、これらのアプリケーションを呼出すべき順序とを規定する。一実施例によれば、サービスオーケストレーションは、（１）オーケストレーションプロファイルレシーバ（Orchestration Profile Receiver：ＯＰＲ）３０４、および（２）オーケストレーション論理プロセッサ（ＯＬＰ）３０３という構成要素を用いて行なわれる。

一実施例によれば、セッション制御層によってトリガされると、オーケストレーションエンジン３００は、各コールまたはセッションに対し、以下の手順を行なう：
ａ．オーケストレーションプロファイル選択３０１：オーケストレーションエンジンは、ＯＰＲを用いてオーケストレーションプロファイルを選択し検索する。オーケストレーションプロファイルは、次に使用するＯＬＰのタイプについての情報と、そのタイプのＯＬＰが必要とする特定のパラメータとを含む。オーケストレーションエンジンは、ホーム加入者サーバ（Home Subscriber Server：ＨＳＳ）ＯＰＲ３０７、ローカル加入者サーバ（Local Subscriber Server：ＬＳＳ）ＯＰＲ３０８、またはオーケストレーションエンジンの構成設定で規定されるような任意の他の設置されたＯＰＲを使用できる。これらのＯＰＲは次に、ＨＳＳ３０９またはＬＳＳ３１０への接続を維持できる；
ｂ．アプリケーショントリガリング３０２：オーケストレーションエンジンは、ＯＬＰ構成要素と相互作用する。ＯＬＰのタイプは、前のステップで使用されたＯＰＲによって特定される。たとえば、ＯＬＰは、静的経路ＯＬＰ３０５または３ＧＰＰ ｉＦＣ ＯＬＰ３０６を含んでいてもよい。プロファイルに含まれる情報を用いて、ＯＬＰはオーケストレーション論理を取得し、オーケストレーション論理を処理し、どのアプリケーションを次にトリガするかを判断する。アプリケーションがＯＬＰによって一旦選択されると、オーケストレーションエンジンはセッションをそのアプリケーションに向けて送り、そのアプリケーションが戻ってくるのを待つ；
ｃ．セッションが戻ってくると、オーケストレーションエンジンは引続きオーケストレーション論理を処理して、トリガすべき次のアプリケーションを探す。このプロセスは、オーケストレーションが完了するまで繰返される。この段階では、オーケストレーションエンジンはセッションをセッション制御エンティティに戻す。

一実施例によれば、オーケストレーションエンジンがＯＰＲをトリガすると、ＯＰＲはオーケストレーションプロファイルを用いて応答する。これは、ＯＰＲが（１）加入者データおよびオーケストレーションプロファイルを保持するプロファイルサーバ（たとえば、ＨＳＳ、ＬＳＳ）に接続し、（２）セッション情報（たとえば、セッション送信元、セッション送信先、およびＩＮサービスキー）を用いてオーケストレーションプロファイルを選択し、（３）オーケストレーションプロファイルを取得してそれをオーケストレーションエンジンに転送することによって行なわれる。

さまざまな実施例によれば、異なるＯＰＲ３０４が、加入者データおよびオーケストレーションプロファイルの異なるソースに接続する。一例として、サービスブローカーは、ＨＳＳオーケストレーションプロファイルレシーバ３０７と、ＬＳＳオーケストレーションプロファイルレシーバ３０８とを含んでいてもよい。ホーム加入者サーバ（ＨＳＳ）は、ＩＭＳドメインにおける主要ユーザデータベースである。それは、加入者アプリケーションおよびオーケストレーションプロファイルを含む加入関連情報を含む。ＨＳＳ ＯＰＲは、標準Ｓｈインターフェイスを通してダイアメータプロトコルを用いて、ＨＳＳに接続し、オーケストレーションプロファイルを選択する。サービスブローカーはまた、ローカル加入者サーバ（ＬＳＳ）と呼ばれるプロファイルサーバの搭載実現化例を含んでいてもよい。ＬＳＳは、初期フィルタ条件（ｉＦＣ）フォーマットで与えられるオーケストレーション論理を含む加入者プロファイルを記憶可能である。ＬＳＳ ＯＰＲはＬＳＳに接続して、オーケストレーション論理を有する加入者プロファイルを探す。また、サービスブローカーは、デフォルトオーケストレーションプロファイルレシーバを採用していてもよい。このＯＰＲを使用する場合、オーケストレーションエンジンは、外部サーバからオーケストレーションプロファイルを検索しない。代わりに、ＯＥは、その予め構成されたオーケストレーション論理を有する静的経路ＯＬＰをトリガする。

さまざまな実施例によれば、オーケストレーション論理プロセッサ（ＯＬＰ）３０３は、どのアプリケーションをどの順序で呼出すかを判断するために、オーケストレーション論理を取得してそれを処理する。ＯＬＰは、オーケストレーションエンジンによってトリガされる。それはプロファイルデータを用いて、呼出す必要があるアプリケーションのアドレスを代わりに提供する。アプリケーションがその処理を終了し、オーケストレーションエンジンに戻ると、エンジンはＯＬＰを再度トリガして、呼出すべき次のアプリケーションのアドレスを受信する。異なるフォーマットのプロファイルおよびオーケストレーション論理規則を処理するために、異なるＯＬＰが使用される。サービスブローカーは、初期フィルタ条件（ｉＦＣ）ＯＬＰと、静的経路ＯＬＰとを含んでいてもよい。初期フィルタ条件（ｉＦＣ）とは、ＥＴＳＩ ＴＳ １２９ ２２８ Ｖ７．１１．０、ＩＰマルチメディア（ＩＭ）サブシステムＣｘおよびＤｘインターフェイスにおいて特定された、オーケストレーション論理を特定するための標準フォーマットである。ｉＦＣは、複数の条件（トリガポイント）と、ある条件が満たされると呼出されるアプリケーションサーバとから構成される、ＸＭＬフォーマットの１組の規則である。それらの条件は論理式で与えられており、セッション内のコンテンツフィールド上で適用可能である。静的経路ＯＬＰは、アプリケーションの予め構成されたリストを用いて、どのアプリケーションをどの順序で呼出すかを判断する。新しいＯＬＰをサービスブローカーに追加してオーケストレーション論理の追加のフォーマットをサポートすることも可能である。

図４は、この発明のさまざまな実施例に従った、課金オーケストレーションを行なうためのプロセスのフローチャート図である。この図は例示を目的としてある特定の順序での機能的ステップを示しているが、プロセスはこの特定の順序またはステップに必ずしも限定されない。当業者であれば、この図に示すさまざまなステップを変更し、再構成し、並行して行ない、またはさまざまな方法で適合させることができることを理解するであろう。また、この発明の精神および範囲から逸脱することなく、或るステップまたは一連のステップをこのプロセスに追加し、またはこのプロセスから省略することが可能である、ということが理解されるべきである。

ステップ４００に示すように、サービスブローカーは、電気通信ネットワークで生じた課金イベントを受信できる。サービスブローカーは次に、課金イベントのパラメータを検査し、課金規則および加入者の情報をチェックして（ステップ４０１）、課金イベントに応答してどの課金サービスを起動するかを判断することができる（ステップ４０２）。この情報に基づき、サービスブローカーは、課金イベントに応答した、サービスブローカーによる２つ以上の課金サービスの起動のオーケストレーションを行なうことができる（ステップ４０３）。

図５は、一実施例に従った、電気通信環境において課金オーケストレーションを行なうためのシステムの図である。図５に示すように、サービスブローカー５００は、電気通信ネットワーク５０４から課金イベント５０２を受信できる。サービスブローカーは、課金イベントのパラメータ５０８と、１組の課金規則５１０と、加入者の情報５１２とを検査して（５０６）、課金イベントに応答してどの課金サービスを起動するかを判断する（５１４）ことができる。サービスブローカー上に存在するオーケストレーションエンジン５１６が次に、課金イベントに応答した２つ以上の課金サービス５２０の起動のオーケストレーションを行なう（５１８）ことができる。

この開示において説明されたさまざまなコンテキスト全体を通し、この発明の実施例は、前述のシステムおよび方法を実行するよう構成されたコンピュータ装置、コンピューティングシステム、およびマシン読取可能媒体をさらに包含する。当業者には明らかであるように、特別に設計された集積回路または他の電子機器からなる一実施例に加え、この発明は、この開示の教示に従ってプログラミングされた従来の汎用もしくは専用デジタルコンピュータまたはマイクロプロセッサを用いて適宜実現されてもよい。

ソフトウェア技術の当業者には明らかであるように、この開示の教示に基づき、適切なソフトウェア符号化が、熟練したプログラマーによって容易に準備可能である。当業者には容易に明らかであるように、この発明はまた、特定用途向け集積回路を準備することによって、または従来の構成回路の適切なネットワークを相互接続することによって実現されてもよい。

さまざまな実施例は、ここに提示された特徴のいずれかを行なうように汎用または専用コンピューティングプロセッサ／機器をプログラミングするために使用可能な命令を記憶した記憶媒体であるコンピュータプログラム製品を含む。記憶媒体は、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、光磁気ディスク、ホログラフィックストレージ、ＲＯＭ、ＲＡＭ、ＰＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ機器、磁気カードまたは光カード、ナノシステム（分子メモリＩＣを含む）を含む任意のタイプの物理的媒体；紙または紙ベースの媒体；ならびに命令および／または情報を記憶するのに好適な任意のタイプの媒体または装置のうちの１つ以上を含んでいてもよいが、それらに限定されない。コンピュータプログラム製品は全体でまたは分割して、１つ以上の公的および／または私的ネットワークを通して送信されてもよく、送信は、ここに提示された特徴のいずれかを行なうために１つ以上のプロセッサによって使用可能な命令を含む。さまざまな実施例では、送信は、複数の別個の送信を含んでいてもよい。

この発明の好ましい実施例の前述の説明は、例示および説明を目的として提供された。それは、包括的であるよう、または発明を開示されたそのままの形に限定するよう意図されてはいない。多くの修正および変更が当業者には明らかであり得る。発明の原理およびその実際の用途を最良に説明するために、実施例は選択され、説明されており、それにより、関連技術の他の当業者がこの発明を理解することができるようにしている。この発明の範囲は添付の請求項およびそれらの均等物によって定義される、ということが意図されている。

Claims (11)

1. 電気通信環境において課金オーケストレーションを行なうための方法であって、前記方法は、
   サービスブローカーによって、電気通信ネットワークからの課金イベントを受信するステップと、
   前記課金イベントに応答してどの課金サービスを起動するかを判断するために、前記サービスブローカーによって、前記課金イベントのパラメータと、複数の課金規則と、加入者の情報とを検査するステップと、
   前記課金イベントに応答した、前記サービスブローカーによる２つ以上の課金サービスの起動のオーケストレーションを行なうステップと、を含み、
   前記サービスブローカーは、１つ以上のオーケストレーション論理プロセッサ（ＯＬＰ）によって、どのアプリケーションをある特定の順序で呼出すかを判断するために、オーケストレーション論理を取得して前記オーケストレーション論理を処理し、
   前記オーケストレーション論理は、前記オーケストレーションのために、セッションを扱うべきアプリケーションと前記アプリケーションを呼出すべき順序とを規定する、方法。
2. 前記サービスブローカーは、旧来のサービスとＩＰマルチメディアシステム（ＩＭＳ）／ロングタームエボリューション（ＬＴＥ）サービスとの組合せを含む異なる課金サービス間で、課金イベントのオーケストレーションを行なう、請求項１に記載の方法。
3. 前記サービスブローカーは、課金オーケストレーションを行なうために使用される課金論理を記憶するオーケストレーションエンジンをさらに含み、前記課金論理は拡張マークアップ言語（ＸＭＬ）文書で記憶されている、請求項１または２に記載の方法。
4. 前記課金サービスの起動のオーケストレーションを行なうステップは、前記順序で呼出される異なるタイプのアプリケーションが単一のコールのコンテキストにおいて前記２つ以上の課金サービスからなる複合サービスを構築することを可能にする、請求項１から３のいずれか一項に記載の方法。
5. 前記サービスブローカーは、オーケストレーションプロファイルを選択し検索する１つ以上のオーケストレーションプロファイルレシーバ（ＯＰＲ）をさらに含む、請求項１から４のいずれか一項に記載の方法。
6. 前記１つ以上のＯＰＲは、加入者データおよびオーケストレーションプロファイルを保持するプロファイルサーバに接続し、セッション情報を用いてオーケストレーションプロファイルを選択し、前記オーケストレーションプロファイルを取得し、前記オーケストレーションプロファイルをオーケストレーションエンジンに転送する、請求項５に記載の方法。
7. 前記オーケストレーションは、プリペイドコールサービス用のスポンサーコードを含み、コールが行なわれると、前記コールの料金の一部分は、ある課金サービスを用いて加入者の口座から差引かれ、別の部分は、異なる課金サービスを呼出すことによってスポンサーの口座から差引かれる、請求項１から６のいずれか一項に記載の方法。
8. 前記サービスブローカーは、アプリケーションサーバを接続し、
   前記ＯＬＰは、前記オーケストレーション論理により規定される前記特定の順序で呼出すべきアプリケーションのアドレスを、前記サービスブローカーに提供し、
   前記サービスブローカーは、前記アドレスにより前記アプリケーションを呼出す、請求項１から７のいずれか一項に記載の方法。
9. 電気通信環境において課金オーケストレーションを行なうためのシステムであって、前記システムは、
   電気通信ネットワークからの課金イベントを受信し、課金イベントに応答してどの課金サービスを起動するかを判断するために、課金イベントのパラメータと、複数の課金規則と、加入者の情報とを検査する、サービスブローカーと、
   課金イベントに応答した２つ以上の課金サービスの起動のオーケストレーションを行なう、前記サービスブローカー上に存在するオーケストレーションエンジンと、を含み、
   前記サービスブローカーは、どのアプリケーションをある特定の順序で呼出すかを判断するために、オーケストレーション論理を取得して前記オーケストレーション論理を処理するために１つ以上のオーケストレーション論理プロセッサ（ＯＬＰ）を有し、
   前記オーケストレーション論理は、前記オーケストレーションのために、セッションを扱うべきアプリケーションと前記アプリケーションを呼出すべき順序とを規定する、システム。
10. 前記サービスブローカーは、アプリケーションサーバを接続し、
    前記ＯＬＰは、前記オーケストレーション論理により規定される前記特定の順序で呼出すべきアプリケーションのアドレスを、前記サービスブローカーに提供し、
    前記サービスブローカーは、前記アドレスにより前記アプリケーションを呼出す、請求項９に記載のシステム。
11. 請求項１から８のいずれか一項に記載の方法をコンピュータに実行させるためのプログラム。