特許 5898980 ネットワーク環境において非持続性のメッセージの複数のキューを管理する方法、システム及び記憶媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5898980

(24)【登録日】2016年3月11日

(45)【発行日】2016年4月6日

(54)【発明の名称】ネットワーク環境において非持続性のメッセージの複数のキューを管理する方法、システム及び記憶媒体

(51)【国際特許分類】

   G06F 13/00 20060101AFI20160324BHJP

【ＦＩ】

   G06F13/00 540C

【請求項の数】21

【全頁数】30

(21)【出願番号】特願2012-19956(P2012-19956)

(22)【出願日】2012年2月1日

(65)【公開番号】特開2012-160189(P2012-160189A)

(43)【公開日】2012年8月23日

【審査請求日】2014年12月10日

(31)【優先権主張番号】13/019,505

(32)【優先日】2011年2月2日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】511269886

【氏名又は名称】インヴュー，インコーポレイテッド

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(72)【発明者】

【氏名】ジョン ワット

【審査官】 古河 雅輝

(56)【参考文献】

【文献】 特開２００８−００５４４９（ＪＰ，Ａ）

【文献】 特開２００２−１４９６１９（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００４／０２４０４６２（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

Ｇ０６Ｆ １５／００

Ｇ０６Ｆ １９／００

Ｇ０６Ｑ １０／００−１０／１０

Ｇ０６Ｑ ３０／００−３０／０８

Ｇ０６Ｑ ５０／００−５０／２０

Ｇ０６Ｑ ５０／２６−９９／００

Ｈ０４Ｌ １２／００−１２／２６

Ｈ０４Ｌ １２／５０−１２／９５５

(57)【特許請求の範囲】

【請求項1】

ゲートウェイのプロセスにおいて非持続性のメッセージを受信する段階であって、該メッセージは、該メッセージが送られるべき名前を付されたキューを示す情報を含む、段階と；
データプロセッサにより、前記名前を付されたキューを、該キューについての一貫性のあるハッシュを用いてキューノードへマッピングする段階であって、該マッピングする段階は、前記名前を付されたキューを示す前記情報に対応する前記の受信したメッセージの一部のハッシュを生成する段階と、前記の生成したハッシュを用いて対応するキューノードを識別する段階と、を有し、前記マッピングする段階は、前記キューノードと別個のキューノードマッパーにより実行される、段階と；
前記キューノードにおいて前記メッセージをキューのプロセスへマッピングする段階と；
前記キューのプロセスにより、購読者のゲートウェイのリストへアクセスする段階と；
前記メッセージを前記リストの中の、前記購読者のゲートウェイの夫々へルーティングする段階と；
を有する、方法。

【請求項2】

ゲートウェイとクライアントとの間の持続性のコネクションを保持する段階
を含む、請求項１に記載の方法。

【請求項3】

前記クライアントを、前記名前を付されたキューのリスナとして登録する段階
を含む、請求項２に記載の方法。

【請求項4】

前記登録する段階は、メッセージハンドラコールバックを提供する段階を含む、
請求項３に記載の方法。

【請求項5】

前記名前を付されたキューの前記キューノードへの前記マッピングを管理するためのスーパーバイザのプロセスを用いる段階
を含む、請求項１に記載の方法。

【請求項6】

前記キューノードにおけるメッセージストリームと状態ストリームをマウントする段階
を含む、請求項１に記載の方法。

【請求項7】

ホットノード追加のプロセスにおいて、前記キューノードの状態を新しいキューノードへ移行する段階
を含む、請求項１に記載の方法。

【請求項8】

前記ゲートウェイのプロセスにおいて、トランスレータのプロセスを用いて、前記非持続性のメッセージを受信する段階
を含む、請求項１に記載の方法。

【請求項9】

前記キューノードの状態を更新するために状態マネージャサービスを用いる段階
を含む、請求項１に記載の方法。

【請求項10】

ログイン時にシステムチャットキューとバディ状態キューのためにユーザを購読する段階
を含む、請求項１に記載の方法。

【請求項11】

データプロセッサと；
ネットワークへのアクセスのために前記プロセッサとデータ通信するネットワーク接続と；
メッセージキューシステムモジュールであって：
ゲートウェイのプロセスにおいて非持続性のメッセージを受信し、該メッセージは、該メッセージが送られるべき該メッセージが送られるべき名前を付されたキューを示す情報を含み；
前記名前を付されたキューを、該キューについての一貫性のあるハッシュを用いてキューノードへマッピングし、該マッピングは、前記名前を付されたキューを示す前記情報に対応する前記の受信したメッセージの一部のハッシュを生成し、前記の生成したハッシュを用いて対応するキューノードを識別することを有し、前記マッピングは、前記キューノードと別個のキューノードマッパーにより実行され；
前記キューノードにおいて前記メッセージをキューのプロセスへマッピングし；
前記キューのプロセスにより、購読者のゲートウェイのリストへアクセスし；
前記メッセージを前記リストの中の、前記購読者のゲートウェイの夫々へルーティングする；
ために、前記プロセッサにより実行可能な、メッセージキューシステムモジュールと；
を有する、システム。

【請求項12】

ゲートウェイとクライアントとの間の持続性のコネクションを保持する
ようさらに構成される、請求項１１に記載のシステム。

【請求項13】

前記クライアントを、前記名前を付されたキューのリスナとして登録する
ようさらに構成される、請求項１２に記載のシステム。

【請求項14】

前記登録は、メッセージハンドラコールバックの提供を含む、
請求項１３に記載のシステム。

【請求項15】

前記名前を付されたキューの前記キューノードへの前記マッピングを管理するためのスーパーバイザのプロセスを用いる
ようさらに構成される、請求項１１に記載のシステム。

【請求項16】

前記キューノードにおけるメッセージストリームと状態ストリームをマウントする
ようさらに構成される、請求項１１に記載のシステム。

【請求項17】

ホットノード追加のプロセスにおいて、前記キューノードの状態を新しいキューノードへ移行する
ようさらに構成される、請求項１１に記載のシステム。

【請求項18】

前記ゲートウェイのプロセスにおいて、トランスレータのプロセスを用いて、前記非持続性のメッセージを受信する
ようさらに構成される、請求項１１に記載のシステム。

【請求項19】

前記キューノードの状態を更新するために状態マネージャサービスを用いる
ようさらに構成される、請求項１１に記載のシステム。

【請求項20】

ログイン時にシステムチャットキューとバディ状態キューのためにユーザを購読する
ようさらに構成される、請求項１１に記載のシステム。

【請求項21】

コンピュータ読み取り可能な記憶媒体であって、コンピュータにより実行される場合に、該コンピュータに：
ゲートウェイのプロセスにおいて非持続性のメッセージを受信させ、該メッセージは、該メッセージが送られるべき名前を付されたキューを示す情報を含み；
前記名前を付されたキューを、該キューについての一貫性のあるハッシュを用いてキューノードへマッピングさせ、該マッピングは、前記名前を付されたキューを示す前記情報に対応する前記の受信したメッセージの一部のハッシュを生成し、前記の生成したハッシュを用いて対応するキューノードを識別することを有し、前記マッピングは、前記キューノードと別個のキューノードマッパーにより実行され；
前記キューノードにおいて前記メッセージをキューのプロセスへマッピングさせ；
前記キューのプロセスにより、購読者のゲートウェイのリストへアクセスさせ；
前記メッセージを前記リストの中の、前記購読者のゲートウェイの夫々へルーティングさせる；
命令を記録した、コンピュータ読み取り可能な記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、一実施形態に従って、ネットワーク化された構成要素（entity）とともに使用する方法、システム及び記憶媒体に関し、特には、ネットワーク環境において非持続性の（non-persistent）メッセージの複数のキュー（multiple queue）を管理する方法、システム及び記憶媒体に関する。

【0002】

本明細書の開示の一部は、著作権保護の対象である素材を含む。著作権者は、特許庁のファイル又は記録の中に現れるように、明細書又は特許の開示についての複製に反対しないが、そうでない場合には、いかなる著作権も留保する。次の掲示は、以下で説明され、当該文書の一部を形成する図面の中で示される、ソフトウェア及びデータへ適用される。
Copyright 2009-2011 IMVU Corporation, All Rights Reserved

【背景技術】

【0003】

ネットワーク化されたコンピュータ環境における、チャット又はインスタントメッセージング通信の使用は、よく知られている。America Online（登録商標）インスタントメッセージングシステム（AIM）は、ネットワーク環境においてインスタントメッセージを制御するための、よく知られたシステムの一つである。これらの既存のシステムにおいて、二つのコンピュータのユーザは、インスタントメッセージ（IM）サーバと連携するコンピュータ上で、インスタントメッセージ（IM）クライアントを用いて、非持続性のテキストメッセージをリアルタイムでやりとりすることができる。

【0004】

ほとんどのメッセージングサービスは、購読ベース又はユーザ識別ベースであり、多数のコンテンツのファン（follower）、又は特定のメッセージ又はコンテンツソースの多数のユーザ（ここでは購読者（subscriber）と呼ぶ）を生ずる。これらのコンテンツのファン又は購読者は、特定のコンテンツソース又はコンテンツ流通システムの周りに、コミュニティ又はソーシャルネットワークを形成し得る。ソーシャルネットワークは、人々が、互いに連絡するための基礎として、メッセージングを用いるようになるにつれて、普及している。

【発明の概要】

【発明が解決しようとする課題】

【0005】

ユーザのプール（user pool）、購読者及びソーシャルネットワークの数及び規模が拡大するにつれて、購読者、リスニングユーザ及びメッセージコンテンツに関与したユーザの程度を追跡し、管理することがより困難になっている。同様に、様々なコンテンツソース及びソーシャルネットワークにわたって使用される、最も人気のあるコンテンツ項目を特定し、ランク付けすることは、より困難になっている。従って、ネットワーク環境における非持続性のメッセージの複数のキューを管理するシステム及び方法が必要とされている。

【課題を解決するための手段】

【0006】

ネットワーク環境において非持続性のメッセージの複数のキューを管理するためのシステム及び方法が開示される。

【0007】

一つの特定の実施形態における方法は、ゲートウェイのプロセスにおいて非持続性のメッセージを受信する段階であって、該メッセージは、名前を付されたキューを示す情報を含む、段階と；データプロセッサにより、前記名前を付されたキューを、該キューについての一貫性のあるハッシュを用いてキューノードへマッピングする段階と；前記キューノードにおいて前記メッセージをキューのプロセスへマッピングする段階と；前記キューのプロセスにより、購読者のゲートウェイのリストへアクセスする段階と；前記メッセージを前記リストの前記購読者の中の、ゲートウェイの夫々へルーティングする段階と；を有する。

【0008】

また、別の実施形態におけるシステムは、データプロセッサと；ネットワークへのアクセスのために前記プロセッサとデータ通信するネットワーク接続と；メッセージキューシステムモジュールであって：ゲートウェイのプロセスにおいて非持続性のメッセージを受信し、該メッセージは、名前を付されたキューを示す情報を含み；前記名前を付されたキューを、該キューについての一貫性のあるハッシュを用いてキューノードへマッピングし；前記キューノードにおいて前記メッセージをキューのプロセスへマッピングし；前記キューのプロセスにより、購読者のゲートウェイのリストへアクセスし；前記メッセージを前記リストの中の、前記購読者のゲートウェイの夫々へルーティングする；ために、前記プロセッサにより実行可能な、メッセージキューシステムモジュールと；を有する。

