JP2006287647A - 画像通信方法および通信装置 - Google Patents

Abstract

【課題】ネットワ−クを介して複数の端末間で画像データの伝送を行う場合、一方の端末からの画像データの送信を停止させること。
【解決手段】 ＳＩＰライブラリＳＩＰ＿Ｌｉｂ１は、ＶＣクライアントＶＣ＿ＰＣ−２に「Ｉｎｖｉｔｅ（ｖｉｄｅｏ：ＲｅｃｅｉｖｅＯｎｌｙ）」を送信する（Ｓ１２２）。ＳＩＰライブラリＳＩＰ＿Ｌｉｂ２は、ＶＣクライアントＶＣ＿ＰＣ−１に「ＯＫ（Ｖｉｄｅｏ：ＳｅｎｄＲｅｃｅｉｖｅ）」を返信する（Ｓ１２６）。ＳＩＰライブラリＳＩＰ＿Ｌｉｂ１は、ＶＣクライアントＶＣ＿ＰＣ−２に「Ａｃｋ」を送信する（Ｓ１２８）。ＶＣクライアントＶＣ＿ＰＣ−１側では、カメラＣ１の撮影を止め、ビデオウィンドウＶＷ１１を閉じる（Ｓ１３０）。ＶＣクライアントＶＣ＿ＰＣ−１側から送られてきたビデオデータを表示するビデオウィンドウＶＷ２１を閉じる（Ｓ１３２）。
【選択図】 図３

Description

本発明は、ネットワークに接続された複数の端末間で画像データを双方向に通信する画像通信方法および通信装置に関する。

ＴＶ電話等で、相手側端末に自画像の表示をさせたくない場合がある。自画像の表示を表示させない時に、相手側端末に自画像の換わりにミュート画像を送信して、ミュート中であることを相手側に知らせる技術がある（特許文献１）。
特開平６−２３３２８９号公報（［０００５］，［００１３］，［００１５］，［００２０］，［００３１］，［００３４］，［００３５］，図１，５，６，７）

しかしながら従来の技術では、送信する画像がミュート画像になるだけで互いに画像の双方向通信は継続される。自端末の処理の負荷が高く、負荷を低減させるために画像データの送信を停止したい場合には、自画像の換わりにミュート画像を送信し続けるため負荷を低減することが出来ない。

本発明の目的は、ネットワ−クを介して複数の端末間で画像データの伝送を行う場合、一方の端末からの画像データの送信を停止し得る画像通信方法および通信装置を提供することにある。

本発明の一例に係わる画像通信方法は、ネットワ−クを介して第１の端末と第２の端末との間で画像データの伝送を行う画像通信方法であって、前記第１の端末から前記第２の端末への第１の画像データの伝送と前記第２の端末から前記第１の端末への第２の画像データの伝送とを含む双方向画像通信を実行するステップと、前記第１の端末および前記第２の端末の一方から他方に対して、前記第１の画像データおよび前記第２の画像データの一方の伝送を停止することを通知するステップと、前記通知に応じて前記第１の画像データと前記第２の画像データの伝送の一方を停止して、前記第１の端末と前記第２の端末との間で、片方向画像通信を実行するステップとを含むことを特徴とする。

本発明の一例に係わる通信装置は、ネットワークを介して画像通信を実行する通信装置において、相手端末から送信される第１の画像データの受信と前記相手端末への第２の画像データの送信とを実行する双方向画像通信手段と、前記相手端末から、前記第１の画像データおよび前記第２の画像データの一方の伝送を停止することが通知された場合、前記第１の画像データの受信と前記第２の画像データの送信の一方を停止して、前記相手端末との片方向画像通信を実行する片方向画像通信手段とを具備することを特徴とする通信装置。

本発明によれば、一方の端末からの画像データの送信を停止することができる。

本発明の実施の形態を以下に図面を参照して説明する。

（第１の実施形態）
図１は本発明の一実施形態に係わるビジュアルコミュニケーションシステムの全体構成を示す図である。

図１に示すように、この実施形態のビジュアルコミュニケーションシステムは、電話交換機３と、この電話交換機３に電話回線７を介して接続された少なくとも一台の電話端末Ｔｅｌ−１〜Ｔｅｌ−３と、電話交換機３に例えばロ一カルエリアネットワーク（以下ＬＡＮ５と称す）などのＩＰネットワークを介して接続されたサーバコンピュータとしてのビジュアルコミュニケーションサーバ１（以下ＶＣサーバ１と称す）と、このＶＣサーバ１にＬＡＮ５を介して接続された少なくとも一台のクライアントコンピュータとしてのビジュアルコミュニケーションクライアントＶＣ＿ＰＣ−１〜ＶＣ＿ＰＣ−３（以下ＶＣクライアントＶＣ＿ＰＣ−１〜ＶＣ＿ＰＣ−３と称す）とを備えている。

なお、電話端末Ｔｅｌ−１〜Ｔｅｌ−３の機能はＶＣクライアントＶＣ＿ＰＣ−１〜ＶＣ＿ＰＣ−３のそれぞれに搭載されたソフトウェア（ソフトフォン）で実現され、電話回線７としてＬＡＮ５を用いる。

電話交換機３は、電話端末Ｔｅｌ−１〜Ｔｅｌ−３の挙動を検出する。つまり、電話交換機３は、電話端末Ｔｅｌ−１〜Ｔｅｌ−３の挙動を電話回線７を通じて検出し、検出した挙動に応じた回線交換手順を実行する。ある電話端末より相手の電話端末への発呼（電話番号の発信）が行われた際は、互いの電話端末同士が通話可能な状態となったことを検出して音声通信可能な状態にする。

