JP2006338531A - 画面共有サーバ装置、画面共有方法、画面共有サーバプログラム及び記録媒体 - Google Patents

Abstract

【課題】 画面情報の共有を適切に制限することのできる画面共有サーバ装置、画面共有方法、画面共有サーバプログラム及び記録媒体の提供を目的とする。
【解決手段】 表示装置に表示させる画面情報が記録された第一のメモリ領域より該画面情報を取得し、取得された画面情報をネットワークを介して接続する他のコンピュータに送信することにより前記他のコンピュータに前記画面情報を共有表示させる画面共有サーバ手段と、前記他のコンピュータに共有表示させない非共有画面の画面情報について前記第一のメモリ領域への記録は行わないで前記表示装置に表示させる非共有表示制御手段とを有することによる上記課題を解決する。
【選択図】 図８

Description

本発明は、画面共有サーバ装置、画面共有方法、画面共有サーバプログラム及び記録媒体に関し、特にネットワークを介して接続する他のコンピュータと画面共有を行う画面共有サーバ装置、画面共有方法、画面共有サーバプログラム及び記録媒体に関する。

ネットワークを介して接続しているコンピュータ間において画面情報を共有する技術としてＶＮＣ（Virtual Network Computing）が知られている。ＶＮＣによれば、画面共有サーバのディスプレイに表示されている画面情報を画面共有クライアントのディスプレイに表示させることができる。したがって、画面共有クライアントのユーザは、画面共有サーバのディスプレイに表示されている画面情報と同様の画面情報を見ながら、画面共有サーバを遠隔操作することができる（例えば、特許文献１）。

ＶＮＣを実現するためのソフトウェアは、例えば、ＵｌｔｒａＶＮＣ（http://ultravnc.sourceforge.net/）（以下「従来例１」という。）、Ｍｉｃｒｏｓｏｆｔ（登録商標）社のＮｅｔＭｅｅｔｉｎｇ（以下「従来例２」という。）、及びＭｅｔａＶＮＣ（http://sourceforge.net/projects/metavnc/、http://metavnc.sourceforge.net/index-j.html）（以下「従来例３」という。）等、各種提供されている。
特開平１１−６５９７５号公報

しかしながら、画面共有サーバの画面情報の一部については、画面共有クライアントには参照させたくない場合がある。例えば、電子メールを表示させるメーラのように、個人的な情報を表示対象とするアプリケーションウィンドウ等である。

かかる事情を考慮して、従来例１や従来例２には、画面共有の対象とさせたいウィンドウだけを選択する機能があるが、共有対象とするウィンドウの切り替え操作が煩雑であるという問題がある。

また、従来例３は、デスクトップの背景領域をクライアント側に共有表示しない機能を実現している。このソフトウェアは、Ｗｉｎｄｏｗｓ（登録商標）のリージョン関数を用いて画面共有クライアントのウィンドウの形を刳り貫いていくことによって、非共有化を実現している。しかし、この方式では、ウィンドウの移動時に処理効率が悪いという問題がある。

また、共有ウィンドウと共有したくないウィンドウ（非共有ウィンドウ）が重なっている場合に共有表示が適切に行われないことがあるという問題がある。

図１は、共有ウィンドウと非共有ウィンドウとが重なっている様子を示す図である。図１において、デスクトップ画面ｄ５０１、デスクトップ画面ｄ５０２は、それぞれ画面共有サーバ側、画面共有クライアント側のデスクトップ画面を示す。ウィンドウｗ５０１は共有表示されており、デスクトップ画面ｄ５０１及びデスクトップ画面ｄ５０２に表示されている。一方、ウィンドウｗ５０２は非共有とされており、デスクトップ画面ｄ５０１には表示されているが、デスクトップ画面ｄ５０２には表示されていない。このような状況において、ウィンドウｗ５０１とウィンドウｗ５０２との重複領域ａ１がデスクトップ画面ｄ５０２において適切に表示されない場合がある。

また、特許文献１は、非共有領域を塗りつぶす第一の方法と、デスクトップ画面の画面情報をキャッシュしておいて、非共有とされたウィンドウが新たに表示された場合は新しいウィンドウの画面情報をクライアントに送信せずに、キャッシュされた古い画面情報のままにする第二の方法とを採用している。

しかし、第一の方法は、ウィンドウを隠していることが分かってしまう欠点があり、これは当文献中でも指摘されている。

また、第二の方法は、第一の方法の問題点を改善するために考えられた方式であるが、現実的には共有又は非共有ウィンドウを移動させた場合や、大きさを変更した場合に、画面共有クライアントに送信するための画面情報の計算処理に時間がかかると共に、必ずしも意図通りの画面情報を生成できない場合がある。その場合、画面共有クライアントは、崩れた画面情報を受け取る可能性がある。

本発明は、上記の点に鑑みてなされたものであって、画面情報の共有を適切に制限することのできる画面共有サーバ装置、画面共有方法、画面共有サーバプログラム及び記録媒体の提供を目的とする。

そこで上記課題を解決するため、本発明は、表示装置に表示させる画面情報が記録された第一のメモリ領域より該画面情報を取得し、取得された画面情報をネットワークを介して接続する他のコンピュータに送信することにより前記他のコンピュータに前記画面情報を共有表示させる画面共有サーバ手段と、前記他のコンピュータに共有表示させない非共有画面の画面情報について前記第一のメモリ領域への記録は行わないで前記表示装置に表示させる非共有表示制御手段とを有することを特徴とする画面共有サーバ装置として構成される。

また、上記課題を解決するため、本発明は、上記画面共有サーバ装置における画面共有方法、前記画面共有方法をコンピュータに実行させるための画面共有プログラム、又は前記画面共有プログラムを記録した記録媒体としてもよい。

本発明によれば、画面情報の共有を適切に制限することのできる画面共有サーバ装置、画面共有方法、画面共有サーバプログラム及び記録媒体を提供することができる。

以下、図面に基づいて本発明の実施の形態を説明する。本実施の形態では、ＶＮＣ（Virtual Network Computing）と呼ばれる技術を利用する。ＶＮＣとは、ネットワークを介して接続している他のコンピュータの画面を遠隔操作するための技術である。

図２は、ＶＮＣの動作原理を説明するための図である。図２において、サーバＰＣ５１０とクライアントＰＣ５２０とがＬＡＮ（Local Area Network）等のネットワークを介して接続されている。サーバＰＣ５１０には画面共有サーバ５１２が、クライアントＰＣ５２０には画面共有クライアント５２２が、それぞれ実装されている。

画面共有サーバ５１２は、サーバＰＣ５１０の表示装置に表示されている画面データをクライアントＰＣ５２０に提供するためのソフトウェアであり、画面データ取得部５１２１、画面データ送信部５１２２、入力イベント受信部５１２３及び入力イベント生成部５１２４等の機能を有する。

画面共有クライアント５２２は、サーバＰＣ５１０の表示装置に表示されている画面データをクライアントＰＣ５２０の表示装置に表示させるためのソフトウェアであり、画面データ受信部５２２１、画面データ表示部５２２２、入力イベント取得部５２２３、及び入力イベント送信部５２２４等の機能を有する。

サーバＰＣ５１０におけるＯＳ通信部５１１、及びクライアントＰＣ５２０におけるＯＳ通信部５２１は、それぞれのＯＳによって提供される、所定のプロトコル（例えば、ＴＣＰ／ＩＰ）によって通信を行うためのプログラムモジュールである。

サーバＰＣ５１０の表示装置に表示されている画面データは、ＯＳを介して画面データ取得部５１２１によって取得され、画面データ送信部５１２２によって画面共有クライアント５２２に送信される。

クライアントＰＣ５２０において、画面共有サーバ５１２からの画面情報は、画面データ受信５２２１によって受信され、画面データ表示部５２２２によってクライアントＰＣ５２０の表示装置に表示される。

クライアントＰＣ５２０において表示された画面に対してマウス又はキーボード等による入力がなされると、その操作イベントは、入力イベント取得部５２２３によって検出され、入力イベント送信部５２２４によって画面共有サーバ５１２に送信される。

サーバＰＣ５１０において、画面共有クライアント５２２からの操作イベントは、入力イベント受信部５１２３によって受信され、入力イベント生成部５１２４によってＯＳに通知される。

このようにして、クライアントＰＣ５２０において、サーバＰＣ５１０の画面を遠隔操作することができる。したがって、例えば、サーバＰＣ５１０において起動されているアプリケーションの操作等をクライアントＰＣ５２０において行うことができる。

なお、画面共有サーバ５１２が画面データを取得して送信する際には、逐一全画面の画面情報を送信するのではなく、画面の差分情報のみを取得及び送信する。これによって、送信データ及び画面共有クライアント５２２の処理負荷が軽減され、動作の高速化が図られている。

以下、本実施の形態において「画面共有サーバ」又は「画面共有クライアント」というときは、画面共有サーバ５１２又は画面共有クライアント５２２と同様の機能を有するソフトウェアモジュール、又は当該ソフトウェアモジュールがインストールされたコンピュータをいうものとする。

図３は、本発明の実施の形態における画面共有システムの構成例を示す図である。図３において画面共有システム１は、ＬＡＮ（Local Area Network）又はインターネット等のネットワーク５０（有線又は無線の別は問わない。）を介して相互に接続されているＰＣ（Personal Computer）１０ａ、１０ｂ、１０ｃ、及び１０ｄ等（以下、これらのＰＣを総称する場合「ＰＣ１０」という。）より構成されている。各ＰＣ１０には画面共有機能が実装されている。

図４は、本発明の実施の形態におけるＰＣのハードウェア構成例を示す図である。本実施の形態における各ＰＣ１０は、それぞれバスＢで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、演算処理装置１０４と、インタフェース装置１０５と、表示装置１０６と、入力装置１０７と等を有するように構成される。

ＰＣ１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムが記録された記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。

補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。演算処理装置１０４は、メモリ装置１０３に格納されたプログラムに従ってＰＣ１０に係る機能を実行する。インタフェース装置１０５は図２のネットワーク５０に接続するためのインタフェースとして用いられる。

表示装置１０６はプログラムによるＧＵＩ等を表示する。入力装置１０７はキーボード及びマウス等で構成され、様々な操作指示を入力するために用いられる。

図５は、第一の実施の形態の各ＰＣにおける画面共有機能の機能構成例を示す図である。図５において、ＰＣ１０における画面共有機能は、画面共有サーバ１１、画面共有クライアント１２、共有ＰＣ管理部１３、及び共有制御部１４等より構成されている。

画面共有サーバ１１は、図２において説明した画面共有サーバ５１２に相当し、当該ＰＣ１０の表示装置１０６に表示されている画面情報を他のＰＣ１０に提供する。なお、画面共有サーバ１１における画面データ取得部１１１、画面データ送信部１１２、入力イベント受信部１１３、入力イベント生成部１１４は、それぞれ図２の画面データ取得部５１２１、画面データ送信部５１２２、入力イベント受信部５１２３、及び入力イベント生成部５１２４に相当する。

画面共有クライアント１２は、図２において説明した画面共有クライアント５２２に相当し、他のＰＣ１０の表示装置１０６に表示されている画面情報を当該ＰＣ１０の表示装置１０６に表示させる。なお、画面共有クライアント１２における画面データ受信部１２１、画面データ表示部１２２、入力イベント取得部１２３、入力イベント送信部１２４は、それぞれ図２の画面データ受信部５２２１、画面データ表示部５２２２、入力イベント取得部５２２３、入力イベント送信部５２２４に相当する。

共有ＰＣ管理部１３は、共有接続管理部１３１、メンバ管理部１３２、及び操作管理部１３３等より構成される。

