JP2022538200A - 仮想ワークスペース環境におけるクライアントデバイス間のリソース共有 - Google Patents

Abstract

仮想コンピューティング環境においてクライアントデバイス間でリソースを共有するためのシステムおよび方法。他のクライアントデバイスにローカルに接続され、仮想コンピューティング環境内の企業サービスを介して第１クライアントデバイスに利用できない利用可能なリソースのリストに対する第１クライアントデバイスからの要求を受信し、第１クライアントデバイスに利用可能なリソースのリストを提供し、第１クライアントデバイスから利用可能なリソースのリスト内に含まれるリソースの選択を受信し、選択されたリソースとの接続を確立するために、選択されたリソースに接続された第２クライアントデバイスにプッシュ通知を提供し、確立された接続を介して、第１クライアントデバイスに選択されたリソースへのアクセスを提供する方法を開示する。

Description

本開示の態様は、仮想コンピューティング環境におけるクライアントデバイス間でローカルに接続されたリソースを共有するためのシステムおよび方法を提供する。

通常、クラウドシステム、仮想ネットワーク、サーバ等を介して展開されるエンタープライズコンピューティングプラットフォームは、ユーザがクライアントデバイスからネットワークを介してサービスおよび機能を利用し、共有することを可能にする。例えば、仮想ワークスペース環境では、ユーザはクライアントデバイスに表示されるが、実際にはサーバ上の別の場所で実行されている仮想ワークスペースとやりとりできる。

本開示の第１の態様は、仮想コンピューティング環境においてリソースを共有するためのコンピューティングデバイスを用いて実施される方法を提供する。本方法は、コンピューティングシステムによって、第１クライアントデバイスからの要求を受信することを含み、この要求は、利用可能なリソースのリストであり、利用可能なリソースのリストは、少なくとも１つの他のクライアントデバイスにローカルに接続され、仮想コンピューティング環境内のエンタープライズサービスを介して第１クライアントデバイスに利用できないリソースを含む。この方法は、さらに、コンピューティングシステムによって、利用可能なリソースのリストを第１クライアントデバイスに提供し、利用可能なリソースの少なくとも１つの識別子（ＩＤ）およびメタデータを含む利用可能なリソースのリストを提供することを含む。さらに、この方法は、コンピューティングシステムによって、第１クライアントデバイスから利用可能なリソースのリスト内に含まれるリソースの選択を受信することと、選択されたリソースとの接続を確立するために、選択されたリソースに接続された第２クライアントデバイスにプッシュ通知をコンピューティングシステムによって提供することとを含む。

本開示の第２の態様は、仮想コンピューティング環境内のリソースの共有を提供するコンピューティングデバイスを提供する。デバイスは、プロセスを実装するように構成されたメモリと、メモリに接続されたプロセッサとを含む。このプロセスは、リソースセットに関連する情報を記憶することを含み、この情報は、リソースセット内の各リソースに対する識別子（ＩＤ）およびメタデータを含み、各リソースは、クライアントデバイスにローカルに接続され、各リソースは、仮想コンピューティング環境内のエンタープライズサービスを介して、他のクライアントデバイスに利用できない。このプロセスは、第１クライアントデバイスから、利用可能なリソースのリストの要求を受信することと、第１クライアントデバイスに利用可能なリソースのリストを提供することと、利用可能なリソースの各々のＩＤおよびメタデータを含む利用可能なリソースのリストを受信することと、利用可能なリソースのリストから選択されたリソースを第１クライアントデバイスから受信することとをさらに含み、選択されたリソースは第２クライアントデバイスに接続される。プロセスは、選択されたリソースとの接続を確立するために、第２クライアントデバイスに通知をプッシュすることをさらに含む。

本開示の例示的な態様は、本明細書で説明される問題および／または説明されない他の問題を解決するように設計される。

例示的な実施形態による仮想コンピューティング環境を示す。 例示的な実施形態による、仮想コンピューティング環境内でリソースを登録および登録解除するための図を示す。 例示的な実施形態による、仮想コンピューティング環境内のリソースにリモートでアクセスするための図を示す。 例示的な実施形態によるリソース共有アーキテクチャを示す。 例示的な実施形態による代替リソース共有アーキテクチャを示す。 例示的な実施形態による、デバイス共有およびプッシュ通知プロセスの流れ図を示す。 例示的な実施形態による、デバイス共有およびプッシュ通知プロセスの流れ図を示す。 例示的な実施形態によるネットワークアーキテクチャを示す。 例示的な実施形態によるクラウドシステムを示す。 例示的な実施形態によるコンピューティングシステムを示す。

本開示のこれらおよび他の特徴は、本開示の様々な実施形態を描写する添付の図面と併せてなされる、本開示の様々な態様の以下の詳細な説明から、より容易に理解される。

図面は、本開示の典型的な態様のみを描写することを意図しており、したがって、本開示の範囲を限定するものと見なされるべきではない。

本開示の実施形態は、リソースサーバを利用せずに、仮想コンピューティング環境において、クライアントデバイスに接続されたローカルリソースを他のクライアントデバイスと共有するための技術的解決策を提供する。従来、クライアントデバイス間でのプリンタなどのリソースの共有は、プリンタが、ユニバーサルプリントサーバ（ＵＰＳ）、複合デスクトップデリバリコントローラ（ＤＤＣ）および／または他のポリシーなどのエンタープライズサービスによって管理されることを必要とした。したがって、クライアントデバイスにローカルに（例えば、直接）接続されたプリンタ、ファックスなどのリソースを、そのリソースがエンタープライズサービスによって管理されていない限り、共有することはできなかった。リソースには、クライアントデバイスに接続されている仮想デスクトップエージェント（ＶＤＡ）セッションからクライアントデバイスを介して、またはローカルでアクセスできた。

本実施形態は、クライアントデバイスセットにローカルに接続されているリソースを、ワークスペース（ＷＳ）リソースサーバ（例えば、クラウドに配置されている）に登録するための方法論を提供する。また、ＷＳリソースサーバは、クライアントデバイスのユーザから現在利用可能なリソースのリストに対する要求を受信するように設定されている。その後、第１クライアント上のローカルに接続されたリソースと第２クライアントとの間で接続を確立できる。各クライアントには、仮想デスクトップエージェント（ＶＤＡ）セッション、ＷｅｂＳｏｃｋｅｔ接続などを介して、ＷＳリソースサービスとのインターフェイスを管理できるクライアント側（ＣＳ）サービスが含まれている。

本開示の目的のために、「ローカルリソース」は、一般に、ネットワークベースのリソースを含む、クライアントデバイスによってまたはクライアントデバイスから容易にアクセス可能であるが、認証子、ゲートウェイ、ワークスペースアプリケーション、レガシーユニバーサルプリントサーバなどの従来のエンタープライズサービスなしではアクセスできない任意のリソースを含む。ローカルリソースは、ＵＳＢ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉｆｉなどの接続を使用してクライアントデバイスに接続できる。

図１は、例示的な実施形態による仮想コンピューティング環境を有するコンピューティングインフラストラクチャ１００を示す。この場合、ＭＳ Ｗｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ（登録商標）等を実行するサーバデスクトップ１０４は、クライアントデバイスセット（例えば、ラップトップ、スマートデバイスなど）のためにサーバデスクトップ１０４へのリモート仮想アクセスを提供する仮想デスクトップエージェント（ＶＤＡ）１２２セットを含む。サーバデスクトップ１０４は、例えば、オンプレミスシステムとして、またはクラウド１０２を介して実装することができる。図示の例では、サーバデスクトップ１０４は、オンプレミスシステムとして実装され、ワークスペースリソースサーバ１１０へのアクセスを提供するクラウドコネクタ１２０および配信コントローラ１１８を介してクラウド１０２とやりとりする。

