以下、図面を参照して、本発明の実施の形態の一例について説明する。
まず図1を参照して、本発明の実施形態における、情報処理システムの構成の一例について説明する。
本発明のウェブ会議システムは、例えば、パーソナルコンピュータを適用可能な情報処理装置であるクライアント端末100(100G1、100G2、100S)と各クライアント端末でウェブ会議システムを利用可能にするウェブ会議サーバ200(サーバ装置(情報処理装置の1つ))がネットワーク150を介して通信可能に接続され、構成されている。
ウェブ会議サーバ200は、ウェブブラウザを利用したウェブ会議を実現するためのサーバであり、クライアント端末100からのアクセスに応じてウェブ会議画面(インタフェース/例えばhtmlで表現される画面を表示するための情報)をクライアント端末に送信することで、複数のクライアント端末100によりウェブ会議を行うサービスを提供する。
クライアント端末100には、例えば100や100Sに示すようなデスクトップPCや、100G1のようなノートPC、100G2のようなタブレットPCを適用可能である。クライアント端末100は、ウェブ会議サーバ200から受信した会議画面に、同じくウェブ会議サーバ200から受信した画像や映像を表示する。
本実施形態においてクライアント端末100には、ウェブ会議サーバ200へアクセスするためのウェブブラウザ、及び専用のモジュールがインストールされているものとする。なお、この専用のモジュールは、例えば、ウェブブラウザを介して、ウェブ会議サーバ200からダウンロードするActiveXコンポーネントである。なお、ウェブ会議において自身の動画像を送信する場合は、ビデオデバイスである(ウェブカメラ等の)カメラ101を接続する。音声を送信する場合は、マイク102を接続し、相手の音声を視聴するためにはスピーカ103を接続する。マイク102およびスピーカ103はオーディオデバイスである。
また、図1においては各デバイスを別々の筐体として例示しているが、例えば101〜103が同じ筐体のハードに備えられているデバイスを用いてもよい。例えばカメラ機能とマイク機能や、マイク機能とスピーカ機能、および全ての機能を備えたデバイスである。また、クライアント端末100に101〜103のデバイスが内蔵されている場合、これらの内蔵されているデバイスを用いて、画像、音声等を入力・出力するようにしてもよい。
また、本実施形態のウェブ会議システムは、クライアント端末100に表示されている画面の画像を他のクライアント端末(100G1、100G2や100S)の画面に表示する、画面共有(指定画像の表示の共有処理)を行うことができる。共有される画像は、クライアント端末100で指定することが可能である。例えばユーザ操作により指定されたアプリケーションの画面のみを指定画像として共有することができる(アプリケーション共有)。また、クライアント端末100に表示されているデスクトップ画面の指定を受け付けることで、当該デスクトップ画像全体を指定画像として共有することができる(デスクトップ共有)。また、クライアント端末100を指定することで(または自装置のカメラで撮像した画像を全画面表示する操作を受け付けることで)、当該カメラで撮像した画像を指定画像として共有することができる(指定受付手段に該当)。
また、本ウェブ会議システムは、ルームと呼ばれる仮想の会議室をウェブ会議サーバ200において複数生成、記憶、管理することができる。各クライアント端末100を操作するユーザは、自身のユーザID・パスワードを用いて、ウェブブラウザ経由でウェブ会議サーバ200にアクセスしてログインし、自身のユーザIDを用いて当該ルームに入室することで、当該ルームにおいて開催される会議に参加することができる。以上が図1の説明である。
以下、図2を用いて、本発明の実施形態における情報処理装置のハードウェア構成の一例について説明する。
図2において、201はCPUで、システムバス204に接続される各デバイスやコントローラを統括的に制御する。また、ROM202あるいは外部メモリ211には、CPU201の制御プログラムであるBIOS(Basic Input / Output System)やオペレーティングシステムプログラム(以下、OS)や、各サーバ或いは各PCの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。
203はRAMで、CPU201の主メモリ、ワークエリア等として機能する。CPU201は、処理の実行に際して必要なプログラム等をROM202あるいは外部メモリ211からRAM203にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。
であってもよい。また、例えばプロジェクタのような外部出力装置であってもよい。
また、205は入力コントローラで、キーボード(KB)209や不図示のマウス等のポインティングデバイス、タッチパネル、カメラ等からの入力を制御する。
であってもよい。また、例えばプロジェクタのような外部出力装置であってもよい。
206はビデオコントローラで、CRTディスプレイ(CRT)210等の表示器(外部出力装置)への表示を制御する。なお、図2では、CRT210と記載しているが、表示器はCRTだけでなく、液晶ディスプレイや、マルチタッチスクリーン等の他の表示器であってもよい。また、例えばプロジェクタのような外部出力装置であってもよい。
なおビデオコントローラ207は、表示制御を行うためのビデオメモリ(VRAM)を制御することが可能で、ビデオメモリ領域としてRAM203の一部を利用することもできるし、別途専用のビデオメモリを設けることも可能である。本実施形態においては、各クライアント端末100は、クライアント端末100を通常する場合の表示に用いられる第1のビデオメモリ領域と、所定の画面が表示される場合に、第1のビデオメモリ領域の表示内容に重ねて別の表示をするために用いられる第2のビデオメモリ領域を有している。ビデオメモリ領域は2つに限ったものではなく、情報処理装置の資源が許す限り複数有することが可能なものとする。
212は、音声入出力コントローラで、マイク/スピーカ213(図1における102及び103)からの入出力を制御する。マイクから入力された音声を音声認識することが可能となっている。スピーカにはイヤホンを接続することも可能である。
207はメモリコントローラで、ブートプログラム,各種のアプリケーション,フォントデータ,ユーザファイル,編集ファイル,各種データ等を記憶するハードディスク(HD)や、フレキシブルディスク(FD)、或いはPCMCIAカードスロットにアダプタを介して接続されるコンパクトフラッシュ(登録商標)メモリ等の外部メモリ211へのアクセスを制御する。
208は通信I/Fコントローラで、ネットワーク(例えば、図1に示したネットワーク150(例:LAN等))を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、TCP/IPを用いた通信や、ISDNなどの電話回線、および携帯電話の3G回線を用いた通信が可能である。等が可能である。
なお、CPU201は、例えばRAM203内の表示情報用領域へアウトラインフォントの展開(ラスタライズ)処理を実行することにより、CRT210上での表示を可能としている。また、CPU201は、CRT210上の不図示のマウスカーソル等でのユーザ指示を可能とする。
また、外部メモリ211等の、情報を永続的に記憶するための記憶装置(記憶媒体)は、その形態をハードディスク等の記憶装置に限定するものではない。例えば、SSD(Solid State Drive)などの媒体であってもよい。
本発明を実現するための後述する各種プログラムは、外部メモリ211に記録されており、必要に応じてRAM203にロードされることによりCPU201によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイル及び各種情報テーブル等も、外部メモリ211に格納されており、これらについての詳細な説明も後述する。以上が図2の説明である。
次に図3を参照して、本発明の実施形態における、各種装置の機能構成の一例について説明する。
クライアント端末100は、画像記憶部311、送信制御部312、通知受付部313、発話判定部314、表示制御部315等を備えている。
ウェブ会議サーバ200は、会議情報記憶部321、受信制御部322、画像記憶部323、送信制御部324、画像特定部325、受信状況通知部326等を備えている。
会議情報記憶部321は、どのユーザが、どの会議室に入室してどのユーザと会議を行っているかを記憶する記憶部である。
送信制御部312は、カメラにおいて撮像され入力された画像(映像)や、ユーザ操作等により表示を共有する画像として決定された指定画像(デスクトップ全体または指定アプリケーションの画面の画像)を圧縮し、ウェブ会議サーバに送信制御する送信制御部である。送信された圧縮データ(圧縮画像)は、ウェブ会議サーバ200の受信制御部322で受信され、メモリ上の画像記憶部323(キュー)に格納される。
画像記憶部311は、送信制御部312によって送信する画像と同じ画像を記憶する記憶部(キュー)である。カメラは継続的に撮像処理(動画の撮像及びクライアント端末100への動画の入力)を行うため、キューには、動画を構成する複数の画像が、動画内のフレームごとに順々に記憶される。
受信制御部322は、クライアント端末100の送信制御部312より送信された画像(映像)、および指定画像、音声を受信する受信部である。送信制御部324は、受信制御部322で受信した画像、音声等を、同じ会議に参加している(同じ会議室に入室中の)他のクライアント端末100に受信させるべく送信する制御部である。
なお、本実施形態においては、各クライアント端末100がウェブ会議サーバ200に対して、画像記憶部323からの画像の取得要求を行うことで、当該要求に応じてウェブ会議サーバ200の送信制御部324が要求元のクライアント端末100に対して、当該要求受付時におけるキュー内の最新の画像を送信するものとする。クライアント端末100は、要求した画像を受信した後、当該受信した画像(動画内の1フレーム)を表示画面に表示する。そして当該表示と並行して、当該動画内の次の画像をウェブ会議サーバ200に要求する。会議が終了する等、動画の表示が終了するまで、当該画像の要求と表示を繰り返す。
送信制御部324は、どのフレームの画像をどのクライアント端末100に送信したか(どの画像がどのクライアント端末から取得要求を受けた画像か)を外部メモリに記憶する。
画像特定部325は、ウェブ会議サーバ200が各クライアント端末100に送信した画像のうち、どの画像の識別情報を(どのクライアント端末100に送信しタ画像のシーケンス番号を/どのクライアント端末100が受信した画像のシーケンス番号を)通知先に通知するかを特定する特定部である。つまり、通知先に通知するフレーム(画像)を特定する。例えば、全てのクライアント端末100が受信済みの画像(ウェブ会議サーバ200が、送信元以外の全てのクライアント端末100に送信済みの送信済み画像)を通知先に通知する画像として特定する。
受信状況通知部326は、画像特定部325で特定された画像の識別情報を、画像の受信状況を示す情報としてクライアント端末100に通知する。例えば、指定画像の共有を行っている場合、共有元(画像共有のホスト端末)に当該画像の識別情報を送信する。通知受付部313は当該画像の識別情報の通知を受け付ける。
表示制御部315は、カメラから入力された画像(映像/動画)、および共有すべきデスクトップ全体または指定アプリケーションの画面データを表示画面に表示する制御部である。また、通知受付部313が画像の識別情報の通知を受け付けた場合に、当該通知を受け付けた識別情報の示す画像を、画像記憶部311(メモリ上のキュー)から取得して、連続して表示画面に表示させ、動画として再生する。
つまり、自装置の送信した画像のうち、他のクライアント端末100に送信され受信された画像を、画像の受信状況を示す情報として表示画面に表示し、ユーザに通知する。
例えば上述したように、全てのクライアント端末100に送信され受信されたフレームの画像を当該画像の送信元に通知して表示させることで、自装置から送信されている画像であって、ウェブ会議に参加している各クライアント端末100のうち最も画像の取得頻度が少ない(例えば通信状況が悪く、最も動画の取得フレーム数が少ない)クライアント端末100に表示されている画像を、表示画面上で確認することが可能となる。
発話判定部314は、マイクから入力された音声データを解析し、(例えばクライアント端末100を操作しているユーザの)発言の有無を判定する判定部である。上述の説明においては、通知受付部313が通知を受け付けた場合に通知を受けた画像を表示するものとしたが、例えば、通知受付部313が通知を受け付け、且つ発話判定部314で発話がされた場合に、ユーザが各端末に表示されている画像に関する話をしようとしていると判断し、通知受付部313が通知を受けた識別情報の画像を表示画面に表示することができる。以上が図3の説明である。
<第1の実施形態>
次に図4を参照して、本発明の第1の実施形態における、画像送信処理の流れについて説明する。
クライアント端末100のCPU201は、ウェブ会議サーバ200の提供するウェブ会議サービスを享受するために、ブラウザソフト上におけるユーザ操作に応じて所定のURLにアクセスし、不図示のログイン画面を表示する。そして、当該ログイン画面においてユーザIDとパスワードの入力を受け付けて、「ログイン」ボタンの押下を受け付けることで、ウェブ会議サーバ200へのログイン要求を送信する(ステップS401)。
ウェブ会議サーバ200のCPU201は、当該ログイン要求を受け付け(ステップS402)、自装置の外部メモリに予め記憶されているユーザ情報(ユーザID及びパスワード/図8の800に例示)と突き合わせて認証処理(ログイン処理)を行う。認証が成功した場合(受信したユーザIDを用いたウェブ会議サーバ200へのログインが成功した場合)、不図示のメニュー画面の画面情報(例えばhtml情報)を生成して、クライアント端末100に送信する(ステップS403)。
クライアント端末100のCPU201は、当該画面情報を受信して、受信した画面情報に基づいて不図示のメニュー画面を表示画面に表示する(ステップS404)。クライアント端末100のCPU201は、当該メニュー画面に含まれる不図示のルーム(ルームの識別情報)の選択部において、ログインユーザが入室するルームの選択操作を受け付け(ステップS405)、同画面に含まれる不図示の「入室」ボタンの押下を受け付けることで、選択中のルームへの入室要求をウェブ会議サーバ200に送信する(ステップS406)。
クライアント端末100のCPU201は、当該入室要求に、入室の操作を受け付けたクライアント端末100でログイン中のログインユーザのユーザID、入室対象のルームの識別情報(ルームID)、クライアント端末100の識別情報(例えばIPアドレス)、クライアント端末100の端末種別、通信方法等の情報を含めて、当該要求をウェブ会議サーバ200に送信する。端末種別とは、例えばクライアント端末100自身が、PC(デスクトップPC、ノートPC)なのか携帯端末(例えばタブレットPC、携帯電話等)なのかを識別するための情報である。自装置がPCであれば端末種別=pcの値を送信し、自装置が携帯端末であれば端末種別=mobileの値を送信する。各クライアント端末100は、自装置の端末種別の情報を、自装置の外部メモリ等の記憶領域に予め保持・記憶しており、その情報を取得して当該要求に埋め込むものとする。通信方法は、クライアント端末100自身がどのような通信方法でウェブ会議サーバ200と通信しているかを示す通信方法の識別情報である。例えば有線LANを用いた通信であれば通信方法=wire−lineであり、無線通信であれば通信方法=wirelessである。クライアント端末100のCPU201は、自装置の通信を管理している機能部(例えば通信/IFコントローラ)に自装置が外部装置との通信に用いている通信方法を問い合わせて当該通信方法の情報を取得する。そして、入室要求の中に埋め込んで、ウェブ会議サーバ200に送信する。
ウェブ会議サーバ200のCPU201は当該入室要求を受け付けると(ステップS407)、要求されたルーム(会議室)にユーザを入室させる入室処理を実行する(ステップS408)。
ここでは、入室処理に際して、どのユーザが、どの会議室のどの会議に、どのような端末種別のどの端末で、どのような通信方法で通信をして入室しているかを登録・記憶する。
具体的には、図8の会議情報810の会議室811に入室するルームのルームIDを、参加者ID813に入室させるユーザのユーザIDを追加する。また、当該ルームに入室中のユーザがいなかった場合は(無人のルームに入室した場合は)、会議を識別する会議IDを発行して会議ID812に挿入、記憶する。2人目以降の場合は、同ルームに入室中のユーザID(参加者)の参加している会議の会議ID(入室中のルームに対応する会議ID)を会議ID812に記憶するものとする。また、ステップS407で受け付けた入室要求に含まれていたクライアント端末100の端末IDを端末ID814に、端末種別を端末種別815に、通信方法を通信方法816に挿入して記憶する。
入室処理が完了すると、ウェブ会議サーバ200のCPU201は、図10に示すような、各クライアント端末100のカメラにより撮像された会議画像を表示する会議画面の画面情報(例えばhtml情報)を、入室したユーザのユーザIDの送信元のクライアント端末100に送信する(ステップS409)。
クライアント端末100のCPU201は当該会議画面の画面情報を受信し、受信した画面情報に基づいて会議画面を表示する(ステップS410)。以降、会議が終了するまで(会議の終了についてはステップS424で後述)、ステップS411〜ステップS423の処理を実行・継続するものとする。
クライアント端末100のCPU201は、自装置に接続されている(又は自装置に内蔵される)カメラ101からの画像(映像)の入力を受け付けて、カメラ101で撮像された画像(映像/会議画像)を取得し(ステップS411)、会議画面上に表示する(ステップS412)。例えば図10の会議画面における、表示領域1002に、自装置のカメラで撮像した画像を表示する。図10において1001は画像を大きく表示するメイン表示領域であり、1002、1003は画像を小さく表示するサブ表示領域である。
クライアント端末100のCPU201は、カメラ101からの入力画像(映像)を会議画面に表示する一方で、映像コーデックによる画像(映像)の圧縮処理を行い、圧縮後の画像を、1フレームごとに、順々に自装置のメモリ上のキューに保存・記憶する(ステップS413)。
キューの一例を図8の画像キュー820に示す。画像キュー820は、各画像の識別番号(識別情報)であり、画像の順序を示すシーケンス番号821と、画像の実体(画像データ/映像の中の1フレームの画像)である画像822の項目から構成される。クライアント端末100のCPU201は、カメラ101から取得した映像の各フレームの画像について、当該画像を取得した順にシーケンス番号を割り振って、画像キュー820に記憶する。
クライアント端末100のCPU201は、画像キュー820に保存した画像を、ウェブ会議サーバ200に、シーケンス番号と共に送信する(ステップS414)。つまり、画像キュー820に示す情報をウェブ会議サーバ200に送信する。
ウェブ会議サーバ200のCPU201は、当該画像(圧縮データ)を受信し(ステップS415)、自装置のメモリ上に保持している、当該画像の送信元のクライアント端末100(端末ID814)でのログインユーザの画像キュー830に追加して記憶する(ステップS416)。ウェブ会議サーバ200のCPU201は、ユーザの会議室への入室処理が行われた場合に、当該ユーザごとに(ユーザID831に入室したユーザのユーザIDを挿入した)画像キュー830を生成してメモリ上に保持する。画像キュー830のシーケンス番号832、画像833には、画像キュー820のシーケンス番号821、画像822と同じ情報を記憶する。
なお、送信済みユーザ834は、当該シーケンス番号832の示す画像833を送信した他のクライアント端末100の端末IDを格納する項目である。つまり、画像の送信状況を示す。送信済みユーザ834の記憶については後述する。
クライアント端末100のCPU201は、ステップS417において、他の会議参加者の画像833(同じルームに入室している他の入室者のユーザIDをユーザID831に持つ画像キュー830の画像833)の取得要求をウェブ会議サーバ200に送信する(ステップS417)。
ウェブ会議サーバ200のCPU201は当該取得要求を受け付け(ステップS418)、要求元のクライアント端末100(端末ID814)でのログインユーザ以外の、当該ログインユーザと同じルームに入室中のユーザのユーザIDを、会議情報810を参照して特定し、特定した他の入室者の画像833のうち最新のシーケンス番号(最も後ろの番号)の画像833を取得し(ステップS419)、取得した各クライアント端末100のカメラで撮像された画像(会議画像)を、当該画像に対応するユーザIDと共に要求元のクライアント端末100に送信する(ステップS420)。
また、当該クライアント端末100に画像を送信した場合に、送信先のクライアント端末100でログイン中のログインユーザのユーザIDを、送信した画像833に対応する送信済みユーザ834に記憶する(ステップS421)。つまり、どのユーザ(ユーザID831)のどの画像(シーケンス番号832の画像833)を、どのユーザ(送信済みユーザ834)に送信したかを記憶する。送信済みのユーザIDは送信済みユーザ834に、送信がされた順に書き込む。よって、最後に書き込まれたユーザ(例えば、シーケンス番号832=2の画像におけるUser002、シーケンス番号832=4の画像におけるUser003等)が、当該画像を最後に送信した送信先のユーザ(当該画像を最後に受信したユーザ/最後に当該画像の取得要求をした(受け付けた)クライアント端末のユーザ)である。
各フレームの画像の送受信のイメージを図9に示す。図9によれば、クライアント端末100HからUser001が、クラアイント端末100G1からUser002が、クラアイント端末100G2からUser003が、クラアイント端末100SからUser004が、ウェブ会議サーバ200にログインしている。会議情報810に示すように、User001、User002、User003、User004は同じ会議室(ルーム)に入室し、同じ会議に参加しているものとする。図9は、クラアイント端末100Hから送信された画像1〜5を、各クライアント端末100がどの程度の頻度で受信しているか(どの番号の画像を受信できているか)を示す。
図9によれば、例えばクラアイント端末100Sは、画像キュー830内の全ての画像を受信できている。これは通信が安定しており、適切な速度で画像を画像キュー830から取得(ダウンロード)して、自装置内で処理(伸張、表示)できているためと考えられる。一方クラアイント端末100G1は、画像の取得頻度が少なく、そのため取得できている画像は2と5のみである。画像の取得頻度が少ない原因としては、端末自体の画像の伸張、表示をするための処理能力(CPUの性能やメモリ領域の大きさ)が他装置に比べて低いことや、通信速度が低いことが考えられる。処理能力は、例えば大型のデスクトップPCと小型の携帯端末等によって差がある。また、通信速度は例えば有線通信や無線通信といった通信方法によって左右されることがある。このように、クライアント端末ごとに能力や通信方法(通信状況)が異なることがあるため、あるユーザには見えている画像(あるクライアント端末100においては受信できている画像)が、あるユーザには見えていない(あるクライアント端末100においては受信できていない)という状況が生じうる。例えば図9でいう画像1、3、4がそうである。
ウェブ会議に参加しているユーザにとって、どの画像が受信者に見えているかを確認したいことが多々ある。例えば自身の身振り手振りがリアルタイムに相手に伝わっているのか、時間差を以って相手に伝わっているのか(そもそも動画が中抜けして、ジェスチャーが伝わっていないのか)等を確認しながら発言をしたい場合である。
例えば、図10には、User001のクライアント端末100で表示している会議画面1000と、User002のクライアント端末100で表示している会議画面1010とがあるが、会議画面1000ではUser001が手を挙げている画像がカメラにより撮像され1002にリアルタイムに表示されているのに対し、会議画面1010では1011に示すように、User001が手を挙げた画像はまだ表示されていない。これでは、User001が手を挙げて何かを指差し「これがXだ」と発言したとしても、User002にはUser001の言う「これ」が何なのか伝わらない。2秒後になって、やっと1002と1011の表示の同期が取れているが、User001はこの表示の同期がされるまでの間、指をさして「これ」と発言しているのにUser002に「これ」が何か伝わらないのが何故なのか確認することができない。つまり、画像の表示が遅延しているのか分からないため、自身の身振り手振りが通じているのかが分からない。
本発明の実施形態においては、例えば当該ジェスチャーの伝達が一番遅いユーザ、つまり、画像の伝達が遅いユーザを特定して、当該画像の伝達が遅いユーザの端末の画面に表示されている画像(映像)を、所定のユーザ(例えば当該画像の送信元)に通知し、どの画像が受信者に見えているかをユーザに確認させることができる。その具体的方法の一例については、図5の説明で後述する。
図4の説明に戻る。クライアント端末100のCPU201は、ステップS420で送信された画像(圧縮データ)を受信し(ステップS422)、映像コーデックによる伸長処理を行って映像(画像)を復元して、表示中の会議画面に表示する(ステップS423)。例えば図10の1000においてはメイン表示領域1001にUser002の画像(映像)、1002、1003等のサブ表示領域にUser003、User004の画像(映像)が割り当てられている。どの表示領域にどのユーザの画像を表示するかの対応付け情報(表示領域のIDとユーザIDを対応付けた情報)は、クライアント端末100のメモリに記憶されているものとする。クライアント端末100のCPU201は、受信した画像を、それぞれの画像のユーザに対応する表示領域に表示することで、各ユーザの画像(会議画像)の表示を更新し、動画像(映像)として再生・表示する。
クライアント端末100のCPU201は、会議が終了したか判定する(ステップS424)。例えば、クライアント端末100において、不図示の「退出ボタン」の押下操作を受け付けた場合に、ログインユーザにとっての会議終了がされたと判定するものとする。また、ルーム使用の終了時刻がウェブ会議サーバに記憶されている場合、当該終了時刻になるとウェブ会議サーバ200のCPU201はウェブ会議を強制終了し、当該強制終了した旨を強制終了した会議に参加していたユーザのクライアント端末100に通知する。各クライアント端末100のCPU201は、当該強制終了の通知を受け付けた場合に、会議が終了したものと判定する。ウェブ会議が終了した場合には図4の処理を終了し、継続中の場合には処理をステップS411に移行する。
ウェブ会議を行う場合、実際には、複数のクライアント端末100が存在する場合があるため、ウェブ会議サーバ200のCPU201は、ステップS402〜S409をウェブ会議サーバ200にログインしたクライアント端末100の数だけ実行することとなる。また、ステップS415〜S421の処理を、ウェブ会議に参加(ルームに入室)したユーザのクライアント端末100の数だけ実行することとなる。以上が図4の説明である。
次に図5を参照して、本発明の第1の実施形態における、受信状況の通知処理の流れについて説明する。
本実施形態においては、ウェブ会議サーバ200のCPU201は、ステップS501〜S505の処理を、各ユーザ(ユーザID831)の画像キュー830ごとに、当該画像キュー830に格納された各シーケンス番号832に対して実行するものとする。
ウェブ会議サーバ200のCPU201は、画像キュー830から未処理のシーケンス番号832を特定する(ステップS501)。ウェブ会議サーバ200のCPU201は、送信済みユーザ834を参照し、当該シーケンス番号832の示す画像833が、送信元のユーザ(ユーザID831のユーザ)を除く、当該送信元のユーザと同じ会議に参加している他のユーザ(図8の811、812、813から特定)全員に送信済みの画像か判定する(ステップS502)。
全員に送信済みでないと判定した場合には、処理をステップS505に移行する。全員に送信済みであると判定した場合には、処理をステップS503に移行し、当該シーケンス番号832の画像833の送信元のユーザ(ユーザID)を特定し、当該ユーザIDでログインし、ウェブ会議サーバ200と通信している当該画像の送信元のクライアント端末100(図8の端末ID814)を、会議情報810の参加者ID813と端末ID814を参照して、当該画像の受信状況の通知先として特定する(ステップS503)。
ウェブ会議サーバ200のCPU201は、ステップS503で特定した通知先のクライアント端末100に対して、画像の受信状況の通知として、ステップS502で会議参加者全員に送信された(全員が受信している)と判定された画像833(送信済み画像)のシーケンス番号832、当該画像を最後に受信したユーザのユーザIDを通知(送信)する(ステップS504)。
送信済み画像は、他のクライアント端末が受信済みの受信済み画像ともいう。全てのクライアント端末100に送信済みであるということは、当該送信済み画像が、例えば、同じ会議に参加しているユーザのクライアント端末100のうち最も画像の取得頻度が少ない(通信環境が悪いような)クライアント端末100でも受信・取得・表示できているということである。つまり、送信済み画像とは、送信側の端末と同じ会議の中において最も画像の取得頻度が少ないクライアント端末100において表示されている、時間当たりのフレーム数(コマ数)の少ない動画像である。よって、当該送信済み画像を送信元のクライアント端末100に通知することで、クライアント端末100を操作するユーザに、ユーザ自身の操作するクライアント端末100から送信された画像の受信状況(特に、最も受信・表示が遅れている端末における当該画像の受信状況)を容易に確認させることができる。
例えば画像を送信しているクライアント端末100Hと同じ会議に参加している全クライアント端末100(例えば図1でいうクライアント端末100G1、クライアント端末100G2、クライアント端末100S)が、クライアント端末100Hから送信された画像(画像キュー830に保存されている画像)を、図9に示すクライアント端末100Sのように、中抜けすることなく継続して取得要求し、受信し、表示可能な場合は(ウェブ会議サーバ200が、画像キュー830の全ての画像を、全てのクライアント端末100に対して継続して送信している場合は)、クライアント端末100Hの会議画面1000の表示領域1001に表示中のリアルタイムの画像(フレーム)と同じ(フレームの)画像が、継続して、当該送信済み画像として特定される(ステップS502でYES)。しかし、画像の取得の頻度が少ない端末(ウェブ会議サーバ200との通信状況等により画像の取得速度が十分に確保できない端末/例えば図9のクライアント端末100G1、クライアント端末100G2等)が会議に参加中の場合は、当該送信済み画像として、クライアント端末100Hの会議画面1000の表示領域1001に表示中のリアルタイムの画像(フレーム)よりも前のフレームの画像が特定される。画像の取得頻度が少ないと、送信側の端末に表示されているリアルタイムの画像よりも荒い動画が表示されることとなる。つまり、送信元を除く他のクライアント端末100において、リアルタイム画像に比べて遅れて表示される遅延画像(遅延動画)が表示されることとなる。
ステップS506において、クライアント端末100のCPU201は、ステップS504で送信されたシーケンス番号、ユーザIDを受信し(ステップS506/シーケンス番号、ユーザIDの通知を受け付け)、メモリに蓄積して記憶する(ステップS507)。
当該シーケンス番号の示す画像を、画像キュー820から取得して表示画面に表示(例えば、図10の1003に表示)することで、クライアント端末100を操作してログインし会議に参加中のユーザに、自身の端末のカメラから取得して送信している会議画像が、受信が最も遅い(頻度が少ない)他の端末にどのように表示されているかを容易に確認させることができる。
つまり、電子会議における画像の受信状況を容易に確認可能とする仕組みを提供することができる。
本実施形態においては、クライアント端末100のCPU201はさらに、マイク102から入力された音声の有無に基づいて発話がされたか判定し(ステップS508)、発話ありと判定された場合に、前記メモリに蓄積して記憶された画像のシーケンス番号(全ての会議参加者に送信された画像のシーケンス番号)のうち、最新の番号、ユーザIDを取得して(ステップS509)、当該シーケンス番号の示す画像822(圧縮データ)を画像キュー820から検索して取得する(ステップS510)。そして、当該画像822を映像コーデックによる伸長処理を行って映像を復元し、会議画面上に表示する。例えば、図10の1000に示すように、自装置で撮像して表示している画像(表示領域1002に表示)と、ステップS510で取得した画像(表示領域1003に表示)とを並べて表示(比較表示)することで、カメラから取得した最新の映像(リアルタイムの映像/画像)と、受信側のクライアント端末100に送信され、受信・表示されている映像(遅延映像/画像)を比較して確認させることが可能となる。また、1003に示すように、ステップS510で取得した画像を表示する表示領域の枠を強調表示(識別表示)したり、1000における「User001(User002)」の表示に示すように、どのユーザ(User001)の画像でどのユーザ(User002)が受信している画像かを識別表示することで、1002と1003のどちらがリアルタイム画像で、どちらが送信済み画像かを容易に確認させることができる。また、どのユーザが1003に表示している送信済み画像を見ているかを容易に確認させることができる。
ウェブ会議サーバ200のCPU201は、ステップS505において、ステップS501〜S504の処理を終了するか判定する(ステップS505)。例えば、会議が終了した場合、ステップS501〜S504の処理を終了すると判定する。会議の終了については、ステップS424で前述した通りである。処理を終了しない場合は、ステップS501に移行し、処理済の最新画像の次のシーケンス番号の画像を取得して、ステップS502以降の処理を実行する。
また、ウェブ会議サーバ200が、図10の1000に示すように、会議画面上に、1002に示す送信済み画像の表示の「ON/OFF」ボタン1004を含む会議画面の画面情報を生成してクライアント端末100に送信して表示させ、当該「ON/OFF」ボタン1004の押下に応じて、当該「ON/OFF」ボタン1004が押下されたクライアント端末100のユーザに関する(ユーザID831を用いた)ステップS501〜S505の実行開始と終了を切替えてもよい。具体的には、クライアント端末100が当該「ON/OFF」ボタン1004の押下を受け付けることで、当該ボタンの押下を受け付けた旨をウェブ会議サーバ200に通知する。通知にはログインユーザのユーザIDを埋め込む。ウェブ会議サーバ200は当該通知を受け付ける。当該ユーザからの当該通知の受付が会議開始後初めての場合は、自装置の外部メモリ上に、当該ユーザ(通知に含まれるユーザID)と、送信済み画像の表示フラグ=ONの値を設定したON/OFFテーブルを生成して記憶し、当該ユーザIDをユーザID831に持つ画像キュー830のシーケンス番号を対象に、ステップS501〜S505の処理を実行する。また、次に当該「ON/OFF」ボタン1004の押下の通知を受け付けた場合には、通知に含まれるユーザのON/OFFテーブルを参照し、送信済み画像の表示フラグ=ONの場合はOFFに、OFFの場合にはONにフラグを変更する。ステップS505では、当該送信済み画像の表示フラグを参照し、ONの場合は終了と判定せず(ステップS505でNO)、OFFの場合には処理を終了すると判定する(ステップS505でYES)。
これにより、送信済み画像の表示・非表示を、ログインユーザごとに、クライアント端末100からの操作に応じて容易に切替えて、電子会議における画像の受信状況を容易に確認させることができる。
以上が図5の説明である。
以上説明したように、本発明によれば、電子会議における画像の受信状況を容易に確認可能とする仕組みを提供することができる。
なお、上述した第1の実施形態によれば、ステップS501〜S505の処理は各ユーザ(ユーザID831)の画像キュー830ごとに、当該画像キュー830に格納された各シーケンス番号832に対して実行されるものとしたが、例えば特定のユーザ(例えばUser001)の画像キュー830のみを対象とし、当該画像キュー830に格納された各シーケンス番号832に対してステップS501〜S505の処理を実行するものとしてもよい。つまり、User001の画面には図10でいう1003に示す送信済み画像が通知され、表示されるが、User002〜User004については図5の処理を行わないため、図10でいう1003に示す送信済み画像の通知は行われず、表示もされない。
送信済み画像の特定、通知及び表示を特定のユーザのみに限定して実行することで、全てのユーザについて送信済み画像の特定、通知及び表示を行うのに比べてウェブ会議サーバ200の処理負荷を軽減することができる。
当該特定のユーザのユーザIDは、予めウェブ会議サーバ200の外部メモリに記憶されているものとする。
また、ウェブ会議システムにおいては、クライアント端末100が自装置のマイク102から音声を取得した場合に(ユーザが発話していると判定した場合に)、取得した当該音声データをウェブ会議サーバ200に送信し、これを受信して記憶したウェブ会議サーバ200が当該音声を他のクライアント端末100に配信して音声によるコミュニケーションを可能とする。
特に、発話して何かを伝えようとしているユーザが、自身の画像の受信状況を確認したいと考えられるため、例えば、ウェブ会議サーバ200が当該音声データの受信状況を監視し、音声データを受信中(発話中)のユーザを上述した特定のユーザ(送信済み画像を特定、通知、表示させるユーザ)として、ステップS501の前に特定して、当該特定した特定のユーザの画像キュー830のみを対象とし、当該画像キュー830に格納された各シーケンス番号832に対してステップS501〜S505の処理を実行するものとしてもよい。つまり、発話中のユーザのクライアント端末100に対して、当該発話中のユーザのクライアント端末100から送信された画像のうち、同会議に参加中の他の全クライアント端末に送信済みの画像のシーケンス番号を特定し、当該発話中のユーザのクライアント端末100に通知して、表示させるようにしてもよい。
以上が本発明の第1の実施形態の説明である。
<第2の実施形態>
次に図6を参照して、本発明の第2の実施形態における、指定画像送信処理の流れについて説明する。なお、上述した第1の実施形態等と共通する処理については記載を省略する。
第2の実施形態では、図11及び図12に示すように、指定された画像を(例えば全画面表示で)共有するに際して、所定のユーザ(例えば指定画像の共有元)に通知し、どのような指定画像(動画/映像)が受信者に見えているかを当該ユーザに確認させる方法について説明する。
クライアント端末100HのCPU201は、指定画像の共有指示を受け付ける(ステップS601)。例えば図10の会議画面における「全画面」ボタンの押下を受け付けた場合に、当該「全画面」ボタンの押下を受け付けたクライアント端末100Hのカメラ102で撮像された、ウェブ会議サーバ200に送信中の会議画像を指定画像として決定し、指定画像の共有指示を受け付けたものと判定する。また、例えば図10の会議画面における「画面共有」ボタンの押下を受け付けることでクライアント端末100Hが表示する不図示の指定画像選択画面(表示を共有する対象としてクライアント端末100Hのデスクトップ画面の選択可能な選択部と、クライアント端末100Hで起動中のアプリケーションの中から画面の表示を共有するアプリケーションの選択を受け付ける選択部(アプリケーションの一覧)を備える選択画面)において、画面の表示を共有するアプリケーション又はデスクトップの選択を受け付けた場合に、選択された画面の画像を指定画像とすることを決定し、指定画像の共有指示を受け付けたものと判定する。
本実施形態において、指定画像の共有元(送信元)のクライアント端末100はホスト端末であり、共有先(送信先)のクライアント端末100はゲスト端末であるものとする。
クライアント端末100HのCPU201は、当該指定画像を自装置の記憶部(メモリ)から取得し(ステップS602)、図11の1110に示すように全画面表示する(ステップS603)。図11は、図10の「全画面」ボタンが押下された場合に実行される、指定画像(ホスト端末のカメラ画像(会議画像))を全画面表示する画面の構成の一例を示す図である。
また、取得した指定画像を、シーケンス番号と対応付けて指定画像用の画像キュー(クライアント端末100Hのメモリ上に生成)に記憶し(ステップ604)、ウェブ会議サーバ200に送信する(ステップS605)。なお、ここでいう画像キューの構成は図8の820と同一であるものとする。つまり、指定画像と、指定画像のシーケンス番号とを対応付けて記憶した情報である。合わせて、クライアント端末100Hでログイン中のユーザIDをウェブ会議サーバ200に送信する。
ウェブ会議サーバ200のCPU201は、当該指定画像を受信する(ステップS606)。ウェブ会議サーバ200のCPU201は、指定画像の共有を開始する旨を、クライアント端末100Hのユーザ(ここではUser001)と同じ会議に参加中のユーザ(User002、User003、User004)がユーザIDを入力してログインに用いた他のクライアント端末100(100G1、100G2、100S)に送信する(ステップS607)。ここでは一例としてクライアント端末100G1を例にあげて説明する。なお、既に指定画像の共有中の場合は、ステップS607の処理はスキップし、ステップS608に移行する。
ウェブ会議サーバ200のCPU201は、指定画像を自装置のメモリ上に指定画像用の画像キュー(構成は図8の830と同じ)を生成して記憶する。具体的には、クライアント端末100HのユーザのユーザIDと、フレームごとの指定画像と、各指定画像のシーケンス番号と、当該指定画像を送信済みの送信済みユーザを記憶する(ステップS608)。
クライアント端末100G1のCPU201は、指定画像の共有開始の通知を受け付けると(ステップS609)、指定画像をウェブ会議サーバ上の画像キューから取得すべく、当該指定画像の取得要求をウェブ会議サーバ200に送信する(ステップS610)。
ウェブ会議サーバ200のCPU201は当該指定画像の取得要求を受け付け(ステップS611)、指定画像用の画像キューの中に記憶されている、最新のシーケンス番号(最も後ろの番号)の指定画像を取得し(ステップS612)、当該指定画像を要求元のクライアント端末100G1に送信する(ステップS613)。そして、
また、当該クライアント端末100G1に指定画像を送信した場合に、送信先のクライアント端末100G1でログイン中のログインユーザのユーザID(例えばUser002)を、送信した指定画像に対応する送信済みユーザの項に挿入して記憶する(ステップS614)。つまり、どのシーケンス番号のどの指定画像を、どのユーザに送信したかを記憶する。送信済みのユーザIDは送信がされた順に送信済みユーザの項に書き込み、記憶する。よって、送信済みユーザの項に最後に書き込まれたユーザが、当該指定画像を最後に送信した送信先のユーザ(当該指定画像を最後に受信したユーザ/最後に当該指定画像の取得要求をした(受け付けた)クライアント端末のユーザ)である。
クライアント端末100G1のCPU201は、ステップS613で送信された指定画像を受信し(ステップS615)、図11の1120に示すように全画面表示する。他のクライアント端末100(100G2、100S)も同様に、指定画像の取得要求を行い、当該指定画像を受信して図11の1130、1140に示すように全画面表示する(ステップS616)。
クライアント端末100HのCPU201は、ステップS617において、指定画像の共有を終了する操作を受け付けたか判定する(ステップS617)。例えば図11の1110における「×」ボタンの押下を受け付けた場合に、指定画像の共有を終了する操作を受け付けたと判定し、指定画像の共有の終了をウェブ会議サーバ200に通知して、図5の処理を終了する。ウェブ会議サーバ200のCPU201は当該終了の通知を受け付け、当該終了の通知を他のクライアント端末100にも通知し、通知を受け付けた他のクライアント端末100のCPU201は、指定画像の全画面表示を終了して、図10に示すような会議画面を表示画面に表示する。指定画像の共有を終了する操作を受け付けていない場合は、処理をステップS602に移行し、指定画像の共有を継続する。以上が図6の説明である。
次に図7を参照して、本発明の第2の実施形態における、指定画像の受信状況の通知処理の流れについて説明する。
ウェブ会議サーバ200のCPU201は、ステップS701〜S705の処理を、指定画像の共有の開始から終了まで繰り返し実行する。
ウェブ会議サーバ200のCPU201は、指定画像の共有が開始されたか判定する(ステップS700)。例えば、クライアント端末100との間で指定画像の送受信が行われていない状態において、クライアント端末100から指定画像を受信した場合に、指定画像の共有が開始されたと判定する。指定画像の共有が開始された場合には処理をステップS701に移行し、開始されていない場合には図7の処理を終了する。
ウェブ会議サーバ200のCPU201は、自装置のメモリに記憶されている指定画像用の画像キューから未処理の画像を1つ取得し(ステップS701)、当該指定画像が、当該指定画像を送信している送信元のユーザが参加中の会議において、他のユーザ全員に送信された(全員が受信した/取得しにきた)指定画像か、送信済みユーザの項の値を参照して判定する(ステップS702)。全員に送信済みで無い場合、処理をステップS705に移行する。全員に送信済みの場合は、処理をステップS703に移行する。
ウェブ会議サーバ200のCPU201は、指定画像の送信元(ホスト端末であるクライアント端末100H)を、当該指定画像の受信状況(全員が受信した指定画像のシーケンス番号)の通知先として特定し(ステップS703)、参加者全員に送信された指定画像(送信済み画像)のシーケンス番号と、当該指定画像が最後に送信されたユーザのユーザIDとを、指定画像の受信状況を示す情報として、当該特定した通知先に通知する(ステップS704)。
クライアント端末100HのCPU201は、当該シーケンス番号とユーザIDを受信し(ステップS706)、メモリ上に記憶する(ステップS707)。
クライアント端末100HのCPU201は、当該シーケンス番号の示す指定画像を、自装置内の指定画像用の画像キューから取得して表示画面に表示(例えば、図11の1111に表示)することで、クライアント端末100Hを操作してログインし会議に参加中のユーザに、自身の端末から送信している指定画像が、受信が最も遅い(頻度が少ない)他の端末にどのように表示されているかを容易に確認させることができる。
つまり、電子会議における画像の受信状況を容易に確認可能とする仕組みを提供することができる。
本実施形態においては、クライアント端末100HのCPU201はさらに、マイク102から入力された音声の有無に基づいて発話がされたか判定し(ステップS708)、発話ありと判定された場合に、前記メモリに蓄積して記憶された画像のシーケンス番号(全ての会議参加者に送信された指定画像のシーケンス番号)のうち、最新の番号、ユーザIDを取得して(ステップS709)、当該シーケンス番号の示す画像を画像キューから検索して取得する(ステップS710)。そして、当該指定画像を、図11の1111に示すように画面上に表示するものとする。例えば、図11の1110に示すように、自装置で表示している画像(全画面表示している画像)と、ステップS710で取得した画像(表示領域1111に表示)とを合わせて表示(比較表示)することで、最新の映像(リアルタイムの指定画像)と、受信側のクライアント端末100G1に送信され、受信・表示されている映像(遅延映像)を比較して確認させることが可能となる。また、1110に示すUser001(User002)の表示のように、どのユーザ(User001)の端末から送信された指定画像で、どのユーザ(User002)が受信している画像かを識別表示することで、どのユーザが送信済み画像(全てのクライアント端末100が受信している画像=最も画像の取得速度が遅い端末が受信できている、リアルタイムの画像に比べて前のフレームの画像である可能性が高い画像)を見ているのかを容易に確認させることができる。
ウェブ会議サーバ200のCPU201は、ステップS705において、ステップS701〜S704の処理を終了するか判定する(ステップS705)。例えば、指定画像の共有が終了した場合、ステップS701〜S704の処理を終了すると判定する。指定画像の共有の終了については、ステップS617の説明で前述した通りである。処理を終了しない場合は、ステップS701に移行し、処理済の最新画像の次のシーケンス番号の画像を取得して、ステップS702以降の処理を実行する。以上が図7の説明である。
なお、上述した実施形態においては、図11の指定画像の共有画面を例にあげて説明したが、図12に示す画面も、指定画像の共有画面の1つである。図12は、図10の「画面共有」ボタンが押下され、デスクトップ画面の表示を共有する指示を受け付けた場合に実行される、指定画像(ホスト端末のデスクトップ画像)を全画面表示する画面の構成の一例を示す図である。図12において、1200はUser001のクライアント端末100H(ホスト端末)に表示されている画面であり、1210はUser002のクライアント端末100G1(ゲスト端末の1つ)に表示されている画面である。
当該デスクトップ画面の画像(指定画像)の共有は、例えば図6のステップS602で、ウェブ会議サーバ200のCPU201が自装置に表示しているデスクトップ画面の画像を指定画像として決定して取得し、ステップS604で画像キューに保存して、ウェブ会議サーバ200に当該デスクトップ画面の画像を送信し(ステップS605)、ウェブ会議サーバ200がこれを受信してステップS606〜S611の処理を実行。ステップS612で画像キューから最新のシーケンス番号の当該デスクトップ画像(指定画像)を取得して、同会議に参加中の他のクライアント端末100(ゲスト端末/例えばクライアント端末100G1)に送信し(ステップS613)、これを受信したゲスト端末が、受信したデスクトップ画面の画像を図12の1210に示すように全画面表示することで行われる。ウェブ会議サーバ200のCPU201は、ステップS614でどのシーケンス番号のどのデスクトップ画像(指定画像)をどのユーザに送信したかを記憶するものとする。
図12によれば、ホスト端末側のデスクトップ画面では、ウインドウ1202の他に、新たなウインドウ1203を開いて表示しているが、ゲスト端末側ではまだウインドウ1203を含むデスクトップ画面の画像(指定画像)が受信されておらず、まだウインドウ1203が表示されていない。つまり、ゲスト端末には遅延画像が表示されている状態である。指定画像のうち、送信済み画像をクライアント端末100Hに通知することにより、クライアント端末100Hが表示領域1201に当該送信済み画像(ここでは1210に表示中の画像)を表示するため、User001は、クライアント端末100Hに全画面表示中の画像に比べ、当該画像の表示が遅れているクライアント端末100があることを確認できる。また、図12に示すように、表示領域1201と合わせて「User001(User002)」と表示することで、User002のクライアント端末100G1で表示領域1201に表示されているように指定画像の共有・表示が遅れていることを確認できる。
以上説明したように、本発明の第2の実施形態によれば、指定された画像を共有するに際して、所定のユーザに、どのような指定画像が受信者に見えているかを確認させることができる。
つまり、電子会議における画像の受信状況を容易に確認可能とする仕組みを提供することができる。
<第3の実施形態>
次に図13〜図16を参照して、本発明の第3の実施形態について説明する。第1の実施形態、第2の実施形態と共通する処理については説明を割愛する。
第3の実施形態においては、話者(例えばプレゼンテータ、講師等)に、電子会議における画像の受信状況を容易に確認させることができる仕組みを提供することを目的とする。
クライアント端末100HのCPU201は、ステップS601の処理実行後、処理をステップS1301に移行し、図15の1510に示す話者選択画面を表示画面に表示する(ステップS1301)。具体的には、クライアント端末100HのCPU201がウェブ会議サーバ200に話者選択画面1510を要求し、ウェブ会議サーバ200が要求に応じて話者選択画面1510の画面情報を生成してクライアント端末100Hに送信し、クライアント端末100Hが受信した画面情報に基づいて当該話者選択画面1510を表示する。話者選択画面1510は、チェックボックス1511と話者選択受付部1512、「OK」ボタン等を備える。話者選択受付部1512は、話者の選択(指定)を受け付ける受付部である。話者選択受付部1512には、会議に参加中のユーザIDの一覧が埋め込まれて、選択可能に表示されている。チェックボックス1511は、話者選択受付部1512で選択を受け付けたユーザに送信済み画像を表示させるか否かを選択させるための選択受付部である。
クライアント端末100HのCPU201は、話者選択受付部1512で話者の選択を受け付け、「OK」ボタンの押下を受け付けると(ステップS1302/話者指定受付手段に該当)、話者選択受付部1512で選択されたユーザIDを話者指定されたユーザIDとして、ウェブ会議サーバ200に送信する(ステップS1303)。
ウェブ会議サーバ200のCPU201は、当該ユーザIDを受信して、自装置のメモリ上に話者情報1400(図14)を生成して、当該ユーザIDのユーザを話者として記憶する(ステップS1304)。話者情報1400は、どの会議室811のどの会議(会議ID812)に参加しているどのユーザ(参加者ID813)が話者として指定されたかを記憶するテーブルである。会議室811、会議IDにはUser001(クライアント端末100Hでウェブ会議サーバにログイン中のユーザ)が入室している会議室、会議IDを記憶する。参加者ID813には、会議室811に入室中(会議ID812の会議に参加中)のユーザを記憶する。話者フラグ1401には、話者情報1400には全てのユーザに対応付けて0の値(話者ではないことを示す値)を記憶する。ウェブ会議サーバ200のCPU201は、ステップS1304で話者として選択されたと通知されたユーザID(参加者ID813)に対応する話者フラグ1401を1の値(話者であることを示す値)に変更して更新する。そして処理をステップS606に移行する。
その後、ウェブ会議サーバ200のCPU201は、ステップS702において参加者全員が受信した画像であると判定した後、処理をステップS1305に移行して、話者が選択(指定)されているか判定する(ステップS1305)。具体的には、話者情報1400の話者フラグ1401を参照し、話者フラグ1401=1のユーザがいない場合には、話者が選択されていないと判定する。話者が選択されていない場合には、処理を図7のステップS703に移行し、ステップS703以降の処理を実行する。話者フラグ1401=1のユーザがいる場合には、話者が選択されていると判定する。そして、話者フラグ1401=1のユーザである話者(話者のクライアント端末100)を、送信済み画像の通知先として特定し、話者のユーザID及び話者のクライアント端末100の端末IDをメモリに記憶する。ここでは話者=User004、話者のクライアント端末=クライアント端末100Sであるものとする。
ウェブ会議サーバ200のCPU201は処理をステップS1307に移行し、当該通知先である話者(話者のクライアント端末100S)に対して、送信済み画像と、当該送信済み画像が最後に送信されたユーザのユーザIDを、送信済み画像の受信状況を示す情報として通知する。通知を受け付けたクライアント端末100SのCPU201は、当該画像及びユーザIDを受信し、当該送信済み画像をメモリ上に記憶し、表示画面上に表示する。例えば図16でいう表示領域1631に表示する。図16において1610はクライアント端末100Hの画面であり、1620はクライアント端末100G1の画面であり、1630はクライアント端末100Sの画面である。
つまり、本発明の第3の実施形態によれば、話者として選択(指定された)ユーザの端末に、電子会議における画像の受信状況を容易に確認させることができる。
以上が本発明の第3の実施形態の説明である。
上述した実施形態によれば、同じ会議に参加中の他の全クライアント端末に送信済みの画像(送信済み画像)をクライアント端末100に通知した。これにより、送信元のクライアント端末から送信された画像が、他のクライアント端末それぞれにおいてどのように表示されているか、送信元端末に全て通知し、表示させるのに比べ、ウェブ会議サーバ200及びクライアント端末100の処理負荷を軽減することができる。
以上説明したように、本発明によれば、電子会議における画像の受信状況を容易に確認可能とする仕組みを提供することができる。
なお、上述した各実施形態の発明は、それぞれ自由に組み合わせて実行可能であるものとする。
また、上述した実施形態の説明においては、会議参加者全員に送信された送信済み画像のシーケンス番号を、画像の受信状況を示す情報としてクライアント端末100に通知し、画像の受信・表示の遅延状況をユーザに確認させるものとしたが、例えばクライアント端末100の端末種別や、通信方法の情報を用いて、画像の受信状況をクライアント端末100に通知するようにしてもよい。
例えば、携帯端末(端末種別815=mobile)の場合、一般的なPC(端末種別815=pc)よりも端末の性能が低く、メモリ等の作業領域も少ないことが考えられる。つまり、携帯端末はPCよりも処理速度が劣っており、画像の取得頻度が少ないと仮定される。よって、携帯端末において取得、表示されている画像が最も受信・表示が遅れている画像であると仮定し、上述した実施形態における送信済み画像(全てのクライアント端末100に送信済みの画像)の代わりに、当該携帯端末に送信済みの画像を、当該画像の送信元の端末又は話者の端末に通知して表示させる。
以下、電子会議における端末種別に応じて、電子会議における画像の受信状況を容易に確認可能とする仕組みについて説明する。
ウェブ会議サーバ200のCPU201が、図5のステップS501の前に、図8の会議情報810の端末種別815を参照し、端末種別815=mobileの端末を特定し、その端末のユーザを特定する。図8によればUser002である。そして、ステップS501の後、(ステップS502の処理の代わりに)ステップS501で特定した画像の送信済みユーザ834にUser002が含まれるか(携帯端末に送信済みの画像か)判定する。User002のクライアント端末100G1(携帯端末)に当該画像を送信済みの場合には処理をステップS503以降の処理を実行し、当該画像を送信済み画像として、当該画像のシーケンス番号送信元のクライアント端末100に通知する。User002のクライアント端末100G1(携帯端末)に当該画像を送信済みでない場合には処理をステップS505に移行する。
また、例えば、ウェブ会議サーバ200のCPU201が、図7のステップS700後に図8の会議情報810の端末種別815を参照し、端末種別815=mobileの端末のユーザ(User002)を特定する。そして、ステップS701の処理実行後、(ステップS702の処理の代わりに)ステップS701で特定した画像の送信済みユーザ834にUser002が含まれるか(携帯端末に送信済みの画像か)判定する。User002のクライアント端末100G1(携帯端末)に当該画像を送信済みの場合には処理をステップS703以降の処理を実行し、当該画像を送信済み画像として、当該画像のシーケンス番号送信元のクライアント端末100に通知する。User002のクライアント端末100G1(携帯端末)に当該画像を送信済みでない場合には処理をステップS705に移行する。
これにより、電子会議における端末種別に応じて、電子会議における画像の受信状況を容易に確認可能とする仕組みを提供することができる。
例えば会議の参加者数が多い場合であっても、画像ごとに全てのユーザが受信済みの画像かを判定する負荷をかけずに、端末種別によって、遅延画像と考えられる画像を所定のユーザに確認させることができる。
なお、ここでは端末種別に携帯端末とPCを例に上げて比較し、携帯端末に送信済みの画像を送信元に通知するものとしたが、例えばPCと携帯端末の他に端末種別を設定できるようにしてもよい。例えば携帯端末よりも処理能力が低いと思われる端末種別が存在する場合、当該端末種別に送信済みの画像を送信元に通知するようにしてもよい。どの端末種別に送信済みの画像を通知先に通知するかは、不図示の設定画面において、ユーザ操作により自由に設定・変更可能であるもとする。また、当該設定・変更の操作を受け付けることにより、ウェブ会議サーバ200が、設定・変更された端末種別(所定の端末種別)に送信済みの画像を通知先に通知する設定の情報を自装置の外部メモリに記憶するものとする。
また、例えば、端末の通信方法が所定の通信方法である端末に送信された画像を、上述した実施形態における送信済み画像(全てのクライアント端末100に送信済みの画像)の代わりに、通知先に通知するようにしてもよい。
例えば、通信方法が無線通信(通信方法816=wireless)の場合、一般的には有線通信(通信方法816=wire−line)よりも通信状況が安定せず、通信速度を確保し難いと考えられる。つまり、無線通信でウェブ会議サーバと通信している端末は有線通信でウェブ会議サーバと通信している端末よりも、画像の取得頻度が少ないと仮定される。よって、無線通信の端末において取得、表示されている画像が最も受信・表示が遅れている画像であると仮定し、上述した実施形態における送信済み画像(全てのクライアント端末100に送信済みの画像)の代わりに、当該無線通信の端末に送信済みの画像を、当該画像の送信元の端末又は話者の端末に通知して表示させる。
以下、端末の通信方法に応じて、電子会議における画像の受信状況を容易に確認可能とする仕組みについて説明する。
ウェブ会議サーバ200のCPU201が、図5のステップS501の前に、図8の会議情報810の通信方法816を参照し、無線通信の端末(通信方法816=wire−lessの端末)を特定し、その端末のユーザを特定する。図8によればUser002とUser003である。このように対象の端末が複数ある場合は、例えば端末種別を参照し、優先度の高い端末種別(ここでは携帯端末=mobile)の端末を特定し、その端末のユーザを特定する。図8によればUser002である。当該優先度の情報は予めウェブ会議サーバ200のメモリに記憶されているものとする。ウェブ会議サーバ200のCPU201は、ステップS501の後、(ステップS502の処理の代わりに)ステップS501で特定した画像の送信済みユーザ834にUser002が含まれるか(無線通信の端末に送信済みの画像か)判定する。User002のクライアント端末100G1(無線通信の端末)に当該画像を送信済みの場合には処理をステップS503以降の処理を実行し、当該画像を送信済み画像として、当該画像のシーケンス番号送信元のクライアント端末100に通知する。User002のクライアント端末100G1(無線通信の端末)に当該画像を送信済みでない場合には処理をステップS505に移行する。
また、例えば、ウェブ会議サーバ200のCPU201が、図7のステップS700後に図8の会議情報810の通信方法816を参照し、通信方法816=wire−lessの端末のユーザ(例えばUser002)を特定する。そして、ステップS701の処理実行後、(ステップS702の処理の代わりに)ステップS701で特定した画像の送信済みユーザ834にUser002が含まれるか(無線通信の端末に送信済みの画像か)判定する。User002のクライアント端末100G1(無線通信の端末)に当該画像を送信済みの場合には処理をステップS703以降の処理を実行し、当該画像を送信済み画像として、当該画像のシーケンス番号送信元のクライアント端末100に通知する。User002のクライアント端末100G1(無線通信の端末)に当該画像を送信済みでない場合には処理をステップS705に移行する。
これにより、電子会議における端末の通信方法に応じて、電子会議における画像の受信状況を容易に確認可能とする仕組みを提供することができる。
例えば会議の参加者数が多い場合であっても、画像ごとに全てのユーザが受信済みの画像かを判定する負荷をかけずに、端末の通信方法によって、遅延画像と考えられる画像を所定のユーザに確認させることができる。
なお、ここでは通信方法に無線通信と有線通信を例に上げて比較し、無線通信に送信済みの画像を送信元に通知するものとしたが、例えば単に有線通信と無線通信とする以外に通信方法の値を設定できるようにしてもよい。例えば無線通信であれば1x、3G、4G等を通信方法の値として設定可能な場合、1xで通信を行っている端末に送信済みの画像を通知先に通知するようにしてもよい。どの通信方法の端末に送信済みの画像を通知先に通知するかは、不図示の設定画面において、ユーザ操作により自由に設定・変更可能であるもとする。また、当該設定・変更の操作を受け付けることにより、ウェブ会議サーバ200が、設定・変更された通信方法(所定の通信方法)で通信している端末に送信済みの画像を通知先に通知する設定情報を自装置の外部メモリに記憶するものとする。
また、図15の1500に示すような画面を、会議画面における不図示の設定ボタンの押下に応じてクライアント端末100の表示画面に表示し、「カメラ」ボタン1502の押下を受け付けることで、ウェブ会議サーバ200が、図5のステップS501〜505及び、指定されたカメラ画像の共有がされている場合における図7のステップS700〜705の処理を実行するか否かを決定し、切替えるようにしてもよい。また、「アプリケーション共有」ボタン1503の押下を受け付けることで、ウェブ会議サーバ200が、指定されたアプリケーションの画面の画像及びデスクトップ画面の画像の共有がされている場合における図7のステップS700〜705の処理を実行するか否かを決定し、切替えるようにしてもよい。
また、例えば、適切に画像が送受信されているか否かに応じて、電子会議における画像の受信状況を容易に確認可能とする仕組みを提供するようにしてもよい。
具体的には、ステップS502で、処理中の画像が全てクライアント端末100に送信済みの送信済み画像であると判定された場合に、過去所定時間の間(例えば5秒以上前から現在までの間)、当該ステップS502によって処理中の画像が送信済み画像であると判定され続けているか判定する。つまり、会議に参加している全てのクライアント端末100が、画像を取りこぼすことなく受信しているか(所定の時間の間、全てのクライアント端末100が図9に示すクライアント端末100Sのような状態にあるか)判定する。同じ会議に参加中の全てのクライアント端末100が、所定時間の間、画像を取りこぼすことなく受信していると判定された場合には、画像の受信・表示の中抜けや遅延によるミスコミュニケーションが発生しないため、送信済み画像を通知先(例えば画像の送信元)に通知する必要はないと判断し、図5の処理を終了する。同じ会議に参加中の全てのクライアント端末100が、所定時間の間、画像を取りこぼすことなく受信していると判定されなかった場合は、画像を取りこぼしている=画像の受信・表示の中抜けや遅延が発生しているクライアント端末100(例えば図9でいうクライアント端末100G1、100G2)が存在すると判断し、処理をステップS503に移行して、送信済み画像の通知処理を継続する。
また、図7の処理の場合は、ステップS702において、ウェブ会議サーバ200のCPU201が、処理中の画像が全てクライアント端末100に送信済みの送信済み画像であると判定された場合に、過去所定時間の間(例えば5秒以上前から現在までの間)、当該ステップS702によって処理中の画像が送信済み画像であると判定され続けているか判定する。つまり、会議に参加している全てのクライアント端末100が、クライアント端末100Hから送信されている指定画像を取りこぼすことなく受信しているか判定する。同じ会議に参加中の全てのクライアント端末100が、所定時間の間、画像を取りこぼすことなく受信していると判定された場合には、画像の受信・表示の中抜けや遅延によるミスコミュニケーションが発生しないため、送信済み画像を通知先(例えば指定画像の送信元であるクライアント端末100H)に通知する必要はないと判断し、図5の処理を終了する。同じ会議に参加中の全てのクライアント端末100が、所定時間の間、画像を取りこぼすことなく受信していると判定されなかった場合は、画像を取りこぼしている=画像の受信・表示の中抜けや遅延が発生しているクライアント端末100(例えば図9でいうクライアント端末100G1、100G2)が存在すると判断し、処理をステップS703に移行して、送信済み画像の通知処理を継続する。
これにより、例えば所定時間の間、全ての会議参加者が適切に画像を受信している場合には画像の受信状況の通知を行わず、通信負荷を軽減し、切に画像を受信していない参加者がいる場合には画像の受信状況の通知をして、当該受信状況をユーザに確認させることができる。
なお、上述した実施形態においては、会議の前参加者に送信済みの送信済み画像のシーケンス番号と、当該送信済み画像を最後に受信したクライアント端末のユーザIDとを通知先に通知するものとしたが、例えば、どちらか一方のみを通知するようにしてもよい。また、クライアント端末100は、当該送信済み画像とユーザIDとの両方を、図11の1111に示すように表示画面に表示するものとしたが、どちらか一方のみを表示するようにしてもよい。
前記ユーザIDを通知するだけでも、通知されたクライアント端末は、少なくとも画像を最後に受信して表示している他のクライアント端末の存在及びその端末のユーザを確認することが可能である。また、当該ユーザIDを会議画面に表示することで、会議画面を表示中のユーザに視覚的に、どのユーザが画像を最後に受信して見ているユーザかを確認させることができる。
また、送信済み画像のシーケンス番号を通知するだけでも、通知されたクライアント端末は、少なくとも画像を最後に受信して表示している他のクライアント端末の存在を確認することができる。また、当該送信済み画像を表示することで、最後に当該送信済み画像を受信した端末でどのような画像が表示されているか(リアルタイム画像とどの程度の差があるか)をユーザに確認させることができる。
なお、上述した実施形態においては、クライアント端末100は、「User001(User002)」という文字列を表示画面に表示することで、User001から送信した画像を最後に取得したのがUser002であることをユーザに通知していたが、他の通知方法を用いてもよい。例えば「User001から送信した画像を最後に取得したのはUser002である」と音声を再生することで通知してもよい。
また、クライアント端末100において、画像の表示のONとOFFを切替えられる場合、画像の表示をOFFにしているクライアント端末100には、画像キューの画像を送信しない(クライアント端末100からの画像の取得要求がない)ことがある。よって、例えば、クライアント端末100画像の表示機能のON/OFFの状態を、ON/OFfが切替えられたタイミングでウェブ会議サーバ200に通知し、当該通知を受け付けたウェブ会議サーバ200のCPU201が、いずれのクライアント端末100(端末ID)の画像の表示機能がONか(OFF)かを外部メモリに記憶・管理しておき、ステップS502及びステップS702においては、ステップS501またはS701で取得した画像が、当該画像の表示機能がONになっている全ての会議参加者に送信済みの画像かを半定するようにしてもよい。画像の表示機能がONになっている全ての会議参加者(クライアント端末100)に送信済みの画像であれば、図5の場合は処理をステップS503に、図7の場合は処理をステップS703に移行する。
また、図10や図11、図12に示す画面(ウインドウ)を非表示にしているクライアント端末100には、画像キューの画像を送信しない(そもそも、クライアント端末100からの画像の取得要求がない)ことがある。
よって例えば、ウェブ会議サーバ200のCPU201が、ステップS501、ステップS701で取得した画像が割り当てられた表示領域が表示画面上に含まれているかを、各クライアント端末100に対して定期的に問い合せる。そして、ステップS502及びステップS702では、ステップS501、ステップS701で取得した画像が、当該表示領域が画面上に含まれていると返答したクライアント端末100のうち全てのクライアント端末100に送信済みかを判定し、当該画像が、当該表示領域が画面上に含まれていると返答した全てのクライアント端末100に送信済みの画像であれば、図5の場合は処理をステップS503に、図7の場合は処理をステップS703に移行する。
これにより、クライアント端末における画像の表示設定や実際の表示状態に応じて、電子会議における画像の受信状況を容易に確認可能とする仕組みを提供することができる。
以上説明したように、本発明によれば、電子会議における画像の受信状況を容易に確認可能とする仕組みを提供することができる。
尚、本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、1つの機器からなる装置に適用してもよい。
具体的には、ホスト端末(クライアント端末100)とウェブ会議サーバ200が一体であり、例えば図3の321〜326の各機能部で説明した機能をホスト端末が備え、上述した実施形態の各処理のうち、ウェブ会議サーバが実行する処理(図6のステップS606〜S608、S611〜S614、図7のステップS700〜S705で説明した各ステップの処理)を実行するようにしてもよい。
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接、或いは遠隔から供給するものを含む。そして、そのシステム或いは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合も本発明に含まれる。
したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、MO、CD−ROM、CD−R、CD−RWなどがある。また、磁気テープ、不揮発性のメモリカード、ROM、DVD(DVD−ROM,DVD−R)などもある。
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるWWWサーバも、本発明に含まれるものである。
また、本発明のプログラムを暗号化してCD−ROM等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているOSなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。
尚、前述した実施形態は、本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。
即ち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。