JP2021503670A - リモートセッションにおける可視透かしを提供するシステム及び方法 - Google Patents

Abstract

リモートセッションにおける可視透かしを提供するシステム及び方法。当該方法は、リモートセッションの期間に、クライアントコンピューティングデバイスでグラフィック更新をする必要があるか否かを判断し、グラフィック更新が必要であるという判断に応答して第１グラフィック更新メッセージを作成し、グラフィック及び少なくとも１つの透かしの双方がクライアントコンピューティングデバイスの画面に表示された場合、少なくとも１つの透かしの影響を受けるグラフィックの画素を特定し、以前に特定された画素の各々の新たなカラー値を指定する第２コマンド列を構成し、第１コマンド列とエンドオブフレーム（ＥＯＦ）コマンドとの間に第２コマンド列を挿入することによって、第１グラフィック更新メッセージを第２グラフィック更新メッセージに変換し、第２グラフィック更新メッセージをサーバからクライアントコンピューティングデバイスへ送信する。

Description

（関連出願の相互参照）
本出願は、２０１７年１１月２０日に出願された米国特許出願第１５／８１７，８３２号の優先権を主張し、その開示内容は参照により本明細書に組み込まれる。

本開示は、概してコンピューティングシステムに関する。より詳細には、本開示は、リモートセッションにおける可視透かし（visible watermark）を提供するシステム及び方法の実施に関する。

透かしは、コンピュータの画面から外部へ機密情報又は極秘情報が漏洩するおそれに対し、可視的な抑止手段としての機能を果たしている。リモートセッションに透かしを付加する方法は２つある：（１）サーバのフレームバッファの一部として透かしを提供する（サーバオンリー）；又は（２）エンドポイントのクライアントソフトウェアに、画面を更新するたびに透かしを表示するよう指示する。

手法（１）は、純粋にサーバオンリーの解決手段である（すなわち、エンドポイントの更新を要しない。）。透かしは、サーバのフレームバッファ上で合成されるので、エンドポイントに送信された任意のグラフィック画面の更新の一部として提供される。この手法の主なデメリットは、透かしを作製するために余分な中央処理装置（ＣＰＵ）リソースを必要とするということである。

手法（２）は、画面を更新するたびに部分的に透明なオーバーレイを表示する機能がサポートされていない場合に、エンドポイントソフトウェアを更新しなければならないというデメリットがある。このことは、エンドポイントが更新するのに困難を伴うか不可能である場合（例えば、旧シンクライアントなど）、又はエンドポイントの数が多すぎる場合に、いささか厄介である。

本開示は、リモートセッションにおける可視透かしを提供するシステム及び方法の実施に関する。当該方法は、サーバにより、リモートセッションの期間に、クライアントコンピューティングデバイスでグラフィック更新をする必要があるか否かを判断する動作を実行し、グラフィック更新をする必要があるという判断に応答して、第１グラフィック更新メッセージ（例えば、コマンド列）を作成し、グラフィック及び少なくとも１つの透かしの双方がクライアントコンピューティングデバイスの画面に表示された場合、少なくとも１つの透かしの影響を受けるグラフィックの画素を特定し、以前に特定された画素の各々の新たなカラー値を有する新たなグラフィック更新（例えば、ビットマップ）を指定する第２コマンド列を構成し、第１コマンド列とＥＯＦコマンドとの間に第２コマンド列を挿入することによって、第１グラフィック更新メッセージを第２グラフィック更新メッセージに変換し、第２グラフィック更新メッセージをサーバからクライアントコンピューティングデバイスへ送信することを含む。これらの動作は、サーバのグラフィックスエンコーダ（ＧＥ）によって実行することができる。

いくつかのシナリオにおいて、当該方法は、クライアントコンピューティングデバイスのデバイス識別子を用いて、データストアからそれぞれの予め定義された透かしパラメータ情報を取得し、取得されたそれぞれの予め定義された透かしパラメータ情報とクライアントコンピューティングデバイスの既知の画面サイズとに基づいて、少なくとも１つの全画面サイズ透かし画像を生成し、透かしが存在する少なくとも１つの全画面サイズ透かし画像の領域を特定することをさらに含む。全画面サイズ透かし画像は、白色背景又は黒色背景に透かしの少なくとも１つのインスタンスを有するが、これに限定されない。領域の特定は、少なくとも１つの全画面サイズ透かし画像を複数の同一サイズのブロックに分割し、複数の同一サイズのブロックのうちどのブロックが透かしの一部を含んでいるのかを特定し、及び／又は、特定されたブロックの隣接するブロックを統合して、より大きなブロックを生成することによってなされる。

そして、（ａ）透かしが存在する少なくとも１つの全画面サイズ透かし画像の特定された領域と、（ｂ）特定された領域のどの画素が透かしを有するのかを示す透かしビットマップが生成される。グラフィック及び透かしの双方がクライアントコンピューティングデバイスの画面に表示されたとき、透かしビットマップを用いて、透かしの影響を受けるグラフィックの画素を特定する。

以下の図面を参照して本解決手段を説明するが、図面全体を通して、同様の参照符号は同様の特徴を表す。

図１は、例示的なシステムの図である。

図２は、例示的なコンピューティングデバイスの図である。

図３は、従来の例示的なグラフィックス更新メッセージの図である。

図４は、例示的なグラフィックス更新メッセージの図である。

図５は、透かしの５つの可視インスタンスを有するデスクトップ画面の表示例の図である。

図６Ａ〜図６Ｃ（まとめて「図６」と称す。）は、リモートセッションにおける可視透かしを提供する例示的な方法のフロー図を示す。

図７は、例示的な全画面サイズ透かし画像の図である。

図８は、例示的な分割透かし画像の図である。

図９は、例示的なマーク付き分割透かし画像の図である。

図１０は、統合ブロックを有する例示的なマーク付き分割透かし画像の図である。

