(57)【特許請求の範囲】
【請求項１】
企業の社員端末と顧客端末間でのビデオチャットサービスを提供する装置であって、
前記社員端末は、ＷｅｂＲＴＣのライブラリを利用せずにビデオチャットの処理を実行する第１処理部と、ＷｅｂＲＴＣのライブラリを利用してビデオチャットの処理を実行する第２処理部を含むものであり、
前記顧客端末から前記ビデオチャットサービスが要求された場合に、前記顧客端末の種類を識別する顧客端末識別部と
前記顧客端末の種類に応じて、ＷｅｂＲＴＣのライブラリを利用しない前記ビデオチャットサービスのコンテンツまたはＷｅｂＲＴＣのライブラリを利用する前記ビデオチャットサービスのコンテンツを前記顧客端末へ提供する顧客側提供部と、
前記顧客端末の種類に応じて、前記第１処理部により実行される前記ビデオチャットサービスのコンテンツまたは前記第２処理部により実行される前記ビデオチャットサービスのコンテンツを前記社員端末へ提供する社員側提供部と
を備えることを特徴とする情報処理装置。
【請求項２】
企業の社員端末と顧客端末間でのビデオチャットサービスを提供する装置が実行する方法であって、
前記社員端末は、ＷｅｂＲＴＣのライブラリを利用せずにビデオチャットの処理を実行する第１処理部と、ＷｅｂＲＴＣのライブラリを利用してビデオチャットの処理を実行する第２処理部を含むものであり、
前記顧客端末から前記ビデオチャットサービスが要求された場合に、前記顧客端末の種類を識別するステップと
前記顧客端末の種類に応じて、ＷｅｂＲＴＣのライブラリを利用しない前記ビデオチャットサービスのコンテンツまたはＷｅｂＲＴＣのライブラリを利用する前記ビデオチャットサービスのコンテンツを前記顧客端末へ提供するステップと、
前記顧客端末の種類に応じて、前記第１処理部により実行される前記ビデオチャットサービスのコンテンツまたは前記第２処理部により実行される前記ビデオチャットサービスのコンテンツを前記社員端末へ提供するステップと
を備えることを特徴とするサービス提供方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理技術に関し、特に情報処理装置およびサービス提供方法に関する。
【背景技術】
【０００２】
本出願人は、顧客応対を支援するためのビデオチャット技術を提案している（例えば特許文献１参照）。また、ウェブを介してリアルタイムに動画や音声を交換するための技術仕様としてＷｅｂＲＴＣ（Web Real-Time Communication）が提唱されている（例えば特許文献２参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１３−０８４１２３号公報
【特許文献２】特開２０１４−０７１５３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
企業オペレータとのビデオチャットを要求する顧客の端末には様々な種類が存在する。例えば、ある顧客の端末と別の顧客の端末とでは、ＯＳ（Operating System）やウェブブラウザが異なり、異なる情報処理方法によりビデオチャットを実行することがある。したがって、顧客端末の種類に応じたビデオチャットのコンテンツ（画面等）を顧客端末に提供する必要があり、また、オペレータ端末に対しても顧客端末の種類に応じたビデオチャットのコンテンツを提供する必要がある。その結果、オペレータ端末においても異なる情報処理方法によりビデオチャットを実行する必要が生じる。
【０００５】
本発明者は、複数種類の顧客端末に対して、単一のオペレータ端末で対応可能にすることの必要性を認識した。顧客端末の種類に応じたオペレータ端末を用意し、オペレータに使い分けさせることは不経済であり、また非効率だからである。
【０００６】
本願発明は本発明者の上記課題認識に基づくものであり、その主な目的は、所定のサービスの提供先となる顧客端末が複数種類存在する場合でも、単一の社員端末による顧客応対を実現する技術を提供することである。
【課題を解決するための手段】
【０００７】
上記課題を解決するために、本発明のある態様の情報処理装置は、企業の社員端末と顧客端末に所定のサービスを提供する装置であって、社員端末は、第１の方法によりサービスに関する処理を実行する第１処理部と、第１の方法とは異なる第２の方法によりサービスに関する処理を実行する第２処理部を含むものであり、顧客端末からサービスが要求された場合に、顧客端末の種類を識別する顧客端末識別部と、顧客端末の種類に応じて、第１の方法により実行されるサービスのコンテンツまたは第２の方法により実行されるサービスのコンテンツを顧客端末へ提供する顧客側提供部と、顧客端末の種類に応じて、第１処理部により実行されるサービスのコンテンツまたは第２処理部により実行されるサービスのコンテンツを社員端末へ提供する社員側提供部と、を備える。
【０００８】
本発明の別の態様もまた、情報処理装置である。この装置は、企業の社員端末と顧客端末間でのビデオチャットサービスを提供する装置であって、社員端末は、ＷｅｂＲＴＣのライブラリを利用せずにビデオチャットの処理を実行する第１処理部と、ＷｅｂＲＴＣのライブラリを利用してビデオチャットの処理を実行する第２処理部を含むものであり、顧客端末からビデオチャットサービスが要求された場合に、顧客端末の種類を識別する顧客端末識別部と、顧客端末の種類に応じて、ＷｅｂＲＴＣのライブラリを利用しないビデオチャットサービスのコンテンツまたはＷｅｂＲＴＣのライブラリを利用するビデオチャットサービスのコンテンツを顧客端末へ提供する顧客側提供部と、顧客端末の種類に応じて、第１処理部により実行されるビデオチャットサービスのコンテンツまたは第２処理部により実行されるビデオチャットサービスのコンテンツを社員端末へ提供する社員側提供部と、を備える。
【０００９】
本発明のさらに別の態様は、サービス提供方法である。この方法は、企業の社員端末と顧客端末に所定のサービスを提供する装置が実行する方法であって、社員端末は、第１の方法によりサービスに関する処理を実行する第１処理部と、第１の方法とは異なる第２の方法によりサービスに関する処理を実行する第２処理部を含むものであり、顧客端末からサービスが要求された場合に、顧客端末の種類を識別するステップと、顧客端末の種類に応じて、第１の方法により実行されるサービスのコンテンツまたは第２の方法により実行されるサービスのコンテンツを顧客端末へ提供するステップと、顧客端末の種類に応じて、第１処理部により実行されるサービスのコンテンツまたは第２処理部により実行されるサービスのコンテンツを社員端末へ提供するステップと、を備える。
【００１０】
なお、以上の構成要素の任意の組合せ、本発明の表現を、装置、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１１】
本発明によれば、所定のサービスの提供先となる顧客端末が複数種類存在する場合でも、単一の社員端末による顧客応対を実現することができる。
【図面の簡単な説明】
【００１２】
【図１】実施の形態のビデオチャットシステムの構成を示す図である。
【図２】図１のオペレータ端末のソフトウェア構成を示す図である。
【図３】図１のビデオチャットサーバのソフトウェア構成を示す図である。
【図４】図１のビデオチャットサーバの機能構成を示すブロック図である。
【図５】顧客端末がＰＣで、第１ＶＣ提供時の動作を模式的に示す図である。
【図６】顧客端末がｉＯＳ端末またはＡｎｄｒｏｉｄ端末で、第１ＶＣ提供時の動作を模式的に示す図である。
【図７】顧客端末がＰＣで、第２ＶＣ提供時の動作を模式的に示す図である。
【図８】顧客端末がＡｎｄｒｏｉｄ端末で、第２ＶＣ提供時の動作を模式的に示す図である。
【図９】顧客端末がｉＯＳ端末で、第２ＶＣ提供時の動作を模式的に示す図である。
【発明を実施するための形態】
【００１３】
現在、リアルタイムでの動画配信技術としてＦＬＡＳＨ（登録商標）が知られている。しかし、タブレット端末やスマートフォンは通常、ＦＬＡＳＨ形式の動画データの復号・再生に未対応である。そこで本発明者は、ＦＬＡＳＨに代わる動画配信技術としてＷｅｂＲＴＣ（Web Real-Time Communication）に着目した。ＷｅｂＲＴＣは、ウェブブラウザからカメラへアクセスして動画データを取得する機能、ウェブブラウザからマイクへアクセスして音声データを取得する機能、リアルタイム通信機能等を含む。
【００１４】
実施の形態では、ＷｅｂＲＴＣを利用しないビデオチャット（以下「第１ＶＣ」とも呼ぶ。）の提供と、ＷｅｂＲＴＣを利用するビデオチャット（以下「第２ＶＣ」とも呼ぶ。）の提供を顧客端末の種類に応じて切り替える。後述するように、第１ＶＣでは、顧客端末がＰＣであればＦＬＡＳＨによる動画配信・再生を実行し、顧客端末がモバイル端末であればｍｐｅｇによる動画配信・再生を実行する。第２ＶＣは、データの圧縮効率や通信速度の面で第１ＶＣより有利である。実施の形態のビデオチャットサーバは、ＷｅｂＲＴＣに対応する顧客端末には第２ＶＣを提供する一方、ＷｅｂＲＴＣに未対応の顧客端末には第１ＶＣを提供することにより、様々な種類の顧客端末が利用可能なビデオチャットサービスを提供する。
【００１５】
ところで、ビデオチャットにて顧客応対を実施するオペレータ端末は、第１ＶＣか第２ＶＣかに関わらず単一であることが望ましく、すなわち、単一のオペレータ端末で、第１ＶＣと第２ＶＣの両方を実行可能であることが望ましい。ビデオチャットの種類に応じて端末の使い分けが必要になると、オペレータの作業が複雑化し、また作業効率が低下するためである。
【００１６】
本発明者は、オペレータ端末は顧客端末とは異なり環境を自由に設定できることに着目した。実施の形態のオペレータ端末は、第１ＶＣを実行するための処理部と、第２ＶＣを実行するための処理部の両方を備える。ビデオチャットサーバ１２は、顧客端末に提供するビデオチャットコンテンツの種類に応じたビデオチャットのコンテンツをオペレータ端末へ提供し、オペレータ端末におけるビデオチャットの処理部を自動的に切り替えさせる。これにより、様々な種類の顧客端末が利用可能なビデオチャットサービスを提供しつつ、単一のオペレータ端末による顧客応対を実現する。言い換えれば、オペレータ端末の環境は固定したまま、複数種類のビデオチャットの方式に柔軟に対応させることができる。
【００１７】
図１は、実施の形態のビデオチャットシステム１０の構成を示す。ビデオチャットシステム１０は、ビデオチャットサーバ１２、オペレータ端末１４、顧客端末１６を備える。ビデオチャットサーバ１２とオペレータ端末１４は、企業のイントラネット内に設けられる。このイントラネット内にはバックオフィスシステム２４も設けられる。
【００１８】
ビデオチャットサーバ１２は、企業（例えばメーカや小売）が販売する商品の説明や、疑問・お悩みに対する相談、対話を行うためのビデオチャットサービスを提供する。ビデオチャットサーバ１２は、企業における顧客応対担当者（以下「オペレータ」と呼ぶ。）と顧客との対話を実現するために、オペレータ端末１４と顧客端末１６間で映像データ（または、映像データおよび音声データ）を中継する。
【００１９】
ビデオチャットは、映像および音声の同時交換サービスであり、テレビ電話とも言える。例えば、双方向のビデオチャットでは、オペレータ端末１４と顧客端末１６のそれぞれにオペレータと顧客の映像を表示し、オペレータ端末１４は顧客側から提供された音声を出力し、顧客端末１６はオペレータ側から提供された音声を出力してもよい。また、片方向のビデオチャットでは、音声は双方向と同じだが、映像については、オペレータ端末１４と顧客端末１６のいずれにもオペレータの映像のみを表示してもよい。
【００２０】
オペレータ端末１４は、企業のオペレータが操作する情報機器であり、例えばＰＣである。オペレータ端末１４は、ＬＡＮやＷＡＮを介してビデオチャットサーバ１２、バックオフィスシステム２４と接続される。オペレータ端末１４は、スピーカ、マイク、ウェブカメラ（リアルタイムカメラ、ライブカメラとも言う）を備える。
【００２１】
バックオフィスシステム２４は、オペレータの業務を支援するための事務機能や管理機能を提供し、例えばスケジュール管理や勤怠管理を実行する。バックオフィスシステム２４は、バックオフィスシステムのウェブコンテンツ（以下「ＢＯ画面」と呼ぶ。）をオペレータ端末１４へ提供する。ＢＯ画面は、例えばスケジュール管理画面や勤怠管理画面である。
【００２２】
バックオフィスシステム２４は、Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（商標または登録商標、以下「ＩＥ」と呼ぶ。）によるＢＯ画面の表示をサポートするが、Ｇｏｏｇｌｅ  Ｃｈｒｏｍｅ（商標または登録商標、以下「Ｃｈｒｏｍｅ」と呼ぶ。）によるＢＯ画面の表示はサポートしない。したがって、オペレータ端末１４では、ＢＯ画面をＩＥで表示させる必要がある。
【００２３】
顧客端末１６は、企業が提供するビデオチャットサービスを享受するクライアント機器であり、インターネットを介してビデオチャットサーバ１２に接続される。顧客端末１６は、スピーカ、マイク、ウェブカメラを備える。顧客端末１６は、ＰＣ１８、ｉＯＳ端末２０、Ａｎｄｒｏｉｄ端末２２を含む。ＰＣ１８にはＯＳとして、Ｗｉｎｄｏｗｓ（登録商標）やＭａｃｉｎｔｏｓｈ（商標または登録商標）等が搭載される。ｉＯＳ端末２０は、ＯＳとしてｉＯＳ（商標または登録商標）が搭載されたスマートフォンやタブレット端末である。Ａｎｄｒｏｉｄ端末２２は、ＯＳとしてＡｎｄｒｏｉｄ（商標または登録商標）が搭載されたスマートフォンやタブレット端末である。
【００２４】
図２は、図１のオペレータ端末１４のソフトウェア構成を示す。オペレータ端末１４には、ＯＳ３０としてＷｉｎｄｏｗｓが搭載される。ＯＳ３０には、ウェブブラウザとしてＩＥ３２とＣｒｏｍｅ３４を導入する。ＩＥ３２は、ＷｅｂＲＴＣを使用せずにビデオチャット処理を実行し、例えばＦＬＡＳＨを使用してビデオチャット処理を実行する。Ｃｒｏｍｅ３４は、ＷｅｂＲＴＣを使用してビデオチャット処理を実行する。
【００２５】
Ｃｒｏｍｅ３４は、ＪＳライブラリ５０、ウェブソケット５２、ＦＬＡＳＨソケット５４、ＷｅｂＲＴＣライブラリ５６を含む。ビデオチャットコンテンツ４８は、ビデオチャットサーバ１２から提供されたＣｒｏｍｅ３４用のウェブコンテンツであり、ビデオチャットのユーザインタフェースとなるビデオチャット画面のデータを含む。Ｃｒｏｍｅ３４は、ビデオチャットコンテンツ４８に対する解析処理やレンダリング処理を実行し、ビデオチャット画面をＣｒｏｍｅ３４のウィンドウに表示させる。
【００２６】
ビデオチャットコンテンツ４８は、ＷｅｂＲＴＣライブラリ５６およびＪＳライブラリ５０を使用して、言い換えれば、これらのライブラリのＡＰＩをコールして、ビデオチャットの処理を実行する。例えば、（１）ローカルのマイクから音声データを取得し、ビデオチャットサーバ１２へ送信する。（２）ビデオチャットサーバ１２から送信されたリモート（顧客側）の音声データを取得し、ローカルのスピーカから出力させる。
【００２７】
（３）ローカルのウェブカメラから撮像データを取得し、その撮像データをビデオチャットの画面に表示させるとともにビデオチャットサーバ１２へ送信する。（４）ビデオチャットサーバ１２から送信されたリモート（顧客側）の映像データを取得し、ビデオチャットの画面に表示させる。上記の（１）〜（３）は、片方向ビデオチャットか、双方向ビデオチャットかに関わらず実行され、（４）は双方向ビデオチャットの場合にのみ実行される。
【００２８】
ＩＥ３２は、ＪＳライブラリ４０、ウェブソケット４２、ＦＬＡＳＨソケット４４、ＦＬＡＳＨプレーヤ４６を含む。ビデオチャットコンテンツ３８は、ビデオチャットサーバ１２から提供されたＩＥ３２用のウェブコンテンツであり、ビデオチャットのユーザインタフェースとなるビデオチャット画面のデータを含む。ＩＥ３２は、ビデオチャットコンテンツ３８に対する解析処理やレンダリング処理を実行し、ビデオチャット画面をＩＥ３２のウィンドウに表示させる。
【００２９】
ビデオチャットコンテンツ３８は、ＪＳライブラリ５０を使用して、言い換えれば、ＪＳライブラリ５０のＡＰＩをコールして、ビデオチャットの処理を実行する。例えば、（１）ローカルのウェブカメラから撮像データを取得し、その撮像データをビデオチャットの画面に表示させるとともにビデオチャットサーバ１２へ送信する。（２）ビデオチャットサーバ１２から送信されたリモート（顧客側）の映像データを取得し、ビデオチャットの画面に表示させる。上記の（１）は、片方向ビデオチャットか、双方向ビデオチャットかに関わらず実行され、（２）は双方向ビデオチャットの場合にのみ実行される。実施の形態では、ビデオチャットコンテンツ３８によるビデオチャット、すなわち第１ＶＣでは、オペレータと顧客の対話は不図示の電話でなされるため、音声の伝送処理は実行されない。
【００３０】
ＩＥ３２は、バックオフィスシステム２４から提供されたバックオフィスシステムの画面（ＢＯ画面３５）を表示させ、また、ビデオチャットサーバ１２から提供されたビデオチャットの待受画面３６を表示させる。ＢＯ画面３５の中に待受画面３６を表示する構成としてもよいことはもちろんである。
【００３１】
図３は、図１のビデオチャットサーバ１２のソフトウェア構成を示す。ビデオチャットサーバ１２には、ＯＳ６０としてＬＩＮＵＸ（登録商標）が搭載される。ＯＳ６０には、ａｐａｃｈｅ（商標または登録商標）６２、ＴＵＲＮサーバ６６、ストリーミングエンジン６８、ｆｆｍｐｅｇ７０、Ｎｏｄｅ．ｊｓ７２を導入する。
【００３２】
ａｐａｃｈｅ６２は、公知のウェブサーバ製品である。ａｐａｃｈｅ６２は、リバースプロキシとしてのプロキシ機能６４を含む。ｆｆｍｐｅｇ７０は、ＦＬＡＳＨ形式の映像データをｍｐｅｇ形式の映像データに変換する公知の製品である。
【００３３】
ＴＵＲＮサーバ６６は、ＩＣＥサーバとも言え、ＷｅｂＲＴＣの規格により定められた公知のサーバ機能である。ＴＵＲＮサーバ６６は、ビデオチャットを行う端末間でのＷｅｂＲＴＣによるデータ交換を仲介する。ＴＵＲＮサーバ６６は、オペレータ端末１４と顧客端末１６それぞれのアドレスを管理する。ＴＵＲＮサーバ６６は、オペレータ端末１４で取得され、オペレータ端末１４から送信された音声データ・映像データを受信し、顧客端末１６へ転送する。また、顧客端末１６で取得され、顧客端末１６から送信された音声データ・映像データを受信し、オペレータ端末１４へ転送する。
【００３４】
ストリーミングエンジン６８は、ビデオチャットを行う端末間でのＦＬＡＳＨによるデータ交換を仲介するサーバ機能である。ストリーミングエンジン６８は、音声や映像をストリーミング配信する公知のストリーミングサーバであってもよい。例えばストリーミングエンジン６８は、オペレータ端末１４で取得され、オペレータ端末１４から送信された映像データを受信し、顧客端末１６へ転送する。また、顧客端末１６で取得され、顧客端末１６から送信された映像データを受信し、オペレータ端末１４へ転送する。
【００３５】
Ｎｏｄｅ．ｊｓ７２は、サーバサイドのＪａｖａＳｃｒｉｐｔ（登録商標）インタプリタである。Ｎｏｄｅ．ｊｓ７２上で動作するモジュールとしてビデオチャットサーバ機能７４とモバイルストリームサービス７８を備える。モバイルストリームサービス７８は、ｆｆｍｐｅｇ７０が生成したｍｐｅｇデータを、モバイル端末、すなわちビデオチャットを要求したｉＯＳ端末２０またはＡｎｄｒｏｉｄ端末２２へ送信する。
【００３６】
ビデオチャットサーバ機能７４は、ビデオチャットのための種々の管理処理・制御処理を実行する。例えば、ビデオチャットサーバ機能７４は、オペレータと顧客とが会話を行うための仮想的な会議室を生成し、オペレータと顧客の会議室への入退室管理を実行する。ビデオチャットサーバ機能７４は、クライアントＩＦ機能７６を含む。クライアントＩＦ機能７６は、オペレータ端末１４と顧客端末１６のそれぞれと制御情報やプレゼンテーション情報を送受する。
【００３７】
図４は、図１のビデオチャットサーバ１２の機能構成を示すブロック図である。本明細書のブロック図において示す各ブロックは、ハードウェア的には、コンピュータのＣＰＵやメモリをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、図４に示す各ブロックはプログラムモジュールとして実装されてビデオチャットサーバ１２のストレージに格納され、ビデオチャットサーバ１２のＣＰＵがそれらのプログラムモジュールをメインメモリに読み出して適宜実行することにより、各ブロックの機能が発揮されてよい。
【００３８】
ビデオチャットサーバ１２は、通信部８０、制御部８１、記憶部８２を備える。通信部８０は、種々の通信プロトコルにしたがって外部装置との通信処理を実行する。制御部８１は、ビデオチャットサービスに関する各種データ処理を実行し、通信部８０を介して外部装置とデータを送受信する。記憶部８２は、制御部８１により使用される各種データを記憶する記憶領域である。
【００３９】
記憶部８２は、画面データ保持部８４と識別基準保持部８６を含む。画面データ保持部８４は、ビデオチャットサービスのウェブコンテンツ（ウェブページデータ）を保持する。具体的には、顧客用のビデオチャット画面を表示させるためのウェブコンテンツと、オペレータ用のビデオチャット画面を表示させるためのウェブコンテンツを保持する。また、オペレータ用の顧客待受画面を表示させるためのウェブコンテンツを保持する。
【００４０】
顧客用のビデオチャット画面を表示させるためのウェブコンテンツは、映像データや音声データの取得や送信にＷｅｂＲＴＣライブラリを使用しない第１ＶＣ顧客画面のデータと、ＷｅｂＲＴＣライブラリを使用する第２顧客ＶＣ画面のデータを含む。また、オペレータ用のビデオチャット画面を表示させるためのウェブコンテンツは、映像データや音声データの取得や送信にＷｅｂＲＴＣライブラリを使用しない第１ＶＣ社員画面のデータと、ＷｅｂＲＴＣライブラリを使用する第２ＶＣ社員画面のデータを含む。後述するように、第１ＶＣ社員画面のデータは、ＩＥ３２のライブラリを使用し、またＦＬＡＳＨのライブラリを使用するウェブコンテンツとも言える。また、第２ＶＣ社員画面のデータは、Ｃｒｏｍｅ３４のライブラリを使用するウェブコンテンツとも言える。
【００４１】
識別基準保持部８６は、顧客端末１６の種類を識別するための基準データを保持する。この基準データは、顧客端末１６が、ＷｅｂＲＴＣを利用せずにビデオチャット処理を実行する端末か、ＷｅｂＲＴＣを利用してビデオチャット処理を実行する端末かの識別基準を示す。言い換えれば、顧客端末１６が、ＷｅｂＲＴＣを使用しないビデオチャットコンテンツ（例えば第１ＶＣ顧客画面）を提供すべき端末か、ＷｅｂＲＴＣを使用するビデオチャットコンテンツ（例えば第２ＶＣ顧客画面）を提供すべき端末かの識別基準とも言える。
【００４２】
またビデオチャットでは、顧客端末１６において入出力される情報と、オペレータ端末１４において入出力される情報を同期させる必要があり、顧客端末１６でのビデオチャット画面の種類と、オペレータ端末１４でのビデオチャット画面の種類をあわせる必要がある。したがって、識別基準保持部８６の基準データは、オペレータ端末１４に対して、ＷｅｂＲＴＣを使用しないビデオチャットコンテンツ（例えば第１ＶＣ社員画面データ）とＷｅｂＲＴＣを使用するビデオチャットコンテンツ（例えば第２ＶＣ社員画面データ）のいずれを提供するかの決定基準とも言える。
【００４３】
実施の形態における識別基準保持部８６の基準データは、第１ＶＣを示すＵＲＬと、第２ＶＣを示すＵＲＬを含む。第１ＶＣを示すＵＲＬは、企業のウェブページにおいて第１ＶＣの開始を示すリンクに設定され、第２ＶＣを示すＵＲＬは、企業のウェブページにおいて第２ＶＣの開始を示すリンクに設定されてもよい。また識別基準保持部８６の基準データは、顧客端末１６がＰＣ１８であることを示すユーザエージェント情報のキーワードと、顧客端末１６がｉＯＳ端末２０であることを示すユーザエージェント情報のキーワードと、顧客端末１６がＡｎｄｒｏｉｄ端末２２であることを示すユーザエージェント情報のキーワードを含む。
【００４４】
制御部８１は、要求受付部８８、顧客端末識別部９０、待受画面提供部９２、入室通知部９４、ＶＣ顧客画面提供部９６、ＶＣ社員画面提供部９８、ＶＣ制御情報中継部１００、ＶＣ映像中継部１０２、ＶＣ音声中継部１０４を含む。
【００４５】
要求受付部８８は、顧客端末１６から送信された、ビデオチャットサービスの提供を要求する要求電文を受け付ける。顧客端末識別部９０は、識別基準保持部８６に格納された識別基準と、要求受付部８８が受け付けた要求電文にしたがって、顧客端末１６の種類を識別する。顧客端末識別部９０は、要求電文で指定されたＵＲＬと、要求電文が含むユーザエージェント情報にしたがって、顧客端末１６およびオペレータ端末１４へ提供すべきビデオチャット画面の種類を決定する。
【００４６】
具体的には、顧客端末識別部９０は、要求電文での指定ＵＲＬが第１ＶＣを示すＵＲＬか、第２ＶＣを示すＵＲＬかを識別する。すなわち、顧客端末１６が、ＷｅｂＲＴＣのライブラリを利用してビデオチャット処理を実行させるべき端末か、ＷｅｂＲＴＣのライブラリを利用せずにビデオチャット処理を実行させるべき端末かを識別する。また顧客端末識別部９０は、顧客端末１６が、ＰＣ１８、ｉＯＳ端末２０、Ａｎｄｒｏｉｄ端末２２のいずれであるかを識別する。
【００４７】
待受画面提供部９２は、ビデオチャットサービスが顧客により要求されたかどうかの状況を表示する画面であるオペレータ用の待受画面３６のウェブページをオペレータ端末１４へ提供する。待受画面３６は、バックオフィスシステム２４が提供するＢＯ画面３５と同様に、オペレータ端末１４のＩＥ３２により表示される。
【００４８】
入室通知部９４は、要求受付部８８がビデオチャットサービスの要求電文を受け付けた場合に、ビデオチャットサービスが顧客により要求された事実を示す情報を含むウェブコンテンツ（以下「ＶＣ要求受付通知」と呼ぶ。）をオペレータ端末１４へ送信する。そして、オペレータ端末１４の待受画面３６にＶＣ要求受付通知を表示させる。
【００４９】
ＶＣ要求受付通知は、オペレータ用のビデオチャット画面へのリンク（以下「ＶＣ画面リンク」と呼ぶ。）を含む。入室通知部９４は、顧客端末識別部９０による識別結果に応じて、ＶＣ画面リンクのデータを設定する。例えば、要求電文での指定ＵＲＬが第１ＶＣの場合、第１ＶＣ社員画面を示すデータとして、ビデオチャットサーバ１２が提供する第１ＶＣ社員画面の位置を示す通常のＵＲＬ文字列を設定する。その一方、要求電文での指定ＵＲＬが第２ＶＣの場合、第２ＶＣ社員画面を示すデータとして、特殊なＵＲＬ文字列（以下「特殊ＵＲＬ」とも呼ぶ。）を設定する。
【００５０】
特殊ＵＲＬは、ＷｉｎｄｏｗｓＯＳが提供するカスタムＵＲＬスキームの利用に際して予め定められたＵＲＬ文字列である。具体的には、オペレータ端末１４にはＣｒｏｍｅ３４の起動アプリケーションが保存される。このアプリは、Ｃｒｏｍｅ３４の実行形式の位置情報と、ビデオチャットサーバ１２が提供する第２ＶＣ社員画面の位置を示す通常のＵＲＬを示す情報を含む。オペレータ端末１４のＷｉｎｄｏｗｓのレジストリには、特殊ＵＲＬとＣｒｏｍｅ起動アプリとが予め対応付けて記録される。
【００５１】
待受画面３６に表示されたＶＣ画面リンクをオペレータが選択すると、オペレータ端末１４は、カスタムＵＲＬスキームにしたがって、特殊ＵＲＬに対応付けられたＣｒｏｍｅ起動アプリを実行する。Ｃｒｏｍｅ起動アプリは、第２ＶＣ社員画面のＵＲＬを引数としてＣｒｏｍｅ３４を起動する。Ｃｒｏｍｅ３４は、第２ＶＣ社員画面のＵＲＬを指定してビデオチャットサーバ１２にアクセスし、第２ＶＣ社員画面のウェブページをビデオチャットサーバ１２から取得してブラウザウィンドウに表示させる。
【００５２】
ＩＥ３２にもＷｅｂＲＴＣライブラリをプラグインとして組み込むことができる。しかし、現状のプラグインには、通信の帯域制御ができず、例えば映像データの送信において帯域をフルに使用してしまう、また音声デバイスの制御ができない等の問題があることが発明者の検証で明らかになった。その一方で、Ｃｒｏｍｅ３４は、ＷｅｂＲＴＣライブラリ５６を標準で備え、また上記の問題は発生しない。そこでオペレータ端末１４では、バックオフィスシステム２４が提供するウェブコンテンツであるＢＯ画面３５と、待受画面３６をＩＥ３２に表示させつつ、必要に応じてカスタムＵＲＬスキームによりＩＥ３２からＣｒｏｍｅ３４を起動させる。
【００５３】
すなわち、ＷｅｂＲＴＣライブラリが不要な第１ＶＣ社員画面はＩＥ３２で表示させる一方、ＷｅｂＲＴＣライブラリが必須の第２ＶＣ社員画面を表示すべき場合は、ＩＥ３２からＣｒｏｍｅ３４をシームレスに起動し、第２ＶＣ社員画面をＣｒｏｍｅ３４で表示させる。これにより、第２ＶＣ顧客画面を使用したビデオチャット以外では、オペレータは、バックオフィスシステム２４のコンテンツを表示可能なＩＥ３２で作業ができ、ウェブブラウザの使い分けによるオペレータの負担を低減し、また作業の効率化を実現する。
【００５４】
なお、一旦Ｃｈｒｏｍｅ起動アプリを実行して、Ｃｒｏｍｅ３４を起動させるが、これは、本発明者の検証においてカスタムＵＲＬスキームでＣｒｏｍｅ３４を直接起動させることができなかったためである。本発明者は、カスタムＵＲＬスキームでＣｈｒｏｍｅ起動アプリを実行し、Ｃｒｏｍｅ３４を起動させることでこの問題を解決した。
【００５５】
ＶＣ顧客画面提供部９６は、顧客端末識別部９０により識別された顧客端末の種類に応じて、第１ＶＣ顧客画面または第２ＶＣ顧客画面のウェブページを顧客端末１６へ提供する。例えば、要求電文の指定ＵＲＬが第１ＶＣを示し、顧客端末１６がＰＣ１８の場合、ＰＣ用の第１ＶＣ顧客画面を提供する。また、要求電文の指定ＵＲＬが第１ＶＣを示し、顧客端末１６がモバイル端末（すなわちｉＯＳ端末２０またはＡｎｄｒｏｉｄ端末２２）の場合、モバイル端末用の第１ＶＣ顧客画面を提供する。
【００５６】
また、要求電文の指定ＵＲＬが第２ＶＣを示し、顧客端末１６がＰＣ１８の場合、ＰＣ用の第２ＶＣ顧客画面を提供する。また、要求電文の指定ＵＲＬが第２ＶＣを示し、顧客端末１６がＡｎｄｒｏｉｄ端末２２の場合、Ａｎｄｒｏｉｄ端末用の第２ＶＣ顧客画面を提供する。
【００５７】
なお、ｉＯＳ端末２０では、カメラやマイクロフォンに対するウェブブラウザからの直接アクセスが禁止され、ウェブブラウザが直接カメラやマイクから映像データや音声データを取得することはできない。そこで、ｉＯＳ端末２０では、ＷｅｂＲＴＣによるビデオチャットの全機能（すなわちカメラやマイクへのアクセス）を利用する場合に、ビデオチャットを実行するためのネイティブアプリを導入することとする。そのため、要求電文の指定ＵＲＬが第２ＶＣを示し、顧客端末１６がｉＯＳ端末２０の場合、ＶＣ顧客画面提供部９６は、第２ＶＣ顧客画面をｉＯＳ端末２０へ提供することを抑制する。
【００５８】
ＶＣ社員画面提供部９８は、顧客端末識別部９０により識別された顧客端末の種類に応じて、第１ＶＣ顧客画面または第２ＶＣ顧客画面のウェブページを顧客端末１６へ提供する。例えば、要求電文の指定ＵＲＬが第１ＶＣを示す場合、第１ＶＣ社員画面のウェブページを提供する。また、要求電文の指定ＵＲＬが第２ＶＣを示す場合、第２ＶＣ社員画面のウェブページを提供する。
【００５９】
ＶＣ制御情報中継部１００は、ビデオチャットを実行するために必要な制御情報をオペレータ端末１４との間で送受し、また、顧客端末１６との間で送受する。制御情報は、例えば、ネットワーク上のアドレス（ＩＰアドレス等）やウェブブラウザの情報を含む。またＶＣ制御情報中継部１００は、オペレータ端末１４と顧客端末１６間でプレゼンテーション情報を中継する。プレゼンテーション情報は、ビデオチャット画面の表示態様（外観、見せ方）を示す情報を含む。
【００６０】
ＶＣ映像中継部１０２は、オペレータ端末１４から送信されたオペレータ側映像データを顧客端末１６へ転送する。また、顧客端末１６から送信された顧客側映像データをオペレータ端末１４へ転送する。ＶＣ音声中継部１０４は、オペレータ端末１４から送信されたオペレータ側音声データを顧客端末１６へ転送する。また、顧客端末１６から送信された顧客側音声データをオペレータ端末１４へ転送する。
【００６１】
なお図４に示す各ブロックの機能は、図３に示した複数のソフトウェアのいずれかもしくは連携により実現されてもよい。例えば、図４の要求受付部８８、顧客端末識別部９０、待受画面提供部９２、入室通知部９４、ＶＣ顧客画面提供部９６、ＶＣ社員画面提供部９８、ＶＣ制御情報中継部１００の機能は、図３のａｐａｃｈｅ６２、ビデオチャットサーバ機能７４の連携により実現されてもよい。また、図４のＶＣ映像中継部１０２、ＶＣ音声中継部１０４の機能は、第１ＶＣでは、図３のストリーミングエンジン６８、ｆｆｍｐｅｇ７０、モバイルストリームサービス７８の連携により実現され、第２ＶＣでは、図３のＴＵＲＮサーバ６６により実現されてもよい。
【００６２】
以上の構成によるビデオチャットシステム１０の動作を説明する。ここでは、顧客端末識別部９０により識別される、顧客端末１６の種類と、提供するビデオチャットの種類に分けて説明する。以下の図５〜９では、制御情報およびプレゼンテーション情報の流れを実線で示し、映像データ、もしくは、映像データおよび音声データの流れを破線で示している。
【００６３】
図５は、顧客端末１６がＰＣ１８で、第１ＶＣ提供時の動作を模式的に示す。顧客端末１６から第１ＶＣの提供が要求されると、ビデオチャットサーバ１２は、ＰＣ用の第１ＶＣ顧客画面のウェブコンテンツを顧客端末１６へ提供する。またビデオチャットサーバ１２は、第１ＶＣ社員画面であるビデオチャットコンテンツ３８の通常ＵＲＬを設定したＶＣ画面リンクを含むＶＣ要求受付通知をオペレータ端末１４の待受画面３６に表示させる。オペレータがＶＣ画面リンクをクリックすると、第１ＶＣ社員画面であるビデオチャットコンテンツ３８がＩＥ３２上で表示される。
【００６４】
図５の破線で示すように、オペレータ端末１４のカメラで撮像された映像データは、ビデオチャットサーバ１２のストリーミングエンジン６８を介して、ＦＬＡＳＨ形式で顧客端末１６へ伝送され、顧客端末１６の第１ＶＣ顧客画面で表示される。なお、顧客端末１６のカメラで撮像された映像データをオペレータ端末１４へ送る場合は、破線の矢印の向きが逆になる。また、図５の実線で示すように、制御情報およびプレゼンテーション情報は、ウェブソケット・ＦＬＡＳＨソケットを介してビデオチャットサーバ１２と送受信される。
【００６５】
図６は、顧客端末１６がｉＯＳ端末２０またはＡｎｄｒｏｉｄ端末２２で、第１ＶＣ提供時の動作を模式的に示す。顧客端末１６から第１ＶＣの提供が要求されると、ビデオチャットサーバ１２は、モバイル端末用の第１ＶＣ顧客画面のウェブコンテンツを顧客端末１６へ提供する。また図５と同様の動作で、第１ＶＣ社員画面であるビデオチャットコンテンツ３８がオペレータ端末１４のＩＥ３２上で表示される。
【００６６】
図６で示すように、オペレータ端末１４のカメラで撮像された映像データは、ビデオチャットサーバ１２のストリーミングエンジン６８、ｆｆｍｐｅｇ７０、モバイルストリームサービス７８を介して顧客端末１６へ伝送される。その中で映像データは、ＦＬＡＳＨ形式からｍｐｅｇ形式へ変換され、顧客端末１６の第１ＶＣ顧客画面で表示される。
【００６７】
図７は、顧客端末がＰＣ１８で、第２ＶＣ提供時の動作を模式的に示す。顧客端末１６から第２ＶＣの提供が要求されると、ビデオチャットサーバ１２は、ＰＣ用の第２ＶＣ顧客画面のウェブコンテンツを顧客端末１６へ提供する。またビデオチャットサーバ１２は、第２ＶＣ社員画面であるビデオチャットコンテンツ４８の特殊ＵＲＬを設定したＶＣ画面リンクを含むＶＣ要求受付通知をオペレータ端末１４の待受画面３６に表示させる。オペレータがＶＣ画面リンクをクリックすると、特殊ＵＲＬに予め対応付けられたＣｈｒｏｍｅ起動アプリ５８がカスタムＵＲＬスキームによって実行され、第２ＶＣ社員画面のＵＲＬを引数としてＣｒｏｍｅ３４が起動される。そして、第２ＶＣ社員画面のビデオチャットコンテンツ４８がＣｒｏｍｅ３４上に表示される。
【００６８】
制御情報・プレゼンテーション情報の流れは第１ＶＣの場合と同じである。映像データおよび音声データについては、１）オペレータ端末１４が、ＷｅｂＲＴＣライブラリ５６を使用（例えばＡＰＩをコール）してローカルの映像・音声データを取得し、ビデオチャットサーバ１２へ送信する。２）ビデオチャットサーバ１２のＴＵＲＮサーバ６６が映像・音声データを中継する。３）顧客端末１６が、ＷｅｂＲＴＣライブラリ５６を使用してリモートの映像・音声データを取得し、第２ＶＣ顧客画面（リモート映像表示領域）に表示させ、またスピーカから出力させる、という流れになる。顧客端末１６からオペレータ端末１４へ顧客側の映像・音声データを送信する場合は逆の流れになる。
【００６９】
図８は、顧客端末がＡｎｄｒｏｉｄ端末２２で、第２ＶＣ提供時の動作を模式的に示す。顧客端末１６から第２ＶＣの提供が要求されると、ビデオチャットサーバ１２は、Ａｎｄｒｏｉｄ端末２２用の第２ＶＣ顧客画面のウェブコンテンツを顧客端末１６へ提供する。また図７と同様に、オペレータ端末１４のカスタムＵＲＬスキームによってＩＥ３２からＣｒｏｍｅ３４を起動させ、第２ＶＣ社員画面のビデオチャットコンテンツ４８をＣｒｏｍｅ３４上に表示させる。
【００７０】
制御情報・プレゼンテーション情報、および、映像・音声データは図７と同様に伝送される。図８の顧客端末１６のウェブブラウザは、ＦＬＡＳＨソケットを含まないが、これはウェブソケットに対応しているからである。顧客端末１６がＰＣ１８の場合でも、そのウェブブラウザがウェブソケットに対応していれば、ＦＬＡＳＨソケットは不要である。ビデオチャットサーバ１２は、顧客端末１６のウェブブラウザが、ウェブソケット通信に対応するか否かをユーザエージェント情報（例えばブラウザの種類やバージョン）に基づき判定してもよい。そして、ウェブソケット通信に対応する場合と未対応の場合とで異なるビデオチャット画面のコンテンツを顧客端末１６へ提供してもよい。
【００７１】
図９は、顧客端末がｉＯＳ端末２０で、第２ＶＣ提供時の動作を模式的に示す。顧客端末１６から第２ＶＣの提供が要求されると、図７・図８と同様に、オペレータ端末１４のカスタムＵＲＬスキームによってＩＥ３２からＣｒｏｍｅ３４を起動させ、第２ＶＣ社員画面のビデオチャットコンテンツ４８をＣｒｏｍｅ３４上に表示させる。
【００７２】
既述したように、ｉＯＳ端末２０では、ネイティブアプリにてビデオチャットの処理（映像・音声の取得、送受信、画面表示等）を実行する。したがって、ビデオチャットサーバ１２は、第２ＶＣ顧客画面を顧客端末１６へ提供することを抑制する。その一方、映像・音声データは図７、図８と同様に、ビデオチャットサーバ１２のＴＵＲＮサーバ６６を介して伝送される。
【００７３】
以上、本発明を実施の形態をもとに説明した。これらの実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せによりいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００７４】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。例えば、請求項に記載の社員側提供部は、実施の形態に記載のＶＣ社員画面提供部９８、入室通知部９４、待受画面提供部９２が連携することにより実現されてもよい。
【符号の説明】
【００７５】
１０  ビデオチャットシステム、  １２  ビデオチャットサーバ、  １４  オペレータ端末、  １６  顧客端末、  ２４  バックオフィスシステム、  ８８  要求受付部、  ９０  顧客端末識別部、  ９６  ＶＣ顧客画面提供部、  ９８  ＶＣ社員画面提供部。
【図１】
0006436762.tif 000002
【図２】
0006436762.tif 000003
【図３】
0006436762.tif 000004
【図４】
0006436762.tif 000005
【図５】
0006436762.tif 000006
【図６】
0006436762.tif 000007
【図７】
0006436762.tif 000008
【図８】
0006436762.tif 000009
【図９】
0006436762.tif 000010