共有接続管理部１３１は、どのＰＣ１０の画面をどのＰＣ１０に共有させるかを管理する。メンバ管理部１３２は、例えば、ＰＣ１０のＩＰアドレスとユーザとの組み合わせに対して参照（共有）権限の有無を管理する。操作権管理部１３３は、当該ＰＣ１０が画面共有サーバである場合は、現在接続している各画面共有クライアント（各ＰＣ１０）の共有ウィンドウに対する操作権の有無を管理する。一方、当該ＰＣ１０が画面共有クライアントである場合は、現在接続している画面共有サーバに対する操作権の有無を管理する。すなわち、共有表示された画面共有クライアント側には当然に操作権が認められるわけではなく、操作権が許可された画面共有クライアントのみが共有画面を遠隔操作することができる。

これらの各部によって、共有ＰＣ管理部１３は、メンバ管理部１３２で管理されている各ＰＣ１０のＩＰアドレスとＰＣ１０のユーザに関する情報に基づいて、共有接続管理部１３１がいずれのＰＣ１０の画面をいずれのＰＣに対して共有表示するかを管理する。例えば、ＰＣ１０ａの画面を他のＰＣ１０の全てに共有表示を行ったり、ＰＣ１０ｄにプロジェクタが接続されている場合に、ＰＣ１０ｄのみに共有表示させたりすることを制御する。

共有制御部１４は、ウィンドウ監視部１４１、ウィンドウ管理部１４２、及びレイや属性設定部１４３等より構成される。

ウィンドウ監視部１４１は、画面共有の開始後に、表示装置１０６にどのようなウィンドウが表示されているのか、また、どのようなウィンドウが表示されようとしているのか等、ウィンドウの状態を監視する。ウィンドウ管理部１４２は、どのメンバ（ＰＣ１０）にどのウィンドウの共有を許可するかを管理する。共有の許否の判定は、予め設定されている設定情報に基づいて行われる。設定情報の具体例については後述する。レイヤ属性設定部１４３は、ウィンドウ管理部１４２によって共有が禁止されたウィンドウ（以下「非共有ウィンドウ」という。）のＬａｙｅｒ属性（レイヤ属性）を変更することにより、非共有ウィンドウが他のＰＣ１０に共有（表示）されることを防止する。なお、レイヤ属性とは、透過率を指定してウィンドウを半透明にしたり、特定の色を透明色として任意のウィンドウの１色を透明にしたりするためにウィンドウに付与される属性である。ウィンドウにレイヤ属性を付与したり、状態を変化させたりするにはＳｅｔＷｉｎｄｏｗＬｏｎｇ関数でウィンドウの拡張スタイルにＷＳ_ＥＸ_ＬＡＹＥＲＥＤ追加し、ＳｅｔＬａｙｅｒｅｄＡｔｔｒｉｂｕｔｅｓ関数やＵｐｄａｔｅＬａｙｅｒｄＷｉｎｄｏｗ関数等のＡＰＩ（Application Program Interface）を用いればよい。

レイヤ属性設定部１４３による非共有ウィンドウを実現するための原理について図６、図７、及び図８を用いて説明する。Ｗｉｎｄｏｗｓ（登録商標）ＯＳ（Operating System）においてレイヤ属性を持つウィンドウは、仮想的なメモリ領域においてデスクトップ描画メモリ領域とは別のメモリ領域（以下「レイヤ属性ウィンドウ描画メモリ領域」という。）を使って描画（記録）が行われる。ここで、デスクトップ描画メモリ領域とは、通常デスクトップ画面上に表示されるウィンドウが描画（記録）されるメモリ領域をいう。

図６は、仮想的なメモリ空間上におけるデスクトップ描画メモリ領域とレイヤ属性ウィンドウ描画メモリ領域との配置例を示す図である。図６に示されるように、例えば、メモリ領域１０３１が、デスクトップ描画メモリ領域、すなわち、通常のデスクトップ描画用のデバイスコンテキストのメモリ領域として用いられている場合、レイヤ属性ウィンドウ描画メモリ領域、すなわち、レイヤ属が付与されたウィンドウのデバイスコンテキストのメモリ領域は、メモリ領域１０３２のように、デスクトップ描画メモリ領域とは異なる領域に配置される。

図７は、デスクトップ描画メモリ領域とレイヤ属性ウィンドウ描画メモリ領域との用い方を説明するための図である。図７に示されるように、ＯＳ２１は、デスクトップ描画メモリ領域１０３１における画面情報と、レイヤ属性１０３２における透明等の特殊な効果を有する画面情報とを合成し、合成された画面情報をディスプレイドライバ２２を介してＶＲＡＭ（Video RAM ）２３に書き込む。ＶＲＡＭ２３に書き込まれた画面情報は、表示装置１０６に表示される。

ここで、本実施の形態における画面共有サーバ１１は、デスクトップ描画メモリ領域１０３１に書き込まれた画面情報を共有画面の対象として他のＰＣ１０の画面共有クライアント１２に転送する。

図８は、画面共有サーバが共有画面の対象とする画面情報を説明するための図である。図８に示されるように、画面共有サーバ１１は、デスクトップ描画メモリ領域１０３１より共有画面の対象とする画面情報を取得し、レイヤ属性ウィンドウ描画メモリ領域１０３２からは、画面情報は取得しない。したがって、レイヤ属性ウィンドウ描画メモリ領域１０３２における画面情報、すなわち、レイヤ属性が付されたウィンドウは、他のＰＣ１０には共有表示されないということになる。第一の実施の形態のＰＣ１０は、この仕組みを利用する。

図９は、第一の実施の形態における画面共有関係を示す図である。図９に示されるように、第一の実施の形態では、ＰＣ１０ｂ、１０ｃ及び１０ｄのそれぞれの画面共有クライアント１２は、ＰＣ１０ａの画面共有サーバ１１に接続している。したがって、各ＰＣ１０の表示装置１０６における表示画面の状態は、例えば、図１０のようになる。

図１０は、第一の実施の形態における各ＰＣにおける表示画面の状態の例を示す図である。図１０において、デスクトップ画面１０７ａ、１０７ｂ、１０７ｃ、１０７ｄは、そえれぞれ、ＰＣ１０ａ、１０ｂ、１０ｃ、１０ｄの表示装置１０６に表示されているデスクトップ画面を示す。図９に示されるような画面共有関係にある場合、ＰＣ１０ａがウィンドウｗａ１及びｗａ２をデスクトップ画面１０７ａに表示させると、他の表示画面にも同様にウィンドウｗａ１及びｗａ２が表示され、二つのウィンドウが４台のＰＣ１０によって共有される。

このような状況において、図１１に示されるような画面共有を実現したいとする。図１１は、一部のウィンドウが共有されない状態を示す図である。図１１においては、ウィンドウｗａ２は、デスクトップ画面１０７ａにのみ表示されており、他のデスクトップ画面には表示されていない。

以下、図１１に示される状態を実現するための第一の実施の形態における画面共有システム１の処理手順について説明する。図１２は、第一の実施の形態における画面共有システムの処理手順を説明するためのフローチャートである。

ＰＣ１０ｂ、１０ｃ、又は１０ｄのいずれかの画面共有クライアント１２がＰＣ１０ａの画面共有サーバ１１に接続することにより画面共有が開始されると、ＰＣ１０ａの共有制御部１４におけるウィンドウ監視部１４１は、ウィンドウに関する各種のイベントの監視を開始する（Ｓ１０１）。

ウィンドウ監視部１４１は、ウィンドウに関するならかのイベントを検出すると、そのイベントに応じて処理を分岐させる（Ｓ１０２）。

例えば、ＰＣ１０ａのデスクトップ画面１０７ａ上に新たなウィンドウ（以下「カレントウィンドウ」という。）が表示されたことが検出されると、ウィンドウ監視部１４１は、カレントウィンドウの識別情報（ハンドル）をウィンドウ管理部１４２に通知する。

ウィンドウ管理部１４２は、通知されたハンドルに基づいて、カレントウィンドウを表示させようとしているアプリケーション（以下「カレントアプリケーション」という。）の実行ファイル名を調べ、その実行ファイル名と非共有の対象として予め設定登録されているアプリケーション（以下「非共有アプリケーション」という。）の実行ファイル名と比較し、両者が一致すればカレントウィンドウは非共有ウィンドウであると判定する（Ｓ１０３）。

例えば、メールソフト「ＭｙＭａｉｌ．ｅｘｅ」とインスタントメッセンジャーソフト「ＭｙＩＭ．ｅｘｅ」が非共有アプリケーションとして登録されているとする。カレントアプリケーションの実行ファイル名がこれらと一致した場合、カレントウィンドウは、非共有ウィンドウであると判定される。

カレントウィンドウは、非共有ウィンドウであると判定された場合、レイヤ属性設定部１４３は、カレントウィンドウに対してレイヤ属性を付与する（Ｓ１０４）。これによって、カレントウィンドウの画面情報は、レイヤ属性ウィンドウ描画メモリ領域１０３２に書き込まれる。したがって、カレントウィンドウの画面情報は、画面共有サーバ１１の取得対象とはされず、他のＰＣ１０の画面共有クライアント１２には転送されない。

なお、ウィンドウ監視部１４１による監視は、画面共有が行われている間継続され（Ｓ１０１）、全ての画面共有クライアント１２からの接続が切断された場合等、画面共有状態が解除されると（Ｓ１０２で「画面共有終了」）、終了する（Ｓ１０５）。

上述したように、第一の実施の形態における画面共有システム１によれば、任意のアプリケーションのウィンドウを効率的な処理によって非共有にすることができ、セキュアなコミュニケーションが可能となる。したがって、例えば、ＰＣ１０ａを画面共有サーバとして他のＰＣ１０と画面共有を行い、ＰＣ１０ａのユーザが他のＰＣ１０のユーザに対して共有画面を介して何らかの発表を行っている場合であっても、他のユーザに気付かれることなく非共有ウィンドウによって必要な情報を確認することができる。例えば、メーラを非共有のアプリケーションとして予め登録しておけば、そのメーラは自動的に非共有とされるため、非共有とされたメーラによって発表内容に関連するメールの内容を確認しても他のユーザにメールの内容を閲読されるのを防止することができる。したがって、メールの内容を確認するために、一旦画面共有サーバと画面共有クライアントとの間の接続を切断し、メールの内容の確認後に再度接続を行うといった手間が省くことが出来る。

また、新たなウィンドウの検出に応じ、予め登録されている設定情報に基づいて共有の許否が判定されるため、ウィンドウの非共有が自動的に実現される。

更に、発表中にメッセンジャーソフト等で他の参加者がヒントや答えを教えてくれた場合に、その画面が他のＰＣ１０に共有表示されてしまうことを防止することもできる。

また、第一の実施の形態のように、ウィンドウの画面情報をデスクトップ描画メモリ領域１０３１とは異なるメモリ領域に描画することにより当該ウィンドウを非共有とする方式によれば、当該ウィンドウと他の共有ウィンドウとが重なり合った場合でも、他の共有ウィンドウの画面情報には影響は及ばない。したがって、デスクトップ画面や他の共有ウィンドウの画像が乱れたりすることで、当該ウィンドウを非共有としていることを他のユーザに気付かれたりする可能性を低下させることができる。また、特許文献１において示されているような重複部分を再現するための特別な処理（例えば、画面情報のキャッシュ等の処理）は不要となる。

ところで、ＵｌｔｒａＶＮＣ等では、ミラードライバを使ってＧＤＩ（Graphics Device Interface）命令を複製し、複製した命令でメモリ上に生成した仮想ディスプレイに描画を行い、その画面情報を画面共有サーバが取得するように構成されている。これは画面共有サーバが、物理ドライバに描画される画面情報を取得するよりも高速に画面情報を取得することを目的に開発されたものであるが、このミラードライバが利用されると、レイヤ属性を持つウィンドウの画面情報も画面共有サーバによって取得出来てしまう。そこで、このような場合には、ミラードライバをＯＦＦすることによって本実施の形態を適用すればよい。

