ページモードメッセージング
【課題】ワンショットメッセージングとも呼ばれるページモードメッセージングに関する方法を提供する。
【解決手段】ページモードメッセージングを提供する方法は、セッションモードメッセージングメカニズムを用いて、セッションモードがページタイプメッセージ用のものであることを示すインジケーションと共にメッセージを送信することである。このメッセージがセッションモードで受信されても、受信側はインジケーションに応答して、メッセージをページモードメッセージとして扱う。
【解決手段】ページモードメッセージングを提供する方法は、セッションモードメッセージングメカニズムを用いて、セッションモードがページタイプメッセージ用のものであることを示すインジケーションと共にメッセージを送信することである。このメッセージがセッションモードで受信されても、受信側はインジケーションに応答して、メッセージをページモードメッセージとして扱う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メッセージングに関し、より詳細には、ワンショットメッセージングとも呼ばれるページモードメッセージングに関する。
【背景技術】
【０００２】
通信技術、特にＩＰベースの通信技術及びエンドユーザ端末の発展により、多目的通信の実現性及び様々なサービスの導入が可能になってきた。通信システムに垂直的には統合されていないがマルチメディアアーキテクチャを構築するためのツールであるＳＩＰ（セッション開始プロトコル）により提供されるプリミティブを用いて、ますます頻繁にサービスが実施されている。より正確には、ＳＩＰとは、１つ又はそれ以上の当事者とのセッションを生成、変更、及び終了するためのＩＥＴＦ定義のアプリケーション層制御（シグナリング）プロトコルである。これらのセッションには、例えばインターネット電話、マルチメディア配信、マルチメディア会議、及びＰｏＣ（プッシュツートーク・オーバーセルラー）セッションが含まれる。メッセージングサービスに関しては、プレゼンス及びインスタントメッセージングサービスを提供するためのＳＩＰ及びＳＩＰの既存の実装を用いたＳＩＭＰＬＥ（インスタントメッセージングとプレゼンスを実現するためのＳＩＰ拡張：ＳＩＰ ｆｏｒ Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｌｅｖｅｒａｇｉｎｇ Ｅｘｔｅｎｓｉｏｎｓ）がＩＥＴＦで定義されている。ＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）もまた、ＳＩＰ／ＳＩＭＰＬＥプロトコルに基づくＩＭ（インスタントメッセージング）イネーブラを定義している。ＳＩＭＰＬＥは、インスタントメッセージ交換の２つのモード、すなわちページモード及びセッションモードを定義する。ページモードは、ＳＩＰ ＭＥＳＳＡＧＥ方法を使用し、これによりページモードのインスタントメッセージが送信され、プロトコルレベルでは、後続のインスタントメッセージは前のインスタントメッセージに関連しない。各即時メッセージは、たとえ前のメッセージに対する応答であっても、独立したトランザクションとみなされる。従って、ＳＩＰ ＭＥＳＳＡＧＥ方法は、従来の電子メール又はショートメッセージサービスに類似する。セッションモードは、シグナリング及びセッション確立にＳＩＰを使用し、セッションが確立された後の一連のインスタントメッセージの伝送には、ＭＳＲＰ（メッセージセッションリレープロトコル）を使用する。以下では、この組み合わせを単にＭＳＲＰメカニズムと呼ぶ。すなわち、ＭＳＲＰメカニズムは、セッションモードメッセージングと呼ばれるチャットタイプのメッセージングを提供する。
【０００３】
ユーザが大容量のページモードメッセージを送信したいときに問題が発生する。ＳＩＰ ＭＥＳＳＡＧＥ方法は、ＵＤＰ又はＴＣＰ伝送のいずれかを使用することができる。ＴＣＰは、大容量メッセージにも信頼性の高い伝送方法を提供するが、ＳＩＰ ＭＥＳＳＡＧＥ方法に関しては、ＴＣＰ伝送が常に保証されるとは限らない。大容量メッセージの送信にＵＤＰが使用される場合、ＵＤＰ最大サイズよりも大きいパケットは分割されて、受信側に正しい順序で到着しない可能性がある。更に、ＴＣＰを保証することができたとしても、輻輳制御に関する別の問題が残る。ＳＩＰ ＭＥＳＳＡＧＥ方法は、ＳＩＰセッション制御シグナリングの一部であるので、メッセージは、ＳＩＰシグナリングによって使用されるのと全く同じリソースを用いて送受信される。ユーザ端末に関して、これは、ユーザ端末において大容量メッセージが送受信される間は、実際のＳＩＰシグナリングがブロックされる可能性があることを意味する。ＳＩＰシグナリングのための上述のリソースは、例えば、汎用のＰＤＰ（パケットデータプロトコル）コンテキスト、或いはＧＥＲＡＮ（ＧＳＭ／ＥＤＧＥ無線アクセスネットワーク）及び／又はＵＴＲＡＮ（ＵＭＴＳ地上無線アクセスネットワーク）システムの場合は専用シグナリングのＰＤＰコンテキストとすることができる。他のシステムでは、リソースは例えば、シグナリング目的のための予約及び／又は専用の帯域幅とすることができる。ＳＩＰシグナリングがブロックされることに加え、ＳＩＰプロキシの負荷に関する更なる問題が生じる可能性がある。ページモードメッセージは通常、ＳＩＰ ＭＥＳＳＡＧＥ方法を使用するので、ＳＩＰ ＭＥＳＳＡＧＥ方法を用いる全てのメッセージがＳＩＰプロキシを介して送信される。従って、ＳＩＰプロキシを介して送信される大きいサイズのページモードメッセージは、ＳＩＰプロキシのパフォーマンスを著しく低下させ、事実上、全てのＳＩＰシグナリングのブロックとＳＩＰネットワークの全体のパフォーマンスの低下という両方の結果をもたらす可能性がある。従って、場合によっては、大きいサイズのメッセージにＳＩＰ ＭＥＳＳＡＧＥ方法を使用するのは適切ではない。
【０００４】
１つの解決策としては、メッセージのサイズがある制限を超える場合には、ＳＩＰ ＭＥＳＳＡＧＥ方法の代わりにＭＳＲＰメカニズムを使用することである。しかしながら、ＭＳＲＰメカニズムは、セッションモードメッセージングサービスのためのものであり、ページモードメッセージングを目的としていない。更に、受信するページモードメッセージは、保留されてメッセージ受信箱に格納され、そこからユーザが都合の良いときにそれらのメッセージを読むことができるが、セッションモードメッセージングの場合は、受信メッセージがユーザ端末により開封されてユーザに示され、対話を促す。従って、受信側から見ると、ＭＳＲＰメカニズムの使用時にはページモードメッセージを受信することができないことになる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、上記の問題を克服するための方法及び該方法を実装するための装置を提供することである。本発明の目的は、独立クレームに記載される内容によって特徴付けられる方法、ユーザ端末、及びサーバにより達成される。本発明の好ましい実施形態は、従属クレームにおいて開示される。
【課題を解決するための手段】
【０００６】
本発明は、問題を認識して、セッションモード（チャットタイプ）メッセージングメカニズムを用いて送信されるメッセージがページモードメッセージであるか否かを示し、更に該メッセージがページモードメッセージであることに応答して、ページモードメカニズムを用いて又はこのようなページモードメッセージに関して定義された特定の指示に従ってメッセージが受信されたかのように動作することによりこの問題を解決することに基づいている。セッションモードに関して、一連のメッセージ交換を目的とするＭＳＲＰなどのプロトコルが使用されることを意味する。ページモードに関しては、プロトコルレベルで各メッセージが独立したトランザクションであること、すなわち、後続のインスタントメッセージはプロトコルレベルでは前のインスタントメッセージに関連しないことを意味する。
【０００７】
本発明の利点は、インジケーションを用いることにより、ページモードメッセージがセッションモードメッセージとして送信されたときでもページモードメッセージとして受信することができる点である。別の利点は、大容量メッセージに起因するＳＩＰシグナリングのブロックを回避することができる点である。
【図面の簡単な説明】
【０００８】
【図１】簡略化したシステムアーキテクチャを示す図である。
【図２】本発明の実施形態によるユーザ端末の送信モードにおける機能性を示すフローチャートである。
【図３】本発明の実施形態によるユーザ端末の受信モードにおける機能性を示すフローチャートである。
【図４】本発明の実施形態によるユーザ端末の受信モードにおける機能性を示すフローチャートである。
【図５Ａ】本発明の実施形態によるＳＩＰ ＩＮＶＩＴＥメッセージの実施例を示す図である。
【図５Ｂ】本発明の実施形態によるＳＩＰ ＩＮＶＩＴＥメッセージの実施例を示す図である。
【図５Ｃ】本発明の実施形態によるＳＩＰ ＩＮＶＩＴＥメッセージの実施例を示す図である。
【図５Ｄ】本発明の実施形態によるＳＩＰ ＩＮＶＩＴＥメッセージの実施例を示す図である。
【図６】本発明の実施形態によるシグナリングを示す図である。
【図７】本発明の実施形態によるシグナリングを示す図である。
【図８】本発明の実施形態によるシグナリングを示す図である。
【図９】本発明の実施形態によるシグナリングを示す図である。
【発明を実施するための形態】
【０００９】
以下において、添付図面を参照しながら好ましい実施形態を用いて本発明をより詳細に説明する。
以下の実施形態は例示的なものである。本明細書では、複数の箇所で「ある実施形態」、「１つの実施形態」又は「一部の実施形態」への言及をする場合があるが、このような各参照が同じ実施形態を指すこと、及びその特徴が単一の実施形態だけに当てはまることを必ずしも意味する訳ではない。異なる実施形態の単一の特徴を組み合わせて別の実施形態を提供することもできる。
【００１０】
本発明は、あらゆるユーザ端末、サーバ、及び／又はユーザ端末によりアクセス可能であり、且つメッセージングサービス、すなわちほぼリアルタイムでのエンティティ間の又はメールボックス内へのメッセージフォーマットのデータ送信を可能にするあらゆる通信システム又は異なる通信システムのあらゆる組み合わせに対して適用可能である。メッセージフォーマットに対してもデータ型に対しても制限はない。データは、テキスト、音声、ビデオクリップ、マルチメディア、その他とすることができる。通信システムは、固定通信システム又は無線通信システム、或いは固定ネットワークと無線ネットワークの両方を利用する通信システムとすることができる。特に無線通信においては、使用されるプロトコル、通信システム及び端末の仕様は急速に進歩している。このような進歩により、本発明に追加の変更が必要となる可能性がある。従って、全ての用語及び表現は広範に解釈されるべきであり、これらは本発明を限定するものではなく、例証を意図している。
【００１１】
以下では、本発明を適用することのできるシステム環境の実施例として、ＳＩＰ及びＭＳＲＰを利用する極めて簡略化したシステム環境を用いて本発明を説明しており、本発明をこれに限定するものではない。通信システム、及びプロキシなどの中間ノード、並びにＳＩＰ及びＭＳＲＰよりも下位又は上位で使用される他のプロトコル、又は対応するプロトコルは、実際の発明には無関係であることを理解されたい。従って、これらをここでより詳細に議論する必要はない。本発明は第一に、アプリケーション層におけるメッセージ送信に関する。
【００１２】
図１は、通信システム１、２つのユーザ端末２、２’、及びネットワーク３だけを示す極めて簡略化したシステムアーキテクチャである。当業者であれば、システムはまた、他のデバイス、インスタントメッセージングサーバなどのシステムエンティティ、機能、及び構造を含むことは明らかであり、本明細書ではこれらについて詳細に説明する必要はない。
【００１３】
ユーザ端末２、２’は、ユーザが通信システムと直接又はコンピュータシステムを介して対話できる、装置の一部又はデバイスであり、すなわち、ユーザに情報を提示し、ユーザによる情報入力を可能にし、言い換えれば、ユーザ端末とは特定の通信の終端点である。すなわち、ユーザ端末２、２’は、メッセージをサポートし、アクセスネットワーク（図１には示されていない）が存在する場合にはこのようなアクセスネットワークを介してシステムのネットワークと通信することのできるあらゆるノード又はホストとすることができる。ユーザ端末２、２’は、ネットワーク３に無線で又は固定接続を介して接続されたパーソナルコンピュータＰＣなどの非移動装置とすることができる。ユーザ端末２、２’はまた、メッセージングをサポートする無線移動端末、サービスプラットホームとしての役目を果たし且つ異なるサービス関連機能のロード及び実行をサポートするマルチサービス端末、又は（利用可能なアクセスネットワークを介して）ネットワークに接続可能なラップトップＰＣ、（利用可能なアクセスネットワークを介して）ネットワークに接続可能な携帯情報端末ＰＤＡ、その他とすることもできる。
【００１４】
ユーザ端末２は、ユーザがメッセージを生成及び／又は読み出すことのできる少なくとも１つのユーザインタフェース（ＵＩ）２１、１つ又はそれ以上のメッセージングアプリケーション（Ａｐｐｌ）２２、受信するページモードタイプのメッセージを少なくとも一時的に格納するためのメモリ（Ｍｅｍ）２３（又はユーザ端末はメモリにアクセスを有するように構成される）、及び通信情報（メッセージ）を送受信するためのトランシーバ（ＴＲｘ）２４を含む。
【００１５】
メッセージングアプリケーション２２は、本発明に従う機能性を実装するように構成されたソフトウェアアプリケーションとすることができる。機能性は、例えば、対応するメッセージングアプリケーションを更新することによって、又は新規のメッセージングアプリケーションを端末に追加することによって実現することができる。
【００１６】
図２は、本発明の実施形態によるユーザ端末の送信モードにおける機能性を示すフローチャートである。図２の実施例では、ユーザが常にページモードメッセージを同様の方法で生成すること、及びメッセージに対して使用される方法／メカニズムをユーザ端末が選択することを前提とする。
【００１７】
図２は、ユーザがページモードメッセージを生成して、受信側にメッセージを送信するための指示をユーザインタフェースを介して与えるとき（ステップ２０１）に開始される。すなわち、ステップ２０１において、ユーザ端末は「このアドレスにメッセージを送信する」コマンドを受信する。このコマンドに応答してステップ２０２で、ユーザ端末は、メッセージのサイズを求め、ステップ２０３で、そのメッセージサイズが予め定められたサイズ制限よりも大きいか否かをチェックする。予め定められた制限は、例えば、使用するサービスプロトコル、ユーザ、又はオペレータが定義することができ、或いは端末に対して事前構成することができる。予め定められた制限は、トランスポートプロトコルメッセージに適合するサイズに相当するのが望ましい。しかしながら、予め定められた制限の値及び予め定められた制限の設定方法は、本発明に関して重要な意味を持たない。本発明の一部の実施形態では、全てのページモードメッセージをそのサイズに関わらず、ＭＳＲＰメカニズム又はこれに相当するメカニズムを用いて送信することさえ可能である。例えば、オペレータがページモードを使用できないことにより、ユーザ端末は常にセッションモードを使用するように事前設定することができる。
【００１８】
メッセージサイズが制限を超えない場合（ステップ２０３）、ステップ２０４で、ユーザ端末は、ＳＩＰ ＭＥＳＳＡＧＥ方法を用いて内容を送信する。
【００１９】
メッセージサイズが制限を超える場合（ステップ２０３）には、ステップ２０５で、ユーザ端末は、本発明に従って、ＭＳＲＰメカニズムを用いてページモードインジケータと共にメッセージを送信する。実装によっては、ユーザ端末は、ＭＳＲＰにより送信するページモードメッセージにメッセージの実際のサイズに関する情報を追加することができ、又はできない場合もある。実際のメッセージ送信手順については、図６、７、及び８により詳細に示されている。
【００２０】
本発明の一実施形態では、ユーザは、３つのオプション、すなわち小容量ページモードメッセージ（サイズは予め定められた制限以下）、他のページモードメッセージ、及びセッション（チャット）メッセージングの中から選択する必要があり、ユーザが他のページモードメッセージを選択する際には、メッセージの送信時に、ページモードインジケータを用いるセッションモードメッセージングメカニズムが使用される。
【００２１】
図３は、本発明の実施形態によるユーザ端末の受信モードにおける機能性を示すフローチャートである。図３の実施例では、メッセージの実際のサイズに関する情報は送信されないことを前提とする。明瞭化の目的でなされる追加の前提は、ユーザ端末がメッセージを受信することができるようにメッセージ用に十分な空きメモリを有していること、及びユーザ端末がページモードメッセージを受け入れるように構成されていることである。メッセージが空きメモリよりも大きい場合に起こることは本発明とは無関係であり、すなわちこれは、受信側端末の実装次第であり、例えば、十分な空きメモリが存在しない場合には、端末はセッション要求を拒否することができ、或いはセッション要求は受け入れられるが、メモリが満杯になるとセッションを終了する。
【００２２】
ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）の受信（ステップ３０１）に応答して、ステップ３０２でユーザ端末は、ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）がページモードメッセージのためのものであるかどうかをチェックする。ページモードメッセージのためのものである場合には、ステップ３０３で、ユーザ端末がセッションを確立し、ステップ３０４でメッセージを受信し、ステップ３０５でメッセージを格納し、ステップ３０６でセッションを解放する。その後、又はこれと同時に、ステップ３０７でユーザ端末はメッセージを受信したことをユーザに表示する。従って、ユーザは後でメッセージを読むことができる。すなわち、ユーザ端末は、メッセージがＳＩＰ ＭＥＳＳＡＧＥ方法で受信されたかのようにユーザに対して動作する。
【００２３】
ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）がチャットのためのもの（すなわちセッションモードメッセージング用）であり、ページモードメッセージのためのものではない場合（ステップ３０２）、ステップ３０８でユーザ端末はセッションを確立し、ステップ３０９で、セッションが終了するまでダイアログを表示する。
【００２４】
受信ユーザ端末は、全てのページモードメッセージを拒否するように構成することができ、この場合にはセッションが確立されないが、ステップ３０３から３０７までの代わりに拒否が送信される。
【００２５】
受信ユーザ端末は、ページモードメッセージ要求をネットワーク受信箱、別の端末、その他に転送するように構成することができ、この場合にはセッションが確立されないが、ステップ３０３から３０７までの代わりに要求が転送される。このような状況の実施例が図７及び８に示されている。全てのページモードメッセージが転送されていずれかの場所に格納され、ユーザが別の端末でこれらのメッセージを表示する必要がある場合でも、転送を行う端末がページモードメッセージングを提供するとみなされる。
【００２６】
本発明の別の実施形態では、メッセージの受信後にチェックが行われる（すなわち、ステップ３０２がステップ３０４の後に実行され、チェック後の処理はステップ３０５又はステップ３０８のいずれかに進む）。
【００２７】
図４は、本発明の別の実施形態によるユーザ端末の受信モードにおける機能性を示すフローチャートである。図４の実施例では、メッセージの実際のサイズに関する情報が存在することを前提とする。図３に関連する上記のような明瞭にするための追加の前提は、同じ説明を不必要に繰り返すわけではないが、ユーザ端末がメッセージ用に十分な空きメモリを有していること、及びユーザ端末がページモードメッセージを受け入れるように構成されていることである。
【００２８】
ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）の受信（ステップ４０１）に応答して、ステップ４０２でユーザ端末は、ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）がページモードメッセージのためのものかどうかをチェックする。ページモードメッセージのためのものである場合には、ステップ４０３で、ユーザ端末がメッセージのサイズについてユーザに通知する。ユーザがメッセージを受け入れる場合（ステップ４０４）、ステップ４０５でユーザ端末がセッションを確立し、ステップ４０６でメッセージを受信し、ステップ４０７でメッセージを格納する。その結果、ユーザは後でメッセージを読むことができる。次にステップ４０８で、ユーザ端末はセッションを解放する。すなわち、ユーザ端末はメッセージがＳＩＰ ＭＥＳＳＡＧＥ方法で受信されたかのようにユーザに対して動作する。この特定の実施例では、ユーザはメッセージの配信を受け入れることで既にメッセージについて通知されたとみなされるので、ユーザ端末はメッセージの受信についてユーザに通知しない。しかしながら、別の実装では、ユーザデバイスは、ユーザに対してメッセージの受信を通知するようにも構成することができる。
【００２９】
ユーザがメッセージを受け入れない場合（ステップ４０４）、ステップ４０９で、ユーザ端末はセッション確立を拒否する。別の実施形態では、ユーザ端末は、拒否するのではなく図７及び８に示されるようにセッション確立を転送して、メッセージをネットワーク内に格納し、後で取り出すことができるようにすることができる。
【００３０】
ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）がチャットのためのもの（すなわちセッションモードメッセージング用）でありページモードメッセージのためではない場合（ステップ４０２）、ステップ４１０で、ユーザ端末はセッションを確立し、ステップ４１１でセッションが終了するまでダイアログを表示する。
【００３１】
本発明の別の実施形態では、ユーザがメッセージを受け入れるか否かを尋ねる代わりに（すなわちステップ４０３の代わりに）、ユーザ端末は、予め定められたサイズ制限を超えないメッセージを受け入れるように構成される。予め定められたサイズ制限は、例えば、オペレータ、ユーザ端末メーカー、及び／又はユーザが定義することができる。
【００３２】
以下では、図５Ａから８で示される幾つかの実施例においてシグナリングについてより詳細に説明し、ここではＳＤＰ（セッション記述プロトコル）を用いてセッションを開始し、ＭＳＲＰ ｏｖｅｒ ＴＣＰを用いて実際の内容を送信するが、本発明はこれらの実施例に限定されるものではない。以下の実施例に関連してなされる別の前提は、受信ユーザ端末がメッセージを拒否しないことである。必要に応じて、更なる情報はｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｍｅｓｓａｇｅ−ｓｅｓｓｉｏｎｓ−１０．ｔｘｔに見出すことができ、これは参照により本明細書に組み込まれる。しかしながら、どのプロトコルが使用されるかは本発明に関して重要な意味を持たず、上記は例証にすぎない。例えば、ＳＤＰの代わりに他のオファー／アンサーメカニズムプロトコルを使用することができ、ＴＣＰの代わりに、ＳＣＴＰ（Ｓｉｇｎａｌｉｎｇ Ｃｏｍｍｏｎ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などの他の輻輳制御プロトコルを使用することができる。
【００３３】
図５Ａから５Ｄは、セッションモード招待がページモードメッセージのためであることをセッションモードメッセージがどのように示すことができるかについての幾つかの実施例を示している。
【００３４】
図５Ａの実施形態では、新規のページモードインジケータ５−１（ｍ＝ｍｅｓｓａｇｅ ９ ｍｓｒｐ ｐａｇｅ−ｍｏｄｅ）を含むｍライン及びメッセージの実際のサイズを示すパラメータａ＝ｍａｘ−ｓｉｚｅ５−２（ａ＝ｍａｘ−ｓｉｚｅ：ａｃｔｕａｌ ｓｉｚｅ）の組み合わせによりページモードメッセージであることが示されている。
【００３５】
図５Ｂの実施形態では、新規のページモードインジケータ５−１（ｍ＝ｍｅｓｓａｇｅ ９ ｍｓｒｐ ｐａｇｅ−ｍｏｄｅ）を含むｍライン及びメッセージの実際のサイズを示すパラメータ５−３ａ＝ａｃｔｕａｌ−ｓｉｚｅ（ａ＝ａｃｔｕａｌ−ｓｉｚｅ：ａｃｔｕａｌ ｓｉｚｅ）の組み合わせにより、ページモードメッセージであることが示されている。この実施形態では、パラメータａ＝ｍａｘ−ｓｉｚｅがメッセージの最大サイズを示す。
【００３６】
図５Ｃの実施形態では、パラメータ５−３ａ＝ａｃｔｕａｌ−ｓｉｚｅにより、ページモードメッセージであることが示されている。このパラメータの値が０以外の場合にはメッセージがページモードメッセージであることを暗黙的に示し、０の場合はページモードメッセージでないことを暗黙的に示す。この実施形態では、ｍラインの情報が、ＭＳＲＰを使用すべきであることを示しており、パラメータａ＝ｍａｘ−ｓｉｚｅがメッセージの最大サイズを示す。
【００３７】
図５Ｄの実施形態では、新規のページモードインジケータ５−１（ｍ＝ｍｅｓｓａｇｅ ９ ｍｓｒｐ ｐａｇｅ−ｍｏｄｅ）を含むｍラインにより、ページモードメッセージであることが示されている。この実施形態では、パラメータａ＝ｍａｘ−ｓｉｚｅがメッセージの最大サイズを示しており、追加のａ−パラメータは必要ない。
【００３８】
図６のシグナリングチャートには、エンドポイント間のシグナリングだけが示されているが、１つ又はそれ以上の仲介装置を含んでもよい。図６は、受信側、より正確には受信側のユーザ端末内の対応するクライアントがメッセージを受け入れるときのシグナリングを示している。図６は、アリスがボブにメッセージを送信しようとするときに開始される。アリスのユーザ端末ＵＴ１（より正確にはＵＴ１内の対応するクライアント）は、ポイント６−１でセッションモードメカニズムを用いてページモードメッセージを送信しなければならないことを認識する（ポイント６−１については図２において上記で詳細に説明されている）。従って、ＵＴ１は、セッション招待メッセージ６−２をページモードインジケーションＰＭＩと共にボブのユーザ端末ＵＴ２に送信する。メッセージ６−２は、図５Ａから５Ｄに示されているメッセージの１つであることが望ましい。メッセージ６−２の受信に応答して、ＵＴ２は、ポイント６−３でこのメッセージがページモードメッセージのためのセッションモード招待であることを検出して、メッセージ６−４を送信することでこの招待を受け入れる。ＵＴ１はメッセージ６−５を送信することでこの受け入れを確認応答し、次いでＵＴ１は、ページモードメッセージの実際の内容をセッションモードメッセージ６−６で送信する。この内容の受信に応答して、ＵＴ２は、ボブが後でその内容を表示することができるようにポイント６−７でこれらを格納する。ＵＴ２はまた、上記図３及び４で上述されたように、ボブに通知することもできる。内容の受信に応答して、ＵＴ２はまた、メッセージ６−８でセッションモードの確認応答を送信することで受信を確認応答する。図６に示される実施形態では、送信ユーザ端末ＵＴ１は、この確認応答に応答してメッセージ６−９をＵＴ２に送信することでセッションを終了するように構成されており、次いで、ＵＴ２が、メッセージ６−１０を送信し、終了を確認応答する。
【００３９】
図７のシグナリングチャートには、受信エンドポイントの関連のインスタントメッセージングサーバを介したエンドポイント間のシグナリングが示されているが、１つ又はそれ以上の仲介装置を含んでもよい。図７は、受信側、より正確には受信側のユーザ端末内の対応するクライアントがメッセージを受け入れないが、後で取り出すためにメッセージを格納するようにネットワークに要求するときのシグナリングを示している。図７は、アリスがボブにメッセージを送信しようとするときに開始される。アリスのユーザ端末ＵＴ１（より正確にはＵＴ１内の対応するクライアント）は、ポイント７−１でセッションモードメカニズムを用いてページモードメッセージを送信しなければならないことを認識する（ポイント７−１については図２に関連して上記で詳細に説明されている）。従って、ＵＴ１は、セッション招待メッセージ７−２をページモードインジケーションＰＭＩと共にボブのユーザ端末ＵＴ２にサーバを介して送信する。メッセージ７−２は、図５Ａから５Ｄに示されているメッセージの１つであることが望ましい。メッセージ７−２の受信に応答して、ＵＴ２は、ポイント７−３でこのメッセージがページモードメッセージのためのセッションモード招待であることを検出する。何らかの理由で、ＵＴ２はページモードメッセージを受け入れないが、リダイレクトメッセージ７−４をサーバに送信する。リダイレクトメッセージの１つの実施例は、メッセージを処理すべき方法に関する情報を含むことができるＳＩＰ ３０２「Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ（一時的に移動）」メッセージである。しかしながら、どのように及びどのプロトコルを用いてリダイレクトが実行され、必要に応じて追加の指示／情報が与えられるかは、本発明には無関係である。他の実施例は、ＳＩＰ ＰＵＢＬＩＳＨ、ＳＩＰ ＯＰＴＩＯＮＳ、ＳＩＰ ＲＥＧＩＳＴＥＲ内の着呼機能などのＳＩＰプロトコルを用いた、又はＸＣＡＰ（拡張マークアップ言語設定アクセスプロトコル）による個別のトランザクションの利用を含む。ＵＴ２はまた、図３及び４に関連して上述したように、メッセージについてボブに通知することもできる。
【００４０】
この実施例では、サーバ、より正確にはバックトゥバックユーザーエージェントは、代替サービスを提供することを許容し、従って、サーバは、自己をセッションのエンドポイントであるとみなし、メッセージ７−５を送信することで最初の招待を受け入れる。ＵＴ１は、メッセージ７−６をサーバに送信することでこの受け入れを確認応答し、次いで、ページモードメッセージの実際の内容をセッションモードメッセージ７−７でサーバに送信する。この内容の受信に応答して、サーバは、ボブが後でその内容を表示することができるようにポイント７−８でこれらを格納する。この内容の受信に応答して、サーバはまた、メッセージ７−９でセッションモードの確認応答を送信することで受信を確認応答する。図７に示される実施形態では、送信ユーザ端末ＵＴ１は、この確認応答に応答してメッセージ７−１０をサーバに送信することでセッションを終了するように構成されており、次いでサーバが、メッセージ７−１１を送信して終了を確認応答する。その後、ボブは、メッセージの内容を後で表示することができるが、この表示の実装は本発明には無関係であり、従って、ここでは詳細には議論しない。
【００４１】
図８のシグナリングチャートには、図７のように、受信エンドポイントの関連のインスタントメッセージングサーバを介したエンドポイント間のシグナリングが示されているが、１つ又はそれ以上の仲介装置を含んでもよい。図８は、受信側、より正確には受信側のユーザ端末内の対応するクライアントがメッセージを受け入れないが、後で取り出すためにメッセージを保存するようにネットワーク内のゲートウェイＧＷに要求するときのシグナリングを示している。図８は、アリスがボブにメッセージを送信しようとするときに開始される。アリスのユーザ端末ＵＴ１（より正確にはＵＴ１内の対応するクライアント）は、ポイント８−１でセッションモードメカニズムを用いてページモードメッセージを送信しなければならないことを認識する（ポイント８−１については図２に関連して上記で詳細に説明されている）。従って、ＵＴ１は、セッション招待メッセージ８−２をページモードインジケーションＰＭＩと共にボブのユーザ端末ＵＴ２にサーバを介して送信する。メッセージ８−２は、図５Ａから５Ｄに示されているメッセージの１つであることが望ましい。メッセージ８−２の受信に応答して、ＵＴ２は、ポイント８−３でこのメッセージがページモードメッセージのためのセッションモード招待であることを検出する。何らかの理由で、ＵＴ２はページモードメッセージを受け入れないが、リダイレクトメッセージ８−４をサーバに送信し、このリダイレクトメッセージはメッセージをゲートウェイＧＷに転送すべきであることを示す（リダイレクトメッセージについては図７に関連して上記で説明された）。ＵＴ２はまた、図３及び４に関連して上述したように、メッセージについてボブに通知することもできる。
【００４２】
この実施例では、サーバ、より正確にはバックトゥバックユーザーエージェントが、メッセージ８−４で示されるＧＷのＵＲＩ（統一資源位置識別子）への新規の要求を生成して、この要求をメッセージ８−５で送信する。この要求は、ページモードインジケーションを含まないセッションモード招待であることが望ましい。ＧＷは、メッセージ８−６を送信することで最初の招待を受け入れる。ＵＴ１は、メッセージ８−７をＧＷに送信することでこの受け入れを確認応答し、次いでページモードメッセージの実際の内容をセッションモードメッセージ８−８でＧＷに送信する。この内容の受信に応答して、ＧＷは、ボブが後でその内容を表示することができるようにポイント８−９でこれらを格納する。この内容の受信に応答して、ＧＷはまた、メッセージ８−１０でセッションモードの確認応答を送信することで受信を確認応答する。図８に関連して示される実施形態では、送信ユーザ端末ＵＴ１は、この確認応答に応答してメッセージ８−１１をＧＷに送信することでセッションを終了するように構成されており、次いでＧＷが、メッセージ８−１２を送信して終了を確認応答する。次にボブは、メッセージの内容を後で表示することができるが、この表示の実装は本発明には無関係であり、従って、ここでは詳細には議論しない。
【００４３】
図９は、本発明の別の実施形態によるシグナリングを示しており、この実施形態では、インスタントメッセージングサーバもインジケーションを検出するように構成される。インスタントメッセージングサーバは、個別のサーバか、或いは１つ又はそれ以上の他の構成要素を含むネットワークノード内のサーバ構成要素とすることができる。図９に示される実施例では、受信側（ＵＴ２）が到達可能でないか、或いは受信側のページモードメッセージがこの例ではサーバ内に位置する受信側のネットワーク受信箱内に格納されることになる設定を有することを前提とする。これは、ネットワーク構成とすることもできる。図９のシグナリングチャートには、送信エンドポイントＵＴ１と受信エンドポイントの関連のインスタントメッセージングサーバとの間のシグナリングが示されているが、１つ又はそれ以上の仲介装置を含んでもよい。図９は、アリスがボブにメッセージを送信しようとするときに開始される。アリスのユーザ端末ＵＴ１（より正確にはＵＴ１内の対応するクライアント）は、ポイント９−１でセッションモードメカニズムを用いてページモードメッセージを送信しなければならないことを認識する（ポイント９−１については図２に関連して上記で詳細に説明している）。従って、ＵＴ１は、セッション招待メッセージ９−２をページモードインジケーションＰＭＩと共にボブのユーザ端末ＵＴ２にサーバを介して送信する。メッセージ９−２は、図５Ａから５Ｄに示されているメッセージの１つであることが望ましい。メッセージ９−２の受信に応答して、サーバ、より正確にはバックトゥバックユーザーエージェントが、ポイント９−３で、このメッセージがページモードメッセージのためのセッションモード招待であることを検出し、従って、ボブすなわちＵＴ２のページモードメッセージに関する構成をチェックする。構成は、ページモードメッセージは後で取り出すために格納されるべきであることを示しているので、サーバは自己をセッションのエンドポイントであるとみなし、メッセージ９−４を送信することで招待を受け入れる。ＵＴ１は、メッセージ９−５をサーバに送信することでこの受け入れを確認応答し、次いでページモードメッセージの実際の内容をセッションモードメッセージ９−６でサーバに送信する。この内容の受信に応答して、サーバは、ボブが後でその内容を表示することができるようにポイント９−７でこれらを格納する。本発明の別の実施形態では、メッセージは、他のネットワークノード又はリモートデータベースに格納する、或いはゲートウェイに転送することができる。内容の受信に応答して、サーバはまた、メッセージ９−８でセッションモードの確認応答を送信することで受信を確認応答する。図９に関連して示される実施形態では、送信ユーザ端末ＵＴ１は、この確認応答に応答してメッセージ９−９をサーバに送信することでセッションを終了するように構成されており、次いでサーバが、メッセージ９−１０を送信して終了を確認応答する。次にボブは、メッセージの内容を後で表示することができるが、この表示の実装は本発明には無関係であり、従って、ここでは詳細には議論しない。
【００４４】
本発明の別の実施形態では、受信側のインスタントメッセージングサーバが、セッション要求を転送するか否かを決定するように、或いはメッセージサイズ、受信側の端末機能及び／又はネットワーク負荷に基づいて自己をエンドポイントであるとみなすように構成される。
【００４５】
図９に基づく別の実施形態では、セッションモードメカニズムを用いて送信されるページモードメッセージはネットワーク受信箱に格納されてユーザに通知されるだけであるが、ページモードメカニズムを用いて送信されるページモードメッセージはユーザに転送されるような構成をユーザが有することができる。
【００４６】
図２、３、４、６、７、８、及び９に示されるステップ、ポイント、及びシグナリングメッセージは、絶対的な時系列順にはなっておらず、ステップ／ポイントの一部は、同時に又は所与の順序とは異なる順序で実行することができる。ステップ／ポイント間又はステップ／ポイント内で他の機能を実行することもできる。ステップ／ポイントの幾つか又はステップ／ポイントの一部分を省くこともできる。シグナリングメッセージは例示的なものにすぎず、同じ情報の送信において幾つかの別個のメッセージを含むことさえできる。更に、メッセージは他の情報を含むこともできる。メッセージ及びステップ／ポイントは、自由に組み合わせることも、幾つかの部分に分けることもできる。更に、使用するプロトコルと同様に、メッセージの名称、種類、及び／又は内容は、上述のものと異なることも可能である。
【００４７】
上記では、通信、すなわちファイル送信及び呼び出しが１対１の通信であることを前提として本発明を開示したが、当業者であれば、通信は１対多の通信とすることもできることは明らかである。
上記に提示した実施形態及びその一部分を組み合わせて本発明の好ましい実施形態を生み出すことができる。
【００４８】
本発明の機能性を実装するユーザ端末、これに相当する他のデバイス及び／又はサーバ、或いは対応するサーバ構成要素は、従来技術の手段だけでなく、上述の方法でページモードメッセージを送信及び／又は受信するための手段も備える。現行のネットワークノード及びユーザ端末は、本発明に従う機能で利用することのできるプロセッサ及びメモリを備える。本発明の実装に必要とされる全ての修正及び構成は、追加又は更新されたソフトウェアルーチンとして実装することのできるルーチン、特定用途向け回路（ＡＳＩＣ）、及び／又はプログラム可能回路として実行することができる。
【００４９】
当業者であれば、技術の進展に伴って本発明の概念を様々な方法で実装することができることは明らかであろう。本発明及びその実施形態は、上述の実施例に限定されるものではないが、請求項の範囲内で変えることができる。
【符号の説明】
【００５０】
６−１ セッションモードのページモードメッセージ
６−３ ページモードを検出する
６−７ 格納する
【技術分野】
【０００１】
本発明は、メッセージングに関し、より詳細には、ワンショットメッセージングとも呼ばれるページモードメッセージングに関する。
【背景技術】
【０００２】
通信技術、特にＩＰベースの通信技術及びエンドユーザ端末の発展により、多目的通信の実現性及び様々なサービスの導入が可能になってきた。通信システムに垂直的には統合されていないがマルチメディアアーキテクチャを構築するためのツールであるＳＩＰ（セッション開始プロトコル）により提供されるプリミティブを用いて、ますます頻繁にサービスが実施されている。より正確には、ＳＩＰとは、１つ又はそれ以上の当事者とのセッションを生成、変更、及び終了するためのＩＥＴＦ定義のアプリケーション層制御（シグナリング）プロトコルである。これらのセッションには、例えばインターネット電話、マルチメディア配信、マルチメディア会議、及びＰｏＣ（プッシュツートーク・オーバーセルラー）セッションが含まれる。メッセージングサービスに関しては、プレゼンス及びインスタントメッセージングサービスを提供するためのＳＩＰ及びＳＩＰの既存の実装を用いたＳＩＭＰＬＥ（インスタントメッセージングとプレゼンスを実現するためのＳＩＰ拡張：ＳＩＰ ｆｏｒ Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｐｒｅｓｅｎｃｅ Ｌｅｖｅｒａｇｉｎｇ Ｅｘｔｅｎｓｉｏｎｓ）がＩＥＴＦで定義されている。ＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）もまた、ＳＩＰ／ＳＩＭＰＬＥプロトコルに基づくＩＭ（インスタントメッセージング）イネーブラを定義している。ＳＩＭＰＬＥは、インスタントメッセージ交換の２つのモード、すなわちページモード及びセッションモードを定義する。ページモードは、ＳＩＰ ＭＥＳＳＡＧＥ方法を使用し、これによりページモードのインスタントメッセージが送信され、プロトコルレベルでは、後続のインスタントメッセージは前のインスタントメッセージに関連しない。各即時メッセージは、たとえ前のメッセージに対する応答であっても、独立したトランザクションとみなされる。従って、ＳＩＰ ＭＥＳＳＡＧＥ方法は、従来の電子メール又はショートメッセージサービスに類似する。セッションモードは、シグナリング及びセッション確立にＳＩＰを使用し、セッションが確立された後の一連のインスタントメッセージの伝送には、ＭＳＲＰ（メッセージセッションリレープロトコル）を使用する。以下では、この組み合わせを単にＭＳＲＰメカニズムと呼ぶ。すなわち、ＭＳＲＰメカニズムは、セッションモードメッセージングと呼ばれるチャットタイプのメッセージングを提供する。
【０００３】
ユーザが大容量のページモードメッセージを送信したいときに問題が発生する。ＳＩＰ ＭＥＳＳＡＧＥ方法は、ＵＤＰ又はＴＣＰ伝送のいずれかを使用することができる。ＴＣＰは、大容量メッセージにも信頼性の高い伝送方法を提供するが、ＳＩＰ ＭＥＳＳＡＧＥ方法に関しては、ＴＣＰ伝送が常に保証されるとは限らない。大容量メッセージの送信にＵＤＰが使用される場合、ＵＤＰ最大サイズよりも大きいパケットは分割されて、受信側に正しい順序で到着しない可能性がある。更に、ＴＣＰを保証することができたとしても、輻輳制御に関する別の問題が残る。ＳＩＰ ＭＥＳＳＡＧＥ方法は、ＳＩＰセッション制御シグナリングの一部であるので、メッセージは、ＳＩＰシグナリングによって使用されるのと全く同じリソースを用いて送受信される。ユーザ端末に関して、これは、ユーザ端末において大容量メッセージが送受信される間は、実際のＳＩＰシグナリングがブロックされる可能性があることを意味する。ＳＩＰシグナリングのための上述のリソースは、例えば、汎用のＰＤＰ（パケットデータプロトコル）コンテキスト、或いはＧＥＲＡＮ（ＧＳＭ／ＥＤＧＥ無線アクセスネットワーク）及び／又はＵＴＲＡＮ（ＵＭＴＳ地上無線アクセスネットワーク）システムの場合は専用シグナリングのＰＤＰコンテキストとすることができる。他のシステムでは、リソースは例えば、シグナリング目的のための予約及び／又は専用の帯域幅とすることができる。ＳＩＰシグナリングがブロックされることに加え、ＳＩＰプロキシの負荷に関する更なる問題が生じる可能性がある。ページモードメッセージは通常、ＳＩＰ ＭＥＳＳＡＧＥ方法を使用するので、ＳＩＰ ＭＥＳＳＡＧＥ方法を用いる全てのメッセージがＳＩＰプロキシを介して送信される。従って、ＳＩＰプロキシを介して送信される大きいサイズのページモードメッセージは、ＳＩＰプロキシのパフォーマンスを著しく低下させ、事実上、全てのＳＩＰシグナリングのブロックとＳＩＰネットワークの全体のパフォーマンスの低下という両方の結果をもたらす可能性がある。従って、場合によっては、大きいサイズのメッセージにＳＩＰ ＭＥＳＳＡＧＥ方法を使用するのは適切ではない。
【０００４】
１つの解決策としては、メッセージのサイズがある制限を超える場合には、ＳＩＰ ＭＥＳＳＡＧＥ方法の代わりにＭＳＲＰメカニズムを使用することである。しかしながら、ＭＳＲＰメカニズムは、セッションモードメッセージングサービスのためのものであり、ページモードメッセージングを目的としていない。更に、受信するページモードメッセージは、保留されてメッセージ受信箱に格納され、そこからユーザが都合の良いときにそれらのメッセージを読むことができるが、セッションモードメッセージングの場合は、受信メッセージがユーザ端末により開封されてユーザに示され、対話を促す。従って、受信側から見ると、ＭＳＲＰメカニズムの使用時にはページモードメッセージを受信することができないことになる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
本発明の目的は、上記の問題を克服するための方法及び該方法を実装するための装置を提供することである。本発明の目的は、独立クレームに記載される内容によって特徴付けられる方法、ユーザ端末、及びサーバにより達成される。本発明の好ましい実施形態は、従属クレームにおいて開示される。
【課題を解決するための手段】
【０００６】
本発明は、問題を認識して、セッションモード（チャットタイプ）メッセージングメカニズムを用いて送信されるメッセージがページモードメッセージであるか否かを示し、更に該メッセージがページモードメッセージであることに応答して、ページモードメカニズムを用いて又はこのようなページモードメッセージに関して定義された特定の指示に従ってメッセージが受信されたかのように動作することによりこの問題を解決することに基づいている。セッションモードに関して、一連のメッセージ交換を目的とするＭＳＲＰなどのプロトコルが使用されることを意味する。ページモードに関しては、プロトコルレベルで各メッセージが独立したトランザクションであること、すなわち、後続のインスタントメッセージはプロトコルレベルでは前のインスタントメッセージに関連しないことを意味する。
【０００７】
本発明の利点は、インジケーションを用いることにより、ページモードメッセージがセッションモードメッセージとして送信されたときでもページモードメッセージとして受信することができる点である。別の利点は、大容量メッセージに起因するＳＩＰシグナリングのブロックを回避することができる点である。
【図面の簡単な説明】
【０００８】
【図１】簡略化したシステムアーキテクチャを示す図である。
【図２】本発明の実施形態によるユーザ端末の送信モードにおける機能性を示すフローチャートである。
【図３】本発明の実施形態によるユーザ端末の受信モードにおける機能性を示すフローチャートである。
【図４】本発明の実施形態によるユーザ端末の受信モードにおける機能性を示すフローチャートである。
【図５Ａ】本発明の実施形態によるＳＩＰ ＩＮＶＩＴＥメッセージの実施例を示す図である。
【図５Ｂ】本発明の実施形態によるＳＩＰ ＩＮＶＩＴＥメッセージの実施例を示す図である。
【図５Ｃ】本発明の実施形態によるＳＩＰ ＩＮＶＩＴＥメッセージの実施例を示す図である。
【図５Ｄ】本発明の実施形態によるＳＩＰ ＩＮＶＩＴＥメッセージの実施例を示す図である。
【図６】本発明の実施形態によるシグナリングを示す図である。
【図７】本発明の実施形態によるシグナリングを示す図である。
【図８】本発明の実施形態によるシグナリングを示す図である。
【図９】本発明の実施形態によるシグナリングを示す図である。
【発明を実施するための形態】
【０００９】
以下において、添付図面を参照しながら好ましい実施形態を用いて本発明をより詳細に説明する。
以下の実施形態は例示的なものである。本明細書では、複数の箇所で「ある実施形態」、「１つの実施形態」又は「一部の実施形態」への言及をする場合があるが、このような各参照が同じ実施形態を指すこと、及びその特徴が単一の実施形態だけに当てはまることを必ずしも意味する訳ではない。異なる実施形態の単一の特徴を組み合わせて別の実施形態を提供することもできる。
【００１０】
本発明は、あらゆるユーザ端末、サーバ、及び／又はユーザ端末によりアクセス可能であり、且つメッセージングサービス、すなわちほぼリアルタイムでのエンティティ間の又はメールボックス内へのメッセージフォーマットのデータ送信を可能にするあらゆる通信システム又は異なる通信システムのあらゆる組み合わせに対して適用可能である。メッセージフォーマットに対してもデータ型に対しても制限はない。データは、テキスト、音声、ビデオクリップ、マルチメディア、その他とすることができる。通信システムは、固定通信システム又は無線通信システム、或いは固定ネットワークと無線ネットワークの両方を利用する通信システムとすることができる。特に無線通信においては、使用されるプロトコル、通信システム及び端末の仕様は急速に進歩している。このような進歩により、本発明に追加の変更が必要となる可能性がある。従って、全ての用語及び表現は広範に解釈されるべきであり、これらは本発明を限定するものではなく、例証を意図している。
【００１１】
以下では、本発明を適用することのできるシステム環境の実施例として、ＳＩＰ及びＭＳＲＰを利用する極めて簡略化したシステム環境を用いて本発明を説明しており、本発明をこれに限定するものではない。通信システム、及びプロキシなどの中間ノード、並びにＳＩＰ及びＭＳＲＰよりも下位又は上位で使用される他のプロトコル、又は対応するプロトコルは、実際の発明には無関係であることを理解されたい。従って、これらをここでより詳細に議論する必要はない。本発明は第一に、アプリケーション層におけるメッセージ送信に関する。
【００１２】
図１は、通信システム１、２つのユーザ端末２、２’、及びネットワーク３だけを示す極めて簡略化したシステムアーキテクチャである。当業者であれば、システムはまた、他のデバイス、インスタントメッセージングサーバなどのシステムエンティティ、機能、及び構造を含むことは明らかであり、本明細書ではこれらについて詳細に説明する必要はない。
【００１３】
ユーザ端末２、２’は、ユーザが通信システムと直接又はコンピュータシステムを介して対話できる、装置の一部又はデバイスであり、すなわち、ユーザに情報を提示し、ユーザによる情報入力を可能にし、言い換えれば、ユーザ端末とは特定の通信の終端点である。すなわち、ユーザ端末２、２’は、メッセージをサポートし、アクセスネットワーク（図１には示されていない）が存在する場合にはこのようなアクセスネットワークを介してシステムのネットワークと通信することのできるあらゆるノード又はホストとすることができる。ユーザ端末２、２’は、ネットワーク３に無線で又は固定接続を介して接続されたパーソナルコンピュータＰＣなどの非移動装置とすることができる。ユーザ端末２、２’はまた、メッセージングをサポートする無線移動端末、サービスプラットホームとしての役目を果たし且つ異なるサービス関連機能のロード及び実行をサポートするマルチサービス端末、又は（利用可能なアクセスネットワークを介して）ネットワークに接続可能なラップトップＰＣ、（利用可能なアクセスネットワークを介して）ネットワークに接続可能な携帯情報端末ＰＤＡ、その他とすることもできる。
【００１４】
ユーザ端末２は、ユーザがメッセージを生成及び／又は読み出すことのできる少なくとも１つのユーザインタフェース（ＵＩ）２１、１つ又はそれ以上のメッセージングアプリケーション（Ａｐｐｌ）２２、受信するページモードタイプのメッセージを少なくとも一時的に格納するためのメモリ（Ｍｅｍ）２３（又はユーザ端末はメモリにアクセスを有するように構成される）、及び通信情報（メッセージ）を送受信するためのトランシーバ（ＴＲｘ）２４を含む。
【００１５】
メッセージングアプリケーション２２は、本発明に従う機能性を実装するように構成されたソフトウェアアプリケーションとすることができる。機能性は、例えば、対応するメッセージングアプリケーションを更新することによって、又は新規のメッセージングアプリケーションを端末に追加することによって実現することができる。
【００１６】
図２は、本発明の実施形態によるユーザ端末の送信モードにおける機能性を示すフローチャートである。図２の実施例では、ユーザが常にページモードメッセージを同様の方法で生成すること、及びメッセージに対して使用される方法／メカニズムをユーザ端末が選択することを前提とする。
【００１７】
図２は、ユーザがページモードメッセージを生成して、受信側にメッセージを送信するための指示をユーザインタフェースを介して与えるとき（ステップ２０１）に開始される。すなわち、ステップ２０１において、ユーザ端末は「このアドレスにメッセージを送信する」コマンドを受信する。このコマンドに応答してステップ２０２で、ユーザ端末は、メッセージのサイズを求め、ステップ２０３で、そのメッセージサイズが予め定められたサイズ制限よりも大きいか否かをチェックする。予め定められた制限は、例えば、使用するサービスプロトコル、ユーザ、又はオペレータが定義することができ、或いは端末に対して事前構成することができる。予め定められた制限は、トランスポートプロトコルメッセージに適合するサイズに相当するのが望ましい。しかしながら、予め定められた制限の値及び予め定められた制限の設定方法は、本発明に関して重要な意味を持たない。本発明の一部の実施形態では、全てのページモードメッセージをそのサイズに関わらず、ＭＳＲＰメカニズム又はこれに相当するメカニズムを用いて送信することさえ可能である。例えば、オペレータがページモードを使用できないことにより、ユーザ端末は常にセッションモードを使用するように事前設定することができる。
【００１８】
メッセージサイズが制限を超えない場合（ステップ２０３）、ステップ２０４で、ユーザ端末は、ＳＩＰ ＭＥＳＳＡＧＥ方法を用いて内容を送信する。
【００１９】
メッセージサイズが制限を超える場合（ステップ２０３）には、ステップ２０５で、ユーザ端末は、本発明に従って、ＭＳＲＰメカニズムを用いてページモードインジケータと共にメッセージを送信する。実装によっては、ユーザ端末は、ＭＳＲＰにより送信するページモードメッセージにメッセージの実際のサイズに関する情報を追加することができ、又はできない場合もある。実際のメッセージ送信手順については、図６、７、及び８により詳細に示されている。
【００２０】
本発明の一実施形態では、ユーザは、３つのオプション、すなわち小容量ページモードメッセージ（サイズは予め定められた制限以下）、他のページモードメッセージ、及びセッション（チャット）メッセージングの中から選択する必要があり、ユーザが他のページモードメッセージを選択する際には、メッセージの送信時に、ページモードインジケータを用いるセッションモードメッセージングメカニズムが使用される。
【００２１】
図３は、本発明の実施形態によるユーザ端末の受信モードにおける機能性を示すフローチャートである。図３の実施例では、メッセージの実際のサイズに関する情報は送信されないことを前提とする。明瞭化の目的でなされる追加の前提は、ユーザ端末がメッセージを受信することができるようにメッセージ用に十分な空きメモリを有していること、及びユーザ端末がページモードメッセージを受け入れるように構成されていることである。メッセージが空きメモリよりも大きい場合に起こることは本発明とは無関係であり、すなわちこれは、受信側端末の実装次第であり、例えば、十分な空きメモリが存在しない場合には、端末はセッション要求を拒否することができ、或いはセッション要求は受け入れられるが、メモリが満杯になるとセッションを終了する。
【００２２】
ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）の受信（ステップ３０１）に応答して、ステップ３０２でユーザ端末は、ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）がページモードメッセージのためのものであるかどうかをチェックする。ページモードメッセージのためのものである場合には、ステップ３０３で、ユーザ端末がセッションを確立し、ステップ３０４でメッセージを受信し、ステップ３０５でメッセージを格納し、ステップ３０６でセッションを解放する。その後、又はこれと同時に、ステップ３０７でユーザ端末はメッセージを受信したことをユーザに表示する。従って、ユーザは後でメッセージを読むことができる。すなわち、ユーザ端末は、メッセージがＳＩＰ ＭＥＳＳＡＧＥ方法で受信されたかのようにユーザに対して動作する。
【００２３】
ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）がチャットのためのもの（すなわちセッションモードメッセージング用）であり、ページモードメッセージのためのものではない場合（ステップ３０２）、ステップ３０８でユーザ端末はセッションを確立し、ステップ３０９で、セッションが終了するまでダイアログを表示する。
【００２４】
受信ユーザ端末は、全てのページモードメッセージを拒否するように構成することができ、この場合にはセッションが確立されないが、ステップ３０３から３０７までの代わりに拒否が送信される。
【００２５】
受信ユーザ端末は、ページモードメッセージ要求をネットワーク受信箱、別の端末、その他に転送するように構成することができ、この場合にはセッションが確立されないが、ステップ３０３から３０７までの代わりに要求が転送される。このような状況の実施例が図７及び８に示されている。全てのページモードメッセージが転送されていずれかの場所に格納され、ユーザが別の端末でこれらのメッセージを表示する必要がある場合でも、転送を行う端末がページモードメッセージングを提供するとみなされる。
【００２６】
本発明の別の実施形態では、メッセージの受信後にチェックが行われる（すなわち、ステップ３０２がステップ３０４の後に実行され、チェック後の処理はステップ３０５又はステップ３０８のいずれかに進む）。
【００２７】
図４は、本発明の別の実施形態によるユーザ端末の受信モードにおける機能性を示すフローチャートである。図４の実施例では、メッセージの実際のサイズに関する情報が存在することを前提とする。図３に関連する上記のような明瞭にするための追加の前提は、同じ説明を不必要に繰り返すわけではないが、ユーザ端末がメッセージ用に十分な空きメモリを有していること、及びユーザ端末がページモードメッセージを受け入れるように構成されていることである。
【００２８】
ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）の受信（ステップ４０１）に応答して、ステップ４０２でユーザ端末は、ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）がページモードメッセージのためのものかどうかをチェックする。ページモードメッセージのためのものである場合には、ステップ４０３で、ユーザ端末がメッセージのサイズについてユーザに通知する。ユーザがメッセージを受け入れる場合（ステップ４０４）、ステップ４０５でユーザ端末がセッションを確立し、ステップ４０６でメッセージを受信し、ステップ４０７でメッセージを格納する。その結果、ユーザは後でメッセージを読むことができる。次にステップ４０８で、ユーザ端末はセッションを解放する。すなわち、ユーザ端末はメッセージがＳＩＰ ＭＥＳＳＡＧＥ方法で受信されたかのようにユーザに対して動作する。この特定の実施例では、ユーザはメッセージの配信を受け入れることで既にメッセージについて通知されたとみなされるので、ユーザ端末はメッセージの受信についてユーザに通知しない。しかしながら、別の実装では、ユーザデバイスは、ユーザに対してメッセージの受信を通知するようにも構成することができる。
【００２９】
ユーザがメッセージを受け入れない場合（ステップ４０４）、ステップ４０９で、ユーザ端末はセッション確立を拒否する。別の実施形態では、ユーザ端末は、拒否するのではなく図７及び８に示されるようにセッション確立を転送して、メッセージをネットワーク内に格納し、後で取り出すことができるようにすることができる。
【００３０】
ＳＩＰ ＩＮＶＩＴＥ（ＭＳＲＰ）がチャットのためのもの（すなわちセッションモードメッセージング用）でありページモードメッセージのためではない場合（ステップ４０２）、ステップ４１０で、ユーザ端末はセッションを確立し、ステップ４１１でセッションが終了するまでダイアログを表示する。
【００３１】
本発明の別の実施形態では、ユーザがメッセージを受け入れるか否かを尋ねる代わりに（すなわちステップ４０３の代わりに）、ユーザ端末は、予め定められたサイズ制限を超えないメッセージを受け入れるように構成される。予め定められたサイズ制限は、例えば、オペレータ、ユーザ端末メーカー、及び／又はユーザが定義することができる。
【００３２】
以下では、図５Ａから８で示される幾つかの実施例においてシグナリングについてより詳細に説明し、ここではＳＤＰ（セッション記述プロトコル）を用いてセッションを開始し、ＭＳＲＰ ｏｖｅｒ ＴＣＰを用いて実際の内容を送信するが、本発明はこれらの実施例に限定されるものではない。以下の実施例に関連してなされる別の前提は、受信ユーザ端末がメッセージを拒否しないことである。必要に応じて、更なる情報はｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｒｎｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｉｅｔｆ−ｓｉｍｐｌｅ−ｍｅｓｓａｇｅ−ｓｅｓｓｉｏｎｓ−１０．ｔｘｔに見出すことができ、これは参照により本明細書に組み込まれる。しかしながら、どのプロトコルが使用されるかは本発明に関して重要な意味を持たず、上記は例証にすぎない。例えば、ＳＤＰの代わりに他のオファー／アンサーメカニズムプロトコルを使用することができ、ＴＣＰの代わりに、ＳＣＴＰ（Ｓｉｇｎａｌｉｎｇ Ｃｏｍｍｏｎ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などの他の輻輳制御プロトコルを使用することができる。
【００３３】
図５Ａから５Ｄは、セッションモード招待がページモードメッセージのためであることをセッションモードメッセージがどのように示すことができるかについての幾つかの実施例を示している。
【００３４】
図５Ａの実施形態では、新規のページモードインジケータ５−１（ｍ＝ｍｅｓｓａｇｅ ９ ｍｓｒｐ ｐａｇｅ−ｍｏｄｅ）を含むｍライン及びメッセージの実際のサイズを示すパラメータａ＝ｍａｘ−ｓｉｚｅ５−２（ａ＝ｍａｘ−ｓｉｚｅ：ａｃｔｕａｌ ｓｉｚｅ）の組み合わせによりページモードメッセージであることが示されている。
【００３５】
図５Ｂの実施形態では、新規のページモードインジケータ５−１（ｍ＝ｍｅｓｓａｇｅ ９ ｍｓｒｐ ｐａｇｅ−ｍｏｄｅ）を含むｍライン及びメッセージの実際のサイズを示すパラメータ５−３ａ＝ａｃｔｕａｌ−ｓｉｚｅ（ａ＝ａｃｔｕａｌ−ｓｉｚｅ：ａｃｔｕａｌ ｓｉｚｅ）の組み合わせにより、ページモードメッセージであることが示されている。この実施形態では、パラメータａ＝ｍａｘ−ｓｉｚｅがメッセージの最大サイズを示す。
【００３６】
図５Ｃの実施形態では、パラメータ５−３ａ＝ａｃｔｕａｌ−ｓｉｚｅにより、ページモードメッセージであることが示されている。このパラメータの値が０以外の場合にはメッセージがページモードメッセージであることを暗黙的に示し、０の場合はページモードメッセージでないことを暗黙的に示す。この実施形態では、ｍラインの情報が、ＭＳＲＰを使用すべきであることを示しており、パラメータａ＝ｍａｘ−ｓｉｚｅがメッセージの最大サイズを示す。
【００３７】
図５Ｄの実施形態では、新規のページモードインジケータ５−１（ｍ＝ｍｅｓｓａｇｅ ９ ｍｓｒｐ ｐａｇｅ−ｍｏｄｅ）を含むｍラインにより、ページモードメッセージであることが示されている。この実施形態では、パラメータａ＝ｍａｘ−ｓｉｚｅがメッセージの最大サイズを示しており、追加のａ−パラメータは必要ない。
【００３８】
図６のシグナリングチャートには、エンドポイント間のシグナリングだけが示されているが、１つ又はそれ以上の仲介装置を含んでもよい。図６は、受信側、より正確には受信側のユーザ端末内の対応するクライアントがメッセージを受け入れるときのシグナリングを示している。図６は、アリスがボブにメッセージを送信しようとするときに開始される。アリスのユーザ端末ＵＴ１（より正確にはＵＴ１内の対応するクライアント）は、ポイント６−１でセッションモードメカニズムを用いてページモードメッセージを送信しなければならないことを認識する（ポイント６−１については図２において上記で詳細に説明されている）。従って、ＵＴ１は、セッション招待メッセージ６−２をページモードインジケーションＰＭＩと共にボブのユーザ端末ＵＴ２に送信する。メッセージ６−２は、図５Ａから５Ｄに示されているメッセージの１つであることが望ましい。メッセージ６−２の受信に応答して、ＵＴ２は、ポイント６−３でこのメッセージがページモードメッセージのためのセッションモード招待であることを検出して、メッセージ６−４を送信することでこの招待を受け入れる。ＵＴ１はメッセージ６−５を送信することでこの受け入れを確認応答し、次いでＵＴ１は、ページモードメッセージの実際の内容をセッションモードメッセージ６−６で送信する。この内容の受信に応答して、ＵＴ２は、ボブが後でその内容を表示することができるようにポイント６−７でこれらを格納する。ＵＴ２はまた、上記図３及び４で上述されたように、ボブに通知することもできる。内容の受信に応答して、ＵＴ２はまた、メッセージ６−８でセッションモードの確認応答を送信することで受信を確認応答する。図６に示される実施形態では、送信ユーザ端末ＵＴ１は、この確認応答に応答してメッセージ６−９をＵＴ２に送信することでセッションを終了するように構成されており、次いで、ＵＴ２が、メッセージ６−１０を送信し、終了を確認応答する。
【００３９】
図７のシグナリングチャートには、受信エンドポイントの関連のインスタントメッセージングサーバを介したエンドポイント間のシグナリングが示されているが、１つ又はそれ以上の仲介装置を含んでもよい。図７は、受信側、より正確には受信側のユーザ端末内の対応するクライアントがメッセージを受け入れないが、後で取り出すためにメッセージを格納するようにネットワークに要求するときのシグナリングを示している。図７は、アリスがボブにメッセージを送信しようとするときに開始される。アリスのユーザ端末ＵＴ１（より正確にはＵＴ１内の対応するクライアント）は、ポイント７−１でセッションモードメカニズムを用いてページモードメッセージを送信しなければならないことを認識する（ポイント７−１については図２に関連して上記で詳細に説明されている）。従って、ＵＴ１は、セッション招待メッセージ７−２をページモードインジケーションＰＭＩと共にボブのユーザ端末ＵＴ２にサーバを介して送信する。メッセージ７−２は、図５Ａから５Ｄに示されているメッセージの１つであることが望ましい。メッセージ７−２の受信に応答して、ＵＴ２は、ポイント７−３でこのメッセージがページモードメッセージのためのセッションモード招待であることを検出する。何らかの理由で、ＵＴ２はページモードメッセージを受け入れないが、リダイレクトメッセージ７−４をサーバに送信する。リダイレクトメッセージの１つの実施例は、メッセージを処理すべき方法に関する情報を含むことができるＳＩＰ ３０２「Ｍｏｖｅｄ Ｔｅｍｐｏｒａｒｉｌｙ（一時的に移動）」メッセージである。しかしながら、どのように及びどのプロトコルを用いてリダイレクトが実行され、必要に応じて追加の指示／情報が与えられるかは、本発明には無関係である。他の実施例は、ＳＩＰ ＰＵＢＬＩＳＨ、ＳＩＰ ＯＰＴＩＯＮＳ、ＳＩＰ ＲＥＧＩＳＴＥＲ内の着呼機能などのＳＩＰプロトコルを用いた、又はＸＣＡＰ（拡張マークアップ言語設定アクセスプロトコル）による個別のトランザクションの利用を含む。ＵＴ２はまた、図３及び４に関連して上述したように、メッセージについてボブに通知することもできる。
【００４０】
この実施例では、サーバ、より正確にはバックトゥバックユーザーエージェントは、代替サービスを提供することを許容し、従って、サーバは、自己をセッションのエンドポイントであるとみなし、メッセージ７−５を送信することで最初の招待を受け入れる。ＵＴ１は、メッセージ７−６をサーバに送信することでこの受け入れを確認応答し、次いで、ページモードメッセージの実際の内容をセッションモードメッセージ７−７でサーバに送信する。この内容の受信に応答して、サーバは、ボブが後でその内容を表示することができるようにポイント７−８でこれらを格納する。この内容の受信に応答して、サーバはまた、メッセージ７−９でセッションモードの確認応答を送信することで受信を確認応答する。図７に示される実施形態では、送信ユーザ端末ＵＴ１は、この確認応答に応答してメッセージ７−１０をサーバに送信することでセッションを終了するように構成されており、次いでサーバが、メッセージ７−１１を送信して終了を確認応答する。その後、ボブは、メッセージの内容を後で表示することができるが、この表示の実装は本発明には無関係であり、従って、ここでは詳細には議論しない。
【００４１】
図８のシグナリングチャートには、図７のように、受信エンドポイントの関連のインスタントメッセージングサーバを介したエンドポイント間のシグナリングが示されているが、１つ又はそれ以上の仲介装置を含んでもよい。図８は、受信側、より正確には受信側のユーザ端末内の対応するクライアントがメッセージを受け入れないが、後で取り出すためにメッセージを保存するようにネットワーク内のゲートウェイＧＷに要求するときのシグナリングを示している。図８は、アリスがボブにメッセージを送信しようとするときに開始される。アリスのユーザ端末ＵＴ１（より正確にはＵＴ１内の対応するクライアント）は、ポイント８−１でセッションモードメカニズムを用いてページモードメッセージを送信しなければならないことを認識する（ポイント８−１については図２に関連して上記で詳細に説明されている）。従って、ＵＴ１は、セッション招待メッセージ８−２をページモードインジケーションＰＭＩと共にボブのユーザ端末ＵＴ２にサーバを介して送信する。メッセージ８−２は、図５Ａから５Ｄに示されているメッセージの１つであることが望ましい。メッセージ８−２の受信に応答して、ＵＴ２は、ポイント８−３でこのメッセージがページモードメッセージのためのセッションモード招待であることを検出する。何らかの理由で、ＵＴ２はページモードメッセージを受け入れないが、リダイレクトメッセージ８−４をサーバに送信し、このリダイレクトメッセージはメッセージをゲートウェイＧＷに転送すべきであることを示す（リダイレクトメッセージについては図７に関連して上記で説明された）。ＵＴ２はまた、図３及び４に関連して上述したように、メッセージについてボブに通知することもできる。
【００４２】
この実施例では、サーバ、より正確にはバックトゥバックユーザーエージェントが、メッセージ８−４で示されるＧＷのＵＲＩ（統一資源位置識別子）への新規の要求を生成して、この要求をメッセージ８−５で送信する。この要求は、ページモードインジケーションを含まないセッションモード招待であることが望ましい。ＧＷは、メッセージ８−６を送信することで最初の招待を受け入れる。ＵＴ１は、メッセージ８−７をＧＷに送信することでこの受け入れを確認応答し、次いでページモードメッセージの実際の内容をセッションモードメッセージ８−８でＧＷに送信する。この内容の受信に応答して、ＧＷは、ボブが後でその内容を表示することができるようにポイント８−９でこれらを格納する。この内容の受信に応答して、ＧＷはまた、メッセージ８−１０でセッションモードの確認応答を送信することで受信を確認応答する。図８に関連して示される実施形態では、送信ユーザ端末ＵＴ１は、この確認応答に応答してメッセージ８−１１をＧＷに送信することでセッションを終了するように構成されており、次いでＧＷが、メッセージ８−１２を送信して終了を確認応答する。次にボブは、メッセージの内容を後で表示することができるが、この表示の実装は本発明には無関係であり、従って、ここでは詳細には議論しない。
【００４３】
図９は、本発明の別の実施形態によるシグナリングを示しており、この実施形態では、インスタントメッセージングサーバもインジケーションを検出するように構成される。インスタントメッセージングサーバは、個別のサーバか、或いは１つ又はそれ以上の他の構成要素を含むネットワークノード内のサーバ構成要素とすることができる。図９に示される実施例では、受信側（ＵＴ２）が到達可能でないか、或いは受信側のページモードメッセージがこの例ではサーバ内に位置する受信側のネットワーク受信箱内に格納されることになる設定を有することを前提とする。これは、ネットワーク構成とすることもできる。図９のシグナリングチャートには、送信エンドポイントＵＴ１と受信エンドポイントの関連のインスタントメッセージングサーバとの間のシグナリングが示されているが、１つ又はそれ以上の仲介装置を含んでもよい。図９は、アリスがボブにメッセージを送信しようとするときに開始される。アリスのユーザ端末ＵＴ１（より正確にはＵＴ１内の対応するクライアント）は、ポイント９−１でセッションモードメカニズムを用いてページモードメッセージを送信しなければならないことを認識する（ポイント９−１については図２に関連して上記で詳細に説明している）。従って、ＵＴ１は、セッション招待メッセージ９−２をページモードインジケーションＰＭＩと共にボブのユーザ端末ＵＴ２にサーバを介して送信する。メッセージ９−２は、図５Ａから５Ｄに示されているメッセージの１つであることが望ましい。メッセージ９−２の受信に応答して、サーバ、より正確にはバックトゥバックユーザーエージェントが、ポイント９−３で、このメッセージがページモードメッセージのためのセッションモード招待であることを検出し、従って、ボブすなわちＵＴ２のページモードメッセージに関する構成をチェックする。構成は、ページモードメッセージは後で取り出すために格納されるべきであることを示しているので、サーバは自己をセッションのエンドポイントであるとみなし、メッセージ９−４を送信することで招待を受け入れる。ＵＴ１は、メッセージ９−５をサーバに送信することでこの受け入れを確認応答し、次いでページモードメッセージの実際の内容をセッションモードメッセージ９−６でサーバに送信する。この内容の受信に応答して、サーバは、ボブが後でその内容を表示することができるようにポイント９−７でこれらを格納する。本発明の別の実施形態では、メッセージは、他のネットワークノード又はリモートデータベースに格納する、或いはゲートウェイに転送することができる。内容の受信に応答して、サーバはまた、メッセージ９−８でセッションモードの確認応答を送信することで受信を確認応答する。図９に関連して示される実施形態では、送信ユーザ端末ＵＴ１は、この確認応答に応答してメッセージ９−９をサーバに送信することでセッションを終了するように構成されており、次いでサーバが、メッセージ９−１０を送信して終了を確認応答する。次にボブは、メッセージの内容を後で表示することができるが、この表示の実装は本発明には無関係であり、従って、ここでは詳細には議論しない。
【００４４】
本発明の別の実施形態では、受信側のインスタントメッセージングサーバが、セッション要求を転送するか否かを決定するように、或いはメッセージサイズ、受信側の端末機能及び／又はネットワーク負荷に基づいて自己をエンドポイントであるとみなすように構成される。
【００４５】
図９に基づく別の実施形態では、セッションモードメカニズムを用いて送信されるページモードメッセージはネットワーク受信箱に格納されてユーザに通知されるだけであるが、ページモードメカニズムを用いて送信されるページモードメッセージはユーザに転送されるような構成をユーザが有することができる。
【００４６】
図２、３、４、６、７、８、及び９に示されるステップ、ポイント、及びシグナリングメッセージは、絶対的な時系列順にはなっておらず、ステップ／ポイントの一部は、同時に又は所与の順序とは異なる順序で実行することができる。ステップ／ポイント間又はステップ／ポイント内で他の機能を実行することもできる。ステップ／ポイントの幾つか又はステップ／ポイントの一部分を省くこともできる。シグナリングメッセージは例示的なものにすぎず、同じ情報の送信において幾つかの別個のメッセージを含むことさえできる。更に、メッセージは他の情報を含むこともできる。メッセージ及びステップ／ポイントは、自由に組み合わせることも、幾つかの部分に分けることもできる。更に、使用するプロトコルと同様に、メッセージの名称、種類、及び／又は内容は、上述のものと異なることも可能である。
【００４７】
上記では、通信、すなわちファイル送信及び呼び出しが１対１の通信であることを前提として本発明を開示したが、当業者であれば、通信は１対多の通信とすることもできることは明らかである。
上記に提示した実施形態及びその一部分を組み合わせて本発明の好ましい実施形態を生み出すことができる。
【００４８】
本発明の機能性を実装するユーザ端末、これに相当する他のデバイス及び／又はサーバ、或いは対応するサーバ構成要素は、従来技術の手段だけでなく、上述の方法でページモードメッセージを送信及び／又は受信するための手段も備える。現行のネットワークノード及びユーザ端末は、本発明に従う機能で利用することのできるプロセッサ及びメモリを備える。本発明の実装に必要とされる全ての修正及び構成は、追加又は更新されたソフトウェアルーチンとして実装することのできるルーチン、特定用途向け回路（ＡＳＩＣ）、及び／又はプログラム可能回路として実行することができる。
【００４９】
当業者であれば、技術の進展に伴って本発明の概念を様々な方法で実装することができることは明らかであろう。本発明及びその実施形態は、上述の実施例に限定されるものではないが、請求項の範囲内で変えることができる。
【符号の説明】
【００５０】
６−１ セッションモードのページモードメッセージ
６−３ ページモードを検出する
６−７ 格納する
【特許請求の範囲】
【請求項１】
ページモードメッセージを送信するための方法であって、
前記方法が、
セッションモードメッセージングメカニズムを用いて、前記セッションモードがページモードメッセージのためのもののものであることを示すインジケーションと共にメッセージを送信する段階と、
前記インジケーションに応答して、前記受信メッセージをページモードメッセージとして扱う段階と、
を含むことを特徴とする方法。
【請求項２】
前記メッセージを送受信するためのセッションを生成する段階と、
前記メッセージが送信されたことに応答して前記セッションを終了する段階と、
を更に含む、
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記メッセージを送受信するためのセッションを生成する段階と、
前記メッセージが受信されたことに応答して前記セッションを終了する段階と、
を更に含む、
ことを特徴とする請求項１に記載の方法。
【請求項４】
セッション記述プロトコルを用いて前記セッションモードメッセージングメカニズムでセッションを開始する段階と、
セッション開始メッセージのヘッダに前記インジケーションを追加する段階と、
を更に含む、
ことを特徴とする前記請求項のいずれか１項に記載の方法。
【請求項５】
前記ヘッダ内のｍラインが前記インジケーションを含む、
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記インジケーションが前記メッセージの実際のサイズを示すパラメータである、
ことを特徴とする請求項４に記載の方法。
【請求項７】
前記インジケーションが、ｍラインのインジケーションと、前記メッセージの実際のサイズを示すパラメータとを含む、
ことを特徴とする請求項４に記載の方法。
【請求項８】
ページモードメッセージング及びセッションモードメッセージングを提供するユーザ端末であって、前記ユーザ端末が、セッションモードメッセージングメカニズムを用いて、前記メッセージがページモードメッセージであることを示すインジケーションと共にページモードメッセージを送信するように構成されている、
ことを特徴とするユーザ端末。
【請求項９】
前記ユーザ端末が更に、ページモードメッセージのサイズが予め設定された制限を超えることに応答して、前記セッションモードメッセージングメカニズムを用いて前記ページモードメッセージを送信するように構成されている、
ことを特徴とする請求項８に記載のユーザ端末。
【請求項１０】
前記ユーザ端末が更に、ユーザコマンドに応答して、前記セッションモードメッセージングメカニズムを用いて前記ページモードメッセージを送信するように構成されている、ことを特徴とする請求項８又は９に記載のユーザ端末。
【請求項１１】
ページモードメッセージング及びセッションモードメッセージングを提供するユーザ端末であって、前記ユーザ端末が、
セッションモードメッセージングメカニズムがページモードメッセージ用に使用されるというインジケーションを検出し、前記インジケーションに応答して、受信メッセージをページモードメッセージとして扱うように構成されている、
ことを特徴とするユーザ端末。
【請求項１２】
前記ユーザ端末が更に、前記受信に応答して前記受信メッセージを格納するように構成されている、
ことを特徴とする請求項１１に記載のユーザ端末。
【請求項１３】
前記ユーザ端末が更に、前記メッセージを前記ユーザに通知するように構成されている、
ことを特徴とする請求項１１又は１２に記載のユーザ端末。
【請求項１４】
前記ユーザ端末が更に、前記インジケーションに応答して前記メッセージのサイズをチェックし、前記サイズに基づいて前記セッションモードメカニズムの継続又は終了を決定するように構成されている、
ことを特徴とする請求項１１、１２、又は１３に記載のユーザ端末。
【請求項１５】
前記ユーザ端末が更に、前記インジケーションに応答して前記メッセージのサイズをチェックし、前記サイズを前記ユーザに表示することに加えて前記セッションモードメカニズムの継続又は終了に関する更なる指示を前記ユーザに対して要求するように構成されている、
ことを特徴とする請求項１１、１２、１３、又は１４に記載のユーザ端末。
【請求項１６】
前記ユーザ端末が更に、前記ページモードメッセージに関するセッション要求を転送することにより前記セッションモードメカニズムを継続するように構成されている、
ことを特徴とする請求項１１、１２、１３、１４、又は１５に記載のユーザ端末。
【請求項１７】
ページモードメッセージング及びセッションモードメッセージングを提供するサーバであって、前記サーバは、
セッションモードメッセージングメカニズムがページモードメッセージのために使用されるというインジケーションを検出し、前記インジケーションに応答して、自己を前記セッションモードメッセージングメカニズムのエンドポイントであるとみなすように構成されている、
ことを特徴とするサーバ。
【請求項１８】
前記サーバが更に、前記インジケーションに応答して受信メッセージをページモードメッセージとして扱うように構成されている、
ことを特徴とする請求項１７に記載のサーバ。
【請求項１】
ページモードメッセージを送信するための方法であって、
前記方法が、
セッションモードメッセージングメカニズムを用いて、前記セッションモードがページモードメッセージのためのもののものであることを示すインジケーションと共にメッセージを送信する段階と、
前記インジケーションに応答して、前記受信メッセージをページモードメッセージとして扱う段階と、
を含むことを特徴とする方法。
【請求項２】
前記メッセージを送受信するためのセッションを生成する段階と、
前記メッセージが送信されたことに応答して前記セッションを終了する段階と、
を更に含む、
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記メッセージを送受信するためのセッションを生成する段階と、
前記メッセージが受信されたことに応答して前記セッションを終了する段階と、
を更に含む、
ことを特徴とする請求項１に記載の方法。
【請求項４】
セッション記述プロトコルを用いて前記セッションモードメッセージングメカニズムでセッションを開始する段階と、
セッション開始メッセージのヘッダに前記インジケーションを追加する段階と、
を更に含む、
ことを特徴とする前記請求項のいずれか１項に記載の方法。
【請求項５】
前記ヘッダ内のｍラインが前記インジケーションを含む、
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記インジケーションが前記メッセージの実際のサイズを示すパラメータである、
ことを特徴とする請求項４に記載の方法。
【請求項７】
前記インジケーションが、ｍラインのインジケーションと、前記メッセージの実際のサイズを示すパラメータとを含む、
ことを特徴とする請求項４に記載の方法。
【請求項８】
ページモードメッセージング及びセッションモードメッセージングを提供するユーザ端末であって、前記ユーザ端末が、セッションモードメッセージングメカニズムを用いて、前記メッセージがページモードメッセージであることを示すインジケーションと共にページモードメッセージを送信するように構成されている、
ことを特徴とするユーザ端末。
【請求項９】
前記ユーザ端末が更に、ページモードメッセージのサイズが予め設定された制限を超えることに応答して、前記セッションモードメッセージングメカニズムを用いて前記ページモードメッセージを送信するように構成されている、
ことを特徴とする請求項８に記載のユーザ端末。
【請求項１０】
前記ユーザ端末が更に、ユーザコマンドに応答して、前記セッションモードメッセージングメカニズムを用いて前記ページモードメッセージを送信するように構成されている、ことを特徴とする請求項８又は９に記載のユーザ端末。
【請求項１１】
ページモードメッセージング及びセッションモードメッセージングを提供するユーザ端末であって、前記ユーザ端末が、
セッションモードメッセージングメカニズムがページモードメッセージ用に使用されるというインジケーションを検出し、前記インジケーションに応答して、受信メッセージをページモードメッセージとして扱うように構成されている、
ことを特徴とするユーザ端末。
【請求項１２】
前記ユーザ端末が更に、前記受信に応答して前記受信メッセージを格納するように構成されている、
ことを特徴とする請求項１１に記載のユーザ端末。
【請求項１３】
前記ユーザ端末が更に、前記メッセージを前記ユーザに通知するように構成されている、
ことを特徴とする請求項１１又は１２に記載のユーザ端末。
【請求項１４】
前記ユーザ端末が更に、前記インジケーションに応答して前記メッセージのサイズをチェックし、前記サイズに基づいて前記セッションモードメカニズムの継続又は終了を決定するように構成されている、
ことを特徴とする請求項１１、１２、又は１３に記載のユーザ端末。
【請求項１５】
前記ユーザ端末が更に、前記インジケーションに応答して前記メッセージのサイズをチェックし、前記サイズを前記ユーザに表示することに加えて前記セッションモードメカニズムの継続又は終了に関する更なる指示を前記ユーザに対して要求するように構成されている、
ことを特徴とする請求項１１、１２、１３、又は１４に記載のユーザ端末。
【請求項１６】
前記ユーザ端末が更に、前記ページモードメッセージに関するセッション要求を転送することにより前記セッションモードメカニズムを継続するように構成されている、
ことを特徴とする請求項１１、１２、１３、１４、又は１５に記載のユーザ端末。
【請求項１７】
ページモードメッセージング及びセッションモードメッセージングを提供するサーバであって、前記サーバは、
セッションモードメッセージングメカニズムがページモードメッセージのために使用されるというインジケーションを検出し、前記インジケーションに応答して、自己を前記セッションモードメッセージングメカニズムのエンドポイントであるとみなすように構成されている、
ことを特徴とするサーバ。
【請求項１８】
前記サーバが更に、前記インジケーションに応答して受信メッセージをページモードメッセージとして扱うように構成されている、
ことを特徴とする請求項１７に記載のサーバ。
【図１】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図５Ｄ】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図５Ｄ】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１３−１２２３０（Ｐ２０１３−１２２３０Ａ）
【公開日】平成２５年１月１７日（２０１３．１．１７）
【国際特許分類】
【出願番号】特願２０１２−１９３８６０（Ｐ２０１２−１９３８６０）
【出願日】平成２４年９月４日（２０１２．９．４）
【分割の表示】特願２０１０−２８５３９７（Ｐ２０１０−２８５３９７）の分割
【原出願日】平成１８年６月５日（２００６．６．５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
【公開日】平成２５年１月１７日（２０１３．１．１７）
【国際特許分類】
【出願日】平成２４年９月４日（２０１２．９．４）
【分割の表示】特願２０１０−２８５３９７（Ｐ２０１０−２８５３９７）の分割
【原出願日】平成１８年６月５日（２００６．６．５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（３９８０１２６１６）ノキア コーポレイション (1,359)
【Ｆターム（参考）】
[ Back to top ]