JP2009512931A

JP2009512931A - オフラインインスタントメッセージのリトリーブ

Info

Publication number: JP2009512931A
Application number: JP2008536181A
Authority: JP
Inventors: ミグエルエー．ガルシア‐マルティン; アダムハルナ
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2005-10-19
Filing date: 2006-10-13
Publication date: 2009-03-26
Also published as: WO2007046046A1; EP1938536B1; EP1938536A1; KR20080048078A; US9258259B2; PT1938536E; US20070078935A1; KR100966959B1; ES2403188T3; PL1938536T3; DK1938536T3

Abstract

メールサーバに保存されユーザがリトリーブ保留中のメッセージのリトリーブが開示される。メールサーバに保存されている、ユーザがリトリーブすることを保留中の複数のメッセージのサマリが、ユーザの端末装置で受信される（S31）。メッセージには固有識別子に関連付けられている。メールサーバからリトリーブされるメッセージのうちの少なくとも１つは、メッセージのサマリに基づいて選択される（S32）。少なくとも１つのメッセージに関連付けられた固有識別子から、少なくとも１つのメッセージのリトリーブに有効な識別子が判断され（S33）、リトリーブに有効な識別子を有するリトリーブ要求がメールサーバに送信される（S34）。保存されたメッセージのうちの少なくとも１つのリトリーブに有効な少なくとも１つの識別子を有するリトリーブ要求を受信すると（S41）、メールサーバは、少なくとも１つのメッセージを端末装置に送信する（S42）。
【選択図】図２

Description

発明の背景

（技術分野）
本発明は、セッション開始プロトコル（Session Initiation Protocol; SIP）／インスタントメッセージングとプレゼンスを活用する拡張のためのSIP（SIP for Instant Messaging and Presence Leveraging Extensions; SIMPLE）に基づくインスタントメッセージングに関する。具体的には、本発明は、メールサーバがインスタントメッセージをネットワークに保存して、さらにエンドユーザに配信する場合（恐らく、ユーザが後でネットワークに接続する場合）に発生する技術問題に対処する。

ユーザAが、１つ以上のインスタントメッセージをユーザBに送信すると仮定する。これらのメッセージの配信に使用される技術は、SIP MESSAGE方法またはメッセージセッションリレープロトコル（Message Session Relay Protocol; MSRP）に基づくことができる。さらに、ユーザBがそのSIPサーバに登録されていないこと、ならびにメールアプリケーションサーバが、後でユーザBにさらに配信するように、実際のインスタントメッセージを保存していると仮定する。

ユーザBがそのSIPネットワークに登録すると、SIPユーザエージェントは、メッセージのサマリおよび待機インジケータイベントパッケージに要請し、リトリーブすることを保留中メッセージの通知を入手する。メールサーバが大量のインスタントメッセージを保存し、ユーザBは、これらの保存されたインスタントメッセージのサマリを含む通知を入手すると仮定する。

本発明は、オフラインインスタントメッセージのリトリーブの改善を可能にする。

発明の摘要

図1は、本発明に係る端末装置およびネットワーク装置の構成を示す略ブロック図である。

端末装置10は、受信ブロック11、選択ブロック12、判断ブロック13、および送信ブロック14を備える。受信ブロック11は、ネットワーク装置20などのメールサーバに保存された複数のメッセージであって、ユーザがリトリーブすることを保留中の複数のメッセージのサマリを受信する。このメッセージの各々は固有識別子と関連付けられている。選択ブロック12は、メッセージのサマリに基づいて、メールサーバからリトリーブされるメッセージのうちの少なくとも１つを選択する。判断ブロック13は、その少なくとも１つのメッセージに関連付けられた固有識別子に基づいて、その少なくとも１つのメッセージのリトリーブに有効な識別子を決定することによって、リトリーブに有効な少なくとも１つの識別子を取得する。送信ブロック14は、リトリーブに有効な少なくとも１つの識別子を有するリトリーブ要求を、メールサーバに送信する。

固有識別子は、メールサーバまたは統一リソース識別子（Uniform Resource Identifier; URI）によって提供されるメッセージ識別子であってもよい。

メールサーバなどのネットワーク装置20は、ユーザがリトリーブすることを保留中の複数のメッセージを保存し、受信ブロック21および送信ブロック22を備える。受信ブロック21は、保存されたメッセージのうちの少なくとも１つのリトリーブに有効な少なくとも１つの識別子を有するリトリーブ要求を受信し、送信ブロック22は、リトリーブ要求を送信したユーザの端末装置（例えば、端末装置10）に、少なくとも１つのメッセージを送信する。

送信ブロック22は、メッセージセッションリレープロトコル（Message Session Relay Protocol; MSRP）のSENDメッセージにおいて、少なくとも１つのメッセージを送信してもよい。