その他、電話交換機３は、一方の電話端末Ｔｅｌ−１が相手に電話をかけているときの発着信中の挙動なども検知する。発着信の挙動とは、発信側の電話端末が行う相手電話端末の電話番号の発信動作・相手の電話端末の着信鳴動などがある。つまり、発着信の挙動とは、電話端末Ｔｅｌ−１〜Ｔｅｌ−３間で電話をかける、受ける、切る際の各電話端末Ｔｅｌ−１，Ｔｅｌ−３の挙動である。

各ＶＣクライアントＶＣ＿ＰＣ−１〜ＶＣ＿ＰＣ−３は、ＣＰＵ（Central Processing Unit）、メモリ、ディスプレイ、キーボート、マウス、ハードディスク装置、ＬＡＮインタフェース（以下ＬＡＮ＿Ｉ／Ｆと称す）、ＵＳＢインタフェース（以下ＵＳＢ＿Ｉ／Ｆと称す）などを備えた一般的なコンピュータである。

図２は、クライアントの概略構成を示すブロック図である。

ＬＡＮにＬＡＮインタフェースＬＡＮ＿Ｉ／Ｆが接続されている。ＬＡＮインタフェースＬＡＮ＿Ｉ／Ｆに制御部が接続されている。

セッション制御やクライアント情報の登録といったアプリケーションレイヤでの通信を行うためにＳＩＰ（Session Initiation Protocol）ライブラリＳＩＰ＿Ｌｉｂが実装されている。ＶＣサーバ１との間でＳＩＰのメッセージを送受信するために、ＯＳに備えられたＴＣＰ／ＩＰにより、ＶＣサーバ１との間でＬＡＮ５を通じた通信が行われる。

制御部はモード切替モジュールＭＣ、多方向画像通信モジュールＭＩＴ、片方向画像通信モジュールＳＩＴ、ウィンドウ制御部ＷＣ、監視部Ｍ、および通知部Ｎを有する。

カメラＣは、ＶＣクライアントの前にいる人の胸像を撮影するように設置されている。カメラＣで撮影された画像は、エンコード／デコード部ＥＤによってエンコードされて画像データが生成される。また、相手側のＶＣクライアントＶＣ＿ＰＣから送信された画像データはエンコード／デコード部ＥＤがデコードして、表示装置Ｄに表示される。エンコード／デコード部ＥＤの機能は、ハードウエアで実現しても良いし、エンコード／デコード機能のソフトウェアをＣＰＵが実行することによって実現しても良い。

監視部Ｍは、エンコード／デコード部ＥＤ、ＬＡＮ５の負荷を監視する。ユーザの操作、または監視部Ｍの監視結果に応じて通知部Ｎが、通信相手のクライアントに画像データの送信の停止、または画像データの設定の変更を通知する。

通話時、音声入力Ｖｉｎから音声が入力され、入力された音声がソフトフォンＳＰによって相手側ＶＣクライアントに送信される。相手側ＶＣクライアントから送信された音声データはソフトフォンによって、音声出力Ｖｏｕｔから出力される。

ハードディスク装置には、ビジュアルコミュニケーション機能を実現するテレビ会議用の画面を表示したり、カメラＣにより撮影された話者の映像（画像）を取り込みＶＣサーバ１へ送信するクライアントソフトウェアがインストールされている。また、ハードディスク装置には、電話端末の機能を実現するためのソフトフォンがインストールされている。

メモリには、予め自クライアントの識別情報であるクライアントＩＤと、関連付けを行う電話端末の識別情報である電話番号が対応してクライアント情報として登録されている。

クライアントソフトウェアの機能としては、ＶＣサーバ１との通信機能、ＶＣサーバ１へのログイン機能があり、これらの機能をＣＰＵとメモリなどが協動して実現する。

ＶＣサーバ１との通信機能は、ＶＣサーバ１とのセッション制御に関する信号の送受信を行ったり、メモリのクライアントＩＤや対応する電話番号などのクライアント情報をＶＣサーバ１へログインするための送受信を行ったりする。

ＶＣサーバ１は、ＣＰＵ、メモリ、ディスプレイ、キーボート、マウス、ハードディスク装置、ＬＡＮインタフェース（以下ＬＡＮ＿Ｉ／Ｆと称す）などを備えたコンピュータである。

ハードディスク装置には、オペレーティングシステム（以下ＯＳと称す）、サーバソフトウェアがインストールされている。ＯＳおよびサーバソフトウェアなどのソフトウェアと上記ハードウェアは、互いに協動して、ビジュアルコミュニケーション機能を実現する。

このビジュアルコミュニケーションシステムは、電話交換機は音声通話中である電話端末の組み合わせをＶＣサーバに通知する。ＶＣサーバは通知された電話端末に対応する全クライアントに通知する。この時、通話相手のクライアントのＩＰアドレス、ポート番号を通知する。ビデオ通信を行う場合、通知されたクライアントのＩＰアドレス、ポート番号に対してビデオ通信の開始要求、画像データの送受信を行う。

図３の通信シーケンス図を参照して、２台のＶＣクライアント間のビデオセッションを開始から、画像データの送信を中止する手順について説明する。