【0009】

また、別の実施形態におけるコンピュータ読み取り可能な記憶媒体は、コンピュータにより実行される場合に、該コンピュータに：ゲートウェイのプロセスにおいて非持続性のメッセージを受信させ、該メッセージは、名前を付されたキューを示す情報を含み；前記名前を付されたキューを、該キューについての一貫性のあるハッシュを用いてキューノードへマッピングさせ；前記キューノードにおいて前記メッセージをキューのプロセスへマッピングさせ；前記キューのプロセスにより、購読者のゲートウェイのリストへアクセスさせ；前記メッセージを前記リストの中の、前記購読者のゲートウェイの夫々へルーティングさせる；命令を記録した、コンピュータ読み取り可能な記憶媒体である。

【0010】

いくつかの実施形態は、例示する目的によって説明されるものであって、限定を目的とするものではない。

【図面の簡単な説明】

【0011】

【図1】一つの例示的な実施形態のメッセージキューシステムの要素を表す図。

【図2】一つの例示的な実施形態のゲートウェイ１２の要素を表す図。

【図3】一つの例示的な実施形態のメッセージキューの要素を表す図。

【図4】一つの例示的な実施形態のメッセージキューの要素を表す図。

【図5】一つの例示的な実施形態の一貫性のあるハッシュ（consistent hash）処理を表す図。

【図6】一つの例示的な実施形態におけるメッセージ処理を表す図。

【図7】一つの例示的な実施形態のホットノード追加（hot add node）処理を表す図。

【図8】ネットワーク環境において非持続性のメッセージの複数のキューを管理するシステム及び方法についての一つの例示的な実施形態を表す図。

【図9】いくつのかの実施形態が動作するネットワークシステムについての別の例示的な実施形態を表す図。

【図10】当該開示書で説明されるメッセージキューシステムにおける処理の一つの例示的な実施形態を説明する処理フローチャートを表す図。

【図11】当該開示書で説明される一つ以上のあらゆる手順をコンピュータに実行させることのできる命令の組を含む、例示的なコンピュータシステムの方式におけるコンピュータを表す図。

【発明を実施するための形態】

【0012】

次の記載において、説明を目的として、様々な実施形態の完全な理解を提供するために、数多くの特定の詳細が説明される。しかしながら、当業者は、これらの特定の詳細がなくとも、様々な実施形態を実施し得ることは明らかであろう。

【0013】

（いくつかの例示的な実施形態の説明）
特定の実施形態のメッセージキューシステムは、拡張性があり、効率的で、セキュアで、柔軟で、かつ容易に理解される、メッセージと状態更新のスイッチング（switching）及びルーティングファブリック（routing fabric）を実装する、スタンドアロンのソフトウェアスタックである。メッセージキューシステムは、堅牢であって、クライアントが接続し、クライアントのサイトからメッセージをルーティングする、拡張性のあるメッセージキューシステムである。メッセージキューシステムは、軽量なメッセージキューシステムであり、リアルタイムでインタラクティブなマルチプレイヤ型のシステムのために最適化された、状態管理プロトコルであるとも考えられる。図１は、例示的な一つの実施形態についてのメッセージキューシステムの要素を表す。例示的な一つの実施形態において、コアのメッセージキューシステム１０は、三つの主な役割を有する：クライアントゲートウェイ１２、メッセージキューノード１４及びキュー管理１６。本開示書において、これらを、大まかに、それぞれ、「ゲートウェイ」、「キューノード」及び「スーパーバイザ」又は「ボス」と呼ぶ。「ノード」は、一般的に、メッセージキューシステムの一部として動作する、あらゆるコンピュータである。本開示書で用いられる「ノード」は、「キューノード」と同じではない点に留意する。キューノードは、ノードについての、多数の可能性のある種類のうちの一つであり得る。

【0014】

トポロジ的に、いくつかの実施形態のクライアントゲートウェイ１２は、クライアントシステム２０におけるユーザへのインターフェースである。図２は、一つの実施形態についての、ゲートウェイ１２の要素を表す。ユーザリクエストは、特定のドメイン名により、サーバへ到達する。受信されたユーザリクエストは、ゲートウェイ１２を横断して、ロードバランサ２２によって負荷分散される。各ユーザの連続したセッションが、同一のゲートウェイに向かう必要はない。ある時間において、ユーザごとに、一つの同時セッション（トランスミッション・コントロール・プロトコル、すなわちTCP接続）のみが存在し得るためである。セッションは、一般的に、長寿命である。例えば、一つのセッションは、ユーザがクライアントにログインしている間は、持続し得る。ある特定の実施形態において、セッションは、TCP上のGoogle（登録商標）のプロトコルバッファに基づく、カスタマイズされたプロトコルを用いることができる。

【0015】

ゲートウェイ１２は、ユーザリクエストを、実際のメッセージキューが処理される、メッセージキューノード１４のプールに誘導する、多重化／多重分離機能を実行し得る。クライアント２０は、特定の、名前を付されたメッセージキューを通して届くメッセージを監視する（例えば、アクセスを得る）ために、購読（subscribe）され得る。さらに、クライアント２０は、特定の、名前を付されたメッセージキューへメッセージを送信するために、購読され得る。図３及び４は、一つの例示的な実施形態の、メッセージキューの要素を表す。一つの特定の実施形態において、各メッセージキューノードは、メッセージキューの決定論的なサブセットに関与している。キュー名の、メッセージキューノードへのマッピングは、キューマップ（queue map）又はノードマップ（node map）によって実行される。それらは、キュー名を、ハッシュ処理（例えば、hash(キュー名)）を用いて、「バケツ（bucket）」へとマッピングする。図５は、一つの例示的な実施形態の、一貫性のあるハッシュ（consistent hash）処理を表す。各バケツは、既知のキューノードによって扱われる。特定の実施形態において、既知のキューノードは、一般的に、ノード全体で公平に分布された、８から１６個のバケツを用いて動作する。当業者にとって明らかなように、特定の実施形態において、使用されるキューノードごとのバケツの数は、より多いか、より少なくてもよい。

【0016】

スーパーバイザ１６は、ノードマップの信頼できる情報源であるとともに、システム全体の統計が、容易なモニタリングのために集められる、中心点である。しかしながら、スーパーバイザは、あらゆるリアルタイムのメッセージフローには関与しない。従って、全体のシステムは、スーパーバイザノードが一時的にダウンしても、完全な動作状態で目的を果たすことができる。しかしながら、スーパーバイザの関与なしに、ノードマップを再構成することはできない。

【0017】

特定の実施形態において、全てのコンピュータは、同一のコードソースツリー（code source tree）を実行するが、各ノードを起動するコマンドラインは、それが何の種類のノードであるかを決定する。各ノードは、自身を、スーパーバイザ１６を用いて登録する。従って、スーパーバイザ１６は、どのノードがメッセージキューシステム１０の有効な役割をするかを決定するために、うってつけの場所である。一つの特定の実施形態において、各「ノード」は、典型的に、８つのCPUコアと８GBのRAMを有し、計算のみを行う（データベースではない）サーバであり得る。一つの特定のシステムにおいて、一つのスーパーバイザノード（「ボス」）１６が提供される。このスーパーバイザノード１６がダウンしても、即時の置き換えは必要ではないが、システムをモニタする能力が低減する。一つの特定の実施形態において、５から１０個のクライアントゲートウェイノードが提供される。ロードバランサ２２は、利用可能なクライアントゲートウェイノードにわたって、クライアントのリクエストを広めるために提供され得る。一つの特定のシステムにおいて、５から１０個のメッセージキューノードが提供される。これらのメッセージキューノード、あるいはキューノードは、主に、それら自身の間でメッセージを伝達し得る。典型的なシステムにおいて、内部のトラフィックは極めて少ない。一つの典型的な実施形態において、全体のキューは、機能及びユーザ数が超過するまでは、全負荷時に、全体で１ギガビットより小さい帯域を用い得る。ネットワークパケットと入力／出力帯域幅のシステムレベルでの測定基準（metric）もまた提供され得る。

【0018】

メッセージキューノード１４は、主として認証の目的で、いくつかのWebコンピュータへのメッセージングを行い得る。一つの特定の実施形態において、このトラフィックは、JSON（JavaScript Object Notation）とHTTP（Hypertext Transport Protocol）を用いる。メッセージキューノードは、既存のWebプールを用いるか、あるいは、本開示書で説明されるような、メッセージキューシステム専用の新たなプールを生成する。一般的に、サーバの「プール」とは、本開示書で用いられる用語において、フロントエンドの負荷分散を用いて、特定のDNS（Domain Name Server）アドレスに応答するサーバの組である。そのサーバは、負荷分散され、ユーザへメッセージを送信するために、ゲートウェイの組へ到達し得る。一つの特定の実施形態において、このトラフィックは、JSONとHTTPを用いることができる。一つの特定の実施形態において、ソフトウェアは、Erlang/OTP R13B04上で記述されることができる。該ソフトウェアは、http://www.erlang.org/からダウンロードし、ビルドすることができる。

【0019】

各ノードは、Nagios互換の、「キー=値」のテキスト形式で統計を出力し得る、URL（Uniform Resource Locator）を有する。従って、各ノードに関するそのURLを単純に打ち込むことにより、アプリケーションレベルでのモニタリング用スクリプトを記述することができる。ノードのソフトウェアは、/etc/init.dの中で起動するように、セットアップされ得る。そして、正確なワークディレクトリと、特定されるコマンドラインオプションを有し得る。

【0020】

以下のセクションでは、一つの例示的な実施形態についての、メッセージキューシステム処理の機能レベルの実装について説明する。以下の説明は、一つの例示的な実施形態のメッセージキューシステムが、どのようにソフトウェア実行ファイル及びソフトウェア処理へ分解されるかの説明を含む。一つの例示的な実施形態のメッセージキューシステムは、
１）複数のゲートウェイ１２の処理と、
２）複数のキューノード１４の処理と、
３）単一のスーパーバイザ１６の処理と、
の三つの種類を含む。さらに、特定の実施形態のために、図１で示されるように、二つの要素：複数のトランスレータ１７の処理と、状態マネージャWebサービス１８が提供され得る。これらの処理は、以下でより詳細に説明されるが、まず初めに、本開示書で用いられる用語の概要を説明する。

用語集
・メッセージキューシステム
クライアントライブラリ、ゲートウェイ、キューノード及びスーパーバイザ、並びにトランスレータ及びコアのメッセージキューシステムから呼び出されるWebサービスのような補助的なシステムから構成される全体のシステム

・メッセージキュー（百万個のオーダーで存在し得る）
メッセージキューシステムにおける購読とアクセス制御の一つの単位であり、購読者（キューを通じてトラフィックをリスンすることに関心のあるクライアント）のリストとマウントのリストを含む。メッセージキューは、典型的にはディスク上で保持されない

・メッセージストリーム（百万個のオーダーで存在し得る）
メッセージキューシステム内の単一のアドレス指定が可能なエンドポイントであり、該エンドポイントを通じて、メッセージが、キューの全ての購読者にブロードキャストされる。一つのメッセージストリームは、メッセージキュー内で、名前を付されたマウントとして識別される