第１の実施形態によると、ネットワーク装置20は、保存されたメッセージ毎にメッセージ識別子を提供する提供ブロック23をさらに備えてもよく、ここで、送信ブロック22は、保存されたメッセージのサマリを端末装置10などのユーザに送信し、各メッセージは、判断されたメッセージ識別子と関連付けられる。

提供ブロック23は、保存されたメッセージの各々のセッション開始プロトコル要求に含まれるCall-IDヘッダフィールドを、メッセージ識別子に使用してもよく、あるいは固有の統一リソース識別子（Uniform Resource Identifier; URL）生成してもよく、このURIはネットワーク装置にルーティング可能であり、ここでメッセージ識別子はURIの一部である。

提供ブロック23は、保存されたメッセージの各々のメッセージセッションリレープロトコル要求のMessage-IDヘッダフィールドを、メッセージ識別子に使用してもよい。

第２の実施形態によると、ネットワーク装置20は、会議サーバと、保存されたメッセージに対応する仮想SIPユーザエージェントなどの仮想エンドポイントとを備えてもよい。会議サーバは、保存されたメッセージのうちの選択されたものを指示する識別子のリストを含むリトリーブ要求を、ユーザから受信することができ、このリトリーブ要求は、選択されたメッセージを配信するための第１のセッションを確立する。次に、会議サーバは、リストにおいて識別された、選択されたメッセージ毎に、該選択されたメッセージに対応する複数のエンドポイントと第２のセッションを確立し、該第２のセッション内で選択されたメッセージを受信し、該第１のセッション内で選択されたメッセージをユーザに転送することができる。

図1の構成は、本発明を説明するためのものであり、端末装置およびネットワーク装置は、本発明および本明細書で省略される記載の理解に関係のないさらなる機能を実行するさらなるブロック（メッセージを保存するためのネットワーク装置20における保存ブロックなど）を備えてもよいことに留意されたい。

図2は、端末装置10側で、メールサーバからメッセージをリトリーブする方法を示すフロー図である。ステップS31において、メールサーバに保存された、それぞれ固有識別子に関連付けられた複数のメッセージであって、ユーザがリトリーブすることを保留中の複数のメッセージのサマリが、端末装置に受信される。ステップS32において、メールサーバからリトリーブされるメッセージのうちの少なくとも１つはステップS31で受信したメッセージのサマリに基づいて選択される。ステップS33において、少なくとも１つのメッセージのリトリーブに有効な識別子は、少なくとも１つのメッセージに関連付けられた固有識別子に基づいて判断されることによって、リトリーブに有効な少なくとも１つの識別子を取得し、ステップS34において、リトリーブに有効な識別子を有するリトリーブ要求は、メールサーバに送信される。

図3は、ネットワーク装置20側で、メールサーバからメッセージをリトリーブする方法を示すフロー図である。ステップS41において、保存されたメッセージのうちの少なくとも１つのリトリーブに有効な少なくとも１つの識別子を有するリトリーブ要求は受信され、ステップS42において、その少なくとも１つのメッセージは、リトリーブ要求を送信したユーザの端末装置に、その少なくとも１つのメッセージを送信する。

第２の実施形態によると、保存されたメッセージのうちの選択されたものを指示する識別子のリストを含む、ユーザからのリトリーブ要求は、ネットワーク装置20で受信され、このリトリーブ要求は、選択されたメッセージを配信するために第１のセッションを確立する。第２のセッションは、リストにおいて識別された選択メッセージ毎に確立され、選択されたメッセージは、該第２のセッション内で受信され、選択メッセージは、該第１のセッション内でユーザに転送される。
本発明は、コンピュータプログラムとして実装されてもよい。

メールサーバは、メール保存プリケーションサーバまたはインスタントメッセージメールサーバとして実装されることができる。

本発明の第１の実施形態によると、ユーザは、保存されたメッセージ毎に割り当てられた固有のメッセージ識別を含む、メッセージサマリ通知を受信する。ユーザがリトリーブしたいメッセージ毎に、SIPユーザエージェントは、例えば、何らかの変換を行なった後に、メッセージの識別宛てのメッセージのSIPセッションを生成する。サーバは、INVITE要求を受信すると、ユーザがリトリーブしたい実際のメッセージを一意的に判断することができる。

この解決手段によって、ユーザは、リトリーブするべきこの保存されたインスタントメッセージを選択できるようになる。特に、保存されたインスタントメッセージの数およびサイズが関連する場合に、帯域幅が限定される移動シナリオにおける利点は莫大である。したがって、ユーザは、緊急として対象となる、あるいは特定のユーザから受信されたメッセージを選択してリトリーブ、残りのメッセージを後で読むことができる。

本発明の第２の実施形態によると、ユーザが、メールサーバからリトリーブしたいインスタントメッセージを選択すると、URIリストの概念を利用して、選択されたメッセージ宛ての単一セッション（SIP INVITE）を生成するという機構が提供される。本実施形態は、会議サーバと、各々がインスタントメッセージを表す多数の仮想SIPユーザエージェントとを含むメールサーバをモデル化する。

