JP5504315B2 - ページモードメッセージング - Google Patents

Description

本発明は、メッセージングに関し、より詳細には、ワンショットメッセージングとも呼ばれるページモードメッセージングに関する。

通信技術、特にＩＰベースの通信技術及びエンドユーザ端末の発展により、多目的通信の実現性及び様々なサービスの導入が可能になってきた。通信システムに垂直的には統合されていないがマルチメディアアーキテクチャを構築するためのツールであるＳＩＰ（セッション開始プロトコル）により提供されるプリミティブを用いて、ますます頻繁にサービスが実施されている。より正確には、ＳＩＰとは、１つ又はそれ以上の当事者とのセッションを生成、変更、及び終了するためのＩＥＴＦ定義のアプリケーション層制御（シグナリング）プロトコルである。これらのセッションには、例えばインターネット電話、マルチメディア配信、マルチメディア会議、及びＰｏＣ（プッシュツートーク・オーバーセルラー）セッションが含まれる。メッセージングサービスに関しては、プレゼンス及びインスタントメッセージングサービスを提供するためのＳＩＰ及びＳＩＰの既存の実装を用いたＳＩＭＰＬＥ（インスタントメッセージングとプレゼンスを実現するためのＳＩＰ拡張：ＳＩＰ ｆｏｒ Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｌｅｖｅｒａｇｉｎｇ Ｅｘｔｅｎｓｉｏｎｓ）がＩＥＴＦで定義されている。ＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）もまた、ＳＩＰ／ＳＩＭＰＬＥプロトコルに基づくＩＭ（インスタントメッセージング）イネーブラを定義している。ＳＩＭＰＬＥは、インスタントメッセージ交換の２つのモード、すなわちページモード及びセッションモードを定義する。ページモードは、ＳＩＰ ＭＥＳＳＡＧＥ方法を使用し、これによりページモードのインスタントメッセージが送信され、プロトコルレベルでは、後続のインスタントメッセージは前のインスタントメッセージに関連しない。各即時メッセージは、たとえ前のメッセージに対する応答であっても、独立したトランザクションとみなされる。従って、ＳＩＰ ＭＥＳＳＡＧＥ方法は、従来の電子メール又はショートメッセージサービスに類似する。セッションモードは、シグナリング及びセッション確立にＳＩＰを使用し、セッションが確立された後の一連のインスタントメッセージの伝送には、ＭＳＲＰ（メッセージセッションリレープロトコル）を使用する。以下では、この組み合わせを単にＭＳＲＰメカニズムと呼ぶ。すなわち、ＭＳＲＰメカニズムは、セッションモードメッセージングと呼ばれるチャットタイプのメッセージングを提供する。

ユーザが大容量のページモードメッセージを送信したいときに問題が発生する。ＳＩＰ ＭＥＳＳＡＧＥ方法は、ＵＤＰ又はＴＣＰ伝送のいずれかを使用することができる。ＴＣＰは、大容量メッセージにも信頼性の高い伝送方法を提供するが、ＳＩＰ ＭＥＳＳＡＧＥ方法に関しては、ＴＣＰ伝送が常に保証されるとは限らない。大容量メッセージの送信にＵＤＰが使用される場合、ＵＤＰ最大サイズよりも大きいパケットは分割されて、受信側に正しい順序で到着しない可能性がある。更に、ＴＣＰを保証することができたとしても、輻輳制御に関する別の問題が残る。ＳＩＰ ＭＥＳＳＡＧＥ方法は、ＳＩＰセッション制御シグナリングの一部であるので、メッセージは、ＳＩＰシグナリングによって使用されるのと全く同じリソースを用いて送受信される。ユーザ端末に関して、これは、ユーザ端末において大容量メッセージが送受信される間は、実際のＳＩＰシグナリングがブロックされる可能性があることを意味する。ＳＩＰシグナリングのための上述のリソースは、例えば、汎用のＰＤＰ（パケットデータプロトコル）コンテキスト、或いはＧＥＲＡＮ（ＧＳＭ／ＥＤＧＥ無線アクセスネットワーク）及び／又はＵＴＲＡＮ（ＵＭＴＳ地上無線アクセスネットワーク）システムの場合は専用シグナリングのＰＤＰコンテキストとすることができる。他のシステムでは、リソースは例えば、シグナリング目的のための予約及び／又は専用の帯域幅とすることができる。ＳＩＰシグナリングがブロックされることに加え、ＳＩＰプロキシの負荷に関する更なる問題が生じる可能性がある。ページモードメッセージは通常、ＳＩＰ ＭＥＳＳＡＧＥ方法を使用するので、ＳＩＰ ＭＥＳＳＡＧＥ方法を用いる全てのメッセージがＳＩＰプロキシを介して送信される。従って、ＳＩＰプロキシを介して送信される大きいサイズのページモードメッセージは、ＳＩＰプロキシのパフォーマンスを著しく低下させ、事実上、全てのＳＩＰシグナリングのブロックとＳＩＰネットワークの全体のパフォーマンスの低下という両方の結果をもたらす可能性がある。従って、場合によっては、大きいサイズのメッセージにＳＩＰ ＭＥＳＳＡＧＥ方法を使用するのは適切ではない。

１つの解決策としては、メッセージのサイズがある制限を超える場合には、ＳＩＰ ＭＥＳＳＡＧＥ方法の代わりにＭＳＲＰメカニズムを使用することである。しかしながら、ＭＳＲＰメカニズムは、セッションモードメッセージングサービスのためのものであり、ページモードメッセージングを目的としていない。更に、受信するページモードメッセージは、保留されてメッセージ受信箱に格納され、そこからユーザが都合の良いときにそれらのメッセージを読むことができるが、セッションモードメッセージングの場合は、受信メッセージがユーザ端末により開封されてユーザに示され、対話を促す。従って、受信側から見ると、ＭＳＲＰメカニズムの使用時にはページモードメッセージを受信することができないことになる。

