JP2011515980A

JP2011515980A - 通信システムにおけるピアツーピアマルチメディア接続の状態を問い合わせるシステムおよび方法

Info

Publication number: JP2011515980A
Application number: JP2011501329A
Authority: JP
Inventors: ヂュウ，ヂョンウェン; ゴダン，アンドレ
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2008-03-28
Filing date: 2009-03-24
Publication date: 2011-05-19
Also published as: EP2260630A1; US20090248810A1; WO2009118687A1

Abstract

ピアツーピアマルチメディア接続に関する状態情報をネットワークが問い合わせることができる。問い合わせを受けた端末は、例えば、ピアツーピアマルチメディア接続で送信されたデータのタイプおよび／または量、および／またはピアツーピアマルチメディア接続で未だ送信されていないデータのタイプおよび／または量を含む応答状態情報を提供することができる。この状態情報を使用して、例えば、マルチメディアサービスを使用する顧客に対する課金または料金請求の支援を行うことができる。
【選択図】図５ａ

Description

本発明は、広く電気通信システムに関し、特に、例えば課金／料金請求などを目的として、ピアツーピアマルチメディア通信サービスおよびコールの状態を問い合わせる方法およびシステムに関する。

通信技術および用途は、ここ数十年で大きく変化した。ごく最近は、銅配線技術が、長距離の音声通信の伝送に使用する主要な機構であった。コンピュータが導入され、ビジネス、個人ユーザ、教育機関を含む多くの目的で、遠隔地間のデータ交換の能力が望ましいものとなった。ケーブルテレビの導入、および関連した同軸ケーブルの普及によって、ビジネスから公共へ通信およびデータ配信を増加する別の機構がつくられた。技術が前進し、デジタル加入者回線（DSL：digital subscriber line）伝送機器が導入され、既存の銅の電話配線のインフラストラクチャによるデータ伝送をより高速にすることができた。加えて、ケーブルインフラストラクチャによる双方向の情報交換も、ビジネスから公共へ利用可能となった。無線通信は、携帯電話をもつ様々な人々のうちの大きな割合でユビキタスとなった。このような多くの進歩によって、ユーザが利用可能なサービスのオプションおよびアプリケーションの成長が促された。

消費者電子産業は成長を続け、プロセッサの能力は増大し、装置間のデータ伝送を可能とする装置がより多く公共に利用可能となり、この伝送データに基づいて運営されるサービスがより多く利用可能となった。特に注目すべきなのは、インターネット、およびローカルエリアネットワーク（LAN：local area network）である。この２つの革新によって、複数のユーザと複数の装置とが、異なる装置間、異なる装置タイプ間でデータ通信およびデータ交換することができるようになる。インターネットに関しては、その物理的機構および関連する通信ストリームが、増加したデータフローの処理もできるようになった。サーバは以前よりもメモリが多くなり、過去よりも帯域幅が高い通信リンクが存在し、プロセッサはより高速で、より有能であり、これらの要素を利用するプロトコルがある。消費者によるインターネットの利用が増えるにつれ、サービス会社は、従来のサービス、および新たなマルチメディア型のサービスを提供する機構としてインターネット（および他のインターネットプロトコル（IP：Internet Protocol）ネットワーク）に取り組んできた。このようなマルチメディアサービスとしては、例えば、インターネットプロトコルテレビジョン（IPTV：Internet Protocol television、ＩＰデータパケットを使用してネットワークによってテレビジョンプログラムを配信するシステムやサービスを指す）ビデオオンデマンド（VOD：video on demand）、ボイスオーバＩＰ（VoIP：voice over IP）が挙げられるが、単一に、または組み合わせて受信する他のウェブ関連サービスも含まれる。インターネットや他の接続ネットワークを通じて装置との通信を処理可能な無線ネットワークにも同じことがあてはまる。