図の例では、２つのクライアントデバイス１０６、１０８が、サーバデスクトップ１０４に遠隔的にアクセスするように構成されている。第１クライアントデバイス１０６は、クライアント側（ＣＳ）リソースサービス１３４を実行するワークスペース（ＷＳ）アプリケーション１３０（例えば、米国フロリダ州フォート、ラウダーデールのＣｉｔｒｉｘ Ｓｙｓｔｅｍｓから市販されているＣｉｔｒｉｘ（登録商標）ワークスペースによって提供される）を含み、ＶＤＡセッション１２８を介してサーバデスクトップ１０４に接続される。同様に、第２クライアントデバイス１０８は、ＣＳリソースサービス１３８を実行するＷＳアプリケーション１４０を含み、ＶＤＡセッション１４２を介してサーバデスクトップ１０４に接続される。

この場合、プリンタ、スキャナ、ファックス、周辺機器などのリソース１２４は、エンタープライズサービスを使用せずに、例えばユニバーサルシリアルバス（ＵＳＢ）接続を介してクライアントデバイス１０６に接続されている。過去の実装では、リソース１２４は、ローカルクライアントデバイス１０６を介してのみ利用可能であり、すなわち、リモートクライアントデバイス１０８のユーザは、プリントサーバのようなエンタープライズサービスがなければ、リソース１２４にアクセスできない。本アプローチは、第２クライアントデバイス１０８が、（１）クライアントデバイス１０６、１０８にそれぞれインストールされたクライアント側（ＣＳ）リソースサービス１３４、１３８、および（２）クラウド１０２に実装されたＷＳリソースサーバ１１０の使用により、第１クライアントデバイス１０６上のリソース１２４にアクセスすることを可能にする。いくつかの実施形態では、クライアント側（ＣＳ）リソースサービス１３４、１３８は、それぞれワークスペース（ＷＳ）アプリケーション１３０、１４０の一部としてインストールすることができる。

例示的な一実施形態では、ＷＳリソースサーバ１１０は、Ｃｉｔｒｉｘ ＨＤＸ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｅｘｐｅｒｉｅｎｃｅ）プロトコルなどの仮想チャネルインフラストラクチャを介して、フルまたはライトウェイトヘッドレスセッションのいずれかでＣＳリソースサービス１３４、１３８と通信する。ヘッドレスセッションは、ユーザが直接開始することなく、ユーザが見ることができるアーティファクトなしに、バックグラウンド動作として自動的かつ静かに確立されるＩＣＡ（Ｃｉｔｒｉｘ Ｉｎｄｅｐｅｎｄｅｎｔ Ｃｏｍｐｕｔｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）などのプロトコルを利用する。このようなインフラストラクチャは、クライアントデバイス上でワークスペースの仮想バージョンをレンダリングし、例えば、（１）画面アクティビティ、アプリケーションコマンド、エンドポイントデバイス、およびネットワークとサーバの機能を調べて、アプリケーションまたはデスクトップアクティビティをレンダリングする方法と場所をすぐに決定し、（２）データ圧縮を提供し、（３）データ重複排除などのテクニックを使用してネットワークトラフィックを最適化できる。軽量ヘッドレスセッションでは、セッションは、例えば、グラフィカルユーザインターフェイスや、リソース１２４の使用に必要ではないオーディオ、マルチメディア、クライアントドライブマッピング、クリップボードマッピングなどの追加の仮想チャネルをレンダリングせずに実行される。

ＣＳリソースサービス１３４、１３８は、例えば、ＨＤＸ ＶＤＡセッション、ヘッドレスＶＤＡセッション、または何らかの他のプロトコルを使用して、アクティブセッションを介して、関連するＷＳアプリケーション１３０、１４０を使用してＷＳリソースサーバ１１０と通信する。ＣＳリソースサービス１３４、１３８によって実行される例示的な機能は、リソース１２４のクラウド１０２への登録を実行するために、リソース１２４およびＷＳリソースサーバ１１０への転送デバイスメタデータによって生成される、リソース接続および切断イベント、例えば、「プラグアンドプレイ」イベントの捕捉を含む。ＣＳリソースサービス１３４、１３８はまた、ユーザが、他のユーザまたはデバイスにリソース１２４へのアクセスを許可するアクセス権を設定することを可能にする。これらの権利は、次に、ＷＳリソースサーバ１１０またはアクセス制御を管理する別のサーバのいずれかに転送される。ＣＳリソースサービス１３４、１３８は、列挙要求をＷＳリソースサーバ１１０に送信して、ユーザが利用可能なすべてのリソースおよび関連するリソース詳細をリストすることもできる。ＣＳリソースサービス１３４、１３８は、さらに、任意の着信要求をリッスンして、遠隔クライアントデバイスからローカルに接続されたリソース１２４にアクセスし、ＷＳリソースサーバ１１０からの要求者のアクセス権を認証およびチェックした後に、要求者へのアクセスを許可することができる。

一実施形態では、新しいリソース１２４がクライアントデバイス１０６に接続されると、ＷＳリソースサーバ１１０は、新しいクライアント側リソース１２４を、例えば、リソースデータベース（ＤＢ）１１２に登録する。一実施形態では、新しいリソース１２４が接続されると、ＷＳリソースサーバ１１０は、リソースメタデータを受信し、リソースＩＤを生成する。ＷＳリソースサーバ１１０は、関連するリソースメタデータを含むリソースＩＤのリストをリソースＤＢ１１２に保持する。

ユーザ要求に応答して、ＷＳリソースサーバ１１０は、そのユーザのアクセス権を検証した後、ユーザが利用可能なすべてのクライアント側リソース１２４のリストを生成する。ＷＳリソースサーバ１１０は、例えば、ＭｉｃｒｏｓｏｆｔによるＡｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙのようなディレクトリサービスを使用して、許可ポリシーに基づいてユーザを認証し、ユーザを許可するために、ＷＳリソースサーバ１１０の一部であってもなくてもよい認証サービス１１４に連絡してもよい。一旦生成されると、ＷＳリソースサーバ１１０は、リソースメタデータを要求側ＣＳリソースサービス１３８に共有する。メタデータには、例えば、リソースタイプ、名前、モデル、ドライババージョン、Ｗｉｎｄｏｗｓでは｛Ｃｌａｓｓ ＧＵＩＤ、インスタンスＧＵＩＤ｝、ＬＩＮＵＸでは｛Ｐｒｏｄｕｃｔ ＩＤ、Ｐｒｏｄｕｃｔ Ｖｅｒｓｉｏｎ｝、デバイスＭａｃアドレス、クライアント名などがある。一部の実施形態では、ユーザ要求は、ＶＤＡセッション、例えばＶＤＡセッション１４２内でトリガすることができる。他の実施形態では、ユーザ要求は、クライアントデバイス、例えば、クライアントデバイス１０８のＷＳアプリケーション１４０からトリガされ、ＶＤＡセッション１４２を介してＷＳリソースサーバ１１０に中継されることができる。

