JP2014523568A - 効率的な状態調整 - Google Patents

Abstract

本明細書で説明される実施形態は、一般に、トークンを、状態更新を求めるロングポーリング要求の双方向のパラメータとして使用するための方法およびシステムに関する。クライアントが、状態更新を求めてサーバにポーリングを行い、更新は、サーバイベントの結果であり得る。サーバ状態データがハッシュされて、現在の状態データを表すトークン／ハッシュが生成される。サーバが、このトークン／ハッシュを、ポーリング要求の中でクライアントから受信されたトークン／ハッシュと比較する。これらのトークンが異なる場合、サーバは、実際の状態データをサーバトークンと一緒にクライアントに送信する。トークンを要求パラメータとして使用することによって、不要な状態更新が回避され、さらにクライアント／サーバ同期が、データのプッシュを状態更新に限定することによって、より迅速に実現される。さらに、クライアントが、トークン要求パラメータに関して空の値、またはランダムな／デフォルトの値を送信することによって、ポーリングに対する応答を強制することが可能である。

Description

[0001]ウェブブラウザなどのブラウザによるポーリングを使用して、ウェブサーバなどのサーバからデータを要求することが、ますます一般化している。ウェブブラウザとウェブサーバの間のデータ交換の際、ウェブブラウザ、またはクライアントは、通常、クライアントとサーバの間で同期を実現しようとしてコンテンツ更新を求める要求をサーバに送信する。各要求に応答して、サーバは、完全な応答を送信する。毎回、完全な応答を送信することによって、そのような要求と応答の交換は、サーバにおいてそのようなデータに更新が全く行われていない場合でさえ、クライアント要求に応答してデータが送信される場合、ネットワークリソースを不要に消費する。さらに、単一のウェブサーバと通信する多数のブラウザからのウェブサーバコンテンツおよびウェブサーバ更新を求める要求の増大が、システムリソースを逼迫させるとともに、待機時間をもたらし、このことが、クライアントコンテンツをサーバ更新と調整させようと試みる際の非効率を悪化させる。

[0002]ブラウザとサーバの間でコンテンツをより効率的に交換しようと試みる際、ハイパーテキスト転送プロトコル（ＨＴＴＰ）ロングポーリング（long polling）などのロングポーリングにより、サーバにおけるイベント、またはサーバ活動をトリガする他のイベントが生じた場合に、ウェブサーバがブラウザにデータをプッシュ（push）することが可能になる。ロングポーリングでは、ブラウザ、またはクライアントが、サーバにロングポーリング要求を送信して、サーバにおいてイベントを獲得する。そのようなロングポーリング技法は、ときとして、長期保持されるＨＴＴＰ要求を使用してサーバからブラウザにデータをプッシュすることを、ブラウザがそのようなデータを特別に要求することなしに行うための「コメット(Comet)」ウェブアプリケーションモデルの一環として言及される。通常のロングポーリング実装形態またはコメット実装形態において、クライアント要求は、サーバイベントが生じるまでサーバによって保持される。イベントが生じると、サーバは、ブラウザに完全な応答で新たなデータを送信する。このため、サーバに対する要求は、サーバが送信すべき新たなデータを入手するまで存続する。応答を受信すると、ブラウザは、サーバに別の要求を送信して、その後のイベントを待つ。しかし、各サーバ応答はサーバイベントに対応するため、コンテンツをサーバと調整させる際に不要な更新が、依然として行われるとともに、同期していないクライアントは、待機時間を経験する。これらのサーバイベントの一部は、サーバが、中間イベントに基づいて新たなデータを送信することを開始する際に、クライアントがサーバの現在の状態と同一の状態に既にある場合などに、同期を実現するのに不要である。したがって、例えば、クライアントが、インターネットからの切断に起因して同期しなくなった場合、クライアントは、それまでのサーバイベントに関するデータを有する潜在的に多数の応答メッセージを処理することによって、現在のサーバ状態に追いつこうと試みる。遅いクライアントが変化の速いサーバと同期を保つことは、このサーバはさらなる変更を行ってしまっている一方で、そのクライアントは、しばしば、それまでのイベントを依然として処理しているため、過度に困難であり得る。さらに、クライアントがサーバに遅れをとった場合、一部の中間イベントは、クライアントがサーバとの同期を達するのに無視する可能性がある。しかし、サーバイベントに基づくデータプッシュは、サーバの現在の状態との最終的な同期を実現するのにイベントを使用しないにもかかわらず、イベントをクライアントにプッシュする。

[0003]この「背景技術」において特定の問題を扱ってきたが、本開示は、それらの特定の問題を解決することに限定されることは全く意図していない。

[0004]実施形態は、一般に、サーバにおける状態データを、トークン機構を介してクライアントにプッシュすることに関する。具体的には、トークンが、状態更新を求めるロングポーリング要求の多方向の、例えば、双方向のパラメータとして使用されて、サーバ（複数可）とクライアント（複数可）の間の効率的な状態調整が実現される。ウェブサーバなどのサーバが、状態更新を受信する。例えば、サーバが、文書編集セッションを備える或るアプリケーションから状態更新を受信することが可能であり、このセッションの中で共同作成の文書に行われた変更が、例えば、サーバ、またはサーバ上で実行される管理モジュールに送信される。次に、管理モジュールが、受信された状態更新を反映するようにサーバの状態を変更する。次に、サーバが、サーバとクライアントの間の同期が所望される状態のダイジェスト（digest）／ハッシュを計算する。そうする際に、そのハッシュ値を備えるトークンが生成される。何らかの状態更新を求める要求をクライアントから受信すると、サーバは、そのクライアント要求と一緒に受信されたトークンをサーバ上のトークンと比較して、それらのトークンが異なるかどうかを判定する。それらのトークンが異ならない場合、クライアントは、データの現在の状態を有しており、クライアントのコンテンツをサーバとさらに調整させる必要がない。代わりに、サーバが、サーバ状態の変化が生じるまで、受信されたトークンと一緒にそのクライアント要求、すなわち、長期保持される要求を保持する。しかし、それらのトークンが異なる場合、クライアントは、現在の状態を有さない。すると、サーバが、実際の状態を、サーバ上の現在のトークンと一緒にクライアントに送信する。いくつかの実施形態において、次に、クライアントが、クライアントのデータを更新し、受信されたトークンを、状態更新を求める後の要求と一緒に送信するために格納することが可能である。前述したとおり、いくつかの実施形態において、クライアントからの要求は、ロングポーリング技法の一環としての長期保持される要求である。さらなる実施形態において、クライアントによるロングポーリングは、ＨＴＴＰロングポーリングで構成される。他の実施形態において、通常のポーリングが使用される。