・状態ストリーム（百万個のオーダーで存在し得る）
メッセージキューシステムの中の単一のアドレス指定が可能なエンドポイントであって、該エンドポイントを通じて状態がフローを更新する。状態ストリームは、典型的にはディスク上で保持されない。しかし、キー／値の状態についての、結果として生ずる一貫性をサポートし、同様に、状態マネージャへの呼び出しを通じて、状態変更リクエストの検証をサポートする。状態ストリームは、メッセージキュー内で、名前を付されたマウントとしてアドレス指定され、ゼロ又はそれ以上の状態マネージャを有する

・マウント
メッセージキュー内の、特定の名前を付されたストリーム。すなわち、メッセージストリーム又は状態ストリーム。本開示書で用いられるように、「マウント」の語は、「ストリーム」の語の同義語とみなされ得る

・クライアント（百万個のオーダーで存在し得る）
ゲーム／シミュレーションの参加者。クライアントは、特別な権限を有さない限り、共有状態の生成／削除に関する、いかなる信頼できる決定も行わない

・ゲートウェイ（百万個のオーダーで存在し得る）
クライアントからのコネクションを受け入れ、それらを適切なエンドポイントであるメッセージキューノードへルーティングする処理。さらに、ゲートウェイは、認証と、メッセージキューシステムT->Erlangの変換を実行する

・キューノード（十個のオーダーで存在し得る）
名前を付されたメッセージキューを通じて、メッセージと状態更新を、購読されたクライアントに（ゲートウェイを介して）ルーティングする処理をホストするコンピュータ

・ゲートウェイノード（十個のオーダーで存在し得る）
ゲートウェイと持続（Persist）処理をホストするコンピュータ

・スーパーバイザ（一つ存在する）
メッセージキューインフラの構成に関する、信頼できる状態を有するコンピュータ及び処理

・持続（Persist）（百万個のオーダーで存在し得る）
ゲートウェイの視点から「新しい」クライアントとして動作するが、トランスレータの視点からREST（Representational State Transfer-style）形式として動作する処理。特定のログインしたクライアントに対して、特定のクライアント識別子（Cid）を関連付ける。実際には、特定のフィルタプラグインを用いたゲートウェイであり得る

・トランスレータ（百万個のオーダーで存在し得る）
一方の境界上で（perlbalが通信するための）HTTPサーバとして動作し、他方の境界上でErlangへ変換する処理。トランスレータは、Cidに基づいて、入ってくる（incoming）要求のために適切な持続（Persist）を提供する。トランスレータは、新しいシステムと通信するために、古いクライアントにより用いられる

・トランスレータノード（十個のオーダーで存在し得る）
トランスレータ処理をホストするコンピュータ

・状態マネージャ
キューノードの命令により、状態更新リクエストを検証し、展開することのできるプラグイン。入力として「古い状態」と「要求された変更」を受信し、「新たな状態」を出力する

・呼び出し（Call-out）
既知のプロトコル（典型的にはHTTP JSONサービス）に従って、メッセージキューシステムからの特定のリクエストに応答する処理。状態マネージャの一形態は、呼び出しを用いる。ゲートウェイは、認証の検証とコネクション切断通知の呼び出しを用いる

・サービス（百個のオーダーで存在し得る）
本システムの外部の手段を通じて、メッセージキューの生成、再構成及び削除をリクエストする権限を有する処理

・状態プラグイン
状態ストリームマウントによって、状態更新の一貫性を実行するために用いられるErlangモジュール。一つの例は、PHP呼び出しプラグインである

・フィルタプラグイン
ゲートウェイによって、クライアントに送られ、クライアントから受信されるメッセージをフィルタするために用いられるErlangモジュール。異なるフォーマットを用いるメッセージを、残りのメッセージシステム又は周囲の統合されたシステムにより使用される、均一のフォーマットへ変換するために用いることができる

【0021】

（ゲートウェイのプロセス）
ゲートウェイ１２のプロセスは、クライアントとの持続性のコネクション、及び持続性のサーバプロセスとの持続性のコネクションを維持する。コネクションの生成は、コネクションの持続期間の間に持続する、認証を確立する。認証とバイナリプロトコルのデコード以外の、ゲートウェイのプロセスは、比較的シンプルである。ゲートウェイのプロセスは、キュー名（id）を、ターゲットのキューノードにマッピングすることができる。そして、メッセージをターゲットのキューノードに転送し、同様に、適切に接続されたクライアントに応答を返す。図２は、一つの例示的な実施形態のゲートウェイ１２の要素を表す。図６は、一つの例示的な実施形態におけるメッセージ処理を表す。ゲートウェイのプロセスは、エンドポイント（例えば、キューとクライアント）間の購読を、さらに生成することができる。ゲートウェイのプロセスは、キューのidの名前空間のためのルーティングファブリック（routing fabric）を確立する。ゲートウェイは、キューノードへマッピングする名前空間の各サブセットに対して、一つ以上のTCPコネクションを確立する。該コネクションを通じて、ゲートウェイは、そのノード上のキューへ、全てのメッセージをルーティングする。そして、ゲートウェイ上で、現時点で購読されているクライアントを有する、そのノード上の全てのキューからメッセージを受信する。キューへの購読がクライアントに対してリクエストされた場合に、ゲートウェイは、そのキューを、現時点でリスンしている、キューのマップへ追加する（そのキューがマップの中にない場合）。さらに、ゲートウェイは、そのキューのエントリの内からの参照を、クライアントへ追加する。そのように、ゲートウェイは、接続されたノード上のキューから受信されたメッセージを、購読されるクライアントの適切な組へルーティングすることができる。このマッピングは、クライアントがキューから購読をやめた場合、あるいはクライアントが切断した場合に、解除される。クライアントが、メッセージ又は状態変更リクエストをキューへ送信した場合には、ゲートウェイは、メッセージを適切なキューへ転送する。ゲートウェイが転送するあらゆるメッセージに対して、リクエストを行った、認証されたユーザは、リクエスト上に追加される。従って、クライアントは、いかなるリクエストの中にも、自らの身元を含まない（含んではいけない）。代わりに、リクエスト送信者は、ゲートウェイのプロセスにより、メッセージの中で権威をもって識別され得る。そのように、システムは、なりすまし攻撃を受ける心配がない。ゲートウェイは、Webサイト上の信頼されたサービスからの、バルクでの購読、生成、削除及び更新を可能にする、管理インターフェースをさらに有する。ゲートウェイのプロセスは、外部システムへ接続ユーザの喪失を知らせるために、Webサービスを呼び出すことのできる場合には、サインオフに対してフックを必要とする可能性がある。代わりに、システムは、所定のユーザ専用のキューを購読し、ユーザが切断したとき、ユーザが去ったことの通知を受信し得る。ゲートウェイは、処理が活動状態である場合に、自らが利用可能であるものとして登録し得る。ゲートウェイは、所定時間（例えば、数分）ごとに、スーパーバイザへ統計データを送信することができる。

【0022】

（キューノードのプロセス）
一つの特定の実施形態において、キューノード１４は、メッセージキューを操作する。図３及び４は、一つの例示的な実施形態の、メッセージキューの要素を表す。各メッセージキューは、現時点で購読されているリスナのリスト又は組を有する。これらのリストは、各メッセージキューに対して異なり得る。各メッセージキューは、名前と購読者の組から構成される。キューの内部で、メッセージストリームと状態ストリームが「マウント」され得る。さらに、キューは、構成済みの状態マネージャ呼び出しサービスと同様に、キューの中の各「マウント」を有し得る。キューノードは、ゲートウェイがノードへのコネクションを生成し、ノードがルーティングにより入ってきた（incoming）メッセージに単に反応し、関与するゲートウェイに通知する場合には、主として受動的である。キューノードは、ユーザのキュー購読リクエストを受信すると、要求しているゲートウェイが、キューに対する出力のリストへ加えられ（存在していなかった場合）、購読しているユーザが、そのゲートウェイのエントリの中の一エントリとして追加される。このように、たとえ一つのゲートウェイ上で複数のユーザが同一のキューを購読していても、一つのメッセージは、その一つのゲートウェイへ一度転送されればよい。一人のユーザが購読を解除した場合、あるいはゲートウェイが（例えば障害により）切断した場合には、この手順は逆になる。キューの統合のために、以下でさらに詳細に説明されるように、一つのキューの状態は、完全にシリアライズ可能であり、かつ、別のキューノードへ転送可能でなければならない。さらに、一つのキューノードは、新たなキューノードへ転送されたキューを対象としたメッセージを転送可能でなければならない。キューノードは、処理が活性化した場合には、自身を利用可能として登録し得る。キューノードは、時間ごと（例えば、数分）にスーパーバイザへ統計を送信することができる。

【0023】

（スーパーバイザのプロセス）
スーパーバイザ１６のプロセスは、メッセージキューシステムの中の全てのノードを管理することができる。スーパーバイザのプロセスは、キューノードのマッピングテーブルのために、キュー名をさらに管理する。一つの特定の実施形態において、このマッピングは、従来の「循環ハッシュ（circle hash）」（あるいは、代わりに、N個の既存のノードの組へ追加される新しいノードの、１対Ｎの再マッピングを可能とする、ノードへマッピングされたバケツ）として保持される。さらに、スーパーバイザのプロセスは、ゲートウェイノードとキューノードからシステムの性能と負荷に関する統計データを集め、管理インターフェースを通じてシステム性能の集計ビューを提供する。スーパーバイザのプロセスは、クラスタネットワークの外部からは一般的には確認できないが、代わりに、Web管理サービスを通じて完全にアクセスされる。スーパーバイザは、ノードのマッピングテーブルへの更新について、ゲートウェイへ通知することができる。

【0024】

一つの特定の実施形態において、唯一のスーパーバイザのプロセスが存在する。しかしながら、スーパーバイザプロセスは、たとえ一時的に停止しても、ゲートウェイノードとキューノードの設定されたネットワークが動作し続けることができる点で、単一障害点ではない。この場合には、メッセージキューシステムは、統計データをレポートし、あるいはノードのマッピングテーブルを構成することができるだけではない。スーパーバイザプロセスは、一つの特定の実施形態において、単に統計データのコレクタとして動作する。この単純化により失われた主な機能は、既存クライアントのコネクションを中断することなく、キャパシティを追加し、ダウンしたノードから負荷を再分配する能力である。

【0025】

（トランスレータのプロセス）
メッセージキューゲートウェイと直接通信するために更新されない、あるいは、制限された、HTTPのみのプロキシファイアウォールのために更新することができない、古いクライアントは、既存のチャットスクリプトのためにXMLRPC呼び出しをし続けることができる。XMLRPCは、従来のリモートプロシージャコール（RPC）プロトコルであり、その呼び出しをエンコードするためにXML（Extensible Mark-up Language）を用い、転送方式としてHTTPを用いる。それらのスクリプトは、メッセージを変換し、メッセージキューゲートウェイへ転送する必要があり得る。なぜならば、メッセージキューゲートウェイは、持続性のコネクションモデルを用い、XMLRPC Webサーバは、一般的には、REST（Representational State Transfer）と同様のポーリングモデルを用いるため、二つのモデルの間で何らかの変換（translate）が必要となる。

【0026】

