(57)【要約】  通信サービスアプリケーションとは別のソフトウェアプロセスとして動作するルールエンジン（Ｒｕｌｅｓ  Ｅｎｇｉｎｅ）で使用されるルールを、ルールエディタ（Ｒｕｌｅｓ  Ｅｄｉｔｏｒ）を使用して準備する通信ネットワークにおいて、プリペイド／ポストペイド通信サービスを提供するためのシステムおよび方法が提供される。ルールは、サービスプロバイダや個々の加入者による方法を含むさまざまな方法で準備することができる。【選択図】図１
2009525689.tif 000002
【特許請求の範囲】
【請求項１】
グローバルデータベーススキーマに変更を加えることなくルールエンジンに固有のデータを定義するステップであって、そのことによってアプリケーションソフトウェアを再コンパイルすることなくデータを追加できるステップと、
アプリケーションがルールセットを実行するためのルールエンジンクエリーとしてルールエンジンに固有のデータをルールエンジンに提供するステップとをさらに備える請求項１０に記載の方法。
【請求項２】
アプリケーションがリアルタイムコール処理中にルールエンジンにクエリーを送信する、請求項１に記載の方法。
【請求項３】
ルールエディタがルールをルールデータベースにアップロードして保存し、ルールデータベースは実行するルールを取得するためにルールエンジンによってアクセスできる、請求項１に記載の方法。
【請求項４】
サービスプロバイダおよび／または加入者が、ルールエディタを使用してインターネット経由および／またはモバイルハンドセット経由でルールを準備できる、請求項１に記載の方法。
【請求項５】
通信ネットワークが無線通信ネットワークである、請求項１に記載の方法。
【請求項６】
通信ネットワークが有線通信ネットワークである、請求項１に記載の方法。
【請求項７】
通信ネットワークにおいてプリペイド／ポストペイド通信サービスを提供するシステムであって、
ルールを作成し、ルールを更新し、さらにルールをネットワークエレメントに配信するためのルールエディタと、
プリペイド／ポストペイド通信サービスを提供するためのソフトウェアプロセスとして動作する通信サービスアプリケーションであって、アプリケーションロジック内の決定点でルールエンジンクエリーを生成し、ルールエンジンクエリーは１つまたは複数の入力ＮＶＰ（Ｎａｍｅ  Ｖａｌｕｅ  Ｐａｉｒ）を含むアプリケーションと、
アプリケーションから受信したルールエンジンクエリー入力を使用してルールを実行し、実行されたルールの結果によって決定される出力ＮＶＰを含み、出力ＮＶＰはアプリケーションによって実行される１つまたは複数のアクションを指定するルールエンジンクエリー出力を提供するための、アプリケーションとは別のプロセスとして動作するルールエンジンとを備える、システム。
【請求項８】
アプリケーションがリアルタイムコール処理中にルールエンジンにルールエンジンクエリーを送信する、請求項７に記載のシステム。
【請求項９】
ルールエディタがルールをルールデータベースにアップロードして保存し、ルールデータベースは実行するルールを取得するためにルールエンジンによってアクセスできる、請求項７に記載のシステム。
【請求項１０】
サービスプロバイダおよび／または加入者が、ルールエディタを使用してインターネット経由および／またはモバイルハンドセット経由でルールを準備できる、請求項７に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービスロジック決定ルールにポリシー管理を統合することによって、既存のプリペイド／ポストペイド通信サービスアプリケーションを拡張するためのシステムおよび方法に関する。
【背景技術】
【０００２】
本発明は、特に無線通信システム（セルラーシステムとも呼ばれる）の技術を目的としており、したがって特に無線通信システムに関連して説明されているが、当然のことながら、本発明は有線通信ネットワークやＩｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ−Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍｓ（ＩＭＳ）ネットワークを含むその他の分野およびアプリケーションにも有効であると考えられる。
【０００３】
増大し続ける顧客ベースに対してますます高レベルのサービスを提供するとともに、リソースの配備方法を決定する上で柔軟性の向上を可能にするために、通信ネットワークの管理において、ポリシー管理はますます重要になっている。ネットワークにおける既存のポリシーサポートの多くは、きわめて短い応答時間で大規模に実施できる比較的シンプルなポリシーというニーズに追い立てられてきた。
【０００４】
従来のプリペイド無線サービスアプリケーションでは、国際電気通信連合（ＩＴＵ：Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｕｎｉｏｎ）サービスの作成標準に基づく決定グラフ（Ｄｅｃｉｓｉｏｎ  Ｇｒａｐｈｓ）を使用してポリシー管理を実行している。しかし、決定グラフには、通常、エンドユーザーに固有でない、つまり個々の加入者レベルでは定義できない複雑なテーブル駆動型ロジックが含まれている。
【０００５】
ネットワークが集中し、エンドユーザーサービスがさらに包括的になるにつれて、こうした変化に適応できるポリシーインフラストラクチャを提供することが重要になっている。オペレータおよびエンドユーザーさえも、個々のニーズに合わせて容易にカスタマイズでき、パーソナライズできるポリシーインフラストラクチャである。
【０００６】
Ｌｕｃｅｎｔ  Ｔｅｃｈｎｏｌｏｇｉｅｓ社は、ポリシー管理プロジェクトとしてルールエンジン（ＲＥ：Ｒｕｌｅｓ  Ｅｎｇｉｎｅ）を開発してきた。ルールエンジンは、米国特許出願第６，４２４，９４８号および米国特許出願第６，４９９，０２３号で説明するように、新しく出現するサービスアプリケーションをサポートできる表現力がきわめて高いポリシーを指定し、実施するための高速で拡張可能なキャリアグレード（ｃａｒｒｉｅｒ−ｇｒａｄｅ）のサポートを提供する。上記の特許は、いずれも入力条件に基づいてデータ項目を評価するための強力で柔軟性の高い技術に関するルールワークフローシステムおよび計算ルールと組み合わせポリシーの使い方について説明している。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
既存の通信サービスでは、プリペイドおよび／またはポストペイドサービスアプリケーションに関して、非常に複雑な加入者アカウントデータの管理および評価システムが必要である。こうした複雑性は、準備とパフォーマンスの問題の原因となり、新しいサービスの作成や拡張に多大な影響を及ぼしている。サービスの作成および拡張を迅速かつ容易に展開できるようにする場合に、より大きな柔軟性を提供できる新しいソリューションを検出するのが望ましい。
【０００８】
本発明は、前述の問題およびその他の問題を解決する新しい改善されたシステムおよび方法を目的とする。
【課題を解決するための手段】
【０００９】
サービスアプリケーションとは別のソフトウェアプロセスとして動作するルールエンジンで使用されるルールを、ルールエディタを使用して準備する通信ネットワークにおいて、プリペイド／ポストペイド通信サービスを提供するためのシステムおよび方法が提供される。
【００１０】
本発明の１つの態様により、本システムには、ルールを作成し、ルールを更新し、さらにルールをネットワークエレメントに配信するためのルールエディタと、プリペイド／ポストペイド通信サービスを提供するソフトウェアプロセスとして動作する通信サービスアプリケーション（アプリケーションはアプリケーションロジック内の決定点（Ｄｅｃｉｓｉｏｎ  Ｐｏｉｎｔ）でルールエンジンクエリー（Ｒｕｌｅｓ  Ｅｎｇｉｎｅ  ｑｕｅｒｙ）を生成し、ルールエンジンクエリーは１つまたは複数の入力Ｎａｍｅ  Ｖａｌｕｅ  Ｐａｉｒ（ＮＶＰ）を含む）と、アプリケーションから受信したルールエンジンクエリー入力を使用してルールを実行し、実行されたルールの結果によって決定される出力ＮＶＰ（出力ＮＶＰはアプリケーションによって実行される１つまたは複数のアクションを指定する）を含むルールエンジンクエリー出力を提供するための、アプリケーションとは別のプロセスとして動作するルールエンジンとが含まれる。
【００１１】
本発明の別の態様により、本方法には、ルールエディタを使用してルールを作成するステップと、プリペイドおよび／またはポストペイド通信サービスを提供するソフトウェアプロセスとしてプリペイド／ポストペイド通信サービスアプリケーションを操作するステップと、アプリケーションがアプリケーションロジック内の決定点に到達し、１つまたは複数の入力ＮＶＰおよびルールセットＩＤを含むルールエンジンクエリーを生成するステップと、アプリケーションがアプリケーションプロセスとは異なる個別のプロセスとして動作するルールエンジンにルールエンジンクエリーを送信するステップと、ルールエンジンが１つまたは複数の入力ＮＶＰを使用してルールセットＩＤで決定された適用可能なルールセットを実行し、１つまたは複数のアクションを指定する１つまたは複数の出力ＮＶＰを含むルールエンジンクエリー応答を生成するステップと、アプリケーションがルールエンジンクエリー応答を受信し、１つまたは複数のアクションを実行するステップとが含まれる。
【００１２】
これ以外に本発明を適用できる範囲は、以下に示す詳細な説明から明らかになるであろう。ただし、詳細な説明および特定の例は、本発明の好ましい実施形態を示しているが、説明のみを目的として提供されていることを理解されたい。というのは、本発明の精神および範囲を逸脱しないさまざまな変更や変形が当業者には明らかになるからである。
【００１３】
本発明は、装置を構成するさまざまな要素の構造、配列、および組み合わせ、および方法を構成するステップの形で存在しており、それによって意図された目的については、本明細書の以下の部分でより詳細に説明し、特許請求の範囲で明確に提示し、さらに以下に示す添付の図面に示している。
【発明を実施するための最良の形態】
【００１４】
ここで図面を参照すると（図面に示す内容は、本発明の好ましい実施形態の説明のみを目的としており、本発明を限定するためのものではない）、図１はエンドユーザーに無線通信サービスを提供する好ましいシステム全体の図が示されている（一般的に１００で示されている）。システム１００は、無線通信サービスを提供できるネットワークノード１１２を備える無線通信ネットワーク（たとえば、ＧＳＭ、ＣＤＭＡ、または他の既知の無線通信ネットワーク）の一部でもよい。こうしたノードの例には、特に基地局、モバイル交換センター、およびＨＬＲ（Ｈｏｍｅ  Ｌｏｃａｔｉｏｎ  Ｒｅｇｉｓｔｅｒ）を含めることができるが、これらに限定はされない。システム１００は、通常、サービスプロバイダ（ネットワークプロバイダとも呼ばれる）によって提供され、管理されている。ただし、システム１００は有線ネットワークまたはＩＭＳネットワークにおいて同様の通信機能を提供できるアナログネットワークエレメントを使用する有線ネットワークまたはＩＭＳネットワークでもよいことを理解されたい。
【００１５】
システム１００には、１つまたは複数のプロセッサ（図示せず）上で実行され、１１６に示すアクションを介して１つまたは複数のネットワークノード１１２に指示し、モバイルハンドセット（ｍｏｂｉｌｅ  ｈａｎｄｓｅｔｓ）１０２（特にモバイルハンドセット、携帯電話（ｍｏｂｉｌｅ  ｐｈｏｎｅｓ  ａｎｄ  ｃｅｌｌｕｌａｒ  ｐｈｏｎｅｓ）とも呼ばれる）を介してエンドユーザーに適切なサービスを提供する１つまたは複数のアプリケーション１１４が含まれる。こうしたアクションには、サービスプロバイダに管理と保守の機能を提供すること（たとえば、監査または検証サービスを提供すること）を含めてもよい。
【００１６】
システム１００には、さらにアプリケーション１１４と通信し、アプリケーション１１４で使用するサービスロジック決定ルールにポリシー管理を統合することにより、すべての加入者によるサービスへのニーズを個別に確認し、リアルタイムで（たとえばコール処理中に）アクション１１６を使用してこれを実現するＰｏｌｉｃｙ  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｔｅｒｆａｃｅ（ＰＭＩ）１１８も含まれる。ＰＭＩ  １１８には、１つまたは複数のルールエディタ（１つまたは複数）１２２から提供される計算上のルールを処理するルールエンジン１２０もさらに含まれている。ルールは、ルールデータベース１２４に格納でき、ルールエンジン１２０からアクセスすることができる。１つまたは複数のユーザーインターフェイス１２６によって、エンドユーザーおよびサービスプロバイダはルールを作成し、変更し、配信することができるが、この方法では、アプリケーション１１４に再コンパイルを要する大幅な変更を加え、それによって新しいアプリケーション製品をリリースする必要はない。例示を目的として無線通信ネットワークが使用されているが、本発明はアナログネットワークノードを使用する有線通信ネットワークおよびＩｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  Ｍｕｌｔｉｍｅｄｉａ  Ｓｕｂｓｙｓｔｅｍｓ（ＩＭＳ）ネットワークにも適用できることを理解されたい。
【００１７】
ここで図２を参照すると、無線プリペイドサービスを提供するアプリケーション２１４を含むシステム１００の例が２００に示されている（Ｌｕｃｅｎｔ  Ｔｅｃｈｎｏｌｏｇｉｅｓ社製のＭｉＬｉｆｅ（登録商標）  ＳｕｒｅＰａｙ製品スイートとして知られている）。このプリペイドサービスアプリケーション２１４は、一連の包括的な無線プリペイドサービスをエンドユーザーに提供する。エンドユーザーは、通常はこうしたサービスに加入し、それによって加入者と呼ばれるが、こうしたサービスはより大規模なサービスの要素であってもよく、加入の権限なしにエンドユーザーに提供されてもよいので、こうした用語を限定と見なしてはならない。システム１００／２００は、ポストペイド無線サービスおよび無線ネットワークバックオフィス請求システム（ｂａｃｋ  ｏｆｆｉｃｅ  ｂｉｌｌｉｎｇ  ｓｙｓｔｅｍｓ）にも適用できることを理解されたい。
【００１８】
ＰＭＩ  １１８には、ルールエンジン２２０（Ｌｕｃｅｎｔ  Ｔｅｃｈｎｏｌｏｇｉｅｓ社製のＬｕｃｅｎｔ  Ｖｏｒｔｅｘ（商標）として知られている）が含まれている。Ｌｕｃｅｎｔ  Ｖｏｒｔｅｘ（商標）ルールエンジンは、ＩＥＴＦポリシーフレームワーク標準とＰａｒｌａｙ／ＯＳＡポリシー管理ＡＰＩ標準に基づいている。以下でより詳細に説明するように、ルールエンジン２２０は、適用可能なルールセットと呼ばれる１つまたは複数のルールを実行し、ロジック駆動型の（ｌｏｇｉｃ  ｄｒｉｖｅｎ）結果を提供することによって、１つまたは複数のアクションを実行して通信サービスを提供する。
【００１９】
ルールエンジン２２０は、無線通信ネットワークの複数の機能エレメント（ｆｕｎｃｔｉｏｎａｌ  ｅｌｅｍｅｎｔｓ）に配信することができ、したがって複数のネットワークノード１１２に配置できるが、ＰＭＩは唯一のネットワークノードによってのみ提供できることを理解されたい。システム２００には、無線ネットワーク内のコール処理動作を担当するサービス制御機能（ＳＣＦ：Ｓｅｒｖｉｃｅ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）２４０が含まれる。この機能２４０は、１つまたは複数のネットワークノード１１２（たとえば、１つまたは複数のサービス制御ポイント（ＳＣＰ：Ｓｅｒｖｉｃｅ  Ｃｏｎｔｒｏｌ  Ｐｏｉｎｔ））に含めることができる１つまたは複数の計算用プロセッサ（ｃｏｍｐｕｔａｔｉｏｎａｌ  ｐｒｏｃｅｓｓｏｒｓ）によって提供できる。
【００２０】
この例では、ＳＣＦ  ２４０によってアプリケーション２１４とルールエンジン２２０が提供されている。ただし、ルールエンジン１２０／２２０とアプリケーション１２４／２２４は、別々の計算用プロセッサ（特に、サーバー、コンピュータ、またはネットワークノードとも呼ばれる）によって実行できる別々のプロセスであることを理解されたい。しかし、代わりにこうした個別のプロセスを同一の計算用プロセッサで実行することもできる。ルールエンジン２２０とアプリケーション２１４を別々のプロセスとして実行することにより、アプリケーションの速度を低下することなくより複雑な決定が可能になるので、システム２００のパフォーマンスが向上する。これで、個々のエンドユーザーに固有のルールをシステム１００によって準備でき、実行できるようになる。
【００２１】
ルールデータベース２２４は、ルールエンジン２２０と同じ処理ノード上に配置することも、ルールエンジン２２０と通信する別のプロセッサ上に配置することもできる。
【００２２】
システム２００には、ＳＣＦ  ２４０によって提供されるルールエンジン２２０に密接に関連付けられたルールエディタ２２２ａを含む複数のルールエディタ２２２が含まれている。システム２００には、サービスプロバイダ２５４がルールの作成または既存のルールの変更によってルールを準備できるルールエディタ２２２ｂを備えるＳｅｒｖｉｃｅ  Ｃｒｅａｔｉｏｎ  ａｎｄ  Ｐｒｏｖｉｓｉｏｎｉｎｇ  Ｅｎｖｉｒｏｎｍｅｎｔ（ＳＣＰＥ）２５０も含まれている。ＳＣＰＥのルールエディタ２２２ｂはルールをルールエンジン２２０に配信して使用し、かつ／またはルールデータベース２２４に配信して保存する。サービスプロバイダ２５４は、ルールエディタ２２２ｂにアクセスし、インターネット接続２５６またはモバイルハンドセット２５８を使用するか、または既知のネットワーク接続を経由してルールを準備できる。
【００２３】
システム２００には、さらにエンドユーザー２６４が個々にルールを作成し、既存のルールを変更することによってルールを準備できるようにするルールエディタ２２２ｃを備えるエンドユーザーインターフェイス（ＥＵＩ：Ｅｎｄ  ｕｓｅｒ  ｉｎｔｅｒｆａｃｅ）２６０も含まれている。このようにして、ルールは加入者に固有になるように準備できるので、アプリケーション２１４は個々のエンドユーザーに固有のニーズに合わせて調整され、カスタマイズされた無線プリペイドサービスを提供することができる。エンドユーザー２６４は、インターネット接続２６６経由、またはモバイルハンドセット２６８経由でＷｅｂベースのブラウザを使用してルールエディタ２２２ｃでルールを準備できる。ルールエディタ２２２ｃは、準備されたルールをルールエンジン２２０に配信して使用し、かつ／またはルールデータベース２２４に配信して保存する。
【００２４】
次に図３を参照すると、システム２００の動作方法が３００に一般的に示されている。３０２で、１つまたは複数のルールエディタ２２２ａ−２２２ｃを使用してルールが準備される。たとえば、ルールは、サービスプロバイダ２５４によってルールエディタ２２２ｂを使用して作成および／または変更してから、ルールデータベース２２４に配信して保存することができる。前述のように、サービスプロバイダ２５４はプリペイドサービスアプリケーション２１４に新しい製品のリリースを要する大幅なソフトウェア変更を加えることなくルールを準備できる。
【００２５】
アプリケーション２１４はＳＣＦ２４０内で動作しており、３０４で決定点に到達する。広範囲にわたるさまざまな決定点は、アプリケーション２１４内のコンフィギュレーションデータ（ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｄａｔａ）を使用して定義できる。例には、コールが評価される前、およびルーティングされる（ｒｏｕｔｅｄ）前に呼び出されるプレコール（Ｐｒｅ−Ｃａｌｌ）決定点を含めることができるが、限定と見なしてはならない。プレコール決定点は、音声コールおよびデータコールなどを含むがこれらに限定はされないあらゆるタイプのコールに適用される。
【００２６】
プレルート（Ｐｒｅ−Ｒｏｕｔｅｄ）コール決定点は、コールが評価された後、しかしコールがルーティングされる前に呼び出される。この決定点も、音声コール、データコールなどを含むあらゆるタイプのコールに適用される。
【００２７】
決定点には、たとえば、イベント／セッションベースでチャージするための標準プロトコルであるＤｉａｍｅｔｅｒイベントチャージ（ｅｖｅｎｔ  ｃｈａｒｇｅ）、または別の標準プロトコルであり、本来はリモートサーバーからデータにアクセスする手段として定義されたが、ＳｕｒｅＰａｙアプリケーションによって使用され、コンテンツのチャージ（たとえば、着メロ（ｒｉｎｇｔｏｎｅ）ダウンロードのサブ（ｓｕｂ）のチャージ）を行うＬｉｇｈｔｗｅｉｇｈｔ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＬＤＡＰ）要求などのプレイベント（Ｐｒｅ−Ｅｖｅｎｔ）決定点も含まれる。プレイベント決定点には、特にリアルタイムＳＭＳサービスの実装を含めることもできる。
【００２８】
決定点には、さらにコールが完了した後に呼び出されるポストコール決定点、およびイベントが発生した後に呼び出されるポストイベント決定点を含めてもよい。
【００２９】
監査決定点（Ａｕｄｉｔ  Ｄｅｃｉｓｉｏｎ  Ｐｏｉｎｔｓ）は、監査プロセス（たとえば、日次または月次のアカウント監査プロセスなど）から呼び出される決定点である。
【００３０】
再チャージ（Ｏｎ  Ｒｅｃｈａｒｇｅ）決定点は、プリペイドコールプランの再チャージ（トップアップとも呼ばれる）が実行されるときに呼び出される決定点である。
【００３１】
メニューアクセス（Ｍｅｎｕ  Ａｃｃｅｓｓ）決定点は、エンドユーザーが使用中に作動させる双方向音声応答（ＩＶＲ：Ｉｎｔｅｒａｃｔｉｖｅ  Ｖｏｉｃｅ  Ｒｅｓｐｏｎｓｅ）などのメニューアクセスロジックによって呼び出される決定点である。これ以外の決定点には、モバイルハンドセットから特定のショートコード（たとえば＊６４）をダイヤルすることによって呼び出されるショートコード（Ｓｈｏｒｔ  Ｃｏｄｅ）決定点を含めることができる。
【００３２】
決定点は、加入者が最初にコールしたとき、その日の最初のコール（Ｆｉｒｓｔ  Ｃａｌｌ  ｏｆ  ｔｈｅ  Ｄａｙ）決定点、またはその月の最初のコール（Ｆｉｒｓｔ  Ｃａｌｌ  ｏｆ  ｔｈｅ  Ｍｏｎｔｈ）決定点などのコール特異点でもよい。アクティブ化（Ａｃｔｉｖａｔｉｏｎ）決定点は、加入者がそのアカウントを最初にアクティブ化したときに呼び出される決定点である。
【００３３】
アプリケーション２１４は、３０６で決定点がアクティブかどうかを決定する条件として、別のプロセスから呼び出される必要のないデータであるローカルコンフィギュレーションデータを使用する。たとえば、プレコール決定点は、エンドユーザーがプリペイドコールを実行中に、プリペイドエンドユーザーのローカルコンフィギュレーションデータによって提供される条件が満たされる場合にアクティブと見なされる。アプリケーション２１４は、３０６で決定点がアクティブでないと判定した場合に、アプリケーションは３０８でルールエンジンにクエリーを送信することなく続行される。アプリケーション２１４は、３０６で決定点がアクティブであると判定した場合に、アプリケーション２１４は３１０でルールエンジン２２０に１つまたは複数のルールエンジンクエリー２３０ａを送信することによって、ルールエンジンで１つまたは複数の特定のルール（本明細書ではルールセットと呼ばれる）の処理をトリガする。
【００３４】
個々のコールまたはイベントには、アクティブな決定点が存在しなくても、１つまたは複数存在してもよい。唯一のコールによって、アプリケーション２１４がルールエンジン２２０を呼び出し、複数のルールエンジンクエリーを使用して複数の異なるルールセットを処理するようにできる。個々の決定点は、アプリケーション２１４内で別々のコンフィギュレーションデータによってアクティブ化できる。異なる加入者クラスは、異なるアクティブ決定点のセットを使用して構成できる。さらに、ルールエンジンクエリー（たとえば、ユーザーが特定の料金プラン（ｔａｒｉｆｆ  ｐｌａｎ）に加入しているかどうか、または加入者のアカウント残高（ａｃｃｏｕｎｔ  ｂａｌａｎｃｅ）が特定のしきい値を超えているかどうかといった唯一のクエリー）をトリガする必要があるかどうかを決定する場合に使用される追加の基準を柔軟に定義できる。
【００３５】
アプリケーション２１４とルールエンジン２２０は別々のソフトウェアプロセスであるため、ルールエンジンクエリーはプロセス間（ｉｎｔｅｒｐｒｏｃｅｓｓ）クエリーである。アプリケーション２１４とルールエンジン２２０は、同一の計算用プロセッサ上で実行されるローカルプロセスでもよい。あるいは、別々のプロセッサ上で実行されるリモートプロセスであり、ルールエンジンクエリーおよび応答はネットワーク接続を経由して送信されてもよい。さらに、ルールエンジンクエリーは、よく知られている任意の適切な信号プロトコルおよび／または通信プロトコルを使用して提供できるので、さまざまな無線通信ネットワークを実装する上でシステム２００の柔軟性を向上する。
【００３６】
アプリケーション２１４は、アクティブな決定点でルールエンジンにルールエンジンクエリー（１つまたは複数）の形で情報を提供し、ルールエンジンによって実行される１つまたは複数のルール（適用可能なルールセットと呼ばれる）を、ルールセットＩＤを使用して識別する。
【００３７】
ルールエンジンクエリーには、ルールエンジン２２０で適用可能なルールセットを実行するために使用されるデータを提供する入力Ｎａｍｅ  Ｖａｌｕｅ  Ｐａｉｒ（ＮＶＰ）も含まれる。この入力ＮＶＰデータは、アプリケーション２１４によって既存の任意のアプリケーション変数を含むように構成できる。たとえば、アクティブなプレコール決定点で、アプリケーションは、いくつかある変数の中で特に、加入者ＩＤ、現在の残高レベル（ｂａｌａｎｃｅ  ｌｅｖｅｌ）、料金プラン、ダイヤルナンバーを送信できる。このようにして、アプリケーションロジック内で定義される任意の変数は、入力ＮＶＰの候補になることができる。
【００３８】
既存の任意のアプリケーション変数を含むように入力ＮＶＰの内容を柔軟に定義できることに加えて、サービスプロバイダ２５４はルールエンジンクエリー内でルールエンジン２２０に入力として渡すことができる新しいデータ（ルールエンジンに固有のデータと呼ばれる）を定義できる。ルールエンジンに固有のデータをさまざまに定義できるので、ルールエンジンは１つまたは複数のアプリケーションに強力で柔軟な容易に準備できるインターフェイスを提供することができる。例には、個々の加入者、加入者クラス、または他のタイプのグループに合わせたデータの定義、あるいは全般的なデータの定義を含めることができる。データは、料金方式に関連するものでも、コール処理を含む通信ネットワークの動作に関する他の側面に適用できるものでもよい。
【００３９】
ルールエンジンに固有のデータは、グローバルデータベーススキーマを一切変更することなしに定義できるので、アプリケーションを再コンパイルすることなくデータを追加でき、したがってアプリケーションソフトウェアの新しい製品をリリースする必要もない。
【００４０】
ルールエンジンに固有のデータは、アプリケーション自体によって生成できる。ルールセット自体が、ルールエンジンに固有のデータに対して適用する更新を指定することもできる。さらに、たとえば、ＷｅｂまたはＷＡＰを経由して接続されたセルフケアインターフェイス（ｓｅｌｆ−ｃａｒｅ  ｉｎｔｅｒｆａｃｅ）の形をとるものなどのエンドユーザーインターフェイス（ＥＵＩ：Ｅｎｄ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を使用して、ルールエンジンに固有のデータを加入者自身で更新することもできる。
【００４１】
ルールエンジン２２０は、３１２で適用可能なルールセットを実行すると、３１４で出力ＮＶＰを生成し、図１の１１２に示されるネットワークノード上に実装された１つまたは複数のアクションの実行を、既知のプロトコルを使用して指定できる。出力ＮＶＰは、３１６でルールエンジン２２０からアプリケーション２１４に返送されるルールエンジン応答２３０ｂに含まれる。３１８でアプリケーションはクエリー応答を受信し、３２０で特定のエンドユーザーに合わせてアクションが実行される。前述のように、これはすべてリアルタイムで（たとえば、コール実行中、または特に監査、バックアップ、または保守に関連する業務などといったスケジュールされた実装を実行中に）実行できる。
【００４２】
ステップ３２０で実行される広範囲にわたるさまざまなアクションは、アプリケーション内で定義できる。例には、クエリー入力および／またはクエリー応答で定義された加入者のアカウント残高にデビットまたはクレジットを適用する“Ａｄｊｕｓｔ  Ｂａｌａｎｃｅ”、１つのアカウントから別のアカウントに残高を転送する“Ｔｒａｎｓｆｅｒ  Ｂａｌａｎｃｅ”、“Ａｐｐｌｙ  Ｒｅｃｈａｒｇｅ  ｂｙ  Ｃｒｅｄｉｔ  Ｃａｒｄ”、コールの処理が許可されるかどうかを判定する“Ｉｍｐｏｓｅ  Ｓｃｒｅｅｎｉｎｇ”、“Ｒｅｍｏｖｅ  Ｓｃｒｅｅｎｉｎｇ”、ＳＭＳメッセージが送信されるようにする（ＳＭＳ通知テキスト全体をルールセットによって定義すること、またはアプリケーション内で事前に準備することができる）“Ｓｅｎｄ  ＳＭＳ  Ｎｏｔｉｆｉｃａｔｉｏｎ”、ＵＳＳＤメッセージが送信されるようにする“Ｓｅｎｄ  ＵＳＳＤ  Ｎｏｔｉｆｉｃａｔｉｏｎ”、ＳＭＳメッセージがエンドユーザー以外のだれかに送信されるようにする（たとえば子供が特定の番号にコールしたことをその両親に通知させる）“Ｓｅｎｄ  ＳＭＳ  ｔｏ  ３ｒｄ  Ｐａｒｔｙ”、加入者のクレジットを特定の金額だけ削減する“Ｃｏｎｆｉｓｃａｔｅ  Ｃｒｅｄｉｔ”、加入者が特別な料金方式を受けられるようにする（たとえば割引料金を適用してもよい）“Ｓｕｂｓｃｒｉｂｅ  ｔｏ  ａ  Ｐｒｏｍｏｔｉｏｎａｌ  Ｔａｒｉｆｆ”、加入者のクレジットの期限が切れる期日を変更する“Ｍｏｄｉｆｙ  Ｃｒｅｄｉｔ  Ｅｘｐｉｒｙ  Ｄａｔｅ”、加入者（ｓｕｂｓ）のライフサイクルの状態をたとえば“Ｒｅｃｈａｒｇｅ  Ｏｎｌｙ”から“Ａｃｔｉｖｅ”に変更する“Ｔｒｉｇｇｅｒ  Ｃｈａｎｇｅ  ｔｏ  Ｓｕｂｓｃｒｉｂｅｒ’ｓ  Ｌｉｆｅｃｙｃｉｅ  Ｓｔａｔｅ”、無線ネットワークによってコールがどう処理されるかに関するさまざまなアクション（たとえば、このコールを接続から除外する、着信コールをボイスメールにルーティングするなど）を指定する“Ｃａｌｌ  Ｈａｎｄｌｉｎｇ”を含めることができるが、限定と見なしてはならない。さらに、出力ＮＶＰは、ルールエンジンに固有のデータを含むアプリケーションサーバーロジック内の特定の変数の内容をシステム２００が更新する必要があることを指定することもできる。
【００４３】
前述のように、無線通信サービスアプリケーションには、Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｕｎｉｏｎ（ＩＴＵ）サービスの作成標準に基づいてサービスカスタマイズ機能を提供する決定グラフがあらかじめ配備されている。ルールエンジン２２０では、従来は決定グラフでは不可能だったアプリケーション２１４のある程度のカスタマイズとパーソナライズが可能である。たとえば、決定グラフは加入者レベルでは定義できない。さらに、決定グラフはそれ自体のデータを作成できず、その代わりにサービスアプリケーションの要素となる変数のみを使用している。また、決定グラフはエンドユーザーからはアクセスできない。
【００４４】
しかし、ルールエンジン２２０は決定グラフに代わるものではなく、こうした先行技術を強化し、ネットワークプロバイダがそれぞれに固有の利点を拡張できるようにすることを目的としている。たとえば、決定グラフはエンドユーザーと直接対話できる（たとえば、アナウンス（ａｎｎｏｕｎｃｅｍｅｎｔ）を行ったりユーザーが入力した数字を受信したりして、決定グラフの後続の実行を指示することによる）。ルールエンジンのルールセットは、特別なアクション“Ｅｘｅｃｕｔｅ  Ｄｅｃｉｓｉｏｎ  Ｇｒａｐｈｓ”を使用して決定グラフを実行することができる。さらに、ルールエンジンクエリーは、ＤＧの内部から特別なルールエンジンＳＩＢ（Ｓｅｒｖｉｃｅ  ｉｎｄｅｐｅｎｄｅｎｔ  Ｂｕｉｌｄｉｎｇ  Ｂｌｏｃｋ）を使用してトリガできる。こうした技術の組み合わせによって高度な柔軟性とパーソナライズが提供され、ネットワークプロバイダは高度なサービスを非常に迅速に市場に提供することができる。
【００４５】
ここで図４を参照すると、システム２００の動作の特定の例が、４００のコールフロー図によって一般的に示されている。この例では、ルールエンジン２２０を使用して加入者２６４が継続的なプリペイドサービスから毎年プリペイドクレジットのボーナス再チャージという利益を得るシンプルなロイヤルティー管理スキーム（ｌｏｙａｌｔｙ  ｍａｎａｇｅｍｅｎｔ  ｓｃｈｅｍｅ）を定義している。こうしたシナリオでは、モバイルから発信されたコールによってプレコール決定点がトリガされる。この例で使用されるプロトコルは、Ｅｕｒｏｐｅａｎ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｔａｎｄａｒｄ  Ｉｎｓｔｉｔｕｔｅ  （ＥＴＳＩ）  ＣＳ１である。しかし、こうしたロイヤルティー管理スキームはシステム２００によって他の方法でも管理できること、たとえば監査決定点を使うことやその他の既知のプロトコルを使用してもよいことを理解されたい。
【００４６】
エンドユーザー２６４は、終端交換（Ｔｅｒｍｉｎａｔｉｎｇ  Ｅｘｃｈａｎｇｅ）４０１への無線プリペイドコールを実行する。終端交換４０１は、モバイルハンドセットでも有線電話（ｗｉｒｅｌｉｎｅ  ｐｈｏｎｅ）でもよい。サービング（ｓｅｒｖｉｎｇ）ＭＳＣ  １１２は、４０２で発信コール（ｏｕｔｇｏｉｎｇ  ｃａｌｌ）のＩｎｉｔｉａｌＤＰ開始イベントをアプリケーション２１４に送信する。アプリケーション２１４は、ローカルコンフィギュレーションデータをチェックして、この加入者のプレコール決定点がアクティブであることを確認する。
【００４７】
アプリケーション２１４は、コンフィギュレーションデータからルールセットＩＤと入力ＮＶＰのリストを取得し、４０４でルールエンジンクエリーとして要求を送信する。入力ＮＶＰデータには、ルールエンジンに固有のデータに格納された加入者の名前が含まれる。ルールエンジン２２０は、ルールエンジンクエリーを受信し、入力ＮＶＰを抽出し、さらに指定されたルールセットの実行を開始する。ルールセットの実行により、加入者が１年間にわたって顧客であり、したがってボーナスを受け取る資格があることを確認する。
【００４８】
ルールエンジン２２０は、１０ドルの再チャージを適用し、加入者のハンドセット２６８にＳＭＳ通知を送信し、加入者に通知するアクションを含む出力ＮＶＰを含むルールエンジンクエリー応答をアプリケーション２１４に返送する。アプリケーション２１４はクエリー応答を受信し、１０ドルのボーナスを適用し、さらに４０８でお祝いのＳＭＳ通知を送信する。
【００４９】
これで、コールセットアップは従来どおりに継続される。アプリケーション２１４は、４１０で通常のイベント（ｏＡｎｓｗｅｒ、ｏＤｉｓｃｏｎｎｅｃｔ、ＲｏｕｔｅＳｅｌｅｃｔＦａｉｌ、Ｂｕｓｙ、ｏＡｂａｎｄｏｎ、ＮｏＡｎｓｗｅｒなど）を含む要求レポートＢＣＳＭイベントをＭＳＣに送信し、さらにＣｏｎｔｉｎｕｅを送信する。ＭＳＣは、ＩＳＵＰ  Ｉｎｉｔｉａｌ  Ａｄｄｒｅｓｓ  Ｍｅｓｓａｇｅ（ＩＡＭ）４１２を終端交換に送信する。４１４でＩＳＵＰ  Ａｄｄｒｅｓｓ  ＣｏｍｐｌｅｔｅおよびＡｎｓｗｅｒが発信元（ｏｒｉｇｉｎａｔｉｎｇ）ＭＳＣに送信され、この時点でコールは正常音声（ｎｏｒｍａｌ  ｓｐｅｅｃｈ）フェーズにある。
【００５０】
発信元ＭＳＣ  １１２は、４１６でアプリケーション２１４にｏＡｎｓｗｅｒイベントを送信し、この時点で評価（ｒａｔｉｎｇ）を目的とした計時を開始する。最終的に、４２０で発信元パーティーはＩＳＵＰ  Ｒｅｌｅａｓｅを使用して終端交換４０１から切断する。アプリケーション２１４は、４２２でｏＤｉｓｃｏｎｎｅｃｔイベントを使用して通知され、これがアプリケーション２１４のトリガとなって最終的な評価を適用してコール詳細レコード（Ｃａｌｌ  Ｄｅｔａｉｌ  Ｒｅｃｏｒｄ）を生成する。アプリケーション２１４のコールインスタンスは、４２４でＭＳＣ  １１２にＣｏｎｔｉｎｕｅを送信して終了する。４２６で、ネットワークリソースの割り当てを解除する最後のＩＳＵＰリリースが実行される。
【００５１】
ここで図５を参照すると、ＩＳ  ８２６プロトコルを使用してモバイルハンドセットからコールを発信するシステム２００の動作の別の例がコールフロー図の５００に一般的に示されている。この例では、ルールエンジン２４０が使用されており、特定の場所からのコールが５０％値引きになる（ただし、コールの料金が１ドルを上回る場合にのみ）という特別な販売促進を定義している。この例は、ポストコール決定点を使用して実装される。
【００５２】
発信側のエンドユーザーは、値引きの対象となる場所にいる間にモバイルハンドセットを使用して終端交換４０１へのプリペイド無線コールを実行する。サービングＭＳＣ  １１２は、Ｏｒｉｇｉｎａｔｉｏｎ＿Ａｔｔｅｍｐｔ＿Ａｕｔｈｏｒｉｚｅｄ（ＯＲＲＥＱ）トリガを検出し、５０２でこのトリガに関連付けられたＳＣＰ  ２４０にＯＲＲＥＱを送信する。ＳＣＰ  ２４０には、ＭｉＬｉｆｅ（登録商標）  ＳｕｒｅＰａｙアプリケーション２１４が含まれる。ＳＣＰ  ２４０は、エンドユーザー２６４がプリペイドコールサービスに加入しており、加入者のアカウント残高がしきい値を超えていることを示すアクティブなプリペイドコールを備えていることを確認する。ＳＣＰ  ２４０は、５０４でコール処理が継続されることを示すｏｒｒｅｑをサービングＭＳＣ  １１２に送信する。
【００５３】
サービングＭＳＣ  １１２は、ダイヤルされた数字を分析し、コールのルーティングを準備する。サービングＭＳＣ  １１２は、Ｃａｌｌｉｎｇ＿Ｒｏｕｔｉｎｇ＿Ａｄｄｒｅｓｓ＿Ａｖａｉｌａｂｌｅトリガを検出し、このトリガに関連付けられたＳＣＰ  ２４０にＡＮＬＹＺＤを送信する。ＳＣＰ  ２４０は、５０８でサービングＭＳＣ  １１２にａｎｌｙｚｄを送信する。サービングＭＳＣ  １１２は、５１０でコールを拡張し（ｅｘｔｅｎｄｓ）、５１２で受信側からコールに応答が返される。
【００５４】
サービングＭＳＣ  １１２は、Ｏ＿Ａｎｓｗｅｒトリガを検出し、５１４でこのトリガに関連付けられたＳＣＰ  ２４０にＯＡＮＳＷＥＲを送信する。ＯＡＮＳＷＥＲを受信すると、ＳＣＰ  ２４０はコール開始時刻をセットし、コールの計時を開始する。コールはカットスルーされ（ｃｕｔ  ｔｈｒｏｕｇｈ）、接続される。
【００５５】
発信側がハングアップすると、５１６でサービングＭＳＣ  １１２はコールを終了する。サービングＭＳＣ  １１２は、Ｏ＿Ｄｉｓｃｏｎｎｅｃｔトリガを検出し、５１８でこのトリガに関連付けられたＳＣＰ  ２４０にＯＤＩＳＣＯＮＮＥＣＴを送信する。ＯＤＩＳＣＯＮＮＥＣＴを受信すると、ＳＣＰ  ２４０はコールの料金を計算する。アプリケーション２１４は、ローカルコンフィギュレーションデータをチェックして、この加入者のポストコール決定点がアクティブであることを確認する。コール料金は、このトリガがアクティブかどうかを判定するための追加の基準として使用される。コール料金が１ドルより少ない場合は、ルールエンジン２２０がトリガされない。
【００５６】
アプリケーション２１４は、コンフィギュレーションデータからルールセットＩＤと入力ＮＶＰリストを取得し、５２０でルールエンジン２２０に要求を送信する。ルールエンジン２２０は要求を受信し、入力ＮＶＰを抽出し、さらにルールセットＩＤで指定されたルールセットの実行を開始する。ルールセットは、加入者の位置に基づいてこのコールに特別な販売促進が適用されることを確認する。
【００５７】
ルールエンジン２２０は、５２２でコール料金の５０％を返金する“Ｂａｌａｎｃｅ  Ａｄｊｕｓｔｍｅｎｔ”アクションを含む出力ＮＶＰを含む応答をアプリケーション２１４に返送する。ＳＣＰ  ２４０は、５２４でサービングＭＳＣ  １１２にｏｄｉｓｃｏｎｎｅｃｔを送信し、５２６でサービングＭＳＣ  １１２はコールをリリースする。
【００５８】
以上の説明は、本発明の特定の実施形態の開示を提供するにすぎず、本発明を限定する意図はない。このように、本発明は前述の実施形態のみには限定されない。逆に、当業者は本発明の範囲を逸脱しない代替の実施形態を考案できると理解される。
【図面の簡単な説明】
【００５９】
【図１】本発明によるプリペイド／ポストペイド通信サービスを提供するシステムを示すブロック図である。
【図２】図１に示すシステムの無線通信ネットワークによる特定の例を示すブロック図である。
【図３】図２に示すシステムの動作方法を示す流れ図である。
【図４】図３および４に示すシステムおよび方法の１つの動作例を示すコールフロー図（ｃａｌｌ  ｆｌｏｗ  ｄｉａｇｒａｍ）である。
【図５】図３および４に示すシステムおよび方法の別の動作例を示すコールフロー図である。
【図１】
2009525689.tif 000003
【図２】
2009525689.tif 000004
【図３】
2009525689.tif 000005
【図４】
2009525689.tif 000006
【図５】
2009525689.tif 000007