ユーザによってＶＣクライアントＶＣ＿ＰＣ−１（第１の端末）に搭載されたビデオアプリケーションＶＡ１のビデオボタンが操作されると、ビデオアプリケーションＶＡ１はＳＩＰライブラリＳＩＰ＿Ｌｉｂ１に「ビデオ接続要求」があったことを通知する（ステップＳ１０１）。ＳＩＰライブラリＳＩＰ＿Ｌｉｂ１は、「ビデオ接続要求」の通知に応答して、ＶＣクライアントＶＣ−ＰＣ−２に対して「Ｉｎｖｉｔｅ（Ｖｉｄｅｏ：ＳｅｎｄＲｅｃｅｉｖｅ）」を送信する（ステップＳ１０２）。「Ｉｎｖｉｔｅ（Ｖｉｄｅｏ：ＳｅｎｄＲｅｃｅｉｖｅ）」には、ＶＣクライアントＶＣ＿ＰＣ−１が送受信可能なビデオの解像度、フレームレート、及びビットレートの情報が含まれる。又、ＳＩＰライブラリＳＩＰ＿Ｌｉｂ１は、ビデオアプリケーションＶＡ１に、ＶＣクライアントＶＣ＿ＰＣ２に「Ｉｎｖｉｔｅ（Ｖｉｄｅｏ：ＳｅｎｄＲｅｃｅｉｖｅ）」を送信したことを通知する（ステップＳ１０３）。

ＳＩＰライブラリＳＩＰ＿Ｌｉｂ２は、「Ｉｎｖｉｔｅ（Ｖｉｄｅｏ：ＳｅｎｄＲｅｃｅｉｖｅ）」に応答して、ビデオアプリケーションＶＡ２に「ビデオ接続通知」を通知する（ステップＳ１０４）。ビデオアプリケーションＶＡ２は「ビデオ接続通知」に対して、ＳＩＰライブラリＳＩＰ＿Ｌｉｂ２に「接続受付」を通知する（ステップＳ１０５）。ＳＩＰライブラリＳＩＰ＿Ｌｉｂ２は、「接続受付」に応答してＶＣクライアントＶＣ＿ＰＣ−１に対して「ＯＫ（Ｖｉｄｅｏ：ＳｅｎｄＲｅｃｅｉｖｅ）」を返信する（ステップＳ１０６）。「ＯＫ（Ｖｉｄｅｏ：ＳｅｎｄＲｅｃｅｉｖｅ）」には、ＶＣクライアントＶＣ＿ＰＣ−２（第２の端末）が送受信可能なビデオの解像度、フレームレート、ビットレート情報が含まれる。又、ＳＩＰライブラリＳＩＰ＿Ｌｉｂ２は、ビデオアプリケーションＶＡ２に、ビデオアプリケーションＶＡ１に「Ｏｋ（Ｖｉｄｅｏ：ＳｅｎｄＲｅｃｅｉｖｅ）」を返信したことを通知する。

ＳＩＰライブラリＳＩＰ＿Ｌｉｂ１は、「Ｏｋ（Ｖｉｄｅｏ：ＳｅｎｄＲｅｃｅｉｖｅ）」に応答して、ＶＣクライアントＶＣ＿ＰＣ−２に「Ａｃｋ」を返信する（ステップＳ１０８）。

ＶＣクライアントＶＣ＿ＰＣ−２側が「Ａｃｋ」を受信すると、ＶＣクライアントＶＣ＿ＰＣ−１とＶＣクライアントＶＣ＿ＰＣ−２との間のセッションが確立する。

ＳＩＰライブラリＳＩＰ＿Ｌｉｂ１は、ビデオアプリケーションＶＡ１に、「ビデオ接続要求（ステップＳ１０１）」に対してＶＣクライアントＶＣ＿ＰＣ−２が応答してきたことを通知する（ステップＳ１０９）。ビデオアプリケーションＶＡ１は、図４に示すように、表示装置Ｄ１にビデオウィンドウＶＷ１１，ＶＷ１２を表示し（ステップＳ１１０）、ＶＣクライアントＶＣ＿ＰＣ１側のカメラＣ１で撮影し、エンコード・デコード部でエンコードされた画像データをＶＣクライアントＶＣ＿ＰＣ−２に送信する（ステップＳ１１１）。ビデオウィンドウＶＷ１１はＶＣクライアントＶＣ＿ＰＣ−１側のカメラＣ１の撮影された画像を表示し、ビデオウィンドウＶＷ１２は、ＶＣクライアントＶＣ＿ＰＣ−２からＶＣクライアントＶＣ＿ＰＣ−１に送られた画像データをエンコード・デコード部でデコードして得られた画像を表示する。

ＶＣクライアントＶＣ＿ＰＣ−１およびＶＣクライアントＶＣ＿ＰＣ−２間で双方向画像通信される画像データの解像度、フレームレート、及びビットレートは同じである。ステップＳ１０２およびステップＳ１０６で互いの解像度、フレームレート、及びビットレートが交換されているが、双方向画像通信される画像データの解像度、フレームレート、及びビットレートは低い性能のＶＣクライアントに合わせられる。

ＳＩＰライブラリＳＩＰ＿Ｌｉｂ２は、「Ａｃｋ」に応答して、ビデオアプリケーションＶＡ２に、「ビデオ接続完了」を通知する（ステップＳ１１２）。ビデオアプリケーションＶＡ２は、「ビデオ接続完了」に応答して、表示装置Ｄ２にビデオウィンドウＶＷ２１，ＶＷ２２を表示し（ステップＳ１１３）、ＶＣクライアントＶＣ＿ＰＣ２側のカメラＣ２で撮影された画像をＶＣクライアントＶＣ＿ＰＣ−１に送信する（ステップＳ１１４）。ビデオウィンドウＶＷ２１はＶＣクライアントＶＣ＿ＰＣ−１側のカメラＣ２で撮影された画像を表示し、ビデオウィンドウＶＷ２２はＶＣクライアントＶＣ＿ＰＣ−２側から送信された画像データを表示する。