本実施形態によると、移動環境で使用可能な最適化された方法で、メールサーバに既に保存された選択メッセージを選択およびリトリーブするような機構が、提供される。本解決手段によると、ユーザは、単一のプロトコル動作で、無限数の選択された保存メッセージをリトリーブすることができる。

この解決手段によって、ユーザは、メールサーバに対する単一セッションを使用して、選択されたメッセージをリトリーブするための信号伝達および往復変換を最小限に抑えることができる。参照することによってその内容が本明細書に組み込まれる、2005年9月30日に米国特許商標局に出願されたGarciaらによる暫定特許出願「インスタントメッセージングのための方法および装置」（Method and Apparatus for Instant Messaging）および第１の実施形態により、保存されたインスタントメッセージの全部、または選択されたメッセージの１つずつ（個別のSIPセッションを必要とする各メッセージを意味する）のいずれかがリトリーブ可能になる。

したがって、本発明の第２の実施形態によって、セッション設定の遅延が低減することによってユーザ経験が増加し、無線インターフェースなどの低帯域幅チャネルで作動するリソースが最適化される。

本発明に係る端末装置およびネットワーク装置の構成を示す略ブロック図である。

本発明に係るリトリーブ方法を示すフロー図である。

本発明の第１の実施形態に係る信号伝達図である。

本発明の第２の実施形態に係るメールサーバホストを示す略ブロック図である。

本発明の第２の実施形態に係る信号伝達図である。

発明の実施形態の説明

インスタントメッセージがユーザのメールボックスに蓄積されたと仮定すると、ユーザの電話機のスイッチがオンの場合、電話機は、RFC3842「セッション開始プロトコル（Session Initiation Protocol; SIP）のためのメッセージサマリとメッセージ待機指示イベントパッケージ」に準拠して、メッセージサマリイベントパッケージに要請を送信し、保留中メッセージを含む通知を受信する。RFC3842の内容は、参照することによって本明細書に組み込まれる。また、本機構は、ボイスメールやファックスなどにも適用される。通知機能（ユーザのメッセージシステムの代わりに作動するSIPユーザエージェント）は、NOTIFYの本文中に、例えば「４つの既読メッセージと３つの新着メッセージがあります」などの保存メッセージのメッセージサマリを送信する。

任意により、サマリを考慮した後、To、From、Date、Subject、およびMessage-IDのヘッダが各メッセージに付加されてもよい。

ユーザ／ユーザ側端末装置（User Equipment; UE）が通知を受けると、所望の媒体タイプを含むINVITEをサーバに送信して、リトリーブすることができる（オープンモバイルアライアンス（Open Mobile Alliance; OMA）におけるメッセージグループの目的として、INVITEには、MSRPのセッション記述プロトコル（Session Description Protocol; SDP）の記述を含めなければならないが、その他の媒体タイプを含んでもよい）。

さらに、ユーザは、上記暫定特許出願「インスタントメッセージングのための方法および装置」に記載の機構を適用して、メタデータ情報（例えば、差出人、送信時間など）を含む、保存されたインスタントメッセージの全てをメールサーバからリトリーブすることができる。このため、SIP機構は、メッセージ保存アプリケーションサーバとして作動するアプリケーションサーバにこれまでに蓄積されたインスタントメッセージをリトリーブするように提供される。これは、例えば、RFC3261の27.5章に規定されるようなmessage/sipとして、あるいはRFC3420に規定されるようなmessage/sipfragとしてカプセル化することによって、SIPメッセージの該当ヘッダを保持し、次に、それをMSRP SEND 要求のペイロードとして送信することによって、達成可能である。RFC3261および3420の内容は、参照することによって本明細書に組み込まれる。さらに、保存アプリケーションサーバは、MSRP SENDメッセージと、メッセージが受信された日時を含むカプセル化SIPメッセージとにヘッダを付加することができる。さらに具体的には、日時のヘッダは、保存されたSIPおよびMSRPメッセージ毎に挿入される。新規の意味論は、保存されたインスタントメッセージのカプセル化に使用可能であり、message/sipおよびmessage/sipfragは、その元々の内容以外でMSRPにおいて使用される。したがって、ヘッダ情報をMSRPメッセージのペイロードとして含む、カプセル化されたSIPメッセージを配信する方法が提供される。

上記機構を使用して、ユーザがメールサーバとコンタクトをとり、保存メッセージアプリケーションサーバに既に蓄積された既存のインスタントメッセージを、リトリーブ可能にする方法および装置が提供される。インスタントメッセージは、SIP MESSAGE要求（IETF RFC3428による）またはSIPセッションの一部であるMSRPメッセージ（例えば、要求）を使用して、保存メッセージアプリケーションサーバに蓄積可能である。RFC3428の内容は、参照することによって本明細書に組み込まれる。メタデータおよび／またはヘッダ情報によって、ユーザは、メッセージの発信元、メッセージの放置時間を判断可能になる。