図１１は、例示的な透かしビットマップの図である。

本明細書で一般的に説明され、添付図面に示された実施形態の構成要素は、多種多様な異なる構成で配置及び設計され得ることが容易に理解されよう。したがって、図示されている様々な実施形態の以下のより詳細な説明は、本開示の範囲を限定するものではなく、様々な実施形態の単なる代表例である。実施形態の様々な態様が図示されているが、特に明示しない限り、図面は必ずしも縮尺通りに描かれていない。

本解決手段は、その精神又は本質的な特徴から逸脱することなく、他の特定の形態で具現化することができる。説明された実施形態は、あらゆる点で単なる例示にすぎず、限定的に解釈してはならない。したがって、本解決手段の範囲は、添付の特許請求の範囲によって示されるのであって、この詳細な説明には、なんら拘束されない。特許請求の範囲の均等物の意味及び範囲内における変更はすべて本解決手段の範囲内に包含されるべきである。

本明細書全体を通して、特徴、利点、又は類似の用語への言及は、本解決手段で実現され得る特徴及び利点のすべてが本解決手段の任意の単一の実施形態であるべきであることを意味しない。むしろ、特徴及び利点に言及する用語は、実施形態に関連して説明される特定の特徴、利点、又は特性が本解決手段の少なくとも１つの実施形態に含まれることを意味すると理解される。したがって、本明細書全体にわたる特徴及び利点、並びに類似の言語の議論は、必ずしもそうではないが、同じ実施形態を指す場合がある。

さらに、本解決手段に記載された特徴、利点、及び特性は、１つ以上の実施形態において任意の適切な方法で組み合わせることができる。当業者は、本明細書の説明に照らして、特定の実施形態の１つ以上の特定の特徴又は利点なしで本解決手段が実施可能であることを認識するであろう。他の例では、本解決手段のすべての実施形態で示されていない特定の実施形態において、追加の特徴及び利点が認識される場合がある。

本明細書全体を通して、「一実施形態」（one embodiment）、「実施形態」（an embodiment）、又は同様の文言への言及は、示された実施形態に関連して説明された特定の特徴、構造、又は特性が本解決手段の少なくとも１つの実施形態に含まれることを意味する。したがって、本明細書全体を通して、「一実施形態では」（in one embodiment）、「実施形態では」（in an embodiment）という文言、及び同様の文言は、必ずしもそうではないが、すべて同じ実施形態を指す場合がある。

本文書で用いられている単数形「a」、「an」、及び「the」は、文脈上特に明記されていない限り、複数形の言及を含む。別段に定義されていない限り、本明細書で用いられているすべての技術用語及び科学用語は、当業者によって一般に理解されるのと同じ意味を有する。本文書で用いられている「備える／有する」（comprising）という用語は「含むが、それに限定されない」（including, but not limited to）ことを意味する。

本解決手段は、リモートセッションにおける可視透かしを提供するシステム及び方法に関する。設置のし易さと、あらゆるエンドポイントソフトウェアと互換性があることと、サーバオンリーの解決手段はより安全であるという一般的な定説とにより、本解決手段は、サーバオンリーの解決手段として実施される（すなわち、エンドポイントの更新を要しない。）。

初期のサーバオンリーのプロトタイプは、ユーザのセッションにおける他のアプリケーションと並行して動作するユーザモードアプリケーションを含んでいた。ユーザモードアプリケーションは、所望の透かしテキストを含む全画面表示の部分的な透明ウィンドウを生成することによって、サーバのフレームバッファに透かしを適用していた。Desktop Window Manager（ＤＷＭ）は、全画面表示の部分的な透明ウィンドウ及び他のデスクトップウィンドウでアルファベースの合成を行い、所望の効果を生んでいた。そして、結果として得られたグラフィックスは、グラフィックスエンコーダ（ＧＥ）によって符号化され、エンドポイントに送信され、表示されていた。

初期のサーバオンリーのプロトタイプは以下の難点を有している：（１）ユーザモードの透かし処理を終えることができると、結果として、当該透かしが除去される；（２）結果として得られる、ＧＥにかけられたグラフィックス更新（入力画像）は、キャッシング又は圧縮に役立ついかなる性質をも示す可能性が極めて低く、これにより、必要とする全体のネットワーク回線容量が増加してしまう。難点（１）は、透かし処理に特別な許可を適用することで解決され得る。実験データは、Office生産性アプリケーションからなる５０分の自動作業負荷に対し、同一の作業負荷で透かしが存在しない場合に比べて、１５倍多い回線容量が使用されたことを示している。さらに、透かしが存在する符号化されたグラフィックスのあらゆるキャッシュ可能特性の欠如と複雑性により、７倍多いサーバＣＰＵも必要とされていた。

本解決手段は、初期のサーバオンリーのプロトタイプのサーバＣＰＵコスト及び上述のネットワーク回線容量に比べてわずかなコスト及び回線容量で、サーバオンリーの透かしを提供する手法を提示する。本解決手段は、以下の新しい特徴を有する：（１）設置のし易さ（純粋なサーバオンリーの解決手段）；（２）新たなプロトコルコマンドの導入が不要（あらゆる既存の受信機で動作する。）；（３）初期のサーバオンリーのプロトタイプ（１５倍増加）及び従来の他のサーバオンリーの解決手段に比べて低い回線容量の効果（２〜３倍増加）；（４）初期のサーバオンリーのプロトタイプ（７倍）及び従来の他のサーバオンリーの解決手段に比べて低いＣＰＵの効果（１．５〜２倍）。