本発明の目的は、上記の問題を克服するための方法及び該方法を実装するための装置を提供することである。本発明の目的は、独立クレームに記載される内容によって特徴付けられる方法、ユーザ端末、及びサーバにより達成される。本発明の好ましい実施形態は、従属クレームにおいて開示される。

本発明は、問題を認識して、セッションモード（チャットタイプ）メッセージングメカニズムを用いて送信されるメッセージがページモードメッセージであるか否かを示し、更に該メッセージがページモードメッセージであることに応答して、ページモードメカニズムを用いて又はこのようなページモードメッセージに関して定義された特定の指示に従ってメッセージが受信されたかのように動作することによりこの問題を解決することに基づいている。セッションモードに関して、一連のメッセージ交換を目的とするＭＳＲＰなどのプロトコルが使用されることを意味する。ページモードに関しては、プロトコルレベルで各メッセージが独立したトランザクションであること、すなわち、後続のインスタントメッセージはプロトコルレベルでは前のインスタントメッセージに関連しないことを意味する。

本発明の利点は、インジケーションを用いることにより、ページモードメッセージがセッションモードメッセージとして送信されたときでもページモードメッセージとして受信することができる点である。別の利点は、大容量メッセージに起因するＳＩＰシグナリングのブロックを回避することができる点である。

簡略化したシステムアーキテクチャを示す図である。 本発明の実施形態によるユーザ端末の送信モードにおける機能性を示すフローチャートである。 本発明の実施形態によるユーザ端末の受信モードにおける機能性を示すフローチャートである。 本発明の実施形態によるユーザ端末の受信モードにおける機能性を示すフローチャートである。 本発明の実施形態によるＳＩＰ ＩＮＶＩＴＥメッセージの実施例を示す図である。 本発明の実施形態によるＳＩＰ ＩＮＶＩＴＥメッセージの実施例を示す図である。 本発明の実施形態によるＳＩＰ ＩＮＶＩＴＥメッセージの実施例を示す図である。 本発明の実施形態によるＳＩＰ ＩＮＶＩＴＥメッセージの実施例を示す図である。 本発明の実施形態によるシグナリングを示す図である。 本発明の実施形態によるシグナリングを示す図である。 本発明の実施形態によるシグナリングを示す図である。 本発明の実施形態によるシグナリングを示す図である。

以下において、添付図面を参照しながら好ましい実施形態を用いて本発明をより詳細に説明する。
以下の実施形態は例示的なものである。本明細書では、複数の箇所で「ある実施形態」、「１つの実施形態」又は「一部の実施形態」への言及をする場合があるが、このような各参照が同じ実施形態を指すこと、及びその特徴が単一の実施形態だけに当てはまることを必ずしも意味する訳ではない。異なる実施形態の単一の特徴を組み合わせて別の実施形態を提供することもできる。

本発明は、あらゆるユーザ端末、サーバ、及び／又はユーザ端末によりアクセス可能であり、且つメッセージングサービス、すなわちほぼリアルタイムでのエンティティ間の又はメールボックス内へのメッセージフォーマットのデータ送信を可能にするあらゆる通信システム又は異なる通信システムのあらゆる組み合わせに対して適用可能である。メッセージフォーマットに対してもデータ型に対しても制限はない。データは、テキスト、音声、ビデオクリップ、マルチメディア、その他とすることができる。通信システムは、固定通信システム又は無線通信システム、或いは固定ネットワークと無線ネットワークの両方を利用する通信システムとすることができる。特に無線通信においては、使用されるプロトコル、通信システム及び端末の仕様は急速に進歩している。このような進歩により、本発明に追加の変更が必要となる可能性がある。従って、全ての用語及び表現は広範に解釈されるべきであり、これらは本発明を限定するものではなく、例証を意図している。

以下では、本発明を適用することのできるシステム環境の実施例として、ＳＩＰ及びＭＳＲＰを利用する極めて簡略化したシステム環境を用いて本発明を説明しており、本発明をこれに限定するものではない。通信システム、及びプロキシなどの中間ノード、並びにＳＩＰ及びＭＳＲＰよりも下位又は上位で使用される他のプロトコル、又は対応するプロトコルは、実際の発明には無関係であることを理解されたい。従って、これらをここでより詳細に議論する必要はない。本発明は第一に、アプリケーション層におけるメッセージ送信に関する。

図１は、通信システム１、２つのユーザ端末２、２’、及びネットワーク３だけを示す極めて簡略化したシステムアーキテクチャである。当業者であれば、システムはまた、他のデバイス、インスタントメッセージングサーバなどのシステムエンティティ、機能、及び構造を含むことは明らかであり、本明細書ではこれらについて詳細に説明する必要はない。

ユーザ端末２、２’は、ユーザが通信システムと直接又はコンピュータシステムを介して対話できる、装置の一部又はデバイスであり、すなわち、ユーザに情報を提示し、ユーザによる情報入力を可能にし、言い換えれば、ユーザ端末とは特定の通信の終端点である。すなわち、ユーザ端末２、２’は、メッセージをサポートし、アクセスネットワーク（図１には示されていない）が存在する場合にはこのようなアクセスネットワークを介してシステムのネットワークと通信することのできるあらゆるノード又はホストとすることができる。ユーザ端末２、２’は、ネットワーク３に無線で又は固定接続を介して接続されたパーソナルコンピュータＰＣなどの非移動装置とすることができる。ユーザ端末２、２’はまた、メッセージングをサポートする無線移動端末、サービスプラットホームとしての役目を果たし且つ異なるサービス関連機能のロード及び実行をサポートするマルチサービス端末、又は（利用可能なアクセスネットワークを介して）ネットワークに接続可能なラップトップＰＣ、（利用可能なアクセスネットワークを介して）ネットワークに接続可能な携帯情報端末ＰＤＡ、その他とすることもできる。