SIPセッションがMSRP媒体で確立されると、全保存メッセージは、サーバからユーザ／UEに転送される。各保存メッセージは、個別のMSRP SEND要求において送信され（MSRP SEND要求が大量になる前に）、その各々は、それ自体の元々のメッセージIDによって識別される。このように、ユーザは、全メッセージを一度にリトリーブするが、メッセージIDによって全メッセージを分類することができる。

いくつかの解決手段の欠点の１つとして、MSRPヘッダがメッセージを蓄積するSIP URIといかなる関係性も持たないために、元々の送信者識別（ユーザ情報）が必然的に失われることが挙げられる。ゆえに、電子メール、インスタントメッセージング、MMSなどのメッセージのアプリケーションボックスで既に利用可能であるような特定のメッセージへ送信者の関連付けが失われる。また、これは、保存メッセージアプリケーションサーバに設定されることから、送信可能ではあるが、受信者が送信者を識別不可能であるという点において、SIP MESSAGE要求にも当てはまる。

ユーザが自身の保存インスタントメッセージをリトリーブしたい場合に、自身の保存メッセージアプリケーションサーバでMSRPセッションを確立するという機構が提案される。保存メッセージASは、MSRP SEND要求における各リトリーブセッションまたは独立型メッセージをカプセル化する。したがって、各MSRP SEND要求は、ペイロードを含むSIPセッションまたはメッセージを表す（１つ以上のMSRP SEND要求またはメッセージの場合はその他のいくつかのタイプ）。

しかしながら、上記機構を使用することによって、ユーザBは、選択されたメッセージ（例えば、特定の件名または所定の優先度のある、特定時間フレーム中に所定のユーザに送信されたメッセージ）をリトリーブすることはできない。具体的には、ユーザがどのメッセージを受信したいかを、ユーザBがメールサーバに指示できる機構は存在しない。

［第１の実施形態］

図4は、第１の実施形態に係る、ユーザと保存メッセージアプリケーションサーバ（application server; AS）との間で交換されるメッセージを示す信号伝達図である。図4に示されるように、アリスは、 SIP MESSAGE要求（フロー1）を使用して、インスタントメッセージをチャーリーに送信する。このMESSAGE要求には、本明細書ではテキスト#1と呼ばれるいくつかのテキストが含まれる。チャーリーがオフラインであると仮定すると、メッセージは、保存メッセージアプリケーションサーバ（AS）に受信および保存される。

別のユーザのボブは、INVITE要求（フロー3）をチャーリーに送信することによってSIPセッションを生成する。INVITE要求にはセッション記述が含まれ、このセッション記述には、セッションに基づくインスタントメッセージを送信するためのMSRP記述子が含まれる。チャーリーはオフラインであるため、保存メッセージASは、INVITE要求を傍受し、セッションを確立する。次に、チャーリーは、MSRP SEND要求（テキスト#2およびテキスト#3をそれぞれ含むフロー5および7）を使用して、２つのメッセージをチャーリーのメッセージアカウントに蓄積する。すなわち、実際のメッセージは、MSRP SEND要求で送信される。メッセージ#9は、インスタントメッセージのセッションを終了させるSIP BYE要求である。

後に、チャーリーは、ネットワークに接続し、SIP SUBSCRIBE要求（メッセージ#11）を自身のメールサーバ、つまり保存メッセージASに送信することによって、メッセージサマリ通知を要請する。

通知は、NOTIFY要求（メッセージ#13）に含まれる。ユーザがメッセージサマリおよびメッセージ待機インジケータイベントパッケージの通知要請によって受信する通知には、特に、Message-IDヘッダのフォーマットの固有識別子がメッセージ毎に含まれる。メールサーバは、メッセージ毎にMessage-IDを選択する。一般的なマッピングにおいて、通知におけるMessage-IDは、SIP MESSAGEまたはSIP INVITE要求（MSRPセッションを開始した）のCall-IDヘッダフィールドと同じ値を含むことが可能であり、あるいは通知におけるMessage-IDは、MSRP SEND要求におけるMessage-IDヘッダフィールドと同じ値を含むことができる。チャーリーが、リトリーブするメッセージを選択すると、リトリーブされる特定メッセージ宛てのINVITE要求（メッセージ#15）を生成する。

第１の実施形態の代替および類似の実装例が2例ある。

〔実装例A〕

メールサーバは、メッセージサマリのMessage-IDヘッダに、SIPに含まれるCall-IDヘッダフィールドを複写するか、あるいは、メッセージサマリのMessage-IDヘッダに、MSRP SEND要求のMessage-IDヘッダを複写する。したがって、保存された各SIP MESSAGE、完全なMSRPセッション（SIP INVITEによって開始された）、または個々のMSRP SEND要求は、Message-IDによって一意的に特定される。したがって、ユーザが、特定のメッセージをメッセージサマリから選択してリトリーブする場合、保存されたメッセージには、メッセージサマリのMessage-IDヘッダに形成される固有のSIP URIが割り当てられる。