次に、第二の実施の形態について説明する。図１３は、第二の実施の形態における画面共有システムの処理手順を説明するためのフローチャートである。図１３中、図１２と同一ステップには同一ステップ番号を付し、その説明は省略する。なお、画面共有システム１のシステム構成を始め、画面共有関係（図９）等、他の条件については第一の実施の形態と同様とする。

図１３においては、ステップＳ１０３がステップＳ２０３に置き換わっている。ステップＳ２０３において、ウィンドウ管理部１４２は、ウィンドウ監視部１４１より通知されたウィンドウハンドルに基づいてカレントウィンドウのウィンドウ名（ウィンドウのタイトル名）を取得し、そのウィンドウ名が、予め登録されている非共有キーワードを含んでいるか否かに基づいてカレントウィンドウが非共有ウィンドウであるか否かを判定する。

ここで、ウィンドウ名とは、各ウィンドウを識別するための情報として各ウィンドウに付与される文字列をいい、一般的には、そのアプリケーションの操作対象とされているファイルのファイル名等、閲覧対象とされる文書の名前が用いられる。

また、非共有キーワードとは、例えば、「秘」、「重要」、又は「Ｆｒｏｍ ＡＢＣＤカンパニー」等、予めユーザによって設定されているキーワードであり、ウィンドウ管理部１４２が管理している。

カレントウィンドウのウィンドウ名に非共有キーワードが含まれていた場合（Ｓ２０３でＹＥＳ）、レイヤ属性設定部１４３は、カレントウィンドウにレイヤ属性を付与する（Ｓ１０４）。したがって、この場合、カレントウィンドウは、他のＰＣ１０には共有表示されない。

上述したように、第二の実施の形態における画面共有システム１によれば、非共有キーワードをウィンドウ名と比較することによって非共有の要否が判断される。したがって、同一のアプリケーションでも、操作対象とされる文書によって共有又は非共有の別を制御することができる。よって、例えば、共有表示されても構わないメールや文書は共有表示されるが、取引に関するメールや機密度の高いファイル等は共有表示されないようにすることが出来る。

なお、アプリケーションによっては、起動状態のまま（ウィンドウを表示したまま）操作対象とする文書等を変更することが可能なものがある。そのようなアプリケーションについては、ウィンドウ監視部１４１がウィンドウ名の変化を検出し、新たなウィンドウ名に非共有キーワードが含まれていない場合は、レイヤ属性を解除するといった処理を行ってもよい。こうすることで、例えば、ファイル名に非共有キーワードを含む文書が操作対象とされたために非共有ウィンドウとして表示されたアプリケーションにおいて、その後に操作対象の文書が変更された場合に、当該文書のファイル名に非共有キーワードが含まれていなければ、そのまま当該アプリケーションのウィンドウを共有状態に変更することが可能となる。

次に第三の実施の形態について説明する。図１４は、第三の実施の形態における画面共有システムの処理手順を説明するためのフローチャートである。なお、画面共有システム１のシステム構成を始め、画面共有関係（図９）等、他の条件については第一の実施の形態と同様とする。

新たなウィンドウ（カレントウィンドウ）の表示が検出されると、レイヤ属性設定部１４３は、カレントウィンドウにレイヤ属性を付与する（Ｓ１０４）。これによって、カレントウィンドウは、一旦非共有とされる。

続いて、ウィンドウ管理部１４２は、カレントウィンドウの共有表示の許否をユーザに問い合わせるダイアログ（以下「共有許否ダイアログ」という。）をカレントウィンドウに重ねるようにして表示装置１０６に表示させる（Ｓ３０１）。

図１５は、共有許否ダイアログの表示例を示す図である。図１５において、ダイアログｄ１が共有許否ダイアログであり、ウィンドウｗａ２の共有の許否を問い合わせている。なお、レイヤ属性設定部１４３によって、共有許否ダイアログｄ１にレイヤ属性を付与するようにすることが望ましい。こうすることで、共有許否ダイアログｄ１が他のＰＣ１０に共有表示されるのを回避することができる。

共有許否ダイアログｄ１の問い合わせに対し、ユーザが共有を許可した場合（Ｓ３０３でＹＥＳ）、レイヤ属性設定部１４３は、カレントウィンドウに付与されているレイヤ属性を解除する。これによって、カレントウィンドウは共有表示される。一方、ユーザが共有を許可しない場合、カレントウィンドウに対するレイヤ属性は付与されたままにされる。したがって、カレントウィンドウは非共有とされる。

上述したように、第三の実施の形態における画面共有システム１によれば、ウィンドウの表示の際に画面共有の許否をユーザに選択させることができる。

次に、第四の実施の形態について説明する。図１６は、第四の実施の形態における非共有ウィンドウの表示例を示す図である。

第四の実施の形態において、ウィンドウ管理部１４２は非共有と判定されたウィンドウｗａ２のウィンドウ枠の幅を太くする等の視覚的な属性を変化させることによる装飾を行って、ＰＣ１０ａを利用しているユーザが各ウィンドウが共有表示されているのか、非共有なのかを視覚的に認識できるようにする。なお、画面共有システム１のシステム構成を始め、画面共有関係（図９）等、他の条件については第一の実施の形態等と同様とする。

ウィンドウ枠の幅を太くする以外にも、例えばＷｉｎｄｏｕｗｓ（登録商標）環境であれば、ＳｅｔＬａｙｅｒｅｄＡｔｔｒｉｂｕｔｅｓ関数を使って、非共有ウィンドウの透過率を５０％等にして半透明表示にしてもよい。また、非共有ウィンドウのウィンドウ名の末尾に非共有ウィンドウであることが認識可能な文字列（例えば、「（非表示）」といった文字列）を追加してもよいし、非表示のポップアップを表示してもよい。

上述したように第四の実施の形態における画面共有システム１によれば、共有表示されているウィンドウと、非共有のウィンドウとを画面共有サーバのユーザに容易に認識させることができる。したがって、ユーザの誤操作を防止することができる。

ところで、上記第一から第四の実施の形態では、非共有ウィンドウに対するイベントの制御について明記されていなかった。すなわち、例えば、ＰＣ１０ａに非共有ウィンドウが表示されているとする。ここで、ＰＣ１０ｂは、画面共有クライアントとしてＰＣ１０ａに対する遠隔操作の操作権を持っているとすると、ＰＣ１０ｂにおけるマウスイベントやキーボードイベントは、ＰＣ１０ａに転送される。そのマウスイベント等がたまたま非共有ウィンドウｗａ２の領域内で発生した場合は、非共有ウィンドウｗａ２がＰＣ１０ｂより遠隔操作されてしまい、予期せぬ事態が発生してしまう可能性がある。そこで、第五の実施の形態として、非共有ウィンドウが他のＰＣ１０より遠隔操作されるのを回避した例について説明する。なお、画面共有システム１のシステム構成を始め、画面共有関係（図９）等、他の条件については第一の実施の形態等と同様とする。

図１７は、第五の実施の形態の画面共有サーバにおいて画面共有クライアントからのマウスイベントが受信された際の処理を説明するためのフローチャートである。

ＰＣ１０ａの画面共有サーバ１１の入力イベント受信部１１３が、他のＰＣ１０における画面共有クライアント１２であって操作権のあるものからマウスイベントを受信することにより図１７の処理は開始される。

位置情報を含むマウスイベントを受信した入力イベント受信部１１３が、ウィンドウ管理部１４２に対してマウスイベントの座標が、非共有ウィンドウｗａ２の領域内であるか否かを問い合わせると、ウィンドウ管理部１４２は、受信されたマウスイベントより特定される当該マウスイベントの座標値と、非共有ウィンドウｗａ２の領域に関する座標値とに基づいて、当がマウスイベントが非共有ウィンドウｗａに影響を与えるか、すなわち、当該マウスイベントが非共有ウィンドウｗａ２内であるか否かを判定する（Ｓ４０１）。

ウィンドウ管理部１４２によって、マウスイベントが非共有ウィンドウ内に含まれていると判定された場合（Ｓ４０２でＹＥＳ）、入力イベント受信部１１３は、当該マウスイベントを破棄する（Ｓ４０３）。したがって、この場合、非共有ウィンドウｗａ２に対して当該マウスイベントは伝えられない。

一方、マウスイベントは非共有ウィンドウｗａ２内に含まれていないと判定された場合（Ｓ４０２でＮＯ）、入力イベント受信部１１３は、当該マウスイベントを入力イベント生成部１１４に通知する。したがって、この場合、入力イベント生成部１１４によってマウスイベントがＰＣ１０ａにおいて生成される（Ｓ４０４）。

また、図１８は、第五の実施の形態の画面共有サーバにおいて画面共有クライアントからのキーボードイベントが受信された際の処理を説明するためのフローチャートである。

キーボードイベントを受信した入力イベント受信部１１３は、ウィンドウ管理部１４２に対してアクティブウィンドウ（操作対象とされているウィンドウ）が、非共有ウィンドウｗａ２であるか否かを問い合わせる（Ｓ５０１）。

ウィンドウ管理部１４２によって、アクティブウィンドウは非共有ウィンドウｗａ２であると判定された場合（Ｓ５０２でＹＥＳ）、入力イベント受信部１１３は、当該キーボードイベントを破棄する（Ｓ５０３）。したがって、この場合、非共有ウィンドウｗａ２に対して当該キーボードイベントは伝えられない。

一方、アクティブウィンドウは非共有ウィンドウｗａ２ではないと判定された場合（Ｓ５０２でＮＯ）、入力イベント受信部１１３は、当該キーボードイベントを入力イベント生成部１１４に通知する。したがって、この場合、入力イベント生成部１１４によってキーボードイベントがＰＣ１０ａにおいて生成される（Ｓ５０４）。

上述したように第五の実施の形態における画面共有システム１によれば、画面共有サーバにおいて非共有表示されたウィンドウが、他の画面共有クライアントから誤って遠隔操作されてしまうのを防止することができる。

次に、第６の実施の形態について説明する。第五の実施の形態では、画面共有サーバ側が、非共有ウィンドウに対するイベントを制御する例について説明したが、第六の実施の形態では、画面共有クライアント側で非共有ウィンドウに対するイベントを制御する例を説明する。なお、画面共有システム１のシステム構成を始め、画面共有関係（図９）等、他の条件については第一の実施の形態等と同様とする。

図１９は、第六の実施の形態の画面共有システムにおける処理を説明するためのフローチャートである。

画面共有サーバとしてのＰＣ１０ａにおいてウィンドウ監視部１４１が、非共有ウィンドウの増減や移動等を検出すると、ウィンドウ管理部１４２は、デスクトップ画面１０７ａのどの領域が非共有ウィンドウｗａ２によって占められているかに関する情報（以下「非共有領域情報」という。）を更新し（Ｓ６０２）、その非共有領域情報を画面共有クライアントである各ＰＣ１０（ＰＣ１０ｂ、ｃ及びｄ）に送信する（Ｓ６０３）。非共有領域情報を受信したＰＣ１０ｂ等は、非共有領域情報を所定の管理領域（例えば、ファイル等）に設定する。

画面共有サーバより非共有領域情報を受信した各画面共有クライアントでは、以下のような処理によって非共有ウィンドウに対するイベントを制御する。

図２０は、第六の実施の形態の画面共有クライアントにおいてマウスイベントが発生した際の処理を説明するためのフローチャートである。図２０では、画面共有クライアントとしてＰＣ１０ｂを例とする。