一つの特定の実施形態についてのトランスレータ１７のプロセスは、持続性であり、状態を持った（stateful）プロセスである。トランスレータのプロセスは、メッセージキューゲートウェイへの接続を確立し、クライアントごとにXMLRPC API（Application Programming Interface）を用いる。トランスレータのプロセスは、次に、XMLRPCからのJSONリクエストを受信し、それらをメッセージキューシステムのメッセージへ変換する。さらに、トランスレータのプロセスは、メッセージキューシステムからのメッセージと状態更新をバッファし、XMLRPCシステムがポーリングするのに都合がよいように、それらをJSONデータとして利用可能にする。所定の時間（例えば、５分）の間に、ポーリングされたメッセージがない場合には、クライアントが切断したものとみなし、持続性のコネクションは解除される。

【0027】

差の小さい実装のバリエーションにおいては、トランスレータの入力のために、JSONに代わってXMLが用いられ、既存のスクリプトの処理をより容易にする。より差の大きな実装のバリエーションにおいては、チャットWebサーバの必要性を顕著に削減し、あるいは除去するために、チャットスクリプトのふるまいを完全にエミュレーションする。XMLRPC（チャットWeb）サーバからトランスレータのプロセスへのマッピングには、カスタマID（cid）に関する単純なmod演算が用いられる。代わりに、前記マッピングは、チャットWebのインスタンスに統計的に基づき、あるいは、循環ハッシュ又は他の一貫性のあるハッシュ方式（consistent hashing mechanism）のような、あらゆる他の一貫性のあるマッピング機能を用いて、行われることができる。

【0028】

（状態マネージャサービス）
固有の状態（プロパティ値）を導入し、更新し、あるいは削除するためのリクエストを受信するキュー状態ストリームは、状態の更新の規則を実行するために、状態マネージャサービス１８を呼び出し得る。キュー状態ストリームは、現在の状態及びリクエストされた状態の変更を、JSON形式のデータブロックへ一まとめにすることができ、さらに状態マネージャWebサービスへリクエストをポスト（post）することができる。状態マネージャWebサービス１８は、次に、三つの結果のうち一つを返す：
ａ）ok：リクエストされた変更を適用する
ｂ）拒否：変更しない
ｃ）変更：状態マネージャによって返されたように変更を適用する
状態マネージャは、主たるWebサーバ上の状態を持たない（stateless）のWebサービスを実行することができる。状態マネージャからの負荷が別個に管理される必要がある場合には、必要に応じて、Webのフロントエンドの単独のプールへ容易に変更され得る。実際には、キュー状態ストリームに対して、状態マネージャは、キューが生成されるときのパラメータとして構成される。実際には、既知のキューに対して、あらゆる数の状態マネージャが存在し得る。既知の部屋（room）、オブジェクト又はサービスが、必要に応じて、異なる状態の組を実現するために、複数のキュー状態ストリームを用いることができる。状態マネージャは、複数の状態の組に基づいて決定をするために、複数のマウントされたストリームをリスンすることができる。例えば、部屋のアバターの状態（誰が「キング」か）ごとについての情報と、部屋の状態（どのノードが「王座」にあるか）ごとについての情報とを要求する規則は、キングのみが王座に座ることができるという規則を実行可能にするための両方の種類の情報を知るために、マウントされ得る。

【0029】

（ゲートウェイノード）
ゲートウェイノードは、スーパーバイザへ接続され、キューの名前空間のマッピングを受信すると、クライアントのリクエストをすぐに処理し始めることができる。ゲートウェイノードが必要とすることの全ては、ハードウェアのロードバランサに、クライアントを指し始めさせることである。一つの特定の実施形態において、ある設計目標は、単一のサーバ（８コア、２４GB/sのメモリバス）への接続に対して、２０，０００ユーザである。TCPコネクションの欠落と再確立（例えば、断続的なWiFiのホットスポットのため）を行うクライアントの、新たなコネクションに対して、新たなゲートウェイが選択され得るであろう。これを軽減するために、クライアントの購読情報が、クライアントに特有の状態ストリームの中に保持され、ゲートウェイによって管理される。クライアントがゲートウェイへ再接続した場合には、クライアントは、クライアントが現時点で参加している全ての購読を再び配信する。このキューは、いくらかのタイムアウト時間（例えば、６０秒）の後に、自動的に除去され得る。タイムアウト時間内にキューを購読するクライアントがいない場合には、「ハード（hard）」なキューは、不要に割り当てられたシステムリソースを開放するために、切断される。バディ（buddy）へサインオフの通知をすぐに提供するために、制御された（ユーザが開始した）サインオフにより、ゲートウェイが切断される前に、ゲートウェイを通じてメッセージがもたらされ、バディ状態（buddy state）チャネルの中で状態更新がもたらされる。

【0030】

内部的に、一つの特定の実施形態のゲートウェイは、gen_server（特に、バイナリのTCPサブクラスと、HTTPインターフェースのHTTPサーバサブクラス）に基づく。各アクセプタは、入ってくる（incoming）それぞれのリクエストに対して、新たなErlangプロセスを開始する。長く実行されているコネクション（クライアントのバイナリプロトコル）に対して、このプロセスは、そのユーザ特有のルーティングの状態を作る。システム内のメッセージは、Erlangのタプルとして送信され、典型的にはErlangの構造体（structs）として構成される。

【0031】

さらに、ゲートウェイノードごとに、一つの「ノードディスパッチャ（node dispatcher）」のプロセス又は「マップ済フォワーダ（mapped forwarder）」のプロセスが存在する。このプロセスは、メッセージキュー名を対応するキューノードに変換し、出ていく（outgoing）パケットをキューノードに転送し、購読している接続ユーザへ送るために、そのキューノードからパケットを受信する。一つの特定の実施形態において、クライアントのコネクションは、一般的に４４３番ポートを通じて提供される。それぞれの受け入れられたコネクションは、プロトコルバッファプロトコルをデコードし、リクエストをErlangのタプル（構造体）へと変える、クライアントフレーム構成ハンドラ（client framing handler）を生ずる。ほとんどのメッセージは、宛先であるキュー名を既知の物理的なキューノードに変換し、そのキューノードのための通信プロセスへ送る、キューマップに進む。各ゲートウェイノードにおいて、ノードごとに、そのノード上のゲートウェイのプロセスによって用いられる、少なくとも一つのそのようなプロセスが存在する。一つの特定の実施形態において、キューから購読者への応答は、この「ノードディスパッチャ」のプロセスをバイパスすることができる。すなわち、これらの応答は、それぞれの購読しているゲートウェイのプロセスへ真っ直ぐに送られ得る。メッセージの「ノードディスパッチャ」プロセスが、ボトルネックとなるプロセスであることが判明した場合には、このプロセスを並列化することができ、コネクション処理プロセス（connection handling process）を構成する場合には、N個のメッセージキューノードディスパッチャプロセスをラウンドロビン方式によって処理することができる。この個別のプロセスを生成するポイントは、より実装が容易な、名前空間の動的な再マッピングを行うことである。

【0032】

スーパーバイザ管理インターフェースは、当初は、統計データをスーパーバイザへプッシュすることに限られる。一つの特定の実施形態において、これらの統計データには以下のものが含まれる：
・秒毎のルーティングされたメッセージ数 ←負荷を追跡することができる
・接続クライアント数 ←負荷分散を検証し、機能停止を検出することができる
・接続キューノード数 ←接続の問題が存在するかどうかを発見できる
・クライアントごとの購読されたキュー数 ←統計と計画目的
・ターンアラウンドリクエスト（op_idコードを用いたリクエスト）に対する最小、平均、最大の待ち時間 ←一つの特定の目標に対する性能を追跡するため（例えば、100msの目標）
・直近の期間（例えば、一時間）から往復する最も遅いメッセージ ←問題のあるリクエストを追跡するため
・秒ごとのWebリクエスト数 ←メッセージキューシステム上のクラスタの負荷を追跡するため
・Webリクエストに対する最小、平均、最大の待ち時間 ←システムを通じた性能を追跡するため
・直近の期間（例えば、一時間）から最も長く実行しているWebリクエスト ←問題のあるリクエストを追跡するため
・Erlangプロセスの総メモリサイズ
・最も大きなErlangプロセス、サイズ、種類
・プロセスの種類ごとのErlang例外の数
・ソフトウェアのバージョン
以下でより詳細に説明されるように、オンラインのキューノードの挿入／移動／削除の実装の一部として、管理インターフェースは、キューマップの更新のコミット周期に加わることができる。HTTPインターフェースは、JSONリクエストを受け入れ、JSONデータを返す。HTTPインターフェースは、HTTPコネクションごとに、一つのErlangプロセスを生ずる。一つの代わりの実施形態において、リクエストハンドラ（request handler）のプールに移動することを選択することができる。前記インターフェースは、JSONをErlang構造体へ変換し、応答の構造体からJSONへと、再度、逆に変換する。ここでは、１６進数の＼xXXをサポートするようJSONを拡張し、３２より少ない、あるいは１２６より大きい文字列のためのエンコーディングを用いる。代わりの方法は、文字列を、そのまま（Unicode形式のJSONによって求められる）、あるいは＼uXXXX（ASCII JSONによって求められる）として送信することである。

【0033】

（キューノード）
メッセージキューノードは、スーパーバイザにより管理される、キューノードマップから名前空間の領域を割り当てられるまでは、キューのリクエストを処理し始めることができない。一つの特定の実施形態において、各キューは、単一のErlangプロセスによって表される。これは、キューの中の全てのマウントされた名前空間が、キューの中で（例えば、「プロパティバッグ（property bag）」で示されるメッセージストリームと状態ストリーム）シリアライズされていることを意味する。Webサービスへの呼び出しは、呼び出しを要求するストリームのために、同様にシリアライズされる。メッセージストリーム上でポストされたメッセージは、呼び出しを必要としなくてもよい。したがって、外部の検証を必要とする状態変更リクエストと比べて、再び順序付けする。キューは、Erlangプロセスへプラグインとして読み込まれる、プロセスの中のフィルタ又は状態マネージャも含んでもよく、キュープロセスそのものの一部（再度、シリアライズの目的のために）として実行しても良い。

【0034】

一つの特定の実施形態において、設計目標は、単一のサーバ（８GB、8コア、２４GB/sメモリバス）上において最大１００，０００個のキューが存在することである。これは、キューごとに８０kBの状態を可能にする。キューごとのオーバーヘッドにより、メモリの制約が問題となった場合には、システム全体の待ち時間を低く抑えるために、単一の機器でRAMを増設するのではなく、より多くのキューノードに分割することができる。一つの特定の実施形態において、システムを通じて（キューノードを通じて入ってくるゲートウェイからリスンしているクライアントまでの）流れる単一のメッセージの設計目標は、１００ミリ秒以内である。２４GB/sメモリバスと８GBのRAMを有するサーバは、８GBのワーキングセットを処理するために、３５０ミリ秒を費やす必要があるであろうことに留意する。

【0035】