これにより、メッセージがSIP MESSAGE要求で蓄積される場合に、メッセージを１つずつリトリーブ可能になる。メッセージが多数のMSRP SEND要求で蓄積される場合（INVITE-BYEセッション内で）、その解決手段によって、SIP INVITEのCall-IDで識別されたセッションの一部である全MSRPメッセージ、または個々の保存されたMSRP SEND要求がリトリーブ可能になる。

以下は、ユーザBが受信するメッセージサマリ通知の例である。通知によって、新しいテキストメッセージがリトリーブ待機中であることが示される。

bob@example.com から送信され、かつ値がd0982dkjs@bobmobile.example.comであるMessage-IDヘッダで識別される第２のメッセージのみを、チャーリーがリトリーブしたいと仮定すると、チャーリーは、SIP URI（一般的なフォーマットは「sip:username@hostname」）宛てのSIP INVITE要求を生成し、このSIP INVITE要求は以下を含む。

・ URIにおけるユーザ名としての、選択されたMessage-IDのエスケープ値。
・メールサーバのホスト名（これは、一般的に、SIPユーザエージェントにおいて事前に構成される）。

すなわち、ユーザ（つまり、チャーリー）は、保存されたインスタントメッセージの固有識別子を、リトリーブに有効な識別子にマップする。

この実施例を進めると、チャーリーは、Request-URIがsip: d0982dkjs%40bobmobile.example.com@mailserver.example.comであるSIP INVITE要求（例えば、図4のメッセージ#15）を生成する。

「%40」は、「@」記号に対応するエスケープ文字である（これは、SIPの実用において標準的）。

例えば、ユーザ（つまり、チャーリー）は、メッセージ#15において、以下のINVITE（該当するヘッダのみ印刷）をボイスメールサーバ（保存メッセージAS）に送信する。

このINVITE要求は、通常のSIP手順に従ってメールサーバ（保存メッセージAS）に届けられる。メールサーバは、「ユーザ名」を抽出し、それをアンエスケープして元々のメッセージIDを入手し、そのメッセージをリトリーブ、それをチャーリーに送信する。このために、前記暫定特許出願「インスタントメッセージングのための方法および装置」に記載の機構が適用されてもよい。

例えば、保存メッセージASは、図4の保存されたSIP INVITEメッセージ#3、保存されたMSRP SEND要求#5および#7、ならびに保存されたSIP BYEメッセージ#9を取り込み、message/sip（RFC3261の27.5章）またはmessage/sipfrag（RFC3420）に設定されるメッセージタイプで、それらをMSRP SEND要求にカプセル化する（図示せず）。

〔実装例B〕

本実装は、本質的にAと同じである。その違いは、インスタントメッセージを蓄積したSIP MESSAGEまたはINVITEのCall-IDヘッダ値ではなく、代わりに、メールサーバを示して、かつメッセージを識別する固有のURIで、メールサーバがMessage-IDヘッダを投入するという点だけにある。

例えば、以下は、実装例Aで示されたものと同じNOTIFY要求であるが、実装例Bに修正されている。

したがって、チャーリーが、ボブが配信した同一の第２のメッセージをリトリーブしたい場合、そのメッセージにメールサーバによって割り当てられたMessage-ID値宛てのINVITE要求を生成する。このMessage-ID値によって、サーバにおけるメッセージは一意的に識別される。この代替として、SIPメッセージのRequest-URIを生成する前に、受信したMessage-IDを他の何かに変換する必要はない。つまりリトリーブされるメッセージのMessage-ID値がSIP要求のRequest-URIに複写される。

［第２の実施形態］

上記と同様、ユーザがしばらくの間オフラインであり、その他の何人かのユーザが、プロトコルとして一般的にSIP（RFC3261のセッション開始プロトコル）とMSRP（インターネットドラフトdraft-ietf-simple-message-sessins-12.txtのメッセージセッションリレープトロコル）との組み合わせを使用して、１つ以上のインスタントメッセージを保存メッセージASに蓄積したと仮定する。ユーザがオンラインになると（ネットワークに接続）、ユーザは、保存されたインスタントメッセージの全てを、例えば、暫定特許出願「インスタントメッセージングのための方法および装置」に記載の機構を適用することによってリトリーブすることができる。しかしながら、本機構は、保存されたインスタントメッセージの「全て」に対して動作する。

上述の第１の実施形態により、１つであり厳密に１つであるインスタントメッセージ（メッセージがSIP MESSAGE要求で配信された場合）、インスタントメッセージの１つであり厳密に１つであるセッション（メッセージが、SIP INVITEおよび多数のMSRPS END要求を使用して蓄積された場合）、または１つであり厳密に１つであるMSRP SENDメッセージ、のうちのいずれかをユーザが選択してリトリーブできるようになる。ユーザが、複数のインスタントメッセージ、インスタントメッセージの複数のセッション、または同一セッションに属する複数の（全てではない）MSRP SEND メッセージをリトリーブしたい場合、リトリーブの度に、ユーザが個別のSIPセッションをメールサーバに対して確立しなければならない（つまり、ユーザは、個別のSIP INVITE要求を送信しなければならない）ことから、この機構により問題が生じる。