ＰＣ１０ｂにおいてマウスイベントが発生すると、ＰＣ１０ｂの操作権管理部１３３は、ＰＣ１０ａに対する操作権の有無を判定する（Ｓ７０１）。操作権管理部１３３によって操作権は有ると判定された場合、ＰＣ１０ｂの入力イベント取得部１２３は、マウスイベントが発生した座標が遠隔操作可能領域内であるかを判定する（Ｓ７０２）。ここで、遠隔操作可能領域とは、画面共有サーバ（ＰＣ１０ａ）より受信した非共有領域情報によって特定される領域以外の領域をいう。すなわち、非共有ウィンドウによって占められる以外の領域が、遠隔操作可能領域に相当する。

マウスイベントが発生した座標が遠隔操作可能領域内であると判定された場合、ＰＣ１０ｂの入力イベント送信部１２４は、当該マウスイベントをＰＣ１０ａの画面共有サーバ１１に送信する（Ｓ７０３）。

一方、ＰＣ１０ａに対する操作権は無いと判定された場合（Ｓ７０１でＮＯ）、又は、マウスイベントが発生した座標が遠隔操作可能領域外であると判定された場合（Ｓ７０２でＮＯ）は、ＰＣ１０ｂの入力イベント送信部１２４は、当該マウスイベントを破棄する（Ｓ７０４）。したがって、この場合、当該マウスイベントはＰＣ１０ａの画面共有サーバ１１には送信されず、非共有ウィンドウｗａ２に対する遠隔操作は行われない。

上述したように第六の実施の形態における画面共有システム１によれば、第五の実施の形態における画面共有システムと同様、画面共有サーバにおいて非共有表示されたウィンドウが、他の画面共有クライアントから誤って遠隔操作されてしまうのを防止することができる。

次に、第七の実施の形態について説明する。図２１は、第七の実施の形態における画面共有関係を示す図である。図２１中、図９と同一部分には同一符号を付し、その説明は省略する。

図２１に示されるように、第七の実施の形態では、第一の実施の形態における画面共有関係（図９）に加えて、ＰＣ１０ａの画面共有クライアント１２は、ＰＣ１０ｂの画面共有サーバ１１に接続している。したがって、ＰＣ１０ｂ、ＰＣ１０ｃ、及びＰＣ１０ｄは、ＰＣ１０ａにおける共有ウィンドウを共有表示することができる。また、ＰＣ１０ａは、ＰＣ１０ｂにおける共有ウィンドウを共有表示することができる。

このような共有関係は、例えば、ＰＣ１０ｂのユーザが、発表者であるＰＣ１０ａのユーザを支援する場合を想定するとよい。すなわち、ＰＣ１０ｂのユーザがＰＣ１０ｂにおいて共有ウィンドウを表示させ、その共有ウィンドウを用いて発表者に対してアドバイスを行うような場合である。この場合、ＰＣ１０ｂに表示された共有ウィンドウはＰＣ１０ａに共有表示される。ＰＣ１０ａの画面共有クライアント１２はＰＣ１０ｂの画面共有サーバ１１に接続しているからである。しかし、ＰＣ１０ａに表示されたＰＣ１０ｂの共有ウィンドウは、ＰＣ１０ａを画面共有サーバとするＰＣ１０ｃ及び１０ｄ等にも表示されてしまう。

図２２は、第七の実施の形態における画面共有関係において発生し得る各ＰＣにおける表示画面の状態の例を示す図である。図２２中、図１１と同一部分には同一符号を付し、その説明は適宜省略する。

図２２において、ウィンドウｗａ１は、ＰＣ１０ａのデスクトップ画面１０７ａに表示されている共有ウィンドウである。したがって、ウィンドウｗａ１は、デスクトップ画面１０７ｂ、１０７ｃ及び１０７ｄにも共有表示されている。なお、デスクトップ画面１０７ｂにおいて、ウィンドウｗａ１は閉じた状態にされているがこれは便宜的なものである。

一方、デスクトップ画面１０７ａ、１０７ｃ及び１０７ｄに表示されているウィンドウｗｂ１は、ＰＣ１０ｂのデスクトップ画面１０７ｂが共有表示されているものである。

すなわち、ウィンドウｗｂ１は、ＰＣ１０ａとＰＣ１０ｂとのクライアント・サーバ関係に基づいてデスクトップ画面１０７ａに表示され、更に、ＰＣ１０ａと、ＰＣ１０ｃ及びＰＣ１０ｄとのクライント・サーバ関係に基づいてデスクトップ画面１０７ｃ及び１０７ｄに表示されている。なお、ウィンドウｗｂ１内には、デスクトップ画面１０７ｂにおいて表示されているウィンドウｗｂ２が表示されている。

このように、図２１に示されるような画面共有関係によれば、ＰＣ１０ｂのデスクトップ画面１０７ｂに表示されるウィンドウが、ＰＣ１０ｂの画面共有クライアントではないＰＣ１０ｃ及び１０ｄにも間接的に表示されてしまう可能性がある。これでは、ＰＣ１０ｂのユーザが、ウィンドウｗｂ２を用いてＰＣ１０ａのユーザにアドバイス等を行おうとしても、その内容が他のユーザにも筒抜けとなってしまう。

そこで、第七の実施の形態では、図２１に示されるような画面共有関係において、ＰＣ１０ｂに表示されるウィンドウをＰＣ１０ａにだけ共有表示させる例について説明する。なお、画面共有システム１のシステム構成等、他の条件については第一の実施の形態等と同様とする。

図２３は、第七の実施の形態における画面共有システムの処理手順を説明するためのフローチャートである。図２３中、図１２と同一ステップには同一ステップ番号を付し、その説明は省略する。

図２３においては、ステップＳ１０３がステップＳ７０３に置き換わっている。ウィンドウ監視部１４１によってカレントウィンドウの表示が検出されると（Ｓ１０２）、ウィンドウ管理部１４２は、新規ウィンドウが、画面共有クライアント１２によって表示されたものであるか否かを判定する（Ｓ７０３）。

カレントウィンドウが画面共有クライアント１２によって表示されたものである場合（Ｓ７０３でＹＥＳ）、レイヤ属性設定部１４３は、カレントウィンドウにレイヤ属性を付与する（Ｓ１０４）。したがって、この場合、カレントウィンドウは、他のＰＣ１０には共有表示されない。

カレントウィンドウがｗｂ１である場合、図２３の処理によれば各ＰＣ１０の表示状態は図２４のようになる。

図２４は、第七の実施の形態における画面共有システムにおける各ＰＣの表示画面の状態の例を示す図である。図２４中、図２２と同一部分には同一符号を付し、その説明は省略する。

図２４を図２２と比較するとその違いが明確である。すなわち、図２４においては、ウィンドウｗｂ１及びウィンドウｗａ２は、デスクトップ画面１０７ａにおいてのみ共有表示されている。これは、ウィンドウｗｂ１及びｗｂ２は、ＰＣ１０ａの画面共有クライアント１２によって表示される際にレイヤ属性が付与されることにより、ＰＣ１０ａの画面共有サーバ１１による他のＰＣ１０への転送対象とはならないからである。

上述したように、第七の実施の形態における画面共有システム１によれば、画面共有サーバとしてのＰＣ１０ａが他のＰＣ１０の画面共有クライアントとなることにより、当該他のＰＣ１０のウィンドウが間接的に別のＰＣ１０に表示されてしまうのを回避することができる。したがって、例えば、発表者のＰＣ画面を、他のＰＣの画面上に共有表示している場合において、豊富な情報量を有するコンテンツによって密かに発表者を支援することが可能となる。

次に、第八の実施の形態について説明する。図２５は、第八の実施の形態の各ＰＣにおける画面共有機能の機能構成例を示す図である。図２５中、図５と同一部分には同一符号を付し、その説明は省略する。図２５において、ＰＣ１０には、新たにアノテーションアプリ１６が追加されている。

アノテーションアプリ１６は、マウスイベントを捕捉し、マウスの軌跡に応じた線データを他のＰＣ１０のアノテーションアプリ１６に送信することにより、アノテーションを可能とするアプリケーションである。

例えば、ＰＣ１０ｂからＰＣ１０ａに対してアノテーションを行う場合を説明する。ＰＣ１０ｂでアノテーションアプリ１６を起動し、デスクトップ画面１０７ｂに対して描き込みが行われると、アノテーションアプリ１６は、マウスイベントを捕捉し、その線データを画面共有サーバとしてのＰＣ１０ａのアノテーションアプリ１６に送信する。線データを受信したＰＣ１０ａのアノテーションアプリ１６は、線データが描画されたアノテーションアプリのウィンドウを、その位置や大きさを調整してデスクトップ画面１０７ａに重ねて表示させる。なお、アノテーションアプリ１６のウィンドウは、透過ウィンドウ（背景が透明なウィンドウ）として表示される。したがって、ユーザには線データのみが描画されたように見える。

なお、画面共有関係は、第七の実施の形態（図２１）と同様であるとし、他の条件については第一の実施の形態等と同様であるとする。

図２１のような画面共有関係において、ＰＣ１０ｂにおいてアノテーションアプリ１６が起動され、マウスによって描画が行われると図２６に示されるような状況が発生し得る。

図２６は、第八の実施の形態における画面共有関係において発生し得る各ＰＣにおける表示画面の状態の例を示す図である。図２６中、図１１と同一部分には同一符号を付し、その説明は省略する。

図２６において、線データｌｂ１は、ＰＣ１０ｂのデスクトップ画面１０７ｂにおいて描き込みが行われたものである。それが、ＰＣ１０ｂのアノテーションアプリ１６からＰＣ１０ａのアノテーションアプリ１６に転送されることによってデスクトップ画面１０７ａに表示され、更に、デスクトップ画面１０７ａに表示された線データｌｂ１が、画面共有機能によってデスクトップ画面１０７ｃ及び１０７ｄに表示される。

しかし、線データｌｂ１がＰＣ１０ａ以外に表示されてしまうと不都合な場合がある。例えば、ＰＣ１０ｂを操作しているユーザがアノテーションによって発表者（ＰＣ１０ａ）を助ける場合等である。そこで、第八の実施の形態では、ＰＣ１０ｂにおける描き込みが、ＰＣ１０ａにのみ表示される例を説明する。

図２７は、第八の実施の形態における画面共有システムの処理手順を説明するためのフローチャートである。なお、ＰＣ１０ａでは、予めアノテーションアプリ１６の画面共有の許否に関する設定がなされているものとする。

画面共有が開始されると、ＰＣ１０ａの共有制御部１４におけるウィンドウ監視部１４１は、ウィンドウに関する各種のイベントの監視を開始する（Ｓ８０１）。

ウィンドウ監視部１４１は、ＰＣ１０ａのアノテーションアプリ１６が起動されると（Ｓ８０２で「アノテーションアプリの起動」）、設定情報に基づいてアノテーションアプリ１６の共有は許可されているか否かを判定する（Ｓ８０３）。

アノテーションアプリ１６の共有が許可されていない場合（Ｓ８０３でＹＥＳ）、レイヤ属性設定部１４３は、アノテーションアプリ１６のウィンドウに対してレイヤ属性を付与する（Ｓ８０４）。これによって、ＰＣ１０ａにおけるアノテーションアプリ１６の画面情報は、レイヤ属性ウィンドウ描画メモリ領域１０３２に書き込まれる。したがって、アノテーションアプリ１６の画面情報は、画面共有サーバ１１の取得対象とはされず、他のＰＣ１０の画面共有クライアント１２には転送されない。

図２７の処理によって、各ＰＣ１０の表示状態は図２８のようになる。図２８は、第八の実施の形態における画面共有システムにおける各ＰＣの表示画面の状態の例を示す図である。図２８中、図２６と同一部分には同一符号を付し、その説明は省略する。