専用の透かし処理によって透かしを提供し、Composition Manager（ＣＭ）に依拠して結果としての画像を与えるよりも、ＧＥを修正して、グラフィックス更新の通常の処理後に透かしの合成をする。当該処理は概して次の動作を含む。ＧＥ初期化時に、（管理者によって構成された所望の透かしテキスト及び／又は画像を有し部分的に透明な）全画面表示の透かしフレームバッファが計算される。次に、フレームバッファのどの部分に透かし情報が存在するのかを記述するビットマップが構築される。この計算とマップ構築動作は、ＧＥを初期化するたびに（例えば、モニタレイアウトを変更するときに）一度にまとめて動作すべきものである。そして、入力されたグラフィック更新に対し、通常のＧＥ動作が行われる。これらのＧＥ動作は、ネットワーク回線容量の使用を削減するために主にキャッシングと圧縮の最適化を伴う。エンドポイントに最新の画面更新（エンドオブフレーム（ＥＯＦ）コマンド）の表示を指示する前に、初期化時に構築されたビットマップを用いて、計算前の透かしフレームバッファでの任意の透かし情報とグラフィックス更新との共通部分が算出される。ビットマップは、透かしフレームバッファを複数のブロック（例えば、各々が１６×１６画素）として記述するので、影響を受ける領域は、以前に構築されたマップを用いて、Ｘ画素（例えば、１６画素）の高さの長方形のストリップとして計算される。グラフィックス更新がごく一部である場合、透かし全体を合成する必要はないため、現在の演算動作は、送信が必要な透かしの部分に効果的に絞られる。その後、これらのストリップに対してアルファブレンドの合成動作を行う。これは、“over”operationとしても知られており、入力画像と透かしの画素を結合することで、両画素を表す結合色が生成される。合成されたストリップは、無損失ランレングス符号化（ＲＬＥ）オーバーレイビットマップとして、エンドポイントに送信される。これらのビットマップは、他の無損失ビットマップ（キャッシュした）と同様に送信されるので、後で同一のビットマップが生成された場合に再利用され得る。そして、ＥＯＦコマンドが発行され、エンドポイントに全ての更新の表示を指示する。

本解決手段は、以下の利点を有する。あらゆるエンコーダ最適化は、依然として、何も損なわれていない入力グラフィックス更新に対して行われる。これにより、回線容量の使用が大幅に減少するだけでなく、最良のキャッシュの再利用及び圧縮の利益につなげることができる。サーバオンリーであるため、新たな機能を有効にするために、クライアントソフトウェア更新をする必要がない。余分なＣＰＵコストはオーバーオペレーション（over operation）の結果として生じるが、比較的安価な動作である。アルファブレンド動作によって形成された合成ビットマップはサーバ側で生成され、新たなプロトコルを必要としない。プロトコルについて言えば、これは、無損失のコーデック（例えば、Citrix lossless codes）を用いて圧縮される単なる通常のビットマップである。このアプローチは、新たなコマンドを導入しないので、デフォルトであらゆる既存のエンドポイントと互換性がある。透かしアプリケーションは、ＧＥ処理の一部として実施されるので、改ざんされることはない。ＧＥ処理が終了すると、エンドポイントに送信されるグラフィックス更新は一切なくなるので、自動的に安全である。

実験により、上述の同一の自動作業負荷に対して、回線容量の使用は、透かしが存在しない場合よりも約２〜３倍多く、ＣＰＵの使用は、約１．５〜２倍多いことが示されている。このことは、初期のプロトタイプ（１５倍多い回線容量）に対する大幅な減少を表している。クライアントソリューションに対して減少した安全性リスクと設置のし易さにより、２〜３倍の増加は顧客にとって許容可能であることが早期に示されている。

図１を参照すると、例示的なシステム１００の図が示されている。システム１００は、リモートセッションにおける可視透かしを提供する方法を実施する。これに関し、システム１００は、顧客設備１４０とクラウドサービスプロバイダ設備１４２とを備える。顧客設備１４０は、企業組織などの顧客の１つ以上の建物を備えている。顧客は、複数のエンドユーザ１０２_１〜１０２_Ｎを有する。エンドユーザとしては、従業員が挙げられるが、これに限定されない。エンドユーザ１０２_１〜１０２_Ｎは、それぞれ、クラウドサービスプロバイダによって提供されたクラウドサービスにアクセスして使用するなど、種々の目的のためにクライアントコンピューティングデバイス１０４_１〜１０４_Ｎを使用する。これに関し、クライアントコンピューティングデバイス１０４_１〜１０４_Ｎは、接続損失によって中断されることなく、アプリケーション及び仮想デスクトップへのアクセスを促進するように構成される。よって、クライアントコンピューティングデバイス１０４_１〜１０４_Ｎは、様々なソフトウェアアプリケーションをインストールしており、これらを実行する。これらのソフトウェアアプリケーションとして、ウェブブラウザ１１６_１〜１１６_Ｎ及び／又はウェブレシーバ１１８_１〜１１８_Ｎが挙げられるが、これに限定されない。

いくつかのシナリオでは、ウェブレシーバ１１８_１〜１１８_Ｎとして、それぞれ、フロリダ州のシトリックス・システムズ社から入手可能なCitrix Receiversと、フロリダ州のシトリックス・システムズ社から入手可能なウェブサイト用のCitrix Receiversとを挙げることができるが、これに限定されない。Citrix Receiversは、クライアントデバイスから離れたところにあるサーバによってホストされたアプリケーション及びフルデスクトップへのアクセスを要するクライアントソフトウェアを有する。この点に関して本解決手段は限定されない。

クライアントコンピューティングデバイス１０４_１〜１０４_Ｎはまた、内部に様々な情報を格納している。この情報として、アカウントレコード１２０_１〜１２０_Ｎが挙げられるが、これに限定されない。クライアントコンピューティングデバイス１０４_１〜１０４_Ｎは、イントラネットを介して互いに接続可能であり、インターネットを介して外部デバイスに接続可能である。イントラネット及びインターネットは、ネットワーク１０６として図１に示されている。