これにより、特に移動環境において問題が発生することは明らかである。一方で、これにより、1.5往復（INVITE-200-ACK）が信号伝達フローに追加されるため、連続的にメッセージをリトリーブする場合に遅延が生じる。さらに、これらのINVITE要求の各々は多数のヘッダを含むため、ユーザエージェントとメールサーバとの間で転送されるバイト数は少なくない。

第２の実施形態によると、以下が仮定される。
・特定のユーザ宛てのインスタントメッセージは、メールサーバに蓄積されている。
・リトリーブすることを保留中のインスタントメッセージのサマリについて、ユーザが報告を受ける機構が適宜存在する。本機構には、メールサーバのメッセージ毎に固有識別子が含まれる。このような機構の例は、RFC3842「セッション開始プロトコル（SIP）のための、メッセージサマリおよびメッセージ待機指示表示」に記載される。
・保存されたインスタントメッセージの固有識別子を、リトリーブに有効な識別子にマップすることをユーザができるようにする機構が存在する。このような機構の例は、第１の実施形態に記載される。
・ユーザがセッションを確立して、１つ以上の保存されたインスタントメッセージをリトリーブ可能になる機構が存在する。このような機構の例は、暫定特許出願「インスタントメッセージングのための方法および装置」に記載される。

第２の実施形態によると、保存メッセージASまたはメールサーバホストは、以下を備える仮想エンティティとしてモデル化される。
・参照することによってその内容が本明細書に組み込まれる「セッション開始プロトコル（SIP）における要求が含まれるリストを使用した会議確立」のdraft-ietf-sipping-uri-list-conferencing-03.txtに準拠した、会議サーバとしても既知である、SIP INVITEトランザクション用のURIリストサーバエクスプローダ。
・同一のメールサーバホストに含まれる１つ以上の仮想SIPユーザエージェント。本仮想SIPユーザエージェントはリソースを表し、本発明においてこのリソースは、効果的に保存されたインスタントメッセージまたはインスタントメッセージのセッションである。各インスタントメッセージまたはインスタントメッセージのセッションは、固有の統一リソース識別子（Uniform Resource Identifier; URI）によって識別されることを特徴とする。

図5は、メールサーバホスト（インスタントメッセージメールサーバ）のモデル図であり、会議サーバと、各々が保存されたインスタントメッセージを表す多数の仮想SIPユーザエージェンとを内蔵する。

図6は、第２の実施形態に係る、ユーザとインスタントメッセージメールサーバとの間で交換されるメッセージを示す信号伝達図を示す。

メールサーバが図のようにモデル化されると、ユーザは、単一のSIPセッションを設定することによって保存されたインスタントメッセージの選択をリトリーブしたい場合に、ユーザエージェントは、２つのメッセージ本文を含む単一のSIP INVITE要求（メッセージ#1）を送信する。この２つのメッセージ本文とは、インスタントメッセージセッションを設定するためのセッション記述プロトコル（RFC2327）とURIリスト（draft-ietf-sipping-uri-list-conferencing-03.txtに表示される）とである。SDPにより、MSRP（draft-ietf-simple-message-sessions-l2.txt）に基づいて、少なくとも１つのメッセージ媒体ストリームを確立する意志が示される。URIリストには１つ以上のURIが含まれ、その各々は、サーバにおけるユーザがリトリーブしたい保存インスタントメッセージを一意的に識別する。メールサーバは、MSRPに基づいたメッセージ媒体ストリームを示すSDPを含む200 OK応答（メッセージ#2）で回答する。

このようなINVITE要求を受信すると、メールサーバの会議サーバ部分は、保存されたメッセージを識別する各仮想SIPユーザエージェントにINVITE要求をエクスプロードする。会議サーバは、着信するINVITEのURIリストに示されるURIの各々に、SDP含むINVITE要求を送信する。すなわち、メールサーバの会議サーバは、INVITE（#1）のURIリストに含まれるURIの各々に、INVITE要求を送信する。図6には、INVITE要求#4、#5、および#6が存在する。その各々には、MSRPに基づいた少なくとも１つのメッセージ媒体ストリームを確立する意志を示すSDP本文が含まれる。

これにより、エンドユーザと、所定のメッセージを識別する各仮想SIPユーザエージェントとの間で仮想集中型会議が生成される。次に、これらの仮想SIPユーザエージェントの各々は、保存されたインスタントメッセージを会議サーバに送信し、次に、この会議サーバは、それらをエンドユーザに中継する。すなわち、仮想SIPユーザエージェントは、それ自身のSDPを含む200 OKメッセージ（図6のメッセージ#7、#8、および#9）で回答し、次に、保存されたメッセージ（またはインスタントメッセージのセッション）を、例えば、暫定特許出願「インスタントメッセージングのための方法および装置」に示される手順を適用することによって送信する（これは、図6の残りのメッセージ#13から#24に対応する）。

