JP2008533807A - メッセージを受信者に配信するための通信システムにおける方法とシステム構成 - Google Patents

Abstract

通信システムにおいて通信メッセージを受信者に配信するための、記載されているメッセージング装置は、いくつかのメッセージング・サーバ（２０１〜２０４）、共通のメッセージ・ストア（２０５）およびディスパッチャ（２０６）を備えている。メッセージング・サーバ（２０１〜２０４）は、受信者宛のメッセージを受信し、そのメッセージを共通のメッセージ・ストアに保存し、共通のメッセージ・ストアに保存し終わった受信メッセージをディスパッチャに知らせることができる。ディスパッチャは、それから、そのメッセージの受信者への配信のためにいずれのメッセージング・サーバを起動するかを決めるように、設定されている。この決定は、受信者の配信の好みに基づいて行うることができる。その後、ディスパッチャは、そのメッセージを配信するように決められたメッセージング・サーバを起動し、決められたメッセージング・サーバがそのメッセージを読み出し、受信者に配信する。必要であれば、決められたメッセージング・サーバは、そのメッセージを、決められたメッセージング・サーバにより処理されるメッセージ・タイプに適合させる。この解決策により、受信者は、メッセージを、発信元のメッセージ・タイプに係わらず、任意の好適なメッセージ・タイプで受信することができる。また、この処置は、電話会社が新しいメッセージ・タイプを処理する新しいメッセージング技術をシステムに組み込むことをより容易にする。

Description

本発明は、通信システムにおける方法とシステム構成に関するものであり、特に、受信者とメッセージの送り手との通信を容易にするように、メッセージを受信者に配信するための方法とシステム構成に関するものである。

すべての通信世界において、現在我々が経験しているように、音声、データ、画像および映像のようなメディア・タイプは、世界中どこでもいつでも便利に交信されており、それによって生活の質と生産性とを向上させ、より資源効率のよい世界を可能にしている。メッセージングは、そのような世界でエンドユーザにとって鍵となるサービスである。そのような世界において、人々は、それぞれの通信相手の能力を気に掛けることなく、自身の好みのやり方でメッセージを送信し、受信することができるであろう。

エンドユーザの経験を豊かにし、そのエンドユーザがメディア形式をより自由に選べることができるように、メッセージング・サービスの能力が絶えず改良されている。しかし、これらの改良が、新しい技術を有するユーザにとって呼びかけのできる通信相手の集合の分裂を招くことがあってはならない。すなわち、新しいメッセージング・サービスや技術を有するユーザが、そのメッセージング・サービスや技術が可能な他のユーザとしか通信ができないような状況を招くべきではない。それゆえ、統合されたメッセージの世界に円滑に移行できるように、新しいメッセージング技術と確立したメッセージング技術との相互作用のための機能をサポートする取り組みが行われている。

電気通信分野におけるマルチメディアおよび３Ｇの出現で、重要な技術上の飛躍的な進歩が到来している。メディアのタイプを、通信の基盤でありメディアが通信方法を決めることに依存しなくてはならないものと、もはや考える必要はない。場所や時間を考慮したり、通信手段の選択がそのような要因に基づく必要はいずれもない。技術的には、３Ｇおよびマルチメディアが、どこでも、いつでも、任意のメディア・タイプ（映像、音声、画像およびテキスト）およびそれらの組み合わせを用いて通信することを可能にしている。しかしながら、その導入は、当初は、全てのユーザを一度に最新の技術に高めることはできないので、通信能力の分裂をきたす。一般に、ＳＭＳおよび移動電話の成功は、本人認識の確実性と連携するサービスの重要性を示している。

以上のように、エンドユーザは、完全に自身の通信要求に基づいて通信方法を決めることを望むということが、見出されてきた。たとえば、メッセージを送信するユーザは、自身の現在の要求に叶った形式でそのメッセージを送信できることを望み、そのメッセージを受信するエンドユーザは、自身の現在の要求に叶った形式でそのメッセージを受信することを望んでいる。

エンドユーザ間、すなわちメッセージの発信者からメッセージの受信者へのメッセージングを可能にする大抵の先行技術による解決策は、垂直型アーキテクチャに基づいており、そこでは各々のメッセージングの解決策は、単独で動作、すなわち、それ自身のプロビジョニングやサービス管理等に対する機能性を有する。

図１は、垂直型メッセージング・アーキテクチャを有する通信システムを示しており、現在、通例は電話会社により配備されている。ここで、各々のメッセージング・サービスないしメッセージ・タイプ、たとえばＩＰメッセージング（ＭｏＩＰ: Messaging over IP）、マルチメディア・メッセージング・サービス（ＭＭＳ: Multimedia Message Services）、インスタント・メッセージング（ＩＭ: Instant Messaging）、ショート・メッセージ・サービス（ＳＭＳ: Shoet Message Services）は、そのエンドユーザのドメインに設定されるそれ自身のクライアント、たとえばＳＭＳクライアント、ＭＭＳクライアント、インスタント・メッセージングとプレゼンス・サービス（ＩＭＰＳ: Instant Messaging and Presence Service）クライアント、およびそれ自身のサービス・センタ、たとえばＭｏＩＰセンタ、マルチメディア・メッセージング・センタ（ＭＭＣ: Multimedia messaging Centre）、ＳＭＳ−ＣおよびＩＭＰＳサービス・センタをもたらす。

このような解決策では、各々のサービス・センタは、それ自身のメッセージ・ストア、それ自身のディレクトリ、自身の通知サーバおよびしばしば自身のＯ＆Ｍシステムを有する。そのＭｏＩＰサービス・センタは、ボイス・メール、ウェブ・メールおよび電子メール・サービスを処理する、エリクソンのシステムである。この垂直型メッセージング・アーキテクチャは、また、その異なるメッセージング・サービスに対して共通のサービス・ネットワーク・ドメイン内にいくつかの機能、たとえば共通ディレクトリ、およびプロビジョニング、課金、Ｏ＆Ｍおよび認証に共通の機能を有する。そのアーキテクチャは、また、他のネットワークとの通信のためのボーダ・ゲートウェイ、たとえばボイス・ゲートウェイ、プッシュ・プロキシ・ゲートウェイおよびＷＡＰゲートウェイを有する。

その通信システムは、また、ビジネス管理ドメイン、ネットワーク管理ドメインおよびアプリケーション・ドメインとの接続部を備えている。アプリケーション・ドメインとの接続は、付加価値サービス・プロバイダのゲートウェイ（ＶＡＳＰ ＧＷ）を介して可能である。マルチメディア・ライブラリ（ＭＭＬ: Multimedia Library）が、また備わっており、たとえばユーザに対するＭＭＳメッセージを保存する。そのＭＭＬは、また、ユーザがそのＭＭＬから他のマルチメディア・コンテンツにアクセスするのを可能にしている。それによって、そのＭＭＬは、ストレージ、内容検索イネーブラとして機能し、そしてメッセージの共有を可能にしている。

垂直型解決策を配備した経験から、共通の機能性がないことが、そのシステムにおいて付加的なノードないしメッセージングの解決策ごとに対し、一体化と運用のコストが１０倍に増加することは明らかである。また、垂直型解決策が、移動通信サービスのような通信サービスの配備にとって、極めて長い時間がかかることを経験的に知っている。それゆえ、たとえば通信サービスの電話会社および他のプロバイダから、垂直型メッセージング・アーキテクチャから、異なるメッセージング・サービスに対して、一部の機能性が共通である水平型メッセージング・アーキテクチャに向けて切り替えるという要望がある。

以上のように、ユーザには、そのユーザ自身のその時点の通信要求および通信能力に基づいて誰とでも通信できるという要求がある。また、電話会社には、そのメッセージング・アーキテクチャが、新しいメッセージ・タイプを処理する新しいメッセージング技術を容易に追加されることができそうな水平型メッセージング解決策／アーキテクチャを提供できるという要求がある。

そのアプリケーションにおいて、メッセージ・タイプは、特定のメッセージング・サーバにより処理されるメッセージとして定義される。たとえば、通常、電子メール・サーバは、メッセージ・タイプの電子メールを処理し、ボイス・メール・サーバは、メッセージ・タイプのボイス・メールを処理し、そしてＭＭＳサーバは、メッセージ・タイプのＭＭＳメッセージを処理する。また、１つのメッセージング・サーバが、複数種のメッセージを処理することもできるだろう。その結果、メッセージ・タイプという文言は、実際に複数種のメッセージ、たとえばＭＭＳおよびＳＭＳを含むことができる。

本発明の目的は、元のメッセージ・タイプにかかわらず、メッセージが特定のメッセージ・タイプとして受信者に受信されるように、通信システムにおけるメッセージを受信者に配信するための方法およびシステム構成を提供することである。

本発明の別の目的は、新しいメッセージ・タイプがシステム構成にごく少しの変更をした方法およびシステム構成により処理されることが可能になるように、通信システムにおけるメッセージを受信者に配信するための方法およびシステム構成を提供することである。

上述の目的は、独立クレームを特徴付ける部分で説明されている方法およびシステム構成により達成される。

第１の側面に照らして、本発明は、通信メッセージを受信者に配信するための通信システムにおける方法に係わる。

その通信システムは、異なるタイプのメッセージを処理するいくつかのメッセージング・サーバであって、各々のメッセージング・サーバは特定のメッセージ・タイプのメッセージを処理するメッセージング・サーバと、いくつかのメッセージング・サーバのいずれかから受信されたメッセージを保存するための共通のメッセージ・ストアと、受信者へのメッセージ配信を処理するディスパッチャとを備える。