図２は、図１を参照して、例示的なリソース登録プロセス２００および例示的なリソース切断プロセス２０２を示す流れ図を示す。図１は、リソース登録プロセス２００の間に、ユーザがリソース１２４をクライアントデバイス１０６に接続し、これにより、リソース１２４は、「プラグアンドプレイ」イベントのようなイベントを生成し、その後、ＷＳアプリケーション１３０上で実行されるＣＳリソースサービス１３４によって処理される。次いで、イベントは、アクティブなフルまたはヘッドレスＨＤＸ ＶＤＡセッション１２８を使用して、仮想チャネルを介して、例えば、ＨＤＸを介して通信される。次に、ＷＳアプリケーション１３０は、クラウドコネクタ１２０を介してＷＳリソースサーバ１１０に登録呼び出しを行う。また、ＷＳアプリケーション１３０は、要求と共にリソースメタデータを送信する。

例示的な実施形態では、デバイスが検出されると、登録プロセス中に、ＣＳリソースサービス１３４は、例えば、インタフェースコールＧＵＩＤ、ハンドル、タイプ、名前、モデル、製品ＩＤ、製品バージョン、ドライバ情報、ＩＰアドレスなどを含み得るリソースメタデータ（すなわち、デバイス情報）をＷＳリソースサーバ１１０に送信する。次に、ＷＳリソースサーバ１１０は、後続のイベントに使用されるＣＳリソースサービス１３４にリソースＩＤを送り返す。

したがって、ＷＳリソースサーバ１１０は、受信された要求に応答して、リソースメタデータを検証し（例えば、重複のチェックなど）、これは、リソースタイプ、リソースドライバ、リソースＩＰアドレス（内部／外部）などを評価することができる。次に、ＷＳリソースサーバ１１０は、リソースＩＤを生成し、リソースメタデータにリソースＩＤを割り当て、リソース１２４を追跡するＷＳアプリケーション１３０およびＣＳリソースサービス１３４に送信する。

リソース切断プロセス２０２の間、例えば、リソース１２４は、クライアントデバイス１０６からアンプラグされ、例えば、「プラグアンドプレイ」切断イベントが生成される。ＷＳアプリケーション１３０上で実行されるＣＳリソースサービス１３４は、イベントを捕捉し、リソースＩＤと共にＷＳリソースサーバ１１０に要求を転送して、リソースデータベース１１２内でリソースを非アクティブとしてマークする。

図３は、図１を参照して、例示的なリソースアクセスプロセスを示す。この例では、クライアントデバイス１０８上のＷＳアプリケーション１４０のユーザは、ユーザクレデンシャルを提供し、利用可能なリソースのリストを要求する。ＷＳアプリケーション１４０上で実行されるＣＳリソースサービス１３８は、クラウドコネクタ１２０を介してＷＳリソースサーバ１１０に要求を送信する。次に、ＷＳリソースサーバ１１０は、認証サービス１１４を呼び出して、ユーザのクレデンシャルを検証する。Ａｃｔｉｖｅ Ｄｉｒｅｃｔｏｒｙ（ＡＤ）統合（ＡＤデータベースでのルックアップなど）、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ ＡＤ、サードパーティＩＤプロバイダ（ＩＤＰ）との統合など、任意の認証プロセスを使用できる。さらに、クラウドコネクタを使用して、許可をローカルＡＤアカウントと統合することができる（例えば、顧客企業がすでにそれをサポートしている場合）。

ユーザが認可されると、ＷＳリソースサーバ１１０は、ユーザの認可および関連するポリシーに基づいて、ユーザが利用可能なリソースのリストを決定する。次に、ＷＳリソースサーバ１１０は、ＷＳアプリケーション１４０を介して利用可能なリソースのリストをユーザに送信する。ユーザは、アクセスしたいリソース１２４を選択し、その要求をＷＳリソースサーバ１１０に送信する。次に、ＷＳリソースサーバ１１０は、プッシュ通知をクライアントデバイス１０６に送信して、リソース１２４に接続されたＷＳアプリケーション１３０／ＶＤＡセッション１２８をウェイクアップする。プッシュ通知サービス１１６は、ＷＳリソースサーバ１１０に組み込まれてもよいし、独立していてもよい。プッシュ通知が受信されると、ユーザはリソースメタデータ情報を介してリソース１２４に直接アクセスすることができる。例示的なＶＤＡ実施形態では、ＨＤＸは、印刷データなど、リソース１２４によって必要とされる任意のデータを管理する。この場合、ＨＤＸ印刷仮想チャネルは、ローカルリソース１２４を仮想プリンタとしてセッションにマッピングするために使用される。

ＷＳリソースサーバ１１０からのプッシュ通知は、まず、ＷＳリソースサーバ１１０の一部であるか、または第三者によって提供されるプッシュ通知サービス１１６に送られる。そして、通知は、その通知をＷＳアプリケーション１３０に転送するクライアントデバイス１０６のオペレーティングシステムに転送される。通知は、次に、ＣＳリソースサービス１３４に転送され、これは、ウェイクアップ信号またはリソース１２４への接続信号を発行する。

プッシュ通知は、効率的なネイティブプラットフォーム機能（例えば、Ｗｉｎｄｏｗｓ、Ａｐｐｌｅ、Ａｎｄｒｏｉｄ（登録商標）など、プッシュ通知とそれぞれのクラウドプッシュ通知サービスを使用する）を利用するため、理想的なアプローチであることに留意されたい。しかし、既存のアクティブな接続は、通知、例えば、アクティブなＷＳアプリケーション１３０をＷＳリソースサーバ１１０のＷｅｂＳｏｃｋｅｔ接続に、またはアクティブなＷＳアプリケーション１３０をＶＤＡ ＨＤＸ接続、例えば、アクティブなＶＤＡセッション１２８に送信するために、代替的に利用することができる。

パフォーマンスと可用性のために、クライアントリソース１２４は、ＷＳアプリケーション１３０を介してＷＳリソースサーバ１１０によってトリガされるプッシュ通知を介してウェイクアップされてもよい（これは、クライアントデバイス１０６上の接続されたリソースのマッピングを維持する）。最初に、ＷＳリソースサーバ１１０へのリソース登録時に、ＷＳアプリケーション１３０は、プッシュ通知サービス１１６に登録し、ＷＳリソースサーバ１１０にリソース情報と共に送信されるデバイストークンを取得することもできる。本実施形態では、リソース１２４を所有するクライアントデバイス１０６上で実行されるＷＳアプリケーション１３０は、アクティブなリソースセッション１２８を維持する必要はない。別のクライアントデバイスがリソース１２４の使用を要求すると、ＷＳリソースサーバ１１０は、利用可能なリソースＩＤおよびメタデータをクライアントデバイス１０６に送信する。リソースの選択後、同じものに対する要求がＷＳリソースサーバ１１０に送信される。ＷＳリソースサーバ１１０は、先に受信したクライアントデバイス１０６のデバイストークンを用いて、プッシュ通知を送信する。

このプッシュ通知は、リソース１２４に接続されたＷＳアプリケーション１３０を起動する。ウェイクアップ要求を受信すると、次に、ＷＳアプリケーション１３０は、リソースセッション１３２を起動し、その後、リソースと通信する要求を受信することができる。セッションが既に存在する場合（例えば、前の要求から）、そのセッションが利用される。セッションが存在しない場合は、新しいヘッドレスリソースセッションを作成できる。