図２８を図２６と比較するとその違いが明確である。すなわち、図２８においては、線データｌｂ１は、デスクトップ画面１０７ａにおいてのみ表示されている。これは、デスクトップ画面１０７ａにおいて線データｌｂ１を表示させるＰＣ１０ａのアノテーションアプリ１６は、レイヤ属性が付与されることによりＰＣ１０ａの画面共有サーバ１１による他のＰＣ１０への転送対象とはならないからである。

上述したように第八の実施の形態におけるが面共有システム１によれば、画面共有サーバとしてＰＣ１０ａが他のＰＣ１０の画面共有クライアントとなることにより、ＰＣ１０ａに対するアノテーションが別のＰＣ１０に表示されてしまうのを回避することができる。したがって、例えば、発表者の画面に一のユーザが他のユーザには見えない描き込みを行うことによって、発表者を密かに支援することが出来る。

なお、ＰＣ１０ａのアノテーションアプリ１６の共有表示の許否は、上記のようにＰＣ１０ａ自身に設定できるようにしてもよいし、アノテーションの描き込みを行うＰＣ１０ｂが設定できるようにしてもよい。

図２９は、第八の実施の形態においてアノテーションを行う側が共有の許否を設定する場合の各ＰＣにおける画面共有機能の機能構成例を示す図である。図２９中、図２５と同一部分には同一符号を付し、その説明は省略する。

図２９においては、非共有指示部１９が新たに追加されている。非共有指示部１９は、他のＰＣ１０のアノテーションアプリ１６に対して非共有を指示するための機能を有する。

図３０は、第八の実施の形態においてアノテーションを行う側が共有の許否を設定する場合の画面共有システムの処理手順を説明するためのフローチャートである。図３０では、アノテーションを行う側がＰＣ１０ｂであり、アノテーションをされる側がＰＣ１０ａである場合を例としている。

ＰＣ１０ｂのアノテーションアプリ１６が、ＰＣ１０ａのアノテーションアプリ１６に対して接続要求を行うと（Ｓ８１１）、ＰＣ１０ａのアノテーションアプリ１６は、接続要求を受け付け、セッションを開設後、接続完了通知をＰＣ１０ｂのアノテーションアプリ１６に送信する（Ｓ８１２）。接続完了通知を受けたＰＣ１０ｂの非共有指示部１９が、アノテーションの非共有をＰＣ１０ａに対して指示すると（Ｓ８１３）、ＰＣ１０ａのレイヤ属性設定部１４３は、ＰＣ１０ａのアノテーションアプリ１６にレイヤ属性を付与する。

このように、アノテーションの描き込みを行うＰＣ１０ｂよりアノテーションアプリ１６の非共有の設定を行うことができる。

次に、第九の実施の形態について説明する。非共有にしたいアプリケーションのウィンドウをオーバーレイ表示によって表示すればハードウェア処理によってウィンドウの描画が実行されるため、デスクトップ描画メモリ領域１３０１に画面情報が書き込まれることはない。ここでは、オーバーレイ表示を実現するための手段としてＤｉｒｅｔＤｒａｗを例とする。ＤｉｒｅｃｔＤｒａｗで描画するように実装すれば、ＤｉｒｅｃｔＤｒａｗによって描画命令が直接グラフィックアクセラレータに送信され、アクセラレータのハードウェア処理によってＰＣに接続された表示装置に描画されるので、画面共有サーバはその画面データを取得することが出来ないため、非共有にすることが出来る。

図３１は、アプリケーションによる描画の仕組みを説明するための図である。一般的に、各種アプリケーションは、ＧＤＩによる描画命令（ＧＤＩ描画命令）によってウィンドウの描画命令をＯＳ２１に対して発行する。ＧＤＩ描画命令に基づいて生成される画面情報は、デスクトップ描画メモリ領域１０３１に記録される。

ＧＤＩ描画命令ではなく、ＤｉｒｅｃｔＤｒａｗを用いてウィンドウを描画するようにアプリケーションを実装することもできる。ＤｉｒｅｃｔＤｒａｗによる描画命令（ＤｉｒｅｃｔＤｒａｗ描画命令）は、ディスプレイドライバＤｉｒｅｃｔＤｒａｗ部２２２がその描画命令をサポートしている場合は、ディスプレイドライバＤｉｒｅｃｔＤｒａｗ部２２２に伝えられ、サポートされていない場合は、ＯＳ２１を介してディスプレイドライバＤＤＩ（Display Driver Interface）２２１に伝えられる。この場合は、ディスプレイドライバＤＤＩ部２２１は、通常のデスクトップ描画メモリ領域１０３１を使用して、描画命令に基づく画面情報をＶＲＡＭ２３に記録する。

ディスプレイドライバＤｉｒｅｃｔＤｒａｗ部２２２は、ＤｉｒｅｃｔＤｒａｗ描画命令に基づく画面情報をディスプレイアダプタハードウェア画像処理部２４に生成させる。ディスプレイアダプタハードウェア画像処理部２４によって生成された画面情報は、ＶＲＡＭ２３に記録される。なお、ＶＲＡＭ２３に記録された画面情報は、表示装置１０６に表示される。

したがって、非共有としたいアプリケーションをＤｉｒｅｃｔＤｒａｗを使って描画するように実装しておけば、自分ＰＣ上で起動している画面共有アプリケーションを操作するつもりが、画面共有クライアントアプリケーション画面内に共有表示されている他のＰＣのそれを間違って操作してしまうことを防ぐことが出来る。

このように第九の実施の形態による画像共有システム１によれば、非共有にしたいアプリケーションを、オーバーレイで表示するよう実装することにより、ウィンドウを非共有にすることが可能となる。

次に、第十の実施の形態について説明する。図３２は、第十の実施の形態の各ＰＣにおける画面共有機能の機能構成例を示す図である。図３２中、図５と同一部分には同一符号を付し、その説明は省略する。

図３２においては、共有制御部１４におけるレイヤ属性設定部１４３が、非共有設定部１４４に置き換わっている。非共有設定部１４４については、図３３を参照しつつ説明する。

図３３は、第十の実施の形態における非共有設定部の機能構成例を示す図である。図３３において、非共有設定部１４４は、ＧＤＩ描画命令フック部１４４１、描画命令変換部１４２２、及びＤｉｒｅｃｔＤｒａｗ描画命令部１４４３等より構成されている。

ＧＤＩ描画命令フック部１４４１は、非共有に設定されたアプリケーションからのＧＤＩ描画命令をフックする。描画命令変換部１４４２は、フックされたＧＤＩ描画命令をＤｉｒｅｃｔＤｒａｗ描画命令に変換する。ＤｉｒｅｃｔＤｒａｗ描画命令部１４４３は、描画命令変換部１４４２によって生成されたＤｉｒｅｃｔＤｒａｗ描画命令を呼び出すことにより、ＤｉｒｅｃｔＤｒａｗによって非共有アプリケーションのウィンドウの描画を実行する。

このように、非共有設定部１４４によれば、ＧＤＩ描画命令がＤｉｒｅｃｔＤｒａｗ描画命令に変換されることにより、グラフィックアクセラレータのハードウェア処理によって表示装置１０６への描画が行われる。したがって、デスクトップ描画メモリ領域１０３１への画面情報の書き込みは行われず、画面共有サーバ１１はその画面情報を取得することが出来ない。よって、非共有アプリケーションのウィンドウの共有表示を回避することができる。

なお、画面共有システム１のシステム構成を始め、画面共有関係（図９）等、他の条件については第一の実施の形態と同様とする。

図３４は、第十の実施の形態における画面共有システムの処理手順を説明するためのフローチャートである。図３４中、図１２と同一ステップには同一ステップ番号を付し、その説明は適宜省略する。

図３４では、ステップＳ１０４がステップＳ１００４に置き換わっている。ウィンドウ管理部１４２は、カレントアプリケーションは非共有アプリケーションであると判定すると（Ｓ１０３でＹＥＳ）、カレントアプリケーションのＧＤＩ描画命令を監視対象とするよう非共有設定部１４４に通知する（Ｓ１００４）。

ウィンドウ管理部１４２からの通知を受けた非共有設定部１４４の処理について説明する。図３５は、第十の実施の形態における非共有設定部の処理手順を説明するためのフローチャートである。

ＧＤＩ描画命令フック部１４４１は、ＧＤＩ描画命令を検出するとそのＧＤＩ描画命令が監視対象のアプリケーションからのものであるか否かを判定する（Ｓ１００５）。ＧＤＩ描画命令が監視対象のアプリケーションからのものであった場合、ＧＤＩ描画命令フック部１４４１は、当該ＧＤＩ描画命令をフックし、描画命令変換部１４４２が、当該ＧＤＩ描画命令をＤｉｒｅｃｔＤｒａｗ描画命令に変換する（Ｓ１００６）。なお、ＧＤＩ描画命令フック部１４４１は、フックしたＧＤＩ描画命令はＯＳ２１には返却しない。

続いて、ＤｉｒｅｃｔＤｒａｗ描画命令部１４４３は、描画命令変換部１４４２によって生成されたＤｉｒｅｃｔＤｒａｗ描画命令を呼び出す。これによってグラフィックアクセラレータによってウィンドウが描画される（Ｓ１００７）。

一方、検出されたＧＤＩ描画命令が監視対象のアプリケーションによるものでなかった場合、ＧＤＩフック部１４４１は、当該ＧＤＩ描画命令をＯＳ２１に返却する（Ｓ１００８）。したがって、この場合、画面情報はデスクトップ描画メモリ領域１０３１に書き込まれ、画面共有サーバ１１の取得対象とされることにより、画面共有される。

上述したように、第十の実施の形態における画面共有システム１によれば、非共有にしたい任意のアプリケーションのウィンドウを描画命令変換によってオーバーレイ描画することにより、非共有にすることが出来る。

次に、第十一の実施の形態について説明する。第十一の実施の形態は、第十の実施の形態に対して共有設定部１４４の機能構成例及びその処理手順が異なる。

図３６は、第十一の実施の形態における非共有設定部の機能構成例を示す図である。図３６では、描画命令変換部１４４２が仮想描画部１４４４に置き換わっている。仮想描画部１４４４は、メモリ上の仮想的なディスプレイに対して画面情報をビットマップデータとして描画する。

図３７は、第十一の実施の形態における非共有設定部の処理手順を説明するためのフローチャートである。図３７中、図３５と同一ステップには同一ステップ番号を付し、その説明は適宜省略する。

ＧＤＩ描画命令が監視対象のアプリケーションからのものであった場合（Ｓ１００５でＹＥＳ）、ＧＤＩ描画命令フック部１４４１は、当該ＧＤＩ描画命令をフックし、仮想描画部１４４４が、当該ＧＤＩ描画命令に基づいてビットマップデータを仮想的なディスプレイに描画する（Ｓ１０１６）。なお、ＧＤＩ描画命令フック部１４４１は、フックしたＧＤＩ描画命令はＯＳ２１には返却しない。

続いて、ＤｉｒｅｃｔＤｒａｗ描画命令部１４４３は、仮想的なディスプレイよりビットマップデータを取得し（Ｓ１０１７）、そのビットマップデータのＤｉｒｅｃｔＤｒａｗによる描画命令を呼び出す。これによって、仮想的なディスプレイのビットマップデータがグラフィックアクセラレータによって表示装置１０６に描画される（Ｓ１０１８）。

上述したように、第十一の実施の形態における画面共有システム１によれば、非共有にしたい任意のアプリケーションのウィンドウをオーバーレイ描画することにより、非共有にすることが出来る。

次に、第十二の実施の形態について説明する。第十二の実施の形態では、第一の実施の形態と同様の画面共有関係（図９）を維持しつつ、図３８に示されるように特定のＰＣ（ＰＣ１０ｂ）にのみＰＣ１０ａの画面を共有させる例について説明する。

図３８は、複数の画面共有クライアントのうち特定の画面共有クライアントのみに画面共有を許可した場合の各ＰＣの表示画面の状態を示す図である。

