(57)【要約】  トランスポートプルモードメッセージングサービスは、メッセージの配信を保証しつつ、異なったタイプのクライアントが互いにメッセージを送受信できるようにする。クライアントに特有のアダプタは、サーバに接続し、キューでそれらを待っているメッセージを取り出す。クライアントは、取り出されたメッセージの受信者として自分自身を指定することもできるし、あるいは、別のクライアントを受信者として指定することもできる。これによって、異なったタイプのクライアントのユーザは通信を行うことを可能になり、また、どのように、いつ、どこで自分へのメッセージを見るかに関して、多大なフレキシビリティが提供される。
2007526674.tif 000002
【特許請求の範囲】
【請求項１】
トランスポートにとらわれないプルモードメッセージングのためのシステムであって、
第１のメッセージを第１の通信プロトコルを使って第１のアダプタに送信し、前記第１のメッセージが受信されたことを表す応答を、前記第１の通信プロトコルを使って前記第１のアダプタから受信し、所定の時間内に前記アダプタからの前記応答が受信されない場合には、前記第１のメッセージを前記第１の通信プロトコルを使って前記第１のアダプタに再送信する第１のクライアントと、
前記第１のメッセージを受信し、前記第１のメッセージが受信されたことを表す応答を、前記第１のプロトコルを使って前記第１のクライアントに送信し、前記第１のメッセージに基づいて第２のメッセージを生成し、前記第２のメッセージを第２の通信プロトコルを使ってサーバに送信する第１のアダプタと、
前記第２のメッセージに基づいて少なくとも１つの命令を実行するサーバエンジンと、
データを前記第２のメッセージに関連付けて記憶するメッセージストレージとを備えることを特徴とするシステム。
【請求項２】
第３のメッセージを第３の通信プロトコルを使って第２のアダプタから受信する第２のクライアントと、
第４のメッセージを前記プロトコルを使って前記サーバエンジンから受信し、前記第４のメッセージに基づいて第３のメッセージを生成し、前記第３のメッセージを第３の通信プロトコルを使って第２のクライアントに送信する第２のアダプタとをさらに備えることを特徴とする請求項１に記載のシステム。
【請求項３】
前記少なくとも１つの命令は、前記第２のメッセージに関連付けたデータを記憶装置に記憶するための命令を含むことを特徴とする請求項１に記載のシステム。
【請求項４】
前記サーバエンジンと前記アダプタの一方は、前記第２のメッセージがすでに記憶されている重複メッセージかどうかを判断し、そうである場合には、前記第２のメッセージを拒否し、そうでない場合には、前記メッセージに関連付けられたエンドポイントを判断して、前記メッセージを前記エンドポイントに対応するキューに記憶することを特徴とする請求項３に記載のシステム。
【請求項５】
前記記憶装置は、エンドポイントに関連付けられたキューを含むことを特徴とする請求項３に記載のシステム。
【請求項６】
前記エンドポイントは前記第１のクライアントに関連付けられていることを特徴とする請求項５に記載のシステム。
【請求項７】
前記エンドポイントは、ユーザ、クライアント、および前記クライアントとは異なるアプリケーションの少なくとも１つに関連付けられていることを特徴とする請求項５に記載のシステム。
【請求項８】
前記少なくとも１つの命令は、記憶装置からさらなるメッセージを検索し、前記追加メッセージをエンドポイントに送信するための命令であることを特徴とする請求項１に記載のシステム。
【請求項９】
前記エンドポイントは前記第１のクライアントに関連付けられている
ことを特徴とする請求項８に記載のシステム。
【請求項１０】
前記エンドポイントは、ユーザ、クライアント、および前記クライアントとは異なるアプリケーションの少なくとも１つに関連付けられていることを特徴とする請求項８に記載のシステム。
【請求項１１】
前記第１のクライアントは、前記第１のメッセージを送信するのに先立って前記第１のメッセージを生成し、前記第１のメッセージは一意のメッセージ識別子を含むことを特徴とする請求項１に記載のシステム。
【請求項１２】
前記第１のアダプタまたは前記サーバエンジンは、前記受信された第１のメッセージがすでに受信されたメッセージの重複物であるかどうかを判断することを特徴とする請求項１に記載のシステム。
【請求項１３】
前記第１のクライアントデバイスは、前記第１のメッセージに対応する、第１のクライアントデバイスに特有の識別子を生成し、前記第１のクライアントに特有の識別子を記憶し、前記第１のクライアントに特有の識別子を前記第１のメッセージとともに前記第１のアダプタに送信することを特徴とする請求項１に記載のシステム。
【請求項１４】
前記応答は第１のクライアントに特有の識別子を含み、前記第１のクライアントは、受信された前記第１のクライアント特有の識別子が、記憶されている第１のクライアントに特有の識別子に対応していることを検証することを特徴とする請求項１に記載のシステム。
【請求項１５】
前記第１の通信プロトコルは、前記第２の通信プロトコルとは異なる
ことを特徴とする請求項１に記載のシステム。
【請求項１６】
前記第２の通信プロトコルは、前記第３の通信プロトコルとは異なる
ことを特徴とする請求項２に記載のシステム。
【請求項１７】
前記第３の通信プロトコルは、前記第１の通信プロトコルとは異なる
ことを特徴とする請求項２に記載のシステム。
【請求項１８】
トランスポートにとらわれないプルモードメッセージングのための方法であって、
第１のメッセージを、第１の通信プロトコルを使って、クライアントから対応するアダプタに送信するステップと、
前記第１のメッセージを前記アダプタで受信するステップと、
前記第１のメッセージが受信されたことを表す応答を、前記第１の通信プロトコルを使って、前記アダプタから前記クライアントに送信するステップと、
前記応答を前記クライアントで受信するステップと、
所定の時間内に、前記クライアントで、前記アダプタからの前記応答が受信されない場合には、前記第１のメッセージを前記クライアントから前記アダプタに再送信するステップと、
前記アダプタで、前記第１のメッセージに基づいて第２のメッセージを生成するステップと、
前記第２のメッセージを、第２の通信プロトコルを使って、前記アダプタから前記サーバエンジンに送信するステップと、
前記サーバエンジンで、前記第２のメッセージに基づいて少なくとも１つの命令を実行するステップとを備えることを特徴とする方法。
【請求項１９】
前記第１の通信プロトコルは、前記第２の通信プロトコルとは異なる
ことを特徴とする請求項１８に記載の方法。
【請求項２０】
前記少なくとも１つの命令を実行するステップは、前記第２のメッセージに関連付けたデータを記憶装置に記憶するステップを含むことを特徴とする請求項１８に記載の方法。
【請求項２１】
前記データを前記記憶装置に記憶するステップは、
前記第２のメッセージがすでに記憶されている重複メッセージかどうかを判断するステップと、
重複物である場合には前記第２のメッセージを拒否するステップと、
前記メッセージに関連付けられたエンドポイントを判断するステップと、
前記メッセージを前記エンドポイントに対応するキューに記憶するステップとを含むことを特徴とする請求項２０に記載の方法。
【請求項２２】
前記記憶装置は、エンドポイントに関連付けられたキューを含むことを特徴とする請求項２０に記載の方法。
【請求項２３】
前記エンドポイントは前記クライアントに関連付けられていることを特徴とする請求項２２に記載の方法。
【請求項２４】
前記エンドポイントは、ユーザ、クライアント、および前記クライアントとは異なるアプリケーションの少なくとも１つに関連付けられていることを特徴とする請求項２２に記載の方法。
【請求項２５】
前記少なくとも１つの命令を実行するステップは、記憶装置からさらなるメッセージを検索するステップと、前記追加メッセージをエンドポイントに送信するステップとを含むことを特徴とする請求項１８に記載の方法。
【請求項２６】
前記エンドポイントは前記クライアントに関連付けられていることを特徴とする請求項２５に記載の方法。
【請求項２７】
前記エンドポイントは、ユーザ、クライアント、および前記クライアントとは異なるアプリケーションの少なくとも１つに関連付けられていることを特徴とする請求項２５に記載の方法。
【請求項２８】
前記第１のメッセージを送信するのに先立って前記第１のメッセージを生成するステップであって、前記第１のメッセージが一意のメッセージ識別子を含むステップをさらに備えることを特徴とする請求項１８に記載の方法。
【請求項２９】
前記アダプタまたは前記サーバエンジンで、前記受信された第１のメッセージがすでに受信したメッセージの重複物であるかどうかを判断するステップをさらに備えることを特徴とする請求項１８に記載の方法。
【請求項３０】
前記第１のメッセージを、前記クライアントから前記アダプタに送信するステップは、
前記第１のメッセージに対応するクライアントに特有の一意の識別子を生成するステップと、
前記クライアントに特有の識別子を記憶するステップと、
前記クライアントに特有の識別子を前記第１のメッセージとともに前記アダプタに送信するステップとを含むことを特徴とする請求項１８に記載の方法。
【請求項３１】
前記応答はクライアントに特有の識別子を含み、前記方法は、受信した前記クライアント特有の識別子が、記憶されているクライアントに特有の識別子に対応していることを検証するステップをさらに備えることを特徴とする請求項１８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、メッセージ配信システムの分野に関する。より詳細には、本発明は、メッセージの送受信におけるメッセージの信頼性に関する。
【０００２】
本出願は、参照によりその開示全体が本明細書に組み込まれている、２００３年１２月３１日に出願した米国特許出願第１０／７５０，１９１号明細書の優先権を主張するものである。
【背景技術】
【０００３】
技術の進歩に伴って、ユーザに提供されるメッセージ送受信可能なデバイスはますます多様化しつつある。標準的な会社員が、電話ボイスメールシステム、パーソナルディジタルアシスタント（ＰＤＡ）、スモールメッセージサービス（ＳＭＳ）を使った携帯電話、パーソナル電子メールアカウントを含む、複数のデバイスを使ってメッセージを送受信することは珍しいことではない。複数のソースおよびデバイスからメッセージを送受信する能力は、会社員にとってフレキシビリティをもたらすものではあるが、一方で、それに付随する問題も生じる。例えば、今や、会社員は、いくつかの異なるデバイスをチェックしなければならず、それによって、時間、費用、ストレスが増える。また、このような会社員にメッセージを送信したいと思うユーザは、会社員がメッセージをタイミング良く受け取る可能性を高めるために、会社員がその時点でどのデバイスを使っているかを推測しなければならない。
【０００４】
さらに、メッセージの送信者が、そのメッセージを受信者が受け取ったかどうかを知る確実な方法がないことが多く、これは、同じメッセージの複数のコピーが送受信されることにつながる可能性がある。きわめて重要な用途においては、重複メッセージが問題になる場合がある。例えば、あるユーザが電子メールで株式を１００株売却する注文を出すとする。メールが配信されたかどうか不確かな場合、このユーザはそれを再度送信する場合がある。受信者にとっては、ユーザが２回、株式を１００株づつ売却したいのか、あるいは注文を含む２回目のメッセージが重複したものなのかを知る確実な方法はない。
【０００５】
このような問題に対処するこれまでの解決策は、柔軟性に乏しく、また特定の技術に限定されることが多かった。例えば、携帯電話で受信するために電子メールをＳＭＳに変換するプログラムが存在する。しかし、このような解決策は、メッセージの受信者がそのメッセージをどこで受け取るかの選択を行えるようにできないことが多く、代わりに、送信者がメッセージをどこに送るかを指定することに頼っている。さらに、このような解決策は、メッセージが受信されたことを送信者に保証するものではなく、また、メッセージが送信されても、それが受信者に知らせるものでもない。さらに、受信者がメッセージ受信のために使用しているそのような技術を、メッセージの送信者が知っている必要がある。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記を考えると、メッセージが配信され、二重メッセージが削除されることを確実に保証するメッセージングシステムに対する必要性がある。さらに、メッセージを受信するのに使用されるデバイスの心配をすることなく、他のユーザにメッセージを送受信でき、さらには、その後、自分自身へのメッセージをいつ、どのデバイスで受け取ることができるかを選択できる能力をユーザに提供する必要がある。
【課題を解決するための手段】
【０００７】
本発明は、メッセージの配信を保証する、トランスポートにとらわれないプルモードメッセージングのためのメカニズムを提供する。
【０００８】
一実施形態によれば、あるクライアントのユーザが、特定のエンドポイントにメッセージを送りたいと考える。エンドポイントは、アプリケーション、別のユーザ、または別のクライアントであってよい。このユーザのクライアントは、そのメッセージに対して一意のメッセージ識別（番号など）を生成し、次いで、メッセージをその一意のメッセージ識別とともにサーバに送信する。サーバは、その一意のメッセージ識別付きのメッセージを受信したことをクライアントに応答することができる。クライアントは、指定時間内にサーバから応答を受信しなかった場合には、メッセージと一意の識別を再送信する。サーバは、そのメッセージを受信した後、メッセージストア内の重複メッセージを探す。重複物が見つからない場合には、サーバは、そのメッセージをメッセージストアに保存する。
【０００９】
あるクライアントのユーザが、メッセージストア内で配信待機中の自分へのメッセージのいくつかまたはすべてのメッセージを受信したいと思う。ユーザは、自分が使用中のクライアント上で、または何か他のエンドポイントで、自分のメッセージを受け取りたいと思う。ユーザクライアントは、ユーザが受信したいメッセージおよび所望のエンドポイントを指定するメッセージを生成する。ユーザクライアントは、そのメッセージに対して一意のメッセージ識別を生成し、メッセージをその一意のメッセージ識別とともにサーバに送信する。サーバは、その一意のメッセージ識別付きのメッセージを受信したことをクライアントに応答することができる。クライアントは、指定時間内にサーバから応答を受信しなかった場合には、メッセージと一意の識別を再送信する。サーバは、指定されたメッセージを検索して、それらを指定されたエンドポイントに送信する。
【００１０】
本発明のさらなる特徴および利点は、添付の図面を参照しながら説明する、以下の例示的実施形態の詳細な説明を読むことにより明らかになるであろう。
【００１１】
上記の発明を解決するための手段、および以下の本発明を実施するための最良の形態は、添付の図面と関連して読むとよりよく理解される。本発明を説明する目的で、図面には本発明の例示的な構成を示してあるが、本発明は開示の特定の方法および手段に限定されるわけではない。
【発明を実施するための最良の形態】
【００１２】
概略
本発明は、保証されたメッセージ配信を提供しつつ、多様なタイプのシステムまたはデバイスのクライアントが互いにメッセージを送受信できるようにする、トランスポートにとらわれないプルモードメッセージングに向けられたものである。本明細書に記載の例示的なシステムおよび方法は、現在の技術およびシステムに見受けられる、異なるクライアントデバイス間の相互運用性およびメッセージ配信の信頼性についての問題を克服するものである。
【００１３】
電子メールアプリケーションや携帯電話などのクライアントデバイスは、サーバに接続して、キューでそれらを待っているメッセージを取り出す。クライアントは、それら自身を取り出されたメッセージの受信者として指定することもできるし、あるいは、別のクライアントを受信者として指定することもできる。クライアントは、クライアントアダプタを介してサーバと通信する。クライアントアダプタ同士は、クライアントおよびサーバが使用している特定のプロトコルを利用することによって（かつ変換することによって）、サーバとクライアントの間で相互作用することができる。これによって、異なったタイプのクライアントのユーザが通信を行うことが可能になり、また、どのように、いつ、どこで自分へのメッセージを見るかに関して、多大なフレキシビリティがユーザに提供される。
【００１４】
例示的な実施形態
図１は、本発明に従って、複数の異なるデバイスおよびフォーマットによって、またそれらの間で、メッセージの送信、問合せ、および／または受信が行われることを可能にする、トランスポートにとらわれないプルモードメッセージングシステム１００の例示的な実施形態の構成図を示す。メッセージストレージ１０１、サーバエンジン１０２、複数のクライアントアダプタ１０３、１０４、１０５、および複数のクライアントデバイス１０６、１０７、１０８が備えられている。メッセージストレージ１０１は、クライアントによって送信および／または受信されたメッセージを記憶するために使用することができる。メッセージは、メッセージ本文、メッセージ送信者の識別、メッセージのエンドポイントの宛先、およびメッセージに関連するその他のいずれかの情報を含む。エンドポイントは、例えば、特定のユーザ、クライアントデバイス、またはアプリケーションであり得る。メッセージは、そのメッセージを削除するようにというサーバエンジン１０２からの命令が受信されるまで記憶されている。当技術分野で知られている、データ記憶のためのいずれかの方法、システム、または技術を使用できることを理解されたい。
【００１５】
サーバエンジン１０２を使って、クライアントアダプタ１０３、１０４、１０５およびメッセージストレージ１０１と通信を行う。クライアントアダプタは、サーバエンジン１０２がメッセージストレージ１０１上で特定の動作を行うように要求することができる。これらの動作には、メッセージストレージ１０１への、またはそこからのメッセージの追加、削除、および／または検索が含まれ得る。メッセージストレージ１０１に対する変更はどれも、一般的にサーバエンジン１０２の修正に従って行われ、クライアントアダプタの動作に影響を与えることはないので、サーバエンジン１０２は、メッセージストレージ１０１の基本的な設計におけるフレキシビリティを可能にする。
【００１６】
例えば、サポートされるクライアントデバイスタイプそれぞれについて１つずつというように、複数のクライアントアダプタがある。クライアントアダプタは、関連するクライアントデバイスとサーバエンジン１０２の間の仲介の役割を果たすことができ、クライアントデバイスまたはサーバエンジン１０２のどちらかが同じ通信方法またはプロトコルを使用しなくても、クライアントがサーバエンジン１０２と相互作用できるようにする。サポートされるクライアントタイプごとにクライアントアダプタを使用することによって、サーバエンジン１０２またはクライアント自体に対する修正を必要とすることなく、新しいクライアントを容易に追加できることを理解されたい。これらのクライアントデバイスを、ユーザによるメッセージの送受信に使用することができる。
【００１７】
例示の目的で、本例に関して、３つのクライアントアダプタおよび３つのクライアントデバイスについて説明する。例えば、ＰＤＡアダプタ１０３を使って、ＰＤＡクライアント１０６とサーバエンジン１０２の間の通信を行う。ＰＤＡクライアント１０６は、当技術分野においてよく知られている標準的なパーソナルディジタルアシスタントであってよい。同様に、電子メールアダプタ１０４を使って、電子メールクライアント１０７とサーバエンジン１０２の間の通信を行う。電子メールクライアント１０７は、当技術分野においてよく知られている、マイクロソフト（商標登録）のＯｕｔｌｏｏｋなどの標準的な電子メールアプリケーションであってよい。さらに、ＳＭＳアダプタ１０５を使って、ＳＭＳクライアント１０８とサーバエンジン１０２の間の通信を行う。ＳＭＳクライアント１０８は、当技術分野においてよく知られている標準的な携帯電話デバイスであってよい。
【００１８】
ＰＤＡクライアント１０６のユーザが、特定のエンドポイントにメッセージを送りたいとする。説明の目的でＰＤＡクライアント１０６が選択されているが、メッセージを送信するのにどのクライアントを使ってもよいことを理解されたい。エンドポイントは、例えば、別のユーザ、アプリケーション、または異なるタイプのクライアントであってよい。この例では、エンドポイントがＳＭＳクライアント１０８であると仮定する。
【００１９】
メッセージが受信されることを保証するために、ＰＤＡクライアント１０６は、まず、そのメッセージに対して一意のメッセージ識別（例えば番号またはその他の識別子）を生成する。当技術分野で知られている、一意のメッセージ識別子を生成するためのいずれかの方法、システムまたは技術を使用することができる。この一意の識別子の目的は、メッセージが受信されたことを保証すること、また、その後に再提出が行われた場合にはシステムによってそれが重複として扱われるようにすることである。この一意の識別子を、ＰＤＡクライアント１０６に関連付けられたアダプタ、この場合においてはＰＤＡアダプタ１０３に、メッセージの内容と一緒に送ることができる。
【００２０】
この例示的実施形態では、ＰＤＡクライアント１０６が送信したメッセージをＰＤＡアダプタ１０３が受信する場合もあるし、あるいはしない場合もある。ＰＤＡアダプタ１０３は、メッセージを受信した場合には、ＰＤＡクライアント１０６によって提供された一意の識別子とともにメッセージを受信したことを述べたメッセージで、ＰＤＡクライアント１０６に応答することができる。ＰＤＡアダプタ１０３がメッセージを受信しなかった場合、つまりメッセージが伝送中に失われた場合、または、ＰＤＡクライアント１０６が応答を受信しなかった場合には、特定の指定時間の経過後に、ＰＤＡクライアント１０６は、元のメッセージを一意の識別子とともに再送信することができる。ＰＤＡクライアント１０６は、メッセージが受信されたことを表す応答をＰＤＡアダプタ１０３から受信するまで、メッセージと一意の識別子を再送信し続ける。
【００２１】
この例示的実施形態において、ＰＤＡアダプタ１０３は、ＰＤＡクライアント１０６によって送信されたメッセージに対する応答をすでに送信しているとする。そのメッセージを、次に、ＰＤＡアダプタ１０３がサーバエンジン１０２に送信することができる。ＰＤＡアダプタ１０３を、メッセージ要求を処理するサーバエンジン１０２とメッセージを送信し、要求するＰＤＡクライアント１０６の間の通信層として特徴付けることができる。クライアントデバイスのそれぞれは、異なるスタンダードまたはプロトコルを使って通信することができる。サーバエンジン１０２にとって、複数のスタンダードまたはプロトコルを利用しているクライアントデバイスと通信することは面倒であることを理解されるであろう。したがって、それぞれのタイプのクライアントが、サーバエンジン１０２とそれぞれのタイプのクライアントの間の通信を可能にする、関連付けられたアダプタ（例えば、１０３、１０４、１０５）を有することができる。クライアントアダプタを使用することによって、サーバの設計がモジュール化され、また新しいアダプタタイプを作成することにより新しいタイプのクライアントを追加する能力が提供されることを理解されたい。
【００２２】
次に、サーバエンジン１０２は、前にＰＤＡクライアント１０６によって供給された一意のメッセージ識別子と、そのクライアントに関連付けられたクライアント識別番号とを使って、メッセージストレージ１０１に問い合わせることができる。各クライアントは、好ましくは、それに関連付けられた識別子を持っている。クライアント識別子は、クライアントを一意に識別して他のクライアントから区別する、いずれかの番号または識別であってよい。
【００２３】
この問合せは、一致する一意のメッセージ識別子と、ＰＤＡクライアント１０６に対応するクライアント識別子とを含むメッセージを探して、メッセージストレージ１０１をサーチする。メッセージストレージ１０１が一致するものがあった場合にそれらを返してくると、サーバエンジン１０２は、望ましくは、現在のメッセージを重複とみなして、そのメッセージを保存しない。一意のメッセージ識別子は特定のクライアントに対してのみ一意であって、システム全体に対してではないため、一意のメッセージ識別子とともにクライアント識別子を使うことによって、一意のメッセージ識別子がかちあっているためにメッセージが失われたりしないことが保証されることを理解されたい。
【００２４】
メッセージストレージ１０１が問合せの結果を返さない場合に、サーバエンジン１０２は、メッセージストレージ１０１に記憶するためにそのメッセージを標準化することができる。アダプタを使用することによって、クライアントはサーバエンジン１０２との通信が可能になるが、しかし、依然として、メッセージストレージ１０１に記憶するためにメッセージをフォーマットまたは標準化する必要性があり得ることを理解されたい。メッセージは、望ましくは、サーバエンジン１０２によってＸＭＬに標準化される。当技術分野で知られている、メッセージ標準化のためのシステム、技術または方法を使用できることを理解されたい。次いで、標準化されたメッセージはメッセージストレージ１０１に送信され、後でクライアントデバイスが検索できるように記憶される。
【００２５】
例示的一実施形態において、ＳＭＳクライアント１０８のユーザが、自分宛に送信されているかもしれないメッセージのいくつかまたはすべてを受け取りたいとする。前にＰＤＡクライアント１０６のユーザによって送信されたメッセージなどのこれらのメッセージは、メッセージストレージ１０１に存在することができる。ユーザは、それらのメッセージを受け取りたいということを、どのように受け取りたいかということとともに指定したメッセージをＳＭＳアダプタ１０５に送信することによって、それらのメッセージを要求することができる。
【００２６】
ユーザは、自分へのメッセージをどのように自分に返させることができるかについて、いくつかから選択できる。特に、ユーザは、メッセージが受信されるエンドポイントを指定することができる。このエンドポイントは、ユーザが現在使用しているデバイスであってもよいが、別のユーザまたは電子メールクライアント１０７など、別のエンドポイントであってもよい。例えば、ユーザは、多数のメッセージが持てるので、代わりに電子メールクライアント１０７上でそれらを見たいということもある。さらに、ユーザは、自分が現在使用しているデバイス上でメッセージを受け取りたいが、ただし異なるプロトコルを使用したいという場合がある。例えば、ユーザは、それまで電子メールクライアント１０７を使って自分のパーソナルコンピュータでメッセージを受信していたかもしれないが、今は、ウェブブラウザを使ってそのパーソナルコンピュータでメッセージを受信したいという場合がある。
【００２７】
ＳＭＳクライアント１０８のユーザが、自分へのメッセージをＳＭＳクライアント１０８上で読みたいと想定する。したがって、彼は、ＳＭＳクライアント１０８でメッセージを受け取りたいということを表すメッセージを、ＳＭＳアダプタ１０５に送ることができる。ＳＭＳクライアント１０８は、まず、一意のメッセージ識別子を生成する。この一意のメッセージ識別子を使って、そのメッセージがＳＭＳアダプタ１０５によって受信されることを保証し、また重複メッセージの送信を防ぐ。次に、ＳＭＳクライアント１０８は、ユーザが自分へのメッセージをエンドポイントＳＭＳクライアント１０８で受け取りたいということを指定した、一意のメッセージ識別子付きのメッセージを、いずれかの追加配信オプションが有効であればそれとともに、ＳＭＳアダプタ１０５に送信することができる。
【００２８】
ＳＭＳアダプタ１０５は、その関連するメッセージをＳＭＳクライアント１０８に送信するようにという要求を、ＳＭＳクライアント１０８から受信することができる。ＳＭＳアダプタ１０５は、次に、ＳＭＳクライアント１０８をエンドポイントとするすべてのメッセージの要求とともに、メッセージをサーバエンジン１０２に送信することができる。サーバエンジン１０２は、ＳＭＳクライアント１０８に一致する指定エンドポイントを有するメッセージについて、メッセージストレージ１０１に問い合わせる。メッセージストレージ１０１は、一致するすべてのメッセージをサーバエンジン１０２に返す。サーバエンジン１０２は、それらのメッセージを、伝送先のエンドポイント、この場合はＳＭＳクライアント１０８が要求するフォーマットに標準化することができる。前に述べたように、メッセージは、ＸＭＬとしてメッセージストレージ１０１に記憶されている。サーバエンジン１０２は、望ましくは、それらのメッセージを、ＸＭＬからＳＭＳクライアント１０８が要求するフォーマットに変換する。サーバエンジン１０２は、次いで、それらのメッセージをＳＭＳアダプタ１０５に送信する。ＳＭＳアダプタ１０５は、次いで、それらのメッセージを一意のメッセージ識別子とともにＳＭＳクライアント１０８に送信することができる。ＳＭＳクライアント１０８は、メッセージを受信すると、それらを表示するか、または別の方法でユーザに提供することができる。
【００２９】
ＳＭＳクライアント１０８が、要求したメッセージを受信しない場合がある。これは、例えば、ＳＭＳアダプタ１０５に送信した最初の要求が伝送中に失われたか、または、ＳＭＳアダプタ１０５からの応答が伝送中に失われたことによる可能性がある。いずれの場合も、ＳＭＳクライアント１０８は、所定の（好ましくは、ユーザ定義の）タイムアウト期間経過後に、元のメッセージを元の一意のメッセージ識別子とともに再送信する。好ましくは、ＳＭＳクライアント１０８は、一致する一意の識別子を含む応答をＳＭＳアダプタ１０５から受信するまで、一意の識別子付きの元のメッセージを再送信し続ける。重複応答が到着した場合には、その一意のメッセージ識別子から識別できるため、望ましくは、ＳＭＳクライアント１０８はそれを無視する。
【００３０】
ＳＭＳクライアント１０８のユーザが自分へのメッセージを受け取ったとする。これらのメッセージは、ユーザが電子メールアプリケーションに送りたいと望む情報を含んでいることがある。例えば、メッセージは、ユーザがデスクトップコンピュータ上で電子メールアプリケーションを用いることによって容易に見ることができる、テキストまたは添付物を含む。ＳＭＳクライアント１０８のユーザが特定のメッセージを電子メールクライアント１０７に転送したいと仮定すると、彼は、電子メールクライアント１０７に対応するエンドポイントに選択したメッセージを転送するようにというメッセージを、ＳＭＳアダプタ１０５がそのメッセージを受信したことを保証するための一意のメッセージ識別子とともにＳＭＳアダプタ１０５に送ることができる。
【００３１】
ＳＭＳアダプタ１０５は、そのメッセージを受信すると、メッセージを受信したことを示す応答をＳＭＳクライアント１０８に送信することができる。ＳＭＳクライアント１０８は、ある（好ましくは、ユーザ定義の）タイムアウト期間内に応答を受け取らなかった場合、メッセージを再送信することができる。
【００３２】
ＳＭＳアダプタ１０５は、指定したメッセージを電子メールクライアント１０７に転送するようにというメッセージをサーバエンジン１０２に送信することができる。サーバエンジン１０２は、メッセージストレージ１０１に、指定されたメッセージの問合せを行う。サーバエンジンは、次いで、受信したメッセージのコピーを作成することができ、メッセージの宛先を電子メールクライアント１０７に変更することができる。サーバエンジン１０２は、次に、新しいメッセージをメッセージストレージ１０１に保存することができる。メッセージは、その後、電子メールクライアント１０７がそれらを要求してくるのを、あるいはその他の方法でアクセスしてくるのをメッセージストレージ１０１で待つ。
【００３３】
図２は、クライアントとサーバの間のメッセージの配信を保証する例であり、図３は、本発明に従った、メッセージの配信を保証する例示的方法に対応する流れ図である。
【００３４】
クライアントデバイス２２０がサーバ２３０にメッセージを送りたいと仮定する。このメッセージは、例えば、その送信者が別のユーザに受け取ってほしいと思っている情報を中継するため、あるいは、サーバが問い合わせたメッセージの配信を要求するためなど、様々な目的で送信され得る。クライアントデバイス２２０は、このメッセージを送信する前に、識別番号などの一意のメッセージ識別子を生成し、あるいは、要求して受信する。この一意のメッセージ識別は、当技術分野で知られている、メッセージに一意の識別子を関連付けるためのいずれかの方法、システムまたは技術を使って生成することが考えられる。
【００３５】
２０１で、クライアントデバイス２２０は、一意のメッセージ識別とともにメッセージをサーバ２３０に送信する。２０１を、図３のステップ３０１に関してさらに説明する。ステップ３０１で、一意のメッセージ識別が生成され、メッセージとともにサーバに送信される。さらに、タイマが開始されて、メッセージが送信されてからの経過時間をカウントする。当技術分野で知られている、時間をカウントするためのいずれかの方法、システム、または技術を使用できることを理解されたい。
【００３６】
２０２に示すように、サーバ２３０に送信されたメッセージは、様々な理由によって受信されない。理由のいくつかは、図１に関して上記に説明した。所定の、および／またはユーザプログラム可能な、ある指定タイムアウト時間（“ｔ”）の経過後、クライアントデバイス２２０は、サーバ２３０からメッセージへの応答を受け取らなかったと判断する。２０３で、クライアントデバイス２２０は、一意のメッセージ識別とともにメッセージを再送信する。２０４で、サーバ２３０はメッセージを受信し、メッセージに含まれている命令を実行することができる。
【００３７】
ステップ３０２〜３０４に関して、２０３および２０４をさらに説明する。ステップ３０２で、“ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅｄ”などの変数をチェックすることにより、メッセージに対して一致する応答が受信されたかどうかを判断する。変数は、好ましくは、一致するメッセージが受信されたかどうかを表すために設定されたフラグ変数である。当技術分野で知られている、メッセージが到着したかどうかを判断するためのいずれかの方法、技術、またはシステムを使用できることを理解されたい。メッセージが受信された場合には、処理はステップ３９９に進み、そこでルーチンは終了する。メッセージが受信されなかった場合には、処理はステップ３０３に進む。
【００３８】
ステップ３０３で、元のメッセージが送信されてから最大時間ｔが経過したかどうかが判断される。最大時間ｔが経過したことは、メッセージを再送信すべきであることを表す。タイマの現在値がｔと比較される。タイマの値がｔより小さい場合には、プロセスはステップ３０２に戻る。そうでなければ、プロセスはステップ３０４に進む。
【００３９】
ステップ３０４で、最大時間ｔが経過したと判断され、クライアントは、元のメッセージと一意のメッセージ識別を再送信する。また、タイマは、望ましくは、メッセージを再送信すべきかどうかを後でまた判断できるようにリセットされる。
【００４０】
図２に戻ると、２０５に示すように、サーバ２３０は、メッセージを受信したという応答をクライアントデバイス２２０に送信する。サーバ２３０は、この応答に、応答の対象となるメッセージとともに送信されてきた一意のメッセージ識別を含めることができる。
【００４１】
２０６で、サーバ２３０に送信された応答は様々な理由により受信されない。理由のいくつかは上記に記載した。そこで、２０７で、時間ｔが経過し、クライアントデバイス２２０は、元のメッセージに対する応答を受け取らなかったと判断する。クライアントデバイス２２０は、実際はメッセージが受信されたことがわからない場合もある。したがって、クライアントデバイス２２０は、メッセージを一意のメッセージ識別とともに再送信する。上記のステップ３０２〜３０４に関して、２０６および２０７を図３においてさらに説明してある。
【００４２】
２０８で、サーバ２３０は、２０７で重複物として送信されたメッセージを受信する場合がある。サーバ２３０は、前に、同じ一意のメッセージ識別子の付いたメッセージをクライアントデバイス２２０から受け取っており、したがってメッセージに含まれている命令をすでに実行していると認識する。したがって、サーバ２３０は、自分が２０５で送信したメッセージが受信されなかったとみなすことができる。２０９で、サーバ２３０は、それが２０５で最初に送信した、メッセージに対する応答を再送信する。
【００４３】
２１０で、クライアントデバイス２２０は、サーバ２３０から応答を受け取ることができる。クライアントデバイス２２０は、その応答が、サーバ２３０に送信したメッセージと同じ一意のメッセージ識別を含んでいると判断する。そこで、クライアントデバイス２２０は、メッセージが受信され、サーバ２３０が反応したと結論を下すことができる。
【００４４】
ステップ３０２および３９９で、２１０をさらに説明する。ステップ３０２で、変数ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅｄをチェックすることによって、メッセージに対する一致する応答が受信されたかどうかを判断する。フラグ変数ｍｅｓｓａｇｅ＿ｒｅｃｅｉｖｅｄは、一致するメッセージが受信されたかどうかを表すように設定されている。当技術分野で知られている、メッセージが到着したかどうかを判断するためのいずれかの方法、技術、またはシステムを使用できることを理解されたい。メッセージが受信された場合には、プロセスはステップ３９９に進むことができる。メッセージが受信されなかった場合には、プロセスはステップ３０３に進むことができる。ステップ３９９では、応答が受信されたことがすでに判断できているので、プロセスは終了する。
【００４５】
例示的なコンピューティング環境
図４は、本発明を実施することができる適切なコンピューティングシステム環境４００の例を示す。コンピューティングシステム環境４００は、適切なコンピューティング環境の一例にすぎず、本発明の使用または機能の範囲に関する限定を示唆することを意図したものではない。また、コンピューティングシステム環境４００を、この例示的な動作環境４００中に示したコンポーネントのいずれか１つまたは組合せに何らか依存するもの、あるいはコンポーネントのいずれか１つまたは組合せを必要とするものとして解釈すべきでもない。
【００４６】
本発明は、例えば、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な大衆消費電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境など、数多くのその他の汎用または専用のコンピューティングシステム環境または構成で動作可能である。
【００４７】
図４を見ると、本発明を実施するための例示的なシステムは、汎用コンピューティングデバイスをコンピュータ４１０の形態で含む。コンピュータ４１０のコンポーネントには、処理装置４２０、システムメモリ４３０、および、システムメモリを含めて様々なシステムコンポーネントを処理装置４２０に結合する、システムバス４２１を含めることができるが、それらに限定されるわけではない。システムバス４２１は多様なバスアーキテクチャを使用する、メモリバス、メモリコントローラ、周辺バス、およびローカルバスを含む、いかなる種類のバス構造であってもよい。
【００４８】
コンピュータ４１０は、一般的に、様々なコンピュータ可読媒体を含み、揮発性および不揮発性媒体の両方、取外し可能および固定媒体の両方を含む。
【００４９】
システムメモリ４３０は、ＲＯＭ４３１およびＲＡＭ４３２などの揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。起動時などにコンピュータ４１０内の構成要素間の情報転送の助けとなる基本ルーチンを含む、基本入出力システム４３３（ＢＩＯＳ）は、一般的にＲＯＭ４３１に記憶されている。限定ではなく例として、図４は、オペレーティングシステム４３４、アプリケーションプログラム４３５、その他のプログラムモジュール４３６、およびプログラムデータ４３７を示す。
【００５０】
コンピュータ４１０はまた、その他の取外し可能／固定の揮発性／不揮発性コンピュータ記憶媒体も含む。例にすぎないが、図４には、固定不揮発性磁気媒体からの読取りまたはそこへの書込みを行うハードディスクドライブ４４１、取外し可能な不揮発性磁気ディスク４５２からの読取りまたはそこへの書込みを行う磁気ディスクドライブ４５１、および取外し可能な不揮発性光ディスク４５６からの読取りまたはそこへの書込みを行う光ディスクドライブ４５５を示してある。ハードディスクドライブ４４１は、一般的に、インタフェース４４０などの固定メモリインタフェースを介してシステムバス４２１に接続され、磁気ディスクドライブ４５１および光ディスクドライブ４５５は、一般的に、インタフェース４５０などの取外し可能なメモリインタフェースによってシステムバス４２１に接続される。
【００５１】
これらのドライブおよびそれらに関連するコンピュータ記憶媒体は、コンピュータ可読能命令、データ構造、プログラムモジュールおよびその他のデータの記憶をコンピュータ４１０に提供する。図４では、例えば、ハードディスクドライブ４４１を、オペレーティングシステム４４４、アプリケーションプログラム４４５、その他のプログラムモジュール４４６、およびプログラムデータ４４７を記憶しているものとして示してある。これらのコンポーネントは、オペレーティングシステム４３４、アプリケーションプログラム４３５、その他のプログラムモジュール４３６、およびプログラムデータ４３７と同じ場合もあれば異なる場合もあることに注意されたい。ユーザは、キーボード４６２、および、一般にマウス、トラックボールまたはタッチパッドと呼ばれるポインティングデバイス４６１などの入力デバイスを介して、コンピュータ４１０にコマンドおよび情報を入力することができる。これらおよびその他の入力デバイスは、システムバスに結合されたユーザ入力インタフェース４６０を介して処理装置４２０に接続されることが多いが、その他のインタフェースおよびバス構造によって接続することができる。モニタ４９１またはその他のタイプの表示デバイスも、ビデオインタフェース４９０などのインタフェースを介して、システムバス４２１に接続される。モニタに加えて、コンピュータはまた、スピーカ４９７やプリンタ４９６などのその他の周辺出力デバイスも含むことができ、それらは、出力周辺インタフェース４９５を介して接続することができる。
【００５２】
コンピュータ４１０は、リモートコンピュータ４８０などの１つまたは複数のリモートコンピュータへの論理接続を使って、ネットワーク化された環境で動作することができる。リモートコンピュータ４８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、またはその他の一般的なネットワークノードであってよく、一般的に、コンピュータ４１０に関連して上述した構成要素の多くまたは全てを含む。ただし、図４にはメモリ記憶装置４８１のみを示してある。図示の論理接続には、ＬＡＮ４７１およびＷＡＮ４７３が含まれるが、その他のネットワークも含まれ得る。
【００５３】
ＬＡＮネットワーク化環境において使用する場合、コンピュータ４１０を、ネットワークインタフェースまたはアダプタ４７０を介してＬＡＮ４７１に接続する。ＷＡＮネットワーク化環境において使用する場合、コンピュータ４１０は、一般的に、モデム４７２、またはインターネットなどのＷＡＮ４７３を介して通信を確立するためのその他の手段を含む。モデム４７２は、内蔵または外付けであってよく、ユーザ入力インタフェース４６０またはその他の適切なメカニズムを介してシステムバス４２１に接続することができる。ネットワーク化環境においては、コンピュータ４１０に関連して説明したプログラムモジュールまたはその一部を、リモートメモリ記憶装置に記憶することができる。限定ではなく例として、図４は、リモートアプリケーションプログラム４８５をメモリ装置４８１に常駐するものとして示している。図示のネットワーク接続は例にすぎず、コンピュータ間の通信リンクを確立するためのその他の手段を使用できることを理解されたい。
【００５４】
上述のように、本発明の例示的な実施形態を様々なコンピューティングデバイスに関連させて説明してきたが、基礎をなすコンセプトは、いかなるコンピューティングデバイスまたはシステムにも適用できる。本明細書で説明している様々な技術は、ハードウェアまたはソフトウェアに関連させて、または必要に応じてそれらを組み合わせて実施することができる。したがって、本発明の方法および装置、またはその特定の態様またはその一部は、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ハードドライブ、またはいずれかのその他のマシン可読記憶媒体などの有形媒体において実施されるプログラムコード（すなわち命令）の形態をとることができ、この場合、このプログラムコードがコンピュータなどのマシンによってロードされ、実行されると、そのマシンが本発明を実行するための装置になる。プログラム可能なコンピュータ上でプログラムコードを実行する場合、そのコンピューティングデバイスは、一般に、プロセッサが読み取り可能な記憶媒体（揮発性および不揮発性メモリおよび／または記憶素子）、少なくとも１つの入力デバイス、および少なくとも１つの出力デバイスを含む。プログラムは、所望により、アセンブリまたはマシン言語で実装することができる。いすれの場合も、言語はコンパイル済みまたは解釈済みの言語であって、ハードウェアの実装と組み合わせることができる。
【００５５】
本発明の方法および装置はまた、電気配線やケーブル布線、光ファイバ、またはいずれかのその他の伝送形態を介してなど、何らかの伝送媒体を介して伝送されるプログラムコードの形態で実施される、通信を介した実行が可能である。この場合、プログラムコードが受信されて、ＥＰＲＯＭ、ゲートアレイ、プログラム可能論理デバイス（ＰＬＤ）、クライアントコンピュータなどのマシンによってロードされ、実行されると、そのマシンが本発明を実行するための装置になる。このプログラムコードは、汎用プロセッサに実装された場合、プロセッサと結合して、本発明の機能を呼び出すために動作する唯一の装置を提供する。さらに、本発明に関連して使用されるいずれかの記憶技術は、常にハードウェアとソフトウェアの組合せになる。
【００５６】
本発明を、様々な図の好ましい実施形態に関連して説明してきたが、本発明から逸脱することなく本発明と同じ機能を実行するために、その他の同様の実施形態も使用することができ、あるいは、記載の実施形態に修正および追加を施すことができることを理解されたい。したがって、本発明は、いずれか１つの実施形態に限定すべきものではなく、添付の特許請求の範囲に従った範囲で解釈すべきものである。
【図面の簡単な説明】
【００５７】
【図１】本発明の特徴を説明する際に役立つ、例示的システムの構成図である。
【図２】本発明に従ってクライアントとサーバの間のメッセージ配信を保証する例示的方法を説明する際に役立つ図である。
【図３】本発明に従ってクライアントとサーバの間のメッセージ威信を保証する例示的方法の流れ図である。
【図４】本発明の態様を実施することができる、例示的コンピューティング環境を示す構成図である。
【図１】
2007526674.tif 000003
【図２】
2007526674.tif 000004
【図３】
2007526674.tif 000005
【図４】
2007526674.tif 000006
【国際調査報告】
2007526674.tif 000007