名前を付されたキューの、キューノードへのマッピングは、キュー名のMD5ハッシュを通じてなされる。次に、ノードサーバへ割り当てられたバケツ（bucket）の順番への、MD5ハッシュの上位Nビット（例えば、１０ビット）のマッピングが続く。MD5ハッシュ方式は、当該技術分野における当業者により良く知られている。最初に、多数のバケツは、それぞれの参加しているキューノードへ割り当てられ得る。より多くのキューノードがオンラインになると、バケツは、割り当てられたノードから公平に除去され、確率的にバランスのとれた、1/Nの負荷マッピングを保つように、新たなノードへ追加される。スーパーバイザは、ハッシュとノードのマッピングのマスタのマッピングを保有する。一つの特定の実施形態において、負荷を平坦にするために、ノードごとのバケツの最小値を定めることができる。例えば、あるノードが二つのバケツによりマッピングされ、あるノードが三つのバケツによりマッピングされる場合に、それ以外では負荷分散が一様である場合の負荷の違いは、二番目のノードは、一番目のノードより５０％高くなる。一つの特定の実施形態において、ノードごとのバケツの最低数（例えば、ノードごとに最低８個のバケツ）のポリシーが定められる。全てのノードが８つのバケツを有すると、例えば、マッピングされたアドレス空間の変更なく、ノードごとのバケツの数を倍にすることができる。このように、各バケツは、ノードごとの合計１６個のバケツのために、二つの新たなバケツに変わる。次に、負荷の不均衡の懸念なしに、再度公平に再分配を始めることができる。ノードごとに用いられるバケツの最小数は、それ以外は一様な負荷であるとすると、最大の負荷の不均衡を決定する（「ホットキー（hot key）」でない）。ノードごとの８個のバケツの最小数の、最悪の場合の割合は８：９であり、あるいは二番目のホストの負荷が１２．５％高くなる。バケツの最小数を増やすことについてのコストが存在する。なぜなら、ノードマップは、キューノードマッパー（queue node mapper）プロセスの「ホットデータ（hot data）」であるためである。従って、ノードマップは、理想的には、L1キャッシュへうまく適合すべきである。

【0036】

内部的に、各メッセージキューは、Erlangプロセスである。さらに、各ゲートウェイから入ってくる（incoming）メッセージのための、受信プロセスが存在する。

【0037】

メッセージキューノードは、ゲートウェイからリクエストを受信する。これらのリクエストは、物理ノードの「中央入力（central input）」プロセスへ進む。物理ノードは、順に適切なメッセージキュープロセスに送る。メッセージキューは、メッセージキューごとの、一つのErlangプロセスである。各メッセージキューの中で、異なる名前を付された「ハンドラ（handler）」が「マウント（mount）」される。これらは、メッセージの転送や状態の記憶のような、特有の振る舞いを実装する。ハンドラは、名前によって参照される、Erlangモジュールの形式をとる。状態記憶ハンドラは、Erlangモジュールとして記述された、プラグインの状態マネージャをさらにサポートする。当業者にとって明らかなように、Erlangモジュール以外の種類のモジュールが、同様に用いられ得る。ある状態マネージャハンドラプラグインは、PHP呼び出しのハンドラである。このことは、プラグインが、例えば呼び出すべきURLは何かを示す、構成データを許可されなければならないことを意味する。各キューは、購読されているゲートウェイノードのリストとして、ゲートウェイのエントリごとにユーザのリストと共にソートされた、購読されているユーザのリストを含み、出力ノードに対する参照数の計算を可能にし、同様に、プレゼンス情報（presence information）の生成を可能にする。

【0038】

多くの場合、ホットコード（hot code）の再読込みに合わせて設計する。これは、モジュール名を通じて、末尾再帰的に、明示的に自らを呼び出す「ループ」関数として説明される。いくつかのデータ構造の更新は、代わりにローリングリスタート（rolling restart）を必要とし得る。これらの場合のケースの大部分を発見するために、テストを用いることができる。段階的な展開に関するWebプッシュモニタと同様の例外カウンタを通じて、これらを検出することができる。スーパーバイザは、現段階では実行時の測定基準（metrics）の受け手である。一つの特定の実施形態において、これらの測定基準は、以下のものを含むことができる：
・一定時間ごとにルーティングされたメッセージ数
・メッセージキュー数
・メッセージキューごとのマウント数
・キューごとの平均の状態記憶メモリ
・キュープロセスにより使用される総メモリ
・最大プロセス、サイズ、種類
・Erlang例外、数、プロセスの種類
・ソフトウェアのバージョン
スーパーバイザ１６は、キューの移行に加わる、ノードレシーバプロセス（node receiver process）を作ることもできる。キューの移行とは、移動されるメッセージキューを対象としたメッセージが対象のノードへ転送された後、ノードがメッセージキューをシリアライズさせ、新たなホストノードに移動させることを意味する。これは、全てのゲートウェイが、新たなメッセージの送信マップ（dispatch map）をコミットするまで続く。このとき、移行外キュー（migrated-out queue）についてのあらゆる情報が除去される。このプロセスは、ホットノード追加（hot add node）処理として表され得る。図７は、一つの例示的な実施形態のホットノード追加処理を示す。キューの移行は、ある時間に一つのキューをリクエストされ得る。これにより、そのノードは、一時的に、他のリクエストを処理し続け、移動しているキューを対象とするメッセージのみをキューイングすることができる。移動したキューが成功を報告した場合には、保留のメッセージが転送され、移動すべき次のキューが開始される。１００，０００個のキューを有し、ミリ秒ごとに一つのキューを移行し、全てのキューの１／１０を移行する場合には、この処理は１０秒かかるであろう。つまり、移行中にリクエストを処理できることは、システムの反応性のために重要である。

【0039】

メッセージキューは、クライアントが切断し、再接続した場合には、失われたメッセージの再送の責任を負う。これをサポートするために、メッセージキューは、マウントにより生成された、それぞれの出ていく（outgoing）メッセージに番号を付することができる。クライアントが接続すると、該クライアントは「最後に受信したメッセージ」のシリアル番号を提供することができる。このシリアル番号が、キューによってまだ記憶されているメッセージのもの（あるいは、最も古い、記憶されているメッセージより前のシリアル番号）と一致する場合には、次に、それ以降のメッセージが再度配送され、クライアントは最新であるとみなされ得る。シリアル番号が０である場合、あるいはシリアル番号が記憶されているメッセージの範囲より前に欠落している場合には、コネクションは「新しい」ものとして取り扱われ、各マウントは「新しい状態」を伝えるよう求められ得る。該状態は、メッセージストリームに対しては何も行わず、状態ストリームに対して、全ての状態のスナップショットを配送する。

【0040】

（スーパーバイザノード）
スーパーバイザは、Erlangランタイムにおけるシステム全体の登録名（例えば、「supervisor」）を用いてアドレス指定されても良い。スーパーバイザは、特別なコマンドライン引数を用いて、スーパーバイザとして開始される。オンラインになったメッセージキューノード及びゲートウェイノードは、ノードの実行プロセスへのコマンドラインパラメータにより記述される種類を用いて、スーパーバイザに自身を登録する。スーパーバイザは、異なるノードから統計データを集め、システム内の計測指標の総合的な管理の概要を提供し得る。システムへ新たなメッセージキューノードを挿入する場合には、スーパーバイザは、まず、全てのキューノードに、新たなマップについて告知する。そして、全てのキューノードに、キュー状態（同様に、目標のキューに対して入ってくる（incoming）トラフィック）を新たなノードへ転送させる。次に、スーパーバイザは、新たなマップを全てのゲートウェイに分配する。これにより、ゲートウェイは、入ってくる（incoming）トラフィックを、適切な、新たなノードへ送ることを知ることができる。最終的に、全てのノードは、新たなノードが「コミット」され、古いノードが、今移動されたメッセージキューに関連する全ての状態を除去し得ることを、通知され得る。

【0041】

（クライアント）
クライアントは、チャットメッセージベースのやりとりのための、メッセージキューシステム（例えば、ドメインネームサーバ、すなわちDNS名）と接続するために、更新される。checkForMessages ()のようなXMLRPCの呼び出しは、メッセージキューゲートウェイからのトラフィックによって駆動されるように再び誘導される（re-vectored）。ゲートウェイとクライアントとの間には単一の接続のみが必要である。ユーザは、失効時間とユーザIDとハッシュの署名を含む、ハッシュにて署名されたクッキーを通じて、そのゲートウェイのものと特定される。このクッキーは、クライアントが最初にログインしたときに（ログインが完全にそのゲートウェイを通じて生じるまで、かつ、ログインが完全にそのゲートウェイを通じて生じる限りにおいて）、Webシステムによって発行される。クッキーの盗用を回避するために、ゲートウェイが暗号でランダムなチャレンジをクライアントに発行し、クライアントがユーザのパスワードを用いてこれを署名し、ゲートウェイへ返す、スリーウェイハンドシェイク方式がある。ゲートウェイは、次に、署名が、前記チャレンジにローカルで署名して得られた署名と、関連があるか検証する。このために、ユーザのパスワードがサーバ側で保持されている必要がある。これに対して、一つの実施形態では、ユーザが、パスワードのハッシュを用いてチャレンジに署名し、パスワードはサーバ側で保管される。すなわち、パスワードのハッシュが新たな「パスワード」であるが、万が一システムに侵入された場合に、プレーンテキストのパスワードの漏えいを回避する。

【0042】

（セキュリティ）
いくつかの実施形態における本システムは、ユーザのなりすまし攻撃を回避するよう設計される。本システムは、個人情報の盗難の攻撃を軽減するようにも設計され、ハンドシェイク段階のセットアップを確認する認証のコストを削減する。サービスが、あらゆるソース依存（source-dependent）の動作に対して確立された身元情報（例えば、カスタマID）を用いる限り、システムはセキュアであり得る。プレーンテキストのIDをサービスに渡す不正なサービスは、このレベルで保護されることができない。しかし、代わりに、適切なAPIの設計と個別のサービスの監査により、軽減されなければならない。

【0043】

（一つの例示的な実施形態におけるクライアント／サーバ統合）
キューのための全ての生成、購読及び購読解除は、いくつかのXMLRPC又は全てのAPIコールの副作用として、サーバ側で発生する。例えば、ユーザのログイン処理の一部として、ログインプロセスは、ユーザのシステムチャット（system chat）キューとバディ状態（buddy-state）キューを生成し、これらのチャットキューと状態キューのために前記ユーザを購読することができる。一つのキューを購読すると、三つのフラグが特定され得る。
・キューが存在していない場合に、キューを生成すべきかどうか（すなわち、自分のバディ状態（buddystate）を購読している場合には真であり、友人のバディ状態を購読している場合には偽である）
・キューの他の購読者について知っていることに関心があるかどうか
・「キープアライブ（keep-alive）」参加者かどうか；自分のプレゼンスがキューの生存を制御すべきかどうか（再度、自分のバディ状態に対しては真であり、友人のものに対しては偽である）
正常な購読は、ネットワーク上でクライアントに「キュー購読済（queue subscribed）」メッセージを生成する。これにより、あるクライアントセッションが、XMLRPCコールの中で起こったキューの購読を知る。直接のTCPコネクションがそのクライアントに対して確立されなかった場合には、ゲートウェイは、そのクライアントが接続したとき、全ての購読メッセージが送られるように、キューの購読を記憶する。このことは、ユーザのログイン中に生ずるキューの購読を取り扱う。これは、クライアントがTCPを用いてゲートウェイへ接続する前に生ずる。同様に、購読の解除は、クライアントに「キュー購読解除（queue unsubscribed）」メッセージを送信する。