ＩＰネットワークを使用して様々なサービスを提供する新しく異なる方法を適用するため、新たなネットワークアーキテクチャが開発され、規格化されている。かかる発展の１つが、インターネットプロトコルマルチメディアサブシステム（IMS：Internet Protocol Multimedia Subsystem）である。ＩＭＳとは、ＩＰＴＶやＩＭＳメッセージングサービスなどのＩＰマルチメディアサービスをエンドユーザへ配信するアーキテクチャフレームワークである。以下、単純化したＩＭＳアーキテクチャ例を図１で説明する。ＩＭＳアーキテクチャとともに、セッション開始プロトコル（SIP：Session Initiation Protocol）シグナリングを使用して、２つの装置間のセッションのセットアップ、変更、終了を行うことが多い。例えば、ＳＩＰシグナリングを移動装置間で使用して、ピアツーピアセッションをセットアップしたり、移動装置とＩＭＳに関連するアプリケーションサーバとの間で使用して、移動装置でマルチメディアサービスを受け取ったりすることができる。ＩＭＳへの関心が増すにつれて、例えば携帯電話などのエンドユーザ装置用のＩＭＳ対応アプリケーションの量も増加している。すなわち、このようなサービスにアクセスするユーザに課金する効果的かつ柔軟で正確な方法が求められることになる。

典型的には、以下でより詳細に説明するように、ピアツーピアマルチメディアサービスに関し、このようなサービスの提供に対する課金機構としてはたらくアプリケーションサーバは、マルチメディアサービスのシグナリングパスにのみ関するものであり、メディアパス、すなわち、マルチメディアサービスに関するペイロード情報が伝送されるパスに関するものではない。したがって、このようなアプリケーションサーバは、マルチメディアサービスの一部として伝送された実際のメディアコンテンツではなく、シグナリングパスによって入手可能なセッションセットアップ情報に基づいて、顧客に料金請求することのみ可能である。セッションセットアップ情報は、例えば２つの携帯電話間のマルチメディアコールに対する課金の仕方に関して、十分に正確な情報を提供することもあれば、提供しないこともある。例えば、音楽を伝送し、後にビデオを伝送するために、２つのピア装置間にセッションがセットアップされると、セッションのセットアップ時に入手可能な、送信されるメディアの表示ではなく、伝送された実際のメディアに基づいて、顧客に料金請求するのが望ましいことがある。

ツァイ（Cai）らの米国特許出願公開第２００７／０１７４４００号明細書は、ＩＭＳセッション中のメディアの変更に対するＩＭＳバジェット制御の機構を説明している。この特許出願公開において、ＩＭＳネットワークは、ＩＭＳセッション中にメディアの変更（例えばオーディオからオーディオ／ビデオへ）を可能にするものとして説明されている。この出願公開で説明されている機構は、加入者に依存して、メディアの変更に関する通信を開始するものであり、すなわちプッシュ機構である。しかしながら、ネットワーク運用者としては、料金請求を目的として、よりいっそうの制御をこの動作に対して行うことが好ましいこともある。

したがって、以下の実施形態例は、例えばピアツーピアマルチメディアサービスの課金に関する状態問い合わせ方法およびシステムに対する上述の必要性に取り組むものである。

本発明に係るシステムおよび方法は、例えば、ピアツーピアマルチメディアサービスまたはコールに対する顧客への課金に使用可能な状態情報を収集するプル機構を提供することによって、かかる必要性およびその他に取り組むものである。

一実施形態例によれば、ピアツーピアマルチメディア接続の状態を問い合わせる方法が、ピアツーピアマルチメディア接続の状態を問い合わせるメッセージをアプリケーションサーバから送信するステップと、ピアツーピアマルチメディア接続の状態に関する応答をアプリケーションサーバにおいて受信するステップとを含む。

別の実施形態例によれば、通信ノードが、ピアツーピアマルチメディア接続の状態を問い合わせるメッセージを送信し、ピアツーピアマルチメディア接続の状態に関する応答を受信する処理部を備える。

さらに別の実施形態例によれば、ピアツーピアマルチメディア接続に関する状態問い合わせを処理する方法が、ピアツーピアマルチメディア接続の状態を問い合わせるメッセージを端末装置において受信するステップと、ピアツーピアマルチメディア接続の状態に関する応答を端末装置から送信するステップとを含む。

なおも別の実施形態例によれば、端末装置が、ピアツーピアマルチメディア接続の状態を問い合わせるメッセージを受信し、ピアツーピアマルチメディア接続の状態に関する応答を送信する処理部を備える。

添付図面は実施形態例を説明するものである。

図１は、実施形態例が動作可能なインターネットプロトコルマルチメディアサブシステム（ＩＭＳ）アーキテクチャを示す。図２（ａ）は、実施形態例が動作可能なシグナリングパスとメディアパスとを含むピアツーピア接続を示す。図２（ｂ）は、より詳細に図２（ａ）のシグナリングパスを示す。図３は、様々な実施形態例に係るシグナリング図を示す。図４は、実施形態例に係る端末装置または通信ノードを示す。図５（ａ）は、それぞれ、実施形態に係る、ピアツーピア接続の状態を問い合わせ、それに応じる方法を示すフローチャートである。図５（ｂ）は、それぞれ、実施形態に係る、ピアツーピア接続の状態を問い合わせ、それに応じる方法を示すフローチャートである。