以上で、双方向画像データ通信が行われる。双方向画像データ通信は、ＶＣクライアントＶＣ＿ＰＣ−１およびＶＣクライアントＶＣ＿ＰＣ−２のモード切替モジュールＭＣが多方向画像通信ＭＩＴを選択することで、画像データの送信／受信が行われる。

双方向ビデオ通信中、何らかの理由でユーザ１がＶＣクライアントＶＣ＿ＰＣ−２に対してビデオを送ることを止めたい場合、ユーザ１はビデオアプリケーションＶＡ１のビデオボタンを操作する。双方向ビデオ通信中に、ビデオアプリケーションＶＡ１のビデオボタンが操作されると、通知部Ｎ１が「ビデオ送信オフ」をＳＩＰライブラリＳＩＰ＿Ｌｉｂ１に通知する（ステップＳ１２１）。ＳＩＰライブラリＳＩＰ＿Ｌｉｂ１は、「ビデオ送信オフ」に応答して、ＶＣクライアントＶＣ＿ＰＣ−２に「Ｉｎｖｉｔｅ（ｖｉｄｅｏ：ＲｅｃｅｉｖｅＯｎｌｙ）」を送信する（ステップＳ１２２）。又、ＳＩＰライブラリＳＩＰ＿Ｌｉｂ１は、ＶＣクライアントＶＣ＿ＰＣ２に「「Ｉｎｖｉｔｅ（ｖｉｄｅｏ：ＲｅｃｅｉｖｅＯｎｌｙ）」を送信したことをビデオアプリケーションＶＡ１に通知する（ステップＳ１２３）。

ＳＩＰライブラリＳＩＰ＿Ｌｉｂ２は、「Ｉｎｖｉｔｅ（Ｖｉｄｅｏ：ＲｅｃｅｉｖｅＯｎｌｙ）」に応答して、「ビデオ接続更新」をビデオアプリケーションＶＡ２に通知する（ステップＳ１２４）。ビデオアプリケーションＶＡ２は、「ビデオ接続更新」に応答して、ＳＩＰライブラリＳＩＰ＿Ｌｉｂ２に「接続受付」を通知する（ステップＳ１２５）。ＳＩＰライブラリＳＩＰ＿Ｌｉｂ２は、「接続受付」に応答して、ＶＣクライアントＶＣ＿ＰＣ−１に「ＯＫ（Ｖｉｄｅｏ：ＳｅｎｄＲｅｃｅｉｖｅ）」を送信する（ステップＳ１２６）。又、ＳＩＰライブラリＳＩＰ＿Ｌｉｂ２は、ＶＣクライアントＶＣ＿ＰＣ１に「ＯＫ（Ｖｉｄｅｏ：ＳｅｎｄＲｅｃｅｉｖｅ）」を送信したことをビデオアプリケーションＶＡ２に通知する（ステップＳ１２７）。

ＳＩＰライブラリＳＩＰ＿Ｌｉｂ１は、「ＯＫ（Ｖｉｄｅｏ：ＳｅｎｄＲｅｃｅｉｖｅ）」に応答して、ＶＣクライアントＶＣ＿ＰＣ−２に「Ａｃｋ」を送信する（ステップＳ１２８）。

又、ＳＩＰライブラリＳＩＰ＿Ｌｉｂ１は、「ビデオ送信オフ（ステップＳ１２１）」に対して、ＶＣクライアントＶＣ＿ＰＣ−２から応答が有ったことを通知（「ビデオ接続応答」）する（ステップＳ１２９）。「ビデオ接続応答」が通知されると、モード切替モジュールＭＣ１が片方向画像通信モジュールＳＩＴ１を選択する。片方向画像通信モジュールＳＩＴは、図５に示すように、カメラＣ１の撮影を止め、ビデオウィンドウＶＷ１１を閉じる（ステップＳ１３０）。

ＳＩＰライブラリＳＩＰ＿Ｌｉｂ２は、「Ａｃｋ」に応答して、ビデオアプリケーションＶＡ２に「ビデオ接続完了」を通知する（ステップＳ１３１）。「ビデオ接続完了」通知に応答して、モード切替モジュールＭＣ２が片方向画像通信モジュールＳＩＴ２を選択する。片方向画像通信モジュールＳＩＴ２は、図５に示すように、ＶＣクライアントＶＣ＿ＰＣ−１側から送られてきたビデオデータを表示するビデオウィンドウＶＷ２１を閉じる（ステップＳ１３２）。

以上の処理で、ＶＣクライアントＶＣ＿ＰＣ−１からＶＣクライアントＶＣ＿ＰＣ−２に画像データが送信されないが、ＶＣクライアントＶＣ＿ＰＣ−２からビデオがＶＣクライアントＶＣ＿ＰＣ−１に画像データが送られ、片方向画像通信が実行される。

片方向画像通信時、データのビデオウィンドウＶＷ２１を閉じることで、トラブルで画像が表示されなくなったのではなく、ＶＣクライアントＶＣ＿ＰＣ−１の通知によって画像データを送信することを止めたということが分かる。