【0044】

（一つの例示的な実施形態におけるクライアント処理）
最初に、本開示書で説明されるメッセージキューシステムと関連する、クライアント側の処理を扱うために、一つのサービスがクライアントで登録される。一つの特定の実施形態において、クライアント上のServiceProviderモジュールは、メッセージキューシステムと関連するクライアント側の処理を取り扱うために、新たなサービスであるMQManagerを登録することができる。クライアントのログイン後、MQManagerサービスは、クライアントで認証及び接続プロセスを開始するために必要なデータを有し得る。一つの特定の実施形態における、ログイン処理に関する詳細を以下に示す。

【0045】

キューに関心のあるオブジェクトは、MQManagerを用いて、名前により、そのキューに対するリスナとして登録され得る。そして、メッセージハンドラコールバック（message handler callback）を提供する。一つのオブジェクトのみが、信頼できる処理と既知のキューの消費に責任を負う。つまり、一つのオブジェクトのみがリスンすることを許される。MQManagerがXという名前のキューを待っているリスナを既に有しており、他のリスナがリスンするために登録しようとしている場合には、MQManagerは例外を起こす。より多くのオブジェクトがそのキューのメッセージを知る必要がある場合には、リスンするオブジェクトのメッセージハンドラは、他のリスナのためのイベントと通信することができる。

【0046】

MQManagerは、各キュー名のコールバックを保管することができ、MQManagerがメッセージを受け取ると、それらのコールバックを呼び出す。MQManagerは、最初に、メッセージをデコードする。つまり、リスナのメッセージハンドラは、メッセージオブジェクトを受信するのであって、ビット文字列を受信するのではない。キュー購読済（queue subscribed）メッセージそのものは、リスナのメッセージハンドラに合わせて送信され、同時に、初期状態又は初期参加データを含み得る。さらに、リスンしているオブジェクトは、購読の時点（point of subscription）に関心があり得る。同様に、購読解除のメッセージが、メッセージハンドラに送信され得る。購読解除のメッセージが受信された場合には、リストからリスナをすぐには除去しないことに留意する。代わりに、リスナは、同一のキューに対する別の購読リクエストが生ずるかどうかを、リスニングオブジェクトが再度購読することなく、自動的に検出することが望ましい。MQManagerがメッセージを受信し、デコードされたメッセージオブジェクトとともにリスナのコールバックを呼び出すとき、MQManagerは、複数のキューをリスンするための一つのコールバックを用いるオブジェクトのために、キュー名を渡すこともできる。MQManagerは、チャットセッションがエコーメッセージを処理する必要がないように、このユーザに由来するものとしてマークされたメッセージをフィルタすることができる。

【0047】

MQManagerにより受信された購読メッセージが、そのキューをリスンしているオブジェクトを有していない場合には、MQManagerは、キュー名を用いて購読メッセージを保留する。そのキューに対して入ってくる後続のメッセージは、同一の場所に保留される。オブジェクトが、いくつか後の時点で、そのキュー名をリスンしようとした場合には、そのオブジェクトは、保留されたメッセージの束を、すぐに送信させることができる。これにより、オブジェクトは、すぐにキュー名がわからなくても、購読に対してリスンすることができる。例えば、ユーザがチャットを生成し、新たに生成されたチャットID（chatId）49723942とともに、呼び出しが返るまで、その新たなチャットのキュー名「chat/49723942/messages」はわからない。メッセージを保留している場合に、そのキューに対する未処理の最も古いメッセージが、ある時間（例えば、５分）より古いとき、エラーを記録し、そのキューの保留分を破棄して、そのキューに対する後続のメッセージの保留を止めることができる。

【0048】

MQManagerの要素を送信するメッセージ（例えば、sendMessage）は、任意の「expectAsyncResult」フラグをとり得る。このフラグと共に送信されるメッセージは、前記メッセージに付され、sendMessageによって返される、MQManagerによって生成されるop_idを有することができる。「expectAsyncResult」と共に送信されるメッセージは、成功／失敗の応答を期待する、状態メッセージである。すなわち、op_idと共に送信されるメッセージは、どのop_idメッセージが関連し、成功／失敗の結果となったかを特定する、ネットワークからの応答を非同期的に受信する。sendMessageにより生成されるop_idを用いて呼び出すオブジェクトが実行することと、そのハンドラに送信される、後続の結果のメッセージについて、呼び出すオブジェクトが全ての責任をもつ。使用方法の例に関するチャットの開示を以下に示す。

【0049】

MQManagerは、他のアウトバウンドトラフィックが存在しない場合には、毎時間（例えば、２０秒）ごとに、TCP上でpingによるキープアライブを送信する処理を行うことができる。MQManagerは、他のインバウンドトラフィックが存在しない場合には、毎時間（例えば、２０秒）ごとに、TCP上でpingによるキープアライブを受信する処理を行うことができる。予期されるキープアライブが存在しない場合、あるいはコネクションが予期せず失われた場合には、透過的に再接続することができ、ソケットエラーの間に保留された可能性のあるメッセージを含む、接続されていない状態の間に送られるべきメッセージをキューイングする。これらのキューイングされたメッセージは、接続が再度確立されると、送信され得る。ゲートウェイは、再接続が十分迅速になされる場合には、クライアントの購読を自動的に保持することができる。コネクションが合理的な期間内に再度確立できない場合（ゲートウェイが、クライアントの長期にわたるコネクションの不在をタイムアウトとみなし、既存の購読を除去するような）には、クライアントは、長期にわたるネットワークの機能停止に対して通常行うように振舞うべきできあり、ユーザに再度ログインを要求する。コネクションの消滅は、出て行くメッセージを後の配送のためにキューイングするための唯一の出来事である。すなわち、ゲートウェイにおけるsendMessageのあらゆる失敗又はそれを超えた失敗（例えば、存在しないキューへの送信、購読されていないキュー又は書き込むことができないキューへの送信）は、op_idが特定されていない限りは（例えば、「expectAsyncResult」が「MQManager.sendMessage」へ渡される）、静かに（silently）失敗する。この場合には、エラー結果が戻され得る。

【0050】

（一つの例示的な実施形態におけるログイン処理）
MQManagerは、serviceProviderを用いて登録される場合に生成されるが、ユーザのログインが完了するまで、TCPコネクションの確立を開始しない。コネクションが張られた後、認証プロセスが開始される。一つの特定の実施形態において、認証は、以下のステップを含む、複数のステップのプロセスである。
・クライアントが、自らを識別するため、ログイン時に提供されるクッキーを送信する。
・ゲートウェイがランダムのチャレンジを用いて応答する
・クライアントがパスワードのハッシュを用いてチャレンジに署名し、署名されたチャレンジを送信する
・ゲートウェイはパスワードのハッシュを用いて、ローカルでそのチャレンジに署名し、クライアントがちょうど提供したものと一致するか検証し、クライアントに成功／失敗を示す
認証が失敗すると、ユーザは、ログインが失敗したのと同様の方法で、再度ログインするために問合せる。ログインプロセスの一部として、ログインコンポーネントは、システムチャット（system-chat）キューとバディ状態（buddy-state）キューのために、ユーザを生成し、購読する。システムチャットキューとバディ状態キューの両方に対する購読は、他の購読者に関心がなく、そのユーザがキープアライブの参加者であるものとしてマークされる。さらに、ログインコンポーネントは、そのユーザの友人、ファン、最近のチャット、ユーザの友人の態様で現れる人、全てのためにユーザを購読し、そのユーザのキューのために彼ら全員を購読するように、彼ら全員を輪にする。購読は生成しない（non-creating）ものとしてマークされるため、キューを有しない、あるいはユーザのキューを購読する方法がないオフラインの友人に対しては何も起きない。購読は、全て、キープアライブでないようにもマークされる。

【0051】

（一つの例示的な実施形態におけるシステムチャット処理）
一つの特定の実施形態において、システムチャット（systemchat）の購読メッセージのためにリスンするマネージャオブジェクト（manager object）が存在する。システムチャットメッセージを受信すると、マネージャオブジェクトは、イベントバス上のそのシステムチャットメッセージ内容を、使用すべき全てのクライアントのためにエコーする。マネージャオブジェクトは、購読メッセージと購読解除メッセージをエコーしない。一つの実施形態において、システムチャットイベントが、任意のペイロードのJSONのblobを用いたストリングトークンとして、サーバによってもたらされる。

【0052】

（一つの例示的な実施形態における友人の処理）
バディ状態オブジェクト（BuddyState object）が、クライアントのログイン直後に、有効化される。バディ状態オブジェクトは、ユーザのバディを管理する、メインのバディマネージャオブジェクトである。バディ状態オブジェクトは、ログイン直後に、ユーザの友人（バディ（buddies））のリストをすぐに取得することができる。リストの中の各バディのために、バディ状態オブジェクトは、（例えば、全てのバディのためのある単一のコールバックを用いて）その友人のためのバディ状態キューをリスンすることができる。一つの特定のキューのための購読メッセージは、ユーザの友人がオンラインであることを意味し、その特定のキューのための購読解除メッセージは、ユーザの友人がオフラインであることを意味する。従って、バディ状態オブジェクトの初期化時において、全ての友人は、証明されるまではオフラインである。それらのキューを通じた他のメッセージは、ユーザに実際のバディの状態（例えば、取り込み中（DND（Do Not Disturb））、成人限定、離席中（away）等）を知らせることができる。オンライン状態と実際のバディの状態の更新は、バディ状態オブジェクトのイベントシステムを用いて、クライアントの様々な部分へ送られ得る。バディ状態オブジェクトは、ユーザのバディ状態キューを処理し、ユーザのバディ状態キューへメッセージを送信する（例えばDNDになった、応答可能になった、サインオフしている、等）責任を負う。ユーザがサインオフする場合には、「サインオフ（signing off）」メッセージが、それらのバディ状態キューへ送信される。そうして、バディ状態オブジェクトは、サインオフメッセージ又はある友人のための購読解除メッセージを、ユーザがオフラインになっているものとして解釈し得る。ユーザがサインオフメッセージなしに消えた場合には、それらのゲートウェイは、いずれはそれらをタイムアウトさせ、それらの全てのキューからそれらの購読を解除し得る。そのユーザは、それらの自らのバディキューのキープアライブの参加者ではないため、そのバディキューは解体され、全ての他の参加者は購読解除され得る。そうして、他のクライアントは、そのユーザのタイムアウトを知り得る。リスナは、購読解除が生じた後であっても、MQManagerの中で保持されるため、バディ状態オブジェクトは、友人がオフラインになり、ネットワークから購読解除が受信された場合には、再度リスンする必要はない。ユーザは、新たな友人がオンラインになったことを知る。なぜなら、その友人のログイン処理の一部は、友人のバディ状態キューの全ての購読であるためである。バディリストの変更のために（例えば、友人の追加、友人の削除等）、バディ状態オブジェクトは、新たなバディの購読をリスンすることができ、それぞれの他のバディ状態キューからユーザを購読又は購読解除する。同様に、新しい最近のチャットのために、バディ状態オブジェクトは、その新しい最近のチャットのための購読をリスンすることができ、最近のチャットを行っているユーザの間の適切な購読を生成することができる。

【0053】