具体的には、各仮想SIPユーザエージェントは、保存されたMESSAGEを取り込み、SIP MESSAGE要求の該当するヘッダ（例えば、From、To、Call-ID、P-Asserted-Identityなど）を保持し、それをmessage/sip（RFC3261の第２7.5章）またはmessage/sipfrag（RFC3420）のいずれかとしてカプセル化し、それをMSRP SEND要求（図6のメッセージ#13、#17、#21）のペイロードとして送信する。

同様に、各仮想SIPユーザエージェントは、保存されたSIP INVITEメッセージ、対応する保存されたMSRP SEND要求、および対応する保存されたSIP BYEメッセージを取り込んで、message/sipまたはmessage/sipfragに設定されるメッセージタイプで、それらを別のMSRP SEND要求（メッセージ#13、#17、#21）にカプセル化してもよい。同様に、各仮想SIPユーザエージェントは、保存されたMSRP SEND要求を取り込み、それをmessage/msrpとしてカプセル化し、それをMSRP SEND要求（#13、#17、#21）のペイロードとして送信してもよい。

本発明は、全ての起こり得る組み合わせおよび置換に及ぶ。例えば、MSRP SEND要求#13は、保存されたMSRP SEND要求をカプセル化可能で、一方 MSRP SEND要求#15は、SIP MESSAGE要求をカプセル化可能である。あるいはMSRP SEND要求#17は、そのセッションの一部として送信された全てのMSRP SEND要求を含むSIP INVITE要求と、SIP BYE要求とをカプセル化可能である。

仮想SIP UAが、その保存されたインスタントメッセージをサーバに配信すると、仮想SIP UAはBYE要求（図6のメッセージ#25、#27、および#29）を会議サーバに送信してセッションを終了させる。最後の仮想SIP UAが接続を絶つと、会議サーバは、BYE要求（メッセージ#31）をユーザに送信し、セッションを終了させる。

最後に、エンドユーザは、保存されたインスタントメッセージの選択を、たった一度の信号伝達セッションで受信する。

会議サーバと、各々が保存されたインスタントメッセージを表す多数の仮想SIPユーザエージェントとを備えるように考えられることに留意されたい。より理解するためにさらに分解されるメールサーバのモノリシック実装が考えられる。しかしながら、これは、実装を制限するものではなく、実装により、異なるホストにおいて、メールサーバの各構成要素を分離することを決定してもよい。この場合、用語としての「メールサーバ」は、これらのホストをまとめて言及するように使用される。

また、メールサーバのモノリシック実装の場合、会議サーバと各SIP仮想ユーザエージェントとの間に規定されるインターフェースは、内部呼び出しまたは規定されるAPIになるが、必ずしもSIPで実装される必要はない。

本発明の実施形態が、オフラインメッセージの「プッシュ」配信機構にも適用可能であることに留意することが重要である。プッシュ配信システムにおいて、保存メッセージアプリケーションサーバは、例えば、SIP SUBSCRIBE／NOTIFYおよび／またはその他の任意の機構により、ユーザがオフラインからオンラインに戻る時間を把握する。

上記記載は、本発明に関する説明であり、本発明を限定するものとして解釈されないことを理解されたい。添付の請求項に定義される本発明の精神および範囲から逸脱することなく、当業者によって種々の修正および用途が考えられてもよい。

Claims