外部デバイスは、クラウドサービスプロバイダ設備１４２に設置された１つ以上のクラウドサービスサーバ１０８を有する。クラウドサービスプロバイダ設備１４２は、クラウドサービスプロバイダの１つ以上の建物を備えている。サーバ１０８は、接続損失によって中断されることなく、アプリケーション及び仮想デスクトップへのアクセスを促進するように構成される。よって、サーバ１０８は、様々なソフトウェアアプリケーションをインストールしており、これらを実行する。ソフトウェアアプリケーションとして、ストアフロント１２２及びデスクトップデリバリコントローラ（ＤＤＣ）１２４が挙げられるが、これに限定されない。ストアフロント及びＤＤＣは周知技術であるため、ここでの説明は省略する。ここでは、任意の知られた又は知られ得るストアフロント及び／又はＤＤＣを採用することができる。サーバ１０８は、さらに、発行情報１６０が格納されたデータストア１１０にアクセスするように構成され、データストア１１０から／への読み書きも可能である。発行情報１６０として、ソフトウェアアプリケーション、コード、メディアコンテンツ（例えば、テキスト、画像、映像など）、及び／又は透かし関連情報が挙げられるが、これに限定されない。

クラウドサービスサーバ１０８はまた、ＧＥ１２６を備える。ＧＥは周知技術であるため、ここでの詳細な説明は省略する。ここでは、任意の知られた又は知られ得るＧＥを、限定することなく用いることができる。例えば、ＧＥ１２６は、米国特許第９，７５４，３８５号（３８５特許）に記載されたＧＥを備える。３８５特許の開示内容は参照により本明細書に組み込まれる。この場合、３８５特許のＧＥは、本解決手段を実施するために本明細書で記載された１つ以上の動作を実行するように修正される（例えば、クライアントコンピューティングデバイスに対し、少なくとも１つの透かしを画面に表示させるようにする。）。

ＧＥ１２６は、概して、クライアントコンピューティングデバイス１０４_１〜１０４_Ｎとクラウドサービスサーバ１０８との間に確立されたセッションの期間に、クライアントコンピューティングデバイス１０４_１〜１０４_Ｎの表示画面にレンダリングされるクラウドサービスサーバ１０８の他の構成要素１２２及び１２４からのグラフィックス（例えば、アプリケーションウィンドウ、画像、アイコン、及び／又はその他のデスクトップ若しくはウィンドウの視覚的特徴）を受信するよう機能する。ＧＥ１２６は、受信したグラフィックスを解析し、クライアントコンピューティングデバイス１０４_１〜１０４_Ｎにグラフィックス更新を報告する必要があるか否かを判断する。報告する必要がある場合、ＧＥ１２６は、透かし情報付きのグラフィックス更新メッセージを作成し、ネットワーク１０６を介してウェブレシーバ１１８_１〜１１８_Ｎへ送信する。グラフィックス更新メッセージに応答して、ウェブレシーバ１１８_１〜１１８_Ｎは、グラフィックス更新メッセージに含まれるコマンドに従って、更新されたグラフィックスを構築し、画面に表示する。

従来のグラフィックス更新メッセージ３００の図を図３に示す。図３に示すように、従来のグラフィックス更新メッセージ３００は、複数のグラフィック更新コマンド３０２〜３０６とエンドオブフレーム（ＥＯＦ）コマンド３０８とを有する。グラフィック更新コマンド３０２〜３０６として、画面上の第１位置に新たな画像を描画するためのコマンド、画面上の第２位置に新たなテキストを描画するためのコマンド、画面上の第３位置にローカルキャッシュからの画像を描画するためのコマンド、及び／又は、画面のある部分を画面の別の部分へコピーするためのコマンドを挙げることができるが、これらに限定されない。いったん、画面更新のためにコマンド列が作成されると、ＥＯＦコマンド３０８がコマンド列の末尾に挿入される。ＥＯＦコマンド３０８は、ウェブレシーバに対し、グラフィック更新コマンド３０２〜３０６に従って所定のフレームのメモリに構成された更新されたグラフィックスを画面表示するよう指示するために設けられている。

図４を参照すると、ＧＥ１２６によって作成されたグラフィックス更新メッセージ４００が示されている。グラフィックス更新メッセージ４００は、従来のグラフィックス更新メッセージ３００に含まれている情報に対して追加された情報を有している。この点に関し、グラフィックス更新メッセージ４００は、複数のグラフィック更新コマンド４０２〜４０６とＥＯＦコマンド４１４とを有することを理解されたい。これらのコマンド４０２〜４０６、４１４は、従来のグラフィックス更新メッセージ３００のコマンド３０２〜３０６、３０８と同一又は類似である。グラフィックス更新メッセージ４００は、これらのコマンド４０２〜４０６、４１４に加えて、少なくとも１つの透かしベースのグラフィック更新コマンド４０８〜４１２を有している。透かしベースのグラフィック更新コマンド４０８〜４１２は、グラフィックのどの画素が透かしを有するべきなのか、及びこれらの画素に対する再計算されたカラー値を示す情報を含むが、これに限定されない。本解決手段は、この情報を画素の２次元配列（ビットマップ）としてコンパイルする。これらの画素は、透かしが現れない元の入力画像のカラー値、及び透かしが現れる再計算されたカラー値のものである。これらの追加の透かしベースのグラフィックス更新（オーバーレイ）を、従来のグラフィックス更新コマンドとして、フレームのグラフィックス更新メッセージに挿入することができ、これにより、エンドポイントが認識しない新たなコマンドは導入されない。

図５を参照すると、透かし５００の５つの可視インスタンスを有するデスクトップ画面の表示例の図が示されている。本解決手段は、図５の具体例に限定されない。例えば、任意の数の可視透かしインスタンスを、画面に表示された１つ以上のグラフィックスに設けることができる。また、透かしは、所定のアプリケーションに従って選択された任意の情報を含めることができる。例えば、各顧客（又は会社）は、種々のコンテンツ、テキスト又はその他のものを指定し、それぞれの透かしに含めるようにしてもよい。