以下の実施形態例の詳細な説明では、添付図面を参照する。異なる図面に同一の参照番号がある場合は、同一または同様の要素を識別している。また、以下の詳細な説明は本発明を限定するものではなく、本発明の範囲は、添付の特許請求の範囲によって限定される。

上で簡単に述べた実施形態例について以下で説明するため、単純化したＩＭＳシステムアーキテクチャ例１０を、例えば図１に示すように、サービスレイヤ１２、制御レイヤ１４、接続レイヤ１６の３つのレイヤに分割する。ここで、サービスレイヤ１２は、例えばＩＰＴＶサービスやＩＭＳメッセージングサービスなど、エンドユーザへ配信可能なサービスおよびアプリケーションを有するアプリケーションサーバ（AS：application server）１８、２０を含む。制御レイヤ１４は、ホーム加入者サーバ（HSS：home subscriber server）２２と、メディアリソース機能（MRF：media resource function）２４と、コールサービス制御機能（CSCF：call service control function）２６と、シグナリングゲートウェイ／メディアゲートウェイ制御機能（SG/MGSF：signaling gateway/media gateway control function）２８と、メディアゲートウェイ３０とを含む。ＣＳＣＦ２６は、ＩＭＳシステム１０におけるＳＩＰメッセージングを処理する多種多様なＳＩＰプロキシまたはサーバを総じて表したものであり、例えば中でも、アプリケーション１８、２０のいずれがＳＩＰメッセージを送信すべきか判定するサービングＣＳＣＦ（S-CSCF：serving CSCF）などが含まれる。典型的には、このような制御レイヤ１４の要素（および他の要素）を使用して、例えば、セッションセットアップの管理、リソース変更の処理、リソースの解放を行う。

接続レイヤ１６は、例えば、バックボーンネットワークにもアクセスネットワークにも使用するルータおよびスイッチを含む。このような要素は、図１では、インターネットプロトコル（ＩＰ）／マルチプロトコルラベルスイッチング（MPLS：multi-protocol label switching）３２と、公共交換電話網（PSTN：public switched telephone network）／公共地上移動体ネットワーク（PLMN：public land mobile network）３４と、メディアゲートウェイ３０とで表している。したがって、接続レイヤ１６を使用して、様々なユーザ装置や様々なサービスおよびアプリケーションを互いに接続する。エンドユーザ（端末）のタイプの例としていくつか挙げると、例えば、セットトップボックス（STB：set-top box）、パーソナルコンピュータ、携帯電話などがある。当業者であれば、ＩＭＳシステムまたはアーキテクチャに存在する要素を増やしたり減らしたりすることが可能であることは了解されよう。一般的なＩＭＳアーキテクチャおよびＳＩＰシグナリングに関する詳細については、それぞれ、２００７年３月付けの第３世代パートナーシッププロジェクト（3GPP：Third Generation Partnership Project）技術仕様書（TS：Technical Specification）２３．２２８バージョン８、および２００２年６月付けのリクエストフォーコメント（RFC：Request for Comments）３２６１で見られる。

これらの実施形態例は３ＧＰＰにしたがったアーキテクチャの通信システムを参照しているが、本発明はこれに限定されないことは了解されよう。しかしながら、３ＧＰＰ通信システムを例として取り上げると、かかるシステムは、典型的に、運用者がそのネットワークサービスに対して顧客に課金できる課金管理フレームワークを提供するものでもある。３ＧＰＰ通信システムにおけるこの課金または料金請求の態様については、図２（ａ）に示す例を検討することによって、より良く理解されよう。