図４、図６Ａおよび図６Ｂを参照して、リソース共有環境２２０におけるプッシュ通知サービスの使用についてさらに説明する。図６Ａの流れ図（図４および図１を参照）に示すように、ＷＳアプリケーション１３０は、Ｓ１において、ウィンドウ通知サービス、Ａｎｄｒｏｉｄ ＰＮＳ、Ａｐｐｌｅ ＰＮＳなどのプッシュ通知サービス（ＰＮＳ）２３０に登録する。Ｓ２において、ＷＳアプリケーション１３０は、クライアント側リソースサービス１３４を実行し、ＶＤＡ２２８とのアクティブなリモートセッションを確立する。Ｓ３において、ＷＳアプリケーション１３０は、例えば、秘密ＩＤ、秘密鍵、デバイストークン、デバイスタイプなどを、ＷＳリソースサービス２２２（例えば、ＷＳリソースサーバ１１０上で実行されている）に、例えば、ＶＤＡホストエージェント２３６を介して、または直接的に、送信する。

Ｓ４において、ＶＤＡ２２８は、有効なセッション残留を有する可能性があり、Ｓ５において、別のユーザが、リソース１２４にアクセスするために、ＷＳリソースサービス２２２に要求を発行することに留意されたい。Ｓ６において、ＷＳリソースサービス２２２は通知を生成し、Ｓ７において、ディスパッチのための通知を準備する。例えば、通知コンテキストを秘密鍵で暗号化し、デバイストークン、秘密鍵ＩＤ、メタデータ等を追加する。Ｓ８で、ＷＳサービス２２２はＶＤＡホストエージェント２３６に通知を送信する。Ｓ９において、ＷＳアプリケーション１３０がアクティブ接続を有するかどうかの判定が行われる。

アクティブな接続が存在しない場合、ＷＳリソースサービス２２２は、プッシュ通知プロバイダ２３２に、Ｓ１０において、デバイスタイプに基づいてＰＮＳを介して通知をディスパッチするように通知する。次に、Ｓ１１において、ＰＮＳ２３０は、ターゲットデバイス（すなわち、リソース１２４に接続されたクライアントデバイス１０６）にサイレント通知を中継する。Ｓ１２において、ターゲットデバイス（すなわち、クライアントデバイス１０６）は、ＷＳアプリケーション１３０に対するプッシュ通知を受信し、Ｓ１３において、ターゲットデバイスＯＳエージェント２２７は、その通知をＷＳアプリケーション１３０に中継する。次に、クライアント側リソースサービス１３４は、Ｓ１４において、ＷＳアプリケーション１３０から通知を受信し、Ｓ１５において、その通知を復号する。Ｓ１６において、クライアント側リソースサービス１３４は、リソース１２４をウェイクアップ／再接続する。

Ｓ９でアクティブな接続がある場合、Ｓ１７で、例えば、ＨＤＸコネクタまたはＷｅｂＳｏｃｋｅｔなどの他のプロトコルを介して、ウェイクアップ通知がディスパッチされる。次に、プロセスはＳ１４で続行し、クライアント側リソースサービス１３４はＷＳアプリケーション１３０から通知を受信する。このプロセスは、図６Ｂを用いて続く。

代替実施形態では、ＷＳアプリケーションおよびＨＤＸなどの仮想チャネルプロトコルを使用して通信経路を提供するのではなく、代わりにＷｅｂＳｏｃｋｅｔなどの技術を利用することができる。ＷｅｂＳｏｃｋｅｔはコンピュータ通信プロトコルで、１つのＴＣＰ接続を介して全二重通信チャネルを提供する。このアプローチは、ＣＳ資源サービス１３４、１３８（図１）がＶＤＡに接続するか、またはヘッドレスＨＤＸセッションを実行する必要性を除去する。ＷｅｂＳｏｃｋｅｔは、ＷＳリソースサーバ１１０との双方向通信と、デバイスメタデータの共有を可能にする。リソースは、前述したように、プッシュ通知を介して起動されてもよい。あるいは、前述のように、既存のアクティブなＷｅｂＳｏｃｋｅｔ接続を使用してリソースを起動することができる。ある実装では、ＣＳリソースサービス１３４、１３８は、オープンなＷｅｂＳｏｃｋｅｔを維持し、ＷＳリソースサーバ１１０からの受信データをリッスンすることができる。ＣＳリソースサービス１３８が永続的なＷｅｂＳｏｃｋｅｔ接続を維持する実施形態では、ＷＳアプリケーションは関与する必要はない。ネイティブプラットフォーム統合プッシュ通知、例えば、Ａｐｐｌｅ Ｐｕｓｈ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ（ＡＰＳ）、Ｗｉｎｄｏｗｓ Ｐｕｓｈ Ｎｏｔｉｆｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ（ＷＰＳ）などを含む実施形態では、ＷＳアプリケーションは、プッシュ通知を受信し、それらをＣＳリソースサービス１３８に中継するように登録することができる。

図５は、ＨＤＸを利用しないアーキテクチャ２５０を示す。代わりに、ＷＳリソースサーバ１１０を介したリソース共有は、直接的なピアツーピア（Ｐ２Ｐ）接続２５２（例えば、ＷｅｂＳｏｃｋｅｔ、ＴＣＰ、ＵＤＰ、ＨＴＴＰＳなど）またはＰ２Ｐ間接接続を利用する。前述のように、ＷｅｂＳｏｃｋｅｔ接続は、コンピューティングデバイス（例えば、ＷＳリソースサーバ１１０）と確立することができる。第１デバイス１０６と第２デバイス１０８との間のＰ２Ｐ直接接続は、可能であればいつでも利用される。あるいは、Ｐ２Ｐ間接接続、例えば、第１および第２デバイス間のネットワークアドレス変換（ＴＵＲＮ）サーバ２５４周辺のリレーを使用するネットワークアドレス変換（ＳＴＵＮ）／トラバーサルからのヘルプを利用することもできる。

図６Ｂに戻ると、デバイス共有プロセスがさらに説明され、図６ＡのコネクタＡから続く。Ｓ１８において、要求されたマシン（例えば、クライアントデバイス１０６またはクライアントデバイス１０８）がＰ２Ｐメソッドを介して到達可能であるかどうかの判定が行われる。肯定の場合、クライアント側リソースサービスは、直接アドレスを介して、またはＳ１９で間接的（例えば、ＳＴＵＮ／ＴＵＲＮ）サーバを介して接続をセットアップし、共有リソースへのアクセスは、Ｓ２０で提供される。Ｓ１８において、要求されたマシンがＰ２Ｐを介して到達可能でない場合、Ｓ２１において、ＨＤＸプロトコルを使用するかどうかの判定が行われる。肯定の場合、Ｓ２３において、ＷＳアプリケーションはリレーとして動作し、ＨＤＸを介して接続をセットアップし、Ｓ２０において共有リソースにアクセスする。否定の場合、Ｓ２２において、ＷＳアプリケーションはリレーとして動作し、ＷｅｂＳｏｃｋｅｔを介して接続をセットアップし、Ｓ２０において共有リソースにアクセスする。

図７を参照すると、エンタープライズコンピューティングプラットフォームを実装するのに適した例示的なネットワーク環境４００が示されている。ネットワーク環境４００は、１つまたは複数のネットワーク４０４（１）～４０４ｎ（一般にネットワーク４０４と呼ばれる）を介して１つまたは複数のサーバ４０６（１）～４０６（ｎ）（一般にリモートマシン４０６またはサーバ４０６とも呼ばれる）と通信する１つまたは複数のクライアント４０２（１）～４０２（ｎ）（一般にローカルマシン４０２またはクライアント４０２とも呼ばれる）を含むことができる。いくつかの実施形態では、クライアント４０２は、１つまたは複数の機器４１０（１）～４１０ｎ（一般に、機器４１０またはゲートウェイ４１０と呼ばれる）を介してサーバ４０６と通信することができる。