[0005]さらなる実施形態において、クライアントは、状態更新を求める要求に即時に応答するようサーバを強制することが可能である。他の実施形態において、サーバは、例えば、所定の期間内に、またはサーバが応答することが可能であるとシステムリソースの利用可能性によって決定されると、応答するよう強制される。応答するようサーバを強制する際、クライアントは、或る実施形態によれば、サーバに、クライアントの長期保持される要求の中の要求パラメータとしてトークン値に関して空の値を送信する。別の実施形態において、クライアントは、サーバに、クライアントの長期保持される要求の中の要求パラメータとしてトークン値に関してランダムな／デフォルトの値を送信し、このランダムな／デフォルトの値は、サーバ上の現在のトークン値と合致する可能性の低い値である。空の値、またはランダムな／デフォルトの値により、サーバは、サーバ上のトークンとクライアントから受信されたトークンが合致しないことを判定させられる。その結果、サーバは、クライアントに、サーバの状態データ、およびサーバ上のトークンを送信することによって即時に返信する。このため、クライアントは、サーバがデータを定期的にプッシュして戻すのを、またはサーバイベントが生じるのを待つことなしに、クライアントのポーリング要求に対する即時の応答を得ることができる。

[0006]この「発明の概要」は、「発明を実施するための形態」において後段でさらに説明されるいくつかの選定された概念を簡略化された形態で紹介するように与えられる。この「発明の概要」は、主張される主題の重要な特徴、または不可欠な特徴を特定することは意図しておらず、主張される主題の範囲を限定することも全く意図していない。

[0007]本開示の実施形態は、添付の図面を参照することによって、より容易に説明することが可能であり、図面では、同様の参照符号は同様の項目を指す。

[0008]本明細書で開示される実施形態による、状態更新を求める長期保持される要求のパラメータとしてトークンを使用するための環境またはシステムを示す例示的な論理図である。 [0009]本明細書で開示される実施形態による、状態更新を求める長期保持される要求のパラメータとしてトークンを使用するためのさらなるタイプの環境またはシステム、例えば、３層アーキテクチャを示す例示的な論理図である。 [0010]本開示の実施形態による、図１Ａおよび図１Ｂに示される例示的な環境において状態更新を求める長期保持される要求のパラメータとしてトークンを使用するためのソフトウェアモジュールを示す例示的な論理図である。 [0011]本開示の実施形態による、状態と一緒に、要求パラメータとして、さらに応答戻り値としてトークン／ハッシュを使用するための環境またはシステムを示す例示的な論理図である。 [0012]本開示の実施形態による、状態更新をプッシュすべきかどうかを判定するための方法の動作特性を表す流れ図である。 [0013]本開示の或る実施形態による、トークンを比較して、状態が変化しているかどうかを判定するための方法の動作特性を表す流れ図である。 [0014]本開示の実施形態による、状態更新を求める要求に対する応答を強制するための方法の動作特性を表す流れ図である。 [0015]本開示の或る実施形態による、データをプッシュするように空のトークン値またはランダムな／デフォルトのトークン値を受信するための方法の動作特性を表す流れ図である。 [0016]本開示の実施形態が実施可能な例示的なコンピューティングシステムを示す図である。

[0017]次に、本開示において、特定の実施形態が示される添付の図面を参照して、例示的な実施形態をより完全に説明する。しかし、他の態様が、異なる多くの形態で具現化され得、本開示に特定の実施形態が含められることは、そのような態様を、本明細書で説明される実施形態に限定するものと解釈されるべきではない。むしろ、図面に示される実施形態は、徹底的で、完全であるとともに、意図される範囲を当業者に十分に伝える開示を与えるように含められる。破線が、オプションのコンポーネント、またはオプションの動作を示すのに使用され得る。

[0018]実施形態は、一般に、トークン機構をロングポーリングと一緒に使用して、サーバが、サーバイベントではなく、データの状態の変化に基づいてクライアントまたはブラウザにデータをプッシュすることを可能にすることに関する。状態更新を伴うサーバメッセージだけをクライアントに送信することにより、データの不要な交換が回避され、このため、システム効率が向上する。例えば、プレゼンタが、ウェブ会議環境においてそれぞれのウェブブラウザから通信する様々なユーザとプレゼンテーションスライドショーを共有する共同作成プレゼンテーションアプリケーションにおいて、プレゼンタが、スライド＃１でスライドショーを始めることが可能である。ウェブブラウザＡにおけるクライアントＡが、クライアントＡのコンピュータコンピュータのユーザインターフェースモジュールを介してスライド＃１をクライアントＡが同時に表示している現在の状態を有することが可能である。プレゼンタが、次に、例えば、スライド＃５に切り換えて、別の聴衆メンバーからの質問に答える。その間に、クライアントＡがウェブ会議から切断される。次に、プレゼンタは、スライド＃３に切り換え、その後、スライド＃１に戻る。再接続すると、クライアントＡが、現在の状態を所望する。トークン機構に基づくロングポーリングを介して、サーバ、またはサーバ上に存在する管理モジュールは、プレゼンタがスライド＃１に戻るように切り換えたため、クライアントＡが現在の状態を有すると判定する。したがって、クライアントＡに状態更新は、全く送信されない。他方、従来のサーバイベント駆動のポーリング技法では、クライアントＡにまず、スライド＃５およびスライド＃３と関係する更新が送信されてから、クライアントＡは、最終的にスライド＃１でサーバと同期する。さらに、クライアントＡがスライド＃１に戻った頃には、プレゼンタは、例えば、スライド＃２に既に切り換えている可能性がある。このため、サーバ応答を状態更新に制限するトークン機構を介するロングポーリングは、例えば、より高速に、かつより安価にデータをクライアントブラウザに通信すること、およびクライアントとサーバの間のデータの整合性および同期を高めることを含む、多数の利益をもたらす。

[0019]或る実施形態において、ウェブサーバなどのサーバが、文書編集セッションを備えるアプリケーションなどから状態更新を受信する。いくつかの実施形態において、そのような更新は、サーバ上に存在するマネージャにおいて、または管理モジュールにおいて受信される。次に、サーバにおける状態が、この受信された状態更新を反映するように変更される。この状態は、状態のハッシュ値を備えるトークンを生成するようにハッシュされる。いくつかの実施形態によれば、サーバが状態更新を求める何らかのクライアント要求、例えば、長期保持される要求を受信すると、サーバは、クライアントから受信されたトークンをサーバ上のトークンへの要求と比較する。それらのトークンが合致した場合、そのクライアントは、サーバと同期しており、例えば、そのクライアントは、データの現在の状態を有する。したがって、サーバは、そのクライアント要求、および受信されたトークンを保持する。他方、それらのトークンが異なる場合、クライアントは、サーバと同期しておらず、データの現在の状態を有さない。したがって、サーバは、実際の状態を、サーバ上の現在のトークンと一緒にクライアントにプッシュする。いくつかの実施形態において、次に、クライアントは、クライアントのデータを更新することが可能である。さらなる実施形態において、クライアントは、受信されたトークンを、状態更新を求める後の要求と一緒に送信するために格納することもする。いくつかの実施形態によれば、したがって、クライアントとサーバは、データの交換のために永続的な接続を保ち、状態データは、クライアントがそのデータの現在の状態を有さないと判定された場合に限り、クライアントに送信される。前述したとおり、いくつかの実施形態において、クライアントからの要求は、ロングポーリング技法の一環としての長期保持される要求である。さらなる実施形態において、クライアントによるロングポーリングは、ＨＴＴＰロングポーリングで構成される。他の実施形態において、通常のポーリングが使用される。