図３８中、図１０と同一部分には同一符号を付し、その説明は省略する。図３８において、ウィンドウｗａ４は、ＰＣ１０ａのデスクトップ画面１０７ａにおいて表示されているものであるが、デスクトップ画面１０７ｂにおいてのみ共有表示されており、他のデスクトップ画面には共有表示されていない。このように、複数の画面共有クライアントが接続されている場合に、特定の画面共有クライアントとのみ画面を共有することを、以下「秘匿共有」という。

図３９は、第十二の実施の形態の各ＰＣにおける画面共有機能の機能構成例を示す図である。図３９中、図５と同一部分には同一符号を付し、その説明は省略する。

図３９においては、第２画面共有サーバ１７が新たな構成要素とされている。第２画面共有サーバ１７は、画面共有サーバ１１と同様の機能構成し、画面情報を他のＰＣ１０に転送する。但し、第２画面共有サーバ１７が転送の対象とする画面情報は、画面共有サーバ１１と異なる。

図４０は、第２画面共有サーバが転送対象とする画面情報を説明するための図である。図４０に示されるように、画面共有サーバ１１の画面データ取得部１１は、転送対象とする画面情報をデスクトップ描画メモリ領域１０３１より取得するのに対し、第２画面共有サーバ１７の画面データ取得部１７１は、レイヤ属性ウィンドウ描画メモリ領域１０３２より取得する。

また、図３９において、ウィンドウ管理部１４２は、デスクトップ画面に表示される各ウィンドウの共有の許否に関する設定情報を画面共有クライアント毎に管理している。

なお、画面共有システム１のシステム構成を始め、画面共有関係（図９）等、他の条件については第一の実施の形態と同様とする。

図４１は、第十二の実施の形態の画面共有システムにおいて秘匿共有を実現するための処理手順を説明するためのフローチャートである。

秘匿共有の対象として設定されているアプリケーションのウィンドウが起動されると、レイヤ属性設定部１４３は、当該ウィンドウにレイヤ属性を付与し、当該ウィンドウを非共有ウィンドウとする（Ｓ１２０１）。したがって、この段階では、ＰＣ１０ａに表示された非共有ウィンドウは、他のＰＣ１０には共有表示されない。

続いて、ウィンドウ管理部１４２は、第２画面共有サーバ１７を起動する（Ｓ１２０２）。なお、第２画面共有サーバ１７は、デスクトップ全体ではなく、秘匿共有にしたアプリケーションの画面情報のみを取得するようにする。一般に、画面共有サーバは、デスクトップ画面全体を画面共有対象とすると、レイヤ属性を持つウィンドウの画面情報が合成されたデスクトップ画面の画面情報を得ることは出来ないが、画面情報の取得元を個別のアプリケーションのウィンドウに限定することで、このレイヤ属性ウィンドウ描画メモリ領域１０３２から特定のウィンドウの画面情報を取得することが出来る。例えば、ＧｅｔＷｉｎｄｏｗＤＣというＷｉｎｄｏｗｓ（登録商標）のＡＰＩ関数を用いることによって指定したアプリケーションのデバイスコンテキストを取得することが出来、これにより秘匿共有の対象とされたアプリケーションウィンドウのビットマップデータを得ることが出来る。

秘匿共有のアプリケーションウィンドウの画面情報を取得した第２画面共有サーバ１７は、秘匿共有が許可されたＰＣ１０の画面共有クライアント１２にのみ画面情報を転送する。したがって、当該画面共有クライアント１２を有するＰＣ１０のみが秘匿共有を行うことができる。すなわち、図３８は、ＰＣ１０ｂのみが秘匿共有が許可された例を示している。他のＰＣ１０（ＰＣ１０ｃ及びＰＣ１０ｄ）には、秘匿共有のアプリケーションのウィンドウｗａ４は表示されないが、共有が許可されているアプリケーションのウィンドウｗａ１は画面が乱れることなく共有表示される。

その後、秘匿共有を行っているアプリケーションが終了した場合や、秘匿共有を中止して全ての画面共有クライアントに対して共有を許可した場合、又は全ての画面共有クライアントに対して当該アプリケーションのウィンドウが非共有とされた場合（Ｓ１２０３でＹＥＳ）、第２画面共有サーバ１７は終了する（Ｓ１２０４）。

上述したように、第十二の実施の形態における画面共有システム１によれば、レイヤ属性が付されたウィンドウの画面情報を取得するに第２画面共有サーバ１７を設けることにより、通常であれば共有できないウィンドウを、特定のＰＣ１０に限って共有表示可させることができる。

なお、上記においては、一つのウィンドウを秘匿共有する方法を示したが、第３画面共有サーバ、第４画面共有サーバ・・・と画面共有サーバの起動数を増やすことにより、複数のウィンドウを秘匿共有させてもよい。

次に、第十三の実施の形態について説明する。第十三の実施の形態では、第九の実施の形態のように、ＤｉｒｅｃｔＤｒａｗによってウィンドウを描画するアプリケーションのウィンドウを特定の画面共有クライアントにのみ共有表示させる例について説明する。

図４２は、第十三の実施の形態の各ＰＣにおける画面共有機能の機能構成例を示す図である。図４２中、図３９と同一部分には同一符号を付し、その説明は省略する。

図４２においては、仮想描画部１８が新たな構成要素とされている。また、共有制御部１４において、レイヤ属性設定部１４３が共有設定部１４５に置き換わっている。

図４３は、第十三の実施の形態における共有設定部の機能構成例を示す図である。図４３において、共有設定部１４５は、ＤｉｒｅｃｔＤｒａｗ描画命令フック部１４５１、描画命令変換部１４５２、及びＤｉｒｅｃｔＤｒａｗ描画命令部１４５３等より構成されている。

図４４は、第十三の実施の形態の画面共有システムにおいて秘匿共有を実現するための処理手順を説明するためのフローチャートである。

非共有アプリケーションがＤｉｒｅｃｔＤｒａｗでウィンドウを描画するアプリケーションであった場合、ウィンドウ管理部１４２は共有設定部１４５に対して当該アプリケーションからのＤｉｒｅｃｔＤｒａｗ描画命令の監視を指示すると共に（Ｓ１３０１）、第２画面共有サーバ１７を起動する（Ｓ１３０２）。後述するように、この段階において、特定の画面共有クライアントに対してのみ当該アプリケーションウィンドウの秘匿共有が実行される。

その後、秘匿共有を行っているアプリケーションが終了した場合や、秘匿共有を中止して全ての画面共有クライアントに対して共有を許可した場合、又は全ての画面共有クライアントに対して当該アプリケーションのウィンドウが非共有とされた場合（Ｓ１３０３でＹＥＳ）、第２画面共有サーバ１７は終了し、秘匿共有の対象となっていたアプリケーションのＤｉｒｅｃｔＤｒａｗ描画命令を監視対象から外す（Ｓ１２０４）。

続いて、ステップＳ１３０１において、ＤｉｒｅｃｔＤｒａｗ描画命令の監視を指示された共有設定部１４５による処理手順を説明する。図４５は、第十三の実施の形態における共有設定部の処理手順を説明するためのフローチャートである。

ＤｉｒｅｃｔＤｒａｗ描画命令フック部１４５１は、アプリケーションからのＤｉｒｅｃｔＤｒａｗ描画命令をフックし、フックしたＤｉｒｅｃｔＤｒａｗ描画命令が監視対象とされているアプリケーションによるものでない場合は（Ｓ１３１１でＮＯ）、ＤｉｒｅｃｔＤｒａｗ描画命令をＯＳ２１に返却する（Ｓ１３１２）。これによって、このアプリケーションはグラフィックアクセラレータによって表示装置１０６に描画される。すなわち、いずれの画面共有クライアント上でも非共有のままになる。

一方、フックされたＤｉｒｅｃｔＤｒａｗ描画命令が監視対象とされているアプリケーションによるものである場合（Ｓ１３１１でＹＥＳ）、フックされたＤｉｒｅｃｔＤｒａｗ描画命令はＯＳ２１に返却されずに、描画命令変換部１４５２によってＧＤＩ描画命令に変換される（Ｓ１３１４）。仮想描画部１８は、変換後のＧＤＩ描画命令に基づいて、メモリ上の仮想的なディスプレイに対して描画を行う（Ｓ１３１４）。

第２画面共有サーバ１７は、仮想的なディスプレイの画面情報を取得し、秘匿共有を行っている画面共有クライアントに対してのみ当該画面情報を転送する。その結果、画面共有サーバ１１が起動しているＰＣ１０ａでは、秘匿共有アプリケーションのウィンドウはＤｉｒｅｃｔＤｒａｗによって表示装置１０６に描画される。したがって、秘匿共有が許可されていない画面共有クライアントには、当該アプリケーションウィンドウは表示されない。しかし、秘匿共有が許可されている画面共有クライアントには当該アプリケーションウィンドウが表示される。

上述したように、第十三の実施の形態における画面共有システム１によれば、オーバーレイ描画によって非共有とされるウィンドウを、特定の画面共有クライアントに対してのみ共有表示させることができる。

次に、第十四の実施の形態について説明する。第十四の実施の形態では、第十の実施の形態のように、ＧＤＩ描画命令がＤｉｒｅｃｔＤｒａｗ描画命令に変換されることによって非共有とされているウィンドウを、特定の画面共有クライアントにのみ秘匿共有させる例について説明する。

図４６は、第十四の実施の形態の各ＰＣにおける画面共有機能の機能構成例を示す図である。図４６中、図４２と同一部分には同一符号を付し、その説明は省略する。

図４２においては、共有制御部１４において、共有設定部１４５が非共有設定部１４４に置き換わっている。なお、非共有設定部１４４は、図３２において説明した非共有設定部１４４に相当する。

図４７は、第十四の実施の形態における非共有設定部の機能構成例を示す図である。図４７中、図３３と同一部分には同一符号を付し、その説明は省略する。

図４８は、第十四の実施の形態の画面共有システムにおいて秘匿共有を実現するための処理手順を説明するためのフローチャートである。

非共有アプリケーションが起動されると、ウィンドウ管理部１４２は、非共有設定部１４４に対して当該アプリケーションからのＧＤＩ描画命令の監視を指示すると共に（Ｓ１４０１）、第２画面共有サーバ１７を起動する（Ｓ１４０２）。後述するように、この段階において、特定の画面共有クライアントに対してのみ当該アプリケーションウィンドウの秘匿共有が実行される。

その後、秘匿共有を行っているアプリケーションが終了した場合や、秘匿共有を中止して全ての画面共有クライアントに対して共有を許可した場合、又は全ての画面共有クライアントに対して当該アプリケーションのウィンドウが非共有とされた場合（Ｓ１４０３でＹＥＳ）、第２画面共有サーバ１７は終了し、秘匿共有の対象となっていたアプリケーションのＧＤＩ描画命令を監視対象から外す（Ｓ１４０４）。

続いて、ステップＳ１４０１において、ＧＤＩ描画命令の監視を指示された非共有設定部１４４による処理手順を説明する。図４９は、第十四の実施の形態における非共有設定部の処理手順を説明するためのフローチャートである。

ＧＤＩ描画命令フック部１４４１は、アプリケーションからのＧＤＩ描画命令をフックして監視している。ＧＤＩ描画命令フック部１４４１は、検出されたＧＤＩ描画命令が監視対象とされたアプリケーションのＧＤＩ描画命令でない場合は（Ｓ１４１１でＮＯ）ＧＤＩ描画命令をＯＳ２１に返却する（Ｓ１４１２）。これによって、このアプリケーションの画面情報はデスクトップ描画メモリ領域１０３１に描画される。したがって、当該アプリケーションウィンドウは画面共有される。