ビデオウィンドウＶＷ２１の閉じ方として、ＶＣクライアントＶＣ＿ＰＣ−２の使用者が相手のビデオ送信停止を容易に連想できるように、画面が徐々に小さくなって最後になくなるようなメッセージ性のあるウィンドウクローズの効果を用いても良い。

また、ネットワーク障害による通信断、もしくは、通信品質の著しい低下時には、受信側クライアントの監視部Ｍが受信動画データがない、もしくは、不完全であることを検出して、最終画像データを静止画として表示し続けても良い。この場合、片方向画像通信時と異なる表示形態であるので、ＬＡＮ５に不都合が生じていて画像データを正常に受信できていないということが分かる。

ＶＣクライアントＶＣ＿ＰＣ−１が、ＶＣクライアントＶＣ＿ＰＣ−１からの画像データの送信を停止することをＶＣクライアントＶＣ＿ＰＣ−２に通知し、ＶＣから送信されていた画像データを表示していたビデオウィンドウ２１を閉じる例について説明した。

しかし、ＶＣクライアントＶＣ＿ＰＣ−１からＶＣクライアントＶＣ＿ＰＣ−２に対して、画像データの送信の停止を命令することも可能である。この場合、ステップＳ１２２において、「Ｉｎｖｉｔｅ（Ｖｉｄｅｏ：ＲｅｃｅｉｖｅＯｎｌｙ）」の換わりに「Ｉｎｖｉｔｅ（Ｖｉｄｅｏ：ＳｅｎｄＯｎｌｙ）」をＶＣクライアントＶＣ＿ＰＣ−２に送信すれば良い。

また、上述した例ではユーザが画像データの送信の停止を指示していたが、自動的に画像データの送信の停止を通知することも可能である。例えば、監視部Ｍがデコード／エンコード部ＥＤの負荷が高いことを検知した場合、通知部Ｎが画像データの送信を停止することを相手側クライアントに通知する。画像データの送信を停止することによって、エンコード処理が不要となり、デコード／エンコード部の処理の負荷が低減する。

また、監視部ＭがＬＡＮの回線状況を認識し、双方向画像通信を実行することが出来ない場合に、通知部Ｎが一方のＶＣクライアントからの画像データの送信の停止を実行させる通知を行っても良い。ＬＡＮの回線状況を認識するのは、「Ｉｎｖｉｔｅ（Ｖｉｄｅｏ：ＳｅｎｄＲｅｃｅｉｖ）」の送信側、受信側のＶＣクライアントのどちらでも良い。また、ＶＣサーバが回線状況を監視し、回線状況に応じて一方のＶＣクライアントに画像データの送信の停止を実行させるように指示し、指示されたＶＣクライアントが相手側のＶＣクライアントに片方向画像通信を実行するように通知しても良い。

また、エンコード／デコード部ＥＤの負荷に応じて解像度、フレームレート、ビットレートを再設定し、相手側のＶＣクライアントに通知しても良い。解像度、フレームレート、ビットレートを再設定することによってデコード／エンコード部ＥＤの処理の負荷を低減させることができる。また、ＬＡＮの回線状況に応じて解像度、フレームレート、ビットレートを再設定し、相手側のＶＣクライアントに通知しても良い。

また、ＶＣクライアント１が、双方向画像通信されていた画像データの解像度、フレームレート、及びビットレートと異なる解像度、フレームレート、及びビットレートを含む画像情報（第２の画像情報）を相手側のＶＣクライアント２に通知することによって、新たな画像情報に基づいて生成された画像データの双方向画像通信を行うことも可能である。

（第２の実施形態）
第１の実施形態で述べたビジュアルコミュニケーションシステムは、アプリケーション共有機能を有している。アプリ共有機能とは、一方の通信ピア（自分もしくは通信相手）のＰＣ上で起動されているアプリケーションのウィンドウを、他方の通信ピア（通信相手もしくは自分）のＶＣクライアントの表示装置に表示する機能である。このようにして、アプリを共有している状態をアプリ共有状態と呼ぶ。アプリ共有は、二者の通信ピアのうちどちらからでも開始することができるが、一方が送信側になると他方は受信側となる。受信側となったクライアントは、そのアプリ共有が終了するまで、送信側になることはできない。この時、アプリケーションを起動している方を送信側、相手のアプリケーションウィンドウが表示されている方を受信側と呼ぶ。

アプリ共有中、送信側のマウスカーソルの動きは、受信側のアプリ共有画面上で同様に再現される。アプリ共有の受信側では、共有しているウィンドウに対応するアプリケーションがＰＣにインストールされている必要はない。原寸表示モードで、アプリケーション共有を行うことにより、受信側でも共有アプリを操作して内容を編集することが可能（共同編集機能）である。

図６は、アプリ共有のユーザインタフェース（ＵＩ）ウィンドウである。ユーザは、このウィンドウを操作してアプリ共有を使用を選択する。アプリ共有は、図６に示すように、「無通信状態」と「通信状態」との２つの状態を持つ。「通信状態」では、図６に示すように、通信ピアの各々は、一方が自側ＰＣ上の起動アプリ画面を送信する「送信側」、他方が送信側のアプリ画面が再現される「受信側」となる。

図６（ａ）は、無通信状態のＵＩウィンドウを表し、通信ピアの間で送信側/受信側が決定していない状態である。図６（ｂ）に示すＵＩウィンドウは、通信中状態でかつ自側が送信側となっている状態である。図６（ｃ）に示すＵＩウィンドウは、通信中状態でかつ自側が受信側となっている状態である。

