時間依存通信を最適化する方法及び通信ノード
通信ノード（ユーザ端末またはサーバ）が特定のタイプの通知メッセージを受信することを購読する場合に、例えばSIP SUBSCRIBE機構を用いる、通信方法及び通信ノードが提供される。ノードが後に音声通信のような時間依存アプリケーションに関与する際、時間依存アプリケーションへの関与に応じて、ノードは特定のタイプの通知メッセージの受信の購読の一時停止を要求する。このような要求は、例えばSIP SUBSCRIBEやSIP NOTIFYやSIP PUBLISHメッセージを用いて実現される。通信ノードは、特定のタイプの通知メッセージの受信を購読し、時間依存アプリケーションを開始する通信モジュールと、時間依存アプリケーションへの関与に応じて、特定のタイプの通知メッセージの受信の購読を一時停止するための要求の発行を受け持つサービス論理とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、時間依存通信を最適化する方法及びシステムに関する。
【背景技術】
【０００２】
セッション開始プロトコル（ＳＩＰ:Session Initiation Protocol）は、音声、ビデオ、チャット、ゲーム等のマルチメディア要素を含んでもよい通信セッションの開始をサポートする、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ:Internet Engineering Task Force）のインターネットプロトコルである。ＳＩＰはＨＴＴＰ（Hyper Text Terminal Protocol）やＳＭＴＰ（Simple Mail Transfer Protocol）のような他のプロトコルと同様、通信が可能であることを保証する責任を負う、開放型システム間相互接続（ＯＳＩ:open system interconnection）通信モデルのアプリケーション層で動作する。ＳＩＰはマルチメディアセッションやインターネット電話通信を確立でき、それらを修正または終了できる。このプロトコルは、ユニキャストまたはマルチキャストのセッションに、参加者をお互いに招待することや、開始者(initiator)が関与せずに、このようなセッションを確立することもできる。ＳＩＰはネームマッピングや転送サービスをサポートしているため、ユーザが末端位置から通信やサービスの開始及び受信を行うことを可能とするとともに、ユーザがどこにいてもネットワークがユーザを特定することを可能とする。ＳＩＰセッションの参加者はＳＩＰ ＵＲＬ（Uniform Resource Locators）によって特定される。要求は、例えばＵＤＰ（User Datagram Protocol）やＴＣＰ（Transfer Control Protocol）のような、いかなる転送プロトコルを介して送信されてもよい。ＳＩＰは、セッションに用いる末端システム、通信媒体及びそのパラメータ、及び通信に関与するための被呼者の要求を決定する。そしてこれらが確保されると、ＳＩＰは通信の両端において、呼パラメータを確立し、呼転送及び終了を処理する。ＳＩＰプロトコルは、ＩＥＴＦのＲＣＦ(request for comments)３２６１に規定され、当該ＲＦＣの全体を参照により本明細書に含める。
【０００３】
ＩＰマルチメディアサブシステム（ＩＭＳ:IP Multimedia Subsystem）は、インターネットプロトコルＩＰマルチメディアをモバイルユーザへ配信するためのアーキテクチャフレームワークである。それは当初はワイヤレス標準化団体の第３世代共同プロジェクト（３ＧＰＰ:third Generation Partnership Project）によって策定され、ＧＳＭ（General System for mobile Communications）から進化したモバイルネットワークの構想の一部である。もともと、３ＧＰＰ Ｒ５（Release 5）はＧＰＲＳ（汎用パケット無線システム:General Packet Radio Service）上でインターネットサービスを配信するための方式を示していたが、その後３ＧＰＰ、３ＧＰＰ２、及びＴＩＳＰＡＮ（Telecoms & Internet converged Services & Protocols for Advanced Networks。ＥＴＳＩ（欧州電気通信標準化機構:European Telecommunications Standards Institute）の標準化団体））により、例えばＷＬＡＮ（Wireless Local Area Networks）、ＣＤＭＡ２０００（Code Division Multiple Access 2000）、及び固定回線のような、ＧＰＲＳ以外のネットワークをサポートするように更新された。
【０００４】
インターネットとの統合を容易に提供するために、ＩＭＳはＳＩＰのようなＩＥＴＦプロトコルを可能な限り使用する。ＩＭＳは、現在はＩＰで稼動している伝統的なセルラーネットワークにおいても実装され、従来の回路交換型音声サービスに加え、例えばプッシュトゥトーク（ＰＴＴ）のようなＩＰベースの拡張追加サービスを提供するためにＳＩＰを使用する。
【０００５】
しかしながら、ＳＩＰは大きいメッセージサイズによっても特徴付けられる信号プロトコルであるため、セルラーネットワークで支配的な狭帯域の接続に関してＳＩＰを使用することは、輻輳問題を引き起こし得る。
【０００６】
ＳＩＰの興味深い機能の一つは、そのSUBSCRIBE/NOTIFYの機構である。この機構は、ＳＩＰベースのエンティティが、他のピアＳＩＰエンティティにおいて発生した特定のイベントに関して、当該ＳＩＰベースのピアエンティティの情報、またはエンティティに関する情報を受信することを可能にする。特定のイベントのSIP NOTIFYメッセージによるこの通知の発生は、もちろん、このピアエンティティにおける事前許可承認及び承認の対象である。
【０００７】
例えば、ＳＩＰの使用に基づくＩＭＳにおけるプレゼンスは、あるイベントについての通知を購読及び受信するために上述の機構を利用する。言い換えれば、ユーザまたはサーバは、通信相手のプレゼンス情報を購読することにより、その通信相手のプレゼンスまたはステータスを知らされることができる。購読が受け付けられると、通信相手のプレゼンス・ステータスの変更がある場合いつでも、その変更（例えばユーザＢのプレゼンス・ステータスが「ビジー」に変わった、ユーザＢのプレゼンス・ステータスが「オンライン」になった、ユーザＢは通信不可能になった、等）を知らせる通知が要求者に送信される。
【０００８】
一般的に、SUBSCRIBE/NOTIFY機構の通常の使用は、本質的に非同期のイベント、即ち、不定期な間隔で発生しうるイベントに対して適用される。言い換えれば、誰もそのようなイベントの発生頻度を予測できない。例えば、ユーザがプレゼンス・ステータスを頻繁に変更した場合、変更がなされるたびに、そのユーザのプレゼンス・ステータスを購読した他のピアに対して通知が生成される。このような場合に、複数回のプレゼンス更新通知によって生成されるトラフィックが、相当大きなサイズとなりうることは理解されよう。さらに、ＩＭＳにおける現在のプレゼンスアーキテクチャは、SUBSCRIBE/NOTIFY機構を、複数のユーザで共有するユーザリストの生成及びユーザリストの管理のような別の目的でも利用する。プレゼンス・リストは、Ｅメールの配信リストと同様、ユーザがリストサーバで運営されているユーザリストに１つの購読を発行することが可能であり、リストサーバはユーザリストの全てのメンバに最終的な購読(back-end subscription)を生成する。これは、個別に購読を行う場合と同様の利点を実現しながら、ユーザがリストのそれぞれのユーザに対して個別に購読を発行する労力を省く。さらには無線リソースに不安のあるセルラー環境におけるＳＩＰ信号伝達を節約できるという効果もある。したがって、ユーザはリストのいかなるメンバのプレゼンスに変更が生じようとも、当該プレゼンスの変更が通知されるように、他の複数のユーザを含むプレゼンス・リストを購読してもよい。
【０００９】
それ故に、ＩＭＳネットワークには予測不可能な方法でトラフィックを生成し得る多数のノードが存在する。トラフィックは、例えば音声通信やビデオ会議やＰＴＴのような他の時間依存アプリケーションと自身に固有のトラフィックチャネルを相互に共有する、複数のユーザ装置（ＵＥ:User Equipment。本明細書では代わりにユーザ端末と呼ぶ）に宛てられる。そのため、音声通信等の時間依存アプリケーションを行っている間の、プレゼンス通知のような、複数の通知メッセージをＵＥが受信することは、ライブ音声通信の品質の劣化、または瞬間的な通信の中断の原因となり得る。
【００１０】
予測していないトラフィックがＵＲに到達した際の、ライブ音声通信セッションの品質の劣化の問題に対処するために、試みられている多数の解決策が存在する。しかしながら全ての解決策は、レート制御及びプレゼンス・メッセージの長さの最小化により、トラフィックを減らすことを目的としている。プレゼンス・メッセージのサイズの制限するための、プレゼンス・ステータスの数の減少、及びトラフィックを圧縮してサイズを縮小するための圧縮アルゴリズムの使用の少なくともいずれかを含んだ技術が開発された。しかしながら上述の解決策はいずれも、プレゼンスに関連するトラフィックが、ＵＥの音声通信にマイナスの影響を与えない、実行可能な解決策を提供できない。
【００１１】
上述した問題点を解決するための従来技術の解決策は存在しないが、以下に提案するハチソンの特許文献１は、本発明の分野と一部関連している。この特許文献１には、タイムクリティカルな通信が起こりそうな時期を予測する機能が記載されている。このような予測に基づき、他の通信は、タイムクリティカルな通信を干渉しないであろう時期に送信される。インスタントメッセージ（ＩＭ）を含む、異なる複数のクラスでのスケジューリング送信を伴う方法は、SIP INVITEメッセージ、及び登録通信または応答を含む第１クラスでの通信が発生しそうな時間枠を決定する。第２クラスの通信の伝送は、第１クラスの通信のために予測され、決定された時間枠の間は起こらないようにスケジューリングされる。しかしながら、特許文献１はいつ通信が発生するかを予想において、予測する方法に限定されており、本発明の概念の教示や示唆まではしていない。
【００１２】
図１（従来技術）を参照する。図１は、プレゼンス・イベント情報を送信するために２ユーザ間でＳＩＰのSUBSCRIBE/NOTIFY機構を用いる例示的な従来技術シナリオの単純化されたハイレベルノード操作及び信号のフロー図である。図１に示される、単純化されたＩＭＳネットワーク１００は、第１のユーザ端末（ＵＥ）Ａ１０２、及び第２のユーザ端末（ＵＥ）Ｂ１０４を備える。図１で説明される動作は、任意のユーザに関連するプレゼンス・イベント情報の購読によって、要求者がそのようなプレゼンス・ステータスの変更が発生した際に通知され得る方法を示している。動作１０６において、要求者ユーザ端末Ａ１０２はユーザ端末Ｂに関するプレゼンス・イベント情報の購読を行うために、SIP SUBSCRIBEメッセージをユーザ端末Ｂ１０４に送信する。（なお、SIP ACKや200 OKメッセージのような、ＳＩＰの承認及び確認メッセージは簡単のため省略される。）動作１０７においてユーザ端末Ｂは、メッセージを受信すると、SIP NOTIFYメッセージを通じて、ユーザ端末Ｂ１０４に関する、（ユーザＢのプレゼンス情報＝「ビジー」）を現在有するプレゼンス・イベント情報１０９をユーザＡ１０２に通知する。さらなる動作１１０において、ユーザ端末Ｂのプレゼンス・イベント情報の変更は起こりうる（例えばイベント＝ユーザＢのステータス「ビジー」から「アイドル」に変更）。そして結果として、ユーザ端末Ｂ１０４は、ユーザＡ１０２に変更を通知するために、新しいプレゼンス情報１１４（例えばユーザＢの新しいプレゼンス情報＝「アイドル」）を有するユーザ端末Ａ１０２宛の第２のSIP NOTIFYメッセージを、動作１１２において発行する。
【００１３】
図２（従来技術）を参照する。図２は、同じユーザ端末Ａ１０２及びプレゼンス・サーバ２０４を備えるＩＭＳネットワーク１００’を示している。ここでは、ユーザはプレゼンス・ステータス情報を発行するためにプレゼンス・サーバ２０４を用いることと、プレゼンス・サーバ２０４がユーザ端末Ａ１０２と同じようなネットワーク１００’のユーザに対してプレゼンスに関連するサービスを提供することとを前提とする。図２は、ユーザ端末Ａ１０２が、ユーザ端末Ｂ１０４のような、他のプレゼンスエンティティに関連するプレゼンス情報を受け取るために、どのようにしてプレゼンス・サーバ２０４に購読を行えばよいかを示している。最初の動作２０６において、ユーザ端末Ａ１０２は、プレゼンス・サーバ２０４からプレゼンス・イベント情報を受け取るために、イベント及び状態２０８の少なくともいずれかを有する、SIP SUBSCRIBEメッセージを、プレゼンス・サーバ２０４に送信することによって購読を行う。（なお、図２でもいくつかのＳＩＰの承認及び確認メッセージは、簡単のため省略されることに留意されたい。）図２に示される特定例において、イベント２０８はユーザＡ１０２がユーザ端末Ｂ（図２には示さず）のプレゼンスの変更があったときに、通知の受信を所望していることを特定する。SUBSCRIBEメッセージ２０６に応答してサーバ２０４は、プレゼンス・サーバ２０４が現在ユーザ端末Ｂに関して有している、最初のプレゼンス情報２１１（例えばユーザＢのプレゼンス情報＝「忙しい」）を有するSIP NOTIFYメッセージ２０９を応答する。その後プレゼンス・サーバ２０４は、ユーザ端末Ｂのプレゼンス・ステータスの変更を含む、プレゼンス情報更新を有するSIP PUBLISHメッセージ２１２を受信する。これにより、動作２１３においてプレゼンス・サーバ２０４は、ユーザＢについてのプレゼンス情報の変化が、そのような情報を用いてユーザ端末Ａ１０２を更新するように指定されているイベント２０８に合致していることに気づく。結果として動作２１４においてプレゼンス・サーバ２０４は、ユーザ端末Ｂの更新されたプレゼンス情報２１６を有する新しいSIP NOTIFYメッセージ（例えばユーザＢのプレゼンス情報＝「アイドル」）を発行する。
【００１４】
図３（従来技術）を参照する。図３は、ユーザ端末Ａ３０２及びユーザ端末Ｃ３０４を備える単純化されたＩＭＳネットワーク３００のハイレベルノード動作及び信号のフロー図である。図３には、従来技術の、プレゼンス・イベント情報の送信方法の欠点が図示されている。動作３０６においてユーザ端末Ａ３０２は、ライブ音声セッションにユーザ端末Ｃ３０４を招待するためにユーザ端末Ｃ３０４へのSIP INVITEメッセージを発行する。（なお、いくつかのＳＩＰ承認及び確認メッセージは簡単のため省略されてもよいことに留意されたい。）動作３０８において、ユーザＣ３０４は応答として、ライブ音声セッションへの参加を受け入れることを確認する、SIP 200 OKメッセージを返す。そして動作３１０において、２つのユーザ端末間でライブ音声セッションが確立され、ライブ音声セッションはその後、ライブ音声通信のやり取りをするために、ライブセッションを使用することが可能である。しかしながら、先に述べたように、ライブ通信中に一方のユーザによってプレゼンス情報の通知が受信された場合に問題が発生するかもしれない。これは、本例示的なシナリオにおける場合に想定される、ライブセッション及びプレゼンス・トラフィックが同じトラフィックチャネルを使用した状況において、さらに悪化する。例えば、ユーザ端末Ａ３０２が動作３１４、３１６及び３１８において、ユーザＡ３０２が購読した（前の個々の購読は図３には図示せず）、プレゼンスエンティティに関連するプレゼンス情報を有する個々のSIP NOTIFYメッセージを受信する。このような通知の受信の結果として、ユーザ端末Ａ３０２はライブセッション３１０とともに瞬断３２０ｉを経験し得る。このような瞬断は、ライブセッション３１０上で受信及び送信される音声信号における重大な悪化を引き起こし得る。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】国際公開第２００５／０３４４７７号パンフレット
【発明の概要】
【００１６】
よって、既存の解決策の欠陥及び欠点を打開するため、上述した欠陥を効率的に解決する解決策を有することが好都合であろうことは容易に理解される。本発明は、このような方法及びシステムを提供する。
【００１７】
１つの局面では、本発明は、ユーザ端末またはサーバが特定のタイプの通知メッセージの受信を購読する際に開始される通信方法である。音声通信のような時間依存アプリケーションにおいてユーザ端末またはサーバが後に関与する際、ユーザ端末またはサーバは、時間依存アプリケーションへの関与に応じて、特定のタイプの通知メッセージの受信の購読の一時停止を要求する。このような要求は、例えばSIP SUBSCRIBEやSIP NOTIFYやSIP PUBLISHメッセージを用いて実現される。
【００１８】
別の局面では、本発明は、特定のタイプの通知メッセージの受信を購読し、時間依存アプリケーションを開始する通信モジュールと、時間依存アプリケーションにおける関与に応じて、特定のタイプの通知メッセージの受信の購読を一時停止するための要求の発行を支持するサービス論理モジュールを備える通信ノードである。
【００１９】
発明のさらなる詳細な理解、そのさらなる目的及び利点のために、以下の記述を添付の図面と併用して、これから参照する。
【図面の簡単な説明】
【００２０】
【図１】プレゼンス・サービスの従来技術による実装を例示する、ノード操作及び信号のフロー図。
【図２】プレゼンス・サービスの従来技術による実装を例示する、別のノード操作及び信号のフロー図。
【図３】プレゼンス・サービスの従来技術による実装を例示する、さらに別のノード操作及び信号のフロー図。
【図４】本発明の好ましい実施形態の、第１の可能な変形物を例示するハイレベルノード操作及び信号のフロー図。
【図５】本発明の好ましい実施形態の、第２の可能な変形物を例示する別のハイレベルノード操作及び信号のフロー図。
【図６】本発明の好ましい実施形態の、第３の可能な変形物を例示するさらに別のハイレベルノード操作及び信号のフロー図。
【図７】本発明の好ましい実施形態の、電気通信ノードでの例示的な実現の実例となるハイレベルブロック図。
【発明を実施するための形態】
【００２１】
本発明の革新的な内容は、様々な例示的な実施形態への詳細な言及を用いて述べられるだろう。しかしながら、この分類の実施形態が、発明の革新的な内容の、多くの有利な使用のうちの、いくつかの例だけを提供することは理解されるべきである。一般に、本願の明細書の記載は、特許請求の範囲に記載された本発明の様々な態様のいずれかを必ずしも限定しない。さらに、一部の記載は、いくつかの独創的な機能に当てはまるが、他の機能には当てはまらなくてもよい。図において、同様または類似の要素は、いくつかの図を通じて、同一の参照番号で指定される。
【００２２】
本発明、及び本発明に関連する好ましい実施形態によれば、プレゼンス通知のような、例えばユーザ端末の時間依存アプリケーション（例えば音声またはビデオ通信）に干渉するかもしれないデータトラフィックをユーザ端末がこのような時間依存アプリケーションに関与している間一時停止することを可能にする方法、システム及び電気通信ノードが提供される。発明によれば時間既存アプリケーションサービスの品質を保つため、購読者が時間依存アプリケーションに関与すると、１つまたは複数のノード（ユーザ端末またはアプリケーションサーバ）にメッセージの送信を一時停止するように要求するために、SIP SUBSCRIBE/NOTIFYメッセージ方式またはSIP PUBLISHメッセージのような、様々な構造が用いられてよい。
【００２３】
図４を参照する。図４は、発明の好ましい実施形態を実行する単純化された例示的なネットワーク４００の、例示的なノード操作及び信号のフロー図を示している。ネットワーク４００は、ユーザ端末Ａ４０２、ユーザ端末Ｂまたはサーバ（ここではノード４０４として示される）の他に、他のユーザ端末またはアプリケーションサーバＣ（ここではノード４０６として示される）を備える。ユーザ端末及びサービス４０２、４０４及び４０６は、例えばＳＩＰ信号伝達を用いることにより、ネットワーク４００における通信を継続可能である。始めに、動作４０８において、ユーザ端末Ａ４０２は、ユーザ端末Ａ４０２がノード４０６から受信を所望しているプレゼンス・イベント情報のタイプを特定する、プレゼンス・イベントまたは状態４１０を含むSIP SUBSCRIBEメッセージを発行することにより、ノード４０６からプレゼンス・イベント情報を受信するために購読してよい。例えば、プレゼンス・イベントまたは状態４１０は、例えば第１のステータスから第２のステータスになった等、プレゼンス・イベント情報が更新される度に、ユーザ端末Ａ４０２がプレゼンス・サーバ４０６から受信を所望している、ユーザＸ（不図示）に関連するプレゼンス・イベント情報を特定してもよい。動作４１２において、ノード４０６はメッセージ４０８を受信し、ユーザ端末Ａ４０２の購読を登録することにより、プレゼンス・イベントまたは状態４１０を格納する。ここで説明されている本発明の好ましい実施形態を実施する目的のために、ユーザ端末Ａ４０２が、ノードＢ４０４とライブ通信セッションに関与することを要求し、ライブ通信セッション４１６の要求を含むSIP INVITEメッセージ４１４を発行するものとする。動作４１８において、ユーザ端末Ｂ４０４はユーザ端末Ａ４０２へのSIP 200 OKメッセージを返送することにより、ユーザ端末Ａ４０２に要求されたライブ通信セッションへの参加承諾の通知を返す。最終的に、通話相手４０２及び４０４の両方は、両者間のライブ通信セッション４２０を確立する。本発明の好ましい実施形態によれば、動作４２２においてユーザ端末Ａ４０２は、このライブ通信セッションを独占的にサポートするために指定された、別個のトラフィックチャネルを有するかどうかを調べる。もしそうなら、すなわち、ライブ通信セッション４２０が別個のトラフィックチャネルを独占的に使用する場合には、さらなる動作４２４においてユーザ端末Ａ４０２は別個のトラフィックチャネルがアイドル状態か否か、即ち使用可能であるか否かを検出する。トラフィックチャネルが存在し、使用可能である場合、ライブ通信セッションの品質は、ノード４０６からプレゼンスに関連する通知メッセージ（または例えばインスタントメッセージ等のその他の通知メッセージ）を受け取ることにより悪影響を引き起こさないとの結論を出す。そして、ライブ通信セッションの品質を保護する、さらなる動作が必要ないとして、ステップ４２６で方法は終了する。一方、動作４２４において、ライブ通信セッションが独占的に使用するために指定されたトラフィックチャネルがダウンしている、またはアクセスできないと、判別された場合、または動作４２２においてユーザ端末Ａ４０２がライブ通信セッション４２０と例えばプレゼンス通知メッセージの受信の両方を実行するために、同じトラフィックチャネルを使用していると判別された場合、動作４２８でユーザ端末Ａ４０２は、ライブ通信セッション４２０の瞬断を回避するために、ノード４０６からのプレゼンス・メッセージの受信を一時停止するように動作する。ユーザ端末Ａ４０２は、先の動作４１２で登録された購読を終了するために、指示４３２を含む、ノード４０６に送信されるSIP NOTIFYメッセージ４３０を使用することができる。動作４３４において、ノードＣ４０６はユーザ端末Ａ４０２の購読を終了し、SIP 200 OKメッセージ４３６を用いて終了を確認する。動作４２８の結果として、ユーザ端末Ａ４０２は、ライブ通信セッション４２０の間、もはやノードＣ４０６からの通知メッセージを受信しない。その後、動作４３８において、ユーザ端末Ａ４０２はライブ通信セッションを終了できるように、ノードＢ４０４に対しSIP BYEメッセージを発行することによって、ライブ通信セッションを終了する。ライブセッションの終了のあと、ノードＣ４０６のプレゼンス・イベント情報のための購読を再度確立するために、ユーザＡ４０２は新しいSIP SUBSCRIBEメッセージ４４０を発行する。具体的には、メッセージ４４０にプレゼンス・イベントまたは状態４１０を含めることによって、ノードＣ４０６のプレゼンス・イベント情報のための購読を再度確立する。動作４４２において、ノード４０６はイベントまたは状況４１０を格納し、再びユーザ端末Ａ４０２のプレゼンス通知メッセージのための購読を登録する。動作４４４において、ノードＣ４０６は、（例えば、不図示のユーザＸに関連するプレゼンス・イベント情報の更新の結果として）特定されたイベントまたは状態４１０の発生を検出する。この検出により、プレゼンス通知４６６が、プレゼンス・イベント情報４４７を搬送するSIP NOTIFYメッセージの形式で、要求されたプレゼンス情報（ユーザＸのプレゼンス・イベント情報の更新）とともにユーザ端末Ａ４０２に返送されることになる。
【００２４】
図５を参照する。図５は、同一のノード４０２、４０４及び４０６を備える、上述したものと同一の例示的なネットワーク４００における別のハイレベルノード動作及び信号のフロー図を示している。図５には、前述したものと同様の動作４０８及び４１２が示され、この動作により、ユーザ端末Ａ４０２は、イベントまたは状態４１０の発生に応じたユーザＸ（不図示）に関連するプレゼンス・イベント情報をノード４０６から受信するための購読を行う。図５は、プレゼンス通知の送信の一時停止を可能にするために、ユーザ端末Ａ４０２がライブ通信セッションに関与する際にノード４０６に通知する別の方法を含む、発明の好ましい実施形態の別の変形例を示している。このような変形例は動作４１５で開始する。動作４１５において、ユーザ端末Ａ４０２がライブ通信セッションのような時間依存アプリケーションに関与する際にノード４０６に通知するように、ノード４０６がユーザＡ４０２に要求するためにも、ＳＩＰのSUBSCRIBE/NOTIFY機構が使用される。ノード４０６は、ユーザ端末Ａ４０２によってライブ通信セッションが確立された際に、また必要に応じて、そのようなライブセッションが別個のトラフィックチャネルを使用するように指定もしくは割り当てされていない際に、通知をノード４０６に戻させるようなイベント４１３の定義を含んだSUBSCRIBEメッセージ４１５をユーザ端末Ａ４０２に送信する。動作４１８において、ユーザ端末４０２はイベント４１３を格納する。その後、ユーザ端末Ａ４０２は、ライブ通信セッションの確立要求４１６を含むSIP INVITEメッセージ４１４を、ユーザ端末Ｂ４０４に発行することにより、ライブ通信セッション４２０を確立する。ノード４０４からSIP 200 OKメッセージ４１８によって承諾が確認されると、ライブ通信セッション４２０は確立される。
【００２５】
動作５２２において、イベント４１３を格納しているユーザ端末Ａ４０２は、ライブセッション４２０の確立をノード４０６に通知すべきであることを検出する。検出５２２は図４のステップ４２２及び４２４ですでに述べたものと同一のステップを含んでよい。それ故に動作５２２において、ユーザ端末Ａ４０２はライブ通信セッションが、別個のトラフィックチャネルの使用を割り当てることなく確立されたと判定する。そして動作５２４において、ユーザ端末Ａ４０２はプレゼンス・イベント情報の送信の一時停止を要求するために、ノード４０６へのSIP NOTIFYメッセージを発行する。このため、NOTIFYメッセージ５２４は、一時停止要求５２５と、必要に応じて、別個のトラフィックチャネルが割り当てられていないライブセッションの確立に関する情報５２７とを含む。メッセージ５２４はノード４０６によって受信され、動作５２６においてノード４０６は、ライブ通信セッションがユーザ端末Ａ４０２によって受信されるいかなるメッセージの干渉によっても中断されないように、ユーザ端末Ａ４０２へのプレゼンスに関連する情報の送信を一時停止する。その後、ユーザ端末Ａ４０２は動作５２８においてライブ通信セッションの終了を決定し、このためノード４０４にSIP BYEメッセージ５３０を発行し、さらに動作５３４においてノード４０６に、これ以上ライブセッションが存在しないことを通知する。通知５３４の結果として、ノード４０６は動作５３８において、はじめに動作４１２で生成された購読を再度有効化する。そのうちユーザＸに関連するプレゼンス・イベント情報を受信すると、ノード４０６は動作５４０において、ユーザ端末Ａ４０２にプレゼンス情報５４２を通知する。
【００２６】
図６を参照する。図６はユーザ端末がライブ通信セッションのような時間依存アプリケーションに関与する際、セッション中のプレゼンス・メッセージの受信が一時停止されるよう、ノードに通知するための発明の好ましい実施形態のさらに別の変形例の、さらに別のノード動作及び信号のフロー図を示している。図６には、ノード４０２、４０４及び４０６を備える同一のネットワーク４００が示されており、ユーザ端末Ａ４０２は動作４０８において、ノード４０６のプレゼンス・イベント情報を受信するために再び購読を行う。そしてノード４０６は動作４１２においてイベントまたは状態の定義４１０を格納し、プレゼンス・イベント情報の発生がユーザ端末Ａ４０２に転送される。動作４１４及び４１８において、ユーザ端末Ａ４０１はノードＢ４０４と、再びライブ通信セッション４２０を確立する。動作６２０において、ユーザ端末Ａ４０２はライブ通信セッション４２０の瞬断を避けるため、プレゼンス・メッセージの転送の一時停止を要求するためにノード４０６に通知する必要性を検出する。検出６２０は、図４の４２２及び４２４で既に述べたものと同一のステップを含んでよい。発明の好ましい実施形態の本変形例によれば、動作６２２において、ユーザ端末Ａ４０２は、一時停止要求６２１と、必要に応じて、別個のトラフィックチャネル６２４の割当なしにライブ通信セッションを確立したことを知らせる情報６２４とを含む、プレゼンス・イベント情報の送信の一時停止を要求するSIP PUBLISHメッセージ６２２を発行する。SIP PUBLISHメッセージ６２２はノード４０６で受信され、動作６２６においてノード４０６はユーザ端末Ａ４０６に、プレゼンスに関連する情報の送信を一時停止する。その後、動作６２８において、ユーザ端末Ａ４０２はSIP BYEメッセージ６３０を発行することによりライブ通信セッションを閉じ、動作６３２において、必要であればプレゼンス・メッセージ転送が再開できるように、ノード４０６へのセッション終了通知の必要性を検出する。このため、動作６３４において、ユーザ端末Ａ４０２は、ライブセッションが存在しないことを表す情報６３６を含むノード４０６への新しいSIP PUBLISHメッセージを発行する。そしてPUBLISHメッセージ６３４を受信すると、ノード４０６はユーザ端末Ａ４０２へのプレゼンス・メッセージ送信を再度有効化する。そのうち、ユーザ端末Ａ４０２が所望しているプレゼンス・イベント情報に関する何らかの情報がノード４０６によって受信されると、動作６３８においてノード４０６は、ユーザ端末Ａ４０２が所望しているプレゼンス情報６４０（ユーザＸに関する何らかの更新されたプレゼンス情報）を含む、新しいSIP NOTIFYメッセージを発行する。
【００２７】
図７を参照する。図７は本発明の好ましい実施形態に係る電気通信ノード７００の例示的なハイレベル機能ブロック図を示している。ノード７００は、上述したサーバまたはユーザ端末であってよく、サービス論理モジュール７０４及びＳＩＰスタックモジュールの型を有してもよい通信モジュール７０６に接続された、セッションマネージャモジュール７０２を実装する。Ｉ／Ｏインタフェース７０８は他のノードとの通信に用いられ、外部ノードからのＳＩＰメッセージの受信に関与し、外部ノードにＳＩＰメッセージを転送するために用いられる。通信モジュール７０６は、ノード７００によって発行及び受信されたそれぞれの生成及び解釈に関与する。セッションマネージャ７０２は、分離または共有された、ノード７００により処理される通信セッションに関連するトラフィックチャネルの確立を検出及び管理するために用いられる。サービス論理７０４は、時間依存アプリケーションがノード７０６で開始されたことを検出し、通信モジュール７０６に他のノードからの通知メッセージの受信を一時停止するためのメッセージを発行させるように指示することを含む本発明を実行するために用いられる。例えば、図４、５，６及び７をまとめて参照すると、ＳＩＰスタックはＳＩＰセッション４２０を確立するための、メッセージ４１４及び４１８の交換を受け持つ。動作４２２及び４２４はサービス論理７０４によって達成され、ライブ通信セッションに別個のトラフィックチャネルが割り当てられたか否か、及びセッションマネージャ７０２から得られた情報によって、チャネルが使用されていないか否かを検出する。動作４２２または４２４のいずれか一つの回答が否であれば、継続しているライブ通信が存在する場合、プレゼンスに関連するメッセージの受信を一時停止するための要求をノード４０６に通知するために、例えばSIP SUBSCRIBEメッセージ４３０のような適切なＳＩＰメッセージを発行するよう、サービス論理７０４はＳＩＰスタックに指示する。同様に、図５及び７をまとめて参照し、通信モジュール７０６によって処理された、メッセージ４１６及び４１８の交換によって、ライブ通信セッション４２０が確立した時点で、動作５２２においてサービス論理７０４は、プレゼンスに関連するメッセージが一時停止されるべきであるかを、ノード４０６に通知する必要性を検出する。動作５２８において通信モジュール７０６がライブ通信セッションを閉じた時点で、サービス論理７０４はセッションが閉鎖されたことを通知され、動作５３２においてアプリケーションサーバ４０６に返送するSIP NOTIFYメッセージの発行の必要性を検出する。なお、これらの動作は通信モジュール７０６によって達成される。最後に、図６及び７の両方を参照し、検出６２０及び６３２は、サービス論理７０４によって達成され、ＳＩＰメッセージ６１４及び６３４は、通信モジュール７０６によって、他のノード４０６に対し発行させる。
【００２８】
それ故に、本発明により、例えばユーザ端末またはサーバのような電気通信ノードに、ライブ通信セッション（例えば音声やビデオ会議通信）のような時間依存アプリケーションに関与すること、及びライブ通信セッションに干渉するかもしれないメッセージ（例えばプレゼンスに関連するメッセージ）の受信を一時停止することを可能とする。本発明の例示的な実施形態は、プレゼンスに関連するメッセージに言及して主に説明したが、本発明の応用は単にプレゼンスに関連するメッセージの一時停止に限定されず、むしろライブ通信セッションのような時間依存アプリケーションの間に受信されることになっている、他のタイプのメッセージの一時停止に有利に用いられることが可能であることは、本技術分野に属する当業者によって理解される。例えば、ユーザ端末は、例えばＳＭＳ（Short Message Service）やＭＭＳ（Multimedia Messaging Service）やＩＭＳ（IP Multimedia Subsystem）メッセージとして送信される気象通知のような、他のタイプの通知を購読してもよく、発明は図４、５及び６に述べられた通り、時間依存アプリケーションに関与する際に、ＳＭＳサーバやＭＭＳサーバやＩＭＳサーバにユーザが通知することを可能としてもよい。本発明は、ライブ通信が確立された際に、メッセージの送信を一時停止することを他のユーザまたはアプリケーションサーバに通知するための、例えばSIP PUBLISHメッセージまたはSIP SUBSCRIBE/NOTIFY機構等の、ＳＩＰメッセージを用いた、単純で効果的な方式を提供する。しかしながら、他の通信プロトコルもまた、これらの通知を実行するために用いられてもよいことは理解できる。発明のさらなる実施形態においては、ライブ通信セッションが分離されたトラフィックチャネルに割り当てられていない場合、あるいはトラフィックチャネルが使用されていない（例えば故障やその他利用できない）場合にのみ、対応するノードに通知を送信するよう、さらなる計算を行うことも可能である。
【００２９】
上述の説明に基づき、本発明が例えば音声通信またはビデオ会議のような時間依存アプリケーションの品質を維持する、単純でさらに効率的な方法を提案する、有利な解決策を提供することは、本技術分野に属する当業者によって理解されるべきである。本発明のシステム及び方法は、特定のタイプのメッセージ及びノードの特定な言及が述べられたものであるが、本文書に含まれる革新的な教示が、必ずしも上述の言及に限定されるものでなく、通話相手が購読する、いかなるタイプのメッセージ、及びいかなるタイプの信号伝達プロトコルで有利に実装されてもよいことは、本文書の参照によって実現されるべきである。本発明の実施及び構成は、上述の記載から明らかであると確信する。参照及び述べられた方法及びシステムは、好ましいものとして特徴付けられているが、以下に説明する請求項によって定義される発明の範囲から逸脱しない範囲で、様々な変更及び修正がなされてもよいことは容易に理解できよう。
【００３０】
本発明の方法及びシステムの、いくつかの好ましい実施形態が、添付の図面に図示、及び上述の詳細な説明に記載されているが、発明が開示された実施形態に限定されるものなく、以下の請求項によって説明、及び定義される発明の範囲から逸脱せずに、多数の再配列、修正、及び置き換えが可能であることは理解されよう。
【技術分野】
【０００１】
本発明は、時間依存通信を最適化する方法及びシステムに関する。
【背景技術】
【０００２】
セッション開始プロトコル（ＳＩＰ:Session Initiation Protocol）は、音声、ビデオ、チャット、ゲーム等のマルチメディア要素を含んでもよい通信セッションの開始をサポートする、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ:Internet Engineering Task Force）のインターネットプロトコルである。ＳＩＰはＨＴＴＰ（Hyper Text Terminal Protocol）やＳＭＴＰ（Simple Mail Transfer Protocol）のような他のプロトコルと同様、通信が可能であることを保証する責任を負う、開放型システム間相互接続（ＯＳＩ:open system interconnection）通信モデルのアプリケーション層で動作する。ＳＩＰはマルチメディアセッションやインターネット電話通信を確立でき、それらを修正または終了できる。このプロトコルは、ユニキャストまたはマルチキャストのセッションに、参加者をお互いに招待することや、開始者(initiator)が関与せずに、このようなセッションを確立することもできる。ＳＩＰはネームマッピングや転送サービスをサポートしているため、ユーザが末端位置から通信やサービスの開始及び受信を行うことを可能とするとともに、ユーザがどこにいてもネットワークがユーザを特定することを可能とする。ＳＩＰセッションの参加者はＳＩＰ ＵＲＬ（Uniform Resource Locators）によって特定される。要求は、例えばＵＤＰ（User Datagram Protocol）やＴＣＰ（Transfer Control Protocol）のような、いかなる転送プロトコルを介して送信されてもよい。ＳＩＰは、セッションに用いる末端システム、通信媒体及びそのパラメータ、及び通信に関与するための被呼者の要求を決定する。そしてこれらが確保されると、ＳＩＰは通信の両端において、呼パラメータを確立し、呼転送及び終了を処理する。ＳＩＰプロトコルは、ＩＥＴＦのＲＣＦ(request for comments)３２６１に規定され、当該ＲＦＣの全体を参照により本明細書に含める。
【０００３】
ＩＰマルチメディアサブシステム（ＩＭＳ:IP Multimedia Subsystem）は、インターネットプロトコルＩＰマルチメディアをモバイルユーザへ配信するためのアーキテクチャフレームワークである。それは当初はワイヤレス標準化団体の第３世代共同プロジェクト（３ＧＰＰ:third Generation Partnership Project）によって策定され、ＧＳＭ（General System for mobile Communications）から進化したモバイルネットワークの構想の一部である。もともと、３ＧＰＰ Ｒ５（Release 5）はＧＰＲＳ（汎用パケット無線システム:General Packet Radio Service）上でインターネットサービスを配信するための方式を示していたが、その後３ＧＰＰ、３ＧＰＰ２、及びＴＩＳＰＡＮ（Telecoms & Internet converged Services & Protocols for Advanced Networks。ＥＴＳＩ（欧州電気通信標準化機構:European Telecommunications Standards Institute）の標準化団体））により、例えばＷＬＡＮ（Wireless Local Area Networks）、ＣＤＭＡ２０００（Code Division Multiple Access 2000）、及び固定回線のような、ＧＰＲＳ以外のネットワークをサポートするように更新された。
【０００４】
インターネットとの統合を容易に提供するために、ＩＭＳはＳＩＰのようなＩＥＴＦプロトコルを可能な限り使用する。ＩＭＳは、現在はＩＰで稼動している伝統的なセルラーネットワークにおいても実装され、従来の回路交換型音声サービスに加え、例えばプッシュトゥトーク（ＰＴＴ）のようなＩＰベースの拡張追加サービスを提供するためにＳＩＰを使用する。
【０００５】
しかしながら、ＳＩＰは大きいメッセージサイズによっても特徴付けられる信号プロトコルであるため、セルラーネットワークで支配的な狭帯域の接続に関してＳＩＰを使用することは、輻輳問題を引き起こし得る。
【０００６】
ＳＩＰの興味深い機能の一つは、そのSUBSCRIBE/NOTIFYの機構である。この機構は、ＳＩＰベースのエンティティが、他のピアＳＩＰエンティティにおいて発生した特定のイベントに関して、当該ＳＩＰベースのピアエンティティの情報、またはエンティティに関する情報を受信することを可能にする。特定のイベントのSIP NOTIFYメッセージによるこの通知の発生は、もちろん、このピアエンティティにおける事前許可承認及び承認の対象である。
【０００７】
例えば、ＳＩＰの使用に基づくＩＭＳにおけるプレゼンスは、あるイベントについての通知を購読及び受信するために上述の機構を利用する。言い換えれば、ユーザまたはサーバは、通信相手のプレゼンス情報を購読することにより、その通信相手のプレゼンスまたはステータスを知らされることができる。購読が受け付けられると、通信相手のプレゼンス・ステータスの変更がある場合いつでも、その変更（例えばユーザＢのプレゼンス・ステータスが「ビジー」に変わった、ユーザＢのプレゼンス・ステータスが「オンライン」になった、ユーザＢは通信不可能になった、等）を知らせる通知が要求者に送信される。
【０００８】
一般的に、SUBSCRIBE/NOTIFY機構の通常の使用は、本質的に非同期のイベント、即ち、不定期な間隔で発生しうるイベントに対して適用される。言い換えれば、誰もそのようなイベントの発生頻度を予測できない。例えば、ユーザがプレゼンス・ステータスを頻繁に変更した場合、変更がなされるたびに、そのユーザのプレゼンス・ステータスを購読した他のピアに対して通知が生成される。このような場合に、複数回のプレゼンス更新通知によって生成されるトラフィックが、相当大きなサイズとなりうることは理解されよう。さらに、ＩＭＳにおける現在のプレゼンスアーキテクチャは、SUBSCRIBE/NOTIFY機構を、複数のユーザで共有するユーザリストの生成及びユーザリストの管理のような別の目的でも利用する。プレゼンス・リストは、Ｅメールの配信リストと同様、ユーザがリストサーバで運営されているユーザリストに１つの購読を発行することが可能であり、リストサーバはユーザリストの全てのメンバに最終的な購読(back-end subscription)を生成する。これは、個別に購読を行う場合と同様の利点を実現しながら、ユーザがリストのそれぞれのユーザに対して個別に購読を発行する労力を省く。さらには無線リソースに不安のあるセルラー環境におけるＳＩＰ信号伝達を節約できるという効果もある。したがって、ユーザはリストのいかなるメンバのプレゼンスに変更が生じようとも、当該プレゼンスの変更が通知されるように、他の複数のユーザを含むプレゼンス・リストを購読してもよい。
【０００９】
それ故に、ＩＭＳネットワークには予測不可能な方法でトラフィックを生成し得る多数のノードが存在する。トラフィックは、例えば音声通信やビデオ会議やＰＴＴのような他の時間依存アプリケーションと自身に固有のトラフィックチャネルを相互に共有する、複数のユーザ装置（ＵＥ:User Equipment。本明細書では代わりにユーザ端末と呼ぶ）に宛てられる。そのため、音声通信等の時間依存アプリケーションを行っている間の、プレゼンス通知のような、複数の通知メッセージをＵＥが受信することは、ライブ音声通信の品質の劣化、または瞬間的な通信の中断の原因となり得る。
【００１０】
予測していないトラフィックがＵＲに到達した際の、ライブ音声通信セッションの品質の劣化の問題に対処するために、試みられている多数の解決策が存在する。しかしながら全ての解決策は、レート制御及びプレゼンス・メッセージの長さの最小化により、トラフィックを減らすことを目的としている。プレゼンス・メッセージのサイズの制限するための、プレゼンス・ステータスの数の減少、及びトラフィックを圧縮してサイズを縮小するための圧縮アルゴリズムの使用の少なくともいずれかを含んだ技術が開発された。しかしながら上述の解決策はいずれも、プレゼンスに関連するトラフィックが、ＵＥの音声通信にマイナスの影響を与えない、実行可能な解決策を提供できない。
【００１１】
上述した問題点を解決するための従来技術の解決策は存在しないが、以下に提案するハチソンの特許文献１は、本発明の分野と一部関連している。この特許文献１には、タイムクリティカルな通信が起こりそうな時期を予測する機能が記載されている。このような予測に基づき、他の通信は、タイムクリティカルな通信を干渉しないであろう時期に送信される。インスタントメッセージ（ＩＭ）を含む、異なる複数のクラスでのスケジューリング送信を伴う方法は、SIP INVITEメッセージ、及び登録通信または応答を含む第１クラスでの通信が発生しそうな時間枠を決定する。第２クラスの通信の伝送は、第１クラスの通信のために予測され、決定された時間枠の間は起こらないようにスケジューリングされる。しかしながら、特許文献１はいつ通信が発生するかを予想において、予測する方法に限定されており、本発明の概念の教示や示唆まではしていない。
【００１２】
図１（従来技術）を参照する。図１は、プレゼンス・イベント情報を送信するために２ユーザ間でＳＩＰのSUBSCRIBE/NOTIFY機構を用いる例示的な従来技術シナリオの単純化されたハイレベルノード操作及び信号のフロー図である。図１に示される、単純化されたＩＭＳネットワーク１００は、第１のユーザ端末（ＵＥ）Ａ１０２、及び第２のユーザ端末（ＵＥ）Ｂ１０４を備える。図１で説明される動作は、任意のユーザに関連するプレゼンス・イベント情報の購読によって、要求者がそのようなプレゼンス・ステータスの変更が発生した際に通知され得る方法を示している。動作１０６において、要求者ユーザ端末Ａ１０２はユーザ端末Ｂに関するプレゼンス・イベント情報の購読を行うために、SIP SUBSCRIBEメッセージをユーザ端末Ｂ１０４に送信する。（なお、SIP ACKや200 OKメッセージのような、ＳＩＰの承認及び確認メッセージは簡単のため省略される。）動作１０７においてユーザ端末Ｂは、メッセージを受信すると、SIP NOTIFYメッセージを通じて、ユーザ端末Ｂ１０４に関する、（ユーザＢのプレゼンス情報＝「ビジー」）を現在有するプレゼンス・イベント情報１０９をユーザＡ１０２に通知する。さらなる動作１１０において、ユーザ端末Ｂのプレゼンス・イベント情報の変更は起こりうる（例えばイベント＝ユーザＢのステータス「ビジー」から「アイドル」に変更）。そして結果として、ユーザ端末Ｂ１０４は、ユーザＡ１０２に変更を通知するために、新しいプレゼンス情報１１４（例えばユーザＢの新しいプレゼンス情報＝「アイドル」）を有するユーザ端末Ａ１０２宛の第２のSIP NOTIFYメッセージを、動作１１２において発行する。
【００１３】
図２（従来技術）を参照する。図２は、同じユーザ端末Ａ１０２及びプレゼンス・サーバ２０４を備えるＩＭＳネットワーク１００’を示している。ここでは、ユーザはプレゼンス・ステータス情報を発行するためにプレゼンス・サーバ２０４を用いることと、プレゼンス・サーバ２０４がユーザ端末Ａ１０２と同じようなネットワーク１００’のユーザに対してプレゼンスに関連するサービスを提供することとを前提とする。図２は、ユーザ端末Ａ１０２が、ユーザ端末Ｂ１０４のような、他のプレゼンスエンティティに関連するプレゼンス情報を受け取るために、どのようにしてプレゼンス・サーバ２０４に購読を行えばよいかを示している。最初の動作２０６において、ユーザ端末Ａ１０２は、プレゼンス・サーバ２０４からプレゼンス・イベント情報を受け取るために、イベント及び状態２０８の少なくともいずれかを有する、SIP SUBSCRIBEメッセージを、プレゼンス・サーバ２０４に送信することによって購読を行う。（なお、図２でもいくつかのＳＩＰの承認及び確認メッセージは、簡単のため省略されることに留意されたい。）図２に示される特定例において、イベント２０８はユーザＡ１０２がユーザ端末Ｂ（図２には示さず）のプレゼンスの変更があったときに、通知の受信を所望していることを特定する。SUBSCRIBEメッセージ２０６に応答してサーバ２０４は、プレゼンス・サーバ２０４が現在ユーザ端末Ｂに関して有している、最初のプレゼンス情報２１１（例えばユーザＢのプレゼンス情報＝「忙しい」）を有するSIP NOTIFYメッセージ２０９を応答する。その後プレゼンス・サーバ２０４は、ユーザ端末Ｂのプレゼンス・ステータスの変更を含む、プレゼンス情報更新を有するSIP PUBLISHメッセージ２１２を受信する。これにより、動作２１３においてプレゼンス・サーバ２０４は、ユーザＢについてのプレゼンス情報の変化が、そのような情報を用いてユーザ端末Ａ１０２を更新するように指定されているイベント２０８に合致していることに気づく。結果として動作２１４においてプレゼンス・サーバ２０４は、ユーザ端末Ｂの更新されたプレゼンス情報２１６を有する新しいSIP NOTIFYメッセージ（例えばユーザＢのプレゼンス情報＝「アイドル」）を発行する。
【００１４】
図３（従来技術）を参照する。図３は、ユーザ端末Ａ３０２及びユーザ端末Ｃ３０４を備える単純化されたＩＭＳネットワーク３００のハイレベルノード動作及び信号のフロー図である。図３には、従来技術の、プレゼンス・イベント情報の送信方法の欠点が図示されている。動作３０６においてユーザ端末Ａ３０２は、ライブ音声セッションにユーザ端末Ｃ３０４を招待するためにユーザ端末Ｃ３０４へのSIP INVITEメッセージを発行する。（なお、いくつかのＳＩＰ承認及び確認メッセージは簡単のため省略されてもよいことに留意されたい。）動作３０８において、ユーザＣ３０４は応答として、ライブ音声セッションへの参加を受け入れることを確認する、SIP 200 OKメッセージを返す。そして動作３１０において、２つのユーザ端末間でライブ音声セッションが確立され、ライブ音声セッションはその後、ライブ音声通信のやり取りをするために、ライブセッションを使用することが可能である。しかしながら、先に述べたように、ライブ通信中に一方のユーザによってプレゼンス情報の通知が受信された場合に問題が発生するかもしれない。これは、本例示的なシナリオにおける場合に想定される、ライブセッション及びプレゼンス・トラフィックが同じトラフィックチャネルを使用した状況において、さらに悪化する。例えば、ユーザ端末Ａ３０２が動作３１４、３１６及び３１８において、ユーザＡ３０２が購読した（前の個々の購読は図３には図示せず）、プレゼンスエンティティに関連するプレゼンス情報を有する個々のSIP NOTIFYメッセージを受信する。このような通知の受信の結果として、ユーザ端末Ａ３０２はライブセッション３１０とともに瞬断３２０ｉを経験し得る。このような瞬断は、ライブセッション３１０上で受信及び送信される音声信号における重大な悪化を引き起こし得る。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】国際公開第２００５／０３４４７７号パンフレット
【発明の概要】
【００１６】
よって、既存の解決策の欠陥及び欠点を打開するため、上述した欠陥を効率的に解決する解決策を有することが好都合であろうことは容易に理解される。本発明は、このような方法及びシステムを提供する。
【００１７】
１つの局面では、本発明は、ユーザ端末またはサーバが特定のタイプの通知メッセージの受信を購読する際に開始される通信方法である。音声通信のような時間依存アプリケーションにおいてユーザ端末またはサーバが後に関与する際、ユーザ端末またはサーバは、時間依存アプリケーションへの関与に応じて、特定のタイプの通知メッセージの受信の購読の一時停止を要求する。このような要求は、例えばSIP SUBSCRIBEやSIP NOTIFYやSIP PUBLISHメッセージを用いて実現される。
【００１８】
別の局面では、本発明は、特定のタイプの通知メッセージの受信を購読し、時間依存アプリケーションを開始する通信モジュールと、時間依存アプリケーションにおける関与に応じて、特定のタイプの通知メッセージの受信の購読を一時停止するための要求の発行を支持するサービス論理モジュールを備える通信ノードである。
【００１９】
発明のさらなる詳細な理解、そのさらなる目的及び利点のために、以下の記述を添付の図面と併用して、これから参照する。
【図面の簡単な説明】
【００２０】
【図１】プレゼンス・サービスの従来技術による実装を例示する、ノード操作及び信号のフロー図。
【図２】プレゼンス・サービスの従来技術による実装を例示する、別のノード操作及び信号のフロー図。
【図３】プレゼンス・サービスの従来技術による実装を例示する、さらに別のノード操作及び信号のフロー図。
【図４】本発明の好ましい実施形態の、第１の可能な変形物を例示するハイレベルノード操作及び信号のフロー図。
【図５】本発明の好ましい実施形態の、第２の可能な変形物を例示する別のハイレベルノード操作及び信号のフロー図。
【図６】本発明の好ましい実施形態の、第３の可能な変形物を例示するさらに別のハイレベルノード操作及び信号のフロー図。
【図７】本発明の好ましい実施形態の、電気通信ノードでの例示的な実現の実例となるハイレベルブロック図。
【発明を実施するための形態】
【００２１】
本発明の革新的な内容は、様々な例示的な実施形態への詳細な言及を用いて述べられるだろう。しかしながら、この分類の実施形態が、発明の革新的な内容の、多くの有利な使用のうちの、いくつかの例だけを提供することは理解されるべきである。一般に、本願の明細書の記載は、特許請求の範囲に記載された本発明の様々な態様のいずれかを必ずしも限定しない。さらに、一部の記載は、いくつかの独創的な機能に当てはまるが、他の機能には当てはまらなくてもよい。図において、同様または類似の要素は、いくつかの図を通じて、同一の参照番号で指定される。
【００２２】
本発明、及び本発明に関連する好ましい実施形態によれば、プレゼンス通知のような、例えばユーザ端末の時間依存アプリケーション（例えば音声またはビデオ通信）に干渉するかもしれないデータトラフィックをユーザ端末がこのような時間依存アプリケーションに関与している間一時停止することを可能にする方法、システム及び電気通信ノードが提供される。発明によれば時間既存アプリケーションサービスの品質を保つため、購読者が時間依存アプリケーションに関与すると、１つまたは複数のノード（ユーザ端末またはアプリケーションサーバ）にメッセージの送信を一時停止するように要求するために、SIP SUBSCRIBE/NOTIFYメッセージ方式またはSIP PUBLISHメッセージのような、様々な構造が用いられてよい。
【００２３】
図４を参照する。図４は、発明の好ましい実施形態を実行する単純化された例示的なネットワーク４００の、例示的なノード操作及び信号のフロー図を示している。ネットワーク４００は、ユーザ端末Ａ４０２、ユーザ端末Ｂまたはサーバ（ここではノード４０４として示される）の他に、他のユーザ端末またはアプリケーションサーバＣ（ここではノード４０６として示される）を備える。ユーザ端末及びサービス４０２、４０４及び４０６は、例えばＳＩＰ信号伝達を用いることにより、ネットワーク４００における通信を継続可能である。始めに、動作４０８において、ユーザ端末Ａ４０２は、ユーザ端末Ａ４０２がノード４０６から受信を所望しているプレゼンス・イベント情報のタイプを特定する、プレゼンス・イベントまたは状態４１０を含むSIP SUBSCRIBEメッセージを発行することにより、ノード４０６からプレゼンス・イベント情報を受信するために購読してよい。例えば、プレゼンス・イベントまたは状態４１０は、例えば第１のステータスから第２のステータスになった等、プレゼンス・イベント情報が更新される度に、ユーザ端末Ａ４０２がプレゼンス・サーバ４０６から受信を所望している、ユーザＸ（不図示）に関連するプレゼンス・イベント情報を特定してもよい。動作４１２において、ノード４０６はメッセージ４０８を受信し、ユーザ端末Ａ４０２の購読を登録することにより、プレゼンス・イベントまたは状態４１０を格納する。ここで説明されている本発明の好ましい実施形態を実施する目的のために、ユーザ端末Ａ４０２が、ノードＢ４０４とライブ通信セッションに関与することを要求し、ライブ通信セッション４１６の要求を含むSIP INVITEメッセージ４１４を発行するものとする。動作４１８において、ユーザ端末Ｂ４０４はユーザ端末Ａ４０２へのSIP 200 OKメッセージを返送することにより、ユーザ端末Ａ４０２に要求されたライブ通信セッションへの参加承諾の通知を返す。最終的に、通話相手４０２及び４０４の両方は、両者間のライブ通信セッション４２０を確立する。本発明の好ましい実施形態によれば、動作４２２においてユーザ端末Ａ４０２は、このライブ通信セッションを独占的にサポートするために指定された、別個のトラフィックチャネルを有するかどうかを調べる。もしそうなら、すなわち、ライブ通信セッション４２０が別個のトラフィックチャネルを独占的に使用する場合には、さらなる動作４２４においてユーザ端末Ａ４０２は別個のトラフィックチャネルがアイドル状態か否か、即ち使用可能であるか否かを検出する。トラフィックチャネルが存在し、使用可能である場合、ライブ通信セッションの品質は、ノード４０６からプレゼンスに関連する通知メッセージ（または例えばインスタントメッセージ等のその他の通知メッセージ）を受け取ることにより悪影響を引き起こさないとの結論を出す。そして、ライブ通信セッションの品質を保護する、さらなる動作が必要ないとして、ステップ４２６で方法は終了する。一方、動作４２４において、ライブ通信セッションが独占的に使用するために指定されたトラフィックチャネルがダウンしている、またはアクセスできないと、判別された場合、または動作４２２においてユーザ端末Ａ４０２がライブ通信セッション４２０と例えばプレゼンス通知メッセージの受信の両方を実行するために、同じトラフィックチャネルを使用していると判別された場合、動作４２８でユーザ端末Ａ４０２は、ライブ通信セッション４２０の瞬断を回避するために、ノード４０６からのプレゼンス・メッセージの受信を一時停止するように動作する。ユーザ端末Ａ４０２は、先の動作４１２で登録された購読を終了するために、指示４３２を含む、ノード４０６に送信されるSIP NOTIFYメッセージ４３０を使用することができる。動作４３４において、ノードＣ４０６はユーザ端末Ａ４０２の購読を終了し、SIP 200 OKメッセージ４３６を用いて終了を確認する。動作４２８の結果として、ユーザ端末Ａ４０２は、ライブ通信セッション４２０の間、もはやノードＣ４０６からの通知メッセージを受信しない。その後、動作４３８において、ユーザ端末Ａ４０２はライブ通信セッションを終了できるように、ノードＢ４０４に対しSIP BYEメッセージを発行することによって、ライブ通信セッションを終了する。ライブセッションの終了のあと、ノードＣ４０６のプレゼンス・イベント情報のための購読を再度確立するために、ユーザＡ４０２は新しいSIP SUBSCRIBEメッセージ４４０を発行する。具体的には、メッセージ４４０にプレゼンス・イベントまたは状態４１０を含めることによって、ノードＣ４０６のプレゼンス・イベント情報のための購読を再度確立する。動作４４２において、ノード４０６はイベントまたは状況４１０を格納し、再びユーザ端末Ａ４０２のプレゼンス通知メッセージのための購読を登録する。動作４４４において、ノードＣ４０６は、（例えば、不図示のユーザＸに関連するプレゼンス・イベント情報の更新の結果として）特定されたイベントまたは状態４１０の発生を検出する。この検出により、プレゼンス通知４６６が、プレゼンス・イベント情報４４７を搬送するSIP NOTIFYメッセージの形式で、要求されたプレゼンス情報（ユーザＸのプレゼンス・イベント情報の更新）とともにユーザ端末Ａ４０２に返送されることになる。
【００２４】
図５を参照する。図５は、同一のノード４０２、４０４及び４０６を備える、上述したものと同一の例示的なネットワーク４００における別のハイレベルノード動作及び信号のフロー図を示している。図５には、前述したものと同様の動作４０８及び４１２が示され、この動作により、ユーザ端末Ａ４０２は、イベントまたは状態４１０の発生に応じたユーザＸ（不図示）に関連するプレゼンス・イベント情報をノード４０６から受信するための購読を行う。図５は、プレゼンス通知の送信の一時停止を可能にするために、ユーザ端末Ａ４０２がライブ通信セッションに関与する際にノード４０６に通知する別の方法を含む、発明の好ましい実施形態の別の変形例を示している。このような変形例は動作４１５で開始する。動作４１５において、ユーザ端末Ａ４０２がライブ通信セッションのような時間依存アプリケーションに関与する際にノード４０６に通知するように、ノード４０６がユーザＡ４０２に要求するためにも、ＳＩＰのSUBSCRIBE/NOTIFY機構が使用される。ノード４０６は、ユーザ端末Ａ４０２によってライブ通信セッションが確立された際に、また必要に応じて、そのようなライブセッションが別個のトラフィックチャネルを使用するように指定もしくは割り当てされていない際に、通知をノード４０６に戻させるようなイベント４１３の定義を含んだSUBSCRIBEメッセージ４１５をユーザ端末Ａ４０２に送信する。動作４１８において、ユーザ端末４０２はイベント４１３を格納する。その後、ユーザ端末Ａ４０２は、ライブ通信セッションの確立要求４１６を含むSIP INVITEメッセージ４１４を、ユーザ端末Ｂ４０４に発行することにより、ライブ通信セッション４２０を確立する。ノード４０４からSIP 200 OKメッセージ４１８によって承諾が確認されると、ライブ通信セッション４２０は確立される。
【００２５】
動作５２２において、イベント４１３を格納しているユーザ端末Ａ４０２は、ライブセッション４２０の確立をノード４０６に通知すべきであることを検出する。検出５２２は図４のステップ４２２及び４２４ですでに述べたものと同一のステップを含んでよい。それ故に動作５２２において、ユーザ端末Ａ４０２はライブ通信セッションが、別個のトラフィックチャネルの使用を割り当てることなく確立されたと判定する。そして動作５２４において、ユーザ端末Ａ４０２はプレゼンス・イベント情報の送信の一時停止を要求するために、ノード４０６へのSIP NOTIFYメッセージを発行する。このため、NOTIFYメッセージ５２４は、一時停止要求５２５と、必要に応じて、別個のトラフィックチャネルが割り当てられていないライブセッションの確立に関する情報５２７とを含む。メッセージ５２４はノード４０６によって受信され、動作５２６においてノード４０６は、ライブ通信セッションがユーザ端末Ａ４０２によって受信されるいかなるメッセージの干渉によっても中断されないように、ユーザ端末Ａ４０２へのプレゼンスに関連する情報の送信を一時停止する。その後、ユーザ端末Ａ４０２は動作５２８においてライブ通信セッションの終了を決定し、このためノード４０４にSIP BYEメッセージ５３０を発行し、さらに動作５３４においてノード４０６に、これ以上ライブセッションが存在しないことを通知する。通知５３４の結果として、ノード４０６は動作５３８において、はじめに動作４１２で生成された購読を再度有効化する。そのうちユーザＸに関連するプレゼンス・イベント情報を受信すると、ノード４０６は動作５４０において、ユーザ端末Ａ４０２にプレゼンス情報５４２を通知する。
【００２６】
図６を参照する。図６はユーザ端末がライブ通信セッションのような時間依存アプリケーションに関与する際、セッション中のプレゼンス・メッセージの受信が一時停止されるよう、ノードに通知するための発明の好ましい実施形態のさらに別の変形例の、さらに別のノード動作及び信号のフロー図を示している。図６には、ノード４０２、４０４及び４０６を備える同一のネットワーク４００が示されており、ユーザ端末Ａ４０２は動作４０８において、ノード４０６のプレゼンス・イベント情報を受信するために再び購読を行う。そしてノード４０６は動作４１２においてイベントまたは状態の定義４１０を格納し、プレゼンス・イベント情報の発生がユーザ端末Ａ４０２に転送される。動作４１４及び４１８において、ユーザ端末Ａ４０１はノードＢ４０４と、再びライブ通信セッション４２０を確立する。動作６２０において、ユーザ端末Ａ４０２はライブ通信セッション４２０の瞬断を避けるため、プレゼンス・メッセージの転送の一時停止を要求するためにノード４０６に通知する必要性を検出する。検出６２０は、図４の４２２及び４２４で既に述べたものと同一のステップを含んでよい。発明の好ましい実施形態の本変形例によれば、動作６２２において、ユーザ端末Ａ４０２は、一時停止要求６２１と、必要に応じて、別個のトラフィックチャネル６２４の割当なしにライブ通信セッションを確立したことを知らせる情報６２４とを含む、プレゼンス・イベント情報の送信の一時停止を要求するSIP PUBLISHメッセージ６２２を発行する。SIP PUBLISHメッセージ６２２はノード４０６で受信され、動作６２６においてノード４０６はユーザ端末Ａ４０６に、プレゼンスに関連する情報の送信を一時停止する。その後、動作６２８において、ユーザ端末Ａ４０２はSIP BYEメッセージ６３０を発行することによりライブ通信セッションを閉じ、動作６３２において、必要であればプレゼンス・メッセージ転送が再開できるように、ノード４０６へのセッション終了通知の必要性を検出する。このため、動作６３４において、ユーザ端末Ａ４０２は、ライブセッションが存在しないことを表す情報６３６を含むノード４０６への新しいSIP PUBLISHメッセージを発行する。そしてPUBLISHメッセージ６３４を受信すると、ノード４０６はユーザ端末Ａ４０２へのプレゼンス・メッセージ送信を再度有効化する。そのうち、ユーザ端末Ａ４０２が所望しているプレゼンス・イベント情報に関する何らかの情報がノード４０６によって受信されると、動作６３８においてノード４０６は、ユーザ端末Ａ４０２が所望しているプレゼンス情報６４０（ユーザＸに関する何らかの更新されたプレゼンス情報）を含む、新しいSIP NOTIFYメッセージを発行する。
【００２７】
図７を参照する。図７は本発明の好ましい実施形態に係る電気通信ノード７００の例示的なハイレベル機能ブロック図を示している。ノード７００は、上述したサーバまたはユーザ端末であってよく、サービス論理モジュール７０４及びＳＩＰスタックモジュールの型を有してもよい通信モジュール７０６に接続された、セッションマネージャモジュール７０２を実装する。Ｉ／Ｏインタフェース７０８は他のノードとの通信に用いられ、外部ノードからのＳＩＰメッセージの受信に関与し、外部ノードにＳＩＰメッセージを転送するために用いられる。通信モジュール７０６は、ノード７００によって発行及び受信されたそれぞれの生成及び解釈に関与する。セッションマネージャ７０２は、分離または共有された、ノード７００により処理される通信セッションに関連するトラフィックチャネルの確立を検出及び管理するために用いられる。サービス論理７０４は、時間依存アプリケーションがノード７０６で開始されたことを検出し、通信モジュール７０６に他のノードからの通知メッセージの受信を一時停止するためのメッセージを発行させるように指示することを含む本発明を実行するために用いられる。例えば、図４、５，６及び７をまとめて参照すると、ＳＩＰスタックはＳＩＰセッション４２０を確立するための、メッセージ４１４及び４１８の交換を受け持つ。動作４２２及び４２４はサービス論理７０４によって達成され、ライブ通信セッションに別個のトラフィックチャネルが割り当てられたか否か、及びセッションマネージャ７０２から得られた情報によって、チャネルが使用されていないか否かを検出する。動作４２２または４２４のいずれか一つの回答が否であれば、継続しているライブ通信が存在する場合、プレゼンスに関連するメッセージの受信を一時停止するための要求をノード４０６に通知するために、例えばSIP SUBSCRIBEメッセージ４３０のような適切なＳＩＰメッセージを発行するよう、サービス論理７０４はＳＩＰスタックに指示する。同様に、図５及び７をまとめて参照し、通信モジュール７０６によって処理された、メッセージ４１６及び４１８の交換によって、ライブ通信セッション４２０が確立した時点で、動作５２２においてサービス論理７０４は、プレゼンスに関連するメッセージが一時停止されるべきであるかを、ノード４０６に通知する必要性を検出する。動作５２８において通信モジュール７０６がライブ通信セッションを閉じた時点で、サービス論理７０４はセッションが閉鎖されたことを通知され、動作５３２においてアプリケーションサーバ４０６に返送するSIP NOTIFYメッセージの発行の必要性を検出する。なお、これらの動作は通信モジュール７０６によって達成される。最後に、図６及び７の両方を参照し、検出６２０及び６３２は、サービス論理７０４によって達成され、ＳＩＰメッセージ６１４及び６３４は、通信モジュール７０６によって、他のノード４０６に対し発行させる。
【００２８】
それ故に、本発明により、例えばユーザ端末またはサーバのような電気通信ノードに、ライブ通信セッション（例えば音声やビデオ会議通信）のような時間依存アプリケーションに関与すること、及びライブ通信セッションに干渉するかもしれないメッセージ（例えばプレゼンスに関連するメッセージ）の受信を一時停止することを可能とする。本発明の例示的な実施形態は、プレゼンスに関連するメッセージに言及して主に説明したが、本発明の応用は単にプレゼンスに関連するメッセージの一時停止に限定されず、むしろライブ通信セッションのような時間依存アプリケーションの間に受信されることになっている、他のタイプのメッセージの一時停止に有利に用いられることが可能であることは、本技術分野に属する当業者によって理解される。例えば、ユーザ端末は、例えばＳＭＳ（Short Message Service）やＭＭＳ（Multimedia Messaging Service）やＩＭＳ（IP Multimedia Subsystem）メッセージとして送信される気象通知のような、他のタイプの通知を購読してもよく、発明は図４、５及び６に述べられた通り、時間依存アプリケーションに関与する際に、ＳＭＳサーバやＭＭＳサーバやＩＭＳサーバにユーザが通知することを可能としてもよい。本発明は、ライブ通信が確立された際に、メッセージの送信を一時停止することを他のユーザまたはアプリケーションサーバに通知するための、例えばSIP PUBLISHメッセージまたはSIP SUBSCRIBE/NOTIFY機構等の、ＳＩＰメッセージを用いた、単純で効果的な方式を提供する。しかしながら、他の通信プロトコルもまた、これらの通知を実行するために用いられてもよいことは理解できる。発明のさらなる実施形態においては、ライブ通信セッションが分離されたトラフィックチャネルに割り当てられていない場合、あるいはトラフィックチャネルが使用されていない（例えば故障やその他利用できない）場合にのみ、対応するノードに通知を送信するよう、さらなる計算を行うことも可能である。
【００２９】
上述の説明に基づき、本発明が例えば音声通信またはビデオ会議のような時間依存アプリケーションの品質を維持する、単純でさらに効率的な方法を提案する、有利な解決策を提供することは、本技術分野に属する当業者によって理解されるべきである。本発明のシステム及び方法は、特定のタイプのメッセージ及びノードの特定な言及が述べられたものであるが、本文書に含まれる革新的な教示が、必ずしも上述の言及に限定されるものでなく、通話相手が購読する、いかなるタイプのメッセージ、及びいかなるタイプの信号伝達プロトコルで有利に実装されてもよいことは、本文書の参照によって実現されるべきである。本発明の実施及び構成は、上述の記載から明らかであると確信する。参照及び述べられた方法及びシステムは、好ましいものとして特徴付けられているが、以下に説明する請求項によって定義される発明の範囲から逸脱しない範囲で、様々な変更及び修正がなされてもよいことは容易に理解できよう。
【００３０】
本発明の方法及びシステムの、いくつかの好ましい実施形態が、添付の図面に図示、及び上述の詳細な説明に記載されているが、発明が開示された実施形態に限定されるものなく、以下の請求項によって説明、及び定義される発明の範囲から逸脱せずに、多数の再配列、修正、及び置き換えが可能であることは理解されよう。
【特許請求の範囲】
【請求項１】
通信方法であって、
特定のタイプの通知メッセージの受信を購読するステップａと、
時間依存アプリケーションに関与するステップｂと、
前記時間依存アプリケーションへの関与に応じて、前記特定のタイプの通知メッセージの受信の購読の一時停止を要求するステップｃと、を備えることを特徴とする通信方法。
【請求項２】
前記時間依存アプリケーションを実行するステップｄと、
前記時間依存アプリケーションを終了するステップｅと、
前記時間依存アプリケーションの終了に応じて、前記購読の再有効化を要求するステップｆと、をさらに備えることを特徴とする請求項１に記載の通信方法。
【請求項３】
前記ステップｃは、前記購読の一時停止を要求するSIP（Session Initiation Protocol） SUBSCRIBEメッセージの送信を含むことを特徴とする請求項１に記載の通信方法。
【請求項４】
前記ステップｃは、前記購読の一時停止を要求するSIP（Session Initiation Protocol） NOTIFYメッセージの送信を含むことを特徴とする請求項１に記載の通信方法。
【請求項５】
前記ステップｃは、前記購読の一時停止を要求するSIP（Session Initiation Protocol） PUBLISHメッセージの送信を含むことを特徴とする請求項１に記載の通信方法。
【請求項６】
前記特定のタイプの通知メッセージはプレゼンスに関連するメッセージを含み、
前記時間依存アプリケーションは、ライブ音声通信を含むことを特徴とする請求項１に記載の通信方法。
【請求項７】
前記ステップｃは、
時間依存通信が別個のトラフィックチャネルに割り当てられているか否かを判別し、前記時間依存通信が別個のトラフィックチャネルに割り当てられていない場合、前記特定のタイプの通知メッセージの受信の購読の一時停止を要求するステップｃ１をさらに備えることを特徴とする請求項１に記載の通信方法。
【請求項８】
前記ステップｃは、
ステップｃ１の後、前記別個のトラフィックチャネルが動作中であるか否かを判別し、前記別個のトラフィックチャネルが動作中でない場合、前記特定のタイプの通知メッセージの受信の購読の一時停止を要求するステップｃ２をさらに備えることを特徴とする請求項７に記載の通信方法。
【請求項９】
前記ステップａは、前記特定のタイプの通知メッセージを定義するイベントを有するSIP（Session Initiation Protocol） SUBSCRIBEメッセージの送信を含むことを特徴とする請求項１に記載の通信方法。
【請求項１０】
通信ノードであって、
特定のタイプの通知メッセージの受信を購読し、時間依存アプリケーションを開始する通信モジュールと、
前記時間依存アプリケーションへの関与に応じて、前記特定のタイプの通知メッセージの受信の購読の一時停止するための要求の発行を指示するサービス論理モジュールと、を備えることを特徴とする通信ノード。
【請求項１１】
前記通信モジュールは、前記時間依存アプリケーションを終了し、前記時間依存アプリケーションの終了に応じて、前記購読の再有効化を要求することを特徴とする請求項１０に記載の通信ノード。
【請求項１２】
前記通信モジュールは、前記購読の一時停止を要求するSIP（Session Initiation Protocol） SUBSCRIBEメッセージを送信するSIP（Session Initiation Protocol）スタックモジュールを備えることを特徴とする請求項１０に記載の通信ノード。
【請求項１３】
前記通信モジュールは、前記購読の一時停止を要求するSIP（Session Initiation Protocol） NOTIFYメッセージを送信することを特徴とする請求項１０に記載の通信ノード。
【請求項１４】
前記通信モジュールは、前記購読の一時停止を要求するSIP（Session Initiation Protocol） PUBLISHメッセージを送信することを特徴とする請求項１０に記載の通信ノード。
【請求項１５】
前記特定のタイプの通知メッセージはプレゼンスに関連するメッセージを含み、
前記時間依存アプリケーションは、ライブ音声通信を含むことを特徴とする請求項１０に記載の通信ノード。
【請求項１６】
時間依存通信が別個のトラフィックチャネルに割り当てられていないことを判別し、前記サービス論理モジュールに前記特定のタイプの通知メッセージの受信の購読の一時停止を要求させるセッションマネージャモジュールをさらに備えることを特徴とする請求項１０に記載の通信ノード。
【請求項１７】
前記セッションマネージャモジュールはさらに、前記別個のトラフィックチャネルが動作中であることを判別し、前記サービス論理モジュールに前記特定のタイプの通知メッセージの受信の購読の一時停止を要求させることを特徴とする請求項１６に記載の通信ノード。
【請求項１８】
前記通信モジュールは、前記特定のタイプの通知メッセージを定義するイベントを含むSIP（Session Initiation Protocol） SUBSCRIBEメッセージを送信することを特徴とする請求項１０に記載の通信ノード。
【請求項１】
通信方法であって、
特定のタイプの通知メッセージの受信を購読するステップａと、
時間依存アプリケーションに関与するステップｂと、
前記時間依存アプリケーションへの関与に応じて、前記特定のタイプの通知メッセージの受信の購読の一時停止を要求するステップｃと、を備えることを特徴とする通信方法。
【請求項２】
前記時間依存アプリケーションを実行するステップｄと、
前記時間依存アプリケーションを終了するステップｅと、
前記時間依存アプリケーションの終了に応じて、前記購読の再有効化を要求するステップｆと、をさらに備えることを特徴とする請求項１に記載の通信方法。
【請求項３】
前記ステップｃは、前記購読の一時停止を要求するSIP（Session Initiation Protocol） SUBSCRIBEメッセージの送信を含むことを特徴とする請求項１に記載の通信方法。
【請求項４】
前記ステップｃは、前記購読の一時停止を要求するSIP（Session Initiation Protocol） NOTIFYメッセージの送信を含むことを特徴とする請求項１に記載の通信方法。
【請求項５】
前記ステップｃは、前記購読の一時停止を要求するSIP（Session Initiation Protocol） PUBLISHメッセージの送信を含むことを特徴とする請求項１に記載の通信方法。
【請求項６】
前記特定のタイプの通知メッセージはプレゼンスに関連するメッセージを含み、
前記時間依存アプリケーションは、ライブ音声通信を含むことを特徴とする請求項１に記載の通信方法。
【請求項７】
前記ステップｃは、
時間依存通信が別個のトラフィックチャネルに割り当てられているか否かを判別し、前記時間依存通信が別個のトラフィックチャネルに割り当てられていない場合、前記特定のタイプの通知メッセージの受信の購読の一時停止を要求するステップｃ１をさらに備えることを特徴とする請求項１に記載の通信方法。
【請求項８】
前記ステップｃは、
ステップｃ１の後、前記別個のトラフィックチャネルが動作中であるか否かを判別し、前記別個のトラフィックチャネルが動作中でない場合、前記特定のタイプの通知メッセージの受信の購読の一時停止を要求するステップｃ２をさらに備えることを特徴とする請求項７に記載の通信方法。
【請求項９】
前記ステップａは、前記特定のタイプの通知メッセージを定義するイベントを有するSIP（Session Initiation Protocol） SUBSCRIBEメッセージの送信を含むことを特徴とする請求項１に記載の通信方法。
【請求項１０】
通信ノードであって、
特定のタイプの通知メッセージの受信を購読し、時間依存アプリケーションを開始する通信モジュールと、
前記時間依存アプリケーションへの関与に応じて、前記特定のタイプの通知メッセージの受信の購読の一時停止するための要求の発行を指示するサービス論理モジュールと、を備えることを特徴とする通信ノード。
【請求項１１】
前記通信モジュールは、前記時間依存アプリケーションを終了し、前記時間依存アプリケーションの終了に応じて、前記購読の再有効化を要求することを特徴とする請求項１０に記載の通信ノード。
【請求項１２】
前記通信モジュールは、前記購読の一時停止を要求するSIP（Session Initiation Protocol） SUBSCRIBEメッセージを送信するSIP（Session Initiation Protocol）スタックモジュールを備えることを特徴とする請求項１０に記載の通信ノード。
【請求項１３】
前記通信モジュールは、前記購読の一時停止を要求するSIP（Session Initiation Protocol） NOTIFYメッセージを送信することを特徴とする請求項１０に記載の通信ノード。
【請求項１４】
前記通信モジュールは、前記購読の一時停止を要求するSIP（Session Initiation Protocol） PUBLISHメッセージを送信することを特徴とする請求項１０に記載の通信ノード。
【請求項１５】
前記特定のタイプの通知メッセージはプレゼンスに関連するメッセージを含み、
前記時間依存アプリケーションは、ライブ音声通信を含むことを特徴とする請求項１０に記載の通信ノード。
【請求項１６】
時間依存通信が別個のトラフィックチャネルに割り当てられていないことを判別し、前記サービス論理モジュールに前記特定のタイプの通知メッセージの受信の購読の一時停止を要求させるセッションマネージャモジュールをさらに備えることを特徴とする請求項１０に記載の通信ノード。
【請求項１７】
前記セッションマネージャモジュールはさらに、前記別個のトラフィックチャネルが動作中であることを判別し、前記サービス論理モジュールに前記特定のタイプの通知メッセージの受信の購読の一時停止を要求させることを特徴とする請求項１６に記載の通信ノード。
【請求項１８】
前記通信モジュールは、前記特定のタイプの通知メッセージを定義するイベントを含むSIP（Session Initiation Protocol） SUBSCRIBEメッセージを送信することを特徴とする請求項１０に記載の通信ノード。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公表番号】特表２０１０−５３７５３７（Ｐ２０１０−５３７５３７Ａ）
【公表日】平成２２年１２月２日（２０１０．１２．２）
【国際特許分類】
【出願番号】特願２０１０−５２１５０６（Ｐ２０１０−５２１５０６）
【出願日】平成２０年８月１５日（２００８．８．１５）
【国際出願番号】ＰＣＴ／ＩＢ２００８／０５３２９３
【国際公開番号】ＷＯ２００９／０２４９１０
【国際公開日】平成２１年２月２６日（２００９．２．２６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公表日】平成２２年１２月２日（２０１０．１２．２）
【国際特許分類】
【出願日】平成２０年８月１５日（２００８．８．１５）
【国際出願番号】ＰＣＴ／ＩＢ２００８／０５３２９３
【国際公開番号】ＷＯ２００９／０２４９１０
【国際公開日】平成２１年２月２６日（２００９．２．２６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]