【誤訳訂正書】
【提出日】平成23年5月6日(2011.5.6)
【誤訳訂正１】
【訂正対象書類名】特許請求の範囲
【訂正対象項目名】全文
【訂正方法】変更
【訂正の内容】
【特許請求の範囲】
【請求項１】
メッセージサーバ、受信計算機システム、及びメッセージＩＤデータベースを備えたメッセージ配信システムであって、
上記メッセージサーバは、
送信計算機システムからメッセージを受信し、上記メッセージの受信に応答してメッセージＩＤを生成するように構成され、上記メッセージＩＤは上記受信されたメッセージを識別するように生成され、
上記メッセージを受信したとき、上記メッセージＩＤを上記メッセージＩＤデータベースにプッシュ送信するように構成され、
上記受信計算機システムからのメッセージ要求の受信に応答して上記受信計算機システムに上記メッセージを送信するように構成され、
上記受信計算機システムは、
上記メッセージＩＤデータベースにメッセージＩＤ問い合わせを送信することにより上記メッセージサーバにではなく上記メッセージＩＤデータベースにコンタクトして、メッセージの配信準備ができているか否かを決定するように動作し、
上記メッセージＩＤデータベースは、
上記受信計算機システムからの上記メッセージＩＤ問い合わせの受信に応答して上記受信計算機システムにメッセージＩＤ応答を提供するように構成され、上記メッセージＩＤ応答は上記メッセージＩＤデータベースに記憶されたメッセージＩＤに関する情報を含む、メッセージ配信システム。
【請求項２】
上記送信計算機システムをさらに備えた、請求項１記載のメッセージ配信システム。
【請求項３】
メッセージサーバからメッセージを受信する受信計算機システムであって、上記システムは、
上記メッセージサーバにではなくメッセージＩＤデータベースにメッセージＩＤ問い合わせを送るように動作し、上記メッセージＩＤデータベースは、メッセージＩＤを記憶し、上記メッセージＩＤ問い合わせの受信に応答して上記受信計算機システムにメッセージＩＤ応答を送信するように構成されており、上記メッセージＩＤ応答は上記メッセージＩＤデータベースに記憶されたメッセージＩＤに関する情報を含み、
上記メッセージＩＤデータベースから上記メッセージＩＤ応答を受信し、上記メッセージＩＤ応答を受信すると、上記メッセージサーバからメッセージを取り出す準備ができていることを上記メッセージＩＤ応答が示しているか否かを決定するように動作し、
肯定された場合には、次いで、
上記メッセージサーバにメッセージ要求を送信することにより、上記メッセージサーバが上記受信計算機システムに上記メッセージを送信することを要求するように動作し、
上記メッセージサーバから送信されたメッセージを受信するように動作する、システム。
【請求項４】
上記メッセージＩＤ応答が上記メッセージサーバにおける特定メッセージを識別するメッセージＩＤを含んでいる、請求項３記載のシステム。
【請求項５】
送信計算機システムからの１又は複数のメッセージを処理する方法であって、上記方法は、
メッセージサーバが、上記送信計算機システムから送信された１又は複数のメッセージの受信に応答して、上記受信された１又は複数のメッセージを識別する１又は複数のメッセージＩＤを生成するステップと、
上記メッセージサーバが、上記１又は複数のメッセージを受信したとき、上記１又は複数のメッセージＩＤのうちの少なくとも１つをメッセージＩＤデータベースにプッシュ送信するステップと、
上記メッセージＩＤデータベースが上記プッシュ送信された少なくとも１つのメッセージＩＤを受信するステップと、
受信計算機システムが、上記メッセージＩＤデータベースにメッセージＩＤ問い合わせを送信することにより上記メッセージサーバにではなく上記メッセージＩＤデータベースにコンタクトして、メッセージの配信準備ができているか否かを決定するステップとを含む、方法。
【請求項６】
上記方法は、更に、上記送信計算機システムが上記メッセージサーバに１又は複数のメッセージを送信するステップを含む、請求項５記載の方法。
【請求項７】
上記少なくとも１つのメッセージＩＤを上記メッセージサーバから上記メッセージＩＤデータベースにプッシュ送信するステップは、
上記メッセージサーバが上記送信計算機システムに上記少なくとも１つのメッセージＩＤを送信するステップと、
上記送信計算機システムが上記少なくとも１つのメッセージＩＤを上記メッセージＩＤデータベースに送信するステップとを含む、請求項５又は６記載の方法。
【請求項８】
上記方法は、更に、上記受信計算機システムが上記メッセージＩＤデータベースにメッセージＩＤ問い合わせを送ったことに応答して、上記メッセージＩＤデータベースが上記受信計算機システムにメッセージＩＤ応答を提供するステップを含み、上記メッセージＩＤ応答が上記メッセージＩＤデータベースに記憶されたメッセージＩＤに関する情報を含む、請求項５から７までのいずれかに記載の方法。
【請求項９】
上記方法は、更に、上記メッセージサーバから上記１又は複数のメッセージのうちの少なくとも１つを取り出す準備ができていることを上記メッセージＩＤ応答が示しているか否かを上記受信計算機システムが決定するステップを含み、
肯定された場合には、次いで、
上記受信計算機システムが上記メッセージサーバにメッセージ要求を送信するステップと、
上記メッセージサーバが、上記メッセージ要求の受信に応答して、上記受信計算機システムに要求されたメッセージを送信するステップと、
上記受信計算機システムが要求したメッセージを受信するステップとを含む、請求項８記載の方法。
【請求項１０】
上記受信計算機システムが上記メッセージサーバから受信した所定のメッセージに対応するメッセージＩＤを、上記受信計算機システムにおいてローカルに記憶する、請求項８又は９記載の方法。
【請求項１１】
受信計算機システムでメッセージサーバからメッセージを受信する方法であって、上記方法は、
上記受信計算機システムが、上記メッセージサーバにではなく上記メッセージＩＤデータベースにメッセージＩＤ問い合わせを送信するステップを含み、上記メッセージＩＤデータベースが、メッセージＩＤを記憶し、上記メッセージＩＤ問い合わせの受信に応答して上記受信計算機システムにメッセージＩＤ応答を送信するように構成されており、上記メッセージＩＤ応答が上記メッセージＩＤデータベースに記憶されたメッセージＩＤに関する情報を含み、
上記方法は、
上記受信計算機システムが上記メッセージＩＤデータベースから上記メッセージＩＤ応答を受信するステップと、
上記メッセージサーバからメッセージを取り出す準備ができていることを上記メッセージＩＤ応答が示しているか否かを上記受信計算機システムが決定するステップとを含み、上記メッセージサーバが、上記受信計算機システムからのメッセージ要求の受信に応答して上記受信計算機システムに上記メッセージを送信するように構成されており、
上記方法は、
上記メッセージサーバからメッセージを取り出す準備ができている場合、次いで、
上記受信計算機システムが、上記メッセージを要求するために上記メッセージサーバにメッセージ要求を送信するステップと、
上記メッセージサーバが、上記メッセージ要求の受信に応答して上記受信計算機システムに上記メッセージを送信するステップと、
上記受信計算機システムが、上記メッセージを受信するステップとを含む、方法。
【請求項１２】
上記受信計算機システムは、上記受信計算機システムが未だメッセージを要求して受信していない場合にのみ、メッセージを要求する、請求項１１記載の方法。
【請求項１３】
上記方法は、更に、上記受信計算機システムがメッセージ受信時にメッセージに関連するメッセージＩＤを記憶するステップを含み、上記メッセージＩＤが上記メッセージサーバにおいてメッセージを識別するものである、請求項１１記載の方法。
【請求項１４】
上記受信計算機システムにおいて対応するメッセージＩＤが利用可能でない場合にのみ、上記受信計算機システムがメッセージを要求する、請求項１３記載の方法。
【請求項１５】
上記メッセージＩＤデータベースのリソースと上記メッセージサーバのリソースとは相互に独立している、請求項１から４までのいずれかに記載のシステム。
【請求項１６】
上記メッセージＩＤデータベースが分散型データベースである、請求項１から４まで及び１５のいずれかに記載のシステム。
【請求項１７】
上記メッセージＩＤデータベースのリソースと上記メッセージサーバのリソースとは相互に独立している、請求項５から１４までのいずれかに記載の方法。
【請求項１８】
上記メッセージＩＤデータベースが分散型データベースである、請求項５から１４まで及び１７のいずれかに記載の方法。
【請求項１９】
ハードウエアの計算機システムで実行されると、請求項５から１４まで、１７及び１８のいずれかに記載の方法の少なくとも１つを当該計算機システムが実行できるようにするソフトウエア。
【請求項２０】
請求項１９に記載のソフトウェアを記憶するメモリと、上記ソフトウェアを実行するプロセッサと、ネットワークインターフェースとを備えた計算機システム。
【誤訳訂正２】
【訂正対象書類名】明細書
【訂正対象項目名】全文
【訂正方法】変更
【訂正の内容】
【発明の詳細な説明】
【発明の名称】通信システムにおけるメッセージ配信の方法及びシステム
【技術分野】
【０００１】
本発明は、通信システムの一人の使用者から通信システムの他の使用者へメッセージを伝送するシステム及び方法に関する。
【背景技術】
【０００２】
計算機を使用可能な通信システムは、常に増大し続けている多数の機能を備えている。それ故、クライアントとサーバのようなネットワーク構成要素間で伝送されなければならないメッセージの数と種類は、増加している。メッセージは、例えばネットワーク構成要素のステータス情報、同期情報、ネットワーク構成要素の能力、識別情報、認可情報、インスタントメッセージ、オーディオとビデオのパッケージのような実時間通信メッセージ等を含んでいる。
【０００３】
通信システムで交換されるデータの本体は、コンテンツ情報それ自体から成る。実時間のオーディオ／ビデオ通信セッションでは、コンテンツ情報は、音響及び映像が取り込まれてディジタル形式に変換されたときに形成されるオーディオ／ビデオパッケージから成る。コンテンツ情報自体に加えて、使用者識別又はネットワークプレゼンスに関する情報のような制御メッセージが交換される。コンテンツ情報と制御メッセージは、多かれ少なかれ統合されていてもよい。
【０００４】
典型的には、通信システムの第１使用者が第２使用者にメッセージを送信することを希望するとき、第１使用者は、新たなメッセージが有るか否かをみるために第２使用者が問い合わせをするメッセージサーバにメッセージを送信する。例えば、電子メールシステムでは、送信者は、受信者に配信される電子メールを作成する。続いて、電子メールは、受信者を特定する情報と共に電子メールサーバに送信される。電子メールシステムの使用者は、当該使用者を受信者とする新たな電子メールが有るか否かを決定するために、一種の制御メッセージである問い合わせメッセージを電子メールサーバに頻繁に送信する。送信者の電子メールが配信された後に電子メールサーバに受信者が問い合わせをすると、電子メールの受信者であることを示す情報を受信する。実時間配信の実感を出すために、使用者がかなり頻繁に、例えば毎秒１回又はそれ以上に頻繁に、電子メールサーバに問い合わせすることを好むことも有る。メッセージの受信者であることを示す情報を受信すると、受信者は、電子メールサーバにメッセージを要求して受信する。
【０００５】
問い合わせは、恐らくある種の認可証明書に加えて、使用者のＩＤ及びパスワードのような認可情報を含み得る。また、問い合わせは、タイムスタンプ又は他の固有の署名を含み得る。電子メールシステムが多数の使用者により使用される場合、問い合わせの処理に要するリソースが遂にシステムの能力を超えることもある。例えば、電子メールサーバの中央処理装置（ＣＰＵ）が入出力データの全てを処理できなくなることがある。また、電子メールサーバとの間で行われる電子メール及び問い合わせの交換は、システムの能力を超えるネットワークリソースを必要とする可能性がある。
【０００６】
結果的に電子メールサーバは正常に機能することを停止し、これは、システムの休止と、メッセージ配信を電子メールシステムに依存しているシステム使用者の不満とを意味する。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明の目的は、計算機システムに配信される１又は複数のメッセージを保持するメッセージサーバにかかる負荷を最小化するシステム及び方法を提供することである。
【課題を解決するための手段】
【０００８】
本発明の第１態様では、メッセージ配信システムが提供される。このシステムは、メッセージサーバ及びメッセージＩＤデータベースを備え、
メッセージサーバは、
第１計算機システムからメッセージを受信し、メッセージの受信に応答してメッセージＩＤを提供し、メッセージＩＤは受信されたメッセージを識別するために形成されるものであり、
メッセージＩＤをメッセージＩＤデータベースに送信し、
第２計算機システムからのメッセージ要求の受信に応答して第２計算機システムにメッセージを送信する
ように構成され、
メッセージＩＤデータベースは、
第２計算機システムからのメッセージＩＤ問い合わせの受信に応答して第２計算機システムにメッセージＩＤ応答を提供し、メッセージＩＤ応答はメッセージＩＤデータベースに記憶されたメッセージＩＤに関する情報を含む
ように構成されている。
【０００９】
このようなシステムは、送信者である一人の人物から受信者である他の人物へメッセージを配信するために使用可能である。第１計算機システムからのメッセージは、例えば、第１計算機システムを使用する送信者により生成されてもよい。メッセージは、任意のタイプの情報を含んでもよい。これは、音声メール、電子メール、インスタントメッセージ、ウェブログへのエントリ、ウェブページのデータ又はビデオクリップ等のファイルでもよい。また、これは、実行可能なプログラム、圧縮されたファイル、ダイナミックリンクライブラリ（ＤＬＬ）等でもよい。また、メッセージは、転送されるファイルの一部でもよい。
【００１０】
メッセージサーバが第１計算機システムからメッセージを受信すると、それにメッセージＩＤを割り当てる。メッセージＩＤは、例えば、認可情報、タイムスタンプ、及びメッセージ番号等の前述したタイプの情報を含み、メッセージ番号は、例えば、メッセージサーバがシステムの使用者から合計で何個のメッセージを受信したかを示す数である。
【００１１】
メッセージＩＤは、例えば１ｋＢのサイズを有する大量の情報を含む可能性がある。もし１００万人の使用者が１０秒毎にこのサイズの問い合わせをメッセージサーバに送信すると、メッセージサーバは、毎秒平均１００ＭＢのデータを交換する必要がある。したがって、ネットワーク制御メッセージ等のオーバヘッドを含めると、必要なビットレートは、毎秒約１ギガビットに達し、殆どの計算機システムとネットワークにとって、大きな、むしろ大きすぎる量となる。問い合わせの交換が済んだ後、実際のメッセージ自体の交換がされる。メッセージＩＤが別個のデータベースであるメッセージＩＤデータベースに送られることは、本システムの利点である。これにより、計算機システムが、メッセージサーバにコンタクトする必要なく、メッセージサーバ上のメッセージに関する情報を得ることができ、その結果、メッセージ要求以外の問い合わせに関してメッセージサーバにかかる負荷は、メッセージサーバから除去されてメッセージＩＤデータベースに移される。それ故、好ましくは、メッセージＩＤデータベースとメッセージサーバは、少なくともネットワークリソース、処理リソース若しくはこの双方に関して、少なくとも実質的に相互に独立したリソースを有し、又は全リソース（電源のような外部リソースと、メッセージＩＤデータベース及びメッセージサーバのいずれの性能にも影響しない他のパラメータとを除く。）に関して実質的に独立している。換言すれば、２つのシステムは、分離している。
【００１２】
メッセージＩＤデータベースにより返されるメッセージＩＤ応答は、例えば、メッセージサーバ上のメッセージを識別するメッセージＩＤを含む。このようにして、典型的には多数のメッセージを有するメッセージサーバに、特定のメッセージを要求することができる。代わりに、応答は、メッセージＩＤのようなメッセージに関する更なる詳細を提供することなく、メッセージを取り出す準備ができていることを示すようにしてもよい。この場合には、応答は、単に、メッセージが（第１計算機システムにより）メッセージサーバに配信されているか否かを示す情報となる。
【００１３】
送信者は、典型的には、特定の受信者へのメッセージを意図しており、送信者からメッセージサーバに提供される典型的情報である受信者識別情報をメッセージサーバがメッセージＩＤに含ませることが望ましい。受信者情報をメッセージサーバがメッセージＩＤに含ませることにより、メッセージＩＤデータベースは、受信者毎に固有のメッセージＩＤ（特定の受信者を示すメッセージＩＤ）のような受信者毎に固有の情報を配信することで、問い合わせに応答することができる。
【００１４】
本発明の第１態様によるメッセージ配信システムの実施形態は、メッセージサーバ、メッセージＩＤデータベース及び第１計算機システムを備える。本発明のメッセージ配信システムの他の実施形態は、メッセージサーバ、メッセージＩＤデータベース及び第２計算機システムを備える。本発明のメッセージ配信システムの他の実施形態は、メッセージサーバ、メッセージＩＤデータベース、第１計算機システム及び第２計算機システムを備える。
【００１５】
本発明の第２態様では、メッセージサーバからメッセージを受信する計算機システムが提供され、このシステムは、
メッセージＩＤデータベースにメッセージＩＤ問い合わせを送るように構成され、メッセージＩＤデータベースはメッセージＩＤを記憶してメッセージＩＤ問い合わせの受信に応答して計算機システムにメッセージＩＤ応答を送信するように構成されており、メッセージＩＤ応答はメッセージＩＤデータベースに記憶されたメッセージＩＤに関する情報を含み、
メッセージＩＤデータベースからメッセージＩＤ応答を受信するように構成され、
メッセージＩＤ応答の受信時に、メッセージサーバからメッセージを取り出す準備ができていることをメッセージＩＤ応答が示しているか否かを決定し、肯定された場合には、そこで、
メッセージサーバにメッセージ要求を送信することにより、メッセージサーバが計算機システムにメッセージを送信することを要求し、
メッセージサーバから送信されたメッセージを受信するように構成されている。
【００１６】
このシステムは、メッセージサーバからメッセージを配信する準備ができているか否かを決定することができる。これは、メッセージＩＤデータベースにメッセージＩＤ問い合わせを送信して、メッセージサーバ上にあるメッセージに関連するメッセージＩＤについて問い合わせることにより行われてもよい。メッセージＩＤデータベースにより返されるメッセージＩＤ応答は、例えば、メッセージサーバ上のメッセージを識別するメッセージＩＤを含む。これにより、計算機システムは、典型的には多数のメッセージを有するメッセージサーバに特定のメッセージを要求することができる。
【００１７】
計算機システムが、メッセージの配信準備ができているか否かを決定するためにメッセージサーバにではなくメッセージＩＤデータベースにコンタクトすることは、利点である。典型的には、計算機システムの使用者は、当該使用者がメッセージサーバからの配信の準備ができているメッセージの受信者であるか否かを頻繁に調べることを希望する。多くの実際のシナリオにおいて、使用者は、メッセージサーバでメッセージ（当該使用者を受信者とするメッセージを送信者が送信するときに利用可能となるメッセージ）が利用可能となるよりも更に頻繁に、メッセージＩＤ問い合わせを（計算機システムを介して）送る。換言すれば、大多数のメッセージＩＤ問い合わせは、配信の準備ができているメッセージがないことを示す可能性がある。この場合、メッセージサーバにメッセージ要求を送信することは無駄であり、本発明の第２態様によるシステムは、このような無駄な要求に関連する負荷を除去し、メッセージサーバがそのリソースをメッセージの受信と送信に割り当て、メッセージＩＤをメッセージＩＤデータベースにプッシュ送信するようにする。
【００１８】
この第２態様による計算機システムの或る実施形態では、メッセージＩＤ応答は、メッセージＩＤを含み、これは、メッセージサーバへのメッセージ要求において送信されたときに、メッセージサーバが特定のメッセージを見いだすために使用される。
【００１９】
本発明の第３態様では、送信計算機システムからの１又は複数のメッセージを処理する方法が提供され、この方法は、
メッセージサーバが、送信計算機システムから送信される１又は複数のメッセージの受信に応答して、受信された１又は複数のメッセージを識別する１又は複数のメッセージＩＤを提供するステップと、
メッセージサーバが１又は複数のメッセージＩＤの少なくとも１つをメッセージＩＤデータベースに送信するステップと、
メッセージＩＤデータベースが送信された少なくとも１つのメッセージＩＤを受信するステップとを含む。
【００２０】
この方法は、メッセージサーバからメッセージを取り出す準備ができていることを告知する手法を提供する。メッセージ識別子であるメッセージＩＤは、別個のデータベースであるメッセージＩＤデータベースで利用可能であり、したがって、計算機システムは、メッセージサーバで保持されるメッセージについての問い合わせを、メッセージサーバにコンタクトする必要なく、代わりにメッセージＩＤデータベースにコンタクトすることにより行ってもよい。
【００２１】
また、第３態様による方法の実施形態は、送信計算機システムが１又は複数のメッセージをメッセージサーバに送信するステップを含んでもよい。
【００２２】
少なくとも１つのメッセージＩＤをメッセージサーバからメッセージＩＤデータベースに送信するステップは、
メッセージサーバが送信計算機システムに少なくとも１つのメッセージＩＤを送信するステップと、
送信計算機システムが少なくとも１つのメッセージＩＤをメッセージＩＤデータベースに送信するステップとを含んでもよい。
【００２３】
この手法は、１又は複数のメッセージをメッセージサーバに送信するための接続が送信計算機システムとメッセージサーバとの間に確立されているので、有利である可能性がある。メッセージＩＤデータベースとの直接接続のような新しい接続を確立するためにメッセージサーバがこの時点でリソースを費やす必要がないので、この接続の再使用は効率的である。この負荷は、代わりに送信計算機システムに課せられる。
【００２４】
また、第３態様による方法の実施形態は、受信計算機システムがメッセージＩＤデータベースにメッセージＩＤ問い合わせを送り、これに対してメッセージＩＤデータベースがメッセージＩＤ応答を提供するステップを含んでもよい。ここで、メッセージＩＤ応答はメッセージＩＤデータベースに記憶されたメッセージＩＤに関する情報を含むものである。メッセージＩＤデータベースにより提供される情報は、例えば、最初メッセージサーバにより提供されてメッセージＩＤデータベースに配信されたメッセージＩＤを含んでもよい。さらなるステップでは、受信計算機システムは、メッセージサーバからメッセージを取り出す準備ができていることをメッセージＩＤ応答が示しているか否かを決定してもよい。これらのステップにより、受信計算機システムの使用者は、メッセージサーバが当該ユーザ宛てのメッセージを保有するか否かを決定できる。肯定された場合には、受信計算機システムはメッセージサーバにメッセージを要求し、そこでメッセージサーバは受信計算機システムに要求されたメッセージを送信することで応答することができる。
【００２５】
メッセージサーバからメッセージを取り出す準備ができていることをメッセージＩＤ応答が示す場合にのみ受信計算機システムがメッセージサーバにコンタクトすることは、利点である。取り出す準備ができたメッセージが存在しない場合、メッセージサーバにコンタクトしてメッセージを要求することは、実りが無く、かつメッセージサーバに不必要な負荷をかける。
【００２６】
受信計算機がメッセージサーバにメッセージを要求するステップでは、メッセージＩＤデータベースからの応答が複数のメッセージＩＤを示している（メッセージサーバにおいて数個のメッセージが利用可能であることを意味する）場合でも、受信者は或るメッセージだけを要求することを選択する可能性がある。これを行うためには、受信計算機システムは、或る基準に従ってメッセージＩＤをフィルタリングしてもよい。ここで、基準は、例えば送信者の指示に従って、又はメッセージサーバ自体で設定された基準により、メッセージサーバによりメッセージＩＤに組み込まれた、メッセージのサイズ、メッセージの生成からの経過時間、メッセージ重要度パラメータ、又は他のパラメータ等を含む。
【００２７】
また、受信計算機システムは、メッセージＩＤ応答において示されるメッセージＩＤを記憶してもよい。このメカニズムは、メッセージサーバに特定のメッセージを要求するか否かを決定するときに、受信計算機システムによりフィルタとして使用される。メッセージＩＤデータベースからのメッセージＩＤ応答に含まれるメッセージＩＤが、既に受信計算機システムがメッセージサーバに要求して受信したメッセージに対応する場合、受信計算機システムは、この対応するメッセージをメッセージサーバに要求しないことを選択してもよい。また、メッセージＩＤは、特定のメッセージをメッセージサーバから既に受信しているか否かを決定する際に受信計算機システムで容易に使用可能である限りにおいては、受信計算機システムにローカルに記憶するのではなく、別個のデータベースで記憶することができる。上記のようにメッセージＩＤをフィルタリングすることにより、メッセージの取り出しに関するメッセージサーバの負荷は、実用的な最小限度、すなわち受信計算機システムで従来は受信されなかったメッセージが伝送される程度まで軽減される。
【００２８】
或る場合には、同じメッセージを複数回取り出しうることが望ましい可能性がある。このことは、メッセージＩＤ応答において得られたメッセージＩＤがローカルに記憶されたメッセージＩＤに対応する場合に、これを受信計算機システムが無視することにより得られる。
【００２９】
好ましくは、ローカルに記憶されたメッセージＩＤとメッセージＩＤ応答から得られたメッセージＩＤとの比較が、受信計算機システムによって行われる。
【００３０】
本発明の第４態様では、受信計算機システムでメッセージを受信する方法が提供され、この方法は、
受信計算機システムが、メッセージＩＤデータベースにメッセージＩＤ問い合わせを送信するステップを含み、メッセージＩＤデータベースがメッセージＩＤを記憶してメッセージＩＤ問い合わせの受信に応答して受信計算機システムにメッセージＩＤ応答を送信するように構成されており、メッセージＩＤ応答がメッセージＩＤデータベースに記憶されたメッセージＩＤに関する情報を含み、
受信計算機システムがメッセージＩＤデータベースからメッセージＩＤ応答を受信するステップを含み、
メッセージサーバからメッセージを取り出す準備ができていることをメッセージＩＤ応答が示しているか否かを受信計算機システムが決定するステップを含み、メッセージサーバが受信計算機システムからのメッセージ要求の受信に応答して受信計算機システムにメッセージを送信するように構成されており、
メッセージサーバからメッセージを取り出す準備ができている場合、そこで、
受信計算機システムがメッセージサーバにメッセージ要求を送信してメッセージを要求し、
メッセージサーバがメッセージ要求の受信に応答して受信計算機システムにメッセージを送信し、
受信計算機システムがメッセージを受信する。
【００３１】
第４態様による方法の利点は、メッセージサーバからメッセージを取り出す準備ができていることをメッセージＩＤ応答が示している場合にのみ、メッセージサーバに受信計算機システムがコンタクトすることである。
【００３２】
第４態様による方法の或る実施形態では、受信計算機システムは、オプションとして、受信計算機システムがメッセージを要求して受信することを以前に行っていない場合にのみ、当該メッセージを要求してもよい。
【００３３】
第４態様の或る実施形態では、受信計算機システムがメッセージサーバに要求して受信したメッセージに関連するメッセージＩＤを記憶するステップを含んでもよい。受信されたメッセージに対応するメッセージＩＤを記憶することは、メッセージサーバにメッセージを要求するか否かを受信計算機システムが決定するためのメカニズムを提供する。メッセージＩＤ応答が、既に受信計算機システムに記憶されているメッセージＩＤを示す場合、受信計算機システムは、メッセージサーバにメッセージを要求しないことを選択してもよい。メッセージＩＤはメッセージＩＤ問い合わせにより取得可能であり、又はそれに代わって、メッセージＩＤは、受信計算機システムからのメッセージ要求の受信に応答して対応するメッセージをメッセージサーバが配信するときに、メッセージサーバにより受信計算機システムに提供されてもよい。
【００３４】
メッセージＩＤデータベースを提供するために任意の種類のデータベース構造が使用され得るが、本発明による方法とシステムのメッセージＩＤデータベースは、好ましくは、ピアツーピアデータベースのような分散型特性を有するものである。このようなデータベースは、集中化したメンテナンスを余り必要としない。また、メッセージＩＤデータベースは、集中化されたデータベースでもよい。また、メッセージＩＤデータベースは、部分的にのみ分散化されていてもよい。
【００３５】
メッセージＩＤ問い合わせをメッセージＩＤデータベースに送ろうとするときに問題が発生すると、受信計算機システムは、代わりに、バックアップ手段として特別に、メッセージＩＤ問い合わせをメッセージサーバ自体に向けて送ってもよい。また、意図的にメッセージサーバに直接問い合わせをしてもよい。このようなメッセージサーバ自体への問い合わせは、頻繁でないことが好ましく、例えば２４時間毎に１回である。
【００３６】
好ましくは、メッセージＩＤデータベースのリソースとメッセージサーバのリソースは、少なくとも部分的には相互に独立しており、これは各システムが固有の専用ネットワークリソース及び／又は処理リソースを有することを意味する。好ましいのは、リソースが完全に独立していることである。換言すれば、メッセージＩＤデータベースとメッセージサーバとは、分離したシステムである。
【００３７】
本発明は、例えば、専用ソフトウエアを使用して適切に適合されたハードウエア計算機システムで実施される。これに関連して、「適切に適合された」とは、ＣＰＵ、コントローラ、メモリ、ネットワークアダプタ及び／又は他の構成要素のような必要なハードウエア構成要素が、ソフトウエアを実行するハードウエア計算機システムの部品として提供されていることを意味する。また、本方法を実行するための命令は、ＡＳＩＣのようなハードウエアで直接的に実装することができ、又は、ハードウエアで実装された部品とソフトウエアで実装された部品との組合わせで実行することができる。本発明による１又は複数の方法を実行できるシステムを達成する他の解決策も存在する。
【発明を実施するための最良の形態】
【００３８】
図１は、本発明のメッセージ配信システムの実施形態を示す。これは、クライアントＡと呼ばれる第１計算機システム１０２、クライアントＢと呼ばれる第２計算機システム１０４、メッセージサーバ１２０及びメッセージＩＤデータベース１３０を備えている。使用者ＡはクライアントＡ１０２を操作し、使用者ＢはクライアントＢ１０４を操作する。クライアントＡ及びＢ（１０２、１０４）は、メッセージサーバ１２０に動作可能に接続１１５される。また、クライアントＡ及びＢ（１０２、１０４）は、メッセージＩＤデータベース１３０に動作可能に接続１２５される。更にまた、メッセージサーバ１２０は、メッセージＩＤデータベース１３０に動作可能に接続１２５される。更に、システムは、メッセージサーバ１２０及び／又はメッセージＩＤデータベース１３０へのクライアントＡとクライアントＢのアクセスを制御するシステム構成要素を備えてもよい。インスタントメッセージシステム、ボイスオーバアイピーシステム及びビデオオーバアイピーシステムは、典型的には、システムの各個人使用者に関する使用者識別情報を典型的には識別符号及び確認符号の形態で含む認証機関を用いている。使用者識別情報の完全性を維持するために、メッセージ配信システムのプロバイダは、典型的には、大部分が集中化されて厳格に管理されているシステムに使用者識別情報を記憶する。また、使用者識別情報の一部は、メッセージＩＤの中と、メッセージＩＤデータベース問い合わせの中にあってもよい。このような特徴は、本発明のシステムと方法に含まれ得る。
【００３９】
メッセージサーバ１２０とメッセージＩＤデータベース１３０は、使用者Ａから使用者Ｂへのメッセージ配信の過程でメッセージとメッセージＩＤを処理する。メッセージサーバ１２０は、使用者Ａと使用者Ｂとの間のメッセージの受信と配信を管理し、直接又はクライアントＡ１０２経由のいずれかで、メッセージＩＤをメッセージＩＤデータベース１３０に配信する。メッセージＩＤデータベース１３０は、メッセージサーバ１２０及び／又はクライアントＡ１０２とメッセージＩＤを交換する。これは、また、クライアントＢ１０４からの問い合わせを処理し、適切な応答を返す。
【００４０】
図２は、クライアント計算機システムのアーキテクチャ２００、例えばクライアントＡ１０２、の単純化した例を示す。これは、中央処理装置（ＣＰＵ）２０２、メモリ２０３、ハードディスク２０４、ネットワークインターフェイス２０６、ならびにキーボード２０７及びマイクロホン２０８等のユーザインターフェイスのような、多数の構成要素を備える。これらの構成要素は、コントローラ（バス）２０１を介して相互接続されている。ＣＰＵ２０２は、構成要素２０２〜２０８を論理的に制御する。メモリ２０３は、一時的情報及び永久的情報の双方を保持する。メモリ２０３は、例えば、クライアント１０２がメッセージを処理できるようにする命令を保持し、種々の構成要素やコントローラ２０１〜２０８の間で交換されるデータと共にメッセージを保持する。
【００４１】
メッセージは、種々の方法で提供される。例示すると、これは、ユーザインターフェイスを介して、例えばキーボード２０７若しくはマイクロホン２０８を介して、又はＤＶＤ、ＣＤ−ＲＯＭ、ＵＳＢにより制御されるメモリ等のようなメディア２０５を介して、入力される。他の方法も使用可能であり、例えば携帯機器から計算機システム２００へのネットワークインターフェイス２０６を介する無線通信を用いる。
【００４２】
ハードディスク２０４は、例えば、メッセージ、ＣＰＵ２０２に対する命令（ソフトウエア）、一時的情報、オペレイティングシステム情報等を保持する。
【００４３】
ネットワークインターフェイス２０６は、例えば、クライアント２００にメッセージを提供するために使用されてもよく、メッセージサーバ１２０とメッセージＩＤデータベース１３０へのネットワーク接続の形成と維持に使用される物理的構成要素でもよい。
【００４４】
また、図２は、メッセージサーバ１２０とメッセージＩＤデータベース１３０の典型的なアーキテクチャを例示しており、これらは、メッセージ配信システムにおけるその機能に従って機能するように同様の構成要素のうちの多数のものを必要としている。携帯装置としてのクライアント、例えばクライアントＡ１０２に内蔵電源を備えることが有利である。また、計算機システム２００を動作可能にするための管理用ソフトウエアは、２０４のようなハードディスクに記憶して２０３のようなメモリにロードするのではなく、ＡＳＩＣのようなハードウエアとして直接実装することが望ましい可能性がある。多くの実装においては、ハードディスク２０４は、絶対に不可欠である。
【００４５】
分散型のメッセージＩＤデータベースは、典型的には、図２のタイプのシステムであって、例えばハードディスクの形態で大きな記憶容量をそれぞれ有している多数のシステムからなる複合体である。
【００４６】
図３ａ及び図３ｂは、メッセージサーバのメッセージデータベースｍＤＢ３３０がアクセスされる態様の２つの例を示している。図３ａでは、クライアントＡ１０２は、単一のフロントエンドＦＥ３１１を介してメッセージデータベース３３０にアクセスする。単純化のために、メッセージデータベース３３０は、図２に含まれているもののようなコントローラや他の構成要素なしに、１つの機能構成要素として示されている。図３ａでは、クライアントＡはメッセージデータベースへの唯一のエントリポイント、すなわち図示されているようにメッセージデータベース３３０に動作可能に接続されているＦＥ３１１、を有している。多くのクライアントが同時にメッセージデータベース３３０へのアクセスを希望すると、エントリポイントＦＥ３１１は、その能力を超えて負荷がかかり、機能しなくなる可能性がある。図３ｂは、３個のフロントエンド、すなわちＦＥ１（３２１）、ＦＥ２（３２２）及びＦＥ３（３２３）の使用を例示している。そして、クライアントＡ１０２は、３個のフロントエンド３２１〜３２３からエントリポイントをランダムに選択することができる。これは、各フロントエンド３２１〜３２３にかかる負荷を分散して減少させ、一つのフロントエンド、例えば３２３、が故障した場合に他のフロントエンド３２１と３２２がメッセージデータベース３３０へのアクセスを保証する。この目的のために、クライアント、例えばクライアントＡ、は、フロントエンドのアドレスリストを有してもよく、これからランダムに選択する。
【００４７】
また、典型的な構成では、フロントエンドは認可システム（図示せず）にも接続される。認可システムは、例えばクライアントＡから提供される認可情報と認可データベースからの認可データとを比較することにより、メッセージデータベースへのクライアントのアクセスを管理するために使用される。メッセージＩＤの問い合わせがメッセージサーバ自体に向けて送られる従来技術のシステムでは、認可は、問い合わせ毎に必要とされる。メッセージＩＤの問い合わせが、メッセージサーバ自体に向けてではなく、メッセージサーバとは別個のメッセージＩＤデータベースに向けて送られることは、本システムの利点である。メッセージＩＤデータベースにおけるメッセージＩＤ等の情報が使用者の個人情報を含まないのであれば、このようなシステムでのセキュリティの確保を多少簡単化することができる。
【００４８】
主に非集中化されたリソースのシステムであるピアツーピアデータベースのような分散型メッセージＩＤデータベース１３０を使用することは、特に有利である。ピアツーピアデータベースは、集中度が低下したメンテナンスを必要とし、アクティブなクライアントの数と共に成長し、アクセス負荷（例えばＣＰＵ負荷及びネットワーク負荷）は、集中化されたシステムにかかるのではなく、複数のクライアントに分散される。
【００４９】
図４は、メッセージが送信者である使用者Ａから受信者である使用者Ｂに配信される過程の最初の部分を示している。最初に、使用者Ａは、メッセージを生成する（ステップ４０１）。これは、キーボードを用いて入力されるテキストのメッセージであってもよく、又はマイクロホンで記録される音声メールでもよい。また、メッセージは、実行可能なファイルとすることができる。メッセージの種々の例は、本明細書内で前述した。実行可能なファイルは、ハードディスクから、ＤＶＤから、無線ネットワーク接続又は他のリソースを介して得ることができる。そして、使用者Ａの計算機システムであるクライアントＡは、ステップ４０２で、メッセージをメッセージサーバ（「ｍＳｅｒｖ」）に送信する。メッセージサーバは、メッセージを受信し（ステップ４０３）、対応するメッセージＩＤ（「ｍＩＤ」）を生成する。メッセージサーバはメッセージとメッセージＩＤをメッセージデータベース（「ｍＤＢ」、図３も参照）に記憶する（ステップ４０４）。そして、メッセージサーバはメッセージＩＤをクライアントＡに送信し（ステップ４０５）、クライアントＡはメッセージＩＤをメッセージＩＤデータベース（「ｍＩＤ−ＤＢ」）に送信する（ステップ４０６）。この時点（状態４０７）で、使用者Ｂは、メッセージＩＤデータベースに問い合わせすることが可能であり、当該使用者Ｂがステップ４０２で送信されたメッセージの受信者であることを見いだす。この方法の変形では、ステップ４０５及び４０６は、メッセージサーバがメッセージＩＤを直接メッセージＩＤデータベースに送るステップ（不図示）で置き換えることができる。しかし、この過程は、新たなネットワーク接続、すなわちメッセージサーバとメッセージＩＤデータベースとの間の接続、を確立しなければならず、非効率である。図４の方法は、ステップ４０２と４０３で有効に確立された既存の接続を用いている。メッセージＩＤをメッセージＩＤデータベースに送信するのに要するリソースは、メッセージサーバによってではなくクライアントＡにより提供されている。
【００５０】
図５は、送信者である使用者Ａから受信者である使用者Ｂへメッセージを配信する過程の他の部分を示す。使用者Ｂは、当該使用者Ｂが１又は複数のメッセージの受信者であるか否かを決定することを望む。使用者ＢのクライアントであるクライアントＢ１０４は、例えば、毎秒１回というような所定の頻度でメッセージＩＤデータベースに問い合わせすることを指示され得る。他の仕組み又は付加的な仕組みもあり得る。例えば、使用者Ｂは、メッセージＩＤデータベースに問い合わせを送信するよう、クライアントに手動で指示してもよい。エントリポイント５０１は、メッセージＩＤデータベース１２０に問い合わせを送信するように使用者Ｂがそのクライアントに手動で命令することを表現している。エントリポイント「Ｔ」（５１１）は、他のトリガメカニズムを表すシンボルである。使用者Ｂの計算機システムであるクライアントＢは、例えば、毎秒問い合わせを送信するよう管理用ソフトウエアにより指示されていてもよい。ステップ５０２では、クライアントＢは、メッセージＩＤデータベース（「ｍＩＤ−ＤＢ」）へ問い合わせを送信する。メッセージＩＤデータベースは、問い合わせを受信し（ステップ５０３）、応答を生成し（ステップ５０４）、クライアントＢに送信する。クライアントＢは、応答を受信し、分析する（ステップ５０５）。クライアントＢは、応答を分析し、メッセージサーバ（「ｍＳｅｒｖ」）に自己宛てのメッセージがあるか否かを決定し（ステップ５０６）、このようなメッセージの特性、例えばメッセージのサイズ、生成からの経過時間、重要性等、を決定する。オプションとして、クライアントＢは、所定の判断基準により選択され、例えば前記特性に関連する一部の未配信メッセージだけを要求してもよい。この分析に基づいて、クライアントＢは、ステップ５０７でメッセージサーバにメッセージを要求する。ステップ５０８で、メッセージサーバは、要求されたメッセージを収集し、クライアントＢに送信する。最後に、状態５０９では、使用者Ｂは、使用者Ａにより当該使用者Ｂ宛てに生成されたメッセージを保有している。クライアントＢがメッセージサーバ１２０にコンタクトしないと決定した場合には、経路５１２に進み、使用者Ｂがシステムにメッセージチェックを指示する（エントリポイント５０１）か、又は使用者Ｂがトリガイベントを待つ（エントリポイント５１１）かを待つことになる。また、システムは、５１３で示されている更新を行うことができる。
【００５１】
図６は、図６の５１３のような更新を示しており、これは、メッセージがクライアントＢに配信された後にシステムにおいて行われる。メッセージサーバは、例えば、クライアントＢに配信されたメッセージをメッセージデータベースから削除してもよい（ステップ６０２）。配信済のメッセージを削除することにより、記憶リソースを解放する。クライアントＢがメッセージＩＤをローカルに記憶する方法では、クライアントＢは、ローカルに記憶されたメッセージＩＤを削除することを選択してもよく、代わりに、最新の問い合わせに対するメッセージＩＤデータベース１３０の応答に含まれていたメッセージＩＤを記憶してもよい（ステップ６０３）。これによりシステムは更新された状態６０４となる。
【００５２】
本発明によるメッセージ配信を以下の例により示す。ダンが、特定の状況で、メアリに挨拶することを希望する。しかし、その状況でメアリが多忙であって手が空いていないので、ダンは代わりにメアリのご多幸を願う音声メッセージを残す。ダンは、メアリ宛てのメッセージｍ１を作成する。ダンは、メッセージを記録するためにマイクロホン（図２に２０８として例示）を使用する。メッセージの記録後、彼の計算機システムであるクライアントＡ１０２は、メッセージサーバ１２０に接続し、メッセージｍ１を送信する。メッセージｍ１の受信後、メッセージサーバ１２０は、メッセージを識別するメッセージＩＤ「ｍ１−ＩＤ」を形成する。メッセージＩＤ「ｍ１−ＩＤ」は、図７に示されている。そして、メッセージサーバ１２０は、メッセージとメッセージＩＤを記憶する。この例では、メッセージＩＤ７１０は、受信者（メアリ）の識別標示７１１と送信者（ダン）の識別標示７１２を含む。更に、メッセージＩＤは、メッセージサーバが受信したメアリを受信者とするメッセージの数を示すメッセージ番号７１３を含む。メッセージサーバが先に１６個のメッセージを受信していると、メッセージＩＤ７１０は、メッセージ番号表示「１７」を含み得る。そして、メッセージサーバは、メッセージＩＤをクライアントＡに送信し、クライアントＡは、メッセージＩＤをメッセージＩＤデータベースに送信する。本例では、メッセージＩＤは、更にメッセージのサイズ７１４を含む。
【００５３】
この時点でメアリが彼女の計算機システムであるクライアントＢにメッセージＩＤデータベース１３０に対する問い合わせを送信させてメッセージをチェックすると、例えばメッセージＩＤ７１０自体の形式で、メッセージＩＤデータベース１３０から応答を受信する。クライアントＢは、メッセージＩＤを分析し、メッセージ番号タグが「１８」であることを見いだす。そうすると、クライアントＢは、メッセージサーバ１２０とのコンタクトを行って対応するメッセージｍ１を要求し、このときにメッセージサーバ１２０はメッセージｍ１を配信する。ここでメアリはダンの音声メッセージを受信する。
【００５４】
メッセージサーバ１２０がメアリへのメッセージを保有していない時にメアリがメッセージＩＤデータベースに問い合わせを送信すると、彼女は、空の応答を受信し、その結果、引き続いてメッセージサーバ１２０にコンタクトすることはしない。それ故、メアリは、取り出すべきメッセージが存在する場合にのみメッセージサーバ１２０に負荷をかける。
【００５５】
他の例では、システムの第３の使用者マークがメアリへのメッセージｍ２の送信を希望する。この例では、マークは、ダンがメッセージｍ１を送信した後にメッセージを送信する。マークはメッセージを生成し、彼のクライアントであるクライアントＣはメッセージサーバ１２０にメッセージを送信する。マークは、テキストメッセージをメアリに送信することを希望する。彼は、計算機システムのキーボードを用いてメッセージを形成する。そうすると、クライアントＣは、メッセージサーバ１２０に接続し、メッセージｍ２を送信する。メッセージｍ２を受信した後、メッセージサーバ１２０は、対応するメッセージＩＤであるｍ２−ＩＤ（図７の７２０）を形成し、メッセージｍ２とメッセージＩＤ「ｍ２−ＩＤ」を記憶する。この時点でメッセージサーバは既にメアリの代理として１８個のメッセージを受信しており、その結果、メッセージＩＤ「ｍ２−ＩＤ」７２０は、図７の７２３で示されるように、メッセージ番号表示「１９」を含む。そして、メッセージサーバは、メッセージＩＤ「ｍ２−ＩＤ」７２０をクライアントＡに送信し、クライアントＡはメッセージＩＤデータベース１３０に送信する。メアリが、彼女の計算機システムであるクライアントＢ１０４にメッセージＩＤデータベースへの問い合わせを送信させることによりメッセージをチェックすると、新たなメッセージＩＤであるｍ２−ＩＤを受信する。先の例と同様に、クライアントＢ１０４は、対応するメッセージ、この場合はｍ２、をメッセージサーバ１２０に要求し、受信する。
【００５６】
メアリが、メッセージＩＤ「ｍ１−ＩＤ」及び番号表示「１８」（７１３）に関連付けられたメッセージを未だ取り出していない場合には、メッセージＩＤデータベース１３０は、代わりに２個のメッセージＩＤ、すなわちｍ１−ＩＤ７１０とｍ２−ＩＤ７２０、を用いて応答する。そして、クライアントＢ１０４は処理を続けて、メッセージサーバ１２０にｍ１とｍ２の双方を要求する。
【００５７】
図７の７１４で示されるように音声メッセージｍ１が比較的大きい場合には、メアリは、７２４で示される、より小さなサイズを有するテキストメッセージのみの取得を望むかも知れない。メアリが使用している図１の１１５で示されるようなネットワーク接続は、音声メッセージｍ１を取り出すために膨大な時間を要する可能性がある。クライアントＢ１０４がメッセージＩＤデータベース１３０からの応答を分析すると、現在のネットワーク接続を介して取り出すにはメッセージｍ１が大きすぎることがメッセージサイズ要素から分かる。メアリのクライアントであるクライアントＢ１０４は、ネットワーク接続速度を試験することにより、メッセージサーバ１２０からメアリのクライアント１０４へｍ１を送信するのに要する時間の見積もりを自ら出す。メアリは取り出し時間が許容可能なものか決定することができ、又はクライアントＢ１０４は、メアリの代理として、ソフトウエアの命令により、メッセージがその時点で取り出すには大きすぎるということを決定する。そして、クライアントＢ１０４は、メッセージＩＤ「ｍ１−ＩＤ」を、未だこのメッセージを取り出していないことを示すために、記憶する。クライアントＢ１０４は、メッセージｍ１でなく、ｍ２だけを要求する。後に、メッセージｍ１を取り出す時間が許容可能となる程度にネットワーク接続速度が高くなったときに、クライアントＢ１０４は、このメッセージを要求してもよい。一旦メッセージが取り出されると、クライアントＢ１０４は、対応するメッセージＩＤ「ｍ１−ＩＤ」７１０を削除してもよい。他の実施例では、クライアントＢ１０４は同様にｍ１−ＩＤ７１０とｍ２−ＩＤ７２０をメッセージＩＤデータベース１３０から取り出すが、クライアントＢ１０４は、今度は代わりに、ｍ１−ＩＤ７１０を記憶し続けてｍ２−ＩＤ７２０を削除するようにメッセージＩＤデータベース１３０に指示する。クライアントＢ１０４が後にメッセージＩＤデータベース１３０に問い合わせすると、メッセージＩＤデータベース１３０からの応答は、再びｍ１−ＩＤ７１０を含んでおり、そこでクライアントＢ１０４は、対応するメッセージをメッセージサーバ１２０に要求するか、又は後の取り出しのためにもう一度そこに残しておくかを、もう一度決定することができる。
【００５８】
他の実施例では、メッセージＩＤデータベース１３０は、最新のメッセージＩＤだけを保持し、メッセージサーバにメッセージが無い場合にはメッセージＩＤを保持しない。上記の例では、メッセージＩＤ「ｍ１−ＩＤ」７１０は、一旦メッセージサーバ１２０が第２メッセージｍ２を受信すると、ｍ２−ＩＤ７２０によって置き換えられる。この場合には、クライアントＢ１０４は、問い合わせへの応答としてｍ２−ＩＤ７２０だけを受信する。メッセージサーバ１２０に要求を出すと、メッセージサーバ１２０は、ｍ２−ＩＤ７２０を表示情報として用い、全ての残っているメッセージを収集する。ｍ１もｍ２も取り出されていないので、メッセージサーバ１２０は、クライアントＢ１０４からの要求に応答してｍ１とｍ２の双方を提供する。メッセージの取り出し後、メッセージＩＤデータベース１３０は、最新のメッセージＩＤ、この場合はｍ２−ＩＤ７２０を削除する。例えば、クライアントＢ１０４からの指示により、そのように動作してもよい。次回にメアリのクライアントであるクライアントＢ１０４がメッセージＩＤデータベース１３０に問い合わせを送信したときには、メアリへのメッセージが存在しないことを示す表示情報を受信する。このように、クライアントＢ１０４は、メッセージサーバにコンタクトしない。
【００５９】
他の実施例では、メッセージＩＤデータベース１３０は、常に最新のメッセージＩＤを保持する。上記の例では、メッセージＩＤデータベースは、最初にｍ１−ＩＤ７１０を保持する。ｍ２を受信すると、メッセージサーバ１２０は、ｍ２−ＩＤ７２０を作成してメッセージＩＤデータベース１３０に送信し、メッセージＩＤデータベース１３０はｍ１−ＩＤ７１０をｍ２−ＩＤ７２０で置き換える。クライアントＢ１０４は、メッセージＩＤデータベース１３０に問い合わせしたとき、常にメッセージＩＤを受信する。一例として、メッセージＩＤデータベース１３０は、メッセージサーバ１２０がクライアントＢからのメッセージｍ１を受信する前のメッセージ番号表示「１６」を有するメッセージＩＤを保持しているかも知れない。メッセージＩＤデータベース１３０へのクライアントＢ１０４の前回の問い合わせにより、クライアントＢ１０４は、メッセージｍ０に対応するメッセージＩＤ「ｍ０−ＩＤ」を与えられている。換言すれば、ｍ０−ＩＤのメッセージ番号表示は「１６」である。クライアントＢ１０４がメッセージＩＤデータベース１３０からメッセージＩＤを受信したとき、対応するメッセージｍ０をメッセージサーバ１２０に要求して受信している。同時に、クライアントＢ１０４はメッセージＩＤ「ｍ０−ＩＤ」をローカルに記憶している。メッセージサーバ１２０がｍ１を受信し、ｍ１−ＩＤ７１０を生成し、ｍ１−ＩＤ７１０をメッセージＩＤデータベース１３０に送信してｍ０−ＩＤを置き換えた後、クライアントＢ１０４からメッセージＩＤデータベース１３０へ問い合わせすると、メッセージサーバにより受信された最新のメッセージがメッセージ番号「１７」を持っていることを示す応答がクライアントＢ１０４に送られる。この時点でクライアントＢ１０４はメッセージＩＤ「ｍ０−ＩＤ」をローカルに記憶しているので、メッセージサーバに取り出し準備ができている新しいメッセージがあると推定する。それ故、クライアントＢ１０４は、メッセージサーバ１２０にコンタクトし、メッセージｍ０をメッセージサーバ１２０に要求して受信する。そして、クライアントＢ１０４は、前にローカルに記憶したメッセージＩＤ「ｍ０−ＩＤ」を最も新しいメッセージＩＤ、ここではｍ１−ＩＤにより置き換える。ｍ１とｍ２の双方のメッセージをメッセージサーバ１２０で受信し、更なるメッセージを受信しなかった場合、メッセージＩＤデータベース１３０のメッセージＩＤは、ｍ２−ＩＤとなる。クライアントＢ１０４がメッセージ番号「１６」のメッセージのみを取りだしている場合、ローカルに記憶されているメッセージＩＤは、ｍ０−ＩＤである。メッセージＩＤデータベース１３０に問い合わせすると、ｍ２−ＩＤが返される。ローカルに記憶されたメッセージＩＤとメッセージＩＤデータベース１３０のメッセージＩＤが異なるので、クライアントＢ１０４は、メッセージサーバ１２０にメッセージを要求する。メッセージサーバ１２０は残っているメッセージ、ここではｍ１とｍ２を収集し、クライアントＢ１０４へ配信する。そして、クライアントＢ１０４は、ｍ２−ＩＤ等をローカルに記憶する。
【００６０】
図８は、他のタイプのメッセージＩＤを示す。図７に示したメッセージＩＤでは、表示情報７１３と７２３は、メッセージサーバ１２０が受信者、この場合はメアリ、の代理として受信したメッセージの合計の個数を示している。図８のメッセージＩＤは、代わりにグローバルメッセージ番号を含んでいる。メッセージサーバは、メアリの代理としてだけでなく、ダン、マーク及び他のシステム使用者の代理としてもメッセージを受信する。図８に示したメッセージＩＤは、図７に示したものと比較して重要な利点を有している。図７のタイプのメッセージＩＤを用いると、メッセージサーバは、システム使用者のそれぞれについて、当該使用者の代理として受信済みのメッセージ番号の情報を含むデータベースを保持しなければならない。図８のメッセージＩＤを用いると、メッセージサーバは、システムの全使用者の代理として受信したメッセージの合計の個数を計数するだけでよい。
【００６１】
図８は、このメッセージＩＤ構造を用いた場合にメアリへの２つのメッセージＩＤがどのようになるかを示している。以下の例で、このメッセージＩＤ構造を用いてメッセージがどのように配信されるかを説明する。この例は、上記の例と同じシナリオに基づいている。
【００６２】
ダンが、特定の状況で、メアリに挨拶することを希望する。しかし、その状況でメアリが多忙であって手が空いていないので、ダンは代わりにメアリのご多幸を願う音声メッセージを残す。ダンは、メアリ宛てのメッセージｍ４を作成する。ダンは、メッセージを記録するためにマイクロホン（図２に２０８として例示）を使用する。メッセージの記録後、彼の計算機システムであるクライアントＡ１０２は、メッセージサーバ１２０に接続し、メッセージｍ４を送信する。メッセージｍ４の受信後、メッセージサーバ１２０は、メッセージを識別するメッセージＩＤ「ｍ４−ＩＤ」を形成する。図７に示されている「ｍ１−ＩＤ」７１０のタイプのメッセージＩＤを形成する代わりに、メッセージサーバ１２０は、ここでは図８に８１０で示されるｍ４−ＩＤを生成するように構成されている。そして、メッセージサーバ１２０は、メッセージとメッセージＩＤを記憶する。この例では、メッセージＩＤ８１０は、先の例のように、受信者（メアリ）の識別標示８１１と送信者（ダン）の識別標示８１２を含む。また、メッセージＩＤは、メッセージサーバが全使用者の代理として受信したメッセージの合計の個数を示すグローバルメッセージ番号８１３を含む。メッセージサーバがダンのメッセージｍ４の受信の前に例えば１４０５０３個のメッセージを受信していると、ｍ４に対するメッセージＩＤ「ｍ４−ＩＤ」８１０は、グローバルメッセージ番号８１３の表示「１４０５０４」を含むように形成される。そして、メッセージサーバは、メッセージＩＤをクライアントＡ（ダンの計算機システム）に送信し、クライアントＡはメッセージＩＤをメッセージＩＤデータベースに渡す。本例では、メッセージＩＤは、先の例のように、更に８１４で表示されるメッセージのサイズを含む。
【００６３】
この時点でメアリが彼女の計算機システムであるクライアントＢにメッセージＩＤデータベース１３０に対する問い合わせを送信させてメッセージをチェックすると、例えばメッセージＩＤ「ｍ４−ＩＤ」８１０自体の形式で、メッセージＩＤデータベース１３０から応答を受信する。このタイプのメッセージＩＤを用いていると、クライアントＢは、新たなメッセージが到来したか否かを決定するために、受信した最新のメッセージＩＤを記憶する必要がある。メアリの計算機システムがメッセージＩＤ応答として受信したばかりのメッセージＩＤ８１０を分析すると、グローバルメッセージ番号が「１４０５０４」であることを見いだす。メアリがグローバルメッセージ番号、例えば「５０２７２」のメッセージを先に受信している場合、彼女のクライアントであるクライアントＢは、メッセージＩＤデータベースにおいて今メアリのために記憶されている（そしてメッセージＩＤ応答を介してクライアントＢに送信されている）メッセージＩＤのグローバルメッセージ番号が、メアリのクライアントであるクライアントＢにローカルに記憶されているものと異なることを見いだす。したがって、クライアントＢは、メッセージサーバ１２０とのコンタクトに移行し、応答によって明示されたメッセージＩＤ、すなわちｍ４−ＩＤ８１０に対応するメッセージを要求することができる。これに応答して、メッセージサーバ１２０は、メッセージｍ４を配信し、ここでメアリはダンの音声メッセージを受信する。
【００６４】
メッセージサーバ１２０がメアリへのメッセージを保有していない時にメアリがメッセージＩＤデータベースに問い合わせを送信すると、彼女に宛てた新たなメッセージが存在しないのでメッセージＩＤデータベースでメアリ用に記憶されたメッセージＩＤが変更されていないため、彼女は、彼女の計算機システムでローカルに記憶された番号、この例では上記のように「５０２７２」、に等しいグローバルメッセージ番号を受信する。それ故、彼女のクライアントがその後不必要にメッセージサーバ１２０にコンタクトして負荷をかけることはない。
【００６５】
ここで、先の例（図７のタイプのメッセージＩＤが使用されている場合）のように、システムの第３の使用者マークがメアリへのメッセージｍ５の送信を希望する。前と同様、マークは、ダンがメッセージｍ４を送信した後にメッセージを送信する。マークはメッセージｍ５を生成し、彼のクライアントであるクライアントＣはメッセージサーバ１２０にメッセージを送信する。マークは、テキストメッセージをメアリに送信することを希望する。彼は、計算機システムのキーボード（図２の２０７）を用いてメッセージを形成する。そうすると、クライアントＣは、メッセージサーバ１２０に接続し、メッセージｍ５を送信する。メッセージｍ５を受信した後、メッセージサーバ１２０は、対応するメッセージＩＤであるｍ５−ＩＤ（図８の８２０）を形成し、メッセージｍ５とメッセージＩＤ「ｍ５−ＩＤ」を記憶する。本例のタイプのメッセージＩＤのメッセージ番号はグローバルメッセージ番号であるので、ダンがメッセージ（ｍ４）を送ったときとマークがメッセージ（ｍ５）を送ったときとの間で受信する任意のメッセージは、グローバルメッセージ番号に算入され、これは、ダンのメッセージｍ４のメッセージＩＤ「ｍ４−ＩＤ」が形成されるときには「１４０５０４」になる。グローバルメッセージ番号は、例えばマークのクライアントであるクライアントＣがメッセージサーバ１２０にマークのメッセージｍ５を送る時点では、「１５１００４」である。マークのメッセージがメッセージサーバ１２０で受信されるとき、図８の８２３で示されるように、グローバルメッセージ番号「１５１００５」が割り当てられる。そして、メッセージサーバは、メッセージＩＤ「ｍ５−ＩＤ」８２０をマークの計算機システムであるクライアントＣに送信し、クライアントＣはメッセージＩＤデータベース１３０に渡す。メアリが彼女の計算機システムであるクライアントＢ１０４にメッセージＩＤデータベースへの問い合わせを送信させることによりメッセージをチェックすると、その応答をクライアントＢで分析することにより、メッセージＩＤにおいて表示されるグローバルメッセージ番号がこのとき「１５１００５」であり、これは、既にダンからのメッセージｍ４を取り出している場合に彼女の計算機システムでローカルに記憶されている番号「１４０５０４」と異なっていることが分かる。クライアントＢ１０４は、対応するメッセージ、この場合はｍ５、をメッセージサーバ１２０に要求し、受信する。
【００６６】
メアリがメッセージＩＤデータベースにおいてグローバルメッセージ番号「１５１００５」を見いだす前にメッセージｍ４を未だ取り出していない場合には、彼女のローカルに記憶されたメッセージＩＤは未だ「５０２７２」であり、メッセージサーバは、代わりに、メアリ宛ての全てのメッセージ、この場合はｍ４とｍ５の双方、を収集して配信することによりメアリからのメッセージ要求に応答する。そして、彼女の計算機システムであるクライアントＢは、ｍ５が受信した最後のメッセージであることを示すために、ｍ５−ＩＤをローカルに記憶する。
【００６７】
当然のことながら、図面は、本発明の或る実施形態だけを示している。本システムと本方法は、特許請求の範囲内で多くの手法によって変更することができるが、また、明細書に示されたものと異なるように構成されたフローチャートで図示することもできる。
【００６８】
当業者は、また、記載されたタイプのメッセージＩＤを無数の手法で変更できることが分かる。当然のことながら、用語「メッセージＩＤ」の使用は、メッセージサーバで形成されるようなメッセージＩＤに対する変更や改造を含んでいる。例えば、メッセージＩＤは、メッセージサーバで用意された原情報の或るものを削除してもよい。そのような変形や修正は、修正されたメッセージＩＤが、メッセージ要求においてメッセージサーバに呈示される場合に、元の（未修正の）メッセージＩＤに対応するメッセージをメッセージサーバで識別させられる限り、特許請求の範囲内のものとなる。
【図面の簡単な説明】
【００６９】
【図１】図１は、メッセージサーバ、メッセージＩＤデータベース、第１計算機システム及び第２計算機システムを備えたメッセージ配信システムを示す。
【図２】図２は、単純化した計算機システムアーキテクチャを示す。
【図３ａ】図３ａは、フロントエンドを有するメッセージサーバを示す。
【図３ｂ】図３ｂは、多数のフロントエンドを有するメッセージサーバを示す。
【図４】図４は、第１使用者が第２使用者に向けてメッセージを生成した後、メッセージサーバ及びメッセージＩＤデータベースを備えたシステムがどのように準備段階の動作を行うかを示すフローチャートである。
【図５】図５は、メッセージデータベースから取り出すべきメッセージの有無を決定するために使用者がシステムにどのように問い合わせするかを示すフローチャートである。
【図６】図６は、メッセージサーバからメッセージを取り出した後、システムの一部がどのように更新されるかを示す。
【図７】図７は、メッセージＩＤの例を示す。
【図８】図８は、メッセージＩＤの他の例を示す。
【誤訳訂正３】
【訂正対象書類名】図面
【訂正対象項目名】図６
【訂正方法】変更
【訂正の内容】
【図６】
2009516885.tif 000001