アプリ共有ウィンドウに配置される各ユーザインタフェース（ＵＩ）について、最上部の「Application Sharing」１０はウィンドウタイトルである。Transmit Settings１１には送信側の設定及び操作ＵＩとして、「Application:」１２は共有するアプリを選択するリスト１３が有る。「Start/Stop:」１４はアプリ共有の開始/停止を操作するStartボタン１５およびStopボタン１６を有する。「Receive Editability:」１７は受信側に対して共有アプリへの編集権を与える(Yes)か否(No)かを設定するためのYesボタン１８およびNoボタン１９を有する。

Receive Settings２０には受信側の設定及び操作ユーザインタフェース（ＵＩ）として、「Material Window View Mode:」２１および「Restore Windows:」２２が有る。「Material Window View Mode:」２１は、ウィンドウ内での共有アプリの表示方法を設定するために、Original Sizeボタン２３、およびBest Fitボタン２４を有する。Original Sizeボタン２３は、送信側と同じサイズで表示することを設定する。Best Fitボタン２４は、受信側のウィンドウサイズに合わせて拡大縮小して全体表示することを設定する。

また、「Restore Window:」２２では複数のウィンドウを重ならないよう最適配置するかしないかを設定するために、Yesボタン２５およびNoボタン２６を有する。

図６（ａ）に示す「無通信状態」では、Transmit Settings（送信設定）１１、「Receive Settings（受信設定）」ともに設定可能である。選択されている設定は点灯（例えば、青色）する。Transmit Settings１１の設定は、将来的に、アプリ共有通信を開始(Startボタン押下)したときの初期値として使用される。「Receive Settings」の設定は、将来的に、アプリ共有の受信側になったときの初期値として使用される。

図６（ｂ）に示す「通信状態（送信側）」では、Transmit Settings１１の各ボタンが操作可能である。「Start/Stop:」１４のStartボタン１５が点灯して送信中であることを表す。Stopボタン１６の操作でアプリ共有が停止する。「Receiver Editability」ではNoボタン１９が点灯して受信側に編集する権限が無いことを表す。Yesボタン１８を操作することで、受信側が編集することが可能になる。「Receive Settings」の各ボタンは、送信側は受信側の状態を取得しないため、各ボタンはグレイアウト（Disable状態）となる。

図６（ｃ）に示す「通信状態（受信側）」では、Transmit Settings１１の各ボタンは操作することができない。「Start/Stop:」１４のStartボタン１５が点滅(Disable状態)して、相手側が送信中であることを表す。「Receiver Editability」１７はNoボタン１９が点滅(Disable状態)して、受信側が編集することができないことを表す。Transmit Settings１１の各ボタンはグレイアウト(Disable)状態のため操作することができない。

「アプリ共有通信中（受信側）状態」では、「Receive Settings」の各ボタンが操作可能である。「Material Window View Mode;」２１の「BestFitボタン」及び「Restore Windowボタン」の操作を行うことが可能であり、設定された何れか一方のボタンが点灯する。「Restore Windows:」２２のYesボタン２５及びNoボタン２６の操作を行うことが可能であり、設定された何れか一方のボタンが点灯する。

図７〜図９には、「Start/Stop:」１４の各ボタン１５，１６、「Receive Editability:」１７の各ボタン１８，１９、「Material Window View Mode:」２１の各ボタン２３，２４の３つのＵＩを例に挙げ、設定状態/操作可能状態の遷移を表した図である。

「Start/Stop:」１４の各ボタン１５，１６の設定状態/操作可能状態の遷移を図７を参照して説明する。図７に示すように、一方のクライアントがStartボタン１５を操作すると、「Start」がイネーブルになって、アプリ共有機能実行が実行され通信状態になる。このとき、Startボタン１５を操作した側が送信側になり、他方が受信側になる。通信中、送信側でStopボタン１６が操作されると、アプリ共有機能が停止する（無通信状態）。通信状態において、受信側では、「Start」がディスイネーブルで、Startボタン１５およびStartボタン１５を操作することが出来ない。

「Receive Editability:」１７の各ボタン１８，１９の設定状態/操作可能状態の遷移を図８を参照して説明する。図８に示すように、無通信状態で「Receive Settings（受信設定）」のYesボタン１８およびNoボタン１９は操作可能である。「編集可（Yes）」がイネーブルの状態で、Noボタン１９を操作すると、「編集不可（No）」がイネーブルになる。「編集不可（No）」がイネーブルの状態でYesボタン１８を操作すると、「編集可能（Yes）」がイネーブルになる。

無通信状態で送信者側の設定が「編集可（Yes）」がイネーブルの時に、Startボタン１５が操作されることで通信中状態になる（操作Ａ）。この時、受信者側で、「Receiver Editability」のYesボタン１８が点滅して、「編集可（Yes）」がイネーブルであることが分かる。

通信状態中、「編集可（Yes）」がイネーブルの設定状態でStopボタン１６が操作されると（操作Ｂ）、送信者側では「編集可（Yes）」がイネーブルの設定のままで無通信状態になる。受信者側では、「Receiver Editability」の設定は通信状態前の設定に戻る。

無通信状態で送信者側の設定が「編集不可（No）」がイネーブルの時に、Startボタン１５が操作されることで通信状態になる（操作Ｃ）。この時、受信者側で、「Receiver Editability」のNoボタン１９が点滅して、「編集不可（No）」がイネーブルの設定になっていることが分かる。