[0020]このため、トークン機構の使用を介して、サーバは、データセット全体ではなく、トークンを比較して、状態が変化しているかどうかを判定することができる。このため、状態データ自体ではなく、トークン値を比較することは、クライアント要求に対するサーバ応答時間を大幅に減少させる。さらに、サーバが、状態の違いが生じたと判定した時点で、サーバのもたらされた現在の状態に影響を与えていない可能性がある介在するイベントではなく、現在の状態をクライアントに送信するため、不要な状態更新が回避される。このため、いくつかの実施形態は、サーバ応答のデータが、サーバイベントではなく、状態更新に限定されるようにする。その結果、クライアントコンテンツとサーバコンテンツの間の整合性が向上し、さらにデータが、より高速に、かつシステムリソースをそれほど不必要に消費することなしに、通信される。

[0021]さらに、ロングポーリングでは、クライアントは、状態データの以前の受信から状態が変化しているかどうかを調べる迅速な方法を有する。いくつかの実施形態において、クライアントは、より大きい可能性が高く、さらに／または実際の状態を判定するのがより複雑である可能性がある状態データの代わりに、単にトークン、またはトークン値を比較することが可能である。

[0022]さらなる実施形態によれば、クライアントは、サーバに、クライアントの長期保持されるポーリング要求の中のトークン値に関して空の値、またはランダムな／デフォルトの値を送信することによって、状態更新を求める要求に対するサーバからの即時の応答を強制することが可能である。他の実施形態において、この応答は、例えば、所定の期間内に、またはサーバが応答することをシステムリソースの利用可能性が許す場合に、強制される。空の値、またはランダムな／デフォルトの値により、サーバは、サーバ上のトークンと受信されたトークンが異なると判定させられる。その結果、サーバは、クライアントに、サーバの状態データ、およびサーバ上のトークンを送信することによって即時に返信する。このため、クライアントは、次の通常のサーバプッシュを待つことなしに、即時の応答を得ることができる。このため、クライアントは、クライアントがサーバとの接続を最初に開始した際、またはクライアントが切断された、またはそれ以外でサーバコンテンツの変化に遅れをとった際などに、サーバとより迅速に同期することが可能である。このため、トークンに関して空の値、またはランダムな／デフォルトの値を送信することにより、サーバエンドポイントがロングポーリングから通常のポーリングに論理的に切り換わることが可能になる。

[0023]さらに、一部の実施形態が示すとおり、トークンの使用は、クライアントが、サーバ応答のタイミングに依拠しないよう強制する。したがって、サーバは、ロングポーリング要求と一緒にクライアントから受信されたトークンがサーバ上のトークンと合致する場合でさえ、即時に返信するオプションを有する。そのような柔軟性は、例えば、サーバ（複数可）がシャットダウンしている場合に、またはサーバ（複数可）がオープンな接続を有することを所望しないときに他の何らかの動作を行っている場合に役に立つ。

[0024]図１Ａを参照すると、本開示の実施形態による、状態更新を求める長期保持される要求のパラメータとしてトークンを使用するための例示的な論理環境または論理システム１００Ａが、示されている。クライアントコンピュータ１０２が、状態更新を求める要求１２８をサーバ１０８に送信する。或る実施形態において、サーバ１０８は、フロントエンドサーバと呼ばれる。いくつかの実施形態において、省略記号１１０およびサーバ１１２で示されるとおり、任意の数のサーバが使用され得る。クライアントコンピュータ１０２は、ユーザ１０４が、例えば、ウェブページを閲覧するための、ウェブブラウザなどのブラウザを実行する。そのようなウェブページまたは文書または他のデータは、例えば、クライアントコンピュータ１０２上で実行されるユーザインターフェースモジュールを介してユーザインターフェースに表示、または出力される。クライアントコンピュータ１０２からサーバ１０８に送信される状態更新を求める要求１２８は、ネットワーク１０６を介して送信される。状態更新を求める要求１２８は、パラメータとしてトークンを備える。要求１２８の中のトークンは、クライアントによって理解されるように、サーバにおける状態のハッシュである。例えば、或る実施形態において、クライアントが、状態更新を求める以前の要求に対するサーバによる応答の中でトークンを受信していることが可能である。別の実施形態において、要求１２８の中のトークン値は、空の値、もしくはランダムな／デフォルトの値、または任意のタイプの「ダミー」値を備えることが可能である。そのような空の値、もしくはランダムな／デフォルトの値、またはダミー値は、或る実施形態によれば、クライアントがサーバと最初に連絡を開始する場合などの、クライアントが値を知らない場合に含められることが可能である。別の実施形態において、空の値、もしくはランダムな／デフォルトの値、またはダミー値は、状態更新を求めるクライアントの要求に即時に応答するようサーバを強制するようにクライアントによって（正しいトークン値を無視しながら）意図的に使用される。別の実施形態において、サーバ返信は、サーバが返信することができるようになるとすぐに行われる。さらに別の実施形態において、サーバ返信は、サーバによって設定された所定の期間内に行われる。さらに別の実施形態において、サーバ返信は、クライアントによって設定された所定の期間内に行われる。図１Ａにおいて、要求１２８は、ＨＴＴＰ要求、「ＧｅｔＳｔａｔｅ」を備えるものとして示されているが、本開示の実施形態による任意のタイプの要求が、本開示の趣旨および範囲を逸脱することなく使用され得る。

[0025]トークンを伴う状態更新を求める要求１２８を受信したことに応答して、サーバ１０８は、サーバ上の現在のトークンが受信されたトークンと合致するかどうかを判定する。それらのトークンが合致しない場合、サーバ１０８は、状態データ１３０と一緒にサーバ上のトークン値をクライアント１０２に送信することによって応答する。

[0026]図１Ａが、クライアントコンピュータ１０２とサーバ１０８の間のメッセージ交換を示す一方で、図１Ｂは、本開示のさらなる実施形態による、サーバ１０８がバックエンドサーバ１１６と通信状態にあるフロントエンドサーバである、さらなるオプションの環境１００Ｂも示す。図１Ａおよび図１Ｂは、本開示の機能が実施され得る例示的な論理環境を示す。論理環境１００Ａおよび１００Ｂは、いずれの特定の実装形態にも限定されるものではなく、本明細書で説明される環境の機能が実施可能な任意のコンピューティング環境を具現化する。図１Ａおよび図１Ｂは、例示の目的で提供される。

[0027]図１Ｂを参照すると、バックエンドサーバ１１６が例示されているが、本明細書で開示されるいくつかの実施形態により、省略記号１１８およびバックエンドサーバ１２０で示されるとおり、複数のバックエンドサーバが使用されてもよい。図１Ａに示されるとおり、一部の実施形態は、クライアントコンピュータ１０２およびサーバ１０８に関してトークン機構を介したロングポーリングが、バックエンドサーバ（複数可）なしに行われるように規定するため、バックエンド環境内のコンポーネントは、オプションのコンポーネントとして破線で示される。図１Ｂに示されるバックエンドサーバ１１６〜１２０が関与する可能な実施形態において、サーバ１０８は、フロントエンドサーバと呼ばれ、フロントエンドサーバ１０８（または１１０、１１２）は、クライアント１０２から最初に受信された状態更新を求める要求１３２を、バックエンドサーバ１１６に通信する。図示されるとおり、本開示のいくつかの実施形態によれば、複数のバックエンドサーバが、省略記号１１８およびバックエンドサーバ１２０で示されるとおり使用され得る。状態更新を求める要求１３２は、その要求のパラメータとしてトークンを備える。要求１３２は、図１Ｂでは、ＨＴＴＰ要求、「ＧｅｔＳｔａｔｅ」を備えるものとして示されているが、本開示のいくつかの実施形態による任意のタイプの要求が、本開示の趣旨および範囲を逸脱することなく使用され得る。

