(57)【特許請求の範囲】
【請求項１】
階層型アカウントに無線ネットワークシステムの使用についての課金を適用する方法であって、
通信セッションの開始の通知を受信するステップと、
課金するための、責任を負う階層型アカウント残高を選択するために、少なくとも１つの残高選択ルールを適用するステップと、
選択された階層型アカウント残高が親アカウントを有するか否かを判断するステップと、
選択された階層型アカウント残高が親アカウントを有する場合には、責任を負う異なる階層型アカウント残高を選択するために、少なくとも１つの残高選択ルールを適用するステップへ戻るステップと、
選択された階層型アカウント残高が親アカウントを有しない場合には、選択された階層型アカウント残高に課金するステップと、
を含む、方法。
【請求項２】
少なくとも１つの残高選択ルールを適用するステップがさらに、残高選択ルールのタイプを判断するステップを含む、請求項１に記載の方法。
【請求項３】
少なくとも１つの残高選択ルールを適用するステップが、優先順位に基づいて少なくとも１つの残高選択ルールを適用するステップをさらに含む、請求項１に記載の方法。
【請求項４】
課金要求に責任のある階層型アカウント残高がない場合、通信セッションを拒否するステップをさらに含む、請求項１に記載の方法。
【請求項５】
少なくとも１つの階層型アカウントと、
通信セッションの開始の通知を受信することと、
少なくとも１つの残高選択ルールを適用すること、および少なくとも１つの階層型アカウントから責任を負う階層型アカウント残高を選択することと、
選択された階層型アカウント残高が親アカウントを有するか否かを判断することと、
選択された階層型アカウント残高が親アカウントを有する場合には、責任を負う異なる階層型アカウント残高を選択するために、少なくとも１つの残高選択ルールを適用するステップへ戻ることと、
選択された階層型アカウント残高が親アカウントを有しない場合には、選択された階層型アカウント残高に課金することによって、階層型アカウントに無線ネットワークシステムの使用についての課金を適用するアカウントマネージャと
を含む、システム。
【請求項６】
少なくとも１つの階層型アカウントが、親の階層型アカウントと子の階層型アカウントとを含む、請求項５に記載のシステム。
【請求項７】
少なくとも１つの階層型アカウントがさらに、
ネットワーク利用残高を格納するために使用される、少なくとも１つの階層型アカウントと関連する少なくとも１つの階層型アカウント残高と、
ネットワーク利用を判断するために使用される、少なくとも１つの階層型アカウント残高と関連する少なくとも１つの残高選択ルールと、
を含む、請求項５に記載のシステム。
【請求項８】
残高選択ルールを提供するための残高ルール提供インタフェースと、
リアルタイムで残高選択ルールを提供して確認するための残高ルール提供システムと、
階層型アカウント関連メッセージを送受信するためのメッセージプロトコルインタフェースと
をさらに含む、請求項５に記載のシステム。
【請求項９】
残高ルール提供インタフェースがさらに、
リアルタイムで加入者の残高選択ルールを入力し、加入者の残高選択ルールを残高ルール提供システムに提供するための加入者のユーザ入力部と、
リアルタイムで事業者の残高選択ルールを入力し、事業者の残高選択ルールを残高ルール提供システムに提供するための事業者のユーザ入力部と
を含む、請求項８に記載のシステム。
【請求項１０】
加入者のユーザ入力が、
加入者の残高選択ルールを入力するためのウェブポータル入力と、
加入者の残高選択ルールを入力するための無線アクセスプロトコル入力と、
加入者の残高選択ルールを入力するための音声自動応答入力と
のうちの少なくとも１つを含む、請求項９に記載のシステム。
【請求項１１】
事業者のユーザ入力が、事業者の残高選択ルールを入力するためのウェブポータルを含む、請求項９に記載のシステム。
【請求項１２】
システムが複数のオンライン課金システム上にある場合、メッセージプロトコルインタフェースがさらに、Ｄｉａｍｅｔｅｒ  Ｒｏプロトコルメッセージを送受信するためのＤｉａｍｅｔｅｒ  Ｒｏプロトコルインタフェースを含む、請求項８に記載のシステム。
【請求項１３】
システムがオンライン課金システム上にある場合、メッセージプロトコルインタフェースがさらに、メッセージを送受信するためのユーザ定義のプロトコルインタフェースを含む、請求項８に記載のシステム。
【請求項１４】
アカウントマネージャが、課金する少なくとも１つの階層型アカウント残高を選択し、課金をルーティングする階層型アカウントがなく、課金する階層型アカウント残高がない場合は通信セッションを拒否する、請求項５に記載のシステム。
【請求項１５】
少なくとも１つの階層型アカウントが、少なくとも１つの請求プランとして配置される、請求項５に記載のシステム。
【請求項１６】
少なくとも１つの請求プランが、少なくとも１人の加入者と、少なくとも１つの階層型アカウント残高とを含む、請求項１５に記載のシステム。
【請求項１７】
少なくとも１つの階層型アカウントが、複数の関連する階層型アカウント残高を含み、関連する階層型アカウント残高のそれぞれが、異なる請求プランに属する、請求項１５に記載のシステム。
【請求項１８】
各階層型アカウントが、少なくとも１つの請求プランと関連する、請求項５に記載のシステム。
【請求項１９】
階層型アカウントに無線ネットワークシステムの使用についての課金を適用する方法であって、
通信セッションの開始の通知を受信するステップと、
課金するための、責任を負う階層型アカウント残高を選択するために、少なくとも１つの残高選択ルールを適用するステップと、
選択されたアカウントが課金可能か否かを判断するステップと、
選択されたアカウントが課金可能な場合には、以下の、
選択された階層型アカウントが親アカウントを有するか否かを判断するステップと、
選択された階層型アカウントが親アカウントを有する場合には、親アカウントの少なくとも１つの残高選択ルールを適用し、課金するための、責任を負う階層型アカウント残高を選択するステップと、
選択された階層型アカウントが親アカウントを有しない場合には、選択された階層型アカウントの残高に課金するステップを実行するステップと、
選択されたアカウントが課金可能でない場合には、以下の、
さらなるアカウントが利用可能かかを判断し、課金するための責任を負う階層型アカウント残高を選択するために少なくとも１つの残高選択ルールを適用し、選択されたアカウントが課金可能か否かを判断するステップに戻るステップと、
選択されたアカウントが課金可能な場合には、少なくとも１つの残高選択ルールを適用するステップと、
選択されたアカウントが課金可能でない場合には、通信セッションを拒否するステップを実行するステップを含む、方法。
【請求項２０】
加入者のユーザ入力部を使用して、リアルタイムで加入者の残高選択ルールを入力し、加入者の残高選択ルールを残高ルール提供システムに提供するステップと、
事業者のユーザ入力部を使用して、リアルタイムで事業者の残高選択ルールを入力し、事業者の残高選択ルールを残高ルール提供システムに提供するステップと、
残高ルール提供インタフェースを使用して、リアルタイムで残高選択ルールを提供して確認するステップと、
受信のためにメッセージプロトコルインタフェースを使用して、階層型アカウント関連メッセージを送信するステップと、
をさらに含む、請求項１９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークリソースを管理することを対象とし、特に、ネットワークリソースを管理するための、ルールベース階層型アカウントシステムおよび方法を対象とする。
【背景技術】
【０００２】
近年、携帯電話の人気により、携帯電話を仕事用と私用の両方に使う人々をもたらした。加入者は、携帯電話の使用が仕事目的で行われるとき、この支払いをしなければならないことを希望せず、また企業は、雇用者の個人的な電話使用の支払いをしなければならないことを希望しないので、多くの人々は私用に１つと仕事用に１つの２つの電話、ゆえに２つのアカウントを有する。加入者は２つのアカウントを有するので、２つの請求書を受け取る。２つの異なる携帯電話のアカウントを有する加入者は、仕事用と私用の両方を提供する１つのサービスプロバイダを有する加入者よりも、あるサービスプロバイダにとどまる誘因が少ない。加入者が非常に容易に、また頻繁にサービスプロバイダを切り換える今日では、サービスプロバイダは、加入者が乗り換えないように加入者を満足させ続ける方法を探し求めている。
【０００３】
携帯電話の遍在の別の結果は、複数の携帯電話を有する家族であり、その場合、親は１人または複数の子供の無線請求書の支払いをしている。この状況の親は、家族の各メンバに対して別々の請求書ではなく、家族の電話使用に対して単一の請求書を受け取ることを希望する場合がある。また親は、子供の携帯電話の使用について制限を設定する機能を有することを希望することがある。同様に企業は、雇用者の携帯電話の使用について制限を設定する機能を有することを希望することがある。
【発明の概要】
【課題を解決するための手段】
【０００４】
１つの実施におけるルールベース階層型アカウントリソース管理システムは、課金すべき階層型アカウントの残高（ｂａｌａｎｃｅ）を判断するための少なくとも１つの残高選択ルールを備えた方法を含む。この方法は、残高選択ルールを階層型アカウントの残高に適用した結果に基づいてシステムリソースを管理する。
【０００５】
別の実施におけるルールベース階層型アカウントリソース管理システムは、少なくとも１つの階層型アカウントを含むシステムである。このシステムはさらに、少なくとも１つの残高選択ルールを適用すること、およびこの少なくとも１つの残高選択ルールの適用に基づいて課金すべき階層型アカウントの残高を選択することに基づいて、通信セッションのネットワークの使用を管理するためのアカウントマネ―ジャで構成されている。
【０００６】
ルールベース階層型アカウントリソース管理システムおよび方法のさらなる態様は、下記に簡単に説明する図面を参照して行う様々な実施形態の詳細な説明を見れば当業者には明らかであろう。
【０００７】
ルールベース階層型アカウントリソース管理システムの例示的実施の特徴は、説明、特許請求の範囲、および添付の図面から明らかになるであろう。
【図面の簡単な説明】
【０００８】
【図１】コアネットワークと通信しているオンライン課金システム（ＯＣＳ）上にあるルールベース階層型アカウントリソース管理システムを表す機能ブロック図である。
【図２】複数の階層型アカウントの一実施形態の例示的な図である。
【図３】請求プランとして配列された、いくつかの階層型アカウントを示す例示的な図である。
【図４】残高ルール提供チャネル、ルール提供システム、およびサンプルアカウントの一実施形態の機能ブロック図である。
【図５】階層型アカウントの残高が課金されるべきかどうかを判断することを含む、ルールベース階層型残高選択方法の１つの実施を表す図である。
【発明を実施するための形態】
【０００９】
図１は、オンライン課金システム（ＯＣＳ）２０と、ルールベース階層型アカウントリソース管理システム２５と、アカウントマネージャ３０と、３つの例示的階層型アカウント４０、５０、６０とを含むネットワークアーキテクチャ１０を示している。時間残高７０、容量残高８０、金額残高９０、およびイベント残高１００など、複数のアカウント残高を含んだ階層型アカウント４０を示している。
【００１０】
ルールベース階層型アカウントリソース管理システム２５は、ＯＣＳ２０上にあることが可能である。ＯＣＳ２０は、コアネットワーク１１０によって要求されるとオンライン課金を提供する。オンライン課金は、リソース使用の課金情報がそのリソースの使用と同時に収集されるプロセスである。しかしながらリソース使用が発生する前に、ネットワークリソースを使用するための適正な許可が取得されなければならない。
【００１１】
コアネットワーク１１０は、公衆交換電話網（ＰＳＴＮ）、符号分割多元接続（ＣＤＭＡ）網、移動体通信のグローバルシステム（ＧＳＭ）網、または他のいかなる無線もしくは地上通信網であることも可能である。コアネットワーク１１０がＣＤＭＡ網を含む場合、コアネットワーク１１０とＯＣＳ２０との間のインタフェースは、ＩＳ−８２６インタフェースであると考えられる。コアネットワーク１１０がＰＳＴＮを含む場合、コアネットワーク１０とＯＣＳ２０との間のインタフェースは、インテリジェントネットワークアプリケーションパート（ＩＮＡＰ）の機能セット１（ＣＳ１）インタフェースであると考えられる。コアネットワーク１１０がＧＳＭ網を含む場合、コアネットワーク１１０とＯＣＳ２０との間のインタフェースは、移動通信ネットワーク拡張ロジック用のカスタマイズされたアプリケーション（ＣＡＭＥＬ、Ｃｕｓｔｏｍｉｚｅｄ  Ａｐｐｌｉｃａｔｉｏｎｓ  ｆｏｒ  Ｍｏｂｉｌｅ  ｎｅｔｗｏｒｋ  Ｅｎｈａｎｃｅｄ  Ｌｏｇｉｃ）のアプリケーション部であると考えられる。ルールベース階層型アカウントリソース管理システム２５のすべてのアカウントが２つ以上のＯＣＳに分散される場合、ＯＣＳ間のインタフェースはＤｉａｍｅｔｅｒ  Ｒｏインタフェースであると考えられる。ルールベース階層型アカウントリソース管理システム２５が、単一ＯＣＳ２０上にある場合、アカウント情報の伝送には内部インタフェースが使用される。内部インタフェースは、２つのプロセスまたはエンティティが同じプロセッサ上にある場合、メッセージを送るおよび受け取ることができる２つのプロセスまたは他のエンティティ間のインタフェースであることは、当業者には容易に理解できるであろう。様々なインタフェースについて上述したが、本明細書ではいくつかの他のインタフェースを有利に使用することも可能であることを当業者は容易に理解するであろう。
【００１２】
ルールベース階層型アカウントリソース管理システム２５の中の階層型アカウントは、例えば携帯電話と関連するアカウントである場合がある。加入者は、階層型アカウントと関連したシステムの使用に対して定期請求を受け取る。アカウント残高は、特定アカウントの使用を記録する、または項目別にすることができる。例えば、アカウント残高は、加入者が音声チャネルの使用に費やす時間と共に格納されることが可能である。さらなる例としては、ショートメッセージサービス（ＳＭＳ）、または加入者が送信するテキスト、メッセージの数と関連するアカウント残高がある場合がある。一般に、アカウント残高のそれぞれは、携帯電話によって行われる活動の記録をとり、例えば加入者の請求が行われ、携帯電話の許可される使用に制限もしくは規制が実施されるようにする。
【００１３】
階層型アカウントは、少なくとも１つの関連するアカウント残高を有し、各アカウント残高は、少なくとも１つの関連する残高選択ルールを有する。例えば、アカウント４０は、時間残高７０、容量残高８０、金額残高９０、およびイベント残高１００と関連する。残高と残高選択ルールの関連付けに関しては、時間残高７０は残高選択ルール１２０と関連し、容量残高８０は残高選択ルール１３０と関連し、金額残高９０は残高選択ルール１４０と関連し、イベント残高１００は残高選択ルール１５０と関連している。簡潔にするために、階層型アカウントは、アカウントと呼ばれる場合もあり、階層型アカウント残高は、残高またはアカウント残高と呼ばれる場合もある。
【００１４】
アカウントと関連するアカウント残高は、アカウントと共に格納されることが可能であり、またはアカウント残高はアカウントとは別個に格納され、何らかの方法でアカウントと関連付けられることが可能である。例えば、アカウントおよびその関連するアカウント残高は、同じデータ構造で格納されることが可能である。あるいは、アカウント残高とアカウントは、別々のデータ構造で格納されることが可能であり、アカウントと、アカウントと関連する残高との間のマッピングがあることがある。同様に、残高選択ルールは、残高と共に格納されることが可能であり、または残高選択ルールは残高とは別個に格納されて、何らかの方法で残高と関連付けられることが可能である。例えば、アカウント残高およびその関連する残高選択ルールは、同じデータ構造で格納されることが可能である。あるいは、アカウント残高およびその関連する残高選択ルールは、別々のデータ構造で格納されることが可能であり、アカウント残高とその関連する残高選択ルールとの間のマッピングがあることがある。
【００１５】
アカウントと関連する各アカウント残高は、残高タイプを有する。例えば、アカウント４０と関連する残高のタイプは、時間残高７０、容量残高８０、金額残高９０、およびイベント残高１００である。残高タイプは、加入者のネットワーク利用に関してどんな情報が監視されているかを規定する。例えば、時間残高７０は、加入者がどれほどの時間音声回線を使用したかを含むことができ、容量残高８０は、どれほどのネットワークデータを加入者が送信したかを含むことができ、金額残高９０は、加入者がいくつの呼を行ったかを含むことができ、イベント残高１００は、加入者が実行したイベントの数を含むことができる。イベントは、例えばＳＭＳメッセージを送信することである場合がある。呼はいかなるタイプの通信セッションであることも可能であることを、当業者は容易に理解するであろう。したがって、音声呼、データ呼、ＳＭＳメッセージ、または通信装置によって開始されるもしくは受信されるいかなるタイプの通信も、呼または通信セッションとみなされる。アカウント残高は、あらかじめ決められた期間のネットワーク使用の記録を保持し、その後、一般に後続の期間のためにリセットされる。例えば、加入者は、月に１００時間の音声通信を許可する請求プランを有することができる。その結果として、一ヶ月が終わった後に、時間残高７０は次の期間のためにリセットされることが可能である。
【００１６】
残高選択ルールは、残高ルールタイプに関して定義されることが可能である。残高ルールタイプは、呼トラフィックタイプ、時間、曜日、ローミング状態、位置ゾーン、ホワイトリスト、ブラックリスト、呼タイプ、友人および家族指定、特定の宛先、または残高しきい値とすることができる。
【００１７】
呼トラフィック残高選択ルールタイプは、階層型アカウントの残高に課金されることが可能である呼トラフィックタイプを定義する。例えば、呼トラフィック残高選択ルールタイプは、特定のアカウント残高に課金される音声呼のみを許可することができる。時間は、残高が課金されることが可能である時間を定義する、または残高がいかなるチャージも受け入れない時間を定義することができる。例えば、企業は、９時から５時の間だけの残高課金を許可する時間ルールを希望することができる。曜日ルールは、残高が課金される、または課金されない日を定義する。
【００１８】
例えば、企業は、加入者が月曜日から金曜日までに限って課金することを許可する曜日ルールを希望することができる。ローミング状態ルールは、加入者がローミング中であるか、またはホーム網にいるかによって残高が課金可能であるかどうかを定義する。例示的説明として、企業は、単に非ローミング呼がそのアカウントに課金され、ローミング呼は加入者の個人のアカウントに課金されることを希望することができる。位置ゾーンルールは、加入者の物理的位置に基づいて残高が課金されることが可能であるかどうかを定義する。無線ネットワークでは、加入者の物理的位置は、特定の位置に絞られる可能性がある。この絞り込みは、特定の無線基地局からのみ、または無線基地局の特定のセクタからのみ発する呼を許可することによって行われることが可能である。例えば、企業は、そのオフィスに近い基地局から発する呼のみを許可することができる。呼の終了は、同じく位置によって制限されることが可能である。
【００１９】
ホワイトリストは、特定の残高に課金することを許可される電話番号を定義する。呼発信がホワイトリストに載っていない番号にされる、または着信呼の番号がホワイトリストに載っていない場合、この呼に対応する課金は、そのホワイトリストの番号と関連する残高に行われることは可能ではない。電話番号は、携帯電話と関連する国際移動体加入者識別番号（ＩＭＳＩ）、携帯電話と関連する移動体識別子（ＩＤ）、固定電話と関連する電話番号、または通信セッションを確立することができる装置を識別する他のいかなる方法とすることも可能であることを、当業者は容易に理解するであろう。
【００２０】
ブラックリストは、特定のアカウント残高に課金することを禁止する電話番号を定義する。呼発信がブラックリストに載っている電話番号にされる、または着信呼の番号がブラックリストに載っている場合、この呼に対応する課金は、ブラックリスト番号と関連付けられた残高にされることは可能ではない。呼タイプ残高選択ルールは、残高に課金することができる呼タイプを制限する。例えば、残高選択ルールは、国際呼は残高に課金されないように設定されることが可能である。
【００２１】
友人および家族指定、またはリストは、アカウントに課金することを許可される呼を定義する。発信または着信番号が友人および家族リストに載っていない場合、対応する呼の課金は、友人および家族リストと関連付けられた残高にはされない。
【００２２】
特別指定は、特定のアカウントに課金されることが可能である特別の番号を示す。例えば、アカウントは、特定のエリアコードへの呼および特定のエリアコードからの呼だけがこのアカウントに課金されることが可能であるように設定されることが可能である。アカウントマネージャ３０は、残高に課金を適用する。アカウントマネージャ３０は、課金が残高しきい値を超える場合、残高に課金を適用しない。例えば、特定残高の残高しきい値は、１０単位で設定されることが可能である。１０単位のしきい値に到達すると、アカウントマネージャ３０はその残高に課金を適用しないことが可能である。しきい値の単位は、いくつかの方法で測定されることが可能である。単位は、金額、システムの時間、転送されたバイト、試みられた呼、受信呼、または通信セッションと関連付けられることが可能である他のタイプの単位で測定されることが可能である。電話または電話からもしくは電話へ行われる通信の測定可能ないかなる特性も、単位として使用されることが可能であることを当業者は容易に理解するであろう。
【００２３】
ルールベース階層型アカウントリソース管理システム２５のアカウントマネージャ３０は、アカウント残高の残高選択ルールを使用して、アカウントマネージャ３０が残高選択ルールと関連する残高に課金するかどうかを判断する。通信セッションが発生すると、コアネットワーク１１０は、このセッションのためにアカウントが課金されることを要求する課金要求メッセージをＯＣＳ２０に送信する。ＯＣＳ２０は、この課金要求メッセージをアカウントマネージャ３０に送信する。この課金要求メッセージの代わりにいかなるタイプの課金メッセージも使用可能であることを、当業者は理解するであろう。
【００２４】
アカウントマネージャ３０は、課金要求メッセージの中の情報に基づいて課金するアカウントを判断する。例えば、アカウントマネージャ３０は、課金要求メッセージの中に含まれている移動体ＩＤに基づいて、アカウント４０が課金されるべきことを判断することができる。アカウント４０に課金を適用しようとする際に、アカウントマネージャ３０は、あらかじめ選択された順序、すなわち時間残高７０、容量残高８０、金額残高９０、およびイベント残高１００で課金しようと試みる。言い換えれば、アカウントと関連する残高を課金することに対するあらかじめ選択された順番の優先順位がある。説明の目的で、アカウントマネージャ３０が時間残高７０に呼を課金することができないと仮定すると、アカウントマネージャ３０は、容量残高８０に課金しようと試みる。アカウントマネージャ３０は、容量残高８０と関連する残高選択ルール１３０を適用して、課金を適用するかどうかを判断する。容量残高８０と関連する残高選択ルール１３０は、例えば、呼トラフィックタイプ、時間、呼タイプ、および残高しきい値を限定するルールから構成される可能性がある。残高選択ルール１３０は、あらかじめ選択された順序で適用され、すなわちルールの適用には優先順位がある。したがって、残高選択ルール１３０が上記の順序である場合、アカウントマネージャ３０は、まず、呼トラフィックタイプルールに基づいてアカウント４０が課金されることが可能であるかどうかを判断する。例えば、容量残高８０と関連する呼トラフィックタイプがデータ呼に設定されていて、これが音声呼である場合、この音声呼は容量残高８０に課金可能ではない。一方、これがデータ呼であって、トラフィックタイプがデータ呼に設定されている場合、アカウントマネージャ３０は、残高ルール１３０の中の次のルールをチェックして、そのルールが満たされるかどうか判断する。
【００２５】
この例の場合では、アカウントマネージャ３０は、時間をチェックする。この時間が、残高ルール１３０によって指定された時間内にない場合、課金は拒否される。容量残高８０と関連するすべての残高選択ルール１３０がアカウントマネージャ３０によってチェックされるまで、これが続く。すべての残高選択ルール１３０が満たされると、容量残高８０が課金される。容量残高８０と関連する残高選択ルール１３０のいずれかが違反される場合、アカウントマネージャ３０は容量残高８０に課金することができない。容量残高８０が課金されることが可能ではない場合、アカウントマネージャ３０は、イベント残高１００が後に続く金額残高９０に課金しようと試みる。
【００２６】
アカウントマネージャ３０が、アカウントと関連するアカウント残高に課金できない場合、呼は拒否される。呼を拒否することは、コアネットワーク１１０へ呼が拒否されることを示すＤａｉａｍｅｔｅｒ  Ｒｏ応答メッセージを送信することを伴う場合がある。しかしながら、呼が拒否されることを示すために他のタイプの課金メッセージが送信される場合もあることを、当業者には容易に理解されるであろう。
【００２７】
ルールベース階層型アカウントリソース管理システム２５では、アカウント残高は、親（上位レベル）階層アカウントと関連付けられる。親アカウントと関連付けられたアカウント残高は、親アカウントの子と呼ばれる。例えば、時間残高７０は、アカウント５０の子である。したがってアカウント５０は、時間残高７０の親である。親アカウントと子アカウント残高が、関連付けられる。子アカウント残高と親アカウントとの間の関連付けは、この２つのエンティティの間にポインタを作成すること、アカウントおよび関連するアカウント残高のリストを含む表を作成すること、関連するアカウント残高およびアカウントのアドレスを含む表を作成すること、または親アカウントと子アカウント残高との間の関連付けを識別する他のいかなる方法によっても行われることが可能である。これらは、アカウント残高とアカウントを関連付けるほんのわずかな例示的方法である。アカウント残高とアカウントを関連付ける他の数多くの方法があることを、当業者は容易に理解するであろう。
【００２８】
あるいは、親アカウントが子アカウント残高を所有すると言われることも可能である。言い換えれば、親アカウントは、この親アカウントと関連付けられたアカウント残高を所有する。例えば、アカウント５０は時間残高７０の親であり、したがってアカウント５０は時間残高７０を所有する。子アカウント残高が親アカウントと関連付けられると同時に、アカウントに所有されるアカウント残高がこのアカウントと関連付けられる。アカウントに所有されるアカウント残高を関連付ける方法は、子アカウント残高を親アカウントに関連付ける方法と同じである。
【００２９】
アカウント残高と関連付けられた１つまたは複数の残高選択ルールの適用に基づいて、アカウントマネージャ３０によるアカウント残高に課金する試みの結果として、課金要求が別のアカウントにルーティングされることがある。課金は、このアカウント残高を所有するアカウントにルーティングされることがある。課金要求、すなわちメッセージをルーティングすることは、内部メッセージを送信することを伴う場合がある。あるいは、課金要求をルーティングすることは、アカウントマネージャ３０が親アカウントと関連付けられた残高に課金しようとすることを伴う場合がある。これらは、課金がどのようにアカウントにルーティングされるかについてのほんの２つの例である。アカウント残高を所有するアカウントに課金が適用される結果となるいかなる方法も、メッセージをルーティングする一例とすることができる。
【００３０】
図１は、アカウントマネージャ３０がどのように課金要求を、責任を負うアカウントにルーティングできるかを示すために使用されることが可能である。図１では、アカウント４０の時間残高７０はアカウント５０によって所有され、すなわち関連付けられ、イベント残高１００はアカウント６０によって所有される。アカウントマネージャ３０が、アカウント４０のような第１のアカウントの、時間残高７０のようなあるアカウント残高に課金しようと試みる場合、これはアカウント５０のような第２のアカウントによって所有され、課金要求は、第２のアカウントにルーティングされて、第２のアカウントの残高選択ルールが適用され、第２のアカウントの少なくとも１つの残高のうちのどれが課金されるべきであるかを判断する。例えば、コアネットワーク１１０は、アカウント４０の課金を含む課金要求をアカウントマネージャ３０に送信する。アカウント残高を課金することのあらかじめ選択された優先順位により、アカウントマネージャ３０は残高選択ルール１２０を適用し、アカウント４０の時間残高７０が課金されるべきことを判断する。したがってアカウントマネージャ３０は、アカウント４０の時間残高７０はアカウント５０によって所有されているので、課金要求をアカウント５０にルーティングする。次にアカウントマネージャ３０は、アカウント５０の残高と関連付けられた残高選択ルールを適用し、課金するアカウント５０の、あるとしたら残高のうちのどの残高に課金するかを判断する。
【００３１】
一例におけるルールベース階層型アカウントリソース管理システムまたは装置２５は、１つまたは複数のコンピュータソフトウェアコンポーネントなど複数の構成要素を含む。いくつかのそのような構成要素は、装置２５の中で結合される、または分離されることが可能である。装置２５の例示的構成要素は、当業者には理解されるように、いくつかのまたは多数のプログラミング言語で書かれたまたは実行される一組のおよび／または一連のコンピュータ命令を使用するおよび／または含む。１つの例における装置２５は、垂直配向を含み、本明細書の説明および図は、説明の目的で、装置２５の１つの例示的配向を示している。
【００３２】
１つの例における装置２５は、１つまたは複数のコンピュータ可読信号搬送媒体を使用する。コンピュータ可読信号搬送媒体は、装置２５の１つまたは複数の実行の１つまたは複数の部分を実行するためのソフトウェア、ファームウェア、および／またはアセンブリ言語を格納する。１つの例における装置２５のコンピュータ可読信号搬送媒体は、磁気、電気、光、バイオ、および原子によるデータ格納媒体のうちの１つまたは複数を含む。例えば、コンピュータ可読信号搬送媒体は、フロッピー（登録商標）ディスク、磁気テープ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスクドライブ、および電子メモリを含む。
【００３３】
図２を見ると、これは複数の階層型アカウント１６０の一実施形態の１つの例である。複数のアカウントは、親アカウント（上位階層アカウント）と、子アカウント（下位階層アカウント）で構成されている。
【００３４】
前述のように、第１のアカウントのアカウント残高は、第２のアカウントに所有される、または関連付けられることが可能である。アカウントマネージャ３０が、親アカウントによって所有されるアカウント残高に課金を適用しようとする場合、この課金は親アカウントにルーティングされる。次にアカウントマネージャ３０は、親アカウントのアカウント残高に課金を適用しようと試みる。親アカウントに課金をルーティングする実際的結果として、加入者は、別の加入者の課金を支払うことができる。例えば、雇用者は、親アカウントと関連する請求を支払うことに対して責任を負う場合があり、被雇用者は、子アカウントと関連する請求を支払うことに責任を負う場合がある。両方のアカウントは、同じサービスプロバイダを利用している可能性がある。被雇用者による仕事の呼が、子アカウントの残高に課金しようとする試みをもたらす可能性がある。この課金は、親アカウントにルーティングされて、適用されることが可能である。したがって、階層的な方法で、すなわち、親−子の方法でアカウントを配置することによって、いくつかのアカウント残高は、１人の人物または事業体が複数の加入者の課金に対して請求されるように設定されることが可能である。実際面では、これは雇用者が、１つの親アカウントによって幾人かの被雇用者の課金を請求されることを意味する場合がある。これは、各被雇用者が、その携帯電話の使用に対する個々の請求を受け取り、各被雇用者が仕事と個人の課金を分けて、仕事の課金に対する雇用者からの払い戻しを求めることに責任を負うという状況を緩和することができる。
【００３５】
前述のように、アカウントは、１つまたは複数の関連するアカウント残高を有することがあり、アカウント残高は、親を有することがある。例えば、図２に示すように、アカウント１８０は、容量残高１７０と関連すると同時に、容量残高１７０は、アカウント１９０の子でもある。アカウント２００は、容量残高２１０とイベント残高２２０の両方の親である。アカウント１９０は、容量残高１７０と金額残高２４０の親であり、またアカウント１９０は、容量残高２１０と関連し、容量残高２１０は、アカウント２００の子である。
【００３６】
図２は、アカウントマネージャ３０が課金を適用しようとするとき、アカウントの階層がどのように横断されるかを示すために使用されることも可能である。アカウントマネージャ３０は、アカウント残高と関連する残高選択ルールに基づいてアカウント残高に課金を適用しようと試みる。第１の例として、１つまたは複数の残高選択ルールの適用に基づいて、アカウントマネージャ３０は、イベント残高２５０に課金しようと試みることができる。イベント残高２５０を課金しようと試みる前に、アカウントマネージャ３０はまず、時間残高２６０、容量残高１７０、および金額残高２７０に課金を適用しようとする。アカウントマネージャ３０が、残高２６０、１７０、２７０のどの１つにも課金を適用できないと判断する場合、アカウントマネージャ３０は、イベント残高２５０に課金を適用しようとする。この場合、イベント残高２５０は、親アカウントによって所有されておらず、したがって、アカウントマネージャ３０は、課金要求をアカウント１８０のイベント残高２５０に適用しようと試みる。アカウントマネージャ３０が、イベント残高２５０の残高選択ルール２８０を適用して、イベント残高２５０が課金可能であるかどうかを判断する。アカウントマネージャ３０が、イベント残高２５０は課金可能ではないと判断する場合、呼は拒否される。
【００３７】
第２の例として、課金要求の結果、アカウントマネージャ３０は、アカウント残高の親に課金することがある。アカウントマネージャ３０は、金額残高２４０に課金しようと試みることがある。残高選択ルール２９０が満たされる場合、アカウントマネージャ３０は、金額残高２４０がアカウント１９０に所有されていると判断する。課金要求はアカウント１９０にルーティングされ、アカウントマネージャ３０がアカウント１９０の残高選択ルール２９２、２９４、２９６、２９８を適用して、アカウント１９０のどの残高に課金するかを判断する。アカウント１９０の残高選択ルール２９２、２９４、２９６、２９８を適用した後、アカウントマネージャ３０は、アカウント１９０の金額残高３００が課金されるべきであると判断することができ、したがって残高３００が課金され、呼が許可される。一方、アカウントマネージャ３０が、アカウント１９０の残高２９２、２９４、２９６、２９８のどれも課金されることが可能ではないと判断する場合、呼は拒否される。
【００３８】
第３の例として、アカウントに課金する試みの結果、アカウントマネージャ３０がアカウント残高の親の親に課金することがある。例えば、アカウントマネージャ３０は、容量残高１７０に課金しようと試みることができる。容量残高１７０は、アカウント１９０によって所有されているので、アカウントマネージャ３０は、アカウント１９０の残高選択ルールのそれぞれを適用する。アカウント１９０の残高選択ルールの適用に基づいて、アカウントマネージャ３０は、容量残高２１０が課金されるべきであると判断することができる。容量残高２１０はアカウント２００によって所有されているので、アカウントマネージャ３０は、課金をアカウント２００にルーティングする。アカウント２００の残高選択ルール３１２、３１４、３１６、３１８の適用に基づき、アカウントマネージャ３０は、容量残高３０５が課金されるべきであると判断することができ、容量残高３０５が課金されて、呼が許可される。アカウント１８０、１９０、および２００と関連する残高のどれも課金されることが可能ではない場合、呼は拒否される。
【００３９】
図３を見ると、これは請求プラン３２０として配列された、いくつかのルールベース階層型アカウントを示す例示的な図である。請求プランは、少なくとも１つのアカウントで構成される。各アカウントはアカウント所有者を有し、各請求プランは所有者を有する。アカウントの各残高は、請求プランの一部であるが、アカウントのすべての残高が、同じ請求プランの一部である必要はない。アカウントは、１つの請求プランの一部であるいくつかの残高と、別の請求プランの一部である他の残高とを有することができる。例えば、アカウント３４０の残高３３０は、ファミリープラン３５０の一部であり、アカウント３４０の残高３６０は、法人プラン３７０の一部である。
【００４０】
例示の目的で、第１の家族メンバがアカウント３８０の所有者であるとすることができ、第２の家族メンバがアカウント３９０の所有者であるとすることができ、保護者（Ｇｕａｒｄｉａｎ）がアカウント３４０の所有者であるとすることができる。雇用者は、法人プラン３７０の所有者、保護者はファミリープラン３５０の所有者であるとすることができる。保護者は、残高３３０を支払う責任があり、雇用者は、残高３６０を支払う責任がある。
【００４１】
請求プランを含む残高選択ルールは、プランの所有者によって更新されることが可能である。アカウント所有者は、プラン所有者が更新を許可する場合、残高選択ルールを更新することができる。こうしたルールは、リアルタイムで更新されることが可能である。したがって、アカウントが更新されると、このアカウントへの課金は、更新された情報を反映する。家族プラン３５０の所有者として、保護者は、アカウント３８０およびアカウント３９０のすべての残高選択ルール４１０、４２０、４３０、および４４０とともに、残高３３０の残高選択ルール４００を更新することができる。保護者の制御に従って、第１および第２の家族メンバは、それぞれのアカウント３８０、３９０の残高選択ルール４１０、４２０、４３０、４４０を更新することができる。同様に、雇用者は、アカウント５３０、アカウント５４０、アカウント５５０、およびアカウント５６０と関連するすべての残高選択ルール４５０、４６０、４７０、４８０、４９０、５００、５１０、５２０を更新することができる。また雇用者は、アカウント３４０の残高３６０と関連する残高選択ルールを更新することもできる。保護者は、被雇用者として法人プラン３７０のメンバであり、法人プランの所有者の判断で、残高３６０と関連する残高選択ルールを更新することができる。
【００４２】
図３はまた、サンプルの残高課金が、結果としてどのように請求プランの所有者への請求となるかを示すために使用されることも可能である。第１の家族メンバが呼を発信し、その結果としてコアネットワーク１１０が課金要求を送信し、これをアカウントマネージャ３０がアカウント３８０にルーティングする場合、アカウント３８０の残高選択ルール４１０、４２０が課金要求に適用され、その結果課金残高５７０への試みとなる可能性がある。残高５７０は、アカウント３４０によって所有されているので、アカウントマネージャ３０は、課金要求をアカウント３４０へ再ルーティングする。アカウント３４０の残高選択ルール４００、５８０の結果として、残高３３０が課金されることが可能である。最終的には、保護者が残高３３０と関連するいかなる課金にも責任を負う。一方、保護者が、結果として課金残高３６０への試みとなる呼を発信する場合、課金要求はアカウント５５０にルーティングされる。法人プラン３７０の所有者は、アカウント５５０への課金に責任があり、アカウント５５０の残高への課金と関連するいかなる請求の支払いもしなければならない。
【００４３】
図４を見ると、これは、残高ルール提供チャネル６１０、残高ルール提供システム６２０、およびＯＣＳ６３５上にあるアカウント６３０を示す機能ブロック図６００である。事業者または加入者は、残高ルール提供チャネル６１０を使用して、リアルタイムでそのアカウントと関連する残高選択ルールを更新することができる。事業者または加入者は、階層型アカウント関連メッセージを送信するために、ルール残高ルール提供インタフェース６１０を使用することができる。アカウント関連メッセージは、残高選択ルールを追加する、削除する、調整することと関連する可能性がある。またメッセージは、アカウントと関連する残高の優先順位を記録することに関連する可能性がある。
【００４４】
加入者および事業者は、異なるユーザインタフェースを使用することができる。加入者は、加入者のユーザインタフェース６３０を使用することができ、事業者は、事業者のユーザインタフェース６４０を使用することができる。加入者のユーザインタフェース６３０は、ウェブポータル６５０、無線アクセスプロトコル（ＷＡＰ）ポータル６６０、または音声自動応答（ＩＶＲ）ポータル６７０を含む。ユーザインタフェース６３０は、こうしたポータルの１つまたは複数で構成される。事業者のユーザインタフェース６４０は、ウェブポータル６８０を有することができる。
【００４５】
加入者のユーザインタフェース６３０および事業者のユーザインタフェース６４０を介して入力される残高選択ルールは、残高ルール提供システム６２０に送信される。残高ルール提供システム６２０は、加入者残高選択ルール分析器６９０と、事業者残高選択ルール分析器７００とを含む。加入者が、一組の残高選択ルールを変更しようと試みる場合、残高ルール提供システム６２０が、こうした変更を加入者の残高選択ルール分析器６９０に転送する。同様に、事業者が残高選択ルールを変更しようと試みる場合、残高ルール提供システム６２０が、こうした変更を事業者の残高選択ルール分析器７００に転送する。
【００４６】
加入者が、残高選択ルールを変更しようと試みる場合、加入者の残高選択ルール分析器６９０は、変更が許容できることを確認する。例えば、加入者が、一組の残高選択ルールを変更しようとしており、請求プランの所有者ではない場合、加入者はいくらかの更新を行うことを認められるが、その他は認められない。例えば、請求プランの所有者は、加入者がホワイトリストを更新することを許可するが、トラフィックタイプまたは時間を更新することは許可しない。加入者が、ホワイトリストを更新しようとする場合、加入者の残高選択ルール分析器６９０が変更を許可する。一方、加入者がトラフィックタイプまたは時間を更新しようとする場合、加入者の残高選択ルール分析器６９０が更新を拒否する。
【００４７】
事業者の残高選択ルール分析器７００は、事業者によって入力された残高選択ルールが許容できることを確認する。これは、残高選択ルールが構文上正しいこと、事業者が変更を試みようとするルールが特定のアカウントによって使用されているルールであること、および事業者が残高選択ルールを正しく入力したことを確かめるための他のいかなる検査も保証することを伴うことがある。
【００４８】
１つの例における機能ブロック図６００は、コンピュータソフトウェアコンポーネントの１つまたは複数のような複数の構成要素を含む。このような構成要素のいくつかは、機能ブロック図６００では結合されるまたは分割されることが可能である。機能ブロック図６００の例示的構成要素は、当業者には理解されるように、いくつかのまたは多くのプログラミング言語で書かれたまたは実行される一組および／または一連のコンピュータ命令を使用するおよび／または含む。１つの例における機能ブロック図６００は、垂直配向を含み、説明の目的で、本明細書の説明および図は機能ブロック図６００の１つの例示的配向を示している。
【００４９】
１つの例における機能ブロック図６００は、１つまたは複数のコンピュータ可読信号搬送媒体を使用する。コンピュータ可読信号搬送媒体は、装置の１つまたは複数の実装の１つまたは複数の部分を実行するためのソフトウェア、ファームウェア、および／またはアセンブリ言語を格納する。１つの例における機能ブロック図６００のコンピュータ可読信号搬送媒体は、磁気、電気、光、バイオ、および原子によるデータ格納媒体のうちの１つまたは複数を含む。例えば、コンピュータ可読信号搬送媒体は、フロッピー（登録商標）ディスク、磁気テープ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスクドライブ、および電子メモリを含む。
【００５０】
図５を見ると、アカウント残高に課金するための、およびネットワーク利用を管理するためのルールベース階層型残高選択方法７３０の一例が示されている。この方法７３０は、アイドル状態で始まる７４０。加入者が、通信セッションを開始する７５０。通信セッションの結果として、階層型アカウントに課金しようと試みる。アカウントマネージャ３０は、アカウントと関連する第１の残高の、一組の残高選択ルールを適用することによって、アカウントに課金しようと試みる７６０。アカウントマネージャ３０がアカウントに課金できない場合７８０、この方法は、アカウントにさらなる残高があるかどうかを判断する７９０。アカウントにさらなる残高がない場合７９０、呼は拒否され８００、方法は終了する８１０。アカウントにさらなる残高がある場合７９０、次の残高と関連する残高選択ルールが適用され８２０、方法７３０は、残高が変更可能であるかどうかを判断するプロセスを繰り返す７８０。
【００５１】
残高が課金できる場合７８０、方法７３０は、残高が親アカウントを有するかどうかを判断する８３０。残高が親アカウントを有する場合、方法７３０は、親アカウントと関連する第１の残高の残高選択ルールを適用する７６０。残高と関連する親がない場合８３０、残高が課金され８４０、方法７３０は終了する８１０。
【００５２】
本明細書に記載するステップまたは操作は、単なる例示である。これらのステップまたは操作には、ルールベース階層型アカウントリソース管理システムの趣旨から逸脱することのない、多くの変形形態がある可能性がある。例えば、諸ステップは、いろいろと異なる順序で行われることがあり、あるいは諸ステップは、追加、削除、または変更されることがある。
【００５３】
ルールベース階層型アカウントリソース管理システムの例示的な実行について本明細書で詳細に示し、説明したが、様々な変更、追加、代用などが、ルールベース階層型アカウントリソース管理システムの趣旨から逸脱することなく行われることが可能であり、したがってこれらは次の特許請求の範囲の中で定義するルールベース階層型アカウントリソース管理システムの範囲内であるとみなされることは、当業者には明らかであろう。
【図１】
0005384513.tif 000002
【図２】
0005384513.tif 000003
【図３】
0005384513.tif 000004
【図４】
0005384513.tif 000005
【図５】
0005384513.tif 000006