図２を参照すると、コンピューティングデバイス２００の例示的なアーキテクチャの図が示されている。図１のコンピューティングデバイス１０４_１〜１０４_Ｎ及びサーバ１０８は、コンピューティングデバイス２００と同一又は類似である。したがって、コンピューティングデバイス２００の説明は、システム１００のこれらの構成要素を理解するのに十分である。

いくつかのシナリオにおいて、本解決手段は、クライアント−サーバアーキテクチャで用いられる。その結果、図２に示されたコンピューティングデバイスアーキテクチャは、クライアントコンピューティングデバイス及びサーバの詳細を理解するのに十分である。

コンピューティングデバイス２００の構成要素は、図２に示された構成要素よりも多くても少なくてもよい。しかしながら、図示されている構成要素は、本解決手段を実施する例示的な解決手段を開示するのに十分である。図２のハードウェアアーキテクチャは、本明細書に記載されているように、グラフィックスの透かしを可能とするように構成された代表的なコンピューティングデバイスの一実装例を表す。したがって、図２のコンピューティングデバイス２００は、本明細書に記載された方法の少なくとも一部を実施する。

コンピューティングデバイス２００の一部又は全ての構成要素は、ハードウェア、ソフトウェア、及び／又はハードウェアとソフトウェアとの組み合わせとして実現することができる。ハードウェアは１つ以上の電子回路を含むが、これに限定されない。電子回路として、受動素子（例えば、抵抗器及びコンデンサ）及び／又は能動素子（例えば、増幅器及び／又はマイクロプロセッサ）を挙げることができるが、これらに限定されない。受動素子及び／又は能動素子は、本明細書に記載された方法、手順、又は機能のうちの１つ以上を実行するように構成され、配置され、及び／又はプログラムされ得る。

図２に示すように、コンピューティングデバイス２００は、ユーザインターフェイス２０２と、中央処理装置（ＣＰＵ）２０６と、システムバス２１０と、システムバス２１０を介してコンピューティングデバイス２００の他の部分に接続されてアクセス可能なメモリ２１２と、システムバス２１０に接続されたハードウェアエンティティ２１４とを備える。ユーザインターフェイスには、入力デバイス及び出力デバイスを設けることができ、コンピューティングデバイス２００の動作を制御するためのユーザ−ソフトウェア相互作用を促す。入力デバイスとして、物理及び／又はタッチキーボード２５０が挙げられるが、これらに限定されない。入力デバイスは、有線接続又は無線接続（例えば、Bluetooth（登録商標）接続）を介してコンピューティングデバイス２００に接続され得る。出力デバイスとして、スピーカー２５２、ディスプレイ２５４、及び／又は発光ダイオード２５６が挙げられるが、これらに限定されない。

ハードウェアエンティティ２１４の少なくとも一部は、メモリ２１２へのアクセス及び使用を伴うアクションを実行する。メモリ２１２として、Random Access Memory（ＲＡＭ）、ディスクドライバ及び／又はCompact Disc Read Only Memory（ＣＤ-ＲＯＭ）が採用され得る。ハードウェアエンティティ２１４は、コンピュータ読み取り可能な記憶媒体２１８を有するディスクドライブユニット２１６を備えることができる。コンピュータ読み取り可能な記憶媒体２１８には、本明細書に記載された方法、手順、又は機能のうちの１つ以上を実行する１組以上の命令２２０（例えば、ソフトウェアコード）が格納されている。命令２２０は、コンピューティングデバイス２００によるＣＰＵ２０６の実行中にＣＰＵ２０６内に及び／又はメモリ２１２内に、完全に又は少なくとも部分的に常駐することもできる。メモリ２１２及びＣＰＵ２０６は、機械読み取り可能な媒体を構成することもできる。ここで「機械読み取り可能な媒体」とは、１組以上の命令２２０を格納する単一の媒体又は複数の媒体（例えば、集中型若しくは分散型データベース、及び／又は関連するキャッシュ及びサーバ）を指す。また、「機械読み取り可能な媒体」は、コンピューティングデバイス２００による実行のための命令２２０の組を格納、符号化、又は搬送することができ、且つ、コンピューティングデバイス２００に本開示の方法のいずれか１つ以上を実行させる任意の媒体も指している。

図６を参照すると、リモートセッションにおける可視透かしを提供する例示的な方法３００のフロー図が示されている。方法３００は、３０２で始まり、続いて３０４において、ウェブブラウザ（例えば、図１のウェブブラウザ１１６_１、…、又は１１６_Ｎ）が立ち上がる。ウェブブラウザは、クライアントコンピューティングデバイス（例えば、図１のクライアントコンピューティングデバイス１０４_１、…、又は１０４_Ｎ）にインストールされている。そして、６０６で、リモートサーバ（例えば、図１のクラウドサービスサーバ１０８）によって提供されたウェブサービスにアクセスするためにブラウザタブを開く。次に、６０８で、デバイス識別子及び少なくとも１つの画面サイズを、クライアントコンピューティングデバイスからリモートサーバへ送信する。リモートサーバがこの情報を受信したことに応答して、６１０に示すように、リモートサーバのＧＥ（例えば、図１のＧＥ１２６）を初期化する。