通信状態中、「編集不可（No）」がイネーブルの状態でStopボタン１６が操作されると（操作Ｄ）、送信者側では「編集不可（No）」がイネーブルのままで無通信状態になる。受信者側では、「Receiver Editability」の設定は通信状態前の設定に戻る。

通信状態中、受信者側の「Receiver Editability」の設定が「編集不可（No）」がイネーブルの状態でYesボタン１８を操作すると、「編集可（Yes）」がイネーブルの設定になる。この時、受信者側では、「編集可（Yes）」がイネーブルになり、Yesボタン１８が点灯する。

通信状態中、受信者側の「Receiver Editability」の設定が「編集可（Yes）」がイネーブルの状態でNoボタン１９を操作すると、「編集不可（No）」がイネーブルの設定になる。この時、受信者側では、「編集不可（No）」がイネーブルの設定になり、Noボタン１９が点灯する。

「Material Window View Mode:」２１の各ボタン２３，２４の設定状態/操作可能状態の遷移を図９を参照して説明する。

無通信状態では、Original Sizeボタン２３およびBest Fitボタン２４の操作が可能である。Startボタン１５が操作されて通信状態になると、送信側ではOriginal Sizeボタン２３およびBest Fitボタン２４を操作することが出来ない。また、受信側の「Material Window View Mode:」２１の設定は送信側に影響を与えないので、受信側の設定も表示されない。

受信側では、無通信状態の「Material Window View Mode:」２１の設定が初期設定としてイネーブルとなる。ユーザがOriginal Sizeボタン２３およびBest Fitボタン２４を操作することが可能であり、操作に応じた設定がイネーブルになる。

Stopボタン１６が操作され、通信状態から無通信状態になると、送信者側の「Material Window View Mode:」２１の設定は通信状態前の設定に戻る。受信側では、通信状態中の設定が初期設定となる。

上述したユーザインタフェースでは、操作用と状態表示用との両方のユーザインタフェースを持ち、ユーザインタフェース上の操作用エリアと状態表示用エリアを兼用することにより、画面上の領域を節約して表示することが可能になる。

また、操作用のインタフェース（例えばボタン）に設定状態を表示する機能を持たせることにより、ユーザによる操作と現在状態の確認をワンアクション化して、操作性を向上させることができる。

また、自側の状態表示用ユーザインタフェースに、状況に応じて相手側状態を表示することにより、相互の状態を確認することができる。

なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

第１の実施形態に係るビジュアルコミュニケーションシステムの全体構成を示す図。 第１の実施形態に係るクライアントの概略構成を示すブロック図。 第１の実施形態に係わるＶＣクライアントのビデオセッションの通信シーケンス図。 双方向画像通信時のＶＣクライアントの表示装置の表示画像を示す図。 片方向画像通信時のＶＣクライアントの表示装置の表示画像を示す図。 第２の実施形態に係わるアプリ共有のユーザインタフェースウィンドウを示す図。 「Start/Stop:」の各ボタンの設定状態/操作可能状態の遷移を表した図。 「Receive Editability:」の各ボタンの各ボタンの設定状態/操作可能状態の遷移を表した図。 「Material Window View Mode:」の設定状態/操作可能状態の遷移を表した図。

符号の説明

１…ビジュアルコミュニケーションサーバ，３…電話交換機，５…ＬＡＮ，７…電話回線，Ｔｅｌ−１〜ｔｅｌ−３…電話端末，ＶＣ＿ＰＣ−１〜ＶＣ＿ＰＣ−３…ＶＣクライアント，ＭＣ…モード切替モジュール，ＭＩＴ…多方向画像通信モジュール，ＳＩＴ…片方向画像通信モジュール，ＷＣ…ウィンドウ制御部，Ｍ…監視部，Ｎ…通知部，ＥＤ…エンコード／デコード部，ＳＰ…ソフトフォン，ＳＩＰ＿Ｌｉｂ…ＳＩＰライブラリ，ＬＡＮ＿Ｉ／Ｆ…ＬＡＮインタフェース，Ｃ…カメラ，Ｖｉｎ…音声入力，Ｖｏｕｔ…音声出力，Ｄ…表示装置

Claims (20)

1. ネットワ−クを介して第１の端末と第２の端末との間で画像データの伝送を行う画像通信方法であって、
   前記第１の端末から前記第２の端末への第１の画像データの伝送と前記第２の端末から前記第１の端末への第２の画像データの伝送とを含む双方向画像通信を実行するステップと、
   前記第１の端末および前記第２の端末の一方から他方に対して、前記第１の画像データおよび前記第２の画像データの一方の伝送を停止することを通知するステップと、
   前記通知に応じて前記第１の画像データと前記第２の画像データの伝送の一方を停止して、前記第１の端末と前記第２の端末との間で、片方向画像通信を実行するステップとを含むことを特徴とする画像通信方法。
2. 前記第１の画像データは前記第２の端末の表示装置の第１ウインドウ内に表示され、前記第２の画像データは前記第１の端末の表示装置の第２ウインドウ内に表示され、
   前記第１の画像データの伝送が停止される場合には、前記第１ウィンドウを閉じ、前記第２の画像データの伝送が停止される場合には前記第２ウィンドウを閉じるステップを更に含むことを特徴とする請求項１記載の画像通信方法。