ここでは、送信側移動体２００と受信側移動体２１０とが、直接ピアツーピア接続して、例えば、メディアパス２２０によって互いにマルチメディアコンテンツを伝送している。図２（ａ）には示していないが、メディアパス２２０には、典型的には、例えば無線アクセスポイントなどの様々なノードや、関連のその他のデータ伝送用インフラストラクチャノードがあり、２つの移動体２００、２１０でそれぞれ動作する２つのメッセージセッション中継プロトコル（MSRP：Message Session Relay Protocol）機能２３０、２４０を伝送する。当業者であれば明らかなように、ＭＳＲＰ機能２３０、２４０は、例えばセッション（この例ではＳＩＰセッション）について一連の関連インスタントメッセージを送受信するものである。しかしながら、当業者であれば、この実施形態例で説明するＭＳＲＰ機能またはセッションは純粋に説明のためのものであり、他のプロトコルを使用して、かかるマルチメディア機能またはセッションの運用を行うことも可能であることが了解されよう。一般的に参照番号２５０で示し、別途図２（ｂ）にも図示するシグナリング（または制御）パスによって、このピアツーピア接続のＳＩＰセッションのセットアップおよび終了は確立される。シグナリングパス２５０のいずれか一端に、各移動体２００、２１０はそれぞれのＳＩＰユーザエージェント２６０、２７０を有する。ＳＩＰユーザエージェント（SIP UA：SIP User Agent）２６０、２７０は、発信ＳＩＰ要求を開始し、着信ＳＩＰ要求を処理する（応答する）機能である。

移動体２００と移動体２１０との間にインスタントメッセージング（IM：instant messaging）のＳＩＰセッションをセットアップするため、ＳＩＰユーザエージェント２６０は、例えばＳＩＰＩＮＶＩＴＥメッセージを移動体２１０へ送信することができる。図２に示すように、ＳＩＰＩＮＶＩＴＥメッセージはシグナリングパス２５０をＳ−ＣＳＣＦ２８０へ進む。Ｓ−ＣＳＣＦ２８０は、移動体２００のホームネットワークのＳ−ＣＳＣＦノードである。Ｓ−ＣＳＣＦ２８０は、ＩＭＳサービス制御（ISC：IMS Service Control）参照ポイントを介して、ＳＩＰＩＮＶＩＴＥメッセージをＩＭＳメッセージングアプリケーションサーバ２９０へ送信し、ＩＭＳメッセージングアプリケーションサーバ２９０はインスタントメッセージングサービスを送信元ユーザに提供する。アプリケーションサーバ２９０は（その対応するＳＩＰＵＡ２９１を介して）、受信側のホームネットワークに関するＳ−ＳＣＳＦノード２９２にＳＩＰＩＮＶＩＴＥメッセージを送信する。すなわち、移動体２１０へＩＭサービスを提供する対応のアプリケーションサーバ２９４へメッセージを搬送する。ＩＭＳＭＡＳ２９４は、処理および確認応答のため、Ｓ−ＣＳＣＦノード２９２を通して受信側ＳＩＰユーザエージェント２７０へＳＩＰＩＮＶＩＴＥメッセージを返信する。このシグナリングはシグナリングパス２５０でも返信される。

図２（ａ）に示すシグナリングでは、ＩＭＳメッセージングアプリケーションサーバ２９０、２９４（およびそれぞれのＳＩＰＵＡ２９１、２９５）は、メディアパス２２０ではなく、シグナリングパス２５０にのみ関するものである。シグナリングパス２５０では、図２（ｂ）に示すように、このサーバ２９０、２９４はバックツーバックユーザエージェント（B2BUA：back-to-back user agent）としてはたらき、様々な制御信号パスリンクによる制御シグナリングを調整する。このリンクは、図２（ｂ）に示すエンドポイントＬ１〜Ｌ６を使用して示すことができる。この役割で、サーバ２９０、２９４のいずれかまたは双方は、とりわけ、マルチメディア接続に対して移動体２００、２１０のユーザに課金する料金請求情報の収集という機能を行う。しかしながら、上述のように、これによって、上述の初期セッションセットアップシグナリングにのみ基づいて課金を行うことができる。すなわちセッションベースの課金である。

本発明の実施形態例によれば、例えばアプリケーションサーバ２９０および／または２９４のようなアプリケーションサーバがＳＩＰセッション中にクライアント側のＭＳＲＰ状態について問い合わせできるようにすることで、正確で柔軟な課金機構が提供される。クライアントの応答に基づいて、問い合わせを発信したアプリケーションサーバは、ＭＳＲＰまたはＳＩＰセッションを続行させるかどうか、あるいはこのセッションを終了させるかどうか判定することができる。加えて、クライアントの応答をアプリケーションサーバが使用して、料金請求の目的で、マルチメディア接続に関する課金情報メッセージを生成し、送信することができる。この実施形態例がプル機構を提供するため、すなわちネットワークが情報を要求しており、処理を制御するところ、ネットワーク運用者は、ピアツーピアマルチメディア接続に対する料金請求および課金に関するその実施要件に処理を合わせることができよう。