図７に示す実施形態は、クライアント４０２とサーバ４０６との間の１つまたは複数のネットワーク４０４を示すが、他の実施形態では、クライアント４０２およびサーバ４０６は、同じネットワーク４０４上にあってもよい。種々のネットワーク４０４は、同じタイプのネットワークであってもよく、または異なるタイプのネットワークであってもよい。例えば、ある実施形態では、ネットワーク４０４（１）は、ローカルエリアネットワーク（ＬＡＮ）または企業イントラネットのようなプライベートネットワークであってもよく、ネットワーク４０４（２）および／またはネットワーク４０４（ｎ）は、ワイドエリアネットワーク（ＷＡＮ）またはインターネットのようなパブリックネットワークであってもよい。他の実施形態では、ネットワーク４０４（１）とネットワーク４０４（ｎ）の両方がプライベートネットワークであってもよい。ネットワーク４０４は、有線および／または無線ネットワークのような１つ以上のタイプの物理ネットワークおよび／またはネットワークトポロジーを使用することができ、伝送制御プロトコル（ＴＣＰ）、インターネットプロトコル（ＩＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、または他の同様のプロトコルのような１つ以上の通信トランスポートプロトコルを使用することができる。

図７に示すように、１つまたは複数の機器４１０は、ネットワーク環境４００の様々な地点または様々な通信経路に配置することができる。例えば、機器４１０（１）は、２つのネットワーク４０４（１）と４０４（２）との間に配備されてもよく、機器４１０は、例えば、クライアント４０２とサーバ４０６との間のネットワークトラフィックを加速するために連携して動作するように互いに通信してもよい。他の実施形態では、機器４１０は、ネットワーク４０４上に配置されてもよい。例えば、デバイス４１０は、クライアント４０２および／またはサーバ４０６の一部として実装されてもよい。一実施形態では、機器４１０は、フロリダ州フォート、ラウダーデールのＣｉｔｒｉｘ Ｓｙｓｔｅｍｓ、Ｉｎｃ．によって販売されているＣｉｔｒｉｘネットワーキング（以前はＮｅｔＳｃａｌｅｒ（登録商標））製品などのネットワークデバイスとして実装することができる。

図７に示すように、１つまたは複数のサーバ４０６は、サーバファーム４０８として動作することができる。サーバファーム４０８のサーバ４０６は、論理的にグループ化することができ、クライアント４０２および／または他のサーバ４０６から地理的に共存するか（例えば、オンプレミス）、または地理的に分散する（例えば、クラウドベース）ことができる。一実施形態では、サーバファーム４０８は、ファイルサーバ、ゲートウェイサーバ、プロキシサーバ、または他の類似のサーバ使用などの他の使用も可能であるが、１つ以上のアプリケーションをクライアント４０２の１つ以上に代わって（例えば、アプリケーションサーバとして）実行する。クライアント４０２は、サーバ４０６上のホストされたアプリケーションへのアクセスを求めてもよい。

図７に示すように、いくつかの実施形態では、機器４１０は、一般にＷＡＮ最適化機器４１２と呼ばれるＷＡＮ最適化機器４１２（１）～４１２（ｎ）などの１つまたは複数の追加の機器を含むか、それに置き換えられるか、またはそれと通信することができる。例えば、ＷＡＮ最適化機器４１２は、ＷＡＦＳ（Ｗｉｄｅ Ａｒｅａ Ｆｉｌｅ Ｆｅａｔｕｒｅｓ）の最適化、ＳＭＢ（Ｓｅｒｖｅｒ Ｍｅｓｓａｇｅ Ｂｌｏｃｋ）またはＣＩＦＳ（Ｃｏｍｍｏｎ Ｉｎｔｅｒｎｅｔ Ｆｉｌｅ Ｓｙｓｔｅｍ）の加速など、ＷＡＮ接続へのトラフィックおよび／またはＷＡＮ接続からのトラフィックなどのネットワークトラフィックの性能、動作、フロー制御、または機能の品質を最適化または改善してもよい。いくつかの実施形態では、（１つまたは複数の）機器４１２は、パフォーマンス強化プロキシまたはＷＡＮ最適化コントローラであってもよい。一実施形態では、機器４１２は、フロリダ州フォートローダーデールのＣｉｔｒｉｘ Ｓｙｓｔｅｍｓ， Ｉｎｃ．が販売するＣｉｔｒｉｘ ＳＤ－ＷＡＮ製品として実装されてもよい。

説明される実施形態では、クライアント４０２、サーバ４０６、および機器４１０および４１２は、少なくとも１つのネットワークを介して通信することができ、本明細書で説明される動作を実行することができる任意のデスクトップコンピュータ、ラップトップコンピュータ、またはモバイルデバイスなど、任意のタイプおよび形態のコンピューティングデバイスとして配備され、かつ／またはその上で実行され得る。例えば、クライアント４０２、サーバ４０６、および／または機器４１０および４１２は、それぞれ、１つのコンピュータ、複数のコンピュータ、または図９に示すコンピューティングシステム３００などの分散コンピュータのネットワークに対応することができる。

図８を参照すると、クラウド環境、クラウドコンピューティング、またはクラウドネットワークとも呼ばれるクラウドコンピューティング環境５００が示されている。クラウドコンピューティング環境５００は、共有コンピューティングサービスおよび／またはリソースを複数のユーザまたはテナントに配信することができる。例えば、共有リソースおよびサービスには、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、データベース、ソフトウェア、ハードウェア、分析、およびインテリジェンスが含まれるが、これらに限定されない。

クラウドコンピューティング環境５００では、１つ以上のクライアント４０２ａ～４０２ｎ（上述のように）がクラウドネットワーク５０４と通信している。クラウドネットワーク５０４は、バックエンドプラットフォーム、例えば、サーバ、ストレージ、サーバファームまたはデータセンターを含むことができる。ユーザまたはクライアント４０２ａ～４０２ｎは、単一の組織／テナントまたは複数の組織／テナントに対応することができる。より具体的には、一実施例では、クラウドコンピューティング環境５００は、単一の組織（例えば、エンタープライズクラウド）にサービスを提供するプライベートクラウドを提供することができる。別の例では、クラウドコンピューティング環境５００は、複数の組織／テナントにサービスを提供するコミュニティまたはパブリッククラウドを提供することができる。

ある実施形態では、ゲートウェイデバイスまたはサービスを利用して、クラウドコンピューティングリソースおよび仮想セッションへのアクセスを提供することができる。例として、Ｃｉｔｒｉｘ Ｓｙｓｔｅｍｓ，Ｉｎｃ．によって提供されるＣｉｔｒｉｘ Ｇａｔｅｗａｙは、オンプレミスまたはパブリッククラウド上に展開されて、ユーザに安全なアクセスと、仮想アプリケーション、ＳａａＳアプリケーションおよびウェブアプリケーションへのシングルサインオンとを提供することができる。さらに、Ｗｅｂの脅威からユーザを保護するために、Ｃｉｔｒｉｘ Ｓｅｃｕｒｅ Ｗｅｂ Ｇａｔｅｗａｙなどのゲートウェイを使用できる。Ｃｉｔｒｉｘ Ｓｅｃｕｒｅ Ｗｅｂ Ｇａｔｅｗａｙは、クラウドベースのサービスとローカルキャッシュを使用して、ＵＲＬのレピュテーションとカテゴリを確認する。

さらに別の実施形態では、クラウドコンピューティング環境５００は、パブリッククラウドとプライベートクラウドの組合せであるハイブリッドクラウドを提供することができる。パブリッククラウドは、クライアント４０２ａ～４０２ｎまたはエンタープライズ／テナントの第三者によって維持されるパブリックサーバを含むことができる。サーバは、地理的に離れた場所やその他の場所にあるオフサイトに配置される場合がある。

