(57)【要約】  各購読要求がそれぞれの購読者クライアントから受信され、かつそれぞれのチャネルのためのものである１又は２以上の購読要求を受信する段階と、各認可された購読要求が、要求の購読者クライアントがチャネルに発行されたメッセージを受信することを許可する購読要求の１又は２以上を認可する段階と、各メッセージがそれぞれの発行者クライアントから受信され、かつそれぞれのチャネル上での発行のためのものである発行のための１又は２以上のメッセージを受信する段階と、メッセージの各々に対して、バッファに関する有限有効期間中にバッファに存在するメッセージをメッセージのチャネルのためのそれぞれのバッファに入れる段階と、バッファの１又は２以上に対して、認可された購読者クライアントにバッファ内のあらゆるメッセージを送信する段階とのためのコンピュータストレージ媒体上に符号化されたコンピュータプログラムを含む方法、システム、及び装置。【選択図】図５
2019530058.tif 000002
【特許請求の範囲】
【請求項１】
各購読要求がそれぞれの購読者クライアントから受信され、かつそれぞれのチャネルのためのものである１又は２以上の購読要求を受信する段階と、
各認可された購読要求が、該要求の前記購読者クライアントが該要求の前記チャネルに発行されたメッセージを受信することを許可する該購読要求の１又は２以上を認可する段階と、
各メッセージがそれぞれの発行者クライアントから受信され、かつそれぞれのチャネル上での発行のためのものである発行のための１又は２以上のメッセージを受信する段階と、
前記メッセージの各々に対して、該メッセージの前記チャネルのためのそれぞれのバッファに該バッファに関する有限有効期間中に該バッファに存在する該メッセージを入れる段階と、
前記バッファの１又は２以上に対して、前記チャネルを購読することを認可された購読者クライアントに該バッファ内のあらゆるメッセージを送信する段階と、
を含むことを特徴とするコンピュータ実装方法。
【請求項２】
１又は２以上の購読要求を認可する段階は、
特定の購読要求の前記チャネルがパターンに適合すると決定する段階と、
前記パターンに対応する許可に基づいて前記特定の購読要求の前記購読者クライアントを認可する段階と、
を含む、
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記特定の購読要求の前記チャネルがパターンに適合すると決定する段階は、
前記チャネルの１又は２以上の名前空間が前記パターンに適合すると決定する段階、
を含む、
ことを特徴とする請求項２に記載の方法。
【請求項４】
各発行要求が前記それぞれの発行者クライアントから受信され、かつそれぞれのチャネルのためのものである１又は２以上の発行要求を受信する段階と、
各認可された発行要求が、前記それぞれの発行者クライアントが該要求の前記チャネルに１又は２以上のメッセージを発行することを許可する該発行要求の１又は２以上を認可する段階と、
を更に含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記メッセージを該メッセージの前記チャネルのためのそれぞれのバッファに入れる段階は、
特定のメッセージがそこから受信された前記発行者クライアントが、該特定のメッセージの前記チャネルにメッセージを発行することを認可されていると決定する段階、
を含む、
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記発行要求の１又は２以上を認可する段階は、
特定の発行要求の前記チャネルがパターンに適合すると決定する段階と、
前記パターンに対応する許可に基づいて前記特定の発行要求の前記発行者クライアントを認可する段階と、
を含む、
ことを特徴とする請求項４に記載の方法。
【請求項７】
前記メッセージを該メッセージの前記チャネルのためのそれぞれのバッファに入れる段階は、
前記バッファに関する有効期間の満了時に該バッファ内のあらゆるメッセージを削除する段階、
を更に含む、
ことを特徴とする請求項１に記載の方法。
【請求項８】
各認証要求がそれぞれのクライアントから受信され、かつ該それぞれのクライアントの１又は２以上の資格を含む１又は２以上の認証要求をそれぞれの接続を通して受信する段階と、
各認証要求に対して、
前記それぞれのクライアントを認証することを要求し、かつ前記資格を含む第１のメッセージを第１のチャネルに発行する段階と、
前記第１のメッセージに応答して提供された認証確認を含む発行された第２メッセージを前記第１のチャネルから取り出す段階と、
それに基づいて、前記それぞれのクライアントを認証する段階と、
を更に含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記認証確認の表示を前記それぞれの接続に関連付けられた情報に格納する段階、
を更に含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記それぞれの接続が存在しなくなったと決定する段階と、
それに基づいて、前記情報を取り除く段階と、
を更に含むことを特徴とする請求項９に記載の方法。
【請求項１１】
前記第１のチャネルは、前記それぞれのクライアントに対してアクセス可能ではないことを特徴とする請求項８に記載の方法。
【請求項１２】
各購読要求がそれぞれの購読者クライアントから受信され、かつそれぞれのチャネルのためのものである１又は２以上の購読要求を受信する段階と、
各認可された購読要求が、該要求の前記購読者クライアントが該要求の前記チャネルに発行されたメッセージを受信することを許可する該購読要求の１又は２以上を認可する段階と、
各メッセージがそれぞれの発行者クライアントから受信され、かつそれぞれのチャネル上での発行のためのものである発行のための１又は２以上のメッセージを受信する段階と、
前記メッセージの各々に対して、該メッセージの前記チャネルのためのそれぞれのバッファに該バッファに関する有限有効期間中に該バッファに存在する該メッセージを入れる段階と、
前記バッファの１又は２以上に対して、前記チャネルを購読することを認可された購読者クライアントに該バッファ内のあらゆるメッセージを送信する段階と、
を含む作動を実行するようにプログラムされた１又は２以上のコンピュータ、
を含むことを特徴とするシステム。
【請求項１３】
１又は２以上の購読要求を認可する段階は、
特定の購読要求の前記チャネルがパターンに適合すると決定する段階と、
前記パターンに対応する許可に基づいて前記特定の購読要求の前記購読者クライアントを認可する段階と、
を含む、
ことを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記作動は、
各発行要求が前記それぞれの発行者クライアントから受信され、かつそれぞれのチャネルのためのものである１又は２以上の発行要求を受信する段階と、
各認可された発行要求が、前記それぞれの発行者クライアントが該要求の前記チャネルに１又は２以上のメッセージを発行することを許可する該発行要求の１又は２以上を認可する段階と、
を更に含む、
ことを特徴とする請求項１２に記載のシステム。
【請求項１５】
前記メッセージを該メッセージの前記チャネルのためのそれぞれのバッファに入れる段階は、
特定のメッセージがそこから受信された前記発行者クライアントが、該特定のメッセージの前記チャネルにメッセージを発行することを認可されていると決定する段階、
を含む、
ことを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記発行要求の１又は２以上を認可する段階は、
特定の発行要求の前記チャネルがパターンに適合すると決定する段階と、
前記パターンに対応する許可に基づいて前記特定の発行要求の前記発行者クライアントを認可する段階と、
を含む、
ことを特徴とする請求項１４に記載のシステム。
【請求項１７】
前記メッセージを該メッセージの前記チャネルのためのそれぞれのバッファに入れる段階は、
前記バッファに関する有効期間の満了時に該バッファ内のあらゆるメッセージを削除する段階、
を更に含む、
ことを特徴とする請求項１２に記載のシステム。
【請求項１８】
前記作動は、
各認証要求がそれぞれのクライアントから受信され、かつ該それぞれのクライアントの１又は２以上の資格を含む１又は２以上の認証要求をそれぞれの接続を通して受信する段階と、
各認証要求に対して、
前記それぞれのクライアントを認証することを要求し、かつ前記資格を含む第１のメッセージを第１のチャネルに発行する段階と、
前記第１のメッセージに応答して提供された認証確認を含む発行された第２メッセージを前記第１のチャネルから取り出す段階と、
それに基づいて、前記それぞれのクライアントを認証する段階と、
を更に含む、
ことを特徴とする請求項１２に記載のシステム。
【請求項１９】
前記作動は、
前記認証確認の表示を前記それぞれの接続に関連付けられた情報に格納する段階、
を更に含む、
ことを特徴とする請求項１８に記載のシステム。
【請求項２０】
１又は２以上のコンピュータによって実行された時に該コンピュータに、
各購読要求がそれぞれの購読者クライアントから受信され、かつそれぞれのチャネルのためのものである１又は２以上の購読要求を受信する段階と、
各認可された購読要求が、該要求の前記購読者クライアントが該要求の前記チャネルに発行されたメッセージを受信することを許可する該購読要求の１又は２以上を認可する段階と、
各メッセージがそれぞれの発行者クライアントから受信され、かつそれぞれのチャネル上での発行のためのものである発行のための１又は２以上のメッセージを受信する段階と、
前記メッセージの各々に対して、該メッセージの前記チャネルのためのそれぞれのバッファに該バッファに関する有限有効期間中に該バッファに存在する該メッセージを入れる段階と、
前記バッファの１又は２以上に対して、前記チャネルを購読することを認可された購読者クライアントに該バッファ内のあらゆるメッセージを送信する段階と、
を含む作動を実行させる命令が格納された非一時的コンピュータ可読媒体、
を含むことを特徴とする物品。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書は、データ通信システムに関し、特に、メッセージングチャネルのアクセス制御を実施するシステムに関する。
【背景技術】
【０００２】
発行−購読パターン（又は「ＰｕｂＳｕｂ」）は、いわゆる発行者が、トピックに対するメッセージを発行し、いわゆる購読者が、彼らが購読している特定のトピックに関するメッセージを受信するソフトウエアシステムによって実施されるデータ通信メッセージング取り決めである。トピック毎に１又は２以上の発行者が存在する可能性があり、発行者は、一般的に、どの購読者が、もし居れば、発行されたメッセージを受信するかの知識を持っていない。一部のＰｕｂＳｕｂシステムは、メッセージをキャッシュに入れず、又は小さいキャッシュを有し、購読者が、特定のトピックに対する購読予約の時点の前で発行されたメッセージを受信しない場合があることを意味する。ＰｕｂＳｕｂシステムは、メッセージ発行のサージ中又は特定のトピックに対する購読者の数が増加する時に性能不安定を受け易い可能性がある。
【発明の概要】
【課題を解決するための手段】
【０００３】
一般的に、本明細書に説明する主題の一態様は、各購読要求がそれぞれのクライアントから受信され、かつそれぞれのチャネルのためのものである１又は２以上の購読要求を受信するアクションと、要求の購読者クライアントが要求のチャネルに発行されたメッセージを受信することを各認可された購読要求が許可する購読要求の１又は２以上を認可するアクションと、各メッセージがそれぞれの発行者クライアントから受信され、かつそれぞれのチャネル上での発行のためのものである発行のための１又は２以上のメッセージを受信するアクションと、メッセージの各々に対して、バッファに関する有限有効期間中にバッファに存在するメッセージをメッセージのチャネルのためのそれぞれのバッファに入れるアクションと、バッファの１又は２以上に対して、チャネルを購読することを認可された購読者クライアントにバッファ内のあらゆるメッセージを送信するアクションとを含む方法に具現化することができる。この態様の他の実施形態は、対応するシステム、装置、及びコンピュータプログラムを含む。
【０００４】
これら及び他の態様は、任意的に以下の特徴の１又は２以上を含むことができる。特定の購読要求を認可するアクションは、特定の購読要求のチャネルがパターンに適合すると決定するアクションと、パターンに対応する許可に基づいて特定の購読要求の購読者クライアントを認可するアクションとを含むことができる。この態様は、各発行要求がそれぞれの発行者クライアントから受信され、かつそれぞれのチャネルのためのものである１又は２以上の発行要求を受信するアクションと、それぞれの発行者クライアントが１又は２以上のメッセージを要求のチャネルに発行することを各認可された発行要求が許可する発行要求の１又は２以上を認可するアクションとを更に含むことができる。メッセージのチャネルのためのそれぞれのバッファにメッセージを入れるアクションは、特定のメッセージがそこから受信された発行者クライアントが特定のメッセージのチャネルにメッセージを発行することを認可されていると決定するアクションを含むことができる。発行要求の１又は２以上を認可するアクションは、特定の発行要求のチャネルがパターンに適合すると決定するアクションと、パターンに対応する許可に基づいて特定の発行要求の発行者クライアントを認可するアクションとを含むことができる。メッセージのチャネルのためのそれぞれのバッファにメッセージを入れるアクションは、バッファの有効期間の満了時にバッファ内のあらゆるメッセージを削除するアクションを含むことができる。この態様は、各認証要求がそれぞれのクライアントから受信され、かつそれぞれのクライアントの１又は２以上の資格を含む１又は２以上の認証要求をそれぞれの接続を通して受信するアクションと、各認証要求に対して、それぞれのクライアントを認証することを要求し、かつ資格を含む第１のメッセージを第１のチャネルに発行するアクションと、第１のメッセージに応答して提供された認証確認を含む発行された第２メッセージを第１のチャネルから取り出すアクションと、それに基づいてそれぞれのクライアントを認証するアクションとを更に含むことができる。この態様は、認証確認の表示をそれぞれの接続に関連付けられた情報に格納するアクションを更に含むことができる。この態様は、それぞれの接続が存在しなくなったと決定するアクションと、それに基づいて情報を取り除くアクションとを更に含むことができる。第１のチャネルは、それぞれのクライアントにアクセス可能ではない可能性がある。特定の購読要求のチャネルがパターンに適合すると決定するアクションは、チャネルの１又は２以上の名前空間がパターンに適合すると決定するアクションを含むことができる。
【０００５】
本明細書に説明する主題の特定の実施形態は、以下の利点の１又は２以上を実現するように実施することができる。メッセージングシステムは、発行者と購読者の間のデータ通信のための複数のチャネルを提供する。メッセージングシステムの各チャネルは、メッセージの順序付けられたシーケンス（チャネルストリーム）を含む。メッセージは、それぞれの待ち行列ノード上に存在する複数のバッファに格納される。各バッファは、それぞれの有効期間、例えば、制限されて多くの場合に短い寿命を有する。購読者又は発行者は、メッセージングシステム内のチャネルへのアクセスのための要求をメッセージングシステムに送信することができる。メッセージングシステムは、要求内のチャネルが例えば許可規則内のパターンに適合するか否かを決定することにより、アクセスのための許可を承諾（認可）又は拒否することができる。メッセージングシステムの顧客は、メッセージングシステム内の顧客チャネルを作成及び管理することができる。顧客チャネルにそれ自体によってアクセスするためのユーザ（購読者又は発行者）からの要求を認可する代わりに、メッセージングシステムは、特定のチャネルにその要求を発行する。顧客は、特定のチャネルを購読し、特定のチャネルに発行された要求を取り出し、ユーザが顧客チャネルにアクセスすることを認可されているか否かを決定し、かつ特定のチャネルに応答（例えば、肯定又は否定）を発行することができる。メッセージングシステムは、特定のチャネルから応答を取り出し、かつ取り出した応答に基づいて顧客チャネルへのユーザアクセスを可能にする又は拒否することができる。要求及び対応する応答は、特定のチャネルのチャネルストリームに格納されるので、それらは、顧客又はユーザ側での再始動又は一時中止のような中断の場合に失われない。
【０００６】
本明細書に説明する主題の１又は２以上の実施形態の詳細は、添付図面及び以下の説明に示している。本発明の主題の他の特徴、態様、及び利点は、説明、図面、及び特許請求の範囲から明らかになるであろう。
【図面の簡単な説明】
【０００７】
【図１Ａ】ＰｕｂＳｕｂ通信パターンをサポートする例示的システムを示す図である。
【図１Ｂ】例示的クライアントデバイス上のソフトウエアの機能層を示す図である。
【図２】例示的メッセージングシステムの図である。
【図３Ａ】データをストリームレットに書き込む例示的方法のデータ流れ図である。
【図３Ｂ】ストリームレットからデータを読み取る例示的方法のデータ流れ図である。
【図４Ａ】メッセージをメッセージングシステム内のチャネルに発行する例示的方法のデータ流れ図である。
【図４Ｂ】メッセージングシステム内のチャネルを購読する例示的方法のデータ流れ図である。
【図４Ｃ】メッセージングシステム内のチャネルのメッセージを格納するための例示的データ構造の図である。
【図５】メッセージングシステムのユーザを認証及び認可する例示的方法のデータ流れ図である。
【図６Ａ】メッセージングシステムのユーザを認証及び認可する例示的方法のデータ流れ図である。
【図６Ｂ】メッセージングシステムのユーザを認証及び認可する例示的方法のデータ流れ図である。
【図７】メッセージングシステムのメッセージチャネルに対する購読及び発行を認可する例示的方法の流れ図である。
【発明を実施するための形態】
【０００８】
図１Ａは、ＰｕｂＳｕｂ通信パターンをサポートする例示的システム１００を示している。発行者クライアント（例えば、発行者１）は、システム１００によってメッセージを指名チャネル（例えば、「チャネル１」）に発行することができる。メッセージは、テキスト、画像コンテンツ、音声コンテンツ、マルチメディアコンテンツ、ビデオコンテンツ、及びバイナリデータなどの１又は２以上を含むあらゆるタイプの情報を含むことができる。メッセージデータの他のタイプも可能である。購読者クライアント（例えば、購読者２）は、システム１００を使用して指名チャネルを購読予約し、かつ購読要求後に又は所与の位置（例えば、メッセージ番号又は時間オフセット）から発生するメッセージの受信を開始することができる。クライアントは、発行者及び購読者の両方とすることができる。
【０００９】
構成に応じて、ＰｕｂＳｕｂシステムは、以下のように分類することができる。
・１対１（１：１）。この構成では、チャネル毎に１人の発行者及び１人の購読者がいる。典型的な使用事例は、プライベートメッセージングである。
・１対多数（１：Ｎ）。この構成では、チャネル毎に１人の発行者と複数の購読者がいる。典型的な使用事例は、放送メッセージ（例えば、株価）である。
・多数対多数（Ｍ：Ｎ）。この構成では、単一チャネルに発行する多くの発行者がいる。
メッセージは、次に、複数の購読者に配信される。典型的な使用事例は、地図アプリケーションである。
【００１０】
指名チャネルを生成するのに必要な個別の作動はない。チャネルが購読された時又はメッセージがチャネルに発行された時にチャネルが暗黙的に生成される。一部の実施では、チャネル名は、名前空間によって限定することができる。名前空間は、１又は２以上のチャネル名を含む。異なる名前空間は、曖昧さを生じることなく同じチャネル名を有することができる。名前空間名は、名前空間及びチャネネームがドット又は他の適切な分離記号によって分けられる場合のチャネル名の接頭辞とすることができる。一部の実施では、チャネル許可設定を指定する時に名前空間を使用することができる。例えば、メッセージングシステム１００は、ａｐｐ１．ｆｏｏ及びａｐｐ１．ｓｙｓｔｅｍ．ｎｏｔｉｆｉｃａｔｉｏｎｓチャネルを有することができ、ここで「ａｐｐｌ」は、名前空間の名称である。本発明のシステムは、クライアントがａｐｐｌ．ｆｏｏチャネルを購読及び発行することを可能にすることができる。しかし、クライアントは、ａｐｐｌ．ｓｙｓｔｅｍ．ｎｏｔｉｆｉｃａｔｉｏｎｓチャネルを発行しないが購読のみとすることができる。
【００１１】
図１Ｂは、例示的クライアントデバイス上のソフトウエアの機能層を示している。クライアントデバイス（例えば、クライアント１０２）は、例えば、パーソナルコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォン、スマートウォッチ、又はサーバコンピュータのようなデータ処理装置である。他のタイプのクライアントデバイスも可能である。アプリケーション層１０４は、ＰｕｂＳｕｂシステム１００に統合することになるエンド−ユーザアプリケーションを含む。メッセージング層１０６は、アプリケーション層１０４がチャネル購読、メッセージ発行、メッセージ取り出し、ユーザ認証、及びユーザ許可のようなシステム１００のサービスを利用するプログラミングインタフェースである。一部の実施では、メッセージング層１０６との間で送られるメッセージは、ＪａｖａＳｃｒｉｐｔ（登録商標）オブジェクト表記（ＪＳＯＮ）オブジェクトとして符号化される。他のメッセージ符号化方式も可能である。
【００１２】
オペレーティングシステム１０８層は、クライアント１０２のオペレーティングシステムソフトウエアを含む。様々な実施では、持続的又は非持続的接続を使用してシステム１００にメッセージを送信する及びシステム１００からメッセージを受信することができる。持続的接続は、例えば、ネットワークソケットを使用して生成することができる。ＴＣＰ／ＩＰ層１１２のようなトランスポートプロトコルは、メッセージング層１０６によって使用されるシステム１００とのトランスポート制御プロトコル／インターネットプロトコル通信を実施し、接続を通してシステム１００にメッセージを送信する。例えば、ユーザデータグラムプロトコル（ＵＤＰ）を含む他の通信プロトコルも可能である。更に別の実施では、任意的なトランスポート層セキュリティ（ＴＬＳ）層１１０を利用してメッセージの機密性を保証することができる。
【００１３】
図２は、例示的メッセージングシステム１００の図である。システム１００は、ＰｕｂＳｕｂ通信パターンを実施するための機能性を提供する。本発明のシステムは、例えば、１又は２以上の地理的な場所で１又は２以上のデータセンター１２２に配備することができるソフトウエア構成要素及びストレージを含む。本発明のシステムは、ＭＸノード（例えば、ＭＸノード又は多重化ノード２０２、２０４、及び２０６）、Ｑノード（例えば、Ｑノード又は待ち行列ノード２０８、２１０、及び２１２）、１又は２以上のチャネルマネージャノード（例えば、チャネルマネージャ２１４、２１５）、及び任意的に１又は２以上のＣノード（例えば、Ｃノード又はキャッシュノード２２０及び２２２）を含む。各ノードは、仮想機械又は物理機械（例えば、データ処理装置）で実行することができる。
各ＭＸノードは、外部ネットワーク２１６を通じた１又は２以上の発行者及び／又は購読者接続の終端ポイントとして機能する。ＭＸノード、Ｑノード、Ｃノード、及びチャネルマネージャ間の内部通信は、例えば、内部ネットワーク２１８を通じて行われる。例示的に、ＭＸノード２０４をクライアント１０２からの購読者接続の終端とすることができる。各Ｑノードは、ＭＸノードによって消費するチャネルデータをバッファに入れる。チャネルに発行されたメッセージの順序付けられたシーケンスが論理的チャネルストリームである。例えば、３つのクライアントが所与のチャネルにメッセージを発行する場合に、クライアントによって発行された複合メッセージは、チャネルストリームを含む。メッセージは、チャネルストリーム内でクライアントによる発行の時間により、ＭＸノードによる受信の時間により、又はＱノードによる受信の時間によって順序付けることができる。チャネルストリームのメッセージを順序付けるための他の方法も可能である。１よりも多いメッセージが順序の同じ位置に割り当てられる場合に、順序の後ろのシーケンスを有するメッセージの１つを（例えば、ランダムに）選択することができる。各チャネルマネージャノードは、チャネルストリームをいわゆるストリームレットに分割することによってＱノードの負荷を管理する役割を果たす。ストリームレットは以下に詳しく説明する。任意的Ｃノードは、キャッシュ及びＱノードからの負荷除去を提供する。
【００１４】
例示的メッセージングシステム１００では、１又は２以上のクライアントデバイス（発行者及び／又は購読者）は、ＭＸノード（例えば、ＭＸノード２０４）へのそれぞれの持続的接続（例えば、ＴＣＰ接続）を設定する。ＭＸノードは、これらの接続の終端ポイントとして機能する。例えば、これらの接続によって運ばれた外部メッセージ（例えば、それぞれのクライアントデバイスとＭＸノード間）は、外部プロトコル（例えば、ＪＳＯＮ）に基づいて符号化することができる。ＭＸノードは、外部プロトコルを終了して外部メッセージを内部通信に翻訳し、逆も同様である。ＭＸノードは、クライアントの代わりにストリームレットを発行及び購読する。従って、ＭＸノードは、同じチャネルを購読又は発行するクライアントデバイスの要求を多重化及び融合することができ、従って、１つずつの代わりに１つとして複数のクライアントデバイスを表している。
【００１５】
例示的メッセージングシステム１００では、Ｑノード（例えば、Ｑノード２０８）は、１又は２以上のチャネルストリームの１又は２以上のストリームレットを格納することができる。ストリームレットは、チャネルストリームの一部分のためのデータバッファである。ストリームレットは、そのストレージが満杯である時に書込に対して閉じることになる。ストリームレットは、ストリームレットの有効期間（ＴＴＬ）が満了した時に読取及び書込に対して閉じて割り当てを解除する。例示的に、ストリームレットは、１ＭＢの最大サイズ及び３分のＴＴＬを有することができる。異なるチャネルは、異なるサイズ及び／又は異なるＴＴＬによって制限されるストリームレットを有することができる。例えば、１つのチャネル内のストリームレットは、３分まで存在することができる一方、別のチャネル内のストリームレットは、１０分まで存在することができる。様々な実施では、ストリームレットは、Ｑノードで実行されるコンピュータ処理に対応する。コンピュータ処理は、ストリームレットのＴＴＬが満了した後に終了することができ、従って、例えば、Ｑノードに戻るコンピュータリソース（ストリームレット）を解放する。
【００１６】
クライアントデバイスから発行要求を受信した時に、ＭＸノード（例えば、ＭＸ２０４）は、チャネルマネージャ（例えば、チャネルマネージャ２１４）に要求してストリームレットへのアクセスを許可し、発行されるメッセージを書き込む。しかし、ＭＸノードがチャネル内のストリームレットへの書込アクセスを予め許可される（かつチャネルが書込に対して閉じていない）場合に、ＭＸノードは、ストリームレットにアクセスする許可を要求する必要なくこのストリームレットにメッセージを書き込むことができることに注意されたい。メッセージがチャネル内のストリームレットに書き込まれた状態で、メッセージは、ＭＸノードによって読み取られ、このチャネルの購読者に提供することができる。
【００１７】
同様に、クライアントデバイスからチャネル購読要求を受信した時に、ＭＸノードは、チャネル内のストリームレットへのアクセスのための許可をチャネルマネージャに要求してストリームレットからメッセージが読み取られる。ＭＸノードがチャネル内のストリームレットへの読取アクセスを予め許可されている（かつチャネルのＴＴＬが読取に対して閉じていない）場合に、ＭＸノードは、ストリームレットにアクセスする許可を要求する必要なくストリームレットからメッセージを読み取ることができる。読取メッセージは、チャネルに購読予約したクライアントデバイスに転送することができる。様々な実施では、ストリームレットから読み取られたメッセージは、ＭＸノードによってキャッシュに入れられ、それによってＭＸノードは、ストリームレットから読み取るのに必要な時間数を低減することができる。
【００１８】
例示的に、ＭＸノードは、ＭＸノードが特定のチャネル内のストリームレットを格納する特定のＱノードのストリームレットにデータのブロックを格納することを可能にするチャネルマネージャからの許可を要求することができる。例示的ストリームレット許可要求及び許可データ構造は以下の通りである。
2019530058.tif 000003
【００１９】
ＳｔｒｅａｍｌｅｔＧｒａｎｔＲｅｑｕｅｓｔデータ構造は、ストリームｃｈａｎｎｅｌの名前及びＭＸノードがストリームレットからの読取又はストリームレットへの書込を意図するか否かを示すモードを格納する。ＭＸノードは、ＳｔｒｅａｍｌｅｔＧｒａｎｔＲｅｑｕｅｓｔをチャネルマネージャノードに送信する。チャネルマネージャノードは、相応にＭＸノードにＳｔｒｅａｍｌｅｔＧｒａｎｔＲｅｓｐｏｎｓｅデータ構造を送信する。ＳｔｒｅａｍｌｅｔＧｒａｎｔＲｅｓｐｏｎｓｅは、ストリームレットの識別子（ｓｔｒｅａｍｌｅｔ−ｉｄ）、ストリームレットの最大サイズ（ｌｉｍｉｔ−ｓｉｚｅ）、ストリームレットが格納することができるメッセージの最大数（ｌｉｍｉｔ−ｍｓｇｓ）、ＴＴＬ（ｌｉｍｉｔ−ｌｉｆｅ）、及びストリームレットが存在するＱノードの識別子（ｑ−ｎｏｄｅ）を含有する。ＳｔｒｅａｍｌｅｔＧｒａｎｔＲｅｑｕｅｓｔ及びＳｔｒｅａｍｌｅｔＧｒａｎｔＲｅｓｐｏｎｓｅはまた、ストリームレットから読み取るためのストリームレットの位置（又はチャネルの位置）を示す位置フィールドを有することができる。
【００２０】
許可は、ストリームレットが閉じた状態で無効になる。例えば、ストリームレットは、ストリームレットのＴＴＬが満了した状態で読取及び書込に対して閉じ、ストリームレットのストレージが満杯の時はストリームレットが書込に対して閉じる。許可が無効になった時に、ＭＸノードは、ストリームレットから読み取る又はストリームレットに書き込むためのチャネルマネージャからの新しい許可を要求することができる。新しい許可は、異なるストリームレットを参照することになり、かつ新しいストリームレットが存在する場所に応じて同じか又は異なるＱノードを意味することになる。
【００２１】
図３Ａは、様々な実施形態でデータをストリームレットに書き込む例示的方法のデータ流れ図である。図３Ａでは、ストリームレットに書き込むためのＭＸノード（例えば、ＭＸノード２０２）要求が、上述のようにチャネルマネージャ（例えば、チャネルマネージャ２１４）によって許可された時に、ＭＸノードは、チャネルマネージャ（３０２）から受信した許可応答で識別されたＱノード（例えば、Ｑノード２０８）との送信制御プロトコル（ＴＣＰ）接続を確立する。ストリームレットは、複数の書込許可（例えば、複数の発行者クライアントによって発行されたメッセージに対する）によって同時に書き込むことができる。ＭＸノードとＱノード間の接続プロトコルの他のタイプも可能である。
【００２２】
ＭＸノードは、次に、ＭＸノードがＱノードに書き込みたいストリームレットの識別子を備えた準備−発行メッセージを送信する（３０４）。ストリームレット識別子及びＱノード識別子は、上述のように書込許可でチャネルマネージャによって提供することができる。Ｑノードは、識別されたストリームレットのハンドラ処理３０１（例えば、Ｑノードで実行されるコンピュータ処理）にメッセージを渡す（３０６）。ハンドラ処理は、ＭＸノードに肯定応答を送信することができる（３０８）。肯定応答を受信した後に、ＭＸノードは、識別されたストリームレットに受信したデータを格納するハンドラ処理へのメッセージの書込（発行）（例えば、３１０、３１２、３１４、及び３１８）を開始する。ハンドラ処理はまた、受信したデータの肯定応答（３１６、３２０）をＭＸノードに送信することができる。一部の実施では、肯定応答は、抱き合わせ又は累積的とすることができる。例えば、ハンドラ処理は、予め決められたデータ量が受信される毎に（例えば、１００メッセージが受信される毎に）、又は予め決められた時間毎に（例えば、１ミリ秒毎に）ＭＸノードに肯定応答を送信することができる。ネーグルのアルゴリズムのような他の肯定応答スケジューリングアルゴリズムを使用することもできる。
【００２３】
ストリームレットが、発行されたデータをそれ以上受け入れられない場合（例えば、ストリームレットが満杯の時）、ハンドラ処理は、問題を示す否定応答（ＮＡＫ）メッセージ（３３０）、次に、ＥＯＦ（ファイルの終わり）メッセージ（３３２）を送信する。従って、ハンドラ処理は、発行許可のためのＭＸノードとのアソシエーションを閉じる。ＭＸノードが格納する追加のメッセージを有する場合に、ＭＸノードは、チャネルマネージャから別のストリームレットの書込許可を要求することができる。
【００２４】
図３Ｂは、様々な実施形態におけるストリームレットからデータを読み取る例示的方法のデータ流れ図である。図３Ｂでは、ＭＸノード（例えば、ＭＸ２０４）は、チャネルマネージャ（例えば、チャネルマネージャ２１４）に特定のメッセージから始まる特定のチャネル又はチャネルの時間オフセットを読み取るための要求を送信する。チャネルマネージャは、特定のメッセージを含有するストリームレットの識別子、特定のメッセージに対応するストリームレットにおける位置、及び特定のストリームレットを含有するＱノード（例えば、Ｑノード２０８）の識別子を含む読取許可をＭＸノードに戻す。ＭＸノードは、ＱノードとのＴＣＰ接続を確立する（３５２）。ＭＸノードとＱノード間の接続プロトコルの他のタイプも可能である。
【００２５】
ＭＸノードは、ストリームレットの識別子（Ｑノード内）及びＭＸノードがそこから読み取りたいストリームレットの位置を備えた購読メッセージ（３５４）をＱノードに送信する（３５６）。Ｑノードは、購読メッセージをストリームレットのハンドラ処理３５１に渡す（３５６）。ハンドラ処理は、ＭＸノードに肯定応答を送信することができる（３５８）。ハンドラ処理は、ストリームレットの位置で開始されるメッセージ（３６０、３６４、３６６）をＭＸノードに送信する。一部の実施では、ハンドラ処理は、ストリームレットのメッセージの全てをＭＸノードに送信することができる。特定のストリームレット内の最後のメッセージを送信した後に、ハンドラ処理は、最後のメッセージの通知をＭＸノードに送信することができる。ＭＸノードは、特定のチャネル内の次のメッセージを含有する別のストリームレットに対する別の要求をチャネルマネージャに送信することができる。
【００２６】
特定のストリームレットが閉じた場合（例えば、特定のストリームレットのＴＴＬが満了した後）、ハンドラ処理は、非購読メッセージ（３９０）、次に、ＥＯＦメッセージ（３９２）を送信して読取許可のためのＭＸノードとのアソシエーションを閉じることができる。ＭＸノードは、ＭＸノードが特定のチャネル内のメッセージのために別のストリームレットに移る（例えば、チャネルマネージャによって示されたように）時にハンドラ処理とのアソシエーションを閉じることができる。ＭＸノードは、ＭＸノードが、対応するクライアントデバイスから非購読メッセージを受信した場合に、ハンドラ処理とのアソシエーションを閉じることができる。
【００２７】
様々な実施では、ストリームレットは、同じ時間インスタンスに書き込み、かつ読み取ることができる。例えば、同じ時間インスタンスに有効読取許可及び有効書込許可を存在させることができる。様々な実施では、複数の読取許可（例えば、複数の発行者クライアントによって購読されるチャネルに対する）によって同時にストリームレットを読み取ることができる。ストリームレットのハンドラ処理は、例えば、到着時間に基づいて同時書込許可からのメッセージを順序付けし、その順序に基づいてメッセージを格納することができる。従って、複数の発行者クライアントからチャネルに発行されたメッセージは、チャネル内のストリームレットにシリアル化して格納することができる。
【００２８】
メッセージングシステム１００では、１又は２以上のＣノード（例えば、Ｃノード２２０）は、１又は２以上のＱノードからのデータ転送をアンロードすることができる。例えば、特定のチャネルのためのストリームレットをＱノードから要求する多くのＭＸノードが存在する場合に、ストリームレットをアンロードして１又は２以上のＣノードをキャッシュに入れることができる。ＭＸノード（例えば、チャネルマネージャから読取許可によって命令される）は、代わりにＣノードからストリームレットを読み取ることができる。
【００２９】
上述のように、メッセージングシステム１００内のチャネルのためのメッセージは、チャネルストリームで順序付けされる。チャネルマネージャ（例えば、チャネルマネージャ２１４）は、それぞれのＱノードに各々が存在する固定サイズストリームレットにチャネルストリームを分割する。従って、チャネルストリームの格納は、多くのＱノード間で共有することができ、各Ｑノードは、チャネルストリームの一部分（１又は２以上のストリームレット）を格納する。より具体的には、ストリームレットは、Ｑノード上のコンピュータ処理に関連付けられた例えばレジスタ及び／又は動的メモリ要素に格納することができ、従って、ハードディスクのような持続性低速ストレージデバイスにアクセスする必要性を回避する。これは高速のメッセージアクセスをもたらす。チャネルマネージャは、Ｑノードのそれぞれのワークロードをモニタし、いかなる１つのＱノードの過負荷も回避する方法でストリームレットを割り当てることにより、メッセージングシステム１００のＱノード間の負荷の均衡を取ることができる。
【００３０】
様々な実施では、チャネルマネージャは、各アクティブストリームレット、ストリームレットが存在するそれぞれのＱノード、ストリームレットの第１のメッセージの位置の識別、及びストリームレットが書込に対して閉じているか否かを識別するリストを維持する。一部の実施では、Ｑノードは、満杯であるために又はストリームレットのＴＴＬが満了した時にストリームレットが閉じていることをストリームレットに発行しているチャネルマネージャ及びあらゆるＭＸノードに通知する。ストリームレットが閉じている時に、ＭＸノードがストリームレットからメッセージの取り出しを継続することができるようにストリームレットのＴＴＬが満了するまでアクティブストリームレットのチャネルマネージャのリストにストリームレットが残る。
【００３１】
ＭＸノードが所与のチャネルに対する書込許可を要求して書き込むことができるチャネルのためのストリームレットがない時に、チャネルマネージャは、Ｑノードの１つに新しいストリームレットを割り当て、ストリームレットのアイデンティティ及びＳｔｒｅａｍｌｅｔＧｒａｎｔＲｅｓｐｏｎｓｅのＱノードを戻す。そうでなければ、チャネルマネージャは、ストリームレット及び対応するＱノードをＳｔｒｅａｍｌｅｔＧｒａｎｔＲｅｓｐｏｎｓｅに書き込むために現在開いているというアイデンティティを戻す。ＭＸノードは、ストリームレットが満杯になるか又はストリームレットのＴＴＬが満了するまでストリームレットにメッセージを発行することができ、この後で新しいストリームレットをチャネルマネージャによって割り当てることができる。
【００３２】
ＭＸノードが所与のチャネルの読取許可を要求して読み取ることができるチャネルのためのストリームレットがない時に、チャネルマネージャは、Ｑノードの１つに新しいストリームレットを割り当て、ストリームレットのアイデンティティ及びＳｔｒｅａｍｌｅｔＧｒａｎｔＲｅｓｐｏｎｓｅのＱノードを戻す。そうでなければ、チャネルマネージャは、ストリームレットのアイデンティティ及びＭＸノードが読み取りたい位置を含有するＱノードを戻す。Ｑノードは、送信するストリームレットのメッセージがなくなるまで指定された位置で始まるストリームレットからＭＸノードへのメッセージの送信を開始することができる。新しいメッセージがストリームレットに発行された時に、このストリームレットを購読しているＭＸノードは、新しいメッセージを受信する。ストリームレットのＴＴＬが満了した場合に、ハンドラ処理３５１は、ＥＯＦメッセージ（３９２）をストリームレットを購読するいずれのＭＸノードにも送信する。
【００３３】
図２に関して上述したように、メッセージングシステム１００は、複数のチャネルマネージャ（例えば、チャネルマネージャ２１４、２１５）を含むことができる。複数のチャネルマネージャは、弾力性を提供して単一障害点を回避する。例えば、１つのチャネルマネージャは、それが維持するストリームレットと現在の許可のリストとを別の「スレーブ」チャネルマネージャに複製することができる。別の例として、複数のチャネルマネージャは、例えばＰａｘｏｓ又はＲａｆｔプロトコルのような分散コンセンサスプロトコルを使用して複数のチャネルマネージャ間で作動を調整することができる。
【００３４】
図４Ａは、メッセージングシステム内のチャネルにメッセージを発行する例示的方法のデータ流れ図である。図４Ａでは、発行者（例えば、発行者クライアント４０２、４０４、４０６）が、図２に関して上述したメッセージングシステム１００にメッセージを発行する。例えば、発行者４０２は、接続４１１をそれぞれ確立して発行要求をＭＸノード２０２に送信する。発行者４０４は、接続４１３をそれぞれ確立して発行要求をＭＸノード２０６に送信する。発行者４０６は、接続４１５をそれぞれ確立して発行要求をＭＸノード２０４に送信する。ここでＭＸノードは、内部ネットワーク２１８を通じてメッセージングシステム１００のチャネルマネージャ（例えば、チャネルマネージャ２１４）及び１又は２以上のＱノード（例えば、Ｑノード２１２及び２０８）と通信することができる（４１７）。
【００３５】
例証として、発行者からＭＸノードへの各発行要求（例えば、ＪＳＯＮ鍵／値ペアにおける）は、チャネル名及びメッセージを含む。ＭＸノード（例えば、ＭＸノード２０２）は、発行要求のメッセージを発行要求のチャネル名（例えば、「ｆｏｏ」）に基づいてメッセージングシステム１００の別々のチャネルに割り当てることができる。ＭＸノードは、チャネルマネージャ２１４によって割り当てられたチャネルを確認することができる。チャネル（購読要求で指定）がメッセージングシステム１００にまだ存在しない場合、チャネルマネージャは、メッセージングシステム１００内で新しいチャネルを生成かつ維持することができる。例えば、チャネルマネージャは、チャネルのストリームの各アクティブストリームレットを識別するリスト、ストリームレットが存在するそれぞれのＱノード、及び上述のようなストリームレットの最初と最後のメッセージの位置の識別を維持することによって新しいチャネルを維持することができる。
【００３６】
特定のチャネルのメッセージに関して、ＭＸノードは、メッセージングシステム１００の１又は２以上のバッファ又はストリームレットにメッセージを格納することができる。例えば、ＭＸノード２０２は、発行者４０２からチャネルｆｏｏへの発行要求メッセージＭ１１、Ｍ１２、Ｍ１３、及びＭ１４を受信する。ＭＸノード２０６は、発行者４０４からチャネルｆｏｏへの発行要求メッセージＭ７８及びＭ７９を受信する。ＭＸノード２０４は、発行者４０６からチャネルｆｏｏへの発行要求メッセージＭ２６、Ｍ２７、Ｍ２８、Ｍ２９、Ｍ３０及びＭ３１を受信する。
【００３７】
ＭＸノードは、チャネルｆｏｏのためのメッセージを格納する１又は２以上のストリームレットを識別することができる。上述のように、各ＭＸノードは、ＭＸノードがチャネルｆｏｏのストリームレットにメッセージを格納するのを可能にするチャネルマネージャ２１４からの書込許可を要求することができる。例えば、ＭＸノード２０２は、チャネルマネージャ２１４からＱノード２１２上のストリームレット４１０１にメッセージＭ１１、Ｍ１２、Ｍ１３、及びＭ１４を書き込む許可を受信する。ＭＸノード２０６は、チャネルマネージャ２１４からストリームレット４１０１にメッセージＭ７８及びＭ７９を書き込む許可を受信する。ここでストリームレット４１０１は、チャネルｆｏｏのメッセージを格納するチャネルストリーム４３０のストリームレットのシーケンスの最後のストリームレット（この時点で）である。ストリームレット４１０１は、ストリームレット４１０１に以前に格納されたがまだ開いているチャネルｆｏｏのメッセージ（４２１）を有し、すなわち、ストリームレット４１０１は、メッセージを格納する空間をまだ有しており、かつストリームレットのＴＴＬが満了していない。
【００３８】
ＭＸノード２０２は、各メッセージがＭＸノード２０２によって受信されたそれぞれの時間に基づいてチャネルｆｏｏのためのメッセージを例えばＭ１１、Ｍ１３、Ｍ１４、Ｍ１２（４２２）のように並べ、受信したメッセージを並べられた通りにストリームレット４１０１に格納することができる。すなわち、ＭＸノード２０２は、最初にＭ１１、次に、Ｍ１３、Ｍ１４、及びＭ１２を受信する。同様に、ＭＸノード２０６は、各メッセージがＭＸノード２０６によって受信されたそれぞれの時間に基づいてチャネルｆｏｏのためのメッセージを例えばＭ７８、Ｍ７９（４２３）のように並べ、受信したメッセージを並べられた通りにストリームレット４１０１に格納することができる。チャネルのためのメッセージの他の配置又は順序付けも可能である。
【００３９】
ＭＸノード２０２（又はＭＸノード２０６）は、例えば図３Ａに関して上述したストリームレットにデータを書き込む方法を使用して受信メッセージを格納することができる。様々な実施では、ＭＸノード２０２（又はＭＸノード２０６）は、チャネルｆｏｏのための受信メッセージをバッファに（例えばローカルデータバッファに）入れて、バッファメッセージが事前に決められた数又はサイズ（例えば、１００メッセージ）に達した時に、又は事前に決められた時間（例えば、５０ミリ秒）が経過した時に、チャネルｆｏｏのストリームレット（例えば、ストリームレット４１０１）に受信メッセージを格納することができる。例えば、ＭＸノード２０２は、ある時間に又は５０ミリ秒毎にストリームレットに１００メッセージを格納することができる。ネーグルのアルゴリズムのような他の肯定応答スケジューリングアルゴリズムを使用することもできる。
【００４０】
様々な実施では、Ｑノード２１２（例えばハンドラ処理）は、チャネルｆｏｏのメッセージをＭＸノード２０２及びＭＸノード２０６によって並べられた順序でストリームレット４１０１に格納する。Ｑノード２１２は、Ｑノード２１２がメッセージを受信する順序でチャネルｆｏｏのメッセージをストリームレット４１０１に格納する。例えば、Ｑノード２１２は、最初に（ＭＸノード２０６から）メッセージＭ７８、次にメッセージＭ１１及びＭ１３（ＭＸノード２０２から）、Ｍ７９（ＭＸノード２０６から）、及びＭ１４及びＭ１２（ＭＸノード２０２から）を受信すると仮定されたい。Ｑノード２１２は、ストリームレット４１０１に以前に格納されたメッセージ４２１の直後に、受信した順序、例えば、Ｍ７８、Ｍ１１、Ｍ１３、Ｍ７９、Ｍ１４、及びＭ１２でストリームレット４１０１にメッセージを格納する。従って、複数の発行者（例えば、４０２、４０４）からチャネルｆｏｏに発行されたメッセージは、特定の順序で並べてチャネルｆｏｏのストリームレット４１０１に格納することができる。チャネルｆｏｏを購読する異なる購読者は、図４Ｂに関して詳しく説明するように同じ特定の順序でチャネルｆｏｏのメッセージを受信することになる。
【００４１】
図４Ａの例では、メッセージＭ１２がストリームレット４１０１に格納された後の時間インスタンスで、ＭＸノード２０４は、チャネルマネージャ２１４からチャネルｆｏｏに書き込む許可を要求する。チャネルマネージャ２１４は、ストリームレット４１０１が書込にまだ開いている場合にストリームレット４１０１へのメッセージの書込許可をＭＸノード２０４に提供する。ＭＸノード２０４は、各メッセージがＭＸノード２０４によって受信されたそれぞれの時間に基づいてチャネルｆｏｏのためのメッセージを例えばＭ２６、Ｍ２７、Ｍ３１、Ｍ２９、Ｍ３０，Ｍ２８（４２４）のように並べ、チャネルｆｏｏのために並べられた通りにメッセージを格納する。
【００４２】
例証として、メッセージＭ２６がストリームレット４１０１の最後の利用可能な位置に格納されると仮定されたい。ストリームレット４１０１が現在満杯であるので、Ｑノード２１２は、ＭＸノード２０４にＮＡＫメッセージ、次にＥＯＦメッセージを送信し、図３Ａに関して上述したように書込許可のためのＭＸノード２０４とのアソシエーションを閉じる。次に、ＭＸノード２０４は、チャネルｆｏｏのための追加のメッセージ（例えば、Ｍ２７、Ｍ３１など）のためのチャネルマネージャ２１４からの別の書込許可を要求する。
【００４３】
チャネルマネージャ２１４は、メッセージングシステム１００の利用可能なＱノードのそれぞれの過負荷（例えばどのくらいのストリームレットが各Ｑノード上に存在しているか）をモニタすることができる。チャネルマネージャ２１４は、いずれの所与のＱノードに対しても過負荷（例えば、ストリームレットが多すぎる又は読取又は書込許可が多すぎる）を回避できるようにＭＸノード２０４からの書込要求にストリームレットを割り当てることができる。例えば、チャネルマネージャ２１４は、メッセージングシステム１００の最小負荷Ｑノードを識別してＭＸノード２０４からの書込要求に対して最小負荷Ｑノードに新しいストリームレットを割り当てることができる。図４Ａの例では、チャネルマネージャ２１４は、Ｑノード２０８上の新しいストリームレット４１０２を割り当てて、ストリームレット４１０２へのチャネルｆｏｏの書込メッセージに対する書込許可をＭＸノード２０４に提供する。図４Ａに示すように、Ｑノードは、ＭＸノード２０４によって並べられた順序Ｍ２７、Ｍ３１、Ｍ２９，Ｍ３０、及びＭ２８で（この時点でストリームレット４１０２に対して他の同時書込許可がないと仮定して）ＭＸノード２０４からのメッセージをストリームレット４１０２に格納する。
【００４４】
チャネルマネージャ２１４が、ＭＸノード（例えば、ＭＸノード２０４）からのチャネル（例えば、ｆｏｏ）への書込許可の要求に対して新しいストリームレット（例えば、ストリームレット４１０２）を割り当てる時に、チャネルマネージャ２１４は、チャネルのストリームに既に存在する他のストリームレットのＴＴＬの後に満了することになるＴＴＬをストリームレットに割り当てる。例えば、チャネルマネージャ２１４は、ストリームレットを割り当てる時にチャネルｆｏｏのチャネルストリームの各ストリームレットに３分のＴＴＬを割り当てることができる。すなわち、各ストリームレットは、チャネルマネージャ２１４によって割り当てられた（生成された）後に３分で満了することになる。前のストリームレットが閉じた（例えば、完全に満杯になった又は満了した）後に新しいストリームレットが割り当てられるので、チャネルｆｏｏのチャネルストリームは、従って、前のストリームレットが満了した後に各々が順次満了するストリームレットを含む。例えば、図４Ａのチャネルｆｏｏの例示的チャネルストリーム４３０に示されるように、ストリームレット４０９８及び４０９８の前のストリームレットは満了している（点線の網掛けボックスによって表示）。これらの満了したストリームレットに格納されたメッセージは、チャネルｆｏｏの購読者が読み取ることはできない。ストリームレット４０９９、４１００、４１０１、及び４１０２は、アクティブのままである（満了していない）。ストリームレット４０９９、４１００、及び４１０１は、書込に対して閉じているが、読み取ることはできる。ストリームレット４１０２は、メッセージＭ２８がストリームレット４１０２に格納された時点で読み取り、かつ書き込むことができる。後の時間にストリームレット４０９９が満了し、次にストリームレット４１００、４１０１が満了することになる等々である。
【００４５】
図４Ｂは、メッセージングシステム内のチャネルを購読する例示的方法のデータ流れ図である。図４Ｂでは、購読者４８０は、メッセージングシステム１００のＭＸノード４６１との接続４６２を確立する。購読者４８２は、ＭＸノード４６１との接続４６３を確立する。購読者４８５は、メッセージングシステム１００のＭＸノード４６８との接続４６７を確立する。ここで、ＭＸノード４６１及び４６８は、内部ネットワーク２１８を通じてメッセージングシステム１００内のチャネルマネージャ２１４及び１又は２以上のＱノードとそれぞれ通信することができる（４６４）。
【００４６】
購読者（例えば、購読者４８０）は、接続を確立する（例えば、４６２）及びチャネルｆｏｏのメッセージを購読する要求をＭＸノード（例えば、ＭＸノード４６１）に送信することによってメッセージングシステム１００のチャネルｆｏｏを購読することができる。要求（例えば、ＪＳＯＮ鍵／値ペアにおける）は、例えば「ｆｏｏ」のようなチャネル名を含むことができる。購読要求を受信した時に、ＭＸノード４６１は、チャネルマネージャ２１４にチャネルｆｏｏのチャネルストリーム内のストリームレットの読取許可に対する要求を送信することができる。
【００４７】
例証として、現時点でチャネルｆｏｏのチャネルストリーム４３１が図４Ｂに示すようにアクティブストリームレット４１０２、４１０３、及び４１０４を含むと仮定されたい。ストリームレット４１０２及び４１０３は各々が満杯である。ストリームレット４１０４は、位置４７７３１に格納された最後のメッセージ（現時点で）を含むチャネルｆｏｏのメッセージを格納する。ストリームレット４１０１及び４１０１の以前のストリームレットは、このそれぞれのＴＴＬが満了しているので無効である。ストリームレット４１０１のＴＴＬが満了しているためにストリームレット４１０１はもう有効でないので、図４Ａに関して上述したストリームレット４１０１に格納されたメッセージＭ７８、Ｍ１１、Ｍ１３、Ｍ７９、Ｍ１４、Ｍ１２、及びＭ２６はチャネルｆｏｏの購読者に利用できない点に注意されたい。上述のように、チャネルｆｏｏのチャネルストリームの各ストリームレットは、３分のＴＴＬを有し、従って、現在の時間から３分以内にチャネルｆｏｏに発行された（すなわち、チャネルのストリームレットに格納された）メッセージ（チャネルｆｏｏのストリームレットに格納されたもの）だけがチャネルｆｏｏの購読者に利用可能になる。
【００４８】
例えば、購読者４８０がチャネルｆｏｏの新しい購読者である時に、ＭＸノード４６１は、チャネルｆｏｏの全ての利用可能なメッセージの読取許可を要求することができる。要求に基づいて、チャネルマネージャ２１４は、チャネルｆｏｏのアクティブストリームレットの最も早期のストリームレット（すなわち、アクティブストリームレットのシーケンスの第１）であるストリームレット４１０２（Ｑノード２０８上）の読取許可をＭＸノード４６１に提供する。ＭＸノード４６１は、例えば図３Ｂに関して上述したストリームレットからデータを読み取る方法を使用して、Ｑノード２０８からのストリームレット４１０２内のメッセージを取り出すことができる。ストリームレット４１０２から取り出されたメッセージは、ストリームレット４１０２に格納されたのと同じ順序を維持する点に注意されたい。しかし、ストリームレット内のメッセージの他の配置又は順序付けも可能である。様々な実施では、ストリームレット４１０２に格納されたメッセージをＭＸノード４６１に提供する時に、Ｑノード２０８は、メッセージをバッファに（例えば、ローカルデータバッファに）入れて、バッファメッセージが事前に決められた数又はサイズ（例えば、２００メッセージ）に達した又は事前に決められた時間（例えば、５０ミリ秒）が経過した時にＭＸノード４６１にメッセージを送信することができる。例えば、Ｑノード２０８は、ある時間に又は５０ミリ秒毎に２００メッセージでチャネルｆｏｏのメッセージ（ストリームレット４１０２からの）をＭＸノード４６１に送信することができる。ネーグルのアルゴリズムのような他の肯定応答スケジューリングアルゴリズムを使用することもできる。
【００４９】
ストリームレット４１０２の最後のメッセージを受信した後で、ＭＸノード４６１は、肯定応答をＱノード２０８に送信し、チャネルマネージャ２１４にチャネルｆｏｏのチャネルストリームの次のストリームレットに対する別の要求（例えば、読取許可の要求）を送信することができる。要求に基づいて、チャネルマネージャ２１４は、チャネルｆｏｏのアクティブストリームレットのシーケンスでストリームレット４１０２に論理的に続くストリームレット４１０３（Ｑノード４７２上）の読取許可をＭＸノード４６１に提供する。ＭＸノード４６１は、例えば、ストリームレット４１０３に格納された最後のメッセージを取り出すまで図３Ｂに関して上述したストリームレットからデータを読み取る方法を使用して、ストリームレット４１０３に格納されたメッセージを取り出すことができる。ＭＸノード４６１は、次のストリームレット４１０４（Ｑノード４７４上）のメッセージに対する読取許可の別の要求をチャネルマネージャ２１４に送信することができる。読取許可を受信した後で、ＭＸノード４６１は、位置４７７３１の最後のメッセージまでストリームレット４１０４に格納されたチャネルｆｏｏのメッセージを取り出す。同様に、ＭＸノード４６８は、ストリームレット４１０２、４１０３、及び４１０４からメッセージを取り出して（図４Ｂに点線の矢印で図示）、メッセージを購読者４８５に提供することができる。
【００５０】
ＭＸノード４６１は、Ｑノード２０８、４７２、又は４７４からメッセージを受信すると共に購読者４８０に（接続４６２を通じて）チャネルｆｏｏの取り出されたメッセージを送信することができる。様々な実施では、ＭＸノード４６１は、ローカルバッファに取り出されたメッセージを格納することができる。従って、取り出されたメッセージは、他の購読者がチャネルｆｏｏを購読してチャネルのメッセージを要求した時に別の購読者（例えば、購読者４８２）に提供することができる。ＭＸノード４６１は、事前に決められた期間を超えた発行の時間を各々が有するローカルバッファに格納されたメッセージを取り除くことができる。例えば、ＭＸノード４６１は、３分を超える発行のそれぞれの時間を有するメッセージ（ローカルバッファに格納された）を取り除くことができる。一部の実施では、ＭＸノード４６１のローカルバッファにメッセージを維持する事前に決められた期間は、所与の時点でチャネルのストリームから取り出されたメッセージが既に満了しているそれぞれの有効期間を有するストリームレットに含まれないので、チャネルｆｏｏのチャネルストリーム内のストリームレットの有効持続時間と同じか又は類似とすることができる。
【００５１】
チャネルストリーム４３１から取り出されて購読者４８０に（ＭＸノード４６１によって）送信されたメッセージは、メッセージがチャネルストリームに格納されたのと同じ順序で並べられるが、メッセージの他の配置又は順序付けも可能である。例えば、チャネルｆｏｏに発行されたメッセージは、特定の順序（例えば、Ｍ２７、Ｍ３１、Ｍ２９、Ｍ３０など）で並べられてストリームレット４１０２に格納され、続いてストリームレット４１０３及びストリームレット４１０４に格納される。ＭＸノードは、チャネルストリーム４３１からメッセージを取り出して、メッセージがチャネルストリームに格納されたのと同じ順序Ｍ２７、Ｍ３１、Ｍ２９、Ｍ３０などで取り出されたメッセージを購読者４８０に提供し、次にストリームレット４１０３の順序付けられたメッセージ、及び次にストリームレット４１０４の順序付けられたメッセージが続く。
【００５２】
チャネルストリーム４３１の全ての利用可能なメッセージを取り出す代わりに、ＭＸノード４６１は、特定の位置、例えば位置４７２０２のメッセージから開始するチャネルストリーム４３１に格納されたメッセージに対する読取許可を要求することができる。例えば、位置４７２０２は、購読者４８０がチャネルｆｏｏを（例えば、メッセージングシステム１００のＭＸノード４６１又は別のＭＸノードへの接続を通して）最後に購読した時の早期のインスタンス（例えば、現在の時間の１０秒前）に対応することができる。ＭＸノード４６１は、位置４７２０２で開始するメッセージに対する読取許可の要求をチャネルマネージャ２１４に送信することができる。要求に基づいて、チャネルマネージャ２１４は、ストリームレット４１０４（Ｑノード４７４上）の読取許可及びチャネルストリーム位置４７２０２に対応するストリームレット４１０４上の位置をＭＸノード４６１に提供する。ＭＸノード４６１は、提供された位置から開始するストリームレット４１０４のメッセージを取り出して、取り出されたメッセージを購読者４８０に送信することができる。
【００５３】
図４Ａ及び４Ｂに関して上述したように、チャネルｆｏｏに発行されたメッセージは、特定の順序で並べられてチャネルのストリームレットに格納される。チャネルマネージャ２１４は、ストリームレットのそれぞれの有効期間を通して生成される場合のストリームレットの順序付けられたシーケンスを維持する。ＭＸノード（例えば、ＭＸノード４６１、又はＭＸノード４６８）によってストリームレットから取り出されて購読者に提供されたメッセージは、一部の実施では、メッセージがストリームレットの順序付けられたシーケンスで格納されるのと同じ順序にすることができる。従って、異なる購読者（例えば、購読者４８０、購読者４８２、又は購読者４８５）に送信されるメッセージは、購読者が接続されるＭＸノードに関わらず（メッセージがストリームレットに格納されるのと）同じ順序にすることができる。
【００５４】
様々な実施では、ストリームレットは、メッセージのブロックのセットにメッセージを格納する。各ブロックは、いくつかのメッセージを格納する。例えば、ブロックは、２００キロバイトのメッセージを格納することができる。各ブロックは、ブロックを保持するストリームレットの有効期間よりも短い可能性がある固有の有効期間を有する。ブロックのＴＴＬが満了した状態で、図４Ｃに関して以下に詳しく説明するように、ブロックを保持するストリームレットからこのブロックを廃棄することができる。
【００５５】
図４Ｃは、メッセージングシステム内のチャネルのメッセージを格納するための例示的データ構造である。図４Ａ及び４Ｂに関してチャネルｆｏｏで説明したように、現時点で、チャネルｆｏｏのチャネルストリーム４３２が図４Ｃに示すようにアクティブストリームレット４１０４及び４１０５を含むと仮定されたい。ストリームレット４１０３及び４１０３の以前のストリームレットは、このそれぞれのＴＴＬが満了しているので無効である。ストリームレット４１０４はその容量の点で既に満杯であり（例えば、対応する書込許可によって決定されるように）、追加のメッセージ書込に対しては閉じられている。ストリームレット４１０４は、メッセージを読み取ることができる。ストリームレット４１０５は開かれており、メッセージ書込及び読取に利用可能である。
【００５６】
例証として、ストリームレット４１０４（例えば、図４Ｂに示したＱノード４７４で実行されるコンピュータ処理）は、現在２ブロックのメッセージを保持する。ブロック４９４は、チャネル位置４７３０１から４７８５０のメッセージを保持する。ブロック４９５は、チャネル４７８５１から４８０００のメッセージを保持する。ストリームレット４１０５（例えば、メッセージングシステム１００の別のＱノードで実行されるコンピュータ処理）は、現在２ブロックのメッセージを保持する。ブロック４９６は、チャネル位置４８００１から４８２００のメッセージを保持する。ブロック４９７は、チャネル位置４８２０１から開始するメッセージを保持し、チャネルｆｏｏの追加のメッセージを依然として受け入れる。
【００５７】
ストリームレット４１０４が（例えば書込許可によって）生成された時に、第１のブロック（サブバッファ）４９２は、メッセージ、例えば、チャネル位置４７０１０から４７１００のメッセージを格納するために生成される。その後に、ブロック４９２がその容量に達した後で、別のブロック４９３がメッセージ、例えば、チャネル位置４７１１１から４７３００のメッセージを格納するために生成される。ブロック４９４及び４９５は、追加のメッセージを格納するために続けて生成される。その後に、ストリームレット４１０４は、追加のメッセージ書込に対して閉じられ、チャネルｆｏｏの追加のメッセージを格納するための追加のブロックを備えたストリームレット４１０５が生成される。
【００５８】
この例では、ブロック４９２及び４９３のそれぞれのＴＴＬは満了している。これらの２つのブロックに格納されたメッセージ（チャネル位置４７０１０から４７３００）は、チャネルｆｏｏの購読者によって読み取ることはできない。ストリームレット４１０４は、例えばブロック４９２及び４９３に対するメモリ空間の割り当てを解除することによって、これらの２つの満了したブロックを廃棄することができる。ブロック４９４又は４９５は満了になり、ストリームレット４１０４自体が無効になる前にストリームレット４１０４によって廃棄することができる。これに代えて、ストリームレット４１０４自体は、ブロック４９４又は４９５が満了する前に無効になることができる。従って、ストリームレットは、例えばストリームレット及びブロックのそれぞれのＴＴＬに応じて、１又は２以上のメッセージのブロックを保持できるか又はメッセージのブロックを包含しなくてもよい。
【００５９】
ストリームレット、又はメッセージングシステム１００のＱノードで実行されるコンピュータ処理は、Ｑノードからメモリ空間の一定のサイズを割り当てることによってチャネルのメッセージを格納するためのブロックを生成することができる。ストリームレットは、ある時間の１つのメッセージをメッセージングシステム１００のＭＸノードから受信し、受信したメッセージをブロックに格納することができる。これに代えて、ＭＸノードは、メッセージのグループをアセンブリし（すなわちバッファに入れ）、メッセージのグループをＱノードに送信することができる。ストリームレットは、メモリ空間のブロック（Ｑノードからの）を割り当てて、メッセージのグループをブロックに格納することができる。ＭＸノードは、例えば各メッセージから共通ヘッダを取り除くこと又は他の適切な圧縮技術を実行することによって、メッセージのグループに圧縮を行うこともできる。
【００６０】
様々な実施では、メッセージングシステム１００のクライアントデバイスとＭＸノードの間の通信は、鍵／値ペアを備えたＪＳＯＮメッセージを使用して符号化することができるが、他のメッセージ符号化方式も可能である。ＪＳＯＮメッセージは、例えばメッセージングシステム１００によって提供されるアプリケーションプログラミングインタフェース（ＡＰＩ）を通してクライアントデバイスとＭＸノードの間で交換することができる。
【００６１】
例えば、発行者クライアント４０６は、図４Ａに示すように接続４１５を通してメッセージングシステム１００のＭＸノード２０４に接続する。発行者クライアント４０６は、発行要求をＭＸノード２０４に送信する。発行要求は、以下のようにチャネル名「ｆｏｏ」及びメッセージ「Ｈｅｌｌｏ、ｗｏｒｌｄ！」を含むＪＳＯＮメッセージにすることができる。
2019530058.tif 000004
【００６２】
上述の例では、「アクション」は、要求（すなわち、発行）のためのアクションを指定している。ＭＸノード２０４が応答（例えば、メッセージが要求されたチャネルに発行されたことを確認するか又は失敗を報告する）を発行者クライアント４０６に送信した時に、「ｉｄ」を使用することができる。ＭＸノード２０４は、発行要求に指定されたチャネル名「ｆｏｏ」に基づいてメッセージングシステム１００の別々のチャネルにメッセージを割り当てることができる。ＭＸノード２０４は、バッファ又はメッセージングシステム１００のチャネルｆｏｏのチャネルストリーム４３０のストリームレットにメッセージを格納することによってチャネルｆｏｏにメッセージを発行する。
【００６３】
例えば、購読者４８０は、図４Ｂに示すように接続４６２を通してメッセージングシステム１００のＭＸノード４６１に接続する。購読者クライアント４８０は、購読要求をＭＸノード４６１に送信することができる。購読要求は、以下のようにチャネルｆｏｏを含むＪＳＯＮメッセージにすることができる。
2019530058.tif 000005
【００６４】
この例では、要求に対するアクションは購読することである。ＭＸノード４６１は、指定された位置４７２０２から開始するチャネルｆｏｏのチャネルストリーム４３１からメッセージを取り出すことができる。位置が購読要求に指定されていない場合、ＭＸノード４６１は、チャネルｆｏｏのチャネルストリーム４３１内のアクティブストリームレットに格納された利用可能なメッセージの全てを例えば図４Ｂに示すストリームレット４１０２、４１０３、及び４１０４から取り出すことができる。
【００６５】
チャネル購読、メッセージ発行、及び取り出しのようなメッセージングシステム１００のサービスは、顧客に提供することができる。顧客は、顧客のユーザのためのメッセージチャネルを作成することができる。例えば、顧客は、音楽ストリーミングサービスとすることができる。音楽ストリーミングサービスは、ロック、ポップ、及びクラシックのような様々な音楽ジャンルのユーザディスカッションフォーラムとしてメッセージングシステム１００内に特定のチャネルを作成することができる。音楽ストリーミングサービスのユーザは、ユーザのクライアントデバイス上で実行されるクライアントアプリケーションから音楽ストリーミングサービスにアクセスすることができる。その一方、ユーザは、メッセージングシステム１００のこれらの特定のチャネルに対して購読又は発行することにより、ロック、ポップ、又はクラシックのユーザディスカッションフォーラムに参加することもできる。ユーザは、ＪＳＯＮメッセージでの購読又は発行要求をメッセージングシステム１００に送信するクライアントアプリケーションからこれらの特定のチャネルに対して購読又は発行することができる。例えば、ユーザのクライアントアプリケーションは、チャネルポップに対する発行要求（すなわち、ポップミュージックに対するユーザディスカッションフォーラム）を送信することができる（例えばメッセージングシステム１００のＭＸノードへの接続を通して）。
2019530058.tif 000006
【００６６】
ユーザが、メッセージングシステム１００の顧客の特定のチャネルに発行又は購読を要求した時に、メッセージングシステム１００は、ユーザが特定のチャネルにアクセスする許可又は認可を有するか否かを調べることができる。メッセージングシステム１００は、ユーザが、ユーザが実際に主張している人物であることを確かめるためにユーザを認証することもできる。ユーザをそれ自身によって認可又は認証する代わりに、メッセージングシステム１００は、顧客にユーザを認可又は認証するように要求することができる。より具体的には、メッセージングシステム１００は、ユーザの認可又は認証を要求するメッセージを作り、図５に関して以下に詳しく説明するように、このメッセージを顧客によって購読されるメッセージングシステム１００の特定のチャネルに発行することができる。
【００６７】
図５は、メッセージングシステム１００のユーザを認証及び認可する例示的方法５００のデータ流れ図である。例証として、ユーザのクライアントデバイス５０６上で実行されるクライアントアプリケーションは、接続５２０を通してメッセージングシステム１００のＭＸノード５６３に接続することができる。クライアントアプリケーションは、認証要求をＭＸノード５６３に送信することができる。ユーザの認証要求は、ユーザの１又は２以上の資格を含むことができる。例えば、この資格は、クライアントアプリケーションから音楽ストリーミングサービスに登録するためにユーザによって使用され、かつクライアントアプリケーションによってクライアントデバイス５０６に格納されたものとすることができる。例えば、認証要求は、以下のようなものとすることができる。
2019530058.tif 000007
【００６８】
上述の例では、ユーザに対する資格は、ログイン又は識別子（「ｊｏｅ」）及びパスワードである。他のタイプの資格も可能である。要求は、顧客（例えば、音楽ストリーミングサービス）に質問することによって認証のためのアクション及び認証する方法を指定する。以下の例では、クライアント、ＭＸノード、及び顧客モジュール間で渡された情報メッセージがＪＳＯＮに示されている。しかし、他のメッセージフォーマットも可能であり、他のメッセージコンテンツも可能である。これらの例は、１つの可能な実施を示しているに過ぎない。
【００６９】
認証要求に基づいて、ＭＸノード５６３は、以下のように資格をサーバ側認証要求に組み込む。
2019530058.tif 000008
【００７０】
次に、ＭＸノード５６３は、顧客による認証及び認可に固有のサーバ側認証要求をチャネルｍｚ．ａｕｔｈに発行する。例えば、ＭＸノード５６３（例えば、メッセージングシステム１００のチャネルマネージャ２１４によって指示）は、チャネルｍｚ．ａｕｔｈのチャネルストリーム５７０のストリームレット５１０３内の位置５１０６７に認証要求を格納することができる（５２２）。
【００７１】
顧客の顧客モジュール５０８は、チャネルｍｚ．ａｕｔｈを購読することによってｍｚ．ａｕｔｈチャネルからサーバ側認証要求を取り出すことができる。顧客モジュール５０８は、例えば顧客の１又は２以上のサーバ上で実行される１又は２以上のソフトウエア構成要素とすることができる。例えば、顧客モジュール５０８は、接続５２４を通してメッセージングシステム１００のＭＸノード５６５に接続することができる。ＭＸノード５６５は、チャネルストリーム５７０のストリームレット５１０３内の位置５１０６７に格納されたサーバ側認証要求及び顧客モジュール５０８が利用できるチャネルストリーム５７０内の他のメッセージを取り出す（５２６）。次に、ＭＸノード５６５は、ユーザに対するサーバ側認証要求（及び他のメッセージ）を顧客モジュール５０８に提供する。
【００７２】
顧客モジュール５０８は、サーバ側認証要求内のユーザに対する資格をユーザ固有のデータ（例えば、ユーザが顧客の音楽ストリーミングサービスに登録した時にユーザによって提供された資格）と比較することによってユーザを認証することができる。それらが適合した場合、顧客モジュール４０８は、肯定応答を以下のようにｍｚ．ａｕｔｈチャネルに発行することができる。
2019530058.tif 000009
【００７３】
肯定応答は、認証の確認を含む（「ａｃｔｉｏｎ」：「ａｕｔｈ／ａｕｔｈｅｎｔｉｃａｔｅ／ｏｋ」）。肯定応答はまた、以下に説明するように、メッセージングシステム１００の顧客のチャネルにアクセスするためにユーザが使用できるトークンを含むことができる。
【００７４】
サーバ側認証要求の資格が顧客固有のデータに適合しない場合、顧客モジュール４０８は、以下のように否定応答をｍｚ．ａｕｔｈチャネルに発行することができる。
2019530058.tif 000010
【００７５】
接続５２４を通して顧客モジュール５０８から応答（肯定又は否定）を受信した後に、ＭＸノード５６５は、チャネルｍｚ．ａｕｔｈのチャネルストリーム５７０内の次に利用できる位置、例えば、ストリームレット５１０３内のチャネル位置５１９４５に応答を格納する（５２８）。後の時間に、ＭＸノード５６３は、チャネルストリーム５７０から応答を取り出す（５３０）。応答が肯定応答である場合、ＭＸノード５６３は、ユーザ（例えば、ユーザのクライアントデバイス５０６のクライアントアプリケーション）がメッセージングシステム１００及び具体的にはメッセージングシステム１００の顧客のチャネルにアクセスすることを可能にする。応答が否定応答である場合、ＭＸノード５６３は、ユーザがメッセージングシステム１００の顧客のチャネルに更にアクセスすることを禁じるか又は接続５２０を閉じることができる。
【００７６】
上述のように、ユーザを認証するために、メッセージングシステム１００（例えば、ＭＸノード５６３）は、サーバ側認証要求を特定のチャネルｍｚ．ａｕｔｈに発行する。サーバ側認証要求は、特定のチャネルｍｚ．ａｕｔｈの購読者及び発行者である顧客（例えば、顧客モジュール５０８）によって取り出される。顧客は、ユーザのアイデンティティを確認又は不承知とし、応答を特定のチャネルｍｚ．ａｕｔｈに発行する。メッセージングシステム１００は、特定のチャネルｍｚ．ａｕｔｈから応答を取り出し、これに従って動作する（例えば、ユーザがメッセージングシステム１００の顧客のチャネルにアクセスすることを可能にする又は拒否する）。
【００７７】
認証要求及び対応する応答は、特定のチャネルｍｚ．ａｕｔｈのチャネルストリームに格納されるので、それらは、顧客又はクライアント側の再始動又は一時中止のような中断の場合に失われない。対照的に、認証要求及び対応する応答は、これらがインターネットのような通信ネットワークを通してユーザのクライアントデバイスと顧客のサーバの間で直接送信される場合に中断に起因して失われることがある。
【００７８】
追加のセキュリティを提供するために、特定のチャネルｍｚ．ａｕｔｈは、メッセージングシステム１００自体（例えば、ＭＸノード）及び顧客モジュール５０８のような指定された購読及び発行クライアントだけにアクセス可能であるよう構成することができる。他の購読者及び発行クライアント（例えば、顧客の音楽ストリーミングサービスのユーザ又はメッセージングシステム１００の他のユーザ）は、特定のチャネルにアクセスすることはできない（例えば、特定のチャネルを購読又は発行することはできない）。
【００７９】
顧客のユーザを認証することに加えて、メッセージングシステム１００は、顧客のユーザに認可（すなわち、様々なチャネルへの承諾許可）を提供するために特定のチャネルｍｚ．ａｕｔｈを使用することができる。例えば、ユーザのクライアントデバイス５０６のクライアントアプリケーションは、接続５２０を通して以下のように顧客のチャネルロック（音楽ストリーミングサービスのロックミュージックに対するユーザディスカッションフォーラム）を購読する（又は発行する）要求をＭＸノード５６３に送信することができる。
2019530058.tif 000011
【００８０】
上述の購読要求に応答して、ＭＸノード５６３は、例えば以下のようにサーバ側認可要求を作ることができる。
2019530058.tif 000012
【００８１】
サーバ側認可要求は、上述のようにユーザを認証する時に顧客モジュール５０８によって承諾されたユーザのためのトークンを含むことができる。上述したサーバ側認証要求と同様に、ＭＸノード５６３は、チャネルｍｚ．ａｕｔｈのチャネルストリーム５７０へのサーバ側認可要求を格納（発行）する。顧客モジュール５０８は、チャネルｍｚ．ａｕｔｈのチャネルストリーム５７０からサーバ側認可要求を取り出し（例えば、ＭＸノード５６５を通して）、ユーザが１又は２以上の許可規則を満足するか否かを決定し、かつ肯定又は否定応答をチャネルｍｚ．ａｕｔｈのチャネルストリーム５７０に発行する（例えば、ＭＸノード５６５を通して）。許可規則は、以下に詳しく説明するように、チャネル（例えば、チャネルの１又は２以上の名前空間）が適合しなければならないパターンに基づいて要求されたチャネルへのアクセスを承諾又は拒否すると決定することができる。
【００８２】
応答は、以下のように、要求されたチャネルをユーザが購読することを許可又は禁止（それぞれ以下のように）する表示及び満了時間（例えば、ＵＮＩＸ（登録商標）時間で表される）を含むことができる。
2019530058.tif 000013
【００８３】
後の時間に、ＭＸノード５６３は、チャネルｍｚ．ａｕｔｈのチャネルストリーム５７０から応答を取り出す。応答が肯定応答である場合（例えば、ユーザがチャネルロックのメッセージを購読することができる）、ＭＸノード５６３は、チャネルロックのストリーム５５４から利用可能なメッセージを取り出して（５３２）、取り出したメッセージをユーザのクライアント５０６に提供することができる。応答が否定メッセージである場合（例えば、ユーザはチャネルロックのメッセージを購読できない）、ＭＸノード５６３は、ユーザに対してチャネルロックのストリーム５５４からメッセージを取り出さない。
【００８４】
メッセージングシステム１００のＭＸノードから送信された許可要求の承諾又は禁止に加えて、顧客モジュール５０８は、メッセージング１００によって提供されたＡＰＩを通してＪＳＯＮメッセージのような要求を送信することにより、メッセージングシステム１００に許可規則を格納することもできる。例えば、顧客モジュール５０８は、名前空間パターンロック．*（例えば、ここで“*”は適合するパターンのワイルドカードを示す）を有するチャネルの許可規則を追加する要求をＭＸノード５０６に送信することができる。
2019530058.tif 000014
【００８５】
上述の例では、許可規則は、「ｒｏｃｋ．」で始まる名前を持つチャネルがトークンを持つユーザにとってアクセス可能（発行又は購読）とすることができることを指定する（例えば、ユーザは、顧客モジュール５０８によって認証されている）。
【００８６】
要求を受信した後で、ＭＸノード５６５は、メッセージングシステム１００に（例えば、メッセージングシステム１００のデータベースに）要求内の許可規則を格納することができる。
【００８７】
顧客モジュール５０８は、例えば、アクション「ａｃｔｉｏｎ」；「ａｕｔｈ／ｄｒｏｐ□ｐｅｒｍｉｓｓｉｏｎを含めることにより、許可規則をドロップ（削除）する要求をＭＸノード５０６に送信することができる。
【００８８】
メッセージングシステム１００のユーザの認証及び認可は、図６Ａ及び６Ｂに関して以下で更に説明する。
【００８９】
図６Ａは、メッセージングシステム１００のユーザを認証及び認可する別の例示的方法６００のデータ流れ図である。例証として、顧客モジュール５０８は、メッセージングシステム１００の顧客のチャネル、ロック、ポップ、及びクラシックの以下の許可規則を有する。
2019530058.tif 000015
【００９０】
図６Ａでは、ユーザのクライアントデバイス６０２上で実行されるクライアントアプリケーションは、ＭＸノード６０３のようなメッセージングシステム１００に接続する（６１２）。メッセージングシステム１００のＭＸノードに接続した後に、クライアントアプリケーションは、ユーザを認証するためのユーザに対する資格をＭＸノードに送信する（６１４）。ＭＸノードは、サーバ側認証要求を特定のチャネルｍｚ．ａｕｔｈに発行（格納）する。
【００９１】
上述のように、顧客モジュール５０８は、ＭＸノード（例えば、ＭＸノード６０５）を通してメッセージングシステム１００に接続され、かつチャネルｍｚ．ａｕｔｈの購読者及び発行者である。ここで、顧客モジュール５０８は、ｍｚ．ａｕｔｈのチャネルストリームからサーバ側認証要求を受信し（６１６）（ＭＸノード６０５を通して）、資格に基づいてユーザのアイデンティティを確認し、肯定応答をｍｚ．ａｕｔｈチャネルに発行する（６１８）。ＭＸノード６０３は、肯定応答を取り出し、肯定確認をクライアントデバイス６０２に送信する（６２０）。顧客モジュール５０８が肯定応答を有するトークンを提供した場合、ＭＸノード６０３は、後の使用のためにトークンを格納する。
【００９２】
例えば、ユーザは、顧客のチャネルロックを購読する要求をＭＸノード６０３に送信することができる（６２２）（クライアントデバイス６０２のクライアントアプリケーションを通して）。ＭＸノード６０３は、ユーザに対するチャネルロックのサーバ側認可要求をｍｚ．ａｕｔｈチャネルに発行する。顧客モジュール５０８は、ｍｚ．ａｕｔｈチャネルからサーバ側認可要求を受信し（６２４）、この要求を上述の許可規則と比較する。許可規則は、チャネルロックの購読を許可するので、顧客モジュール５０８は、肯定応答をｍｚ．ａｕｔｈチャネルに発行する（６２６）。ＭＸノード６０３は、ｍｚ．ａｕｔｈチャネルから肯定応答を取り出し、肯定確認をクライアントデバイス６０２に送信する（６２８）。肯定確認に基づいて、ＭＸノード６０３は、チャネルロックからメッセージを取り出すことができ、取り出したメッセージをクライアントデバイス６０２に提供する（６３０）。
【００９３】
例えば、ユーザは、顧客のチャネルポップを購読する要求をＭＸノード６０３に送信することができる（６３２）（クライアントデバイス６０２のクライアントアプリケーションを通して）。ＭＸノード６０３は、ユーザに対するチャネルポップのサーバ側認可要求をｍｚ．ａｕｔｈチャネルに発行する。顧客モジュール５０８は、ｍｚ．ａｕｔｈチャネルからサーバ側認可要求を受信し（６３４）、この要求を上述の許可規則と比較する。許可規則は、チャネルポップの購読を禁じるので、顧客モジュール５０８は、否定応答をｍｚ．ａｕｔｈチャネルに発行する（６３６）。ＭＸノード６０３は、ｍｚ．ａｕｔｈチャネルから否定応答を取り出し、否定確認をクライアントデバイス６０２に送信する（６３８）。この場合には、ＭＸノード６０３は、ユーザのチャネルポップからメッセージを取り出さない。
【００９４】
例えば、ユーザは、顧客のチャネルクラシックを購読する要求をＭＸノード６０３に送信することができる（６４２）（クライアントデバイス６０２のクライアントアプリケーションを通して）。ＭＸノード６０３は、ユーザに対するチャネルクラシックのサーバ側認可要求をｍｚ．ａｕｔｈチャネルに発行する。顧客モジュール５０８は、ｍｚ．ａｕｔｈチャネルからサーバ側認可要求を受信し（６４４）、この要求を上述の許可規則と比較する。許可規則は、チャネルクラシックのトークンによる購読を許可するので、顧客モジュール５０８は、有効トークンの条件で肯定応答をｍｚ．ａｕｔｈチャネルに発行する（６４６）。ＭＸノード６０３は、ｍｚ．ａｕｔｈチャネルから肯定応答を取り出し、ユーザがメッセージングシステム１００に格納された有効トークンを有することを確認し、次に、肯定応答をクライアントデバイス６０２に送信する（６４８）。肯定確認に基づいて、ＭＸノード６０３は、チャネルクラシックからメッセージを取り出すことができ、取り出したメッセージをクライアントデバイス６０２に提供する（６４９）。
【００９５】
図６Ｂは、メッセージングシステム１００のユーザを認証及び認可する別の例示的方法６５０のデータ流れ図である。この例では、顧客モジュール５０８は、上述の許可規則をｍｚ．ａｕｔｈチャネルに発行する（６６２）。メッセージングシステム１００は、許可規則データベース６６５に許可規則を格納する（キャッシュに入れる）ことができる。
【００９６】
例えば、ユーザは、顧客のチャネルロックを購読する要求をＭＸノード６０３に送信することができる（６７２）（クライアントデバイス６０２のクライアントアプリケーションを通して）。チャネルｍｚ．ａｕｔｈにサーバ側認可要求を発行する代わりに、ＭＸノード６０３は、許可規則データベース６６５に格納された許可規則にアクセスし、かつユーザがチャネルロックを購読することができると決定する。ＭＸノード６０３は、肯定確認をクライアントデバイス６０２に送信する（６７４）。次に、ＭＸノード６０３は、チャネルロックからメッセージを取り出し、取り出したメッセージをクライアントデバイス６０２に提供する（６７６）。
【００９７】
例えば、ユーザは、顧客のチャネルポップを購読する要求をＭＸノード６０３に送信することができる（６８２）（クライアントデバイス６０２のクライアントアプリケーションを通して）。ＭＸノード６０３は、許可規則データベース６６５に格納された許可規則にアクセスし、かつユーザが許可規則に基づいてチャネルポップを購読することができないと決定し、否定確認をクライアントデバイス６０２に送信する（６８４）。
【００９８】
例えば、ユーザは、顧客のチャネルクラシックを購読する要求をＭＸノード６０３に送信することができる（６９２）（クライアントデバイス６０２のクライアントアプリケーションを通して）。ＭＸノード６０３は、許可規則データベース６６５に格納された許可規則にアクセスし、かつユーザが有効トークンによってチャネルポップを購読することができると決定する。
【００９９】
例証として、メッセージングシステム１００に格納されたユーザに関連付けられる有効トークンがないことをとりあえず仮定されたい（例えば、以前のトークンが満了した時、又はメッセージングシステム１００がユーザを認証していない時）。ＭＸノード６０３は、ユーザに対する資格を取得し（例えば、クライアントデバイス６０２上で実行されるクライアントアプリケーションから）、ユーザに対する資格を備えたサーバ側認証要求をチャネルｍｚ．ａｕｔｈに発行することができる。顧客モジュール５０８は、ｍｚ．ａｕｔｈチャネルからサーバ側認証要求を受信し（６９４）、ユーザ固有のデータでユーザに対する資格を検証し、肯定応答をチャネルｍｚ．ａｕｔｈに発行する（６９６）。ＭＸノード６０３は、チャネルｍｚ．ａｕｔｈから肯定応答を取り出し、肯定確認をクライアントデバイス５０２に送信する（６９８）。肯定確認に基づいて、次に、ＭＸノード６０３は、チャネルクラシックからメッセージを取り出し、取り出したメッセージをクライアントデバイス６０２に提供する（６９９）。
【０１００】
様々な実施では、購読又は発行クライアントから要求されたチャネルへのアクセスを承諾又は拒否するための許可規則は、チャネルの１又は２以上の名前空間が適合しなくてはならないパターンを含むことができる。例証として、許可規則は、以下のようなものとすることができる。
【０１０１】
（表）
2019530058.tif 000016
【０１０２】
上述の許可規則では、アクションタイプ（発行又は購読）は、例証の目的で省かれている。”＊”は、適合パターンのワイルドカードを示している。要求されたチャネルに対して、要求されたチャネルの名前空間を含む可能なチャネル名パターンのリストが生成される。次に、リストは、最も適合するチャネル名パターンから始まって最も適合しないチャネル名パターンまで許可規則内の許可パターンと比較される。適合が見つからなかった場合、事前に決められた許可タイプ（例えば、許可）を使用することができる。以下の表は、例示的チャネル名、各例示的チャネル名に対してその可能なチャネル名パターン、及び上述の表に列挙された許可規則にパターンがどのように適合するかを列挙している。
【０１０３】
（表）
2019530058.tif 000017
【０１０４】
図７は、メッセージングシステムのメッセージチャネルの購読及び発行を認可する例示的方法の流れ図である。本発明の方法は、例えば、ＭＸノード（例えば、図５のＭＸノード５６３）を使用して実施することができる。本方法は、１又は２以上の購読要求を受信することによって開始され、各購読要求は、それぞれのクライアントから受信され、かつそれぞれのチャネルのためのものである（７０２）。本方法は、購読要求の１又は２以上を認可し、各認可された購読要求は、要求のクライアントが要求のチャネルに発行されたメッセージを受信することを許可する（７０４）。本方法は、発行のための１又は２以上のメッセージを受信し、各メッセージは、それぞれのクライアントから受信されたものであり、かつそれぞれのチャネル上での発行のためのものである（７０６）。メッセージの各々に対して、本方法は、メッセージのチャネルのためのそれぞれのバッファにメッセージを入れ、メッセージは、バッファに関する有限有効期間中にバッファに存在する（７０８）。チャネルバッファの１又は２以上に対して、本方法は、チャネルを購読することを認可されたクライアントにバッファ内のあらゆるメッセージを送信する（７１０）。
【０１０５】
本明細書に説明する主題及び作動の実施形態は、本明細書及び本明細書の構造的均等物又はこれらの１又は２以上の組合せで開示する構造を含むデジタル電子回路、又はコンピュータソフトウエア、ファームウエア、又はハードウエアを用いて実施することができる。本明細書に説明する主題の実施形態は、１又は２以上のコンピュータプログラムとして、すなわち、デジタル処理装置によって実行するために又はその作動を制御するためにコンピュータストレージ媒体上に符号化されるコンピュータプログラム命令の１又は２以上のモジュールとして実施することができる。これに代えて又はこれに加えて、プログラム命令は、人工的に生成された伝播信号、例えば、データ処理装置によって実行するのに適する受信装置に送信する情報を符号化するために生成される機械発生式電気、光学、又は電磁信号で符号化することができる。コンピュータストレージ媒体は、コンピュータ可読ストレージデバイス、コンピュータ可読ストレージ基板、ランダム又はシリアルアクセスメモリアレイ又はデバイス、又はこれらの１又は２以上の組合せとすることができ、又はこれらに含めることができる。更に、コンピュータストレージ媒体は伝播信号ではないが、コンピュータストレージ媒体は、人工的発生式伝播信号で符号化されたコンピュータプログラム命令のソース又は宛先とすることができる。コンピュータストレージ媒体は、１又は２以上の個別の物理的構成要素又は媒体（例えば、複数のＣＤ、ディスク、又は他のストレージデバイス）とすることができ、又はこれらに含めることができる。
【０１０６】
本明細書に説明する作動は、１又は２以上のコンピュータ可読ストレージデバイスに格納されたか又は他のソースから受信したデータにデータ処理装置によって実行される作動として実施することができる。
【０１０７】
「データ処理装置」という語は、一例として、プログラマブルプロセッサ、コンピュータ、システムオンチップ、又はマルチプロセッサ、又は上述の組合せを含むデータを処理するための全ての種類の装置、デバイス、及び機械を網羅する。装置は、専用論理回路、例えば、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）又はＡＳＩＣ（特定用途向け集積回路）を含むことができる。装置は、ハードウエアに加えて、問題のコンピュータプログラムのための実行環境を生成するコード、例えば、プロセッサファームウエア、プロトコルスタック、データベース管理システム、オペレーティングシステム、クロスプラットフォーム実行時間環境、仮想機械、又はこれらの１又は２以上の組合せを構成するコードを含むことができる。装置及び実行環境は、ウェブサービス、分散コンピュータ及びグリッドコンピュータインフラストラクチャーのような様々な異なるコンピュータモデルインフラストラクチャーを実現することができる。
【０１０８】
コンピュータプログラム（プログラム、ソフトウエア、ソフトウエアアプリケーション、スクリプト、又はコードとしても公知）は、コンパイル又は解釈言語、宣言、手順、又は機能言語を含むプログラミング言語のあらゆる形態で書くことができ、独立プログラムとして又はモジュール、構成要素、サブルーチン、オブジェクト、又はコンピュータ環境に使用するのに適する他のユニットとして含むいずれの形態でも配備することができる。コンピュータプログラムは、ファイルシステムのファイルに対応することができるが、対応する必要はない。プログラムは、他のプログラム又はデータ（例えば、マークアップ言語リソースに格納された１又は２以上のスクリプト）を保持するファイルの一部分に、問題のプログラム専用単一ファイルに、又は複数の調節されたファイル（例えば、１又は２以上のモジュール、サブプログラム、又はコードの一部分を格納するファイル）に格納することができる。コンピュータプログラムは、１つのコンピュータ又は１つのサイトに位置するか又は複数のサイトにわたって分散されて通信ネットワークによって相互接続された複数のコンピュータで実行されるように配備される。
【０１０９】
本明細書に説明した処理及び論理フローは、１又は２以上のコンピュータプログラムを実行する１又は２以上のプログラマブルプロセッサによって実行され、入力データを演算して出力を生成することによってアクションを実行することができる。処理及び論理フローは、専用論理回路、例えば、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）又はＡＳＩＣ（特定用途向け集積回路）によって実行することができ、装置は、専用論理回路、例えば、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）又はＡＳＩＣ（特定用途向け集積回路）として実施することができる。
【０１１０】
コンピュータプログラムの実行に適するプロセッサは、一例として、汎用及び専用マイクロプロセッサの両方、及びあらゆる種類のデジタルコンピュータのいずれか１つ又はそれよりも多いプロセッサを含む。一般的に、プロセッサは、読取専用メモリ又はランダムアクセスメモリ又はこれらの両方から命令及びデータを受信する。コンピュータの基本的な要素は、命令に従ってアクションを実行するためのプロセッサ、及び命令及びデータを格納するための１又は２以上のメモリデバイスである。一般的にコンピュータは、データを格納するための１又は２以上の大容量ストレージデバイス、例えば、磁気ディスク、磁気光学ディスク、光学ディスク、又は固体ドライブを含むか、これらからデータを受信するか又はデータを転送し、又はこの両方のために作動的に結合される。しかし、コンピュータは、そのようなデバイスを有する必要はない。コンピュータは、別のデバイス、いくつか挙げると、例えば、スマートフォン、移動音声又は映像プレーヤ、ゲームコンソール、全地球測位システム（ＧＰＳ）受信機、又は携帯式ストレージデバイス（例えば、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ）に組み込むことができる。コンピュータプログラム命令及びデータを格納するのに適するデバイスは、一例として、半導体メモリデバイス、例えば、ＥＰＲＯＭ、ＥＥＰＲＯＭ、及びフラッシュメモリデバイス、磁気ディスク、例えば、内部ハードディスク又は着脱可能ディスク、磁気光学ディスク、及びＣＤ−ＲＯＭ及びＤＶＤ−ＲＯＭディスクを含む不揮発性メモリ、媒体、及びメモリデバイスの全ての形態を含む。プロセッサ及びメモリは、専用論理回路によって補足又は専用論理回路に組み込むことができる。
【０１１１】
ユーザとの対話を提供するために、本明細書に説明する主題の実施形態は、ディスプレイデバイス、例えば、ユーザに情報を表示するためのディスプレイデバイス、例えば、ＣＲＴ（ブラウン管）又はＬＣＤ（液晶ディスプレイ）モニタ、及びキーボード及びポインティングデバイス、例えば、ユーザがコンピュータに入力を与えることを可能にするマウス、トラックボール、タッチパッド、又はスタイラスを有するコンピュータを用いて実施することができる。他の種類のデバイスを使用して、同様にユーザとの対話を提供することができ、例えば、ユーザに提供されるフィードバックは、センサ式フィードバックのあらゆる形態、例えば、視覚フィードバック、聴覚フィードバック、又は触知フィードバックとすることができ、ユーザからの入力は、音響、音声、又は触知入力を含むあらゆる形態で受信することができる。コンピュータは、ユーザによって使用されるデバイスにリソースを送信し、デバイスからリソースを受信することにより、例えば、ウェブブラウザから受信した要求に応じてユーザのクライアントデバイスのウェブブラウザにウェブページを送信することによってユーザと対話することができる。
【０１１２】
本明細書に説明する主題の実施形態は、バックエンド構成要素を例えばデータサーバとして含むか、又はミドルウェア構成要素、例えば、アプリケーションサーバを含むか、又はフロントエンド構成要素、例えば、ユーザが本明細書に説明する主題の実施と対話することを可能にするグラフィカルユーザインタフェース又はウェブブラウザを有するクライアントコンピュータ、又は１又は２以上のこれらのバックエンド、ミドルウェア、又はフロントエンド構成要素のあらゆる組合せを含むコンピュータシステムを用いて実施することができる。システムの構成要素は、デジタルデータ通信のあらゆる形態又は媒体、例えば、通信ネットワークによって相互接続することができる。通信ネットワークの例は、ローカルエリアネットワーク（「ＬＡＮ」）及びワイドエリアネットワーク（「ＷＡＮ」）、インターネットワーク（例えば、インターネット）及びピアツーピアネットワーク（例えば、アドホックピアツープアネットワーク）を含む。
【０１１３】
コンピュータシステムは、クライアント及びサーバを含むことができる。クライアント及びサーバは、一般的に互いから遠隔にあり、一般的に通信ネットワーク上で対話する。クライアントとサーバの関係は、それぞれのコンピュータで実行されて互いにクライアント−サーバ関係を有するコンピュータプログラムによって発生する。一部の実施形態では、サーバは、データ（例えば、ＨＴＭＬページ）をクライアントデバイスに送信する（クライアントデバイスと対話するユーザにデータを表示してユーザからユーザ入力を受信するために）。クライアントデバイスで生成されたデータ（例えば、ユーザ対話の結果）は、サーバでクライアントデバイスから受信することができる。
【０１１４】
１又は２以上のコンピュータのシステムは、作動中にシステムにアクションを実行させるシステム上にインストールされたソフトウエア、ファームウエア、ハードウエア、又はその組合せを有することによって特定の作動又はアクションを実行するように構成することができる。１又は２以上のコンピュータプログラムは、データ処理装置によって実行された時に装置にアクションを実行させる命令を含むことによって特定の作動又はアクションを実行するように構成することができる。
【０１１５】
本明細書は多くの特定の実施の詳細を含有するが、それらは、いずれの発明又は主張することができる範囲の制限として解釈すべきではなく、逆に特定の発明の特定の実施形態に固有の特徴の説明として解釈しなければならない。個別の実施形態の関連で本明細書に説明するある一定の特徴は、単一実施形態に組み合わせて実施することができる。対照的に、単一実施形態の関連で説明する様々な特徴は、複数の実施形態で別々に又はあらゆる適切な部分組合せを用いて実施することができる。更に、特徴は、ある一定の組合せで作用するように上述し、更にそのように最初に主張したが、主張した組合せからの１又は２以上の特徴は、一部の事例では組合せから削除することができ、主張した組合せを部分組合せ又は部分組合せの変形に向けることができる。
【０１１６】
同様に、作動は、特定の順序で図面に示されているが、これは、望ましい結果を達成するためにそのような作動を示された特定の順序又は連続的な順序で実行し、又は全ての例示された作動を実行することが望ましいとして理解すべきではない。ある状況では、マルチタスク及び並列処理が有利である場合がある。上述の実施形態における様々なシステム構成要素の分離は、全ての実施形態においてそのような分離を要求するものとして理解すべきではなく、説明したプログラム構成要素及びシステムは、一般的に単一ソフトウエア製品に互いに統合するか又は複数のソフトウエア製品にパッケージ化することができることを理解しなければならない。
【０１１７】
すなわち、本主題の特定の実施形態を説明した。他の実施形態も特許請求の範囲内である。一部の事例では、特許請求の範囲に説明するアクションを異なる順序で実行して望ましい結果を達成することができる。更に、添付の図に示す処理は、望ましい結果を達成するために必ずしも示す特定の順序又は連続的な順序を必要としない。ある一定の実施では、マルチタスク及び並列処理が有利である場合がある。
【０１１８】
特許請求するのは、以下のものである。
【符号の説明】
【０１１９】
５００  メッセージングシステムのユーザを認証及び認可する例示的方法
５０６  クライアント
５０８  顧客モジュール
５５８  チャネルクラシック
５６３、５６５  ＭＸノード
【図１Ａ】
2019530058.tif 000018
【図１Ｂ】
2019530058.tif 000019
【図２】
2019530058.tif 000020
【図３Ａ】
2019530058.tif 000021
【図３Ｂ】
2019530058.tif 000022
【図４Ａ】
2019530058.tif 000023
【図４Ｂ】
2019530058.tif 000024
【図４Ｃ】
2019530058.tif 000025
【図５】
2019530058.tif 000026
【図６Ａ】
2019530058.tif 000027
【図６Ｂ】
2019530058.tif 000028
【図７】
2019530058.tif 000029
【国際調査報告】
2019530058.tif 000030
2019530058.tif 000031