一実施形態に係る信号技術例を図３に示す。ここでは、ピアツーピアマルチメディア接続に関するＳＩＰダイアログまたはセッションは、上述のように、例えばＳＩＰメッセージのＳＩＰＩＮＶＩＴＥ、２００ＯＫ、ＡＣＫシーケンスを使用してセットアップされ、このシグナリングは矢印３００で表している。なお、図面を明確にするため、この図面では端末２００のうちの１つに関するシグナリングパスの終端しか示していない。ＳＩＰセッションが確立されると、送信側２００は、矢印３０２で表すように、そのＭＳＲＰ機能２３０を介して受信側２１０へのデータ送信を開始する。ＳＩＰおよびＭＳＲＰセッションの間、例えば、ネットワーク運用者が設定した所定の時間に、アプリケーションサーバ２９０は、シグナリング手続３０３を開始して、図２（ａ）および２（ｂ）に示すシグナリングパスＬ_１〜Ｌ_２の部分に関する送信側２００のＭＳＲＰ状態について問い合わせることができる。

最初は、この実施形態例によれば、アプリケーションサーバ２９０は、セッションデスクリプションプロトコル（SDP：Session Description Protocol）を使用して、ＳＩＰＩＮＶＩＴＥ（あるいは、進行中のセッションの内なので、恐らくより正確には再ＩＮＶＩＴＥといえる）メッセージ３０４を構成する。このメッセージ３０４は、要求がＭＳＲＰ２３０へ向かうことを示す１または２以上のメディアライン（すなわち「ｍ＝（あるメディアネームおよびトランスポートアドレス）」と、１または２以上の属性ライン（すなわち「ａ＝（あるセッション属性）」を含み、問い合わせを形成する。純粋に説明のための例として、この問い合わせに関するＳＩＰ再ＩＮＶＩＴＥメッセージ３０４におけるＳＤＰの部分は、
m = message 7654 TCP / MSRP *
a = CDR_request:file_name:data_size_sent:data_size_remain
と表すことができる。アプリケーションサーバ２９０は、このＳＩＰ再ＩＮＶＩＴＥメッセージ３０４を、既存のＳＩＰセッション内のシグナリングパス２５０の着信行程Ｌ_１〜Ｌ_２に沿ってＳ−ＣＳＣＦ２８０へ送信する。Ｓ−ＣＳＣＦ２８０は、受信ＳＩＰ再ＩＮＶＩＴＥメッセージ３０４を端末２００におけるＳＩＰＵＡ２６０へ渡す。ＳＩＰＵＡ２６０は、ＭＳＲＰ機能２３０とやり取りして、アプリケーションサーバ２９０が要求する情報を得る。例えば、ＳＩＰＵＡ２６０は、ＳＤＰからＳＩＰ再ＩＮＶＩＴＥメッセージ３０４によって搬送された「ａ＝．．．」ラインを解析し、この情報を使用して、内部問い合わせ、すなわちＭＳＲＰ状態要求メッセージ３０６を形成することができる。このメッセージ３０６はＭＳＲＰ機能２３０へ送信される。このＭＳＲＰ状態要求メッセージとしては、例えば、ＭＳＲＰセッション３０２のためにＭＳＲＰ機能２３０によって送信されたオーディオ、ビデオなどや、その他のデータのタイプについて、および／または、ＭＳＲＰセッション３０２を使用して送信するデータのタイプについての情報の要求が挙げられる。

要求メッセージ３０６に応じて、ＭＳＲＰ２３０は、要求された情報を含むＭＳＲＰ状態応答メッセージ３０８をＳＩＰＵＡ２６０へ送信するであろう。すると、ＳＩＰＵＡ２６０は、例えばＳＩＰ２００ＯＫメッセージ３１０によって、セッション３０２に関する更新ＭＳＲＰ状態情報をＳ−ＣＳＣＦ２８０へ送信する。ＳＩＰ再ＩＮＶＩＴＥメッセージ３０４のように、ＳＩＰ２００ＯＫメッセージ３１０は、例えば、送信したデータのタイプ、送信したデータの量、送信するデータのタイプ、送信するデータの量についての情報を含むＭＳＲＰセッション状態に関するＳＤＰ情報を搬送することができる。ＳＩＰ２００ＯＫメッセージのこの部分の、純粋に説明のための例は、要求がアプリケーションサーバ２９０へ向かうことを示すＳＤＰメディアライン「ｍ＝（あるメディアネームおよびトランスポートアドレス）」とＳＤＰ属性ライン（すなわち「ａ＝（あるセッション属性）」とを使用すると、一実施形態例によれば以下となる。
M = message 4321 TCP / MSRP *
a=CDR_response:filename:”cool.jpg”:data_size_sent:”250KB”:data_size_remain:”0KB”
a=CDR_response:filename:”list.txt”:data_size_sent:”13KB”:data_size_remain:”0KB”
a=CDR_response:filename:”face.avi”:data_size_sent:”2500KB”:data_size_remain:”1000KB”