ユーザ端末２は、ユーザがメッセージを生成及び／又は読み出すことのできる少なくとも１つのユーザインタフェース（ＵＩ）２１、１つ又はそれ以上のメッセージングアプリケーション（Ａｐｐｌ）２２、受信するページモードタイプのメッセージを少なくとも一時的に格納するためのメモリ（Ｍｅｍ）２３（又はユーザ端末はメモリにアクセスを有するように構成される）、及び通信情報（メッセージ）を送受信するためのトランシーバ（ＴＲｘ）２４を含む。

メッセージングアプリケーション２２は、本発明に従う機能性を実装するように構成されたソフトウェアアプリケーションとすることができる。機能性は、例えば、対応するメッセージングアプリケーションを更新することによって、又は新規のメッセージングアプリケーションを端末に追加することによって実現することができる。

図２は、本発明の実施形態によるユーザ端末の送信モードにおける機能性を示すフローチャートである。図２の実施例では、ユーザが常にページモードメッセージを同様の方法で生成すること、及びメッセージに対して使用される方法／メカニズムをユーザ端末が選択することを前提とする。

図２は、ユーザがページモードメッセージを生成して、受信側にメッセージを送信するための指示をユーザインタフェースを介して与えるとき（ステップ２０１）に開始される。すなわち、ステップ２０１において、ユーザ端末は「このアドレスにメッセージを送信する」コマンドを受信する。このコマンドに応答してステップ２０２で、ユーザ端末は、メッセージのサイズを求め、ステップ２０３で、そのメッセージサイズが予め定められたサイズ制限よりも大きいか否かをチェックする。予め定められた制限は、例えば、使用するサービスプロトコル、ユーザ、又はオペレータが定義することができ、或いは端末に対して事前構成することができる。予め定められた制限は、トランスポートプロトコルメッセージに適合するサイズに相当するのが望ましい。しかしながら、予め定められた制限の値及び予め定められた制限の設定方法は、本発明に関して重要な意味を持たない。本発明の一部の実施形態では、全てのページモードメッセージをそのサイズに関わらず、ＭＳＲＰメカニズム又はこれに相当するメカニズムを用いて送信することさえ可能である。例えば、オペレータがページモードを使用できないことにより、ユーザ端末は常にセッションモードを使用するように事前設定することができる。

メッセージサイズが制限を超えない場合（ステップ２０３）、ステップ２０４で、ユーザ端末は、ＳＩＰ ＭＥＳＳＡＧＥ方法を用いて内容を送信する。

メッセージサイズが制限を超える場合（ステップ２０３）には、ステップ２０５で、ユーザ端末は、本発明に従って、ＭＳＲＰメカニズムを用いてページモードインジケータと共にメッセージを送信する。実装によっては、ユーザ端末は、ＭＳＲＰにより送信するページモードメッセージにメッセージの実際のサイズに関する情報を追加することができ、又はできない場合もある。実際のメッセージ送信手順については、図６、７、及び８により詳細に示されている。

本発明の一実施形態では、ユーザは、３つのオプション、すなわち小容量ページモードメッセージ（サイズは予め定められた制限以下）、他のページモードメッセージ、及びセッション（チャット）メッセージングの中から選択する必要があり、ユーザが他のページモードメッセージを選択する際には、メッセージの送信時に、ページモードインジケータを用いるセッションモードメッセージングメカニズムが使用される。

図３は、本発明の実施形態によるユーザ端末の受信モードにおける機能性を示すフローチャートである。図３の実施例では、メッセージの実際のサイズに関する情報は送信されないことを前提とする。明瞭化の目的でなされる追加の前提は、ユーザ端末がメッセージを受信することができるようにメッセージ用に十分な空きメモリを有していること、及びユーザ端末がページモードメッセージを受け入れるように構成されていることである。メッセージが空きメモリよりも大きい場合に起こることは本発明とは無関係であり、すなわちこれは、受信側端末の実装次第であり、例えば、十分な空きメモリが存在しない場合には、端末はセッション要求を拒否することができ、或いはセッション要求は受け入れられるが、メモリが満杯になるとセッションを終了する。

ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）の受信（ステップ３０１）に応答して、ステップ３０２でユーザ端末は、ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）がページモードメッセージのためのものであるかどうかをチェックする。ページモードメッセージのためのものである場合には、ステップ３０３で、ユーザ端末がセッションを確立し、ステップ３０４でメッセージを受信し、ステップ３０５でメッセージを格納し、ステップ３０６でセッションを解放する。その後、又はこれと同時に、ステップ３０７でユーザ端末はメッセージを受信したことをユーザに表示する。従って、ユーザは後でメッセージを読むことができる。すなわち、ユーザ端末は、メッセージがＳＩＰ ＭＥＳＳＡＧＥ方法で受信されたかのようにユーザに対して動作する。

ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）がチャットのためのもの（すなわちセッションモードメッセージング用）であり、ページモードメッセージのためのものではない場合（ステップ３０２）、ステップ３０８でユーザ端末はセッションを確立し、ステップ３０９で、セッションが終了するまでダイアログを表示する。

受信ユーザ端末は、全てのページモードメッセージを拒否するように構成することができ、この場合にはセッションが確立されないが、ステップ３０３から３０７までの代わりに拒否が送信される。

受信ユーザ端末は、ページモードメッセージ要求をネットワーク受信箱、別の端末、その他に転送するように構成することができ、この場合にはセッションが確立されないが、ステップ３０３から３０７までの代わりに要求が転送される。このような状況の実施例が図７及び８に示されている。全てのページモードメッセージが転送されていずれかの場所に格納され、ユーザが別の端末でこれらのメッセージを表示する必要がある場合でも、転送を行う端末がページモードメッセージングを提供するとみなされる。