このとき、リモートサーバは、動作６１２〜６２２を実行して、少なくとも１つの透かしビットマップを生成する。６１２では、ＧＥによって、デバイス識別子を用いてデータストア（例えば、図１のデータストア１１０）から予め定義された透かしパラメータ情報を読み出す。透かしパラメータ情報として、透かしのコンテンツ（例えば、アイコン、テキスト又はその他の記号）を指定する情報、全画面サイズ透かし画像に含まれる透かしインスタンスの数を指定する情報、及び／又は、全画面サイズ透かし画像内の透かしインスタンスの相対的位置を指定する情報を挙げることができるが、これらに限定されない。６１４において、画面サイズ及び読み出された予め定義された透かしパラメータ情報は、ＧＥからリモートサーバの透かしジェネレータ（例えば、図１の透かしジェネレータ１２８）へ送信される。そして、透かしジェネレータは、６１６において、画面サイズ及び予め定義された透かしパラメータ情報に従って、少なくとも１つの全画面サイズ透かし画像（例えば、白色背景又は黒色背景に少なくとも１つの透かしインスタンス）を生成する動作を実行する。

図７に、例示的な全画面サイズ透かし画像７００の図を示す。全画面サイズ透かし画像７００は、以下の透かしの４つのインスタンスを有する。
mdadmin@BMWIN7X64
21:43:41 30/08/2017
透かしインスタンスは、画像７００内の異なる箇所に位置している。画像７００はまた、白色背景を有する。本解決手段は、当該図の具体例に限定されない。例えば、全画面サイズ透かし画像には、任意の数の透かしインスタンスを含めることができる。また、透かしは、特定のアプリケーションに従って選択された任意のコンテンツを含めることができる。

次の６１８において、全画面サイズ透かし画像は、透かしジェネレータからＧＥへ送信される。そして、ＧＥは、６２０において、全画面サイズ透かし画像のどこに透かしインスタンスが存在するかを判断する動作を実行する。いくつかのシナリオにおいて、この判断は、各全画面サイズ透かし画像を複数の同一サイズのブロックに分割することによってなされる。図８に、例示的な分割透かし画像８００の図を示す。分割透かし画像８００は複数のブロック８０２からなる。各ブロック８０２のサイズはＸ画素×Ｘ画素である。ここで、Ｘは整数（例えば、１６）である。次いで、分割透かし画像８００を解析して、どのブロック８０２が透かしインスタンスの一部を含んでいるのかを特定する。そして、特定されたブロックにマークを付ける。ここでは、マーク付きブロックを参照符号８０４で表し、マークなしブロックを参照符号８０６で表す。次に、ＧＥは、統合ブロック１００２を有するマーク付き分割透かし画像１０００を生成する動作を実行する。各統合ブロック１００２は、通常、複数の隣接するマーク付きブロック８０４によって定義された長方形であるため、正方形のブロック８０４よりも大きいブロックを構成する。この点に関して本解決手段は限定されない。統合ブロック１００２は長方形以外の形をとってもよい。

そして、６２２において透かしビットマップを生成する。透かしビットマップは、統合ブロック１００２の特色を用いて生成することができる。図１１に、例示的な透かしビットマップ１１００の図を示す。透かしビットマップ１１００は、各統合ブロック１００２に含まれる各画素のビット値を指定する情報を含むテーブルを含めることができるが、これに限定されない。画素値０は、オーバーレイされた透かしの結果として画素のカラー値が変化しなかったことを意味する。画素値１は、オーバーレイされた透かしの結果として画素のカラー値が変化したことを意味する。本解決手段は、このシナリオの具体例に限定されない。

再度図６Ａを参照すると、６２４において、クライアントコンピューティングデバイスとリモートサーバとの間のセッションを確立する。セッションを確立する手法は周知技術であるため、ここでの説明は省略する。ここでは、任意の知られた又は知られ得るセッション確立手法を、限定することなく用いることができる。

セッションの期間中、ＧＥはリモートサーバの他の構成要素（例えば、グラフィックスカードドライバ）からグラフィックスを受け取る。６２８において、ＧＥは、グラフィックスを解析して、少なくとも１つのグラフィックの更新をクライアントコンピューティングデバイスに伝達する必要があるか否かを判断する動作を実行する。伝達する必要があれば、方法６００は図６Ｂの６３０に移行する。

図６Ｂに示すように、６３０では、ＧＥによって、第１グラフィックス更新メッセージ（例えば、図３のグラフィックス更新メッセージ３００）を作成する。第１グラフィックス更新メッセージは、グラフィックを更新するための第１コマンド列（例えば、図３のコマンド３０２〜３０６）とＥＯＦコマンド（例えば、図３のＥＯＦコマンド３０８）とを有する。第１コマンド列として、画面上の第１位置に新たな画像を描画するためのコマンド、画面上の第２位置に新たなテキストを描画するためのコマンド、画面上の第３位置にローカルキャッシュからの画像を描画するためのコマンド、及び／又は、画面のある部分を画面の別の部分へコピーするためのコマンドを挙げることができるが、これらに限定されない。

次に、６３２において、ＧＥは、透かしビットマップを用いて、オーバーレイされた場合に透かしの影響を受けるグラフィックの画素があるか否かを判断する。この判断は、画面上の統合ブロック１００２の位置に表示されるグラフィックの部分を特定することによって行うことができる。実際に部分が特定された場合、オーバーレイされた透かしの影響を受けるグラフィックの画素があると判断する。部分が特定されなかった場合、オーバーレイされた透かしの影響を受けるグラフィックの画素がないと判断する。

グラフィックの１つ以上の画素がオーバーレイされた透かしの影響を受けない場合［６３４：ＮＯ］、方法６００は６３６に移行し、第１グラフィックス更新メッセージをリモートサーバのＧＥからクライアントコンピューティングデバイスのウェブレシーバ（例えば、図１のウェブレシーバ１１８_１、…、１１８_Ｎ）へ送信する。そして、ウェブレシーバは、６３８において、第１グラフィックス更新メッセージに含まれる第１コマンド列に従って、所定のフレームのメモリ（例えば、図２のメモリ２１２）に更新されたグラフィックを構成する動作を実行する。更新されたグラフィックをメモリに構成する手法は周知技術であるため、ここでの説明は省略する。ここでは、更新されたグラフィックをメモリに構成するための任意の知られた又は知られ得る手法を、限定することなく用いることができる。そして、６４０に示すように、第１グラフィックス更新メッセージに含まれるＥＯＦコマンドに応答して、ウェブレシーバによって、更新されたグラフィックを画面に表示する。次いで、方法６００を終了するか又は他の処理を実行する６４２を行う。