メールサーバに保存された、それぞれ固有識別子に関連付けられた複数のメッセージであって、ユーザがリトリーブすることを保留中の複数のメッセージのサマリを受信する手段と、
前記複数のメッセージのサマリに基づいて、前記メールサーバからリトリーブされる前記メッセージのうちの少なくとも１つを選択するための手段と、
前記少なくとも１つのメッセージに関連付けられた前記固有識別子に基づいて、前記少なくとも１つのメッセージのリトリーブに有効な識別子を決定することによって、リトリーブに有効な少なくとも１つの識別子を取得するための手段と、
リトリーブに有効な前記少なくとも１つの識別子を有するリトリーブ要求を、前記メールサーバに送信するための手段と、
を備える、端末装置。
前記固有識別子は前記メールサーバによって提供されるメッセージ識別子である、請求項1に記載の端末装置。
前記固有識別子は統一リソース識別子（Uniform Resource Identifier; URI）である、請求項1に記載の端末装置。
ユーザがリトリーブすることを保留中の複数のメッセージを保存するためのネットワーク装置であって、
前記保存されたメッセージのうちの少なくとも１つのメッセージをリトリーブするために有効な少なくとも１つの識別子を有する、リトリーブ要求を受信するための受信手段と、
前記リトリーブ要求を送信した前記ユーザの端末装置に、前記少なくとも１つのメッセージを送信するための送信手段と、
を備える、ネットワーク装置。
前記送信手段は、メッセージセッションリレープロトコル（Message Session Relay Protocol; MSRP）のSEND メッセージにおいて、前記少なくとも１つのメッセージを送信するように構成される、請求項4に記載のネットワーク装置。
前記保存されたメッセージ毎に、メッセージ識別子を提供するための提供手段をさらに備え、
前記送信手段は、前記保存されたメッセージのサマリを前記ユーザに送信するように構成され、各メッセージは、前記提供されメッセージ識別子に関連付けられる、請求項4に記載のネットワーク装置。
前記提供手段は、前記保存されたメッセージの各々のセッション開始プロトコル要求に含まれるCall-IDヘッダフィールドを、前記提供されたメッセージ識別子に使用するように構成される、請求項6に記載のネットワーク装置。
前記提供手段は、前記保存されたメッセージの各々のメッセージセッションリレープロトコル要求のMessage-IDヘッダフィールドを、前記提供されたメッセージ識別子に使用するように構成される、請求項6に記載のネットワーク装置。
前記提供手段は、固有の統一リソース識別子（Uniform Resource Identifier: URI）を生成するように構成され、前記URIは、前記ネットワーク装置にルーティング可能であり、前記提供されたメッセージ識別子は、前記URIの一部である、請求項6に記載のネットワーク装置。
メールサーバに保存され、かつユーザがリトリーブすることを保留中のメッセージを受信する方法であって、
前記メールサーバに保存され、かつ前記ユーザがリトリーブすることを保留中の複数のメッセージのサマリを受信することであって、ここで各メッセージは固有識別子と関連付けられている、ことと、
前記複数のメッセージのサマリに基づいて、前記メールサーバからリトリーブされる前記メッセージのうちの少なくとも１つを選択することと、
前記少なくとも１つのメッセージに関連付けられた前記固有識別子に基づいて、前記少なくとも１つのメッセージのリトリーブに有効な識別子を決定することによって、リトリーブに有効な少なくとも１つの識別子を取得することと、
リトリーブに有効な前記少なくとも１つの識別子を有するリトリーブ要求を、前記メールサーバに送信することと、
を含む、方法。
ユーザがリトリーブすることを保留中の保存されたメッセージをリトリーブする方法であって、
前記保存されたメッセージのうちの少なくとも１つのメッセージをリトリーブに有効な少なくとも１つの識別子を有する、リトリーブ要求を受信することと、
前記リトリーブ要求を送信した前記ユーザの端末装置に、前記少なくとも１つのメッセージを送信することと、
を含む、方法。
前保存されたメッセージ毎にメッセージ識別子を提供することと、
前記保存されたメッセージのサマリを前記ユーザに送信することであって、各メッセージは前記提供されたメッセージ識別子に関連付けられることと、
をさらに含む、請求項11に記載の方法。
ユーザがリトリーブすることを保留中の複数のメッセージを保存するためのネットワーク装置であって、
会議サーバと、
前記保存された複数のメッセージに対応する複数のエンドポイントと
を備え、前記会議サーバが、前記保存されたメッセージのうちの選択されたメッセージを各々標示する識別子のリストを含むリトリーブ要求であって、前記選択されたメッセージを配信するために第１のセッションを確立するリトリーブ要求を前記ユーザから受信し、前記リストにおいて識別された前記選択されたメッセージ毎に、該選択されたメッセージに対応する前記仮想エンドポイントと第２のセッションを確立し、前記第２のセッション内で前記選択されたメッセージを受信すると共に前記第１のセッション内で前記選択されたメッセージを前記ユーザに転送する、ように構成される、ネットワーク装置。
前記仮想エンドポイントは、仮想セッション開始プロトコル（Session Initiation Protocol; SIP）ユーザエージェントである、請求項13に記載のネットワーク装置。
メールサーバに保存され、かつユーザがリトリーブすることを保留中のメッセージをリトリーブする方法であって、
前記保存されたメッセージのうちの選択されたメッセージを各々標示する識別子のリストを含むリトリーブ要求を受信することであって、前記リトリーブ要求は、前記選択されたメッセージを配信するために第１のセッションを確立することと、
前記リストにおいて識別された前記選択されたメッセージ毎に、第２のセッションを確立することと、
該第２のセッション内で前記選択されたメッセージを受信し、該第１のセッション内で前記選択されたメッセージを前記ユーザに転送すること、
を含む、方法。
処理装置用のプログラムを含むコンピュータプログラムであって、前記プログラムが前記処理装置上で作動される場合に、請求項10から12または15のうちのいずれかに記載のステップを実行するためのソフトウェアコード部分を含む、コンピュータプログラム。
前記コンピュータプログラムは、前記ソフトウェアコード部分が保存されるコンピュータ可読媒体を備える、請求項16に記載のコンピュータプログラム。
前記プログラムは、前記処理装置の内部メモリに直接ロード可能である、請求項16に記載のコンピュータプログラム。