本発明の別の実施形態では、メッセージの受信後にチェックが行われる（すなわち、ステップ３０２がステップ３０４の後に実行され、チェック後の処理はステップ３０５又はステップ３０８のいずれかに進む）。

図４は、本発明の別の実施形態によるユーザ端末の受信モードにおける機能性を示すフローチャートである。図４の実施例では、メッセージの実際のサイズに関する情報が存在することを前提とする。図３に関連する上記のような明瞭にするための追加の前提は、同じ説明を不必要に繰り返すわけではないが、ユーザ端末がメッセージ用に十分な空きメモリを有していること、及びユーザ端末がページモードメッセージを受け入れるように構成されていることである。

ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）の受信（ステップ４０１）に応答して、ステップ４０２でユーザ端末は、ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）がページモードメッセージのためのものかどうかをチェックする。ページモードメッセージのためのものである場合には、ステップ４０３で、ユーザ端末がメッセージのサイズについてユーザに通知する。ユーザがメッセージを受け入れる場合（ステップ４０４）、ステップ４０５でユーザ端末がセッションを確立し、ステップ４０６でメッセージを受信し、ステップ４０７でメッセージを格納する。その結果、ユーザは後でメッセージを読むことができる。次にステップ４０８で、ユーザ端末はセッションを解放する。すなわち、ユーザ端末はメッセージがＳＩＰ ＭＥＳＳＡＧＥ方法で受信されたかのようにユーザに対して動作する。この特定の実施例では、ユーザはメッセージの配信を受け入れることで既にメッセージについて通知されたとみなされるので、ユーザ端末はメッセージの受信についてユーザに通知しない。しかしながら、別の実装では、ユーザデバイスは、ユーザに対してメッセージの受信を通知するようにも構成することができる。

ユーザがメッセージを受け入れない場合（ステップ４０４）、ステップ４０９で、ユーザ端末はセッション確立を拒否する。別の実施形態では、ユーザ端末は、拒否するのではなく図７及び８に示されるようにセッション確立を転送して、メッセージをネットワーク内に格納し、後で取り出すことができるようにすることができる。

ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）がチャットのためのもの（すなわちセッションモードメッセージング用）でありページモードメッセージのためではない場合（ステップ４０２）、ステップ４１０で、ユーザ端末はセッションを確立し、ステップ４１１でセッションが終了するまでダイアログを表示する。

本発明の別の実施形態では、ユーザがメッセージを受け入れるか否かを尋ねる代わりに（すなわちステップ４０３の代わりに）、ユーザ端末は、予め定められたサイズ制限を超えないメッセージを受け入れるように構成される。予め定められたサイズ制限は、例えば、オペレータ、ユーザ端末メーカー、及び／又はユーザが定義することができる。

以下では、図５Ａから８で示される幾つかの実施例においてシグナリングについてより詳細に説明し、ここではＳＤＰ（セッション記述プロトコル）を用いてセッションを開始し、ＭＳＲＰ ｏｖｅｒ ＴＣＰを用いて実際の内容を送信するが、本発明はこれらの実施例に限定されるものではない。以下の実施例に関連してなされる別の前提は、受信ユーザ端末がメッセージを拒否しないことである。必要に応じて、更なる情報はｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｍｅｓｓａｇｅ−ｓｅｓｓｉｏｎｓ−１０．ｔｘｔに見出すことができ、これは参照により本明細書に組み込まれる。しかしながら、どのプロトコルが使用されるかは本発明に関して重要な意味を持たず、上記は例証にすぎない。例えば、ＳＤＰの代わりに他のオファー／アンサーメカニズムプロトコルを使用することができ、ＴＣＰの代わりに、ＳＣＴＰ（Ｓｉｇｎａｌｉｎｇ Ｃｏｍｍｏｎ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などの他の輻輳制御プロトコルを使用することができる。

図５Ａから５Ｄは、セッションモード招待がページモードメッセージのためであることをセッションモードメッセージがどのように示すことができるかについての幾つかの実施例を示している。

図５Ａの実施形態では、新規のページモードインジケータ５−１（ｍ＝ｍｅｓｓａｇｅ ９ ｍｓｒｐ ｐａｇｅ−ｍｏｄｅ）を含むｍライン及びメッセージの実際のサイズを示すパラメータａ＝ｍａｘ−ｓｉｚｅ５−２（ａ＝ｍａｘ−ｓｉｚｅ：ａｃｔｕａｌ ｓｉｚｅ）の組み合わせによりページモードメッセージであることが示されている。

図５Ｂの実施形態では、新規のページモードインジケータ５−１（ｍ＝ｍｅｓｓａｇｅ ９ ｍｓｒｐ ｐａｇｅ−ｍｏｄｅ）を含むｍライン及びメッセージの実際のサイズを示すパラメータ５−３ａ＝ａｃｔｕａｌ−ｓｉｚｅ（ａ＝ａｃｔｕａｌ−ｓｉｚｅ：ａｃｔｕａｌ ｓｉｚｅ）の組み合わせにより、ページモードメッセージであることが示されている。この実施形態では、パラメータａ＝ｍａｘ−ｓｉｚｅがメッセージの最大サイズを示す。

図５Ｃの実施形態では、パラメータ５−３ａ＝ａｃｔｕａｌ−ｓｉｚｅにより、ページモードメッセージであることが示されている。このパラメータの値が０以外の場合にはメッセージがページモードメッセージであることを暗黙的に示し、０の場合はページモードメッセージでないことを暗黙的に示す。この実施形態では、ｍラインの情報が、ＭＳＲＰを使用すべきであることを示しており、パラメータａ＝ｍａｘ−ｓｉｚｅがメッセージの最大サイズを示す。

図５Ｄの実施形態では、新規のページモードインジケータ５−１（ｍ＝ｍｅｓｓａｇｅ ９ ｍｓｒｐ ｐａｇｅ−ｍｏｄｅ）を含むｍラインにより、ページモードメッセージであることが示されている。この実施形態では、パラメータａ＝ｍａｘ−ｓｉｚｅがメッセージの最大サイズを示しており、追加のａ−パラメータは必要ない。