グラフィックの１つ以上の画素がオーバーレイされた透かしの影響を受ける場合［６３４：ＹＥＳ］、方法６００は図６Ｂの６４４に移行し、ＧＥによって、透かしビットマップを用いて、オーバーレイされた場合に透かしの影響を受けるグラフィックの画素を特定する。ＧＥは、（ａ）マーク付き分割全画面透かし画像の統合ブロックの位置と、（ｂ）グラフィックが表示されるフルサイズ画面上の位置とを認識しているので、１つ以上の統合ブロックの画素と同じ位置にあるグラフィックの画素を特定することができる。６４６に示すように、６４４で特定された画素について新たなカラー値を計算する。各カラー値は、Red、Green及びBlue（ＲＧＢ）値によって定義される。この計算において、グラフィック画素のＲＧＢカラー値とそれぞれの透かし画素のＲＧＢカラー値とを組み合わせてもよい。

次の６４８において、ＧＥは、６４６で計算された新たなカラー値に従って、特定された画素を修正するための第２コマンド列（例えば、図４のコマンド４０８、…、４１２）を作成する動作を実行する。第２コマンド列は、グラフィックのどの画素が透かしを有するべきなのか、及びこれらの画素に対する再計算されたカラー値を示す情報を含むが、これに限定されない。

そして、６５０では、第２コマンド列を用いて第２グラフィックス更新メッセージ（例えば、図４のグラフィックス更新メッセージ４００）を作成する。第２グラフィックス更新メッセージは、第１グラフィックス更新メッセージの第１コマンド列とＥＯＦコマンドとの間に第２コマンド列を挿入することによって作成される。６５２において、第２グラフィックス更新メッセージをＧＥからウェブレシーバへ送信する。

ウェブレシーバでは、６５４に示すように、第２グラフィックス更新メッセージに含まれる第１コマンド列に従って、所定のフレームのメモリに更新されたグラフィックを構成する。そして、６５６に示すように、ウェブレシーバは、第２グラフィックス更新メッセージに含まれる第２コマンド列に従って、構成された更新されたグラフィックを修正することで透かしを含めるようにする。６５８では、第２グラフィックス更新メッセージに含まれるＥＯＦコマンドに応答して、透かし付の構成された更新されたグラフィックを画面に表示する。次いで、方法６００を終了するか又は他の処理を実行する６６０を行う。

本解決手段を１つ以上の実施に関して図示及び説明したが、本明細書及び添付図面を読んで理解すると、同等の変更及び変形例が当業者に想到されるであろう。さらに、本解決手段の特定の特徴は、いくつかの実施のうちの１つのみに関して開示されている可能性があるが、そのような特徴は、任意の又は特定の用途にとって望ましく有利であるように他の実施の１つ以上の他の特徴と組み合わせることができる。したがって、本解決手段の広さ及び範囲は、上述の実施形態のいずれによっても限定されるべきではない。むしろ、本解決手段の範囲は、添付の特許請求の範囲及びそれらの均等物に従って定義されるべきである。

図６を参照すると、リモートセッションにおける可視透かしを提供する例示的な方法６００のフロー図が示されている。方法６００は、６０２で始まり、続いて６０４において、ウェブブラウザ（例えば、図１のウェブブラウザ１１６_１、…、又は１１６_Ｎ）が立ち上がる。ウェブブラウザは、クライアントコンピューティングデバイス（例えば、図１のクライアントコンピューティングデバイス１０４_１、…、又は１０４_Ｎ）にインストールされている。そして、６０６で、リモートサーバ（例えば、図１のクラウドサービスサーバ１０８）によって提供されたウェブサービスにアクセスするためにブラウザタブを開く。次に、６０８で、デバイス識別子及び少なくとも１つの画面サイズを、クライアントコンピューティングデバイスからリモートサーバへ送信する。リモートサーバがこの情報を受信したことに応答して、６１０に示すように、リモートサーバのＧＥ（例えば、図１のＧＥ１２６）を初期化する。

グラフィックの１つ以上の画素がオーバーレイされた透かしの影響を受ける場合［６３４：ＹＥＳ］、方法６００は図６Ｃの６４４に移行し、ＧＥによって、透かしビットマップを用いて、オーバーレイされた場合に透かしの影響を受けるグラフィックの画素を特定する。ＧＥは、（ａ）マーク付き分割全画面透かし画像の統合ブロックの位置と、（ｂ）グラフィックが表示されるフルサイズ画面上の位置とを認識しているので、１つ以上の統合ブロックの画素と同じ位置にあるグラフィックの画素を特定することができる。６４６に示すように、６４４で特定された画素について新たなカラー値を計算する。各カラー値は、Red、Green及びBlue（ＲＧＢ）値によって定義される。この計算において、グラフィック画素のＲＧＢカラー値とそれぞれの透かし画素のＲＧＢカラー値とを組み合わせてもよい。

Claims (20)

1. リモートセッションにおける可視透かしを提供する方法であって、
   サーバにより、前記リモートセッションの期間に、クライアントコンピューティングデバイスでグラフィック更新をする必要があるか否かを判断する動作を実行し、
   前記クライアントコンピューティングデバイスでグラフィック更新をする必要があるという判断に応答して、グラフィックを更新するための第１コマンド列とエンドオブフレーム（ＥＯＦ）コマンドとを有する第１グラフィック更新メッセージを作成し、
   前記グラフィック及び少なくとも１つの透かしの双方が前記クライアントコンピューティングデバイスの画面に表示された場合、前記少なくとも１つの透かしの影響を受ける前記グラフィックの画素を特定し、
   以前に特定された前記画素の各々の新たなカラー値を指定する第２コマンド列を構成し、
   前記第１コマンド列と前記ＥＯＦコマンドとの間に前記第２コマンド列を挿入することによって、前記第１グラフィック更新メッセージを第２グラフィック更新メッセージに変換し、
   前記第２グラフィック更新メッセージを前記サーバから前記クライアントコンピューティングデバイスへ送信する、方法。