（一つの例示的な実施形態におけるログアウト処理）
完全に切断されたTCPコネクションにより、ゲートウェイは、全てのキューからログアウトしたユーザを購読解除する。これによって、それらのキューに対するユーザのキープアライブ状態に依存し、いくつかのキューを完全に解体し得る。万が一、不正なシャットダウンである場合には、ユーザのゲートウェイは、ユーザをタイムアウトさせ、同様のステップを実行し得る。さらに、万が一、ゲートウェイに障害が発生した場合には、キューの存在は、タイムアウトの期間に「強い（strong）」購読されたユーザが存在しない場合には、終了する。

【0054】

（一つの例示的に実施形態におけるチャット生成処理）
ユーザがクライアントにおいてチャットセッションを開始したとき、クライアントのチャットモジュール又はMQManagerは、チャットセッション識別子（chatId）を生成することができる。MQManagerは、次に、チャットのメッセージキュー（messageQueue）と状態キュー（stateQueue）のために、ユーザを生成して購読する。メッセージキューは、参加者に関心のあるものとしてマークされる。そして、メッセージキューと状態キューの両方に対しては、そのユーザは、キープアライブユーザであるものとしてマークされない。初期の参加者と継続中の参加者の情報は、実際のメッセージとアニメーションのようなチャットストリームのメッセージと同様に、messageQueueを通じて、クライアントのセッションオブジェクトのために双方向でやりとりされる。初期と継続中の席（seat）状態は、stateQueueを通じて、チャットセッションのために双方向でやりとりされる。状態キューメッセージである席の割り当ては、非同期の応答を予期し得る。従って、チャットセッションは、席のメッセージを送信する場合には、「expectAsyncResponse」フラグを真に設定し、sendMessageから返るop_idを保管し、そのop_idのための結果を有する、将来のある時点において、メッセージリスナ関数に到達する結果メッセージを予期することができる。例えば、ローカルで席）を移動することができ、メッセージを送信し、どこかで、その席の移動と、そのチャットセッションにおけるop_idとを記録することができる（例えば、op_id:(cid,old_seat,new_seat)を含むオブジェクト）。既知のop_idに対する結果のメッセージがネットワークから受信されると、op_idを含むオブジェクトからエントリを移動することができるか（席の割り当てが成功した場合）、あるいはローカルな席の移動をとりやめることができる（席の割り当てが失敗した場合）。chatIdは、名前としてのみ存在することができ、特定のチャットのキューを一意に特定することができる。あるチャットのキューの存在は、そのチャットの存在が確かに存在することを示す。

【0055】

（一つの例示的な実施形態におけるチャット参加処理）
ユーザがクライアントでチャットセッションに参加すると、クライアントのチャットモジュール又はMQManagerは、ユーザが参加しようとしているchatIdのmessageQueueとstateQueueのためにユーザを購読することができ、前記購読を、キープアライブでなく（non-keep-alive）、かつ生成していないもの（non-creating）としてマークする。キューが存在しない場合には、エラーカウンタをインクリメントすることができる。クライアントのチャットモジュール又はMQManagerは、そのchatIdのmessageQueueとstateQueueからユーザを購読解除することに責任を有し得る。

【0056】

（一つの例示的な実施形態における招待処理）
一つの特定の実施形態において、「chatgateway.attemptInvite」によるXMLRPC呼び出しは、データベースにおける招待を生成し、招待された人へsystemChatの通知を送信することができる。該通知は、それらのクライアントに、hatGateway.checkForInviteを呼び出すよう指示し、その招待を読み出し、そして許容するか、拒否する理由を提供する。許容又は拒否の理由は、それらのattemptInvite呼び出しに対して、同期の返り値として、招待した人へ返され得る。一つの代わりの実施形態において、招待した人は、招待される人へ、その返答が別のsystemChatメッセージとして非同期で送り返される、システムチャット（systemchat）の招待を送信することができる。

【0057】

（一つの特定の例示的な実施形態の詳細）
図８は、一つの例示的な実施形態において、ネットワーク環境における非持続性のメッセージについての複数のキューを管理するシステム及び方法を示す。いくつかの例示的な実施形態において、一般的にホストサイト（例えば、Webサイト）を操作するアプリケーション又はサービス１１０は、ユーザプラットフォーム１４０における複数のユーザの間の、ホストサイト１１０からの、非持続性のメッセージ及び状態の転送を単純化して促進するために提供される。ホストサイト１１０は、本開示書で説明されるように、メッセージキューシステムサイト１１０とみなすことができる。複数のユーザプラットフォーム１４０は、ユーザがコンテンツの消費者及び／又はコンテンツの提供者になり得る、複数のメッセージストリームを提供する。メッセージキューシステムサイト１１０及びユーザプラットフォーム１４０は、メッセージ、関連するコンテンツ及び情報を、広域データネットワーク（例えばインターネット）１２０を用いてやりとりすることができる。メッセージキューシステムサイト１１０の様々な要素は、内部的に、従来のイントラネット又はローカルエリアネットワーク（LAN）１１４を用いてやりとりすることもできる。

【0058】

ネットワーク１２０、１１４は、ある計算デバイスを別の計算デバイスと接続するよう構成される。ネットワーク１２０、１１４は、ある電子デバイスから別の電子デバイスへ情報を通信するための、コンピュータ読み取り可能な媒体のあらゆる形状をとることが可能である。ネットワーク１２０は、LAN１１４、WAN（wide area networks）、例えばUSB（universal serial bus）ポートを通じた直接接続、コンピュータ読み取り可能な媒体の他の形状又はそれらのあらゆる組み合わせに加えて、インターネットを含むことができる。異なるアーキテクチャとプロトコルに基づくLANを含む、相互接続されたLANの組み合わせに関して、ルータは、LANの間のリンクとして機能し、メッセージが計算デバイスへ送信されることを可能にする。さらに、LANの中の通信リンクは、一般的に、ツイストペア線又は同軸ケーブルを有し、同時に、ネットワーク間の通信リンクは、アナログの電話線、T1、T2、T3及びT4を含む、完全又は分割のデジタル専用線、ISDN（Integrated Services Digital Networks）、DSN（Digital User Lines）、衛星リンクを含む無線リンク又は当業者に知られている他の通信リンクを用いることができる。さらに、遠隔のコンピュータと他の関連する電子デバイスは、モデムと一時的な電話リンクを用いて、LAN又はWANへ間接的に接続され得る。

【0059】

ネットワーク１２０、１１４は、インフラストラクチャ指向の接続を提供するために、スタンドアロンのアドホックネットワーク等をさらに覆うことができる、あらゆる様々な無線のサブネットワークをさらに含む。そのようなサブネットワークは、メッシュネットワーク、無線LAN（WLAN）ネットワーク、携帯電話ネットワーク等を含み得る。ネットワーク１２０、１１４は、無線リンク又は無線送受信機によって接続される、端末、ゲートウェイ、ルータ等の自律システムをさらに含む。これらのコネクタは、自由かつランダムに移動するよう構成されることができ、それらを任意で組織化することができる。これにより、ネットワーク１２０、１１４のトポロジは素早く変化し得る。

【0060】

ネットワーク１２０、１１４は、第２世代（2G）、第２．５世代、第３世代（3G）、第４世代（4G）の携帯電話システム向け無線アクセス方式、WLAN、無線ルータ（Wireless Router）（WR）メッシュ等を含む、複数のアクセス技術をさらに用いることができる。2G、3G、4Gのようなアクセス技術及び将来のアクセスネットワークは、様々な移動性の程度を有する、一つ以上のクライアントデバイス１４１のようなモバイルデバイスの、広域にわたるカバレージを可能にする。例えば、ネットワーク１２０、１１４は、GSM（Global System for Mobile communication）、GPRS（General Packet Radio Services）、EDGE（Enhanced Data GSM Environment）、WCDMA（Wideband Code Division Multiple Access）、CDMA2000等のような無線ネットワークアクセスを通じて、無線接続を可能にし得る。ネットワーク１２０、１１４は、TCP/IP、UDP、SIP、SMS、RTP、WAP、CDMA、TDMA、EDGE、UMTS、GPRS、GSM、LTE、UWB、WiMax、IEEE 802.11xを含む、様々な他の有線通信プロトコルと無線通信プロトコルを用いて構成され得る。要するに、ネットワーク１２０、１１４は、情報が、ある計算デバイスと別の計算デバイスやネットワーク等との間で移動することができる、実質的にあらゆる無線及び／又は無線通信方式を含み得る。一つの実施形態において、ネットワーク１１４は、ファイアウォール（図示しない）の内部で構成された、例えばビジネスデータセンターの中のLANを表し得る。

【0061】

ユーザプラットフォーム１４０は、ネットワークで転送可能なデジタルコンテンツのあらゆる様々なプロバイダを含み得る。一般的には、使用されるファイルフォーマットはXMLであるが、いくつかの実施形態はこれに限定されず、他のファイルフォーマットが用いられ得る。例えば、HTML/XML以外のフィードフォーマット、あるいはオープンな／規格化されたフィードフォーマットが、いくつかの実施形態によってサポートされ得る。PDF（Portable Document Format）、オーディオ（例えば、MP3（Motion Picture Experts Group Audio Layer 3）等）、ビデオ（例えば、MP4等）、及び特定のコンテンツサイトにより定義される、あらゆるプロプライエタリな交換フォーマットのような、あらゆる電子ファイルフォーマットが、本開示書で説明される、いくつかの実施形態によってサポートされ得る。協調したコンテンツは、ニュースフィード、イベントリスニング、ニュース記事、ブログコンテンツ、ヘッドライン、プロジェクトの更新、ディスカッションフォーラムからの抜粋、会社又は政府情報等のようなコンテンツを含むが、これに限定されない。クレームを含む、本開示書全体を通じて用いられるように、「フィード」の用語は、時にチャネルと呼ばれ、ユーザプラットフォーム１４０からのコンテンツアクセスを可能にする、あらゆる方式を指す。

【0062】

一つの特定の実施形態において、一つ以上のクライアントデバイス１４１を有するユーザプラットフォームにより、ユーザは、メッセージキューシステムサイト１１０とネットワーク１２０を介して、他のユーザプラットフォーム１４０からのコンテンツにアクセスすることができる。クライアントデバイス１４１は、ネットワーク１２０のようなネットワークを通じて情報を送受信するよう構成された、実質的にあらゆる計算デバイスを含み得る。そのようなクライアントデバイス１４１は、携帯電話、スマートフォン、ポケットベル、無線（RF）デバイス、赤外線（IR）装置、GPS（global positioning devices）、PDA（Personal Digital Assistants）、ハンドヘルドコンピュータ、ウェアラブルコンピュータ、タブレットコンピュータ、先の一つ以上のデバイスを組み合わせる統合デバイス等のような、ポータブルデバイス１４４、１４６を含み得る。クライアントデバイス１４１は、パーソナルコンピュータ１４２、マルチプロセッサシステム、マイクロプロセッサベース又はプログラム可能なコンシューマ向け機器、ネットワークPC等のような、他の計算デバイスをさらに含み得る。このように、クライアントデバイス１４１の能力と特徴は、幅広く分布し得る。例えば、携帯電話として構成されたクライアントデバイスは、数値キーパッドと、テキストのみが表示される、２−３行の、モノクロのLCDディスプレイを有し得る。別の例では、Webに対応したクライアントデバイスは、タッチスクリーンと、スタイラスと、テキスト及び画像の両方を表示可能な、数行にわたるカラーのLCDディスプレイを有し得る。さらに、Webに対応したクライアントデバイスは、WAP（wireless application protocol message）及び／又は有線のアプリケーションメッセージ等を送受信可能なブラウザアプリケーションを含み得る。一つの実施形態において、ブラウザアプリケーションは、メッセージを表示し、送信するために、HTML（HyperText Markup Language）、ダイナミックHTML、HDML（Handheld Device Markup Language）、WML（Wireless Markup Language）、WMLScript、JavaScript、xHTML（EXtensible HTML）、コンパクトHTML（CHTML）等を用いることができる。