[0028]いくつかの実施形態において、クライアントから状態更新を求める要求１３２がトークンと一緒に受信されると、バックエンドサーバ１１６が、サーバ上のトークンを受信されたトークンと比較する。或る実施形態において、サーバ１１６（またはサーバ１１８、１２０）上で実行されるマネージャ（もしくは管理）モジュールまたはマネージャ（もしくは管理）コンポーネント１２２が、サーバ上のトークンを、クライアントから受信されたトークンと比較する。図１Ｂで、モジュール１２２は、「マネージャ」モジュールまたは「マネージャ」コンポーネントと呼ばれるが、このモジュールまたはコンポーネントは、本開示の趣旨および範囲を逸脱することなく、任意の名称で呼ばれることが可能である。さらに、管理モジュール１２２は、いくつかの実施形態によれば、ソフトウェアを備えることが可能である一方で、他の実施形態は、このコンポーネントが、本明細書で説明される方法を実行するためのコンピュータプログラミングコードのためのハードウェアであるように規定する。

[0029]或る実施形態において、サーバ１１６および／またはマネージャモジュール１２２が、サーバにおける状態をハッシュすることによってサーバ上のトークンの値を計算する。状態更新１３４は、いくつかの実施形態によれば、例えば、文書編集セッション１２６を備えるアプリケーションからネットワーク１２４を介して受信される。他の実施形態において、状態更新は、別のサーバ、クライアントコンピュータ、コンピュータシステム、別のコンピューティングシステム上で実行されるワークフロー、および／またはウェブブラウザなどから受信される。文書編集セッション１２６は、本開示の教示を例示する目的のために単に例として与えられている。本開示のいくつかの実施形態によれば、トークン値は、データベース１３８の中に格納され得、または他の実施形態において、トークン値は、例えば、サーバ１１６（もしくは１１８、１２０）に取り付けられたデータベース（複数可）の中に格納され得る。

[0030]サーバ１１６および／またはマネージャモジュール１２２は、クライアントから受信されたトークン１３２がサーバ１１６上のトークンと異なるかどうかを判定する。それらの値が異なる場合、サーバ１１６は、サーバ上のトークンと一緒にデータ１３６を、ネットワーク１１４を介してフロントエンドサーバ１０８に送信することによってクライアント要求に応答する。このデータおよびトークンを受信すると、或る実施形態によれば、フロントエンドサーバ１０８は、状態データおよびトークン１３０を、ネットワーク１０６を介してクライアント１０２に送信する。別の実施形態において、フロントエンドサーバ１０８は、このデータおよびトークンを、このデータおよびトークンを受信した時点で送信せず、代わりに、或る期間、待つ。そのような期間は、いくつかの実施形態によれば、所定であり、または他の実施形態では、利用可能なシステムリソースに依存する。

[0031]或る実施形態において、サーバ１１６（および／またはサーバ１０８）から送信されるデータ１３６（または１３０）は、状態更新（複数可）を反映する状態データを備える。他の実施形態において、サーバ１１６（および／またはサーバ１０８）からのデータ１３６（または１３０）は、状態更新に加えてデータを備える。いくつかの実施形態は、要求１２８および１３２の中のトークンが、状態更新を求める要求にパラメータとして含められるべきことを規定するが、さらなる実施形態において、要求１２８および１３２に関連して送信されるトークンは、これらの要求とは別個に送信される。さらに、いくつかの実施形態は、サーバ上のトークンが、応答１３６または１３０の中で状態データと一緒に送信されるべきことを規定するが、他の実施形態は、サーバ上のトークンが、このデータとは別個に送信されるべきことを規定する。

[0032]論理環境１００Ａおよび１００Ｂは、いずれの特定の実装形態にも限定されるものではなく、本明細書で説明される環境の機能が実施可能な任意のコンピューティング環境を具現化する。例えば、いくつかの実施形態によれば、当業者によって理解される任意のタイプのクライアントコンピュータ１０２が使用され得る。さらに、ネットワーク１０６、１１４、および１２４は、個々の単独のネットワークとして示されるものの、当業者によって従来、理解される任意のタイプのネットワークであることが可能である。或る実施形態によれば、ネットワークは、グローバルネットワーク（例えば、インターネットまたはワールドワイドウェブ、すなわち、省略して「ウェブ」）であってもよい。また、ネットワークは、ローカルエリアネットワーク、例えば、イントラネット、またはワイドエリアネットワークであることも可能である。いくつかの実施形態において、ネットワーク１０６、１１４、および１２４を介する通信は、１つまたは複数の標準パケットベースのフォーマット、例えば、Ｈ．３２３、ＩＰ、イーサネット（登録商標）、および／またはＡＴＭに準拠して行われる。

[0033]さらに、当業者によって理解されるように考えられる任意の環境またはシステムが、本開示の実施形態により、使用され得る。図１Ａおよび図１Ｂは、本明細書で開示される実施形態の教示を理解する目的でのみ、例として与えられる。例えば、図１Ｂは、サーバ１０８〜１１２および１１６〜１２０を示す。しかし、いくつかの実施形態は、任意のタイプのサーバ、別個のサーバ、サーバファーム、サーバクラスタ、または他のメッセージサーバも範囲に含む。さらに、図１Ａおよび図１Ｂは、クライアントコンピュータ１０２を示す。しかし、本明細書で開示される実施形態の趣旨および範囲を逸脱することなく、当業者によって理解されるように任意のタイプの小型コンピュータデバイスが使用され得る。１つのクライアントコンピュータ１０２しか図示されないものの、例えば、別の実施形態は、複数の小型コンピュータデバイスがサーバ１０８〜１１２および／または１１６〜１２０と通信するように規定する。或る実施形態において、各小型コンピュータデバイスは、ネットワーク１０６と通信し、または他の実施形態において、複数の別々のネットワークが、小型コンピュータデバイスと通信する。さらに別の実施形態において、各小型コンピュータデバイスが、別個のネットワークと通信する。実際、環境またはシステム１００Ａおよび１００Ｂは、本明細書で開示されるいくつかの実施形態を実施する有効な方法を表すが、本開示の範囲を限定することは全く意図していない。さらに、例示的なネットワーク環境１００Ａおよび１００Ｂは、説明される特定のコンポーネント、例えば、サーバ、クライアントコンピュータなどに関連して考えられることが可能であり、あるいは、そのようなユニットに対応する類似したモジュールに関連して考えられてもよい。