図６のシグナリングチャートには、エンドポイント間のシグナリングだけが示されているが、１つ又はそれ以上の仲介装置を含んでもよい。図６は、受信側、より正確には受信側のユーザ端末内の対応するクライアントがメッセージを受け入れるときのシグナリングを示している。図６は、アリスがボブにメッセージを送信しようとするときに開始される。アリスのユーザ端末ＵＴ１（より正確にはＵＴ１内の対応するクライアント）は、ポイント６−１でセッションモードメカニズムを用いてページモードメッセージを送信しなければならないことを認識する（ポイント６−１については図２において上記で詳細に説明されている）。従って、ＵＴ１は、セッション招待メッセージ６−２をページモードインジケーションＰＭＩと共にボブのユーザ端末ＵＴ２に送信する。メッセージ６−２は、図５Ａから５Ｄに示されているメッセージの１つであることが望ましい。メッセージ６−２の受信に応答して、ＵＴ２は、ポイント６−３でこのメッセージがページモードメッセージのためのセッションモード招待であることを検出して、メッセージ６−４を送信することでこの招待を受け入れる。ＵＴ１はメッセージ６−５を送信することでこの受け入れを確認応答し、次いでＵＴ１は、ページモードメッセージの実際の内容をセッションモードメッセージ６−６で送信する。この内容の受信に応答して、ＵＴ２は、ボブが後でその内容を表示することができるようにポイント６−７でこれらを格納する。ＵＴ２はまた、上記図３及び４で上述されたように、ボブに通知することもできる。内容の受信に応答して、ＵＴ２はまた、メッセージ６−８でセッションモードの確認応答を送信することで受信を確認応答する。図６に示される実施形態では、送信ユーザ端末ＵＴ１は、この確認応答に応答してメッセージ６−９をＵＴ２に送信することでセッションを終了するように構成されており、次いで、ＵＴ２が、メッセージ６−１０を送信し、終了を確認応答する。

図７のシグナリングチャートには、受信エンドポイントの関連のインスタントメッセージングサーバを介したエンドポイント間のシグナリングが示されているが、１つ又はそれ以上の仲介装置を含んでもよい。図７は、受信側、より正確には受信側のユーザ端末内の対応するクライアントがメッセージを受け入れないが、後で取り出すためにメッセージを格納するようにネットワークに要求するときのシグナリングを示している。図７は、アリスがボブにメッセージを送信しようとするときに開始される。アリスのユーザ端末ＵＴ１（より正確にはＵＴ１内の対応するクライアント）は、ポイント７−１でセッションモードメカニズムを用いてページモードメッセージを送信しなければならないことを認識する（ポイント７−１については図２に関連して上記で詳細に説明されている）。従って、ＵＴ１は、セッション招待メッセージ７−２をページモードインジケーションＰＭＩと共にボブのユーザ端末ＵＴ２にサーバを介して送信する。メッセージ７−２は、図５Ａから５Ｄに示されているメッセージの１つであることが望ましい。メッセージ７−２の受信に応答して、ＵＴ２は、ポイント７−３でこのメッセージがページモードメッセージのためのセッションモード招待であることを検出する。何らかの理由で、ＵＴ２はページモードメッセージを受け入れないが、リダイレクトメッセージ７−４をサーバに送信する。リダイレクトメッセージの１つの実施例は、メッセージを処理すべき方法に関する情報を含むことができるＳＩＰ ３０２「Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ（一時的に移動）」メッセージである。しかしながら、どのように及びどのプロトコルを用いてリダイレクトが実行され、必要に応じて追加の指示／情報が与えられるかは、本発明には無関係である。他の実施例は、ＳＩＰ ＰＵＢＬＩＳＨ、ＳＩＰ ＯＰＴＩＯＮＳ、ＳＩＰ ＲＥＧＩＳＴＥＲ内の着呼機能などのＳＩＰプロトコルを用いた、又はＸＣＡＰ（拡張マークアップ言語設定アクセスプロトコル）による個別のトランザクションの利用を含む。ＵＴ２はまた、図３及び４に関連して上述したように、メッセージについてボブに通知することもできる。

この実施例では、サーバ、より正確にはバックトゥバックユーザーエージェントは、代替サービスを提供することを許容し、従って、サーバは、自己をセッションのエンドポイントであるとみなし、メッセージ７−５を送信することで最初の招待を受け入れる。ＵＴ１は、メッセージ７−６をサーバに送信することでこの受け入れを確認応答し、次いで、ページモードメッセージの実際の内容をセッションモードメッセージ７−７でサーバに送信する。この内容の受信に応答して、サーバは、ボブが後でその内容を表示することができるようにポイント７−８でこれらを格納する。この内容の受信に応答して、サーバはまた、メッセージ７−９でセッションモードの確認応答を送信することで受信を確認応答する。図７に示される実施形態では、送信ユーザ端末ＵＴ１は、この確認応答に応答してメッセージ７−１０をサーバに送信することでセッションを終了するように構成されており、次いでサーバが、メッセージ７−１１を送信して終了を確認応答する。その後、ボブは、メッセージの内容を後で表示することができるが、この表示の実装は本発明には無関係であり、従って、ここでは詳細には議論しない。