一方、検出されたＧＤＩ描画命令が監視対象とされたアプリケーションによるＧＤＩ描画命令の場合（Ｓ１４１１でＹＥＳ）、フックした描画命令はＯＳ２１に返却されずに、ＧＤＩ描画命令フック部１４４１によって複製される（Ｓ１４１３）。複製元又は複製先のいずれか一方のＧＤＩ描画命令は仮想描画部１８に出力され、他方は描画命令変換部１４４２に出力される。

仮想描画部１８は、ＧＤＩ描画命令に基づいて、メモリ上に作成された仮想的なディスプレイ上にビットマップデータの描画を行う（Ｓ１４１４）。描画命令変換部１４４２は、ＧＤＩ描画命令をＤｉｒｅｃｔＤｒａｗ描画命令に変換する（Ｓ１４１５）。ＤｉｒｅｃｔＤｒａｗ描画命令部１４４３が、変換されたＤｉｒｅｃｔＤｒａｗ描画命令をＯＳ２１に対して発行すると、その描画命令に基づく画面情報はグラフィックアクセラレータによって、表示装置１０６に描画される（Ｓ１４１６）。

仮想描画部１８によって仮想的なディスプレイに描画された画面情報は、第２画面共有サーバ１７によって取得される。第２画面共有サーバ１７は秘匿共有を行っている画面共有クライアントにのみその画面情報を転送する。

その結果、画面共有サーバ１１が起動しているＰＣ１０ａでは、秘匿共有アプリケーションのウィンドウはＤｉｒｅｃｔＤｒａｗによって表示装置１０６に描画される。したがって、秘匿共有が許可されていない画面共有クライアントには、当該アプリケーションウィンドウは表示されない。しかし、秘匿共有が許可されている画面共有クライアントには当該アプリケーションウィンドウが表示される。

上述したように、第十四の実施の形態における画面共有システム１によれば、オーバーレイ描画によって非共有とされるウィンドウを、特定の画面共有クライアントに対してのみ共有表示させることができる。

次に、第十五の実施の形態について説明する。第十五の実施の形態は、第十四の実施の形態の変形例であるため、相違点について説明する。

図５０は、第十五の実施の形態における非共有設定部の機能構成例を示す図である。図５０中、図４７と同一部分には同一符号を付し、その説明は省略する。図５０における非共有設定部１４４は、描画命令変換部１４４２を有していない点において図４７と異なる。

図５１は、第十五の実施の形態における非共有設定部の処理手順を説明するためのフローチャートである。

ＧＤＩ描画命令フック部１４４１は、アプリケーションからのＧＤＩ描画命令をフックして監視している。ＧＤＩ描画命令フック部１４４１は、検出されたＧＤＩ描画命令が監視対象とされたアプリケーションのＧＤＩ描画命令でない場合は（Ｓ１５１１でＮＯ）ＧＤＩ描画命令をＯＳ２１に返却する（Ｓ１５１２）。これによって、このアプリケーションの画面情報はデスクトップ描画メモリ領域１０３１に描画される。したがって、当該アプリケーションウィンドウは画面共有される。

一方、検出されたＧＤＩ描画命令が監視対象とされたアプリケーションによるＧＤＩ描画命令の場合（Ｓ１５１１でＹＥＳ）、フックした描画命令はＯＳ２１に返却されずに、仮想描画部１８に出力される。仮想描画部１８は、ＧＤＩ描画命令に基づいて、メモリ上に作成された仮想的なディスプレイ上にビットマップデータの描画を行う（Ｓ１５１３）。第２画面共有サーバ１７は、仮想的なディスプレイの画面情報（ビットマップデータ）を取得して、秘匿共有を行っている画面共有クライアントにのみその画面情報を転送する。

一方、ＤｉｒｅｃｔＤｒａｗ描画命令部１４４３は、仮想的なディスプレイの画面情報（ビットマップデータ）を取得する（Ｓ１５１４）。続いて、ＤｉｒｅｃｔＤｒａｗ描画命令部１４４３は、取得したビットマップデータのＤｉｒｅｃｔＤｒａｗによる描画命令を呼び出す。これによって、仮想的なディスプレイのビットマップデータがグラフィックアクセラレータによって表示装置１０６に描画される（Ｓ１５１５）。

その結果、画面共有サーバ１１が起動しているＰＣ１０ａでは、秘匿共有アプリケーションのウィンドウはＤｉｒｅｃｔＤｒａｗによって表示装置１０６に描画される。したがって、秘匿共有が許可されていない画面共有クライアントには、当該アプリケーションウィンドウは表示されない。しかし、秘匿共有が許可されている画面共有クライアントには当該アプリケーションウィンドウが表示される。

上述したように、第十五の実施の形態における画面共有システム１によれば、第十四の実施の形態と同様、オーバーレイ描画によって非共有とされるウィンドウを、特定の画面共有クライアントに対してのみ共有表示させることができる。

なお、画面共有の仕組みとして、画面共有サーバは、デスクトップ画面の画面情報をビットマップ画像として取得してもよいし、ＧＤＩ等の描画命令をＯＳからフックして取得し、取得された描画命令をネットワークを介して画面共有クライアントに送信してもよい。後者の場合、画面共有クライアントは受信したＧＤＩ描画命令を使って描画を行うことによって共有画面を表示させることができる。

また、オーバーレイ描画手段としては、ＤｉｒｅｃｔＤｒａｗの他、Ｄｉｒｅｃｔ３ＤやＤｉｒｅｃｔＸ等のそのたのものを用いても良い。

以上、本発明の実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

共有ウィンドウと非共有ウィンドウとが重なっている様子を示す図である。 ＶＮＣの動作原理を説明するための図である。 本発明の実施の形態における画面共有システムの構成例を示す図である。 本発明の実施の形態におけるＰＣのハードウェア構成例を示す図である。 第一の実施の形態の各ＰＣにおける画面共有機能の機能構成例を示す図である。 仮想的なメモリ空間上におけるデスクトップ描画メモリ領域とレイヤ属性ウィンドウ描画メモリ領域との配置例を示す図である。 デスクトップ描画メモリ領域とレイヤ属性ウィンドウ描画メモリ領域との用い方を説明するための図である。 画面共有サーバが共有画面の対象とする画面情報を説明するための図である。 第一の実施の形態における画面共有関係を示す図である。 第一の実施の形態における各ＰＣにおける表示画面の状態の例を示す図である。 一部のウィンドウが共有されない状態を示す図である。 第一の実施の形態における画面共有システムの処理手順を説明するためのフローチャートである。 第二の実施の形態における画面共有システムの処理手順を説明するためのフローチャートである。 第三の実施の形態における画面共有システムの処理手順を説明するためのフローチャートである。 共有許否ダイアログの表示例を示す図である。 第四の実施の形態における非共有ウィンドウの表示例を示す図である。 第五の実施の形態の画面共有サーバにおいて画面共有クライアントからのマウスイベントが受信された際の処理を説明するためのフローチャートである。 第五の実施の形態の画面共有サーバにおいて画面共有クライアントからのキーボードイベントが受信された際の処理を説明するためのフローチャートである。 第六の実施の形態の画面共有システムにおける処理を説明するためのフローチャートである。 第六の実施の形態の画面共有クライアントにおいてマウスイベントが発生した際の処理を説明するためのフローチャートである。 第七の実施の形態における画面共有関係を示す図である。 第七の実施の形態における画面共有関係において発生し得る各ＰＣにおける表示画面の状態の例を示す図である。 第七の実施の形態における画面共有システムの処理手順を説明するためのフローチャートである。 第七の実施の形態における画面共有システムにおける各ＰＣの表示画面の状態の例を示す図である。 第八の実施の形態の各ＰＣにおける画面共有機能の機能構成例を示す図である。 第八の実施の形態における画面共有関係において発生し得る各ＰＣにおける表示画面の状態の例を示す図である。 第八の実施の形態における画面共有システムの処理手順を説明するためのフローチャートである。 第八の実施の形態における画面共有システムにおける各ＰＣの表示画面の状態の例を示す図である。 第八の実施の形態においてアノテーションを行う側が共有の許否を設定する場合の各ＰＣにおける画面共有機能の機能構成例を示す図である。 第八の実施の形態においてアノテーションを行う側が共有の許否を設定する場合の画面共有システムの処理手順を説明するためのフローチャートである。 アプリケーションによる描画の仕組みを説明するための図である。 第十の実施の形態の各ＰＣにおける画面共有機能の機能構成例を示す図である。 第十の実施の形態における非共有設定部の機能構成例を示す図である。 第十の実施の形態における画面共有システムの処理手順を説明するためのフローチャートである。 第十の実施の形態における非共有設定部の処理手順を説明するためのフローチャートである。 第十一の実施の形態における非共有設定部の機能構成例を示す図である。 第十一の実施の形態における非共有設定部の処理手順を説明するためのフローチャートである。 複数の画面共有クライアントのうち特定の画面共有クライアントのみに画面共有を許可した場合の各ＰＣの表示画面の状態を示す図である。 第十二の実施の形態の各ＰＣにおける画面共有機能の機能構成例を示す図である。 第２画面共有サーバが転送対象とする画面情報を説明するための図である。 第十二の実施の形態の画面共有システムにおいて秘匿共有を実現するための処理手順を説明するためのフローチャートである。 第十三の実施の形態の各ＰＣにおける画面共有機能の機能構成例を示す図である。 第十三の実施の形態における共有設定部の機能構成例を示す図である。 第十三の実施の形態の画面共有システムにおいて秘匿共有を実現するための処理手順を説明するためのフローチャートである。 第十三の実施の形態における共有設定部の処理手順を説明するためのフローチャートである。 第十四の実施の形態の各ＰＣにおける画面共有機能の機能構成例を示す図である。 第十四の実施の形態における非共有設定部の機能構成例を示す図である。 第十四の実施の形態の画面共有システムにおいて秘匿共有を実現するための処理手順を説明するためのフローチャートである。 第十四の実施の形態における非共有設定部の処理手順を説明するためのフローチャートである。 第十五の実施の形態における非共有設定部の機能構成例を示す図である。 第十五の実施の形態における非共有設定部の処理手順を説明するためのフローチャートである。

符号の説明

１ 画面共有システム
１０ａ、１０ｂ、１０ｃ、１０ｄ ＰＣ
１１、５１２ 画面共有サーバ
１２、５２２ 画面共有クライアント
１３ 共有ＰＣ管理部
１４ 共有制御部
１５ ソケット通信部
１６ アノテーションアプリ
１７ 第２画面共有サーバ
１８ 仮想描画部
１９ 非共有指示部
２１ ＯＳ
２２ ディスプレイドライバ
２３ ＶＲＡＭ
５０ ネットワーク
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ 演算処理装置
１０５ インタフェース装置
１０６ 表示装置
１０７ 入力装置
１１１、５１２１ 画面データ取得部
１１２、５１２２ 画面データ送信部
１１３、５１２３ 入力イベント受信部
１１４、５１２４ 入力イベント生成部
１２１、５２２１ 画面データ受信部
１２２、５２２２ 画面データ表示部
１２３、５２２３ 入力イベント取得部
１２４、５２２４ 入力イベント送信部
１３１ 共有接続管理部
１３２ メンバ管理部
１３３ 操作権管理部
１４１ ウィンドウ監視部
１４２ ウィンドウ管理部
１４３ レイヤ属性設定部
１４４ 非共有設定部
１４５ 共有設定部
５１０ サーバＰＣ
５１１、５２１ ＯＳ通信部
５２０ クライアントＰＣ
１０３１ デスクトップ描画メモリ領域
１０３２ レイヤ属性ウィンドウ描画メモリ領域
１４４１ ＧＤＩ描画命令フック部
１４４２ 描画命令変換部
１４４３ ＤｉｒｅｃｔＤｒａｗ描画命令部
１４４４ 仮想描画部
１４５１ ＤｉｒｅｃｔＤｒａｗ描画命令フック部
１４５２ 描画命令変換部
１４５３ ＤｉｒｅｃｔＤｒａｗ描画命令部
Ｂ バス

