(57)【要約】  パケット交換式通信ネットワークにおける通知方法を提供する。移動体端末（４２）に対して通知を行うことを欲するアプリケーションサーバ（４０）は、この移動体端末へ向けられた通知メッセージを送信する。通知は、一般的には制御ロジック（４４）を介して、通知サーバ（４５）へ転送される。移動体端末の状態が第１の所定の状態（例えば、「利用不可能(non-available)」）に対応する場合、通知（４１）は、第２の所定の状態（例えば、「利用可能(available)」）への状態変化の指示を通知サーバが受信するまで、通知サーバに格納される。状態変化に応えて、通知は、一般的には制御ロジックを介して、通知サーバから移動体端末へ送信される。
2008546306.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションサーバ（１０；４０；５０；６０）と移動体端末（１２；４２；５２；６２）とを含むパケット交換式通信システム（１００；４００；５００；６００）における通知の方法であって、
前記移動体端末に対する通知メッセージ（４１；５１）を前記アプリケーションサーバから送信するステップと、
前記通知メッセージを前記通信システム内の通知サーバ（４５；５５；６５；７５）へ転送し、前記移動体端末が第１の所定の状態に関連する場合に前記通知サーバにおいて前記通知メッセージを格納するステップと、
前記移動体端末における前記第１の所定の状態から第２の所定の状態への状態変化を示す指示を前記通知サーバにおいて受信するステップと、
前記状態変化を示す前記指示に応えて、前記通知サーバから前記移動体端末へ前記通知メッセージを送信するステップと、
を備えることを特徴とする方法。
【請求項２】
前記移動体端末（１２；４２；５２；６２）の前記第１の所定の状態と前記第２の所定の状態とは、前記移動体端末のＩＰ接続状態に関連していることを特徴とする請求項１に記載の方法。
【請求項３】
前記状態変化は、前記通信システム（１００；４００；５００；６００）において前記移動体端末（１２；４２；５２；６２）を登録するステップに関連していることを特徴とする請求項２に記載の方法。
【請求項４】
前記通知メッセージ（４１；５１）を格納する前記ステップは、前記移動体端末（１２；４２；５２；６２）への前記通知メッセージの送信に関する失敗した試みに引き続いて行われることを特徴とする請求項１に記載の方法。
【請求項５】
前記通知メッセージ（４１；５１）を格納する前記ステップは、前記移動体端末（１２；４２；５２；６２）の現在の状態に関する知識に基づく格納の決定に引き続いて行われることを特徴とする請求項１に記載の方法。
【請求項６】
前記通知サーバ（４５；５５；６５；７５）において受信される前記状態変化を示す前記指示は、呼セッション制御機能（ＣＳＣＦ）（１４；４４；５４；６４）、ホーム加入者サーバ（ＨＨＳ）（１３；５３）、位置サーバ、及びプレゼンスサーバの中から選択された通信ユニットを送信元とすることを特徴とする請求項１に記載の方法。
【請求項７】
メッセージの種類又は送信者の識別情報に基づいて前記通知メッセージ（４１；５１）を格納するか否かを判定するステップを更に備えることを特徴とする請求項１に記載の方法。
【請求項８】
前記移動体端末（１２；４２；５２；６２）に対する複数の通知メッセージ（４１；５１）を統合するステップと、
前記状態変化に応えて、前記統合された通知メッセージを前記移動体端末へまとめて送信するステップと、
を更に備えることを特徴とする請求項１に記載の方法。
【請求項９】
前記通知メッセージ（４１；５１）は、セッション開始プロトコル（ＳＩＰ）に基づくものであることを特徴とする請求項１に記載の方法。
【請求項１０】
前記通知サーバ（４５；５５；６５；７５）は、前記通信システム（１００；４００；５００；６００）の着信側のドメインに配置されたＳＩＰアプリケーションサーバを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
前記パケット交換式通信システム（１００；４００；５００；６００）は、ＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワークを含むことを特徴とする請求項１に記載の方法。
【請求項１２】
アプリケーションサーバ（１０；４０；５０；６０）と移動体端末（１２；４２；５２；６２）とを含むパケット交換式通信システム（１００；４００；５００；６００）における通知手段を備える通知サーバ（４５；５５；６５；７５）であって、
前記アプリケーションサーバを送信元とし、前記移動体端末へ向けられた通知メッセージ（４１；５１）を受信する手段（７６）と、
前記移動体端末が第１の所定の状態に関連する場合に前記通知メッセージを格納する手段（７７，７８）と、
前記移動体端末における前記第１の所定の状態から第２の所定の状態への状態変化を示す指示を受信する手段（７９）と、
前記状態変化を示す前記指示に応えて、前記移動体端末へ前記通知メッセージを送信する手段（７６）と、
を備えることを特徴とする通知サーバ。
【請求項１３】
前記移動体端末（１２；４２；５２；６２）の前記第１の所定の状態と前記第２の所定の状態とは、前記移動体端末のＩＰ接続状態に関連していることを特徴とする請求項１２に記載の通知サーバ。
【請求項１４】
前記状態変化は、前記通信システム（１００；４００；５００；６００）における前記移動体端末（１２；４２；５２；６２）の登録に関連していることを特徴とする請求項１３に記載の通知サーバ。
【請求項１５】
前記通知メッセージ（４１；５１）を格納する手段（７７，７８）は、前記移動体端末（１２；４２；５２；６２）への前記通知メッセージの送信に関する失敗した試みに応えて前記通知メッセージを格納するように適合されることを特徴とする請求項１２に記載の通知サーバ。
【請求項１６】
前記移動体端末（１２；４２；５２；６２）の現在の状態に関する知識に基づいて前記通知メッセージ（４１；５１）を格納するか否かを決定する手段を更に備えることを特徴とする請求項１２に記載の通知サーバ。
【請求項１７】
呼セッション制御機能（ＣＳＣＦ）（１４；４４；５４；６４）、ホーム加入者サーバ（ＨＨＳ）（１３；５３）、位置サーバ、及びプレゼンスサーバの中から選択された通信ユニットから、前記状態変化を示す前記指示を受信するように構成されることを特徴とする請求項１２に記載の通知サーバ。
【請求項１８】
メッセージの種類又は送信者の識別情報に基づいて前記通知メッセージ（４１；５１）を格納するか否かを判定する手段を更に備えることを特徴とする請求項１２に記載の通知サーバ。
【請求項１９】
前記移動体端末（１２；４２；５２；６２）に対する複数の通知メッセージ（４１；５１）を統合する手段と、
前記状態変化に応えて、前記統合された通知メッセージを前記移動体端末へまとめて送信する手段と、
を更に備えることを特徴とする請求項１２に記載の通知サーバ。
【請求項２０】
セッション開始プロトコル（ＳＩＰ）に基づく通知メッセージ（４１；５１）を制御するように適合されることを特徴とする請求項１２に記載の通知サーバ。
【請求項２１】
前記通信システム（１００；４００；５００；６００）の着信側のドメインに配置されたＳＩＰアプリケーションサーバを含むことを特徴とする請求項１２に記載の通知サーバ。
【請求項２２】
請求項１２乃至２１のいずれか１項に記載の通知サーバ（４５；５５；６５；７５）を含む通知手段を備えることを特徴とするパケット交換式通信システム（１００；４００；５００；６００）。
【請求項２３】
ＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワークであることを特徴とする請求項２２に記載の通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット交換式通信システムに関し、特に、そのようなシステムにおける移動体端末についての通知に関する。
【背景技術】
【０００２】
今日のパケット交換式ネットワーク、特に移動体ＩＰネットワーク及びＩＰマルチメディアシステムにおいて、端末中のサービスを始動させる(trigger)ために個々の移動体端末中のアプリケーションに対してシステムが通知を行う必要のある状況が数多く存在する。通知が送信される典型的なケースには、新しいメッセージが受信された場合、及び誰かがその移動体端末との通信を開始したいと望む場合が含まれる。この種の通知は、エンドユーザに対して表示されてもよいが、通常は表示されない。
【０００３】
ＩＰ接続、及びピア・ツー・ピア接続を達成する一般的な方法は、ＩＰマルチメディア・サブシステム（ＩＭＳ）［１］などのオーバレイネットワークを導入することである。ＩＭＳは、アプリケーション及びプラットフォームに依存しないＩＰサービスを提供する。ＩＭＳは、セッション制御メカニズムとして、セッション開始プロトコル（ＳＩＰ）［２］を使用する。ＳＩＰはメディアに依存せず、コンテンツが音声、映像、データ、或いはウェブベースのものであるかどうかとは無関係に、接続がどのように制御されるかを規定する。ＳＩＰを用いれば、移動体デバイスを登録し、ピア・ツー・ピア接続を開始することができる。
【０００４】
移動体端末に対するＩＰ接続が存在する場合、通知は通常、簡単且つ問題の無い方法で送信され得る。しかしながら、例えばデバイスがカバーエリア外にある場合や電源がオフである場合など、受信者に到達できない場合がしばしばあるため、通知の発行は簡単なものとは程遠くなる。
【０００５】
伝統的な電気通信サービスは、ＳＭＳメッセージをプッシュ型で送信する(pushing out)ことによりこの問題を処理し、ＳＭＳＣは、受信者が利用可能な状態となる(available)まで通知を保持する。ＭＭＳは、この一例である。このような蓄積転送(store-and-forward)メカニズムは、ＩＭＳなどのＩＰマルチメディアシステムに関して使用するにはあまり適していない。このメカニズムは時代遅れで徒に複雑な技術に依拠しており、配信時間に関する不確実性やメッセージの形式及び内容に関する制約などの欠点を伴う。
【０００６】
国際特許出願［３］は、言及したＳＭＳ通知と同じ原理に基づいてＩＭＳシステムのために蓄積転送メカニズムを使用する。これでは比較的複雑であまり効率的でない通知ソリューションになる。
【０００７】
従って、パケット交換式通信のための改良された通知メカニズム、特にＩＰマルチメディアシステムにおける使用に適した通知メカニズムが必要とされている。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明の一般的な目的は、パケット交換式通信システムにおける通知のための改良された方法を提供することである。詳細な目的は、ＩＰマルチメディアシステムにおける改良された通知を実現することである。他の目的は、リソースの効率的な管理に関連する通知メカニズムを提供することである。更に他の目的は、実装が容易な通知メカニズムを提供することである。
【課題を解決するための手段】
【０００９】
これらの目的は、添付の請求の範囲に従って達成される。
【００１０】
簡単に言うと、本発明は、新しい種類の蓄積転送メカニズムを提案する。これによれば、通信における受信側の通知サーバが、通知によって宛先とされた移動体端末の状態（ステータス）に基づく通知を制御するために使用される。受信者が利用可能な状態でないと判断された場合、例えば、受信者が利用可能な状態になるまで通知は通知サーバに格納される。移動体端末が利用可能な状態になると、通知サーバはその旨の指示(indication)を受信し、通知メッセージを移動体端末へ配信しようと試みる。
【００１１】
移動体端末の状態は、例えば「利用可能(available)」「利用不可能(non-available)」などの、移動体端末のＩＰ接続状態に関連させることができる。状態が移動体端末の地理的な位置に関連している実施形態も可能である。
【００１２】
本発明は、ＩＭＳなどのＩＰマルチメディアシステムにおいて実装することができる。本発明によれば、システムは、オフラインのユーザに対してそのユーザが利用可能な状態になった時に配信されるサービスを有することが可能になる。これは著しい利点である。通知サーバは、例えば、ＳＩＰアプリケーションサーバ（ＳＩＰ  ＡＳ）として実装することができ、通知メッセージは、ＳＩＰベースのもの、例えばＳＩＰ  ＮＯＴＩＦＹ又はＳＩＰ  ＭＥＳＳＡＧＥを使用するものとすることができる。
【００１３】
本発明の他の態様によれば、通知方法、通知サーバ、及び通知手段を備えるパケット交換式通信システムが提供される。
【００１４】
添付の図面と共に以下の説明を参照することにより、本発明、及びその更なる目的及び利点を、最適に理解することができるであろう。
【発明を実施するための最良の形態】
【００１５】
略語のリストが本セクションの最後にある。
【００１６】
図１は、本発明を実装可能な、ＩＰマルチメディア通信のための典型的なネットワークの図式的概観図である。このネットワークはＩＭＳアーキテクチャに従って構築されるが、本発明はＩＭＳに限定されるものではなく、他のＩＰマルチメディアシステム或いは更に他のパケット交換式システムに関連して極めて好適に使用され得るということが理解されよう。
【００１７】
ＩＭＳは、水平に階層化されたネットワークアーキテクチャを規定する。図示されているシステム１００は、アプリケーション及びコンテンツのサーバ１０を備えるアプリケーション機能を含み、エンドユーザのために多様なサービスを実行する。サービスは例えば、ＳＩＰアプリケーションサーバ（ＳＩＰ  ＡＳ）内に実装することができる。ＩＭＳシステムは更に、制御機能、即ち、呼又はセッションの開始、修正、及び解放を制御するためのネットワーク制御サーバを含む。ネットワーク制御サーバのうちで最も重要なものは、ＣＳＣＦ１４である。ＣＳＣＦ１４は、ＳＩＰサーバという別名でも知られ、ＳＩＰセッションを制御し、セッション制御、特徴／サービスの制御、及びリソース割り当てのための他のネットワーク要素と協働する。このため、ＣＳＣＦ１４は、アプリケーションサーバ１０に加えて、ドメイン内の移動体端末１２及びＨＳＳ１３と通信するように構成される。ＨＳＳ１３は、ＩＭＳ加入者プロファイルを保持し、とりわけ、認証(authentication)及び許可(authorization)のための機能に加えてＣＳＣＦ及びＡＳのアクセスをサポートするための機能を備える。アプリケーションサーバ１０は、加入者プロファイル情報を取得するために、ＨＳＳ１３と情報をやりとりする。移動体端末１２については、ここでは移動体電話１２−１及びラップトップ１２−２として例示するが、ＩＭＳサービスは、これらがＩＭＳ／ＳＩＰクライアントを備えていることを要求する。そのようなクライアントは、一般的に、ＧＵＩ、サービスロジック、ルーティング機能、及びディスカバリ機能などを備える。
【００１８】
再び図１を参照して、発信側ドメインの移動体端末１２が着信側ドメインの移動体端末へメッセージを送信したいものとする。メッセージは、端末１２から発信側ドメインのＣＳＣＦ１４を経由して送信され、ＣＳＣＦ１４において、ＨＳＳ１３からダウンロードされたトリガーが、メッセージングアプリケーションサーバ１０におけるメッセージングサイズコントローラ及びウイルスフィルタなどの発信側サービスを始動させてもよい。発信側のＣＳＣＦ１４から、メッセージは着信側のＣＳＣＦ１４へ配信される。着信側のＣＳＣＦ１４において、ＨＳＳ１３からダウンロードされたトリガーに基づき、メッセージングアプリケーションサーバ１０における着信側サービスが起動されてもよい。そのようなサービスには、例えばブロックリストがある。次いで、メッセージは着信側のＣＳＣＦ１４を経由して受信端末１２へ向かってルーティングされる。メッセージが配信されるためには、受信端末１２は、接続されており且つ利用可能な状態ある必要がある。
【００１９】
ＩＭＳにおいて、好適なシグナリングはＳＩＰである。ＳＩＰは、「生きた(live)」セッションを制御するためのプロトコルとして意図されているので、後々の配信のために通知を格納するという概念を明示的には備えていない。それにもかかわらず、ＩＭＳ／ＳＩＰ及び類似する環境において蓄積転送（遅延）通知配信メカニズムを備えることが、最も望ましい。
【００２０】
移動体ドメインにおける従来の通知の蓄積転送は通常、ＳＭＳメッセージを使用する。図２は、そのような従来技術による通知メカニズムを説明する概略ブロック図である。例として、例えば他の移動体端末又はサーバから、通信システム２００の移動体端末２２へ、ＭＭＳメッセージが送信されようとしているものとする。移動体端末２２は、ＳＭＳベアラを介して、新しいＭＭＳについて通知されることになる。このＳＭＳ通知２１は、ショートメッセージのための蓄積転送メカニズムとして機能するＳＭＳＣ２０を使用して、供給される。ＳＭＳＣ２０は、ネットワークにおける移動体端末２２の位置を確認するために、ネットワークオペレータのＨＬＲ２３を使用する。ＨＬＲ２３がＳＭＳＣ２０に対して加入者の状態「非アクティブ」と共に応答した場合、ＳＭＳＣ２０は、一定期間メッセージを保持することになる。加入者が自己のデバイス２２にアクセスすると、ＨＬＲ２３はその旨に気付き、ＳＭＳＣ２０に通知し、ＳＭＳＣ２０はＳＭＳ通知２１を配信する。実際のＭＭＳメッセージはホームドメインにおけるＭＭＳＣに格納されており、ＳＭＳ通知２１内の情報に基づいて移動体端末２２が収集することができる。
【００２１】
背景技術のセクションで述べたように、ＳＭＳによる蓄積転送は、ＩＭＳなどのＩＰマルチメディアシステムに関して使用するにはあまり適していない。他の従来の通知メカニズムを図３に示す。図３は、国際特許出願［３］において提案されているソリューションに基づく概略ブロック図である。［３］は、例えばＩＭＳなどの移動体マルチメディアアーキテクチャに対してＭＭＳＣがインタフェースすることを可能にする機能を提供する。これによれば、ＳＩＰメッセージは、例えばメッセージが蓄積されて転送されるべきか否かを示すシグナリングフラグを含む。［３］はまた、ＳＭＳベアラの進化形として、ＭＭＳ受信通知のためにＳＩＰメッセージを使用することに言及している。そのような蓄積転送メカニズムは、ＩＭＳシステムに適合させられているが、上述のＳＭＳ通知に直接的に対応している。図３のシステム３００において、修正されたＭＭＳＣ（又はＭＭＳＣと組み合わされたアプリケーションサーバ）などの蓄積転送（Ｓ＆Ｆ）サーバ３０は、図２のＳＭＳＣのものに対応する機能を提供する。Ｓ＆Ｆサーバ３０は、フラグによって指示されるように、適切な蓄積機能を実行する。通知３１は、移動体端末３２が利用可能な状態になるまでＳ＆Ｆサーバ３０に格納され、移動体端末３２の状態は、Ｓ＆Ｆサーバ３０と通信するように構成されたＨＨＳ３３によって監視される。格納されたＭＭＳメッセージを取り出すための通知３１の送信について端末３２が到達可能になると、ＨＨＳ３３は、Ｓ＆Ｆサーバ３０に通報する。Ｓ＆Ｆサーバ３０と移動体端末３２との間の通信は、ネットワーク内の、ＣＳＣＦを含む呼処理サーバ（ＣＰＳ）３４を介して行われる。
【００２２】
図３のソリューションは、ＩＭＳ／ＳＩＰ環境における通知メッセージの蓄積転送を提供するが、依然として、複雑で要求仕様が厳しい(demanding)というＳＭＳソリューションの欠点と関係している。特に、そのようなソリューションでは、通知を制御する機能は、各々のアプリケーションサーバ／ＭＭＳＣそれぞれに実装されることになる。このことは、異なるアプリケーションサーバに多数の同一の機能が存在することになるということを意味する。また、ＣＳＣＦは、多数の並行するサードパーティーレジストレーション(3rd party registration)によって負荷をかけられることになる。
【００２３】
図３におけるものなどのソリューションに関して説明した欠点を克服するために、本発明は、新しい種類の蓄積転送メカニズムを提案する。これによれば、通信における受信側の通知サーバが、通知によって宛先とされた移動体端末の状態（ステータス）に基づく通知を制御するために使用される。受信者が利用可能な状態でないと判断された場合、例えば、受信者が利用可能な状態になるまで通知は通知サーバに格納される。
【００２４】
移動体端末の状態は、例えば「利用可能(available)」「利用不可能(non-available)」などの、移動体端末のＩＰ接続状態に関連させることが好ましい。代わりの（或いは追加の）状態が移動体端末の地理的な位置に関連している実施形態も可能である。状態変化は、例えば、移動体端末が特定の地理的領域に侵入した時などに発生し得る。
【００２５】
いくつかの例示的な実施形態を参照して、提案する端末の通知を更に説明する。
【００２６】
図４は、本発明の一実施形態に従う通知メカニズムの概略ブロック図である。アプリケーションサーバ４０によって表されるサービスは、移動体端末４２によって表される受信者に対して、例えばＳＩＰ  ＮＯＴＩＦＹなどのＳＩＰメッセージに基づいて通知を行う必要がある。通知は、アプリケーションサーバからネットワーク４００内の制御ロジック４４へ送信される（Ｉ）。制御ロジック４４は、通知を受信者へ送信することができないということを認識し、この通知を通知サーバ４５へ転送する。通知サーバ４５において、通知４１は、後で配信するために格納される（ＩＩ）。制御ロジック４４による移動体端末４２の状態に関する判定は、例えば、「未登録(Not Registered)」に対するトリガーを使用することができる。なぜなら、移動体端末４２は通常、ＩＰ接続を確立するために制御ロジック４４に登録する必要があるからである（ＩＩＩ）。受信者４２の状態が、この例では「利用可能(available)」に変化すると、制御ロジック４４は、例えばサードパーティーレジストレーション手順を介して、その旨に気付く。通知４１は、通知サーバ４５の記憶装置から取り出され（ＩＶ）、受信者４２へ送信され（Ｖ）、これにより、受信者４２においてサービスロジックを実行することが可能になる。
【００２７】
本発明は、ＩＭＳなどのＩＰマルチメディアシステムにおいて、有利に実装され得る。ＩＭＳの用語においては、アプリケーションサーバ４０は例えば、プレゼンスサーバ、メッセージングサーバ、及び位置サーバのうちの少なくともいずれかを含むか、或いは少なくともいずれかに対応し得る。制御ロジックは典型的にはＣＳＣＦであり、「未登録トリガー(not registered trigger)」があると、ＳＩＰ通知を通知サーバへ好適にルーティングする。同様に、通知サーバは、多様なサービスから多数の異なる受信者への通知を制御するように特別に適合されたＳＩＰアプリケーションサーバとして実装され得る。最後に、ＩＭＳシステムにおいては、受信者は一般的に、例えばプレゼンス又はメッセージングのためのクライアントを備える移動体端末である。
【００２８】
本発明を用いると、ＩＭＳベースのネットワーク及び他のＩＰマルチメディア／ＳＩＰベースのネットワークは、オフラインのユーザが利用可能になった時にそのユーザへ配信されるサービスを有することができるようになる。非効率的なＳＭＳベースの通知メカニズムは、本発明の通知サーバを使用することにより、よりインテリジェントでリソース効率の良いＩＰベースの通知の制御に集約される。これにより、新しいサービスの開発が可能になり、サービスの振る舞いが改善される。
【００２９】
図３に示すもののような従来のソリューションでは、異なるアプリケーションサーバ内に多数の同一の機能が存在することになり、ＣＳＣＦ（或いは対応するノード）は、多数の並行するサードパーティーレジストレーションによって負荷をかけられることになる。本発明は、より洗練されたソリューションを提供し、これによれば、通知サーバは、多数の異なるサービスに関する通知を集中型の方法で制御する。このようにすれば、個々のアプリケーションサーバは、通知メッセージの送信後はそれについて考慮する必要が無く、それゆえ、この点においてより低い負荷しかかからない。
【００３０】
アプリケーションサーバは、移動体端末のためのメッセージ（例えばＭＭＳ）が受信されたという事実を移動体端末に通知するために、例えば、通知メッセージを使用することができる。或いは、通知メッセージは、ある移動体端末が他の移動体端末との通信を開始することを望んでいるということを示してもよい。
【００３１】
他の実施形態は、位置及びプレゼンスに関するパラメータの変化に関して、端末に対して絶え間なく通知を送信する種類のサービスに関するものであってもよい。例えば、移動中の乗り物の位置座標を移動体端末中の地図アプリケーションに送信する、位置サービスを想定する。端末内のクライアントは、座標を取得し、乗り物がどのように移動しているかを示す線を地図上に描く。位置の更新のいくつかが失われた場合、サービスの性能が貧弱なものになるということは容易に理解できよう。この場合、線は不正確なものになるであろう。本発明に係る安全な通知の配信によれば、そのようなサービスの性能及び価値が著しく向上する。
【００３２】
通知メッセージは、ＳＩＰベースのもの、例えば、ＳＩＰ  ＮＯＴＩＦＹ又はＳＩＰ  ＭＥＳＳＡＧＥを含むか或いは基づくものであるのが好適である。しかしながら、本発明はＳＩＰ通信に限定されるものではなく、他の通知に関しても同様に使用可能であるということを強調しておく。
【００３３】
移動体端末の状態に関する情報は、本発明の種々の実施形態において種々の方法で提供可能である。通知メッセージの格納は、移動体端末へ通知メッセージを送信することに関する失敗した試みに引き続いて行われ得る。そのような場合、送信失敗は、通知サーバに対して移動体端末の状態を間接的に示す。
【００３４】
通知メッセージの格納は、移動体端末の現在の状態に関する知識に基づいた格納決定に引き続いて行われてもよい。そのような知識は通常、外部ユニットから通知サーバへ提供される。移動体端末がＣＳＣＦなどのセッション制御機能に登録した場合、このユニットは例えば、移動体端末の接続状態に関する情報を通知サーバに対して通信することができる。図４は、そのようなソリューションに関するものである。更に進化したロジックを備えるアプリケーションサーバが、ＣＳＣＦの代わりに、或いは補完的に、使用されてもよい。図５に示される特定の一実施形態において、通知サーバ５５は、移動体端末５２の状態に関連する情報を取得するためにＨＳＳ５３とやりとりする。次いで、通知サーバ５５は、通知メッセージ５１をどのように制御するかを決定するために、例えば、ＨＳＳ５３の加入者プロファイルに含まれる、移動体端末５２の接続状態に関する情報を使用する。或いは、移動体端末５２の状態が、移動体端末５２の位置を概ね絶え間なく監視しているプレゼンスサーバ又は位置サーバ（不図示）を用いて、通知サーバ５５へ通信される。（システム５００のＡＳ５０及び制御ロジック５４は、図４におけるそれらに対応する。）
【００３５】
図６は、本発明の他の例示的な実施形態に従う通知メカニズムを示す概略ブロック図である。図６の通知サーバ６５は、多数のアプリケーションサーバ６０−１、６０−２、６０−３からの通知を同時に制御することができる。通知は、格納するために、ネットワーク６００内の制御ロジック６４を介して通知サーバ６５へ送信される。各端末６２−１、６２−２の状態が変化すると、通知サーバ６５は、（両方又は片方の）適切な端末６２−１、６２−２へ通知を転送する。図６の例では、２つの端末が存在し、そのうちの一方は２つの通知メッセージの受信者であるが、変形例ももちろん可能である。例えば、１つのアプリケーションサーバが複数の通知メッセージを１以上の移動体端末のために送信する場合があってもよい。
【００３６】
なお、本発明を用いると、ＭＭＳなどのメッセージを端末に通知するために通知が使用される場合、通知のみが通知サーバに格納される。実際のメッセージは、アプリケーションにもよるが、発信側のアプリケーションサーバ又は他のどこかに収容される。また、通知の送信者、即ちアプリケーションサーバは、再送の開始に関与することは無い。というのも、再送の開始は通知サーバによって制御されるからである。通知を蓄積転送するためのいかなる機能も、個々のアプリケーションサーバに含まれる必要は無い。それゆえ、提案する通知メカニズムは、実装が容易であるという更なる利点を伴うことになる。
【００３７】
図７は、本発明の例示的な一実施形態に従う通知サーバの論理要素を示す概略ブロック図である。図７の単純化された通知サーバ７５は、通知を受信して配信する手段７６と、通知格納手段７７と、移動体端末の状態を判定する手段８８と、外部ノードに対するインタフェース７９とを備える。受信手段７６を介して通知メッセージを受信すると、状態判定手段７８は通常、移動体端末の状態が通知を送信可能な状態であるか否かを判定する。この判定は、状態判定手段７８と、例えばＣＳＣＦ、ＨＳＳ、プレゼンスサーバなどの外部ノードとの、インタフェース７９を介した何らかのやりとりを伴う。（或いは、送信の試みの結果に基づいて状態が判定されてもよい。）通知を送信不可能である場合、通知は記憶装置７７へ転送される。状態判定手段７８は、移動体端末の状態が変化する時を知るために、（単数又は複数の）外部ノードとやりとりする。状態の情報は、絶え間なく又は要求に応じて、通知サーバへ提供され得る。ある種の状態変化があったことを通知サーバ７５が知ると、記憶装置７７から通知が取得され、通知配信手段７６によって配信（或いは少なくとも配信のために送出）される。
【００３８】
更に、通知サーバ７５は、受信者が利用可能な状態になるまでどの通知メッセージを通知記憶装置７７に格納しておくべきかを決定する手段（不図示）を備えていてもよい。格納の決定は例えば、発信者／送信者の識別情報に基づいていてもよいし、或いは通知メッセージの種類に基づいていてもよい。通知メッセージがその通知のための「有効期限(time-to-live)」を規定するタイムスタンプを含み、それに従って格納が実行される実施形態も可能である。
【００３９】
本発明に従う通知サーバは例えば、通信システムの着信側ドメインに配置されたＳＩＰ  ＡＳとして実装されてもよいし、或いはそのＳＩＰ  ＡＳを含んでもよい。それは一般的には、図６に示すように、複数のアプリケーションサーバからの通知メッセージを同時に制御するように適合される。とは言っても、同一の着信側ネットワークに２以上の通知サーバが存在してももちろん構わない。
【００４０】
特定の実施形態によれば、状態が変化した時に多数の通知メッセージによって受信者において溢れることを防止するために、受信者への通知が統合されてもよい。そのような場合、移動体端末に対する複数の通知メッセージが、適切な方法で、例えば１つのＳＩＰメッセージに統合され、これにより、統合された通知メッセージは、状態変化に応えて（例えば、受信者が利用可能な状態になった時）、移動体端末へまとめて送信される。通知メッセージを統合する手段は、好ましくは、通知サーバが備えるが、例えばＣＳＣＦなど、ネットワーク内の他のどこかに実装されてもよい。
【００４１】
図８は、本発明の典型的な一実施形態に従う通知方法を要約するフローチャートである。最初のステップＳ１において、移動体端末に対して通知を行いたいと欲するアプリケーションサーバは、この移動体端末へ向けられた通知メッセージを送信する。通知は、通常はＣＳＣＦなどの制御ロジックを介して通知サーバへ転送される（ステップＳ２）。ステップ３は、移動体端末の状態をチェックする。移動体端末の状態が第１の所定の状態（例えば、「利用不可能(non-available)」）に対応する場合、通知は通知サーバに格納され（ステップＳ４）、これは、第２の所定の状態（例えば、「利用可能(available)」）への状態変化の指示を通知サーバが受信するまで続く（ステップＳ５）。状態変化は、例えば、通信システムにおける移動体端末の登録に起因し得る。最後のステップＳ６において、状態変化に応えて、通知は、通知サーバから移動体端末へ送信される。通常、この通信は、ＣＳＣＦ又は類似した制御ロジックを介して行われる。移動体端末の状態が通知の格納を要求しない場合、例えば、移動体端末が既に利用可能な状態である場合は、図８において矢印によって示されるように、手順は通常、ステップＳ３からステップＳ６へ直接移行することになる。
【００４２】
具体的に示される実施形態を参照して本発明を説明してきたが、本発明は、開示された特徴の均等物もカバーし、加えて、当業者にとって明らかな修正及び変形をもカバーするということを強調しておく。従って、本発明の範囲は、添付の請求の範囲によってのみ限定される。
【００４３】
［略語］
AS - Application Server （アプリケーションサーバ）
CPS - Call Processing Server （呼処理サーバ）
CSCF - Call Service Control Function （呼サービス制御機能）
GUI - Graphical User Interface （グラフィカルユーザインタフェース）
HLR - Home Location Register （ホームロケーションレジスタ）
HSS - Home Subscriber Server （ホーム加入者サーバ）
IMS - IP Multimedia Subsystem （ＩＰマルチメディア・サブシステム）
IP - Internet Protocol （インターネットプロトコル）
MMS - Multimedia Messaging Service （マルチメディアメッセージングサービス）
MMSC- Multimedia Messaging Service Center （ＭＭＳセンター）
S&F - Store & Forward （蓄積転送）
SIP - Session Initiation Protocol （セッション開始プロトコル）
SMS - Short Message Service （ショートメッセージサービス）
SMSC - Short Message Service Center （ＳＭＳセンター）
【００４４】
［参考文献］
［１］3GPP TS 23.228 V6.9.0 (2005-03)
［２］SIP: Session Initiation Protocol, RFC 3261, June 2002
［３］国際公開第WO 03/087972号パンフレット， Nokia Inc.， ２００３年１０月２３日発行
【図面の簡単な説明】
【００４５】
【図１】本発明を実装可能な、ＩＰマルチメディア通信のための典型的なネットワークの図式的概観図である。
【図２】ＳＭＳメッセージを使用する従来の通知メカニズムを示す概略ブロック図である。
【図３】他の従来の通知メカニズムを示す概略ブロック図である。
【図４】本発明の一実施形態に従う通知メカニズムを示す概略ブロック図である。
【図５】本発明の他の例示的な実施形態に従う通知メカニズムを示す概略ブロック図である。
【図６】本発明の更に他の例示的な実施形態に従う通知メカニズムを示す概略ブロック図である。
【図７】本発明の例示的な一実施形態に従う通知サーバの論理要素を示す概略ブロック図である。
【図８】本発明の典型的な一実施形態に従う通知方法のフローチャートである。
【図１】
2008546306.tif 000003
【図２】
2008546306.tif 000004
【図３】
2008546306.tif 000005
【図４】
2008546306.tif 000006
【図５】
2008546306.tif 000007
【図６】
2008546306.tif 000008
【図７】
2008546306.tif 000009
【図８】
2008546306.tif 000010
【国際調査報告】
2008546306.tif 000011
2008546306.tif 000012
2008546306.tif 000013
2008546306.tif 000014