(57)【特許請求の範囲】
【請求項１】
メッセージ伝達システムがクライアントと通信する方法であって、以下のコンピュータ実装される段階、すなわち：
前記メッセージ伝達システムが前記クライアントから前記クライアントを特定する通知トークンを受信する段階と；
前記クライアントが前記メッセージ伝達システムに接続されていないときに前記クライアントに通知サービスを介して通知を受信させるよう前記クライアントを前記メッセージ伝達システムが前記メッセージ伝達システムにおいて登録する段階であって、前記登録は少なくとも前記通知トークンを記憶することを含む、段階と；
前記クライアントが前記メッセージ伝達システムへの接続をもたないときに、前記メッセージ伝達システムが、少なくとも前記通知トークンに基づいて前記通知サービスを使って、前記クライアントに通知を送信する段階であって、前記通知がペイロード中にデータを有する実際のパケットを含むか含まないかは、前記登録の際の前記クライアントによる指定に基づく、段階とを含む、
方法。
【請求項２】
前記通知サービスが通知チャネルを通じて通知を送るよう構成されており、前記通知チャネルがハイパーテキスト転送プロトコル・セキュアード（HTTPS:  hypertext  transfer  protocol  secured）チャネルである、請求項１記載の方法。
【請求項３】
前記クライアントを登録する段階が、前記クライアントについて通知チャネル一意リソース位置指定子（URL:  uniform  resource  locator）を記憶することを含む、請求項１記載の方法。
【請求項４】
前記通知チャネル一意リソース位置指定子（URL:  uniform  resource  locator）を指定するメッセージを受信する段階をさらに含む、請求項３記載の方法。
【請求項５】
前記通知を送信する段階が、前記クライアントに送られるべきメッセージが第二のクライアントから前記メッセージ伝達システムに送信されたときに実行される、請求項１記載の方法。
【請求項６】
前記クライアントから友達に対する加入申し込みを前記メッセージ伝達システムが受信する段階をさらに含み、前記加入申し込みは、前記友達のクライアントのプレゼンス状態に対する更新を前記クライアントが前記メッセージ伝達システムから自動的に通知されるようにするものであり、前記友達のクライアントのプレゼンス状態とは前記友達のクライアントの可用性または機能を含み、
前記クライアントが前記メッセージ伝達システムへの接続をもたないときに送信される前記通知が、前記友達のクライアントのプレゼンス状態の更新に関する通知である、請求項１記載の方法。
【請求項７】
友達に対する前記加入申し込みが、一または複数の友達を含む友達リストに含まれる友達に対する加入申し込みである、請求項６記載の方法。
【請求項８】
前記通知がペイロード中にデータを有する実際のパケットを含まない場合、前記メッセージ伝達システムは、前記通知を受けた前記クライアントの要求に応答して、前記メッセージ伝達システムの待ち行列に入れられた、ペイロード中に実際のパケットを含む通知を前記クライアントに送る段階をさらに含む、請求項１記載の方法。
【請求項９】
前記通知サービスがプッシュ通知サービスである、請求項１ないし８のうちいずれか一項記載の方法。
【請求項１０】
クライアントと通信するシステムであって、処理ユニットおよびシステム・メモリを有し、前記システム・メモリは前記処理ユニットに：
前記クライアントを特定する通知トークンを前記クライアントから受信する段階と；
前記クライアントが当該システムに接続されていないときに前記クライアントに通知サービスを介して通知を受信させるよう前記クライアントを当該システムにおいて登録する段階であって、前記登録は少なくとも前記通知トークンを記憶することを含む、段階と；
前記クライアントが当該システムへの接続をもたないときに、少なくとも前記通知トークンに基づいて前記通知サービスを使って、前記クライアントに通知を送信する段階であって、前記通知がペイロード中にデータを有する実際のパケットを含むか含まないかは、前記登録の際の前記クライアントによる指定に基づく、段階とを実行させるコードを有している、
システム。
【請求項１１】
処理ユニットに：
クライアントを特定する通知トークンを前記クライアントから受信する段階と；
前記クライアントが前記処理ユニットを有するサーバーに接続されていないときに前記クライアントに通知サービスを介して通知を受信させるよう前記クライアントを前記サーバーにおいて登録する段階であって、前記登録は少なくとも前記通知トークンを記憶することを含む、段階と；
前記クライアントが前記サーバーへの接続をもたないときに、少なくとも前記通知トークンに基づいて前記通知サービスを使って、前記クライアントに通知を送信する段階であって、前記通知がペイロード中にデータを有する実際のパケットを含むか含まないかは、前記登録の際の前記クライアントによる指定に基づく、段階とを実行させるためのコンピュータ・プログラム。
【請求項１２】
メッセージ伝達システムがクライアントと通信する方法であって、以下のコンピュータ実装される段階、すなわち：
前記メッセージ伝達システムが、前記クライアントから、前記クライアントを特定する通知トークンを受信する段階と；
前記メッセージ伝達システムが、前記クライアントと通信するために使われる通知チャネル情報を検出する段階と；
前記メッセージ伝達システムが前記通知チャネル情報を記憶する段階と；
前記クライアントが前記メッセージ伝達システムにセッションを介して接続されていないときに、前記クライアントが通知サービスを介して通知を受信するよう前記クライアントを前記メッセージ伝達システムが前記メッセージ伝達システムにおいて登録する段階であって、前記登録は前記通知チャネル情報および前記通知トークンを記憶することを含む、段階と；
前記クライアントが前記メッセージ伝達システムへの接続をもたないときに、前記メッセージ伝達システムが、前記通知チャネル情報および前記通知トークンに基づいて前記通知サービスを使って、前記クライアントに通知を送信する段階であって、前記通知がペイロード中にデータを有する実際のパケットを含むか含まないかは、前記登録の際の前記クライアントによる指定に基づく、段階とを含む、
方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、通知ベースのクライアントのためのメッセージ伝達に関する。
【背景技術】
【０００２】
クライアント‐サーバー通信システムは、いつサーバーがクライアントに通信を送ってよいかの点で多様でありうる。たとえば、ウェブサイト（サーバー）とクライアントとの間の通信は、要求‐応答モデルに従ってもよい。このモデルでは、クライアントがサーバーに要求を送っている場合には、クライアントはサーバーから到達可能でありうる。それ以外の場合には、クライアントは到達不能でありうる。よって、サーバーは、クライアント要求に応答してクライアントに通信を送ることができるだけであることがある。このモデルでは、クライアント要求の結果として、サーバーが通信を送りうる開かれたネットワーク接続が生じうる。
【０００３】
このモデルは、伝統的なメッセージ伝達システムとは異なっている。伝統的なメッセージ伝達システムは、クライアントとサーバーの間の接続の存在を想定していた。接続が持続的であるため、サーバーは任意の時点でクライアントに通信を送りうる。
【０００４】
プラットフォーム、たとえばモバイル装置の数が増すと、ネットワーク接続の維持は資源的に厳しくなる。たとえば、モバイル装置は、ネットワーク接続を維持しようと努めることによって、たちまちバッテリー電力を使い尽くしてしまうことがある。よって、これらのプラットフォームは、クライアント・アプリケーションがアクティブでないときはネットワーク接続を維持しないことがある。
【０００５】
ネットワーク接続の維持はさらに、ネットワーク自身の限界によって妨げられることがある。場合によっては、ネットワークが信頼できないことがある。たとえば、携帯電話は、適切なセルラー・タワーのない領域ではそのネットワーク接続を失ってしまう。
【０００６】
こうした接続性問題に対する典型的なアプローチは、いまだクライアントとサーバーとの間の開かれたネットワーク接続を創り出すことに依拠している。クライアントとサーバーとの間の通信のために開かれたネットワーク接続に依存することは、増え続けるクライアント装置の、限られた資源に対する需要を増すことになる。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
下記は、本稿に記載されるいくつかの側面の基本的な理解を与えるために本革新の簡略化された概要を呈示する。この概要は、特許請求される主題の包括的な概観ではない。特許請求される主題の主要な特徴または決定的に重要な特徴を特定することも、主題となる革新の範囲を描き出すことも意図していない。その唯一の目的は、後述するより詳細な記述への導入として、特許請求される主題のいくつかの概念を、簡略化された形で呈示することである。
【課題を解決するための手段】
【０００８】
本革新は、サーバーに接続されていないクライアントとの通信のための方法およびシステムに関する。クライアントは、サーバーに、通知チャネル情報を登録してもよい。サーバーは、通知チャネルを使ってクライアントにメッセージを送ってもよい。メッセージは、クライアントへの通知メッセージに含まれてもよい。あるいはまた、メッセージは、ショルダータップ（shoulder  tapping）技法を使って送られてもよい。
【０００９】
ある実施形態では、クライアントは、友達、サービスまたはネットワークに加入申し込み（subscribe）してもよい。加入申し込みによって、クライアントは、通知チャネルを通じて対応する更新について自動的に通知されうる。以下の記述および付属の図面は、特許請求される主題のある種の例示的な側面を詳述する。しかしながら、これらの側面は、本革新の原理が用いられうるさまざまな仕方の若干を示すものであり、特許請求される主題は、そのようなすべての側面およびその等価物を含むことが意図されている。特許請求される主題の他の利点および新規な特徴は、図面との関連で考慮されるときの本革新の以下の詳細な記述から明白となるであろう。
【図面の簡単な説明】
【００１０】
【図１】特許請求される主題に基づくシステムのブロック図である。
【図２】特許請求される主題に基づく、クライアントのための通信方法のプロセス流れ図である。
【図３】特許請求される主題に基づく、ネットワークにおけるクライアント・エンティティを生成するためのメッセージ・フロー図である。
【図４】特許請求される主題に基づく、メッセージを送るためのメッセージ・フロー図である。
【図５】特許請求される主題に基づく、加入申し込みのためのメッセージ・フロー図である。
【図６】特許請求される主題に基づく、友達のプレゼンスを問い合わせするためのメッセージ・フロー図である。
【図７】特許請求される主題に基づく、クライアント・エンティティを削除するためのメッセージ・フロー図である。
【図８】特許請求される主題に基づく、多者会話のためのメッセージ・フロー図である。
【図９】特許請求される主題の諸側面を用いることができる、例示的なネットワーク環境のブロック図である。
【図１０】特許請求される主題のさまざまな側面を実装するための例示的な動作環境のブロック図である。
【発明を実施するための形態】
【００１１】
特許請求される主題について、図面を参照して述べる。図面において、同様の参照符号は全図を通じて同様の要素を指すために使われる。以下の記述では、説明のため、主題となる革新の十全な理解を提供するよう数多くの個別的詳細が記述される。しかしながら、特許請求される主題がこれらの個別的詳細なしでも実施されうることは明白であろう。他方、主題となる革新の記述を容易にするよう、よく知られた構造および装置はブロック図の形で示されている。
【００１２】
本稿での用法では、「コンポーネント」、「システム」、「クライアント」などの用語は、ハードウェア、ソフトウェア（たとえば実行中の）および／またはファームウェアまたはそれらの組み合わせのいずれかの、コンピュータ関係のエンティティに言及することが意図されている。たとえば、コンポーネントは、プロセッサ上で走っているプロセス、オブジェクト、実行可能形式、プログラム、関数、ライブラリ、サブルーチンおよび／またはコンピュータまたはソフトウェア及びハードウェアの組み合わせであることができる。
【００１３】
例として、サーバー上で走っているアプリケーションおよびサーバーの両方がコンポーネントであることができる。一つまたは複数のコンポーネントはプロセス内に存在することができ、コンポーネントは、一つのコンピュータ上に局在化されることも、および／または二つ以上のコンピュータの間に分散されることもできる。用語「プロセッサ」は、一般に、コンピュータ・システムの処理ユニットのようなハードウェア・コンポーネントを指すものと理解される。
【００１４】
さらに、特許請求される主題は、開示される主題を実装するようコンピュータを制御するためのソフトウェア、ファームウェア、ハードウェアまたはその任意の組み合わせを生成するための標準的なプログラミングおよび／またはエンジニアリング技法を使って、方法、装置または製造物として実装されうる。本稿で使うところの用語「製造物」は、任意の非一時的なコンピュータ可読デバイスまたは媒体からアクセス可能なコンピュータ・プログラムを包含することが意図されている。
【００１５】
非一時的なコンピュータ可読記憶媒体は、これに限られないが、磁気記憶デバイス（たとえば中でもハードディスク、フロッピー（登録商標）ディスクおよび磁気ストリップ）、光ディスク（たとえば中でもコンパクトディスク（CD）およびデジタル多用途ディスク（DVD））、スマートカードおよびフラッシュメモリ・デバイス（たとえば中でもカード、スティックおよびキー・ドライブ）を含むことができる。これとは対照的に、コンピュータ可読媒体といえば、一般的に（すなわち、必ずしも記憶媒体ではなく）、さらにワイヤレス信号などのための伝送媒体のような通信媒体をも含みうる。
【００１６】
むろん、当業者は、特許請求される主題の範囲もしくは精神から外れることなく、この構成に対して多くの修正がなしうることを認識するであろう。さらに、本稿では単語「例示的」は例、事例または例示のはたらきをすることを意味するために使われる。本稿で「例示的」として記述されるいかなる側面もしくはデザインも、必ずしも、他の側面もしくはデザインに比して好ましいまたは有利であると解釈されない。
【００１７】
増え続ける数のモバイル・プラットフォームについて、メッセージ伝達システムは、サーバーがクライアントにメッセージを送ることができるようにするために、クライアントとサーバーとの間の開かれたネットワーク接続を使うことがある。しかしながら、クライアントが長持ちする接続を確立することができないときは、接続はシミュレートされてもよい。
【００１８】
先述したように、モバイル・プラットフォームは、クライアントとサーバーの間の接続の維持に関して、次のことを含む課題を導入する：１）通信チャネルの、たとえば無線という性質上、接続は信頼できないことがある、２）サーバーへの接続を維持することは、こうしたプラットフォームでは限られているバッテリー資源を消費する、３）無線接続は、有線接続より帯域幅の点でより限られていることがある。
【００１９】
こうした課題に取り組むため、メッセージ伝達システムは、帯域幅消費を低下させ、通信プロトコルのトランスポート層に耐性（resiliency）論理を追加してもよい。トランスポート層に耐性論理を追加することは、典型的には、メッセージ伝達システムが中間的な接続性問題から回復できるようにする。
【００２０】
図１は、特許請求される主題に基づくシステム１００のブロック図である。システム１００はクライアント１０２と、ネットワーク１０４と、通知サービス１０８と、メッセージ伝達システム１１０とを含む。クライアント１０２は、ネットワーク１０４上でメッセージ伝達システム１１０と通信するクライアント・アプリケーションをもつデバイスであってもよい。クライアント１０２は、携帯電話、携帯情報端末（personal  digital  assistant）、デスクトップ・コンピュータなどといった任意の型の通信またはコンピューティング装置でありうる。クライアント１０２が走るプラットフォームは、通知サービス１０８と対話するための一組のAPIを含んでいてもよい。通知サービス１０８は、クライアント１０２が走るプラットフォームによって提供される別のクラウド・サービスであってもよい。たとえば、ウィンドウズ（登録商標）フォン上では、通知サービス１０８は、マイクロソフト・プッシュ通知（Microsoft  Push  Notification）サービス（MPN）であってもよい。アイフォーン（iPhone）・クライアントは、アップル・プッシュ通知（Apple  Push  Notification）サービス（APN）を使ってもよい。ネイティブな通知サービスAPIを提供しないプラットフォーム上で走るクライアント１０２については、メッセージ伝達システム１１０が代替を提供してもよい。
【００２１】
通知サービス１０８は、ａ）バッテリー寿命を温存しうるおよびｂ）ネットワーク１０４への断続的接続などの上記の固有のネットワーク上の課題を克服するよう構成されていてもよいクライアント１０２に情報を送るためにクラウド・サービスが使用しうる、一つまたは複数の通知チャネルを提供してもよい。通例、クライアント１０２から通知サービス１０８への接続は、クライアント資源を保存するよう開かれることが許容されてもよい。
【００２２】
ネットワーク１０４は、クライアント１０２とメッセージ伝達システム１１０との間の通信をサポートできる任意のネットワークまたはネットワーク集合体でありうる。ネットワーク１０４はインターネット、広域ネットワーク、ローカル・エリア・ネットワークなどでありうる。インターネットは、本稿ではクラウドとも称される。
【００２３】
通知サービス１０８は、メッセージ伝達システム１１０の一部として使われ、メッセージ伝達システム１１０からのメッセージをクライアント１０２に通信するために使われてもよい。よって、メッセージ伝達システム１１０は、次のものを含む典型的なメッセージ伝達システム機能を可能にしてもよい：メッセージ伝達、信号伝達、プレゼンス、オーディオ、ビデオ、など。ある実施形態では、この機能は、クライアント１０２とメッセージ伝達システム１１０との間の接続がないときに提供されてもよい。
【００２４】
プレゼンス（presence）は、ある種の動作のための所与の瞬間におけるクライアント１０２の可用性（availability）および機能（capabilities）を表しうる。典型的なメッセージ伝達システムでは、クライアント１０２の可用性は接続状態と密接に関連している。接続がない場合には、クライアント１０２は利用可能ではないと想定される。本発明の諸実施形態では、接続がないとき、クライアント１０２は、通知サービス１０８を通じて利用可能であってもよい。
【００２５】
開いたネットワーク接続を通じた通信の代わりに、メッセージ伝達システム１１０は、通知サービス１０８を使ってクライアント１０２と通信してもよい。メッセージ伝達システム１１０は、クライアント接続スキームの一部として通知サービス１０８をネイティブにサポートするプロトコルを使ってもよい。ある実施形態では、該プロトコルは、この型のクライアント１０２、すなわち通知ベースのクライアント（notification-based  client）を第一クラス・エンティティとしてサポートし、クライアント１０２のためのさまざまなプラットフォームにネイティブに適合する構造体（constructs）を提供していてもよい。
【００２６】
そのような実施形態では、メッセージ伝達システム１１０は、非接続のクライアント・モードを使ってもよい。このモードでは、必ずしも開かれたネットワーク・セッションをもつことなく、クラウド・サービスによってクライアント・エンティティが提供されてもよい。クライアント１０２は、通知サービス１０８のような他の手段を使って到達可能であってもよい。
【００２７】
プロトコルは、クライアントを登録および登録解除する、クライアントを更新する、メッセージを送る、友達リストに加入申し込みする、友達について問い合わせする、メッセージを問い合わせおよび送達する、および多者通信をサポートするためのコマンドを含んでいてもよい。これらのコマンドは、図４〜図９を参照してより詳細に述べる。
【００２８】
このプロトコルの、既存のプロトコルからのいくつかの相違点は、次のことを含む：１）クラウドにおけるクライアント・エンティティの存在の条件としての、セッションの除去、２）クラウド・サービスと対話する方法としての非接続モードの使用。
【００２９】
クラウド・サービスは、通知サービス１０８についてのデータを記憶してもよい。通知サービス１０８または開かれたネットワーク・セッション（もし存在すれば）が、クライアント１０２に返信するために使用されてもよい。このプロトコルは、多様な通知プラットフォームをネイティブにサポートしうる。このプロトコルを使うと、メッセージ伝達システム１１０は、通知サービスを提供しないクライアント、たとえばウェブ・クライアントにも通知サービスを提供しうる。ある実施形態では、これは、持続性のトランスポート層サービス上で他の通知サービスによって定義されるのと同じセマンティクス（semantics）を使ってなされてもよい。
【００３０】
ある実施形態では、メッセージ伝達システム１１０は、クライアントを認証し、クラウドにおけるクライアント・エンティティの寿命を制御する手段として、認証トークンを生成してもよい。メッセージ伝達システム１１０は、クライアント１０２に返信するために使われるべき通知チャネル情報を記憶してもよい。通知チャネルは、メッセージ伝達システム１１０が通知サービス１０８を使ってクライアント１０２にメッセージを送るための手段である。さらに、メッセージ伝達システム１１０は、任意の潜在的な開かれたネットワーク・セッションについての情報を、もしそのような接続が存在するなら、記憶しうる。この接続情報は、クライアント１０２に返信する代替手段として使用されてもよい。クライアント１０２は、認証失敗応答を受信し、メッセージ伝達システム１１０に対して再認証できることを予期して、要求毎に認証トークンを送ってもよい。
【００３１】
クライアント１０２がメッセージ伝達システム１１０にメッセージを送っているとき、クライアントは接続されたまたは非接続の手段を使用しうる。ある実施形態では、クライアント１０２は非接続チャネルを使ってもよい。ある代替的な非接続手段では、クライアント１０２は、アドホック通信のために一時的なチャネルを開いて、TCPベースのコマンドを使ってもよい。これは、明示的にメッセージ伝達システム１１０に接続したり再接続したりすることなくなされてもよい。
【００３２】
接続された手段に関しては、クライアント１０２は、一つまたは複数の会話（conversation）の継続期間にわたってメッセージ伝達システム１１０に明示的に接続してもよい。クライアント１０２は、任意の所与の時点においてクラウドへの単一接続に制限されてもよい。これは、メッセージ伝達システム１１０によって履行されてもよい。
【００３３】
プロトコルは、クラウドにおけるクライアント・プレゼンス状態を定義していなくてもよく、むしろ、クライアント１０２がその固有のプレゼンス情報、たとえば可用性および機能を更新しうる機構を定義していてもよい。プロトコルはまた、ユーザーとのある関係（たとえばソーシャルまたはプロフェッショナルなウェブサイト上でのつながり）をもつ者が、該当するときに更新を受け取る手段をも提供してもよい。接続性およびプロセス特権制約条件のため、クライアント１０２はそのプレゼンスを正確に更新しないことがある。その代わり、プロトコルは、メッセージ伝達システム１１０上のビジネス論理がクライアント・プレゼンスを更新することを想定してもよい。これは、時間間隔（すなわち、「最後の活動からの分数」）、通知チャネル状態（すなわち、「定期的なピング（ping）試験」または「エラー応答」）または可能なときにはクライアント１０２自身による明示的な更新に基づいてできる。
【００３４】
プロトコルは、クライアント・エンティティを登録または登録解除する一つの手段をサポートしてもよい。しかしながら、メッセージ伝達システム１１０は、該プロトコルを使ってクライアント１０２を登録または登録解除することを履行するのでなくてもよい。クライアント・エンティティをメッセージ伝達システム１１０に追加する他の方法もありうる。たとえば、メッセージ伝達システム１１０は、諸クライアント１０２を追跡している別のクラウド・サービスのような、外部の権威あるソースに問い合わせをしてもよい。クライアント１０２が有効なトークンを呈示する限り、メッセージ伝達システム１１０はその要求にサービスしてもよい。このアプローチが含意するセキュリティ上の課題は、セキュリティで保護された通信チャネルを使って対処されうる。
【００３５】
さらにバッテリー寿命を保存し、帯域幅消費を減らすため、プロトコルは、クライアント１０２を、クラウド中の何らかの権威あるエンティティにすでに存在している何らかのデータをアップロードすることから解放してもよい。その代わり、クライアント１０２は、単に、クライアント固有で一過性のデータをアップロードしてもよい。メッセージ伝達システム１１０は、各クライアントについての、限られた量の状態情報を記憶してもよい。この状態は、たとえば、通知チャネル情報、アクセス・コントロール・リスト（ACL:  access  control  list）、可用性および機能、加入申し込み、キャッシュされたインスタント・メッセージ（IM:  instant  message）または通知および最後の活動時間情報を含みうる。
【００３６】
図２は、特許請求される主題に基づく、クライアント１０２のための通信方法２００のプロセス流れ図である。ある実施形態では、メッセージ伝達システムが方法２００を実行してもよい。
【００３７】
方法２００はブロック２０２で始まる。ここで、通知サービス１０８が通知トークンを生成しうる。通知トークンは、通知サービス１０８を通じて送られる通知の受領者を同定するためにメッセージ伝達システム１１０によって使用されてもよい。クライアント１０２は、通知サービス情報に加えて、通知トークンを、メッセージ伝達システム１１０にアップロードしてもよい。
【００３８】
ブロック２０４では、メッセージ伝達システム１１０は、クライアント１０２を、メッセージ伝達システム１１０からの通信を受信するよう登録してもよい。クライアント１０２の登録は、クライアント１０２についての通知サービスおよびトークン情報を記憶することを含んでいてもよい。通知チャネル情報は、通知トークンとともに、通知サービス１０８を介してクライアント１０２に接触するためのアドレスを提供してもよい。
【００３９】
しかしながら、クライアント１０２がメッセージ伝達システムに接続されておらず、クライアント１０２のためのサーバーからのメッセージがある場合、ブロック２０６において、メッセージ伝達システム１１０は該メッセージを、通知サービスを使って非接続のクライアント１０２に送ってもよい。
【００４０】
図３〜図８は、特許請求される主題に基づく、上記のプロトコルに従った典型的な通信シナリオについてのメッセージ・フロー図である。これらのコマンドは、上記のプロトコルの実装において実行されてもよい。これらの図では、エンドポイント（endpoint）の略EPがクライアント１０２を指す。
【００４１】
このプロトコルのコマンドは、標準的なHTTP方法によってサポートされてもよい。たとえば、図３〜図８を参照して例解するシナリオは、標準的なHTTP方法を使うコマンドの例示的な実装を示している。標準的なHTTP方法は、OPTIONS、GET、HEAD、PUT、POST、DELETE、TRACEおよびCONNECTを含みうる。
【００４２】
先述したように、プロトコルは、バインド（binding）、加入申し込み、メッセージ送信、プレゼンス情報の問い合わせおよび更新、二者および多者会話の確立などのためのコマンドのセットを含んでいてもよい。
【００４３】
登録コマンドは、メッセージ伝達システム１１０においてクライアント・エンティティを生成し、認証トークンをクライアントに返してもよい。登録解除コマンドは、メッセージ伝達システム１１０からクライアント・エンティティを削除してもよい。ある実施形態では、クライアント１０２は、指定されたパーミッションに従って削除されるべき他のクライアント・エンティティを指定してもよい。
【００４４】
ひとたびクライアント・エンティティがメッセージ伝達システム１１０に登録されると、対応するクライアント１０２はそのプレゼンスを、クライアント更新コマンドを使って公開してもよい。該コマンドにおいて指定されるパラメータは、クライアント１０２がサポートする各動作についての通知チャネル情報を含んでいてもよい。パラメータは、クライアント１０２にどのようにして通知が送達されるかを指定する通知型をも含んでいてもよい。通知の一つの型は、コマンドが通知ペイロードに含まれることを指定してもよい。もう一つの型は、コマンドが含まれないこと、たとえばショルダータップ（shoulder  tapping）を指定してもよい。
【００４５】
ある実施形態は、クラウドへの接続を確立することなく、友達にメッセージを送るためのコマンドを含んでいてもよい。前記通知チャネルまたはメッセージ伝達システム１１０から待ち行列に入れられたメッセージを取得するためのコマンドが使用されてもよい。
【００４６】
加入申し込みのためのコマンドは、クライアントが友達に加入申し込みできるようにするために使用されてもよい。友達への加入申し込みは、クライアント１０２が、友達のプレゼンス状態に対する更新を自動的に通知されることができるようにする。クライアント１０２は、友達の部分集合に加入申し込みするために、加入申し込みするための友達リストに適用されるべきフィルタを指定するだけでもよい。メッセージ伝達システム１１０は、クライアントの友達リストを維持するもう一つのクラウド・サービスから連絡先リストを取得してもよい。クライアント１０２は、特定の友達に加入申し込みするためにこのコマンドを使ってもよい。クライアント１０２は、同様に、友達、サービスなどに対して加入解除申し込みをしてもよい。
【００４７】
友達プレゼンス問い合わせコマンドは、クライアント１０２がユーザーの一つまたは複数の連絡先のプレゼンス状態を判別することができるようにしてもよい。友達リストが、どの連絡先のプレゼンス状態を受信すべきかを決定するために使われてもよい。たとえば、空の連絡先リストは、メッセージ伝達システム１１０がユーザーのすべての連絡先のプレゼンス状態を取ってくる結果となってもよい。ある実施形態では、フィルタおよびビュー選択が、応答の精度を改善し、応答のパケット・サイズを縮小するために使われてもよい。たとえば、ビュー・オプションは、メッセージ伝達のための可用性、ビデオ通話のための可用性などといったさまざまなプレゼンス要素を含んでいてもよい。隠された連絡先、グループ、オフラインの連絡先などをフィルタ除去するために、フィルタ・オプションが使用されてもよい。
【００４８】
メッセージ・コマンドは、クライアントにメッセージを送達してもよい。ある実施形態では、典型的なメッセージ送信コマンドは、通知サービス１０８をサポートし、帯域幅消費を減らすよう構成されていてもよい。たとえば、クライアント１０２は、通知ペイロードにおいてまたは待ち行列メッセージ取得コマンドに対する応答のボディにおいてこれらのコマンドを受信してもよい。これは、クライアントの選好に基づいていてもよい。
【００４９】
待ち行列メッセージ取得コマンドは、待ち行列に入れられた通知およびメッセージを取り出すために使われてもよい。ある実施形態では、クライアント１０２は、すべてのキャッシュされた通知が取り出されるまで、メッセージ伝達システム１１０を送信ポーリングしてもよい。プロトコルは、待ち行列に入れられたメッセージを取得するためのコマンドと、メッセージ伝達システム１１０からそれらのメッセージを削除するための別個のコマンドを提供してもよい。
【００５０】
一時的な多者会話を生成し、友達を招待し、メッセージを送り、この多者会話のコンテキストにおいてプレゼンス情報を取得するための一組のコマンドが、典型的な多者会話動作を許容するために使われてもよい。
【００５１】
図３は、特許請求される主題に基づく、メッセージ伝達システム１１０においてクライアント・エンティティを生成するためのメッセージ・フロー図３００である。メッセージ・フロー図３００はメッセージ３０４、３０６を含む。メッセージ３０４は、メッセージ伝達システム１１０へのクライアント・アクセスを許諾してもよい。クライアント１０２からの要求に応答して、メッセージ伝達システム１１０は、クライアント友達アクセス・コントロール・リスト３０２を維持するクラウド・サービスからアクセス・リストを取得してもよく、クライアント認証トークンを生成してもよい。生成されたクライアント認証トークンはクライアント１０２に送られる。
【００５２】
メッセージ３０６は、非接続モードにおける通知のために、メッセージ伝達システム１１０にクライアント１０２を登録してもよい。通知トークンを含む登録要求がメッセージ伝達システム１１０に送られてもよい。その結果、通知トークンおよびクライアント・プレゼンス・データがメッセージ伝達システム１１０に記憶されることになる。通知トークンは、メッセージ伝達システム１１０が、接続されていないときにメッセージ伝達システム１１０からクライアント１０２にメッセージを送るために使うことのできるアドレスを提供する。図３では、認証トークンは、登録メッセージ３０６には含まれていない。ある実施形態では、認証トークンは含まれていてもよい。
【００５３】
図３〜図８を参照して記述されるメッセージは、典型的な通信チャネルに沿って通信されてもよい。任意の特定のメッセージについての通信チャネルの型は、メッセージの送り手および受け手に依存して変わってもよい。
【００５４】
ある実施形態では、クライアント１０２は、許諾トークン、たとえばユーザー・チケットとともに登録コマンドをメッセージ伝達システム１１０に送ってもよい。あるいはまた、エンドポイントは、クライアントからメッセージ伝達システム１１０への呼び出しを最小にするために、登録および他のコマンドのバッチを送ることができる。クライアント１０２は、登録、許諾および初期プレゼンス情報設定のプロセスの間はメッセージ伝達システム１１０への接続を維持しなくてもよい。
【００５５】
メッセージ伝達システム１１０は、許諾トークンを使ってクライアントを認証してもよい。メッセージ伝達システム１１０はクライアント・エンティティを生成し、ユーザーを該クライアントにバインドし、クライアント認証トークンを送り返してもよい。クライアント１０２は該認証トークンを使って、将来の通信のためにメッセージ伝達システム１１０に対して自らを同定してもよい。
【００５６】
本開示の教示を組み込む実施形態を図示し、詳細に記述してきたが、当業者は、それらの教示を組み込んでいる他の多くの変形実施形態を容易に考案できるであろう。上記の教示に照らして、修正および変形が当業者によってなされることができることを注意しておく。
いくつかの態様を記載しておく。
〔態様１〕
ユーザー・インターフェースを表示する方法であって：
表示領域について複数のカードを生成する段階と；
前記複数のカードのうちロックされたゾーンにあるカードが垂直方向に動かされることを許容する段階と；
前記複数のカードのうち通常ゾーンにあるカードが垂直方向に動かされることを制約する段階と；
前記複数のカードのうち前記表示領域にあるカードすべてが水平方向に動かされることを許容する段階とを含む、
方法。
〔態様２〕
前記ロックされたゾーン内のカードだけにユーザー・アクションを受けさせる追加的な段階を含む、態様１記載の方法。
〔態様３〕
前記ユーザー・アクションが、カードの内容をカットする、カードに内容をペーストする、カードの内容を拡大するおよびカードの内容を縮小する、のうちの少なくとも一つである、態様２記載の方法。
〔態様４〕
前記複数のカードのうちどのカードがロックされたゾーンにあるかを決定する追加的な段階を含む、態様１記載の方法であって、前記決定する段階は：
カードが完全に、ロックされたゾーンにあるか、カードの一部がロックされたゾーンにあるかを判別する、カードの50%がロックされたゾーンにあるかを判別する、カードの所定の量がロックされたゾーンにあるかどうかを判別する、のうちの少なくとも一つを含む、方法。
〔態様５〕
態様１記載の方法であって：
前記複数のカードのうち、以前通常ゾーンにあったが、ユーザー・コマンド後に水平方向に動かされたのち、今は前記ロックされたゾーンを占めるカードが垂直方向に動かされることを許容し、一方、前記複数のカードのうち、以前は前記ロックされたゾーンを占めていたが、前記の同じユーザー・コマンド後に水平方向に動かされたのち、今は前記通常ゾーンにあるカードが水平方向に動かされることを制約する、追加的段階を含む、態様１記載の方法。
〔態様６〕
前記ロックされたゾーンがユーザー・コマンドに応答して指定される、態様１記載の方法。
〔態様７〕
前記ロックされたゾーンが前記表示領域中の少なくとも二つの領域を占める、態様１記載の方法。
〔態様８〕
前記通常ゾーンが前記表示領域中の少なくとも二つの領域を占める、態様１記載の方法。
〔態様９〕
ユーザー・インターフェースを表示する装置であって：
表示領域について複数のカードを生成する手段と；
前記複数のカードのうちロックされたゾーンにあるカードが垂直方向に動かされることを許容する手段と；
前記複数のカードのうち通常ゾーンにあるカードが垂直方向に動かされることを制約する手段と；
前記複数のカードのうち前記表示領域にあるカードすべてが水平方向に動かされることを許容する手段とを有する、
装置。
〔態様１０〕
ユーザー・インターフェースを表示する方法であって：
表示領域について複数のカードを生成する段階と；
前記複数のカードのうちロックされたゾーンにあるカードがユーザー・アクションを受けることを許容する段階と；
前記複数のカードのうち前記表示領域にあるカードすべてが水平方向に動かされることを許容する段階とを含む、
方法。
〔態様１１〕
前記ユーザー・アクションが、カードの内容をカットする、カードに内容をペーストする、カードの内容を拡大するおよびカードの内容を縮小する、のうちの少なくとも一つである、態様１０記載の方法。
〔態様１２〕
前記複数のカードのうちどのカードがロックされたゾーンにあるかを決定する追加的な段階を含む、態様１０記載の方法であって、前記決定する段階は：
カードが完全に、ロックされたゾーンにあるか、カードの一部がロックされたゾーンにあるかを判別する、カードの50%がロックされたゾーンにあるかを判別する、およびカードの所定の量がロックされたゾーンにあるかどうかを判別する、のうちの少なくとも一つを含む、方法。
〔態様１３〕
態様１０記載の方法であって：
前記複数のカードのうち、以前通常ゾーンにあったが、ユーザー・コマンド後に水平方向に動かされたのち、今は前記ロックされたゾーンを占めるカードが垂直方向に動かされることを許容し、一方、前記複数のカードのうち、以前は前記ロックされたゾーンを占めていたが、前記の同じユーザー・コマンド後に水平方向に動かされたのち、今は前記通常ゾーンにあるカードが水平方向に動かされることを制約する、追加的な段階を含む、態様１０記載の方法。
〔態様１４〕
前記ロックされたゾーンがユーザー・コマンドに応答して指定される、態様１０記載の方法。
〔態様１５〕
前記ロックされたゾーンが前記表示領域中の少なくとも二つの領域を占める、態様１０記載の方法。
〔態様１６〕
前記通常ゾーンが前記表示領域中の少なくとも二つの領域を占める、態様１０記載の方法。
【００５７】
メッセージ伝達システム１１０に登録することによって、クライアント１０２はプレゼンス変化についての通知およびメッセージを受信しうる。クライアント１０２は、通知が通知ペイロード中に実際のパケットを含まない、すなわちショルダータップ（shoulder  tapping）かどうかを指定してもよい。
【００５８】
図４は、特許請求される主題に基づく、メッセージを送るためのメッセージ・フロー図４００である。メッセージ・フロー図４００は、メッセージ４０４、４０６を含む。メッセージ４０４は、接続していない間に、クライアント１０２が認証トークンを使ってメッセージを送ることを許容する。メッセージ４０６はクライアント１０２が他のクライアント１０２からインスタント・メッセージを受信できるようにしてもよい。図のように、待ち行列メッセージ取得コマンドが、待ち行列２０６からメッセージを取り出すために使用されてもよい。
【００５９】
図５は、特許請求される主題に基づく、加入申し込みをするためのメッセージ・フロー図５００である。クライアント１０２は、加入申し込みコマンドを、該コマンドのボディにおいて指定された諸リストとともに送ることによって連絡先のプレゼンスに加入申し込みする。メッセージ伝達システム１１０は、クライアントの友達リストを維持する別のクラウド・サービス５０２から友達リストを取得してもよい。
【００６０】
プレゼンス通知はクライアントのメッセージ伝達システム１１０に送られてもよい。ひとたびメッセージ伝達システム１１０が友達のプレゼンス通知を得たら、メッセージ伝達システム１１０は通知サービス１０８に通知を送り、通知トークンを使ってターゲット・クライアントを同定してもよい。
【００６１】
ある実施形態では、メッセージ伝達システム１１０は通知をキャッシュして、単にショルダータップ通知（shoulder  tap  notification）を通知サービス１０８に送ってもよい。そのような実施形態では、クライアント１０２は、待ち行列メッセージ取得コマンドをメッセージ伝達システム１１０に送ることによって、キャッシュされた通知を取り出してもよい。
【００６２】
図６は、特許請求される主題に基づく、友達プレゼンスを問い合わせするためのメッセージ・フロー図６００である。図のように、クライアント１０２は、認証トークンを使って友達のプレゼンスを問い合わせしてもよい。
【００６３】
図７は、特許請求される主題に基づく、クライアント・エンティティを登録解除するためのメッセージ・フロー図７００である。この要求は、メッセージ伝達システム１１０への登録解除コマンドにおいて認証トークンを指定してもよい。メッセージ伝達システム１１０は、クラウドからのクライアント認証トークンによって表されるクライアント・エンティティを削除してもよい。
【００６４】
メッセージ伝達システム１１０からクライアント１０２を登録解除するために、メッセージ伝達システム１１０はクライアント状態を利用不能に設定する。よって、クライアント１０２へのいかなるさらなるメッセージも中断されてよく、送り側にエラーが返されてもよい。
【００６５】
図８は、特許請求される主題に基づく、多者会話のためのメッセージ・フロー図８００である。多者会話のためには、ホスト８０２上に登録者リストがホストされていてもよい。ホスト８０２は、メッセージ伝達システム１１０のコンポーネントであってもよい。会話は、一時的なグループとして同定されてもよい。
【００６６】
先述したように、既存のメッセージ伝達システムは、上記の非接続モードを受け入れるよう修正されてもよい。これらの修正は、負荷均衡化、帯域制限および地理的分散ホスティングに関して問題を導入することがある。ある実施形態では、メッセージ伝達システム１１０はクライアント接続モードの変化に対処するために、さまざまな負荷均衡化技法を使うことがありうる。複数の地理的クラウド位置を横断して負荷を均衡化するためにグローバルな負荷均衡化システムが使われてもよい。
【００６７】
さらに、メッセージ伝達システム１１０は、クライアントによるその資源の使用をコントロールし、悪意のある使用から自らを保護するために、さまざまな帯域制限技法を使ってもよい。
【００６８】
図９は、特許請求される主題の諸側面が用いられることのできる例示的なネットワーク接続環境９００のブロック図である。さらに、例示的なネットワーク接続環境９００は、非接続のクライアントと通信するシステムおよび方法を実装するために使われてもよい。
【００６９】
ネットワーク接続環境９００は、一つまたは複数のクライアント９００を含む。クライアント９１０はハードウェアおよび／またはソフトウェア（たとえばスレッド、プロセス、コンピューティング装置）であることができる。例として、クライアント９１０は、インターネットのような通信フレームワーク９４０を通じてサーバーにアクセスを提供するコンピュータであってもよい。
【００７０】
環境９００は、一つまたは複数のサーバー９２０をも含む。サーバー９２０はハードウェアおよび／またはソフトウェア（たとえばスレッド、プロセス、コンピューティング装置）であることができる。サーバーはクライアント９１０によってアクセスされてもよい。
【００７１】
クライアント９１０とサーバー９２０との間の一つの可能な通信は、二つ以上のコンピュータ・プロセスの間で伝送されるよう適応されたデータ・パケットの形であることができる。環境９００は、クライアント９１０とサーバー９２０との間の通信を容易にするために用いられることのできる通信フレームワーク９４０を含む。
【００７２】
クライアント９１０は、クライアント９１０にローカルな情報を記憶するために用いられることのできる一つまたは複数のクライアント・データ記憶９５０に動作可能に接続される。クライアント・データ記憶９５０はクライアント９１０内に、またはクラウド・サーバー内などリモートに位置されていてもよい。同様に、サーバー９２０はサーバー９２０にローカルな情報を記憶するために用いられることのできる一つまたは複数のサーバー・データ記憶９３０に動作可能に接続される。
【００７３】
図１０を参照すると、特許請求される主題のさまざまな側面を実装するための例示的な動作環境１０００が示されている。例示的な動作環境１０００はコンピュータ１０１２を含む。コンピュータ１０１２は処理ユニット１０１４と、システム・メモリ１０１６と、システム・バス１０１８とを含む。
【００７４】
システム・バス１０１８は、これに限られないがシステム・メモリ１０１６を含むシステム・コンポーネントを処理ユニット１０１４に結合する。処理ユニット１０１４はさまざまな利用可能なプロセッサの任意のものであることができる。デュアル・マイクロプロセッサおよび他のマルチプロセッサ・アーキテクチャが処理ユニット１０１４として用いられることもできる。
【００７５】
システム・バス１０１８は、当業者に既知の任意の多様な利用可能なバス・アーキテクチャを使った、メモリ・バスまたはメモリ・コントローラ、周辺バスまたは外部バスおよび／またはローカル・バスを含むいくつかの型のバス構造の任意のものであることができる。システム・メモリ１０１６は、揮発性メモリ１０２０および不揮発性メモリ１０２２を含む非一時的なコンピュータ可読記憶媒体を含む。
【００７６】
スタートアップ時などコンピュータ１０１２内の要素間で情報を転送するための基本的ルーチンを含む基本入出力システム（BIOS）が不揮発性メモリ１０２２に記憶されていてもよい。限定ではなく例として、不揮発性メモリ１０２２は読み出し専用メモリ（ROM）、プログラム可能型ROM（PROM）、電気的にプログラム可能なROM（EPROM）、電気的に消去可能なプログラム可能型ROM（EEPROM）またはフラッシュメモリを含むことができる。
【００７７】
揮発性メモリ１０２０は、外部キャッシュ・メモリとしてはたらくランダム・アクセス・メモリ（RAM）を含む。限定ではなく例として、RAMは、静的RAM（SRAM）、動的RAM（DRAM）、同期DRAM（SDRAM）、倍速データレートSDRAM（DDR  SDRAM）、向上SDRAM（ESDRAM）、シンクリンク（SynchLink）（商標）DRAM（SLDRAM）、ランバス（Rambus）（登録商標）直接RAM（RDRAM）、直接ランバス（登録商標）動的RAM（DRDRAM）およびランバス（登録商標）動的RAM（RDRAM）といった多くの形で利用可能である。
【００７８】
コンピュータ１０１２は、リムーバブル／非リムーバブル、揮発性／不揮発性コンピュータ記憶媒体のような他の非一時的なコンピュータ記憶媒体をも含む。図１０は、たとえば、ディスク記憶１０２４を示している。ディスク記憶１０２４は、これに限られないが、磁気ディスク・ドライブ、フロッピー（登録商標）ディスク・ドライブ、テープ・ドライブ、ジャズ（Jaz）ドライブ、ジップ（Zip）ドライブ、LS-100ドライブ、フラッシュ・メモリ・カードまたはメモリースティックのようなデバイスを含む。
【００７９】
さらに、ディスク記憶１０２４は、別個に、あるいは、これに限られないがコンパクトディスクROMデバイス（CD-ROM）、CD記録可能ドライブ（CD-Rドライブ）、CD書き換え可能型ドライブ（CD-RWドライブ）またはデジタル多用途ディスクROMドライブ（DVD-ROM）といった光ディスク・ドライブを含む他の記憶媒体と組み合わせて記憶媒体を含むことができる。ディスク記憶デバイス１０２４のシステム・バス１０１８への接続を容易にするために、インターフェース１０２６のようなリムーバブルまたは非リムーバブルのインターフェースが典型的には使用される。
【００８０】
図１０は、ユーザーと好適な動作環境１０００内に記述される基本的なコンピュータ資源との間の仲介者のはたらきをするソフトウェアを記述していることが理解される。そのようなソフトウェアはオペレーティング・システム１０２８を含む。ディスク記憶１０２４に記憶されることのできるオペレーティング・システム１０２８は、コンピュータ・システム１０１２の資源をコントロールおよび割り当てするはたらきをする。
【００８１】
システム・アプリケーション１０３０は、システム・メモリ１０１６またはディスク記憶１０２４に記憶されたプログラム・モジュール１０３２およびプログラム・データ１０３４を通じてオペレーティング・システム１０２８による資源の管理を利用する。特許請求される主題は、さまざまなオペレーティング・システムまたはオペレーティング・システムの組み合わせで実装できることは理解しておくものとする。
【００８２】
ユーザーは、入力装置１０３６を通じてコンピュータ１０１２にコマンドまたは情報を入力する。入力装置１０３６はこれに限られないが、ポインティングデバイス（マウス、トラックボール、スタイラスなどのような）、キーボード、マイクロホン、ジョイスティック、衛星ディッシュ、スキャナ、テレビ・チューナー・カード、デジタル・カメラ、デジタル・ビデオ・カメラ、ウェブ・カメラおよび／またはその他を含む。入力装置１０３６は、インターフェース・ポート（単数または複数）１０３８を介してシステム・バス１０１８を通じて処理ユニット１０１４に接続される。インターフェース・ポート１０３８はたとえば、シリアル・ポート、パラレル・ポート、ゲーム・ポートおよびユニバーサル・シリアル・バス（USB）を含む。
【００８３】
出力装置（単数または複数）１０４０は、入力装置（単数または複数）１０３６と同じ型のポートのいくつかを使う。よって、たとえば、USBポートが、コンピュータ１０１２に入力を提供するためおよびコンピュータ１０１２から出力装置１０４０に情報を出力するために使用されてもよい。
【００８４】
出力アダプター１０４２は、アダプターを介してアクセス可能な、数ある出力装置１０４０の中でもモニタ、スピーカーおよびプリンターのようないくつかの出力装置１０４０があることを示すために設けられている。出力アダプター１０４２は、限定ではなく例として、出力装置１０４０とシステム・バス１０１８との間の接続の手段を提供するビデオおよびサウンド・カードを含む。他の装置および／または装置のシステムは、リモート・コンピュータ（単数または複数）１０４４のような入力および出力機能の両方を提供することを注意しておくことができる。
【００８５】
コンピュータ１０１２は、リモート・コンピュータ（単数または複数）１０４４のような一つまたは複数のリモート・コンピュータへの論理的な接続を使ってネットワーク接続された環境においてさまざまなソフトウェア・アプリケーションをホストするサーバーであることができる。リモート・コンピュータ１０４４は、ウェブ・ブラウザ、PCアプリケーション、携帯電話アプリケーションなどとともに構成されたクライアント・システムであってもよい。
【００８６】
リモート・コンピュータ１０４４は、パーソナル・コンピュータ、サーバー、ルーター、ネットワークPC、ワークステーション、マイコン・ベースの機器、携帯電話、ピア装置または他の一般的なネットワーク・ノードなどであることができ、典型的にはコンピュータ１０１２に関して記述された要素の多くまたは全部を含む。
【００８７】
簡単のため、メモリ記憶デバイス１０４６だけがリモート・コンピュータ１０４４とともに示されている。リモート・コンピュータ１０４４はネットワーク・インターフェース１０４８を通じてコンピュータ１０１２に論理的に接続され、次いで通信接続１０５０を介して物理的に接続される。
【００８８】
ネットワーク・インターフェース１０４８は、ローカル・エリア・ネットワーク（LAN）および広域ネットワーク（WAN）といった有線および／または無線通信ネットワークを包含する。LAN技術はファイバー分散データ・インターフェース（FDDI:  Fiber  Distributed  Data  Interface）、銅線分散データ・インターフェース（CDDI:  Copper  Distributed  Data  Interface）、イーサネット（登録商標）、トークンリングなどを含む。WAN技術は、これに限られないが、ポイントツーポイント・リンク、統合サービスデジタル通信網（ISDN:  Integrated  Services  Digital  Networks）およびそれらの変形のような回線交換ネットワーク、パケット交換網およびデジタル加入者線（DSL:  Digital  Subscriber  Lines）を含む。
【００８９】
通信接続（単数または複数）１０５０は、ネットワーク・インターフェース１０４８をバス１０１８に接続するために用いられるハードウェア／ソフトウェアを指す。通信接続１０５０は例示的な明確さのためにコンピュータ１０１２内に示されているが、コンピュータ１０１２の外部であることもできる。ネットワーク・インターフェース１０４８への接続のためのハードウェア／ソフトウェアは、単に例示的な目的のために、携帯電話スイッチ、通常の電話品質モデム、ケーブル・モデムおよびDSLモデムを含むモデム、ISDNアダプターおよびイーサネット（登録商標）・カードといった内蔵および外付け技術を含んでいてもよい。
【００９０】
サーバーのための例示的な処理ユニット１０１４は、インテル（登録商標）Xeon  CPUを含むコンピューティング・クラスターであってもよい。ディスク記憶１０２４は、たとえば数千の印象（impressions）を保持する企業データ記憶システムを含んでいてもよい。
【００９１】
上記のことは、主題となる革新の例を含む。もちろん、特許請求される主題を記述する目的のためにコンポーネントまたは方法論の考えられるあらゆる組み合わせを記述することは可能ではないが、当業者は、主題となる革新の多くのさらなる組み合わせおよび入れ替えが可能であることを認識しうる。よって、特許請求される主題は、付属の請求項の精神および範囲内にはいるあらゆるそのような変更、修正および変形を包含することが意図されている。
【００９２】
特に、上記のコンポーネント、装置、回路、システムなどによって実行されるさまざまな機能に関し、そのようなコンポーネントを記述するために使われる用語（「手段」への言及を含む）は、特に断りのない限り、記述されるコンポーネントの特定される機能を実行する、たとえ開示される構造と構造的に等価でなくても本稿で示される特許請求される主題の例示的な側面における機能を実行する、任意のコンポーネント（たとえば機能的な等価物）に対応することが意図されている。これに関し、本革新がシステムおよび特許請求される主題のさまざまな方法の工程および／またはイベントを実行するためのコンピュータ実行可能な命令を有するコンピュータ可読記憶媒体を含むことも認識されるであろう。
【００９３】
主題となる革新を実装する多くの方法がある。たとえば、アプリケーションおよびサービスが本稿に記載される技法を使うことを可能にする、適切なAPI、ツール・キット、ドライバ・コード、オペレーティング・システム、コントロール、スタンドアローンまたはダウンロード可能なソフトウェア・オブジェクトなどである。特許請求される主題は、API（または他のソフトウェア・オブジェクト）の観点から、および本稿に記載される技法に従って動作するソフトウェアまたはハードウェア・オブジェクトからの使用を考えている。よって、本稿に記載される主題となる革新のさまざまな実装は、完全にハードウェアである、部分的にハードウェア、部分的にソフトウェアである、またソフトウェアである諸側面を有しうる。
【００９４】
上述したシステムは、いくつかのコンポーネントの間の相互作用に関して記述してきた。そのようなシステムおよびコンポーネントは、それらのコンポーネントまたは指定されたサブコンポーネント、指定されたコンポーネントまたはサブコンポーネントの一部および／または追加的なコンポーネントならびに上記のさまざまな入れ替えおよび組み合わせを含むことができることは理解できる。サブコンポーネントは、親コンポーネント内に含まれる（階層的）のではなく、他のコンポーネントに通信上結合されるコンポーネントとして実装されることもできる。
【００９５】
さらに、一つまたは複数のコンポーネントが総合的な機能を提供する単一のコンポーネントに組み合わされてもよく、あるいはいくつかの別個のサブコンポーネントに分割されてもよく、統合された機能を提供するためにそのようなサブコンポーネントに通信上結合するよう管理層のような任意の一つまたは複数の中間層が設けられてもよいことに注意しておいてもよい。本稿に記載した任意のコンポーネントは、本稿に特定的に記載されないが当業者には一般に知られている一つまたは複数の他のコンポーネントと相互作用してもよい。
【００９６】
さらに、主題となる革新の特定の特徴がいくつかの実装のうち一つだけとの関連で開示されていることもありうるが、そのような特徴は、任意の所与のまたは具体的な応用についての所望および利点に応じて、他の実装の一つまたは複数の他の特徴と組み合わされてもよい。さらに、用語「含む」、「もつ」、その変形および他の同様の単語が詳細な説明または請求項のいずれかにおいて使用される限りにおいて、これらの用語は、何らかの追加的なまたは他の要素を排除しない、オープンな移行語として包含的であることが意図されている。
【図１】
0006053699.tif 000002
【図２】
0006053699.tif 000003
【図３】
0006053699.tif 000004
【図４】
0006053699.tif 000005
【図５】
0006053699.tif 000006
【図６】
0006053699.tif 000007
【図７】
0006053699.tif 000008
【図８】
0006053699.tif 000009
【図９】
0006053699.tif 000010
【図１０】
0006053699.tif 000011