[0034]図１Ｂは、クライアントコンピュータ１０２、ならびにサーバ１０８〜１１２および１１６〜１２０を示すが、図２Ａは、本開示のいくつかの実施形態による、状態更新を求める長期保持されるポーリング要求のパラメータとしてトークンを使用するためのソフトウェアモジュールまたはソフトウェアコンポーネントの論理図２００Ａを示す。クライアントコンピュータ２０２Ａは、状態更新に関してサーバ２０４Ａにポーリングするためのウェブブラウザモジュール２０６を備える。他の実施形態において、クライアントコンピュータ２０２Ａは、ウェブブラウザモジュール２０６を使用することなしにサーバ２０４Ａにポーリングを行う。さらなる実施形態は、クライアントコンピュータ２０２Ａが、サーバ２０４Ａから受信されるウェブページ、文書、データなどを閲覧するためのユーザインターフェースを表示するようにクライアントコンピュータ２０２Ａ上で実行されるユーザインターフェースモジュール２０７を含め、さらなるモジュールを備えるように規定する。クライアントコンピュータ２０２Ａは、本明細書で開示されるいくつかの実施形態によれば、トークン機構を介してロングポーリングをもたらすための、省略記号２０８で示される他のモジュールまたはコンポーネント２１０を備える。

[0035]トークン機構を介して状態更新を求めるロングポーリング要求を受信したことに応答して、サーバ２０４Ａは、その受信された要求およびトークンを解析する。例えば、或る実施形態において、サーバ２０４Ａは、サーバ２０４Ａ上で実行される管理モジュール２１２を備える。管理モジュール２１２は、例えば、図１Ｂのマネージャモジュールまたはマネージャコンポーネント１２２に対応し、本開示の趣旨および範囲を逸脱することなく、任意の名称で呼ばれることが可能である。管理モジュールまたは管理コンポーネント２１２は、例えば、文書編集セッションを備えるアプリケーションなどから、状態更新を受信する。管理モジュール２１２は、それらの状態更新を反映するようにサーバ２０４Ａの状態を変更し、さらに状態をハッシュする。このハッシュされた状態値が、サーバの状態を反映するサーバ上のトークンを生成するのに使用される。例示的な実施形態によれば、管理モジュール２１２は、クライアント２０２Ａから受信されたトークン（複数可）と比較するのにサーバ上のトークンを使用して、クライアントの状態データが現在のものであるかどうかを判定する。このため、いくつかの実施形態において、管理モジュール２１２は、例えば、クライアントから受信されたトークン値を評価することによって状態更新を求めるクライアント要求に応答することを規定する。本開示のいくつかの実施形態によれば、サーバ２０４Ａは、トークン機構を介して状態更新を求める長期保持される要求に応答するための、省略記号２１４で示される他のモジュールまたはコンポーネント２１６を備える。

[0036]図２Ｂを参照すると、本開示のいくつかの実施形態によるクライアント２０２Ｂからサーバ２０４Ｂに状態更新を要求するための環境またはシステム２００Ｂの論理図が示されている。例えば、図２Ａのクライアント２０２Ａに対応するようなクライアント２０２Ｂが、要求２１８を、要求２１８のパラメータとしてのトークンと一緒にサーバ２０４Ｂに送信する。例えば、サーバ２０４Ｂは、図２Ａのサーバ２０４Ａに対応する。要求２１８は、ＨＴＴＰ要求、「ＧｅｔＳｔａｔｅ」を備えるものとして図１Ａおよび図１Ｂに示されているが、本開示の趣旨および範囲を逸脱することなく、本開示の実施形態により任意のタイプの要求が使用され得る。これに応答して、サーバ２０４Ｂは、いくつかの実施形態によれば、状態データと、サーバ上のトークンとを備える応答メッセージ２２０をクライアント２０２Ｂに送信する。図２Ｂは、単一の要求２１８、および単一の応答２２０を示すが、他の実施形態では、複数の要求、および複数の応答メッセージが可能である。さらに、いくつかの実施形態は、要求２１８が、トークン機構を介するロングポーリング技法の一環としての長期保持される要求であるように規定するが、他の実施形態では、トークン機構を介した通常のポーリング技法が可能である。さらなる実施形態において、要求メッセージ２１８は、いずれのタイプのポーリング技法も関与することなく、クライアント２０２Ｂからサーバ２０４Ｂに送信される。図２Ａおよび図２Ｂは、例示的なコンポーネントおよび／またはモジュールを示すが、これらのコンポーネントおよび／またはモジュールは、本開示の教示を例示する目的のために単に例として与えられる。いくつかの実施形態において、複数のモジュール、および／または複数のコンポーネントが組み合わされてもよい。さらに、本開示の趣旨および範囲を逸脱することなく、さらなるモジュールおよび／またはコンポーネント、またはより少ないモジュールおよび／またはコンポーネントが使用されてもよい。

[0037]次に、図３が、本開示のいくつかの実施形態による、クライアントおよび／またはブラウザに状態更新をプッシュすべきかどうかを判定するための例示的な動作ステップ３００を示す。図３に示される例示的な動作ステップ３００は、或る実施形態により、サーバおよび／または管理コンポーネントの見地から示される。方法３００が、開始動作３０２で開始され、さらに状態更新を受信すること（３０４）に進み、サーバ、および／またはサーバ上で実行される管理コンポーネントが、文書編集セッションから、例えば、文書および／またはウェブページの変更などの状態更新を受信する（３０４）。例えば、ウェブページの編集が、アプリケーションプログラムの共同作成セッションにおいて行われることが可能である。次に、サーバが、受信された状態更新（複数可）に基づいて、サーバにおける状態を変更する（３０６）。或る実施形態において、サーバはまず、受信された状態更新がサーバにおける状態データの実際の変更を表すかどうかを判定する。受信された状態更新から状態データの実際の変更がもたらされる場合、いくつかの実施形態によれば、サーバの状態データが変更される（３０６）。次に、方法３００は、状態をハッシュする動作３０８に進み、その状態がハッシュされてトークンの値が生成される（３１０）。いくつかの実施形態において、このトークンが格納される。クエリ３１２が、保留中のトークンが存在するかどうかを判定する。例えば、ロングポーリングで長期保持される要求が関与するいくつかの実施形態において、例えば、サーバは、サーバで現在、保留中の状態更新を求める要求の中で、クライアントコンピュータおよび／またはブラウザからトークンを受信していることが可能である。トークンが保留中である場合、方法３００は、「はい」でクエリ３１４に進み、保留中のクライアントトークンがサーバ上のトークンと合致するかどうかを判定する。それらのトークンが合致しない場合、方法３００は、「いいえ」に進み、データをトークンと一緒に送信し（３１６）、状態データ、およびサーバ上のトークン値がクライアントに送信される（３１６）。その後、方法３００は、終了動作３１８で終了する。