Ｓ−ＣＳＣＦ２６０は、問い合わせを開始したアプリケーションサーバ２９０にＳＩＰ２００ＯＫメッセージ３１０を送信する。アプリケーションサーバ２９０は、任意で、着信ＳＩＰ２００ＯＫメッセージ３１０からＭＳＲＰ状態情報を抽出し、例えばコール詳細記録（CDR：Call Detail Record）メッセージ３１４として、情報を料金請求システム（BS：billing system）３１２へ送信することができる。料金請求システム３１２は、典型的には、この情報の受信確認応答を応答３１６によって行う。アプリケーションサーバ２９０がその問い合わせ手続２０２の一部としてＣＤＲメッセージを送信するか否かにかかわらず、Ｓ−ＣＳＣＦ２８０を介してＳＩＰＡＣＫメッセージ３１８でＭＳＲＰ状態情報の受信確認を端末２００に返信するであろう。

上述のように、端末２００のＭＳＲＰ状態に関する問い合わせを開始したアプリケーションサーバ２９０は、返信された状態情報に基づいて、または応答がないことに基づいて、マルチメディア接続を終了すると決定することができる。これについては、例えば、終了するＭＳＲＰセッションが対応ＳＩＰセッションにおいて完了すべき最後のセッションである場合、図３に示すシグナリング手続３２０の方法によって達成することができる。ここでは、アプリケーションサーバ２９０が、例えば終了するＭＳＲＰセッションを識別するＳＤＰ「ｍ＝．．．」ラインを含むＳＩＰＢＹＥメッセージ３２２を送信する。ＳＩＰＢＹＥメッセージは、Ｓ−ＣＳＣＦ２８０に受信され、ＳＩＰＵＡ２６０に転送される。すると、ＳＩＰＵＡ２６０は、ＳＩＰＢＹＥメッセージを処理し、ＭＳＲＰセッションシャットダウン命令が受信されたと判定し、シャットダウン要求メッセージ３２４をＭＳＲＰ機能２３０へ送信する。ＭＳＲＰ機能２３０は、識別したＭＳＲＰセッションを終了し、応答メッセージ３２６をＳＩＰＵＡ２６０へ送信する。ＳＩＰＵＡ２６０は、ＳＩＰ２００ＯＫメッセージ３２８を使用して、要求するアプリケーションサーバ２９０に（Ｓ−ＣＳＣＦ２８０を介して）ＭＳＲＰセッションのシャットダウンの報告を返信する。

上述の実施形態例は、ピアツーピアマルチメディア接続の状態を問い合わせる様々な技術およびシステムを説明するものである。ここで述べるように、これについては、例えばアプリケーションサーバとＳ−ＣＳＣＦとの間など、ネットワーク内の端末装置と通信ノードとの間のシグナリングを含む。上述の様々なメッセージの送信、受信、処理が可能な通信ノードまたは端末装置例４００を、図４に示す。ここで、端末装置または通信ノード４００は、処理部４０２（または複数のプロセッサコア）と、記憶部４０４と、１または２以上の２次格納装置４０６と、ソフトウェアアプリケーション（または複数のアプリケーション）４０８と、インタフェース部４１０とのうちの１または２以上を有し、端末装置または通信ノード４００とネットワークの残りまたは携帯電話の場合の無線送受信部の代表との間の通信を容易にすることができる。例えば、図４に示す構造４００をネットワーク内の通信ノードとすると、処理部４０２は、例えばＳＩＰＵＡ２９１または２９５を含むことができるソフトウェアアプリケーション４０８と結合し、ピアツーピアマルチメディア接続の状態を問い合わせるメッセージを送信し、このピアツーピアマルチメディア接続の状態に関する応答を受信する。記憶部４０４または２次格納装置４０６は、状態問い合わせの応答で受信した状態情報など、上述のアイテム例の格納部として使用できる。あるいは、図４の構造４００を端末装置とする場合、処理部４０２は、例えばＳＩＰＵＡ２６０および／またはＭＳＲＰ機能２３０を含むことができるソフトウェアアプリケーション４０８と結合し、ピアツーピアマルチメディア接続の状態を問い合わせるメッセージを受信し、ピアツーピアマルチメディア接続の状態に関する応答を送信する。