クラウドコンピューティング環境５００は、クライアント４０２ａ～４０２ｎを介してマルチテナント環境またはマルチテナントモデルを介して複数のユーザにサービスするためのリソースプーリングを提供することができ、それぞれの環境内の異なる要求に応答して、異なる物理リソースおよび仮想リソースが動的に割り当てられ、再割り当てされる。マルチテナント環境には、ソフトウェアの単一インスタンス、アプリケーション、または複数のユーザに対応するソフトウェアアプリケーションを提供できるシステムまたはアーキテクチャを含めることができる。いくつかの実施形態において、クラウドコンピューティング環境５００は、複数のクライアント４０２ａ～４０２ｎのためのネットワーク全体にわたる一方的な提供コンピューティング能力（例えば、サーバ時間、ネットワークストレージ）に対して、オンデマンドセルフサービスを提供できる。例として、プロビジョニングサービスは、シトリックスプロビジョニングサービス（Ｃｉｔｒｉｘ ＰＶＳ）などのシステムを介して提供され得る。Ｃｉｔｒｉｘ ＰＶＳは、パッチ、アップデート、およびその他の構成情報を、共有デスクトップイメージを介して、複数の仮想デスクトップエンドポイントに配信するソフトウェアストリーミングテクノロジーである。クラウドコンピューティング環境５００は、１つまたは複数のクライアント４０２からの異なる要求に応じて動的にスケールアウトまたはスケールインする弾性を提供することができる。いくつかの実施形態では、クラウドコンピューティング環境５００は、提供された共有サービスおよびリソースに対応するレポートを監視、制御、および／または生成するための監視サービスを含むか、または提供することができる。

一部の実施形態では、クラウドコンピューティング環境５００は、サービスとしてのソフトウェア（ＳａａＳ）５０８、サービスとしてのプラットフォーム（ＰａａＳ）５１２、サービスとしてのインフラストラクチャ（ＩａａＳ）５１６、サービスとしてのデスクトップ（ＤａａＳ）５２０など、異なるタイプのクラウドコンピューティングサービスのクラウドベースの配信を提供してもよい。ＩａａＳは、指定された期間に必要なインフラストラクチャリソースの使用をレンタルするユーザを指す場合がある。ＩａａＳプロバイダは、大規模なプールからストレージ、ネットワーク、サーバ、または仮想化リソースを提供することがあり、必要に応じてより多くのリソースにアクセスすることで、ユーザを迅速にスケールアップできる。ＩａａＳの例には、米国ワシントン州シアトルのＡｍａｚｏｎ．ｃｏｍ，Ｉｎｃ．によって提供されるＡＭＡＺＯＮ ＷＥＢ ＳＥＲＶＩＣＥＳ、カリフォルニア州マウンテンビューのＧｏｏｇｌｅ Ｉｎｃ．によって提供されるＧｏｏｇｌｅ Ｃｏｍｐｕｔｅ Ｅｎｇｉｎｅ、テキサス州サンアントニオのＲａｃｋｓｐａｃｅ ＵＳ、Ｉｎｃ．によって提供されるＲＡＣＫＳＰＡＣＥ ＣＬＯＵＤ、またはカリフォルニア州サンタバーバラのＲｉｇｈｔＳｃａｌｅ，Ｉｎｃ．によって提供されるＲＩＧＨＴＳＣＡＬＥが含まれる。

ＰａａＳプロバイダは、ＩａａＳによって提供される機能、例えば、ストレージ、ネットワーキング、サーバまたは仮想化、ならびに、例えば、オペレーティングシステム、ミドルウェア、またはランタイムリソースのような追加リソースを提供することができる。ＰａａＳの例には、ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって提供されるＷＩＮＤＯＷＳ ＡＺＵＲＥ、Ｇｏｏｇｌｅ Ｉｎｃ．によって提供されるＧｏｏｇｌｅ Ａｐｐ Ｅｎｇｉｎｅ、およびカリフォルニア州サンフランシスコのＨｅｒｏｋｕ，Ｉｎｃ．によって提供されるＨＥＲＯＫＵが含まれる。

ＳａａＳプロバイダは、ＰａａＳが提供するストレージ、ネットワーキング、サーバ、仮想化、オペレーティングシステム、ミドルウェア、ランタイムリソースなどのリソースを提供する場合がある。いくつかの実施形態では、ＳａａＳプロバイダは、例えば、データおよびアプリケーションリソースを含む追加のリソースを提供することができる。ＳａａＳの例には、Ｇｏｏｇｌｅ Ｉｎｃ．によって提供されるＧＯＧＬＥ ＡＰＰＳ、カリフォルニア州サンフランシスコのＳａｌｅｓｆｏｒｃｅ．ｃｏｍ Ｉｎｃ．によって提供されるＳＡＬＥＳＦＯＲＣＥ、またはＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって提供されるＯＦＦＩＣＥ ３６５が含まれる。ＳａａＳの例はまた、データストレージプロバイダ、例えば、Ｃｉｔｒｉｘ ＳｙｓｔｅｍｓからのＣｉｔｒｉｘ ＳｈａｒｅＦｉｌｅ、カリフォルニア州サンフランシスコのＤｒｏｐｂｏｘ，Ｉｎｃ．によって提供されるＤＲＯＰＢＯＸ、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって提供されるＭｉｃｒｏｓｏｆｔ ＳＫＹＤＲＩＶＥ、Ｇｏｏｇｌｅ Ｉｎｃ．によって提供されるＧｏｏｇｌｅ Ｄｒｉｖｅ、またはカリフォルニア州クパチーノのＡｐｐｌｅ Ｉｎｃ．によって提供されるＡｐｐｌｅ ＩＣＬＯＵＤを含むことができる。

ＳａａＳと同様に、ＤａａＳ（ホストされるデスクトップサービスとも呼ばれる）は、仮想デスクトップセッションが通常、仮想デスクトップで使用されるアプリケーションとともにクラウドサービスとして配信される仮想デスクトップインフラストラクチャ（ＶＤＩ）の形式である。Ｃｉｔｒｉｘ ＳｙｓｔｅｍｓのＣｉｔｒｉｘ Ｃｌｏｕｄは、ＤａａＳ配信プラットフォームの一例である。ＤａａＳ配信プラットフォームは、例えば、ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎからのＡＺＵＲＥ ＣＬＯＵＤ（本明細書では「Ａｚｕｒｅ」）、またはワシントン州シアトルのＡｍａｚｏｎ．ｃｏｍ，Ｉｎｃ．によって提供されるＡＭＡＺＯＮ ＷＥＢ ＳＥＲＶＩＣＥＳ（本明細書では「ＡＷＳ」）などのパブリッククラウドコンピューティングインフラストラクチャ上でホストすることができる。Ｃｉｔｒｉｘ Ｃｌｏｕｄ の場合、Ｃｉｔｒｉｘ Ｗｏｒｋｓｐａｃｅ ａｐｐは、アプリ、ファイル、およびデスクトップを（オンプレミスまたはクラウドのいずれかにかかわらず）まとめて、統一されたエクスペリエンスを提供するためのシングルエントリポイントとして使用できる。

