レイティング通知方法及びシステム
本方法及びシステムは、通信システムのユーザに対して、レイティング通知を生成する。これは、料金表構造が検証され（１０１）、その検証中に、介在する状態に対して１つ以上の通知リクエストが検出される（１０２）。１つ以上の通知リクエストから得られる１つ以上の通知はユーザへ送信される（１０４、１０７）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の分野
本発明は、通信システムにおける課金システムに関するものであり、より詳しくは、通知をレイティングし、かつ通信システムのユーザにカスタマイズ可能でかつ柔軟な通知を提供する方法及びシステムに関するものである。
【０００２】
従来技術の説明
ＧＳＭあるいはＧＰＲＳ、公衆交換電気通信ネットワーク（ＰＴＳＮ）、ＩＳＤＮ、インターネット等の移動通信ネットワークの使用、及びそれらに関係するサービスの使用についての課金は、支払オプションあるいはメカニズムによって達成される。ポストペイド及びプリペイドオプションの両方が使用される。ポストペイドオプションを使用する場合、サービス加入者は、そのサービスを使用した後、例えば、１月に１回、サービスに対する支払を行う。プリペイド支払オプションを用いると、サービス加入者は、サービスを使用する前に支払を行う。
【０００３】
これらの支払オプションの両方は、リアルタイム課金を使用することができる。即ち、課金処理は、ユーザに対するサービスの提供の一部として実行される。ポストペイド支払オプションは、非リアルタイム課金もサポートする。即ち、課金処理が実行される場合には、その時点あるいはその後に、サービスが提供される。
【０００４】
購入時あるいは課金されるイベントが実行された後には、購入あるいはイベントに対する実際の費用をユーザに対して請求することは重要であり、この費用には、領収書として受け取られるディスカウント及びボーナスを含んでいる。市場の観点からは、ディスカウント及びボーナスは、ユーザに通知することなく与えられるべきでない。
【０００５】
オペレータは、一般的には、ユーザとの関係を改善するために、ユーザとの通信のより一層の柔軟性を要望していて、このことは、高度な電話通信が普及している十分に成長した市場における顧客の維持がかなり重要であることを反映するものである。
【０００６】
ユーザにとっては、消費制御を達成するために、購入を実行する前に、購入あるいは課金されるイベントの費用を把握することは重要である。費用の通知は、購入あるいは他の課金されるイベントが同意され受領される前の認可リクエストの一部として、あるいはオンデマンドでの価格照会として実行され得る。
【０００７】
既存のオンライン課金プロトコル、例えば、Ｄｉａｍｅｔｅｒ課金制御アプリケーション（ＣＣＡ）及びＰａｒｌａｙは、価格照会をサポートしている。つまり、このプロトコルは、クライアントシステムに対して、購入前に、課金サーバからの価格情報の提供のリクエストを提供する。
【０００８】
課金セッション中に、少なくとも１つの計算動作が実行される。つまり、価格の判定、金額に対して受けるサービス品質の決定、領収書解析（voucher analysis）での補充額の決定、プロモーション解析等の処理である。このような計算動作は、いくつかの状態を検出し、これは、計算される結果に影響を与える。
【０００９】
既存の課金システムでは、通知解析は、送信対象の標準的な通知がどれであるかを判定する課金されるセッションの最後に実現される。
【００１０】
従来システムにおける問題は、ユーザは、自身のサービスの使用を制御すること、例えば、上述の消費制御を行うことが制限されていることである。
【００１１】
別の問題は、計算動作は、計算される結果に影響を与えるいくつかの状態を検出するが、料金表（tariff：タリフ）構造を介する経路は、更なる解析に利用できない可能性があることである。
【００１２】
本発明の要約
本発明の目的は、通知をレイティングし、通信システムのユーザにカスタマイズ可能でかつ柔軟な通知を提供する方法を提供することであり、これは、上記の問題及び従来技術に関して説明される欠点を解消する。
【００１３】
この目的は、通信システムでリクエストされたサービスのユーザに対して、レイティング通知を生成する方法によって達成される。この方法では、料金表構造が検証され、その検証中に、計算される結果に作用する介在する状態に対して１つ以上の通知リクエストが検出される。１つ以上の通知リクエストから得られる１つ以上の通知はユーザへ送信される。
【００１４】
本発明のより特別な目的は、上記方法を実行するコンピュータプログラムを提供することである。
【００１５】
用語「備える／備えている」は、本明細書で使用される場合には、説明される特徴、整数値、ステップあるいはコンポーネントが存在することを特定するために用いられるが、１つ以上の他の特徴、整数値、ステップあるいはコンポーネントあるいはそれらのグループの存在あるいは追加を除外するものではないことが強調されるべきである。
【００１６】
本発明の詳細説明
図１を参照すると、通信ネットワークの一例が示されており、この通信ネットワークは、課金システム１を含んでいる。この課金システム１は、本発明に従うカスタマイズ可能で、かつ柔軟な通知、例えば、価格照会を、この課金システム１によって提供されるサービスのユーザに対して提供する。通信システムは、これに限定されるものではないが、例えば、セルラー移動電話ネットワークあるいはＰＬＭＮ（公衆地上移動ネットワーク）である。これは、ネットワークに接続される加入者に対してサービス配信を容易にするインテリジェントネットワーク（ＩＮ）のようなサービス提供ネットワークを含んでいる。本実施形態では、このネットワークは、また、プリペイ（pre-pay）オプションを提供し、かつ通信ネットワークの加入者に対するプリペイドサービスのレイティング（rating：格付け）データを判定する方法を提供する。プリペイオプションは、通信ネットワークのサービスに対する課金方法の一例であるだけで、このメカニズムは本発明に必須のものではない。ポストペイオプションあるいは他の課金方法を、本発明の範囲内で同様にして利用可能である。
【００１７】
ユーザは、いくつかのアクセス方法を介して、集中課金及びレイティング機能ＣＣＲＦを提供する課金システム１へアクセスすることができる。このアクセス方法は、図１を参照して更に説明される。課金システム１が、ポータブル無線通信機器２あるいは固定電話３のようなユーザ端末を介してアクセスされる場合、ポータブル無線通信機器２については中間ＭＳＣ／ＧＭＳＣ５／６を介して、また、固定電話３についてはサービス制御ポイントＳＣＰ８を介するローカル交換機（ＬＥ）を介して、サービススイッチングポイント（ＳＳＰ）４及び自身のサービススイッチング機能４’によってその起動が実行される。
【００１８】
ポータブル無線通信機器という用語は、以降では、移動電話と称するが、これは、例えば、ページャ、コミュニケータ、即ち、電子オーガナイザ、スマート電話あるいはその類のあらゆる機器を含んでいる。
【００１９】
ＧＭＳＣ５、即ち、ゲートウェイ移動サービススイッチング局あるいはＭＳＣ６、即ち、移動サービススイッチング局のみが、ネットワーク内の個々の移動電話２についての専用データを提供し、かつ、他のネットワークに向けてのインタフェースとして動作する。この他のネットワークには、例えば、通信システム内の、他のＰＬＭＮ、ＩＳＤＮあるいは、公衆交換ネットワーク（ＰＳＴＮ）がある。
【００２０】
課金システムが、ＧＰＲＳ機能を有する移動電話２’を介する使用によって起動される場合、ＧＳＮ１０は、ＳＣＰ８を介して、自身と一緒に位置するサービススイッチング機能（ＳＳＦ）１１によって課金システム１を直接起動することになる。ネットワークアクセスサーバ（ＮＡＳ）１５を介してデータ端末１４からアクセスされるインターネット１３に接続されるコンテンツサーバ（ＣＳ）１２でのサービス使用によって起動される場合、コンテンツサーバ（ＣＳ）１２は、インターネット１３のようなＴＣＰ／ＩＰネットワークを介して課金システム１へ直接アクセスすることができる。移動電話を介するアプリケーションサーバへのアクセスは、データ端末１４からアクセスする場合と同一の方法で動作する。ここで、ＧＳＮ１０は、ＮＡＳ１５として動作することになる。
【００２１】
本発明に従う課金システムは、カスタマイズ可能で、かつ柔軟な通知、例えば、価格照会に対する応答を、この通信システムによって提供されるサービスのユーザに対して提供する時に関与するシステムコンポーネントを含んでいる。このシステムは、計算動作中に発生するイベントについての情報を収集する手段を提供する。この計算動作には、予約のレイティング、値引きのレイティング、価格照会時のレイティングあるいは価格、ボーナス及びディスカウント、リアルタイムあるいはほぼリアルタイムでの補充額をユーザに通知するための補充時のレイティングがある。
【００２２】
ユーザに送信する通知は、結果として計算される価格のみに依存する必要はない。それゆえ、通知の内容は、最終費用に導く様々な状態に基づいて構成される。更には、例えば、照会、購入等の通知のコンテキストとしてのパラメータにも基づいて構成される。
【００２３】
これらの状態は、例えば、達成されるプロモーションレベル、達成されるボーナスレベル、ディスカウント用に十分な値引き額、より高いサービスクラスあるいはディスカウント用にする補充額とすることができる。また、これらの状態は、トラフィックを促進するための内容をユーザに通知することが有用となる動作をもたらすことができる。この内容は、例えば、「あなたは、３分間の通話によって３つのＳＭＳを無料で取得しているので、あなたは、もう３分間継続するならば３つの新規のＳＭＳを受信することになります」や「あなたが１００００ポイントに到達する場合には、あなたはベータゲームサイトへのフリーアクセスを得ることになります」がある。
【００２４】
計算中に検出されるどのイベントが即時通知を生成すべきであることを決定し、かつ予約計算、値引き計算あるいは価格計算中にどのイベントが遭遇するかを決定し、かつ計算機から、通知を発行する機能へイベントを送信するメカニズムが提供される。
【００２５】
ユーザにとっては、消費制御を達成するために、購入を実行する前に、購入あるいは課金されるイベントの費用を把握することは重要である。費用の通知は、購入が同意され受領される前の認可リクエストの一部として、あるいはオンデマンドでの価格照会として実行され得る。
【００２６】
図２は、いくつかのプロバイダを有する通信システムを示している。ＳＣＰ８はリアルタイムデータベース、かつサービス処理システムであり、これは、ＳＳＦ４’からの問い合わせに基づいて、加入者あるいはアプリケーション専用サービスロジックを実行し、呼セットアップ及び呼フローを制御する。ホームロケーションレジスタ（ＨＬＲ）１６は、ＰＬＭＮに属するすべての加入者のアイデンティティとユーザデータを記憶する。また、ＨＬＲ１６は、公衆交換ネットワーク（ＰＴＳＮ）、ＩＳＤＮネットワーク、インターネット等から呼が到来する場合に、必要な加入者データを、ＧＭＳＣ／ＭＳＣ／５／６に提供する。訪問先（visitor）ロケーションレジスタ（ＶＬＲ）１７は、在圏ＧＭＳＣ／ＭＳＣ／５／６内に現在位置しているあるいはローミングしているあらゆる移動電話の関連データを含んでいる。ＶＬＲ１７は、移動電話から呼が開始される場合に、呼確立中にＧＭＳＣ／ＭＳＣ／５／６をサポートしなければならない。課金システムは、サービスに対して必要なサービスデータを含むデータベースを含んでいて、これには、例えば、料金表データ、加入者データ、グループデータ等が含まれる。本実施形態では、レイティング及び課金解析は、課金システム１、ＳＣＰ８及びいくつかのプロバイダ１８の少なくともいずれかで処理される。このシステムは、インターネットネットプロトコルに基づく、プロトコル及び共通チャネルの少なくとも一方のシグナリングシステム１９の少なくとも一方である。
【００２７】
別の実施形態では、プロバイダ１８は、通信ネットワークのオペレータに関連する、レイティングデータ、プラン、アルゴリズムあるいはスキームに関してプロバイダとの完全性を有する分散レイティング機能を有している。プロバイダは、オペレータから物理的に分けることができる。オペレータとプロバイダ（群）はそれぞれ自身のドメインを制御する。また、これらは、同一あるいは異なる国に位置することができる。また、オペレータとプロバイダ（群）はそれぞれ、自身の所有データを所有し、記憶し、制御する。ここで、オペレータによって制御されるデータはプロバイダからのアクセスが保護され、また、その逆も同様である。例示のように、ユーザは、リモートレイティングに対する基礎、例えば、ディスカウントについて通知される。
【００２８】
本発明の実施形態では、通知オブジェクトは、料金表構造の一部となっている。つまり、料金表構造は、価格及び通知用のオブジェクトの両方あるいは少なくとも一方を導く状態を持っている。各通知オブジェクトは、ユーザに直接送信されるために、あるいは次の処理用に収集されるために、タグが付けられる。ここで、これについては後述する。レイティング構造が検証され、価格が設定される場合、後処理が実行される。これは、制御される通知オブジェクト群に基づく複合通知を構築する。
【００２９】
図３は、レイティング用の解析構造、即ち、明示的に通知を起動するレイティング構造の一部の例である。通知の中で使用対象のデータは、通知オブジェクト内に記憶する、あるいは参照することができる。状態、即ち、料金表構造内のノードは、レイティング、プロモーションあるいは、時間、日、位置、呼のタイプ等の累積器（accumulator）のために実現されるものの１つとすることができる。更に区別する追加の状態は、例えば、次のものがある。
【００３０】
アクションは、照会、購入、予約、セッション制御の終了に対応する。
【００３１】
通知リクエストは、可能であれば、レート、料金あるいはディスカウントとともに、リーフとして料金表構造内に入力される。図３に示されるように、いくつなのノードが同一の状態下にある場合、通知リクエストは、その状態を発生するイベントからの別リーフに定義することができる。
【００３２】
料金表構造中、例えば、料金表ツリー中には、その構造のいくつかの解析ブランチを入力することができる。即ち、いくつかの状態は真となり、かついくつかのリーフは有効とすることができる。これを実行することは、解析毎のいくつかの通知オブジェクトは有効とする、例えば、受け取るボーナス、総費用等とすることができることを意味する。
【００３３】
１つの通知オブジェクトの検出は、他の通知とは独立して実行することができるので、検出された通知のすべての最終的な解析が必要とされる。本発明の実施形態では、この解析は、出力されるレイティング構造の決定を取得するために、ブール条件及びＩＦ文で構築される。この例は、予約が空の状態のアカウントを作成することであり、これは、保留中の通知がこれに対して起動される。解析後には、ユーザが返金／ボーナス／ディスカウントについて直面すること、また、初期要求／リクエストを満足する金額が返済されるべきであることが検出される。新規の通知は、返金／ボーナス／ディスカウントに対しては保留され、また、最終解析は、空のアカウントに対して保留している通知は削除することになる。
【００３４】
加えて、通知をリクエストするためには、レイティングのリーフは、専用の通知用の抑制状態に入ることもできる。この専用の通知は、例えば、「この呼（call：通話）ではボーナス通知は送信しない」あるいは「解析の終了時にボーナス通知を送信する」ことの許可がある。このことは、「複合」通知が、個々のイベント／状態の即時通知の代わりに使用される場合に使用することができ、また、可能なタイプのイベントからの即時通知を防止するために料金表構造内に入れることもできる。解析後には、例えば、「ボーナスについての即時通知は実行しない」及び「即時通知は実行しない」ことを検出することができる。
【００３５】
いくつかのレイティング起動の間での相関については、各アクティブな／受け入れられた／決定された通知リクエストは、通知リファレンスを取得することができる。通知リファレンスは、ダイアログあるいはユーザ対話フローとすることができる。このユーザ対話フローは、例えば、購入時の消費制御用に「購入検証用にＰＩＮを取得する」あるいは単なる「確認の取得」がある。これらのリファレンスは、サブルーチンとしてコールすることができる。
【００３６】
このデータが新規のセッション内の課金入力として入力される場合、課金されるセッション（呼（通話）あるいはアクティブなデータセッション）中で起動されているものの間での相関を取ることができ、これは、課金されるセッション内の矛盾を防止する。
【００３７】
図４は、通知のレイティングを行い、通信システムにおけるユーザにカスタマイズ可能でかつ柔軟な通知を提供する、本発明に従う第１実施形態の方法のフローチャートである。
【００３８】
ステップ１００で、課金及びレイティング機能が、ユーザ自身の移動電話２、２’、固定電話３あるいはデータ端末１４を介するユーザからのリクエストによって起動され、ステップ１０１へ進み、図４の料金表構造を検証し、一方で、購入あるいは課金されるイベントの費用を計算する。ここで、ステップ１０１は、１つ以上のサブステップを含んでいるが、そのすべてについては本明細書では詳細に説明しない。集中課金及びレイティング機能ＣＣＲＦは、課金入力パラメータあるいはデータを収集あるいはアクセスする。これには、例えば、サービスデータ、加入者関連データ、セッションデータ、呼データ、システムデータ等があり、加入者によってリクエストされるサービスの外部サービス要素から受信される。
【００３９】
リクエストされるサービスの一例は、ＰＬＭＮ内のプリペイ加入者からの通常の電話呼に対する消費制御である。加入者は、サービスプロバイダにおける１つ以上のサービスに対して登録されているアカウントを持っている。サービス要素は、例えば、ＣＡＰあるいはＩＮＡＰを介するＳＳＦ、ＭＡＰを介するＨＬＲ、ＨＳＳ（ホーム加入者サブシステム）及びＤｉａｍｅｔｅｒを介するウェブサーバ／アプリケーションサーバ、ＳＩＰ、ＩＰを介するオープンＡＰＩ、即ち、ＯＡＳ／Ｐａｒｌａｙ、ＳＯＡＰを介するＸＭＬウェブサービスあるいは課金サポートを必要とするアプリケーションを有する任意の他のサーバ、例えば、ストリーミング用のイーコマースサイトムービー／ミュージックサーバ、ニュースサイト、ＷＡＰサーバあるいはＳＭＳＣ／ＭＭＣ−Ｃがある。課金入力パラメータは、例えば、記事（article）識別子、イベント数、イベント種、サービス、ローカルタイム、宛先番号発信あるいは着信位置、距離、ＱｏＳ、タイムスロット数、あるいは利用容量等がある。
【００４０】
ステップ１０２で、通知リクエストを有するリーフが検出される。ステップ１０３で、表示用のユーザ端末２、２’、３、１４に直接通知を送信するべきかを判定するための解析が実行される、あるいは後解析用に通知を収集するための解析が実行される。通知が直接送信されるべきであると判定される場合、ステップ１０４で、リクエストされたコンテンツ（内容）でリクエストされた端末に通知が発行される。別の実施形態では、通知は、課金されるセッションに関係する端末以外の別の宛先に送信することができる。
【００４１】
ステップ１０１−１０４は、料金表構造が検証されるまで繰り返される。収集された通知が存在しない場合、本方法は終了し、別の課金リクエスト用にリセットされる。
【００４２】
図５は、本発明に従う方法の第２実施形態のフローチャートである。１つ以上の通知が後解析用に収集される場合、ステップ１０５で、すべての未送信の通知が送信対象であるかを判定するために解析される。必要であれば、ステップ１０６で、メッセージはマージされても良い。異なる通知をどのようにして互いに作用させるかを判定するためにルールエンジンを使用することができる。ステップ１０７で、メッセージ（群）が送信され、本方法は終了し、別の課金リクエスト用にリセットされる。
【００４３】
このシーケンスは、別のボーナス解析とともに、あるいは累積器による選択解析（accumulator selection analysis）で実行することもできる。但し、これの意図は、１つの構造で全体解析を行うことである。
【００４４】
ここで、レイティング解析／処理からの内部あるいは外部通知あるいはダイアログリクエストを起動する可能性が提供される。この解析は、セッション／呼／購入前、中あるいは後、補充前、中あるいは後等の照会時に実行される。
【００４５】
通知機能の１つの特定の用途は価格照会に対するものであるが、本発明はこれに限定されるものではない。
【００４６】
別の実施形態では、料金表構造では通知トリガーは定義されない。その代わり、検証中に補充されるすべての状態がログとして出力され、これは、実行されたレイティングを解析し、対応する通知を生成するために、別の処理によって次のステップで実行することができる。
【００４７】
更に別の実施形態では、補充される（／補充されない）各レイティング状態が、外部通知処理に信号として送信される。この処理は、信号を解析して、どのような通知とするか／通知とするべきであるかを判定することができる。状態は、いまだ遭遇していない即時通知イベントの抑制を受ける可能性もある。
【００４８】
本発明の方法は、通信システム全体の一部を形成するデータ処理システムによって実行可能なコンピュータソフトウェアで実現されることが好ましい。本発明の実施形態では、ネットワークのオペレータのコンピュータプロセッサは、本方法のステップを実行するように構成される。
【００４９】
ここで、本発明が、電子通信ネットワーク内で使用するために改良された方法及びシステムを提供することは明らかであろう。この方法及びシステムは、レイティング及び課金メカニズムを備える。このメカニズムは、通知のレイティングを行い、通信システムのユーザにカスタマイズ可能でかつ柔軟な通知を提供することを提供する。これは、上述の目的及び効果を十分に満足する。
【００５０】
本発明はその特定の実施形態で説明されているが、本発明は、様々な形態の実施形態も可能である。これには、本発明の開示は、本発明の基本的な例示として考慮されるべきであり、かつ図示される特定の実施形態に本発明を制限することを意図しているものでないという理解が伴っている。
【００５１】
本発明は、リアルタイムレイティングを利用する、前払い（プリペイ）（ネットワーク）オペレータあるいは後払い（ポストペイ）（ネットワーク）オペレータ、あるいは、サービスあるいはコンテンツ用の任意のプロバイダに対して、レイティング解析中に遭遇し、かつレイティング結果に作用するイベント及び状態に依存する通知及びダイアログリクエストを起動することを可能にする。１つ以上のいくつかの通知オブジェクト（起動された通知）は、レイティング解析毎に検出することができる。この通知オブジェクトは、レイティングロジックあるいはレイティング機能以外で直ちに解析することができる。ここで、１つのレイティング解析に対するイベントのすべてを、いくつかをフィルタ対象とするために合同解析用に収集することができる、あるいはセッションを終了するために収集することができる。このセッションの終了では、どれらあるいはどれが送信するものであるかが解析される。
【００５２】
本発明の方法は、通信システム全体の一部を形成する分散データ処理システムによって実行可能なコンピュータソフトウェアでも実現することもできる。
【００５３】
より詳しくは、オペレータとプロバイダは、別々のデータ処理システムを形成する、あるいはネットワークの通信システム内の他の装置、コンポーネントあるいはデータ処理システム（群）と通信するための通信システム全体のサブシステムである。データ処理システムは、オペレータ及び各プロバイダドメイン内でデータを処理するためのコンピュータプロセッサと、記憶媒体上にデータを記憶するための、各コンピュータプロセッサに接続されている少なくとも１つの記憶装置を備える。本発明の実施形態では、ネットワークのオペレータのコンピュータプロセッサは、オペレータドメイン内で実行される方法のステップを実行するように構成されている。ネットワークのプロバイダのコンピュータプロセッサは、プロバイダドメイン内で実行される方法の課金ステップを実行するように構成されている。
【００５４】
加えて、本発明は、本発明を実現するように適合されるプログラムあるいはキャリヤに拡張される。このプログラムは、ソースコード、オブジェクトコード、本発明に従う方法の実装に使用するのに適しているコードの形態であっても良い。キャリヤは、プログラムを搬送することができる任意のエンティティあるいは装置であっても良い。例えば、キャリヤは、記録媒体、コンピュータメモリ、リードオンリメモリあるいは電気キャリヤ信号であっても良い。
【００５５】
本方法は、インテリジェント／ＣＡＭＥＬネットワークあるいはインターネットプロトコル内の移動電話の呼（call）を用いて説明しているが、本方法は、任意の通信セッションにも適用することができる。例えば、本発明に従う方法及びシステムは、他の移動電話ネットワーク、公衆交換電気通信ネットワーク（ＰＳＴＮ）、ＩＳＤＮ、インターネット、サービスネットワーク等に適用可能である。これらは、ユーザ及びプロバイダ用の多かれ少なかれ洗練された様々な種類の電気データ通信サービスを提供するものである。
【図面の簡単な説明】
【００５６】
【図１】本発明に従う集中課金システムを含む通信ネットワークの第１実施形態を示す図である。
【図２】本発明に従う集中課金システムを含む通信ネットワークの第２実施形態を示す図である。
【図３】図１のシステムの集中課金機能の解析構造の一部を示す図である。
【図４】本発明に従う方法の第１実施形態のフローチャートである。
【図５】本発明に従う方法の第２実施形態のフローチャートである。
【技術分野】
【０００１】
本発明の分野
本発明は、通信システムにおける課金システムに関するものであり、より詳しくは、通知をレイティングし、かつ通信システムのユーザにカスタマイズ可能でかつ柔軟な通知を提供する方法及びシステムに関するものである。
【０００２】
従来技術の説明
ＧＳＭあるいはＧＰＲＳ、公衆交換電気通信ネットワーク（ＰＴＳＮ）、ＩＳＤＮ、インターネット等の移動通信ネットワークの使用、及びそれらに関係するサービスの使用についての課金は、支払オプションあるいはメカニズムによって達成される。ポストペイド及びプリペイドオプションの両方が使用される。ポストペイドオプションを使用する場合、サービス加入者は、そのサービスを使用した後、例えば、１月に１回、サービスに対する支払を行う。プリペイド支払オプションを用いると、サービス加入者は、サービスを使用する前に支払を行う。
【０００３】
これらの支払オプションの両方は、リアルタイム課金を使用することができる。即ち、課金処理は、ユーザに対するサービスの提供の一部として実行される。ポストペイド支払オプションは、非リアルタイム課金もサポートする。即ち、課金処理が実行される場合には、その時点あるいはその後に、サービスが提供される。
【０００４】
購入時あるいは課金されるイベントが実行された後には、購入あるいはイベントに対する実際の費用をユーザに対して請求することは重要であり、この費用には、領収書として受け取られるディスカウント及びボーナスを含んでいる。市場の観点からは、ディスカウント及びボーナスは、ユーザに通知することなく与えられるべきでない。
【０００５】
オペレータは、一般的には、ユーザとの関係を改善するために、ユーザとの通信のより一層の柔軟性を要望していて、このことは、高度な電話通信が普及している十分に成長した市場における顧客の維持がかなり重要であることを反映するものである。
【０００６】
ユーザにとっては、消費制御を達成するために、購入を実行する前に、購入あるいは課金されるイベントの費用を把握することは重要である。費用の通知は、購入あるいは他の課金されるイベントが同意され受領される前の認可リクエストの一部として、あるいはオンデマンドでの価格照会として実行され得る。
【０００７】
既存のオンライン課金プロトコル、例えば、Ｄｉａｍｅｔｅｒ課金制御アプリケーション（ＣＣＡ）及びＰａｒｌａｙは、価格照会をサポートしている。つまり、このプロトコルは、クライアントシステムに対して、購入前に、課金サーバからの価格情報の提供のリクエストを提供する。
【０００８】
課金セッション中に、少なくとも１つの計算動作が実行される。つまり、価格の判定、金額に対して受けるサービス品質の決定、領収書解析（voucher analysis）での補充額の決定、プロモーション解析等の処理である。このような計算動作は、いくつかの状態を検出し、これは、計算される結果に影響を与える。
【０００９】
既存の課金システムでは、通知解析は、送信対象の標準的な通知がどれであるかを判定する課金されるセッションの最後に実現される。
【００１０】
従来システムにおける問題は、ユーザは、自身のサービスの使用を制御すること、例えば、上述の消費制御を行うことが制限されていることである。
【００１１】
別の問題は、計算動作は、計算される結果に影響を与えるいくつかの状態を検出するが、料金表（tariff：タリフ）構造を介する経路は、更なる解析に利用できない可能性があることである。
【００１２】
本発明の要約
本発明の目的は、通知をレイティングし、通信システムのユーザにカスタマイズ可能でかつ柔軟な通知を提供する方法を提供することであり、これは、上記の問題及び従来技術に関して説明される欠点を解消する。
【００１３】
この目的は、通信システムでリクエストされたサービスのユーザに対して、レイティング通知を生成する方法によって達成される。この方法では、料金表構造が検証され、その検証中に、計算される結果に作用する介在する状態に対して１つ以上の通知リクエストが検出される。１つ以上の通知リクエストから得られる１つ以上の通知はユーザへ送信される。
【００１４】
本発明のより特別な目的は、上記方法を実行するコンピュータプログラムを提供することである。
【００１５】
用語「備える／備えている」は、本明細書で使用される場合には、説明される特徴、整数値、ステップあるいはコンポーネントが存在することを特定するために用いられるが、１つ以上の他の特徴、整数値、ステップあるいはコンポーネントあるいはそれらのグループの存在あるいは追加を除外するものではないことが強調されるべきである。
【００１６】
本発明の詳細説明
図１を参照すると、通信ネットワークの一例が示されており、この通信ネットワークは、課金システム１を含んでいる。この課金システム１は、本発明に従うカスタマイズ可能で、かつ柔軟な通知、例えば、価格照会を、この課金システム１によって提供されるサービスのユーザに対して提供する。通信システムは、これに限定されるものではないが、例えば、セルラー移動電話ネットワークあるいはＰＬＭＮ（公衆地上移動ネットワーク）である。これは、ネットワークに接続される加入者に対してサービス配信を容易にするインテリジェントネットワーク（ＩＮ）のようなサービス提供ネットワークを含んでいる。本実施形態では、このネットワークは、また、プリペイ（pre-pay）オプションを提供し、かつ通信ネットワークの加入者に対するプリペイドサービスのレイティング（rating：格付け）データを判定する方法を提供する。プリペイオプションは、通信ネットワークのサービスに対する課金方法の一例であるだけで、このメカニズムは本発明に必須のものではない。ポストペイオプションあるいは他の課金方法を、本発明の範囲内で同様にして利用可能である。
【００１７】
ユーザは、いくつかのアクセス方法を介して、集中課金及びレイティング機能ＣＣＲＦを提供する課金システム１へアクセスすることができる。このアクセス方法は、図１を参照して更に説明される。課金システム１が、ポータブル無線通信機器２あるいは固定電話３のようなユーザ端末を介してアクセスされる場合、ポータブル無線通信機器２については中間ＭＳＣ／ＧＭＳＣ５／６を介して、また、固定電話３についてはサービス制御ポイントＳＣＰ８を介するローカル交換機（ＬＥ）を介して、サービススイッチングポイント（ＳＳＰ）４及び自身のサービススイッチング機能４’によってその起動が実行される。
【００１８】
ポータブル無線通信機器という用語は、以降では、移動電話と称するが、これは、例えば、ページャ、コミュニケータ、即ち、電子オーガナイザ、スマート電話あるいはその類のあらゆる機器を含んでいる。
【００１９】
ＧＭＳＣ５、即ち、ゲートウェイ移動サービススイッチング局あるいはＭＳＣ６、即ち、移動サービススイッチング局のみが、ネットワーク内の個々の移動電話２についての専用データを提供し、かつ、他のネットワークに向けてのインタフェースとして動作する。この他のネットワークには、例えば、通信システム内の、他のＰＬＭＮ、ＩＳＤＮあるいは、公衆交換ネットワーク（ＰＳＴＮ）がある。
【００２０】
課金システムが、ＧＰＲＳ機能を有する移動電話２’を介する使用によって起動される場合、ＧＳＮ１０は、ＳＣＰ８を介して、自身と一緒に位置するサービススイッチング機能（ＳＳＦ）１１によって課金システム１を直接起動することになる。ネットワークアクセスサーバ（ＮＡＳ）１５を介してデータ端末１４からアクセスされるインターネット１３に接続されるコンテンツサーバ（ＣＳ）１２でのサービス使用によって起動される場合、コンテンツサーバ（ＣＳ）１２は、インターネット１３のようなＴＣＰ／ＩＰネットワークを介して課金システム１へ直接アクセスすることができる。移動電話を介するアプリケーションサーバへのアクセスは、データ端末１４からアクセスする場合と同一の方法で動作する。ここで、ＧＳＮ１０は、ＮＡＳ１５として動作することになる。
【００２１】
本発明に従う課金システムは、カスタマイズ可能で、かつ柔軟な通知、例えば、価格照会に対する応答を、この通信システムによって提供されるサービスのユーザに対して提供する時に関与するシステムコンポーネントを含んでいる。このシステムは、計算動作中に発生するイベントについての情報を収集する手段を提供する。この計算動作には、予約のレイティング、値引きのレイティング、価格照会時のレイティングあるいは価格、ボーナス及びディスカウント、リアルタイムあるいはほぼリアルタイムでの補充額をユーザに通知するための補充時のレイティングがある。
【００２２】
ユーザに送信する通知は、結果として計算される価格のみに依存する必要はない。それゆえ、通知の内容は、最終費用に導く様々な状態に基づいて構成される。更には、例えば、照会、購入等の通知のコンテキストとしてのパラメータにも基づいて構成される。
【００２３】
これらの状態は、例えば、達成されるプロモーションレベル、達成されるボーナスレベル、ディスカウント用に十分な値引き額、より高いサービスクラスあるいはディスカウント用にする補充額とすることができる。また、これらの状態は、トラフィックを促進するための内容をユーザに通知することが有用となる動作をもたらすことができる。この内容は、例えば、「あなたは、３分間の通話によって３つのＳＭＳを無料で取得しているので、あなたは、もう３分間継続するならば３つの新規のＳＭＳを受信することになります」や「あなたが１００００ポイントに到達する場合には、あなたはベータゲームサイトへのフリーアクセスを得ることになります」がある。
【００２４】
計算中に検出されるどのイベントが即時通知を生成すべきであることを決定し、かつ予約計算、値引き計算あるいは価格計算中にどのイベントが遭遇するかを決定し、かつ計算機から、通知を発行する機能へイベントを送信するメカニズムが提供される。
【００２５】
ユーザにとっては、消費制御を達成するために、購入を実行する前に、購入あるいは課金されるイベントの費用を把握することは重要である。費用の通知は、購入が同意され受領される前の認可リクエストの一部として、あるいはオンデマンドでの価格照会として実行され得る。
【００２６】
図２は、いくつかのプロバイダを有する通信システムを示している。ＳＣＰ８はリアルタイムデータベース、かつサービス処理システムであり、これは、ＳＳＦ４’からの問い合わせに基づいて、加入者あるいはアプリケーション専用サービスロジックを実行し、呼セットアップ及び呼フローを制御する。ホームロケーションレジスタ（ＨＬＲ）１６は、ＰＬＭＮに属するすべての加入者のアイデンティティとユーザデータを記憶する。また、ＨＬＲ１６は、公衆交換ネットワーク（ＰＴＳＮ）、ＩＳＤＮネットワーク、インターネット等から呼が到来する場合に、必要な加入者データを、ＧＭＳＣ／ＭＳＣ／５／６に提供する。訪問先（visitor）ロケーションレジスタ（ＶＬＲ）１７は、在圏ＧＭＳＣ／ＭＳＣ／５／６内に現在位置しているあるいはローミングしているあらゆる移動電話の関連データを含んでいる。ＶＬＲ１７は、移動電話から呼が開始される場合に、呼確立中にＧＭＳＣ／ＭＳＣ／５／６をサポートしなければならない。課金システムは、サービスに対して必要なサービスデータを含むデータベースを含んでいて、これには、例えば、料金表データ、加入者データ、グループデータ等が含まれる。本実施形態では、レイティング及び課金解析は、課金システム１、ＳＣＰ８及びいくつかのプロバイダ１８の少なくともいずれかで処理される。このシステムは、インターネットネットプロトコルに基づく、プロトコル及び共通チャネルの少なくとも一方のシグナリングシステム１９の少なくとも一方である。
【００２７】
別の実施形態では、プロバイダ１８は、通信ネットワークのオペレータに関連する、レイティングデータ、プラン、アルゴリズムあるいはスキームに関してプロバイダとの完全性を有する分散レイティング機能を有している。プロバイダは、オペレータから物理的に分けることができる。オペレータとプロバイダ（群）はそれぞれ自身のドメインを制御する。また、これらは、同一あるいは異なる国に位置することができる。また、オペレータとプロバイダ（群）はそれぞれ、自身の所有データを所有し、記憶し、制御する。ここで、オペレータによって制御されるデータはプロバイダからのアクセスが保護され、また、その逆も同様である。例示のように、ユーザは、リモートレイティングに対する基礎、例えば、ディスカウントについて通知される。
【００２８】
本発明の実施形態では、通知オブジェクトは、料金表構造の一部となっている。つまり、料金表構造は、価格及び通知用のオブジェクトの両方あるいは少なくとも一方を導く状態を持っている。各通知オブジェクトは、ユーザに直接送信されるために、あるいは次の処理用に収集されるために、タグが付けられる。ここで、これについては後述する。レイティング構造が検証され、価格が設定される場合、後処理が実行される。これは、制御される通知オブジェクト群に基づく複合通知を構築する。
【００２９】
図３は、レイティング用の解析構造、即ち、明示的に通知を起動するレイティング構造の一部の例である。通知の中で使用対象のデータは、通知オブジェクト内に記憶する、あるいは参照することができる。状態、即ち、料金表構造内のノードは、レイティング、プロモーションあるいは、時間、日、位置、呼のタイプ等の累積器（accumulator）のために実現されるものの１つとすることができる。更に区別する追加の状態は、例えば、次のものがある。
【００３０】
アクションは、照会、購入、予約、セッション制御の終了に対応する。
【００３１】
通知リクエストは、可能であれば、レート、料金あるいはディスカウントとともに、リーフとして料金表構造内に入力される。図３に示されるように、いくつなのノードが同一の状態下にある場合、通知リクエストは、その状態を発生するイベントからの別リーフに定義することができる。
【００３２】
料金表構造中、例えば、料金表ツリー中には、その構造のいくつかの解析ブランチを入力することができる。即ち、いくつかの状態は真となり、かついくつかのリーフは有効とすることができる。これを実行することは、解析毎のいくつかの通知オブジェクトは有効とする、例えば、受け取るボーナス、総費用等とすることができることを意味する。
【００３３】
１つの通知オブジェクトの検出は、他の通知とは独立して実行することができるので、検出された通知のすべての最終的な解析が必要とされる。本発明の実施形態では、この解析は、出力されるレイティング構造の決定を取得するために、ブール条件及びＩＦ文で構築される。この例は、予約が空の状態のアカウントを作成することであり、これは、保留中の通知がこれに対して起動される。解析後には、ユーザが返金／ボーナス／ディスカウントについて直面すること、また、初期要求／リクエストを満足する金額が返済されるべきであることが検出される。新規の通知は、返金／ボーナス／ディスカウントに対しては保留され、また、最終解析は、空のアカウントに対して保留している通知は削除することになる。
【００３４】
加えて、通知をリクエストするためには、レイティングのリーフは、専用の通知用の抑制状態に入ることもできる。この専用の通知は、例えば、「この呼（call：通話）ではボーナス通知は送信しない」あるいは「解析の終了時にボーナス通知を送信する」ことの許可がある。このことは、「複合」通知が、個々のイベント／状態の即時通知の代わりに使用される場合に使用することができ、また、可能なタイプのイベントからの即時通知を防止するために料金表構造内に入れることもできる。解析後には、例えば、「ボーナスについての即時通知は実行しない」及び「即時通知は実行しない」ことを検出することができる。
【００３５】
いくつかのレイティング起動の間での相関については、各アクティブな／受け入れられた／決定された通知リクエストは、通知リファレンスを取得することができる。通知リファレンスは、ダイアログあるいはユーザ対話フローとすることができる。このユーザ対話フローは、例えば、購入時の消費制御用に「購入検証用にＰＩＮを取得する」あるいは単なる「確認の取得」がある。これらのリファレンスは、サブルーチンとしてコールすることができる。
【００３６】
このデータが新規のセッション内の課金入力として入力される場合、課金されるセッション（呼（通話）あるいはアクティブなデータセッション）中で起動されているものの間での相関を取ることができ、これは、課金されるセッション内の矛盾を防止する。
【００３７】
図４は、通知のレイティングを行い、通信システムにおけるユーザにカスタマイズ可能でかつ柔軟な通知を提供する、本発明に従う第１実施形態の方法のフローチャートである。
【００３８】
ステップ１００で、課金及びレイティング機能が、ユーザ自身の移動電話２、２’、固定電話３あるいはデータ端末１４を介するユーザからのリクエストによって起動され、ステップ１０１へ進み、図４の料金表構造を検証し、一方で、購入あるいは課金されるイベントの費用を計算する。ここで、ステップ１０１は、１つ以上のサブステップを含んでいるが、そのすべてについては本明細書では詳細に説明しない。集中課金及びレイティング機能ＣＣＲＦは、課金入力パラメータあるいはデータを収集あるいはアクセスする。これには、例えば、サービスデータ、加入者関連データ、セッションデータ、呼データ、システムデータ等があり、加入者によってリクエストされるサービスの外部サービス要素から受信される。
【００３９】
リクエストされるサービスの一例は、ＰＬＭＮ内のプリペイ加入者からの通常の電話呼に対する消費制御である。加入者は、サービスプロバイダにおける１つ以上のサービスに対して登録されているアカウントを持っている。サービス要素は、例えば、ＣＡＰあるいはＩＮＡＰを介するＳＳＦ、ＭＡＰを介するＨＬＲ、ＨＳＳ（ホーム加入者サブシステム）及びＤｉａｍｅｔｅｒを介するウェブサーバ／アプリケーションサーバ、ＳＩＰ、ＩＰを介するオープンＡＰＩ、即ち、ＯＡＳ／Ｐａｒｌａｙ、ＳＯＡＰを介するＸＭＬウェブサービスあるいは課金サポートを必要とするアプリケーションを有する任意の他のサーバ、例えば、ストリーミング用のイーコマースサイトムービー／ミュージックサーバ、ニュースサイト、ＷＡＰサーバあるいはＳＭＳＣ／ＭＭＣ−Ｃがある。課金入力パラメータは、例えば、記事（article）識別子、イベント数、イベント種、サービス、ローカルタイム、宛先番号発信あるいは着信位置、距離、ＱｏＳ、タイムスロット数、あるいは利用容量等がある。
【００４０】
ステップ１０２で、通知リクエストを有するリーフが検出される。ステップ１０３で、表示用のユーザ端末２、２’、３、１４に直接通知を送信するべきかを判定するための解析が実行される、あるいは後解析用に通知を収集するための解析が実行される。通知が直接送信されるべきであると判定される場合、ステップ１０４で、リクエストされたコンテンツ（内容）でリクエストされた端末に通知が発行される。別の実施形態では、通知は、課金されるセッションに関係する端末以外の別の宛先に送信することができる。
【００４１】
ステップ１０１−１０４は、料金表構造が検証されるまで繰り返される。収集された通知が存在しない場合、本方法は終了し、別の課金リクエスト用にリセットされる。
【００４２】
図５は、本発明に従う方法の第２実施形態のフローチャートである。１つ以上の通知が後解析用に収集される場合、ステップ１０５で、すべての未送信の通知が送信対象であるかを判定するために解析される。必要であれば、ステップ１０６で、メッセージはマージされても良い。異なる通知をどのようにして互いに作用させるかを判定するためにルールエンジンを使用することができる。ステップ１０７で、メッセージ（群）が送信され、本方法は終了し、別の課金リクエスト用にリセットされる。
【００４３】
このシーケンスは、別のボーナス解析とともに、あるいは累積器による選択解析（accumulator selection analysis）で実行することもできる。但し、これの意図は、１つの構造で全体解析を行うことである。
【００４４】
ここで、レイティング解析／処理からの内部あるいは外部通知あるいはダイアログリクエストを起動する可能性が提供される。この解析は、セッション／呼／購入前、中あるいは後、補充前、中あるいは後等の照会時に実行される。
【００４５】
通知機能の１つの特定の用途は価格照会に対するものであるが、本発明はこれに限定されるものではない。
【００４６】
別の実施形態では、料金表構造では通知トリガーは定義されない。その代わり、検証中に補充されるすべての状態がログとして出力され、これは、実行されたレイティングを解析し、対応する通知を生成するために、別の処理によって次のステップで実行することができる。
【００４７】
更に別の実施形態では、補充される（／補充されない）各レイティング状態が、外部通知処理に信号として送信される。この処理は、信号を解析して、どのような通知とするか／通知とするべきであるかを判定することができる。状態は、いまだ遭遇していない即時通知イベントの抑制を受ける可能性もある。
【００４８】
本発明の方法は、通信システム全体の一部を形成するデータ処理システムによって実行可能なコンピュータソフトウェアで実現されることが好ましい。本発明の実施形態では、ネットワークのオペレータのコンピュータプロセッサは、本方法のステップを実行するように構成される。
【００４９】
ここで、本発明が、電子通信ネットワーク内で使用するために改良された方法及びシステムを提供することは明らかであろう。この方法及びシステムは、レイティング及び課金メカニズムを備える。このメカニズムは、通知のレイティングを行い、通信システムのユーザにカスタマイズ可能でかつ柔軟な通知を提供することを提供する。これは、上述の目的及び効果を十分に満足する。
【００５０】
本発明はその特定の実施形態で説明されているが、本発明は、様々な形態の実施形態も可能である。これには、本発明の開示は、本発明の基本的な例示として考慮されるべきであり、かつ図示される特定の実施形態に本発明を制限することを意図しているものでないという理解が伴っている。
【００５１】
本発明は、リアルタイムレイティングを利用する、前払い（プリペイ）（ネットワーク）オペレータあるいは後払い（ポストペイ）（ネットワーク）オペレータ、あるいは、サービスあるいはコンテンツ用の任意のプロバイダに対して、レイティング解析中に遭遇し、かつレイティング結果に作用するイベント及び状態に依存する通知及びダイアログリクエストを起動することを可能にする。１つ以上のいくつかの通知オブジェクト（起動された通知）は、レイティング解析毎に検出することができる。この通知オブジェクトは、レイティングロジックあるいはレイティング機能以外で直ちに解析することができる。ここで、１つのレイティング解析に対するイベントのすべてを、いくつかをフィルタ対象とするために合同解析用に収集することができる、あるいはセッションを終了するために収集することができる。このセッションの終了では、どれらあるいはどれが送信するものであるかが解析される。
【００５２】
本発明の方法は、通信システム全体の一部を形成する分散データ処理システムによって実行可能なコンピュータソフトウェアでも実現することもできる。
【００５３】
より詳しくは、オペレータとプロバイダは、別々のデータ処理システムを形成する、あるいはネットワークの通信システム内の他の装置、コンポーネントあるいはデータ処理システム（群）と通信するための通信システム全体のサブシステムである。データ処理システムは、オペレータ及び各プロバイダドメイン内でデータを処理するためのコンピュータプロセッサと、記憶媒体上にデータを記憶するための、各コンピュータプロセッサに接続されている少なくとも１つの記憶装置を備える。本発明の実施形態では、ネットワークのオペレータのコンピュータプロセッサは、オペレータドメイン内で実行される方法のステップを実行するように構成されている。ネットワークのプロバイダのコンピュータプロセッサは、プロバイダドメイン内で実行される方法の課金ステップを実行するように構成されている。
【００５４】
加えて、本発明は、本発明を実現するように適合されるプログラムあるいはキャリヤに拡張される。このプログラムは、ソースコード、オブジェクトコード、本発明に従う方法の実装に使用するのに適しているコードの形態であっても良い。キャリヤは、プログラムを搬送することができる任意のエンティティあるいは装置であっても良い。例えば、キャリヤは、記録媒体、コンピュータメモリ、リードオンリメモリあるいは電気キャリヤ信号であっても良い。
【００５５】
本方法は、インテリジェント／ＣＡＭＥＬネットワークあるいはインターネットプロトコル内の移動電話の呼（call）を用いて説明しているが、本方法は、任意の通信セッションにも適用することができる。例えば、本発明に従う方法及びシステムは、他の移動電話ネットワーク、公衆交換電気通信ネットワーク（ＰＳＴＮ）、ＩＳＤＮ、インターネット、サービスネットワーク等に適用可能である。これらは、ユーザ及びプロバイダ用の多かれ少なかれ洗練された様々な種類の電気データ通信サービスを提供するものである。
【図面の簡単な説明】
【００５６】
【図１】本発明に従う集中課金システムを含む通信ネットワークの第１実施形態を示す図である。
【図２】本発明に従う集中課金システムを含む通信ネットワークの第２実施形態を示す図である。
【図３】図１のシステムの集中課金機能の解析構造の一部を示す図である。
【図４】本発明に従う方法の第１実施形態のフローチャートである。
【図５】本発明に従う方法の第２実施形態のフローチャートである。
【特許請求の範囲】
【請求項１】
通信システムでリクエストされたサービスのユーザに対して、レイティング通知を生成する方法であって、
料金表構造を検証するステップ（１０１）と、
前記検証中に、介在する状態に対する１つ以上の通知リクエストを検出するステップ（１０２）と、
前記１つ以上の通知リクエストから得られる１つ以上の通知を前記ユーザへ送信するステップ（１０４、１０７）と
を備えることを特徴とする方法。
【請求項２】
前記１つ以上の通知リクエストを検出するステップの後に、前記通知が前記ユーザ（３）へ直接送信されるべきであるか、あるいは後解析（１０３）用に収集されるべきであるかを判定するために、前記検出された１つ以上の通知リクエストを解析するステップを更に備え、
前記通知が直接送信されるべきであると判定される場合（１０３’）、前記１つ以上の通知を前記ユーザへ送信し、
そうでない場合、前記１つ以上の通知リクエストを後解析用に記憶する
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記解析するステップは、１つ以上の通知が後解析用に収集される場合、どの通知を送信するべきであるかを判定するために未送信の通知のすべてを解析する（１０５）
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記ユーザへ送信される前に、１つ以上のメッセージをマージするステップを更に備える
ことを特徴とする請求項２または３に記載の方法。
【請求項５】
前記マージは、マージロジックによって判定される
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記解析は、セッション／呼／購入前、中、あるいは後、あるいは補充前、中あるいは後の照会時に実行される
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記１つ以上のリクエストは、価格照会に対するものである
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
検証中に補充されるすべての状態はログとして出力され、前記ログは、別のプロセスによる次のステップで処理されて、前記実行されるレイティングを解析し、かつ対応する１つ以上の通知を生成する
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記料金表構造内の専用トリガーは、更なる処理用にリアルタイムで発行することができる、あるいは収集することができる通知を起動する
ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
補充される１つ以上の状態は、解析用に外部通知処理に送信される
ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
どのようにして料金表構造が検証されているかのログが生成され、かつ通知（群）を生成するために、前記解析後に処理される
ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
前記状態は、前記判定される結果に作用する
ことを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
【請求項１３】
前記通知は、課金されるセッションに介在する端末以外の別の宛先へ送信される
ことを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
【請求項１４】
請求項１乃至１３のいずれか１項に記載の方法をコンピュータに実行させるためのプログラム命令を有するコンピュータプログラム。
【請求項１５】
請求項１乃至１３のいずれか１項に記載の方法をコンピュータに実行させるためのコンピュータ実行可能命令を有する、キャリヤ上のコンピュータプログラム。
【請求項１６】
前記キャリヤは、記録媒体、コンピュータメモリ、リードオンリメモリあるいは電気キャリヤ信号である
ことを特徴とする請求項１５に記載のコンピュータプログラム。
【請求項１７】
通信システムにおけるユーザへのレイティング通知（群）を生成するシステムであって、
請求項１乃至１３のいずれか１項に記載の方法を実行するように構成されているコンピュータ装置を含むレイティング手段（１）
を備えることを特徴とするシステム。
【請求項１８】
前記システムは、移動通信システムで動作する
ことを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記システムは、インターネットプロトコルベースのプロトコルあるいは共通チャネルシグナリングシステムである
ことを特徴とする請求項１７に記載のシステム。
【請求項２０】
前記サービスは、プリペイドサービスである
ことを特徴とする請求項１７乃至１９のいずれか１項に記載のシステム。
【請求項２１】
前記サービスは、イーコマース／支払サービスである
ことを特徴とする請求項１７乃至２０のいずれか１項に記載のシステム。
【請求項１】
通信システムでリクエストされたサービスのユーザに対して、レイティング通知を生成する方法であって、
料金表構造を検証するステップ（１０１）と、
前記検証中に、介在する状態に対する１つ以上の通知リクエストを検出するステップ（１０２）と、
前記１つ以上の通知リクエストから得られる１つ以上の通知を前記ユーザへ送信するステップ（１０４、１０７）と
を備えることを特徴とする方法。
【請求項２】
前記１つ以上の通知リクエストを検出するステップの後に、前記通知が前記ユーザ（３）へ直接送信されるべきであるか、あるいは後解析（１０３）用に収集されるべきであるかを判定するために、前記検出された１つ以上の通知リクエストを解析するステップを更に備え、
前記通知が直接送信されるべきであると判定される場合（１０３’）、前記１つ以上の通知を前記ユーザへ送信し、
そうでない場合、前記１つ以上の通知リクエストを後解析用に記憶する
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記解析するステップは、１つ以上の通知が後解析用に収集される場合、どの通知を送信するべきであるかを判定するために未送信の通知のすべてを解析する（１０５）
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記ユーザへ送信される前に、１つ以上のメッセージをマージするステップを更に備える
ことを特徴とする請求項２または３に記載の方法。
【請求項５】
前記マージは、マージロジックによって判定される
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記解析は、セッション／呼／購入前、中、あるいは後、あるいは補充前、中あるいは後の照会時に実行される
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記１つ以上のリクエストは、価格照会に対するものである
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
検証中に補充されるすべての状態はログとして出力され、前記ログは、別のプロセスによる次のステップで処理されて、前記実行されるレイティングを解析し、かつ対応する１つ以上の通知を生成する
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記料金表構造内の専用トリガーは、更なる処理用にリアルタイムで発行することができる、あるいは収集することができる通知を起動する
ことを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
補充される１つ以上の状態は、解析用に外部通知処理に送信される
ことを特徴とする請求項１乃至９のいずれか１項に記載の方法。
【請求項１１】
どのようにして料金表構造が検証されているかのログが生成され、かつ通知（群）を生成するために、前記解析後に処理される
ことを特徴とする請求項１乃至１０のいずれか１項に記載の方法。
【請求項１２】
前記状態は、前記判定される結果に作用する
ことを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
【請求項１３】
前記通知は、課金されるセッションに介在する端末以外の別の宛先へ送信される
ことを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
【請求項１４】
請求項１乃至１３のいずれか１項に記載の方法をコンピュータに実行させるためのプログラム命令を有するコンピュータプログラム。
【請求項１５】
請求項１乃至１３のいずれか１項に記載の方法をコンピュータに実行させるためのコンピュータ実行可能命令を有する、キャリヤ上のコンピュータプログラム。
【請求項１６】
前記キャリヤは、記録媒体、コンピュータメモリ、リードオンリメモリあるいは電気キャリヤ信号である
ことを特徴とする請求項１５に記載のコンピュータプログラム。
【請求項１７】
通信システムにおけるユーザへのレイティング通知（群）を生成するシステムであって、
請求項１乃至１３のいずれか１項に記載の方法を実行するように構成されているコンピュータ装置を含むレイティング手段（１）
を備えることを特徴とするシステム。
【請求項１８】
前記システムは、移動通信システムで動作する
ことを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記システムは、インターネットプロトコルベースのプロトコルあるいは共通チャネルシグナリングシステムである
ことを特徴とする請求項１７に記載のシステム。
【請求項２０】
前記サービスは、プリペイドサービスである
ことを特徴とする請求項１７乃至１９のいずれか１項に記載のシステム。
【請求項２１】
前記サービスは、イーコマース／支払サービスである
ことを特徴とする請求項１７乃至２０のいずれか１項に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２００７−５２１７０９（Ｐ２００７−５２１７０９Ａ）
【公表日】平成１９年８月２日（２００７．８．２）
【国際特許分類】
【出願番号】特願２００５−５１２３６６（Ｐ２００５−５１２３６６）
【出願日】平成１５年１２月２３日（２００３．１２．２３）
【国際出願番号】ＰＣＴ／ＳＥ２００３／００２０８４
【国際公開番号】ＷＯ２００５／０６２５９８
【国際公開日】平成１７年７月７日（２００５．７．７）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成１９年８月２日（２００７．８．２）
【国際特許分類】
【出願日】平成１５年１２月２３日（２００３．１２．２３）
【国際出願番号】ＰＣＴ／ＳＥ２００３／００２０８４
【国際公開番号】ＷＯ２００５／０６２５９８
【国際公開日】平成１７年７月７日（２００５．７．７）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]