図８のシグナリングチャートには、図７のように、受信エンドポイントの関連のインスタントメッセージングサーバを介したエンドポイント間のシグナリングが示されているが、１つ又はそれ以上の仲介装置を含んでもよい。図８は、受信側、より正確には受信側のユーザ端末内の対応するクライアントがメッセージを受け入れないが、後で取り出すためにメッセージを保存するようにネットワーク内のゲートウェイＧＷに要求するときのシグナリングを示している。図８は、アリスがボブにメッセージを送信しようとするときに開始される。アリスのユーザ端末ＵＴ１（より正確にはＵＴ１内の対応するクライアント）は、ポイント８−１でセッションモードメカニズムを用いてページモードメッセージを送信しなければならないことを認識する（ポイント８−１については図２に関連して上記で詳細に説明されている）。従って、ＵＴ１は、セッション招待メッセージ８−２をページモードインジケーションＰＭＩと共にボブのユーザ端末ＵＴ２にサーバを介して送信する。メッセージ８−２は、図５Ａから５Ｄに示されているメッセージの１つであることが望ましい。メッセージ８−２の受信に応答して、ＵＴ２は、ポイント８−３でこのメッセージがページモードメッセージのためのセッションモード招待であることを検出する。何らかの理由で、ＵＴ２はページモードメッセージを受け入れないが、リダイレクトメッセージ８−４をサーバに送信し、このリダイレクトメッセージはメッセージをゲートウェイＧＷに転送すべきであることを示す（リダイレクトメッセージについては図７に関連して上記で説明された）。ＵＴ２はまた、図３及び４に関連して上述したように、メッセージについてボブに通知することもできる。

この実施例では、サーバ、より正確にはバックトゥバックユーザーエージェントが、メッセージ８−４で示されるＧＷのＵＲＩ（統一資源位置識別子）への新規の要求を生成して、この要求をメッセージ８−５で送信する。この要求は、ページモードインジケーションを含まないセッションモード招待であることが望ましい。ＧＷは、メッセージ８−６を送信することで最初の招待を受け入れる。ＵＴ１は、メッセージ８−７をＧＷに送信することでこの受け入れを確認応答し、次いでページモードメッセージの実際の内容をセッションモードメッセージ８−８でＧＷに送信する。この内容の受信に応答して、ＧＷは、ボブが後でその内容を表示することができるようにポイント８−９でこれらを格納する。この内容の受信に応答して、ＧＷはまた、メッセージ８−１０でセッションモードの確認応答を送信することで受信を確認応答する。図８に関連して示される実施形態では、送信ユーザ端末ＵＴ１は、この確認応答に応答してメッセージ８−１１をＧＷに送信することでセッションを終了するように構成されており、次いでＧＷが、メッセージ８−１２を送信して終了を確認応答する。次にボブは、メッセージの内容を後で表示することができるが、この表示の実装は本発明には無関係であり、従って、ここでは詳細には議論しない。

図９は、本発明の別の実施形態によるシグナリングを示しており、この実施形態では、インスタントメッセージングサーバもインジケーションを検出するように構成される。インスタントメッセージングサーバは、個別のサーバか、或いは１つ又はそれ以上の他の構成要素を含むネットワークノード内のサーバ構成要素とすることができる。図９に示される実施例では、受信側（ＵＴ２）が到達可能でないか、或いは受信側のページモードメッセージがこの例ではサーバ内に位置する受信側のネットワーク受信箱内に格納されることになる設定を有することを前提とする。これは、ネットワーク構成とすることもできる。図９のシグナリングチャートには、送信エンドポイントＵＴ１と受信エンドポイントの関連のインスタントメッセージングサーバとの間のシグナリングが示されているが、１つ又はそれ以上の仲介装置を含んでもよい。図９は、アリスがボブにメッセージを送信しようとするときに開始される。アリスのユーザ端末ＵＴ１（より正確にはＵＴ１内の対応するクライアント）は、ポイント９−１でセッションモードメカニズムを用いてページモードメッセージを送信しなければならないことを認識する（ポイント９−１については図２に関連して上記で詳細に説明している）。従って、ＵＴ１は、セッション招待メッセージ９−２をページモードインジケーションＰＭＩと共にボブのユーザ端末ＵＴ２にサーバを介して送信する。メッセージ９−２は、図５Ａから５Ｄに示されているメッセージの１つであることが望ましい。メッセージ９−２の受信に応答して、サーバ、より正確にはバックトゥバックユーザーエージェントが、ポイント９−３で、このメッセージがページモードメッセージのためのセッションモード招待であることを検出し、従って、ボブすなわちＵＴ２のページモードメッセージに関する構成をチェックする。構成は、ページモードメッセージは後で取り出すために格納されるべきであることを示しているので、サーバは自己をセッションのエンドポイントであるとみなし、メッセージ９−４を送信することで招待を受け入れる。ＵＴ１は、メッセージ９−５をサーバに送信することでこの受け入れを確認応答し、次いでページモードメッセージの実際の内容をセッションモードメッセージ９−６でサーバに送信する。この内容の受信に応答して、サーバは、ボブが後でその内容を表示することができるようにポイント９−７でこれらを格納する。本発明の別の実施形態では、メッセージは、他のネットワークノード又はリモートデータベースに格納する、或いはゲートウェイに転送することができる。内容の受信に応答して、サーバはまた、メッセージ９−８でセッションモードの確認応答を送信することで受信を確認応答する。図９に関連して示される実施形態では、送信ユーザ端末ＵＴ１は、この確認応答に応答してメッセージ９−９をサーバに送信することでセッションを終了するように構成されており、次いでサーバが、メッセージ９−１０を送信して終了を確認応答する。次にボブは、メッセージの内容を後で表示することができるが、この表示の実装は本発明には無関係であり、従って、ここでは詳細には議論しない。

本発明の別の実施形態では、受信側のインスタントメッセージングサーバが、セッション要求を転送するか否かを決定するように、或いはメッセージサイズ、受信側の端末機能及び／又はネットワーク負荷に基づいて自己をエンドポイントであるとみなすように構成される。

図９に基づく別の実施形態では、セッションモードメカニズムを用いて送信されるページモードメッセージはネットワーク受信箱に格納されてユーザに通知されるだけであるが、ページモードメカニズムを用いて送信されるページモードメッセージはユーザに転送されるような構成をユーザが有することができる。

