(57)【要約】  様々な実施形態は、ウェブクライアントがウェブサービスを提供できるようにする。１つ又は複数の実施形態において、ウェブクライアントは、サーバとして動作するように構成され、他の目的の中でも特に、ウェブクライアントによってサポートされるウェブサービスへの呼び出し及びそのウェブサービスからの呼び出しに使用され得る。そのような使用は、限定ではなく例として、ウェブクライアントへ及びウェブクライアントからメッセージをプッシュすることを含むことができる。様々な技術が標準のプロトコル及びライブライを用いることができ、いずれのカスタムコード又はカスタムプラグインも必要としない。
2015520436.tif 000002
【特許請求の範囲】
【請求項１】
ウェブクライアントによって提供されるウェブサービスに関連するＨＴＴＰ要求を生成するステップと、
前記ＨＴＴＰ要求を、トンネルサービスを実装するインターミディアリサーバに送信するステップと、
前記トンネルサービスから、前記ＨＴＴＰ要求に関連するＨＴＴＰ応答を受信するステップと、
前記ＨＴＴＰ応答を処理するステップであって、前記ＨＴＴＰ応答は、前記ウェブクライアントによる前記ウェブサービスの実行結果に関連するデータ及び情報を含む、ステップと
を含む、方法。
【請求項２】
前記ＨＴＴＰ要求は、前記インターミディアリサーバに関連付けられるトンネルエンドポイントと、前記ウェブクライアントに関連付けられるトンネルＩＤと、前記ウェブサービスを識別し、かつ前記ウェブサービスによって処理されるべきデータ及び情報を含むペイロードとを含む、請求項１に記載の方法。
【請求項３】
前記の生成するステップ、送信するステップ、受信するステップ及び処理するステップは、クライアントコンピューティングデバイスを備える呼び出し元によって実行される、請求項１に記載の方法。
【請求項４】
前記の生成するステップ、送信するステップ、受信するステップ及び処理するステップは、ブラウザを備える呼び出し元によって実行される、請求項１に記載の方法。
【請求項５】
前記の生成するステップ、送信するステップ、受信するステップ及び処理するステップは、ブラウザを備える呼び出し元によって実行され、前記ウェブクライアントは別のブラウザを備える、請求項１に記載の方法。
【請求項６】
前記の生成するステップ、送信するステップ、受信するステップ及び処理するステップは、２つのウェブブラウザ間のブラウザベースのチャットを実装するのに実行される、請求項１に記載の方法。
【請求項７】
コンピュータ読取可能命令を具現化する１つ又は複数のコンピュータ読取可能記憶媒体であって、前記命令は、実行されると、
トンネルサービスにおいて、呼び出し元からのＨＴＴＰ要求を受信するステップであって、前記ＨＴＴＰ要求は、ウェブサービスをサポートするウェブクライアントに向けられたものである、ステップと、
前記ＨＴＴＰ要求をシリアル化するステップと、
前記シリアル化されたＨＴＴＰ要求を要求構造にカプセル化するステップと、
前記カプセル化された要求構造を前記ウェブクライアントに送信するステップと、
前記トンネルサービスにおいて、前記ウェブクライアントからカプセル化された応答構造を受信するステップであって、前記カプセル化された応答構造は、前記ウェブサービスの実行に関連するデータ及び情報を含む、ステップと、
前記カプセル化された応答構造を処理してＨＴＴＰ応答を提供し、該ＨＴＴＰ応答を前記呼び出し元に送信するステップであって、前記ＨＴＴＰ応答が前記データ又は情報を含む、ステップと
を含む方法を実施する、１つ又は複数のコンピュータ読取可能記憶媒体。
【請求項８】
前記カプセル化するステップは、前記シリアル化されたＨＴＴＰ要求をＪＳＯＮ（JavaScript  Object  Notation）にカプセル化することによって実行される、請求項７に記載の１つ又は複数のコンピュータ読取可能記憶媒体。
【請求項９】
前記呼び出し元はブラウザを備える、請求項７に記載の１つ又は複数のコンピュータ読取可能記憶媒体。
【請求項１０】
前記呼び出し元及び前記ウェブクライアントのいずれもブラウザを備えない、請求項７に記載の１つ又は複数のコンピュータ読取可能記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ウェブクライアントがウェブサービスを提供できるようにすることに関する。
【背景技術】
【０００２】
ウェブサーバが互いに対するトランザクションを実行するとき、非常に一般的なプログラミングパターンは、ＨＴＴＰをトランスポートとして使用することである。例えば第１のサーバが、ＨＴＴＰ  ＧＥＴ要求を出して、第２のサーバに特定のリソースの表現を要求することがある。第２のサーバは次いで、リソース表現で応答することができる。サーバ間のトランザクションは、より非同期的な手法で行われる可能性もある。例えば第１のサーバは、ＨＴＴＰ  ＧＥＴ要求を出して、第２のサーバが応答時に使用するリターンＵＲＬを提供することがある。しばらくして、第２のサーバは、第１のサーバによって提供されたＵＲＬを使用して、非同期的に第１のサーバへ応答を返すことができる。この処理は、サーバ間で逆に動作することも容易である。
【０００３】
この同じモデルを使用して、ウェブブラウザのようなクライアント側アプリケーションとサーバとの間のトランザクションは、クライアント側アプリケーションがＨＴＴＰ  ＧＥＴ要求を出して、サーバからの応答を受信することで動作することができる。しかしながら、同じことが逆の処理には当てはまらない可能性がある。特に、サーバは典型的に、ＨＴＴＰ  ＧＥＴ要求やＰＯＳＴ要求をクライアント側アプリ―ケーション又はウェブブラウザに出すことができない。というのも、多くの理由の中でも特に、ウェブブラウザが、典型的にウェブサーバを実行しないからである。もしウェブブラウザが実行したとしても、ファイヤウォール又はネットワークアドレストランスレーション（ＮＡＴ）デバイスのような他の機構は、実際に、そのようなトランザクションが行われるのを不可能にするであろう。
【発明の概要】
【０００４】
この「発明の概要」の記載は、以下の「発明を実施するための形態」において更に説明される概念の選択を簡略化した形で紹介するのに提供される。この「発明の概要」の記載は、特許請求される主題の主要な特徴又は本質的な特徴を特定するようには意図されていない。
【０００５】
様々な実施形態は、ウェブクライアントがウェブサービスを提供するのを可能にする。１つ又は複数の実施形態において、ウェブクライアントは、サーバとして動作し、他の目的の中でも特に、ウェブクライアントによってサポートされるウェブサービスへの呼び出し及びそのウェブサービスからの呼び出しに使用することができる。そのような使用は、限定ではなく例として、ウェブクライアントへ及びウェブクライアントからメッセージをプッシュすることを含むことができる。様々な技術は、標準のプロトコル及びライブラリを用いることができ、いずれのカスタムコード又はカスタムプラグインも必要としない。
【０００６】
１つ又は複数の実施形態において、中間サーバが、ウェブクライアントとの持続接続が確立されるインターミディアリとして機能する。インターミディアリサーバは、ウェブクライアントを、例えばウェブサービスＵＲＬのようなウェブクライアントのプレゼンス又はアドレスを使用して、世界に公開することができる。メッセージを第１のウェブクライアントに送信しようとする他のウェブクライアント（例えばブラウザベースのクライアント）は、公開されたウェブサービスＵＲＬを使用して、予め定義されたウェブサービスを呼び出すことができる。呼び出しを行うウェブクライアントは、同じインターミディアリサーバ又は異なるインターミディアリサーバのいずれかに登録して、そのウェブサービスＵＲＬを公開することもできる。第１のウェブクライアントはその後、このＵＲＬを使用して、メッセージを第２のウェブクライアントにプッシュすることができる。
【０００７】
発明の詳細な説明は、添付の図面を参照しながら説明される。図面において、参照符号の最も左の桁は、その参照符号か最初に現れる図面を特定する。説明及び図面の異なる例における同じ参照符号の使用は、類似又は同一のアイテムを示すことがある。図面に現れるエンティティは、1つ又は複数のエンティティを示すことがあり、したがって、議論において、単数形又は複数形のエンティティへの参照は区別せずに行われることがある。
【図面の簡単な説明】
【０００８】
【図１】１つ又は複数の実施形態に係る例示の実装の環境を示す図である。
【図２】１つ又は複数の実施形態に係る例示の実装の別の環境を示す図である。
【図３】１つ又は複数の実施形態に係る２つのウェブクライアントの間の通信フローを示す図である。
【図４】１つ又は複数の実施形態に係る呼び出し元と、トンネルサービスと、ウェブクライアントとの間の例示のシーケンスフローを示す図である。
【図５】１つ又は複数の実施形態に係る例示の実装のプロシージャを示すフロー図である。
【図６】本明細書で説明される技術の諸実施形態を実装するように、図１及び図２を参照して説明されるような任意のタイプのコンピューティングデバイスとして実装され得る、例示デバイスの様々なコンポーネントを含む例示のシステムを示す図である。
【発明を実施するための形態】
【０００９】
＜概要＞
様々な実施形態は、ウェブクライアントがウェブサービスを提供するのを可能にする。ウェブサービスは、指定のＵＲＬにアドレスされるＨＴＴＰ要求を送信し、ＵＲＬ、ヘッダ及び本文を含め、ＨＴＴＰ要求の様々なフィールド内に入力パラメータを保持することによって、起動することができるプログラムである。次いでプログラムの計算の結果である出力パラメータが、ステータスコード、ヘッダ及び本文を含め、ＨＴＴＰ応答の様々なフィールド内で返される。１つ又は複数の実施形態において、ウェブクライアントは、サーバとして動作し、他の目的の中でも特に、ウェブクライアントによってサポートされるウェブサービスへの呼び出し及びそのウェブサービスからの呼び出しに使用することができる。そのような使用は、限定ではなく例として、ウェブクライアントへ及びウェブクライアントからメッセージをプッシュすることを含むことができる。様々な技術は、標準のプロトコル及びライブラリを用いることができ、カスタムコード又はカスタムプラグインを必要としない。様々な技術を、例えば標準のプロトコル及びライブラリを使用して、ブラウザへのカスタムコード又はプラグインのインストールを必要とせずに、ブラウザベースのチャットクライアントを実装するのに使用することができる。少なくとも一部の実施形態において、行われるＨＴＴＰ通信の構造を修正する必要なく、標準のＨＴＴＰ技術を使用することができる。
【００１０】
１つ又は複数の実施形態において、中間サーバが、ウェブクライアントとの持続接続が確立されるインターミディアリとして機能する。持続接続は、認定の適切な技法又は技術を使用して確立され得る。限定ではなく例として、そのような技法又は技術は、ＣＯＭＥＴ、ＷｅｂＳｏｃｋｅｔ（ウェブソケット）等を含む可能性がある。インターミディアリサーバは、ウェブクライアントを、例えばウェブサービスＵＲＬのようなウェブクライアントのプレゼンス又はアドレスを使用して、世界に公開することができる。メッセージを第１のウェブクライアントに送信しようとする他のウェブクライアント（例えばブラウザベースのクライアント）は、公開されたウェブサービスＵＲＬを使用して、予め定義されたウェブサービスを呼び出すことができる。呼び出しを行うウェブクライアントは、同じインターミディアリサーバ又は異なるインターミディアリサーバのいずれかに登録して、そのウェブサービスＵＲＬを公開することもできる。第１のウェブクライアントはその後、このＵＲＬを使用して、メッセージを第２のウェブクライアントにプッシュすることができる。
【００１１】
本明細書で説明される技術を、多数の実質的な使用に用いることができる。例えば様々な実施形態は、標準のウェブサービス技術を使用してブラウザベースのクライアントの実装を可能にすることができる。ブラウザは、いずれのプラグインのインストールも要さずに、ウェブサービスを呼び出すことができるので、ブラウザクライアントは、非常に軽量になるように設計されることが可能であり、ウェブブラウザを有する任意のデバイス上で動作することが可能である。したがって、様々な柔軟な使用シナリオを提供することができる。加えて、本明細書で説明される技術は、ブラウザベースでないシナリオに対しても幅広く適用可能であり得る。例えば本技術を、限定ではなく例として組み込みデバイスを含む、任意の適切に構成されるデバイスによって用いることができる。例えばそのような組み込みデバイスは、「スマートホーム」や「スマートオフィス」シナリオのような様々なシナリオで用いることが可能な形式をとることができ、上記のような「スマートホーム」又は「スマートオフィス」シナリオでは、例えばライトのスイッチのようなデバイスを組み込みデバイスとして構成し、本明細書で説明されるようにウェブサービスを提示して使用することができる。
【００１２】
以下の議論では、最初に、本明細書で説明される技術を用いることができる例示の環境を説明する。次いで、例示のプロシージャを説明するが、この例示のプロシージャは、例示の環境だけでなく他の環境において実行されてもよい。したがって、例示のプロシージャの実行は例示の環境に限定されず、例示の環境は例示のプロシージャの実行に限定されない。
【００１３】
＜例示の環境＞
図１は、１つ又は複数の実施形態に係る例示の環境１００を示す図である。環境１００は、呼び出し元１０２、クライアント１０４及びインターミディアリサーバ１０６を含む。
【００１４】
呼び出し元１０２は、限定ではなく例として、インターミディアリサーバ１０６を呼び出すように構成されるクライアントコンピューティングデバイス、サーバ又は任意の他のエンティティのような、任意の適切に構成された呼び出し元を備えることができる。１つ又は複数の実施形態において、呼び出し元及びクライアントは、下記に例を提供する任意の適切なコンピューティングデバイス上で実行される、任意の適切なソフトウェアエージェントを備えることができる。このエージェントは、通信するのに本明細書で説明されるメソッド、例えばＨＴＴＰメソッド並びにクライアントのための様々な持続接続のタイプを使用するように構成される。図示及び説明される実施形態において、クライアント１０４は、インターミディアリサーバ１０６との持続接続を含む。任意の適切な技術を使用して、持続接続が確立されるのを可能にすることができる。インターミディアリサーバ１０６は、トンネルエンドポイントによって識別されるトンネルサービスを実装する。上記したように、クライアント１０４は、任意の適切なタイプのクライアントを備えることができる。本明細書で使用される様々な例において、クライアント１０４は、ウェブクライアントを備えており、このウェブクライアントは、必須ではないが、ウェブブラウザとして又はブラウザベースの技術を用いて通信するエージェントとして存在することができる。クライアント１０４は、しかしながら、ブラウザベースの技術を用いて通信する必要はない。例えばクライアント１０４は、当業者に認識されるように、インターミディアリサーバ１０６とのトンネリングにネイティブのライブラリを用いる、モバイルクライアント又は組み込みライブラリの形で存在してもよい。ウェブクライアント１０４は、トンネルＩＤを使用してインターミディアリサーバ１０６に登録する。
【００１５】
動作において、呼び出し元１０２は、ＨＴＴＰ又はＨＴＴＰＳのような標準のウェブプロトコルを用いて、標準の動詞を使用してインターミディアリサーバ１０６を呼び出す。これは、通信するのに用いられる標準のＨＴＴＰ技術に対する修正を全く必要とせずに行うことができる。呼び出し元１０２によって提示される呼び出しには、インターミディアリサーバ１０６に関連付けられるトンネルエンドポイントと、ウェブクライアント１０４に関連付けられるトンネルＩＤと、ウェブクライアント１０４によって実装されるウェブサービスを識別し、及びウェブクライアントによって実装されるウェブサービスにより処理すべきデータ若しくは情報を識別するペイロードとを含む。インターミディアリサーバ１０６は、この呼び出しを、ウェブクライアントが処理することができる標準のウェブ構造に変換することによって処理する。例えばインターミディアリサーバ１０６は、呼び出しをシリアル化し、これを標準にウェブ構造内にカプセル化することができる。その後、カプセル化された構造は、インターミディアリサーバ１０６によって、持続接続を介して、処理のためにウェブクライアント１０４に通信される。ウェブクライアント１０４は、カプセル化された構造を受信すると、ライブラリを用いて、カプセル化された構造により受信したデータ及び情報を含むイベントを、処理のためにウェブサービスに対して発火することができる。データ又は情報がウェブサービスによって処理されると、ウェブクライアント１０４は、ペイロードを有するカプセル化された構造を含む応答を形成する。形成された応答は、インターミディアリサーバ１０６に送信される。形成された応答は、ＴＣＰ接続のような標準の接続を使用してインターミディアリサーバ１０６に送信され得る。インターミディアリサーバ１０６は次いで、この応答を処理してＨＴＴＰ応答を形成し、このＨＴＴＰ応答はその後呼び出し元１０２へ通信される。
【００１６】
このアプローチを使用して、ウェブクライアント１０４によってサポートされる、ファイヤウォールの後ろに存在するウェブサービスは、完全に機能するＨＴＴＰエンドポイントとして使用され、現れることができる。さらに、標準のプロトコルを用いることによって、呼び出し元１０２及びウェブクライアント１０４は、ＮＡＴを通じて、あるいは他の方法ではそのような通信を行うことができないであろう他のデバイスを通じて通信することができる。さらに、当業者には認識されるように、説明されるアプローチは標準のプロトコルを用いるので、効果的な通信に追加のプラグイン又は特別な技術は使用されない。
【００１７】
一般に、本明細書で説明される機能のうちのいずれかは、ソフトウェア、ファームウェア、ハードウェア（例えば固定の論理回路）又はこれらの実装の組み合わせを使用して実装され得る。本明細書で使用されるとき、「モジュール」、「機能性」及び「ロジック（論理）」という用語は一般的に、ソフトウェア、ファームウェア、ハードウェア又はこれらの組み合わせを表す。ソフトウェア実装の場合、モジュール、機能性又はロジックは、プロセッサ（例えば１つ又は複数のＣＰＵ）上で実行されると、指定のタスクを実行するプログラムコードを表す。プログラムコードを、１つ又は複数のコンピュータ読取可能メモリデバイスに格納することができる。以下で説明される技術の特徴はプラットフォーム独立であり、これは、これらの技術が、様々なプロセッサを有する様々な市販のコンピューティングプラットフォームにおいて実装され得ることを意味する。
【００１８】
例えば呼び出し元１０２及びウェブクライアント１０４は、呼び出し元１０２又はウェブクライアント１０４のハードウェア、例えばプロセッサ、機能ブロック等に動作を実行させるエンティティ（例えばソフトウェア）も含み得る。例えば呼び出し元１０２及びウェブクライアント１０４は、関連するコンピューティングデバイス、より具体的にはコンピューティングデバイスのハードウェアに動作を実行させる命令を保持するように構成され得るコンピュータ読取可能媒体を含むことがある。したがって、命令は、動作を実行するようにハードウェアを構成するよう機能し、このようにして、機能を実行するようにハードウェアの変換が行われることになる。命令は、コンピュータ読取可能媒体によって、様々な異なる構成を通じてコンピューティングデバイスに提供され得る。
【００１９】
コンピュータ読取可能媒体のそのような構成の１つは、信号担持媒体であり、したがって命令を（例えば搬送波として）コンピューティングデバイスのハードウェアに、ネットワーク経由等により伝送するように構成される。コンピュータ読取可能媒体は、コンピュータ読取可能記憶媒体として構成されることもあり、この場合は信号担持媒体ではない。コンピュータ読取可能記憶媒体の例には、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、光ディスク、フラッシュメモリ、ハードディスクメモリ並びに磁気、光及び他の技術を使用して命令及び他のデータを格納し得る他のメモリデバイスが含まれる。
【００２０】
プロセッサは、該プロセッサが形成される材料及びプロセッサで用いられる処理機構によって制限されない。例えばプロセッサは、半導体及び／又はトランジスタ（例えば電子集積回路（ＩＣ））で構成されてもよい。そのようなコンテキストにおいて、プロセッサ実行可能な命令は、電気的に実行可能な命令とすることができる。あるいは、プロセッサの機構又はプロセッサ用の機構、したがってコンピューティングデバイスの機構又はコンピューティングデバイス用の機構には、これらに限られないが、量子演算、光演算、機械演算（例えばナノテクノロジを使用するもの）等が含まれ得る。
【００２１】
例示の動作環境について検討したので、次に、呼び出し元及びウェブクライアントが、ウェブブラウザを用いて通信するコンピューティングデバイスの形式で存在する、具体的な例について検討する。
【００２２】
図２は、本明細書で説明される技術を用いるように動作可能な例示的実装の環境２００の図である。図示される環境２００は、コンピューティングデバイス２０２、２２０と、インターミディアリサーバ２３０、２４０と、インターミディアリサーバ２３０、２４０を通信可能にリンクするインターネントのようなネットワーク２５０とを含む。コンピューティングデバイス２０２、２２０は、上述のようなウェブサービスを実装するように構成される。
【００２３】
コンピューティングデバイス２０２は、コンピュータ読取可能記憶媒体２０４を含み、コンピュータ読取可能記憶媒体２０４は、オペレーティングシステム２０６と、１つ又は複数のアプリケーション２０８と、ウェブブラウザ２１０を含む。コンピューティングデバイス２２０は、コンピュータ読取可能記憶媒体２２２を含み、コンピュータ読取可能記憶媒体２２２は、オペレーティングシステム２２４と、１つ又は複数のアプリケーション２２６と、ウェブブラウザ２２８を含む。コンピューティングデバイスの様々なリソース、例えばオペレーティングシステム、オペレーティングシステムリソース、アプリケーション及び／ウェブブラウザは、以下で明らかになるように、ウェブＵＲＬによって表されることが可能である。このようにして、ウェブサービスは様々なレベルの粒度で公開され得る。その例は以下で提供される。
【００２４】
オペレーティングシステム２０６、２２４は、基礎となるそれぞれのコンピューティングデバイスを、該コンピューティングデバイス上で実行可能なそれぞれアプリケーション又はウェブブラウザに抽象化するように構成される。例えばオペレーティングシステム２０６、２２４は、それぞれのコンピューティングデバイスの処理メモリ、ネットワーク及び／又はディスプレイ機能を抽象化してもよく、その結果、この基礎となる機能性がどのように実装されるかを知らずに、アプリケーションを書くことができる。例えばアプリケーションは、レンダリングがどのように行われるかを理解することなく、コンピューティングデバイスに関連付けられたディスプレイデバイスによってレンダリングされて表示されるべきデータを、オペレーティングシステムに提供することがある。
【００２５】
オペレーティングシステムは、コンピューティングデバイスのユーザによりナビゲート可能なファイルシステム及びユーザインタフェースを管理するのに用いられるような、様々な他の機能性を表すこともある。
【００２６】
インターミディアリサーバ２３０は、他のコンポーネントの中でも特に、トンネルサービス２３２を含む。同様に、インターミディアリサーバ２４０もトンネルサービス２４２を含む。任意の適切な数のコンピューティングデバイス及び／又はインターミディアリサーバを用いることができる。図示及び説明される実施形態において、コンピューティングデバイス２０２、２２０は、以下で例が提供されるクライアントコンピューティングデバイスを表す。
【００２７】
コンピューティングデバイス２０２、２２０は、ネットワーク２５０を介して通信することができる、デスクトップコンピュータ、モバイルステーション、娯楽用機器、ディスプレイデバイスに通信可能に結合されるセットトップボックス、ワイヤレスフォン、ゲームコンソール等のようなコンピュータとして構成され得る。したがって、コンピューティングデバイス２０２、２２０は、十分なメモリとプロセッサリソースを有する完全なリソースデバイス（例えばパーソナルコンピュータ、ゲームコンソール）から、限られたメモリ及び／又は処理リソースを有する低リソースデバイス（例えば従来的なセットトップボックス、ハンドヘルドゲームコンソール）にまで及ぶことがある。
【００２８】
ネットワーク２５０はインターネットとして説明されるが、ネットワークは多様な構成を想定してもよい。例えばネットワーク２５０は、ワイドエリアネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、無線ネットワーク、公衆電話網、イントラネット等を含むか、そうでなくとも使用することができる。さらに、単一のネットワーク２５０が示されているが、ネットワーク２５０は複数のネットワークを含むように構成されてもよい。
【００２９】
動作に際して、以下でより詳細に説明されるように、様々な実施形態は、ブラウザ２１０、２２８のようなブラウザベースのクライアント（並びに他の非ブラウザベースのクライアント）等のウェブクライアントがウェブサービスを提供するのを可能にする。ブラウザ２１０、２２８は、サーバとして動作するように構成され、他の目的の中でも特に、ブラウザベースのクライアントによってサポートされるウェブサービスへの呼び出し及びそのウェブサービスからの呼び出しに使用され得る。そのような使用は、限定ではなく例として、あるブラウザから別のブラウザへメッセージをプッシュすることを含むことができる。様々な技術を用いて、標準のプロトコル及びライブラリを使用し、上記のようにブラウザ内へのいずれのカスタムコード又はプラグインのインストールも必要とせずに、例えばブラウザベースのチャットクライアントを実装することができる。
【００３０】
インターミディアリサーバ２３０、２４０は、インターミディアリとして機能し、ブラウザベースのクライアントが、それぞれのインターミディアリサーバとの持続接続を確立するのを可能にする。持続接続は、ここではそれぞれ２６０、２６２で表されている。上記のように、持続接続は、任意の適切な技法又は技術を使用して確立され得る。限定ではなく例として、そのような技法又は技術は、ＣＯＭＥＴ、ＷｅｂＳｏｃｋｅｔ（ウェブソケット）等を含む可能性がある。インターミディアリサーバは、ブラウザベースのクライアントを、例えばウェブサービスＵＲＬのようなウェブクライアントのプレゼンス又はアドレスを使用して、世界に公開することができる。メッセージを第１のブラウザベースのクライアントに送信しようとする他のウェブサービスクライアント（例えば別のブラウザベースのクライアント）は、公開されたウェブサービスＵＲＬを使用して、予め定義されたウェブサービスを呼び出すことができる。呼び出しを行うブラウザベースのクライアントは、同じインターミディアリサーバ又は異なるインターミディアリサーバのいずれかに登録して、そのウェブサービスＵＲＬを公開することもできる。第１のブラウザベースのクライアントは、その後、このＵＲＬを使用して、メッセージを第２のブラウザベースのクライアントにプッシュすることができる。
【００３１】
動作において、持続接続２６０、２６２は、それぞれのトンネルサービス２３２、２４２を使用して、ウェブブラウザ２１０、２２８のようなウェブクライアントからそれぞれのインターミディアリサーバへのトンネルを作成するために用いられる。持続接続を用いて、様々なエンティティからの要求を受信することができる。例えば持続接続を用いて、ブラウザベースのクライアントだけでなく、非ブラウザベースのクライアントが、他のブラウザ及び非ブラウザベースのクライアントを含む、他の呼び出し元からのウェブサービス要求を受信できるようにする。これはその後、ブラウザがソケットを開けて、サーバからの同期的要求を受信するか、非同期的要求に対する応答を処理するためにローカルでウェブブラウザを開始する場合に、何が起こるのかについてのエミュレーションを可能にする。
【００３２】
例として、以下を検討する。コンピューティングデバイス２０２は、インターミディアリサーバ２３０との持続接続２６０を確立することができる。ウェブブラウザ２１０は、持続接続２６０を介してインターミディアリサーバ２３０に登録することができる。同様に、コンピューティングデバイス２２０は、インターミディアリサーバ２４０との持続接続２６２を確立することができる。ウェブブラウザ２２８も同様に、持続接続２６２を介してインターミディアリサーバ２４０に登録することができる。ウェブブラウザ２１０がウェブブラウザ２２８と通信したいとき、ウェブブラウザ２１０は、ウェブブラウザ２２８に関連付けられたウェブサービスＵＲＬを取得する。これは、例えばインターミディアリサーバ２４０によって管理されるレジストリを通じて行うことができる。ブラウザ２１０は次いで、ウェブブラウザ２２８によって公開されるウェブサービスＵＲＬを使用してウェブサービスを呼び出して、データ又は他の情報をウェブブラウザ２２８に配信することができる。配信されるデータとともに、ウェブブラウザ２１０は、ウェブブラウザ２１０のウェブサービスＵＲＬもウェブブラウザ２２８に提供することができる。ウェブブラウザ２２８は次いで、ウェブブラウザ２１０のウェブサービスＵＲＬを使用して、データ及び他の情報をウェブブラウザ２１０に配信することができる。１つ又は複数の実施形態において、ウェブサービスＵＲＬは、それぞれインターミディアリサーバ２３０、２４０に関連付けられたアドレスである。ウェブサービスＵＲＬは、関連するブラウザの識別情報を含み、インターミディアリサーバが、それぞれのトンネルサービス２３２、２４２を通じて、ウェブサービス呼び出しの対象である、データを配信すべき場所を確定できるように構成される。トンネルサービスに対して行われる要求は、インターミディアリサーバとの標準のＴＣＰ接続を使用して行われることが可能である。インターミディアリサーバは、意図された受信者との持続接続を使用して、要求を、その受信者に配信することができる。意図された受信者からの応答は、通常のＴＣＰ接続を使用してインターミディアリサーバに返される。
【００３３】
図３は、１つ又は複数の実施形態に係る例示の環境３００を示す図である。環境３００は、ライブラリ３０４を有するウェブブラウザ３０２と、ライブラリ３０８を有するウェブブラウザ３０６と、トンネルサービス３１２を実装するインターミディアリサーバ３１０とを含む。この例において、２つのウェブブラウザ（すなわち、ウェブクライアント）はそれぞれ、１つ又は複数のウェブサービスを実装し、相互に通信することを望む。
【００３４】
図示及び説明される実施形態において、ウェブブラウザ３０２、３０６はそれぞれ、矢印で示されるようにインターミディアリサーバ３１０との持続接続を含む。持続接続を用いて、呼び出し元からのウェブサービス要求を、インターミディアリサーバを経由して受信することができる。任意の適切な技術を用いて持続接続を確立させることができる。加えて、ウェブブラウザの各々は、それぞれのトンネルＩＤを使用してインターミディアリサーバ３１０に登録される。
【００３５】
動作において、ウェブブラウザ３０２（及びウェブブラウザ３０６）は、標準のウェブプロトコルを用いて、ＨＴＴＰ要求の形式で呼び出しを発行する。この具体的な例において、ＨＴＴＰ要求は、以下の形式をとる。  
http://tunnel-endpoint/<tunnel-ID>/service/message
【００３６】
ウェブブラウザ３０２によって発行される呼び出しは、インターミディアリサーバ３１０に関連付けられており、かつインターミディアリサーバ３１０を識別するトンネルエンドポイント（「tunnel-endpoint」）と、ウェブブラウザ３０６に関連付けられるトンネルＩＤ（「tunnel-ID」）と、ウェブブラウザ３０６によって実装されるウェブサービス、及びウェブブラウザによって実装されるウェブサービスにより処理されるべきデータ若しくは情報を識別するペイロード（service/message）とを含む。
【００３７】
インターミディアリサーバ３１０及び該インターミディアリサーバのトンネルサービス３１２は次いで、呼び出しを、ウェブブラウザによって処理することができる標準のウェブ構造へ変換することによって、この呼び出しを処理する。例えばＨＴＴＰ要求は、メソッド、ＵＲＬ、本文及びヘッダを含む。これらを用いてJavaScript（登録商標）構造を構築する。このJavaScript構造は本質的に、キーと、上記のメソッド、ＵＲＬ、本文及びヘッダに対応するコンテンツとを有するディクショナリである。JavaScript構造は次いで、シリアル化され、ＪＳＯＮ（JavaScript  Object  Notation）使用してカプセル化されて、カプセル化された要求構造を提供する。カプセル化された要求構造は次いで、インターミディアリサーバ３１０によって、処理のためにウェブブラウザ３０６へ持続接続を使用して通信される。ウェブブラウザ３０６は、カプセル化された要求構造を受信すると、ライブラリ３０８を使用して、カプセル化された要求構造内で受信したデータ又は情報（すなわち「/service/message」）を含むイベントを、処理のためにウェブサービスに対して発火する。データ又は情報がウェブサービスによって処理されると、ウェブブラウザ３０６は、ペイロードを有するカプセル化された応答構造を含む応答を形成する。例えば応答構造は、ＪＡＳＯＮを使用してカプセル化される。カプセル化された応答構造は、インターミディアリサーバ３１０に送信される。カプセル化された応答構造は、標準のＴＣＰ接続を使用してインターミディアリサーバに送信され得る。インターミディアリサーバ３１０は次いで、カプセル化された応答構造を処理してＨＴＴＰ応答を形成し、該ＨＴＴＰ応答は、ウェブブラウザ３０２に通信される。ＨＴＴＰ応答は、ウェブブラウザ３０２によって通常の方法で処理され得る。
【００３８】
さらに、２つのウェブブラウザ３０２、３０６は、以下のフォーマットを使用して相互にＨＴＴＰ要求を行うことによって、互いに直接通信してもよい。  
http://tunnel-endpoint/<respective-tunnel-ID>
【００３９】
さらに、少なくとも一部の実施形態において、ウェブサービスが、サーバサイドのJavaScriptプログラミング言語及び実行環境であるNode.JSを使用して実装される場合は、当業者には認識されるように、単にトンネルエンドポイントのライブラリをサーバのインスタンス化ライブラリと置き換えることによって、同じコードが、サーバからいずれかのブラウザクライアントへ移動され得る。したがって、入来するウェブ要求の受け取りを登録する代わりに、Node.JS環境においてソフトウェアを実行させるイベントが生成されたように同じイベントを生成するトンネリングソフトウェアのクライアントサイドのJavaScript実装について登録を行うことができる。
【００４０】
図４は、全体的に４００として例示のシーケンスを図示しており、これは、外部のＨＴＴＰ要求が、どのようにＪＳＯＮへカプセル化されて、持続接続を介して、例えばウェブブラウザ等のクライアントへ送信されるかを示している。この例では、図示されていないが、認証が行われる。特に、認証は、トンネルサービスにおいてメッセージを送信するのを認証済みの呼び出し元に制限することによって実施されるか、又はクライアント（例えばブラウザ）自体において実施されることがあり、あるいはその双方で実施してもよい。
【００４１】
この例では、複数の動作が、呼び出し元、トンネルサービス及びクライアントを含むエンティティによって実行されるように図示されている。これらの動作はそれぞれ、丸で囲まれた数字で列挙されており、この数字は、下に条件付けされている。上記のように、呼び出し元は、限定ではなく例として、エンドユーザのコンピューティングデバイス、サーバ、該コンピューティングデバイス又はサーバ上で動作する適切に構成されたアプリケーション、ウェブブラウザ等を含め、任意の適切なエンティティを備えることができる。最初に、呼び出し元は“１”においてＨＴＴＰ要求を作成する。これは、必ずではないが、持続接続を介して行われる可能性がある。例えばＨＴＴＰ要求は、トンネルサービスとの通信を可能にするＴＣＰ接続で行われることも可能である。この例において、ＨＴＴＰ要求はＰＯＳＴであり、図面の下部に示される形式を有する。「connID」は、クライアントに登録されたトンネルＩＤに対応する。「myURL」は、ペイロードの一部である「service/message」に対応する。
【００４２】
トンネルサービスは、ＨＴＴＰ要求を受け取り、“２”において「connID」に合致する接続を選択する。トンネルサービスは、“３”において、ＨＴＴＰ要求をシリアル化して、これをＪＳＯＮ内にカプセル化する。シリアル化されてカプセル化された要求構造は、図面の下部に示されている。クライアントは、カプセル化された要求構造を持続接続により受信し、適切に構成されたライブラリを使用して、そのカプセル化された要求構造を処理し、そして情報及びデータを含む適切なイベントを発火して、クライアントによりサポートされるウェブサービスが、その情報及びデータを処理できるようにする。クライアントは、次いで、ＪＳＯＮ内にカプセル化した応答構造を準備して、“４”において、このカプセル化された応答構造をトンネルサービスへと返す。カプセル化された応答構造は、図面の下部に示されている。この応答は、標準のＴＣＰ接続を使用してトンネルサービスに送信され得る。
【００４３】
トンネルサービスは、その後、カプセル化された応答構造を処理してＨＴＴＰ応答を準備し、このＨＴＴＰ応答は、“５”において呼び出し元に送信される。ＨＴＴＰ応答の構造は、図面の下部に示されている。応答は、要求が満たされたことを示すＨＴＴＰステータスコード２００を、ウェブサービスにより呼び出し元の要求を処理した結果から得られる情報及びデータを含むペイロードとともに含む。応答は、呼び出し元によって、典型的なＨＴＴＰ要求として処理され得る。
【００４４】
上記の議論に加えて、追加の検討事項も考慮することができる。例として以下の事項を検討する。
【００４５】
＜他の検討事項＞
セキュリティの検討事項に関して、以下を検討する。１つ又は複数の実施形態において、機密性を促進させるため、呼び出し元とインターミディアリサーバの間及びインターミディアリサーバとクライアントの間の通信は、限定ではなく例として、トランスポートレイヤセキュリティ（ＴＬＳ）又はセキュアソケットレイヤ（ＳＳＬ）を用いるようなセキュアなトランスポート上で行われる。ＨＴＴＰ通信の場合はＨＴＴＰＳを用いることができる。さらに、確実にサービス要求が認証済みシステムに限定されるように、サービスアカウントを用いることができる。サービスアカウントはアカウントキーを用いることができる。この手法では、サービスの呼び出し元は、このキーを用いてＨＴＴＰ要求に署名をすることができ、したがって、その呼び出し元が実際にキーを所持していて、アカウントに関連付けられているという証明を容易にすることができる。この署名は、任意の適切な暗号化方法、例えばＨＭＡＣ（ハッシュベースのメッセージ認証コード：Hash-based  Message  Authentication  Code）を使用して実装され得る。そのような署名を、追加の認証ヘッダでＨＴＴＰ要求に添付することができる。この署名は、要求が受信されるとサービスによってチェックされ、チェックが成功すると、サービス要求が満たされ得る。
【００４６】
さらに、サービスの呼び出し元が、サーバではなくクライアントの場合、アカウントキーのセキュリティを保証するために、追加のプロビジョニングを用いることができる。クライアントでは典型的に、キーが、サーバ上で格納されるときのように安全に格納されるとは想定できない可能性がある。このために、一時的なアカウントキーを用いて、他のセキュリティ認証情報との交換でこれらのキーを取得するプロシージャと組み合わせることができる。そのようなキーは、例えば１日後又は所定の期間内に失効することより、限定的な有効性を有する可能性がある。さらに、サービスに接続するクライアントは、上述の一時キーと同じ技術を使用して、該クライアント自身を認証するよう求められる可能性もある。
【００４７】
さらに、セキュリティの観点から、トンネルサービスによって、認証済みのシステムが確実に自身のウェブサービス要求を任意の所与のクライアントにリレーさせるようにすることができる機構を用いることができる。これは、クライアント接続に割り当てられ、かつクライアントの個々のサービスＵＲＬに組み込まれる、ランダムな接続ＩＤを暗号化として使用することによって達成される。クライアントは、要求を送信したいと思うシステムのみにＵＲＬを与える。任意の他のシステムは、クライアントに割り当てられたサービスＵＲＬ／接続ＩＤを知らず、また予想することができないという単純な事実によって、要求を行うことができないであろう。
【００４８】
拡張性の観点から、以下のことを検討する。上記したように、呼び出し元は任意の適切なタイプのエンティティを備えることができる。例えば上記の議論では、ウェブブラウザを使用して、特定のウェブサービス又は他のウェブブラウザへの呼び出しを開始した。ここでは、オペレーティングシステム自体が、適切に構成されたインターミディアリサーバとの持続接続を保持することができるという状況を検討する。この例において、オペレーティングシステムは、その個々のリソースを、上述の技術を使用してアクセスすることができるＵＲＬとして公開することができる。例えばディスプレスクリーン上に現れる可能性がある個々のタイルを、個々のＵＲＬに関連付けることができる。個々のタイルに関連付けられるコンテンツは、サービスによって、プッシュモデルを使用して更新され得る。例えばオペレーティングシステムフェッチ、あるいは他の方法により積極的に更新を取得するのではなく、更新は、その関連付けられたＵＲＬにおけるオペレーティングシステムのリソースへプッシュされ得る。したがって、例えばあるタイルが更新されるべき場合、ウェブサービスは、タイルの関連付けられたＵＲＬを使用して、特定のタイルへトンネルされることになるＨＴＴＰ  ＰＯＳＴ要求を行うことができる。例えばコンピューティングシステムは、天気の更新に関連付けられたタイルを有することがある。天気の更新を取り出させるのではなく、上述の技術を使用して、そのような更新をタイルにプッシュすることができる。
【００４９】
別の例として、呼び出しサービスを検討する。呼び出しサービスを用いて、クライアントは、例えばＶＯＩＰ（Voice  over  Internet  Protocol）を使用して互いを呼び出すことができる。これらのシナリオにおいて、あるクライアントが、入来した呼び出しを有する場合、特別な呼び出しサーバを用いるのではなく、上述の技術を、ＨＴＴＰベースの呼び出しサーバとの接続に用いて、入来した呼び出し関連付けられるＨＴＴＰ要求をクライアントに直接送信することができ、これは、結果としてプッシュ呼び出し通知となる。
【００５０】
ウェブブラウザのシナリオに関して、以下を検討する。ＲＴＣ−Ｗｅｂ（Real-Time  Collaboration  on  the  World  Wide  Web）は、ウェブのユーザ間のリアルタイムのインタラクティブ通信を達成することができるウェブブラウザにおいて、標準化されたインフラストラクチャを達成しようとする取り組みである。ＲＴＣ−Ｗｅｂを使用して、ピアツーピアのオーディオ及びビデオメディアセッションをウェブブラウザ間で確立することができる。ＲＴＣ−Ｗｅｂを通じてブラウザ間で確立されたデータチャネルを使用して、ウェブブラウザによってサポートされるウェブサービスは、本明細書で説明される技術を用いて、インターミディアリサーバをバイパスして相互に通信することができる。この手法において、ウェブブラウザによって実装されるライブラリ機能は、互いに対してＨＴＴＰ呼び出しを行い、ウェブブラウザによってサポートされるウェブサービスにアクセスし、これを用いることができる。
【００５１】
さらに、上述の技術はスケーラビリティを非常に容易にする。例えばクライアント又は呼び出し元が拡大すると、トンネルサービスを提示するインターミディアリサーバを容易に追加して、そのような拡大に適応することができる。このタイプのスケーラビリティを使用して、ロードバランサに関連する処理のオーバヘッドを大いに低減することができる。特に、ロードバランサは典型的に、大きなシステムにおいて、呼び出しを向ける場所を確定するのに使用される。ロードバランサが、呼び出しに応答して、インターミディアリサーバとの接続を決定すると、その後は、その呼び出し元のためにロードバランシングを用いる必要はない。すなわち、いったん接続が確定されると、後続の呼び出しは、ロードバランサを使用する必要なく、インターミディアリサーバに対して直接行うことができる。
【００５２】
スケーラビリティに関して、以下を検討する。スケーラビリティはサポートされ、トンネルＵＲＬが構築される方法へと構築される。例えばトンネルＵＲＬは、次の形式を有することができる。  
http://trouterX.trouter.net/connectionID
【００５３】
ここで、trouterX.trouter.netは、持続接続をホストしているサーバの具体的なインスタンスのドメイン名である。これは、全てのサーバが、互いを見つけてウェブサービス要求を相互に委任するという必要性なしに、独立に動作するのを可能にする。正しいサーバを見つけるというジョブがインターネット（例えばＤＮＳ）に委ねられる。この実施形態において、システムは、サーバインスタンスの間で共有状態は有しない。これは、当業者には認識されるように、無限のスケーラビリティのための規定である。
【００５４】
これとは対照的に、代替的なアプローチでは、例えばＵＲＬが次のような形式をとることもある。  
http://alternativeservice.net/app-assigned-ID
【００５５】
このアプローチでは、要求は最初に、典型的に接続を有しないランダムサーバにルーティングされる。したがって、このランダムサーバは、接続のオーナーを見つけ、これに委任しなければいけない。状況は、アプリケーションによって選択されたトンネル／接続ＩＤによって悪化し、したがってサービスがルーティング情報をＵＲＬに組み込むのを防ぐ。これは、当業者に認識されるように、「app-assigned-ID」によってキー付けされる、ルーティング情報を保持する持続ストアの必要性につながる。
【００５６】
１つ又は複数の実施形態に係る例示のシーケンス図及び他の検討事項について検討したので、次に、１つ又は複数の実施形態に従って実装され得る例示のプロシージャの議論について検討する。
【００５７】
＜例示のプロシージャ＞
図５は、クライアントがウェブサービスを提供できるように、呼び出し元と、トンネルサービスと、クライアントとの間で行われる通信フローを示す。この通信フローは、上述のシステム及びデバイスを用いて実装され得る。プロシージャのそれぞれの態様は、ハードウェア、ファームウェア又はソフトウェアあるいはこれらの組み合わせで実装され得る。プロシージャは、１つ又は複数のデバイスによって実行される動作を指定するブロックのセットとして示されるが、それぞれのブロックによる動作を実行するために示される順序に必ずしも限定されない。
【００５８】
ブロック５０２において、呼び出し元は、適切に構成されたウェブクライアントによって提供されるウェブサービスに関連付けられるＨＴＴＰ要求を生成する。ＨＴＴＰ要求の例は、上記に提示されている。ブロック５０４において、ＨＴＴＰ要求をトンネルサービスに送信する。この要求は、標準のＴＣＰ接続を介して送信され得る。
【００５９】
ブロック５０６において、ＨＴＴＰ要求を受信し、ブロック５０８において、ＨＴＴＰ要求を処理してクライアントを識別する。これは、任意に適切な方法で行うことができ、その例は上記で提示されている。ブロック５１０において、ＨＴＴＰ要求をシリアル化して、ブロック５１２において、シリアル化されたＨＴＴＰ要求を要求構造内にカプセル化する。これは任意の適切な方法で行うことができる。少なくとも一部の実施形態において、シリアル化されたＨＴＴＰ要求は、上述のようにＪＳＯＮにカプセル化される。ブロック５１４において、カプセル化された要求構造をクライアントに送信する。１つ又は複数の実施形態において、カプセル化された要求構造は、トンネルサービスとクライアントとの間で維持される持続接続を介して送信される。
【００６０】
ブロック５１６において、クライアントにより、カプセル化された要求構造を受信する。ブロック５１８において、カプセル化された要求構造を、少なくとも部分的にウェブサービスを使用して処理する。ブロック５２０において、カプセル化された応答構造を準備する。このカプセル化された応答構造は、少なくとも、ウェブサービスの実行に関連付けられたデータ及び情報を含む。ブロック５２２において、カプセル化された応答構造をトンネルサービスに送信する。１つ又は複数の実施形態において、カプセル化された応答構造は、標準のＴＣＰ接続を介して送信され得る。
【００６１】
ブロック５２４において、トンネルサービスにより、カプセル化された応答構造を受信する。ブロック５２６において、カプセル化された応答構造を処理して、ＨＴＴＰ応答を呼び出し元に送信する。これをどのように行うことができるかについての例は、上記に提示されている。
【００６２】
ブロック５２８において、呼び出し元がＨＴＴＰ応答を受信し、ブロック５３０において、ＨＴＴＰ応答を処理する。これは、クライアントがウェブサービスを実行した結果としてＨＴＴＰ応答内に含まれる、データ及び情報を処理することを含むことができる。
【００６３】
１つ又は複数の実施形態に係る例示のプロシージャを説明したので、次に、上述の実施形態を実装するのに用いることができる例示のシステム及びデバイスについて検討する。
【００６４】
＜例示のシステム及びデバイス＞
図６は、全体的に６００として例示のシステムを図示している。このシステムは、本明細書で説明される様々な技術を実装することができる１つ又は複数のコンピューティングシステム及び／又はデバイスを表す、例示のコンピューティングデバイス６０２を含む。コンピューティングデバイス６０２は、例えばサービスプロバイタのサーバ、クライアント（例えばクライアントデバイス）に関連付けられたデバイス、オンチップシステム及び／又は任意の他の適切なコンピューティングデバイス若しくはコンピュータシステムとすることができる。
【００６５】
図示されるように、例示のコンピューティングデバイス６０２は、相互に通信可能に接続される処理システム６０４と、１つ又は複数のコンピュータ読取可能媒体６０６と、１つ又は複数のＩ／Ｏインタフェース６０８とを含む。図示されていないが、コンピューティングデバイス６０２は更に、様々なコンポーネントを相互に結合するシステムバスあるいは他のデータ及びコマンド転送システムを含んでもよい。システムバスは、メモリバス若しくはメモリコントローラ、周辺バス、ユニバーサルシリアルバス及び／又は様々なバスアーキテクチャのいずれかを使用するプロセッサ若しくはローカルバスのような、異なるバス構造のうちのいずれか１つ又は組み合わせを含むことができる。制御及びデータ回線のような様々な他の例も考えられる。
【００６６】
処理システム６０４は、ハードウェアを使用して１つ又は複数の動作を実行する機能性を表す。したがって、処理システム６０４は、プロセッサ、機能ブロック等として構成され得るハードウェア要素６１０を含むように図示されている。これは、特定用途向け集積回路あるいは１つ又は複数の半導体を使用して形成される他の論理デバイスとして、ハードウェアでの実装を含むことがある。ハードウェア要素６１０は、これらが形成される材料や用いられる処理機構に制限されない。例えばプロセッサは、半導体及び／又はトランジスタ（例えば電子集積回路（ＩＣ））から構成されることがある。そのようなコンテキストにおいて、プロセッサ実行可能命令は、電子的に実行可能な命令であってよい。
【００６７】
コンピュータ読取可能記憶媒体６０６は、メモリ／ストレージ６１２を含むように図示されている。メモリ／ストレージ６１２は、１つ又は複数のコンピュータ読取可能媒体に関連付けられたメモリ／記憶機能を表す。メモリ／ストレージコンポーネント６１２は、揮発性媒体（ランダムアクセスメモリ（ＲＡＭ）等）及び／又は非揮発性媒体（読取専用メモリ（ＲＯＭ）、フラッシュメモリ、光ディスク、磁気ディスク等）を含むことができる。メモリ／ストレージコンポーネント６１２は、固定の媒体（例えばＲＡＭ、ＲＯＭ、固定のハードドライブ等）並びに取外し可能媒体（例えばフラッシュメモリ、取外し可能ハードドライブ、光ディスク等）を含むことができる。コンピュータ読取可能媒体６０６は、以下で更に説明されるように様々な他の方法で構成されてもよい。
【００６８】
入出力（Ｉ／Ｏ）インタフェース６０８は、ユーザがコマンド及び情報をコンピューティングデバイス６０２に入力するのを可能にし、また様々な入出力デバイスを使用して、情報をユーザ及び／又は他のコンポーネント若しくはデバイスに提示することを可能にする機能性を表す。入力デバイスの例には、キーボード、カーソル制御デバイス（例えばマウス）、マイク、スキャナ、タッチ機能（例えば物理的な接触を検出するように構成される容量式センサ又は他のセンサ）、カメラ（例えば赤外線周波数のような可視又は非可視の波長を用いて、接触を伴わない動きをジェスチャとして認識し得るもの）等が含まれる。出力デバイスの例には、ディスプレイデバイス（例えばモニタ又はプロジェクタ）、スピーカ、プリンタ、ネットワークカード、触覚応答デバイス等が含まれる。したがって、コンピューティングデバイス６０２は、以下で更に説明されるように、ユーザ対話をサポートするように様々な方法で構成され得る。
【００６９】
コンピューティングデバイス６０２は、本明細書で説明される技術を使用して提示することができ、様々な呼び出し元によって用いることができる、１つ又は複数のウェブサービス６１３も含む。
【００７０】
本明細書では、様々な技術がソフトウェア、ハードウェア要素又はプログラムモジュールの一般的なコンテキストにおいて説明され得る。一般に、そのようなモジュールは、特定のタスクを実行するか特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、要素、コンポーネント、データ構造等を含む。本明細書で使用されるとき、「モジュール」、「機能（性）」及び「コンポーネント」という用語は、一般的に、ソフトウェア、ファームウェア、ハードウェア又はこれらの組み合わせを表す。本明細書で説明される技術の特徴はプラットフォーム独立であるが、これは、本技術が、様々なプロセッサを有する様々な市販のコンピューティングプラットフォームにおいて実装され得ることを意味する。
【００７１】
説明されるモジュール及び技術の実装は、何らかの形式のコンピュータ読取可能媒体に格納されるか、そのコンピュータ読取可能媒体によって伝送され得る。コンピュータ読取可能媒体は、コンピューティングデバイス６０２によってアクセスされ得る様々な媒体を含み得る。限定ではなく例として、コンピュータ読取可能媒体は、「コンピュータ読取可能記憶媒体」と「コンピュータ読取可能信号媒体」とを含むことがある。
【００７２】
「コンピュータ読取可能記憶媒体」は、単なる信号伝送や、搬送波又は信号自体等とは対照的に、情報の持続的及び／又は非一時的な記憶を可能にする媒体及び／又はデバイスを指すことができる。したがって、コンピュータ読取可能記憶媒体は、非信号担持媒体を指す。コンピュータ読取可能媒体は、コンピュータ読取可能命令、データ構造、プログラムモジュール、ロジック要素／回路又は他のデータのような情報の記憶に適した方法又は技術で実装される、揮発性及び非揮発性、取外し可能及び取外し不可能の媒体及び／又はストレージデバイスのようなハードウェアを含む。コンピュータ読取可能記憶媒体の例には、これらに限られないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ若しくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）若しくは他の光ストレージ、ハードディスク、磁気カセット、磁気テープ、磁気ディスクストレージ若しくは他の磁気ストレージデバイス、あるいは所望の情報を格納するのに適切であって、コンピュータによってアクセス可能な他の記憶デバイス、有形の媒体又は製品が含まれる。
【００７３】
「コンピュータ読取可能信号媒体」は、命令を、ネットワークを介するなどしてコンピューティングデバイス６０２のハードウェアに伝送するように構成される信号担持媒体を指すことがある。信号媒体は典型的に、コンピュータ読取可能命令、データ構造、プログラムモジュール又は他のデータを、搬送波、データ信号又は他の伝送機構のような変調データ信号に具現化することができる。信号媒体は、任意の情報配信媒体も含む。「変調データ信号」という用語は、情報を信号にエンコードするような方法で設定又は変更された特性の１つ又は複数を有する信号を意味する。限定ではなく例として、通信媒体は、有線ネットワーク又は直接有線接続のような有線媒体と、音響、ＲＦ、赤外線及び他の無線媒体のような無線媒体とを含む。
【００７４】
上述のように、ハードウェア要素６１０及びコンピュータ読取可能媒体６０６は、一部の実施形態において、１つ又は複数の命令を実行するような、説明される技術の少なくとも一部の態様を実装するのに用いられるハードウェア形式で実装されるモジュール、プログラマブルデバイスロジック及び／又は固定のデバイスロジックを表す。ハードウェアは、集積回路若しくはオンチップシステム、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、結合プログラム可能論理回路（ＣＰＬＤ）及びシリコンでの他の実装や他のハードウェアが含まれる。このコンテキストにおいて、ハードウェアは、命令によって定義されるプログラムタスク及び／又はハードウェアによって具現化されるロジックを実行する処理デバイス、並びに実行のために命令を格納するのに用いられるハードウェア、例えば前述したコンピュータ読取可能記憶媒体として動作してもよい。
【００７５】
上述の組み合わせを用いて、本明細書で説明される様々な技術を実装することもできる。したがって、ソフトウェア、ハードウェア又は実行可能モジュールを、何らかの形式のコンピュータ読取可能記憶媒体において及び／又は１つ又は複数のハードウェア要素６１０によって具現化される１つ又は複数の命令及び／又はロジックとして実装してもよい。コンピューティングデバイス６０２は、ソフトウェア及び／又はハードウェアモジュールに対応する特定の命令及び／又は機能を実装するように構成され得る。したがって、コンピューティングデバイス６０２によって実行可能なモジュールのソフトウェアとしての実装は、少なくとも部分的にハードウェアで、例えばコンピュータ読取可能記憶媒体及び／又は処理システム６０４のハードウェア要素６１０の使用を通して達成され得る。命令及び／又は機能は、本明細書で説明される技術、モジュール及び実施例を実装するよう１つ又は複数の製品（例えば１つ又は複数のコンピューティングデバイス６０２及び／又は処理システム６０４）によって実行可能／動作可能である。
【００７６】
図６に更に図示されるように、例示システム６００は、アプリケーションをパーソナルコンピュータ（ＰＣ）、テレビジョンデバイス及び／又はモバイルデバイス上で実行するときに、シームレスなユーザ経験のためのユビキタス環境を可能にする。サービス及びアプリケーションは実質的に、アプリケーションを使用している間、ビデオゲームをプレイしている間、ビデオを観ている間等に、あるデバイスから次のデバイスに遷移する際に、共通のユーザ経験のために３つの全ての環境において同様に動作する。
【００７７】
例示システム６００において、複数のデバイスは中央コンピューティングデバイスを通して相互接続される。中央コンピューティングデバイスは、複数のデバイスにローカルであってもよく、複数のデバイスからリモートに配置されてもよい。一実施形態において、中央コンピューティングデバイスは、複数のデバイスにネットワーク、インターネット又は他のデータ通信リンクを通して接続される、１つ又は複数のサーバコンピュータのクラウドとすることができる。
【００７８】
一実施形態において、この相互接続アーキテクチャは、複数のデバイスにまたがって配信され、複数のデバイスのユーザに共通でシームレスな経験を提供するのを可能にする。複数のデバイスの各々は、異なる物理的要件及び能力を有し、中央コンピューティングデバイスは、プラットフォームを使用して、デバイスへの経験の配信を可能にするが、この経験は、そのデバイスに対して調整されるが、全てのデバイスに対して共通でもある。一実施形態において、ターゲットデバイスのクラスを作成し、経験をデバイスの汎用クラスに対して調整する。デバイスのクラスを、物理的な特徴、利用のタイプ又はデバイスの他の共通の特性によって定義してもよい。
【００７９】
様々な実装において、コンピューティングデバイス６０２は、コンピュータ６１４用、モバイル６１６用、テレビジョン６１８用及び組み込みデバイス６１９用の使用のような様々な異なる構成を想定してもよい。これらの構成の各々は、一般に異なる構成及び能力を有することがあるデバイスを含み、したがって、コンピューティングデバイス６０２は異なるデバイスクラスの１つ又は複数に従って構成され得る。例えばコンピューティングデバイス６０２は、パーソナルコンピュータ、デスクトップコンピュータ、マルチスクリーンコンピュータ、ラップトップコンピュータ、ネットブック等を含むデバイスのコンピュータ６１４クラスとして実装され得る。
【００８０】
コンピューティングデバイス６０２は、モバイルフォン、ポータブル音楽プレイヤ、ポータブルゲームデバイス、タブレットコンピュータ、マルチスクリーンコンピュータ等のモバイルデバイスを含むデバイスのモバイル６１６クラスとして実装されてもよい。コンピューティングデバイス６０２は、簡潔な視聴環境において一般的に大きなスクリーンを有するか、これと接続されるデバイスを含むテレビジョン６１８クラスとして実装されてもよい。これらのデバイスは、テレビジョン、セットトップボックス、ゲームコンソール等を含む。
【００８１】
コンピューティングデバイス６０２は、デバイスの組み込みシステム又は組み込みクラス６１９として実装されることもある。組み込みデバイスは典型的に、特定の制御機能のために設計される。したがって、組み込みデバイスは典型的に、特定のタスクの処理の専用であり得る。組み込みデバイスは、デジタル時計、メディアプレイヤ、ライトのスイッチ、信号機、工場のコントローラ、電話交換、様々な他のタイプの消費者用電化製品、ＧＰＳ受信機、プリンタ、電子レンジや洗濯機、食洗機のような家事用機器、ネットワーク化されたサーモスタットを含むＨＶＡＣシステム、有線又は無線のネットワークを使用するホームオートメーションデバイスのようなものから、ライト、気候、セキュリティ、オーディオ／ビジュアル、監視等のようなものの制御に至るまで、多岐にわたる可能性がある。他の組み込みデバイスが、交通システム、様々なタイプのモーター、バイタルサインのモニタリングや医療画像化等のようなもののための医療機器等に使用されることもあり得る。
【００８２】
本明細書で説明される技術は、コンピューティングデバイス６０２のこれらの様々な構成によってサポートされ、本明細書で説明される技術の特定の実施例に限定されない。この機能性は、下述されるように、分散システムの使用を通して、プラットフォーム６２２を介して「クラウド」６２０上に、全て又は部分的に実装され得る。
【００８３】
クラウド６２０は、リソース６２４のためのプラットフォーム６２２を含むか、及び／又はこれを表す。プラットフォーム６２２は、クラウド６２０のハードウェア（例えばサーバ）及びソフトウェアリソースの機能を抽象化する。リソース６２４は、コンピューティングデバイス６０２からリモートのサーバ上でコンピュータ処理が実行している間に用いることができるアプリケーション及び／又はデータを含み得る。リソース６２４は、ウェブサービスのような、インターネット上で及び／又はセルラ若しくはＷｉ−Ｆｉ（登録商標）ネットワークのような加入者ネットワークを通して提供されるサービスを含むこともできる。
【００８４】
プラットフォーム６２２は、コンピューティングデバイス６０２を他のコンピューティシングデバイスに接続するリソース及び機能を抽出する。プラットフォーム６２２は、リソースのスケーリングを抽象化して、スケールの対応するレベルを、プラットフォーム６２２を介して実装されるリソース６２４について生じた要求に提供するように機能することもある。したがって、相互接続されるデバイスの実施形態において、本明細書で説明される機能性の実装をシステム６００にわたって分散してもよい。例えば機能性は、部分的にコンピューティングデバイス６０２内に実装されてもよく、クラウド６２０の機能性を抽象化するプラットフォーム６２２を介して実装されてもよい。
【００８５】
様々な実施形態は、ウェブクライアントがウェブサービスを提供できるようにする。１つ又は複数の実施形態において、ウェブクライアントは、サーバとして動作し、他の目的の中でも特に、ウェブクライアントによってサポートされるウェブサービスへの呼び出し及びそのウェブサービスからの呼び出しに使用することができる。そのような使用は、限定ではなく例として、ウェブクライアントへ及びウェブクライアントからメッセージをプッシュすることを含むことができる。様々な技術は、標準のプロトコル及びライブラリを用いることができ、いずれのカスタムコード又はカスタムプラグインも必要としない。
【００８６】
１つ又は複数の実施形態において、中間サーバが、ウェブクライアントとの持続接続が確立されるインターミディアリとして機能する。インターミディアリサーバは、ウェブクライアントを、例えばウェブサービスＵＲＬのようなウェブクライアントのプレゼンス又はアドレスを使用して、世界に公開することができる。メッセージを第１のウェブクライアントに送信しようとする他のウェブクライアント（例えばブラウザベースのクライアント）は、公開されたウェブサービスＵＲＬを使用して、予め定義されたウェブサービスを呼び出すことができる。呼び出しを行うウェブクライアントは、同じインターミディアリサーバ又は異なるインターミディアリサーバのいずれかに登録して、そのウェブサービスＵＲＬを公開することもできる。第１のウェブクライアントはその後、このＵＲＬを使用して、メッセージを第２のウェブクライアントにプッシュすることができる。
【００８７】
様々な実施形態を構造的特徴及び／又は方法的動作に特有の言語で説明してきたが、添付の特許請求の範囲において定義される実施形態は、必ずしも説明される具体的な特徴又は動作に限定されない。むしろ、具体的な特徴及び動作は、様々な特許請求に係る実施形態を実装するための例示の形式として開示される。
【図１】
2015520436.tif 000003
【図２】
2015520436.tif 000004
【図３】
2015520436.tif 000005
【図４】
2015520436.tif 000006
【図５】
2015520436.tif 000007
【図６】
2015520436.tif 000008
【国際調査報告】
2015520436.tif 000009
2015520436.tif 000010