Claims (32)

1. 表示装置に表示させる画面情報が記録された第一のメモリ領域より該画面情報を取得し、取得された画面情報をネットワークを介して接続する他のコンピュータに送信することにより前記他のコンピュータに前記画面情報を共有表示させる画面共有サーバ手段と、
   前記他のコンピュータに共有表示させない非共有画面の画面情報について前記第一のメモリ領域への記録は行わないで前記表示装置に表示させる非共有表示制御手段とを有することを特徴とする画面共有サーバ装置。
2. 前記非共有表示制御手段は、前記非共有画面の画面情報を前記第一のメモリ領域とは異なる前記第二のメモリ領域に記録させることを特徴とする請求項１記載の画面共有サーバ装置。
3. 前記第二のメモリ領域に記録された画面情報を取得し、取得された前記画面情報をネットワークを介して接続する他のコンピュータに送信する第二の画面共有サーバ手段を有することを特徴とする請求項２記載の画面共有サーバ装置。
4. 前記非共有表示制御手段は、前記非共有画面に対してレイヤ属性を付与することにより、前記非共有画面の画面情報の前記第一のメモリ領域への記録は行わせないことを特徴とする請求項１乃至３いずれか一項記載の画面共有サーバ装置。
5. 前記非共有表示制御手段は、前記非共有画面をオーバーレイ表示させることにより、前記非共有画面の画面情報の前記第一のメモリ領域への記録は行わせないことを特徴とする請求項１乃至４いずれか一項記載の画面共有サーバ装置。
6. 前記非共有表示制御手段は、
   前記画面情報の前記第一のメモリ領域への描画命令をフックする描画命令フック手段と、
   フックされた前記描画命令をオーバーレイ表示に対応する描画命令に変換する描画命令変換手段と、
   前記描画命令変換手段によって変換された前記オーバーレイ表示に対応する描画命令に基づいて、前記画面情報を前記表示装置にオーバーレイ表示させるオーバーレイ表示手段とを有することを特徴とする請求項５記載の画面共有サーバ装置。
7. 前記非共有表示制御手段は、
   オーバーレイ表示に対する描画命令をフックするオーバーレイ描画命令フック手段と、
   前記オーバーレイ表示に対する描画命令に基づいて前記第二のメモリ領域に前記画面情報を描画する描画手段とを有することを特徴とする請求項３記載の画面共有サーバ装置。
8. 前記非共有表示制御手段は、
   前記画面情報の前記第一のメモリ領域への描画命令をフックする描画命令フック手段と、
   前記描画命令フック手段によってフックされた前記描画命令に基づいて前記第二のメモリ領域に前記画面情報を描画する描画手段と、
   前記描画命令フック手段によってフックされた前記描画命令をオーバーレイ表示に対する描画命令に変換する描画命令変換手段と、
   前記描画命令変換手段によって変換された前記オーバーレイ表示に対する描画命令に基づいて、前記画面情報を前記表示装置にオーバーレイ表示させるオーバーレイ表示手段とを有することを特徴とする請求項３記載の画面共有サーバ装置。
9. 前記画面共有サーバ手段は、画面共有を行っている前記他のコンピュータにおける入力イベントの位置情報を含むイベント情報を受信するイベント情報受信手段と、
   前記イベント情報に基づいて前記入力イベントに対応するイベントを発生させるイベント発生手段とを有し、
   有し、
   前記イベント情報受信手段によって受信された前記イベント情報に含まれている前記位置情報に基づいて、前記入力イベントが前記非共有画面に影響すると判定された場合は、前記イベント発生手段は前記入力イベントに対応するイベントを発生させないことを特徴とする請求項１乃至８いずれか一項記載の画面共有サーバ装置。
10. 前記共有表示の許否を判定するための文字列を管理する文字列管理手段を有し、
    前記非共有表示制御手段は、表示されるウィンドウに関する文字列と前記文字列管理手段に管理されている文字列との比較に基づいて、前記ウィンドウに係る前記画面情報を前記第一のメモリ領域に記録するか否かを判断することを特徴とする請求項１乃至９いずれか一項記載の画面共有サーバ装置。
11. 前記非共有表示制御手段は、表示されるウィンドウに係るアプリケーションの識別名と前記文字列管理手段に管理されている文字列との比較に基づいて、前記ウィンドウに係る前記画面情報を前記第一のメモリ領域に記録するか否かを判断することを特徴とする請求項１０記載の画面共有サーバ装置。
12. 前記非共有表示制御手段は、表示されるウィンドウの名前と前記文字列管理手段に管理されている文字列との比較に基づいて、前記ウィンドウに係る前記画面情報を前記第一のメモリ領域に記録するか否かを判断することを特徴とする請求項１０又は１１記載の画面共有サーバ装置。
13. 前記非共有表示制御手段は、ウィンドウの表示に際し当該ウィンドウの前記共有表示の許否をユーザに入力させることを特徴とする請求項１乃至１２いずれか一項記載の画面共有サーバ装置。
14. ネットワークを介して接続する他のコンピュータより画面情報を受信し、受信された画面情報に基づいて前記表示装置への表示を行なう画面共有クライアント手段を有し、
    前記非共有表示制御手段は、前記画面共有クライアント手段が受信した前記画面情報については前記第一のメモリ領域への記録は行わないで前記表示装置に表示させることを特徴とする請求項１乃至１３いずれか一項記載の画面共有サーバ装置。
15. 前記非共有表示制御手段は、前記非共有画面の視覚的な属性を共有表示される画面と異なるものとすることを特徴とする請求項１乃至１４いずれか一項記載の画面共有サーバ装置。
16. ネットワークを介して接続する他のコンピュータとの画面共有を実行する画面共有サーバ装置における画面共有方法であって、
    表示装置に表示させる画面情報が記録された第一のメモリ領域より該画面情報を取得し、取得された画面情報をネットワークを介して接続する他のコンピュータに送信することにより前記他のコンピュータに前記画面情報を共有表示させる画面共有サーバ手順と、
    前記他のコンピュータに共有表示させない非共有画面の画面情報について前記第一のメモリ領域への記録は行わないで前記表示装置に表示させる非共有表示制御手順とを有することを特徴とする画面共有方法。
17. 前記非共有表示制御手順は、前記非共有画面の画面情報を前記第一のメモリ領域とは異なる前記第二のメモリ領域に記録させることを特徴とする請求項１６記載の画面共有方法。
18. 前記第二のメモリ領域に記録された画面情報を取得し、取得された前記画面情報をネットワークを介して接続する他のコンピュータに送信する第二の画面共有サーバ手順を有することを特徴とする請求項１７記載の画面共有方法。
19. 前記非共有表示制御手順は、前記非共有画面に対してレイヤ属性を付与することにより、前記非共有画面の画面情報の前記第一のメモリ領域への記録は行わせないことを特徴とする請求項１６乃至１８いずれか一項記載の画面共有方法。
20. 前記非共有表示制御手順は、前記非共有画面をオーバーレイ表示させることにより、前記非共有画面の画面情報の前記第一のメモリ領域への記録は行わせないことを特徴とする請求項１６乃至１９いずれか一項記載の画面共有方法。
21. 前記非共有表示制御手順は、
    前記画面情報の前記第一のメモリ領域への描画命令をフックする描画命令フック手順と、
    フックされた前記描画命令をオーバーレイ表示に対応する描画命令に変換する描画命令変換手順と、
    前記描画命令変換手順において変換された前記オーバーレイ表示に対応する描画命令に基づいて、前記画面情報を前記表示装置にオーバーレイ表示させるオーバーレイ表示手順とを有することを特徴とする請求項２０記載の画面共有方法。
22. 前記非共有表示制御手順は、
    オーバーレイ表示に対する描画命令をフックするオーバーレイ描画命令フック手順と、
    前記オーバーレイ表示に対する描画命令に基づいて前記第二のメモリ領域に前記画面情報を描画する描画手順とを有することを特徴とする請求項１８記載の画面共有方法。
23. 前記非共有表示制御手順は、
    前記画面情報の前記第一のメモリ領域への描画命令をフックする描画命令フック手順と、
    前記描画命令フック手順においてフックされた前記描画命令に基づいて前記第二のメモリ領域に前記画面情報を描画する描画手順と、
    前記描画命令フック手順においてフックされた前記描画命令をオーバーレイ表示に対する描画命令に変換する描画命令変換手順と、
    前記描画命令変換手順において変換された前記オーバーレイ表示に対する描画命令に基づいて、前記画面情報を前記表示装置にオーバーレイ表示させるオーバーレイ表示手順とを有することを特徴とする請求項１８記載の画面共有方法。
24. 前記画面共有サーバ手順は、画面共有を行っている前記他のコンピュータにおける入力イベントの位置情報を含むイベント情報を受信するイベント情報受信手順と、
    前記イベント情報に基づいて前記入力イベントに対応するイベントを発生させるイベント発生手順とを有し、
    有し、
    前記イベント情報受信手順において受信された前記イベント情報に含まれている前記位置情報に基づいて、前記入力イベントが前記非共有画面に影響すると判定された場合は、前記イベント発生手順は前記入力イベントに対応するイベントを発生させないことを特徴とする請求項１６乃至２３いずれか一項記載の画面共有方法。
25. 前記共有表示の許否を判定するための文字列を管理する文字列管理手順を有し、
    前記非共有表示制御手順は、表示されるウィンドウに関する文字列と前記文字列管理手順において管理されている文字列との比較に基づいて、前記ウィンドウに係る前記画面情報を前記第一のメモリ領域に記録するか否かを判断することを特徴とする請求項１６乃至２４いずれか一項記載の画面共有方法。
26. 前記非共有表示制御手順は、表示されるウィンドウに係るアプリケーションの識別名と前記文字列管理手順において管理されている文字列との比較に基づいて、前記ウィンドウに係る前記画面情報を前記第一のメモリ領域に記録するか否かを判断することを特徴とする請求項２５記載の画面共有方法。
27. 前記非共有表示制御手順は、表示されるウィンドウの名前と前記文字列管理手順において管理されている文字列との比較に基づいて、前記ウィンドウに係る前記画面情報を前記第一のメモリ領域に記録するか否かを判断することを特徴とする請求項２５又は２６記載の画面共有方法。
28. 前記非共有表示制御手順は、ウィンドウの表示に際し当該ウィンドウの前記共有表示の許否をユーザに入力させることを特徴とする請求項１６乃至２７いずれか一項記載の画面共有方法。
29. ネットワークを介して接続する他のコンピュータより画面情報を受信し、受信された画面情報に基づいて前記表示装置への表示を行なう画面共有クライアント手順を有し、
    前記非共有表示制御手順は、前記画面共有クライアント手順において受信された前記画面情報については前記第一のメモリ領域への記録は行わないで前記表示装置に表示させることを特徴とする請求項１６乃至２８いずれか一項記載の画面共有方法。
30. 前記非共有表示制御手順は、前記非共有画面の視覚的な属性を共有表示される画面と異なるものとすることを特徴とする請求項１６乃至２９いずれか一項記載の画面共有方法。
31. コンピュータに、
    表示装置に表示させる画面情報が記録された第一のメモリ領域より該画面情報を取得し、取得された画面情報をネットワークを介して接続する他のコンピュータに送信することにより前記他のコンピュータに前記画面情報を共有表示させる画面共有サーバ手順と、
    前記他のコンピュータに共有表示させない非共有画面の画面情報について前記第一のメモリ領域への記録は行わないで前記表示装置に表示させる非共有表示制御手順とを実行させるための画面共有プログラム。
32. 請求項３１記載の画面共有プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images