図２、３、４、６、７、８、及び９に示されるステップ、ポイント、及びシグナリングメッセージは、絶対的な時系列順にはなっておらず、ステップ／ポイントの一部は、同時に又は所与の順序とは異なる順序で実行することができる。ステップ／ポイント間又はステップ／ポイント内で他の機能を実行することもできる。ステップ／ポイントの幾つか又はステップ／ポイントの一部分を省くこともできる。シグナリングメッセージは例示的なものにすぎず、同じ情報の送信において幾つかの別個のメッセージを含むことさえできる。更に、メッセージは他の情報を含むこともできる。メッセージ及びステップ／ポイントは、自由に組み合わせることも、幾つかの部分に分けることもできる。更に、使用するプロトコルと同様に、メッセージの名称、種類、及び／又は内容は、上述のものと異なることも可能である。

上記では、通信、すなわちファイル送信及び呼び出しが１対１の通信であることを前提として本発明を開示したが、当業者であれば、通信は１対多の通信とすることもできることは明らかである。
上記に提示した実施形態及びその一部分を組み合わせて本発明の好ましい実施形態を生み出すことができる。

本発明の機能性を実装するユーザ端末、これに相当する他のデバイス及び／又はサーバ、或いは対応するサーバ構成要素は、従来技術の手段だけでなく、上述の方法でページモードメッセージを送信及び／又は受信するための手段も備える。現行のネットワークノード及びユーザ端末は、本発明に従う機能で利用することのできるプロセッサ及びメモリを備える。本発明の実装に必要とされる全ての修正及び構成は、追加又は更新されたソフトウェアルーチンとして実装することのできるルーチン、特定用途向け回路（ＡＳＩＣ）、及び／又はプログラム可能回路として実行することができる。

当業者であれば、技術の進展に伴って本発明の概念を様々な方法で実装することができることは明らかであろう。本発明及びその実施形態は、上述の実施例に限定されるものではないが、請求項の範囲内で変えることができる。

６−１ セッションモードのページモードメッセージ
６−３ ページモードを検出する
６−７ 格納する

Claims (58)

1. ページモードメッセージを送信する方法であって、
   装置によって、セッションモードメッセージメカニズムを用いて、セッションモードが前記ページモードメッセージ用のものであることを示すインジケーションと共に前記ページモードメッセージを送信する段階と、
   前記ページモードメッセージを伝送するためのセッションをメッセージセッションリレープロトコルによって確立する段階と、
   を含むことを特徴とする方法。
2. 前記装置は、予め設定された制限を越える前記ページモードメッセージのサイズに応答して、前記ページモードメッセージを送信することを特徴とする請求項１に記載のユーザ端末。
3. セッション開始プロトコルを用いて前記セッションを生成する段階と、
   を更に含む、
   ことを特徴とする請求項１に記載の方法。
4. 前記装置によって、招待メッセージを送信する段階であって、前記メッセージをページモードメッセージとして示す前記インジケーションは前記招待メッセージのヘッダに挿入される、前記送信する段階と、
   を更に含む、
   ことを特徴とする請求項３に記載の方法。
5. 前記招待メッセージは、オファーを伴う要求メッセージである
   ことを特徴とする請求項４に記載の方法。
6. 前記オファーは、セッション記述プロトコルオファーであることを特徴とする請求項５に記載の方法。
7. 前記招待メッセージに対する応答を受信する段階であって、前記応答は２００「ＯＫ」である前記受信する段階と、
   を更に含む、
   ことを特徴とする請求項４に記載の方法。
8. 前記応答はアンサーであることを特徴とする請求項７に記載の方法。
9. 前記アンサーはセッション記述プロトコルアンサーであることを特徴とする請求項８に記載の方法。
10. 前記装置によって、セッションモードメッセージの前記ページモードメッセージの内容を送信する段階と、
    を更に含む、
    ことを特徴とする請求項１に記載の方法。
11. 前記セッションをノン・チャット・セッションとして確立する段階と、
    を更に含む、
    ことを特徴とする請求項１に記載の方法。
12. 前記セッションは、前記メッセージの配信の完了時に解放されることを特徴とする請求項１に記載の方法。
13. 前記セッションを終了させるためにＳＩＰ ＢＹＥ要求を送信する段階と、
    を更に含む、
    ことを特徴とする請求項１２に記載の方法。
14. 前記ＳＩＰ ＢＹＥに対する応答の受信時に前記セッションを解放する段階と、
    を更に含む、
    ことを特徴とする請求項１３に記載の方法。
15. 少なくとも１つのプロセッサと、
    １つ以上のプログラムのためのコンピュータプログラムコードを含む少なくとも１つのメモリと、を備え、
    前記少なくとも１つのプロセッサ、前記少なくとも１つのメモリ、及び前記コンピュータプログラムコードが、
    セッションモードメッセージメカニズムを用いて、セッションモードが前記ページモードメッセージ用のものであることを示すインジケーションと共に前記ページモードメッセージを送信し、
    前記ページモードメッセージを伝送するためのセッションをメッセージセッションリレープロトコルによって確立する、
    ように装置に行わせるように構成されている、
    ことを特徴とする装置。
16. 前記装置は、予め設定された制限を越える前記ページモードメッセージのサイズに応答して、前記ページモードメッセージを送信することを特徴とする請求項１５に記載の装置。
17. セッション開始プロトコルを用いて前記セッションを生成することを特徴とする請求項１５に記載の装置。
18. 招待メッセージを送信することを更に含み、前記メッセージをページモードメッセージとして示す前記インジケーションは前記招待メッセージのヘッダに挿入される
    ことを特徴とする請求項１７に記載の装置。