[0038]クエリ３１２に戻ると、保留中であるトークンが存在しない場合、方法３００は、「いいえ」でクエリ３２２に進み、状態更新を求める要求と一緒にクライアントなどから、トークンが受信されているかどうかを判定する。トークンが受信されていない場合、方法３００は、「いいえ」に進み、サーバが状態のさらなる変更を受信すること（３０４）が可能な状態更新を受信する（３０４）。その後、ステップ３０４からクエリ３１２までが繰り返される。クエリ３２２で、クライアントからトークンが受信された場合、方法３００は、「はい」でクエリ３１４に進み、サーバ上のトークンが、クライアントからの受信されたトークンと異なるかどうかが判定される。それらのトークンが合致した場合、方法３００は、「はい」でステップ３２０に進み、クライアント要求、例えば、長期保持される要求を、受信されたトークンと一緒に保持する。次に、方法３００は、状態更新を受信すること（３０４）に進み、さらに、その後、ステップ３０４〜３１２が繰り返される。それらのトークンが合致しない場合、方法３００は、「いいえ」に進み、状態データを、サーバ上のトークン値と一緒にクライアントに送信する（３１６）。その後、方法３００は、終了動作３１８で終了する。

[0039]図３は、状態更新をプッシュすべきかどうかを判定するための方法の例示的な動作ステップを示すが、図４は、本開示の或る実施形態による、トークンを比較して、状態が変化しているかどうかを判定するための例示的な動作ステップを示す。図４に示される例示的な動作ステップ４００は、或る実施形態により、クライアントおよび／またはブラウザの見地から示される。方法４００が、開始動作４０２で開始され、さらに状態を所望するクエリ４０４に進み、クライアント（および／またはブラウザ）がサーバにおける現在の状態を所望するかどうかが判定される。例えば、クライアントは、或る実施形態によれば、クライアントがサーバと同期しているかどうかを知ることを所望する可能性がある。サーバにおける状態が所望されない場合、方法４００は、「いいえ」で終了動作４２０に進み、方法４００が終了する。しかし、サーバにおける状態が所望される場合、方法４００は、「はい」に進み、第１のトークン／ハッシュパラメータで状態を要求し（４０６）、クライアントが、現在の状態を求めてサーバに要求を送信する。或る実施形態において、この要求は、サーバから状態更新を得るロングポーリング技法の一環としての長期保持される要求である。本開示のいくつかの実施形態によれば、第１のトークン、つまり、クライアントトークンが、要求のパラメータとして、この要求と一緒に送信される（４０６）。例えば、或る実施形態において、クライアントがそれまでに、サーバからトークン値を受信していることが可能であり、クライアントは、このトークン値を要求パラメータとしてサーバに送信する。別の実施形態において、クライアントは、このトークン値を空の値、もしくはランダムな／デフォルトの値、またはダミー値に設定する。さらに別の実施形態において、このトークンは、クライアント要求とは別個に送信される。

[0040]状態更新を求める要求に応答して、クライアントは、状態データを第２のトークンと一緒に受信する（４０８）。或る実施形態において、第２のトークンは、サーバ上のトークンの値であり、サーバ上のトークンの値は、サーバにおける現在の状態のハッシュを表す。いくつかの実施形態は、サーバ上のトークンが、応答（状態データを備える）のパラメータとしてクライアントに送信されることを規定する。他の実施形態において、このトークンは、状態データとは別個に送信される。次に、クライアントが、クライアントがそれらのトークンを比較して、サーバにおいて状態変化が存在するかどうかを判定することを所望するかどうかを決定する（４１０）。いくつかの実施形態において、それらのトークンを比較することは、状態が前回の状態更新から変化しているかどうかをクライアントが手早く調べる方法をもたらす。クライアントは、例えば、より大きい／より複雑な状態データの代わりにトークンを比較することが可能である。クライアントがトークンを比較することを所望する場合、方法４００は、「はい」でクエリ４１２に進み、それらのトークンが異なるかどうかを判定する（４１２）。それらのトークンが異ならない場合、例えば、それらのトークンが合致する場合、方法４００は、「いいえ」でクエリ４０４に進み、クライアントが状態更新を要求することを所望するかどうかを判定し、さらに、その後、いくつかの実施形態によれば、方法４００は、ステップ４０４〜４１０を繰り返す、または終了動作４２０で終了する。他方、それらのトークンが異なる場合、いくつかの実施形態によれば、方法４００は、「はい」で状態を更新する（４１６）に進み、クライアントが、状態データを更新し（４１６）、さらに第２のトークン、すなわち、ステップ４０８でサーバから受信されたトークン値を格納する（４１８）。

[0041]クエリ４１０に戻ると、クライアントが、トークンを比較して、状態変化が存在するかどうかを判定することを所望しない場合、方法４００は、「いいえ」でクエリ４１４に進み、クライアントにおける状態データが、ステップ４０８でサーバから受信された状態データと異なるかどうかを判定する。いくつかの実施形態において、状態データが異なるかどうかを判定することは、例えば、クエリ４１２でトークンが異なるかどうかを判定することよりも、相当に複雑である。状態データが異なる場合、方法４００は、「はい」で状態を更新する動作４１６に進み、さらに第２のトークンを格納し（４１８）、クライアントが、後の要求と一緒に送信するように、サーバから受信されたトークンまたはトークン値を格納する。いくつかの実施形態において、クライアントは、第２のトークンを無差別に格納し、アプリケーションが要求するのに応じて受信された状態データを使用する。第２のトークンを格納することによって、クライアントは、状態更新を求めるサーバに対する後の要求の中で、第２のトークンをこの後の要求の中にパラメータとして含めることによって、クライアントの現在の状態を示すことが可能である。クエリ４１４で状態データが異なる場合、いくつかの実施形態によれば、方法４００は、「いいえ」で状態を所望するクエリ４０４に進み、さらにステップ４０４〜４１０が繰り返され、または方法４００は、終了動作４２０で終了する。

[0042]図５を参照すると、本開示のいくつかの実施形態による、状態更新を求める要求に対する応答を強制するための例示的な動作ステップが示されている。図５に示される例示的な動作ステップ５００は、或る実施形態により、クライアントおよび／またはブラウザ、例えば、ウェブブラウザの見地から示される。方法５００が、開始動作５０２で開始され、さらに方法５００は、クエリ５０４に進み、クライアント（および／または、例えば、ブラウザ）がサーバ応答を強制することを所望するかどうかを判定する。いくつかの実施形態において、クライアントは、例えば、クライアントにおけるサービス中断の後、クライアントがサーバと同期していないことを認識している場合、サーバからの応答を強制することを所望することが可能である。他の実施形態において、クライアントは、クライアントが、例えば、スマートフォンなどのポータブルコンピューティングデバイス上にあり、さらに、例えば、ポーリングが、典型的には、より多くの計算処理を要求し、より多くの電力を消費する際に、ポーリングを可能にする電源に接続される場合に、例えば、サーバ応答を繰り返し強制することによって実現される、通常のポーリングに切り換えることを所望する。または、別の例として、クライアントが、ネットワークがダウンしているまたは頻繁なサービス中断を経験している場合に、ポーリングの方がより安全であると判定することが可能であり、さらに定期的にポーリングすることを所望することが可能である。さらに、クライアントが、サーバ負荷またはサーバ接続を処理する問題から生じる誤りを、より体裁よく扱うように、ロングポーリングから普通の、または通常のポーリングに切り換えることを所望することが可能である。さらに、例えば、ユーザが単独の編集者であるマルチユーザ編集環境においてクライアントが機能している環境において、ロングポーリングが、単に必要ないため、クライアントが、例えば、サーバ応答を強制することによる、ポーリングに切り換えることを所望することが可能である。