3. 前記通知は、前記第１の端末の処理の負荷に応じて実行されることを特徴とする請求項１記載の画像通信方法。
4. 前記通知は、前記ネットワークの負荷に応じて、実行されることを特徴とする請求項１記載の画像通信方法。
5. 前記第１の画像データ及び第２の画像データは、第１の画像設定に基づいて用意され、
   前記第１の端末および前記第２の端末の一方から他方に対して、第２の画像設定を通知するステップと、
   第１の端末から第２の端末への前記第２の画像設定に基づく第３の画像データの伝送と、第２の端末から第１の端末への前記第２の画像設定に基づく第４の画像データの伝送とを含む双方向画像通信が実行されるステップとを更に含むことを特徴とする請求項１記載の画像通信方法。
6. 第２の画像設定の通知は、
   前記第１の端末および前記第２の端末の一方が、処理の負荷を検出するステップと、
   前記負荷の検出を行った前記第１の端末および前記第２の端末の一方で前記負荷に応じて前記第２の画像設定を決定するステップと
   を更に含むことを特徴とする請求項５記載の画像通信方法。
7. 第２の画像設定の通知は、
   前記第１の端末および前記第２の端末の一方が、ネットワークの負荷を検出するステップと、
   前記負荷に応じて前記第２の画像設定を決定するステップと
   を含むことを特徴とする請求項５記載の画像通信方法。
8. 前記第１の端末および前記第２の端末の一方で、前記第１の端末および前記第２の端末の他方から送られた画像データを正常に受信できているかを検出するステップと、
   正常に受信できていない場合、前記第１の端末および前記第２の端末の一方の表示装置に、画像データを正常に受信できていないことを表す情報を表示することを特徴とする請求項１記載の画像通信方法。
9. 前記情報は、最終的に正常に受信された画像データに対応する静止画像であることを特徴とする請求項８に記載の画像通信方法。
10. ネットワークを介して画像通信を実行する通信装置において、
    相手端末から送信される第１の画像データの受信と前記相手端末への第２の画像データの送信とを実行する双方向画像通信手段と、
    前記相手端末から、前記第１の画像データおよび前記第２の画像データの一方の伝送を停止することが通知された場合、前記第１の画像データの受信と前記第２の画像データの送信の一方を停止して、前記相手端末との片方向画像通信を実行する片方向画像通信手段とを具備することを特徴とする通信装置。
11. 表示装置と、
    前記第１の画像データを前記表示装置の第１ウインドウ内に表示し、前記第１の画像データの伝送を停止することが通知された場合、前記第１ウィンドウを閉じるウィンドウ制御部とを更に具備することを特徴とする請求項１０記載の通信装置。
12. 前記第１の画像データが正常に受信できているかを監視する監視部を更に具備し、
    正常に受信できていない場合、前記ウィンドウ制御部は第１ウインドウ内に前記第１の画像データを正常に受信できていないことを表す情報を表示することを特徴とする請求項１１記載の通信装置。
13. 前記ウィンドウ制御部は、前記情報として最終的に正常に受信された画像データに対応する静止画像を前記第１ウインドウ内に表示することを特徴とする請求項１２に記載の画像通信装置。
14. 第１の画像設定に基づいて前記第２の画像データを生成する画像データ生成部を更に具備し、
    前記画像データ生成部は、前記相手端末から第２の画像設定が通知された場合、第２の画像設定に基づく第２の画像データを生成し、
    前記双方向画像通信手段は、前記相手端末への第２の画像設定に基づいて生成された第２の画像データの送信を実行することを特徴とする請求項１１記載の通信装置。
15. ネットワークを介して画像通信を実行する通信装置において、
    相手端末から送信される第１の画像データの受信と前記相手端末への第２の画像データの送信とを実行する双方向画像通信手段と、
    前記相手端末に、前記第１の画像データおよび前記第２の画像データの一方の伝送を停止することを通知する通知手段と、
    前記通知手段によって前記第１の画像データおよび前記第２の画像データの一方の伝送を停止することを前記相手端末に通知した場合、前記第１の画像データの受信と前記第２の画像データの送信の一方を停止して、前記相手端末との片方向画像通信を実行する片方向画像通信手段とを具備することを特徴とする通信装置。
16. 前記通信装置は、表示装置と、
    前記第２の画像データを生成する処理、および／または前記第１の画像データを前記表示装置に表示するための処理をおこなう画像データ処理部とを更に具備し、
    前記通知部は、前記画像データ処理部の負荷に応じて、前記第１の画像データおよび前記第２の画像データの一方の伝送を停止することを通知することを特徴とする請求項１５に記載の通信装置。
17. 前記通知部は、前記ネットワークの負荷に応じて、前記第１の画像データおよび前記第２の画像データの一方の伝送を停止することを通知することを特徴とする請求項１５記載の通信装置。
18. 第１の画像設定に基づいて前記第２の画像データを生成する画像データ生成部と、
    第２の画像設定を生成し、生成された第２の画像設定を前記相手端末に通知する設定通知部とを更に具備し、
    前記画像データ生成部は、前記通知部が前記相手端末に第２の画像設定を通知した場合、第２の画像設定に基づく第２の画像データを生成し、
    前記双方向画像通信手段は、前記相手端末への第２の画像設定に基づいて生成された第２の画像データの送信を実行することを特徴とする請求項１５記載の通信装置。
19. 前記第１の画像データを前記表示装置に表示するための処理をおこなう画像データ処理部を更に具備し、
    前記設定通知部は、前記画像データ生成部の負荷、および前記画像データ処理部の負荷の少なくとも一方に応じて、前記第２の画像設定を生成することを特徴とする請求項１８に記載の通信装置。
20. 前記設定通知部は、前記ネットワークの負荷に応じて、前記第２の画像設定を生成することを特徴とする請求項１９記載の通信装置。

Images