(57)【要約】【課題】【解決手段】システムと方法は、プッシュ・トゥ・トーク（ＰＴＴ）ディスパッチシステム（dispatch system）のようなグループ通信システムにおける支払請求可能な情報を収集し、管理するために提供される。ローカルノードは、グループ通信に関連した支払請求可能なイベントデータを集めて、フラットファイル・データベースにそれを格納する。支払請求可能なイベントデータは、転送スキームに従ってローカルノードから集中ノードへ転送され、よりロバストなリレーショナルデータベースに格納される。【選択図】図３
2009528795.tif 000002
【特許請求の範囲】
【請求項１】
グループ通信システムおける支払請求可能な情報を収集し管理するためのローカルノードであって、
前記ローカルノードに関連したネットのメンバー間グループ通信を検出し、さらに前記グループ通信に関連した支払請求可能なイベントデータを集めるメディア制御ユニット（ＭＣＵ）マネージャーと、
前記グループ通信の終端上の前記ネットに関連した前記ローカルノード内の前記支払請求可能なイベントデータを格納するローカルログサーバと、を具備し、
前記ローカルノードからの前記支払請求可能なイベントデータは集中ノードに転送されることを特徴とするローカルノード。
【請求項２】
前記ローカルノードに保存された転送スキームをさらに具備し、
前記支払請求可能なイベントデータは、前記転送スキームに従って前記集中ノードに転送されることを特徴とする請求項１に記載のローカルノード。
【請求項３】
収集すべき前記支払請求可能なイベントデータの分類を定義する、前記ローカルノードでのフィルタをさらに具備することを特徴とする請求項１に記載のローカルノード。
【請求項４】
前記支払請求可能なイベントデータが前記集中ノードに転送された後に、前記支払請求可能なイベントデータは前記ローカルノードから削除されることを特徴とする請求項１に記載のローカルノード。
【請求項５】
前記ローカルノードは前記集中ノードに関連した複数のローカルノードのうちの１つであり、前記ネットはグループ通信に関与する複数のネットの内の１つであり、前記複数のネットのそれぞれは前記複数のローカルノードのうちの少なくとも１つに関連していることを特徴とする請求項１に記載のローカルノード。
【請求項６】
前記ネットの前記メンバーは、前記ネットの少なくとも３つのメンバーを具備することを特徴とする請求項１に記載のローカルノード。
【請求項７】
グループ通信システムにおける支払請求可能な情報を収集し管理するためのシステムであって、
ネットのメンバー間のグループ通信を検出するロジックと、
前記グループ通信に関連した支払請求可能なイベントデータを収集するロジックと、
前記グループ通信の終端上で前記ネットに関連したローカルノード内の前記支払請求可能なイベントデータを格納するロジックと、
前記ローカルノードから集中ノードへ前記支払請求可能なイベントデータを転送するロジックを具備することを特徴とするシステム。
【請求項８】
前記集中ノード内のリレーショナルデータベースに前記支払請求可能なイベントデータを格納するロジックをさらに具備し、
前記支払請求可能なイベントデータは前記ローカルノード内のフラットファイル・データベースに格納されることを特徴とする請求項７に記載のシステム。
【請求項９】
前記支払請求可能なイベントデータは、前記グループ通信が前記ネットの前記メンバー間で開始したときを示すNetStartedEventと、前記グループ通信がシャットダウン（shutdown）されたときを示すNetShutdownEventを含むことを特徴とする請求項７に記載のシステム。
【請求項１０】
前記支払請求可能なイベントデータは転送スキームに従って前記集中ノードに転送されることを特徴とする請求項７記載のシステム。
【請求項１１】
前記ローカルノードにおいて収集する前記支払請求可能なイベントデータの分類を定義するために該ローカルノードでのフィルタを実行するフィルタロジックをさらに具備することを特徴とする請求項７に記載のシステム。
【請求項１２】
前記集中ノードが前記支払請求可能なイベントデータを格納した後、前記ローカルノードから前記支払請求可能なイベントデータを削除するロジックをさらに具備することを特徴とする請求項７に記載のシステム。
【請求項１３】
前記ネットの前記メンバーが該ネットのうちの少なくとも３つのメンバーを具備することを特徴とする請求項７に記載のシステム。
【請求項１４】
グループ通信システムにおける支払請求可能な情報を収集し管理する方法であって、
ネットのメンバー間のグループ通信の検出し、
前記グループ通信に関連した支払請求可能なイベントデータを収集し、
前記グループ通信の終端上の前記ネットに関連したローカルノード内の前記支払請求可能なイベントデータを格納し、
前記ローカルノードから集中ノードへ前記支払請求可能なイベントデータを転送することを具備することを特徴とする方法。
【請求項１５】
前記集中ノード内のリレーショナルデータベースに前記支払請求可能なイベントデータを格納し、
前記ローカルノード内のフラットファイル・データベースに前記支払請求可能なイベントデータを格納することをさらに具備する請求項１４に記載の方法。
【請求項１６】
前記支払請求可能なイベントデータは、前記ネットの前記メンバー間で前記グループ通信が開始したときを示すNetStartedEventと、前記グループ通信がシャットダウン（shutdown）されたときを示すNetShutdownEventを含むことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記ローカルノードにおいて、転送スキームを用いることをさらに具備し、
前記支払請求可能なイベントデータが前記転送スキームに従って転送されることを特徴とする請求項１４に記載の方法。
【請求項１８】
前記ローカルノードにおいて同期コマンドを受信することをさらに具備し、
前記支払請求可能なイベントデータが前記同期コマンドに応じて転送されることを特徴とする請求項１４に記載の方法。
【請求項１９】
収集すべき支払請求可能なイベントデータの分類を定義するために、前記ローカルノードにおいてフィルタを実行することをさらに具備することを特徴とする請求項１４に記載の方法。
【請求項２０】
前記集中ノードに前記支払請求可能なイベントデータを転送した後に、前記ローカルノードから前記支払請求可能なイベントデータを削除することをさらに具備することを特徴とする請求項１４に記載の方法。
【請求項２１】
前記ローカルノードは前記集中ノードに関連した複数のローカルノードのうちの１つであり、前記ネットはグループ通信に関与する複数のネットの内の１つであり、前記複数のネットのそれぞれは前記複数のローカルノードのうちの少なくとも１つに関連していることを特徴とする請求項１４に記載の方法。
【請求項２２】
前記グループ通信のためのメッセージが半二重通信リンクを介して送られることを特徴とする請求項２１に記載の方法。
【請求項２３】
前記グループ通信は、第１ＲＮＣと第１ＢＳＣの少なくとも１つを介して前記少なくとも３つの第１加入者装置のうちの１つに送信され、前記グループ通信は、第２ＲＮＣと第２ＢＳＣの少なくとも１つを介して前記少なくとも３つのメンバーの１つへ送信されることを特徴とする請求項２３に記載の方法。
【請求項２４】
前記ネットの前記メンバーが少なくとも３つのメンバーを具備することを特徴とする請求項１４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はグループ通信システムの管理および運用に関する。より具体的には、本発明は、グループ通信システムにおける請求情報を収集し、格納し、管理するためのシステムおよび方法に関する。
【背景技術】
【０００２】
グループ通信システムは異なる位置にいる複数ユーザの間の同時通信を提供するために用いられる。グループ通信システムの例は、タクシーキャブおよびバスの全車両、警察署、消防署および他の救急隊員のためのディスパッチシステム（dispatch system）を含んでいる。通常、グループ通信システムは１人のユーザ（例えばタクシーキャブディスパッチャー（taxi cab dispatcher））が同時にグループの残りのメンバーに送信することを許可する。グループメンバーに同時に送信するユーザは発信者と呼ばれることもある。グループ内の任意の一人のメンバーが、他のグループのメンバーに交代で送信するグループ内の異なるメンバーと共に他の全員に話すことを許可するように、グループ通信システムは中央に集中しすぎないように組織化されることもある。
【０００３】
現在、グループ通信システムは、ビジネス（例えばタクシー、バスおよびトラックの全車両）また救急サービスおよび政府当局（例えば警察および法執行機関、消防署、軍隊、森林消防士等）によって用いられる。もし収益を得るより好ましい方法があれば、通信サービスプロバイダは喜んで個人のユーザおよび個人顧客にグループ通信サービスを提供するだろう。しかしながら、異なる通信サービスプロバイダは、変数、パラメータおよび支払請求可能なイベントの様々な組合せに基づいた、異なる支払い請求スキーム（billing scheme）の各種取り合わせを用いる。支払い請求目的に応じて異なるサービスプロバイダによって必要な種々のデータを収集し、管理するために、必要なものは、ロバストであり、それにもかかわらず柔軟であるシステムである。
【発明の開示】
【０００４】
ここに開示された本発明の態様は、グループ通信システムにおける支払請求可能な情報を収集するために提供する方法およびシステムにより、上記の指定された要求に対処する。
【０００５】
本発明の種々の態様によれば、複数の加入者装置を持ったネットのメンバー間のグループ通信を検知し、グループ通信に関連した請求可能なイベントデータを集めるための装置、方法およびコンピュータ読取り可能な媒体を提供する。支払請求可能なイベントデータはローカルノード内、例えばフラットファイル・データベースに格納される。その後、支払請求可能なイベントデータは、ローカルノードから集中ノードに転送される。ここで、それはよりロバストなデータベース、例えば集中ノード内のリレーショナルデータベースに格納される。
【発明を実施するための最良の形態】
【０００６】
図１は、種々の実施形態を実行するために用いられるグループ通信システム１００を示す。図１のグループ通信システム１００のようなグループ通信システムは、プッシュ・トゥ・トークシステム、ディスパッチシステム（dispatch system）、ネットブロードキャストサービス（ＮＢＳ）またはポイント−マルチポイント（point-to-multi-point）通信システムとも呼ばれる。グループ通信は１台の加入者装置から２台以上の他の加入者装置のグループに送信される。「ネット」とは、グループ通信システムにおいて互いと通信するような認可された加入者装置のグループである。例えば、加入者装置１０６−１１８は、ネットのメンバーになり得、メンバーとして、グループ通信に参加することができる。ネットの異なるメンバーは交代でグループ通信を送信および受信してもよい。加入者装置は１つ以上のネットに属していてもよいが、一般的に、加入者装置は、特定の時に１つのネットで通信を行うに過ぎないかもしれない。いくつかの実施形態は、加入者装置がネット内でモニタのみの特権を有することができるように実行されてもよい。いくつかの実施形態では、ネットは２台以上の加入者装置を含んでもよいし、または他の実施形態では３台以上の加入者装置を含んでいてもよいし、他の実施形態においては数十、数百もの加入者装置を含んでいてもよい。ネットに属する加入者装置はネットの「メンバー」と呼ばれてもよい。
【０００７】
加入者装置からの通信は、ボイスオーバーＩＰ（ＶｏＩＰ）フレームとしてパッケージにされ、ＶoIPアプリケーションである、ネットブロードキャストサービス（ＮＢＳ）を用いて送信される。ＮＢＳシステムは、米国特許出願シリアル番号０９／５１８，９８５、米国特許出願シリアル番号０９／５１８，７７６にさらに詳細に記述されている。両者とも２０００年３月３日出願され、それぞれはここにそのまま参照することにより組み込まれる。
【０００８】
グループ通信システムは、第１世代（１Ｇ）、第２世代（２Ｇ）および第３世代（３Ｇ）の機器を含む通信機器およびネットワークを各種取り合わせを用いて実行されてもよい。いくつかのレガシー１Ｇネットワーク装置がまだ作動中であるが、ネットワークの大多数は２Ｇ技術と３Ｇ技術の両方又はいずれか一方を利用する。１Ｇアナログ無線ネットワークは、１９９０年代の初めの間に普及したが、無線通信の急速な拡大のために容易に拡張可能ではなかった。１Ｇネットワークと比較して、２Ｇデジタルシステムは増大した容量およびより多くのサービスを提供した。現在作動している２Ｇシステムのうちのいくつかは、ヨーロッパの移動体通信のためのグローバルシステム（ＧＳＭ）、および、暫定基準（Interim Standard）１３６（ＩＳ−１３６）および暫定基準（Interim Standard）９５（ＩＳ−９５）に基づいた米国の携帯電話システムを含んでいる。種々の実施形態に従うグループ通信は適切に設定された３Ｇ、２Ｇまたは１Ｇシステムにおいて実行されてもよい。通信システムは主として３Ｇシステムとして実行されることが大半だが、１Ｇまたは２Ｇの技術と互換性をもつレガシー機器も含まれることがある。グループ通信システムは、ネットの加入者装置の各々への半二重通信リンクを用いたプッシュ・トゥ・トーク（ＰＴＴ）無線システムとして実行されてもよい。
【０００９】
ネットのメンバー間の通信は、実績のある技術を用いて既存の通信システム内で行なわれてもよい。例えば、図１に示された代表的なグループ通信システム１００はレガシー２Ｇの機器（例えばＢＳＣ１３０−１３２およびＢＴＳ１３４−１３８）と同様に、３Ｇ機器も（例えばＲＮＣ１２０−ＲＮＣ１２２およびノードＢ１２４−１２８）含んでいる。
【００１０】
グループ通信メッセージは、インターネットプロトコル（ＩＰ）を用いたいくつかの技術のうちどれかで送信されてもよい。
【００１１】
そのような通信技術は、例えば、ＣＤＭＡ（符号分割多元接続）、ＴＤＭＡ（時間分割多元接続）、ＦＤＭＡ（周波数分割多元接続）、ＯＦＤＭＡ（直交周波数分割多元接続）、およびＧＳＭのような符号化技術のハイブリッド、あるいは通信またはデータネットワークに用いられる無線プロトコルのような他のものを含んでいてもよい。いくつかの実施形態では、ネット用のグループ通信は、１人のネットメンバーからネットの他のメンバーへ１つの専用ブロードキャストチャネルで送信されてもよい。専用のブロードキャストチャネルは与えられた周波数範囲または通信チャネルで実行されてもよい。他の実施形態では、異なる周波数またはチャネルの収集は、グループ通信用の制御器によってネットに割り当てられてもよい。
【００１２】
図に示された多くの加入者装置１０６−１１８は、グループ通信に関与することが可能である。グループ通信システム１００は、３Ｇに準拠するいくつかのノードＢ１２４−１２８で、それぞれが加入者装置１１０−１１４で無線接続を維持するように各々形成されたものを含む。各ノードＢは順に、無線ネットワーク制御器（ＲＮＣ）１２０−１２２の１つに接続される。３Ｇに従って、ＲＮＣ１２０およびＲＮＣ１２２はＩｕｒインターフェース経由で相互に接続し、それによって、ＲＮＣの間のローカル通信の切り替えを許可する。すなわち、ＲＮＣ−ＲＮＣ通信リンクは、ＭＳＣを通してリンクをたどるというよりはむしろ、ＲＮＣを接続したノードＢに登録された移動加入者間の通信について確立されてもよい。例えば、加入者装置１１０から加入者装置１１２までの通信は、２つのＲＮＣ間のＩｕｒインターフェースを通してＲＮＣ１２０からＲＮＣ１２２へ送られる。
【００１３】
通信サービスプロバイダが、従来のシステムを用いてグループ通信のための請求情報を集めることは難しいことがある。なぜならば、異なる通信サービスプロバイダは、支払請求可能なイベントの様々な組合せに基づいて、異なる請求スキーム（billing scheme）を有しているからである。
【００１４】
サービスプロバイダは、提供したサービスを加入者に請求するためにＮＢＳサービス使用法を追跡する能力を必要とする。実際の請求スキーム（billing scheme）は、あるサービスプロバイダと別のサービスプロバイダでは変化するかもしれない。また、サービスプロバイダは、異なるサービスプランのために異なる請求スキーム（billing scheme）を実行したいかもしれない。
【００１５】
従って、特定のサービスプロバイダの請求パラメータについて特化された請求スキーム（billing scheme）は、別のサービスプロバイダの請求スキーム（billing scheme）に十分な情報を提供しない可能性がある。
【００１６】
ここに開示された通信管理（ＣＭ）システムは、支払請求可能なものとして潜在的に見なされたすべてのイベントを記録する包括的なスキームを実行する。ＣＭシステムは、サービスプロバイダが用いるそれらのイベントを取り選ぶ柔軟性をサービスプロバイダに与える。そして、ＣＭシステムは、引き続き選択されたイベントを請求する後処理を行う。さらに、本発明に係る種々の実施形態に従って、サービスプロバイダは、システム変更およびモニタ性能を追跡するためにイベントを選択してもよい。そのようなすべてのイベントは、ここではビジネスイベントと呼ばれてもよく、このような全てのイベントは以下で議論される。
【００１７】
グループ通信システム１００は多くの２Ｇのベーストランシーバー局（base transceiver station）（ＢＴＳ）１３４−１３８を含む。ＢＴＳ１３４−１３８の各々は基地局制御装置(base station controller)ＢＳＣ１３０−１３２のうちの１つに接続される。３ＧのＲＮＣとは異なり、２ＧのＢＳＣは、典型的には、ローカルのＢＳＣ−ＢＳＣ間通信切り替えをする能力を有しない。ＢＣＳ、ＲＮＣおよびシステム１００の他の様々な要素は、典型的にはＰＳＴＮおよび／またはインターネットの一部、および光ファイバーケーブルリンクを含む地上通信線のネットワークを介して相互に接続される。
【００１８】
例えば、ＭＳＣ１４０、ＲＮＣ１２０−１２２、ノードＢ１２４−１２６、ＢＳＣ１３０−１３２またはＢＴＳ１３４−１３８はそのような地上通信線を用いて接続されてもよい。場合によっては、ＲＦリンクまたは衛星中継はシステム１００の１つ以上の要素を相互接続するために用いられてもよい。
【００１９】
ＲＮＣ１２０−１２２およびＢＳＣ１３０−１３２は各々移動交換センター（mobile switching center）ＭＳＣ１４０に接続される。ＭＳＣ１４０は、公共電話網（public services telephone network）（ＰＳＴＮ）１４２に接続され、プッシュ・トゥ・トーク能力をもった固定電話でもよい加入者装置１０８のような地上線のＰＳＴＮユーザに接続される。また、ＭＳＣ１４０はＧＰＲＳサービスノード（Serving GPRS Service Node）（ＳＣＳＮ）１４４を介してインターネット１５０にも接続される。
【００２０】
加入者装置１０６は、例えば無線アクセスポイントまたは他のインターネットポータルを通して、インターネット１５０に直接接続されてもよい。
【００２１】
加入者装置１０６−１１８は無線ハンドセットまたは携帯電話として実行されてもよいが、無線で接続しているコンピュータ、ＰＤＡ(personal digital assistant)（携帯情報端末）、ページャ(pager)、ナビゲーション装置、音楽またはビデオコンテンツのダウンロードユニット、無線ゲーム装置、在庫管理ユニット、または空間（air interface）を介して無線で通信する装置のタイプのようなものを含んでいてもよい。
【００２２】
グループ通信システム１００は、システムに登録されたネットの加入者メンバーに関連した情報（例えばユーザＩＤ、請求情報）を格納するために通信マネージャー（ＣＭ）システム１６０の一部として設定されうる中央のデータベースを含んでいる。ＣＭシステム１６０は、異なる場所での種々のノード内に設置されている多数の分散装置を含んでいてもよい。ＣＭシステム１６０の詳細は、図２で説明する。
【００２３】
図２は、本発明に係る様々な実施形態を実行するために設定された通信管理システムＣＭシステム１６０を示す。ＣＭシステム１６０の通信マネージャー（Communications Manager）２０４は、ＮＢＳクライアント（例えば加入者装置を持ったユーザ）と、運用上のクライアント（例えばサービスプロバイダ）からの入力との相互作用（やりとり）を容易にする。多くの支払請求可能なイベントはそのような相互作用（やりとり）の結果生成される。通信マネージャー（Communications Manager）２０４は持続性のデータベースにこれらの支払請求可能なイベントを取り込んで記録するように設定されている。イベント記録用のデータベーススキーマはサービスプロバイダに提供することが可能である。このように、個別サービスプロバイダは、グループ通信サービスの提供に対する費用請求を目的とした、支払請求可能なイベントの使用法を決定することが可能である。
【００２４】
ＣＭシステム１６０におけるイベントロギングサービスの代表的な高レベルのアーキテクチャは、図２で説明される。示されるように、イベントロギングサービスはＣＭコア２００上で実行する中央ログサーバ２０２、および各メディア制御ユニット（media control unit）（ＭＣＵ）ノード２２０とＭＣＵ２２２上で実行するローカルログサーバ２２４を含む。中央ログサーバ２０２は１つのノード（例えば、集中ノード）に配置されてもよいが、ローカルログサーバはグループ通信システム１００の至る所にある他の複数のノードに分散している（例えば、エンドユーザの近い場所に位置するローカルノードにおいて）。「ローカルノード」とは、この開示を通して使われるものとして、「発信ノード（originating nodes）」と同一のものを意味し、「発信ノード（originating nodes）」と置き換え可能に使用される。しかし、ある実施においては、集中ノードはローカルノードと同一場所に配置してもよい。ＣＭコア２００のコンポーネント（例えばＣＭマネージャー２０４、運用サーバ２０６およびセッション設定プロトコルユーザエージェントサーバ２０８（ＳＩＰ  ＵＡＳ２０８））は、ＣＭコア２００上で動作する中央ログサーバ２０２にイベントを報告する。ＳＩＰ  ＵＡＳ２０８はリダイレクトサーバ（redirect server）と呼ばれることもある。ＭＣＵ２２０はそれぞれ、ＭＣＵマネージャー２２６の管理の下で、そのノード上で動作するローカルログサーバ２２４にそのイベントを報告する。中央ログサーバ２０２は、すべての情報管理用イベント（system wide events）の持続性のある保存場所（repository）を維持するための責任を負う。ローカルログサーバ２２４はそれぞれ、そのノード特有のイベントを集めて、中央ログサーバ２０２にデータを転送する責任を負う。運用ワークステーションクライアント２４０は、データをダウンロードし、処理し、さらに操作し、かつＣＭコア複合体２００の運用およびメンテナンスに専念するために提供されてもよい。
【００２５】
ＣＭシステム１６０は、グループ通信システム１００の至る所にある地点に、例えばメディア制御ユニット（例えばＭＣＵ２２０−２２２）のノードを含んでいてもよい。ローカルノードのうちのいくつかは、隣接して設置されてもよいし、ＭＳＣ１４０、ＲＮＣ１２０−１２２、またはグループ通信システム１００の他の要素の一部として設定されてもよい。ＣＭシステム１６０におけるローカルＭＣＵノード２２０は、そのノードに生じるイベントを集める責任を負うローカルログサーバ２２４を収容するように設定されてもよい。ＣＭシステム１６０のノードは、必ずしもグループ通信システム１００の通信要素と同一の位置にある必要はない。ＣＭシステム１６０のノードは、インターネットにアクセス可能または別の容易に利用可能な通信手段があるなど、ほぼあらゆる位置に設置してもよい。ＣＭシステム１６０のローカルノードは、グループ通信呼び出し（group communication calls）（例えば支払請求可能なイベント）に関連する情報を収集する。収集されたイベントは、ローカルの一時的なデータベース（ローカルログサーバ２２４）に格納され、集中ＣＭノード２１０内の中央ログサーバ２０２へ転送される。中央ログサーバ２０２は、商用データベースマネジメントシステム（ＤＢＭＳ）のようなロバストな持続性のあるデータベースを含めてもよい。ノード上で動作する、またはそのノードに関連する、ＣＭシステム１６０の全てのコンポーネントは、そのノード上で動作するローカルログサーバ２２４にイベントを報告する。いくつかの実施形態では、ログサーバ２２４にイベントを報告するＣＭシステム１６０のコンポーネントは、例えば、特定のＭＳＣに登録されたグループ通信加入者装置を含んでいてもよい。他の実施形態では、そのコンポーネント（おそらく異なるＭＳＣに登録されている）ネットワークに属する加入者装置を含んでいてもよい。
【００２６】
ローカルログサーバ２２４と中央ログサーバ２０２は、同一のインターフェースを使用し、クライアントに同様のサービスを提供してもよい。中央ログサーバ２０２は中央請求ログサーバ２０２と呼ばれてもよい。場合によっては、ローカルログサーバ２２４はＣＭコア２００と同じノード上で実行してもよい。
【００２７】
いくつかの実施形態では、もし中央ログサーバ２０２とほかのＣＭコンポーネントが同じノード上にあり、付加的なローカルログサーバが必要であると明確でない場合は、中央ログサーバがＣＭコアローカルログサーバ２２４の責任を引き受けることができる。
【００２８】
中央ログサーバ２０２はよりロバストなリレーショナルデータベース（例えばリレーショナルデータベース）を用いてもよい。一方でローカルログサーバ２２４は従来のフラットファイルをイベントロギングに用いていてもよい。フラットファイル・データベースシステムにおいて、それぞれのデータベースは単一のテーブルに含まれている。一方、リレーショナルデータベースシステムでは、情報を格納する複数のテーブルを用いており、さらにそれぞれのテーブルでも異なる記録方式を持っている。
【００２９】
中央ログサーバ２０２とローカルログサーバ２２４とのほかの差異は、データ送出および支払請求可能なイベントデータの流れの点にある。ローカルログサーバ２２４は、中央ログサーバ２０２に支払請求可能なイベントデータを送るが、支払請求可能なイベントデータではないデータは、中央ログサーバ２０２からローカルログサーバ２２４にもどる。中央ログサーバ２０２はイベントデータのためのロバストな保存場所（repository）の役割を果たす。
【００３０】
イベントデータは、変数、パラメータおよび支払請求可能なイベントの様々な組合せに基づいた、異なる請求スキーム（billing scheme）の各種取り合わせでそれを用いる異なる通信サービスプロバイダへ向かって最終的に進んでいく。
【００３１】
ＣＭシステム１６０は、請求目的に応じて異なるサービスプロバイダによって必要とされる様々なタイプのイベントデータを収集し管理することにとって、ロバストだが柔軟なシステムを提供する。しかし、イベントデータはローカルノードからサービスプロバイダに直接は提供されない。その代わり、中央ログサーバ２０２に格納されたデータに対してサービスプロバイダが請求目的のためにアクセスしたり、中央ログサーバ２０２がサービスプロバイダにデータを提供してもよい。
【００３２】
ローカルログサーバ２２４に格納されたデータは、中央ログサーバ２０２に転送されるまで、サービスプロバイダによってアクセスされることは許可されない。
【００３３】
ローカルログサーバ２２４は、中央ログサーバ２０２にイベントを直ちに転送することは要求されない。ローカルログサーバ２２４は蓄積交換方式として動作し、イベントをフラットファイルデータベースに局所的に格納し、その後、都合のよいときもしくは予め決定されたデータの転送スキームに従って、これらのイベントを、より高度なリレーショナルデータベースに格納するために中央ログサーバ２０２へ転送する。
【００３４】
データ転送スキームは、データを転送するために所定の時間を必要とするだろう。例えば、最後のデータが送信された後に一定時間を経過した後、スケジュールに従って、または毎日の終わりに呼び出しのピーク時でない時間帯である。
【００３５】
データ転送スキームは、通信システム１００の通信頻度のレベルを検出し、相対的に通信頻度が低い時間にデータを転送することを含んでもよい。データ転送スキームはローカルログサーバ２２４の容量が満たされる限度を測定し、その日（または週、月など）の一定時間が満たされるか、ローカルログサーバ２２４の最大容量の内のあるパーセンテージまで満たされる、例えば７５パーセントや、ほかの似たようなパーセントまで満たされたときにデータを転送するといったことを含めてもよい。
【００３６】
いくつかの実施形態では、データは同期コマンドに応じて転送されてもよい。同期コマンドを受信するとすぐに、ローカルログサーバ２２４は、中央ログサーバ２０２にローカルに記録されたイベントを転送する。中央ログサーバ２０２は、データベースアクセスサーバを用いて、そのすべてのクライアント（例えば個々のローカルログサーバ２２４）から持続性のあるデータベース（例えばＤＢＭＳ）に受信したイベントを運用する。
【００３７】
ローカルログサーバ２２４は、典型的に、中央サーバ２０２にイベントを直接ロギングするためのシステムの要求と比較して、これらのイベントを局所的にロギングするのにより簡単でより迅速な手段を用いる。
【００３８】
イベントをローカルログサーバ２２４に局所的に記録するのには、より簡単で、かつより迅速な傾向がある一方、ローカルログサーバ２２４はそれほどロバストでない傾向がある。これは、ＮＢＳメディアシグナリング（NBS media signaling）、オーバヘッドメッセージの通信、要求、承認などのような目的のために処理帯域幅をあけておくことが必要だからである。ＣＭシステム１６０はバックグラウンドスレッドをもち、優先度を低く実行し、よりロバストなデータベースの中へ記憶するために中央ログサーバ２０２へ局所的に格納されたイベントをディスパッチ（dispatch）する。
【００３９】
図２に示されたＣＭシステム１６０は、ＣＭコア複合体２００のコンポーネントとして設定されるＣＭノード２１０と、少なくとも１つのＭＣＵノード２２０−２２２として図示されるメディア制御ユニットを含んでいる。
【００４０】
ＭＣＵノード２２０−２２２は、時にローカルノード、発信ノード（originating node）、ネットモジュールと呼ばれるかもしれない。ＣＭシステム１６０はまた、種々の機能を実行するために１つ以上の運用ワークステーション２４０や、ＳＩＰ  ＵＡＳ２０８、ドメインネームサービス（ＤＮＳ）サーバ（図示せず）のような他の要素を含んでいる。
【００４１】
例えば、ＤＮＳサーバは、インターネット・ネットワークアドレスにＤＮＳホスト名のマッピングをすることを制御する。ＳＩＰ  ＵＡＳサーバ２０８は、ネットリストに関してユーザーリクエストに答えて、ネットのＳＩＰ招待メッセージに応答する働きをもつ。ＳＩＰは、ＡＳＣＩＩプロトコルを使用し、ネットのメンバー間のグループ通信を制御する。ＳＩＰ  ＵＡＳサーバ２０８は、加入者装置からＳＩＰ要求を受信し、その要求に応答する責任を負うホスト役を務めるアプリケーションである。
【００４２】
ＳＩＰ(session initiation protocol)（セッション設定プロトコル）およびＮＢＳ（net broadcast service）クライアントと交換されたＮＢＳ（net broadcast service）メッセージは、イベントと考慮されない。しかしながら、これらのメッセージは、製品開発中にデバッグすることを容易にするメッセージコンテンツ（例えばアスキー・テキストフォーマットで）として記録されてもよい。ロギングサービスは、フラットファイルにおいてそのようなメッセージを局所的に記録する一定のインターフェースとして役立ててもよい。
【００４３】
このサービスのユーザは、メッセージログインターフェースを呼び出す間に定型化されたメッセージを提供する。このメッセージログインターフェースは、記録されたメッセージのオン、オフのトグルを選択的に行うフィルタを実行してもよい。これらのフィルタは、イベントを記録するために用いられるフィルタとは異なり、クライアントの構成の一部として格納されてもよい。
【００４４】
ＣＭシステム１６０は、２つの主要な部分に分割できるコンポーネントを具備するものとして考えてもよい。その主要な部分とは、集中ＣＭノード２１０と、通信システムの全体にわたって分散している１つ以上のローカルＭＣＵノード２２０である。加入者装置の登録のための初期セッションは、ＣＭノード２１０の管理の下で行なわれる。
【００４５】
初期セッションの後、異なる加入者装置のネットは１つ以上のローカルＭＣＵノード２２０−２２２によって操作される。
【００４６】
ＭＣＵノード２２０は、ＣＭノード２１０からおよびＣＭノード２１０へネット操作のための情報を通信するように設定される。
【００４７】
一旦それが確立されたならば、ＭＣＵノード２２０−２２２のうちの１つがネットを操作する。一旦特定のネットが確立されれば、ＣＭノード２１０とＭＣＵノード２２０の間の機能と能力の分割することは、汎用的にロバストなシステムを保証する。このように、ＣＭノード２１０はネットが動作するように設定される通信構造のタイプについて、多大な柔軟性を持って他のネットと初期接続を提供することが可能である。
【００４８】
集中ＣＭノード２１０はネットに対する初期登録を行い、加入者装置を既存のネットに参加させる。加えて、請求情報は、ＣＭノード２１０の中央ログサーバ２０２内に集められる。例えば、ＣＭシステム１６０は、中央ログサーバ２０２の持続的なデータベースへ個々のイベントのロギングを、選択的にトグルする支払請求可能なイベントフィルタを含む設定してもよい。
【００４９】
つまり、フィルタは、どの個々のイベントが支払請求可能なイベントとして収集され格納されるかを決定する。
【００５０】
このフィルタは、ＣＭシステム１６０の柔軟性を高めるように設計されていて、いかなる時でも変更したり、メンテナンスルーチンの一部として更新したりすることが可能である。フィルタパラメータの変更は、全てのローカルログサーバ２２４に広められる。
【００５１】
支払請求可能なイベントフィルタは、イベントログマスク、パラメータ収集ルーチン、支払請求可能なイベント情報の明細書等のような他の名前で呼ばれてもよい。ログサーバインターフェースは、そのクライアント（例えばローカルログサーバ２２４）によって中央ログサーバ２０２に報告された望まれないイベントをフィルタリングして提供されてもよい。ＭＣＤノードのローカルログサーバインターフェースは、中央ログサーバ２０２へ望まないイベントを転送する前に、もしくはこれらを局所的に書き込む前に、ＭＣＵマネージャー２２６から受け取った望まないイベントをフィルタリングして提供されてもよい。なぜならば、一旦この望まないイベントを局所的に書き込んだ場合は、典型的に中央ログサーバ２０２へ書き込む前にはフィルタリングはできないからである。
【００５２】
ＣＭノード２１０はまた、ＣＭシステム１６０の運用機能および保守機能をサポートし制御する。加入者装置からのネットリストの要求は、ＣＭノード２１０内で管理される。ＣＭノード２１０は、ＭＣＵノード２２０に加入者装置を割り当てることにより、加入者装置からのセッション設定プロトコル（ＳＩＰ）招待メッセージに応答する。いくつかの運用機能はＣＭマネージャー２０４によってＣＭノード２１０内で行なわれる。例えば、ＣＭマネージャー２０４は、ネットの生成と削除や、既存のネットに加入者装置を加えたり消去したりするような様々なネット運用機能を制御する。
【００５３】
ＣＭマネージャー２０４はまた、種々のネットに参加したＭＣＵノードの状態をモニタし、特定のＭＣＵノードにネットを割り当てるかまたは再割り当てをしてもよい。ネットに所属している加入者装置がどこに位置しているかによって、ＣＭマネージャー２０４は、最も近いＭＣＵノードにネットを割り当ててもよい。ネットワーク接続の常識からいって加入者数が最大のネットに割り当ててもよい。
【００５４】
上述したように、中央ログサーバ２０２は主に、通話時間、通話時刻、通話によって測定された二地点間の距離、ＩＤ情報およびその他の支払請求可能なイベントのようなものを集めて格納するために用いられる。中央ログサーバ２０２は、種々のローカルＭＣＵノード２２０がもつ各々のローカルログサーバ２２４から支払請求可能なイベント情報を集める。支払請求可能なイベントは、すべてのグループ通信パラメータに関係する加入者装置からの情報を含んでいる。そのパラメータは通信管理システム１６０において有効な異なるネット上で起こる請求対象のグループ通信に用いられる。
【００５５】
イベントは、提供された目的に基づいた異なるイベントタイプへ分類されてもよい。ある実施形態では、イベントは以下の５つのイベントタイプへ分類される：
１．支払請求可能なイベント（あるいはサービス使用イベント）；
２．システムイベント；
３．構成管理イベント；
４．セキュリティイベント；および
５．警戒／アラーム
これら５つのイベントタイプは、それぞれサブタイプへさらにまとめられてもよい。例えば、各イベントタイプに関連して以下に述べられるようにまとめることができる。
【００５６】
中央ログサーバ２０２およびローカルログサーバ２２４によって実行されたイベントロギングサービスは、ＣＭシステム１６０の存続期間に生成されたイベントを記録する責任がある。記録されたイベントは異なるタイプのユーザに異なる目的を提供する。例えば、サービスプロバイダの経理部は、ビジネスイベント（例えば支払請求可能なイベントまたはサービス使用データ）およびいくつかの設定管理イベントにのみ関心があるかもしれない。一方、運用上のユーザは、仕事と関係がないイベント（例えばシステムイベント、構成管理イベント、セキュリティイベントおよび警告やアラーム）にたいてい関心があるだろう。
【００５７】
典型的に、ビジネスイベント（例えば支払請求可能なイベント）の数は、他のビジネスと関係がないイベントの数を超える。従って、ビジネスイベントのロギングは、より多くのデータベース資源が必要で、さらには実行により多くの時間がかかる傾向があり、より大量のデータが発生するかもしれない。いくつかの実施形態では、イベントデータベースは所定の時間だけイベントを格納するようにしてもよい。より古いイベントは、アーカイブされるかおよび／または最終的にイベントデータベースから（例えば中央ログサーバ２０２から）削除されてもよい。それとして、アーカイブされたイベントは、処理目的や表示目的のためには容易に利用できないかもしれない。最新のイベントは、データベースに存在し、処理または表示のために用いることが可能なイベントである。最新のイベントは中央ログサーバ２０２に格納されたイベントとして定義されてもよい。および最新のイベントは、必ずしもローカルログサーバ２２４に属するイベントを含んでいなくともよく、中央ログサーバ２０２にまだアップロードされていないイベントでもよい。
【００５８】
支払請求可能なイベントは、ＮＢＳグループ通信サービスの使用に対する、サービスプロバイダの顧客への請求金額の計算に使用する際に、サービスプロバイダが選択することができるイベントである。支払請求可能なイベントのサブタイプとしてNetEvent、FloorEventおよびUserEventを含んでいてもよい。支払請求可能なイベントのサブタイプであるNetEventは、支払請求可能なイベントであるNetStartedEvent、NetShutdownEventおよびNetDormantEventを含んでいてもよい。NetStartedEventは、新しいネットが始められる場合はいつでも、ＭＣＵによって報告される支払請求可能なイベントである。NetShutdownEventは、既存のネットがシャットダウン（shutdown）している場合はいつでも、ＭＣＵによって報告される支払請求可能なイベントである。これらの支払請求可能なイベントは、グループ通信の通話時間を追跡するために用いられてもよい。他のそのような支払請求可能なイベントは、ネットの全てのメンバーまたはネットの各メンバーのグループ通信呼び出しの継続時間を、算出または追跡をするために集められてもよい。別の支払請求可能なイベントであるNetDormantEventは、ネットが休止状態から出る場合はいつでも、ＭＣＬＩによって報告されたイベントである。
【００５９】
支払請求可能なイベントのサブタイプFloorEventは、支払請求可能なイベントPTTGrantEventおよびPTTReleaseEventを含んでいてもよい。PTTGrantEventは、加入者装置が通話の許可を与えられる時、ＭＣＵによって報告される支払請求可能なイベントである。PTTReleaseEventは、加入者装置がフロア（floor）を解放するか、または加入者装置がタイムアウトまたはＰＴＴ要求により優先度の高いユーザからフロア（floor）を解放することを強いられる時、ＭＣＵによって報告される支払請求可能なイベントである。支払請求可能なイベントのサブタイプUserEventは、支払請求可能なイベントUserjoinedEventおよびUserQuitEventを含んでいてもよい。UserjoinedEventは、ＭＣＵが新しい加入者装置が正常にネットに参加することを報告する支払請求可能なイベントである。UserQuitEventは、ＭＣＵが既存の加入者装置がネットを止めることまたはネットから強制的に退出されることを報告する支払請求可能なイベントである。
【００６０】
システムイベントは、一般的にＣＭマネージャー２０４、ＳＩＰ  ＵＡＳサーバ２０８、ＭＣＵマネージャー２２６等のような異なるシステム装置（例えばＣＭシステム１６０のコンポーネント）の性能をモニタするために用いられる。システムイベントは、スタートアップ、シャットダウン、失敗および回復動作のようなシステム操作の結果として生成される。システムイベントのサブタイプは、SystemManagementEvent、DataManagernentEvent、ConfigltemCreateEvent、ConfigDeleteEventおよびConfigltemModifyEventを含んでいてもよい。システムイベントのサブタイプであるSystemManagementEventは、システムイベントUnitStartupEvent、UnitShutdownEvent、UnitFailureEventおよびUnitRecoveredEventを含んでいてもよい。UnitStartupEventは、ＣＭシステム１６０の他のすべてのコンポーネントが起動中である後に、ＣＭマネージャー２０４によって登録されるシステムイベントである。ＳＩＰ  ＵＡＳ２０８は、それが正常にその初期化を完了しており、ＮＢＳクライアントから（例えば加入者装置から）ＳＩＰ  ＩＮＶＩＴＥＳを受け入れる準備ができているとき、コンポーネントの状態を報告する。
【００６１】
ＭＣＵマネージャー２２６は、ＭＣＵログサーバ２２４とＭＣＵマネージャ２２６が管理するノード上のすべてのＭＣＵが起動中となった後に、UnitStartupEventシステムイベントを送る。UnitShutdownEventは、ＣＭシステム１６０のコンポーネントが正常にシャットダウンした後に、ＣＭマネージャー２０４によって報告されるシステムイベントである。ＳＩＰ  ＵＡＳ２０８は、それが正常にシャットダウンを完了しており、もはやＮＢＳクライアントからのＳＩＰ  ＩＮＶＩＴＥＳを処理することができない場合は、これを報告する。ＭＣＵマネージャー２２６は、自身が管理するノード上のＭＣＵがすべてシャットダウンした後にこのイベントを送る。UnitFailureEventは、ＣＭマネージャー２０４およびＭＣＵマネージャー２２６によって管理された１つ以上のシステムのコンポーネントがもはや応答しない、およびこれらのコンポーネントが動作しないかもしれないと検知したものをＣＭマネージャー２０４およびＭＣＵマネージャー２２６によって報告されるシステムイベントである。UnitRecoveredEventは、動作しないコンポーネントの回復に成功したことを、ＣＭマネージャー２０４およびＭＣＵマネージャー２２６によって報告されるシステムイベントである。システムイベントのサブタイプであるDataManagernentEventは、システムイベントSyncEventおよびArchivalEventを含んでいてもよい。SyncEventは、運用上のクライアント（例えば運用ワークステーション２４０)による同期要求の指定的な実行を、ＣＭマネージャー２０４によって報告されるシステムイベントである。ArchivalEventは、運用上のクライアントによるアーカイブ要求の実行を、ＣＭマネージャー２０４によって報告されるシステムイベントである。
構成管理イベントは、典型的にＣＭシステム１６０の構成データベースが変えられるときはいつでも生成される。構成データベースは、ネット、ネットユーザ、システムパラメータおよびそのような要素のための静的な情報を保持する。構成管理イベントのサブタイプはConfigltemCreateEvent、ConfigltemDeleteEventおよびConfigltemModifyEventを含んでいてもよい。構成管理イベントのサブタイプConfigltemCreateEventは、構成管理イベントUserCreatedEventおよびNetCreatedEventを含んでいてもよい。UserCreatedEventは、データベースに新しい加入者装置の追加が成功したときに、運用サーバ２４０によって報告される構成管理イベントである。
【００６２】
NetCreatedEventは、ＣＭデータベースに新しいネットの追加が成功したときに、サーバ２４０によって報告される構成管理イベントである。構成管理イベントのサブタイプであるConfigltemDeleteEventは構成管理イベントUserDeletedEventおよびNetDeletedEventを含んでいてもよい。UserDeletedEventは、データベースから正常に既存の加入者装置を削除することを、運用サーバ２４０から中央ログサーバ２０２へ報告される構成管理イベントである。
【００６３】
報告されたエントリーの数を制限するものを除いたすべてのイベントのためのクエリ；
特定のイベントのためのクエリ；
なんらかの制限のある時間フレームの間で発生したイベントのためのクエリ；
特定のネット例のイベントのためのクエリ；
特定のノード用のイベントのためのクエリ；
および特定ユーザのイベントのためのクエリ
情報管理用イベントおよびそれに関連する支払請求可能なイベント上で行うクエリは、膨大なデータを生成して処理に多くの時間がかかる傾向がある。
【００６４】
そのため、いくつかの実施形態では、そのようなクエリはバッチサブミッションとして実行されるか、またはオンラインオプションとして提供されないかもしれない。
【００６５】
図３は、ＭＣＵノード２２０の中のローカルログサーバ２２４から、ＣＭノード２１０の中の中央ログサーバ２０２へ支払請求可能なイベントデータを通信する方法３００を示したフローチャートである。この通信方法は３０１に始まり、３０３へ進んで、グループ通信が始められているかどうかが決定される。いくつかの実施形態では、集中ＣＭノード２１０は、呼び出しを行なうネットが登録されるローカルＭＣＵノード２２０にグループ通信呼び出しの通知を送る。他の実施形態では、グループ通信を始める加入者装置から直接ＭＣＵノード２２０にメッセージが送られてもよい。もしＭＣＵノード２２０がグループ通信について通知を受けていない場合、３０３において「ＮＯ」に沿って３０５へ進み、グループ通信が始められるのを待つ。３０３において、一旦グループ通信が始められた場合、「ＹＥＳ」に沿って３０７へ進む。
【００６６】
３０７において、ローカルＭＣＵノード２２０は、ネットに関する情報にアクセスする。そのような情報は、ネットメンバーのＩＤ、サービスプロバイダ、どのネットメンバーがアクティブでグループ通信に参加しているか、どのネットワークメンバーが一時的に非アクティブであるけれどもコンタクトが確立されると通信に参加するか、グループ通信によるネットメンバーの費用請求に属するどんな制限やルールがあるか、ネットメンバーが受ける費用の額についてどんな制限があるか、またはそのようなタイプの情報が含まれている。一旦適用可能なネット情報が３０７において検索されたならば、３０９に進みサービスプロバイダのための支払請求可能なイベントフィルタを検索する。
【００６７】
支払請求可能なイベントフィルタは、個々のイベントのうちどれが支払請求可能なイベントとして集められ格納されるかを決定する。これは、サービスプロバイダが興味のあるパラメータを指定することを許可し、ＣＭノード２１０の中に支払請求可能なイベントフィルタが用意され、どのパラメータが支払請求可能なイベントとして集められ保存されるかを制御するために、そのフィルタはローカルＭＣＵノード２２０にダウンロードされる。イベント収集用のフィルタによって指定されうる支払請求可能なイベントのいくつかの例としては、NetStartedEvent、NetShutdownEvent、UserjoinedEvent、UserQuitEvent(上述したように）または他の支払請求可能なイベントのようなものを含んでいる。支払請求可能なイベントフィルタは、特定のサービスプロバイダのすべてのネットのために提供されてもよいし、またはシステムが各々のネット、および同一の請求プランを設定するネットグループのために支払請求可能なイベントフィルタを格納してもよい。
【００６８】
データは、支払請求可能なイベントフィルタを用いずに、イベントのデフォルトセットを規定するか利用可能なイベントをすべて集めるかのどちらかにより集められてもよい。３０９において支払請求可能なイベントフィルタが検索され、もしあるなら、３１１に進む。
【００６９】
３１１では、グループ通信に関係するデータが集められる。収集されたデータは、支払請求可能なイベントフィルタによって制御または指定される。データは、ＭＣＵノード２２０において通信システムのいたるところからメッセージを受信することにより集められてもよい。それは例えば、種々の支払請求可能なイベントを測定するまたはアクセスするために設置された、通信システムの中のどこかほかの場所、例えばタイマー、制御論理およびストレージレジスターからである。
【００７０】
一旦適切な支払請求可能なイベントがＭＣＵノード２２０で集められたならば、３１３に進み、ローカルログサーバ２２４においてデータの格納を行う。ローカルログサーバ２２４は、イベントが代わりに中央サーバ２０２に直接格納される場合に要求されるよりもこれらのイベントをより簡単で迅速な方式で局所的に記録するために通常は設計されている。いくつかの実施形態では、イベントの格納は、高度なリレーショナルデータベースにおいてというよりはむしろフラットファイルにデータを格納することにより達成される。一旦支払請求可能なイベントがローカルログサーバ２２４に記録されたならば、３１５に進む。
【００７１】
ＣＭシステム１６０は、蓄積転送システムとして設計され、支払請求可能なイベントがローカルログサーバ２２４に最初に記録されて、次にデータは中央のサーバ２０２に移動する。ブロック３１５では、データがその時に転送されるかどうかが決定される。支払請求可能なイベント情報は、ＭＵＣノード２２０で同期コマンドを受信することに応じて転送されてもよい。同期命令を受信する際、ローカルログサーバ２２４は、局所的に記録されたイベントを中央ログサーバ２０２へ転送する。ローカルログサーバ２２４もまたデータ転送スキームに従って収集された支払請求可能なイベント情報を転送するように設定してもよい。データ転送スキームは例えば、ある時間が経過した後、またはローカルログサーバ２２４内のデータが所定の容量に達する場合である。
【００７２】
ブロック３１５では、支払請求可能なイベントデータが転送されると決定した場合は、３１５の「ＹＥＳ」に沿って、３１７へ進み中央ログサーバ２０２に転送される。一旦そのデータが転送されれば、ローカルログサーバ２２４が受領の承認を受け取ることを必要として、次に３１９へ進む。
【００７３】
３１５に戻ると、請求イベントデータがそのときに転送されないと決定された場合、３１５の「ＮＯ」に沿って３１９へ進む。
【００７４】
３１９では、中央ＣＭノード２１０からローカルノード２２０へいずれかの更新、修正またはダウンロードされるべき新情報があるかどうかが決定される。そのようなダウンロードは、ソフトウェアの更新、ネットまたは加入者装置に関する１つ以上の更新情報、支払請求可能なイベントフィルタまたはデータ転送スキームの修正、またはＭＣＵノード２２０のソフトウェア、ルーチンまたはデータへの他のそのような変更を含む。３１９では、もしＭＣＵノード２２０に更新または新情報があると決定された場合、「ＹＥＳ」に沿って３１９から３２１へ進み、任意のそのような情報も受信し、ＭＣＵノード２２０にそれを実行する。一旦３２１で更新が組み入れられたならば、３２３に移る。３１９に戻ると、ＭＣＵノード２２０に更新または新情報がないと決定した場合、「ＮＯ」に沿って３１９から３２３に進む。
【００７５】
３２３のブロックでは、ＭＣＵ２２０ノードが使用可能のままであるかどうかを決定する。時々ノードは、メンテナンスのためにオフラインになったり、偶然にも電源異常等によりオフラインになったりするかもしれない。もしＭＣＵ２２０ノードが使用可能のままであることである場合、「ＹＥＳ」に従って３２３から３０５へ進み、別のグループ通信を待つ。しかし、もし３２３でＭＣＵ２２０ノードがシャットダウンされるか、オフラインになることが決定された場合、「ＮＯ」に沿って３２３から３２５へ進み処理を終了する。
【００７６】
図は、本発明を説明することを可能とし、かつ本発明の原理を示すために提供される。図の方法ブロック図において示される本発明を実行するためのいくつかの動作は、図において示されるそれ以外の順に行なわれてもよいし、またはここに提供される代表的な説明以外の方法で、ある意味で説明されてもよい。例えば、ブロック３０７のネット情報にアクセスする動作は、３０９において支払請求可能なフィルタが検索されると同時に、またはそれに続いて行われてもよい。新しいグループ通信を待ち、探索を行う３０３および３０５においても、新しいグループ通信がいつでも、図３に示されたシーケンスにおいてＭＣＵノードが動作中のまま他の動作がいつでも同時に行われてもよい。さらに、種々の実施形態の多数のコンポーネントが、種々の実施形態を説明するためにここに用いられるもの以外の用語によって説明されてもよい。例えば、ここで用いられる「加入者装置」という用語は、ある例として、いくつかの実施形態の中で「ユーザ」という用語に置き換えられてもよい。（例えば、「加入者装置は通話の許可を得られる」という文は、「ユーザが通話の許可を得られる」という文と同じ意味に解釈される。）
当該技術分野において通常の知識を有する者は、情報または信号が様々に異なるテクノロジーおよび技術のうちのどれでも用いて表わされてもよいと理解する。例えば、上記の説明の全体にわたって参照されるデータ、命令、コマンド、情報、信号、ビット、シンボルおよびチップは、電圧、電流、電磁波、磁界または磁性粒子、光場または光子、またはそのいずれかの組み合わせによって表わされてもよい。
【００７７】
また、当該技術分野における通常の知識を有する者は様々な制御ブロック、実例となる方法のブロック図、種々の制御するロジック、実例となる方法ブロック、モジュール、回路、およびここに開示された実施形態に関連して説明されたアルゴリズムルーチンが、それの電子ハードウェア、コンピュータソフトウェア、ファームウェアまたは組合せとして実行されてもよいことを認識する。
【００７８】
明白にハードウェアおよびソフトウェアのこの互換性を示すために、種々の実例となるコンポーネント、ブロック、モジュール、回路およびステップは、それらの機能性に関して一般的に上述した。
【００７９】
そのような機能性がハードウェアまたはソフトウェアとして実行されるかどうかは、特にシステム全体のアプリケーションや設計の制約に依存する。
【００８０】
当該技術分野における通常の知識を有する専門家は、各特定用途の方法を様々な際に説明された機能性を実行することを知る。しかし、そのような実行判定は本発明の範囲から逸脱するとは解釈されないものとする。
【００８１】
ここに開示された実施形態に関連して説明された種々の実例となる論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向けＩＣ（ＡＳＩＣ）、フィールドプログラマブルゲートアレー（ＦＰＧＡ）または他のプログラマブルロジックデバイス、離散ゲートまたはトランジスターロジック、離散ハードウェア構成機器、または本実施形態で説明した機能を行うように設計されたそのいずれかの組み合わせにより、実行されるかまたは処理を行なわれてもよい。
【００８２】
汎用プロセッサはマイクロプロセッサかもしれないが、その代わりにプロセッサは、何らかの従来のプロセッサ、制御器、マイクロコントローラ、コンピュータまたはステートマシンでもよい。プロセッサも、コンピューティング装置（例えばＤＳＰおよびマイクロプロセッサの組合せ、複数のマイクロプロセッサ、ＤＳＰコアに関連して１つ以上のマイクロプロセッサまたは他のそのような構成）の組合せとして実行されてもよい。
【００８３】
ここに開示された実施形態に関連して説明した方法、ルーチンまたはアルゴリズムの動作は、ハードウェア、プロセッサによって実行されたソフトウェアモジュール、によって直接具体化されるか、または２つの組合せで直接具体化されてもよい。ソフトウェアモジュールは、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、登録、ハードディスク、取外し可能ディスク、ＣＤ−ＲＯＭまたは当該技術においてよく知られた記憶媒体の他の形式に属してもよい。代表的な記憶媒体は、プロセッサが情報を読み書きしてもよいようなプロセッサ（記憶媒体）に接続している。その変形例としては、記憶媒体はプロセッサに統合してもよい。プロセッサおよび記憶媒体はＡＳＩＣに属してもよい。ＡＳＩＣはユーザ端末に属してもよい。その変形例としては、プロセッサおよび記憶媒体はユーザ端末の個別部品として属してもよい。
【００８４】
図示され検討されていた実施形態の様々な変更は、当該技術において通常の知識を有するものには容易に明白になる。また、ここに定義された原理は、本発明の趣旨または範囲から逸脱せずに、他の実施形態に適用されてもよい。したがって本発明は、本明細書に示される実施形態に限定されることなく、本明細書に開示された原理および新規な特徴に対して最も広い範囲を与えることを意図している。例えばグループ通信、特にＰＴＴは、一般的に音声通信として考えられる。しかしながら、音声またはデータのいずれかはグループ通信として送信されてもよい。
【００８５】
本発明の種々の実施形態を説明する際に、特定の用語は図の目的および明瞭さのために用いられた。例えば、用語「ネット」が互いに通信することを認められた通信装置ユーザのグループを意味するために用いられた。しかしながら、本発明は、選択された特定の用語に制限するように意図していない。それぞれの特定の用語は、同様の目的で同様の方式において作用する技術的に同等な当業者に知られた同等の技術を含むことを意図する。従って、その説明は、本発明を制限するようには意図されない。本発明は、添付された特許請求の範囲内で広く保護されるように意図される。
【図面の簡単な説明】
【００８６】
明細書に組み込まれ、明細書の一部を構成し、本発明の種々の実施形態を図示し、典型的な描写とともに本発明の原理の説明することを提供する添付の図面。
【図１】グループ通信システムを示す図。
【図２】本発明の種々の実施形態を実装するための通信マネージャーを示す図。
【図３】ＭＣＵノードのローカルログサーバからＣＭノードの中央ログサーバまで請求可能なイベントデータを通信する方法を示すフローチャート。
【図１】
2009528795.tif 000003
【図２】
2009528795.tif 000004
【図３】
2009528795.tif 000005
【国際調査報告】
2009528795.tif 000006