[0043]サーバ応答が強制される場合、いくつかの実施形態によれば、この応答は、即時に送信され得る。他の実施形態において、サーバは、所定の期間に応じて応答する。さらなる実施形態において、サーバは、例えば、利用可能なシステムリソースによって決定される期間内に応答する。サーバによる応答に関する多数の期間は、本開示の範囲および趣旨を逸脱することなく、本開示のいくつかの実施形態により適用され得る。

[0044]図５に戻ると、クライアントがサーバ応答を強制することを所望する場合（５０４）、方法５００は、「はい」に進み、空のトークン値で状態を要求し（５０６）、クライアントは、状態更新を求める要求の中で空の値をトークン値として送る。別の実施形態において、クライアントは、ダミー値をトークン値として送って、状態応答を強制する。このため、そのような実施形態におけるクライアントは、空の値、もしくはランダムな／デフォルトの値、またはダミー値を送信する際に正しいトークン値を無視する。または、他の実施形態において、クライアントは、例えば、サーバとの接続を開始する際などに、正しいトークン値を知らない。サーバは、トークン値に関して空の値、もしくはランダムな／デフォルトの値、またはダミー値を受信するため、サーバ上のトークンは、クライアントからの受信されたトークンと合致せず、したがって、クライアントは、サーバ上の実際の状態およびトークン値を受信する（５０８）。サーバ上のトークン値は、本開示の趣旨および範囲を逸脱することなく、サーバ上のトークン、第２のトークンなどと呼ばれることが可能である。次に、方法５００は、クエリ５１０に進み、それらのトークンが異なるかどうかを判定し（５１０）、クライアントにおけるトークン値、例えば、第１のトークンが、サーバ上のトークン、例えば、第２のトークンと異なるかどうかが判定される。それらのトークンが異なる場合、サーバにおける状態は、クライアントがクライアントの状態を以前に更新して以来、変化している。このため、いくつかの実施形態において、クライアントは、サーバと同期していない。それらのトークンが異なると判定された場合、方法５００は、「はい」で状態を更新する（５１２）に進み、第２のトークンを格納する（５１４）。このため、サーバから受信された状態データが、ステップ５１２でクライアントにおける状態を更新するのに使用され、さらにサーバからのトークンが、サーバにおいて状態更新を求める後の可能な要求の中で使用されるように格納される（５１４）。その後、方法５００は、終了動作５１６で終了する。

[0045]クエリ５０４に戻ると、クライアントがサーバ応答を強制することを所望しない場合、方法５００は、「いいえ」に進み、第１のトークン値要求パラメータで状態を要求し（５１８）、クライアントは、トークン値として空の値、もしくはランダムな／デフォルトの値、またはダミー値を使用するのではなく、代わりに、正しいトークン／ハッシュ値を使用する。正しいトークン／ハッシュを使用した結果、サーバからの即時の応答は、強制されない。代わりに、いくつかの実施形態において、クライアントは、サーバにおいて状態の変化が生じるのを待つ（５２０）。
サーバにおいて状態変化または状態更新が生じた後、ステップ５０８で、クライアントが、サーバからその状態、または状態データ、および第２のトークン、またはトークン値を受信する。その後、ステップ５１０〜５１４が繰り返され、さらに方法５００は、終了動作５１６で終了する。

[0046]次に、図６が、本開示の或る実施形態による、データをプッシュするように空の値、またはランダムな／デフォルトの値をトークン値として受信するための例示的な動作ステップを示す。図６に示される例示的な動作ステップ６００は、或る実施形態により、サーバ、および／または管理コンポーネントもしくは管理モジュールの見地から示される。方法６００が、開始動作６０２で開始され、さらに状態をハッシュする動作６０４に進み、サーバにおける状態データがハッシュされて、ハッシュ値のトークンが生成される（６０６）。次に、サーバ（および／または管理モジュールもしくは管理コンポーネント）が、状態更新を求める要求を、トークン値に関して空の値、またはランダムな／デフォルトの値と一緒に受信する（６０８）。いくつかの実施形態において、そのような要求は、ロングポーリング技法の一環としての長期保持される要求である。いくつかの実施形態において、ロングポーリング技法は、ＨＴＴＰロングポーリングで構成される。次に、サーバが、受信されたトークンまたはトークン値を、ステップ６０６で生成されたトークンと比較する（６１０）。空の値、もしくはランダムな／デフォルトの値、またはダミー値が要求パラメータとして含められているので、サーバ上のトークンと受信されたトークンは合致せず、したがって、サーバは、状態データを、ステップ６０６で生成されたサーバ上のトークンと一緒に送信する、つまり、プッシュする（６１２）。その後、方法６００は、終了動作６１４で終了する。

[0047]図３〜図６は、例示的な動作ステップを示すが、図示される動作ステップは、他のステップになるように組み合わされること、さらに／または並べ替えられることが可能である。さらに、例えば、より少ないステップ、またはさらなるステップが使用されてもよい。

[0048]最後に、図７が、本明細書で開示されるいくつかの実施形態が実施され得る例示的なコンピューティングシステム７００を示す。少なくとも１つのプロセッサ７０２を有する、クライアントコンピュータ１０２、フロントエンドサーバ１０８〜１１２、およびバックエンドサーバ１１６〜１２０などのコンピュータシステム７００が、本明細書で開示されるいくつかの実施形態により、示される。システム７００は、例えば、システムメモリと、揮発性メモリと、不揮発性メモリとを備えるメモリ７０４を有する。コンピューティングシステム７００は、最も基本的な構成において、図７に破線７０６で示される。さらに、システム７００は、磁気ディスクもしくは磁気テープ、または光ディスクもしくは光テープを含むが、以上には限定されないさらなるストレージ（リムーバブルおよび／または非リムーバブルの）を含むことも可能である。そのようなさらなるストレージが、リムーバブルストレージ７０８および非リムーバブルストレージ７１０で図７に示される。

[0049]本明細書で使用されるコンピュータ可読媒体という用語には、コンピュータ記憶媒体が含まれ得る。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を格納するために任意の方法または技術で実装された揮発性媒体および不揮発性媒体、リムーバブルメディアおよび非リムーバブルメディアが含まれ得る。システムメモリ７０４、リムーバブルストレージ７０８、および非リムーバブルストレージ７１０はすべて、コンピュータ記憶媒体の例（すなわち、メモリストレージ）である。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、電気的に消去可能な読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタルバーサタイルディスク（ＤＶＤ）もしくは他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、または情報を格納するのに使用され得るとともに、コンピューティングデバイス７００によってアクセスされ得る他の任意の媒体が含まれることが可能であるが、以上には限定されない。任意のそのようなコンピュータ記憶媒体が、デバイス７００の一部であり得る。図７の例示は、本開示の範囲を限定することを全く意図していない。

