(57)【要約】  ＩＰマルチメディアサービスに関する移動体の加入者のクレジットを留保する方法である。この方法は、ＩＰマルチメディアサービスの起動の前の、前記ＩＰマルチメディアサービスの前記加入者の初期登録に続いて、早期セッション確立処理を使用して、課金制御ノードでクレジット量を留保し、かつ前記クレジットの留保をＩＭＰマルチメディアサービングエレメントへ通知し、前記ＩＰマルチメディアサービスの起動時に、前記ＩＰマルチメディアサービングエレメントは、前記早期セッション確立処理に直ちに移行することが可能となる。
2008502035.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰマルチメディアサービスに関する移動体の加入者に対するクレジットを留保する方法であって、
ＩＰマルチメディアサービスの起動の前の、前記ＩＰマルチメディアサービスの前記加入者の初期登録に続いて、早期セッション確立処理を使用して、課金制御ノードでクレジット量を留保し、かつ前記クレジットの留保をＩＭＰマルチメディアサービングエレメントへ通知し
前記ＩＰマルチメディアサービスの起動時に、前記ＩＰマルチメディアサービングエレメントは、前記早期セッション確立処理に直ちに移行することが可能となる
ことを特徴とする方法。
【請求項２】
前記早期セッション確立処理は、ＤＩＡＭＥＴＥＲベースのプロトコルを使用する、前記ＩＰマルチメディアサービングエレメントと前記課金ノード間のメッセージの交換を含んでいる
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記早期セッション確立処理は、前記ＩＰマルチメディアサービスへの前記加入者の登録に続いて自動的に起動される
ことを特徴とする請求項１または２に記載の方法。
【請求項４】
前記早期セッション確立処理は、ＩＰマルチメディアサービスを起動する前記加入者によって起動される
ことを特徴とする請求項１または２に記載の方法。
【請求項５】
前記ＩＰマルチメディアサービスは、セルラーオーバープッシュ−ツー−トークＩＰマルチメディアサービスである
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記ＩＰマルチメディアサービングエレメント及び前記課金制御ノードの内の１つは、前記ＩＰマルチメディアサービスに対して適切なクレジット量を見積もる
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記加入者は、プリペイド加入者であり、前記課金制御ノードは、前記加入者のホームネットワークに配置されているプリペイドシステムサーバである
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記ＩＰマルチメディアセッション時に、実際のセッション状態に基づいて、前記ＩＰマルチメディアサービングエレメントと前記課金制御ノード間のクレジット照会処理を実行して、クレジット量を調整し、前記見積もったクレジット量を前記調整したクレジット量に置き換える、あるいは該調整したクレジット量を補充する
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
移動体の加入者によるＩＰマルチメディアサービスへのアクセスを容易にするように構成されているＩＰマルチメディアサービングエレメントを操作する方法であって、
課金制御ノードとのトランザクションを開始して、該課金制御ノードにおいてクレジット量を留保する早期セッション確立処理の一部として、前記ＩＰマルチメディアサービスの加入者の初期登録を続行する
ことを特徴とする方法。
【請求項１０】
ＩＰマルチメディアサービスへの加入者アクセスを制御するように構成されている課金制御ノードを制御する方法であって、
前記ＩＰマルチメディアサービスの起動の前に、前記ＩＰマルチメディアサービスの加入者の初期登録を続行する早期セッション確立処理に参加し、前記課金制御ノードは、将来のセッションに対して留保するべき適切なクレジット量を見積もる
ことを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の分野
本発明は、ＩＰマルチメディアサービス用の課金メカニズムに関するものであり、これは、特に、但し必須ではないが、セルラーオーバープッシュツートークサービス（Push-to-talk over Cellular services）に適用可能である。
【０００２】
本発明の背景
ＩＰマルチメディアサービスは、同一セッション内で、音声、ビデオ、メッセージング、データ等を動的に組み合わせて提供する。基本アプリケーションと、組み合わせることが可能となるメディアの数が増えることによって、エンドユーザへ提供されるサービスの数も増え、また、個人間通信の経験も充実することになる。このことは、新世代の、パーソナライズされた、より充実したマルチメディア通信サービスをもたらすことになるであろう。
【０００３】
ＩＰマルチメディアサブシステム（ＩＭＳ）は、第３世代パートナシッププロジェクト（３ＧＰＰ）によって定義される技術であり、これは、３Ｇ移動通信ネットワークを介するＩＰマルチメディアサービスを提供する。ＩＭＳは、サービスの統合と対話を介して、エンドユーザの個人間の通信経験を充実させるための鍵となる機能を提供する。ＩＭＳは、ＩＰベースのネットワークを介して、新規の充実した個人間（クライアント間）通信と、個人対コンテンツ間（クライアント対サーバ）通信を可能にする。このＩＭＳは、セッション開始プロトコル（ＳＩＰ）とサービス搬送プロトコル（ＳＤＰ）を使用して、ユーザ端末（あるいはユーザ端末とウェブサーバ）間の呼あるいはセッションをセットアップし、かつ制御する。図１は、移動体ネットワークアーキテクチャにＩＭＳがどのように適合しているかを示している。
【０００４】
既存のセルラー電話ネットワークオペレータは、近年、いわゆる「プリペイド」加入を使用することを選択する加入者数の著しい増加を経験している。この「プリペイド」加入は、加入者が、現金額（クレジットバランス（預金残高）（credit balance））を自身のオペレータに寄託するものであり、これは、加入者が次回のサービスを使用することによって消費されるものである。プリペイド加入のオプションは、ＩＰＭＭサービスのユーザと等しくポピュラーのものになることが判明することは予想されることである。事実、プリペイドサービスの提供は、ＩＰＭＭサービスで広く取り上げるために必須なものになると思われる。
【０００５】
オンライン／リアルタイム課金メカニズムが使用される場合（プリペイドユーザに関しては）、リクエストされたサービスへのアクセスを提供するＩＰＭＭサービングエレメント（ＳＥ）に対しての一般ルールは、そのリクエストされたサービスへの移動ノードのアクセスを許可する前にクレジット（信用）照会をリクエストすることである。しかしながら、ＩＰＭＭ  ＳＥが、プリペイドシステム（ＰＰＳ）あるいはオンライン課金システム（ＯＣＳ）とも呼ばれる課金制御ノードとのクレジット照会取引を行わなければならないので、プリペイド加入者に対するセッションセットアップ時間は必然的に増大することになるであろう。
【０００６】
いくつかのＩＭＰＰ／ＩＭＳベースのサービスに対しては、セッションセットアップ時間は重要である。このことは、例えば、インスタントパーソナルトーク及びアドホックインスタントグループトークのような、いわゆるセルラーオーバープッシュツートーク（Push-to-talk over Cellular：ＰｏＣ）サービスに当てはまる。これは、発信者が、自身の端末のＰｏＣボタンを操作して、ウォーキー−トーキータイプセッションに１人以上のユーザを招待し、その招待したパーティ／パーティ群と瞬時に連絡を取ることを求めるものである（テレフォニーサービスに基づく、伝統的な発信、呼び出し、応答に対して）。現在提案されているプリペイド支払メカニズムの導入は、受入不可能なレベルまでのＰｏＣセッションセットアップ時間が悪化する可能性がある。あるいは、クレジット照会フェーズで発生する更なる遅延のために、ユーザは最適な状態には及ばない経験を蒙る可能性がある。
【０００７】
本発明の要約
本発明の目的は、実際のかつ認められる加入者サービスレベルにおけるプリペイド支払メカニズムの影響を未然に防ぐことである。
【０００８】
本発明の第１の構成に従えば、ＩＰマルチメディアサービスに関する移動体の加入者に対するクレジットを留保する方法が提供される。
【０００９】
この方法は、
ＩＰマルチメディアサービスの起動の前の、前記ＩＰマルチメディアサービスの前記加入者の初期登録を続行し、
早期セッション確立処理を使用して、課金制御ノードでクレジット量を留保し、かつ前記クレジットの留保をＩＭＰマルチメディアサービングエレメントへ通知し、
前記ＩＰマルチメディアサービスの起動時に、前記ＩＰマルチメディアサービングエレメントは、前記早期セッション確立処理に直ちに移行することが可能である
ことを特徴とする。
【００１０】
前記早期セッション確立処理は、前記ＩＰマルチメディアサービングエレメントと前記課金ノード間の適切なメッセージの交換を含むことになることを明らかであろう。このメッセージは、ＤＩＡＭＥＴＥＲプロトコルの仕様を満足するものである。
【００１１】
前記早期セッション確立処理は、典型的には、前記加入者の端末（ＵＥ）とＩＭＳサーバ間のサービス交渉目的（例えば、メディアアドレス及びコーデックタイプ）のためにも使用されることになる。
【００１２】
前記セッション確立処理は、前記ＩＰマルチメディアサービスの前記加入者の登録に続いて自動的に起動することができる。あるいは、前記セッション確立処理は、例えば、自身の端末で特定のＩＰマルチメディアサービスを起動する加入者／エンドユーザによって起動することができる。
【００１３】
本発明は、特に、必須ではないが、プッシュ−ツー−トークオーバーセルラー（ＰｏＣ）ＩＰマルチメディアサービスに適用可能である。
【００１４】
本方法は、前記ＩＰマルチメディアサービングエレメント及び前記課金制御ノードの内の１つで、前記ＩＰマルチメディアサービスに対して適切なクレジット量を見積もることを含んでいる。好ましくは、この見積もりは、前記課金制御ノードで実行される。
【００１５】
プリペイド加入者の場合には、前記課金制御ノードは、前記加入者のホームネットワークに配置されるプリペイドシステム（ＰＰＳ）サーバとなる。
【００１６】
好ましくは、本方法は、前記ＩＰマルチメディアサービスの起動時に、調整されたクレジット量をリクエスト／起動している実際のサービスに基づいて、前記ＩＭマルチメディアサービスエレメントと前記課金制御ノード間のクレジット照会処理を実行する。前記見積もられたクレジット量は、調整されたクレジット量に置き換えられる。
【００１７】
本発明の第２の構成に従えば、移動体の加入者のＩＰマルチメディアサービスへのアクセスを容易にするように構成されているＩＰマルチメディアサービングエレメントを制御する方法を提供する。この方法は、
前記ＩＰマルチメディアセッションの開始の前に、該ＩＰマルチメディアサービスの加入者の初期登録を続行し、課金制御ノードとの早期セッション確立処理を開始して、前記課金制御ノードにおいてクレジット量を留保する
ことを特徴とする。
【００１８】
本発明の第３の構成に従えば、ＩＰマルチメディアサービスへの加入者アクセスを制御するように構成される課金制御ノードを制御する方法を提供する。この方法は、
前記ＩＰマルチメディアサービスの起動の前に、前記ＩＰマルチメディアサービスの加入者の初期登録を続行する早期セッション確立処理に参加し、前記課金制御ノードは、将来のセッションに対して留保するべき適切なクレジット量を見積もる
ことを特徴とする。
【００１９】
本発明の実施形態の詳細説明
ＩＰマルチメディアサブシステム（ＩＭＳ）セッションでは、いくつかの異なるＩＭＳオペレータの加入者であるユーザの数が存在し得る。任意の一般的に適用可能な課金処理では、自身が所有する課金ポリシーに従って、それぞれＩＭＳオペレータは自身が所有する加入者への課金を行うことを可能にするべきである。つまり、同一のＩＭＳセッションに対して、異なるネットワークについては異なる課金モデルが適用される可能性があると言える。また、異なる課金モデルは、与えられるオペレータのネットワークの範囲内で、同一のＩＰＭＭサービス／機能に対して、異なるセットの加入者に適用される可能性がある。
【００２０】
３ＧＰＰ  Ｒ５  ＴＳ  ３２．２２５とＴＳ  ３２．２００、及びＩＥＴＦ  ＤＣＣ（インターネットドラフト「Ｄｉａｍｅｔｅｒクレジット制御アプリケーション」）に従えば、ＩＭＳオンライン課金については２つの状況に区別される。
【００２１】
１）「ワンタイムイベント型自動引き落とし（One-Time Event with Direct Debiting）」状況。３ＧＰＰにおける「即時イベント型課金（Immediate Event Charging）」モデル。ＩＥＴＦ  ＤＣＣにおける「クレジット照会型自動引き落とし（Credit Authorization with Direct Debiting）」モデル。
【００２２】
２）「セッションベース型クレジットコントロール」状況。３ＧＰＰにおける「単位留保によるイベント型課金（Event Charging with Unit Reservation）」モデル。ＩＥＴＦ  ＤＣＣにおける「留保金によるクレジット照会（Credit Authorization with Money Reservation）」モデル。
【００２３】
両モデルにおいて、ＩＰＭＭサービングエレメント（ＩＰＭＭ  ＳＥ）、即ち、クレジット制御クライアントは、エンドユーザへの配信対象のサービスを許可する前に、オンライン課金システム（ＯＣＳ）／プリペイドシステム（ＰＰＳ）、即ち、クレジット制御サーバからクレジット照会を要求する。セッションベースのクレジット制御状況は、ほとんどのＩＰＭＭサービスに対してより適切なものとなるように考慮されていて、これは、本明細書で考慮された状況である。
【００２４】
セッションベースのクレジット制御は、ＰＰＳがＩＭＰＰ  ＳＥからのリクエストを格付し、ユーザアカウント（口座）（user account）から適切な金額を留保し、そして、対応する量のクレジットリソース（credit resource）をＩＰＭＭ  ＳＥへ通知する場合における処理である。もちろん、「クレジットリソース」は、実際の金銭的なクレジットであることを意味しなくてもよく、クレジットリソースは、従量制（be metered）の単位（データ量あるいは時間）の形態で与えられてもよい。クレジットリソースの量で、クレジット照会の回答として成功を受領すると、ＩＰＭＭ  ＳＥは、エンドユーザへのサービス配信を許可し、与えられるリソースの使用の監視を開始する。エンドユーザに許可されているクレジットリソースが消費される場合、あるいはサービスが正常に配信されるあるいは終了する場合、ＩＰＭＭ  ＳＥは使用量をＰＰＳへ報告し、ＰＰＳは、ユーザアカウントから使用量を差し引く（サービス配信が継続している場合、ＰＰＳは格付けを実行し、かつ新規のクレジット留保を行う）。この処理は、最初の問い合わせ、可能であれば、中間の問い合わせ、そして、最終の問い合わせを含んでいる。ＩＰＭＭ  ＳＥとＰＰＳの両方は、クレジット照会状態情報を維持するために必要とされる。
【００２５】
図２の上部は、ＩＰＭＭ用の一般的なオンライン課金アーキテクチャを示していて、一方、その図の下部は、ＰｏＣ用の簡略化アーキテクチャを示している。オンライン課金システム（ＯＣＳ）／プリペイドシステム（ＰＰＳ）は、リアルタイム課金メカニズム用の課金制御機能を提供する。プリペイドシステムは、アカウント（口座）残高（account balance）マネージャ及びユーザアカウント（ユーザ口座）、格付エンジン及び料金表情報を含んでいる。格付エンジンは、料金が設定されていないセッション／サービスあるいはソースに、即ち、サービングエレメントが料金を設定していないこれらのものの格付値を提供する。オンライン課金に対しては、課金入力をＰＰＳへ提供することができるＩＰＭＭ  ＳＥ群は、サービングコール（呼）セッション制御機能（Ｓ−ＣＳＣＦ：Serving-Call Session Control Function）、マルチメディアリソース機能制御（ＭＲＦＣ）及びアプリケーションサーバ（ＡＳ）である。セルラーオーバープッシュツートーク（ＰｏＣ）に対して、課金入力をＰＰＳへ提供するＳＥは、ＰｏＣサーバ（ＭＲＦ及びＡＳ機能を採用している）である。ＩＰＭＭ  ＳＥ群及びＰＰＳ間のインタフェースは、３ＧＰＰのリリース５及び６によって定義されているような、Ｄｉａｍｅｔｅｒベースプロトコル（ＤＢＰ）とＤｉａｍｅｔｅｒクレジット制御アプリケーション（ＤＣＣ）に基づいている。
【００２６】
図３は、ＰｏＣリリース２アーキテクチャを示していて、ここでは、ＰｏＣ機能エンティティは太実線で示されている。以下のインタフェースは、図３に示される。
【００２７】
Ｉｔ  ：フロア（発言権：floor）制御媒体（メディア：media）
Ｉｔｎ：フロア（発言権：floor）制御及び媒体
Ｉｓ  ：ＰｏＣクライアント対プロキシセッションシグナリング
Ｉｆ  ：プロキシ対ＰｏＣサーバセッションシグナリング
Ｉｎ  ：プロキシ対プロキシセッションシグナリング
Ｉｍ  ：グループ管理サーバ対ＰｏＣクライアント
Ｉｋ  ：グループ管理サーバ対ＰｏＣサーバ
Ｉｏ  ：ＯＴＡＰサーバ対ＰｏＣクライアント
ＰｏＣアーキテクチャは、２つのＰｏＣサーバ機能として、制御（controlling）ＰｏＣサーバ機能／論理エンティティと、参加（participating）ＰｏＣサーバ機能／論理エンティティを有している。各ＰｏＣトークセッションでは、１つの制御ＰｏＣサーバだけが存在する。これに対して、参加ＰｏＣサーバは１つ以上存在し得る。制御ＰｏＣサーバは、集中化タスクを取り扱う。このタスクは、ＰｏＣトークセッション内の２つ以上のＰｏＣサーバによって処理されるべきではない。ＰｏＣサーバは、制御ＰｏＣサーバあるいは参加ＰｏＣサーバのどちらかとして動作する。これは、ＰｏＣトークセッション単位で選択される。
【００２８】
ＰｏＣサーバの実装（即ち、物理的なエンティティ／ノード）は、制御ＰｏＣサーバと参加ＰｏＣサーバの両方として同時にかつ同一のＰｏＣトークセッションに対して動作しても良い。インスタントパーソナルトーク及びアドホックインスタントグループトークの場合では、招待ユーザのＰｏＣサーバは制御ＰｏＣサーバとなる。チャットグループトーク及びインスタントグループトークの場合では、制御ＰｏＣサーバは、グループアイデンティティ（グローバルグループアイデンティティ）を所有する／管理するＰｏＣサーバである。これらのＰｏＣサービスの更なる詳細は、以下のアペンディックスで示される。
【００２９】
上述しているように、ＰｏＣセッションに対するクレジット留保（credit reservation）に対する従来の方法は、重大なセッションセットアップ遅延を招く可能性がある。ＰｏＣ遅延検知サービス／機能（即ち、インスタントパーソナルトーク及びアドホックインスタントグループトーク）に対するクレジットを留保する別の方法を本明細書で提案する。これは、すべてのプリペイド特性（即ち、オペレータクレジット制御、エンドユーザリアルタイム消費制御）を維持するものである。この方法は、いわゆる「早期セッション」確立処理を使用することで、エンドユーザがトークセッションを開始する前に、即ち、実際のＰｏＣ機能が起動される前の、重要なセッションセットアップ時間で、ＰｏＣ機能用のクレジットを留保するものである。早期セッション確立処理は、ＵＥとユーザ自身のホームＰｏＣサーバ間のサービスネゴシエーション目的（例えば、ＲＴＰ／ＲＴＣＰ用のＩＰアドレス／ポート番号及びコーデックタイプの通信）用に使用される。この早期セッションは、ＩＭＳ登録に続いて即時に、あるいはその後の任意の時点で確立することができる。早期セッション確立処理は、ＰｏＣ確立処理は、ＰｏＣリソース２．０アーキテクチャで定義される。
【００３０】
早期セッション確立では、ＰｏＣサーバは、早期セッション確立リクエストの処理で継続する前に、ＰＰＣ向けのクレジット留保を実行する（Accounting-Record-Type = STARTとともに、Ｄｉａｍｅｔｅｒアカウンティング（Accounting）リクエスト（ＡＣＲ）を送信することによる）。ＰＰＳは、サービスに暫定的な格付けを行い（この時点では、後の時点でどのＰｏＣ機能がユーザによって起動されるかはわからない）、ユーザのクレジット残高が十分である場合は、ＰＰＣはユーザアカウントから適切な金額を留保し、対応するクレジットユニット（単位）量をＰｏＣサーバへ返信する（Ｄｉａｍｅｔｅｒ  ＡＣＡメッセージでは、Accounting-Record-Type = STARTを用いる）。クレジット留保が成功すると、ＰｏＣサーバは、早期セッション確立リクエストの処理を継続する。ここで、ＰｏＣ機能はまだ起動されていないので、このクレジット照会フェーズは特に時間には制約されない。
【００３１】
クレジット留保が失敗する（例えば、ユーザのクレジット残高が使い尽くされている）状態では、ＰＰＳは、失敗指示をＰｏＣサーバへ返信することによって、即時サービス終了処理を開始する（Ｄｉａｍｅｔｅｒ  ＡＣＡメッセージでは、Result-Code  =  DIAMETER_END_USER_SERVICE_DENIEDを用いる）。ＰｏＣサーバは、ＳＩＰエラー指示をサービング（サービス提供中の）ＩＭＳコアへ返信する。エラー指示は、ＵＥ及びエンドユーザへ返信される。
【００３２】
上述のように、早期セッション確立でクレジットが留保される場合、ＰｏＣサーバは、後の時点でどのＰｏＣ機能が起動されるか、あるいは早期セッション確立処理を実行するＵＥが、発信（セッションオーナー）あるいは終了（参加）エンドユーザによって使用されるかどうかについての事実についてはまだ気にかけない。つまり、早期セッション確立で、ＰｏＣサーバは、プリペイドシステムを格付けするための入力制限をだけを行えば良い。セッション接続（即ち、実際のＰｏＣ機能起動／セットアップ段階）では、ＰｏＣサーバは、事前に留保されているクレジットを基に、直ちにサービスリクエストを処理する。ここで、ＰｏＣサーバは、格付け用の正確な入力をＰＰＳへ提供することが可能である（Ｄｉａｍｅｔｅｒ  ＡＣＲメッセージでは、Accounting-Record-Type = INTERIMを用いる）。このクレジット照会フェーズもまたあまり時間に制約されない。これは、見積もられたクレジット量が既に留保されていて、サービスプロバイダへのリスクが減っているからである。サービス起動は直ちに処理すことができる一方で、これに平行して、次のクレジット照会が格付けを改良するために実行される。
【００３３】
図４は、インスタントパーソナルトーク機能を用いて改良クレジット照会用に使用される場合の早期セッション確立処理に関係するシグナリングを示している。この状況は、両サイド間の早期セッション確立処理について与えるものである（尚、シグナリングフローは、発信及び着信ＩＭＳコアを示していない）。それぞれのシグナリングステップを以下に示す。
【００３４】
ネットワークＡ早期セッション確立
１ａ．ＵＥ−Ａは、ＩＭＳコアＡを介して、ＳＩＰ  ＩＮＶＩＴＥをＰｏＣサーバＡへ送信することによって、早期セッション確立を（初期ＩＭＳ登録の直後あるいはいくつかの後の時点、例えば、ユーザは、ＵＥからインスタントトークサービスを起動する時）開始する（即ち、ＵＥはＳＩＰ  ＩＮＶＩＴＥをＩＭＳコアＡへ送信する）。ＩＭＳコアＡは、ＳＩＰ１００「試行（トライング）」をＵＥ  Ａへ返信する。ＩＭＳコアＡは、発信トリガーを検出して、結果として、ＳＩＰ  ＩＮＶＩＴＥをＰｏＣサーバＡへ送信する。ＳＩＰ  ＩＮＶＩＴＥは、次のものを含んでいる。
【００３５】
Request-URI user part set to pre-configured string "Ad-hocGroupRequest"
Accept-Contact including the feature tag "+g.poc.talkburt=TRUE"
To = URI user part set to pre-configured string "Ad-hocGroupRequest"
From = inviting user's Public User Identity
Message body with Content Type "application/sdp" containing an SDP Offer 1
２ａ．ＰｏＣサーバＡは、早期セッションがサポートされているかをチェックする。この状況を想定するために、早期セッションがサポートされていると仮定する。ＰｏＣサーバＡは、ＳＩＰ１００トライングをＩＭＳコアＡへ送信する。
【００３６】
ネットワークＡにおける課金、初期問い合わせ
３ａ．制御ＰｏＣサーバは、ユーザＡのホームプリペイドシステムＡに向けてのクレジット制御セッションを開始するとともに、受信したセッションセットアップリクエスト／ＳＩＰ  ＩＮＶＩＴＥの処理を継続する。プリペイドシステムＡは、ＥＣＦアドレスによって識別される。これは、ＩＭＳのユーザＡの登録時に、ホーム加入者システム（ＨＳＳ）からＩＭＳコアＡのＳ−ＣＳＣＦへ、ユーザＡプロファイルの一部としてダウンロードされ、かつＳＩＰ  ＩＮＶＩＴＥで、ＩＭＳコアＡのＳ−ＣＳＣＦからＰｏＣサーバＡへ送信される。
【００３７】
４ａ．制御ＰｏＣサーバは、Ｄｉａｍｅｔｅｒ  ＡＣＲをプリペイドシステムＡへ送信する。Ｄｉａｍｔｅｒ  ＡＣＲは、以下のものを含んでいる。：
Accounting-Record-Type=START_RECORD
Subscription-Id (Type=END_USER_SIP_URL, Data='user-A SIP URI')
M-S-C-C (#1)
Service-Parameter-Info(Type=ExtensionNumber1,
Value=POC_ANY_TALK_SESSION)
Service-Parameter-Info (Type=ExtensionNumber2, Value=session-owner)
Requested-Service-Unit (Type=SERVICE_CREDIT_EVENT, 
Value='pre-configured value')
Service-Parameter-Info (Type=ExtensionNumberA,
Value= e.g. "total time session is up"
M-S-C-C (#2)
Service-Parameter-Info (Type=ExtensionNumber1, 
Value=POC_ANY_TALK_SESSION)
Service-Parameter-Info (Type=ExtensionNumber2,
Value=session-owner)
Requested-Service-Unit (Type=SERVICE_CREDIT_EVENT, 
value='pre-configured value')
Service-Parameter-Info (Type=ExtensionNumberC,
Value= e.g. "number of distributed talk bursts"
M-S-C-C (#n)
Service-Parameter-Info (Type=ExtensionNumber1, 
Value=POC_ANY_TALK_SESSION)
Service-Parameter-Info (Type=ExtensionNumber2,
Value=session-participant)
Requested-Service-Unit (Type=SERVICE_CREDIT_EVENT, 
Value='pre-configured value')
Service-Parameter-Info (Type=ExtensionNumberBB,
Value= e.g. "number of sent and/or received talk burst"
注：この例では、３つのＭ−Ｓ−Ｃ−Ｃ  ＡＶＰが含まれている／示されている。一般的には、関係するサービス−タイプ及びパーティ役割の組み合わせに対するＩＰＭＭ  ＳＥによってサポートされる各測定方法の１つには、いくつかのＭ−Ｓ−Ｃ−Ｃ  ＡＶＰが含まれていても良い。
【００３８】
５ａ  プリペイドシステム−Ａは、受信したサービス−パラメータ−情報（Service-Parameter-Info）の内容に基づいて、暫定的にサービスの格付けを行い（この段階では、将来リクエストされるサービスがインスタントパーソナルトークあるいはアドホックインスタントグループトークであるかはわからない）、エンドユーザアカウント（予想されるサービスの料金を保持していて）からクレジット照会を行い、そして、Ｄｉａｍｅｔｅｒ  ＡＣＡメッセージをＰｏＣサーバへ返信する。この状況を説明する上では、ユーザのクレジット残高は十分にあると想定する。このＤｉａｍｅｔｅｒ  ＡＣＡは、以下のものを含んでいる。：
Result-Code=DIAMETER_SUCCESS
Accounting-Record-Type=START_RECORD
Accounting-Interim-Interval ('value set by the Prepaid System')
Subscription-Id (Type=END_USER_SIP_URL, Data='user-A SIP URI')
M-S-C-C (#a)
Service-Parameter-Info (Type=ExtensionNumber1, 
Value=POC_ANY_TALK_SESSION)
Service-Parameter-Info (Type=ExtensionNumber2,
Value=session-owner)
Granted-Service-Unit (Type=SERVICE_CREDIT_EVENT, 
Value='Prepaid System sets Granted-Service-Unit value = Requested-Service-Unit value')
Service-Parameter-Info (Type=ExtensionNumberC, 
Value= e.g. "number of distributed talk bursts").  注：これは、ユーザがセッションオーナの役割を後になって担う場合に有効となる課金モデルである。
M-S-C-C (#b)
Service-Parameter-Info (Type=ExtensionNumber1, 
Value=POC_ANY_TALK_SESSION)
Service-Parameter-Info (Type=ExtensionNumber2,
Value= session-participant)
Granted-Service-Unit (Type=SERVICE_CREDIT_EVENT, 
Value='Prepaid System sets Granted-Service-Unit value = Requested-Service-Unit value')
Service-Parameter-Info (Type=ExtensionNumberBB, 
Value= "sent talk burst").  注：これは、ユーザがセッション参加者の役割を後になって担う場合に有効となる課金モデルである。
【００３９】
制御ＰｏＣサーバＡは、許可済−サービス−ユニット（the granted-service-units）の使用の監視を開始する。
【００４０】
早期セッション確立手続
６ａ．ＰｏＣサーバＡは、ＳＩＰ２０２受付済（SIP 202 Accepted）をＩＭＳコアＡを介してＵＥ  Ａへ送信する。このＳＩＰ２０２受付済は、次のものを含んでいる：
Contact, containing the transient ad-hoc group identifier generated by the Controlling PoC Server
Message body with Content Type "application/sdp" containing an SDP Answer 1
７ａ．ＵＥ  Ａは、ＩＭＳコアＡを介して、ＳＩＰ  ＡＣＫをＰｏＣサーバへ送信する。
【００４１】
ネットワークＢ早期セッション確立及び課金初期問い合わせ
ネットワークＡにおけるステップ１ａから７ａに平行して、ステップ１ｂから７ｂが、ネットワークＢ（ユーザＢ、ＵＥ  Ｂ、ＩＭＳコアＢ、ＰｏＣサーバＢ、プリペイドシステムＢを含む）で発生する。
【００４２】
早期セッション−接続
図４に示される早期セッション確立処理の完了後、加入者（この場合、ＵＥ−Ａ）によって接続処理が開始される。図５及び６は、インスタントパーソナルトーク確立（即ち、接続セットアップ）に関係するシグナリングを示している。ここでも、このシグナリングフローは、発信及び着信ＩＭＳコアは示していない。シグナリングステップは、次のようになる。
【００４３】
早期セッションによる接続セットアップ
１．ＵＥ  Ａのエンドユーザである、ネットワークＡの加入者は、ＰｏＣボタンを操作して、ＵＥ  Ｂのエンドユーザである、ネットワークＢの加入者とのインスタントパーソナルトークセッションを開始する。
【００４４】
２．ＵＥ−Ａは、ＩＭＳコアＡを介して、ＳＩＰ  ＲＥＦＥＲをＰｏＣサーバＡへ送信する。ＳＩＰ  ＲＥＦＥＲは、次のものを含んでいる。：
Refer-To: invited user's Public User Identity (i.e. SIP URI or E.164 number)
３．発信側参加ＰｏＣサーバＡは、ＳＩＰ  ＲＥＦＥＲ内の情報（即ち、パブリックユーザアイデンティティ）に基づいて、セッションタイプをインスタントパーソナルトークとして認識する。
【００４５】
発信側参加ＰｏＣサーバＡは、制御ＰｏＣサーバの機能を獲得する。発信側参加ＰｏＣサーバ機能は、論理的には、制御ＰｏＣサーバ機能と同一の場所に配置されている。つまり、インスタントパーソナルトークに対しては、招待ユーザに割当られているＰｏＣサーバは制御ＰｏＣサーバとなる。
【００４６】
制御ＰｏＣサーバは：
トークセッションについての招待ユーザを認可し、
ＳＩＰ  ＲＥＦＥＲを、発信ＳＩＰ  ＩＮＶＩＴＥ／ＲＥＦＥＲそれぞれに対する参照（基準）イベントパッケージへの潜在的な加入リクエストとして解釈し（即ち、招待ＵＥは、ＳＩＰ  ＮＯＴＩＦＹで、招待ユーザの最終ＳＩＰ応答についての情報を受信する)、
そして、ＳＩＰ  ＲＥＦＥＲを潜在的な「フロアーリクエスト」として解釈する。
【００４７】
ネットワークＡでの課金、中間問い合わせ
４．制御ＰｏＣサーバは、中間問い合わせを実行して、新規／追加の格付け入力を課金システムＡに提供する。即ち、制御ＰｏＣサーバは、ここでは、セッションのタイプがインスタントパーソナルトークであるという知識を持っている。
【００４８】
５．制御ＰｏＣサーバは、Ｄｉａｍｅｔｅｒ  ＡＣＲをプリペイドシステムＡへ送信する。Ｄｉａｍｅｔｅｒ  ＡＣＲは、次のものを含んでいる。：
Accounting-Record-Type=INTERIM _RECORD
Subscription-Id (Type=END_USER_SIP_URL, Data='user-A SIP URI')
M-S-C-C
Service-Parameter-Info (Type=ExtensionNumber1, 
Value=POC_INSTANT_PERSONAL_TALK)
Service-Parameter-Info (Type=ExtensionNumber2,
Value= session-owner)
Requested-Service-Unit (Type=SERVICE_CREDIT_EVENT,
Value='pre-configured value')
Used-Service-Unit (Type=SERVICE_CREDIT_EVENT,
Value='amount of used service units')
Service-Parameter-Info (Type=ExtensionNumberC,
Value= e.g. "number of distributed talk bursts")
６．プリペイドシステムＡは、エンドユーザのアカウントから使用量を差し引き、受信したサービス−パラメータ−情報（Service-Parameter-Info）の内容に基づいてサービスの格付けを行い、エンドユーザのアカウント（サービスの料金を賄う）から新規のクレジット照会を行い、そして、Ｄｉａｍｅｔｅｒ  ＡＣＡを返信する。この状況の上では、ユーザのクレジット残高は十分にある。このＤｉａｍｅｔｅｒ  ＡＣＡは、次のものを含んでいる。：
Result-Code=DIAMETER_SUCCESS
Accounting-Record-Type=INTERIM _RECORD
Accounting-Interim-Interval (‘value set by the Prepaid System')
Subscription-Id (Type=END_USER_SIP_URL, Data='user-A SIP URI')
M-S-C-C
Service-Parameter-Info (Type=ExtensionNumber1, 
Value=POC_INSTANT_PERSONAL_TALK)
Service-Parameter-Info (Type=ExtensionNumber2,
Value= session-owner)
Granted-Service-Unit (Type=SERVICE_CREDIT_EVENT, 
Value=‘Prepaid System sets Granted-Service-Unit value = Requested-Service-Unit value')
Service-Parameter-Info (Type=ExtensionNumberC,
Value= e.g. "number of distributed talk bursts")
７．制御ＰｏＣサーバＡは、許可済サービス−ユニット（granted-service-units）の使用の監視を継続する。
【００４９】
８．制御ＰｏＣサーバＡは、ＩＭＳコアＡを介して、ＳＩＰ２０２受付済（SIP 202 Accepted）をＵＥ  Ａへ送信する。
【００５０】
９．制御ＰｏＣサーバＡは、ＳＩＰ  ＩＮＶＩＴＥ（ＳＤＰ  Ｏｆｆｅｒ２）を参加ＰｏＣサーバＢへ送信する。ＵＥ  ＡからのＳＩＰ  ＲＥＦＥＲメッセージの受信に続いて、このメッセージが直ちにＰｏＣサーバＡによって送信できることが理解されるであろう。即ち、このメッセージは、ＤＩＡＭＥＴＥＲメッセージの前あるいは間（５及び６）に送信され得る。
【００５１】
１０．参加ＰｏＣサーバＢは、（ＧＬＭＳ機能から）Ｄｏ−ｎｏｔ−Ｄｉｓｔｕｒｂ（干渉不要）フラグ、アクセス（受入／拒否）リスト、及び招待ユーザの回答モードを取得する。参加ＰｏＣサーバＢは、Ｄｏ−ｎｏｔ−Ｄｉｓｔｕｒｂ（干渉不要）フラグ及び招待ユーザのアクセス（受入／拒否）リストに基づいて、そのリクエストを認可する。この状況の上では、参加ＰｏＣサーバＢは、ＤｎＤフラグが設定されてなく、招待ユーザが拒否リストには存在せず、そして、招待ユーザの回答モードが「自動回答」に設定されていると判定する。
【００５２】
ネットワークＢにおける課金、中間問い合わせ
１１．参加ＰｏＣサーバは、中間問い合わせを実行して、新規／追加の格付け入力を課金システムＡに提供する。即ち、参加ＰｏＣサーバは、ここでは、ＰｏＣセッションの終了の知識を持っている。
【００５３】
１２．参加ＰｏＣサーバは、Ｄｉａｍｅｔｅｒ  ＡＣＲをプリペイドシステムＢへ送信する。Ｄｉａｍｅｔｅｒ  ＡＣＲは、次のものを含んでいる。：
Accounting-Record-Type=INTERIM _RECORD
Subscription-Id (Type=END_USER_SIP_URL, Data='user-A SIP URI')
M-S-C-C
Service-Parameter-Info (Type=ExtensionNumber1, 
Value=POC_ANY_TALK_SESSION)
Service-Parameter-Info (Type=ExtensionNumber2,
Value= session-participant)
Requested-Service-Unit (Type=SERVICE_CREDIT_EVENT,
Value='pre-configured value')
Used-Service-Unit (Type=SERVICE_CREDIT7_EVENT,
Value='amount of used service units')
Service-Parameter-Info (Type=ExtensionNumberBB,
Value= "sent talk burst")
１３．プリペイドシステムＢは、エンドユーザのアカウントから使用量を差し引き、受信したサービス−パラメータ−情報（Service-Parameter-Info）の内容に基づいてサービスの格付けを行い、エンドユーザのアカウント（サービスの料金を賄う）から新規のクレジット照会を行い、そして、Ｄｉａｍｅｔｅｒ  ＡＣＡを返信する。この状況の上では、ユーザのクレジット残高は十分にある。このＤｉａｍｅｔｅｒ  ＡＣＡは、次のものを含んでいる。：
Result-Code=DIAMETER_SUCCESS
Accounting-Record-Type=INTERIM _RECORD
Accounting-Interim-Interval (‘value set by the Prepaid System')
Subscription-Id (Type=END_USER_SIP_URL, Data='user-A SIP URI')
M-S-C-C
Service-Parameter-Info (Type=ExtensionNumber1, 
Value=POC_ANY_TALK_SESSION)
Service-Parameter-Info (Type=ExtensionNumber2, 
Value= session-participant)
Granted-Service-Unit (Type=SERVICE_CREDIT_EVENT, 
Value=‘Prepaid System sets Granted-Service-Unit value = Requested-Service-Unit value')
Service-Parameter-Info (Type=ExtensionNumberBB, 
Value= "sent talk burst")
１４．参加ＰｏＣサーバＢは、許可済サービス−ユニットの使用の監視を開始する。
【００５４】
早期セッション手続での接続セットアップ
１５．ＵＥ−Ｂは、確立済の早期セッションを持っていて、また、自動回答モードのセット（設定）を持っている。つまり、参加ＰｏＣサーバＢは、早期メディアモードを選択している。
【００５５】
１６．参加ＰｏＣサーバＢは、ＳＩＰ  ２００  ＯＫ（ＳＤＰ  Ａｎｓｗｅｒ  ２）を制御ＰｏＣサーバへ送信する。
【００５６】
１７．ＳＩＰ  ＡＣＫは、制御ＰｏＣサーバＡから参加ＰｏＣサーバＢへ送信される。ＳＩＰ  ＩＮＶＩＴＥメッセージ（９）と同様に、ＳＩＰ  ＡＣＫとＳＩＰ  ２００  ＯＫメッセージの送信は、ＤＩＡＭＥＴＥＲメッセージ（５、６、１２、１３）の交換とは独立していることに注意されたい。
【００５７】
１８．制御ＰｏＣサーバは、参加ＰｏＣサーバＢを介して、ＲＴＣＰ「フロア（発言権：floor）取得済」をＵＥ  Ｂへ送信する。
【００５８】
１９．「聴取（受信）指示」が、ユーザＢへ与えられる。
【００５９】
２０．制御ＰｏＣサーバは、ＲＴＣＰ「フロア許可済」をＵＥ  Ａへ送信する。ＳＩＰ  ＩＮＶＩＴＥメッセージ（９）と同様に、ＲＴＣＰ「フロア取得済」（１８）とＲＴＣＰ「フロア許可済」の送信は、ＤＩＡＭＥＴＥＲメッセージ（５、６、１２、１３）の交換とは独立していることに注意されたい。
【００６０】
２１．「トーク（会話）指示」が、ユーザＡへ与えられる（ＳＤＰ回答を搬送する「ＳＩＰ２０２受付済」と、ＰｏＣサーバを示す「ＲＴＣＰフロア許可済」の両方がメディアに渡される準備が整っていて、また、これらは、ユーザ対話目的のために必要とされている）。
【００６１】
ユーザＡのトーキング（会話）の開始
２２．ユーザＡは、トークを開始する。
【００６２】
２３．「ＲＴＰトークバースト」（メディア）が、制御ＰｏＣサーバと関係ＰｏＣサーバＢを介して、ＵＥ  ＡからＵＥ  Ｂへ送信される。
【００６３】
２４．ユーザＡは、ユーザＢのスピーチフレーズを聴取（受信）する。
【００６４】
２５．ＳＩＰ  ２００  ＯＫの受信時での従前の「招待ユーザの暗黙（間接的な）の加入状態」によって、制御ＰｏＣサーバは、ＳＩＰ  ＮＯＴＩＦＹリクエストをＩＭＳコアＡへ送信する。ＩＭＳコアＡは、ＳＩＰ  ＮＯＴＩＦＹをＵＥ  Ａへ送信する。ＳＩＰ  ＮＯＴＩＦＹは、次のものを含んでいる。：
Event = refer
Message body with Content Type "message/sipfrag" containing:
The status line of the SIP response that the PoC Server received from the invited user,  "SIP/2.0 200 OK" for this scenario; and
The Public User Identity of the invited user (SIP URI or MSISDN)
２６．ＵＥ  Ａは  ＳＩＰ  ＮＯＴＩＦＹに対して、ＳＩＰ  ２００  ＯＫをＩＭＳコアＡへ送信する。ＩＭＳコアＡは、ＳＩＰ  ２００  ＯＫを制御ＰｏＣサーバへ送信する。
【００６５】
ユーザＡのトーキング（会話）の終了
２７．ユーザＡは、ＰｏＣボタンを解除する。
【００６６】
２８．ＵＥ  Ａは、「ＲＴＣＰフロア解除」を制御ＰｏＣサーバへ送信する。
【００６７】
２９．制御ＰｏＣサーバは、「ＲＴＣＰフロアアイドル」をＵＥ  Ａへ送信する。
【００６８】
３０．制御ＰｏＣサーバは、「ＲＴＣＰフロアアイドル」を、参加ＰｏＣサーバＢへ送信する。この参加ＰｏＣサーバＢは、更に、それをＵＥ  Ｂへ送信する。
【００６９】
３１．「フロアアイドル指示」が、ユーザＢへ与えられる。
【００７０】
より多くのトークバーストが、ユーザＡ及びユーザＢによって送信／受信されても良い。
他のトークバーストが、ユーザＡとユーザＢによって送信／受信されても良い。
【００７１】
他のクレジット制御の中間問い合わせが発生しても良い。
【００７２】
ユーザＡによるトークセッションの切断
３２．ユーザＡは、トークセッションの切断をリクエストする。
【００７３】
３３．ＵＥ−Ａは、「ＲＴＣＰ  ＢＹＥ（バイ）」を制御ＰｏＣサーバへ送信する。
【００７４】
３４．制御ＰｏＣサーバは、非起動（停止：inactivity）タイマの満了を検出する。セッション終了ポリシーに従えば、制御ＰｏＣサーバは、トークセッション解除をリクエストする。
【００７５】
３５．制御ＰｏＣサーバは、「ＲＴＣＰ  ＢＹＥ（バイ）」を参加ＰｏＣサーバＢへ送信する。このＰＯＣサーバＢは、更に、それをＵＥ−Ｂへ送信する。
【００７６】
３６．セッション切断指示が、ユーザＢへ与えられる。
【００７７】
３７．制御ＰｏＣサーバは、ＳＩＰ  ＢＹＥを、参加ＰｏＣサーバＢへ送信する。
【００７８】
３８．参加ＰｏＣサーバＢは、（ＳＩＰ  ＢＹＥに対して）ＳＩＰ  ２００  ＯＫで応答する。
【００７９】
ネットワークＡにおける課金、最終問い合わせ
３９．制御ＰｏＣサーバは、Ｄｉａｍｅｔｅｒ  ＡＣＲをプリペイドシステムＡを送信する。Ｄｉａｍｅｔｅｒ  ＡＣＲは、次のものを含んでいる。：
Accounting-Record-Type=STOP_RECORD
Subscription-Id (Type=END_USER_SIP_URL, Data='user-A SIP URI')
Used-Service-Unit (Type=SERVICE_CREDIT_EVENT, Value='amount of used service units')
４０．プリペイドシステムＡは、Ｄｉａｍｅｔｅｒ  ＡＣＡへ返信する。この状況の上では、ユーザのクレジット残高は十分にある。このＤｉａｍｅｔｅｒ  ＡＣＡは、次のものを含んでいる。：
Result-Code=DIAMETER_SUCCESS
Accounting-Record-Type=STOP_RECORD
ネットワークＢにおける課金、最終問い合わせ
４１．参加ＰｏＣサーバは、Ｄｉａｍｅｔｅｒ  ＡＣＲをプリペイドシステムＢへ送信する。Ｄｉａｍｔｅｒ  ＡＣＲは、次のものを含んでいる。：
Accounting-Record-Type=STOP_RECORD
Subscription-Id (Type=END_USER_SIP_URL, Data='user-A SIP URI')
Used-Service-Unit (Type=SERVICE_CREDIT_EVENT, Value='amount of used service units')
４２．プリペイドシステムＢは、Ｄｉａｍｔｅｒ  ＡＣＡへ返信する。この状況の上では、ユーザのクレジット残高は十分にある。このＤｉａｍｅｔｅｒ  ＡＣＡは、次のものを含んでいる。：
Result-Code=DIAMETER_SUCCESS
Accounting-Record-Type=STOP_RECORD
クレジット照会フェーズがＰｏＣトークセッションセットアップ時間に影響を与えないようにして、プリペイド機能（市場に広く受け入れられるための必須のＰｏＣ機能）の導入がなされることが上述の説明から明らかであろう。ＩＰＭＭサービングエレメント（例えば、ＰｏＣサーバ）は、時には、「ＰｏＣ早期セッション処理」の一部とする初期ＩＭＳユーザ登録後、つまり、実際のセットアップ時間が重要なＰｏＣサービス機能（即ち、インスタントパーソナルトーク、アドホック、インスタントグループトーク）がエンドユーザによって起動される前に、プリペイドシステム向けのクレジット照会を実行してクレジットを留保する。エンドユーザがＰｏＣサービス機能を起動する場合、ＩＰＭＭサービングエレメントは、予め留保されたクレジットを利用することによって直ちにサービスリクエストを処理することができる。同時に、ＩＭＰＰサービングエレメントは、次のクレジット照会を実行して、プリペイドシステムに再調整済の格付け入力（例えば、実際の起動されたＰｏＣ機能、セッション発信パーティの役割）を提供する。これにより、クレジット照会フェーズは、ＰｏＣトークセッションセットアップ時間に影響を与えない。
【００８０】
本発明の範囲から逸脱しないで、上述の実施形態を様々に変形することができることが当業者には明らかであろう。
【００８１】
アペンディックス
セルラーオーバープッシュツートーク（ＰｏＣ）は、ＩＭＳ技術に基づく、「ウォーキ−トーキー」タイプのサービスである。ＰｏＣサービスは、以下の機能を含んでいる。：
インスタントパーソナルトーク
これは、（１対１）の他人との音声通信である。これは、ユーザは別の人と同時に会話するものである。ユーザは、他のユーザを招待して、インスタントパーソナルトークセッションを確立する。１対１のインスタントパーソナルトークサービスの参加ユーザは、新規のユーザあるいはユーザ群をセッションに追加することで、１対Ｎ通信（即ち、アドホックインスタントグループトーク）を確立することができる。
【００８２】
チャットグループトーク
これは、１対Ｎ音声通信である。これは、ユーザは別の人と同時に会話するものである。ユーザは、チャットグループトークに参加するためにグループに参加する。即ち、各参加者は、個々にセッションに加入する。チャットグループには２つのタイプが存在する。：
１．オープンチャットグループは、任意のユーザが加入することができるグループである。
【００８３】
２．制限付チャットグループは、メンバーリストのグループであり、そのグループの所属するユーザだけがグループメンバーを追加したり削除することができる。また、グループのメンバーだけがチャットグループトークセッションに参加することができる。
【００８４】
制限付チャットグループトークが確立される前に、グループは生成されていなければならず、またメンバーは定義されていなければならない。オープンチャットグループトークが確立される前に、グループは生成されていなければならない。進行中のオープンあるいは制限付チャットグループトークセッションの参加者は、他のユーザをセッションに追加したり、招待することができる。グループが制限されている場合は、参加者は、そのグループのメンバーのユーザだけを招待することができる。
【００８５】
インスタントグループトーク
これは、１対Ｎ音声通信である。これは、ユーザは別の人と同時に会話するものである。グループのメンバーの１人は、他のグループのメンバーのすべてをインスタントグループトークセッションに招待する。インスタントグループトークが確立される前に、グループは生成されなければならず、また、メンバーが定義されていなければならない。グループから外れているあるいは最初に招待を拒否されているグループのメンバーは、進行中のインスタントグループトークセッションに参加／再参加することができる。進行中のインスタントグループトークセッションへの参加者は、グループの他のメンバーをそのセッションに追加／招待することができる。
【００８６】
アドホックインスタントグループトーク
これは、１対Ｎ音声通信である。これは、ユーザは別の人と同時に会話するものである。ユーザは、選択されたユーザをアドホックインスタントトークセッションへ招待する。進行中のアドホックインスタントグループセッションへの参加者は、他のユーザをそのセッションへ追加／招待することができる。グループから外れているあるいは最初は招待を拒否されているユーザは、進行中のアドホックインスタントグループトークセッションへ参加／再参加することができる。
【００８７】
インスタントパーソナルアラート
ユーザは、別のユーザへアラートを行うことができる。このアラートは、ユーザが通信を行いたいことを表現し、また、例えば、インスタントパーソナルトーク機能を使用して、他のユーザにコールバックしてもらうことを丁重にリクエストする方法でもある。インスタントパーソナルアラートは、テキストメッセージを搬送することもできる。
【００８８】
加えて、次の機能が、上述のＰｏＣ機能に関連して使用される。：
グループ及びリスト管理
これは、以下に説明するように、ＰｏＣエンドユーザ（及びオペレータ）にグループ、リスト及び他の情報を管理することを可能にする。この情報は、ネットワーク内のグループ及びリスト管理サーバ（ＧＬＭＳ）論理エンティティに記憶されていて、ＵＥ−ＧＬＭＳインタフェースを介して管理される。
【００８９】
コンタクトリスト
これらは、ＵＥ及びネットワーク内のコンタクトエントリ（個人及びグループ）を記憶するために使用される。このようなりストは、ＵＥによって使用され、ＰｏＣ通信を開始する場合のユーザとグループをアドレスする。コンタクトリストは、インスタントパーソナルトークタイプ及びアドホックインスタントグループセッションタイプに適用される。
【００９０】
アクセス（受入／拒否）リスト
これらは、アクセスルールを定義するために使用される。つまり、ＰｏＣサービスを介して、誰が特定のユーザに到達することが許可されているあるいは許可されていないことを示すものである（即ち、着呼／招待ユーザは、受入／拒否リストを使用して、他のユーザからの着信トークセッションリクエストを受け入れるあるいは拒否することができる）。アクセスリストは、すべてのトークセッションタイプに適用され、また、ＰｏＣサーバによって使用される。これは、着呼／終端側（パーティ）の機能である。
【００９１】
グループリスト
グループリストは、ＰｏＣ特定グループを定義するために使用され、オープン／制限付チャットグループトーク及びインスタントグループトークに適用される。これは、ＰｏＣサーバとＵＥによって使用される。
【００９２】
Ｄｏ−ｎｏｔ−Ｄｉｓｔｕｒｂ（干渉不要）（ＤｎＤ）
着呼／招待ユーザは、「Ｄｏ  Ｎｏｔ  Ｄｉｓｔｕｒｂ」機能を使用して、すべての着信トークセッション（インスタントパーソナルアラート以外）をブロックすることができる。ＤｎＤは、アクセスリストより優先する。これは、ＰｏＣサーバによって使用される。これは、着呼／終端側（パーティ）の機能である。
【００９３】
回答モード
着呼／招待ユーザは、自動あるいは手動回答モードを選択することができ、また、これは、ＰｏＣサーバとＵＥによって使用される。これは、着呼／終端パーティの機能である。招待ユーザへサービスを提供しているＰｏＣサーバは、回答モードを使用して、セッションに対するメディアモード（早期あるいは遅延メディア）を選択することができる。
【００９４】
プレゼンス（存在）
この機能は、他のパーティのアクセス可能性をパーティ群に広告（通知）するために使用される。
【図面の簡単な説明】
【００９５】
【図１】ＩＰマルチメディアサブシステムを組み込む移動体ネットワークアーキテクチャを示す図である。
【図２】ＩＰＭＭサービス用の論理的なオンライン課金アーキテクチャを示す図である。
【図３】ＰｏＣリリース２アーキテクチャを示す図である。
【図４】ＰｏＣインスタントパーソナルトーク用の早期セッション確立処理に関係するシグナリングを示す図である。
【図５】サービスが実際に起動される場合の、早期セッション確立に続く、セッション接続処理に関係するシグナリングを示す図である。
【図６】サービスが実際に起動される場合の、早期セッション確立に続く、セッション接続処理に関係するシグナリングを示す図である。
【図３】
2008502035.tif 000003
【図１】
2008502035.tif 000004
【図２】
2008502035.tif 000005
【図４】
2008502035.tif 000006
【図５】
2008502035.tif 000007
【図６】
2008502035.tif 000008
【国際調査報告】
2008502035.tif 000009
2008502035.tif 000010