説明されたソリューションの要素は、コンピュータ３００が、１つまたは複数のプロセッサ３０２、揮発性メモリ３０４（例えば、ＲＡＭ）、不揮発性メモリ３０８（例えば、１つまたは複数のハードディスクドライブ（ＨＤＤ）または他の磁気または光記憶媒体、フラッシュドライブまたは他のソリッドステート記憶媒体などの１つまたは複数のソリッドステートドライブ（ＳＳＤ）、１つまたは複数のハイブリッド磁気およびソリッドステートドライブ、および／またはクラウドストレージなどの１つまたは複数の仮想記憶ボリューム、またはそのような物理記憶ボリュームと仮想記憶ボリュームまたはアレイの組合せ）、ユーザインターフェース（ＵＩ）３１０、１つまたは複数の通信インターフェイス３０６、および通信バス３１２を含むことができる図９に示すようなコンピューティングシステムで実施することができる。ユーザインターフェイス３１０は、グラフィカルユーザインターフェイス（ＧＵＩ）３２０（例えば、タッチスクリーン、ディスプレイなど）と、１つまたは複数の入力／出力（Ｉ／Ｏ）デバイス３２２（例えば、マウス、キーボードなど）とを含むことができる。不揮発性メモリ３０８は、オペレーティングシステム３１４、１つ以上のアプリケーション３１６、およびデータ３１８を記憶し、例えば、オペレーティングシステム３１４および／またはアプリケーション３１６のコンピュータ命令が、揮発性メモリ３０４のうちプロセッサ３０２によって実行されるようにする。データは、ＧＵＩ３２０の入力デバイスを使用して入力されてもよいし、Ｉ／Ｏデバイス３２２から受信されてもよい。コンピュータ３００の様々な要素は、通信バス３１２を介して通信することができる。図９に示すコンピュータ３００は、単に一例として、クライアント、サーバ、および／または機器として示されており、任意のコンピューティング環境または処理環境によって、本明細書で説明するように動作することができる適切なハードウェアおよび／またはソフトウェアを有することができる任意のタイプのマシンまたはマシンのセットを用いて実装することができる。

プロセッサ３０２は、システムの機能を実行するために１つまたは複数のコンピュータプログラムを実行する１つまたは複数のプログラマブルプロセッサによって実装され得る。本明細書で使用されるように、「プロセッサ」という用語は、機能、動作、または動作のシーケンスを実行する電子回路を記述する。機能、動作、または動作のシーケンスは、電子回路にハードコードされるか、またはメモリデバイスに保持された命令によってソフトコードされてもよい。「プロセッサ」は、デジタル値を使用して、またはアナログ信号を使用して、機能、動作、または動作のシーケンスを実行してもよい。いくつかの実施形態では、「プロセッサ」は、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、マイクロプロセッサ、デジタル信号プロセッサ、マイクロコントローラ、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラマブルロジックアレイ（ＰＬＡ）、マルチコアプロセッサ、またはメモリに関連する汎用コンピュータで具現化されてもよい。「プロセッサ」は、アナログ、デジタル、または混合信号であってもよい。プロセッサ」は、アナログ、デジタル、または混合信号であってもよい。 いくつかの実施形態では、「プロセッサ」は、１つまたは複数の物理プロセッサ、または１つまたは複数の「仮想」（例えば、遠隔地にあるまたは「クラウド」）プロセッサであってもよい。

通信インターフェイス３０６は、コンピュータ３００が様々な有線および／または無線またはセルラ接続を介してＬＡＮ、ＷＡＮ、またはインターネットのようなコンピュータネットワークにアクセスできるようにするための１つ以上のインターフェイスを含んでもよい。

記載された実施形態では、第１コンピューティングデバイス３００は、クライアントコンピューティングデバイス（例えば、クライアント）のユーザに代わってアプリケーションを実行することができ、その中でアプリケーションがユーザまたはクライアントコンピューティングデバイス（例えば、クライアント）に代わって実行される実行セッションを提供し、ホストされたデスクトップセッションなどの端末サービスセッションを実行し、または、１つ以上のアプリケーション、１つ以上のデスクトップアプリケーション、および１つ以上のアプリケーションが実行できる１つ以上のデスクトップセッションのうちの１つ以上を含むコンピューティング環境へのアクセスを提供することができる。

前述の図面は、本開示のいくつかの実施形態に関連する処理のいくつかを示す。この点に関して、図面の流れ図内の各図またはブロックは、説明される方法の実施形態に関連するプロセスを表す。また、いくつかの代替の実装形態では、図面またはブロックに示される動作は、図に示される順序とは異なる順序で行われてもよく、または、例えば、実際には、含まれる動作に応じて、実質的に同時に、または逆の順序で実行されてもよいことにも留意されたい。また、当業者は、処理を記述する追加のブロックが加えられてもよいことを認識するであろう。

以下の開示を読めば当業者には理解されるように、本明細書で説明される様々な態様は、システム、デバイス、方法、またはコンピュータプログラム製品（例えば、上記の動作またはステップを実行するためのコンピュータ実行可能命令を有する非一時的コンピュータ可読媒体）として実施され得る。したがって、これらの態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、またはソフトウェアおよびハードウェアの態様を組み合わせた実施形態の形態をとることができる。さらに、このような態様は、記憶媒体内または記憶媒体上に具現化された、コンピュータ読み取り可能なプログラムコードまたは命令を有する１つ以上のコンピュータ読み取り可能な記憶媒体によって記憶されたコンピュータプログラム製品の形態をとることができる。ハードディスク、ＣＤ－ＲＯＭ、光記憶デバイス、磁気記憶デバイス、および／またはそれらの任意の組合せを含む、任意の適切なコンピュータ可読記憶媒体を利用することができる。

本明細書で使用される用語は、特定の実施形態を説明するためだけのものであり、本開示を限定することを意図するものではない。本明細書中で使用されるように、単数形「１つの」は、文脈が明確に示さない限り、複数形も含むことを意図している。本明細書中で使用される場合、用語「含む」は、述べられた特徴、整数、ステップ、操作、要素、および／または構成要素の存在を明記するが、１つまたは複数の他の特徴、整数、ステップ、操作、要素、構成要素、および／またはそれらのグループの存在または追加を排除しないことをさらに理解するであろう。「任意の」または「任意に」とは、続いて記述された事象または状況が発生してもしなくてもよく、記述には事象が発生する例と発生しない例が含まれることを意味する。

本明細書および特許請求の範囲を通して本明細書で使用されているように、近似的な表現は、それが関連する基本的な機能の変化をもたらすことなく許容的に変化し得るあらゆる量的表現を修正するために適用することができる。したがって、「約」、「およそ」、「実質的に」などの用語によって修正された値は、指定された正確な値に限定されるものではない。少なくともいくつかの例では、近似的な表現は、値を測定するための機器の精度に対応することができる。本明細書および特許請求の範囲では、範囲の制限を組み合わせたり、入れ替えたりすることができ、そのような範囲は、文脈または言語が別の方法を示していない限り、特定され、その中に含まれるすべてのサブ範囲を含む。範囲の特定の値に適用される「約」は、両方の値に適用され、値を測定する機器の精度に別段依存しない限り、記載された値の±１０％を示すことがある。

特許請求の範囲に記載した機能要素に加え全ての手段またはステップの対応する構造、材料、行為等は、特許請求の範囲に規定された他の構成要件との結合において当該機能を発揮する任意の構造、材料または行為を含むものである。本開示の説明は、例示および説明の目的のために提示されてきたが、網羅的であることも、開示された形式の開示に限定されることも意図されていない。本開示の範囲および思想から逸脱することなく、多くの修正および変形が当業者には明らかであろう。本実施形態は、本開示の原理および実際の適用を最もよく説明するために、また、当業者が、意図される特定の使用に適した様々な修正を伴う様々な実施形態について本開示を理解することを可能にするために、選択され、説明された。