その方法は、受信メッセージング・サーバにおいて、メッセージの受信者宛のメッセージを受信する工程と、共通のメッセージ・ストアにメッセージを保存する工程と、受信メッセージ・サーバにより、ディスパッチャに受信メッセージを通知する工程と、ディスパッチャにより、メッセージの配信のためにいずれのメッセージング・サーバを起動するかを決定する工程と、ディスパッチャにより、メッセージを配信するように決定されたメッセージング・サーバを起動する工程と、決定されたメッセージング・サーバで、メッセージ・ストアからメッセージを受信する工程と、メッセージが、決定されたメッセージング・サーバにより処理されるメッセージ・タイプと異なるタイプである場合、メッセージを決定されたメッセージング・サーバにより処理されるメッセージ・タイプに適合させる工程と、メッセージを受信者に配信する工程とを有する。

第２の側面に照らして、本発明は、通信メッセージを受信者に配信するように適合された通信システムにおけるシステム構成に係わる。

その通信システムは、異なるタイプのメッセージを処理するように適合されているいくつかのメッセージング・サーバであって、各々のメッセージング・サーバは特定のメッセージ・タイプを処理するように適合されているメッセージング・サーバと、メッセージング・サーバのいずれかから受信されたメッセージを保存するように適合された共通のメッセージ・ストアと、受信者へのメッセージ配信を処理するように適合されたディスパッチャとを備える。

いくつかのメッセージング・サーバの各々は、さらに、メッセージの受信者宛のメッセージを受信する手段と、ディスパッチャに受信済みメッセージを通知する手段と、メッセージがメッセージ・サーバにより処理されるメッセージ・タイプと異なるタイプである場合、メッセージをメッセージング・サーバにより処理されるメッセージ・タイプに適合させる手段と、メッセージを受信者に配信する手段とを有する。

ディスパッチャは、さらに、メッセージの配信のために、いずれのメッセージング・サーバを起動するかを決定する手段と、メッセージを配信するように、決定されたメッセージング・サーバを起動する手段とを有する。

第３の側面に照らして、本発明は、通信メッセージの受信者への配信を処理するように設定された通信システムおけるノードに係わるものである。

その通信システムは、異なるタイプの通信メッセージを処理するためにいくつかのメッセージング・サーバを有し、各々のメッセージング・サーバは、特定のメッセージ・タイプのメッセージを処理するように設定されている。

そのノードは、通信システムにおける他の構成要素との通信用に設定された通信インタフェースと、メッセージの受信者への配信を制御するためのルート決定ユニット及びスケジューリング・ユニットとを備える。

そのノードは、さらに、通信インタフェースで、メッセージング・サーバから、メッセージング・サーバで受信されたメッセージについての通知を受信する手段と、受信者の配信の好みに基づいて、メッセージの配信を担うメッセージング・サーバを決定する手段と、メッセージを配信するように、決定されたメッセージング・サーバを起動する手段とを有する。

第４の側面に照らして、本発明は、通信メッセージの受信者への配信を処理する通信システム内のノードにおける方法に係わるものである。

その通信システムは、異なるタイプの通信メッセージを処理するためにいくつかのメッセージング・サーバを有し、各々のメッセージング・サーバは、特定のメッセージ・タイプのメッセージを処理するように設定されている。

その方法は、メッセージング・サーバから、そのメッセージング・サーバで受信されたメッセージについての通知を受信する工程と、受信者の配信の好みに基づいて、メッセージの配信を担うメッセージング・サーバを決定する工程と、メッセージを配信するように、その決定されたメッセージング・サーバを起動する工程とを有する。

本発明の長所は、そのエンドユーザに、本人の全てのメッセージに共通のメールボックスを提供することである。

本発明のさらなる長所は、その通信システムの電話会社に、共通の機能および要素の再使用および共有に基づいて、水平型に統合されたメッセージング解決策を提供することである。それによって、その電話会社が、新しいメッセージ・タイプを処理する新しいメッセージング技術をそのシステムに一体化することがより容易になるであろう。

更なる長所は、メッセージの発信者から送信されたときのメッセージのメッセージ形式ないしタイプに係わらず、エンドユーザがエンドユーザにより定義された形式ないしタイプでメッセージを受信できるようにすることである。

本発明の別の長所は、実際のメッセージが、メッセージの処理方法に関する要求に従わないという事実によっている。それによって、メッセージが、メッセージングシステム内に余計に送信されることなく、それによってシステムに余計な負荷を加えることが避けられる。

さらに別の長所は、本発明が、実時間に近い特性が必要とされるとき、たとえばチャット・セッションにおいて、ディスク・ストレージによりもたらされる待ち時間を避けるために、メッセージの最適化された直接配信を可能にすることである。さらに、本発明により提供される直接配信は、本発明の中で説明されている蓄積機能および転送機能に対するフォールバックを、常にいつでも有している。

本発明は、以下で、添付の図面を参照しながらさらに詳しく説明されるであろう。

本発明が、下文に、本発明の好適な実施形態が示されている添付図面を参照しながら、より完全に説明されるであろう。しかしながら、本発明は、多くの異なる形で実施されることができ、そして本明細書で説明されている実施形態に限定されるものと解釈されるべきではない。むしろ、これらの実施形態は、この開示が完全かつ欠けたところがなく、そして当業者には本発明の範囲を十分伝えることになるように提供されている。図面では、同じ番号は同じ要素を参照している。

本発明に準拠したメッセージングシステムおよび方法は、エンドユーザの要求に対応する永続的なメッセージング・ビジネスを設立するという要望を反映している。ごく少数のユーザのみがお互いに通信できるとか、あるいは技術シフトの苦労がエンドユーザに課せられるような、技術の孤立化(technoligy island)を作り出すことなくこれらの要求をかなえる、より高度な方法に移る特別な挑戦がある。本発明に準拠したメッセージングシステムおよび方法は、他のエンドユーザにより使用されている旧来の技術によって設定される制限に対処し、メッセージング・サービス間の相互作用をできるようにしながら、上級のエンドユーザに対して一貫したメッセージング・サービスを保証することが狙いである。

これまでに説明してきた基準の全てを考慮して、本発明の実施形態に準拠したシステムが、図２に示されているように設定されることができる。

図２の装置は、いくつかのメッセージング・サーバを備えており、各々のメッセージング・サーバが１つのメッセージ・タイプを処理する、ボイス・メールを処理するボイス・メール・サーバ２０１、ＭＭＳメッセージを処理するＭＭＳサーバ２０２、電子メールを処理する電子メール・サーバ２０３、およびＸＸＸサーバ２０４を現している。ＸＸＸサーバは、任意の他のメッセージ・タイプを処理するための任意の他のメッセージング・サーバを象徴している。

メッセージング・サーバ２０１−２０４は、各々のメッセージング・サービスに対するビジネス・ロジックを含んでおり、そこでの１つの重要な側面はプロトコルの処理である。メッセージング・サーバは、システムの外部から、たとえば移動端末２１１からのメッセージを受信し、ディスパッチャ２０６に受信済みメッセージを通知し、メッセージをメッセージ・ストア２０５に送信し、そして移動端末２１２のような受信者にメッセージを配信するように設定されている。

そのシステムは、また、上で簡単に触れた２つのメッセージング・イネーブラ、メッセージ・ストア２０５およびディスパッチャ２０６を備え、それらはメッセージング・サーバ２０１−２０４と接続されている。メッセージ・ストア２０５は、メッセージ・タイプ、たとえば電子メール、ＭＭＳ、ボイス・メール、ビデオ・メール、インスタント・メッセージの蓄積および転送等に係わらず、受信者の全てのメッセージを含む、受信者あたり１つのメールボックス・ディレクトリをホスティングするファイル・サーバである。

受信者は、最も普通の場合、エンド・ユーザである。とはいえ、中継の場合、たとえば第１の電話会社の第１の通信システムから別の電話会社の第２の通信システムに送信されるメッセージに対しては、図８に関連してさらに説明されているように、受信者は、第１の通信システムにあるメッセージングシステムの観点からは、第２の通信システムと見なすことができ、それ自身のメールボックスを第１の通信システム内のメッセージ・ストアに有している。たとえば、ＭＭＳ内の各々のＭＭ４の宛先は、着信／発信トラヒック用にそれ自身のメールボックスを有している。ＭＭ４は、ＭＭＳ参照アーキテクチャのインタフェースである。ＭＭ４は、１つのＭＭＳサーバと他のマルチメディア・メッセージ環境にある別のＭＭＳサーバとの間の参照点である。ＭＭ４および他のＭＭＳインタフェースは、２００４年６月に発行された３ＧＰＰ技術仕様書ＴＳ＿２３．１４０＿バージョン＿５．１１．０の第６章に説明されている。そのメッセージ・ストアは、すべての異なるタイプのメッセージを保存する共通のメッセージ・ストアである。各々のメールボックスは、少なくとも１つのインボックスおよび１つのアウトボックス・ファルダを有するが、また、送信される項目等に対する他のフォルダも有することができる。