2. 前記方法は、前記サーバのグラフィックスエンコーダによって実行される、請求項１に記載の方法。
3. 前記クライアントコンピューティングデバイスのデバイス識別子を用いて、データストアからそれぞれの予め定義された透かしパラメータ情報を取得することをさらに含む、請求項１に記載の方法。
4. 前記取得されたそれぞれの予め定義された透かしパラメータ情報と前記クライアントコンピューティングデバイスの既知の画面サイズとに基づいて、少なくとも１つの全画面サイズ透かし画像を生成することをさらに含む、請求項３に記載の方法。
5. 前記少なくとも１つの全画面サイズ透かし画像は、白色背景又は黒色背景に透かしの少なくとも１つのインスタンスを有する、請求項４に記載の方法。
6. 透かしが存在する前記少なくとも１つの全画面サイズ透かし画像の領域を特定することをさらに含む、請求項４に記載の方法。
7. 前記領域の特定は、
   前記少なくとも１つの全画面サイズ透かし画像を複数の同一サイズのブロックに分割し、
   前記複数の同一サイズのブロックのうちどのブロックが前記透かしの一部を含んでいるのかを特定すること
   によってなされる、請求項６に記載の方法。
8. 前記領域の特定は、さらに、前記特定されたブロックの隣接するブロックを統合して、より大きなブロックを生成することによってなされる、請求項７に記載の方法。
9. （ａ）前記透かしが存在する前記少なくとも１つの全画面サイズ透かし画像の前記特定された領域を示し、且つ（ｂ）前記特定された領域のどの画素が前記透かしを有するのかを示す透かしビットマップを生成することをさらに含む、請求項６に記載の方法。
10. 前記グラフィック及び前記透かしの双方が前記クライアントコンピューティングデバイスの画面に表示されたとき、前記透かしビットマップを用いて、前記透かしの影響を受ける前記グラフィックの前記画素を特定する、請求項７に記載の方法。
11. 少なくとも１つの処理構成要素と、
    リモートセッションにおける可視透かしを提供する方法を前記少なくとも１つの処理構成要素に実施させるためのプログラミング命令を有する非一時的なコンピュータ読み取り可能な記憶媒体と、
    を備えるシステムであって、
    前記プログラミング命令は、
    前記リモートセッションの期間に、クライアントコンピューティングデバイスでグラフィック更新をする必要があるか否かを判断し、
    前記クライアントコンピューティングデバイスでグラフィック更新をする必要があるという判断に応答して、グラフィックを更新するための第１コマンド列とエンドオブフレーム（ＥＯＦ）コマンドとを有する第１グラフィック更新メッセージを作成し、
    前記グラフィック及び少なくとも１つの透かしの双方が前記クライアントコンピューティングデバイスの画面に表示された場合、前記少なくとも１つの透かしの影響を受ける前記グラフィックの画素を特定し、
    以前に特定された前記画素の各々の新たなカラー値を指定する第２コマンド列を構成し、
    前記第１コマンド列と前記ＥＯＦコマンドとの間に前記第２コマンド列を挿入することによって、前記第１グラフィック更新メッセージを第２グラフィック更新メッセージに変換し、
    前記第２グラフィック更新メッセージを前記クライアントコンピューティングデバイスへ送信させるための命令を有する、システム。
12. 前記処理構成要素はグラフィックスエンコーダを備える、請求項１１に記載のシステム。
13. 前記プログラミング命令は、前記クライアントコンピューティングデバイスのデバイス識別子を用いて、データストアからそれぞれの予め定義された透かしパラメータ情報を取得するための命令をさらに有する、請求項１１に記載のシステム。
14. 前記プログラミング命令は、前記取得されたそれぞれの予め定義された透かしパラメータ情報と前記クライアントコンピューティングデバイスの既知の画面サイズとに基づいて、少なくとも１つの全画面サイズ透かし画像を生成するための命令をさらに有する、請求項１３に記載のシステム。
15. 前記少なくとも１つの全画面サイズ透かし画像は、白色背景又は黒色背景に透かしの少なくとも１つのインスタンスを有する、請求項１４に記載のシステム。
16. 前記プログラミング命令は、透かしが存在する前記少なくとも１つの全画面サイズ透かし画像の領域を特定するための命令をさらに有する、請求項１４に記載のシステム。
17. 前記領域の特定は、
    前記少なくとも１つの全画面サイズ透かし画像を複数の同一サイズのブロックに分割し、
    前記複数の同一サイズのブロックのうちどのブロックが前記透かしの一部を含んでいるのかを特定すること
    によってなされる、請求項１６に記載のシステム。
18. 前記領域の特定は、さらに、前記特定されたブロックの隣接するブロックを統合して、より大きなブロックを生成することによってなされる、請求項１７に記載のシステム。
19. 前記プログラミング命令は、（ａ）前記透かしが存在する前記少なくとも１つの全画面サイズ透かし画像の前記特定された領域を示し、且つ（ｂ）前記特定された領域のどの画素が前記透かしを有するのかを示す透かしビットマップを生成するための命令をさらに有する、請求項１６に記載のシステム。
20. 前記グラフィック及び前記透かしの双方が前記クライアントコンピューティングデバイスの画面に表示されたとき、前記透かしビットマップを用いて、前記透かしの影響を受ける前記グラフィックの前記画素を特定する、請求項１７に記載のシステム。