19. 前記招待メッセージは、オファーを伴う要求メッセージであることを特徴とする請求項１８に記載の装置。
20. 前記オファーは、セッション記述プロトコルオファーであることを特徴とする請求項１９に記載の装置。
21. 前記招待メッセージに対する応答を受信することを更に含み、前記応答は２００「ＯＫ」である前記受信する
    ことを特徴とする請求項１８に記載の装置。
22. 前記応答はアンサーであることを特徴とする請求項２１に記載の装置。
23. 前記アンサーはセッション記述プロトコルアンサーであることを特徴とする請求項２２に記載の装置。
24. セッションモードメッセージの前記ページモードメッセージの内容を送信することを更に含む、
    ことを特徴とする請求項１５に記載の装置。
25. 前記セッションをノン・チャット・セッションとして確立することを更に含む、
    ことを特徴とする請求項１７に記載の装置。
26. 前記セッションは、前記メッセージの配信の完了時に解放されることを特徴とする請求項１５に記載の装置。
27. 前記セッションを終了させるためにＳＩＰ ＢＹＥ要求を送信することを更に含む、
    ことを特徴とする請求項２６に記載の装置。
28. 前記ＳＩＰ ＢＹＥメッセージに対する応答の受信時に前記セッションを解放することを更に含む、
    ことを特徴とする請求項２７に記載の装置。
29. ページモードメッセージを受信する方法であって、
    装置によって、セッションモード要求メッセージを受信する段階と、
    セッションモードが前記ページモードメッセージ用のものであることを示すインジケーションを含む前記セッションモード要求メッセージを検証する段階と、
    前記ページモードメッセージを受信するためにセッションを確立するか、又は、前記要求を拒否する段階と、
    を含むことを特徴とする方法。
30. 前記ページモードメッセージは大きいサイズのメッセージであることを特徴とする請求項２９に記載の方法。
31. 十分でないリソースに起因して前記要求を拒否する段階を更に含む、
    ことを特徴とする請求項２９に記載の方法。
32. 前記要求に応答する応答メッセージを送信する段階を更に含む、
    ことを特徴とする請求項２９に記載の方法。
33. 前記応答メッセージは２００「ＯＫ」であることを特徴とする請求項３２に記載の方法。
34. 前記応答はセッション記述プロトコルアンサーであることを特徴とする請求項３２に記載の方法。
35. 前記セッションモード要求メッセージは招待メッセージであることを特徴とする請求項２９に記載の方法。
36. セッション記述プロトコルオファーを受信する段階を更に含む、
    ことを特徴とする請求項３５に記載の方法。
37. 前記セッション中に前記ページモードメッセージの内容を受信する段階を更に含む、
    ことを特徴とする請求項２９に記載の方法。
38. 前記内容はメッセージのヘッダに挿入されることを特徴とする請求項３７に記載の方法。
39. 前記メッセージはメッセージセッションリレープロトコルメッセージであることを特徴とする請求項３８に記載の方法。
40. 前記メッセージセッションリレープロトコルメッセージを受信する応答メッセージ確認を送信する段階を更に含み、前記応答メッセージは２００ ＯＫメッセージであることを特徴とする請求項３９に記載の方法。
41. ノン・チャット・セッションを確立する段階を更に含む、
    ことを特徴とする請求項２９に記載の方法。
42. 解放要求メッセージの受信時に前記セッションを解放する段階を更に含む、
    ことを特徴とする請求項２９に記載の方法。
43. 前記セッションを解放するために２００ ＯＫメッセージを送信する段階を更に含む、
    ことを特徴とする請求項４２に記載の方法。
44. 少なくとも１つのプロセッサと、
    １つ以上のプログラムのためのコンピュータプログラムコードを含む少なくとも１つのメモリと、を備え、
    前記少なくとも１つのプロセッサ、前記少なくとも１つのメモリ、及び前記コンピュータプログラムコードが、少なくとも、
    装置によって、セッションモード要求メッセージを受信し、
    セッションモードが前記ページモードメッセージ用のものであることを示すインジケーションを含む前記セッションモード要求メッセージを検証し、
    前記ページモードメッセージを受信するためにセッションを確立し、又は、前記要求を拒否する、
    ように前記装置に行わせるように構成されている、
    ことを特徴とする装置。
45. 前記ページモードメッセージは大きいサイズのメッセージであることを特徴とする請求項４４に記載の装置。
46. 十分でないリソースに起因して前記要求を拒否することを更に含む、
    ことを特徴とする請求項４４に記載の装置。
47. 前記要求に応答する応答メッセージを送信することを更に含む、
    ことを特徴とする請求項４４に記載の装置。
48. 前記応答メッセージは２００「ＯＫ」であることを特徴とする請求項４７に記載の装置。
49. 前記応答はセッション記述プロトコルアンサーであることを特徴とする請求項４７に記載の装置。
50. 前記セッションモード要求メッセージは招待メッセージであることを特徴とする請求項４４に記載の装置。
51. セッション記述プロトコルオファーを受信することを更に含む、
    ことを特徴とする請求項５０に記載の装置。
52. 前記セッション中に前記ページモードメッセージの内容を受信することを更に含む、
    ことを特徴とする請求項４４に記載の装置。
53. 前記内容はメッセージのヘッダに挿入されることを特徴とする請求項５２に記載の装置。
54. 前記メッセージはメッセージセッションリレープロトコルメッセージであることを特徴とする請求項５３に記載の装置。
55. 前記メッセージを受信する応答確認を送信することを更に含み、前記応答メッセージは２００ ＯＫメッセージであることを更に含む、
    ことを特徴とする請求項５３に記載の装置。
56. ノン・チャット・セッションを確立することを更に含む、
    ことを特徴とする請求項４４に記載の装置。
57. 解放要求メッセージの受信時に前記セッションを解放することを更に含む、
    ことを特徴とする請求項４４に記載の装置。
58. ２００ ＯＫメッセージを送信し、前記セッションを解放することを更に含む、
    ことを特徴とする請求項５７に記載の装置。

Images