[0050]本明細書で使用されるコンピュータ可読媒体という用語には、通信媒体も含まれ得る。通信媒体は、搬送波などの変調されたデータ信号、または他のトランスポート機構におけるコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータによって具現化され得、さらに任意の情報配信媒体を含む。「変調されたデータ信号」という用語は、信号内に情報を符号化するように１つまたは複数の特性が設定されている、または変更されている信号を表すことが可能である。例として、限定としてではなく、通信媒体には、有線ネットワークまたは直接配線接続などの有線媒体、および音響媒体、無線周波数（ＲＦ）媒体、赤外線媒体、および他のワイヤレス媒体などのワイヤレス媒体が含まれ得る。

[0051]システム７００は、デバイスが他のデバイスと通信することを可能にする通信接続（複数可）７１６を含むことも可能である。さらに、本開示の或る実施形態により、例えば、クライアントコンピュータ１０２上の対応するユーザインターフェース（ＵＩ）モジュール（図示せず）によって実現される、例えば、クライアントコンピュータ１０２上のＵＩのフィールドに内容を入力するのに、システム７００は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスなどの入力デバイス（複数可）７１４を有することが可能である。また、ディスプレイ、スピーカ、プリンタなどの出力デバイス（複数可）７１２が含められることも可能である。これらのデバイスのすべては、当技術分野でよく知られており、本明細書で詳細に説明される必要はない。前述のデバイスは、例であり、他のデバイスが使用されてもよい。

[0052]前段で図を参照して本開示の実施形態を説明してきたので、当業者に容易に想起されるとともに、本開示の範囲および趣旨に包含され、さらに添付の特許請求の範囲において定義される多数の変形が、それらの実施形態に行われてもよいことが認識されよう。実際、いくつかの実施形態が本開示の目的のために説明されてきたが、本開示の範囲に完全に含まれる様々な変更および変形が行われることが可能である。

[0053]同様に、本開示は、構造上の特徴、方法上の動作、およびそのような動作を含むコンピュータ可読媒体に特有の言い回しを使用してきたものの、添付の特許請求の範囲において定義される主題は、本明細書で説明される特定の構造、動作、特徴、または媒体には必ずしも限定されないことを理解されたい。むしろ、前述した特定の構造、特徴、動作、および／または媒体は、特許請求の範囲を実施する例示的な形態として開示される。実施形態のいくつかの態様では、複数のクライアントコンピュータ、複数のフロントエンドサーバ、複数のバックエンドサーバ、および複数のネットワークなどが実現される。または、他の実施形態において、単一のクライアントコンピュータが、単一のフロントエンドサーバ、単一のバックエンドサーバ、および単一のネットワークと一緒に使用される。さらなる実施形態は、例えば、単一のフロントエンドサーバを有し、バックエンドサーバを有さない単一のクライアントコンピュータを可能にする。本開示の範囲および趣旨に含まれる他の実施形態または改良形態が、当業者には認識されよう。したがって、特定の構造、動作、または媒体は、本開示を実施する例示的な実施形態として開示される。本開示は、添付の特許請求の範囲によって定義される。

Claims (10)

1. 状態データをクライアントにプッシュするためのコンピュータ実施方法であって、
   サーバにおいて状態更新を受信するステップと、
   前記状態更新を受信したことに応答して、前記サーバにおいて前記状態を変更するステップと、
   前記サーバにおいて前記状態をハッシュするステップと、
   前記サーバ上でトークンを生成するステップであって、前記トークンは、前記状態の前記ハッシュである、ステップと、
   前記クライアントからトークンを受信するステップと、
   前記サーバ上の前記トークンと前記クライアントからの前記受信されるトークンが異なるかどうかを判定するステップと、
   前記サーバ上の前記トークンと前記クライアントからの前記受信されるトークンが異なる場合、状態データを前記サーバ上の前記トークンと一緒に前記クライアントにプッシュするステップと
   を含む方法。
2. 前記サーバ上の前記トークンと前記クライアントからの前記受信されるトークンが異なるかどうかを前記判定するステップは、前記サーバ上の前記トークンの値と前記クライアントからの前記受信されるトークンの値が異なるかどうかを判定するステップを含む請求項１に記載のコンピュータ実施方法。
3. 前記クライアントから、状態更新を求める要求を受信するステップをさらに含み、前記クライアントからの前記受信されるトークンは、状態更新を求める前記要求のパラメータである、
   請求項１に記載のコンピュータ実施方法。
4. 前記サーバ上の前記トークンと前記クライアントからの前記受信されるトークンが異ならない場合、前記クライアントからの前記受信される要求および前記受信されるトークンを保持するステップをさらに含む、
   請求項３に記載のコンピュータ実施方法。
5. 前記クライアントからの前記受信されるトークンの値は、空である請求項３に記載のコンピュータ実施方法。
6. 前記サーバ上の前記トークンと前記クライアントからの前記受信される空のトークン値が異なることを判定するステップと、
   状態データを、前記サーバ上の前記トークンと一緒に前記クライアントにプッシュするステップと
   をさらに含む請求項５に記載のコンピュータ実施方法。
7. 前記空の値に応答して、所定の期間内に前記状態データを、前記サーバ上の前記トークンと一緒に前記クライアントにプッシュするステップ
   をさらに含む請求項５に記載のコンピュータ実施方法。
8. プロセッサによって実行されると、状態データを求めてサーバにポーリングを行うための方法を実行するコンピュータ実行可能命令を格納する１つまたは複数のコンピュータ記憶媒体であって、前記方法が、
   クライアントによる、前記サーバにおける前記状態データを求める第１の要求を送信するステップであって、前記第１の要求は、第１のトークンを備える、ステップと、
   前記状態データを第２のトークンと一緒に受信するステップと、
   前記第１のトークンと前記第２のトークンを比較して、前記受信される状態データが前記クライアントにおいて格納された状態データと異なるかどうかを判定するステップと、
   前記第１のトークンと前記第２のトークンが異なる場合、前記クライアントにおいて格納された前記状態データを更新するステップとを含む、
   １つまたは複数のコンピュータ記憶媒体。
9. 前記ポーリングは、トークン機構を介するハイパーテキスト転送プロトコル（ＨＴＴＰ）ロングポーリングで構成される、請求項８に記載の１つまたは複数のコンピュータ記憶媒体。
10. トークン機構を介してサーバにおける状態データをクライアントにプッシュするためのシステムであって、
    プロセッサと、
    前記プロセッサに結合されたメモリとを備え、前記メモリは、
    状態更新を受信し、
    前記状態更新を受信したことに応答して、前記状態を変更し、
    前記状態をハッシュし、
    前記サーバ上で、前記状態の前記ハッシュであるトークンを生成し、
    前記クライアントからトークンを受信し、
    前記サーバ上の前記トークンと前記クライアントからの前記受信されるトークンが異なるかどうかを判定し、
    前記サーバ上の前記トークンと前記クライアントからの前記受信されるトークンが異なる場合、状態データを、前記サーバ上の前記トークンと一緒に前記クライアントにプッシュする
    ように構成された、前記サーバ内の管理モジュール
    を実現するように前記プロセッサによって実行可能なコンピュータプログラム命令を備える、
    システム。

Images