Claims (20)

1. コンピューティングデバイスが、第１クライアントデバイスからの要求を受信し、
   前記要求は、利用可能なリソースのリストの要求であり、
   前記利用可能なリソースのリストは、少なくとも１つの他のクライアントデバイスにローカルに接続され、仮想コンピューティング環境内のエンタープライズサービスを介して前記第１クライアントデバイスに利用できないリソースを含み、
   前記コンピューティングデバイスが、前記第１クライアントデバイスに前記利用可能なリソースのリストを提供し、
   前記利用可能なリソースのリストは、前記利用可能なリソースの少なくとも１つの識別子（ＩＤ）およびメタデータを含み、
   前記コンピューティングデバイスが、第２クライアントデバイスに接続されている前記利用可能なリソースのリスト内に含まれる選択されたリソースの前記第１クライアントデバイスからの選択を受信し、
   前記コンピューティングデバイスが、前記選択されたリソースとの接続を確立するためのプッシュ通知を前記第２クライアントデバイスに提供する、
   方法。
2. 前記プッシュ通知に応答して、前記第２クライアントデバイスでクライアント側リソースサービスを実行しているワークスペースアプリケーションを介して、前記選択されたリソースとのＶＤＡ（仮想デリバリエージェント）セッションを確立し、
   前記コンピューティングデバイスを介して、前記ＶＤＡセッションを介して前記選択されたリソースへのアクセスを前記第１クライアントデバイスに提供する、
   請求項１に記載の方法。
3. 前記プッシュ通知に応答して、前記第２クライアントデバイスでバックグラウンド動作として動作するＶＤＡ（仮想デリバリエージェント）セッションを確立し、
   前記コンピューティングデバイスを介して、前記ＶＤＡセッションを介して前記選択されたリソースへのアクセスを前記第１クライアントデバイスに提供する、
   請求項１に記載の方法。
4. 前記第１クライアントデバイスは、ＶＤＡセッションによって前記コンピューティングデバイスに接続される、請求項１に記載の方法。
5. 前記プッシュ通知に応答して、前記選択されたリソースに接続されている前記第２クライアントデバイスと前記コンピューティングデバイスとの間のＷｅｂＳｏｃｋｅｔ接続とピアツーピア（Ｐ２Ｐ）接続との少なくとも１つを確立し、
   前記第１クライアントデバイスに、前記ＷｅｂＳｏｃｋｅｔ接続またはＰ２Ｐ接続を介して前記選択されたリソースに評価を提供する、
   請求項１に記載の方法。
6. 前記利用可能なリソースのリストについての前記要求は、前記第１クライアントデバイスのユーザの認証情報をさらに含み、
   前記方法は、前記認証情報に基づいて前記第１クライアントデバイスの前記ユーザを認証することをさらに含む、
   請求項１に記載の方法。
7. 前記コンピューティングデバイスは、ユーザセットのためのリソースセットへのアクセス権を決定する、
   請求項６に記載の方法。
8. 前記コンピューティングデバイスが、前記第１クライアントデバイスの前記ユーザの認証と、前記リソースセットに対するアクセス権とに基づいて、前記利用可能なリソースのリストを、前記第１クライアントデバイスに提供することをさらに含む、
   請求項７に記載の方法。
9. クライアントデバイスへのリソースの新しいローカル接続を検出し、
   新しく接続されたリソースをリソースデータベースに登録し、
   前記新しく接続されたリソースを、前記第１クライアントデバイスで前記利用可能なリソースのリストに追加する、
   請求項１に記載の方法。
10. クライアントデバイスからの指定されたリソースの切断を検出し、
    前記コンピューティングデバイスに前記切断を通知し、
    前記利用可能なリソースのリストから前記指定されたリソースを非アクティブ化する、
    請求項１に記載の方法。
11. メモリと、
    前記メモリに接続されているプロセッサと、
    を含み、
    前記プロセッサは、
    リソースセットに関連付けられている情報を記憶し、
    前記情報は、前記リソースセットの各リソースの識別子（ＩＤ）およびメタデータを含み、
    各リソースはクライアントデバイスにローカルに接続され、各リソースは仮想コンピューティング環境内のエンタープライズサービスを介して他のクライアントデバイスに利用不能であり、
    第１クライアントデバイスから利用可能なリソースのリストの要求を受信し、
    前記要求は、利用可能なリソースのリストの要求であり、
    前記第１クライアントデバイスに前記利用可能なリソースのリストを提供し、
    前記利用可能なリソースのリストは、前記利用可能なリソースの各々の前記ＩＤおよびメタデータを含み、
    前記利用可能なリソースのリストから選択されたリソースを前記第１クライアントデバイスから受信し、
    前記選択されたリソースは第２クライアントデバイスに接続され、
    前記選択されたリソースとの接続を確立するために前記第２クライアントデバイスに通知をプッシュする、
    コンピューティングデバイス。
12. 前記通知に応答して、前記第２クライアントデバイスでクライアント側リソースサービスを実行しているワークスペースアプリケーションを介して、前記選択されたリソースとのＶＤＡ（仮想デリバリエージェント）セッションを確立し、
    前記ＶＤＡセッションを介して前記選択されたリソースへのアクセスを前記第１クライアントデバイスに提供する、
    請求項１１に記載のコンピューティングデバイス。
13. プッシュされた前記通知に応答して、前記第２クライアントデバイスでバックグラウンド動作として動作するＶＤＡ（仮想デリバリエージェント）セッションを前記選択されたリソースで確立し、
    前記ＶＤＡセッションを介して前記選択されたリソースへのアクセスを前記第１クライアントデバイスに提供する、
    請求項１１に記載のコンピューティングデバイス。
14. 前記第１クライアントデバイスは、ＶＤＡセッションによってワークスペースリソースに接続される、請求項１１に記載のコンピューティングデバイス。
15. 前記通知に応答して、前記選択されたリソースに接続されている前記第２クライアントデバイスとワークスペースリソースのサーバとの間のＷｅｂＳｏｃｋｅｔ接続とピアツーピア（Ｐ２Ｐ）接続との少なくとも１つを確立し、
    前記第１クライアントデバイスにより、前記ＷｅｂＳｏｃｋｅｔ接続またはＰ２Ｐ接続を介して前記選択されたリソースを評価する、
    請求項１１に記載のコンピューティングデバイス。
16. 前記第１クライアントデバイスから前記利用可能なリソースの要求に含まれる認証情報に基づいて、前記第１クライアントデバイスのユーザを認証する、
    請求項１１に記載のコンピューティングデバイス。
17. ユーザセットのためのリソースセットへのアクセス権を決定する、
    請求項１６に記載のコンピューティングデバイス。
18. 前記第１クライアントデバイスの前記ユーザの認証と、前記リソースセットに対するアクセス権とに基づいて、前記利用可能なリソースのリストを、前記第１クライアントデバイスに提供することをさらに含む、
    請求項１７に記載のコンピューティングデバイス。
19. クライアントデバイスへのリソースの新しいローカル接続を検出し、
    新しく接続されたリソースをリソースデータベースに登録し、
    前記新しく接続されたリソースを、前記第１クライアントデバイスで前記利用可能なリソースのリストに追加する、
    請求項１１に記載のコンピューティングデバイス。
20. クライアントデバイスからの指定されたリソースの切断を検出し、
    ワークスペースリソースに前記切断を通知し、
    前記利用可能なリソースのリストから前記指定されたリソースを非アクティブ化する、
    請求項１１に記載のコンピューティングデバイス。
    

Images