実施形態例に係る上述の技術例およびシステム例を活用して、例えばネットワークの観点から、ピアツーピアマルチメディア接続の状態を問い合わせる方法例を、図５（ａ）に示す。ここでは、ステップ５００において、ピアツーピアマルチメディア接続の状態を問い合わせるメッセージがアプリケーションサーバから送信される。そして、ステップ５０２において、ピアツーピアマルチメディア接続の状態に関する応答がアプリケーションサーバにて受信される。同様に、端末の観点から、ピアツーピアマルチメディア接続に関する状態問い合わせを処理する方法を、図５（ｂ）に示す。ここでは、ステップ５０４において、ピアツーピアマルチメディア接続の状態を問い合わせるメッセージが端末装置にて受信される。そして、ステップ５０６において、ピアツーピアマルチメディア接続の状態に関する応答が端末装置から送信される。

上述の実施形態例については、あらゆる点で、本発明を例示したものであり、限定したつもりはない。したがって、本発明は、当業者によってこの明細書から導出可能な詳細な実施において、多くの変更が可能である。例えば上述の例において、状態問い合わせは、シグナリングパスの行程Ｌ_１〜Ｌ_２で行ったが、例えば、シグナリングパスの行程Ｌ_５〜Ｌ_６で行うことも可能である。このような変更例および修正例は、すべて、特許請求の範囲によって限定される本発明の範囲および趣旨の内のものと考えられる。本クラスの説明で使用した要素、動作、命令は、特に明記がない限り、いずれも本発明に対して決定的であり本質的であると解釈すべきではない。また、ここで冠詞「ａ」を使用した場合は、１または２以上のアイテムを含むことを意図している。

Claims