【0063】

クライアントデバイス１４１は、ネットワーク送信を用いて、別の計算デバイスからコンテンツ又はメッセージを受信するよう構成される、少なくとも一つのクライアントアプリケーションをさらに有し得る。クライアントアプリケーションは、テキストコンテンツ、グラフィックコンテンツ、ビデオコンテンツ、オーディオコンテンツ、警報、メッセージ、通知等を提供し、受信する能力を有し得る。さらに、クライアントデバイス１４１は、別の計算デバイス等との間で、SMS（Short Message Service）、直接のメッセージング（例えば、Twitter（登録商標））、電子メール、MMS（Multimedia Message Service）、インスタントメッセージング（IM）、IRC（internet relay chat）、mIRC、Jabber、EMS（Enhanced Messaging Service）、テキストメッセージング、スマートメッセージング、OTA（Over the Air）メッセージング等を通じて、メッセージを通信及び／又は受信するようさらに構成され得る。

【0064】

クライアントデバイス１４１は、無線アプリケーションデバイス１４８をさらに含み得る。クライアントアプリケーションは、前記デバイスのユーザが、少なくとも一つのメッセージソースを購読できるように構成される、そのような購読により、ユーザプラットフォーム１４０におけるユーザは、クライアントデバイス１４１を通じて、メッセージコンテンツの少なくとも一部を受信することができる。そのようなコンテンツは、インスタントメッセージ、Twitter（登録商標）のツイート、投稿、株価のフィード、ニュース記事、個人広告、ショッピングカタログ価格、画像、検索結果、部ログ、スポーツ、天気予報等を含み得るが、これに限定されない。さらに、コンテンツは、IM、SMS、Twitter（登録商標）、Facebook（登録商標）、MMS、IRC、EMS、オーディオメッセージ、HTML、電子メール又は他のメッセージングアプリケーションを含む、様々なあらゆる配送方式を用いて、クライアントデバイス１４１へ提供され得る。一つの特定の実施形態において、本開示書で説明されるように、コンテンツの購読のために用いられるアプリケーションの実行可能なコードは、ネットワーク１２０を介して無線アプリケーションデバイス１４８へダウンロードされ得る。

【0065】

一部の例では、ユーザプラットフォーム１４０におけるユーザは、クライアントデバイス１４１上で利用可能な全ての方式によって提供される、あるコンテンツ及び／又はコンテンツチャネルを購読することができる。本開示書で説明されるいくつかの実施形態において、ホットサイト１１０は、様々な配送方式を用いてユーザへコンテンツチャネル情報を配送するために、処理された情報を使用することができる。例えば、コンテンツチャネル情報は、二、三例を挙げると、電子メール、SMS（Short Message Service）、無線アプリケーション及び直接のメッセージング（例えばTwitter（登録商標））を用いて、ユーザへ配送され得る。さらに、コンテンツチャネル情報は、ユーザからのリクエストに応じて、ユーザへ提供され得る。

【0066】

図８をさらに参照すると、一つの例示的な実施形態のホットサイト１１０は、メッセージキューシステム２００、イントラネット１１４及びメッセージキューシステムデータベース１０５を含むように示されている。メッセージキューシステム２００は、ゲートウェイ１２、メッセージキューノード１４、スーパーバイザ１６、トランスレータ１７、状態マネージャ１８及びロードバランサ２２をさらに含み得る。これらのモジュールのそれぞれは、ホットサイト１１０上で動作するメッセージキューシステム２００の実行可能な環境の中で動作する、ソフトウェアコンポーネントとして実装され得る。一つの例示的な実施形態のこれらのモジュールのそれぞれは、本開示書で提供される図面に関連して、上でより詳細に説明される。

【0067】

図９は、いくつかの実施形態が動作し得る、ネットワークシステムについての別の例示的な実施形態１０１を表す。図示される実施形態において、ホットサイト１１０は、メッセージキューシステム２００を含むように示されている。メッセージキューシステム２００は、機能要素１２−２２を含むように表されている。一つの特定の実施形態において、ホットサイト１１０は、ユーザがユーザインターフェース又はWebインターフェースを通じてホットサイト１１０とやりとり可能な、Webインターフェースを有する、Webサーバ９０４をさらに有し得る。ホットサイト１１０は、ホットサイト１１０が、プログラムのデータ転送又は自動化されたデータ転送のレベルで、他のネットワークエンティティとやりとりすることができる、API（application programming interface）９０２を含むことができる。API９０２とWebインターフェース９０４は、直接に、あるいはインターフェース９０６を介して、メッセージキューシステム２００とやりとりするよう構成され得る。メッセージキューシステム２００は、直接に、あるいはインターフェース９０６を介して、データ記憶装置１０５へアクセスするよう構成され得る。

【0068】

図１０は、本開示書で説明される、メッセージキューシステムの一つの例示的な実施形態を表す処理フロー図である。一つの例示的な実施形態についての方法は：ゲートウェイのプロセスにおいて非持続性のメッセージを受信する段階であって、該メッセージは、名前を付されたキューを示す情報を含む、段階（処理ブロック１０１０）と；データプロセッサにより、前記名前を付されたキューを、該キューについての一貫性のあるハッシュ（consistent hash）を用いてキューノードへマッピングする段階と（処理ブロック１０２０）；前記キューノードにおいて前記メッセージをキューのプロセスへマッピングする段階と（処理ブロック１０３０）；前記キューのプロセスにより、購読者のゲートウェイのリストへアクセスする段階と（処理ブロック１０４０）；前記メッセージを前記リストの中の、前記購読者のゲートウェイの夫々へルーティングする段階と（処理ブロック１０５０）；を含む。

【0069】

図１１は、当該開示書で説明される一つ以上のあらゆる手順をコンピュータに実行させることのできる命令の組を含む、例示的なコンピュータシステムの方式におけるコンピュータを表す図である。代わりの実施形態において、コンピュータは、スタンドアロンデバイスとして動作し、あるいは、他のコンピュータへ接続（例えば、ネットワーク化）され得る。ネットワークによる展開において、コンピュータは、サーバ−クライアント環境におけるサーバコンピュータ又はクライアントコンピュータとして動作し、あるいは、ピアツーピア（又は分散）ネットワーク環境におけるピアのコンピュータとして動作し得る。コンピュータは、パーソナルコンピュータ（PC）、タブレットPC、セットトップボックス（STB）、PDA（Personal Digital Assistant）、携帯電話、Web端末、ネットワークルータ、スイッチ又はブリッジ、又は取るべき動作を特定する命令（順次又はそうでないもの）の組を実行することのできる、あらゆるコンピュータであり得る。さらに、単一のコンピュータのみが図示されているが、「コンピュータ」の用語は、本開示書で議論された、あらゆる一つ以上の方式を実行するための命令の組（あるいは複数の組）を、個別に、あるいは結合して実行する、あらゆるコンピュータの集まりを含むよう理解され得る。

【0070】

例示的なコンピュータシステム７００は、データプロセッサ７０２（例えば、CPU（central processing unit）、GPU（graphics processing unit）、又は両方）、メインメモリ７０４及びスタティックメモリ７０６を有し、互いにバス７０８を介して通信する。コンピュータシステム７００は、ビデオディスプレイユニット７１０（例えば、LCD（liquid crystal display）又はCRT（cathode ray tube））をさらに含み得る。コンピュータシステム７００は、入力デバイス７１２（例えば、キーボード）、カーソル制御デバイス７１４（例えば、マウス）、ディスクドライブユニット７１６、信号生成デバイス７１８（例えば、スピーカ）及びネットワークインターフェースデバイス７２０をさらに有する。

【0071】

ディスクドライブユニット７１６は、一時的でない、コンピュータ読み取り可能な媒体７２２を含む。該媒体は、本開示書で説明される、一つ以上のあらゆる方式又は機能を具体化する、一つ以上の命令（例えば、ソフトウェア７２４）の組を保管する。命令７２４は、完全に、あるいは少なくとも部分的に、メインメモリ７０４、スタティックメモリ７０６、及び／又はコンピュータシステム７００による実行中には、プロセッサ７０２の中に存在し得る。メインメモリ７０４とプロセッサ７０２は、コンピュータ読み取り可能な媒体を構成し得る。命令７２４は、ネットワークインターフェースデバイス７２０を用いて、ネットワーク７２６を通じてさらに送受信され得る。一つの例示的な実施形態において、コンピュータ読み取り可能な媒体７２２は、単一の媒体として表されているが、「コンピュータ読み取り可能な媒体（machine-readable medium）」の語は、一つ以上の命令の組を保管する、単一の、一時的でない媒体又は複数の媒体（例えば、集中型又は分散型データベース並びに／又は関連するキャッシュ及びサーバ）を含むよう解釈されるべきである。「コンピュータ読み取り可能な媒体」の語は、あらゆる、一時的でない媒体、又は、一時的若しくは半一時的な媒体をつくるために協調する、一時的な媒体の組み合わせを含むよう解釈し得る。その媒体は、コンピュータによる実行のための命令の組を保管し、エンコードし、実行可能であって、コンピュータに様々な実施形態の、一つ以上のあらゆる方式を実行させる。あるいは、その媒体は、そのような命令の組によって利用される、あるいはそのような命令の組と関連する、データ構造を保管し、エンコードし、あるいは実行することができる。「コンピュータ読み取り可能な媒体」の語は、従って、ソリッドステートメモリ、光学媒体及び磁気媒体を含むよう解釈され得るが、これに限定されない。

【0072】

米国特許法施行規則§1.72(b)は技術内容の本質を簡潔に伝えることを目的として要約を記載することを求めており、その要件を遵守すべく、要約を記載する。要約は、クレームの範囲又は意味を解釈し、限定するために用いられ得ないという理解のもとに、記載される。さらに、上述の詳細な説明において、開示書の簡素化の目的のために、いくつかの特徴が単一の実施形態においてまとめられているように理解され得る。開示書についてのこの方法は、クレームされる実施形態が、各クレーム内で表現的に列挙されるよりも、より多くの特徴を要求している意図を反映するものと解釈されるべきではない。むしろ、本明細書に添付のクレームが反映しているように、発明の主題は、開示された単一の実施形態の全ての特徴よりも少ない特徴に存在する。従って、本明細書に添付のクレームは、詳細な説明に組み込まれ、請求項は、それぞれが個別の実施形態として独立している。

【符号の説明】

【0073】

１０ メッセージキューシステムコア
１２ ゲートウェイ
１４ キューノード
１６ スーパーバイザ
１７ トランスレータ
１８ 状態マネージャ
２０ クライアント
２２ ロードバランサ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】