ディスパッチャ２０６は、メッセージングシステムの心臓部であり、メッセージが配信されることを保証する。ディスパッチャ２０６は、２つのはっきりと異なる部分を備える。すなわち、メッセージの配信にいずれのメッセージング・サーバ・タイプを使用するかを決定するルート・リゾルバと、メッセージをいつ起動するかを決定するタイマー機能、すなわちスケジューラとである。ディスパッチャ２０６は、メッセージの配信のためにいずれかのメッセージング・サーバを起動し、そして受信者の好み、たとえばユーザのプロファイルやプレゼンス等に基づいて、いつ配信するかを決定するように設定されている。受信者の好みを調べるために、システムは、共通ディレクトリ２０７およびプレゼンス・サーバ２０８と関連付けられることができる。共通ディレクトリ２０７および／またはプレゼンス・サーバ２０８は、そのとき、ディスパッチャが受信者の好みを調べるために、ディスパッチャ２０６により連絡を取ることができる。結果として、ディスパッチャは、また、メッセージを受信者に配信するために、決定されたメッセージング・サーバを起動するように設定されている。

図２のシステムに対して、以下に、本発明の典型的な実施形態に準拠した手順が説明されている。その手順は、また矢印で説明されており、極太で描かれた矢印は、メッセージが発信者、たとえば第１の移動端末２１１から、受信者、たとえば第２の移動端末２１２まで取ることのできる異なるルートを示している。通常の太さの矢印は、信号のみを示している。信号は、また極太の矢印上で送ることもできる。

最初に、メッセージング・サーバ２０１−２０４が、メッセージを受信する。そのメッセージング・サーバは、それから、同じメッセージ・タイプでそのメッセージの受信者への直接配信が適切であるかどうかを調べるために、ディスパッチャにオプションのルート探索メッセージを送信することができる。その後、オプションのルート探索メッセージに対するディスパッチャからの応答に、そのメッセージを直接配信するように、メッセージング・サーバに対する起動が含まれている場合、メッセージング・サーバはそのメッセージを受信者に配信する。そうでない場合、すなわち、ルート探索メッセージが送信されない場合、メッセージング・サーバは、そのメッセージをメッセージ・ストア２０５に送信し、メッセージ・ストア２０５にある受信者のインボックスにメッセージを保存する。

メッセージング・サーバは、また、ディスパッチャ２０６に新たに到来したメッセージを通知する。ディスパッチャに送信される最も重要な情報は、ルーティング情報（受信者／宛先ＩＤ）およびメッセージ参照である。付加的な情報は、メッセージ・タイプおよびコンテンツ・タイプを含む。ディスパッチャ２０６がこの情報を受信すると、たとえば受信者の好み、たとえばユーザ・プロファイルやプレゼンス等に基づいて、そのメッセージの配信のためにいずれのメッセージング・サーバを起動するか、およびいつ起動するかを決定する。この決定は、受信者の好みに基づいていること以外に、また、メッセージング・サーバにかかる負荷のような、メッセージの配信の可能性に関連する他の属性に基づくこともできる。

ディスパッチャは、メッセージが後で配信されることになる場合、あるいは、再試行がメッセージに対してスケジュールされなければいけない場合、すなわち、もしそのメッセージが初めての配信ではその受信者にうまく配信されなくて、メッセージが再送されなければならない場合にも、また処理をする。スケジュールされた時間になると、ディスパッチャは、決定されたメッセージング・サーバ、すなわちディスパッチャにより選定されたメッセージング・サーバを起動する。メッセージング・サーバは、そのとき、アプリケーション・ルールに従ってそのメッセージをそのエンドユーザに配信することを担っている。実際のメッセージと、そのメッセージをどのように処理するかという要求とを切り離すことにより、メッセージは、メッセージングシステムの中で不必要に送信されることはなく、システムに不必要な負荷を掛けることはないであろう。

もし、受信者がそのメッセージが配信される前に通知を受ける方がよければ、この通知手順は、決定されたメッセージング・サーバの役目になる。これはその通知手順が、しばしば各々のメッセージング・サービスに固有であるからである。たとえば、ボイス・メール通知およびＭＭＳ通知は、全く異なる。ディスパッチャのタスクは、ちょうど、たとえばユーザの好みに基づいて正しいメッセージング・サーバを起動することである。メッセージの受信者が複数の場合、ディスパッチャは、各々の受信者の好みに基づいて受信者あたり１つのメッセージング・サーバ・インスタンスを起動する役目を有する。これは、たとえば、幾人かの受信者に対してはＭＭＳとして、他の受信者に対してはＳＭＳとして、そのメッセージが配信されることになるであろう。

図３は、図２に従ったそのメッセージングシステムを経由するメッセージの流れの例を示している。図３で、同じメッセージング・サーバ２０１−２０４が実際には２度示されていることに注目されたい。これは、図３の左側の部分にあるシステムに入ったときから、受信者に配信されて図３の右側の部分にあるシステムを離れるまで、メッセージがそのメッセージングシステムによりどのように処理されるかをよく示すためになされている。

