情報共有システム
【課題】共有情報の配信を行うサーバに接続される情報端末の実質的な数を減らすことにより、情報伝送の遅延と通信障害の発生の減少を図り、サーバの負荷の軽減を図る。
【解決手段】各情報端末が、利用者が使用状態であることを示す状態情報に基づいて、情報端末が使用されていない可能性のあるアイドル状態であるか否かを判定するアイドル状態判定部と、アイドル状態であると判定された場合、サーバに同一拠点内の代表端末の検出を要求する検出要求を送信し、かつサーバから代表端末の情報を受信する代表端末検出要求部と、アイドル状態と判定された場合にサーバ又は、代表端末から配信されるストリーミング情報を受信するストリーミング受信部とを備え、サーバが、第１の情報端末から代表端末の検出要求を受信した場合、第１の情報端末と同一の拠点に属する代表端末を検出し、その代表端末の情報を第１の情報端末に送信する代表端末検出部を備える。
【解決手段】各情報端末が、利用者が使用状態であることを示す状態情報に基づいて、情報端末が使用されていない可能性のあるアイドル状態であるか否かを判定するアイドル状態判定部と、アイドル状態であると判定された場合、サーバに同一拠点内の代表端末の検出を要求する検出要求を送信し、かつサーバから代表端末の情報を受信する代表端末検出要求部と、アイドル状態と判定された場合にサーバ又は、代表端末から配信されるストリーミング情報を受信するストリーミング受信部とを備え、サーバが、第１の情報端末から代表端末の検出要求を受信した場合、第１の情報端末と同一の拠点に属する代表端末を検出し、その代表端末の情報を第１の情報端末に送信する代表端末検出部を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、情報共有システムに関し、特に、ネットワークを介して接続された複数の情報端末間で、共通の映像や音声等の情報を伝送する情報共有システムに関する。
【背景技術】
【０００２】
従来からネットワークを介して、複数の情報端末間で映像や音声等の情報の伝送を行う通信システムや、専用のサーバ等を介して遠隔地にある複数の情報端末間で音声会議やビデオ会議を行う通信システムが利用されている。
たとえば、従来のビデオ会議システムでは、多地点接続装置（ＭＣＵ：Ｍｕｌｔｉ−ｐｏｉｎｔ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）および、ＭＣＵ機能を有したサーバに、各地点ごとに設置された情報端末や参加者ごとの情報端末が、インターネット，ＬＡＮ，あるいは専用回線等のネットワークを介して接続され、情報端末毎に入力された映像，音声，文書などの情報がＭＣＵに集積され、ＭＣＵにおいて各情報のデコード（復号化），ミキシング（合成），エンコード（符号化）等の一連の処理が行われ、各情報端末に共通の情報として配信される。
一般的に、各情報端末を利用している会議への参加者は、共通の映像を見て、共通の音声を聞きながら会議を行うものとする。
【０００３】
また、利用者が自ら遠隔会議装置（情報端末）の主電源を切断する操作をすることなく、動画像符号化機構の動き検出機構から動きベクトル値を取得して利用者の退席を判定し、自動的に安全に回線及び電源を切断することのできる自動回線切断機能付遠隔会議システムが提案されている（特許文献１参照）。
【０００４】
また、ユーザの在席または退席に係る情報（プレゼンス情報）を他のユーザの通信端末で表示するプレゼンスサービスを有する通信システムにおいて、ユーザが自己のプレゼンス情報の設定や変更を忘れることがあることを考慮して、ユーザの通信端末の周囲で撮影された撮影画像又はその通信端末の周囲で取得された音声を、プレゼンス情報として相手ユーザの通信端末へ送信し、相手ユーザのプレゼンス状態を正確に把握するようにしたプレゼンス情報処理端末（特許文献２参照）や、プレゼンス情報のユーザによる設定操作だけでなく、マイクにより集音される音に基づいてユーザの在席／退席を判定して、プレゼンス情報を更新する通信端末が、提案されている（特許文献３参照）。
【０００５】
また、サーバ装置とデータの送受信を行う通信端末装置において、その通信端末装置及び利用者の状態情報を示すプレゼンス情報が特定の条件に合致した際に、端末装置の動作の変更及び通信データの加工を行う機能を備え、プレゼンス情報を基にして端末装置側で動作変更やデータの加工処理を行うことにより、サーバ側の負荷を軽減することのできる通信システムが提案されている（特許文献４参照）。
また、この特許文献４には、サーバ装置が、通信端末装置から送信されたプレゼンス情報を使用して、設定された特定条件（たとえば、特定地域内にある端末）に適合する端末群情報を収集して、端末装置の新規グループを自動的に作成する通信システムが開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平８−３３６１２２号公報
【特許文献２】特開２００４−２１４９３４号公報
【特許文献３】特開２００７−１２９４１１号公報
【特許文献４】国際公開ＷＯ２００６／０５４７７８
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、従来のＭＣＵを利用した多地点会議システムでは、ＭＣＵに同時に接続される情報端末の数が増加すればするほど、ＭＣＵと各情報端末間の通信回線で送受信されるトラフィックが増加するので、情報伝送の遅延や、ノイズの発生による通信エラー等の通信障害が起こりやすくなり、円滑な会議の進行ができなくなる場合もある。
さらに、ＭＣＵでは、接続される情報端末が増加すればするほど、エンコード（符号化）、デコード（複号化）等の処理をすべき情報量が増加するので、ＭＣＵにかかる負荷が大きくなり、それにより各情報端末への情報伝送に遅延をもたらすことになる。
【０００８】
また、ＭＣＵにおいて、情報端末から送信されてくる在席または退席を示す情報を基にして、各端末の動作管理や、通信回線の接続や切断処理を一元的に一括管理する場合は、利用者は一時的に中座しただけなのに、ＭＣＵによって通信回線を切断されてしまう場合や、その利用者の情報端末への電源供給が停止されてしまう場合もある。
このような場合、利用者は、会議に再び参加するためには、回線接続処理や電源投入等の一連の操作をやり直す必要があるので、利用者にとって不便であり、操作負担が大きかった。
【０００９】
また、特許文献１，２および３に記載されたシステム等においても、端末の動作制御が自動的に行われ、あるいはプレゼンス状態が正確に把握できたとしても、利用者にとって意図しない通信回線や電源の切断が行われる場合もあり、利用者が自ら再起動操作等を行う必要があった。
また、いずれの特許文献に開示された技術も、ネットワークに接続される情報端末の数が増加した場合において、伝送遅延や通信障害等の問題を軽減させることを目的とするものではなく、そのような軽減措置については考慮されていない。
【００１０】
そこで、この発明は、以上のような事情を考慮してなされたものであり、サーバに接続されている複数の情報端末のうち、実質的にサーバと情報通信を行う情報端末の数を抑制して、情報伝送の遅延および、通信エラー等の通信障害の発生の減少、サーバが処理する情報量の低減によるサーバの負荷の軽減を図り、さらに情報端末の動作状態の段階的な制御を行うことによる情報端末側の利用者の操作負担の軽減を図ることのできる情報共有システムを提供することを課題とする。ここで、サーバとは、ビデオ会議の制御機能のうち、少なくともＭＣＵ機能を有する装置を指すこととする。
【課題を解決するための手段】
【００１１】
この発明は、サーバと、複数の情報端末とがネットワークを介して接続され、前記情報端末において入力された情報をサーバに送信し、前記サーバが、各情報端末から送信された情報を用いて共有情報を生成し、前記共有情報を前記情報端末へ配信する情報共有システムであって、前記情報端末が、その情報端末を利用者が使用状態であることを示す状態情報を生成する情報入力部と、前記情報入力部によって生成された状態情報に基づいて、情報端末が使用されていない可能性のあるアイドル状態であることを判定するアイドル状態判定部と、アイドル状態であることが判定された場合に、情報端末の現在の動作状態に対応して、段階的に動作状態を変更する端末モード切替部と、情報端末の現在の動作状態を、サーバへ送信する端末状態通知部と、アイドル状態であると判定された場合に、サーバに、同一拠点内の代表端末の検出を要求する検出要求を送信し、かつサーバから代表端末の情報を受信する代表端末検出要求部と、アイドル状態であると判定された場合に、サーバあるいは前記代表端末から配信されるストリーミング情報を受信するストリーミング受信部とを備え、前記サーバが、前記情報端末から送信されてきた動作状態に基づいてその情報端末との通信方法を切り替える通信方法切替部と、第１の情報端末から代表端末の検出要求を受信した場合に、前記第１の情報端末と同一の拠点に属する情報端末の中から代表端末を検出し、その代表端末の情報を前記第１の情報端末に送信する代表端末検出部と、情報端末にストリーミング情報を送信するストリーミング配信部とを備え、前記情報端末の動作状態に従って、各情報端末ごとにサーバと各情報端末との間の通信状態を変更させることを特徴とする情報共有システムを提供するものである。
【００１２】
これによれば、アイドル状態であると判定された情報端末は、サーバあるいは同一拠点内の代表端末から配信されるストリーミング情報を受信する一方向的な通信状態となるので、サーバと情報端末間の通信状態を情報伝送量の少ない状態とすることができ、さらに情報伝送量が減少することにより伝送遅延の減少と通信障害の発生の減少を図り、サーバの負荷を軽減することができる。
また、情報端末の動作状態を段階的に変更しているので、たとえば、変更後の動作状態から変更前の動作状態への復帰のための操作を比較的容易にすることができ、利用者の操作負担を軽減でき、その復帰を短時間で行うことができる。
【００１３】
また、前記代表端末検出部が、前記代表端末を検出できた場合に、前記第１の情報端末のストリーミング受信部は、検出された代表端末から、ストリーミング情報を受信することを特徴とする。
これによれば、アイドル状態である第１の情報端末は、代表端末からストリーミング情報を受信するので、サーバから第１の情報端末へ直接映像等の共有情報が送信されることがなく、より伝送遅延の減少と通信障害の発生を減少させ、サーバの負荷もより軽減させることができる。
【００１４】
また、前記代表端末検出部が、前記第１の情報端末と同一拠点に属する代表端末を検出できなかった場合、代表端末の未検出通知を、前記第１の情報端末に送信し、前記第１の情報端末が、前記未検出通知を受信した場合、前記第１の情報端末の端末状態通知部が、自己が代表端末となることをサーバに通知し、その後、ストリーミング受信部は、サーバから、ストリーミング情報を受信することを特徴とする。
これによれば、アイドル状態である第１の情報端末は、サーバからストリーミング情報を一方向的に受信するので、サーバの負荷の軽減と、伝送遅延の減少および通信障害の減少を図ることができる。
【００１５】
この発明において、前記同一拠点内の代表端末は、前記第１の情報端末と同一グループに属する情報端末として予め設定された情報端末の中から、選択されることを特徴とする。
また、前記同一グループに属する情報端末は、同一の拠点ＩＤを持つ情報端末、同一ルータに接続されそのルータの配下のネットワークに属する情報端末、および同一ドメイン内の情報端末のいずれかとしてもよい。
さらに、前記代表端末は、前記第１の情報端末と同一の拠点ＩＤを持ち、アイドル状態ではない情報端末とすることができる。
【００１６】
また、前記情報端末の動作状態は、サーバと双方向通信を行う第１モード、サーバから音声および映像を含む情報を受信して片方向通信を行う第２モード、情報端末の主機能を停止してサーバとの通信を中止した状態の第３モード、情報端末の電源を切断した状態の第４モードを含み、前記アイドル状態判定処理により、アイドル状態であることが検出されるごとに、情報端末の動作状態を前記第１モードから第４モードの順に段階的に変更させることを特徴とする。
【００１７】
ここで、第１モードにおいて、サーバと情報端末間で、映像および音声の双方向通信が行われるのに対し、第２モードでは、サーバから情報端末の方向へ、映像および音声の片方向送信が行われるので、第１モードよりも伝送される情報量は少ない。第３および第４モードでは、サーバと情報端末間の通信が中止されているので、サーバとその情報端末間で伝送される情報はなくなる。したがって、アイドル状態の検出により、情報端末の動作状態を第１モードから第２モード、第３モード、第４モードのように段階的に変更していけば、情報端末とサーバ間の情報伝送量が減少する方向に動作状態を変更できるので、サーバに接続される実質的な情報端末数を減少させることができる。これにより、サーバおよび情報端末における映像および音声のエンコード、デコードといった処理負荷の軽減だけでなく、通信伝送量の削減に伴ない、伝送遅延や、通信障害の発生を減少させることができる。
また、アイドル状態を検出するごとに、第１モードから第４モードへ順に、情報端末の動作状態を段階的に変更するので、変更前の動作状態への復帰が、アイドル状態を検出したときにいきなり情報端末の電源を切断してしまう場合よりも、より短時間に、より容易な操作で可能となり、利用者の負担を軽減できる。
【００１８】
また、前記情報入力部は、利用者の操作による入力信号を入力する入力部と、カメラにより撮影された映像を入力する映像入力部と、マイクから音声を入力する音声入力部とを備え、前記入力信号、入力映像および入力音声を用いて、前記状態情報を生成することを特徴とする。
また、前記アイドル状態判定部は、所定の設定時間中に継続して、前記入力信号の入力がないこと、前記入力音声の入力がないこと、および前記入力映像に所定の変化がないことのいずれもが検出された場合、その情報端末が使用されていない可能性があるアイドル状態であると判定することを特徴とする。
【００１９】
ここで、利用者が情報端末を使用していることを示す状態情報として、利用者の操作の有無と利用者の音声の入力の有無と、利用者を撮影した映像の変化の有無を利用する。
たとえば、利用者がマウスを動かした場合、マウスを動かしたことを示す入力信号により、入力信号があったことを示す状態情報が生成される。
そして、利用者の操作入力、利用者の音声入力および映像変化という３つの情報を総合的に利用して、利用者がその情報端末を使用していない可能性があると判定するので、利用者の不在の判断を、より確実にすることができる。
【００２０】
さらに、利用者の音声特徴データと、利用者の顔の特徴を示す顔画像特徴データを含む認識データベースを記憶した記憶部と、前記入力音声と音声特徴データとを用いた音声認識と、前記入力映像と顔画像特徴データとを用いた画像認識とを利用して、利用者を特定する人物認識を行う人物認識部とをさらに備え、前記アイドル状態判定部は、所定の設定時間中に継続して、前記人物認識部により人物認識が失敗した場合に、その情報端末が使用されていない可能性があるアイドル状態であると判定することを特徴とする。
これにより、利用者を特定したアイドル状態の判定を行うので、利用者の不在の判断をより確実に行うことができる。
【００２１】
さらに、この発明は、サーバと、複数の情報端末とがネットワークを介して接続され、前記情報端末において入力された情報をサーバに送信し、前記サーバが、各情報端末から送信された情報を用いて共有情報を生成し、前記共有情報を前記情報端末へ配信する情報共有システムの情報共有方法であって、前記情報端末が、その情報端末を利用者が使用状態であることを示す状態情報を生成する情報入力ステップと、前記状態情報に基づいて、情報端末が使用されていない可能性のあるアイドル状態であるか否かを判定するアイドル状態判定ステップと、アイドル状態であると判定された場合に、情報端末の現在の動作状態に対応して、段階的に所定の動作状態に変更する端末モード切替ステップと、情報端末の現在の動作状態を、サーバへ送信する端末状態通知ステップと、アイドル状態であると判定された第１の情報端末が、サーバに、同一拠点内の代表端末の検出を要求する検出要求送信ステップと、前記サーバが、前記代表端末の検出要求を受信した場合に、検出要求を送信してきた前記第１の情報端末と同一の拠点に属する情報端末の中から代表端末を検出するステップと、検出された代表端末の情報を前記第１の情報端末に送信するステップと、前記第１の情報端末が、受信した代表端末の情報を用いて、その代表端末に、ストリーミング配信を要求する配信要求送信ステップと、前記代表端末が、受信した配信要求に基づいて、前記第１の情報端末に、ストリーミング情報を送信するステップとを備えたことを特徴とする情報共有方法を提供するものである。
また、コンピュータに、前記したような情報共有方法の各ステップを実行させるための情報共有システムのプログラムを提供するものである。
【発明の効果】
【００２２】
この発明によれば、アイドル状態であると判定された情報端末は、サーバあるいは同一拠点内の代表端末から配信されるストリーミング情報を受信する一方向的な通信状態となるので、サーバと情報端末間の通信状態を情報伝送量の少ない通信状態とすることができ、伝送遅延を減少させ、通信障害の発生を減少させることができ、さらにサーバが共有情報を生成するときの負荷を減少させることができる。
また、情報端末の動作状態を段階的に変更させるので、変更後の動作状態から変更前の動作状態へ復帰するための利用者の操作負担が軽減でき、その復帰にかかる時間を短縮することができる。
【図面の簡単な説明】
【００２３】
【図１】本発明の情報共有システムの一実施例の概略構成図である。
【図２】情報端末の第１実施例の構成ブロック図である。
【図３】サーバの第１実施例の構成ブロック図である。
【図４】サーバ端末間通信状態（アクティブモード）の一実施例の説明図である。
【図５】サーバ端末間通信状態（スリープモード）の一実施例の説明図である。
【図６】サーバ端末間通信状態（ログオフモード）の一実施例の説明図である。
【図７】サーバ端末間通信状態（シャットダウンモード）の一実施例の説明図である。
【図８】サーバと端末間の通信シーケンスの一実施例の説明図である。
【図９】第１実施例の端末におけるモード移行処理のフローチャートである。
【図１０】第１実施例の端末におけるアイドル状態判定処理のフローチャートである。
【図１１】第１実施例のサーバにおける端末状態判断制御処理のフローチャートである。
【図１２】記憶部に格納されるデータベースの一実施例の説明図である。
【図１３】情報端末の第２実施例の構成ブロック図である。
【図１４】サーバの第２実施例の構成ブロック図である。
【図１５】第２実施例のサーバにおけるモード移行制御処理のフローチャートである。
【図１６】第２実施例のサーバにおけるアイドル状態判定処理のフローチャートである。
【図１７】第２実施例の端末における端末状態制御処理のフローチャートである。
【図１８】情報端末の第３実施例の構成ブロック図である。
【図１９】サーバの第３実施例の構成ブロック図である。
【図２０】第３実施例で用いられる端末データベースの一実施例の説明図である。
【図２１】第３実施例の端末におけるグループ化処理のフローチャートである。
【図２２】第３実施例の代表端末のストリーミング配信処理のフローチャートである。
【図２３】第３実施例の端末におけるアイドル状態判定処理のフローチャートである。
【図２４】第３実施例のサーバにおける端末状態検出制御処理のフローチャートである。
【図２５】第３実施例のサーバと端末間の通信シーケンスの説明図である。
【図２６】第３実施例のサーバ端末間通信状態（アクティブモード）の説明図である。
【図２７】第３実施例のサーバ端末間通信状態（スリープモード）の説明図である。
【図２８】第３実施例のサーバ端末間通信状態（スリープモード）の説明図である。
【図２９】第３実施例のサーバ端末間通信状態（スリープモード）の説明図である。
【図３０】第３実施例のサーバ端末間通信状態（スリープモード）の説明図である。
【発明を実施するための形態】
【００２４】
以下、図面を使用して本発明の実施の形態を説明する。なお、以下の実施例の記載によって、この発明が限定されるものではない。
＜本発明の情報共有システムの構成＞
図１に、本発明の情報共有システムの一実施例の概略構成図を示す。
ここでは、映像，音声，文書などの情報を共有して、複数の情報端末間で画像音声等による会議を行う情報共有システム（以下、会議システムとも呼ぶ）について、説明する。
【００２５】
図１において、情報共有システムは、主として、１台のサーバ１と、複数台の情報端末（以下、会議端末、または単に端末とも呼ぶ）２とから構成される。
サーバ１と、各情報端末２とは、ネットワークを介して接続される。
サーバ１は、従来の会議システムでも利用されている会議制御機能のうち、少なくとも多地点接続装置（ＭＣＵ）と同等の機能を有する装置であり、主として、接続された端末の状態監視、接続制御、各種情報の通信制御、映像や音声の符号化、映像や音声の復号化処理、ユーザ認証、機器認証、通信暗号化等を行うものである。
また、端末２は、会議に参加する利用者が在席する部屋（オフィスや会議室など）に設置される装置であり、主として、映像および音声による利用者自身の認識処理、端末の動作状態や入力操作の確認処理、入力される各種情報の加工変換や通信制御処理を行うものである。
【００２６】
情報端末２では、会議に必要な情報が入力され、入力された情報はサーバに送信される。入力される情報としては、後述するが、主として、キーボードやマウス等の入力信号、マイクからの入力音声、カメラからの入力映像である。これらの入力された情報は、符号化（エンコード）処理をした後、サーバに送信してもよい。また、通信経路における機密性、秘匿性を考慮し、暗号化処理を行ってもよい。
サーバ１は、上記のようなサーバに送信された情報を用いて共有情報を生成し、この共有情報を、各情報端末へ配信する。
【００２７】
サーバ１と端末２（ＴＥ１〜ＴＥｎ）との接続は、たとえば有線の通信ケーブルによって直接接続してもよく、また、いわゆる無線ＬＡＮ等の無線通信方式によって接続してもよい。
また、各種のネットワーク（ＬＡＮ（Ｎ１），インターネット（Ｎ２），専用通信網（Ｎ３）など）を介して、サーバ１と端末２とを接続してもよい。
ある端末（ＴＥ１）を利用する利用者が会議に参加する場合、その端末ＴＥ１とサーバ１との間の通信回線を接続し、リンクを確立させた後、端末ＴＥ１に付属したカメラやマイクからその利用者の画像や音声あるいは会議に必要な文書や図面データなどを、サーバ１に送信する。
このとき、通信路における伝送量軽減や、リアルタイム（低遅延）通信を行うために、所定の規格のコーデック（例えば、映像であればＭＰＥＧ４、Ｈ．２６３、Ｈ．２６４、音声であればＧ．７１１、Ｇ．７２２、Ｇ．７２９等）を利用して、送信されるデータ量を圧縮符号化する処理（エンコード）が行われる。
【００２８】
サーバ１では、端末ＴＥ１から送られてきた映像，音声等の情報と、その他の端末２（ＴＥ２，…ＴＥｎ）から送られてきた同様の情報を復号化（デコード）した後、合成（ミキシング）する処理を行う。この合成処理を行った情報（合成情報）が、共有情報となる。共有情報は、現在接続が確立されている複数の端末２に向かって、配信される。
サーバ１では、受信した複数の映像のミキシングを行う前に、各端末２から送られてきた映像の復号化処理（デコード）を行い、さらに画像サイズの調整（リサイズ）を行い、その後１つの共有情報として配信するために複数の映像を合成する処理が行われる。
たとえば、４人の利用者が会議に参加していたとすると、４台の端末２から送信されてきた各利用者の人物画像の映像データをそれぞれデコードし、１画面に分割表示できるようにリサイズし、４つの映像を合成（ミキシング）する。
さらに、ミキシングした後の合成映像は、サーバで符号化処理（エンコード）が行われた後、共有情報としてサーバ１から端末２へ送信される。
【００２９】
このようなミキシングされた共有情報が送信されてきた各端末２では、受信情報の復号化処理（デコード）が行われ、その端末に付属した表示装置やスピーカから、画像や音声が出力される。
たとえば、現在接続が確立されている端末２が４台であれば、ミキシングされた後の共有情報は、サーバ１から時分割多重化処理等を用いてリアルタイムで、４つの端末にそれぞれ配信される。
【００３０】
しかし、接続が確立されている端末数がさらに増加した場合、たとえばその端末数が２０台の場合、円滑に会議を進行させるためには、２０台のそれぞれの端末２で、同じようにリアルタイムで、共有情報の画像や文書を見て、共有情報の音声を開く必要があるので、サーバ１はより高速に情報の配信処理を行う必要がある。
【００３１】
一般に、通信回線として電話回線を用いたＡＤＳＬやＩＳＤＮによる通信、光ファイバーを用いたＦＴＴＨによる通信、無線通信、その他のより高速の専用回線を用いた通信が利用できるが、いずれも回線そのものの通信速度や一定時間に伝送できる通信量に限界があるので、円滑な会議の進行にほとんど問題がなく、情報伝送の遅延が問題とならずに、リアルタイムで情報配信ができる最大端末数も、利用する通信回線の太さ（通信帯域）や、通信に用いられる映像や音声のデータ量および、端末そのもののＣＰＵ性能等によって上限値が決まってくる。
【００３２】
この発明は、情報共有システムの会議に参加可能な端末が非常に多数存在する場合でも、サーバ１に対して同時に接続が確立され、サーバから直接的に共有情報の配信が行われる端末の実質的な数をできるだけ減少させて、リアルタイム性を保持した情報の配信を行い、円滑な会議の進行をさまたげることのないようにする。
【００３３】
この発明では、上記のようなサーバに接続される実質的な端末数の減少は、次のような処理によって実現させることを特徴とする。
（１）端末ごとの段階的動作制御
実質的に端末が使用されていない可能性のある動作状態（以下、アイドル状態と呼ぶ）であると判定された場合、その端末の動作状態のモードを、段階的に変更し、その端末とサーバとの通信状態を所定の順序で切り替え、最終的に端末の電源を切断する。
ここでは、端末の動作状態に従って、サーバと各端末との通信状態が動的に変更される。
【００３４】
（２）端末のグループ化によるサーバから見た接続端末数の減少化
同一ルータに接続されたネットワーク上に複数の端末が存在する場合など、複数の端末が属するグループを設定し、そのグループの中の１台の端末を代表端末に設定し、サーバと直接通信する端末を代表端末のみに制限することにより、サーバと直接共有情報の通信を行う端末の数を減少させる。
代表端末以外のグループ内に属する端末は、共有情報を受信した代表端末から、その受信情報を配信してもらうようにする。
【００３５】
上記（１）の処理において、端末がアイドル状態であるか否かの判定は、たとえば、画像による人物認識や音声認識による利用者自身に関する情報の取得や、端末の動作状態（電源のＯＮ／ＯＦＦ）や入力操作の有無等の検出により行うことができる。
また、アイドル状態の判定処理は、サーバ側又は端末側のどちらで行ってもよい。
【００３６】
さらに、（１）の処理において、段階的に変更される端末の動作状態のモード（動作モードとも呼ぶ）とは、たとえば、順に、アクティブモード，スリープモード，ログオフモード，およびシャットダウンモード（電源切断状態）が考えられる。ただし、この４つのモードは例示であり、これに限定されるものではない。
前記した第１モードがアクティブモードに相当し、第２モードがスリープモードに相当し、第３モードがログオフモードに相当し、第４モードがシャットダウンモードに相当する。
たとえば、第２モード（スリープモード）の動作状態のときに、アイドル状態であると判定された場合、第３モード（ログオフモード）に切り替え、第３モードのときにアイドル状態であると判定された場合、第４モード（シャットダウンモード）に切り替える。
【００３７】
ここで、アクティブモードとは、その端末に搭載されたすべての機能が実行可能な状態を意味し、たとえば、サーバと映像および音声の双方向通信を行う状態を意味する。
スリープモードとは、サーバからの映像および音声の受信のみ（片方向通信）を行っている状態を意味し、その端末で実行可能な機能を実行するためには、利用者がマウスやキーボード等の端末操作等を行ったり、利用者が端末の前にいることでカメラ入力画像を変化させたり、利用者が発言することでマイク入力音声を発生させることで、アイドルモードからアクティブモードに移行させる必要がある。
【００３８】
また、ログオフモードとは、端末の画面上に利用者へのログイン操作を促す画面が表示されるような状態を意味し、たとえば、利用者がログイン認証をしなければ、その端末の機能を実行させることができないような状態を意味する。
また、ログオフモードでは、情報端末の主機能が停止した状態で、サーバとの通信を中止した状態である。
シャットダウンモードとは、端末の電源が切断されている状態を意味し、端末を動作させるためにたとえば、利用者が電源ボタンを押し、端末にインストールされているＯＳ等のソフトウェアを起動させなければならない状態を意味する。
以下の実施例では、アイドル状態が検出されるごとに、情報端末の動作状態を、第１モード（アクティブモード）から、第２モード（スリープモード）、第３モード（ログオフモード）、第４モード（シャットダウンモード）の順に、段階的に変更させるようにする。
【００３９】
ここで、上記４つのモードは、利用者が所定の機能を実行させるために、行わなければならない操作手順と、実行できるようになるまでの時間が異なる。
利用者の操作に関して、アクティブモードが最も容易であるのに対し、シャットダウンモードが最も多くの操作手順を必要とし、利用者が所望の機能を実行させるようになるまでに最も時間がかかる。
このように、４つのモードを設けたのは、所定の機能を実行させるアクティブモードに端末を復帰させるのに必要な利用者の操作負担をできるだけ少なくするように考慮したためである。
【００４０】
たとえば、従来のように利用者が不在であることを確認したときに、一律に端末の電源を切断するようにした場合において、その不在は一時的なものであって利用者は会議に参加する意思がまだある場合でも、利用者は端末の電源投入から始めて一連の操作をすべて実行しなければならず、操作負担が大きく、また、なかなか会議に復帰することができないことになる。
したがって、利用者の不在が確認された場合は、サーバとの間の情報通信は一旦中断し、伝送遅延や通信障害の発生が少なくなるようにするが、その不在が会議への不参加（退席）によるものと確実に認識できない場合は、たとえば端末を単にスリープモードにするようにすれば、比較的容易な操作でアクティブモードに復帰できるので、利用者の操作負担は軽く、短時間で会議へ復帰できるようになる。
以下に、上記（１）および（２）の処理を実現する構成および具体的な処理内容の実施例について説明する。
【００４１】
＜情報端末の構成＞
図２に、情報端末の第１実施例の構成ブロック図を示す。
情報端末２（ＴＥ）は、主として、入力部１１，映像入力部２１，表示部３１，音声入力部４１，音声出力部４５，通信部５１，認証部５５，記憶部６１，信号処理部７１，および制御部８０から構成される。
【００４２】
ここで、上記した情報入力部は、入力部１１と、映像入力部２１と、音声入力部４１とを含むものに相当し、情報端末を利用者が使用状態であることを示す状態情報を生成する部分である。
入力部１１は、キーボード１２，マウス１３，タブレット１４などのポインティングデバイスに加え、人検知センサ１５を備え、これらの入力を受信し、制御部８０へ送信するための信号に変換する入力処理部１６とを備える。
人検知センサ１５は、たとえば、熱感知センサ，赤外線センサ，超音波センサなどを用いることができる。人検知センサの代わりに、後述するカメラ２２やマイク４２の入力信号を元に端末の前に人がいるかどうかを検知するようにしても良い。
入力部１１からは、主として利用者の操作による入力信号が入力され、この入力信号が、状態情報の生成に用いられる。たとえば、この入力信号が入力されている場合、情報端末が使用状態であることを示す状態情報が生成される。
【００４３】
映像入力部２１は、端末の近傍の映像や、端末の前にいる会議に参加している者（利用者）の映像を入力する部分であり、カメラ２２と、カメラで撮影された映像をデジタル信号に変換する映像処理部２３とを備える。入力された映像６６は、記憶部６１に一時記憶される。この入力映像６６も、上記した状態情報の生成に用いられる。
【００４４】
表示部３１は、利用者の自画像を表示したり、会議に参加している他者の人物画像等を表示する部分であり、ＬＣＤ，ＣＲＴなどのディスプレイ３２と、ディスプレイ３２へ表示させる表示信号を生成する表示処理部３３とを備える。
【００４５】
音声入力部４１は、端末ＴＥの近傍の音声を入力する部分であり、マイク４２と、マイクから入力された音声をデジタル信号に変換する入力音声処理部４３とを備える。入力された音声６７は、記憶部６１に一時記憶される。
この入力音声６７も、上記した状態情報の生成に用いられる。
【００４６】
音声出力部４５は、スピーカ４６，出力音声処理部４７とを備え、たとえば、サーバから送られてきた音声を、スピーカから出力する部分である。
【００４７】
通信部５１は、サーバあるいは他の端末ＴＥとの間で、データ送信やデータ受信を行う部分であり、種々のネットワークを介して所定の通信プロトコル（例えば、Ｈ．３２３、ＳＩＰ、ＨＴＴＰ等）でデータ通信ができるように、データの通信制御を行う。また、会議システムでは、音声および映像の通信を行うが、必要に応じてデータの秘匿化や、データ量の削減のために、データの暗号化処理（例えば、ＡＥＳ：Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ、３ＤＥＳ：Ｔｒｉｐｌｅ−Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ等）、データの圧縮処理（符号化もしくはエンコードとも呼ぶ。例えば、映像であればＭＰＥＧ４、Ｈ．２６３、Ｈ．２６４、音声であればＧ．７１１、Ｇ．７２２、Ｇ．７２９等）を行う。
したがって、通信部５１は、通信暗号部５２および通信復号部５３を備えることが好ましい。
また、通信部５１は、端末モード切替部８６によって変更された後の動作状態に従って、サーバとの間の通信状態を変更する。
たとえば、映像および音声を双方向に送受信する双方向通信状態や、映像および音声をサーバから一方向的に受信する片方向通信状態に変更する。
【００４８】
認証部５５は、利用者の特定や端末および会議システムへのログイン認証を行う部分であり、主として事前に登録・管理されているＩＤ，パスワード入力により、認証を行う。
【００４９】
記憶部６１は、各種の入力情報（入力映像６６，入力音声６７など），表示情報，出力情報，送受信データ，信号処理されたデータなどの情報を記憶する部分であり、音声認識や画像認識などを利用した人物認識を行うために予め格納されている認識データベース６２を備える。
認識データベース６２は、主として利用者を特定するユーザ名６３と、その利用者の音声特徴データ６４と、その利用者の顔画像特徴データ６５とから構成される。端末ＴＥを複数の利用者が利用する場合、その利用者ごとに、認識情報（６３，６４，６５）が格納される。本稿には図示しないが、認識データベース６２には、利用者ごとのパスワード情報（データ自体は暗号化されていることが望ましい）を格納しても良い。
音声認識や画像認識は、人物認識部８４により行う。
記憶部６１には、ＲＯＭ，ＲＡＭなどの半導体素子，ハードディスク，ＣＤ，ＤＶＤ，ＵＳＢメモリなどの記憶媒体などが用いられる。
また、記憶部６１には、端末ＴＥの各機能を実行させるためのプログラムも記憶される。
【００５０】
信号処理部７１は、入力された映像および音声を、サーバに対して送信するデータに変換（符号化処理，エンコード処理とも呼ぶ）したり、サーバ等から送信されてきた映像および音声を、ディスプレイに表示およびスピーカから出力できるようにもとのデータに変換（復号化処理，デコード処理とも呼ぶ）したりする部分である。
主として、映像符号化部７２，映像復号化部７３，音声符号化部７４，音声復号化部７５から構成される。
信号処理部７１には、たとえば、所定の規格のコーデックに適合した符号化および復号化を実行することのできるコーデックＬＳＩが用いられる。符号化および復号化処理はＬＳＩのようなハードウェアコーデックではなく、ソフトウェアコーデックによって実現してもよい。
【００５１】
制御部８０は、ＣＰＵ，ＲＯＭ，ＲＡＭ，Ｉ／Ｏコントローラ，タイマー等を含むマイクロコンピュータに相当する部分であり、ＣＰＵが、記憶部６１に記憶されたプログラムをＲＡＭ（主記憶）に読み出すことにより、各種ハードウェアを有機的に動作させて、端末の各機能を実行させる。
図２では、制御部８０の行う機能として、アイドル状態判定部８１，端末状態通知部８５，端末モード切替部８６を示している。
アイドル状態判定部８１は、情報入力部によって生成された状態情報に基づいて、情報端末が使用されていない可能性のあるアイドル状態であることを判定する部分であり、主として、時間計測部８２，入力信号検知部８３，人物認識部８４とからなる。
これらの機能ブロック（８１〜８６）の各機能は、ＣＰＵが、その機能ごとのプログラムに基づいて、入力部１１、映像入力部２１、音声入力部４１などから得られた情報を用いて、それぞれ所定の処理を実行することにより実現される。
【００５２】
アイドル状態判定部８１によって、ネットワークを通じて接続された端末ＴＥの現在の動作状態を判定する処理を行い、端末モード切替部８６が、動作モードを、アクティブモード（Ｍ１），スリープモード（Ｍ２），ログオフモード（Ｍ３），シャットダウンモード（Ｍ４）のいずれかに変更する。
アイドル状態とは、情報端末が使用されていない可能性がある状態を意味し、利用者が中座や退席などの理由で、会議に参加していない状態あるいは参加していない可能性のある状態を意味する。アイドル状態が検出されると、４つのモードのうちアクティブモード以外のいずれかの状態になる。
この動作状態の判定には、後述するように、入力部１１による操作入力の有無の判断と、入力映像および入力音声を利用した人物認識による判断を利用する。
たとえば、所定の設定時間中に継続して（たとえば１０分間）、マウス等の操作入力がなく、カメラから入力される映像に変化がなく、かつマイクからの音声の入力がない場合は、アイドル状態であると判定する。
【００５３】
時間計測部８２は、アイドル状態であるか否かを判断するための設定時間をカウントするものである。設定時間は、予めデフォルト値として固定設定されるか、あるいは利用者によって変更できるようにしてもよい。たとえば、設定時間を１０分に設定したとすると、１０分間継続して状態を監視する。
入力信号検知部８３は、入力部１１からの入力信号の有無を検知する部分である。たとえば、キーボード１２から何らかの文字入力があることが検知されれば、入力信号ありと判断し、アイドル状態ではないと判定される。
【００５４】
人物認識部８４は、入力映像６６と入力音声６７とを用いて、認識データベース６２の認識情報（６３，６４，６５）と比較して一致するか否かを判断し、現在の利用者が、予め認識データベース６１に登録されている利用者に含まれているか否かを判断する部分である。
人物認識では、入力音声６７と音声特徴データ６４とを用いた音声認識と、入力映像６６と顔画像特徴データ６５とを用いた画像認識とを利用して、利用者を特定する。
たとえば、現在会議に参加している利用者の顔画像のデータが、登録されたユーザ名６３に対応した顔画像のデータと一致した場合、その利用者が特定でき、人物認識が成功したと判断し、アイドル状態ではないと判定される。逆に、人物認識が失敗した場合は、情報端末が使用されていない可能性があるアイドル状態であると判定される。
【００５５】
端末状態通知部８５は、情報端末の現在の動作状態を、サーバへ送信する部分であり、検知されたアイドル状態に基づいて、たとえば上記した４つのモード（Ｍ１，Ｍ２，Ｍ３，Ｍ４）のうちいずれかの状態であることを示す状態情報を生成し、通信部５１を介して、サーバに送信する。
たとえば、直前にアクティブモードであったモードが、その後の判定でアイドル状態になったことが検出された場合、アクティブモードからスリープモードになったと判定し、端末は現在スリープモードであることを示す状態情報を、サーバに送信する。
【００５６】
端末モード切替部８６は、自己の端末の動作状態のモードを、上記４つのモードのうちいずれかに変更する部分であり、アイドル状態であることが判定された場合に、情報端末の現在の動作状態に対応して、段階的に動作状態を変更する部分である。
たとえば、アイドル状態判定部８１によって、動作状態がスリープモードからログオフモードに変化したと判定された場合は、その端末の現在の動作状態を、ログオフモードに変更する。動作状態の変更は、端末の現在の動作状態に対応して、段階的に行われる。
【００５７】
以上が、端末の主要な機能ブロックであるが、制御部８０によって実現される機能（８１，８５，８６）は、これに限るものではない。
これらの機能は、主としてソフトウェアによって実現されるものであるので、必要に応じて他の機能を実行するプログラムを記憶部６１に格納し、そのプログラムに基づいてＣＰＵがハードウェアを有機的に動作させることにより、その機能を実行させてもよい。
また、プログラムは、予めＲＯＭ等に固定記憶して提供してもよいが、その後に削除，追加，変更，アップデート等をするために、ハードディスク等の書きかえ可能な記憶装置に記憶してもよく、ＣＤやＤＶＤなどの記録媒体によって提供してもよく、あるいはネットワークを介してサーバ等からダウンロードするようにしてもよい。
【００５８】
＜サーバの構成＞
図３に、サーバの第１実施例の構成ブロック図を示す。
サーバ１は、主として、入力部１０１，表示部１１１，通信部１２１，認証部１２５，ＭＣＵ部１３１，記憶部１４１，信号処理部１５１，および制御部１６１から構成される。
【００５９】
入力部１０１は、各種情報を入力する部分であり、キーボード１０２，マウス１０３，タブレット１０４およびこれらの入力デバイスからの入力を、制御部１６１へ送信することのできる信号に変換する入力処理部１０５とを備える。
表示部１１１は、ＬＣＤ，ＣＲＴなどのディスプレイ１１２と、ディスプレイに表示する表示信号を生成する表示処理部１１３とからなる。
ただし、サーバ１を完全に無人で運用する場合は、入力部や表示部はなくてもよい。
【００６０】
通信部１２１は、ネットワークを介して、端末ＴＥとデータの送受信をする部分であり、端末と同様に、所定の通信プロトコル（例えば、Ｈ．３２３、ＳＩＰ、ＨＴＴＰ等）でデータ通信し、映像および音声を所定のコーデック（例えば、映像であればＭＰＥＧ４、Ｈ．２６３、Ｈ．２６４、音声であればＧ．７１１、Ｇ．７２２、Ｇ．７２９等）で符号化し、所定の規格（例えば、ＡＥＳ：Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ、３ＤＥＳ：Ｔｒｉｐｌｅ−Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ等）で暗号化処理をする通信暗号部１２２と通信復号部１２３とを備える。
認証部１２５は、端末ＴＥと同様に、利用者の特定や端末および会議システムへのログイン認証を行う部分である。
【００６１】
ＭＣＵ部１３１は、いわゆる多地点接続装置（ＭＣＵ）で行われている処理を実行する部分であり、主として、複数の映像信号を合成する映像ミキシング部１３２，映像のサイズを変更する映像リサイズ部１３３，複数の音声信号を合成する音声ミキシング部１３４とから構成される。ＭＣＵ部１３１は信号処理部１５１と共通で構成されていてもよい。
【００６２】
記憶部１４１は、サーバで実行される処理で利用される各種データを記憶する部分であり、さらに、サーバに接続される端末を特定する情報（装置ＩＤ１４３，拠点ＩＤ１４４，ＩＰアドレス１４５）を格納した端末データベース１４２や、端末を利用する利用者を特定する情報（ユーザＩＤ１４７，拠点ＩＤ１４４，ＩＰアドレス１４５，メールアドレス１４８）を格納したユーザデータベース１４６を記憶する部分である。
この端末データベース１４２と、ユーザデータベース１４６は、サーバと端末との間で、双方向通信するときや、サーバから端末へ映像、音声等の情報を片方向送信するときに利用される。
この他に、サーバの各機能を実行するのに必要なプログラムも、記憶部１４１に記憶される。
記憶部１４１には、ＲＯＭ，ＲＡＭ，ハードディスク，ＣＤやＤＶＤなどの記録媒体などが用いられる。
【００６３】
信号処理部１５１は、端末から送られてきた映像および音声を、一旦もとの信号に戻す変換処理（復号化処理，デコード処理）をしたり、複数の端末へ映像や音声を送信するためのデータ変換処理（符号化処理，エンコード処理）をする部分である。
この信号処理部１５１は、端末ＴＥと同様に、主として映像符号化部１５２，映像復号化部１５３，音声符号化部１５４，音声復号化部１５５から構成され、コーデックＬＳＩもしくはソフトウェアコーデックを用いて実現することができる。
【００６４】
制御部１６１は、ＣＰＵ，ＲＯＭ，ＲＡＭ，Ｉ／Ｏコントローラ，タイマー等からなるマイクロコンピュータに相当する部分であり、ＣＰＵが、記憶部１４１に記憶されたプログラムに基づいて、各種ハードウェアを有機的に動作させることにより、サーバの各機能が実現される。
図３では、制御部１６１の機能として、端末状態判断部１６２と、通信方法切替部１６３とを示している。
【００６５】
端末状態判断部１６２は、端末から送られてくる動作状態のモードを示す状態情報を受信して、その端末が現在どのモードになっているかを判断する部分である。
通信方法切替部１６３は、情報端末の端末状態通知部によって送信されてきた端末の動作状態に基づいて、その情報端末に対する通信方法を切り替える部分である。通信方法としては、主として、双方向通信状態、画像音声等の送信をサーバから端末への方向のみとする片方向通信状態、データ通信の中止状態、端末の電源を切断した状態、通信回線を切断してその端末を管理対象外とする状態などがある。
また、サーバと情報端末との間の通信状態は、情報端末の動作状態に従って、各情報端末ごとに変更させられる。
【００６６】
＜端末の動作モードの説明＞
以下に、サーバと端末間における通信状態を切替える実施例として、端末の４つの動作状態のモードについて説明する。
図４に、端末のアクティブモード（Ｍ１）の一実施例の説明図を示す。
ここでは、サーバ１に対して、４台の情報端末（ＴＥ１〜ＴＥ４）が、直接接続されている場合を示す。
図４では、４つの端末（ＴＥ１〜ＴＥ４）の動作状態は、いずれもアクティブモードであるとする。
アクティブモードＭ１とは、ここでは、端末ＴＥが、サーバとの間で、データの双方向通信を行うことが可能な状態を意味する。
たとえば、端末ＴＥ１では、カメラで撮影した自画像（送信画像データＳＤ１）を、サーバへ送信し、サーバから受信画像ＲＤ１を受信することを示している。
【００６７】
ここで、受信画像ＲＤ１は、サーバが４台の端末（ＴＥ１〜ＴＥ４）から送られてきたそれぞれの自画像（ＳＤ１，ＳＤ２，ＳＤ３，ＳＤ４）を受信した後、デコード，リサイズ，ミキシング，エンコードの各処理をして、１つの画面上に、４つの自画像を４分割表示できるようにした画像データである。
各受信画像（ＲＤ１，ＲＤ２，ＲＤ３，ＲＤ４）は、すべて同一画像であり、図４では、表示部の画面上において、その左上に端末ＴＥ１で撮影された画像（ＳＤ１）、右上に端末ＴＥ２で撮影された画像（ＳＤ２）、左下に端末ＴＥ３で撮像された画像（ＳＤ３）、右下に端末ＴＥ４で撮影された画像（ＳＤ４）を４分割表示するような受信画像を示している。
この受信画像は、サーバに接続された端末で共有される共有情報の１つであり、共有情報としては、他に、いずれかの端末で入力された音声や、各端末に予め配信された文書情報も含まれる。
【００６８】
図５に、端末のスリープモード（Ｍ２）の一実施例の説明図を示す。
スリープモードＭ２とは、ここでは、端末ＴＥとサーバ間において、映像や音声などの情報の通信に関して、サーバから端末ＴＥへ、一方向の通信が行われる片方向通信状態を意味する。
図５では、端末ＴＥ１のみがスリープモードＭ２であり、他の端末（ＴＥ２，ＴＥ３，ＴＥ４）はアクティブモードＭ１である状態を示している。
【００６９】
端末ＴＥ１がアクティブモードＭ１からスリープモードＭ２に切替わる条件としては、たとえば、所定の設定時間の間、入力部のキーボード等からの入力が全くなく、かつ入力映像の変化もなく、音声の入力もない状態（アイドル状態）が継続したことが検出された時などが挙げられる。
すなわち、アクティブモードＭ１においてこのようなアイドル状態が検出されたとき、すぐに端末をシャットダウンするのではなく、段階的に動作モードを変更（ここではスリープモードＭ２に変更）することで、中座等で席をはずしていた利用者が戻ってきた時に復帰しやすくする。
スリープモードＭ２では、中座していた利用者が端末の前に着席（カメラの入力映像やマイクの入力音声に変化が起きる）し、何らかの入力操作をすれば、アイドル状態判定部８１および制御部８０を通じ、自動的にアクティブモードに復帰できる。
【００７０】
また、スリープモードＭ２となった端末ＴＥ１では、自画像ＳＤ１を送信することはなく、サーバから、受信画像ＲＤ１を受信することを行う。
サーバでは、３つの端末（ＴＥ２，ＴＥ３，ＴＥ４）から送られてくる自画像（ＳＤ２，ＳＤ３，ＳＤ４）に対して、デコード，リサイズ，ミキシングおよびエンコードなどの一連の処理を実行し、３つ画像を合成した画像を生成する。この場合、サーバでは、端末ＴＥ１の自画像ＳＤ１に対するデコード処理にかかる負荷が軽減されることになる。
たとえば、図５に示すように、もともと端末ＴＥ１の自画像を表示していた左上の領域を空白として４分割表示した合成画像が生成される。この合成画像は、サーバから４つの端末へ送信され、それぞれ受信画像（ＲＤ１，ＲＤ２，ＲＤ３，ＲＤ４）として受信され、各端末の表示部に表示される。
【００７１】
図６に、端末のログオフモード（Ｍ３）の一実施例の説明図を示す。
ログオフモードＭ３とは、ここでは、端末ＴＥとサーバとの間で、映像や音声等の情報通信をしない状態（通信中止状態）を意味する。
図６では、端末ＴＥ１のみが、ログオフモードＭ３であり、他の端末（ＴＥ２，ＴＥ３，ＴＥ４）はアクティブモードＭ１である状態を示している。
端末ＴＥ１がログオフモードＭ３となっているのは、たとえば、スリープモードＭ２になっていた端末ＴＥ１が、所定の設定時間を経過してもアイドル状態が継続的に検出されていることを意味する。
すなわち、スリープモードＭ２の状態のときに、さらに継続してアイドル状態が検出されたとき、すぐに端末をシャットダウンするのではなく、段階的に動作モードを変更（ここではログオフモードＭ３に変更）することで、中座等で席をはずしていた利用者が戻ってきた時に復帰しやすくする。
【００７２】
ログオフモードＭ３の状態で、利用者が端末をアクティブモードに復帰させるためには、たとえば、ユーザ認証およびログイン操作をすればよい。スリープモードＭ２より操作手順が必要となるが、シャットダウンモードＭ４よりは容易に、会議に復帰することができる。
また、ログオフモードＭ３となった端末ＴＥ１では、通信中止状態となるので、自画像ＳＤ１の送信および、受信画像ＲＤ１の受信は行われなくなる。図示しないが、この場合、端末ＴＥ１の表示部１には、利用者に対するユーザログイン画面を表示してもよい。
一方、他の３つの端末（ＴＥ２，ＴＥ３，ＴＥ４）では、アクティブモードの通常の動作が行われ、それぞれの自画像がサーバに送信されるので、図５のスリープモードと同様に、４分割された画面に、３つの端末のそれぞれの自画像を合成した受信画像が生成されて、サーバから３つの端末へ送信される。この場合、サーバでは、端末ＴＥ１の自画像ＳＤ１に対するデコード処理および、合成画像ＲＤ１の送信にかかる負荷が軽減されることになる。すなわち、サーバでは、端末ＴＥ１を除く実質３つの端末（ＴＥ２，ＴＥ３，ＴＥ４）のみの通信処理に負荷が軽減される。
【００７３】
図７に、端末のシャットダウンモード（Ｍ４）の一実施例の説明図を示す。
「シャットダウンモード」Ｍ４とは、ここでは、電源切断状態を意味し、端末とサーバとの間の回線が接続されていない状態である。電源切断は、原則、端末側で自動的に行われるものとするが、サーバからの指示を受けた後に、自動的に切断してもよい。
図７では、端末ＴＥ１のみがシャットダウンモードＭ４であり、他の端末（ＴＥ２，ＴＥ３，ＴＥ４）は、アクティブモードＭ１である状態を示している。
端末ＴＥ１がシャットダウンモードＭ４となるのは、たとえば、ログオフモードＭ３になった後、所定の設定時間の間、継続的にアイドル状態であることが検出されたことを意味する。
すなわち、端末ＴＥ１におけるログオフモードＭ３の状態になって以降も、継続的にアイドル状態であることが検出されつづければ、実質的に利用者が不在となったと判断し、端末の電源を切断する。
シャットダウンした後において、利用者が会議に再度参加したい場合には、通常どおりの操作手順（電源投入、ログイン認証等）を実行して端末を起動させることになる。
【００７４】
図７において、各端末での自画像の送信と、受信画像の受信は、図６のログオフモードと同様であり、３つの端末（ＴＥ２，ＴＥ３，ＴＥ４）とサーバ間での双方向通信が行われる。
【００７５】
以上のように、図５のスリープモードＭ２の場合では、映像、音声等の情報通信がサーバから端末ＴＥ１への一方向の通信のみとなるので、サーバにおける通信処理にかかる負荷が軽減される。図６のログオフモードＭ３と、図７のシャットダウンモードＭ４の場合では、サーバは４台の端末のうち、端末ＴＥ１に対する映像や音声等の情報通信は行われないため、通信処理にかかる負荷が軽減される。
【００７６】
また、現実には、サーバに接続される端末の台数は、５台以上の場合もあり、さらに、端末の動作モードも各端末ごとに変化するので、端末からサーバに送信される情報や、サーバから端末へ送信される合成画像も、図４〜図７以外に種々のパターンが考えられる。
また、サーバに接続された複数の端末がすべてアクティブモードであれば、サーバと各端末間で伝送されるデータ量は多く、サーバで処理すべきデータ量も多いため、伝送遅延や通信障害が起こる可能性は高くなるが、本実施例のように、利用者が不在となっている可能性のある端末の状態を検出し、段階的に動作モードを変更することで、サーバに接続された映像、音声等の情報の通信を行う端末の実質的な数を減少させられるため、伝送遅延の減少と通信障害の発生を低減させることができる。また、利用者の不在を検出した際、すぐに端末の電源を切断する場合よりも、端末が利用できる状態（アクティブモード）への復帰にかかる利用者の操作負担を軽減できる。
【００７７】
＜情報端末とサーバ間の通信シーケンス＞
図８に、情報端末とサーバとの間で行われる通信シーケンスの一実施例の説明図を示す。
図８（ａ）は、端末ＴＥ１が、アクティブモードＭ１のときの通信シーケンスの概要を示したものである。
まず、端末ＴＥ１で、その端末の状態がアイドル状態であるか否か判定し、たとえば、マウスや人検知センサによる入力があることが検出された場合、アイドル状態ではないと判定する。
このとき、端末ＴＥ１からサーバへ、端末ＴＥ１が現在アクティブモードＭ１であるということを示す端末状態情報を通知する。
一方、サーバは、通知された端末状態情報を確認して、その送信元の端末ＴＥ１が「アクティブモード」であることを判断したとすると、映像や音声等の情報を、その端末ＴＥ１とサーバとの間で、相互に双方向に通信するようにする。
【００７８】
図８（ｂ）は、端末ＴＥ１が、スリープモードＭ２となった場合の通信シーケンスの概要を示したものである。
ここでは、端末ＴＥ１において、アクティブモードのときに、アイドル状態であるか否かの判定を行い、アイドル状態になっていると判定されたとする。
このとき、端末ＴＥ１は、動作モードをスリープモードＭ２に移行する。その後、端末ＴＥ１からサーバへ、端末ＴＥ１が現在スリープモードＭ２となっていることを示す端末状態情報を通知する。
一方、サーバでは、通知された端末状態情報を確認して、その送信元の端末ＴＥ１が「スリープモード」Ｍ２になったと判断する。そして、スリープモードになった端末ＴＥ１に対する通信を、双方向通信から片方向通信に切りかえる。
すなわち、映像、音声等の情報通信に関して、サーバから端末ＴＥ１への送信のみをする一方向通信に切りかえる。
【００７９】
ここで、片方向通信への切替えは、主として、次のような２つの方法のうち、いずれかの方法が考えられる。
（１）通信プロトコルを固定したまま、所定の通信シーケンスは継続するが、スリープモードとなった端末ＴＥ１から送信されてきた映像および音声についての一連の信号処理を中止する。具体的には、サーバにおいて、その端末ＴＥ１についての映像復号化処理（デコード）と、音声復号化処理（デコード）を停止する。
この場合、たとえば通信プロトコルとして、ＳＩＰやＨ．３２３、ＨＴＴＰ等の規格が採用されていたとすれば、その通信プロトコルを利用した通信シーケンスは継続して行う。
【００８０】
（２）通信プロトコルを、別の通信プロトコルに変更する。
たとえば、ＳＩＰやＨ．３２３、ＨＴＴＰ等の通信プロトコルを中止し、映像、音声に関するストリーミング配信の通信プロトコルに変更する。ストリーミング配信とは、サーバから端末ＴＥ１へ、一方向的に映像、音声等のデータを送信する通信方式である。
ストリーミング配信としては、所定の規格（ｍｍｓ，ｈｔｔｐ，ｒｔｍｐ，ｒｔｓｐ等）のいずれかを採用することが望ましい。
【００８１】
上記いずれの方法も、端末とサーバ間で所定の通信プロトコルに基づいて、データの送信と受信が行われるが、サーバから端末に対して、一方向的に、映像および音声の送信が行われるものであるので、通信回線を流れるトラフィックを減少させることができる。したがって、データ伝送の遅延を減少させ、通信エラー等の通信障害も削減させることができ、その結果実質的にサーバに接続された端末の数を減少させることができるので、円滑な会議の進行が可能となる。
【００８２】
図８（ｃ）は、端末ＴＥ１が、ログオフモードＭ３となった場合の通信シーケンスの概要を示したものである。
ここで、端末ＴＥ１は、図８（ｂ）のスリープモードＭ２のときに、アイドル状態であるか否かの判定を行い、継続してアイドル状態になっていると判定されたとする。
このとき、端末ＴＥ１では動作モードを、ログオフモードＭ３へ移行する。ログオフモードＭ３にする場合、端末ＴＥ１では、たとえば、具体的には、端末およびサーバとのユーザログインの解除や、端末とサーバとの通信処理を終了させるような処理を行う。
その後、端末ＴＥ１からサーバへ、端末ＴＥ１が現在ログオフモードＭ３となっていることを示す端末状態情報を通知する。
【００８３】
一方、サーバでは、通知された端末状態情報を確認して、その送信元の端末ＴＥ１がログオフモードＭ３になったと判断する。その後、サーバは、端末ＴＥ１との間で行っていた片方向通信を停止し、映像および音声の通信を中止する。
ここで、通信の中止は、たとえば、通信プロトコルはそのまま継続し、一方向の映像、音声等の通信を停止してもよく、あるいは、通信プロトコルに従ってシーケンスそのものを停止し、確立していたリンクを解除（ユーザログイン待ち状態）してもよい。
【００８４】
図８（ｄ）は、端末ＴＥ１が、シャットダウンモードＭ４となった場合の通信シーケンスの概要を示したものである。
ここでは、端末ＴＥ１において、図８（ｃ）のログオフモードＭ３のときに、アイドル状態か否かの判定を行い、継続的にアイドル状態となっていると判定されたとする。
このとき、端末ＴＥ１では通信プロトコルが継続されている場合は、サーバに対して、シャットダウンモードＭ４へ移行することを示す端末状態情報を通知する。
その後、端末ＴＥ１では、所定のシャットダウンの一連の動作を自動的に行い、回線を切断して、自己の電源を切断する。
一方、サーバ側では、通知された端末状態情報を確認し、端末ＴＥ１がシャットダウンモードＭ４になったと判断する。その後、サーバは、端末ＴＥ１を管理対象外とするための処理たとえば、具体的には、サーバと端末ＴＥ１との間の通信プロトコル終了、端末ＴＥ１およびサーバにおけるユーザ認証の解除（ログオフ）のような処理を行う。
【００８５】
以上が、端末の４つの動作モードに対するシーケンスの説明である。
ただし、動作モードはこれらの４つに限定されるものではなく、これら４つ以外の他のモードを設定する場合は、その他のモードについて設定された所定のシーケンスを実行するようにすればよい。
この他のモードとしては、たとえば、映像のみによる通信，音声のみによる通信，共有ドキュメントデータのみの通信，および、これらの双方向通信，片方向通信などのモードが考えられる。
【００８６】
＜端末のモード移行処理＞
図９に、情報端末のモード移行処理の第１実施例のフローチャートを示す。
ここでは、上記したように図４から図８に示したように、端末のモードを段階的に移行させる処理について説明する。
また、端末およびサーバは、それぞれ図２および図３に示したような機能ブロックを備え、端末側でアイドル状態の判定処理を行うものとする。
【００８７】
図９において、まず、ステップＳ１に示すように、端末が初期状態として、アクティブモードＭ１になっているものとする。このとき、図８（ａ）で示したように、端末とサーバとは、双方向通信状態にある。
ステップＳ２において、端末の端末状態通知部８５が、自己の現在の動作モードの状態を確認し、ここでは、アクティブモードＭ１であることをサーバに通知する（端末状態通知処理）。
【００８８】
ステップＳ３において、端末のアイドル状態判定部８１が、入力部１１からの入力信号の有無、映像入力部２１からの入力映像の変化の有無、音声入力部４１からの入力音声の有無等を確認することにより、端末が現在アイドル状態にあるか否かを判定する（アイドル状態判定処理）。
このアイドル状態判定処理の詳細については、図１０のフローチャートで説明する。
【００８９】
ステップＳ４において、端末がアイドル状態であると判定された場合は、ステップＳ５へ進み、そうでない場合は、ステップＳ１４へ進む。
ステップＳ５において、端末モード切替部８６が、端末の動作モードをスリープモードＭ２に移行する処理を実行する。
ここでは、自己の端末の動作モードをアクティブモードＭ１からスリープモードＭ２に設定変更する。具体的には、たとえば、今まで双方向通信をしていた通信状態を、サーバから映像および音声などの情報を受信する片方向通信に切り替える処理や、映像や音声のストリーミング受信処理等を行う。
【００９０】
ステップＳ６において、端末状態通知部８５が、スリープモードＭ２になったことを、サーバへ通知する。
ステップＳ７において、ステップＳ３と同じアイドル状態判定処理を実行する。
ここでは、現在スリープモードＭ２である場合において、さらにアイドル状態が継続しているかどうかをチェックする。
【００９１】
ステップＳ８において、アイドル状態が継続していると判定された場合は、ステップＳ９へ進み、そうでない場合は、ステップＳ１５へ進む。
ここで、そうでない場合とは、たとえば、マウスや人検知センサ等の入力があった場合を意味する。このとき、ステップＳ１５において、端末モード切替部８６が、アクティブモード移行処理を実行する。
アクティブモード移行処理では、たとえば、端末の動作モードを、スリープモードＭ２からアクティブモードＭ１に設定変更し、さらに通信状態を片方向通信から双方向通信に戻すようにする。
ステップＳ１５の後は、ステップＳ１４へ進み、端末状態通知部８５が、アクティブモードＭ１になったことを、サーバへ通知する。
【００９２】
ステップＳ９において、端末モード切替部８６が、ログオフモード移行処理を実行する。ここでは、端末の動作モードを、スリープモードＭ２からログオフモードＭ３へ設定変更し、さらに、図示しないが、端末の画面上にユーザログイン画面を表示するような処理をする。
ステップＳ１０において、端末状態通知部８５が、ログオフモードＭ３になったことを、サーバへ通知する。
ステップＳ１１において、アイドル状態判定部８１が、再度アイドル状態判定処理を実行する。
ステップＳ１２において、ログオフモードＭ３の状態において、アイドル状態がさらに継続している場合は、ステップＳ１３へ進み、そうでない場合は、ステップＳ１６へ進む。
【００９３】
ステップＳ１３において、端末モード切替部８６が、シャットダウンモード移行処理を実行する。ここでは、端末の動作モードを、ログオフモードＭ３からシャットダウンモードＭ４へ設定変更する。この後、ステップＳ１４へ進み、端末がシャットダウンモードＭ４になったことを、サーバへ通知し、その後、図９には示していないが、端末自身の電源を自動的に切断する。あるいは、ステップＳ１３の処理の中で、サーバにシャットダウンすることを通知した後、自動的に電源を切断し、処理を終了してもよい。
【００９４】
一方、ステップＳ１６において、ログオフモードＭ３の状態で、アイドル状態でないことが検出されたので、ログイン画面を表示する。
このとき、アイドル状態でないことは、利用者がキーボードやマウスを使用して、いわゆるログイン操作をしたことを意味する。
また、ステップＳ１６の処理の後、ステップＳ１５に移行し、端末の動作モードは、ログオフモードＭ３から、アクティブモードに設定変更される。その後、ステップＳ１４において、動作モードがアクティブモードになったことを、サーバへ通知する。
【００９５】
図１０に、図９に示した端末で行うアイドル状態判定処理の一実施例のフローチャートを示す。
ステップＳ２１において、時間計測部８２による時間計測処理を開始する。ここでは、タイマーを初期値（設定時間）にリセットする。
初期値としては、アイドル状態であるか否かを判断するのに適切な時間、たとえば１０分にセットし、カウントダウンをスタートさせる。ただし、アイドル状態であるか否かを判断するのに適切な時間は、一律に予め１０分間に固定設定してもよいが、この時間は、利用者や利用形態によって適切な値が異なると考えられるので、利用者もしくはシステム管理者等によって設定変更できるようにすることが好ましい。
【００９６】
ステップＳ２２において、入力信号検知部８３が、入力部１１，映像入力部２１，音声入力部４１からの入力信号の有無や変化をチェックする。
たとえば、キーボードやマウスからの操作入力がないかチェックする。また、人検知センサからの入力信号がないか、利用者の音声入力がないかをチェックする。
さらに、カメラから入力される映像入力について、所定のしきい値を越えるような変化がないかどうかチェックする。
これらの入力信号をチェックした結果、初期値として設定された設定時間の間に、１回も入力信号と入力音声の入力がなく、かつ映像入力の変化もない場合は、入力信号の検知がなかったと判断される。
一方、入力信号の入力が１回以上ある場合や、あるいは映像入力に所定の変化が検知された場合は、入力信号が検知されたと判断される。
【００９７】
ステップＳ２３において、人物認識部８４が、音声認識および画像認識のいずれか一方、あるいは両方の認識処理を用いて、利用者の人物認識を行う。
人物認識処理は、利用者が、端末の記憶部６１の認識データベース６２に予め登録された人物であるか否かを確認する処理である。
たとえば、カメラ２２で撮影された入力映像６６と、認識データベース６２の中に記憶された顔画像特徴データとを比較し、いわゆるパターンマッチングにより、一致する顔画像特徴データが認識データベース６２の中に存在する場合は、人物認識が成功し、現在の利用者がだれであるかが正常に特定され、その利用者が端末の前に在席し、会議に参加している状態であると判断される。
【００９８】
一方、一致する顔画像特徴データが、認識データベース６２の中に存在しなかった場合、利用者を特定することができず、人物認識が失敗したことになる。この場合、利用者が端末のカメラによる撮影範囲に存在せず、会議に参加していない可能性がある状態であると判断される。
ただし、この人物認識処理は、処理に必要な負荷や処理時間、認識精度（カメラに複数の人物が映った場合や、照明環境、眼鏡や服装などの影響による認識誤り発生）等の理由から、必須の処理とはせずに、利用者が必要に応じて実行できるオプションとしてもよい。
ステップＳ２４において、ステップＳ２２とＳ２３の結果、入力信号や入力音声等の検知がなかった場合や、人物認識も失敗した場合は、現在利用者が端末の前には不在の可能性があると判断し、ステップＳ２５へ進む。
【００９９】
一方、入力信号のいずれか１つ以上の入力が検知された場合、あるいは、人物認識が成功した場合、またはいずれかの入力信号があり人物認識も成功した場合は、ステップＳ２７へ進み、アイドル状態でないと判定し、処理を終了する。
ステップＳ２５において、設定された設定時間が経過したか否かチェックする。設定時間がまだ経過していないときは、ステップＳ２２へ戻り、再度ステップＳ２２からＳ２４までの処理を繰り返す。
設定時間がすでに経過した場合、その設定時間の間、アイドル状態が継続されていたことになるので、ステップＳ２６へ進み、端末が現在アイドル状態になっていると判定し、処理を終了する。
【０１００】
図１１に、サーバにおける端末状態判断制御処理の一実施例のフローチャートを示す。
ステップＳ３１において、サーバの端末状態判断部１６２が、各端末から送られてくる端末状態情報が受信されたか否か、確認する。受信された場合は、ステップＳ３２へ進む。
ここで、端末状態情報は、たとえば、端末を特定する端末ＩＤと、その端末の動作モード（端末状態）を示すデータとを含むものである。
ステップＳ３２において、受信した端末状態情報に含まれる「端末状態」を示すデータが、アクティブモードＭ１を示すものであるか否か、チェックする。
ここで、アクティブモードＭ１であれば、ステップＳ３３へ進み、通信方法切替部１６３が、その端末との間では、音声および映像の双方向通信ができる状態に設定する。具体的には、たとえば、通信方法切替部１６３が、所定の通信プロトコル（ＳＩＰ，Ｈ．３２３，ＨＴＴＰ等）に基づく通信シーケンス処理を行う。
【０１０１】
ステップＳ３２において、アクティブモードでない場合は、ステップＳ３４へ進む。
ステップＳ３４において、受信した「端末状態」のデータが、スリープモードＭ２を示すものか否か、チェックする。
スリープモードＭ２であれば、ステップＳ３５へ進み、そうでない場合は、ステップＳ３６へ進む。
ステップＳ３５において、通信方法切替部１６３が、その端末との間では、サーバから端末に対して音声および映像の情報を伝送する片方向通信状態に設定する。
具体的には、たとえば、通信方法切替部１６３が、ストリーミング配信用の規格（ｍｍｓ，ｈｔｔｐ，ｒｔｍｐ，ｒｔｓｐ等）に基づく通信プロトコルへの切替えや、端末からの映像、音声の受信を中止する等の処理を行う。
【０１０２】
ステップＳ３６において、受信した「端末状態」のデータが、ログオフモードＭ３を示すものか否か、チェックする。
ログオフモードＭ３であれば、ステップＳ３７へ進み、そうでない場合はステップＳ３８へ進む。
ステップＳ３７において、通信方法切替部１６３が、その端末とサーバ間での音声および映像の通信を中止する。
【０１０３】
ステップＳ３８において、受信した「端末状態」のデータが、シャットダウンモードＭ４を示すものか否か、チェックする。
シャットダウンモードＭ４であればステップＳ３９へ進み、そうでない場合は、処理を終了する。あるいは、ステップＳ３１へ戻ってもよい。
ステップＳ３９において、端末がシャットダウンされたことが受信されると、端末との接続が完全に切れたことになるので、その端末を管理対象外に設定する。
管理対象外とするためには、具体的には、端末に対し、所定の通信プロトコルによる通信シーケンスを終了する等の処理をすればよい。
図１１に示したサーバによる処理は、サーバに接続された各端末ごとに行われる。
【０１０４】
図１２に、端末およびサーバの記憶部に格納されている各データベースの内容の一実施例の説明図を示す。
図１２（ａ）は、図２の端末の記憶部６１に格納されている認識データベース６２の一実施例を示している。
ここでは、登録されたユーザごとに、そのユーザ名６３と、ユーザの音声特徴データ６４と、顔画像特徴データ６５とが、関連付けて記憶されている。
【０１０５】
図１２（ｂ）は、図３のサーバの記憶部１４１に格納されている端末データベース１４２の一実施例を示している。
ここでは、端末ごとに、装置ＩＤ１４３と、拠点ＩＤ１４４と、ＩＰアドレス１４５とが、関連付けて記憶されている。
【０１０６】
図１２（ｃ）は、図３のサーバの記憶部１４１に格納されているユーザデータベース１４６の一実施例を示している。
ここでは、ユーザ名１４７と、拠点ＩＤ１４４と、メールアドレス１４８と、ＩＰアドレス１４５とが関連付けて記憶されている。
なお、各データベースに格納される情報の項目は、以上のものに限られず、他に必要な項目があれば、追加して記憶してもよい。
【０１０７】
＜情報端末とサーバ間通信の第２実施例＞
以下に、第２実施例の構成および処理内容について、説明する。
この第２実施例では、端末が現在アイドル状態であるか否かを判定する処理を、端末側ではなく、サーバで行うことを特徴とする。
図１３に、情報端末の第２実施例の構成ブロック図を示す。
ここで、図２の構成とは、記憶部６１と制御部８１の機能ブロックが一部分異なる。
すなわち、記憶部６１には、認識データベース６２を備えない。
また、制御部８１は、アイドル状態判定部８１を備えずに、端末モード変更受付部８７を備える。
【０１０８】
情報端末の端末状態通知部８５は、入力部等からなる情報入力部によって生成された状態情報と、情報端末の現在の動作状態とを含む状態監視情報を、サーバへ送信する。
また、端末モード変更受付部８７は、サーバから送信される動作状態の移行通知を受信する部分である。
端末モード切替部８６は、受信した移行通知に基づいて、段階的に動作状態を変更する。
【０１０９】
図１４に、サーバの第２実施例の構成ブロック図を示す。
ここで、図３の構成とは、記憶部１４１と、制御部１６１の機能ブロックが一部分異なる。
記憶部１４１は、図２の端末に備えられていたのと同じ認識データベース１４９をさらに備える。
また、制御部１６１は、端末モード制御部１６４を備え、図２の端末に備えられていたアイドル状態判定部１６５をさらに備える。
【０１１０】
アイドル状態判定部１６５は、図２の端末で行われるアイドル状態の判定と同様の処理を行うものであるが、そのアイドル状態であることの判定は、接続される各端末から送信される状態監視情報や、端末で入力された映像や音声の情報に基づいて、行われる。
端末モード制御部１６４は、アイドル状態であると判定された場合に、端末から送信されてきた状態監視情報に含まれる現在の動作状態に対応して、サーバが段階的に移行させるべき動作状態を設定し、端末に対して、設定した動作状態への移行通知を、送信する部分である。
この第２実施例でも、サーバと情報端末との間の通信状態は、その情報端末の動作状態に従って各情報端末ごとに変更させられる。
【０１１１】
また、認識データベース１４９は、図２の端末と同様に、アイドル状態判定部１６５の人物認識処理で用いられ、端末データベース１４２とユーザデータベース１４６は、端末とサーバ間の双方向通信および片方向通信をするときや、これらの通信方法の切替をするときに用いられる。
図１３と図１４の構成のうち、他の機能ブロックについては図２と図３と同様の処理を実行する。
【０１１２】
図１５に、第２実施例におけるサーバのモード移行制御処理のフローチャートを示す。
ここでは、主として、端末から送られてくる各種情報を用いて、その端末がアイドル状態となっているか否かを判定し、その端末の動作モードを移行させるか否かを決定し、その端末に対して動作すべき動作モードを通知する処理を行う。
すなわち、サーバが、各端末の動作モードを管理し、各端末はサーバから通知される動作モードに基づいて、受動的にその動作モードを設定変更する。
図１５のフローは、サーバが、各端末ごとにそれぞれ独立に行う処理である。
【０１１３】
ステップＳ５１において、ここでは、サーバの初期状態として、現在端末との間の通信が双方向通信状態であって、その端末がアクティブモードであったとする。
ステップＳ５２において、サーバのアイドル状態判定部１６５により、端末がアイドル状態であるか否か、判定する。
この判定処理の詳細内容は、図１６のフローチャートで説明する。
ステップＳ５３において、端末がアイドル状態になったと判定された場合、ステップＳ５４へ進み、そうでない場合は処理を終了する。
ステップＳ５４において、今まで端末の動作モードはアクティブモードであったので、端末モード制御部１６４が、その端末をスリープモードに移行させる処理を行う（スリープモード移行処理）。
【０１１４】
ステップＳ５４では、端末に対して、現在の動作モードを「スリープモード」Ｍ２へ切りかえることを要求する移行通知を、送信する。さらに、通信方法切替部１６３により、現在の通信状態を、双方向通信から片方向通信に切りかえる処理をし、サーバから端末に対して、映像や音声の情報の一方向送信が行えるようにする。この移行通知を受信した端末は、動作モードをアクティブモードＭ１からスリープモードＭ２へ切り替え、一方向通信ができる通信状態にする。
ステップＳ５５において、アイドル状態判定部１６５が、ステップＳ５２と同様に、アイドル状態判定処理を行う。
ステップＳ５６において、端末が、さらにアイドル状態が継続している状態であったと判定された場合、ステップＳ５７へ進み、そうでない場合は、ステップＳ６１へ進む。
【０１１５】
ステップＳ５７において、現在スリープモードＭ２のときに、アイドル状態であると判定されたので、端末モード制御部１６４が、その端末をログオフモードＭ３に移行させる処理を行う（ログオフモード移行処理）。
ここでは、端末に対して、動作モードを「ログオフモード」Ｍ３へ切りかえることを要求する移行通知を、送信する。また、通信状態を一方向通信から、通信中止状態に変更する。
【０１１６】
一方、ステップＳ６１では、端末がアイドル状態ではないと判定された場合なので、端末モード制御部１６４は、アクティブモード移行処理を行う。
たとえば、端末がスリープモードＭ２の状態のときに、キーボードや人検知センサからの入力信号が入力されたことを示す状態監視情報が、その端末から送られてきた場合に、アイドル状態ではないと判定され、ステップＳ６１の処理を行う。
ステップＳ６１においては、端末に対して、動作モードをスリープモードＭ２からアクティブモードＭ１へ切りかえることを要求する移行通知を、送信する。さらに、通信状態を、一方向通信から双方向通信へ変更する。
【０１１７】
ステップＳ５８において、アイドル状態判定部１６５が、アイドル状態判定処理を行う。
ステップＳ５９において、その端末がアイドル状態をまだ継続していると判定された場合、ステップＳ６０へ進み、そうでない場合は、ステップＳ６２へ進む。
ステップＳ６０において、端末が現在ログオフモードＭ３のときに、アイドル状態であると判定されたので、端末モード制御部１６４が、その端末をシャットダウンモードＭ４へ移行させる処理を行う（シャットダウンモード移行処理）。
【０１１８】
ここでは、端末に対して、動作モードを「シャットダウンモード」Ｍ４へ切りかえることを要求する移行通知を、送信する。
この移行通知を受信した端末は、所定のシャットダウン処理を自動的に行い、電源を切断する。
また、サーバは、その端末との間の通信回線を切断し、その端末を管理対象外に設定する。
【０１１９】
一方、ステップＳ６２において、ログオフモードＭ３のときにアイドル状態でないと判定された場合は、利用者が何らかの入力操作等をしたことや映像の変化あるいは音声の入力がされたことが検出された場合なので、ログオンへの移行通知処理を行う。
ここでは、たとえば、端末に対して、ログオフ状態から、ログオン状態に変化した可能性のあることを通知し、ステップＳ６１にて、動作モードを、アクティブモードへ移行すべきことを要求する通知を送信する。
この通知を受けた端末は、利用者のログオン操作を受け入れて、たとえば、動作モードをアクティブモードにすればよい。
あるいは、ログオフ状態からログオンへ変更する処理は、端末側での処理なので、サーバ側では、ステップＳ５９でアイドル状態でないと判定した場合には、ステップＳ６２の処理は行わずに、処理を終了してもよい。
【０１２０】
図１６に、サーバにおけるアイドル状態判定処理のフローチャートを示す。
ここで、ステップＳ７２とＳ７３での処理が、端末から送信されてくる情報を基にして行われる点が、図１０の処理と異なる。
ステップＳ７１において、時間計測部１６６が、時間計測処理を開始させ、設定時間を初期値にリセットし、カウントダウンを開始する。
ステップＳ７２において、端末状態判断部１６２が、端末から送られてくるその端末の状態監視情報を受信する。
状態監視情報とは、たとえば、端末の現在の動作モードを示す情報、端末の入力部から入力された入力信号の情報、端末のカメラによって入力された映像およびマイクから入力された音声などの情報を意味する。
【０１２１】
ここでは、受信された状態監視情報を用いて、入力信号検知部１６７が、アイドル状態でないと判定されるような入力信号が入力されていないかどうか、チェックする。
たとえば、人検知センサによる入力の有無が判定され、人検知センサの入力があったことが検知された場合には、後のステップＳ７４において、アイドル状態でないと判断される。
また、この他に、端末のキーボード，マウス，タブレットなどの入力部からの入力信号が１つ以上あったことが検知された場合には、アイドル状態でないという判定に利用される。
さらに、端末から送られてきた映像に変化があるか否か、端末から入力音声が送られてきたか否かチェックされ、映像の変化があったことが検知された場合、入力音声が送られてきた場合、あるいは、映像の変化と入力音声の入力がいずれも検知された場合は、いずれの場合も、アイドル状態でないと判定される。
逆に、上記した入力信号がすべて検知されていない場合には、アイドル状態であると判定される。
【０１２２】
ステップＳ７３において、人物認識部１６８が、端末から送られてきた受信映像と受信音声とを用いて、人物認識処理を行う。
ここでは、受信音声と、認識データベース１４９の音声特徴データとを比較し、音声認識処理を行い、さらに、受信映像と、認識データベース１４９の顔画像特徴データとを比較し、画像認識処理を行う。
各認識処理は、図１０で行われる処理と同様の処理である。
これらの認識処理で、音声および映像が一致するデータが認識データベースに存在した場合には、人物認識が成功したと判断し、アイドル状態ではないと判定される。
一方、一致するデータがないときには、人物認識が失敗したと判断し、アイドル状態であると判定される。
【０１２３】
ステップＳ７４において、ステップＳ７２とＳ７３との判断結果を利用して、アイドル状態か否かの判定を行う。
ここでは、ステップＳ７２の判断結果により端末で入力信号が検知された場合、あるいはステップＳ７３で人物認識が成功した場合、あるいは入力信号が検知されかつ人物認識が成功した場合のいずれかであれば、ステップＳ７７へ進み、現在端末はアイドル状態ではないと判定する。
また、入力信号が検知されなかった場合、かつ人物認識が失敗した場合に、ステップＳ７５へ進む。
ステップＳ７５において、設定時間が経過したか否かを確認し、まだ経過していない場合は、ステップＳ７２へ戻る。
一方、経過してしまった場合は、その設定時間をこえて、アイドル状態が継続していたことになるので、ステップＳ７６へ進み、アイドル状態であると判定する。
【０１２４】
図１７に、第２実施例における端末の端末状態制御処理のフローチャートを示す。
ここでは、主として、サーバから送られてくる移行通知の内容に基づいて、自己の端末の動作モードを設定変更する。
まず、端末状態通知部８５は、ステップＳ８１において、自己の端末状態を監視し、ステップＳ８２において、サーバに、監視によって取得した現在の状態監視情報を通知する。
【０１２５】
ステップＳ８１においては、入力部１１からの入力信号の有無をチェックし、さらに映像入力部２１のカメラ２２からの入力された映像を、入力映像６６として記憶部６１に記憶し、マイク４２から入力された音声を、入力音声６７として記憶する。
ステップＳ８２では、たとえば入力部からの入力信号の有無についての情報、入力映像および入力音声を含む情報をサーバに通知するために、現在の状態監視情報を生成し、サーバに送信する。
【０１２６】
次に、ステップＳ８３において、端末モード変更受付部８７が、サーバからの移行通知情報が受信されたか否か、チェックする。
受信されていない場合はステップＳ８１へ戻り、受信された場合は、ステップＳ８４へ進む。
【０１２７】
ステップＳ８４，Ｓ８６，Ｓ８８において、受信した移行通知の内容が、どの動作モードであるか否か、チェックする。
まず、ステップＳ８４において、受信した移行通知がスリープモードＭ２への移行を要求するものであった場合、ステップＳ８５へ進み、端末モード切替部８６が、動作モードを、スリープモードＭ２へ切り替え、通信状態を、音声と映像の片方向通信の状態に移行させる。
すなわち、サーバから送られてくる映像と音声を受信する片方向通信に切りかえる。
このとき、端末からサーバへ、映像および音声を送信しないようにしてもよい。
【０１２８】
ステップＳ８６において、受信した移行通知がログオフモードＭ３への移行を要求するものであった場合、ステップＳ８７へ進む。
ステップＳ８７では、上記した図９のステップＳ９と同様のログオフモードへの移行処理を行う。
ステップＳ８８において、受信した移行通知がシャットダウンモードＭ４への移行を要求するものであった場合、ステップＳ８９へ進み、ステップＳ１３と同様のシャットダウンモード移行処理を行う。
【０１２９】
一方、ステップＳ８８において、受信した移行通知がシャットダウンモードＭ４への移行通知でなかった場合は、ステップＳ９０へ進み、ステップＳ１５と同様に、アクティブモードＭ１への移行処理を実行する。ただし、現在すでにアクティブモードＭ１になっている場合は、この処理は実行しなくてもよい。
スリープモードＭ２からアクティブモードＭ１へ戻る場合には、片方向通信から双方向通信へ切りかえる処理が行われる。
【０１３０】
以上が第２実施例における端末とサーバの処理内容である。
この第２実施例では、アイドル状態の判定処理をサーバ側で行うので、その判定処理を行うための負荷がサーバにかかることになるが、第１実施例と同様に、段階的に、端末の動作モードを変更するので、サーバに接続される実質的な端末の数を減少させることができ、サーバの負荷の減少と、通信遅延等の減少による円滑な会議の実現と、利用者の操作負担の軽減を図ることができる。
【０１３１】
＜第３実施例、グループ化による端末数の減少＞
ここでは、複数の端末をグループ化して、その中の１台を代表端末に設定することにより、サーバに接続される端末の数を実質的に減少させる実施例を説明する。
図１８に、情報端末の第３実施例の構成ブロック図を示す。
図１８において、端末は、さらに、代表端末検出要求部８８と、ストリーミング要求部８９と、ストリーミング受信部９０と、ストリーミング配信部９１とを備える。
代表端末検出要求部８８は、サーバに対して、同一拠点内の代表端末を検出するように要求する部分であり、検出された代表端末の情報をサーバから受信する。
ストリーミング要求部８９は、代表端末に対して、ストリーミング情報（音声および映像）をその端末に配信するように要求する部分である。
ストリーミング受信部９０は、サーバあるいは代表端末から配信されたストリーミング情報を受信する部分である。
【０１３２】
ストリーミング配信部９１は、端末が代表端末である場合に、他の端末に対してストリーミング情報を送信する部分である。
ここで、ストリーミング配信とは、ストリーミング情報である映像や音声を一方向に送信することを意味する。
ストリーミング受信を行う端末は、自端末の映像、音声データの符号化や送信を行わないので、双方向通信を行う場合よりも、端末にかかる負荷は少なくなる。
【０１３３】
図１９に、サーバの第３実施例の構成ブロック図を示す。
図１９において、サーバは、さらに、代表端末検出部１６９と、ストリーミング配信部１７０とを備える。
代表端末検出部１６９は、記憶部１４１の端末データベース１４２に記憶された拠点ＩＤ１４４を用いて、代表端末とすべき端末が、同一拠点内に存在するか否かを検出する部分である。
ストリーミング配信部１７０は、サーバから、情報端末に対して、ストリーミング情報を送信する部分である。
このサーバからのストリーミング配信は、代表端末と判断された情報端末に対してのみ行われ、代表端末でない情報端末へは行われない。
【０１３４】
また、図２０に、この第３実施例で用いられる端末データベースの一実施例の説明図を示す。図２０において、記憶部１４１の端末データベース１４２には、代表端末フラグ１５０を備える。代表端末フラグ１５０は、端末が代表端末であるか否かを識別するための情報であり、「ＯＮ」のとき、その端末が代表端末であることを意味し、「ＯＦＦ」のとき、その端末は代表端末でないことを意味する。
図２０においては、４つの端末のうち、拠点ＩＤが「関西」となっている２つの端末が、同一拠点の端末であり、この同一拠点に含まれる２つの端末のうち、装置ＩＤ＝「Ｇ５３１８２」の端末の代表端末フラグ１５０が「ＯＮ」であるので、この端末が代表端末であることを意味する。
ここで、同一拠点が１つのグループを形成し、１つのグループには、代表端末は１つだけ存在する。
【０１３５】
グループ化は、比較的近くの位置に設置されている端末同士を１つのグループとして設定するものであり、たとえば、図２０のように、同じ拠点に属する複数の端末は、１つのグループに属するものとして扱う。
また、同一ルータあるいは同一中継サーバの配下のネットワークに属する複数の端末を、１つのグループに属するものとして扱ってもよく、さらに、ＩＰアドレスを構成する数字列のうち、特定の数字列部分が同一の端末（同一ドメイン内の端末）を１つのグループに属するものとして扱ってもよい。
以下の説明では、同一拠点ＩＤを持つ複数の端末は、同一のグループに属するものとして扱うことにする。
【０１３６】
また、図２０の場合、同一拠点に含まれる２つの端末は、１つのグループに属する端末とみなされ、サーバから見た場合、そのグループに属する代表端末のみがサーバに接続されているかのように扱われる。すなわち、サーバから映像音声等の情報を送信する場合、サーバから、同一拠点（同一グループ）に属する代表端末のみにその情報が直接送信され、その同一拠点に属する代表端末でない端末にはサーバから直接送信されない。
代表端末でない端末には、原則として、同一拠点に属する代表端末から、ストリーミング配信で、情報を送信するものとする。
【０１３７】
また、同一拠点すなわち、１つのグループに属する端末が複数ある場合は、アイドル状態ではない端末、すなわち現在アクティブモードである端末のうち１つの端末が代表端末として選択される。
ただし、１つのグループに属する端末の中に、アクティブモードである端末が１つもない場合は、アイドル状態である端末（たとえば、スリープモードの端末）の中から、１つの端末が代表端末として選択される。
さらに、代表端末となっていた端末がアイドル状態となってしまった場合は、同一拠点内のアクティブモードである他の端末を代表端末に変更し、変更後の代表端末からストリーミング配信を受けるようにしてもよい。
【０１３８】
また、同一拠点の中に、１つしか端末が存在しない場合において、その端末がアイドル状態となった場合、他の拠点に属する代表端末から、ストリーミング配信を受けるようにしてもよい。
あるいは、アイドル状態となった端末自身が、実質的に代表端末となり、サーバから、ストリーミング配信を受けるようにしてもよい。
また、同一拠点内の代表端末は、原則として同じグループ内に属する他の端末に対してのみストリーミング配信を行うが、他の拠点に属する端末ＴＥｎからストリーミング配信の要求を受けた場合は、代表端末は、他の拠点のその端末ＴＥｎに対して、ストリーミング配信をしてもよい。
【０１３９】
まず、第３実施例における端末とサーバ間の情報配信の概略について説明する。
図２６に、第３実施例におけるサーバ端末間通信状態の１つであるアクティブモードの説明図を示す。
図２６では、１つのサーバに対して、４台の端末（ＴＥ１〜ＴＥ４）が接続されるものとする。
ここでは、４台の端末（ＴＥ１〜ＴＥ４）は、すべてアクティブモードＭ１であるとし、端末ＴＥ１とＴＥ２とが、同一拠点に属し、同じ拠点ＩＤを持ち、グループ化されているものとする。
また、４つの端末は、いずれもまだ代表端末とはなっておらず、したがって各端末の代表端末フラグは、すべて「ＯＦＦ」であるとする。
【０１４０】
このように、すべての端末がアクティブモードＭ１である場合、サーバと各端末間の通信は、いずれも双方向通信状態にあり、各端末（ＴＥ１〜ＴＥ４）からサーバへは、その端末のエンコードされた自画像（ＳＤ１〜ＳＤ４）が送信され、サーバにおいて、４つの自画像が受信されデコード，リサイズ，ミキシング，エンコードという一連の処理が実行されて、合成された画像（ＲＤ１〜ＲＤ４）が、各端末（ＴＥ１〜ＴＥ４）へ配信される。
したがって、同一拠点に２つの端末（ＴＥ１，ＴＥ２）が属する場合であっても、その２つの端末（ＴＥ１，ＴＥ２）は、それぞれ、サーバに対して双方向通信を行う。
この状態はサーバに最も負荷がかかり、伝送遅延や通信障害が起こりやすい状態であると言える。
【０１４１】
図２７に、第３実施例のサーバ端末間通信状態において、端末ＴＥ１がスリープモードＭ２になった場合の説明図を示す。
ここでは、端末ＴＥ１において、利用者が不在となりアイドル状態が検出され、アクティブモードＭ１からスリープモードＭ２になり、端末ＴＥ１とサーバとの直接通信は行われない。
この場合、端末ＴＥ１と同一拠点（同一グループ）に属する端末であって、アクティブモードである端末ＴＥ２が、そのグループの代表端末となる。
そして、スリープモードＭ２となった端末ＴＥ１は、代表端末ＴＥ２からストリーミング配信を受ける。
【０１４２】
代表端末ＴＥ２は、サーバで生成された受信画像ＲＤ２を受信し、この受信画像ＲＤ２をそのまま端末ＴＥ１へストリーミング配信する。すなわち受信画像ＲＤ２と同じ画像ＲＤ１を配信する。
端末ＴＥ１は、スリープモードＭ２なので、自画像ＳＤ１を送信することなく、端末ＴＥ２から送られてくる情報ＲＤ１をストリーミング受信するだけである。
ここで、サーバは端末ＴＥ１の自画像ＳＤ１は送信されてこないので、サーバで生成される合成画像は、自画像ＳＤ１は含まれず、３つの端末（ＴＥ２，ＴＥ３，ＴＥ４）から送られてきた自画像（ＳＤ２，ＳＤ３，ＳＤ４）を一画面に分割表示できるようにした画像である。
【０１４３】
図２７の場合、サーバから見ると、図２６の場合に比べて、直接接続され、かつ双方向通信を行う端末が１台少なくなり、サーバと端末間で行われる通信データ量が減少し、合成すべき画像も４つから３つに減少するので、サーバでデコード等を行う必要のあるデータ量も少なくなる。
すなわち、共有情報である受信画像を受信する端末は４台であるが、サーバに直接接続される端末は３台となり実質的に減少するので、通信されるデータ量が減少することにより、伝送遅延が少なくなり、通信障害の発生も少なくなり、会議の円滑な進行が可能となる。
【０１４４】
図２８に、第３実施例のサーバ端末間通信状態において、端末ＴＥ１とＴＥ２とが、どちらもスリープモードＭ２となった場合の説明図を示す。
ここでは、同一拠点内のすべての端末（ＴＥ１，ＴＥ２）が、スリープモードＭ２となったので、端末ＴＥ２は、代表端末になったままで、サーバからのストリーミング配信を受ける。
さらに、端末ＴＥ１は、サーバと直接通信は行わず、代表端末ＴＥ２からストリーミング配信を受ける。
端末ＴＥ３とＴＥ４とは、どちらもアクティブモードＭ１であるので、サーバとの間では双方向通信が行われ、各端末の自画像（ＳＤ３，ＳＤ４）がサーバへ送信される。スリープモードＭ２となった端末ＴＥ１とＴＥ２からの自画像（ＳＤ１，ＳＤ２）はサーバへは送信されない。
したがって、サーバから３つの端末（ＴＥ２，ＴＥ３，ＴＥ４）へ送られる受信画像（ＲＤ２，ＲＤ３，ＲＤ４）は、２つの自画像（ＳＤ３，ＳＤ４）が含まれるものである。
端末ＴＥ１へ配信される受信画像ＲＤ１は、端末ＴＥ２が受信した画像ＲＤ２と同じものである。
【０１４５】
この場合、サーバと双方向通信を行う端末は２台となり、サーバからのストリーミング配信を受ける端末は１台となり、サーバと端末間で行う通信のデータ量は、図２７の場合より少なくなる。
また、サーバでデコード等の一連の処理をすべきデータも２つの自画像（ＳＤ３，ＳＤ４）となるので、その処理にかかる負荷も少なくなる。
したがって、サーバから、共有情報である受信画像を受信する端末は４台のままであるが、サーバと直接通信を行う端末は３台となり、さらにそのうちの１台の端末（ＴＥ２）は、一方向通信であるストリーミング受信のみをする端末であるので、伝送遅延や通信障害を低減でき、サーバの負荷も少なくすることができる。
【０１４６】
図２９に、第３実施例のサーバ端末間通信状態において、端末ＴＥ４が、スリープモードＭ２となった場合の説明図を示す。
ここでは、同一拠点に属する２つの端末（ＴＥ１，ＴＥ２）と、もう一台の端末ＴＥ３とが、アクティブモードＭ１であり、それぞれ、サーバと双方向通信を行っているものとする。
端末ＴＥ４のみがスリープモードＭ２となっており、端末ＴＥ４が属する同一グループには、他に端末が存在しないとする。
すなわち、同一拠点（同一グループ）に、１台の端末ＴＥ４しか存在しないとする。この場合、同一グループ内に他に代表端末となるべき端末がないので、端末ＴＥ４は自ら代表端末となり、サーバからストリーミング配信を受ける。端末４は、スリープモードＭ２となっているので、その自画像ＳＤ４を送信することなく、サーバから受信画像ＲＤ４をストリーミング受信する。
したがって、サーバに送信される自画像は、３つの端末（ＴＥ１，ＴＥ２，ＴＥ３）からの自画像（ＳＤ１，ＳＤ２，ＳＤ３）であるので、サーバから送信される合成画像（ＲＤ１〜ＲＤ４）は、この３つの自画像を含むものとなる。
【０１４７】
図２９の場合、同一拠点（同一グループ）内に１つの端末しかない場合において、その端末がスリープモードＭ２となってしまった場合、サーバからのストリーミング配信を受けることにより、受信画像ＲＤ４を表示部に表示させることができる。
また、スリープモードＭ２となった端末ＴＥ４については、双方向通信からストリーミング配信を受ける一方向通信に切りかえられるので、データ伝送量を少なくすることができ、サーバの負荷の軽減と、伝送遅延の減少および通信障害の減少を図ることができる。
【０１４８】
図３０に、第３実施例のサーバ端末間通信状態において、３台の端末ＴＥ１，ＴＥ２，ＴＥ４が、スリープモードとなった場合の説明図を示す。
ここでは、図２８に示したのと同様に、同一拠点内に属するすべての端末（ＴＥ１，ＴＥ２）が、スリープモードＭ２となっているので、一方の端末ＴＥ２が代表端末となり、サーバからストリーミング配信を受ける。他方の端末ＴＥ１は、この代表端末ＴＥ２からストリーミング配信を受ける。
【０１４９】
また、図２９に示したのと同様に、同一拠点に１つの端末しかない端末ＴＥ４もスリープモードＭ２となっているが、図３０では、端末ＴＥ４は、サーバからストリーミング配信を受けるのではなく、代表端末ＴＥ２から、ストリーミング配信を受けるようにした場合を示している。
したがって、代表端末ＴＥ２は、まず、サーバからのストリーミング配信を受け、さらに、２つの端末（ＴＥ１，ＴＥ４）に対して、ストリーミング配信を行っている。
この場合、アクティブモードＭ１である端末は、ＴＥ３のみであるので、サーバに送信される自画像は、端末ＴＥ３からの画像ＳＤ３のみであり、サーバから端末に送信される合成画像（ＲＤ１〜ＲＤ４）は、端末ＴＥ３の自画像ＳＤ３を含むものである。
【０１５０】
この場合、サーバに直接接続される端末は２台となり、そのうち１台の端末（ＴＥ３）が双方向通信を行い、もう１台の端末（ＴＥ２）は、ストリーミング配信を行う一方向通信の端末である。
したがって、共有情報である受信画像（ＲＤ１〜ＲＤ４）は、４台の端末で表示されるが、サーバに直接接続される端末の数は実質的に２台となり、サーバと端末間で通信されるデータ量を減少させることができる。
【０１５１】
また、サーバで受信される自画像も、１台の端末ＴＥ３からのみであり、合成画像を生成するのにかかるサーバの負荷も少なくすることができる。
したがって、図３０の場合、代表端末からストリーミング配信を行う相手の端末を、同一拠点に属する他の端末と、他の拠点に属する端末にすることにより、サーバに直接接続される端末の数をより少なくすることができ、サーバの負荷の減少、伝送遅延の減少、および通信障害の減少を図ることができる。
【０１５２】
図２５に、第３実施例における端末とサーバ間の通信シーケンスの概略説明図を示す。
図２５（ａ）は、端末ＴＥ１がアクティブモードＭ１であり、サーバと端末ＴＥ１とが双方向通信を行っている場合を示している。これは、図８（ａ）と同様である。
図２５（ｂ）は、端末ＴＥ１がスリープモードＭ２となった場合のシーケンスを示している。
ここで、図２６に示すように、端末ＴＥ１と端末ＴＥ２とが同一拠点（同一グループ）に属するものとする。このシーケンスは、図２７の通信状態となる場合を示している。
【０１５３】
まず、スリープモードＭ２となった端末ＴＥ１から、サーバに対して、端末ＴＥ１がスリープモードＭ２になったことを示す端末状態通知を送信する。この通知により、端末ＴＥ１とサーバとの間の通信は双方向通信状態から、片方向通信状態（端末ＴＥ１からの映像、音声データをサーバ側で処理しない状態）にする。
さらに、端末ＴＥ１から、サーバに対して、代表端末を検出してもらうことを要求する情報を送信する（代表端末検出要求の送信）。
この検出要求を受信したサーバは、サーバの記憶部に記憶された端末データベース１４２を利用して、端末ＴＥ１とグループ化できる代表端末があるか否か調べる。図２６の場合、端末ＴＥ１とＴＥ２とが同一拠点にあるので、この２つの端末が、同一グループにグループ化される。また、端末ＴＥ２がアクティブモードＭ１であったとすると、代表端末として端末ＴＥ２が検出される。
【０１５４】
代表端末として端末ＴＥ２を選択することができるので、サーバは端末データベース１４２の中の端末ＴＥ２の代表端末フラグを「ＯＮ」に設定し、端末ＴＥ１に対して、代表端末検出通知を送信する。
この代表端末検出通知では、代表端末とした端末ＴＥ２の装置ＩＤとＩＰアドレスとが通知される。
その後、この通知を受信した端末ＴＥ１は、端末ＴＥ２に対して、ストリーミング要求を送信する。
【０１５５】
ストリーミング要求を受信した端末ＴＥ２は、この要求を検出すると、サーバから送られてきた受信画像ＲＤ２を、端末ＴＥ１に対してストリーミング配信する。
すなわち、端末ＴＥ１は、サーバとの通信は行わず、端末ＴＥ２との間で、画像音声等の情報を含むストリーミング配信による片方向通信を行う（ストリーミング受信）。
これにより、スリープモードＭ２となった端末ＴＥ１は、共有情報を受信することができる。
【０１５６】
図２５（ｃ）は、サーバで代表端末が検出されなかった場合のシーケンスを示している。これはつまり、端末ＴＥ１がスリープモードＭ２となったため、サーバに対して代表端末検出要求を行ったが、サーバで代表端末の検出ができなかった場合である。
このとき、サーバから端末ＴＥ１に対して、代表端末の未検出通知が送信される。
この未検出通知を受けた端末ＴＥ１は、自らを代表端末に設定し、端末ＴＥ１を代表端末に移行したことを示す端末状態通知（代表端末モードへの移行）を、サーバに送信する。
この通知を受けたサーバは、端末ＴＥ１の動作モードが代表端末になったことを検出して、端末ＴＥ１の代表端末フラグを「ＯＮ」に設定する。
その後、サーバは、端末ＴＥ１に対して、ストリーミング配信を行う。これにより、端末ＴＥ１は、サーバからの片方向通信により、共有情報を受信するストリーミング受信をする。
【０１５７】
この図２５（ｃ）は、図２９の状態に相当する。
この場合は、端末ＴＥ１がスリープモードＭ２となったため、サーバとの通信が双方向通信から片方向通信に切りかわるが、さらにその片方向通信が、サーバからのストリーミング配信となる。
ストリーミング受信をする端末ＴＥ１では、所定の通信プロトコルによる双方向通信時のように受信画像のデコードをする必要はなく、その端末ＴＥ１の負荷を少なくすることができる。
【０１５８】
図２１に、第３実施例における端末のグループ化処理のフローチャートを示す。
ここでのグループ化処理は、主として、アイドル状態判定処理と、スリープモード移行処理と、代表端末検出要求処理と、ストリーミング受信処理とからなる。
スリープモードＭ２へ移行した端末は、同一拠点内に代表端末となるべき他の端末が存在する場合には、その代表端末からストリーミング配信を受け、代表端末となるべき端末が存在しない場合は、自らが代表端末となり、サーバからストリーミング配信を受ける。
【０１５９】
図２１のステップＳ１０１において、端末の初期状態がアクティブモードＭ１であったとする。
ステップＳ１０２において、端末状態通知部８５が、現在の端末の動作モード（アクティブモード）を、サーバへ通知する。
ステップＳ１０３において、アイドル状態判定部８１が、自己の端末の状態がアイドル状態となっているか否か判定する（アイドル状態判定処理）。
図２３に、この第３実施例のアイドル状態判定処理の詳細フローチャートを示す。ただし、図２３のフローは、図１０に示したものと同一なので、説明を省略する。
【０１６０】
ステップＳ１０４において、端末がアイドル状態であると判定された場合、ステップＳ１０５へ進み、端末モード切替部８６がスリープモード移行処理を行う。
スリープモードへの移行処理は、上記したステップＳ５と同様の処理である。
ステップＳ１０６において、サーバに対し、現在の動作モードがスリープモードＭ２になったことを示す端末状態通知を、送信する。
【０１６１】
ステップＳ１０７において、代表端末検出要求部８８が、サーバに対して、代表端末検出要求を送信する。
この要求を受信したサーバは、代表端末を検出する処理を行い、代表端末を検出した場合は、代表端末を検出したことを示す通知を、この端末へ送信する。一方、代表端末が検出されない場合は、未検出であったことを示す通知を端末へ送信する。
ステップＳ１０８において、サーバからの通知により、代表端末が検出されたか否か、チェックする。
代表端末が検出されたという通知を受けた場合は、ステップＳ１０９へ進み、そうでない場合はステップＳ１１３へ進む。
【０１６２】
ステップＳ１０９において、ストリーミング要求部８９が、代表端末に対し、ストリーミングの配信を要求する情報を送信する。
この要求情報を受信した代表端末は、ストリーミング配信部９１によって、ストリーミング情報を、その端末に対して配信する。
【０１６３】
ステップＳ１１０において、ストリーミング受信部９０が、代表端末から送られてくるストリーミング情報を受信する。
ステップＳ１１１において、再度ステップＳ１０７と同じ代表端末検出要求処理を行う。これは、今まで代表端末であった端末が、代表端末でなくなっていないか、あるいは代表端末が変更されていないかをチェックするための処理である。
ステップＳ１１２において、サーバからの通知により、代表端末が検出された場合は、処理を終了し、そうでない場合は、ステップＳ１１３へ進む。
【０１６４】
ステップＳ１１３において、他に代表端末となるべき端末がなかったので、自らが代表端末に移行する処理を行う。すなわち、その端末の動作モードを、スリープモードから、代表端末モードに移行する。
代表端末となった端末は、他の端末に対して、ストリーミング配信を行える端末となる。また、代表端末となった端末は、サーバからの片方向通信により、ストリーミング情報を受信する。
【０１６５】
ステップＳ１１４において、サーバに対して、自端末の動作モードが代表端末モードになったことを示す端末状態通知を、送信する。
ステップＳ１１５において、サーバから送られてくるストリーミング情報を受信するストリーミング受信を行う。
ストリーミング受信された情報は、代表端末の表示部に表示するとともに、グループ化された同一拠点内の他の端末に対して、その受信情報を、ストリーミング配信する。
【０１６６】
図２２に、第３実施例において、代表端末となった端末のストリーミング配信処理の概略フローチャートを示す。
ステップＳ１２１において、他の端末から、ストリーミング配信要求を受信したか否か、チェックする。
受信した場合は、ステップＳ１２２へ進み、要求を送信してきた端末に対し、受信したストリーミング情報のストリーミング配信を行う。
【０１６７】
図２４に、第３実施例のサーバにおける端末状態検出制御処理のフローチャートを示す。
ステップＳ１３１において、端末状態判断部１６２が、端末から端末状態情報を受信したか否かチェックする。
受信した場合は、ステップＳ１３２へ進み、そうでない場合はステップＳ１３１をループする。
ステップＳ１３２において、端末から受信した端末状態が、アクティブモードか否か、チェックする。
アクティブモードの場合、ステップＳ１３３へ進み、そうでない場合は、ステップＳ１３４へ進む。
ステップＳ１３３において、通信方法切替部１６３が、サーバと端末との通信状態を、アクティブモードで行われる双方向通信状態に切り替える。
ステップＳ１３４において、受信した端末状態がスリープモードか否か、チェックする。
スリープモードの場合、ステップＳ１３５へ進み、そうでない場合、ステップＳ１３９へ進む。
【０１６８】
ステップＳ１３５において、代表端末検出部１６９が、代表端末検出処理を行う。
ここでは、記憶部１４１の端末データベース１４２をチェックし、端末が属する拠点ＩＤ１４４と同一の拠点ＩＤを持つ他の端末があるか否かチェックする。
同一拠点ＩＤを持つ端末が他に存在する場合、その端末がアクティブモードであれば、その端末を代表端末に設定し、代表端末が検出されたと判断する。
すなわち、その端末の代表端末フラグ１５０を「ＯＮ」にする。
また、同一拠点ＩＤを持つ端末の中に、すでに代表端末フラグ１５０が「ＯＮ」となっているものがあれば、代表端末が検出されたと判断する。
さらに、同一拠点ＩＤを持つ端末が、他に１つもない場合は、代表端末がなかったと判断する。
【０１６９】
ステップＳ１３６において、代表端末が検出された場合、ステップＳ１３８へ進み、そうでない場合、ステップＳ１３７へ進む。
ステップＳ１３８において、端末データベース１４２から、代表端末の装置ＩＤとＩＰアドレスを読み出し、代表端末検出通知を作成し、スリープモードとなった端末に対して、送信する。
ステップＳ１３７において、代表端末が未検出であったことを示す情報を、スリープモードとなった端末へ送信する。
【０１７０】
ステップＳ１３９において、受信した端末状態が、代表端末モードであるか否か、チェックする。
代表端末モードであれば、ステップＳ１４０へ進み、そうでない場合は、処理を終了する。
ステップＳ１４０において、代表端末モードになっている端末を、代表端末として設定する処理を行う。具体的には、端末データベース１４２の中のその端末に対する代表端末フラグ１５０を、「ＯＮ」に設定する。
ステップＳ１４１において、ストリーミング配信部１７０は、代表端末となっている端末に対し、デコード等の処理をした後の映像や音声などの共有情報を、ストリーミング配信する。
なお、端末の代表端末フラグ１５０は、初期状態では、すべて「ＯＦＦ」とし、図示していないが、たとえば、端末の電源切断等の理由で代表端末でなくなった場合は、その端末の代表端末フラグを「ＯＦＦ」に設定する。
【０１７１】
以上が、第３実施例における端末とサーバの処理内容であるが、サーバに接続された端末数が５台以上の場合や、同一拠点（同一グループ）に属する端末の数が３台以上の場合もあるので、グループ化のパターンは、図２６から図３０に示したものに限るものではなく、他のパターンも考えられる。
ただし、いずれの場合も、グループ化された端末群の中に、１つの代表端末を設定し、その代表端末のみをサーバに直接接続可能な端末とし、サーバから双方向通信やストリーミング配信を受けるようにしているので、サーバに接続される実質的な端末の数を減少させることができ、接続端末数の減少によって、伝送遅延の減少と、通信障害の減少と、サーバの負荷の軽減を図ることができる。
【符号の説明】
【０１７２】
１ サーバ
２ 情報端末（端末）
１１ 入力部
１２ キーボード
１３ マウス
１４ タブレット
１５ 人検知センサ
１６ 入力処理部
２１ 映像入力部
２２ カメラ
２３ 映像処理部
３１ 表示部
３２ ディスプレイ
３３ 表示処理部
４１ 音声入力部
４２ マイク
４３ 入力音声処理部
４５ 音声出力部
４６ スピーカ
４７ 出力音声処理部
５１ 通信部
５２ 通信暗号部
５３ 通信復号部
５５ 認証部
６１ 記憶部
６２ 認識データベース
６３ ユーザ名
６４ 音声特徴データ
６５ 顔画像特徴データ
６６ 入力映像
６７ 入力音声
７１ 信号処理部
７２ 映像符号化部
７３ 映像復号化部
７４ 音声符号化部
７５ 音声復号化部
８０ 制御部
８１ アイドル状態判定部
８２ 時間計測部
８３ 入力信号検知部
８４ 人物認識部
８５ 端末状態通知部
８６ 端末モード切替部
８７ 端末モード変更受付部
８８ 代表端末検出要求部
８９ ストリーミング要求部
９０ ストリーミング受信部
９１ ストリーミング配信部
１０１ 入力部
１０２ キーボード
１０３ マウス
１０４ タブレット
１０５ 入力処理部
１１１ 表示部
１１２ ディスプレイ
１１３ 表示処理部
１２１ 通信部
１２２ 通信暗号部
１２３ 通信複号部
１２５ 認証部
１３１ ＭＣＵ部
１３２ 映像ミキシング部
１３３ 映像リサイズ部
１３４ 音声ミキシング部
１４１ 記憶部
１４２ 端末データベース
１４３ 装置ＩＤ
１４４ 拠点ＩＤ
１４５ ＩＰアドレス
１４６ ユーザデータベース
１４７ ユーザＩＤ
１４８ メールアドレス
１４９ 認識データベース
１５０ 代表端末フラグ
１５１ 信号処理部
１６１ 制御部
１６２ 端末状態判断部
１６３ 通信方法切替部
１６４ 端末モード制御部
１６５ アイドル状態判定部
１６６ 時間計測部
１６７ 入力信号検知部
１６８ 人物認識部
【技術分野】
【０００１】
この発明は、情報共有システムに関し、特に、ネットワークを介して接続された複数の情報端末間で、共通の映像や音声等の情報を伝送する情報共有システムに関する。
【背景技術】
【０００２】
従来からネットワークを介して、複数の情報端末間で映像や音声等の情報の伝送を行う通信システムや、専用のサーバ等を介して遠隔地にある複数の情報端末間で音声会議やビデオ会議を行う通信システムが利用されている。
たとえば、従来のビデオ会議システムでは、多地点接続装置（ＭＣＵ：Ｍｕｌｔｉ−ｐｏｉｎｔ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）および、ＭＣＵ機能を有したサーバに、各地点ごとに設置された情報端末や参加者ごとの情報端末が、インターネット，ＬＡＮ，あるいは専用回線等のネットワークを介して接続され、情報端末毎に入力された映像，音声，文書などの情報がＭＣＵに集積され、ＭＣＵにおいて各情報のデコード（復号化），ミキシング（合成），エンコード（符号化）等の一連の処理が行われ、各情報端末に共通の情報として配信される。
一般的に、各情報端末を利用している会議への参加者は、共通の映像を見て、共通の音声を聞きながら会議を行うものとする。
【０００３】
また、利用者が自ら遠隔会議装置（情報端末）の主電源を切断する操作をすることなく、動画像符号化機構の動き検出機構から動きベクトル値を取得して利用者の退席を判定し、自動的に安全に回線及び電源を切断することのできる自動回線切断機能付遠隔会議システムが提案されている（特許文献１参照）。
【０００４】
また、ユーザの在席または退席に係る情報（プレゼンス情報）を他のユーザの通信端末で表示するプレゼンスサービスを有する通信システムにおいて、ユーザが自己のプレゼンス情報の設定や変更を忘れることがあることを考慮して、ユーザの通信端末の周囲で撮影された撮影画像又はその通信端末の周囲で取得された音声を、プレゼンス情報として相手ユーザの通信端末へ送信し、相手ユーザのプレゼンス状態を正確に把握するようにしたプレゼンス情報処理端末（特許文献２参照）や、プレゼンス情報のユーザによる設定操作だけでなく、マイクにより集音される音に基づいてユーザの在席／退席を判定して、プレゼンス情報を更新する通信端末が、提案されている（特許文献３参照）。
【０００５】
また、サーバ装置とデータの送受信を行う通信端末装置において、その通信端末装置及び利用者の状態情報を示すプレゼンス情報が特定の条件に合致した際に、端末装置の動作の変更及び通信データの加工を行う機能を備え、プレゼンス情報を基にして端末装置側で動作変更やデータの加工処理を行うことにより、サーバ側の負荷を軽減することのできる通信システムが提案されている（特許文献４参照）。
また、この特許文献４には、サーバ装置が、通信端末装置から送信されたプレゼンス情報を使用して、設定された特定条件（たとえば、特定地域内にある端末）に適合する端末群情報を収集して、端末装置の新規グループを自動的に作成する通信システムが開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平８−３３６１２２号公報
【特許文献２】特開２００４−２１４９３４号公報
【特許文献３】特開２００７−１２９４１１号公報
【特許文献４】国際公開ＷＯ２００６／０５４７７８
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、従来のＭＣＵを利用した多地点会議システムでは、ＭＣＵに同時に接続される情報端末の数が増加すればするほど、ＭＣＵと各情報端末間の通信回線で送受信されるトラフィックが増加するので、情報伝送の遅延や、ノイズの発生による通信エラー等の通信障害が起こりやすくなり、円滑な会議の進行ができなくなる場合もある。
さらに、ＭＣＵでは、接続される情報端末が増加すればするほど、エンコード（符号化）、デコード（複号化）等の処理をすべき情報量が増加するので、ＭＣＵにかかる負荷が大きくなり、それにより各情報端末への情報伝送に遅延をもたらすことになる。
【０００８】
また、ＭＣＵにおいて、情報端末から送信されてくる在席または退席を示す情報を基にして、各端末の動作管理や、通信回線の接続や切断処理を一元的に一括管理する場合は、利用者は一時的に中座しただけなのに、ＭＣＵによって通信回線を切断されてしまう場合や、その利用者の情報端末への電源供給が停止されてしまう場合もある。
このような場合、利用者は、会議に再び参加するためには、回線接続処理や電源投入等の一連の操作をやり直す必要があるので、利用者にとって不便であり、操作負担が大きかった。
【０００９】
また、特許文献１，２および３に記載されたシステム等においても、端末の動作制御が自動的に行われ、あるいはプレゼンス状態が正確に把握できたとしても、利用者にとって意図しない通信回線や電源の切断が行われる場合もあり、利用者が自ら再起動操作等を行う必要があった。
また、いずれの特許文献に開示された技術も、ネットワークに接続される情報端末の数が増加した場合において、伝送遅延や通信障害等の問題を軽減させることを目的とするものではなく、そのような軽減措置については考慮されていない。
【００１０】
そこで、この発明は、以上のような事情を考慮してなされたものであり、サーバに接続されている複数の情報端末のうち、実質的にサーバと情報通信を行う情報端末の数を抑制して、情報伝送の遅延および、通信エラー等の通信障害の発生の減少、サーバが処理する情報量の低減によるサーバの負荷の軽減を図り、さらに情報端末の動作状態の段階的な制御を行うことによる情報端末側の利用者の操作負担の軽減を図ることのできる情報共有システムを提供することを課題とする。ここで、サーバとは、ビデオ会議の制御機能のうち、少なくともＭＣＵ機能を有する装置を指すこととする。
【課題を解決するための手段】
【００１１】
この発明は、サーバと、複数の情報端末とがネットワークを介して接続され、前記情報端末において入力された情報をサーバに送信し、前記サーバが、各情報端末から送信された情報を用いて共有情報を生成し、前記共有情報を前記情報端末へ配信する情報共有システムであって、前記情報端末が、その情報端末を利用者が使用状態であることを示す状態情報を生成する情報入力部と、前記情報入力部によって生成された状態情報に基づいて、情報端末が使用されていない可能性のあるアイドル状態であることを判定するアイドル状態判定部と、アイドル状態であることが判定された場合に、情報端末の現在の動作状態に対応して、段階的に動作状態を変更する端末モード切替部と、情報端末の現在の動作状態を、サーバへ送信する端末状態通知部と、アイドル状態であると判定された場合に、サーバに、同一拠点内の代表端末の検出を要求する検出要求を送信し、かつサーバから代表端末の情報を受信する代表端末検出要求部と、アイドル状態であると判定された場合に、サーバあるいは前記代表端末から配信されるストリーミング情報を受信するストリーミング受信部とを備え、前記サーバが、前記情報端末から送信されてきた動作状態に基づいてその情報端末との通信方法を切り替える通信方法切替部と、第１の情報端末から代表端末の検出要求を受信した場合に、前記第１の情報端末と同一の拠点に属する情報端末の中から代表端末を検出し、その代表端末の情報を前記第１の情報端末に送信する代表端末検出部と、情報端末にストリーミング情報を送信するストリーミング配信部とを備え、前記情報端末の動作状態に従って、各情報端末ごとにサーバと各情報端末との間の通信状態を変更させることを特徴とする情報共有システムを提供するものである。
【００１２】
これによれば、アイドル状態であると判定された情報端末は、サーバあるいは同一拠点内の代表端末から配信されるストリーミング情報を受信する一方向的な通信状態となるので、サーバと情報端末間の通信状態を情報伝送量の少ない状態とすることができ、さらに情報伝送量が減少することにより伝送遅延の減少と通信障害の発生の減少を図り、サーバの負荷を軽減することができる。
また、情報端末の動作状態を段階的に変更しているので、たとえば、変更後の動作状態から変更前の動作状態への復帰のための操作を比較的容易にすることができ、利用者の操作負担を軽減でき、その復帰を短時間で行うことができる。
【００１３】
また、前記代表端末検出部が、前記代表端末を検出できた場合に、前記第１の情報端末のストリーミング受信部は、検出された代表端末から、ストリーミング情報を受信することを特徴とする。
これによれば、アイドル状態である第１の情報端末は、代表端末からストリーミング情報を受信するので、サーバから第１の情報端末へ直接映像等の共有情報が送信されることがなく、より伝送遅延の減少と通信障害の発生を減少させ、サーバの負荷もより軽減させることができる。
【００１４】
また、前記代表端末検出部が、前記第１の情報端末と同一拠点に属する代表端末を検出できなかった場合、代表端末の未検出通知を、前記第１の情報端末に送信し、前記第１の情報端末が、前記未検出通知を受信した場合、前記第１の情報端末の端末状態通知部が、自己が代表端末となることをサーバに通知し、その後、ストリーミング受信部は、サーバから、ストリーミング情報を受信することを特徴とする。
これによれば、アイドル状態である第１の情報端末は、サーバからストリーミング情報を一方向的に受信するので、サーバの負荷の軽減と、伝送遅延の減少および通信障害の減少を図ることができる。
【００１５】
この発明において、前記同一拠点内の代表端末は、前記第１の情報端末と同一グループに属する情報端末として予め設定された情報端末の中から、選択されることを特徴とする。
また、前記同一グループに属する情報端末は、同一の拠点ＩＤを持つ情報端末、同一ルータに接続されそのルータの配下のネットワークに属する情報端末、および同一ドメイン内の情報端末のいずれかとしてもよい。
さらに、前記代表端末は、前記第１の情報端末と同一の拠点ＩＤを持ち、アイドル状態ではない情報端末とすることができる。
【００１６】
また、前記情報端末の動作状態は、サーバと双方向通信を行う第１モード、サーバから音声および映像を含む情報を受信して片方向通信を行う第２モード、情報端末の主機能を停止してサーバとの通信を中止した状態の第３モード、情報端末の電源を切断した状態の第４モードを含み、前記アイドル状態判定処理により、アイドル状態であることが検出されるごとに、情報端末の動作状態を前記第１モードから第４モードの順に段階的に変更させることを特徴とする。
【００１７】
ここで、第１モードにおいて、サーバと情報端末間で、映像および音声の双方向通信が行われるのに対し、第２モードでは、サーバから情報端末の方向へ、映像および音声の片方向送信が行われるので、第１モードよりも伝送される情報量は少ない。第３および第４モードでは、サーバと情報端末間の通信が中止されているので、サーバとその情報端末間で伝送される情報はなくなる。したがって、アイドル状態の検出により、情報端末の動作状態を第１モードから第２モード、第３モード、第４モードのように段階的に変更していけば、情報端末とサーバ間の情報伝送量が減少する方向に動作状態を変更できるので、サーバに接続される実質的な情報端末数を減少させることができる。これにより、サーバおよび情報端末における映像および音声のエンコード、デコードといった処理負荷の軽減だけでなく、通信伝送量の削減に伴ない、伝送遅延や、通信障害の発生を減少させることができる。
また、アイドル状態を検出するごとに、第１モードから第４モードへ順に、情報端末の動作状態を段階的に変更するので、変更前の動作状態への復帰が、アイドル状態を検出したときにいきなり情報端末の電源を切断してしまう場合よりも、より短時間に、より容易な操作で可能となり、利用者の負担を軽減できる。
【００１８】
また、前記情報入力部は、利用者の操作による入力信号を入力する入力部と、カメラにより撮影された映像を入力する映像入力部と、マイクから音声を入力する音声入力部とを備え、前記入力信号、入力映像および入力音声を用いて、前記状態情報を生成することを特徴とする。
また、前記アイドル状態判定部は、所定の設定時間中に継続して、前記入力信号の入力がないこと、前記入力音声の入力がないこと、および前記入力映像に所定の変化がないことのいずれもが検出された場合、その情報端末が使用されていない可能性があるアイドル状態であると判定することを特徴とする。
【００１９】
ここで、利用者が情報端末を使用していることを示す状態情報として、利用者の操作の有無と利用者の音声の入力の有無と、利用者を撮影した映像の変化の有無を利用する。
たとえば、利用者がマウスを動かした場合、マウスを動かしたことを示す入力信号により、入力信号があったことを示す状態情報が生成される。
そして、利用者の操作入力、利用者の音声入力および映像変化という３つの情報を総合的に利用して、利用者がその情報端末を使用していない可能性があると判定するので、利用者の不在の判断を、より確実にすることができる。
【００２０】
さらに、利用者の音声特徴データと、利用者の顔の特徴を示す顔画像特徴データを含む認識データベースを記憶した記憶部と、前記入力音声と音声特徴データとを用いた音声認識と、前記入力映像と顔画像特徴データとを用いた画像認識とを利用して、利用者を特定する人物認識を行う人物認識部とをさらに備え、前記アイドル状態判定部は、所定の設定時間中に継続して、前記人物認識部により人物認識が失敗した場合に、その情報端末が使用されていない可能性があるアイドル状態であると判定することを特徴とする。
これにより、利用者を特定したアイドル状態の判定を行うので、利用者の不在の判断をより確実に行うことができる。
【００２１】
さらに、この発明は、サーバと、複数の情報端末とがネットワークを介して接続され、前記情報端末において入力された情報をサーバに送信し、前記サーバが、各情報端末から送信された情報を用いて共有情報を生成し、前記共有情報を前記情報端末へ配信する情報共有システムの情報共有方法であって、前記情報端末が、その情報端末を利用者が使用状態であることを示す状態情報を生成する情報入力ステップと、前記状態情報に基づいて、情報端末が使用されていない可能性のあるアイドル状態であるか否かを判定するアイドル状態判定ステップと、アイドル状態であると判定された場合に、情報端末の現在の動作状態に対応して、段階的に所定の動作状態に変更する端末モード切替ステップと、情報端末の現在の動作状態を、サーバへ送信する端末状態通知ステップと、アイドル状態であると判定された第１の情報端末が、サーバに、同一拠点内の代表端末の検出を要求する検出要求送信ステップと、前記サーバが、前記代表端末の検出要求を受信した場合に、検出要求を送信してきた前記第１の情報端末と同一の拠点に属する情報端末の中から代表端末を検出するステップと、検出された代表端末の情報を前記第１の情報端末に送信するステップと、前記第１の情報端末が、受信した代表端末の情報を用いて、その代表端末に、ストリーミング配信を要求する配信要求送信ステップと、前記代表端末が、受信した配信要求に基づいて、前記第１の情報端末に、ストリーミング情報を送信するステップとを備えたことを特徴とする情報共有方法を提供するものである。
また、コンピュータに、前記したような情報共有方法の各ステップを実行させるための情報共有システムのプログラムを提供するものである。
【発明の効果】
【００２２】
この発明によれば、アイドル状態であると判定された情報端末は、サーバあるいは同一拠点内の代表端末から配信されるストリーミング情報を受信する一方向的な通信状態となるので、サーバと情報端末間の通信状態を情報伝送量の少ない通信状態とすることができ、伝送遅延を減少させ、通信障害の発生を減少させることができ、さらにサーバが共有情報を生成するときの負荷を減少させることができる。
また、情報端末の動作状態を段階的に変更させるので、変更後の動作状態から変更前の動作状態へ復帰するための利用者の操作負担が軽減でき、その復帰にかかる時間を短縮することができる。
【図面の簡単な説明】
【００２３】
【図１】本発明の情報共有システムの一実施例の概略構成図である。
【図２】情報端末の第１実施例の構成ブロック図である。
【図３】サーバの第１実施例の構成ブロック図である。
【図４】サーバ端末間通信状態（アクティブモード）の一実施例の説明図である。
【図５】サーバ端末間通信状態（スリープモード）の一実施例の説明図である。
【図６】サーバ端末間通信状態（ログオフモード）の一実施例の説明図である。
【図７】サーバ端末間通信状態（シャットダウンモード）の一実施例の説明図である。
【図８】サーバと端末間の通信シーケンスの一実施例の説明図である。
【図９】第１実施例の端末におけるモード移行処理のフローチャートである。
【図１０】第１実施例の端末におけるアイドル状態判定処理のフローチャートである。
【図１１】第１実施例のサーバにおける端末状態判断制御処理のフローチャートである。
【図１２】記憶部に格納されるデータベースの一実施例の説明図である。
【図１３】情報端末の第２実施例の構成ブロック図である。
【図１４】サーバの第２実施例の構成ブロック図である。
【図１５】第２実施例のサーバにおけるモード移行制御処理のフローチャートである。
【図１６】第２実施例のサーバにおけるアイドル状態判定処理のフローチャートである。
【図１７】第２実施例の端末における端末状態制御処理のフローチャートである。
【図１８】情報端末の第３実施例の構成ブロック図である。
【図１９】サーバの第３実施例の構成ブロック図である。
【図２０】第３実施例で用いられる端末データベースの一実施例の説明図である。
【図２１】第３実施例の端末におけるグループ化処理のフローチャートである。
【図２２】第３実施例の代表端末のストリーミング配信処理のフローチャートである。
【図２３】第３実施例の端末におけるアイドル状態判定処理のフローチャートである。
【図２４】第３実施例のサーバにおける端末状態検出制御処理のフローチャートである。
【図２５】第３実施例のサーバと端末間の通信シーケンスの説明図である。
【図２６】第３実施例のサーバ端末間通信状態（アクティブモード）の説明図である。
【図２７】第３実施例のサーバ端末間通信状態（スリープモード）の説明図である。
【図２８】第３実施例のサーバ端末間通信状態（スリープモード）の説明図である。
【図２９】第３実施例のサーバ端末間通信状態（スリープモード）の説明図である。
【図３０】第３実施例のサーバ端末間通信状態（スリープモード）の説明図である。
【発明を実施するための形態】
【００２４】
以下、図面を使用して本発明の実施の形態を説明する。なお、以下の実施例の記載によって、この発明が限定されるものではない。
＜本発明の情報共有システムの構成＞
図１に、本発明の情報共有システムの一実施例の概略構成図を示す。
ここでは、映像，音声，文書などの情報を共有して、複数の情報端末間で画像音声等による会議を行う情報共有システム（以下、会議システムとも呼ぶ）について、説明する。
【００２５】
図１において、情報共有システムは、主として、１台のサーバ１と、複数台の情報端末（以下、会議端末、または単に端末とも呼ぶ）２とから構成される。
サーバ１と、各情報端末２とは、ネットワークを介して接続される。
サーバ１は、従来の会議システムでも利用されている会議制御機能のうち、少なくとも多地点接続装置（ＭＣＵ）と同等の機能を有する装置であり、主として、接続された端末の状態監視、接続制御、各種情報の通信制御、映像や音声の符号化、映像や音声の復号化処理、ユーザ認証、機器認証、通信暗号化等を行うものである。
また、端末２は、会議に参加する利用者が在席する部屋（オフィスや会議室など）に設置される装置であり、主として、映像および音声による利用者自身の認識処理、端末の動作状態や入力操作の確認処理、入力される各種情報の加工変換や通信制御処理を行うものである。
【００２６】
情報端末２では、会議に必要な情報が入力され、入力された情報はサーバに送信される。入力される情報としては、後述するが、主として、キーボードやマウス等の入力信号、マイクからの入力音声、カメラからの入力映像である。これらの入力された情報は、符号化（エンコード）処理をした後、サーバに送信してもよい。また、通信経路における機密性、秘匿性を考慮し、暗号化処理を行ってもよい。
サーバ１は、上記のようなサーバに送信された情報を用いて共有情報を生成し、この共有情報を、各情報端末へ配信する。
【００２７】
サーバ１と端末２（ＴＥ１〜ＴＥｎ）との接続は、たとえば有線の通信ケーブルによって直接接続してもよく、また、いわゆる無線ＬＡＮ等の無線通信方式によって接続してもよい。
また、各種のネットワーク（ＬＡＮ（Ｎ１），インターネット（Ｎ２），専用通信網（Ｎ３）など）を介して、サーバ１と端末２とを接続してもよい。
ある端末（ＴＥ１）を利用する利用者が会議に参加する場合、その端末ＴＥ１とサーバ１との間の通信回線を接続し、リンクを確立させた後、端末ＴＥ１に付属したカメラやマイクからその利用者の画像や音声あるいは会議に必要な文書や図面データなどを、サーバ１に送信する。
このとき、通信路における伝送量軽減や、リアルタイム（低遅延）通信を行うために、所定の規格のコーデック（例えば、映像であればＭＰＥＧ４、Ｈ．２６３、Ｈ．２６４、音声であればＧ．７１１、Ｇ．７２２、Ｇ．７２９等）を利用して、送信されるデータ量を圧縮符号化する処理（エンコード）が行われる。
【００２８】
サーバ１では、端末ＴＥ１から送られてきた映像，音声等の情報と、その他の端末２（ＴＥ２，…ＴＥｎ）から送られてきた同様の情報を復号化（デコード）した後、合成（ミキシング）する処理を行う。この合成処理を行った情報（合成情報）が、共有情報となる。共有情報は、現在接続が確立されている複数の端末２に向かって、配信される。
サーバ１では、受信した複数の映像のミキシングを行う前に、各端末２から送られてきた映像の復号化処理（デコード）を行い、さらに画像サイズの調整（リサイズ）を行い、その後１つの共有情報として配信するために複数の映像を合成する処理が行われる。
たとえば、４人の利用者が会議に参加していたとすると、４台の端末２から送信されてきた各利用者の人物画像の映像データをそれぞれデコードし、１画面に分割表示できるようにリサイズし、４つの映像を合成（ミキシング）する。
さらに、ミキシングした後の合成映像は、サーバで符号化処理（エンコード）が行われた後、共有情報としてサーバ１から端末２へ送信される。
【００２９】
このようなミキシングされた共有情報が送信されてきた各端末２では、受信情報の復号化処理（デコード）が行われ、その端末に付属した表示装置やスピーカから、画像や音声が出力される。
たとえば、現在接続が確立されている端末２が４台であれば、ミキシングされた後の共有情報は、サーバ１から時分割多重化処理等を用いてリアルタイムで、４つの端末にそれぞれ配信される。
【００３０】
しかし、接続が確立されている端末数がさらに増加した場合、たとえばその端末数が２０台の場合、円滑に会議を進行させるためには、２０台のそれぞれの端末２で、同じようにリアルタイムで、共有情報の画像や文書を見て、共有情報の音声を開く必要があるので、サーバ１はより高速に情報の配信処理を行う必要がある。
【００３１】
一般に、通信回線として電話回線を用いたＡＤＳＬやＩＳＤＮによる通信、光ファイバーを用いたＦＴＴＨによる通信、無線通信、その他のより高速の専用回線を用いた通信が利用できるが、いずれも回線そのものの通信速度や一定時間に伝送できる通信量に限界があるので、円滑な会議の進行にほとんど問題がなく、情報伝送の遅延が問題とならずに、リアルタイムで情報配信ができる最大端末数も、利用する通信回線の太さ（通信帯域）や、通信に用いられる映像や音声のデータ量および、端末そのもののＣＰＵ性能等によって上限値が決まってくる。
【００３２】
この発明は、情報共有システムの会議に参加可能な端末が非常に多数存在する場合でも、サーバ１に対して同時に接続が確立され、サーバから直接的に共有情報の配信が行われる端末の実質的な数をできるだけ減少させて、リアルタイム性を保持した情報の配信を行い、円滑な会議の進行をさまたげることのないようにする。
【００３３】
この発明では、上記のようなサーバに接続される実質的な端末数の減少は、次のような処理によって実現させることを特徴とする。
（１）端末ごとの段階的動作制御
実質的に端末が使用されていない可能性のある動作状態（以下、アイドル状態と呼ぶ）であると判定された場合、その端末の動作状態のモードを、段階的に変更し、その端末とサーバとの通信状態を所定の順序で切り替え、最終的に端末の電源を切断する。
ここでは、端末の動作状態に従って、サーバと各端末との通信状態が動的に変更される。
【００３４】
（２）端末のグループ化によるサーバから見た接続端末数の減少化
同一ルータに接続されたネットワーク上に複数の端末が存在する場合など、複数の端末が属するグループを設定し、そのグループの中の１台の端末を代表端末に設定し、サーバと直接通信する端末を代表端末のみに制限することにより、サーバと直接共有情報の通信を行う端末の数を減少させる。
代表端末以外のグループ内に属する端末は、共有情報を受信した代表端末から、その受信情報を配信してもらうようにする。
【００３５】
上記（１）の処理において、端末がアイドル状態であるか否かの判定は、たとえば、画像による人物認識や音声認識による利用者自身に関する情報の取得や、端末の動作状態（電源のＯＮ／ＯＦＦ）や入力操作の有無等の検出により行うことができる。
また、アイドル状態の判定処理は、サーバ側又は端末側のどちらで行ってもよい。
【００３６】
さらに、（１）の処理において、段階的に変更される端末の動作状態のモード（動作モードとも呼ぶ）とは、たとえば、順に、アクティブモード，スリープモード，ログオフモード，およびシャットダウンモード（電源切断状態）が考えられる。ただし、この４つのモードは例示であり、これに限定されるものではない。
前記した第１モードがアクティブモードに相当し、第２モードがスリープモードに相当し、第３モードがログオフモードに相当し、第４モードがシャットダウンモードに相当する。
たとえば、第２モード（スリープモード）の動作状態のときに、アイドル状態であると判定された場合、第３モード（ログオフモード）に切り替え、第３モードのときにアイドル状態であると判定された場合、第４モード（シャットダウンモード）に切り替える。
【００３７】
ここで、アクティブモードとは、その端末に搭載されたすべての機能が実行可能な状態を意味し、たとえば、サーバと映像および音声の双方向通信を行う状態を意味する。
スリープモードとは、サーバからの映像および音声の受信のみ（片方向通信）を行っている状態を意味し、その端末で実行可能な機能を実行するためには、利用者がマウスやキーボード等の端末操作等を行ったり、利用者が端末の前にいることでカメラ入力画像を変化させたり、利用者が発言することでマイク入力音声を発生させることで、アイドルモードからアクティブモードに移行させる必要がある。
【００３８】
また、ログオフモードとは、端末の画面上に利用者へのログイン操作を促す画面が表示されるような状態を意味し、たとえば、利用者がログイン認証をしなければ、その端末の機能を実行させることができないような状態を意味する。
また、ログオフモードでは、情報端末の主機能が停止した状態で、サーバとの通信を中止した状態である。
シャットダウンモードとは、端末の電源が切断されている状態を意味し、端末を動作させるためにたとえば、利用者が電源ボタンを押し、端末にインストールされているＯＳ等のソフトウェアを起動させなければならない状態を意味する。
以下の実施例では、アイドル状態が検出されるごとに、情報端末の動作状態を、第１モード（アクティブモード）から、第２モード（スリープモード）、第３モード（ログオフモード）、第４モード（シャットダウンモード）の順に、段階的に変更させるようにする。
【００３９】
ここで、上記４つのモードは、利用者が所定の機能を実行させるために、行わなければならない操作手順と、実行できるようになるまでの時間が異なる。
利用者の操作に関して、アクティブモードが最も容易であるのに対し、シャットダウンモードが最も多くの操作手順を必要とし、利用者が所望の機能を実行させるようになるまでに最も時間がかかる。
このように、４つのモードを設けたのは、所定の機能を実行させるアクティブモードに端末を復帰させるのに必要な利用者の操作負担をできるだけ少なくするように考慮したためである。
【００４０】
たとえば、従来のように利用者が不在であることを確認したときに、一律に端末の電源を切断するようにした場合において、その不在は一時的なものであって利用者は会議に参加する意思がまだある場合でも、利用者は端末の電源投入から始めて一連の操作をすべて実行しなければならず、操作負担が大きく、また、なかなか会議に復帰することができないことになる。
したがって、利用者の不在が確認された場合は、サーバとの間の情報通信は一旦中断し、伝送遅延や通信障害の発生が少なくなるようにするが、その不在が会議への不参加（退席）によるものと確実に認識できない場合は、たとえば端末を単にスリープモードにするようにすれば、比較的容易な操作でアクティブモードに復帰できるので、利用者の操作負担は軽く、短時間で会議へ復帰できるようになる。
以下に、上記（１）および（２）の処理を実現する構成および具体的な処理内容の実施例について説明する。
【００４１】
＜情報端末の構成＞
図２に、情報端末の第１実施例の構成ブロック図を示す。
情報端末２（ＴＥ）は、主として、入力部１１，映像入力部２１，表示部３１，音声入力部４１，音声出力部４５，通信部５１，認証部５５，記憶部６１，信号処理部７１，および制御部８０から構成される。
【００４２】
ここで、上記した情報入力部は、入力部１１と、映像入力部２１と、音声入力部４１とを含むものに相当し、情報端末を利用者が使用状態であることを示す状態情報を生成する部分である。
入力部１１は、キーボード１２，マウス１３，タブレット１４などのポインティングデバイスに加え、人検知センサ１５を備え、これらの入力を受信し、制御部８０へ送信するための信号に変換する入力処理部１６とを備える。
人検知センサ１５は、たとえば、熱感知センサ，赤外線センサ，超音波センサなどを用いることができる。人検知センサの代わりに、後述するカメラ２２やマイク４２の入力信号を元に端末の前に人がいるかどうかを検知するようにしても良い。
入力部１１からは、主として利用者の操作による入力信号が入力され、この入力信号が、状態情報の生成に用いられる。たとえば、この入力信号が入力されている場合、情報端末が使用状態であることを示す状態情報が生成される。
【００４３】
映像入力部２１は、端末の近傍の映像や、端末の前にいる会議に参加している者（利用者）の映像を入力する部分であり、カメラ２２と、カメラで撮影された映像をデジタル信号に変換する映像処理部２３とを備える。入力された映像６６は、記憶部６１に一時記憶される。この入力映像６６も、上記した状態情報の生成に用いられる。
【００４４】
表示部３１は、利用者の自画像を表示したり、会議に参加している他者の人物画像等を表示する部分であり、ＬＣＤ，ＣＲＴなどのディスプレイ３２と、ディスプレイ３２へ表示させる表示信号を生成する表示処理部３３とを備える。
【００４５】
音声入力部４１は、端末ＴＥの近傍の音声を入力する部分であり、マイク４２と、マイクから入力された音声をデジタル信号に変換する入力音声処理部４３とを備える。入力された音声６７は、記憶部６１に一時記憶される。
この入力音声６７も、上記した状態情報の生成に用いられる。
【００４６】
音声出力部４５は、スピーカ４６，出力音声処理部４７とを備え、たとえば、サーバから送られてきた音声を、スピーカから出力する部分である。
【００４７】
通信部５１は、サーバあるいは他の端末ＴＥとの間で、データ送信やデータ受信を行う部分であり、種々のネットワークを介して所定の通信プロトコル（例えば、Ｈ．３２３、ＳＩＰ、ＨＴＴＰ等）でデータ通信ができるように、データの通信制御を行う。また、会議システムでは、音声および映像の通信を行うが、必要に応じてデータの秘匿化や、データ量の削減のために、データの暗号化処理（例えば、ＡＥＳ：Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ、３ＤＥＳ：Ｔｒｉｐｌｅ−Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ等）、データの圧縮処理（符号化もしくはエンコードとも呼ぶ。例えば、映像であればＭＰＥＧ４、Ｈ．２６３、Ｈ．２６４、音声であればＧ．７１１、Ｇ．７２２、Ｇ．７２９等）を行う。
したがって、通信部５１は、通信暗号部５２および通信復号部５３を備えることが好ましい。
また、通信部５１は、端末モード切替部８６によって変更された後の動作状態に従って、サーバとの間の通信状態を変更する。
たとえば、映像および音声を双方向に送受信する双方向通信状態や、映像および音声をサーバから一方向的に受信する片方向通信状態に変更する。
【００４８】
認証部５５は、利用者の特定や端末および会議システムへのログイン認証を行う部分であり、主として事前に登録・管理されているＩＤ，パスワード入力により、認証を行う。
【００４９】
記憶部６１は、各種の入力情報（入力映像６６，入力音声６７など），表示情報，出力情報，送受信データ，信号処理されたデータなどの情報を記憶する部分であり、音声認識や画像認識などを利用した人物認識を行うために予め格納されている認識データベース６２を備える。
認識データベース６２は、主として利用者を特定するユーザ名６３と、その利用者の音声特徴データ６４と、その利用者の顔画像特徴データ６５とから構成される。端末ＴＥを複数の利用者が利用する場合、その利用者ごとに、認識情報（６３，６４，６５）が格納される。本稿には図示しないが、認識データベース６２には、利用者ごとのパスワード情報（データ自体は暗号化されていることが望ましい）を格納しても良い。
音声認識や画像認識は、人物認識部８４により行う。
記憶部６１には、ＲＯＭ，ＲＡＭなどの半導体素子，ハードディスク，ＣＤ，ＤＶＤ，ＵＳＢメモリなどの記憶媒体などが用いられる。
また、記憶部６１には、端末ＴＥの各機能を実行させるためのプログラムも記憶される。
【００５０】
信号処理部７１は、入力された映像および音声を、サーバに対して送信するデータに変換（符号化処理，エンコード処理とも呼ぶ）したり、サーバ等から送信されてきた映像および音声を、ディスプレイに表示およびスピーカから出力できるようにもとのデータに変換（復号化処理，デコード処理とも呼ぶ）したりする部分である。
主として、映像符号化部７２，映像復号化部７３，音声符号化部７４，音声復号化部７５から構成される。
信号処理部７１には、たとえば、所定の規格のコーデックに適合した符号化および復号化を実行することのできるコーデックＬＳＩが用いられる。符号化および復号化処理はＬＳＩのようなハードウェアコーデックではなく、ソフトウェアコーデックによって実現してもよい。
【００５１】
制御部８０は、ＣＰＵ，ＲＯＭ，ＲＡＭ，Ｉ／Ｏコントローラ，タイマー等を含むマイクロコンピュータに相当する部分であり、ＣＰＵが、記憶部６１に記憶されたプログラムをＲＡＭ（主記憶）に読み出すことにより、各種ハードウェアを有機的に動作させて、端末の各機能を実行させる。
図２では、制御部８０の行う機能として、アイドル状態判定部８１，端末状態通知部８５，端末モード切替部８６を示している。
アイドル状態判定部８１は、情報入力部によって生成された状態情報に基づいて、情報端末が使用されていない可能性のあるアイドル状態であることを判定する部分であり、主として、時間計測部８２，入力信号検知部８３，人物認識部８４とからなる。
これらの機能ブロック（８１〜８６）の各機能は、ＣＰＵが、その機能ごとのプログラムに基づいて、入力部１１、映像入力部２１、音声入力部４１などから得られた情報を用いて、それぞれ所定の処理を実行することにより実現される。
【００５２】
アイドル状態判定部８１によって、ネットワークを通じて接続された端末ＴＥの現在の動作状態を判定する処理を行い、端末モード切替部８６が、動作モードを、アクティブモード（Ｍ１），スリープモード（Ｍ２），ログオフモード（Ｍ３），シャットダウンモード（Ｍ４）のいずれかに変更する。
アイドル状態とは、情報端末が使用されていない可能性がある状態を意味し、利用者が中座や退席などの理由で、会議に参加していない状態あるいは参加していない可能性のある状態を意味する。アイドル状態が検出されると、４つのモードのうちアクティブモード以外のいずれかの状態になる。
この動作状態の判定には、後述するように、入力部１１による操作入力の有無の判断と、入力映像および入力音声を利用した人物認識による判断を利用する。
たとえば、所定の設定時間中に継続して（たとえば１０分間）、マウス等の操作入力がなく、カメラから入力される映像に変化がなく、かつマイクからの音声の入力がない場合は、アイドル状態であると判定する。
【００５３】
時間計測部８２は、アイドル状態であるか否かを判断するための設定時間をカウントするものである。設定時間は、予めデフォルト値として固定設定されるか、あるいは利用者によって変更できるようにしてもよい。たとえば、設定時間を１０分に設定したとすると、１０分間継続して状態を監視する。
入力信号検知部８３は、入力部１１からの入力信号の有無を検知する部分である。たとえば、キーボード１２から何らかの文字入力があることが検知されれば、入力信号ありと判断し、アイドル状態ではないと判定される。
【００５４】
人物認識部８４は、入力映像６６と入力音声６７とを用いて、認識データベース６２の認識情報（６３，６４，６５）と比較して一致するか否かを判断し、現在の利用者が、予め認識データベース６１に登録されている利用者に含まれているか否かを判断する部分である。
人物認識では、入力音声６７と音声特徴データ６４とを用いた音声認識と、入力映像６６と顔画像特徴データ６５とを用いた画像認識とを利用して、利用者を特定する。
たとえば、現在会議に参加している利用者の顔画像のデータが、登録されたユーザ名６３に対応した顔画像のデータと一致した場合、その利用者が特定でき、人物認識が成功したと判断し、アイドル状態ではないと判定される。逆に、人物認識が失敗した場合は、情報端末が使用されていない可能性があるアイドル状態であると判定される。
【００５５】
端末状態通知部８５は、情報端末の現在の動作状態を、サーバへ送信する部分であり、検知されたアイドル状態に基づいて、たとえば上記した４つのモード（Ｍ１，Ｍ２，Ｍ３，Ｍ４）のうちいずれかの状態であることを示す状態情報を生成し、通信部５１を介して、サーバに送信する。
たとえば、直前にアクティブモードであったモードが、その後の判定でアイドル状態になったことが検出された場合、アクティブモードからスリープモードになったと判定し、端末は現在スリープモードであることを示す状態情報を、サーバに送信する。
【００５６】
端末モード切替部８６は、自己の端末の動作状態のモードを、上記４つのモードのうちいずれかに変更する部分であり、アイドル状態であることが判定された場合に、情報端末の現在の動作状態に対応して、段階的に動作状態を変更する部分である。
たとえば、アイドル状態判定部８１によって、動作状態がスリープモードからログオフモードに変化したと判定された場合は、その端末の現在の動作状態を、ログオフモードに変更する。動作状態の変更は、端末の現在の動作状態に対応して、段階的に行われる。
【００５７】
以上が、端末の主要な機能ブロックであるが、制御部８０によって実現される機能（８１，８５，８６）は、これに限るものではない。
これらの機能は、主としてソフトウェアによって実現されるものであるので、必要に応じて他の機能を実行するプログラムを記憶部６１に格納し、そのプログラムに基づいてＣＰＵがハードウェアを有機的に動作させることにより、その機能を実行させてもよい。
また、プログラムは、予めＲＯＭ等に固定記憶して提供してもよいが、その後に削除，追加，変更，アップデート等をするために、ハードディスク等の書きかえ可能な記憶装置に記憶してもよく、ＣＤやＤＶＤなどの記録媒体によって提供してもよく、あるいはネットワークを介してサーバ等からダウンロードするようにしてもよい。
【００５８】
＜サーバの構成＞
図３に、サーバの第１実施例の構成ブロック図を示す。
サーバ１は、主として、入力部１０１，表示部１１１，通信部１２１，認証部１２５，ＭＣＵ部１３１，記憶部１４１，信号処理部１５１，および制御部１６１から構成される。
【００５９】
入力部１０１は、各種情報を入力する部分であり、キーボード１０２，マウス１０３，タブレット１０４およびこれらの入力デバイスからの入力を、制御部１６１へ送信することのできる信号に変換する入力処理部１０５とを備える。
表示部１１１は、ＬＣＤ，ＣＲＴなどのディスプレイ１１２と、ディスプレイに表示する表示信号を生成する表示処理部１１３とからなる。
ただし、サーバ１を完全に無人で運用する場合は、入力部や表示部はなくてもよい。
【００６０】
通信部１２１は、ネットワークを介して、端末ＴＥとデータの送受信をする部分であり、端末と同様に、所定の通信プロトコル（例えば、Ｈ．３２３、ＳＩＰ、ＨＴＴＰ等）でデータ通信し、映像および音声を所定のコーデック（例えば、映像であればＭＰＥＧ４、Ｈ．２６３、Ｈ．２６４、音声であればＧ．７１１、Ｇ．７２２、Ｇ．７２９等）で符号化し、所定の規格（例えば、ＡＥＳ：Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ、３ＤＥＳ：Ｔｒｉｐｌｅ−Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ等）で暗号化処理をする通信暗号部１２２と通信復号部１２３とを備える。
認証部１２５は、端末ＴＥと同様に、利用者の特定や端末および会議システムへのログイン認証を行う部分である。
【００６１】
ＭＣＵ部１３１は、いわゆる多地点接続装置（ＭＣＵ）で行われている処理を実行する部分であり、主として、複数の映像信号を合成する映像ミキシング部１３２，映像のサイズを変更する映像リサイズ部１３３，複数の音声信号を合成する音声ミキシング部１３４とから構成される。ＭＣＵ部１３１は信号処理部１５１と共通で構成されていてもよい。
【００６２】
記憶部１４１は、サーバで実行される処理で利用される各種データを記憶する部分であり、さらに、サーバに接続される端末を特定する情報（装置ＩＤ１４３，拠点ＩＤ１４４，ＩＰアドレス１４５）を格納した端末データベース１４２や、端末を利用する利用者を特定する情報（ユーザＩＤ１４７，拠点ＩＤ１４４，ＩＰアドレス１４５，メールアドレス１４８）を格納したユーザデータベース１４６を記憶する部分である。
この端末データベース１４２と、ユーザデータベース１４６は、サーバと端末との間で、双方向通信するときや、サーバから端末へ映像、音声等の情報を片方向送信するときに利用される。
この他に、サーバの各機能を実行するのに必要なプログラムも、記憶部１４１に記憶される。
記憶部１４１には、ＲＯＭ，ＲＡＭ，ハードディスク，ＣＤやＤＶＤなどの記録媒体などが用いられる。
【００６３】
信号処理部１５１は、端末から送られてきた映像および音声を、一旦もとの信号に戻す変換処理（復号化処理，デコード処理）をしたり、複数の端末へ映像や音声を送信するためのデータ変換処理（符号化処理，エンコード処理）をする部分である。
この信号処理部１５１は、端末ＴＥと同様に、主として映像符号化部１５２，映像復号化部１５３，音声符号化部１５４，音声復号化部１５５から構成され、コーデックＬＳＩもしくはソフトウェアコーデックを用いて実現することができる。
【００６４】
制御部１６１は、ＣＰＵ，ＲＯＭ，ＲＡＭ，Ｉ／Ｏコントローラ，タイマー等からなるマイクロコンピュータに相当する部分であり、ＣＰＵが、記憶部１４１に記憶されたプログラムに基づいて、各種ハードウェアを有機的に動作させることにより、サーバの各機能が実現される。
図３では、制御部１６１の機能として、端末状態判断部１６２と、通信方法切替部１６３とを示している。
【００６５】
端末状態判断部１６２は、端末から送られてくる動作状態のモードを示す状態情報を受信して、その端末が現在どのモードになっているかを判断する部分である。
通信方法切替部１６３は、情報端末の端末状態通知部によって送信されてきた端末の動作状態に基づいて、その情報端末に対する通信方法を切り替える部分である。通信方法としては、主として、双方向通信状態、画像音声等の送信をサーバから端末への方向のみとする片方向通信状態、データ通信の中止状態、端末の電源を切断した状態、通信回線を切断してその端末を管理対象外とする状態などがある。
また、サーバと情報端末との間の通信状態は、情報端末の動作状態に従って、各情報端末ごとに変更させられる。
【００６６】
＜端末の動作モードの説明＞
以下に、サーバと端末間における通信状態を切替える実施例として、端末の４つの動作状態のモードについて説明する。
図４に、端末のアクティブモード（Ｍ１）の一実施例の説明図を示す。
ここでは、サーバ１に対して、４台の情報端末（ＴＥ１〜ＴＥ４）が、直接接続されている場合を示す。
図４では、４つの端末（ＴＥ１〜ＴＥ４）の動作状態は、いずれもアクティブモードであるとする。
アクティブモードＭ１とは、ここでは、端末ＴＥが、サーバとの間で、データの双方向通信を行うことが可能な状態を意味する。
たとえば、端末ＴＥ１では、カメラで撮影した自画像（送信画像データＳＤ１）を、サーバへ送信し、サーバから受信画像ＲＤ１を受信することを示している。
【００６７】
ここで、受信画像ＲＤ１は、サーバが４台の端末（ＴＥ１〜ＴＥ４）から送られてきたそれぞれの自画像（ＳＤ１，ＳＤ２，ＳＤ３，ＳＤ４）を受信した後、デコード，リサイズ，ミキシング，エンコードの各処理をして、１つの画面上に、４つの自画像を４分割表示できるようにした画像データである。
各受信画像（ＲＤ１，ＲＤ２，ＲＤ３，ＲＤ４）は、すべて同一画像であり、図４では、表示部の画面上において、その左上に端末ＴＥ１で撮影された画像（ＳＤ１）、右上に端末ＴＥ２で撮影された画像（ＳＤ２）、左下に端末ＴＥ３で撮像された画像（ＳＤ３）、右下に端末ＴＥ４で撮影された画像（ＳＤ４）を４分割表示するような受信画像を示している。
この受信画像は、サーバに接続された端末で共有される共有情報の１つであり、共有情報としては、他に、いずれかの端末で入力された音声や、各端末に予め配信された文書情報も含まれる。
【００６８】
図５に、端末のスリープモード（Ｍ２）の一実施例の説明図を示す。
スリープモードＭ２とは、ここでは、端末ＴＥとサーバ間において、映像や音声などの情報の通信に関して、サーバから端末ＴＥへ、一方向の通信が行われる片方向通信状態を意味する。
図５では、端末ＴＥ１のみがスリープモードＭ２であり、他の端末（ＴＥ２，ＴＥ３，ＴＥ４）はアクティブモードＭ１である状態を示している。
【００６９】
端末ＴＥ１がアクティブモードＭ１からスリープモードＭ２に切替わる条件としては、たとえば、所定の設定時間の間、入力部のキーボード等からの入力が全くなく、かつ入力映像の変化もなく、音声の入力もない状態（アイドル状態）が継続したことが検出された時などが挙げられる。
すなわち、アクティブモードＭ１においてこのようなアイドル状態が検出されたとき、すぐに端末をシャットダウンするのではなく、段階的に動作モードを変更（ここではスリープモードＭ２に変更）することで、中座等で席をはずしていた利用者が戻ってきた時に復帰しやすくする。
スリープモードＭ２では、中座していた利用者が端末の前に着席（カメラの入力映像やマイクの入力音声に変化が起きる）し、何らかの入力操作をすれば、アイドル状態判定部８１および制御部８０を通じ、自動的にアクティブモードに復帰できる。
【００７０】
また、スリープモードＭ２となった端末ＴＥ１では、自画像ＳＤ１を送信することはなく、サーバから、受信画像ＲＤ１を受信することを行う。
サーバでは、３つの端末（ＴＥ２，ＴＥ３，ＴＥ４）から送られてくる自画像（ＳＤ２，ＳＤ３，ＳＤ４）に対して、デコード，リサイズ，ミキシングおよびエンコードなどの一連の処理を実行し、３つ画像を合成した画像を生成する。この場合、サーバでは、端末ＴＥ１の自画像ＳＤ１に対するデコード処理にかかる負荷が軽減されることになる。
たとえば、図５に示すように、もともと端末ＴＥ１の自画像を表示していた左上の領域を空白として４分割表示した合成画像が生成される。この合成画像は、サーバから４つの端末へ送信され、それぞれ受信画像（ＲＤ１，ＲＤ２，ＲＤ３，ＲＤ４）として受信され、各端末の表示部に表示される。
【００７１】
図６に、端末のログオフモード（Ｍ３）の一実施例の説明図を示す。
ログオフモードＭ３とは、ここでは、端末ＴＥとサーバとの間で、映像や音声等の情報通信をしない状態（通信中止状態）を意味する。
図６では、端末ＴＥ１のみが、ログオフモードＭ３であり、他の端末（ＴＥ２，ＴＥ３，ＴＥ４）はアクティブモードＭ１である状態を示している。
端末ＴＥ１がログオフモードＭ３となっているのは、たとえば、スリープモードＭ２になっていた端末ＴＥ１が、所定の設定時間を経過してもアイドル状態が継続的に検出されていることを意味する。
すなわち、スリープモードＭ２の状態のときに、さらに継続してアイドル状態が検出されたとき、すぐに端末をシャットダウンするのではなく、段階的に動作モードを変更（ここではログオフモードＭ３に変更）することで、中座等で席をはずしていた利用者が戻ってきた時に復帰しやすくする。
【００７２】
ログオフモードＭ３の状態で、利用者が端末をアクティブモードに復帰させるためには、たとえば、ユーザ認証およびログイン操作をすればよい。スリープモードＭ２より操作手順が必要となるが、シャットダウンモードＭ４よりは容易に、会議に復帰することができる。
また、ログオフモードＭ３となった端末ＴＥ１では、通信中止状態となるので、自画像ＳＤ１の送信および、受信画像ＲＤ１の受信は行われなくなる。図示しないが、この場合、端末ＴＥ１の表示部１には、利用者に対するユーザログイン画面を表示してもよい。
一方、他の３つの端末（ＴＥ２，ＴＥ３，ＴＥ４）では、アクティブモードの通常の動作が行われ、それぞれの自画像がサーバに送信されるので、図５のスリープモードと同様に、４分割された画面に、３つの端末のそれぞれの自画像を合成した受信画像が生成されて、サーバから３つの端末へ送信される。この場合、サーバでは、端末ＴＥ１の自画像ＳＤ１に対するデコード処理および、合成画像ＲＤ１の送信にかかる負荷が軽減されることになる。すなわち、サーバでは、端末ＴＥ１を除く実質３つの端末（ＴＥ２，ＴＥ３，ＴＥ４）のみの通信処理に負荷が軽減される。
【００７３】
図７に、端末のシャットダウンモード（Ｍ４）の一実施例の説明図を示す。
「シャットダウンモード」Ｍ４とは、ここでは、電源切断状態を意味し、端末とサーバとの間の回線が接続されていない状態である。電源切断は、原則、端末側で自動的に行われるものとするが、サーバからの指示を受けた後に、自動的に切断してもよい。
図７では、端末ＴＥ１のみがシャットダウンモードＭ４であり、他の端末（ＴＥ２，ＴＥ３，ＴＥ４）は、アクティブモードＭ１である状態を示している。
端末ＴＥ１がシャットダウンモードＭ４となるのは、たとえば、ログオフモードＭ３になった後、所定の設定時間の間、継続的にアイドル状態であることが検出されたことを意味する。
すなわち、端末ＴＥ１におけるログオフモードＭ３の状態になって以降も、継続的にアイドル状態であることが検出されつづければ、実質的に利用者が不在となったと判断し、端末の電源を切断する。
シャットダウンした後において、利用者が会議に再度参加したい場合には、通常どおりの操作手順（電源投入、ログイン認証等）を実行して端末を起動させることになる。
【００７４】
図７において、各端末での自画像の送信と、受信画像の受信は、図６のログオフモードと同様であり、３つの端末（ＴＥ２，ＴＥ３，ＴＥ４）とサーバ間での双方向通信が行われる。
【００７５】
以上のように、図５のスリープモードＭ２の場合では、映像、音声等の情報通信がサーバから端末ＴＥ１への一方向の通信のみとなるので、サーバにおける通信処理にかかる負荷が軽減される。図６のログオフモードＭ３と、図７のシャットダウンモードＭ４の場合では、サーバは４台の端末のうち、端末ＴＥ１に対する映像や音声等の情報通信は行われないため、通信処理にかかる負荷が軽減される。
【００７６】
また、現実には、サーバに接続される端末の台数は、５台以上の場合もあり、さらに、端末の動作モードも各端末ごとに変化するので、端末からサーバに送信される情報や、サーバから端末へ送信される合成画像も、図４〜図７以外に種々のパターンが考えられる。
また、サーバに接続された複数の端末がすべてアクティブモードであれば、サーバと各端末間で伝送されるデータ量は多く、サーバで処理すべきデータ量も多いため、伝送遅延や通信障害が起こる可能性は高くなるが、本実施例のように、利用者が不在となっている可能性のある端末の状態を検出し、段階的に動作モードを変更することで、サーバに接続された映像、音声等の情報の通信を行う端末の実質的な数を減少させられるため、伝送遅延の減少と通信障害の発生を低減させることができる。また、利用者の不在を検出した際、すぐに端末の電源を切断する場合よりも、端末が利用できる状態（アクティブモード）への復帰にかかる利用者の操作負担を軽減できる。
【００７７】
＜情報端末とサーバ間の通信シーケンス＞
図８に、情報端末とサーバとの間で行われる通信シーケンスの一実施例の説明図を示す。
図８（ａ）は、端末ＴＥ１が、アクティブモードＭ１のときの通信シーケンスの概要を示したものである。
まず、端末ＴＥ１で、その端末の状態がアイドル状態であるか否か判定し、たとえば、マウスや人検知センサによる入力があることが検出された場合、アイドル状態ではないと判定する。
このとき、端末ＴＥ１からサーバへ、端末ＴＥ１が現在アクティブモードＭ１であるということを示す端末状態情報を通知する。
一方、サーバは、通知された端末状態情報を確認して、その送信元の端末ＴＥ１が「アクティブモード」であることを判断したとすると、映像や音声等の情報を、その端末ＴＥ１とサーバとの間で、相互に双方向に通信するようにする。
【００７８】
図８（ｂ）は、端末ＴＥ１が、スリープモードＭ２となった場合の通信シーケンスの概要を示したものである。
ここでは、端末ＴＥ１において、アクティブモードのときに、アイドル状態であるか否かの判定を行い、アイドル状態になっていると判定されたとする。
このとき、端末ＴＥ１は、動作モードをスリープモードＭ２に移行する。その後、端末ＴＥ１からサーバへ、端末ＴＥ１が現在スリープモードＭ２となっていることを示す端末状態情報を通知する。
一方、サーバでは、通知された端末状態情報を確認して、その送信元の端末ＴＥ１が「スリープモード」Ｍ２になったと判断する。そして、スリープモードになった端末ＴＥ１に対する通信を、双方向通信から片方向通信に切りかえる。
すなわち、映像、音声等の情報通信に関して、サーバから端末ＴＥ１への送信のみをする一方向通信に切りかえる。
【００７９】
ここで、片方向通信への切替えは、主として、次のような２つの方法のうち、いずれかの方法が考えられる。
（１）通信プロトコルを固定したまま、所定の通信シーケンスは継続するが、スリープモードとなった端末ＴＥ１から送信されてきた映像および音声についての一連の信号処理を中止する。具体的には、サーバにおいて、その端末ＴＥ１についての映像復号化処理（デコード）と、音声復号化処理（デコード）を停止する。
この場合、たとえば通信プロトコルとして、ＳＩＰやＨ．３２３、ＨＴＴＰ等の規格が採用されていたとすれば、その通信プロトコルを利用した通信シーケンスは継続して行う。
【００８０】
（２）通信プロトコルを、別の通信プロトコルに変更する。
たとえば、ＳＩＰやＨ．３２３、ＨＴＴＰ等の通信プロトコルを中止し、映像、音声に関するストリーミング配信の通信プロトコルに変更する。ストリーミング配信とは、サーバから端末ＴＥ１へ、一方向的に映像、音声等のデータを送信する通信方式である。
ストリーミング配信としては、所定の規格（ｍｍｓ，ｈｔｔｐ，ｒｔｍｐ，ｒｔｓｐ等）のいずれかを採用することが望ましい。
【００８１】
上記いずれの方法も、端末とサーバ間で所定の通信プロトコルに基づいて、データの送信と受信が行われるが、サーバから端末に対して、一方向的に、映像および音声の送信が行われるものであるので、通信回線を流れるトラフィックを減少させることができる。したがって、データ伝送の遅延を減少させ、通信エラー等の通信障害も削減させることができ、その結果実質的にサーバに接続された端末の数を減少させることができるので、円滑な会議の進行が可能となる。
【００８２】
図８（ｃ）は、端末ＴＥ１が、ログオフモードＭ３となった場合の通信シーケンスの概要を示したものである。
ここで、端末ＴＥ１は、図８（ｂ）のスリープモードＭ２のときに、アイドル状態であるか否かの判定を行い、継続してアイドル状態になっていると判定されたとする。
このとき、端末ＴＥ１では動作モードを、ログオフモードＭ３へ移行する。ログオフモードＭ３にする場合、端末ＴＥ１では、たとえば、具体的には、端末およびサーバとのユーザログインの解除や、端末とサーバとの通信処理を終了させるような処理を行う。
その後、端末ＴＥ１からサーバへ、端末ＴＥ１が現在ログオフモードＭ３となっていることを示す端末状態情報を通知する。
【００８３】
一方、サーバでは、通知された端末状態情報を確認して、その送信元の端末ＴＥ１がログオフモードＭ３になったと判断する。その後、サーバは、端末ＴＥ１との間で行っていた片方向通信を停止し、映像および音声の通信を中止する。
ここで、通信の中止は、たとえば、通信プロトコルはそのまま継続し、一方向の映像、音声等の通信を停止してもよく、あるいは、通信プロトコルに従ってシーケンスそのものを停止し、確立していたリンクを解除（ユーザログイン待ち状態）してもよい。
【００８４】
図８（ｄ）は、端末ＴＥ１が、シャットダウンモードＭ４となった場合の通信シーケンスの概要を示したものである。
ここでは、端末ＴＥ１において、図８（ｃ）のログオフモードＭ３のときに、アイドル状態か否かの判定を行い、継続的にアイドル状態となっていると判定されたとする。
このとき、端末ＴＥ１では通信プロトコルが継続されている場合は、サーバに対して、シャットダウンモードＭ４へ移行することを示す端末状態情報を通知する。
その後、端末ＴＥ１では、所定のシャットダウンの一連の動作を自動的に行い、回線を切断して、自己の電源を切断する。
一方、サーバ側では、通知された端末状態情報を確認し、端末ＴＥ１がシャットダウンモードＭ４になったと判断する。その後、サーバは、端末ＴＥ１を管理対象外とするための処理たとえば、具体的には、サーバと端末ＴＥ１との間の通信プロトコル終了、端末ＴＥ１およびサーバにおけるユーザ認証の解除（ログオフ）のような処理を行う。
【００８５】
以上が、端末の４つの動作モードに対するシーケンスの説明である。
ただし、動作モードはこれらの４つに限定されるものではなく、これら４つ以外の他のモードを設定する場合は、その他のモードについて設定された所定のシーケンスを実行するようにすればよい。
この他のモードとしては、たとえば、映像のみによる通信，音声のみによる通信，共有ドキュメントデータのみの通信，および、これらの双方向通信，片方向通信などのモードが考えられる。
【００８６】
＜端末のモード移行処理＞
図９に、情報端末のモード移行処理の第１実施例のフローチャートを示す。
ここでは、上記したように図４から図８に示したように、端末のモードを段階的に移行させる処理について説明する。
また、端末およびサーバは、それぞれ図２および図３に示したような機能ブロックを備え、端末側でアイドル状態の判定処理を行うものとする。
【００８７】
図９において、まず、ステップＳ１に示すように、端末が初期状態として、アクティブモードＭ１になっているものとする。このとき、図８（ａ）で示したように、端末とサーバとは、双方向通信状態にある。
ステップＳ２において、端末の端末状態通知部８５が、自己の現在の動作モードの状態を確認し、ここでは、アクティブモードＭ１であることをサーバに通知する（端末状態通知処理）。
【００８８】
ステップＳ３において、端末のアイドル状態判定部８１が、入力部１１からの入力信号の有無、映像入力部２１からの入力映像の変化の有無、音声入力部４１からの入力音声の有無等を確認することにより、端末が現在アイドル状態にあるか否かを判定する（アイドル状態判定処理）。
このアイドル状態判定処理の詳細については、図１０のフローチャートで説明する。
【００８９】
ステップＳ４において、端末がアイドル状態であると判定された場合は、ステップＳ５へ進み、そうでない場合は、ステップＳ１４へ進む。
ステップＳ５において、端末モード切替部８６が、端末の動作モードをスリープモードＭ２に移行する処理を実行する。
ここでは、自己の端末の動作モードをアクティブモードＭ１からスリープモードＭ２に設定変更する。具体的には、たとえば、今まで双方向通信をしていた通信状態を、サーバから映像および音声などの情報を受信する片方向通信に切り替える処理や、映像や音声のストリーミング受信処理等を行う。
【００９０】
ステップＳ６において、端末状態通知部８５が、スリープモードＭ２になったことを、サーバへ通知する。
ステップＳ７において、ステップＳ３と同じアイドル状態判定処理を実行する。
ここでは、現在スリープモードＭ２である場合において、さらにアイドル状態が継続しているかどうかをチェックする。
【００９１】
ステップＳ８において、アイドル状態が継続していると判定された場合は、ステップＳ９へ進み、そうでない場合は、ステップＳ１５へ進む。
ここで、そうでない場合とは、たとえば、マウスや人検知センサ等の入力があった場合を意味する。このとき、ステップＳ１５において、端末モード切替部８６が、アクティブモード移行処理を実行する。
アクティブモード移行処理では、たとえば、端末の動作モードを、スリープモードＭ２からアクティブモードＭ１に設定変更し、さらに通信状態を片方向通信から双方向通信に戻すようにする。
ステップＳ１５の後は、ステップＳ１４へ進み、端末状態通知部８５が、アクティブモードＭ１になったことを、サーバへ通知する。
【００９２】
ステップＳ９において、端末モード切替部８６が、ログオフモード移行処理を実行する。ここでは、端末の動作モードを、スリープモードＭ２からログオフモードＭ３へ設定変更し、さらに、図示しないが、端末の画面上にユーザログイン画面を表示するような処理をする。
ステップＳ１０において、端末状態通知部８５が、ログオフモードＭ３になったことを、サーバへ通知する。
ステップＳ１１において、アイドル状態判定部８１が、再度アイドル状態判定処理を実行する。
ステップＳ１２において、ログオフモードＭ３の状態において、アイドル状態がさらに継続している場合は、ステップＳ１３へ進み、そうでない場合は、ステップＳ１６へ進む。
【００９３】
ステップＳ１３において、端末モード切替部８６が、シャットダウンモード移行処理を実行する。ここでは、端末の動作モードを、ログオフモードＭ３からシャットダウンモードＭ４へ設定変更する。この後、ステップＳ１４へ進み、端末がシャットダウンモードＭ４になったことを、サーバへ通知し、その後、図９には示していないが、端末自身の電源を自動的に切断する。あるいは、ステップＳ１３の処理の中で、サーバにシャットダウンすることを通知した後、自動的に電源を切断し、処理を終了してもよい。
【００９４】
一方、ステップＳ１６において、ログオフモードＭ３の状態で、アイドル状態でないことが検出されたので、ログイン画面を表示する。
このとき、アイドル状態でないことは、利用者がキーボードやマウスを使用して、いわゆるログイン操作をしたことを意味する。
また、ステップＳ１６の処理の後、ステップＳ１５に移行し、端末の動作モードは、ログオフモードＭ３から、アクティブモードに設定変更される。その後、ステップＳ１４において、動作モードがアクティブモードになったことを、サーバへ通知する。
【００９５】
図１０に、図９に示した端末で行うアイドル状態判定処理の一実施例のフローチャートを示す。
ステップＳ２１において、時間計測部８２による時間計測処理を開始する。ここでは、タイマーを初期値（設定時間）にリセットする。
初期値としては、アイドル状態であるか否かを判断するのに適切な時間、たとえば１０分にセットし、カウントダウンをスタートさせる。ただし、アイドル状態であるか否かを判断するのに適切な時間は、一律に予め１０分間に固定設定してもよいが、この時間は、利用者や利用形態によって適切な値が異なると考えられるので、利用者もしくはシステム管理者等によって設定変更できるようにすることが好ましい。
【００９６】
ステップＳ２２において、入力信号検知部８３が、入力部１１，映像入力部２１，音声入力部４１からの入力信号の有無や変化をチェックする。
たとえば、キーボードやマウスからの操作入力がないかチェックする。また、人検知センサからの入力信号がないか、利用者の音声入力がないかをチェックする。
さらに、カメラから入力される映像入力について、所定のしきい値を越えるような変化がないかどうかチェックする。
これらの入力信号をチェックした結果、初期値として設定された設定時間の間に、１回も入力信号と入力音声の入力がなく、かつ映像入力の変化もない場合は、入力信号の検知がなかったと判断される。
一方、入力信号の入力が１回以上ある場合や、あるいは映像入力に所定の変化が検知された場合は、入力信号が検知されたと判断される。
【００９７】
ステップＳ２３において、人物認識部８４が、音声認識および画像認識のいずれか一方、あるいは両方の認識処理を用いて、利用者の人物認識を行う。
人物認識処理は、利用者が、端末の記憶部６１の認識データベース６２に予め登録された人物であるか否かを確認する処理である。
たとえば、カメラ２２で撮影された入力映像６６と、認識データベース６２の中に記憶された顔画像特徴データとを比較し、いわゆるパターンマッチングにより、一致する顔画像特徴データが認識データベース６２の中に存在する場合は、人物認識が成功し、現在の利用者がだれであるかが正常に特定され、その利用者が端末の前に在席し、会議に参加している状態であると判断される。
【００９８】
一方、一致する顔画像特徴データが、認識データベース６２の中に存在しなかった場合、利用者を特定することができず、人物認識が失敗したことになる。この場合、利用者が端末のカメラによる撮影範囲に存在せず、会議に参加していない可能性がある状態であると判断される。
ただし、この人物認識処理は、処理に必要な負荷や処理時間、認識精度（カメラに複数の人物が映った場合や、照明環境、眼鏡や服装などの影響による認識誤り発生）等の理由から、必須の処理とはせずに、利用者が必要に応じて実行できるオプションとしてもよい。
ステップＳ２４において、ステップＳ２２とＳ２３の結果、入力信号や入力音声等の検知がなかった場合や、人物認識も失敗した場合は、現在利用者が端末の前には不在の可能性があると判断し、ステップＳ２５へ進む。
【００９９】
一方、入力信号のいずれか１つ以上の入力が検知された場合、あるいは、人物認識が成功した場合、またはいずれかの入力信号があり人物認識も成功した場合は、ステップＳ２７へ進み、アイドル状態でないと判定し、処理を終了する。
ステップＳ２５において、設定された設定時間が経過したか否かチェックする。設定時間がまだ経過していないときは、ステップＳ２２へ戻り、再度ステップＳ２２からＳ２４までの処理を繰り返す。
設定時間がすでに経過した場合、その設定時間の間、アイドル状態が継続されていたことになるので、ステップＳ２６へ進み、端末が現在アイドル状態になっていると判定し、処理を終了する。
【０１００】
図１１に、サーバにおける端末状態判断制御処理の一実施例のフローチャートを示す。
ステップＳ３１において、サーバの端末状態判断部１６２が、各端末から送られてくる端末状態情報が受信されたか否か、確認する。受信された場合は、ステップＳ３２へ進む。
ここで、端末状態情報は、たとえば、端末を特定する端末ＩＤと、その端末の動作モード（端末状態）を示すデータとを含むものである。
ステップＳ３２において、受信した端末状態情報に含まれる「端末状態」を示すデータが、アクティブモードＭ１を示すものであるか否か、チェックする。
ここで、アクティブモードＭ１であれば、ステップＳ３３へ進み、通信方法切替部１６３が、その端末との間では、音声および映像の双方向通信ができる状態に設定する。具体的には、たとえば、通信方法切替部１６３が、所定の通信プロトコル（ＳＩＰ，Ｈ．３２３，ＨＴＴＰ等）に基づく通信シーケンス処理を行う。
【０１０１】
ステップＳ３２において、アクティブモードでない場合は、ステップＳ３４へ進む。
ステップＳ３４において、受信した「端末状態」のデータが、スリープモードＭ２を示すものか否か、チェックする。
スリープモードＭ２であれば、ステップＳ３５へ進み、そうでない場合は、ステップＳ３６へ進む。
ステップＳ３５において、通信方法切替部１６３が、その端末との間では、サーバから端末に対して音声および映像の情報を伝送する片方向通信状態に設定する。
具体的には、たとえば、通信方法切替部１６３が、ストリーミング配信用の規格（ｍｍｓ，ｈｔｔｐ，ｒｔｍｐ，ｒｔｓｐ等）に基づく通信プロトコルへの切替えや、端末からの映像、音声の受信を中止する等の処理を行う。
【０１０２】
ステップＳ３６において、受信した「端末状態」のデータが、ログオフモードＭ３を示すものか否か、チェックする。
ログオフモードＭ３であれば、ステップＳ３７へ進み、そうでない場合はステップＳ３８へ進む。
ステップＳ３７において、通信方法切替部１６３が、その端末とサーバ間での音声および映像の通信を中止する。
【０１０３】
ステップＳ３８において、受信した「端末状態」のデータが、シャットダウンモードＭ４を示すものか否か、チェックする。
シャットダウンモードＭ４であればステップＳ３９へ進み、そうでない場合は、処理を終了する。あるいは、ステップＳ３１へ戻ってもよい。
ステップＳ３９において、端末がシャットダウンされたことが受信されると、端末との接続が完全に切れたことになるので、その端末を管理対象外に設定する。
管理対象外とするためには、具体的には、端末に対し、所定の通信プロトコルによる通信シーケンスを終了する等の処理をすればよい。
図１１に示したサーバによる処理は、サーバに接続された各端末ごとに行われる。
【０１０４】
図１２に、端末およびサーバの記憶部に格納されている各データベースの内容の一実施例の説明図を示す。
図１２（ａ）は、図２の端末の記憶部６１に格納されている認識データベース６２の一実施例を示している。
ここでは、登録されたユーザごとに、そのユーザ名６３と、ユーザの音声特徴データ６４と、顔画像特徴データ６５とが、関連付けて記憶されている。
【０１０５】
図１２（ｂ）は、図３のサーバの記憶部１４１に格納されている端末データベース１４２の一実施例を示している。
ここでは、端末ごとに、装置ＩＤ１４３と、拠点ＩＤ１４４と、ＩＰアドレス１４５とが、関連付けて記憶されている。
【０１０６】
図１２（ｃ）は、図３のサーバの記憶部１４１に格納されているユーザデータベース１４６の一実施例を示している。
ここでは、ユーザ名１４７と、拠点ＩＤ１４４と、メールアドレス１４８と、ＩＰアドレス１４５とが関連付けて記憶されている。
なお、各データベースに格納される情報の項目は、以上のものに限られず、他に必要な項目があれば、追加して記憶してもよい。
【０１０７】
＜情報端末とサーバ間通信の第２実施例＞
以下に、第２実施例の構成および処理内容について、説明する。
この第２実施例では、端末が現在アイドル状態であるか否かを判定する処理を、端末側ではなく、サーバで行うことを特徴とする。
図１３に、情報端末の第２実施例の構成ブロック図を示す。
ここで、図２の構成とは、記憶部６１と制御部８１の機能ブロックが一部分異なる。
すなわち、記憶部６１には、認識データベース６２を備えない。
また、制御部８１は、アイドル状態判定部８１を備えずに、端末モード変更受付部８７を備える。
【０１０８】
情報端末の端末状態通知部８５は、入力部等からなる情報入力部によって生成された状態情報と、情報端末の現在の動作状態とを含む状態監視情報を、サーバへ送信する。
また、端末モード変更受付部８７は、サーバから送信される動作状態の移行通知を受信する部分である。
端末モード切替部８６は、受信した移行通知に基づいて、段階的に動作状態を変更する。
【０１０９】
図１４に、サーバの第２実施例の構成ブロック図を示す。
ここで、図３の構成とは、記憶部１４１と、制御部１６１の機能ブロックが一部分異なる。
記憶部１４１は、図２の端末に備えられていたのと同じ認識データベース１４９をさらに備える。
また、制御部１６１は、端末モード制御部１６４を備え、図２の端末に備えられていたアイドル状態判定部１６５をさらに備える。
【０１１０】
アイドル状態判定部１６５は、図２の端末で行われるアイドル状態の判定と同様の処理を行うものであるが、そのアイドル状態であることの判定は、接続される各端末から送信される状態監視情報や、端末で入力された映像や音声の情報に基づいて、行われる。
端末モード制御部１６４は、アイドル状態であると判定された場合に、端末から送信されてきた状態監視情報に含まれる現在の動作状態に対応して、サーバが段階的に移行させるべき動作状態を設定し、端末に対して、設定した動作状態への移行通知を、送信する部分である。
この第２実施例でも、サーバと情報端末との間の通信状態は、その情報端末の動作状態に従って各情報端末ごとに変更させられる。
【０１１１】
また、認識データベース１４９は、図２の端末と同様に、アイドル状態判定部１６５の人物認識処理で用いられ、端末データベース１４２とユーザデータベース１４６は、端末とサーバ間の双方向通信および片方向通信をするときや、これらの通信方法の切替をするときに用いられる。
図１３と図１４の構成のうち、他の機能ブロックについては図２と図３と同様の処理を実行する。
【０１１２】
図１５に、第２実施例におけるサーバのモード移行制御処理のフローチャートを示す。
ここでは、主として、端末から送られてくる各種情報を用いて、その端末がアイドル状態となっているか否かを判定し、その端末の動作モードを移行させるか否かを決定し、その端末に対して動作すべき動作モードを通知する処理を行う。
すなわち、サーバが、各端末の動作モードを管理し、各端末はサーバから通知される動作モードに基づいて、受動的にその動作モードを設定変更する。
図１５のフローは、サーバが、各端末ごとにそれぞれ独立に行う処理である。
【０１１３】
ステップＳ５１において、ここでは、サーバの初期状態として、現在端末との間の通信が双方向通信状態であって、その端末がアクティブモードであったとする。
ステップＳ５２において、サーバのアイドル状態判定部１６５により、端末がアイドル状態であるか否か、判定する。
この判定処理の詳細内容は、図１６のフローチャートで説明する。
ステップＳ５３において、端末がアイドル状態になったと判定された場合、ステップＳ５４へ進み、そうでない場合は処理を終了する。
ステップＳ５４において、今まで端末の動作モードはアクティブモードであったので、端末モード制御部１６４が、その端末をスリープモードに移行させる処理を行う（スリープモード移行処理）。
【０１１４】
ステップＳ５４では、端末に対して、現在の動作モードを「スリープモード」Ｍ２へ切りかえることを要求する移行通知を、送信する。さらに、通信方法切替部１６３により、現在の通信状態を、双方向通信から片方向通信に切りかえる処理をし、サーバから端末に対して、映像や音声の情報の一方向送信が行えるようにする。この移行通知を受信した端末は、動作モードをアクティブモードＭ１からスリープモードＭ２へ切り替え、一方向通信ができる通信状態にする。
ステップＳ５５において、アイドル状態判定部１６５が、ステップＳ５２と同様に、アイドル状態判定処理を行う。
ステップＳ５６において、端末が、さらにアイドル状態が継続している状態であったと判定された場合、ステップＳ５７へ進み、そうでない場合は、ステップＳ６１へ進む。
【０１１５】
ステップＳ５７において、現在スリープモードＭ２のときに、アイドル状態であると判定されたので、端末モード制御部１６４が、その端末をログオフモードＭ３に移行させる処理を行う（ログオフモード移行処理）。
ここでは、端末に対して、動作モードを「ログオフモード」Ｍ３へ切りかえることを要求する移行通知を、送信する。また、通信状態を一方向通信から、通信中止状態に変更する。
【０１１６】
一方、ステップＳ６１では、端末がアイドル状態ではないと判定された場合なので、端末モード制御部１６４は、アクティブモード移行処理を行う。
たとえば、端末がスリープモードＭ２の状態のときに、キーボードや人検知センサからの入力信号が入力されたことを示す状態監視情報が、その端末から送られてきた場合に、アイドル状態ではないと判定され、ステップＳ６１の処理を行う。
ステップＳ６１においては、端末に対して、動作モードをスリープモードＭ２からアクティブモードＭ１へ切りかえることを要求する移行通知を、送信する。さらに、通信状態を、一方向通信から双方向通信へ変更する。
【０１１７】
ステップＳ５８において、アイドル状態判定部１６５が、アイドル状態判定処理を行う。
ステップＳ５９において、その端末がアイドル状態をまだ継続していると判定された場合、ステップＳ６０へ進み、そうでない場合は、ステップＳ６２へ進む。
ステップＳ６０において、端末が現在ログオフモードＭ３のときに、アイドル状態であると判定されたので、端末モード制御部１６４が、その端末をシャットダウンモードＭ４へ移行させる処理を行う（シャットダウンモード移行処理）。
【０１１８】
ここでは、端末に対して、動作モードを「シャットダウンモード」Ｍ４へ切りかえることを要求する移行通知を、送信する。
この移行通知を受信した端末は、所定のシャットダウン処理を自動的に行い、電源を切断する。
また、サーバは、その端末との間の通信回線を切断し、その端末を管理対象外に設定する。
【０１１９】
一方、ステップＳ６２において、ログオフモードＭ３のときにアイドル状態でないと判定された場合は、利用者が何らかの入力操作等をしたことや映像の変化あるいは音声の入力がされたことが検出された場合なので、ログオンへの移行通知処理を行う。
ここでは、たとえば、端末に対して、ログオフ状態から、ログオン状態に変化した可能性のあることを通知し、ステップＳ６１にて、動作モードを、アクティブモードへ移行すべきことを要求する通知を送信する。
この通知を受けた端末は、利用者のログオン操作を受け入れて、たとえば、動作モードをアクティブモードにすればよい。
あるいは、ログオフ状態からログオンへ変更する処理は、端末側での処理なので、サーバ側では、ステップＳ５９でアイドル状態でないと判定した場合には、ステップＳ６２の処理は行わずに、処理を終了してもよい。
【０１２０】
図１６に、サーバにおけるアイドル状態判定処理のフローチャートを示す。
ここで、ステップＳ７２とＳ７３での処理が、端末から送信されてくる情報を基にして行われる点が、図１０の処理と異なる。
ステップＳ７１において、時間計測部１６６が、時間計測処理を開始させ、設定時間を初期値にリセットし、カウントダウンを開始する。
ステップＳ７２において、端末状態判断部１６２が、端末から送られてくるその端末の状態監視情報を受信する。
状態監視情報とは、たとえば、端末の現在の動作モードを示す情報、端末の入力部から入力された入力信号の情報、端末のカメラによって入力された映像およびマイクから入力された音声などの情報を意味する。
【０１２１】
ここでは、受信された状態監視情報を用いて、入力信号検知部１６７が、アイドル状態でないと判定されるような入力信号が入力されていないかどうか、チェックする。
たとえば、人検知センサによる入力の有無が判定され、人検知センサの入力があったことが検知された場合には、後のステップＳ７４において、アイドル状態でないと判断される。
また、この他に、端末のキーボード，マウス，タブレットなどの入力部からの入力信号が１つ以上あったことが検知された場合には、アイドル状態でないという判定に利用される。
さらに、端末から送られてきた映像に変化があるか否か、端末から入力音声が送られてきたか否かチェックされ、映像の変化があったことが検知された場合、入力音声が送られてきた場合、あるいは、映像の変化と入力音声の入力がいずれも検知された場合は、いずれの場合も、アイドル状態でないと判定される。
逆に、上記した入力信号がすべて検知されていない場合には、アイドル状態であると判定される。
【０１２２】
ステップＳ７３において、人物認識部１６８が、端末から送られてきた受信映像と受信音声とを用いて、人物認識処理を行う。
ここでは、受信音声と、認識データベース１４９の音声特徴データとを比較し、音声認識処理を行い、さらに、受信映像と、認識データベース１４９の顔画像特徴データとを比較し、画像認識処理を行う。
各認識処理は、図１０で行われる処理と同様の処理である。
これらの認識処理で、音声および映像が一致するデータが認識データベースに存在した場合には、人物認識が成功したと判断し、アイドル状態ではないと判定される。
一方、一致するデータがないときには、人物認識が失敗したと判断し、アイドル状態であると判定される。
【０１２３】
ステップＳ７４において、ステップＳ７２とＳ７３との判断結果を利用して、アイドル状態か否かの判定を行う。
ここでは、ステップＳ７２の判断結果により端末で入力信号が検知された場合、あるいはステップＳ７３で人物認識が成功した場合、あるいは入力信号が検知されかつ人物認識が成功した場合のいずれかであれば、ステップＳ７７へ進み、現在端末はアイドル状態ではないと判定する。
また、入力信号が検知されなかった場合、かつ人物認識が失敗した場合に、ステップＳ７５へ進む。
ステップＳ７５において、設定時間が経過したか否かを確認し、まだ経過していない場合は、ステップＳ７２へ戻る。
一方、経過してしまった場合は、その設定時間をこえて、アイドル状態が継続していたことになるので、ステップＳ７６へ進み、アイドル状態であると判定する。
【０１２４】
図１７に、第２実施例における端末の端末状態制御処理のフローチャートを示す。
ここでは、主として、サーバから送られてくる移行通知の内容に基づいて、自己の端末の動作モードを設定変更する。
まず、端末状態通知部８５は、ステップＳ８１において、自己の端末状態を監視し、ステップＳ８２において、サーバに、監視によって取得した現在の状態監視情報を通知する。
【０１２５】
ステップＳ８１においては、入力部１１からの入力信号の有無をチェックし、さらに映像入力部２１のカメラ２２からの入力された映像を、入力映像６６として記憶部６１に記憶し、マイク４２から入力された音声を、入力音声６７として記憶する。
ステップＳ８２では、たとえば入力部からの入力信号の有無についての情報、入力映像および入力音声を含む情報をサーバに通知するために、現在の状態監視情報を生成し、サーバに送信する。
【０１２６】
次に、ステップＳ８３において、端末モード変更受付部８７が、サーバからの移行通知情報が受信されたか否か、チェックする。
受信されていない場合はステップＳ８１へ戻り、受信された場合は、ステップＳ８４へ進む。
【０１２７】
ステップＳ８４，Ｓ８６，Ｓ８８において、受信した移行通知の内容が、どの動作モードであるか否か、チェックする。
まず、ステップＳ８４において、受信した移行通知がスリープモードＭ２への移行を要求するものであった場合、ステップＳ８５へ進み、端末モード切替部８６が、動作モードを、スリープモードＭ２へ切り替え、通信状態を、音声と映像の片方向通信の状態に移行させる。
すなわち、サーバから送られてくる映像と音声を受信する片方向通信に切りかえる。
このとき、端末からサーバへ、映像および音声を送信しないようにしてもよい。
【０１２８】
ステップＳ８６において、受信した移行通知がログオフモードＭ３への移行を要求するものであった場合、ステップＳ８７へ進む。
ステップＳ８７では、上記した図９のステップＳ９と同様のログオフモードへの移行処理を行う。
ステップＳ８８において、受信した移行通知がシャットダウンモードＭ４への移行を要求するものであった場合、ステップＳ８９へ進み、ステップＳ１３と同様のシャットダウンモード移行処理を行う。
【０１２９】
一方、ステップＳ８８において、受信した移行通知がシャットダウンモードＭ４への移行通知でなかった場合は、ステップＳ９０へ進み、ステップＳ１５と同様に、アクティブモードＭ１への移行処理を実行する。ただし、現在すでにアクティブモードＭ１になっている場合は、この処理は実行しなくてもよい。
スリープモードＭ２からアクティブモードＭ１へ戻る場合には、片方向通信から双方向通信へ切りかえる処理が行われる。
【０１３０】
以上が第２実施例における端末とサーバの処理内容である。
この第２実施例では、アイドル状態の判定処理をサーバ側で行うので、その判定処理を行うための負荷がサーバにかかることになるが、第１実施例と同様に、段階的に、端末の動作モードを変更するので、サーバに接続される実質的な端末の数を減少させることができ、サーバの負荷の減少と、通信遅延等の減少による円滑な会議の実現と、利用者の操作負担の軽減を図ることができる。
【０１３１】
＜第３実施例、グループ化による端末数の減少＞
ここでは、複数の端末をグループ化して、その中の１台を代表端末に設定することにより、サーバに接続される端末の数を実質的に減少させる実施例を説明する。
図１８に、情報端末の第３実施例の構成ブロック図を示す。
図１８において、端末は、さらに、代表端末検出要求部８８と、ストリーミング要求部８９と、ストリーミング受信部９０と、ストリーミング配信部９１とを備える。
代表端末検出要求部８８は、サーバに対して、同一拠点内の代表端末を検出するように要求する部分であり、検出された代表端末の情報をサーバから受信する。
ストリーミング要求部８９は、代表端末に対して、ストリーミング情報（音声および映像）をその端末に配信するように要求する部分である。
ストリーミング受信部９０は、サーバあるいは代表端末から配信されたストリーミング情報を受信する部分である。
【０１３２】
ストリーミング配信部９１は、端末が代表端末である場合に、他の端末に対してストリーミング情報を送信する部分である。
ここで、ストリーミング配信とは、ストリーミング情報である映像や音声を一方向に送信することを意味する。
ストリーミング受信を行う端末は、自端末の映像、音声データの符号化や送信を行わないので、双方向通信を行う場合よりも、端末にかかる負荷は少なくなる。
【０１３３】
図１９に、サーバの第３実施例の構成ブロック図を示す。
図１９において、サーバは、さらに、代表端末検出部１６９と、ストリーミング配信部１７０とを備える。
代表端末検出部１６９は、記憶部１４１の端末データベース１４２に記憶された拠点ＩＤ１４４を用いて、代表端末とすべき端末が、同一拠点内に存在するか否かを検出する部分である。
ストリーミング配信部１７０は、サーバから、情報端末に対して、ストリーミング情報を送信する部分である。
このサーバからのストリーミング配信は、代表端末と判断された情報端末に対してのみ行われ、代表端末でない情報端末へは行われない。
【０１３４】
また、図２０に、この第３実施例で用いられる端末データベースの一実施例の説明図を示す。図２０において、記憶部１４１の端末データベース１４２には、代表端末フラグ１５０を備える。代表端末フラグ１５０は、端末が代表端末であるか否かを識別するための情報であり、「ＯＮ」のとき、その端末が代表端末であることを意味し、「ＯＦＦ」のとき、その端末は代表端末でないことを意味する。
図２０においては、４つの端末のうち、拠点ＩＤが「関西」となっている２つの端末が、同一拠点の端末であり、この同一拠点に含まれる２つの端末のうち、装置ＩＤ＝「Ｇ５３１８２」の端末の代表端末フラグ１５０が「ＯＮ」であるので、この端末が代表端末であることを意味する。
ここで、同一拠点が１つのグループを形成し、１つのグループには、代表端末は１つだけ存在する。
【０１３５】
グループ化は、比較的近くの位置に設置されている端末同士を１つのグループとして設定するものであり、たとえば、図２０のように、同じ拠点に属する複数の端末は、１つのグループに属するものとして扱う。
また、同一ルータあるいは同一中継サーバの配下のネットワークに属する複数の端末を、１つのグループに属するものとして扱ってもよく、さらに、ＩＰアドレスを構成する数字列のうち、特定の数字列部分が同一の端末（同一ドメイン内の端末）を１つのグループに属するものとして扱ってもよい。
以下の説明では、同一拠点ＩＤを持つ複数の端末は、同一のグループに属するものとして扱うことにする。
【０１３６】
また、図２０の場合、同一拠点に含まれる２つの端末は、１つのグループに属する端末とみなされ、サーバから見た場合、そのグループに属する代表端末のみがサーバに接続されているかのように扱われる。すなわち、サーバから映像音声等の情報を送信する場合、サーバから、同一拠点（同一グループ）に属する代表端末のみにその情報が直接送信され、その同一拠点に属する代表端末でない端末にはサーバから直接送信されない。
代表端末でない端末には、原則として、同一拠点に属する代表端末から、ストリーミング配信で、情報を送信するものとする。
【０１３７】
また、同一拠点すなわち、１つのグループに属する端末が複数ある場合は、アイドル状態ではない端末、すなわち現在アクティブモードである端末のうち１つの端末が代表端末として選択される。
ただし、１つのグループに属する端末の中に、アクティブモードである端末が１つもない場合は、アイドル状態である端末（たとえば、スリープモードの端末）の中から、１つの端末が代表端末として選択される。
さらに、代表端末となっていた端末がアイドル状態となってしまった場合は、同一拠点内のアクティブモードである他の端末を代表端末に変更し、変更後の代表端末からストリーミング配信を受けるようにしてもよい。
【０１３８】
また、同一拠点の中に、１つしか端末が存在しない場合において、その端末がアイドル状態となった場合、他の拠点に属する代表端末から、ストリーミング配信を受けるようにしてもよい。
あるいは、アイドル状態となった端末自身が、実質的に代表端末となり、サーバから、ストリーミング配信を受けるようにしてもよい。
また、同一拠点内の代表端末は、原則として同じグループ内に属する他の端末に対してのみストリーミング配信を行うが、他の拠点に属する端末ＴＥｎからストリーミング配信の要求を受けた場合は、代表端末は、他の拠点のその端末ＴＥｎに対して、ストリーミング配信をしてもよい。
【０１３９】
まず、第３実施例における端末とサーバ間の情報配信の概略について説明する。
図２６に、第３実施例におけるサーバ端末間通信状態の１つであるアクティブモードの説明図を示す。
図２６では、１つのサーバに対して、４台の端末（ＴＥ１〜ＴＥ４）が接続されるものとする。
ここでは、４台の端末（ＴＥ１〜ＴＥ４）は、すべてアクティブモードＭ１であるとし、端末ＴＥ１とＴＥ２とが、同一拠点に属し、同じ拠点ＩＤを持ち、グループ化されているものとする。
また、４つの端末は、いずれもまだ代表端末とはなっておらず、したがって各端末の代表端末フラグは、すべて「ＯＦＦ」であるとする。
【０１４０】
このように、すべての端末がアクティブモードＭ１である場合、サーバと各端末間の通信は、いずれも双方向通信状態にあり、各端末（ＴＥ１〜ＴＥ４）からサーバへは、その端末のエンコードされた自画像（ＳＤ１〜ＳＤ４）が送信され、サーバにおいて、４つの自画像が受信されデコード，リサイズ，ミキシング，エンコードという一連の処理が実行されて、合成された画像（ＲＤ１〜ＲＤ４）が、各端末（ＴＥ１〜ＴＥ４）へ配信される。
したがって、同一拠点に２つの端末（ＴＥ１，ＴＥ２）が属する場合であっても、その２つの端末（ＴＥ１，ＴＥ２）は、それぞれ、サーバに対して双方向通信を行う。
この状態はサーバに最も負荷がかかり、伝送遅延や通信障害が起こりやすい状態であると言える。
【０１４１】
図２７に、第３実施例のサーバ端末間通信状態において、端末ＴＥ１がスリープモードＭ２になった場合の説明図を示す。
ここでは、端末ＴＥ１において、利用者が不在となりアイドル状態が検出され、アクティブモードＭ１からスリープモードＭ２になり、端末ＴＥ１とサーバとの直接通信は行われない。
この場合、端末ＴＥ１と同一拠点（同一グループ）に属する端末であって、アクティブモードである端末ＴＥ２が、そのグループの代表端末となる。
そして、スリープモードＭ２となった端末ＴＥ１は、代表端末ＴＥ２からストリーミング配信を受ける。
【０１４２】
代表端末ＴＥ２は、サーバで生成された受信画像ＲＤ２を受信し、この受信画像ＲＤ２をそのまま端末ＴＥ１へストリーミング配信する。すなわち受信画像ＲＤ２と同じ画像ＲＤ１を配信する。
端末ＴＥ１は、スリープモードＭ２なので、自画像ＳＤ１を送信することなく、端末ＴＥ２から送られてくる情報ＲＤ１をストリーミング受信するだけである。
ここで、サーバは端末ＴＥ１の自画像ＳＤ１は送信されてこないので、サーバで生成される合成画像は、自画像ＳＤ１は含まれず、３つの端末（ＴＥ２，ＴＥ３，ＴＥ４）から送られてきた自画像（ＳＤ２，ＳＤ３，ＳＤ４）を一画面に分割表示できるようにした画像である。
【０１４３】
図２７の場合、サーバから見ると、図２６の場合に比べて、直接接続され、かつ双方向通信を行う端末が１台少なくなり、サーバと端末間で行われる通信データ量が減少し、合成すべき画像も４つから３つに減少するので、サーバでデコード等を行う必要のあるデータ量も少なくなる。
すなわち、共有情報である受信画像を受信する端末は４台であるが、サーバに直接接続される端末は３台となり実質的に減少するので、通信されるデータ量が減少することにより、伝送遅延が少なくなり、通信障害の発生も少なくなり、会議の円滑な進行が可能となる。
【０１４４】
図２８に、第３実施例のサーバ端末間通信状態において、端末ＴＥ１とＴＥ２とが、どちらもスリープモードＭ２となった場合の説明図を示す。
ここでは、同一拠点内のすべての端末（ＴＥ１，ＴＥ２）が、スリープモードＭ２となったので、端末ＴＥ２は、代表端末になったままで、サーバからのストリーミング配信を受ける。
さらに、端末ＴＥ１は、サーバと直接通信は行わず、代表端末ＴＥ２からストリーミング配信を受ける。
端末ＴＥ３とＴＥ４とは、どちらもアクティブモードＭ１であるので、サーバとの間では双方向通信が行われ、各端末の自画像（ＳＤ３，ＳＤ４）がサーバへ送信される。スリープモードＭ２となった端末ＴＥ１とＴＥ２からの自画像（ＳＤ１，ＳＤ２）はサーバへは送信されない。
したがって、サーバから３つの端末（ＴＥ２，ＴＥ３，ＴＥ４）へ送られる受信画像（ＲＤ２，ＲＤ３，ＲＤ４）は、２つの自画像（ＳＤ３，ＳＤ４）が含まれるものである。
端末ＴＥ１へ配信される受信画像ＲＤ１は、端末ＴＥ２が受信した画像ＲＤ２と同じものである。
【０１４５】
この場合、サーバと双方向通信を行う端末は２台となり、サーバからのストリーミング配信を受ける端末は１台となり、サーバと端末間で行う通信のデータ量は、図２７の場合より少なくなる。
また、サーバでデコード等の一連の処理をすべきデータも２つの自画像（ＳＤ３，ＳＤ４）となるので、その処理にかかる負荷も少なくなる。
したがって、サーバから、共有情報である受信画像を受信する端末は４台のままであるが、サーバと直接通信を行う端末は３台となり、さらにそのうちの１台の端末（ＴＥ２）は、一方向通信であるストリーミング受信のみをする端末であるので、伝送遅延や通信障害を低減でき、サーバの負荷も少なくすることができる。
【０１４６】
図２９に、第３実施例のサーバ端末間通信状態において、端末ＴＥ４が、スリープモードＭ２となった場合の説明図を示す。
ここでは、同一拠点に属する２つの端末（ＴＥ１，ＴＥ２）と、もう一台の端末ＴＥ３とが、アクティブモードＭ１であり、それぞれ、サーバと双方向通信を行っているものとする。
端末ＴＥ４のみがスリープモードＭ２となっており、端末ＴＥ４が属する同一グループには、他に端末が存在しないとする。
すなわち、同一拠点（同一グループ）に、１台の端末ＴＥ４しか存在しないとする。この場合、同一グループ内に他に代表端末となるべき端末がないので、端末ＴＥ４は自ら代表端末となり、サーバからストリーミング配信を受ける。端末４は、スリープモードＭ２となっているので、その自画像ＳＤ４を送信することなく、サーバから受信画像ＲＤ４をストリーミング受信する。
したがって、サーバに送信される自画像は、３つの端末（ＴＥ１，ＴＥ２，ＴＥ３）からの自画像（ＳＤ１，ＳＤ２，ＳＤ３）であるので、サーバから送信される合成画像（ＲＤ１〜ＲＤ４）は、この３つの自画像を含むものとなる。
【０１４７】
図２９の場合、同一拠点（同一グループ）内に１つの端末しかない場合において、その端末がスリープモードＭ２となってしまった場合、サーバからのストリーミング配信を受けることにより、受信画像ＲＤ４を表示部に表示させることができる。
また、スリープモードＭ２となった端末ＴＥ４については、双方向通信からストリーミング配信を受ける一方向通信に切りかえられるので、データ伝送量を少なくすることができ、サーバの負荷の軽減と、伝送遅延の減少および通信障害の減少を図ることができる。
【０１４８】
図３０に、第３実施例のサーバ端末間通信状態において、３台の端末ＴＥ１，ＴＥ２，ＴＥ４が、スリープモードとなった場合の説明図を示す。
ここでは、図２８に示したのと同様に、同一拠点内に属するすべての端末（ＴＥ１，ＴＥ２）が、スリープモードＭ２となっているので、一方の端末ＴＥ２が代表端末となり、サーバからストリーミング配信を受ける。他方の端末ＴＥ１は、この代表端末ＴＥ２からストリーミング配信を受ける。
【０１４９】
また、図２９に示したのと同様に、同一拠点に１つの端末しかない端末ＴＥ４もスリープモードＭ２となっているが、図３０では、端末ＴＥ４は、サーバからストリーミング配信を受けるのではなく、代表端末ＴＥ２から、ストリーミング配信を受けるようにした場合を示している。
したがって、代表端末ＴＥ２は、まず、サーバからのストリーミング配信を受け、さらに、２つの端末（ＴＥ１，ＴＥ４）に対して、ストリーミング配信を行っている。
この場合、アクティブモードＭ１である端末は、ＴＥ３のみであるので、サーバに送信される自画像は、端末ＴＥ３からの画像ＳＤ３のみであり、サーバから端末に送信される合成画像（ＲＤ１〜ＲＤ４）は、端末ＴＥ３の自画像ＳＤ３を含むものである。
【０１５０】
この場合、サーバに直接接続される端末は２台となり、そのうち１台の端末（ＴＥ３）が双方向通信を行い、もう１台の端末（ＴＥ２）は、ストリーミング配信を行う一方向通信の端末である。
したがって、共有情報である受信画像（ＲＤ１〜ＲＤ４）は、４台の端末で表示されるが、サーバに直接接続される端末の数は実質的に２台となり、サーバと端末間で通信されるデータ量を減少させることができる。
【０１５１】
また、サーバで受信される自画像も、１台の端末ＴＥ３からのみであり、合成画像を生成するのにかかるサーバの負荷も少なくすることができる。
したがって、図３０の場合、代表端末からストリーミング配信を行う相手の端末を、同一拠点に属する他の端末と、他の拠点に属する端末にすることにより、サーバに直接接続される端末の数をより少なくすることができ、サーバの負荷の減少、伝送遅延の減少、および通信障害の減少を図ることができる。
【０１５２】
図２５に、第３実施例における端末とサーバ間の通信シーケンスの概略説明図を示す。
図２５（ａ）は、端末ＴＥ１がアクティブモードＭ１であり、サーバと端末ＴＥ１とが双方向通信を行っている場合を示している。これは、図８（ａ）と同様である。
図２５（ｂ）は、端末ＴＥ１がスリープモードＭ２となった場合のシーケンスを示している。
ここで、図２６に示すように、端末ＴＥ１と端末ＴＥ２とが同一拠点（同一グループ）に属するものとする。このシーケンスは、図２７の通信状態となる場合を示している。
【０１５３】
まず、スリープモードＭ２となった端末ＴＥ１から、サーバに対して、端末ＴＥ１がスリープモードＭ２になったことを示す端末状態通知を送信する。この通知により、端末ＴＥ１とサーバとの間の通信は双方向通信状態から、片方向通信状態（端末ＴＥ１からの映像、音声データをサーバ側で処理しない状態）にする。
さらに、端末ＴＥ１から、サーバに対して、代表端末を検出してもらうことを要求する情報を送信する（代表端末検出要求の送信）。
この検出要求を受信したサーバは、サーバの記憶部に記憶された端末データベース１４２を利用して、端末ＴＥ１とグループ化できる代表端末があるか否か調べる。図２６の場合、端末ＴＥ１とＴＥ２とが同一拠点にあるので、この２つの端末が、同一グループにグループ化される。また、端末ＴＥ２がアクティブモードＭ１であったとすると、代表端末として端末ＴＥ２が検出される。
【０１５４】
代表端末として端末ＴＥ２を選択することができるので、サーバは端末データベース１４２の中の端末ＴＥ２の代表端末フラグを「ＯＮ」に設定し、端末ＴＥ１に対して、代表端末検出通知を送信する。
この代表端末検出通知では、代表端末とした端末ＴＥ２の装置ＩＤとＩＰアドレスとが通知される。
その後、この通知を受信した端末ＴＥ１は、端末ＴＥ２に対して、ストリーミング要求を送信する。
【０１５５】
ストリーミング要求を受信した端末ＴＥ２は、この要求を検出すると、サーバから送られてきた受信画像ＲＤ２を、端末ＴＥ１に対してストリーミング配信する。
すなわち、端末ＴＥ１は、サーバとの通信は行わず、端末ＴＥ２との間で、画像音声等の情報を含むストリーミング配信による片方向通信を行う（ストリーミング受信）。
これにより、スリープモードＭ２となった端末ＴＥ１は、共有情報を受信することができる。
【０１５６】
図２５（ｃ）は、サーバで代表端末が検出されなかった場合のシーケンスを示している。これはつまり、端末ＴＥ１がスリープモードＭ２となったため、サーバに対して代表端末検出要求を行ったが、サーバで代表端末の検出ができなかった場合である。
このとき、サーバから端末ＴＥ１に対して、代表端末の未検出通知が送信される。
この未検出通知を受けた端末ＴＥ１は、自らを代表端末に設定し、端末ＴＥ１を代表端末に移行したことを示す端末状態通知（代表端末モードへの移行）を、サーバに送信する。
この通知を受けたサーバは、端末ＴＥ１の動作モードが代表端末になったことを検出して、端末ＴＥ１の代表端末フラグを「ＯＮ」に設定する。
その後、サーバは、端末ＴＥ１に対して、ストリーミング配信を行う。これにより、端末ＴＥ１は、サーバからの片方向通信により、共有情報を受信するストリーミング受信をする。
【０１５７】
この図２５（ｃ）は、図２９の状態に相当する。
この場合は、端末ＴＥ１がスリープモードＭ２となったため、サーバとの通信が双方向通信から片方向通信に切りかわるが、さらにその片方向通信が、サーバからのストリーミング配信となる。
ストリーミング受信をする端末ＴＥ１では、所定の通信プロトコルによる双方向通信時のように受信画像のデコードをする必要はなく、その端末ＴＥ１の負荷を少なくすることができる。
【０１５８】
図２１に、第３実施例における端末のグループ化処理のフローチャートを示す。
ここでのグループ化処理は、主として、アイドル状態判定処理と、スリープモード移行処理と、代表端末検出要求処理と、ストリーミング受信処理とからなる。
スリープモードＭ２へ移行した端末は、同一拠点内に代表端末となるべき他の端末が存在する場合には、その代表端末からストリーミング配信を受け、代表端末となるべき端末が存在しない場合は、自らが代表端末となり、サーバからストリーミング配信を受ける。
【０１５９】
図２１のステップＳ１０１において、端末の初期状態がアクティブモードＭ１であったとする。
ステップＳ１０２において、端末状態通知部８５が、現在の端末の動作モード（アクティブモード）を、サーバへ通知する。
ステップＳ１０３において、アイドル状態判定部８１が、自己の端末の状態がアイドル状態となっているか否か判定する（アイドル状態判定処理）。
図２３に、この第３実施例のアイドル状態判定処理の詳細フローチャートを示す。ただし、図２３のフローは、図１０に示したものと同一なので、説明を省略する。
【０１６０】
ステップＳ１０４において、端末がアイドル状態であると判定された場合、ステップＳ１０５へ進み、端末モード切替部８６がスリープモード移行処理を行う。
スリープモードへの移行処理は、上記したステップＳ５と同様の処理である。
ステップＳ１０６において、サーバに対し、現在の動作モードがスリープモードＭ２になったことを示す端末状態通知を、送信する。
【０１６１】
ステップＳ１０７において、代表端末検出要求部８８が、サーバに対して、代表端末検出要求を送信する。
この要求を受信したサーバは、代表端末を検出する処理を行い、代表端末を検出した場合は、代表端末を検出したことを示す通知を、この端末へ送信する。一方、代表端末が検出されない場合は、未検出であったことを示す通知を端末へ送信する。
ステップＳ１０８において、サーバからの通知により、代表端末が検出されたか否か、チェックする。
代表端末が検出されたという通知を受けた場合は、ステップＳ１０９へ進み、そうでない場合はステップＳ１１３へ進む。
【０１６２】
ステップＳ１０９において、ストリーミング要求部８９が、代表端末に対し、ストリーミングの配信を要求する情報を送信する。
この要求情報を受信した代表端末は、ストリーミング配信部９１によって、ストリーミング情報を、その端末に対して配信する。
【０１６３】
ステップＳ１１０において、ストリーミング受信部９０が、代表端末から送られてくるストリーミング情報を受信する。
ステップＳ１１１において、再度ステップＳ１０７と同じ代表端末検出要求処理を行う。これは、今まで代表端末であった端末が、代表端末でなくなっていないか、あるいは代表端末が変更されていないかをチェックするための処理である。
ステップＳ１１２において、サーバからの通知により、代表端末が検出された場合は、処理を終了し、そうでない場合は、ステップＳ１１３へ進む。
【０１６４】
ステップＳ１１３において、他に代表端末となるべき端末がなかったので、自らが代表端末に移行する処理を行う。すなわち、その端末の動作モードを、スリープモードから、代表端末モードに移行する。
代表端末となった端末は、他の端末に対して、ストリーミング配信を行える端末となる。また、代表端末となった端末は、サーバからの片方向通信により、ストリーミング情報を受信する。
【０１６５】
ステップＳ１１４において、サーバに対して、自端末の動作モードが代表端末モードになったことを示す端末状態通知を、送信する。
ステップＳ１１５において、サーバから送られてくるストリーミング情報を受信するストリーミング受信を行う。
ストリーミング受信された情報は、代表端末の表示部に表示するとともに、グループ化された同一拠点内の他の端末に対して、その受信情報を、ストリーミング配信する。
【０１６６】
図２２に、第３実施例において、代表端末となった端末のストリーミング配信処理の概略フローチャートを示す。
ステップＳ１２１において、他の端末から、ストリーミング配信要求を受信したか否か、チェックする。
受信した場合は、ステップＳ１２２へ進み、要求を送信してきた端末に対し、受信したストリーミング情報のストリーミング配信を行う。
【０１６７】
図２４に、第３実施例のサーバにおける端末状態検出制御処理のフローチャートを示す。
ステップＳ１３１において、端末状態判断部１６２が、端末から端末状態情報を受信したか否かチェックする。
受信した場合は、ステップＳ１３２へ進み、そうでない場合はステップＳ１３１をループする。
ステップＳ１３２において、端末から受信した端末状態が、アクティブモードか否か、チェックする。
アクティブモードの場合、ステップＳ１３３へ進み、そうでない場合は、ステップＳ１３４へ進む。
ステップＳ１３３において、通信方法切替部１６３が、サーバと端末との通信状態を、アクティブモードで行われる双方向通信状態に切り替える。
ステップＳ１３４において、受信した端末状態がスリープモードか否か、チェックする。
スリープモードの場合、ステップＳ１３５へ進み、そうでない場合、ステップＳ１３９へ進む。
【０１６８】
ステップＳ１３５において、代表端末検出部１６９が、代表端末検出処理を行う。
ここでは、記憶部１４１の端末データベース１４２をチェックし、端末が属する拠点ＩＤ１４４と同一の拠点ＩＤを持つ他の端末があるか否かチェックする。
同一拠点ＩＤを持つ端末が他に存在する場合、その端末がアクティブモードであれば、その端末を代表端末に設定し、代表端末が検出されたと判断する。
すなわち、その端末の代表端末フラグ１５０を「ＯＮ」にする。
また、同一拠点ＩＤを持つ端末の中に、すでに代表端末フラグ１５０が「ＯＮ」となっているものがあれば、代表端末が検出されたと判断する。
さらに、同一拠点ＩＤを持つ端末が、他に１つもない場合は、代表端末がなかったと判断する。
【０１６９】
ステップＳ１３６において、代表端末が検出された場合、ステップＳ１３８へ進み、そうでない場合、ステップＳ１３７へ進む。
ステップＳ１３８において、端末データベース１４２から、代表端末の装置ＩＤとＩＰアドレスを読み出し、代表端末検出通知を作成し、スリープモードとなった端末に対して、送信する。
ステップＳ１３７において、代表端末が未検出であったことを示す情報を、スリープモードとなった端末へ送信する。
【０１７０】
ステップＳ１３９において、受信した端末状態が、代表端末モードであるか否か、チェックする。
代表端末モードであれば、ステップＳ１４０へ進み、そうでない場合は、処理を終了する。
ステップＳ１４０において、代表端末モードになっている端末を、代表端末として設定する処理を行う。具体的には、端末データベース１４２の中のその端末に対する代表端末フラグ１５０を、「ＯＮ」に設定する。
ステップＳ１４１において、ストリーミング配信部１７０は、代表端末となっている端末に対し、デコード等の処理をした後の映像や音声などの共有情報を、ストリーミング配信する。
なお、端末の代表端末フラグ１５０は、初期状態では、すべて「ＯＦＦ」とし、図示していないが、たとえば、端末の電源切断等の理由で代表端末でなくなった場合は、その端末の代表端末フラグを「ＯＦＦ」に設定する。
【０１７１】
以上が、第３実施例における端末とサーバの処理内容であるが、サーバに接続された端末数が５台以上の場合や、同一拠点（同一グループ）に属する端末の数が３台以上の場合もあるので、グループ化のパターンは、図２６から図３０に示したものに限るものではなく、他のパターンも考えられる。
ただし、いずれの場合も、グループ化された端末群の中に、１つの代表端末を設定し、その代表端末のみをサーバに直接接続可能な端末とし、サーバから双方向通信やストリーミング配信を受けるようにしているので、サーバに接続される実質的な端末の数を減少させることができ、接続端末数の減少によって、伝送遅延の減少と、通信障害の減少と、サーバの負荷の軽減を図ることができる。
【符号の説明】
【０１７２】
１ サーバ
２ 情報端末（端末）
１１ 入力部
１２ キーボード
１３ マウス
１４ タブレット
１５ 人検知センサ
１６ 入力処理部
２１ 映像入力部
２２ カメラ
２３ 映像処理部
３１ 表示部
３２ ディスプレイ
３３ 表示処理部
４１ 音声入力部
４２ マイク
４３ 入力音声処理部
４５ 音声出力部
４６ スピーカ
４７ 出力音声処理部
５１ 通信部
５２ 通信暗号部
５３ 通信復号部
５５ 認証部
６１ 記憶部
６２ 認識データベース
６３ ユーザ名
６４ 音声特徴データ
６５ 顔画像特徴データ
６６ 入力映像
６７ 入力音声
７１ 信号処理部
７２ 映像符号化部
７３ 映像復号化部
７４ 音声符号化部
７５ 音声復号化部
８０ 制御部
８１ アイドル状態判定部
８２ 時間計測部
８３ 入力信号検知部
８４ 人物認識部
８５ 端末状態通知部
８６ 端末モード切替部
８７ 端末モード変更受付部
８８ 代表端末検出要求部
８９ ストリーミング要求部
９０ ストリーミング受信部
９１ ストリーミング配信部
１０１ 入力部
１０２ キーボード
１０３ マウス
１０４ タブレット
１０５ 入力処理部
１１１ 表示部
１１２ ディスプレイ
１１３ 表示処理部
１２１ 通信部
１２２ 通信暗号部
１２３ 通信複号部
１２５ 認証部
１３１ ＭＣＵ部
１３２ 映像ミキシング部
１３３ 映像リサイズ部
１３４ 音声ミキシング部
１４１ 記憶部
１４２ 端末データベース
１４３ 装置ＩＤ
１４４ 拠点ＩＤ
１４５ ＩＰアドレス
１４６ ユーザデータベース
１４７ ユーザＩＤ
１４８ メールアドレス
１４９ 認識データベース
１５０ 代表端末フラグ
１５１ 信号処理部
１６１ 制御部
１６２ 端末状態判断部
１６３ 通信方法切替部
１６４ 端末モード制御部
１６５ アイドル状態判定部
１６６ 時間計測部
１６７ 入力信号検知部
１６８ 人物認識部
【特許請求の範囲】
【請求項１】
サーバと、複数の情報端末とがネットワークを介して接続され、
前記情報端末において入力された情報をサーバに送信し、
前記サーバが、各情報端末から送信された情報を用いて共有情報を生成し、前記共有情報を前記情報端末へ配信する情報共有システムであって、
前記情報端末が、その情報端末を利用者が使用状態であることを示す状態情報を生成する情報入力部と、
前記情報入力部によって生成された状態情報に基づいて、情報端末が使用されていない可能性のあるアイドル状態であることを判定するアイドル状態判定部と、
アイドル状態であることが判定された場合に、情報端末の現在の動作状態に対応して、段階的に動作状態を変更する端末モード切替部と、
情報端末の現在の動作状態を、サーバへ送信する端末状態通知部と、
アイドル状態であると判定された場合に、サーバに、同一拠点内の代表端末の検出を要求する検出要求を送信し、かつサーバから代表端末の情報を受信する代表端末検出要求部と、
アイドル状態であると判定された場合に、サーバあるいは前記代表端末から配信されるストリーミング情報を受信するストリーミング受信部とを備え、
前記サーバが、前記情報端末から送信されてきた動作状態に基づいてその情報端末との通信方法を切り替える通信方法切替部と、
第１の情報端末から代表端末の検出要求を受信した場合に、前記第１の情報端末と同一の拠点に属する情報端末の中から代表端末を検出し、その代表端末の情報を前記第１の情報端末に送信する代表端末検出部と、
情報端末にストリーミング情報を送信するストリーミング配信部とを備え、
前記情報端末の動作状態に従って、各情報端末ごとにサーバと各情報端末との間の通信状態を変更させることを特徴とする情報共有システム。
【請求項２】
前記代表端末検出部が、前記代表端末を検出できた場合に、前記第１の情報端末のストリーミング受信部は、検出された代表端末から、ストリーミング情報を受信することを特徴とする請求項１の情報共有システム。
【請求項３】
前記代表端末検出部が、前記第１の情報端末と同一拠点に属する代表端末を検出できなかった場合、代表端末の未検出通知を、前記第１の情報端末に送信し、
前記第１の情報端末が、前記未検出通知を受信した場合、前記第１の情報端末の端末状態通知部が、自己が代表端末となることをサーバに通知し、その後、ストリーミング受信部は、サーバから、ストリーミング情報を受信することを特徴とする請求項１の情報共有システム。
【請求項４】
前記同一拠点内の代表端末は、前記第１の情報端末と同一グループに属する情報端末として予め設定された情報端末の中から、選択されることを特徴とする請求項１乃至３のいずれかの情報共有システム。
【請求項５】
前記同一グループに属する情報端末は、同一の拠点ＩＤを持つ情報端末、同一ルータに接続されそのルータの配下のネットワークに属する情報端末、および同一ドメイン内の情報端末のいずれかであることを特徴とする請求項４の情報共有システム。
【請求項６】
前記代表端末は、前記第１の情報端末と同一の拠点ＩＤを持ち、アイドル状態ではない情報端末であることを特徴とする請求項５の情報共有システム。
【請求項７】
前記情報端末の動作状態は、サーバと映像および音声の双方向通信を行う第１モード、サーバから映像および音声を含む情報を受信して片方向通信を行う第２モード、情報端末の主機能を停止してサーバとの通信を中止した状態の第３モード、情報端末の電源を切断した状態の第４モードを含み、
前記アイドル状態判定処理により、アイドル状態であることが検出されるごとに、情報端末の動作状態を前記第１モードから第４モードの順に段階的に変更させることを特徴とする請求項１乃至６のいずれかの情報共有システム。
【請求項８】
前記情報入力部は、
利用者の操作による入力信号を入力する入力部と、カメラにより撮影された映像を入力する映像入力部と、マイクから音声を入力する音声入力部とを備え、
前記入力信号、入力映像および入力音声を用いて、前記状態情報を生成することを特徴とする請求項１乃至７のいずれかの情報共有システム。
【請求項９】
前記アイドル状態判定部は、
所定の設定時間中に継続して、前記入力信号の入力がないこと、前記入力音声の入力がないこと、および前記入力映像に所定の変化がないことのいずれかが検出された場合、その情報端末が使用されていない可能性があるアイドル状態であると判定することを特徴とする請求項８の情報共有システム。
【請求項１０】
利用者の音声特徴データと、利用者の顔の特徴を示す顔画像特徴データを含む認識データベースを記憶した記憶部と、
前記入力音声と音声特徴データとを用いた音声認識と、前記入力映像と顔画像特徴データとを用いた画像認識とを利用して、利用者を特定する人物認識を行う人物認識部とをさらに備え、
前記アイドル状態判定部は、所定の設定時間中に継続して、前記人物認識部により人物認識が失敗した場合に、その情報端末が使用されていない可能性があるアイドル状態であると判定することを特徴とする請求項８または９の情報共有システム。
【請求項１１】
サーバと、複数の情報端末とがネットワークを介して接続され、
前記情報端末において入力された情報をサーバに送信し、
前記サーバが、各情報端末から送信された情報を用いて共有情報を生成し、前記共有情報を前記情報端末へ配信する情報共有システムの情報共有方法であって、
前記情報端末が、その情報端末を利用者が使用状態であることを示す状態情報を生成する情報入力ステップと、
前記状態情報に基づいて、情報端末が使用されていない可能性のあるアイドル状態であるか否かを判定するアイドル状態判定ステップと、
アイドル状態であると判定された場合に、情報端末の現在の動作状態に対応して、段階的に所定の動作状態に変更する端末モード切替ステップと、
情報端末の現在の動作状態を、サーバへ送信する端末状態通知ステップと、
アイドル状態であると判定された第１の情報端末が、サーバに、同一拠点内の代表端末の検出を要求する検出要求送信ステップと、
前記サーバが、前記代表端末の検出要求を受信した場合に、検出要求を送信してきた前記第１の情報端末と同一の拠点に属する情報端末の中から代表端末を検出するステップと、検出された代表端末の情報を前記第１の情報端末に送信するステップと、
前記第１の情報端末が、受信した代表端末の情報を用いて、その代表端末に、ストリーミング配信を要求する配信要求送信ステップと、
前記代表端末が、受信した配信要求に基づいて、前記第１の情報端末に、ストリーミング情報を送信するステップとを備えたことを特徴とする情報共有方法。
【請求項１２】
コンピュータに、前記請求項１１に記載した情報共有方法の各ステップを実行させるための情報共有システムのプログラム。
【請求項１】
サーバと、複数の情報端末とがネットワークを介して接続され、
前記情報端末において入力された情報をサーバに送信し、
前記サーバが、各情報端末から送信された情報を用いて共有情報を生成し、前記共有情報を前記情報端末へ配信する情報共有システムであって、
前記情報端末が、その情報端末を利用者が使用状態であることを示す状態情報を生成する情報入力部と、
前記情報入力部によって生成された状態情報に基づいて、情報端末が使用されていない可能性のあるアイドル状態であることを判定するアイドル状態判定部と、
アイドル状態であることが判定された場合に、情報端末の現在の動作状態に対応して、段階的に動作状態を変更する端末モード切替部と、
情報端末の現在の動作状態を、サーバへ送信する端末状態通知部と、
アイドル状態であると判定された場合に、サーバに、同一拠点内の代表端末の検出を要求する検出要求を送信し、かつサーバから代表端末の情報を受信する代表端末検出要求部と、
アイドル状態であると判定された場合に、サーバあるいは前記代表端末から配信されるストリーミング情報を受信するストリーミング受信部とを備え、
前記サーバが、前記情報端末から送信されてきた動作状態に基づいてその情報端末との通信方法を切り替える通信方法切替部と、
第１の情報端末から代表端末の検出要求を受信した場合に、前記第１の情報端末と同一の拠点に属する情報端末の中から代表端末を検出し、その代表端末の情報を前記第１の情報端末に送信する代表端末検出部と、
情報端末にストリーミング情報を送信するストリーミング配信部とを備え、
前記情報端末の動作状態に従って、各情報端末ごとにサーバと各情報端末との間の通信状態を変更させることを特徴とする情報共有システム。
【請求項２】
前記代表端末検出部が、前記代表端末を検出できた場合に、前記第１の情報端末のストリーミング受信部は、検出された代表端末から、ストリーミング情報を受信することを特徴とする請求項１の情報共有システム。
【請求項３】
前記代表端末検出部が、前記第１の情報端末と同一拠点に属する代表端末を検出できなかった場合、代表端末の未検出通知を、前記第１の情報端末に送信し、
前記第１の情報端末が、前記未検出通知を受信した場合、前記第１の情報端末の端末状態通知部が、自己が代表端末となることをサーバに通知し、その後、ストリーミング受信部は、サーバから、ストリーミング情報を受信することを特徴とする請求項１の情報共有システム。
【請求項４】
前記同一拠点内の代表端末は、前記第１の情報端末と同一グループに属する情報端末として予め設定された情報端末の中から、選択されることを特徴とする請求項１乃至３のいずれかの情報共有システム。
【請求項５】
前記同一グループに属する情報端末は、同一の拠点ＩＤを持つ情報端末、同一ルータに接続されそのルータの配下のネットワークに属する情報端末、および同一ドメイン内の情報端末のいずれかであることを特徴とする請求項４の情報共有システム。
【請求項６】
前記代表端末は、前記第１の情報端末と同一の拠点ＩＤを持ち、アイドル状態ではない情報端末であることを特徴とする請求項５の情報共有システム。
【請求項７】
前記情報端末の動作状態は、サーバと映像および音声の双方向通信を行う第１モード、サーバから映像および音声を含む情報を受信して片方向通信を行う第２モード、情報端末の主機能を停止してサーバとの通信を中止した状態の第３モード、情報端末の電源を切断した状態の第４モードを含み、
前記アイドル状態判定処理により、アイドル状態であることが検出されるごとに、情報端末の動作状態を前記第１モードから第４モードの順に段階的に変更させることを特徴とする請求項１乃至６のいずれかの情報共有システム。
【請求項８】
前記情報入力部は、
利用者の操作による入力信号を入力する入力部と、カメラにより撮影された映像を入力する映像入力部と、マイクから音声を入力する音声入力部とを備え、
前記入力信号、入力映像および入力音声を用いて、前記状態情報を生成することを特徴とする請求項１乃至７のいずれかの情報共有システム。
【請求項９】
前記アイドル状態判定部は、
所定の設定時間中に継続して、前記入力信号の入力がないこと、前記入力音声の入力がないこと、および前記入力映像に所定の変化がないことのいずれかが検出された場合、その情報端末が使用されていない可能性があるアイドル状態であると判定することを特徴とする請求項８の情報共有システム。
【請求項１０】
利用者の音声特徴データと、利用者の顔の特徴を示す顔画像特徴データを含む認識データベースを記憶した記憶部と、
前記入力音声と音声特徴データとを用いた音声認識と、前記入力映像と顔画像特徴データとを用いた画像認識とを利用して、利用者を特定する人物認識を行う人物認識部とをさらに備え、
前記アイドル状態判定部は、所定の設定時間中に継続して、前記人物認識部により人物認識が失敗した場合に、その情報端末が使用されていない可能性があるアイドル状態であると判定することを特徴とする請求項８または９の情報共有システム。
【請求項１１】
サーバと、複数の情報端末とがネットワークを介して接続され、
前記情報端末において入力された情報をサーバに送信し、
前記サーバが、各情報端末から送信された情報を用いて共有情報を生成し、前記共有情報を前記情報端末へ配信する情報共有システムの情報共有方法であって、
前記情報端末が、その情報端末を利用者が使用状態であることを示す状態情報を生成する情報入力ステップと、
前記状態情報に基づいて、情報端末が使用されていない可能性のあるアイドル状態であるか否かを判定するアイドル状態判定ステップと、
アイドル状態であると判定された場合に、情報端末の現在の動作状態に対応して、段階的に所定の動作状態に変更する端末モード切替ステップと、
情報端末の現在の動作状態を、サーバへ送信する端末状態通知ステップと、
アイドル状態であると判定された第１の情報端末が、サーバに、同一拠点内の代表端末の検出を要求する検出要求送信ステップと、
前記サーバが、前記代表端末の検出要求を受信した場合に、検出要求を送信してきた前記第１の情報端末と同一の拠点に属する情報端末の中から代表端末を検出するステップと、検出された代表端末の情報を前記第１の情報端末に送信するステップと、
前記第１の情報端末が、受信した代表端末の情報を用いて、その代表端末に、ストリーミング配信を要求する配信要求送信ステップと、
前記代表端末が、受信した配信要求に基づいて、前記第１の情報端末に、ストリーミング情報を送信するステップとを備えたことを特徴とする情報共有方法。
【請求項１２】
コンピュータに、前記請求項１１に記載した情報共有方法の各ステップを実行させるための情報共有システムのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【公開番号】特開２０１１−１１４６９９（Ｐ２０１１−１１４６９９Ａ）
【公開日】平成２３年６月９日（２０１１．６．９）
【国際特許分類】
【出願番号】特願２００９−２７０５２１（Ｐ２００９−２７０５２１）
【出願日】平成２１年１１月２７日（２００９．１１．２７）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
【公開日】平成２３年６月９日（２０１１．６．９）
【国際特許分類】
【出願日】平成２１年１１月２７日（２００９．１１．２７）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
[ Back to top ]