拡張されたメッセージングプラットフォーム
第１の配信チャネルを介して受信者デバイスに配信するために発信デバイスからメッセージを受信するように構成されたサーバを備え、このサーバが、第１の配信チャネルを介してメッセージの配信を実行できない場合に代替配信チャネルを選択するように構成されるメッセージシステムを開示する。本発明は、メッセージの経路指定を行うための方法をさらに開示し、この方法は、１つのサーバにおいて、受信者に配信するために発信デバイスからメッセージを受信するステップと、第１の配信チャネルを介して受信者デバイスにメッセージを転送するステップと、前記受信者デバイスから確認応答メッセージを受信するのを待つステップとを含み、確認応答メッセージが受信されない場合に、サーバが、代替配信チャネルを介して受信者デバイスにメッセージを再送するというものである。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、拡張メッセージングサービスを提供するためのシステム及び方法に関する。特に、本発明は、限定はしないが、移動体通信ネットワーク内の拡張メッセージングサービス及び／又はファイル共有サービスを提供することに関する。
【背景技術】
【０００２】
移動体通信システムにおいて最も広範に使用されている形態のメッセージングは、ショートメッセージサービス（ＳＭＳ）である。典型的には、メッセージは、発信デバイスから、蓄積交換機構を備えるショートメッセージサービスセンサー（ＳＭＳＣ）に送信される。ＳＭＳＣとハンドセットとの間のショートメッセージの伝送は、ＳＳ７プロトコルの移動通信応用部（ＭＡＰ）を使用して実行される。メッセージは、ＭＡＰｍｏ−ＦｏｒｗａｒｄＳＭ及びｍｔ−ＦｏｒｗａｒｄＳＭオペレーションを使って送信され、そのペイロード長は、信号プロトコルの制約条件によって正確に１４０オクテット（１４０オクテット＝１４０×８ビット＝１１２０ビット）に制限される。ショートメッセージは、さまざまなアルファベット、つまり、デフォルトのＧＳＭ ７ビットアルファベット（以下に示す）、８ビットデータアルファベット、及び１６ビットＵＴＦ−１６／ＵＣＳ−２アルファベットを使用して符号化することができる。
【０００３】
その結果、加入者がハンドセットにおいてどのアルファベットを構成したかに応じて、最大個別ショートメッセージサイズが７ビット文字１６０個、８ビット文字１４０個、又は１６ビット文字７０個（スペースを含む）となる。ＧＳＭ ７ビットアルファベットのサポートは、ＧＳＭハンドセット及びネットワーク要素については必須であるが［１５］、アラビア語、中国語、韓国語、日本語、又はキリル文字言語（例えば、ロシア語）などの言語の文字は、１６ビットＵＣＳ−２文字コード（Ｕｎｉｃｏｄｅ）を使用して符号化されなければならない。経路指定データ及び他のメタデータが、ペイロードサイズに加わる。
【０００４】
受信者に到達不能である場合、ＳＭＳＣは、後から再試行するためにメッセージをキューに入れる。いくつかのＳＭＳＣは、伝送が１回だけ試行される「転送しっぱなし」というオプションも備える。したがって、メッセージ配信はベストエフォート型であり、そのため、メッセージがこのメッセージの受信者に実際に配信されることが保証されず、またメッセージの遅延又は完全な喪失は、特にネットワーク間で送信するときには稀なことではない。
【０００５】
近年、インスタントメッセージと電子メールなどの付加的メッセージサービスがモバイル環境に移行した。標準的なデスクトップ環境では、インスタントメッセージング（ＩＭ）は、１つのネットワーク上で２人以上の参加者の間のリアルタイムテキストベースの通信又はほぼリアルタイムの通信を実現した。したがって、電子メールなどのサービスとＩＭとの際立った違いは、ユーザ間の通信の同期が感知されるかどうかであり、メッセージングはリアルタイム又はほぼリアルタイムで実行される。インスタントメッセージは、典型的には、電子メールの永続的性質とのギャップを埋め、ＵＲＬ又はドキュメントのスニペットのような情報（電話を介して通信するときには扱いにくくなる可能性がある）の高速交換を容易にするローカルメッセージ履歴としてログに記録される。ＩＭを使用すると、通信を効果的に、また効率的に行うことができ、確認応答又は返信の受信をすぐに行うことができる。
【０００６】
モバイルインスタントメッセージング（ＭＩＭ）は、標準的なデスクトップＩＭアプリケーションのものとわずかに異なる。ＭＩＭは、デスクトップメッセージングのエクスペリエンスを、移動途中にあるという使用シナリオに移し換えようとするプレゼンス機能対応のメッセージングサービスである。一方で、デスクトップエクスペリエンスの中核となる考え方のいくつかが、接続されているモバイルデバイスに適用されるが、それ以外の考え方は、適用されない。帯域幅、メモリサイズ、メディアフォーマットの利用可能性、キーパッドベースの入力、スクリーン出力、ＣＰＵ性能、及び電池容量など、実際に十分で、パワフルで、しかも使い勝手のよいモバイルエクスペリエンスを実現するために、例えば、フォームファクタ及びモビリティに関連する違いのいくつかを考慮する必要があるが、これは、デスクトップデバイスユーザ、さらにはネットワークに接続した状態を維持するノマディックユーザがもたらす核心的問題である。
【０００７】
上述のようにモバイルデータネットワークは信頼性がなく、メッセージは、行方不明になってしまうことがある（メッセージ配信はベストエフォート型である）。既存のモバイルインスタントメッセージング（ＩＭ）の「ゲートウェイ」製品は、ＩＭメッセージを「カジュアルチャット」として扱う。そのようなものとして、ＭＩＭはメッセージの喪失を重大なこととみなさないため、メッセージが対象受信者に配信される保証はない。したがって、ＭＩＭの現在の実装は、情報の配信が重要であるビジネス環境又は他の用途にあまり向いていない。
【０００８】
上述のように、大半の既存のメッセージングシステム（例えば、ＳＭＳ）は、ストレージ容量が限られている。ＳＭＳの場合、いかなるメッセージバックアップ機能も働かせるために、ローカルのＰＣバックアップ／アーカイブが必要になる場合があり、その場合、プロセスは本質的に手動である。メッセージを保存したい場合、ユーザは、新しいメッセージが入るスペースを解放するために自分のモバイルデバイス上でメッセージを削除する前にこの手動プロセスを実行しなければならない。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
したがって、カジュアルユーザだけでなくビジネスユーザ又はクリティカルユーザにも受け入れられる信頼性の高いメッセージングソリューションを提供する必要がある。後で検討できるように送受信されたメッセージをユーザ側でバックアップすることができるファシリティを備えることも有利であろう。
【課題を解決するための手段】
【００１０】
したがって、本発明の一態様においては、拡張メッセージシステムが提供され、前記システムは、
第１の配信チャネルを介して少なくとも１つの受信者デバイスに配信するために発信デバイスからメッセージを受信するように構成された少なくとも１つのサーバを備え、
少なくとも１つのサーバが、第１の配信チャネルを介してメッセージの配信を実行できない場合に代替配信チャネルを選択するようにさらに構成され、
或いは、発信デバイスが、第１の配信チャネルを介してメッセージの配信を実行できない場合に代替配信チャネルを選択するように構成されてもよい。
【００１１】
メッセージングネットワークは、発信デバイス、少なくとも１つのサーバ、及び１つ又は複数の受信者を含むものと考えることができる（これらは、モバイルデバイスでも電子メール又は他の受信者タイプであってもよい）。
【００１２】
メッセージは、テキストメッセージであると考えられるか、或いは他の何らかの種類のデータメッセージ又は限定はしないが、画像、音楽ファイル、若しくはドキュメントなどのファイルとすることもできる。
【００１３】
配信の保証の原理は、メッセージ伝送のすべてのレッグにおいて適用される。したがって、発信デバイスは、メッセージをどのように送信するかを規律するための、１つ又は複数の定義済みルールセットを備えることができる。ルールセットは、第１の配信チャネルでメッセージを再送するまでに発信デバイスが待っている期間、代替配信チャネルに切り換えるまで第１の配信チャネルで再試行を続ける頻度、及び代替配信チャネルに切り換えるまで第１の配信チャネルで再試行を続ける時間の長さに関する情報を含むことができる。メッセージは、発信デバイスがメッセージを少なくとも１つのサーバに配信しようとする毎にインクリメントされる再試行カウンターを備えることができる。このシステムを使用すると、ユーザは、そのプリファレンスに従ってルールセットを再構成することができる。
【００１４】
発信デバイスは、メッセージの配信ステータスに関する情報を与えるインジケータをユーザに対して表示することができる。
【００１５】
第１の配信チャネルは、インターネットプロトコル（ＩＰ）ベースのメッセージングチャネルでもよく、またメッセージは、インスタントメッセージ若しくはチャットメッセージでもよい。好ましくは、代替配信チャネルは、ＳＭＴＰ、ＭＩＭＥ、ＰＯＰ、ＩＭＡＰ、又は同様のメッセージングチャネルである。適切には、代替配信チャネルは、ＳＳ７又は同様のメッセージングチャネルとすることができる。代替配信が、メッセージの配信に使用される場合、発信デバイス又は少なくとも１つのサーバは、代替配信チャネルのメッセージング標準に適合するようにメッセージを再フォーマットすることができる。
【００１６】
好ましくは、発信デバイスは、第１のメッセージングチャネルを介してメッセージを受信した後に前記少なくとも１つのサーバから確認応答メッセージを受信するように構成される。
【００１７】
確認応答メッセージが発信デバイスに返されない場合、発信デバイスは、送信者のビジネスルール及びユーザ設定を適用して、実行すべきアクションを決定する。典型的には、これは、定義された回数の再試行及びその後の、配信が行われる代替配信チャネルへの切り換えを含むことができる。この場合、実行すべきアクションを決定するためにユーザの介入を必要とすることもある。さらに、これは、二次配信チャネルに切り換えるようサーバに指令するメッセージヘッダ内に記述された命令を伴う、一次配信チャネルによるサーバへの配信を含むことができる。
【００１８】
メッセージが前記少なくとも１つのサーバに到達した後、１人又は複数の受信者へのメッセージの経路指定がなされなければならない。最初に、少なくとも１つのサーバが、発信デバイスのユーザによって指定された配信チャネルを使用してメッセージを配信することを試みる。
【００１９】
サーバは、メッセージをどのように送信するかを規律するための、１つ又は複数の定義済みルールセットを備えることができる。ルールセットは、第１の配信チャネルでメッセージを再送するまでに少なくとも１つのサーバが待っている期間、代替配信チャネルに切り換えるまで第１の配信チャネルで再試行を続ける頻度、及び代替配信チャネルに切り換えるまで第１の配信チャネルで再試行を続ける時間の長さに関する情報を含むことができる。メッセージは、サーバがメッセージを少なくとも１つの受信者デバイスに配信しようとする毎にインクリメントされる再試行カウンターを備えることができる。このシステムを使用すると、ユーザは、そのプリファレンスに従ってルールセットを再構成することができる。或いは、サーバは、再試行を管理する責任を発信デバイスに委ねることもできる。
【００２０】
好ましくは、少なくとも１つのサーバは、第１のメッセージングチャネルを介してメッセージを受信した後に前記少なくとも１つの受信者デバイスから確認応答メッセージを受信するように構成される。このシステムは、少なくとも１つのサーバが少なくとも１つの受信者デバイスによるメッセージの受信を発信デバイスに通知するように構成することもできる。このエンドツーエンドによる通知は、発信デバイスが再試行プロセスを管理している場合に確実な配信を行うためにのみ必要である。そうではなく、少なくとも１つのサーバがプロセスを制御し続けており、配信の確実性を維持している場合、受信確認応答を発信デバイスに返すことは必須でない。確認応答メッセージは、それが最低限、その確認応答をメッセージに関連付けるのに十分な情報を含んでいさえすれば、適当ないかなるフォーマットのものでもよい。確認応答は、例えば、シリアル番号、タイムスタンプ、一意的なＩＤ、又は同様のものを含むことができる。一意的なＩＤは、メッセージの受信に関連付けられているシリアル番号及びタイムスタンプから生成することができる。
【００２１】
或いはサーバが、受信の確認応答を単純に発信デバイスに渡すこともできる。このアプローチでは、受信者デバイスへの配信が確実に行われるようにする、発信デバイスの責任が高まる。
【００２２】
確認応答メッセージが少なくとも１つのサーバに返されない場合、サーバは、送信者及び受信者のビジネスルール及びユーザ設定を適用して、実行すべきアクションを決定する。典型的には、これは、定義された回数の再試行及びその後の、配信が行われる代替配信チャネルへの切り換えを含むことができる。
【００２３】
少なくとも１つのサーバをデータベースに結合することができる。サーバは、メッセージを配信しようとするそれぞれの試みのログを、ネットワーク固有の情報とともにデータベースに定期的に書き込むように構成することができる。データベースは、配信サーバを通るすべてのメッセージに対するメッセージリポジトリとして使用することもできる。システムは、ユーザから送信され、ユーザが受信するすべてのメッセージにアクセスするためのユーザ向けの適切なインターフェースを備えることができる。
【００２４】
本発明の他の態様においては、メッセージの経路指定を行うための方法が提供され、前記方法は、
１つのサーバにおいて、少なくとも１人の受信者に配信するために発信デバイスからメッセージを受信するステップと、
第１の配信チャネルを介して少なくとも１つの受信者デバイスにメッセージを転送するステップと、
前記少なくとも１つの受信者デバイスから確認応答メッセージを受信するのを待つステップを含み、確認応答が受信メッセージでない場合に、サーバは代替配信チャネルを介して前記少なくとも１つの受信者デバイスにメッセージを再送する。
【００２５】
この方法は、代替配信チャネルを介してメッセージを再送する前に所定の回数だけ第１の配信チャネルを介してメッセージを再送するステップを含むことができる。適切には、第１の配信チャネルを介してメッセージを再送するステップは、メッセージに関連する再試行カウンターをインクリメントするステップを含む。この方法は、任意選択で、事前に第１の配信チャネルを介して配信を行わせることができなかった場合に代替配信チャネルを介してメッセージの転送を発信デバイスにおいて開始するステップを含むことができる（つまり、発信デバイスは、第１の配信チャネルの再試行をオーバーライドする能力を有する）。
【００２６】
適切には、代替配信チャネルを介してメッセージを転送するステップは、チャネルのメッセージング標準に適合するようにメッセージを再フォーマットするステップをさらに含む。
【００２７】
この方法は、重複するメッセージを識別するための受信デバイス上の処理を組み込むこともできる。ネットワークの信頼性が低いシナリオでは、送信側の少なくとも１つのサーバ又は発信デバイスが受信に成功したことを示す応答を返す前に何回もメッセージが送信されることがある。これが、メッセージそれ自体ではなく、送信に失敗した受信によるものである場合、その結果、受信デバイスに重複メッセージが到着することがある。これは、上述したようにメッセージに含まれる一意的な識別子を使用することによって対処される。受信デバイスは、すでに受信されているメッセージ内の一意的な識別子を見て、すでに受信され、表示されているメッセージを再表示しない。
【００２８】
本発明の他の態様においては、メッセージの配信ステータスを示すインジケータをユーザに対して表示することができる。一アプローチにおいて、メッセージ再試行が発信デバイスによって制御される場合、送信アプリケーションを終了しようとしているユーザに対し、メッセージが配信されているとまだ確認されていないこと、及び再試行がまだ未解決であることを示す警告が出されることが好ましい。
【００２９】
本発明をより理解しやすくし、実用上の効果をもたらすために、本発明の好ましい実施形態を例示する、添付の図面を参照する。
【図面の簡単な説明】
【００３０】
【図１】本発明の一実施形態による拡張メッセージシステムの略ブロック図である。
【図２】本発明の一実施形態によるメッセージングシステム内のさまざまな地点間の信号伝送を示す流れ図である。
【発明を実施するための形態】
【００３１】
図１を参照すると、本発明の一実施形態によるメッセージングシステム１００が示されている。本発明の状況では、メッセージは、テキストメッセージであると考えられるか、或いは他の何らかの種類のデータメッセージ、又は限定はしないが、画像、音楽ファイル、若しくはドキュメントなどのファイルとすることもできる。
【００３２】
図に示されているように、デバイスメッセージングアプリケーション１０２を介してメッセージを作成するために、発信デバイス１０１（例えば、モバイルハンドセット、ＰＤＡ、ポータブルコンピュータ、又は同様のもの）がユーザによって使用される。この場合、メッセージングアプリケーションは、モバイルＩＭアプリケーションである。ユーザが所望のメッセージを作成した後、ユーザは、次いでその連絡先又は友達リスト１０３から１つ又は複数の受信者１０７を選択する。受信者１０７は、同じネットワーク１０４のメンバーでも異なるネットワーク１０６のメンバーでもよい。受信者１０７が、選択された後、次いで、デバイスのメッセージングアプリケーション１０２は、ネットワーク１０４を介してメッセージを、対象受信者と受信者デバイス（複数可）１０７へのメッセージに使用される好ましい配信チャネルとに関する情報を備える配信サーバ１０５に転送する。好ましい配信チャネルは、データ（インターネットプロトコル／ＩＰ）ベースのメッセージング（例えば、インスタントメッセージング又はチャット）、ＳＭＳ、ＭＭＳ、電子メール、又は他の任意の定義済みメッセージングフォーマットとすることができる。発信デバイス１０１が、メッセージを配信サーバ１０５に転送した後、発信デバイス１０１は、メッセージの受信を確認した配信サーバ１０５からの確認応答メッセージ／パケットを受信することを予期する。確認応答の特定のフォーマットは、最初の送信済みメッセージに容易に関連付けられる場合には重要ではない。確認応答メッセージを最初の送信済みメッセージに関連付けるためのアプローチは多数ある。例えば、この関連付けは、確認応答メッセージを最初の送信済みメッセージに関連付ける一意的なメッセージＩＤを生成するために使用されるシリアル番号、タイムスタンプ、又は同様のものを使用することで実行できる。
【００３３】
発信デバイス１０１が、確認応答を受信できない場合、定義済みルールセットに基づき、所定の時間だけ待って、その後、メッセージの再送を試みる。定義済みルールセットは、メッセージを再送するまでにデバイスが待つ期間を定義するだけでなく、再試行を続ける頻度及び長さをも定義する。例えば、このルールセットは、送信デバイス１０１による最大１０回の再試行を許容し、最初にメッセージを送信しようとしてからそれぞれの再試行が５分間隔となるように、構成することができる。最大試行回数に達しても送信デバイス１０１がメッセージ配信を完了できない場合に、所定の期間の経過後に、メッセージを経路指定に従って配信サーバ１０５に送るために代替方法を介して配信を行わせることを試みることができる。
【００３４】
さらに、ユーザが、メッセージ送信未完了のまま発信デバイスのクライアントアプリケーションをログオフするか、又は終了しようとした場合、発信デバイスのクライアントアプリケーションは、メッセージの配信ステータスに関してユーザに通知し、ログオフ又は終了を完了する前に代替配信オプションを選ばせる。
【００３５】
図１に示されているように、配信サーバ１０５は、この場合、複数の冗長配信チャネルを構成するように少なくとも１つの電子メールサーバ１０８及び／又は少なくとも１つのメッセージングセンター（ＳＭＳＣ、ＭＭＳＣ）１０９に結合される。一次配信チャネルを介してメッセージを経路指定で受信者デバイス（複数可）に送ることができない場合（つまり、メッセージのネイティブフォーマット）、配信サーバは、次の好ましい配信フォーマットに切り換わる。例えば、配信サーバ１０５は、ＩＭからＳＭＳに切り替わり、メッセージの配信を実行させることができる。
【００３６】
或いは発信デバイス１０１は、ユーザによって選択された一次配信チャネルを介してメッセージを配信できない場合に代替配信チャネルを選択するようユーザに促すこともできる。場合によっては、利用可能でないとサーバに認識されている配信チャネルをユーザが選択することもあり、例えば、ユーザがＩＰベースのメッセージングを選択することもあるが、サーバは、このタイプのメッセージを受信するのにその受信デバイスを利用できないことを認識している。この場合、配信サーバ１０５は、代替配信チャネル（例えば、電子メールゲートウェイ１０８、ＳＭＳＣ １０９）を介して配信するためにメッセージを代替メッセージフォーマット（ＳＭＳ、電子メールなど）に変換する。
【００３７】
一次配信チャネルは、二次配信チャネルに切り換えるようサーバに指令するメッセージヘッダ内に記述された一組の命令を含むことができる。配信サーバ１０５によってメッセージが送信（及び再送）される毎に、０（初期配信）からカウントアップされる、再試行カウンターを伝える。再試行する毎に、カウンターがインクリメントされて再試行回数を示す。次いで、配信サーバは、配信サーバ上で構成されているルールセットに基づき、再試行カウント結果に基づいてメッセージに対する代替配信方法を試みることを選択することができる。これにより、指定された回数の再試行が行われた後に、メッセージをＳＭＳ、ＭＭＳ、又は電子メールに変換することができる。最初の反復において、メッセージが、３回目の再試行から始めるＳＭＳを介した配信に対して試みられる。
【００３８】
セルサイトなどを含むネットワーク情報とともにメッセージを配信するそれぞれの試行のログが、サーバによってデータベース１１０に格納される。そのような場合、配信サーバ１０５は、ネットワーク１０４のＨＬＲ（ホームロケーションレジスタ）に結合することができる。メッセージを正常に配信できなかった場合、データベース１１０にログ記録が書き込まれる。ログは、成功しなかった配信に関する情報を記録するだけでなく、受信モバイルデバイスに関係するＨＬＲ情報も記録する。その後、こうして得られたデータについて、標準的なデータ分析ツールを使用して分析することで、メンテナンス及び／又はアップグレードを必要とする特定のネットワークエリアを明らかにすることができる。このようなロギングによって、特定のサービスエリア問題、又はネットワークの他の不備を明確にすることができる。それに加えて、データベース１１０は、以下でさらに詳しく説明されるユーザメッセージ用のストレージファシリティとして使用することができる。
【００３９】
図２は、本発明の一実施形態によるメッセージングシステム１００によって使用される信号伝送を示している。メッセージの配信を行うために、配信サーバ１０５は、最初に所期の受信者（複数可）１０７及びユーザ優先配信チャネルを識別する必要がある。ネットワーク内のそれぞれのクライアントデバイス（発信又は受信デバイス１０１、１０７）は、時間ベースのハートビートトランザクション２１３を使用してサーバと交信し、これにより、サーバは、ネットワーク内のすべてのデバイスの存在を追跡することができる。この例では、それぞれのクライアントデバイスは、ハートビートを１０分おきにサーバに送信する。サーバは、送られてくると予期していてハートビートを受信しなかった場合、そのクライアントデバイスはオフラインになっているものとしてマークする。
【００４０】
ハートビートトランザクションは、クライアントデバイスの存在を示すために使用されるだけでなく、クライアントデバイスで現在利用可能なサービスのレベルを示すためにも使用される。例えば、ユーザが、例えばＩＭ通信を使用する優先配信を指示した場合、サーバは、受信者１０７がサーバに接続されていて、受信者デバイスのハートビートを通じて提供された情報を介してメッセージを受信するのに利用可能な状態にあることをチェックして確認する。場合によっては、受信デバイス１０７は、ＩＭメッセージを受信する用意ができていないか、又は受信できないことがあり、その場合、配信サーバ１０５は、ＳＭＳ ２０９、電子メール２０７、又は他の適切なメッセージングフォーマットなどの適用可能な代替配信チャネルを使用してそれぞれの受信者にメッセージを送信することを試みる。それぞれの配信アプローチについて、メッセージが配信されたときに確認／確認応答メッセージが受信者（又は、ＳＭＳ及び電子メールの場合には状況に応じて、配信エージェント）から届くと予期されている。次いで、これは、メッセージの最初の送信者に受け渡される。上述のように、システムが確認を最初に送信されたメッセージに関連付けることができる限り、確認メッセージの具体的フォーマットは重要でない。
【００４１】
図２に示されているように、発信デバイス１０１は、ＩＭメッセージ２０１を配信サーバ１０５に転送し、一次配信チャネル２０２を介して受信者デバイス１０７に配信する。配信サーバ１０５は、確認応答メッセージを発信デバイス１０１に送り返す。次いで、配信サーバ１０５は、ＩＭメッセージを受信者デバイス１０７に送信する。次いで、受信者デバイス１０７が、確認応答メッセージ２０３を配信サーバ１０５に送り返し、次いで、配信サーバ１０５が、任意選択で、メッセージ２０４の成功したエンドツーエンド配信を送信デバイス１０１に通知する。一次配信チャネル２０２が利用不能である場合、配信サーバ１０５は、電子メールゲートウェイ１０８を介した電子メール２０５、又はＳＭＳＣ １０９を介したＳＭＳ ２０６などの代替配信チャネルを介して経路指定によりメッセージを送ることを試みる。
【００４２】
電子メールが選択された代替配信経路である場合、配信サーバ１０５は、メッセージをそのネイティブフォーマットから適切な電子メールフォーマットに変換してから、メッセージ２０５を電子メールゲートウェイに転送する。次いで、電子メールゲートウェイ１０８が、メッセージ２０７を受信者デバイス１０７に転送し、次いで、受信者デバイスが、確認応答メッセージ２０８を送り返す。同様に、ＳＭＳ又はＭＭＳが代替配信経路として選択された場合、配信サーバ１０５は、メッセージをそのネイティブフォーマットから適切なサイズのＳＭＳパケットに変換してから、メッセージをＳＭＳＣ １０９に転送する。しかし、本発明のこの実施形態においては、この場合に、メッセージ全体を受信者デバイス（複数可）１０７に配信するのに必要なだけのＳＭＳメッセージパケットが送信されるので、任意選択でメッセージの切り捨てを行うこともできる。次いで、ＳＭＳＣ １０９が、メッセージ２０９を受信者デバイス１０７に転送し、次いで、受信者デバイスが、確認応答メッセージ２１０を送り返す。図示されている例において、サーバは、電子メールを介して送信されたメッセージ２１１、２１２（破線の輪郭で示されている）の確認を、或いは電子メールサーバ及び／又はＳＭＳＣ／ＳＭＳゲートウェイを介したＳＭＳの確認を求めないが、その理由は、これらのフォーマットが両方とも、許容できる信頼性を有するとみなされるからである。しかし、当業者であれば、そのような検証手順をシステムに容易に組み込めることを理解するであろう。
【００４３】
上述のように、配信サーバ１０５から受信者デバイス１０７へのメッセージの経路指定は、配信サーバ１０５上に実装された一組の所定のルールを介して行うことができる。このルールセットは、再試行回数、使用される代替配信チャネル及びその順序、再試行が続けられる時間、再試行の頻度を決定する。以下の表は、本発明の一実施形態によるテキスト型メッセージングシステムでメッセージの経路指定を行うために適用されるルールセットの一例を示している。
【表１】
【００４４】
メッセージが画像又は他のファイルを含む本発明の他の実施形態では、代替配信チャネルは、ＭＭＳ又は他の何らかのファイル転送プロトコルとして構成することができる。
【００４５】
ユーザは、例えば、オンラインインターフェース又は同様のものを介してそのプリファレンスに合わせてルールセットを構成することができる。次いで、ルールステータスの変更が、特定のユーザに対するルールセットのオペレーションを修正する配信サーバに伝達される。この例では、ユーザは、そのステータス設定、そのオフライン設定、及びその現在のネットワークプレゼンスに基づいてメッセージの経路指定をどのように行うかを定義することができる。上述のように、ハートビートトランザクションが、ユーザのプレゼンスを配信サーバに通知する。しかし、ユーザがメッセージを受信できるかどうかは、ユーザ定義ステータス設定、その「オフライン設定」、及びユーザが接続（ログイン）されているかどうかの組み合わせに基づいて判定される。
・ ＳＭＳ経路指定。オフラインの場合、クライアントデバイスステータスがオフラインに設定されたときにＳＭＳを介してメッセージを経路指定するようサーバに通知する。
・ 電子メール経路指定。ユーザがクライアントデバイスにログオンしていない場合に電子メールを送信するようメッセージの経路指定を行う。
・ ウェイクアップ。システムがＳＳ７又はＳＭＳ０を使用して受信デバイス上のクライアントアプリケーションを目覚めさせ、次いでメッセージをユーザに送るようにする。
・ サーバに保存。ユーザがそのクライアントデバイスに再度ログインするまでサーバ上にメッセージを保存するようサーバに通知する。
【００４６】
したがって、利用可能性が、システムのルールセットの適用をユーザ側で修正することを可能にするユーザ定義属性となる。表１に示されているように、ユーザがオンラインであるかオフラインであるかに応じてユーザが選択できるシステム内のステータスが多数ある。４種類の主要なステータスは、「利用可能」、「利用不可能」、「妨害しない」、及び「不可視」である。ネットワークにおいて、ユーザによって選択されたオフライン設定により、代替配信チャネルを介してメッセージの配信をタイミングよく行える場合、ユーザによって選択されたステータスは、オフラインのときに保持される。ネットワーク内ユーザが、電子メール又は「サーバ上に保存」などの適時な配信を許可しないオフライン設定を選択した場合、その利用可能性は、オフラインのときに「通信できない」と示される。クライアントデバイスの「ネットワーク外」のユーザについては、制限されたオフライン設定が利用可能である、つまり、「サーバ上に保存」及び「電子メール」である。したがって、オフラインのネットワーク外のユーザは、「通信できない」と常にみなされる。
【００４７】
上記に加えて、このシステムでは、ユーザがメッセージにさまざまな特性、例えば、メッセージ重要度を割り当てることができるようにすることも可能である。メッセージ重要度は、送信者側で「通常」又は「高」に設定することができる。メッセージ重要度は、メッセージヘッダ内にデータとして保持され、メッセージ処理を決定するためにネットワーク全体にわたって使用される。
【００４８】
ユーザが、高重要度を選択した場合、ネットワーク、サーバインフラストラクチャ、及び受信デバイスを介したメッセージ配信ルールでは、メッセージの処理方法が異なる。典型的には、高重要度メッセージは、通信事業者から割増料金を課金される。
【００４９】
高重要度メッセージの場合、このルールセットの下での通常処理に対し以下の変更が行われる。
・ 送信デバイスからサーバへの再試行が、１分おきに、最大３回まで行われる。メッセージの送信に失敗した場合、送信者は、送信デバイス上で警告を受け、続けるか、又は代替配信チャネルに切り換えるかの選択肢を与えられる。
・ サーバから受信デバイスへの再試行が、１分おきに、最大３回まで行われ、その後、代替チャネルに切り換える。
・ 高重要度メッセージは、決して、電子メールにしか経路指定されないわけではない。受信者が、そのオフライン設定で電子メールを指定している場合、メッセージは、電子メールにコピーされるが、ＳＭＳへも経路指定される。
・ 受信デバイス上で、高重要度メッセージに対し、特別警告音が鳴る。
・ 受信デバイス上で、受信の確認応答を求める要求がユーザに対し示され、確認応答が、メッセージとして元の送信者に（日時の確認とともに）送り返される。
・ メッセージは、データベース１１０（後述）上で高重要度であるというタグを付けられる。
【００５０】
上で簡単に述べたように、データベース１１０は、リモートストレージファシリティとして使用することができる。この「ＳｔｏｒｅｌＴ」機能は、配信サーバ１０５との間でやり取りされるすべてのメッセージのフルメッセージアーカイブファシリティを実現するものである。メッセージへのアクセスは、ウェブサイトを介して行う。ユーザは、ログインしてから、広範な検索ファシリティ及びタグ付け機能を利用してメッセージにアクセスすることができる。ユーザがメッセージを削除しなくて済むように、十分な容量のストレージが確保されている。
【００５１】
配信サーバは、非同期プロセスで送受信されたそれぞれのメッセージをデータストレージファシリティ１１０に書き込む。メッセージは、典型的には、送信者／受信者毎に別々に書き込まれる。ストレージの必要な容量は、メッセージの単一コピーを書き込み、そのメッセージを複数の送信者／受信者に関連付けるリンクを使用することによって減らすことができる。このアプローチでは検索速度の低下のトレードオフが認められる。
【００５２】
例えば、メッセージが以下のいくつかの特性を含む場合、メッセージのタグ付けを、自動的に実行させることができる。
・ ウェブサイトへのリンクを含む
・ 電話番号であることを示唆する基準を満たす数値を含む
・ 住所を含む（「通り」、「アパート」、「ｓｔ．」、「ａｐｔ」などのキーワードのデータベースに基づく）
【００５３】
「ＳｔｏｒｅＩＴ」ユーザインターフェースは、ＰＣバージョンのメッセージングクライアントを介してメッセージの転送及び返信を行う機能も備える。ウェブインターフェースとしては、以下のものが挙げられる。
・ ユーザモバイルメッセージングアプリケーションと同じユーザＩＤ及びパスワードを使用してログインできる能力。
・ 送受信されたすべてのメッセージへのアクセス。
・ 送信日時、受信者／送信者情報を含むメッセージメタデータ。
・ メッセージのタグ付け（ユーザ選択可能なタグ、並びに自動化されたタグ、例えば、ウェブサイトへのリンク又は番号を含むメッセージにタグ付けする）。
・ メッセージングオプション（メッセージに返信する、新規メッセージを送信するなど）。
・ 友達リストへのアクセス。
・ メッセージアーカイブ管理（選択された受信者又はすべての受信者について一部のメッセージ又は全部のメッセージを削除する）。
・ ユーザ設定（ＳｔｏｒｅＩＴをオフにする、特定の受信者についてオフにする、特定の受信者についてオンにするなど）。
【００５４】
上記の実施形態は、本発明を例示するために提示したものにすぎず、またそれに対するさらなる修正及び改善は、当業者には明らかなように、本明細書に記載されている本発明の広い範囲及び分野内に収まるとみなされることは理解されるであろう。特に、以下の追加及び／又は修正（網羅していない）は、本発明の範囲から逸脱することなく行うことができる。
・ 再試行の管理は、配信サーバ１０５の代わりに発信デバイス１０１が実行することができる。
・ 受信の確認応答は、配信サーバ１０５をバイパスすることができる。このアプローチでは、発信デバイス１０１は、受信者デバイス１０７への配信を保証するように構成される。
・ 発信デバイス１０１は、メッセージの配信ステータスに関する情報を与えるインジケータをユーザに対して表示するように構成することができる。
・ 発信デバイス１０１は、第１の配信チャネルを介してメッセージの配信を実行できない場合に代替配信チャネルを選択するように構成することができる。
・ 代替配信が、メッセージの配信に使用される場合、発信デバイス又は少なくとも１つのサーバのいずれかが、代替配信チャネルのメッセージング標準に適合するようにメッセージを再フォーマットすることができる。
・ 確認応答メッセージが発信デバイスに返されない場合、実施形態において説明されているようなビジネスルール及びユーザ設定に加えて、配信サーバ１０５にメッセージを送信するように一次配信チャネルをさらに構成することができ、また配信サーバ１０５は二次配信チャネルに切り換えるようサーバに指令する命令をメッセージヘッダ内に入れる。
・ メッセージの配信ステータスを示すインジケータをユーザに対して表示することができる。例えば、メッセージ再試行が発信デバイスによって制御される場合、送信アプリケーションを終了しようとしているユーザに対し、メッセージが配信中であるとまだ確認されていないこと、及び再試行がまだ未解決であることを示す警告が出される。
【技術分野】
【０００１】
本出願は、拡張メッセージングサービスを提供するためのシステム及び方法に関する。特に、本発明は、限定はしないが、移動体通信ネットワーク内の拡張メッセージングサービス及び／又はファイル共有サービスを提供することに関する。
【背景技術】
【０００２】
移動体通信システムにおいて最も広範に使用されている形態のメッセージングは、ショートメッセージサービス（ＳＭＳ）である。典型的には、メッセージは、発信デバイスから、蓄積交換機構を備えるショートメッセージサービスセンサー（ＳＭＳＣ）に送信される。ＳＭＳＣとハンドセットとの間のショートメッセージの伝送は、ＳＳ７プロトコルの移動通信応用部（ＭＡＰ）を使用して実行される。メッセージは、ＭＡＰｍｏ−ＦｏｒｗａｒｄＳＭ及びｍｔ−ＦｏｒｗａｒｄＳＭオペレーションを使って送信され、そのペイロード長は、信号プロトコルの制約条件によって正確に１４０オクテット（１４０オクテット＝１４０×８ビット＝１１２０ビット）に制限される。ショートメッセージは、さまざまなアルファベット、つまり、デフォルトのＧＳＭ ７ビットアルファベット（以下に示す）、８ビットデータアルファベット、及び１６ビットＵＴＦ−１６／ＵＣＳ−２アルファベットを使用して符号化することができる。
【０００３】
その結果、加入者がハンドセットにおいてどのアルファベットを構成したかに応じて、最大個別ショートメッセージサイズが７ビット文字１６０個、８ビット文字１４０個、又は１６ビット文字７０個（スペースを含む）となる。ＧＳＭ ７ビットアルファベットのサポートは、ＧＳＭハンドセット及びネットワーク要素については必須であるが［１５］、アラビア語、中国語、韓国語、日本語、又はキリル文字言語（例えば、ロシア語）などの言語の文字は、１６ビットＵＣＳ−２文字コード（Ｕｎｉｃｏｄｅ）を使用して符号化されなければならない。経路指定データ及び他のメタデータが、ペイロードサイズに加わる。
【０００４】
受信者に到達不能である場合、ＳＭＳＣは、後から再試行するためにメッセージをキューに入れる。いくつかのＳＭＳＣは、伝送が１回だけ試行される「転送しっぱなし」というオプションも備える。したがって、メッセージ配信はベストエフォート型であり、そのため、メッセージがこのメッセージの受信者に実際に配信されることが保証されず、またメッセージの遅延又は完全な喪失は、特にネットワーク間で送信するときには稀なことではない。
【０００５】
近年、インスタントメッセージと電子メールなどの付加的メッセージサービスがモバイル環境に移行した。標準的なデスクトップ環境では、インスタントメッセージング（ＩＭ）は、１つのネットワーク上で２人以上の参加者の間のリアルタイムテキストベースの通信又はほぼリアルタイムの通信を実現した。したがって、電子メールなどのサービスとＩＭとの際立った違いは、ユーザ間の通信の同期が感知されるかどうかであり、メッセージングはリアルタイム又はほぼリアルタイムで実行される。インスタントメッセージは、典型的には、電子メールの永続的性質とのギャップを埋め、ＵＲＬ又はドキュメントのスニペットのような情報（電話を介して通信するときには扱いにくくなる可能性がある）の高速交換を容易にするローカルメッセージ履歴としてログに記録される。ＩＭを使用すると、通信を効果的に、また効率的に行うことができ、確認応答又は返信の受信をすぐに行うことができる。
【０００６】
モバイルインスタントメッセージング（ＭＩＭ）は、標準的なデスクトップＩＭアプリケーションのものとわずかに異なる。ＭＩＭは、デスクトップメッセージングのエクスペリエンスを、移動途中にあるという使用シナリオに移し換えようとするプレゼンス機能対応のメッセージングサービスである。一方で、デスクトップエクスペリエンスの中核となる考え方のいくつかが、接続されているモバイルデバイスに適用されるが、それ以外の考え方は、適用されない。帯域幅、メモリサイズ、メディアフォーマットの利用可能性、キーパッドベースの入力、スクリーン出力、ＣＰＵ性能、及び電池容量など、実際に十分で、パワフルで、しかも使い勝手のよいモバイルエクスペリエンスを実現するために、例えば、フォームファクタ及びモビリティに関連する違いのいくつかを考慮する必要があるが、これは、デスクトップデバイスユーザ、さらにはネットワークに接続した状態を維持するノマディックユーザがもたらす核心的問題である。
【０００７】
上述のようにモバイルデータネットワークは信頼性がなく、メッセージは、行方不明になってしまうことがある（メッセージ配信はベストエフォート型である）。既存のモバイルインスタントメッセージング（ＩＭ）の「ゲートウェイ」製品は、ＩＭメッセージを「カジュアルチャット」として扱う。そのようなものとして、ＭＩＭはメッセージの喪失を重大なこととみなさないため、メッセージが対象受信者に配信される保証はない。したがって、ＭＩＭの現在の実装は、情報の配信が重要であるビジネス環境又は他の用途にあまり向いていない。
【０００８】
上述のように、大半の既存のメッセージングシステム（例えば、ＳＭＳ）は、ストレージ容量が限られている。ＳＭＳの場合、いかなるメッセージバックアップ機能も働かせるために、ローカルのＰＣバックアップ／アーカイブが必要になる場合があり、その場合、プロセスは本質的に手動である。メッセージを保存したい場合、ユーザは、新しいメッセージが入るスペースを解放するために自分のモバイルデバイス上でメッセージを削除する前にこの手動プロセスを実行しなければならない。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
したがって、カジュアルユーザだけでなくビジネスユーザ又はクリティカルユーザにも受け入れられる信頼性の高いメッセージングソリューションを提供する必要がある。後で検討できるように送受信されたメッセージをユーザ側でバックアップすることができるファシリティを備えることも有利であろう。
【課題を解決するための手段】
【００１０】
したがって、本発明の一態様においては、拡張メッセージシステムが提供され、前記システムは、
第１の配信チャネルを介して少なくとも１つの受信者デバイスに配信するために発信デバイスからメッセージを受信するように構成された少なくとも１つのサーバを備え、
少なくとも１つのサーバが、第１の配信チャネルを介してメッセージの配信を実行できない場合に代替配信チャネルを選択するようにさらに構成され、
或いは、発信デバイスが、第１の配信チャネルを介してメッセージの配信を実行できない場合に代替配信チャネルを選択するように構成されてもよい。
【００１１】
メッセージングネットワークは、発信デバイス、少なくとも１つのサーバ、及び１つ又は複数の受信者を含むものと考えることができる（これらは、モバイルデバイスでも電子メール又は他の受信者タイプであってもよい）。
【００１２】
メッセージは、テキストメッセージであると考えられるか、或いは他の何らかの種類のデータメッセージ又は限定はしないが、画像、音楽ファイル、若しくはドキュメントなどのファイルとすることもできる。
【００１３】
配信の保証の原理は、メッセージ伝送のすべてのレッグにおいて適用される。したがって、発信デバイスは、メッセージをどのように送信するかを規律するための、１つ又は複数の定義済みルールセットを備えることができる。ルールセットは、第１の配信チャネルでメッセージを再送するまでに発信デバイスが待っている期間、代替配信チャネルに切り換えるまで第１の配信チャネルで再試行を続ける頻度、及び代替配信チャネルに切り換えるまで第１の配信チャネルで再試行を続ける時間の長さに関する情報を含むことができる。メッセージは、発信デバイスがメッセージを少なくとも１つのサーバに配信しようとする毎にインクリメントされる再試行カウンターを備えることができる。このシステムを使用すると、ユーザは、そのプリファレンスに従ってルールセットを再構成することができる。
【００１４】
発信デバイスは、メッセージの配信ステータスに関する情報を与えるインジケータをユーザに対して表示することができる。
【００１５】
第１の配信チャネルは、インターネットプロトコル（ＩＰ）ベースのメッセージングチャネルでもよく、またメッセージは、インスタントメッセージ若しくはチャットメッセージでもよい。好ましくは、代替配信チャネルは、ＳＭＴＰ、ＭＩＭＥ、ＰＯＰ、ＩＭＡＰ、又は同様のメッセージングチャネルである。適切には、代替配信チャネルは、ＳＳ７又は同様のメッセージングチャネルとすることができる。代替配信が、メッセージの配信に使用される場合、発信デバイス又は少なくとも１つのサーバは、代替配信チャネルのメッセージング標準に適合するようにメッセージを再フォーマットすることができる。
【００１６】
好ましくは、発信デバイスは、第１のメッセージングチャネルを介してメッセージを受信した後に前記少なくとも１つのサーバから確認応答メッセージを受信するように構成される。
【００１７】
確認応答メッセージが発信デバイスに返されない場合、発信デバイスは、送信者のビジネスルール及びユーザ設定を適用して、実行すべきアクションを決定する。典型的には、これは、定義された回数の再試行及びその後の、配信が行われる代替配信チャネルへの切り換えを含むことができる。この場合、実行すべきアクションを決定するためにユーザの介入を必要とすることもある。さらに、これは、二次配信チャネルに切り換えるようサーバに指令するメッセージヘッダ内に記述された命令を伴う、一次配信チャネルによるサーバへの配信を含むことができる。
【００１８】
メッセージが前記少なくとも１つのサーバに到達した後、１人又は複数の受信者へのメッセージの経路指定がなされなければならない。最初に、少なくとも１つのサーバが、発信デバイスのユーザによって指定された配信チャネルを使用してメッセージを配信することを試みる。
【００１９】
サーバは、メッセージをどのように送信するかを規律するための、１つ又は複数の定義済みルールセットを備えることができる。ルールセットは、第１の配信チャネルでメッセージを再送するまでに少なくとも１つのサーバが待っている期間、代替配信チャネルに切り換えるまで第１の配信チャネルで再試行を続ける頻度、及び代替配信チャネルに切り換えるまで第１の配信チャネルで再試行を続ける時間の長さに関する情報を含むことができる。メッセージは、サーバがメッセージを少なくとも１つの受信者デバイスに配信しようとする毎にインクリメントされる再試行カウンターを備えることができる。このシステムを使用すると、ユーザは、そのプリファレンスに従ってルールセットを再構成することができる。或いは、サーバは、再試行を管理する責任を発信デバイスに委ねることもできる。
【００２０】
好ましくは、少なくとも１つのサーバは、第１のメッセージングチャネルを介してメッセージを受信した後に前記少なくとも１つの受信者デバイスから確認応答メッセージを受信するように構成される。このシステムは、少なくとも１つのサーバが少なくとも１つの受信者デバイスによるメッセージの受信を発信デバイスに通知するように構成することもできる。このエンドツーエンドによる通知は、発信デバイスが再試行プロセスを管理している場合に確実な配信を行うためにのみ必要である。そうではなく、少なくとも１つのサーバがプロセスを制御し続けており、配信の確実性を維持している場合、受信確認応答を発信デバイスに返すことは必須でない。確認応答メッセージは、それが最低限、その確認応答をメッセージに関連付けるのに十分な情報を含んでいさえすれば、適当ないかなるフォーマットのものでもよい。確認応答は、例えば、シリアル番号、タイムスタンプ、一意的なＩＤ、又は同様のものを含むことができる。一意的なＩＤは、メッセージの受信に関連付けられているシリアル番号及びタイムスタンプから生成することができる。
【００２１】
或いはサーバが、受信の確認応答を単純に発信デバイスに渡すこともできる。このアプローチでは、受信者デバイスへの配信が確実に行われるようにする、発信デバイスの責任が高まる。
【００２２】
確認応答メッセージが少なくとも１つのサーバに返されない場合、サーバは、送信者及び受信者のビジネスルール及びユーザ設定を適用して、実行すべきアクションを決定する。典型的には、これは、定義された回数の再試行及びその後の、配信が行われる代替配信チャネルへの切り換えを含むことができる。
【００２３】
少なくとも１つのサーバをデータベースに結合することができる。サーバは、メッセージを配信しようとするそれぞれの試みのログを、ネットワーク固有の情報とともにデータベースに定期的に書き込むように構成することができる。データベースは、配信サーバを通るすべてのメッセージに対するメッセージリポジトリとして使用することもできる。システムは、ユーザから送信され、ユーザが受信するすべてのメッセージにアクセスするためのユーザ向けの適切なインターフェースを備えることができる。
【００２４】
本発明の他の態様においては、メッセージの経路指定を行うための方法が提供され、前記方法は、
１つのサーバにおいて、少なくとも１人の受信者に配信するために発信デバイスからメッセージを受信するステップと、
第１の配信チャネルを介して少なくとも１つの受信者デバイスにメッセージを転送するステップと、
前記少なくとも１つの受信者デバイスから確認応答メッセージを受信するのを待つステップを含み、確認応答が受信メッセージでない場合に、サーバは代替配信チャネルを介して前記少なくとも１つの受信者デバイスにメッセージを再送する。
【００２５】
この方法は、代替配信チャネルを介してメッセージを再送する前に所定の回数だけ第１の配信チャネルを介してメッセージを再送するステップを含むことができる。適切には、第１の配信チャネルを介してメッセージを再送するステップは、メッセージに関連する再試行カウンターをインクリメントするステップを含む。この方法は、任意選択で、事前に第１の配信チャネルを介して配信を行わせることができなかった場合に代替配信チャネルを介してメッセージの転送を発信デバイスにおいて開始するステップを含むことができる（つまり、発信デバイスは、第１の配信チャネルの再試行をオーバーライドする能力を有する）。
【００２６】
適切には、代替配信チャネルを介してメッセージを転送するステップは、チャネルのメッセージング標準に適合するようにメッセージを再フォーマットするステップをさらに含む。
【００２７】
この方法は、重複するメッセージを識別するための受信デバイス上の処理を組み込むこともできる。ネットワークの信頼性が低いシナリオでは、送信側の少なくとも１つのサーバ又は発信デバイスが受信に成功したことを示す応答を返す前に何回もメッセージが送信されることがある。これが、メッセージそれ自体ではなく、送信に失敗した受信によるものである場合、その結果、受信デバイスに重複メッセージが到着することがある。これは、上述したようにメッセージに含まれる一意的な識別子を使用することによって対処される。受信デバイスは、すでに受信されているメッセージ内の一意的な識別子を見て、すでに受信され、表示されているメッセージを再表示しない。
【００２８】
本発明の他の態様においては、メッセージの配信ステータスを示すインジケータをユーザに対して表示することができる。一アプローチにおいて、メッセージ再試行が発信デバイスによって制御される場合、送信アプリケーションを終了しようとしているユーザに対し、メッセージが配信されているとまだ確認されていないこと、及び再試行がまだ未解決であることを示す警告が出されることが好ましい。
【００２９】
本発明をより理解しやすくし、実用上の効果をもたらすために、本発明の好ましい実施形態を例示する、添付の図面を参照する。
【図面の簡単な説明】
【００３０】
【図１】本発明の一実施形態による拡張メッセージシステムの略ブロック図である。
【図２】本発明の一実施形態によるメッセージングシステム内のさまざまな地点間の信号伝送を示す流れ図である。
【発明を実施するための形態】
【００３１】
図１を参照すると、本発明の一実施形態によるメッセージングシステム１００が示されている。本発明の状況では、メッセージは、テキストメッセージであると考えられるか、或いは他の何らかの種類のデータメッセージ、又は限定はしないが、画像、音楽ファイル、若しくはドキュメントなどのファイルとすることもできる。
【００３２】
図に示されているように、デバイスメッセージングアプリケーション１０２を介してメッセージを作成するために、発信デバイス１０１（例えば、モバイルハンドセット、ＰＤＡ、ポータブルコンピュータ、又は同様のもの）がユーザによって使用される。この場合、メッセージングアプリケーションは、モバイルＩＭアプリケーションである。ユーザが所望のメッセージを作成した後、ユーザは、次いでその連絡先又は友達リスト１０３から１つ又は複数の受信者１０７を選択する。受信者１０７は、同じネットワーク１０４のメンバーでも異なるネットワーク１０６のメンバーでもよい。受信者１０７が、選択された後、次いで、デバイスのメッセージングアプリケーション１０２は、ネットワーク１０４を介してメッセージを、対象受信者と受信者デバイス（複数可）１０７へのメッセージに使用される好ましい配信チャネルとに関する情報を備える配信サーバ１０５に転送する。好ましい配信チャネルは、データ（インターネットプロトコル／ＩＰ）ベースのメッセージング（例えば、インスタントメッセージング又はチャット）、ＳＭＳ、ＭＭＳ、電子メール、又は他の任意の定義済みメッセージングフォーマットとすることができる。発信デバイス１０１が、メッセージを配信サーバ１０５に転送した後、発信デバイス１０１は、メッセージの受信を確認した配信サーバ１０５からの確認応答メッセージ／パケットを受信することを予期する。確認応答の特定のフォーマットは、最初の送信済みメッセージに容易に関連付けられる場合には重要ではない。確認応答メッセージを最初の送信済みメッセージに関連付けるためのアプローチは多数ある。例えば、この関連付けは、確認応答メッセージを最初の送信済みメッセージに関連付ける一意的なメッセージＩＤを生成するために使用されるシリアル番号、タイムスタンプ、又は同様のものを使用することで実行できる。
【００３３】
発信デバイス１０１が、確認応答を受信できない場合、定義済みルールセットに基づき、所定の時間だけ待って、その後、メッセージの再送を試みる。定義済みルールセットは、メッセージを再送するまでにデバイスが待つ期間を定義するだけでなく、再試行を続ける頻度及び長さをも定義する。例えば、このルールセットは、送信デバイス１０１による最大１０回の再試行を許容し、最初にメッセージを送信しようとしてからそれぞれの再試行が５分間隔となるように、構成することができる。最大試行回数に達しても送信デバイス１０１がメッセージ配信を完了できない場合に、所定の期間の経過後に、メッセージを経路指定に従って配信サーバ１０５に送るために代替方法を介して配信を行わせることを試みることができる。
【００３４】
さらに、ユーザが、メッセージ送信未完了のまま発信デバイスのクライアントアプリケーションをログオフするか、又は終了しようとした場合、発信デバイスのクライアントアプリケーションは、メッセージの配信ステータスに関してユーザに通知し、ログオフ又は終了を完了する前に代替配信オプションを選ばせる。
【００３５】
図１に示されているように、配信サーバ１０５は、この場合、複数の冗長配信チャネルを構成するように少なくとも１つの電子メールサーバ１０８及び／又は少なくとも１つのメッセージングセンター（ＳＭＳＣ、ＭＭＳＣ）１０９に結合される。一次配信チャネルを介してメッセージを経路指定で受信者デバイス（複数可）に送ることができない場合（つまり、メッセージのネイティブフォーマット）、配信サーバは、次の好ましい配信フォーマットに切り換わる。例えば、配信サーバ１０５は、ＩＭからＳＭＳに切り替わり、メッセージの配信を実行させることができる。
【００３６】
或いは発信デバイス１０１は、ユーザによって選択された一次配信チャネルを介してメッセージを配信できない場合に代替配信チャネルを選択するようユーザに促すこともできる。場合によっては、利用可能でないとサーバに認識されている配信チャネルをユーザが選択することもあり、例えば、ユーザがＩＰベースのメッセージングを選択することもあるが、サーバは、このタイプのメッセージを受信するのにその受信デバイスを利用できないことを認識している。この場合、配信サーバ１０５は、代替配信チャネル（例えば、電子メールゲートウェイ１０８、ＳＭＳＣ １０９）を介して配信するためにメッセージを代替メッセージフォーマット（ＳＭＳ、電子メールなど）に変換する。
【００３７】
一次配信チャネルは、二次配信チャネルに切り換えるようサーバに指令するメッセージヘッダ内に記述された一組の命令を含むことができる。配信サーバ１０５によってメッセージが送信（及び再送）される毎に、０（初期配信）からカウントアップされる、再試行カウンターを伝える。再試行する毎に、カウンターがインクリメントされて再試行回数を示す。次いで、配信サーバは、配信サーバ上で構成されているルールセットに基づき、再試行カウント結果に基づいてメッセージに対する代替配信方法を試みることを選択することができる。これにより、指定された回数の再試行が行われた後に、メッセージをＳＭＳ、ＭＭＳ、又は電子メールに変換することができる。最初の反復において、メッセージが、３回目の再試行から始めるＳＭＳを介した配信に対して試みられる。
【００３８】
セルサイトなどを含むネットワーク情報とともにメッセージを配信するそれぞれの試行のログが、サーバによってデータベース１１０に格納される。そのような場合、配信サーバ１０５は、ネットワーク１０４のＨＬＲ（ホームロケーションレジスタ）に結合することができる。メッセージを正常に配信できなかった場合、データベース１１０にログ記録が書き込まれる。ログは、成功しなかった配信に関する情報を記録するだけでなく、受信モバイルデバイスに関係するＨＬＲ情報も記録する。その後、こうして得られたデータについて、標準的なデータ分析ツールを使用して分析することで、メンテナンス及び／又はアップグレードを必要とする特定のネットワークエリアを明らかにすることができる。このようなロギングによって、特定のサービスエリア問題、又はネットワークの他の不備を明確にすることができる。それに加えて、データベース１１０は、以下でさらに詳しく説明されるユーザメッセージ用のストレージファシリティとして使用することができる。
【００３９】
図２は、本発明の一実施形態によるメッセージングシステム１００によって使用される信号伝送を示している。メッセージの配信を行うために、配信サーバ１０５は、最初に所期の受信者（複数可）１０７及びユーザ優先配信チャネルを識別する必要がある。ネットワーク内のそれぞれのクライアントデバイス（発信又は受信デバイス１０１、１０７）は、時間ベースのハートビートトランザクション２１３を使用してサーバと交信し、これにより、サーバは、ネットワーク内のすべてのデバイスの存在を追跡することができる。この例では、それぞれのクライアントデバイスは、ハートビートを１０分おきにサーバに送信する。サーバは、送られてくると予期していてハートビートを受信しなかった場合、そのクライアントデバイスはオフラインになっているものとしてマークする。
【００４０】
ハートビートトランザクションは、クライアントデバイスの存在を示すために使用されるだけでなく、クライアントデバイスで現在利用可能なサービスのレベルを示すためにも使用される。例えば、ユーザが、例えばＩＭ通信を使用する優先配信を指示した場合、サーバは、受信者１０７がサーバに接続されていて、受信者デバイスのハートビートを通じて提供された情報を介してメッセージを受信するのに利用可能な状態にあることをチェックして確認する。場合によっては、受信デバイス１０７は、ＩＭメッセージを受信する用意ができていないか、又は受信できないことがあり、その場合、配信サーバ１０５は、ＳＭＳ ２０９、電子メール２０７、又は他の適切なメッセージングフォーマットなどの適用可能な代替配信チャネルを使用してそれぞれの受信者にメッセージを送信することを試みる。それぞれの配信アプローチについて、メッセージが配信されたときに確認／確認応答メッセージが受信者（又は、ＳＭＳ及び電子メールの場合には状況に応じて、配信エージェント）から届くと予期されている。次いで、これは、メッセージの最初の送信者に受け渡される。上述のように、システムが確認を最初に送信されたメッセージに関連付けることができる限り、確認メッセージの具体的フォーマットは重要でない。
【００４１】
図２に示されているように、発信デバイス１０１は、ＩＭメッセージ２０１を配信サーバ１０５に転送し、一次配信チャネル２０２を介して受信者デバイス１０７に配信する。配信サーバ１０５は、確認応答メッセージを発信デバイス１０１に送り返す。次いで、配信サーバ１０５は、ＩＭメッセージを受信者デバイス１０７に送信する。次いで、受信者デバイス１０７が、確認応答メッセージ２０３を配信サーバ１０５に送り返し、次いで、配信サーバ１０５が、任意選択で、メッセージ２０４の成功したエンドツーエンド配信を送信デバイス１０１に通知する。一次配信チャネル２０２が利用不能である場合、配信サーバ１０５は、電子メールゲートウェイ１０８を介した電子メール２０５、又はＳＭＳＣ １０９を介したＳＭＳ ２０６などの代替配信チャネルを介して経路指定によりメッセージを送ることを試みる。
【００４２】
電子メールが選択された代替配信経路である場合、配信サーバ１０５は、メッセージをそのネイティブフォーマットから適切な電子メールフォーマットに変換してから、メッセージ２０５を電子メールゲートウェイに転送する。次いで、電子メールゲートウェイ１０８が、メッセージ２０７を受信者デバイス１０７に転送し、次いで、受信者デバイスが、確認応答メッセージ２０８を送り返す。同様に、ＳＭＳ又はＭＭＳが代替配信経路として選択された場合、配信サーバ１０５は、メッセージをそのネイティブフォーマットから適切なサイズのＳＭＳパケットに変換してから、メッセージをＳＭＳＣ １０９に転送する。しかし、本発明のこの実施形態においては、この場合に、メッセージ全体を受信者デバイス（複数可）１０７に配信するのに必要なだけのＳＭＳメッセージパケットが送信されるので、任意選択でメッセージの切り捨てを行うこともできる。次いで、ＳＭＳＣ １０９が、メッセージ２０９を受信者デバイス１０７に転送し、次いで、受信者デバイスが、確認応答メッセージ２１０を送り返す。図示されている例において、サーバは、電子メールを介して送信されたメッセージ２１１、２１２（破線の輪郭で示されている）の確認を、或いは電子メールサーバ及び／又はＳＭＳＣ／ＳＭＳゲートウェイを介したＳＭＳの確認を求めないが、その理由は、これらのフォーマットが両方とも、許容できる信頼性を有するとみなされるからである。しかし、当業者であれば、そのような検証手順をシステムに容易に組み込めることを理解するであろう。
【００４３】
上述のように、配信サーバ１０５から受信者デバイス１０７へのメッセージの経路指定は、配信サーバ１０５上に実装された一組の所定のルールを介して行うことができる。このルールセットは、再試行回数、使用される代替配信チャネル及びその順序、再試行が続けられる時間、再試行の頻度を決定する。以下の表は、本発明の一実施形態によるテキスト型メッセージングシステムでメッセージの経路指定を行うために適用されるルールセットの一例を示している。
【表１】
【００４４】
メッセージが画像又は他のファイルを含む本発明の他の実施形態では、代替配信チャネルは、ＭＭＳ又は他の何らかのファイル転送プロトコルとして構成することができる。
【００４５】
ユーザは、例えば、オンラインインターフェース又は同様のものを介してそのプリファレンスに合わせてルールセットを構成することができる。次いで、ルールステータスの変更が、特定のユーザに対するルールセットのオペレーションを修正する配信サーバに伝達される。この例では、ユーザは、そのステータス設定、そのオフライン設定、及びその現在のネットワークプレゼンスに基づいてメッセージの経路指定をどのように行うかを定義することができる。上述のように、ハートビートトランザクションが、ユーザのプレゼンスを配信サーバに通知する。しかし、ユーザがメッセージを受信できるかどうかは、ユーザ定義ステータス設定、その「オフライン設定」、及びユーザが接続（ログイン）されているかどうかの組み合わせに基づいて判定される。
・ ＳＭＳ経路指定。オフラインの場合、クライアントデバイスステータスがオフラインに設定されたときにＳＭＳを介してメッセージを経路指定するようサーバに通知する。
・ 電子メール経路指定。ユーザがクライアントデバイスにログオンしていない場合に電子メールを送信するようメッセージの経路指定を行う。
・ ウェイクアップ。システムがＳＳ７又はＳＭＳ０を使用して受信デバイス上のクライアントアプリケーションを目覚めさせ、次いでメッセージをユーザに送るようにする。
・ サーバに保存。ユーザがそのクライアントデバイスに再度ログインするまでサーバ上にメッセージを保存するようサーバに通知する。
【００４６】
したがって、利用可能性が、システムのルールセットの適用をユーザ側で修正することを可能にするユーザ定義属性となる。表１に示されているように、ユーザがオンラインであるかオフラインであるかに応じてユーザが選択できるシステム内のステータスが多数ある。４種類の主要なステータスは、「利用可能」、「利用不可能」、「妨害しない」、及び「不可視」である。ネットワークにおいて、ユーザによって選択されたオフライン設定により、代替配信チャネルを介してメッセージの配信をタイミングよく行える場合、ユーザによって選択されたステータスは、オフラインのときに保持される。ネットワーク内ユーザが、電子メール又は「サーバ上に保存」などの適時な配信を許可しないオフライン設定を選択した場合、その利用可能性は、オフラインのときに「通信できない」と示される。クライアントデバイスの「ネットワーク外」のユーザについては、制限されたオフライン設定が利用可能である、つまり、「サーバ上に保存」及び「電子メール」である。したがって、オフラインのネットワーク外のユーザは、「通信できない」と常にみなされる。
【００４７】
上記に加えて、このシステムでは、ユーザがメッセージにさまざまな特性、例えば、メッセージ重要度を割り当てることができるようにすることも可能である。メッセージ重要度は、送信者側で「通常」又は「高」に設定することができる。メッセージ重要度は、メッセージヘッダ内にデータとして保持され、メッセージ処理を決定するためにネットワーク全体にわたって使用される。
【００４８】
ユーザが、高重要度を選択した場合、ネットワーク、サーバインフラストラクチャ、及び受信デバイスを介したメッセージ配信ルールでは、メッセージの処理方法が異なる。典型的には、高重要度メッセージは、通信事業者から割増料金を課金される。
【００４９】
高重要度メッセージの場合、このルールセットの下での通常処理に対し以下の変更が行われる。
・ 送信デバイスからサーバへの再試行が、１分おきに、最大３回まで行われる。メッセージの送信に失敗した場合、送信者は、送信デバイス上で警告を受け、続けるか、又は代替配信チャネルに切り換えるかの選択肢を与えられる。
・ サーバから受信デバイスへの再試行が、１分おきに、最大３回まで行われ、その後、代替チャネルに切り換える。
・ 高重要度メッセージは、決して、電子メールにしか経路指定されないわけではない。受信者が、そのオフライン設定で電子メールを指定している場合、メッセージは、電子メールにコピーされるが、ＳＭＳへも経路指定される。
・ 受信デバイス上で、高重要度メッセージに対し、特別警告音が鳴る。
・ 受信デバイス上で、受信の確認応答を求める要求がユーザに対し示され、確認応答が、メッセージとして元の送信者に（日時の確認とともに）送り返される。
・ メッセージは、データベース１１０（後述）上で高重要度であるというタグを付けられる。
【００５０】
上で簡単に述べたように、データベース１１０は、リモートストレージファシリティとして使用することができる。この「ＳｔｏｒｅｌＴ」機能は、配信サーバ１０５との間でやり取りされるすべてのメッセージのフルメッセージアーカイブファシリティを実現するものである。メッセージへのアクセスは、ウェブサイトを介して行う。ユーザは、ログインしてから、広範な検索ファシリティ及びタグ付け機能を利用してメッセージにアクセスすることができる。ユーザがメッセージを削除しなくて済むように、十分な容量のストレージが確保されている。
【００５１】
配信サーバは、非同期プロセスで送受信されたそれぞれのメッセージをデータストレージファシリティ１１０に書き込む。メッセージは、典型的には、送信者／受信者毎に別々に書き込まれる。ストレージの必要な容量は、メッセージの単一コピーを書き込み、そのメッセージを複数の送信者／受信者に関連付けるリンクを使用することによって減らすことができる。このアプローチでは検索速度の低下のトレードオフが認められる。
【００５２】
例えば、メッセージが以下のいくつかの特性を含む場合、メッセージのタグ付けを、自動的に実行させることができる。
・ ウェブサイトへのリンクを含む
・ 電話番号であることを示唆する基準を満たす数値を含む
・ 住所を含む（「通り」、「アパート」、「ｓｔ．」、「ａｐｔ」などのキーワードのデータベースに基づく）
【００５３】
「ＳｔｏｒｅＩＴ」ユーザインターフェースは、ＰＣバージョンのメッセージングクライアントを介してメッセージの転送及び返信を行う機能も備える。ウェブインターフェースとしては、以下のものが挙げられる。
・ ユーザモバイルメッセージングアプリケーションと同じユーザＩＤ及びパスワードを使用してログインできる能力。
・ 送受信されたすべてのメッセージへのアクセス。
・ 送信日時、受信者／送信者情報を含むメッセージメタデータ。
・ メッセージのタグ付け（ユーザ選択可能なタグ、並びに自動化されたタグ、例えば、ウェブサイトへのリンク又は番号を含むメッセージにタグ付けする）。
・ メッセージングオプション（メッセージに返信する、新規メッセージを送信するなど）。
・ 友達リストへのアクセス。
・ メッセージアーカイブ管理（選択された受信者又はすべての受信者について一部のメッセージ又は全部のメッセージを削除する）。
・ ユーザ設定（ＳｔｏｒｅＩＴをオフにする、特定の受信者についてオフにする、特定の受信者についてオンにするなど）。
【００５４】
上記の実施形態は、本発明を例示するために提示したものにすぎず、またそれに対するさらなる修正及び改善は、当業者には明らかなように、本明細書に記載されている本発明の広い範囲及び分野内に収まるとみなされることは理解されるであろう。特に、以下の追加及び／又は修正（網羅していない）は、本発明の範囲から逸脱することなく行うことができる。
・ 再試行の管理は、配信サーバ１０５の代わりに発信デバイス１０１が実行することができる。
・ 受信の確認応答は、配信サーバ１０５をバイパスすることができる。このアプローチでは、発信デバイス１０１は、受信者デバイス１０７への配信を保証するように構成される。
・ 発信デバイス１０１は、メッセージの配信ステータスに関する情報を与えるインジケータをユーザに対して表示するように構成することができる。
・ 発信デバイス１０１は、第１の配信チャネルを介してメッセージの配信を実行できない場合に代替配信チャネルを選択するように構成することができる。
・ 代替配信が、メッセージの配信に使用される場合、発信デバイス又は少なくとも１つのサーバのいずれかが、代替配信チャネルのメッセージング標準に適合するようにメッセージを再フォーマットすることができる。
・ 確認応答メッセージが発信デバイスに返されない場合、実施形態において説明されているようなビジネスルール及びユーザ設定に加えて、配信サーバ１０５にメッセージを送信するように一次配信チャネルをさらに構成することができ、また配信サーバ１０５は二次配信チャネルに切り換えるようサーバに指令する命令をメッセージヘッダ内に入れる。
・ メッセージの配信ステータスを示すインジケータをユーザに対して表示することができる。例えば、メッセージ再試行が発信デバイスによって制御される場合、送信アプリケーションを終了しようとしているユーザに対し、メッセージが配信中であるとまだ確認されていないこと、及び再試行がまだ未解決であることを示す警告が出される。
【特許請求の範囲】
【請求項１】
第１の配信チャネルを介して少なくとも１つの受信者デバイスに配信するために発信デバイスからメッセージを受信するように構成された少なくとも１つのサーバを備え、
前記少なくとも１つのサーバが、前記第１の配信チャネルを介して前記メッセージの配信を実行できない場合に代替配信チャネルを選択するようにさらに構成されるメッセージシステム。
【請求項２】
前記第１の配信チャネルが、インターネットプロトコルチャネルであり、前記メッセージが、インスタントメッセージである請求項１に記載のメッセージングシステム。
【請求項３】
前記第１の配信チャネルが、ＳＭＴＰチャネル、ＭＩＭＥチャネル、ＰＯＰチャネル、ＩＭＡＰチャネルのうちの少なくとも１つから選択され、前記メッセージが、電子メールメッセージである請求項１に記載のメッセージングシステム。
【請求項４】
前記第１の配信チャネルが、ＳＳ７チャネルであり、前記メッセージが、ＳＭＳ又はＭＭＳである請求項１に記載のメッセージングシステム。
【請求項５】
前記サーバが、前記代替配信チャネルのメッセージング標準に適合するよう前記メッセージを再フォーマットするように構成される請求項１〜４のいずれか一項に記載のメッセージングシステム。
【請求項６】
前記少なくとも１つのサーバが、前記第１のメッセージングチャネルを介して前記メッセージを受信した後に前記少なくとも１つの受信者デバイスから確認応答メッセージを受信するように構成され、その際に、前記少なくとも１つのサーバが、前記少なくとも１つの受信者デバイスによる前記メッセージの前記受信を前記発信デバイスに通知する請求項１に記載のメッセージングシステム。
【請求項７】
前記発信デバイスが、前記確認応答メッセージの受信に失敗した後に前記代替配信チャネルを介して前記メッセージを即座に送信するよう前記サーバに命令することができる請求項６に記載のメッセージングシステム。
【請求項８】
前記確認応答メッセージが、シリアル番号、タイムスタンプ、又は前記確認応答メッセージを前記発信デバイスによって送信された前記メッセージに関連付ける一意的ＩＤを含む請求項６又は７に記載のメッセージングシステム。
【請求項９】
前記サーバが、前記少なくとも１つの受信者デバイスに前記メッセージをどのように送信するかを規律するための、１つ又は複数の定義済みルールセットをさらに備える請求項１〜８のいずれか一項に記載のメッセージングシステム。
【請求項１０】
前記定義済みルールセットが、前記第１の配信チャネルで前記メッセージを再送するまでに前記サーバが待っている期間及び代替配信チャネルに切り換えるまで前記サーバが前記第１の配信チャネルで前記メッセージの配信を再試行する最大回数に関係する情報を含む請求項９に記載のメッセージングシステム。
【請求項１１】
前記メッセージが、前記メッセージを前記少なくとも１つの受信者デバイスに前記サーバが配信しようとする毎にインクリメントされる再試行カウンターを含む請求項１０に記載のメッセージングシステム。
【請求項１２】
前記少なくとも１つのサーバが、メッセージを配信しようとするそれぞれの試みのログを、ネットワーク固有の情報とともにデータベースに定期的に書き込むように構成することができる請求項１１に記載のメッセージングシステム。
【請求項１３】
前記少なくとも１つのサーバを通過するすべてのメッセージのコピーが、後からユーザが取り出せるように前記データベースに格納される請求項１２に記載のメッセージングシステム。
【請求項１４】
前記受信者デバイス上の重複メッセージが、一意的識別子に基づきユーザに対し表示されない請求項１〜１３のいずれか一項に記載のメッセージングシステム。
【請求項１５】
メッセージの経路指定を行うための方法であって、
１つのサーバにおいて、少なくとも１つの受信者デバイスに配信するために発信デバイスからメッセージを受信するステップと、
第１の配信チャネルを介して前記少なくとも１つの受信者デバイスに前記メッセージを転送するステップと、
前記少なくとも１つの受信者デバイスから確認応答メッセージを受信するのを待つステップとを含み、確認応答メッセージが受信されない場合に、前記少なくとも１つのサーバが、代替配信チャネルを介して前記少なくとも１つの受信者デバイスに前記メッセージを再送する方法。
【請求項１６】
前記第１の配信チャネルが、インターネットプロトコル（ＩＰ）チャネルであり、前記メッセージが、インスタントメッセージである請求項１５に記載の方法。
【請求項１７】
前記第１の配信チャネルが、ＳＭＴＰチャネル、ＭＩＭＥチャネル、ＰＯＰチャネル、ＩＭＡＰチャネルのうちの少なくとも１つから選択され、前記メッセージが、電子メールメッセージである請求項１５に記載の方法。
【請求項１８】
前記第１の配信チャネルが、ＳＳ７チャネルであり、前記メッセージが、ＳＭＳ又はＭＭＳである請求項１５に記載の方法。
【請求項１９】
前記サーバが、前記代替配信チャネルのメッセージング標準に適合するよう前記メッセージを再フォーマットするように構成される請求項１５〜１８のいずれか一項に記載の方法。
【請求項２０】
前記代替配信チャネルを介して前記メッセージの送信を試みる前に所定の回数だけ前記第１の配信チャネルを介して前記メッセージを再送するステップをさらに含む請求項１５〜１９のいずれか一項に記載の方法。
【請求項２１】
前記第１の配信チャネルを介して前記メッセージを再送するステップが、前記メッセージに関連する再試行カウンターをインクリメントするステップを含む請求項２０に記載の方法。
【請求項２２】
前記受信者デバイス上の重複メッセージが、一意的識別子に基づきユーザに対し表示されない請求項１５〜２２のいずれか一項に記載の方法。
【請求項２３】
前記サーバが、すべてのメッセージのコピーを後からユーザが取り出せるように格納する請求項１５〜２２のいずれか一項に記載の方法。
【請求項２４】
前記サーバが、後から前記ユーザが検索できるようにシステム定義コンテンツルールだけでなくユーザ定義ルールにも基づいてメッセージに自動的にタグ付けする請求項１５〜２３のいずれか一項に記載の方法。
【請求項２５】
メッセージの経路指定を行うための方法であって、
１つのサーバにおいて、少なくとも１つの受信者デバイスに配信するために発信デバイスからメッセージを受信するステップと、
一次配信チャネルを介して前記少なくとも１つの受信者デバイスに前記メッセージを転送するステップと、
前記少なくとも１つの受信者デバイスから確認応答メッセージを受信するのを待ち、前記確認応答を前記発信デバイスに転送して戻すステップとを含み、確認応答メッセージが前記発信デバイスによって受信されない場合に、前記発信デバイスが、前記メッセージを前記サーバに再送して、代替配信チャネルを使用して前記メッセージを前記受信者デバイスへ経路指定するよう指示する方法。
【請求項２６】
前記第１の配信チャネルが、インターネットプロトコル（ＩＰ）チャネルであり、前記メッセージが、インスタントメッセージである請求項２５に記載の方法。
【請求項２７】
前記第１の配信チャネルが、ＳＭＴＰチャネル、ＭＩＭＥチャネル、ＰＯＰチャネル、ＩＭＡＰチャネルのうちの少なくとも１つから選択され、前記メッセージが、電子メールメッセージである請求項２５に記載の方法。
【請求項２８】
前記第１の配信チャネルが、ＳＳ７チャネルであり、前記メッセージが、ＳＭＳ又はＭＭＳである請求項２５に記載の方法。
【請求項２９】
前記サーバが、前記代替配信チャネルのメッセージング標準に適合するよう前記メッセージを再フォーマットするように構成される請求項２５〜２８のいずれか一項に記載の方法。
【請求項３０】
前記代替配信チャネルを介して前記メッセージの送信を試みる前に所定の回数だけ前記第１の配信チャネルを介して前記メッセージを再送するステップをさらに含む請求項２５〜２９のいずれか一項に記載の方法。
【請求項３１】
前記第１の配信チャネルを介して前記メッセージを再送するステップが、前記メッセージに関連する再試行カウンターをインクリメントするステップを含む請求項３０に記載の方法。
【請求項３２】
前記受信者デバイス上の重複メッセージが、一意的識別子に基づきユーザに対し表示されない請求項２５〜３２のいずれか一項に記載の方法。
【請求項３３】
前記サーバが、すべてのメッセージのコピーを後からユーザが取り出せるように格納する請求項２５〜３２のいずれか一項に記載の方法。
【請求項３４】
前記サーバが、後から前記ユーザが検索できるようにシステム定義コンテンツルールだけでなくユーザ定義ルールにも基づいてメッセージに自動的にタグ付けする請求項２５〜３３のいずれか一項に記載の方法。
【請求項３５】
前記発信デバイスが、メッセージの配信ステータスに関するインジケータを前記ユーザに表示する請求項２５〜３４のいずれか一項に記載の方法。
【請求項３６】
前記発信デバイスが、シャットダウン又はログアウトのオペレーションを実行する前にメッセージが配信されていないという警告をユーザに発する請求項２５〜３５のいずれか一項に記載の方法。
【請求項１】
第１の配信チャネルを介して少なくとも１つの受信者デバイスに配信するために発信デバイスからメッセージを受信するように構成された少なくとも１つのサーバを備え、
前記少なくとも１つのサーバが、前記第１の配信チャネルを介して前記メッセージの配信を実行できない場合に代替配信チャネルを選択するようにさらに構成されるメッセージシステム。
【請求項２】
前記第１の配信チャネルが、インターネットプロトコルチャネルであり、前記メッセージが、インスタントメッセージである請求項１に記載のメッセージングシステム。
【請求項３】
前記第１の配信チャネルが、ＳＭＴＰチャネル、ＭＩＭＥチャネル、ＰＯＰチャネル、ＩＭＡＰチャネルのうちの少なくとも１つから選択され、前記メッセージが、電子メールメッセージである請求項１に記載のメッセージングシステム。
【請求項４】
前記第１の配信チャネルが、ＳＳ７チャネルであり、前記メッセージが、ＳＭＳ又はＭＭＳである請求項１に記載のメッセージングシステム。
【請求項５】
前記サーバが、前記代替配信チャネルのメッセージング標準に適合するよう前記メッセージを再フォーマットするように構成される請求項１〜４のいずれか一項に記載のメッセージングシステム。
【請求項６】
前記少なくとも１つのサーバが、前記第１のメッセージングチャネルを介して前記メッセージを受信した後に前記少なくとも１つの受信者デバイスから確認応答メッセージを受信するように構成され、その際に、前記少なくとも１つのサーバが、前記少なくとも１つの受信者デバイスによる前記メッセージの前記受信を前記発信デバイスに通知する請求項１に記載のメッセージングシステム。
【請求項７】
前記発信デバイスが、前記確認応答メッセージの受信に失敗した後に前記代替配信チャネルを介して前記メッセージを即座に送信するよう前記サーバに命令することができる請求項６に記載のメッセージングシステム。
【請求項８】
前記確認応答メッセージが、シリアル番号、タイムスタンプ、又は前記確認応答メッセージを前記発信デバイスによって送信された前記メッセージに関連付ける一意的ＩＤを含む請求項６又は７に記載のメッセージングシステム。
【請求項９】
前記サーバが、前記少なくとも１つの受信者デバイスに前記メッセージをどのように送信するかを規律するための、１つ又は複数の定義済みルールセットをさらに備える請求項１〜８のいずれか一項に記載のメッセージングシステム。
【請求項１０】
前記定義済みルールセットが、前記第１の配信チャネルで前記メッセージを再送するまでに前記サーバが待っている期間及び代替配信チャネルに切り換えるまで前記サーバが前記第１の配信チャネルで前記メッセージの配信を再試行する最大回数に関係する情報を含む請求項９に記載のメッセージングシステム。
【請求項１１】
前記メッセージが、前記メッセージを前記少なくとも１つの受信者デバイスに前記サーバが配信しようとする毎にインクリメントされる再試行カウンターを含む請求項１０に記載のメッセージングシステム。
【請求項１２】
前記少なくとも１つのサーバが、メッセージを配信しようとするそれぞれの試みのログを、ネットワーク固有の情報とともにデータベースに定期的に書き込むように構成することができる請求項１１に記載のメッセージングシステム。
【請求項１３】
前記少なくとも１つのサーバを通過するすべてのメッセージのコピーが、後からユーザが取り出せるように前記データベースに格納される請求項１２に記載のメッセージングシステム。
【請求項１４】
前記受信者デバイス上の重複メッセージが、一意的識別子に基づきユーザに対し表示されない請求項１〜１３のいずれか一項に記載のメッセージングシステム。
【請求項１５】
メッセージの経路指定を行うための方法であって、
１つのサーバにおいて、少なくとも１つの受信者デバイスに配信するために発信デバイスからメッセージを受信するステップと、
第１の配信チャネルを介して前記少なくとも１つの受信者デバイスに前記メッセージを転送するステップと、
前記少なくとも１つの受信者デバイスから確認応答メッセージを受信するのを待つステップとを含み、確認応答メッセージが受信されない場合に、前記少なくとも１つのサーバが、代替配信チャネルを介して前記少なくとも１つの受信者デバイスに前記メッセージを再送する方法。
【請求項１６】
前記第１の配信チャネルが、インターネットプロトコル（ＩＰ）チャネルであり、前記メッセージが、インスタントメッセージである請求項１５に記載の方法。
【請求項１７】
前記第１の配信チャネルが、ＳＭＴＰチャネル、ＭＩＭＥチャネル、ＰＯＰチャネル、ＩＭＡＰチャネルのうちの少なくとも１つから選択され、前記メッセージが、電子メールメッセージである請求項１５に記載の方法。
【請求項１８】
前記第１の配信チャネルが、ＳＳ７チャネルであり、前記メッセージが、ＳＭＳ又はＭＭＳである請求項１５に記載の方法。
【請求項１９】
前記サーバが、前記代替配信チャネルのメッセージング標準に適合するよう前記メッセージを再フォーマットするように構成される請求項１５〜１８のいずれか一項に記載の方法。
【請求項２０】
前記代替配信チャネルを介して前記メッセージの送信を試みる前に所定の回数だけ前記第１の配信チャネルを介して前記メッセージを再送するステップをさらに含む請求項１５〜１９のいずれか一項に記載の方法。
【請求項２１】
前記第１の配信チャネルを介して前記メッセージを再送するステップが、前記メッセージに関連する再試行カウンターをインクリメントするステップを含む請求項２０に記載の方法。
【請求項２２】
前記受信者デバイス上の重複メッセージが、一意的識別子に基づきユーザに対し表示されない請求項１５〜２２のいずれか一項に記載の方法。
【請求項２３】
前記サーバが、すべてのメッセージのコピーを後からユーザが取り出せるように格納する請求項１５〜２２のいずれか一項に記載の方法。
【請求項２４】
前記サーバが、後から前記ユーザが検索できるようにシステム定義コンテンツルールだけでなくユーザ定義ルールにも基づいてメッセージに自動的にタグ付けする請求項１５〜２３のいずれか一項に記載の方法。
【請求項２５】
メッセージの経路指定を行うための方法であって、
１つのサーバにおいて、少なくとも１つの受信者デバイスに配信するために発信デバイスからメッセージを受信するステップと、
一次配信チャネルを介して前記少なくとも１つの受信者デバイスに前記メッセージを転送するステップと、
前記少なくとも１つの受信者デバイスから確認応答メッセージを受信するのを待ち、前記確認応答を前記発信デバイスに転送して戻すステップとを含み、確認応答メッセージが前記発信デバイスによって受信されない場合に、前記発信デバイスが、前記メッセージを前記サーバに再送して、代替配信チャネルを使用して前記メッセージを前記受信者デバイスへ経路指定するよう指示する方法。
【請求項２６】
前記第１の配信チャネルが、インターネットプロトコル（ＩＰ）チャネルであり、前記メッセージが、インスタントメッセージである請求項２５に記載の方法。
【請求項２７】
前記第１の配信チャネルが、ＳＭＴＰチャネル、ＭＩＭＥチャネル、ＰＯＰチャネル、ＩＭＡＰチャネルのうちの少なくとも１つから選択され、前記メッセージが、電子メールメッセージである請求項２５に記載の方法。
【請求項２８】
前記第１の配信チャネルが、ＳＳ７チャネルであり、前記メッセージが、ＳＭＳ又はＭＭＳである請求項２５に記載の方法。
【請求項２９】
前記サーバが、前記代替配信チャネルのメッセージング標準に適合するよう前記メッセージを再フォーマットするように構成される請求項２５〜２８のいずれか一項に記載の方法。
【請求項３０】
前記代替配信チャネルを介して前記メッセージの送信を試みる前に所定の回数だけ前記第１の配信チャネルを介して前記メッセージを再送するステップをさらに含む請求項２５〜２９のいずれか一項に記載の方法。
【請求項３１】
前記第１の配信チャネルを介して前記メッセージを再送するステップが、前記メッセージに関連する再試行カウンターをインクリメントするステップを含む請求項３０に記載の方法。
【請求項３２】
前記受信者デバイス上の重複メッセージが、一意的識別子に基づきユーザに対し表示されない請求項２５〜３２のいずれか一項に記載の方法。
【請求項３３】
前記サーバが、すべてのメッセージのコピーを後からユーザが取り出せるように格納する請求項２５〜３２のいずれか一項に記載の方法。
【請求項３４】
前記サーバが、後から前記ユーザが検索できるようにシステム定義コンテンツルールだけでなくユーザ定義ルールにも基づいてメッセージに自動的にタグ付けする請求項２５〜３３のいずれか一項に記載の方法。
【請求項３５】
前記発信デバイスが、メッセージの配信ステータスに関するインジケータを前記ユーザに表示する請求項２５〜３４のいずれか一項に記載の方法。
【請求項３６】
前記発信デバイスが、シャットダウン又はログアウトのオペレーションを実行する前にメッセージが配信されていないという警告をユーザに発する請求項２５〜３５のいずれか一項に記載の方法。
【図１】
【図２】
【図２】
【公表番号】特表２０１１−５２７４６７（Ｐ２０１１−５２７４６７Ａ）
【公表日】平成２３年１０月２７日（２０１１．１０．２７）
【国際特許分類】
【出願番号】特願２０１１−５１６２２９（Ｐ２０１１−５１６２２９）
【出願日】平成２１年６月３０日（２００９．６．３０）
【国際出願番号】ＰＣＴ／ＳＧ２００９／０００２３８
【国際公開番号】ＷＯ２０１０／００２３５４
【国際公開日】平成２２年１月７日（２０１０．１．７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５１０１４８１７５）サード ブランド プライベート リミテッド (4)
【Ｆターム（参考）】
【公表日】平成２３年１０月２７日（２０１１．１０．２７）
【国際特許分類】
【出願日】平成２１年６月３０日（２００９．６．３０）
【国際出願番号】ＰＣＴ／ＳＧ２００９／０００２３８
【国際公開番号】ＷＯ２０１０／００２３５４
【国際公開日】平成２２年１月７日（２０１０．１．７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＧＳＭ
【出願人】（５１０１４８１７５）サード ブランド プライベート リミテッド (4)
【Ｆターム（参考）】
[ Back to top ]