ピアツーピアマルチメディア接続の状態を問い合わせる方法であって、
前記ピアツーピアマルチメディア接続の状態を問い合わせるメッセージをアプリケーションサーバから送信するステップと、
前記ピアツーピアマルチメディア接続の状態に関する応答を前記アプリケーションサーバにおいて受信するステップと、
を含む方法。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で送信されたデータのタイプに関する、請求項１に記載の方法。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で送信されたデータの量に関する、請求項１に記載の方法。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で未だ送信されていないデータのタイプに関する、請求項１に記載の方法。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で未だ送信されていないデータの量に関する、請求項１に記載の方法。
前記メッセージは、前記状態の問い合わせが行われているマルチメディアセッションを識別するセッションデスクリプションプロトコル（ＳＤＰ）要素を搬送するセッション開始プロトコル（ＳＩＰ）ＩＮＶＩＴＥメッセージである、請求項１に記載の方法。
前記応答は、前記状態の問い合わせが行われているマルチメディアセッションに関する状態情報を含むセッションデスクリプションプロトコル（ＳＤＰ）要素を搬送するセッション開始プロトコル（ＳＩＰ）２００ＯＫメッセージである、請求項１に記載の方法。
前記ピアツーピア接続は、前記アプリケーションサーバを含むシグナリングパスと、２つのエンドユーザ装置を含むが前記アプリケーションサーバを含まないメディアパスとを含む、請求項１に記載の方法。
前記アプリケーションサーバが、前記応答に基づいて、前記ピアツーピアマルチメディア接続を終了するステップをさらに含む、請求項１に記載の方法。
前記アプリケーションサーバが、前記状態に関する課金情報を含むメッセージを料金請求システムへ送信するステップをさらに含む、請求項１に記載の方法。
ピアツーピアマルチメディア接続の状態を問い合わせるメッセージを送信し、前記ピアツーピアマルチメディア接続の状態に関する応答を受信する処理部を備える通信ノード。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で送信されたデータのタイプに関する、請求項１１に記載の通信ノード。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で送信されたデータの量に関する、請求項１１に記載の通信ノード。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で未だ送信されていないデータのタイプに関する、請求項１１に記載の通信ノード。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で未だ送信されていないデータの量に関する、請求項１１に記載の通信ノード。
前記メッセージは、前記状態の問い合わせが行われているマルチメディアセッションを識別するセッションデスクリプションプロトコル（ＳＤＰ）要素を搬送するセッション開始プロトコル（ＳＩＰ）ＩＮＶＩＴＥメッセージである、請求項１１に記載の通信ノード。
前記応答は、前記状態の問い合わせが行われているマルチメディアセッションに関する状態情報を含むセッションデスクリプションプロトコル（ＳＤＰ）要素を搬送するセッション開始プロトコル（ＳＩＰ）２００ＯＫメッセージである、請求項１１に記載の通信ノード。
前記ピアツーピア接続は、前記通信ノードを含むシグナリングパスと、２つのエンドユーザ装置を含むが前記通信ノードを含まないメディアパスとを含む、請求項１１に記載の通信ノード。
前記処理部は、前記応答に基づいて、前記ピアツーピアマルチメディア接続を選択的に終了する、請求項１１に記載の通信ノード。
ピアツーピアマルチメディア接続に関する状態問い合わせを処理する方法であって、
前記ピアツーピアマルチメディア接続の状態を問い合わせるメッセージを端末装置において受信するステップと、
前記ピアツーピアマルチメディア接続の状態に関する応答を前記端末装置から送信するステップと、
を含む方法。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で送信されたデータのタイプに関する、請求項２０に記載の方法。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で送信されたデータの量に関する、請求項２０に記載の方法。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で未だ送信されていないデータのタイプに関する、請求項２０に記載の方法。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で未だ送信されていないデータの量に関する、請求項２０に記載の方法。
前記メッセージは、前記状態の問い合わせが行われているマルチメディアセッションを識別するセッションデスクリプションプロトコル（ＳＤＰ）要素を搬送するセッション開始プロトコル（ＳＩＰ）ＩＮＶＩＴＥメッセージである、請求項２０に記載の方法。
前記応答は、前記状態の問い合わせが行われているマルチメディアセッションに関する状態情報を含むセッションデスクリプションプロトコル（ＳＤＰ）要素を搬送するセッション開始プロトコル（ＳＩＰ）２００ＯＫメッセージである、請求項２０に記載の方法。
前記ピアツーピア接続は、アプリケーションサーバを含むシグナリングパスと、前記端末装置と別の端末装置とを含むが前記アプリケーションサーバを含まないメディアパスとを含む、請求項２０に記載の方法。
前記端末装置内で動作中のセッション開始プロトコルユーザエージェント（ＳＩＰＵＡ）において前記メッセージを受信するステップと、
マルチメディア機能とやり取りして、前記ピアツーピアマルチメディア接続の状態を得るステップと、
を含む、請求項１に記載の方法。
ピアツーピアマルチメディア接続の状態を問い合わせるメッセージを受信し、前記ピアツーピアマルチメディア接続の状態に関する応答を送信する処理部を備える端末装置。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で送信されたデータのタイプに関する、請求項２９に記載の端末装置。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で送信されたデータの量に関する、請求項２９に記載の端末装置。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で未だ送信されていないデータのタイプに関する、請求項２９に記載の端末装置。
前記ピアツーピア接続の状態は、前記ピアツーピア接続で未だ送信されていないデータの量に関する、請求項２９に記載の端末装置。
前記メッセージは、前記状態の問い合わせが行われているマルチメディアセッションを識別するセッションデスクリプションプロトコル（ＳＤＰ）要素を搬送するセッション開始プロトコル（ＳＩＰ）ＩＮＶＩＴＥメッセージである、請求項２９に記載の端末装置。
前記応答は、前記状態の問い合わせが行われているマルチメディアセッションに関する状態情報を含むセッションデスクリプションプロトコル（ＳＤＰ）要素を搬送するセッション開始プロトコル（ＳＩＰ）２００ＯＫメッセージである、請求項２９に記載の端末装置。
前記ピアツーピア接続は、アプリケーションサーバを含むシグナリングパスと、前記端末装置と別の端末装置とを含むが前記アプリケーションサーバを含まないメディアパスとを含む、請求項２９に記載の端末装置。
前記端末装置内で動作中の、前記メッセージを受信するセッション開始プロトコルユーザエージェント（ＳＩＰＵＡ）と、
前記ピアツーピアマルチメディア接続を処理し、前記ＳＩＰＵＡとやり取りして前記応答に状態情報を提供するマルチメディア機能と、
を備える、請求項２９に記載の端末装置。