１．メッセージが、メッセージング・サーバ２０１-２０４(プロトコル・ハンドラー）のいずれかにより受信され、そのメッセージング・サーバは（スパムおよびウィルス・コンテンツに対して）そのメッセージを検査し、メッセージ・ストア２０５内にある受信者のインボックスに保存されるように、メッセージ・ストアにメッセージを送信することができる。ディスパッチャ２０６は、メッセージ・ストアに新しいメッセージの到着があったことの通知を受ける。オプションとして、そのメッセージが共通のメッセージ・ストアに保存される前に、そのメッセージング・サーバは、ディスパッチャにルート探索メッセージを送信し、そのメッセージの受信者への直接配信が適切であるかどうかを調べることができる。もしそうであれば、メッセージング・サーバは、同じメッセージング・タイプを使用してそのメッセージを直接受信者に配信するであろうし、そのメッセージはメッセージ・ストアに保存されないであろう。

２．ディスパッチャ２０６は、そのメッセージがユーザ・プロファイル等のような受信者に関連する属性に基づいてどのように配信されるべきかを調べ、その結果に応じて、そのメッセージを配信すべきいずれかのメッセージング・サーバを選定する。トリガーが掛けられたとき（すぐにであろう）、選定されたメッセージング・サーバを起動するようなイベントがスケジュールされる。

３．メッセージ・ストア２０５は、受信者毎を基にしたメッセージ待ち行列として機能し、待ち行列からの取り外しはランダム・アクセスでディスパッチャにより制御される。任意の発信の宛先は受信者と見なされる。全ての宛先はそれ自身のメールボックスを有しており、たとえば電話会社ＢへのＭＭＳ＿ＭＭ４の宛先はそれ自身のメールボックスを有している。詳細については、図８を参照されたい。

４．選定された発信メッセージング・サーバが起動され、必要ならメッセージ通知（たとえばメッセージあり表示（ＭＷＩ: Message Waiting indication））を含め、メッセージ配信が開始される。そのメッセージは、転送されるかまたは検索されるとき、受信者のインボックスから取り出され、必要であれば受信者の能力に適合される。そのメッセージに関連したディスパッチャ・イベントで実行されていないものは、いずれもメッセージが支障なく配信され終わったとき削除される。実行されていないディスパッチャ・イベントの削除は、メッセージが支障なく配信されたことを通知するメッセージをディスパッチャに送信した、選定された発信メッセージング・サーバによりトリガーが掛けられる。このスケジュールされたイベントの一般的な“削除”は、メッセージの多重配信を避けるためになされる。たとえば、ボイス・メールは、ＭＭＳとして配信されることになっていても、受信者の端末がオフラインであるためその受信者の端末に配信されることはできないであろう。しかしながら、受信者は、別の電話を使用して自身のボイス・メール・サービスを呼び出し、ボイス・メールを調べる。その受信者はメッセージを聞き、それを削除する。すぐに、ボイス・メール・サーバ内で要求されたこの削除は、上で説明されたように、ディスパッチャがスケジュールしたＭＭＳ再試行をも削除し、このようにしてメッセージの多重配信を避けるであろう。

５．そのメッセージが、第１のメッセージング・サーバにより受信され、第２のメッセージング・サーバにより配信されることになる場合、たとえば、もしそれが電子メール・サーバ内で電子メールとして受信され、ＭＭＳサーバによりＭＭＳとして配信されることになると、そのメッセージは第１のタイプから第２のタイプに変換されなければならない。その変換は、通常、選定された発信メッセージング・サーバ内で遂行される。その変換のために、メッセージの状態およびヘッダのマッピングは、相互作用のあるメッセージング・サーバ（プロトコル・ハンドラー）間で了解されなければならない。上の例では、電子メール・ヘッダは、ＭＭＳ多目的インターネット・メール拡張仕様（ＭＩＭＥ: Multipurpose Internet Mail Extentions）のヘッダに変換されなければならず、メッセージの状態は変換されなければならない（電子メールの既読／未読およびＭＭＳプッシュ符号）。メッセージが、第１のタイプから第２のタイプにどのように変換されるかは、そのメッセージ・タイプに依存している。３Ｇパートナーシップ・プロジェクト（３ＧＰＰ）技術仕様書ＴＳ＿２３１４０、たとえば２００３年０３月に発行されたバージョン６．１．０の付録Ａに、ＭＭＳメッセージは、ファクシミリ・メッセージ、ボイス・メール・メッセージ、ＳＭＳ、電子メール等と、どのように相互変換されるかが説明されている。他のメッセージング・タイプ間の変換については、変換がどのように遂行されるようになるかが明確であったり、あるいはまだ仕様が定められていない場合もある。

上で説明されたメッセージの流れでは、メッセージは、その着信メッセージング・サーバにより、順次メッセージ・ストア内の待ち行列に繋がれる。それらは、その発信メッセージング・サーバにその待ち行列からメッセージを取り出すように指図するカーソルとして機能するそのディスパッチャにより、ランダムに待ち行列から外される。その待ち行列は、そのメッセージ・ストア内のインボックスから見ると、ユーザ／インタフェースごとである。

図４は、本発明に準拠したメッセージの流れの例を示している。この例では、ＭＭＳメッセージが、図２のメッセージングシステムをどのように通過するかが示されている。図４にあるように、同じＭＭＳサーバ２０２が、実際には２度示されており、図４の左側の部分にあるシステムに入ったときから、受信者に配信されて図４の右側の部分にあるシステムを離れるまで、メッセージがどのようにそのメッセージングシステムにより処理されるかをよく示している。そのＭＭＳメッセージの配信に係わっているメッセージング・サーバのみが、図４に示されている。メッセージの流れは、図４の中の番号を参照して、次のようになる。

１．ＭＭ１サブミット・メッセージが着信ＭＭＳサーバ２０２により受信され、
２．ＭＭＳサーバ２０２は、メッセージ・ストア２０５に指示してそのメッセージを受信者のインボックスに保存させるように、ＭＭＳメッセージを含むＮＦＳ書き込み命令を送信する、
３．そして、ＭＭＳサーバ２０２は、ディスパッチャ２０６に対し、受信者のユーザＩＤおよびメッセージ参照のようなデータを含むメッセージ内に新しく到着したＭＭＳメッセージがあることを通知する。

４．ディスパッチャ２０６は、ユーザの配信の好みのような配信に対するユーザ（受信者）に関連した属性を調べ、イベントをスケジュールする（ないし保存する）。この場合、結果として、ＭＭＳ配信、すなわちＭＭＳとしてのメッセージ配信になる。

５．再試行イベントは、そのメッセージが通知および以下のように実行される配信の結果として検索されない場合に、ディスパッチャ２０６内でスケジュールされる。

６．発信ＭＭＳサーバは、そのメッセージを配信するために起動される。ユーザ（受信者）ＩＤおよびメッセージ参照を含めて、メッセージ配信要求がディスパッチャからＭＭＳサーバに送信される。

７．ＭＭ１通知メッセージが受信者に送信され、受信者にそのメッセージを通知する。

８．上記７に対する応答として、受信者はそのメッセージの検索を要求するであろう。

９．メッセージは、ＮＦＳリード（取り出しメッセージ）内にある受信者のインボックスからＭＭＳサーバにより読み出される。送信側と受信側との端末間で、そのメッセージ・タイプに影響する端末能力の違い、たとえば異なるディスプレイ解像度、音声コーデック等のために、配信の前にそのメッセージのトランスコーディングをもたらすことになりうる端末の能力が、調べられる。

１０．メッセージが受信者に配信される。

１１．メッセージに関連したディスパッチャ・イベントで実行されていないものは、いずれも、ＭＭＳサーバが、受信者ＩＤおよびメッセージ参照を含めて、そのメッセージを消去する命令をディスパッチャに送信することにより、消去される。

オプションとして、ＭＭＳサーバは、ＭＭＳメッセージを保存するためにメッセージ・ストアに命令を送信する前に、ディスパッチャにルート探索メッセージを送信し、そのＭＭＳメッセージの受信者への直接配信が適切りであるかどうかを調べることができる。もし適切であれば、ＭＭＳサーバは、同じメッセージング・タイプを使用して、受信者に直接そのメッセージを配信するであろうし、そのメッセージはメッセージ・ストアに保存されないであろう。

図５は、本発明に準拠したメッセージの流れの別の例を示している。この例では、図２のシステムがメッセージング・サーバ間相互作用を実現するために、どのように使用されているかが示されている。図５の例では、着信ボイス・メール・メッセージが、ＭＭＳメッセージとして受信者に配信されている。そのメッセージの流れは、図５の同じ番号を参照して、次のようになる。

１．ボイス・メッセージが着信ボイス・メール・サーバ２０１により受信され、
２．ボイス・メール・サーバ２０１は、メッセージ・ストア２０５に指示して、メッセージを受信者のインボックスに保存させるように、そのメッセージを含む網ファイル・システム（ＮＦＳ）書き込み命令を送信する、．
３．そして、ボイス・メール・サーバ２０１は、ディスパッチャ２０６に対し、配信メッセージの予定(Schedule)に、受信者のユーザＩＤおよびメッセージ参照を含む新しく到着したメッセージがあることを通知する。

４．ディスパッチャ２０６は、ユーザの配信の好みのような配信に対するユーザ（受信者）に関連した属性を調べ、イベントをスケジュールする（ないし保存する）。この場合、結果として、元のボイス・メールのＭＭＳ配信になる。

５．再試行イベントは、そのメッセージが通知および以下のように実行される配信の結果として検索されない場合に、ディスパッチャ２０６内でスケジュールされる。

６．発信ＭＭＳサーバは、そのメッセージを配信するために起動される。ユーザ（受信者）ＩＤおよびメッセージ参照を含めて、メッセージ配信要求がディスパッチャからＭＭＳサーバに送信される。

７．ＭＭ１通知メッセージが受信者に送信され、受信者にそのメッセージを通知する。ＭＭ１は、ＭＭＳ参照アーキテクチャのインタフェースである。ＭＭ１は、ＭＭＳユーザ・エージェントとＭＭＳサーバとの間の参照点である。ＭＭ１および他のＭＭＳインタフェースは、２００４年０６月に発行された３ＧＰＰ技術仕様書ＴＳ＿２３．１４０＿バージョン＿５．１１．０の第６章に説明されている。

８．上記７に対する応答として、受信者は、そのメッセージの検索を要求するであろう。

９．そのメッセージは、ＮＦＳリード（取り出しメッセージ）内にある受信者のインボックスからＭＭＳサーバにより読み出される。そのボイス・メール・メッセージは、ＭＭＳサーバ内で、必要に応じてＭＭＳヘッダ属性をマッピングないし生成することによりＭＭＳメッセージに変換される。上で説明されている標準３ＧＰＰ＿ＴＳ＿２３１４０の付録Ａ．５に準拠して、ボイス・メール・メッセージは、インターネット・メールのための音声プロファイル・バージョン２プロトコル（ＶＰＩＭｖ２）を使用することにより、ＭＭＳメッセージに変換される。ＶＰＩＭｖ２は、標準的なインターネット電子メール・システム上でのボイス・メッセージの転送をサポートするＭＩＭＥにフォーマット拡張を提供する。ＶＰＩＭｖ２は、ＩＥＴＦにより見直され終わって後、ＲＦＣ２４２１となった。

ＶＰＩＭ仕様書は、音声記録をカプセルに入れられたＭＩＭＥとし、簡易メール転送プロトコル（ＳＭＴＰ）を介してインターネット・メールの添付ファイルとして送信され、あるいはポスト・オフィス・プロトコル−バージョン３（ＰＯＰ３）ないしインターネット・メッセージ・アクセス・プロトコル−バージョン４（ＩＭＡＰ４）を介してインターネット・メールの添付ファイルとして取り込まれることを可能にしている。ボイス・メッセージに対して使用されるＭＩＭＥタイプは、“ａｕｄｉｏ／*”である。

ＭＭＳとボイス・メールボックスとの相互作用のために、ボイス・メールボックスは、受信された音声記録をＳＭＴＰを介してＶＰＩＭメッセージとしてＭＭＳリレー／サーバに転送することができる。ＭＭＳへの変換後、配信の前にそのメッセージのトランスコーディングをもたらす可能性のある受信者の端末能力が調べられる。

１０．メッセージが受信者に配信される。

１１．そのメッセージに関連したディスパッチャ・イベントで実行されていないものは、いずれも、ＭＭＳサーバが、受信者ＩＤおよびそのメッセージ参照を含めて、メッセージを消去する命令をディスパッチャに送信することにより、消去される。

図２に示されているメッセージングシステムは、またインスタント・メッセージに対しても使用されることができる。図６に、セッション開始プロトコル（ＳＩＰ: Session Initiatio Protocol）がどのように図２のメッセージングシステムを通過するかを示している。図６にあるように、同じＩＭ／チャット・サーバ６０４が実際には２度示されており、図６の左側の部分にあるシステムに入ったときから、受信者に配信されて図６の右側の部分にあるシステムを離れるまで、ＳＩＰメッセージがそのメッセージングシステムによりどのように処理されるかをよく示している。そのメッセージの流れは、図６の同じ番号を参照して、次のようになる。

１．ＳＩＰメッセージが着信ＩＭ／チャット・サーバ６０４により受信され、
３．ＩＭ／チャット・サーバ６０４は、ディスパッチャ２０６に対し、配信メッセージないしルート検索メッセージないし同様のものの予定(Schedule)に、受信者のユーザＩＤおよびメッセージ参照を含む新しく到着したＭＭＳメッセージがあることを通知する。これは、メッセージのヘッダが受信され次第、なされることができよう。すなわち、メッセージのコンテンツを待つ必要がない。これは実時間通信に近いので、時間遅延が短く保たれなければならない。

４．ディスパッチャ２０６は、ユーザの配信の好みのような配信に対するユーザ（受信者）に関連した属性を調べ、イベントをスケジュールする（ないし保存する）。この場合、結果として、ＩＭ／チャットの直接配信になる。

６．発信ＩＭ／チャット・サーバ６０４は、そのメッセージを配信するために起動され、それによって、そのメッセージを保存してその後にメッセージ・ストアからそのメッセージを取り出すことなく、メッセージが直接転送されることを可能としている。すなわち、着信データを発信側に直接ストリーム配信することができる。

１０．ＳＩＰメッセージが受信者に配信される。

上で示されたように、ＩＭ／チャット・サービスに関連したＳＩＰメッセージは、通常、実時間に近い通信特性のために、メッセージ・ストアに保存されないであろう。その代わりに、ＳＩＰメッセージは、ディスパッチャがユーザ関連の属性を調べる短い時間の間、ＩＭ／チャット・サーバ内のメモリ、たとえばランダム・アクセス・メモリ（ＲＡＭ）に留まるであろう。そのＳＩＰメッセージを受信者に配信されることができない場合、ＩＭ／チャット・サーバ６０４は、ＲＡＭ内に全てのＳＩＰメッセージを集め始め、受信者がオンラインに戻り接続が再設定されると、集めたＳＩＰメッセージを順次配信することができる。けれども、待ち状態にあるＳＩＰメッセージが所定の時間内に配信されることができなかった場合、それらのＳＩＰメッセージは、そのユーザのメールボックスのメッセージ・ストア２０５内で保存され、ＩＭアプリケーションにログオンされるか、異なる発信メッセージング・サーバ、たとえばそのＭＭＳサーバ２０２を使用するかのいずれかのときの、遅れた検索／配信に備えることができる。この場合、ＳＩＰメッセージは、上で、たとえば図３に関連して説明された手順に従うであろう。

図７は、本発明の実施形態に準拠して、メッセージを受信者に配信する方法のフローチャートを示している。その方法は、たとえば図２に示されている本発明のシステムを使用することができる。

その方法は、メッセージング・サーバがメッセージを受信することにより始まる（７０１）。そのメッセージを処理することになるのがいずれのタイプのメッセージング・サーバかは、そのメッセージ・タイプに依存する。オプションとしては、受信メッセージング・サーバが、そのときディスパッチャにルート探索メッセージを送信することができ（７１２）、ディスパッチャは、受信者へのメッセージの直接配信が適切であるかどうかを決定する（７１３）。

もし直接配信が適切であれば、ディスパッチャは、ルート探索メッセージに応えて、同じメッセージング・サーバを起動して（７１４）、同じメッセージング・タイプを使用してそのメッセージを直接その受信者に配信し（７１５）、そのメッセージはメッセージ・ストアに保存されないであろう。

もし、ディスパッチャが、そのメッセージが直接配信されるべきではないと決定すると、あるいはルート探索メッセージを送信するオプションの工程が使用されないと、メッセージング・サーバは、そのメッセージをメッセージ・ストアに送信し、そのメッセージの受信者に関連したインボックスにそのメッセージを保存する（７０２）。受信者は、メッセージ・タイプに係わらず、すべてのないし殆んどすべての自身のメッセージに対して１つのインボックスを有している。メッセージング・サーバは、また、ディスパッチャに受信済みメッセージおよびそのメッセージがいずれの受信者宛であるかを通知する（７０３）。その後、ディスパッチャは、そのメッセージを受信者に配信することになるのはいずれのメッセージング・サーバかを決定する（７０４）。この決定は、ユーザの好みおよび、受信者の能力たとえば端末の能力のような受信者の属性ないし好みに基づいている。

ディスパッチャは、そのメッセージを配信するために、決定されたメッセージング・サーバを起動する（７０５）。もし、受信者によりないしそメッセージング・サービスにより要求があると、メッセージング・サーバは、メッセージが配信される前に、受信者にメッセージの受信を通知する（７０６）。そのような場合、メッセージング・サーバは、そのメッセージが配信される前に受信者からの検索要求を受信する（７０７）。

メッセージング・サーバは、検索要求を受信した後ないし起動された直後、メッセージ・ストアからそのメッセージを取り出すか、何らかの別の方法でそのメッセージを受信する（７０８）。メッセージ・ストアからそのメッセージを受信したメッセージング・サーバが、最初にそのメッセージを受信したメッセージング・サーバより他の別のメッセージング・サーバである場合、そのメッセージは、別のメッセージング・サーバにより処理されるメッセージング・タイプに適合されるか、すなわち変換される（７０９）。これは、たとえば別のメッセージング・サーバにより処理されるメッセージ・タイプに関連するメッセージのヘッダ属性にマッピングするか、あるいは生成することによりなされる。

その後、メッセージング・サーバは、そのメッセージを受信者に配信する（７１０）。配信が終わると、メッセージング・サーバは、ディスパッチャに配信済みメッセージを通知し、そして、ディスパッチャは、そのメッセージに関連したディスパッチャ・イベントで実行されていないものはいずれも削除する（７１１）。そのような実行されていないディスパッチャ・イベントは、たとえば、決定されたメッセージング・サーバを起動する前に、再度スケジュールされることができよう。そのような実行されていないディスパッチャ・イベントは、また、たとえば、受信者が自身のボイス・メールを呼び出すことによりそのメッセージを取り出す場合、そのメッセージがＭＭＳサーバにより配信されるように決定された場合に生じうる。

図８は、第１および第２の通信システムを説明しており、各々は、本発明に準拠したメッセージングシステムを有している。

第１の通信システム８１０は、電話会社Ａにより実行されているとし、第１のボイス・メール・サーバ８１１、第１のＭＭＳサーバ８１２、第１の電子メール・サーバ８１３、および第１のＸＸＸサーバ８１４を備える第１のメッセージングシステムを有している。第１の通信システムは、また、第１のメッセージ・ストア８１５および第１のディスパッチャ８１６を備えており、第１のディスパッチャは第１の共通ディレクトリ８１７および第１のプレゼンス・サーバ８１８と関連付けられている。

同じように、第２の通信システム８２０は、電話会社Ｂにより実行されているとし、第２のボイス・メール・サーバ８２１、第２のＭＭＳサーバ８２２、第２の電子メール・サーバ８２３、および第２のＸＸＸサーバ８２４を備える第２のメッセージングシステムを有している。第２の通信システムは、また、第２のメッセージ・ストア８２５および第２のディスパッチャ８２６を備えており、第２のディスパッチャは第２の共通ディレクトリ８２７および第２のプレゼンス・サーバ８２８と関連付けられている。

メッセージが第１の通信システム内の端末８１９から送信され、そのメッセージが第２の通信システム内のユーザ宛であるとき、そのメッセージの受信者は、第１のメッセージング装置から見ると、第２の通信システムであることになろう。これは、第２の通信システムがそれ自身のメールボックスを第１のメッセージ・ストアに有していることになる。すなわち、ＭＭＳにおける各々のＭＭ４の宛先は、着信／発信トラヒックに対してそれ自身のメールボックスを有している。これは、図８に、送り手から受け手へのメッセージの流れを追うことにより図解されている。極太で描かれた矢印は、メッセージがそのシステムの中およびその間で取りうる異なるルートを示している。通常の太さの矢印は、信号のみを示している。信号は、また極太の矢印上で送ることもできる。

例として、第１のシステム内の端末８１９から発信して第２のシステム内の端末８２９宛てのメッセージが、ＭＭＳメッセージとして第１のシステム内の端末８１９から送信され、第１のＭＭＳサーバ８１２で受信される。そのメッセージは、第１のメッセージ・ストア８１５に保存され、第１のディスパッチャ８１６が受信済みメッセージの通知を受ける。第１のディスパッチャは、受信者の属性に基づいてそのメッセージの配信にいずれのサーバを使用するかを決定する。その受信者は、第２の通信システム内に位置しているので、その受信者は第１のメッセージングシステムから見ると、第２の通信システム内のＭＭＳサーバ、すなわち第２のＭＭＳサーバ８２２であることになる。それ故、第１のディスパッチャは、第２のＭＭＳサーバ８２２にそのメッセージを送信するために、第１のＭＭＳサーバを起動するように決定する。

第２のＭＭＳサーバ８２２で受信されると、そのメッセージは、第２のメッセージ・ストア８２５に保存され、第２のディスパッチャ８２６が、新しく受信したメッセージの通知を受ける。その後、第２のディスパッチャが、受信者、すなわち第２の端末８２９の属性（ないしユーザの好み）を調べる。その属性が、たとえば受信者が自身のメッセージを電子メールとして受信するように望んでいるということを示しているとしよう。それ故、その属性に基づいて、第２のディスパッチャは、受信者のコンピュータ８２９にそのメッセージを配信するために第２の電子メール・サーバ８２３を起動するように決定する。起動されると、第２の電子メール・サーバは、第２のメッセージ・ストアからそのメッセージを受信し、たとえばそのメッセージに電子メール・ヘッダを生成することにより、そのメッセージを電子メールのフォーマットに適合すなわち変換して、そのメッセージを電子メールとしてコンピュータ８２９に配信する。

図９は、本発明に準拠した信号プロトコルの例を示している。信号プロトコルは、受信者に配信されるメッセージを受信しているメッセージング・サーバ（受信メッセージング・サーバ）、ディスパッチャ、共通メッセージ・ストア、および受信者にそのメッセージを配信することになるメッセージング・サーバ（決定されたメッセージング・サーバ）相互間で交信される信号メッセージを説明している。

受信メッセージング・サーバがメッセージ（ないしメッセージの最初の部分）を受信し終わってから、ディスパッチャにルート探索メッセージを送信することができる。ルート探索メッセージは、メッセージが直接その受信者に同じメッセージング・サーバを使用して送信されることができるかを、ディスパッチャに問い合わせる。ルート探索メッセージはオプションのメッセージであり、受信メッセージング・サーバが直接配信を使用する能力を有している場合のみ使用される。ディスパッチャは、たとえば受信者のユーザの好みを調べることにより、そのメッセージが直接配信されることができるかどうかを決定する。その後、ディスパッチャは、そのメッセージが直接配信されることができるかどうか、あるいはそのメッセージが共通のメッセージ・ストアに保存されることになるどうかを通知するために、受信メッセージング・サーバにルート探索応答を送信する。ルート探索応答は、そのメッセージを配信することになるいずれかのメッセージング・サーバ・タイプ（たとえば、ＭＭＳ、ＳＭＳ、ボイス・メール等）を提示している。ルート探索応答は、また、そのメッセージの無条件保存を強いる“メッセージング・サーバ無し(No messaging server)”を含むこともできる。

もし、そのメッセージが直接配信されることになると、すなわち、受信メッセージング・サーバが、ルート探索応答で指示されているメッセージング・サーバ・タイプをサポートしていると、メッセージング・サーバはそのメッセージを受信者に配信する。もし、ルート探索応答が、他のメッセージング・サーバの遅れての配信ないしメッセージング・サーバなしを指示していると、受信メッセージング・サーバは、そのメッセージを含む保存メッセージを共通メッセージ・ストアに送信する。そのメッセージが保存され終わると、共通のメッセージ・ストアが保存完了メッセージで応答する。

そのとき、ハンドオーバが受信メッセージング・サーバからディスパッチャに送信され、ディスパッチャに、そのメッセージに対する“終了イベント(expiry event)”をスケジュールすることにより、そのメッセージに対する役目を引き継ぐように指示する。このイベントは、古くなったメッセージをメッセージ・ストアから削除することができ、そのメッセージがメッセージ・ストア内に張り付いてしまうことのないようにするために使用される。ディスパッチャは、そのイベントをスケジュールし、保存され終わるとハンドオーバ確認で応答する。

ディスパッチャは、たとえばユーザの好みに基づいて、いずれのメッセージング・サーバがそのメッセージを配信し、いつそのメッセージを配信するかを決定する。ディスパッチャは、それから、スケジュールされているイベントに対して時間が来たら、送信メッセージで、そのメッセージを配信するために決定されたメッセージング・サーバを起動する。その送信メッセージに対する応答として、決定されたメッセージング・サーバは、メッセージ・ストアから取り出しメッセージでそのメッセージを読み出し、そのメッセージを受信者に配信する。

共通メッセージ・ストアは、決定されたメッセージング・サーバに、取り出し完了メッセージを送信することにより、そのメッセージがいつ読み出しを終えたかを通知する。そのメッセージが受信者に配信され終わったとき、決定されたメッセージング・サーバは、そのメッセージが配信された場合、ディスパッチャに状況“結果ＯＫ”の送信メッセージ応答を送信する。その場合、ディスパッチャは、そのメッセージに関連した付加的なイベントをどれも削除する。配信されない場合、送信メッセージ応答は、状況“結果（恒久的エラー: permanent error）”ないし“結果（一時的エラー: temporary error）”を有することができる。

本発明のメッセージング装置を含む、水平型メッセージング・アーキテクチャを持つ通信システムの例が、図１０に示されている。このアーキテクチャは、エンドユーザに、ユーザの全てのメッセージに共通のメールボックスを提供する。そのアーキテクチャは、また、サービスレイヤに共通の機能、たとえば、共通のユーザ・プロファイル（共通ディレクトリ内に）および共通のプロビジョニング、課金、Ｏ＆Ｍ、およびシングル・サイン・オン（ＳＳＯ）を提供できるようにするセッションの認証を共有する。そのアーキテクチャは、また、電話会社に、たとえばイネーブラおよびボーダ・ゲートウェイのような共通の要素の再使用および共有に基づいて、水平型統合メッセージング解決策を提供し、電話会社の運営費およびある程度の資本経費に対処することになるであろう。

メッセージング・アーキテクチャは、ＩＰプロトコルに基づいており、異なる制御と接続レイヤを持つ異機種環境、たとえば異なるアクセス技術（ＧＳＭ、ＷＣＤＭＡ、ＰＳＴＮ、広帯域、ＩＳＰ等）で走行する一方でＳＩＰおよびＳＳ７の双方をサポートするシステムを、暗黙のうちにサポートするであろう。図１０の要素の簡単な仕様書は、以下のとおりである。

メッセージング・サーバ（図１０に、ＩＭ／チャット・サーバ、携帯電話上でのプッシュ・ツー・トーク（ＰｏＣ）サーバ、ＩＭＰＳサーバ、ボイス・メール・サーバ等により例示されている）は、１つのメッセージ・タイプを処理する各々のメッセージング・サービスに対するビジネス・ロジックを含んでおり、そこでの１つの重要な側面はプロトコル処理である。メッセージング・サーバは、メッセージング・タスクを実行するために、メッセージング・イネーブラ、イネーブラ、ボーダ・ゲートウェイ、およびサービス・ネットワーク・フレームワーク（ＳＮＦ: Service Network Framework）の共通構成要素（すなわち、図１０の共通ディレクトリ、プロビジョニング、課金、Ｏ＆Ｍおよび認証セッション）により提供される共通の機能を使用する。

例として、ＭＭＳサーバがＭＭＳメッセージを受信者に配送するとき、ＭＭＳサーバは、プッシュ・プロキシ・ボーダ・ゲートウェイを介して通知を送信する前に、受信者がそのサービスの会員になっていることを確認するために、ＳＮＦ共通ディレクトリを使用する。ＭＭＳサーバは、ＷＡＰボーダ・ゲートウェイを介して検索要求を受信し、そのメッセージをメッセージ・ストアから読み出す。そのメッセージを配信する前に、ＭＭＳサーバは、端末データベース（ＤＢ）イネーブラにある詳細な端末能力を調べ、必要であれば、メディア・アダプテーション・イネーブラからメッセージのトランスコーディングを要求する。

共通のメッセージング・イネーブラである、ディスパッチャおよびメッセージ・ストアが、新しいメッセージング・アーキテクチャにおいて最も重要な構成要素である。それらは、本明細書の前の部分で詳細に説明されてきている。

ボーダ・ゲートウェイ（たとえば、プッシュ・プロキシＧＷ、ボイスＧＷ、ＷＡＰ ＧＷ、ビデオＧＷ）は、メッセージング・サーバに向けてアクセス依存のプロトコルを、たとえば、ボイス・ゲートウェイにおける回線交換音声からＩＰ音声に変換する一連のプロキシである。

イネーブラ（たとえば、端末ＤＢ、メディア・アダプテーション、ディジタル著作権管理（ＤＲＭ）等）は、共通の機能にサービスに依存しない(service-independent)ビジネス・ロジックを提供し、他のメッセージング構成要素により使用されることができるリソースであり、主としてメッセージング・サーバにそれらのビジネス・ロジックを果たせるようにする。図１０のイネーブラおよびボーダ・ゲートウェイの一覧は、全てを網羅してはいない。

ＳＮＦの共通構成要素は、ユーザ・プロビジョニング、課金、シングル・サイン・オン（ＳＳＯ）およびネットワーク・ノードのＯ＆Ｍのようなサービス・ネットワークの水平化をサポートするための、エリクソンのサービス・ネットワーク・フレームワーク（ＳＮＦ）によって明記されている一連の共通機能である。 ［メッセージング構成要素の仕様書］
本発明に準拠した解決策に係わる図１０のメッセージング・アーキテクチャにおける構成要素の典型的な実施形態についての仕様書は、以下のとおりである。

＜メッセージング・サーバ＞
（ＭＭＳサーバ）
ＭＭＳサーバは、マルチメディア・メッセージング・サービスをエンドユーザに提供するときに鍵となる構成要素である。ＭＭＳサーバは、ユーザないし付加価値サービス・プロバイダ（ＶＡＳＰ）ゲートウェイからのメッセージを受信し、そのメッセージを内部にないし他のネットワークへ中継し、受信者に通知して、発信者に状態応答を提供する。この構成要素は、３ＧＰＰ＿ＴＳ＿２３．１４０で仕様化されているＭＭｘインタフェースをサポートしている。

ＭＭＳサーバの必須機能(Responsibilities)：
・マルチメディア・メッセージの蓄積と転送
・ＭＭＳトラヒックの課金
・エンドユーザがＭＭＳを送信／受信できる場合のポリシー・エンフォースメント
・メッセージの中間保存
（ＳＭＳサーバ）
ＳＭＳサーバは、ＳＭＳメッセージの配信用専用機能である。ＳＭＳサーバは、直ぐには配信することができないＳＭＳメッセージのルーティングおよび配信のための情報を含む。この構成要素は、ＳＭＰＰおよび他のＶＡＳＰインタフェースと、ネットワークに向けたＭＡＰ／ＳＳ７とをサポートする。

ＳＭＳサーバの必須機能：
・ＳＭＳメッセージ管理
・ＳＭＳサービスのためのアクセス制御（ＳＭＰＰセキュリティ、加入者検証）
・ＳＭＳトラヒックの課金
・メッセージの中間保存
（電子メール・サーバ）
電子メール・サーバは、電子メール・クライアント（ＳＭＴＰ、インターネット・メッセージ・アクセス・プロトコル（ＩＭＡＰ４）およびポスト・オフィス・プロトコル３（ＰＯＰ３）からの電子メールへのアクセスを提供する。電子メール・サーバは、また、着信および発信ＳＭＴＰトラヒックをルーティングする、すなわち、ＳＭＴＰメール転送エージェント（ＭＴＡ）として機能する。

必須機能：
・電子メール・クライアント（ＩＭＡＰ４、ＰＯＰ３）に対するアクセス・ポイント
・電子メールのメールボックスおよび／またはそのインターネット（ＳＭＴＰ）へのルーティング
・外部アカウントからの電子メールの取り込み
（ボイス・メール・サーバ）
ボイス・メール・サー構成要素は、すべてのボイス・メールのためのインタフェースである。ボイス・メール・サーバは、音声プロンプトおよびメッセージを再生／録音することにより、エンドユーザと情報をやり取りする。テキスト・メッセージは、テキスト・音声変換を介して読み上げることができる。双方向音声応答（ＩＶＲ: Interactive Vioce Response）対話を通じて進行させるために、ナビゲーション・コマンドが、エンドユーザにより、多周波信号（ＤＴＭＦ: Dual Tone Multi Frequency）、自動音声認識（ＡＳＲ: Automatic Speech Recognition）、ないし制御メッセージを介して発行される。録音されたメッセージは、メッセージ・ストアに保存される前に、ＶＰＩＭ／ＭＩＭＥエンベロープ中に包み込まれる。

ボイス・メール・サーバは、Ｈ．３２３ないしＳＩＰ制御プロトコルおよびリアルタイム・プロトコル（ＲＴＰ: Real Time Protocol）メディア・ストリーミングを介してボーダ・ゲートウェイに接続される。

必須機能：
・電話（ＴＵＩ）インタフェースを介したメッセージ処理の提供
・個人的な案内応答および呼管理に対する機能の提供
・ボイス・メール・プロンプトの管理
・テキスト・メッセージを音声として再生
・ＩＶＲ、ＤＴＭＦおよびマルチモーダル制御の提供
・通知ないし配信のための外部向け呼の発信
・通知および他のＳＭＳサービスの起動
（ビデオ・メール・サーバ）
ビデオ・メール・サーバ構成要素は、全てのビデオ・メールのためのインタフェースである。ビデオ・メール・サーバは、ビデオ・プロンプトおよびメッセージを再生／録画することにより、エンドユーザと情報をやり取りする。対話を通じて進行させるために、ナビゲーション・コマンドが、エンドユーザにより、ＤＴＭＦ、ＡＳＲ、ないし制御メッセージを介して発行される。録画されたメッセージは、メッセージ・ストアに保存される前に、ＭＩＭＥエンベロープ中に包み込まれる。

ビデオ・メール・サーバ構成要素は、Ｈ．３２３ないしＳＩＰ制御プロトコルおよびメディア・ストリーミングを介してボーダ・ゲートウェイに接続される。

必須機能：
・ビデオ（ＶＵＩ）インタフェースを介したメッセージ処理の提供
・個人的な案内応答および呼管理のための機能の提供
・ビデオ・メール・プロンプトの管理
・ＩＶＲ、ＤＴＭＦおよびマルチモーダル制御の提供
・通知ないし配信のための外部向け呼の発信
・通知および他のＳＭＳサービスの起動
（ウェブ・メール・サーバ）
ウェブ／ＷＡＰベースのメッセージング・サーバは、ウェブ・メール・ユーザ・インタフェースだけでなくマルチメディア・コンポーザも提供しており、エンドユーザ側のコンポーザ・クライアントのフロントエンドに相当するネットワーク対応部である。さらに、ウェブ・メール・サーバは、また、公開されているコンテンツと情報のやり取りをして、コンポーザ・クライアントに電話会社承認済みのコンテンツとの情報のやり取りができるようにする。

必須機能：
・メッセージ作成、送信、読み取り、削除等のためのウェブ／ＷＡＰ＿ＧＵＩ
・ハンドセット・クライアントとの情報のやり取りおよびコンテンツ共有の促進
・コンテンツ管理システムおよびポータルとのインタフェース
・公開コンテンツおよびユーザ間で共有されている有料コンテンツ双方の供給
・有料コンテンツを保護するためのＤＲＭとの情報のやり取り
（ＩＭ／チャット・サーバ）
ＩＭ／チャット・サーバは、インスタント・メッセージおよびチャット・サービスをＩＭＳ環境でエンドユーザに提供するときに、鍵となる構成要素である。ＩＭ／チャット・サーバは、ユーザないしそのＶＡＳＰゲートウェイからメッセージを受信し、そのメッセージを内部で、ユーザにあるいはユーザが応対できなければユーザのメッセージ・ストアに、または他のネットワークに中継する。この構成要素は、ＳＩＰ／ＳＩＭＰＬＥ即時メッセージング（ＳＩＰ＿ＭＥＳＳＡＧＥ）、セッション・ベースのメッセージング（ＳＩＰ／ＭＳＲＰ）、およびオープン・モバイル・アライアンス（ＯＡＭ: Open Mobile Alliance）ＳＩＭＰＬＥ＿ＡＤアーキテクチャ＆参照点に準拠した遅延メッセージングをサポートする。

必須機能：
・ＩＭ／チャット・トラヒックの転送
・ＩＭ／チャットの課金
・ホスト・パブリックおよびプライベート・チャット・ルーム
・エンドユーザがＩＭを送信／受信できる場合のポリシー・エンフォースメント
・ユーザが応対できないときのメッセージの保存
（ＰｏＣサーバ）
ＰｏＣサーバは、インスタント・ボイス・メッセージをＩＭＳ環境でエンドユーザに提供するときに、鍵となる構成要素である。ＰｏＣサーバは、ユーザないしＶＡＳＰゲートウェイからメッセージを受信し、そのメッセージを内部で、ユーザに、あるいはユーザが応対できない場合はユーザのメッセージ・ストアに、または他のネットワークに中継する。この構成要素は、ＯＭＡ＿ＰＯＣ＿ＡＤアーキテクチャ＆参照点に準拠した（ＳＩＰ／ＲＴＰ、すなわちＶｏＩＰ）をサポートする。

必須機能：
・ＰｏＣトラヒックの課金
・ＰｏＣ用のグループ・エクスプローダ
・エンドユーザが参加できる場合のポリシー・エンフォースメント
・ユーザが応対できないときのメッセージの保存
（ＩＭＰＳサーバ）
ＩＭＰＳサーバは、インスタント・メッセージおよびチャット・サービスをＩＭＰＳ（前のワイアレス・ビレッジ: Wireless Village）環境でエンドユーザに提供するときに、鍵となる構成要素である。ＩＭＰＳサーバは、ユーザないしＶＡＳＰゲートウェイからメッセージを受信し、そのメッセージを内部でユーザに、または他のネットワークに中継する。この構成要素は、ＯＭＡ＿ＯＭＰＳ１．２に準拠したＣＳＰおよびＳＳＰをサポートする。

必須機能：
・ＩＭ／チャット・トラヒックの転送
・ＩＭ／チャット・トラヒックの課金
・チャット用のグループ・エクスプローダ
・ＩＭＰＳプレゼンスおよびグループ管理
・エンドユーザがＩＭを送信／受信できる場合のポリシー・エンフォースメント
＜メッセージング・イネーブラ＞
（メッセージ・ストア）
メッセージ・ストア構成要素は、基本的にはファイル・サーバＮＡＳであり、その主なタスクは、ネットワーク・ファイル・システム（ＮＦＳ: Network File System）インタフェースを介してメッセージを保存することである。メッセージ・ストアは、エンドユーザの共通のメールボックスをホスティングし、エンドユーザが、エンドユーザの保存されたメッセージを管理するのを支援するために、一連のサブフォルダ（インボックス、アウトボックス、送信済みメッセージ、アーカイブ等）を有している。

必須機能：
・メッセージ（ボイス、ビデオ、テキスト、および画像）の保存
（ディスパッチャ）
ディスパッチャは、メッセージ配信のための鍵となる構成要素であり、エンドユーザにメッセージング・サーバを介して措置を講ずるように通知することによるか、配信メカニズムを起動するかのいずれかで、メッセージ・ストアに保存されているメッセージの配信を保証することを担っている。

ディスパッチャは、メッセージング・サーバからのメッセージ着信表示の結果としてのイベントをスケジュールし、イベントが起動すると、イベントで指定されているメッセージング・サーバにイベントを戻す。起動されたメッセージング・サーバは、そのとき、サービス個別のルールおよびインタフェース、たとえばＳＭＳ、ＷＡＰプッシュ、ＳＩＰプッシュ、電子メール等に準拠して、そのメッセージを検索するようにエンドユーザ／端末に通知する。

ディスパッチャを集中化している主な理由の１つは、メッセージが、第１のインタフェースで配信がまだスケジュールされている一方で、第２のインタフェースからの影響を受けるような場合、メッセージング・サーバのいずれかからのイベント取り消しを可能にするためである。たとえば、ボイス・メールが、ＭＭＳとしての配信がスケジュールされている一方で、音声サービスを介して読み出されるような場合である。ボイス・メール・サーバは、そのとき、ユーザの好みに従って、ＭＭＳ配信を取り消すことができる。

受信者が複数の場合、ディスパッチャは、受信者ごとに１つのメッセージング・サーバ・インスタンスを起動する役目を担っており、ユーザの好みに従って、たとえば、そのメッセージを幾人かの受信者にはＭＭＳ、他のユーザにはＳＭＳとして配信し終えることになるであろう。

必須機能：
・メッセージ・タイプおよびその受信者の好みに基づいて、最初のメッセージ配信のためにいずれのメッセージング・サーバを起動するかの決定
・タイム・スケジュール・イベント、たとえば再試行なし遅延配信のためのイベント
・グループ・リスト・エクスプローダ(Group list exploder)
＜イネーブラ＞
（プレゼンス・サーバ）
プレゼンス・サーバは、メッセージング・サーバに受信者の状態、好みおよび通信能力を提供することにより、ユーザのメッセージング体験を高めるのに役立つ。

クライアント・プラットフォームにおいて、メッセージング・クライアントが受信者のプレゼンスの知識に基づいて、メッセージの送信を最適化するように、プレゼンス・クライアントと情報をやり取りすることができる。

必須機能：
・通信手段、有用性、ネットワークおよびユーザの好みのようなプレゼンス属性の提供
・ＩＥＴＦ、３ＧＰＰおよびＯＭＡで仕様化されている、ＳＩＭＰＬＥ、ＸＭＬ設定アクセス・プロトコル（ＸＣＡＰ: XML Configuration Access Protocol）、およびＨＴＴＰ技術を介したメッセージング・サーバとの通信
・ユーザのプレゼンス情報を取り出すための、ＨＳＳおよびパーレイ・ゲートウェイ(Parlay Gateways)とのやり取り
・プレゼンス情報提示のための、ＯＡＭ／ワイアレス・ビレッジ、ＰｏＣ、３ＧＰＰ＿Ｒ６およびＳＩＰクライアントとの通信
＜ＳＮＦ共通機能＞
この節では、メッセージングに関連する機能性および必須機能のみが説明されている。

（共通ディレクトリ）
共通ディレクトリは、ユーザすなわち受信者およびサービスについての情報を保存する。共通ディレクトリは、メッセージング構成要素により共有される一般的な加入者およびサービスの情報を含む。

必須機能：
・一般的なユーザ情報の保存
・加入者プロビジョニングに対するインタフェースの提供
・他の要素へのユーザおよびサービスの情報の供給
・ディレクトリの安定したスケーラビリティおよび信頼性に繋がる簡易ディレクトリ・アクセス・プロトコル（ＬＤＡＰ: Light Directory Access Protocol）のサポート
共通ディレクトリは、先行技術によるメッセージング製品における各々の個別のディレクトリを置き換えるために開発されている。そのディレクトリは、本発明の１つの実施形態に準拠して、２つの部分を備えることができる。すなわち、データ・モデルおよびディレクトリ・エンジンである。

データ・モデルは、また、将来の変更を考慮しており、ディレクトリ情報ツリー（ＤＩＴ: durectory information tree）において、共通属性用および各々のアプリケーション用の別々のブランチが配置されることができる。

メッセージング・ユーザのユーザ・プロファイルは、ＬＤＡＰバージョン３に準拠した共通ディレクトリ内に保存することができる。そのディレクトリにホスティングされるＬＤＡＰデータ・スキーマは、メッセージング・サーバ（および場合によっては他のアプリケーション）間で共有する属性のための１つの共通部、および１つのメッセージング・サーバ個別部を有するように提案されている。これは、属性共有に柔軟性を付与し、さらに、リリースにわたって共通部に移すことができる新しいメッセージング・サーバおよびアプリケーション仕様の追加を可能にする。

本発明の１つの実装では、ディレクトリ・エンジンが、外部ディレクトリ（ＥＤＳ: External Directory）と呼ばれるＭＭＣ内のディレクトリ上に構築されており、ＥＤＳは実績を上げているＬＤＡＰディレクトリで、ユーザ・ベースの分割により縮尺している。ＥＤＳは、ディストリビューション・データベースで強化されており、その結果、複数のキーに対する高性能な検索を可能にしている。

ユーザ・プロファイルの変更は、いつもメッセージング・サーバを介して処理され、メッセージング・サーバは、そのデータ、たとえば値の範囲、属性の整合性、必須属性が提供されることの保証等の正当性を確認する役目を担っている。共通属性は、共通属性部に保存され、メッセージング・サーバ個別のデータは、メッセージング・サーバごとにメッセージング・サーバ個別部に保存される。

図１１は、受信者へのメッセージ配信に対する本発明の通信装置におけるノードの実施形態の概略ブロック図を示しており、そのノードは、ディスパッチャとして動作するように設定されている。

ノード１０は、メッセージング装置内の他の構成要素、たとえば、その異なるメッセージング・サーバ、共通ディレクトリおよびプレゼンス・サーバとの通信のために設定されている通信インタフェース１１と、メッセージがメッセージング装置を経由していずれのルートを取ることになるか、すなわち、そのメッセージを受信者に配信するためにいずれのメッセージング・サーバを使用するかを決定するルート決定ユニット１２と、メッセージをいつ受信者に配信するかをスケジュールするためのスケジューリング・ユニット１３とを備える。

スケジューリング・ユニットは、メッセージを配信するために時間の経過を追うタイマーを使用する。

ノードは、通信インタフェースで、メッセージング・サーバからメッセージング・サーバで受信されたメッセージの通知を受信し、受信者の配信の好みに基づいて、そのメッセージの配信を担うメッセージング・サーバを決定し、そのメッセージを配信するように、決定されたメッセージング・サーバを起動するために配置されている。。

ノードは、また、受信者の配信の好みに基づいて、メッセージをいつ配信するかを決定するように設定されている。別の実施形態では、ノードは、受信者の配信の好みを保存している共通ディレクトリと通信することにより、またオプションとしては、受信者のプレゼンス情報、すなわち受信者が所在する場所および受信者の状態を把握しているプレゼンス・サーバと通信することにより、受信者の配信の好みを調べるように設定されている。

本発明の方法は、通信システム内のノードにあるコンピュータシステムにロード可能なソフトウェアにより、実行されることができる。

上記のように、本発明に準拠した方法およびメッセージングシステムで、メッセージの受信者が、送信されたときのそのメッセージのメッセージ・タイプに係わらず、受信者により要求されたタイプおよび形式でメッセージを受信できる。また、本発明に準拠したメッセージ配信のためのメッセージングシステムおよび方法を使用することにより、電話会社が、新しいメッセージ・タイプを処理する任意の新しいメッセージング技術を、電話会社のメッセージング解決策に容易に加えることができるであろう。

図面および明細書のなかで、本発明の好適な実施形態および例が開示されてきており、そして専門用語が採用されているけれども、それらは、一般的で、説明の意味のみで使用されており、制限を目的とはしておらず、本発明の範囲は特許請求の範囲の中で説明されている。

先行技術のメッセージング・アーキテクチャの概略ブロックを説明する図である。 本発明のメッセージングシステムの概略ブロック図である。 本発明のメッセージングシステムの別の概略ブロック図であり、そのようなシステムにおいてメッセージがどのように処理されるかの説明を含めた図である。 本発明のメッセージングシステムの概略ブロック図を示しており、ＭＭＳメッセージが本発明のメッセージングシステムを経由してどのように転送されるかの説明を含めた図である。 本発明のメッセージングシステムの概略ブロック図を示しており、送信されたボイス・メール・メッセージがどのようにメッセージングシステムを経由して転送され、ＭＭＳメッセージとして配信されるかの説明を添えた図である。 本発明のメッセージングシステムの概略ブロック図を説明しており、本発明のメッセージングシステムを経由するインスタント・メッセージの配信を説明する図である。 本発明の方法に対応するフローチャートである。 ２つの通信システムの概略ブロック図を説明しており、各々の通信システムが本発明のメッセージングシステムを有する図である。 本発明の実施形態の信号プロトコルを示す図である。 本発明のメッセージングシステムを備えるメッセージング・アーキテクチャの概略ブロック図である。 本発明のディスパッチャの概略ブロックを説明する図である。

Claims (26)

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. 通信メッセージの受信者への配信を処理する通信システム内のノード（１０）における方法であって、前記通信システムが、異なるタイプの通信メッセージを処理するためのいくつかのメッセージング・サーバを有し、各々のメッセージング・サーバが特定のメッセージ・タイプのメッセージを処理するように設定されており、
    メッセージング・サーバからルート探索メッセージを受信する工程と、
    前記メッセージング・サーバで受信されたメッセージが実質的に直接前記受信者に配信することができるかどうかを決定する工程と、
    前記メッセージが実質的に直接配信されることができる場合、前記受信者の配信の好みに基づいて前記受信されたメッセージを配信するために前記受信メッセージング・サーバを起動する工程と、
    前記メッセージが直接配信されることができない場合、前記メッセージング・サーバで受信された前記メッセージについての前記メッセージング・サーバからの通知を受信する工程と、
    前記受信者の配信の好みに基づいて、前記メッセージの配信を担うメッセージング・サーバを決定する工程と、
    前記メッセージを配信するように前記決定されたメッセージング・サーバを起動する工程とを備えることを特徴とする方法。

Images