特開2024-54895情報処理装置、情報処理システム、制御プログラムおよび制御方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024054895
(43)【公開日】2024-04-18
(54)【発明の名称】情報処理装置、情報処理システム、制御プログラムおよび制御方法
(51)【国際特許分類】
G06T 13/40 20110101AFI20240411BHJP
G06T 19/00 20110101ALI20240411BHJP
G06F 3/0481 20220101ALI20240411BHJP
【ＦＩ】
G06T13/40
G06T19/00 A
G06F3/0481
【審査請求】未請求
【請求項の数】10
【出願形態】ＯＬ
(21)【出願番号】P 2022161329
(22)【出願日】2022-10-06
(71)【出願人】
【識別番号】521413866
【氏名又は名称】ＡＶＩＴＡ株式会社
(74)【代理人】
【識別番号】100090181
【弁理士】
【氏名又は名称】山田 義人
(74)【代理人】
【識別番号】100168217
【弁理士】
【氏名又は名称】大村 和史
(72)【発明者】
【氏名】三上 崇志
(72)【発明者】
【氏名】石黒 浩
(72)【発明者】
【氏名】西口 昇吾
(72)【発明者】
【氏名】小栗 賢章
【テーマコード（参考）】
5B050
5E555
【Ｆターム（参考）】
5B050BA09
5B050BA12
5B050CA07
5B050DA04
5B050EA05
5B050EA07
5B050EA12
5B050EA13
5B050EA27
5B050FA05
5B050FA10
5E555AA04
5E555AA11
5E555AA27
5E555AA46
5E555AA61
5E555AA64
5E555BA02
5E555BA03
5E555BA05
5E555BA76
5E555BB02
5E555BB03
5E555BB05
5E555BC04
5E555BD07
5E555BE10
5E555CA24
5E555CA42
5E555CA47
5E555CB02
5E555CB64
5E555CB66
5E555CB67
5E555DA01
5E555DA21
5E555DB32
5E555DC85
5E555EA05
5E555EA07
5E555EA11
5E555EA19
5E555EA22
5E555EA23
5E555FA00
(57)【要約】 （修正有）
【課題】手動モードから自動モードに円滑に切り替えることができる情報処理装置、情報処理システム、制御プログラム及び制御方法を提供する。
【解決手段】利用者側端末が、ネットワークを介して、操作者側端末およびサーバに通信可能に接続される情報処理システムにおいて、操作者側端末（１６）は、利用者と対話する操作者によって使用され、手動モードでは、カメラ（６８）で撮影された撮影画像に基づいて操作者に対応するアバターの画像を生成し、アバターの画像を利用者側端末に表示する。操作者側端末は、撮影画像に基づいて、操作者の所定のジェスチャを検出すると、手動モードから自動モードに切り替えて、アバターの画像を自動で生成する。
【選択図】図３
【解決手段】利用者側端末が、ネットワークを介して、操作者側端末およびサーバに通信可能に接続される情報処理システムにおいて、操作者側端末（１６）は、利用者と対話する操作者によって使用され、手動モードでは、カメラ（６８）で撮影された撮影画像に基づいて操作者に対応するアバターの画像を生成し、アバターの画像を利用者側端末に表示する。操作者側端末は、撮影画像に基づいて、操作者の所定のジェスチャを検出すると、手動モードから自動モードに切り替えて、アバターの画像を自動で生成する。
【選択図】図３
【特許請求の範囲】
【請求項1】
利用者に応対する操作者が使用する情報処理装置であって、
前記操作者を撮影するカメラ、
手動モードにおいて、前記カメラの撮影画像に基づいて前記操作者の動きを反映した当該操作者のアバターの画像を生成するアバター画像生成手段、
前記アバター画像生成手段によって生成された前記アバターの画像を、前記利用者が使用する利用者側端末に送信する送信手段、および
前記撮影画像に基づいて前記操作者の所定の第１ジェスチャを検出した場合に、前記アバター画像生成手段に前記アバターの画像を自動で生成させる自動モードに切り替えるモード切替手段を備える、情報処理装置。
前記操作者を撮影するカメラ、
手動モードにおいて、前記カメラの撮影画像に基づいて前記操作者の動きを反映した当該操作者のアバターの画像を生成するアバター画像生成手段、
前記アバター画像生成手段によって生成された前記アバターの画像を、前記利用者が使用する利用者側端末に送信する送信手段、および
前記撮影画像に基づいて前記操作者の所定の第１ジェスチャを検出した場合に、前記アバター画像生成手段に前記アバターの画像を自動で生成させる自動モードに切り替えるモード切替手段を備える、情報処理装置。
【請求項2】
前記モード切替手段は、前記自動モードにおいて、前記撮影画像に基づいて前記操作者の所定の第２ジェスチャを検出した場合に、前記アバター画像生成手段で前記撮影画像に基づいて前記操作者の動きを反映した前記アバターの画像を生成する前記手動モードに切り替える、請求項１記載の情報処理装置。
【請求項3】
前記撮影画像に基づいて現実空間のワールド座標系における前記操作者の姿勢の複数の第１特徴点を検出する第１検出手段、
前記撮影画像に基づいて第１のローカル座標系における前記操作者の左手および右手の各々の複数の第２特徴点を検出する第２検出手段、
前記撮影画像に基づいて第２のローカル座標系における少なくとも前記操作者の左目または右目の虹彩の複数の第３特徴点および当該虹彩の横幅を検出する第３検出手段、
前記第２検出手段によって検出された複数の第２特徴点に基づいて、前記撮影画像における前記操作者の左手および右手の各々の手のひらの長さである第１長さを算出する第１算出手段、
前記第３検出手段によって検出された前記操作者の左目または右目の虹彩の横幅に対する前記第１算出手段によって算出された前記操作者の左手および右手の各々の手のひらの第１長さの比率である第１比率と、人間の虹彩の標準の横幅である標準幅に対する人間の手のひらの標準の長さである標準長さの比率である第２比率とに基づいて、前記操作者の左目または右目の位置に対する前記操作者の左手および右手の各々の奥行き方向の位置を算出する第２算出手段、
前記第１検出手段によって検出された複数の第１特徴点と、前記第２算出手段によって算出された前記操作者の左手および右手の奥行き方向の位置とに基づいて、前記アバターを配置する仮想空間のワールド座標系における前記アバターの左手および右手の各々の３次元位置を算出する第３算出手段、
前記第２検出手段によって検出された複数の第２特徴点に基づいて、前記仮想空間のワールド座標系における前記アバターの左手および右手の各々の回転を算出する第４算出手段、および
少なくとも前記第３算出手段によって算出された前記アバターの左手および右手の各々の３次元位置と、前記第４算出手段によって算出された前記アバターの左手および右手の各々の回転に基づいて、前記アバターの左腕および右腕の各々の関節角度を算出する第５算出手段をさらに備え、
前記手動モードにおいて、前記アバター画像生成手段は、少なくとも前記第５算出手段によって算出された前記アバターの左腕および右腕の各々の関節角度を用いて前記アバターの画像を生成する、請求項２記載の情報処理装置。
前記撮影画像に基づいて第１のローカル座標系における前記操作者の左手および右手の各々の複数の第２特徴点を検出する第２検出手段、
前記撮影画像に基づいて第２のローカル座標系における少なくとも前記操作者の左目または右目の虹彩の複数の第３特徴点および当該虹彩の横幅を検出する第３検出手段、
前記第２検出手段によって検出された複数の第２特徴点に基づいて、前記撮影画像における前記操作者の左手および右手の各々の手のひらの長さである第１長さを算出する第１算出手段、
前記第３検出手段によって検出された前記操作者の左目または右目の虹彩の横幅に対する前記第１算出手段によって算出された前記操作者の左手および右手の各々の手のひらの第１長さの比率である第１比率と、人間の虹彩の標準の横幅である標準幅に対する人間の手のひらの標準の長さである標準長さの比率である第２比率とに基づいて、前記操作者の左目または右目の位置に対する前記操作者の左手および右手の各々の奥行き方向の位置を算出する第２算出手段、
前記第１検出手段によって検出された複数の第１特徴点と、前記第２算出手段によって算出された前記操作者の左手および右手の奥行き方向の位置とに基づいて、前記アバターを配置する仮想空間のワールド座標系における前記アバターの左手および右手の各々の３次元位置を算出する第３算出手段、
前記第２検出手段によって検出された複数の第２特徴点に基づいて、前記仮想空間のワールド座標系における前記アバターの左手および右手の各々の回転を算出する第４算出手段、および
少なくとも前記第３算出手段によって算出された前記アバターの左手および右手の各々の３次元位置と、前記第４算出手段によって算出された前記アバターの左手および右手の各々の回転に基づいて、前記アバターの左腕および右腕の各々の関節角度を算出する第５算出手段をさらに備え、
前記手動モードにおいて、前記アバター画像生成手段は、少なくとも前記第５算出手段によって算出された前記アバターの左腕および右腕の各々の関節角度を用いて前記アバターの画像を生成する、請求項２記載の情報処理装置。
【請求項4】
前記手動モードにおいて、前記第２検出手段によって検出された前記操作者の左手および右手の各々の前記複数の第２特徴点に基づいて前記所定の第１ジェスチャが有るかどうかを判断する第１判断手段をさらに備える、請求項３記載の情報処理装置。
【請求項5】
前記自動モードにおいて、前記第２検出手段によって検出された前記操作者の左手および右手の各々の前記複数の第２特徴点に基づいて前記所定の第２ジェスチャが有るかどうかを判断する第２判断手段をさらに備える、請求項３または４記載の情報処理装置。
【請求項6】
前記第３検出手段は、前記操作者の顔の複数の第４特徴点をさらに検出し、
前記手動モードにおいて、前記アバター画像生成手段は、前記複数の第４特徴点に基づいて決定される表情の前記アバターの画像を生成する、請求項３記載の情報処理装置。
前記手動モードにおいて、前記アバター画像生成手段は、前記複数の第４特徴点に基づいて決定される表情の前記アバターの画像を生成する、請求項３記載の情報処理装置。
【請求項7】
操作者に応対される利用者が使用する情報処理装置であって、
前記操作者を撮影した撮影画像を取得する取得手段、
手動モードにおいて、前記取得手段によって取得された撮影画像に基づいて前記操作者の動きを反映した当該操作者のアバターの画像を生成するアバター画像生成手段、
前記アバター画像生成手段によって生成された前記アバターの画像を、前記利用者が使用する利用者側端末に送信する送信手段、および
前記撮影画像に基づいて前記操作者の所定のジェスチャを検出した場合に、前記アバター画像生成手段に前記アバターの画像を自動で生成させる自動モードに切り替えるモード切替手段を備える、情報処理装置。
前記操作者を撮影した撮影画像を取得する取得手段、
手動モードにおいて、前記取得手段によって取得された撮影画像に基づいて前記操作者の動きを反映した当該操作者のアバターの画像を生成するアバター画像生成手段、
前記アバター画像生成手段によって生成された前記アバターの画像を、前記利用者が使用する利用者側端末に送信する送信手段、および
前記撮影画像に基づいて前記操作者の所定のジェスチャを検出した場合に、前記アバター画像生成手段に前記アバターの画像を自動で生成させる自動モードに切り替えるモード切替手段を備える、情報処理装置。
【請求項8】
情報処理システムであって、
利用者に応対する操作者が使用する情報処理装置は、
前記操作者を撮影するカメラ、
手動モードにおいて、前記カメラの撮影画像に基づいて前記操作者の動きを反映した当該操作者のアバターの画像を生成するアバター画像生成手段、
前記アバター画像生成手段によって生成された前記アバターの画像を、前記利用者が使用する利用者側端末に送信する送信手段、および
前記撮影画像に基づいて前記操作者の所定のジェスチャを検出した場合に、前記アバター画像生成手段に前記アバターの画像を自動で生成させる自動モードに切り替えるモード切替手段を備え、
前記利用者側端末は、
前記送信手段によって送信された前記アバターの画像を受信する受信手段、および
前記受信手段によって受信された前記アバターの画像を表示する表示手段を備える、情報処理システム。
利用者に応対する操作者が使用する情報処理装置は、
前記操作者を撮影するカメラ、
手動モードにおいて、前記カメラの撮影画像に基づいて前記操作者の動きを反映した当該操作者のアバターの画像を生成するアバター画像生成手段、
前記アバター画像生成手段によって生成された前記アバターの画像を、前記利用者が使用する利用者側端末に送信する送信手段、および
前記撮影画像に基づいて前記操作者の所定のジェスチャを検出した場合に、前記アバター画像生成手段に前記アバターの画像を自動で生成させる自動モードに切り替えるモード切替手段を備え、
前記利用者側端末は、
前記送信手段によって送信された前記アバターの画像を受信する受信手段、および
前記受信手段によって受信された前記アバターの画像を表示する表示手段を備える、情報処理システム。
【請求項9】
利用者に応対する操作者が使用し、前記操作者を撮影するカメラを備える情報処理装置で実行される制御プログラムであって、
前記情報処理装置のプロセッサに、
手動モードにおいて、前記カメラの撮影画像に基づいて前記操作者の動きを反映した当該操作者のアバターの画像を生成するアバター画像生成ステップ、
前記アバター画像生成ステップにおいて生成した前記アバターの画像を、前記利用者が使用する利用者側端末に送信する送信ステップ、および
前記撮影画像に基づいて前記操作者の所定のジェスチャを検出した場合に、前記アバター画像生成ステップに前記アバターの画像を自動で生成させる自動モードに切り替えるモード切替ステップを実行させる、制御プログラム。
前記情報処理装置のプロセッサに、
手動モードにおいて、前記カメラの撮影画像に基づいて前記操作者の動きを反映した当該操作者のアバターの画像を生成するアバター画像生成ステップ、
前記アバター画像生成ステップにおいて生成した前記アバターの画像を、前記利用者が使用する利用者側端末に送信する送信ステップ、および
前記撮影画像に基づいて前記操作者の所定のジェスチャを検出した場合に、前記アバター画像生成ステップに前記アバターの画像を自動で生成させる自動モードに切り替えるモード切替ステップを実行させる、制御プログラム。
【請求項10】
利用者に応対する操作者が使用し、前記操作者を撮影するカメラを備える情報処理装置の制御方法であって、
（ａ）手動モードにおいて、前記カメラの撮影画像に基づいて前記操作者の動きを反映した当該操作者のアバターの画像を生成するステップ、
（ｂ）前記ステップ（ａ）において生成した前記アバターの画像を、前記利用者が使用する利用者側端末に送信するステップ、および
（ｃ）前記撮影画像に基づいて前記操作者の所定のジェスチャを検出した場合に、前記ステップ（ａ）に前記アバターの画像を自動で生成させる自動モードに切り替えるステップを含む、制御方法。
（ａ）手動モードにおいて、前記カメラの撮影画像に基づいて前記操作者の動きを反映した当該操作者のアバターの画像を生成するステップ、
（ｂ）前記ステップ（ａ）において生成した前記アバターの画像を、前記利用者が使用する利用者側端末に送信するステップ、および
（ｃ）前記撮影画像に基づいて前記操作者の所定のジェスチャを検出した場合に、前記ステップ（ａ）に前記アバターの画像を自動で生成させる自動モードに切り替えるステップを含む、制御方法。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、情報処理装置、情報処理システム、制御プログラムおよび制御方法に関し、特にたとえば、操作者の動作に従ってまたは自動でアバターを動作させる、情報処理装置、情報処理システム、制御プログラムおよび制御方法に関する。
【背景技術】
【0002】
この種の従来の情報処理装置の一例が特許文献１に開示されている。特許文献１に開示されるコミュニケーションシステムでは、ユーザが応対端末の前で立ち止まると、チャットボットモードで応対処理が行われる。チャットボットモードが設定された状態では、ユーザの問い合わせ内容に応対する応対パターンが機械学習やルールベースを用いた抽出／分類パターン記憶部から選択される。応対パターンには、応答音声データと共に、アバターの表情（瞬きを含む）および仕草（手や腕の動き、顔の向きを含む）を制御するための座標データが含まれている。この応対パターンに応じて変化するアバターの画像が生成され、応対パターンに含まれる応答音声データに同期して、応答音声が発生される期間にアバターの口唇部を動かすリップシンク処理が行われる。
【0003】
チャットボットモードによる応対では解決されない問い合わせを行う場合、ユーザはオペレータを呼び出す。これに応じて、応対端末の応対モードがチャットボットモードからテレイグジステンスモードに切り替えられ、オペレータ端末に接続要求を送信する。テレイグジスタンスモードが設定された状態で、オペレータ端末は、オペレータの表情およびジェスチャを座標データに変換し、応答音声データと共に応対端末へ送信する。応対端末は、オペレータ端末から送られた座標データに基づいてアバターを生成することで、オペレータの表情およびジェスチャがアバターの表情および仕草に反映されたキャラクタ応対情報を生成し、ユーザに向けて表示する。この場合、オペレータの応答音声データに同期して、応答音声が発生される期間にアバターの口唇部を動かすリップシンク処理が行われる。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開２０２１－５６９４０号
【発明の概要】
【発明が解決しようとする課題】
【0005】
上記の特許文献１のコミュニケーションシステムでは、チャットボットモードからテレイグジステンスモードに切り替えられるが、テレイグジステンスモードからチャットボットモードに切り替えられることは想定されていない。オペレータは応対中に一時的に他の作業を行いたい場合もあり、改善の余地がある。また、オペレータはユーザに応対しているため、テレイグジステンスモードからチャットボットモードに切り替える場合に、キーボード入力、ボタン操作または音声入力を行うのは、困難な状況であり、また、ユーザに違和感または不快感を与える可能性がある。
【0006】
それゆえに、この発明の主たる目的は、新規な、情報処理装置、情報処理システム、制御プログラムおよび制御方法を提供することである。
【0007】
また、この発明の他の目的は、操作者の動きを反映した手動モードからアバターを自動で動作させる自動モードに円滑に切り替えることができる、情報処理装置、情報処理システム、制御プログラムおよび制御方法を提供することである。
【課題を解決するための手段】
【0008】
第１の発明は、利用者に応対する操作者が使用する情報処理装置であって、操作者を撮影するカメラ、手動モードにおいて、カメラの撮影画像に基づいて操作者の動きを反映した当該操作者のアバターの画像を生成するアバター画像生成手段、アバター画像生成手段によって生成されたアバターの画像を、利用者が使用する利用者側端末に送信する送信手段、および撮影画像に基づいて操作者の所定の第１ジェスチャを検出した場合に、アバター画像生成手段にアバターの画像を自動で生成させる自動モードに切り替えるモード切替手段を備える、情報処理装置である。
【0009】
第２の発明は、第１の発明に従属し、モード切替手段は、自動モードにおいて、撮影画像に基づいて操作者の所定の第２ジェスチャを検出した場合に、アバター画像生成手段で撮影画像に基づいて操作者の動きを反映したアバターの画像を生成する手動モードに切り替える。
【0010】
第３の発明は、第２の発明に従属し、撮影画像に基づいて現実空間のワールド座標系における操作者の姿勢の複数の第１特徴点を検出する第１検出手段、撮影画像に基づいて第１のローカル座標系における操作者の左手および右手の各々の複数の第２特徴点を検出する第２検出手段、撮影画像に基づいて第２のローカル座標系における少なくとも操作者の左目または右目の虹彩の複数の第３特徴点および当該虹彩の横幅を検出する第３検出手段、第２検出手段によって検出された複数の第２特徴点に基づいて、撮影画像における操作者の左手および右手の各々の手のひらの長さである第１長さを算出する第１算出手段、第３検出手段によって検出された操作者の左目または右目の虹彩の横幅に対する第１算出手段によって算出された操作者の左手および右手の各々の手のひらの第１長さの比率である第１比率と、人間の虹彩の標準の横幅である標準幅に対する人間の手のひらの標準の長さである標準長さの比率である第２比率とに基づいて、操作者の左目または右目の位置に対する操作者の左手および右手の各々の奥行き方向の位置を算出する第２算出手段、第１検出手段によって検出された複数の第１特徴点と、第２算出手段によって算出された操作者の左手および右手の奥行き方向の位置とに基づいて、アバターを配置する仮想空間のワールド座標系におけるアバターの左手および右手の各々の３次元位置を算出する第３算出手段、第２検出手段によって検出された複数の第２特徴点に基づいて、仮想空間のワールド座標系におけるアバターの左手および右手の各々の回転を算出する第４算出手段、および少なくとも第３算出手段によって算出されたアバターの左手および右手の各々の３次元位置と、第４算出手段によって算出されたアバターの左手および右手の各々の回転に基づいて、アバターの左腕および右腕の各々の関節角度を算出する第５算出手段をさらに備え、手動モードにおいて、アバター画像生成手段は、少なくとも第５算出手段によって算出されたアバターの左腕および右腕の各々の関節角度を用いてアバターの画像を生成する、請求項２記載の情報処理装置である。
【0011】
第４の発明は、第３の発明に従属し、手動モードにおいて、第２検出手段によって検出された操作者の左手および右手の各々の複数の第２特徴点に基づいて所定の第１ジェスチャが有るかどうかを判断する第１判断手段をさらに備える。
【0012】
第５の発明は、第３または第４の発明に従属し、自動モードにおいて、第２検出手段によって検出された操作者の左手および右手の各々の複数の第２特徴点に基づいて所定の第２ジェスチャが有るかどうかを判断する第２判断手段をさらに備える。
【0013】
第６の発明は、第３の発明に従属し、第３検出手段は、操作者の顔の複数の第４特徴点をさらに検出し、手動モードにおいて、アバター画像生成手段は、複数の第４特徴点に基づいて決定される表情のアバターの画像を生成する。
【0014】
第７の発明は、操作者に応対される利用者が使用する情報処理装置であって、操作者を撮影した撮影画像を取得する取得手段、手動モードにおいて、取得手段によって取得された撮影画像に基づいて操作者の動きを反映した当該操作者のアバターの画像を生成するアバター画像生成手段、アバター画像生成手段によって生成されたアバターの画像を、利用者が使用する利用者側端末に送信する送信手段、および撮影画像に基づいて操作者の所定のジェスチャを検出した場合に、アバター画像生成手段にアバターの画像を自動で生成させる自動モードに切り替えるモード切替手段を備える、情報処理装置である。
【0015】
第８の発明は、情報処理システムであって、利用者に応対する操作者が使用する情報処理装置は、操作者を撮影するカメラ、手動モードにおいて、カメラの撮影画像に基づいて操作者の動きを反映した当該操作者のアバターの画像を生成するアバター画像生成手段、アバター画像生成手段によって生成されたアバターの画像を、利用者が使用する利用者側端末に送信する送信手段、および撮影画像に基づいて操作者の所定のジェスチャを検出した場合に、アバター画像生成手段にアバターの画像を自動で生成させる自動モードに切り替えるモード切替手段を備え、利用者側端末は、送信手段によって送信されたアバターの画像を受信する受信手段、および受信手段によって受信されたアバターの画像を表示する表示手段を備える、情報処理システムである。
【0016】
第９の発明は、利用者に応対する操作者が使用し、操作者を撮影するカメラを備える情報処理装置で実行される制御プログラムであって、情報処理装置のプロセッサに、手動モードにおいて、カメラの撮影画像に基づいて操作者の動きを反映した当該操作者のアバターの画像を生成するアバター画像生成ステップ、アバター画像生成ステップにおいて生成したアバターの画像を、利用者が使用する利用者側端末に送信する送信ステップ、および撮影画像に基づいて操作者の所定のジェスチャを検出した場合に、アバター画像生成ステップにアバターの画像を自動で生成させる自動モードに切り替えるモード切替ステップを実行させる、制御プログラムである。
【0017】
第１０の発明は、利用者に応対する操作者が使用し、操作者を撮影するカメラを備える情報処理装置の制御方法であって、（ａ）手動モードにおいて、カメラの撮影画像に基づいて操作者の動きを反映した当該操作者のアバターの画像を生成するステップ、（ｂ）ステップ（ａ）において生成したアバターの画像を、利用者が使用する利用者側端末に送信するステップ、および（ｃ）撮影画像に基づいて操作者の所定のジェスチャを検出した場合に、ステップ（ａ）にアバターの画像を自動で生成させる自動モードに切り替えるステップを含む、制御方法である。
【発明の効果】
【0018】
この発明によれば、操作者の動きを反映した手動モードからアバターを自動で動作させる自動モードに円滑に切り替えることができる。
【0019】
この発明の上述の目的、その他の目的，特徴および利点は、図面を参照して行う以下の実施例の詳細な説明から一層明らかとなろう。
【図面の簡単な説明】
【0020】
【発明を実施するための形態】
【0021】
図１を参照して、この実施例の情報処理システム１０は利用者側端末１２を含み、利用者側端末１２は、ネットワーク１４を介して、操作者側端末１６およびサーバ１８に通信可能に接続される。
【0022】
一例として、利用者側端末１２は、サーバ１８によって提供される所定のサービスを利用する利用者によって使用され、操作者側端末１６は、利用者に応対する操作者によって使用される。
【0023】
利用者側端末１２は、情報処理装置であり、一例として、スマートフォンであり、ブラウザ機能を備えている。ただし、利用者側端末１２としては、タブレットＰＣ、ノート型ＰＣまたはデスクトップ型ＰＣなどの汎用の端末を用いることもできる。
【0024】
ネットワーク１４は、インターネットを含むＩＰ網（または、ＩＰネットワーク）と、このＩＰ網にアクセスするためのアクセス網（または、アクセスネットワーク）とから構成される。アクセス網としては、公衆電話網、携帯電話網、有線ＬＡＮ、無線ＬＡＮ、ＣＡＴＶ（Cable Television）等を用いることができる。
【0025】
操作者側端末１６は、利用者側端末１２とは異なる他の情報処理装置であり、一例として、ノート型ＰＣまたはデスクトップ型ＰＣであるが、スマートフォンまたはタブレットＰＣなどの汎用の端末を用いることもできる。
【0026】
サーバ１８は、利用者側端末１２および操作者側端末１６とは異なるその他の情報処理装置であり、汎用のサーバを用いることができる。したがって、サーバ１８は、ＣＰＵおよび記憶部（ＨＤＤ、ＲＯＭおよびＲＡＭを含む）を備えるとともに、通信インタフェースおよび入出力インタフェースなどのコンポーネントを備える。この実施例では、サーバ１８は、所定のサービスを提供するサイトを運営したり、利用者側端末１２と操作者側端末１６をマッチングしたりするために設けられる。
【0027】
図２は図１に示した利用者側端末１２の電気的な構成を示すブロック図である。図２に示すように、利用者側端末１２はＣＰＵ２０を含み、ＣＰＵ２０は、内部バスを介して、ＲＡＭ２２、通信インタフェース（以下、「通信Ｉ／Ｆ」という）２４および入出力インタフェース（以下、「入出力Ｉ／Ｆ」という）２６に接続される。
【0028】
ＣＰＵ２０は、利用者側端末１２の全体的な制御を司る。ただし、ＣＰＵ２０に代えて、ＣＰＵ機能、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）機能等の複数の機能を含むＳｏＣ（Ｓｙｓｔｅｍ－ｏｎ－ａ－ｃｈｉｐ）を設けてもよい。
【0029】
ＲＡＭ２２は、主記憶装置であり、ＣＰＵ２０のワーク領域またはバッファ領域として使用される。図示は省略するが、利用者側端末１２には、補助記憶装置として、ＨＤＤおよびＲＯＭが設けられる。ただし、ＨＤＤに代えて、または、ＨＤＤに加えて、ＳＳＤ等の不揮発性メモリが使用されてもよい。
【0030】
通信Ｉ／Ｆ２４は、ＣＰＵ２０の制御の下、ネットワーク１４を介して、操作者側端末１６およびサーバ１８などの外部のコンピュータとの間で、制御信号およびデータの送受信を行うために有線インタフェースを有する。ただし、通信Ｉ／Ｆ２４としては、無線ＬＡＮまたはBluetooth（登録商標）等の無線インタフェースを使用することもできる。
【0031】
入出力Ｉ／Ｆ２６には、入力装置２８、表示装置３０、マイク３２およびスピーカ３４が接続されている。入力装置２８は、タッチパネルおよびハードウェアのボタンである。タッチパネルは、汎用のタッチパネルであり、静電容量方式、電磁誘導方式、抵抗膜方式、赤外線方式など、任意の方式のものを用いることができる。後述する操作者側端末１６についても同様である。
【0032】
ただし、利用者側端末１２として、ノート型ＰＣまたはデスクトップ型ＰＣが用いられる場合には、入力装置２８として、キーボードおよびコンピュータマウスが使用される。
【0033】
また、表示装置３０は、ＬＣＤまたは有機ＥＬディスプレイである。上記のタッチパネルは、表示装置３０の表示面上に設けられてもよいし、タッチパネルが表示装置３０と一体的に形成されたタッチディスプレイが設けられてもよい。このことは、後述する操作者側端末１６についても同様である。
【0034】
入出力Ｉ／Ｆ２６は、マイク３２で検出された利用者の音声をデジタルの音声データに変換してＣＰＵ２０に出力するとともに、ＣＰＵ２０によって出力される音声データをアナログの音声信号に変換してスピーカ３４から出力させる。ただし、ＣＰＵ２０から出力される音声データは、操作者側端末１６から受信した音声データである。また、入出力Ｉ／Ｆ２６は、入力装置２８から入力された操作データ（または、操作情報）をＣＰＵ２０に出力すると共に、ＣＰＵ２０の指示に従って生成された画像データを表示装置３０に出力して、画像データに対応する画面または画像を表示装置３０に表示させる。ただし、外部のコンピュータ（たとえば、操作者側端末１６またはサーバ１８）から受信した画像データがＣＰＵ２０によって出力される場合もある。
【0035】
なお、図２に示す利用者側端末１２の電気的な構成は一例であり、限定される必要はない。他の例では、利用者側端末１２はカメラを備えていてもよい。
【0036】
また、利用者側端末１２がスマートフォンである場合には、携帯電話通信網、または、携帯電話網および公衆電話網を介して、通話するための通話回路を備えるが、この実施例では、そのような通話は行わないため、図示は省略してある。このことは、後述する操作者側端末１６がスマートフォンである場合についても同じである。
【0037】
図３は図１に示した操作者側端末１６の電気的な構成を示すブロック図である。図３に示すように、操作者側端末１６はＣＰＵ５０を含み、ＣＰＵ５０は、内部バスを介して、ＲＡＭ５２、通信Ｉ／Ｆ５４および入出力Ｉ／Ｆ５６に接続される。
【0038】
ＣＰＵ５０は、操作者側端末１６の全体的な制御を司る。ただし、ＣＰＵ５０に代えて、ＣＰＵ機能、ＧＰＵ機能等の複数の機能を含むＳｏＣを設けてもよい。
【0039】
ＲＡＭ５２は、主記憶装置であり、ＣＰＵ５０のワーク領域またはバッファ領域として使用される。図示は省略するが、操作者側端末１６には、補助記憶装置として、ＨＤＤおよびＲＯＭが設けられる。ただし、ＨＤＤに代えて、または、ＨＤＤに加えて、ＳＳＤ等の不揮発性メモリが使用されてもよい。
【0040】
通信Ｉ／Ｆ５４は、ＣＰＵ５０の制御の下、ネットワーク１４を介して、利用者側端末１２およびサーバ１８などの外部のコンピュータとの間で、制御信号およびデータの送受信を行うために有線インタフェースを有する。ただし、通信Ｉ／Ｆ５４としては、無線ＬＡＮまたはBluetooth（登録商標）等の無線インタフェースを使用することもできる。
【0041】
入出力Ｉ／Ｆ５６には、入力装置５８および表示装置６０、マイク６２およびスピーカ６４が接続されている。入力装置５８としては、キーボードおよびコンピュータマウスが用いられる。ただし、操作者側端末１６として、スマートフォンまたはタブレットＰＣが用いられる場合には、入力装置５８として、タッチパネルおよびハードウェアのボタンが設けられる。また、表示装置６０は、ＬＣＤまたは有機ＥＬディスプレイである。
【0042】
入出力Ｉ／Ｆ５６は、マイク６２で検出された操作者の音声をデジタルの音声データに変換してＣＰＵ５０に出力するとともに、ＣＰＵ５０によって出力される音声データをアナログの音声信号に変換してスピーカ６４から出力させる。ただし、この実施例では、ＣＰＵ５０から出力される音声データは、利用者側端末１２から受信した音声データである。また、入出力Ｉ／Ｆ５６は、入力装置５８から入力された操作データ（または、操作情報）をＣＰＵ５０に出力すると共に、ＣＰＵ５０の指示に従って生成された画像データを表示装置６０に出力して、画像データに対応する画像を表示装置６０に表示させる。
【0043】
また、操作者側端末１６は、センサインタフェース（以下、「センサＩ／Ｆ」という）６６およびカメラ６８を備えている。ＣＰＵ５０は、バスおよびセンサＩ／Ｆ６６を介してカメラ６８に接続される。カメラ６８は、ＣＣＤまたはＣＭＯＳのような撮像素子を用いたウェブカメラである。この実施例のカメラ６８は深度を検出する機能を備えていない。また、操作者側端末１６自体も、深度（または、距離）を検出（計測）する機能を備えていない。
【0044】
なお、図３に示す操作者側端末１６の電気的な構成は一例であり、限定される必要はない。
【0045】
このような情報処理システム１０では、利用者は、自身の利用者側端末１２を使用して、サーバ１８が提供する所定のサービスのウェブ画面を見ている場合に、操作者（オペレータ）と対話し、所定のサービスに関する問い合わせを行うことができる。
【0046】
一例として、所定のサービスは、オンラインショッピングであるが、操作者が利用者の問い合わせに対して対応（応答）することができる、任意のオンラインサービスである。
【0047】
図４は、利用者と操作者が対話する場合に、利用者側端末１２の表示装置３０に表示されるアバター画面１００の一例を示す。アバター画面１００は、所定のサービスのウェブ画面に重ねてまたはウェブ画面の一部に含んで表示されてもよいし、所定のサービスのウェブ画面に代えて表示されてもよい。ただし、ウェブ画面の一部に含んで表示される場合には、アバターの画像１０２のみが表示されてもよい。
【0048】
アバター画面１００は操作者の分身であるアバターの画像１０２を含み、アバターの画像１０２は人間の女性を模したキャラクタの画像である。図４に示す例では、アバター画面１００に表示されるアバターの画像１０２は、キャラクタの上半身の画像である。一例として、背景は所定の色で塗りつぶされている。
【0049】
また、アバターの画像１０２は、動物またはロボットを模したキャラクタ、アニメキャラクタ、ゲームキャラクタなどの画像にすることもできる。また、アバターの画像１０２は、キャラクタの全身についての画像でもよい。ただし、この実施例では、操作者の動作に合わせてアバターを動作させる場合があるため、人間と同様の骨格を有している必要がある。
【0050】
アバターの画像１０２は、所定の条件を満たす場合に表示装置３０に表示される。所定の条件は、利用者が操作者の呼び出しを指示したこと、利用者の操作が第１所定時間（この実施例では、３０秒）以上無いこと、当該ウェブ画面において同じ位置または似たような場所（近くの位置）を指示していること、所定のサービスにおいて複数回（たとえば、３回）同じウェブ画面に戻ってくることである。ただし、利用者が操作者の呼び出しを指示する場合を除いて、所定の条件を満たす場合には、利用者側端末１２が自動的に操作者を呼び出す。
【0051】
なお、利用者または利用者側端末１２が操作者を呼び出すと、そのことがサーバ１８に通知され、サーバ１８が操作者（操作者側端末１６）をマッチングし、利用者側端末１２と操作者側端末１６が通信可能に接続される。
【0052】
操作者が利用者に応対し、操作者と利用者が対話中である場合には、利用者側端末１２は、マイク３２を通して利用者の音声を検出すると、検出した音声に対応する音声データを操作者側端末１６に送信する。操作者側端末１６では、受信した音声データをスピーカ６４に出力する。したがって、操作者は、利用者の音声を聞くことができる。
【0053】
一方、操作者側端末１６は、マイク６２を通して操作者の音声を検出すると、検出した音声に対応する音声データを利用者側端末１２に送信する。利用者側端末１２では、受信した音声データをスピーカ３４に出力する。したがって、利用者は、操作者の音声を聞くことができる。
【0054】
後述するように、操作者は男性であるため、操作者の音声を女性の声に変換して出力することもできる。また、アバターが、動物またはロボットを模したキャラクタ、アニメキャラクタ、ゲームキャラクタなどの人間以外のキャラクタである場合には、そのキャラクタの声に変換して出力することもできる。
【0055】
また、この実施例では、操作者側端末１６は、操作者の動作によってアバターの動作が制御されるモード（以下、「手動モード」という）および操作者の動作によらないで自動でアバターの動作が制御されるモード（以下、「自動モード」という）の２つの動作モードを有している。
【0056】
なお、この実施例では、説明の便宜上、「自動モード」に対するモードとして、操作者の動作によってアバターの動作が制御されるモードを「手動モード」と呼んでいるが、手動モードにおいては、撮影画像に基づいてアバターの画像１０２が生成されるため、操作者が何らかの操作を行うことはない。
【0057】
手動モードでは、操作者の動作に合わせてアバターが動作される。つまり、操作者の動作がアバターの動作に反映される。したがって、操作者が利用者に応対し、操作者と利用者が対話している場合には、操作者の動作に合わせてアバターが動作される。また、操作者が発話する場合には、操作者の動作に合わせてアバターが動作されるとともに、操作者の音声が出力される。この場合、アバターの画像１０２はリップシンクされる。つまり、アバターの画像１０２は、操作者が発話する音声の出力に合せて、口唇部を動かされる。したがって、アバターが実際にしゃべっているように表現される。
【0058】
この実施例では、アバターの動作には、アバターの画像１０２の頭部、首および手を動かすだけでなく、アバターの画像１０２の顔の表情、瞼および口唇部を変化させることが含まれる。
【0059】
ただし、アバターの画像１０２の顔の表情については、所定の表情（たとえば、微笑み）に固定し、変化させないようにしてもよい。
【0060】
また、手動モードでは、利用者側端末１２は、操作者を撮影した撮影画像に基づいて生成されたアバターの画像１０２の画像データを用いて、アバター画面１００を表示（または、更新）する。アバターの画像１０２の画像データの生成方法については後述する。
【0061】
図４に示すアバターの画像１０２では、アバターは、顔を正面に向け、右手を下ろし、左肩の前に左手を挙げている。このアバターの画像１０２では、アバターの左手の手のひらは前（アバターの顔が向く方向）に向けられている。また、このアバターの画像１０２では、アバターの顔の表情は、喜びの表情すなわち笑顔である。
【0062】
図５は、利用者と操作者が対話する場合に、操作者側端末１６のカメラ６８で撮影された撮影画像１５０の一例を示す。図５に示す例では、撮影画像１５０は、被写体、すなわち、人間の男性である操作者の画像１５２を含む。図５に示す撮影画像１５０では、簡単のため、背景の画像は省略してある。
【0063】
図５に示すように、撮影画像１５０では、操作者は、顔を正面に向け、右手を下ろし、左肩の前に左手を挙げている。この撮影画像１５０では、操作者の左手の手のひらは前（操作者の顔が向く方向）に向けられている。また、この撮影画像１５０では、操作者の顔の表情は、喜びの表情すなわち笑顔である。
【0064】
図４および図５を比較して分かるように、撮影画像１５０における操作者の動作および顔の表情がアバターの画像１０２の動作および顔の表情に反映される。また、図４および図５では分かり難いが、操作者の瞼および口唇部の変化（動き）も、アバターの画像１０２の瞼および口唇部の変化（動き）に反映される。
【0065】
ここで、撮影画像１５０に基づいてアバターの画像１０２の画像データを生成する方法について説明する。
【0066】
この実施例では、ゲームエンジンを用いてアバターの画像１０２が生成（または、描画）される。ゲームエンジンとしては、ユニティ・テクノロジーズ・ジャパン株式会社が開発および提供するUnity（登録商標）が使用される。Unityは、キャラクタを描画、つまり、キャラクタの画像を生成する機能を有している。
【0067】
図４に示したように、この実施例のアバターは、人間の女性のキャラクタであって、アバターの画像１０２を描画するために、ゲームエンジンでは、アバターに、アバターの関節角度、アバターの手の指の関節角度およびアバターの表情パラメータが適用される。ただし、アバターの関節角度は、Hips（アバターの尻のボーン）、LeftUpperLeg（左太もものボーン）、RightUpperLeg（右太もものボーン）、LeftLowerleg（左ひざのボーン）、RightlowerLeg（右ひざのボーン）、LeftFoot（左足首のボーン）、RightFoot（右足首のボーン）、Spine（背骨の第一ボーン）、Chest（胸のボーン）、Neck（首のボーン）、Head（頭のボーン）、LeftShoulder（左肩のボーン）、RightShoulder（右肩のボーン）、LeftUpperArm（左上腕のボーン）、RightUpperArm（右上腕のボーン）、LeftLowerArm（左ひじのボーン）、RightLowerArm（右ひじのボーン）、LeftHand（左手首のボーン）、RightHand（右手首のボーン）、LeftToes（左つま先のボーン）およびRightToes（右つま先のボーン）についての角度と向きである。また、アバターの表情パラメータとは、アバターの顔の表情を表現するためのパラメータである。
【0068】
なお、アバターの画像１０２は、キャラクタの上半身の画像であり、足は動いていないように見えるが、仮想空間においては、アバターの腰が回転しても、アバターの足が直立に固定されるように関節角度が適用される。ただし、アバターの画像１０２は、仮想空間において、仮想カメラでアバターの上半身を撮影した画像である。
【0069】
アバターに適用される、アバターの関節角度、アバターの手の指の関節角度およびアバターの表情パラメータを算出するために必要な情報がカメラ６８の撮影画像から取得される。以下、必要な情報を取得する方法について説明するが、「腕」、「肩」、「肘」、「手」、「手首」、「目」および「瞼」のように、左右に同じ部位がある場合には、それぞれの部位について必要な情報が取得される。ただし、撮影画像に含まれていない部位またはその一部については必要な情報が取得されない場合もある。
【0070】
この実施例では、必要な情報を取得するために、カメラ６８で撮影された撮影画像が画像処理ライブラリの機械学習ソリューションに入力される。画像処理ライブラリとしては、MediaPipeを使用することができる。撮影画像の大きさは、３６０画素×６４０画素に設定されている。
【0071】
また、画像処理ライブラリにおける機械学習ソリューションの一例として、MediaPipe Horisticが使用される。MediaPipe Horisticでは、MediaPipe Poseと、MediaPipe Handsと、MediaPipe Face Meshが同時に（並列で）動いて、撮影画像に含まれる人間の姿勢、手および顔の各々についてのランドマークが同時に推測および追跡される。
【0072】
ここで、MediaPipe Pose、MediaPipe Hands、および、MediaPipe Face Meshのそれぞれについて説明するが、これらの機械学習ソリューションは既に周知であるため、簡単に説明することにする。
【0073】
なお、MediaPipe Horisticは、https://google.github.io/mediapipe/solutions/holistic.htmlに開示されている。また、MediaPipe Pose、MediaPipe Hands、および、MediaPipe Face Meshは、それぞれ、https://google.github.io/mediapipe/solutions/pose.html、 https://google.github.io/mediapipe/solutions/hands.htmlおよびhttps://google.github.io/mediapipe/solutions/face_mesh.htmlに開示されている。
【0074】
MediaPipe Poseでは、撮影画像から人物を含む領域（人物または姿勢の関心領域（ＲＯＩ））が検出され、人物を含む領域すなわち人物の画像がクロップされる。人物の画像がクロップされると、クロップされた人物の画像から人物または姿勢についての所定数（３３個）の特徴点（ランドマーク）の３次元位置が推測（または、検出）される。このような処理が毎フレーム実行され、姿勢についてのランドマークが追跡される。
【0075】
また、この実施例のMediaPipe Poseでは、POSE_WORLD_LANDMARKSの情報が使用される。POSE_WORLD_LANDMARKSの情報は、POSE_LANDMARKSの情報（３３個のランドマークの３次元位置）を現実世界すなわち現実空間のワールド座標系の３次元位置に変換して出力した情報である。現実空間のワールド座標系では、人物の腰の間の中央に原点が設定され、メートル単位で３次元位置が表される。原点は、後述する、２３が付されたランドマークの３次元位置と、２４が付されたランドマークの３次元位置の中間の位置である（図６参照）。
【0076】
ただし、カメラ６８の撮影方向がワールド座標系のｚ軸の方向であり、水平方向がｘ軸の方向であり、垂直方向がｙ軸の方向である。
【0077】
なお、人物を含む領域の検出は、次フレーム以降では、人物または姿勢のランドマークをトラッキングできなくなった場合にのみ実行される。
【0078】
図６はMediaPipe Poseで推測（または、検出）および追跡される姿勢についての３３個のランドマークを示す図である。３３個のランドマークには、０から３２までの数字（インデックス）が付されている。０を付したランドマークはnose（鼻）の位置を示し、１が付されたランドマークはleft_eye_inner（左目の目頭）の位置を示し、２が付されたランドマークはleft_eye（左目（瞳））の位置を示し、３が付されたランドマークはleft_eye_outer（左目の目尻）の位置を示す。
【0079】
また、４が付されたランドマークはright_eye_inner（右目の目頭）の位置を示し、５が付されたランドマークはright_eye（右目（瞳））の位置を示し、６が付されたランドマークはright_eye_outer（右目の目尻）の位置を示す。
【0080】
さらに、７が付されたランドマークはleft_ear（左耳）の位置を示し、８が付されたランドマークはright_ear（右耳）の位置を示し、９が付されたランドマークはmouth_left（左側の口角）の位置を示し、１０が付されたランドマークはmouth_right（右側の口角）の位置を示す。
【0081】
また、１１が付されたランドマークはleft_shoulder（左肩）の位置を示し、１２が付されたランドマークはright_shoulder（右肩）の位置を示し、１３が付されたランドマークはleft_elbow（左肘）の位置を示し、１４が付されたランドマークはright_elbow（右肘）の位置を示し、１５が付されたランドマークはleft_wrist（左手首）の位置を示し、１６が付されたランドマークはright_wrist（右手首）の位置を示す。
【0082】
さらに、１７が付されたランドマークはleft_pinky（左手の小指）の位置を示し、１８が付されたランドマークはright_pinky（右手の小指）の位置を示し、１９が付されたランドマークはleft_index（左手の示指）の位置を示し、２０が付されたランドマークはright_index（右手の示指）の位置を示し、２１が付されたランドマークはleft_thumb（左手の親指）の位置を示し、２２が付されたランドマークはright_thumb（右手の親指）の位置を示す。
【0083】
また、２３が付されたランドマークはleft_hip（左腰）の位置を示し、２４が付されたランドマークはright_hip（右腰）の位置を示し、２５が付されたランドマークはleft_knee（左膝）の位置を示し、２６が付されたランドマークはright_knee（右膝）の位置を示し、２７が付されたランドマークはleft_ankle（左足首）の位置を示し、２８が付されたランドマークはright_ankle（右足首）の位置を示す。
【0084】
さらに、２９が付されたランドマークはleft_heel（左の踵）の位置を示し、３０が付されたランドマークはright_heel（右の踵）の位置を示し、３１が付されたランドマークはleft_foot_index（左足の示指）の位置を示し、３２が付されたランドマークはright_foot_index（右足の示指）の位置を示す。
【0085】
MediaPipe Handsでは、撮影画像から人物の１または複数の手（この実施例では、左手または／および右手）を含む領域が推測（または検出）され、１または複数の手を含む領域すなわち手の画像がクロップされる。１または複数の手の画像がクロップされると、クロップされた１または複数の手の画像のそれぞれから所定数（２１個）の特徴点（ランドマーク）の３次元位置が推測（または、検出）される。このような処理が毎フレーム実行され、１または複数の手についてのランドマークが追跡される。なお、撮影画像から人物の左手または／および右手を検出できない場合には、検出できない左手または／および右手のランドマークの３次元位置は推測されない。
【0086】
この実施例のMediaPipe Handsでは、MULTI_HANDS_LANDMARKSの情報が使用される。MULTI_HANDS_LANDMARKSでは、撮影画像の左上の頂点を原点（０，０）に設定し、右下の頂点を（１，１）に設定するように正規化したローカル座標系でランドマークの座標が計算される。ただし、ローカル座標系では、撮影画像を正面から見た場合の右向きがｘ軸のプラス方向であり、下向きがｙ軸のプラス方向である。また、ｚ軸方向（奥行き方向または深さ）については、手首の位置（後述する、０が付されたランドマークの位置）を基準として表され、値が小さいほどカメラ（この実施例では、カメラ６８）の位置に近づく。
【0087】
なお、手を含む領域の検出は、次フレーム以降では、手のランドマークをトラッキングできなくなった場合にのみ再度実行される。
【0088】
図７はMediaPipe Handsで推測（検出）および追跡される手（ここでは、左手）についての２１個のランドマークを示す図である。ただし、分かり易くするために、図７では左手の手のひらの画像も示してある。なお、図示は省略するが、右手の手の甲の画像を検出した場合にも、図７に示すような２１個のランドマークが推測される。
【0089】
図７に示すように、２１個のランドマークには、０から２０までの数字が付されている。０が付されたランドマークはWRIST（手首）の位置を示し、１が付されたランドマークはTHUMB_CMC（母指球）の位置を示し、２が付されたランドマークはTHUMB_MCP（母指（または、第１指）の第２関節）の位置を示し、３が付されたランドマークはTHUMB_IP（母指の第１関節）の位置を示し、４が付されたランドマークはTHUMB_TIP（母指の指頭）の位置を示す。
【0090】
また、５が付されたランドマークはINDEX_FINGER_MCP（示指（または、第２指）の第３関節）の位置を示し、６が付されたランドマークはINDEX_FINGER_PIP（示指の第２関節）の位置を示し、７が付されたランドマークはINDEX_FINGER_DIP（示指の第１関節）の位置を示し、８が付されたランドマークはINDEX_FINGER_TIP（示指の指頭）の位置を示す。
【0091】
さらに、９が付されたランドマークはMIDDLE_FINGER_MCP（中指（または、第３指）の第３関節）の位置を示し、１０が付されたランドマークはMIDDLE_FINGER_PIP（中指の第２関節）の位置を示し、１１が付されたランドマークはMIDDLE_FINGER_DIP（中指の第１関節）の位置を示し、１２が付されたランドマークはMIDDLE_FINGER_TIP（中指の指頭）の位置を示す。
【0092】
さらにまた、１３が付されたランドマークはRING_FINGER_MCP（環指（または、第４指）の第３関節）の位置を示し、１４が付されたランドマークはRING_FINGER_PIP（環指の第２関節）の位置を示し、１５が付されたランドマークはRING_FINGER_DIP（環指の第１関節）の位置を示し、１６が付されたランドマークはRING_FINGER_TIP（環指の指頭）の位置を示す。
【0093】
そして、１７が付されたランドマークはPINKY_FINGER_MCP（小指（または、第５指）の第３関節）の位置を示し、１８が付されたランドマークはPINKY_FINGER_PIP（小指の第２関節）の位置を示し、１９が付されたランドマークはPINKY_FINGER_DIP（小指の第１関節）の位置を示し、２０が付されたランドマークはPINKY_FINGER_TIP（小指の指頭）の位置を示す。
【0094】
MediaPipe Face Meshでは、撮影画像から人物の顔を含む領域が検出され、顔を含む領域すなわち顔の画像がクロップされる。顔の画像がクロップされると、クロップされた顔の画像から所定数（４６８個）の特徴点（ランドマーク）の３次元座位置が検出される。また、この実施例では、refine_landmarksオプションを使用することが選択されており、上記の顔のランドマークに加えて、虹彩についての所定数（１０個）のランドマークの３次元位置も検出される。このような処理が毎フレーム実行され、顔および虹彩についてのランドマークが追跡される。
【0095】
なお、虹彩のランドマークを検出するための機械学習ソリューションはMediaPipe Irisであり、refine_landmarksオプションを使用することで、MediaPipe Face Meshの出力に、MediaPipe Irisの出力が複合される。MediaPipe Irisもまた、既に周知であるため、説明は省略する。このMediaPipe Irisについては、https://google.github.io/mediapipe/solutions/iris.htmlに開示されている。
【0096】
また、この実施例のMediaPipe Face Meshでは、MULTI_FACE_LANDMARKSの情報が使用される。MULTI_FACE_LANDMARKSでは、撮影画像の左上の頂点を原点（０，０）に設定し、右下の頂点を（１，１）に設定するように正規化したローカル座標系でランドマークの座標が計算される。ただし、ローカル座標系では、撮影画像を正面から見た場合の右向きがｘ軸のプラス方向であり、下向きがｙ軸のプラス方向である。また、ｚ軸方向（奥行き方向または深さ）については、上唇の上端の中央の点（MediaPipe Face Meshで出力される０が付されたランドマークの位置）を基準として表され、値が小さいほどカメラ（この実施例では、カメラ６８）の位置に近づく。
【0097】
なお、顔を含む領域の検出は、次フレーム以降では、顔のランドマークをトラッキングできなくなった場合にのみ再度実行される。
【0098】
図８（Ａ）はMediaPipe Face Meshで推測（または、検出）および追跡される顔についての４６８個のランドマークのうちの一部を示す図である。ただし、分かり易く示すために、図８（Ａ）ではクロップされた操作者の顔の画像も示してある。
【0099】
図８（Ａ）に示すように、MediaPipe Face Meshで検出される４６８個のランドマークは顔の主な部分についての複数のランドマークを含む。たとえば、主な部分は、眉毛、目、鼻、唇、顎、頬、耳および顔の輪郭である。図８（Ａ）では省略するが、顔の複数のランドマークには０－４６７の番号が付されている。顔についての複数のランドマークおよびランドマークに付された番号の詳細については、https://github.com/google/mediapipe/blob/a908d668c730da128dfa8d9f6bd25d519d006692/mediapipe/modules/face_geometry/data/canonical_face_model_uv_visualization.pngに記載されている。
【0100】
図８（Ｂ）はMediaPipe Face Meshでrefine_landmarksオプションを使用することが選択された場合に、顔のランドマークに加えて推測（または、検出）および追跡される、両目の虹彩についての１０個のランドマークを示す図である。ただし、分かり易くするために、図８（Ｂ）では左目および右目の画像も示してある。
【0101】
図８（Ｂ）に示すように、１０個のランドマークには、４６８から４７７までの数字が付されている。４６８が付されたランドマークは右目の虹彩の中心の位置を示し、４６９が付されたランドマークは右目の虹彩の左端の位置を示し、４７０が付されたランドマークは右目の虹彩の上端の位置を示し、４７１が付されたランドマークは右目の虹彩の右端の位置を示し、４７２が付されたランドマークは右目の虹彩の下端の位置を示す。
【0102】
また、４６８が付されたランドマークは右目の虹彩の中心の位置を示し、４６９が付されたランドマークは右目の虹彩の左端の位置を示し、４７０が付されたランドマークは右目の虹彩の上端の位置を示し、４７１が付されたランドマークは右目の虹彩の右端の位置を示し、４７２が付されたランドマークは右目の虹彩の下端の位置を示す。
【0103】
また、refine_landmarksオプションを使用することが選択された場合には、MediaPipe Face Meshは、顔および虹彩のランドマークの３次元位置のみならず、虹彩の横幅も出力する。ただし、虹彩の横幅は、撮影画像の縦横の長さ（画素数）を正規化した場合の数値で表される。また、虹彩の横幅は、４６９が付されたランドマークの３次元位置と４７１が付されたランドマークの３次元位置の距離または４７４が付されたランドマークの３次元位置と４７６が付されたランドマークの３次元位置の距離を算出することで求めることもできる。
【0104】
上述したアバターの手の指の関節角度は、MediaPipe Handsの出力すなわち手についての２１個のランドマークに基づいて算出することができる。
【0105】
また、上述したアバターの表情パラメータは、MediaPipe Face Meshの出力すなわち顔についての４６８個のランドマークに基づいて算出することができる。
【0106】
さらに、上述したアバターの腕の関節角度については、MediaPipe Poseの出力すなわち姿勢についての３３個のランドマークに基づいて算出することもできるが、この実施例では、撮影画像１５０には、操作者の全身が含まれることがなく、多くても上半身が含まれる程度であり、出力されるランドマークの３次元位置についての奥行き方向の情報についての信頼度が低い。
【0107】
この実施例では、UnityにはFinalIK VRIKが適用されており、このFinalIK VRIKによって上述したアバターの関節角度が算出される。FinalIK VRIKはUnityにインストールされるアセットである。
【0108】
FinalIK VRIKには、入力情報、具体的には、Unity内（つまり、アバターを配置する仮想空間）のワールド座標系における、アバターの頭の回転、アバターの左手および右手（この実施例では、左手首および右手首）の各々の３次元位置と回転、アバターの左肘および右肘の各々の３次元位置と回転およびアバターの腰の回転が入力される。
【0109】
ただし、アバターの頭と腰の３次元位置は仮想空間において固定されている。アバターの頭の３次元位置は、MediaPipe Poseの出力のうち、０が付されたランドマークの現実空間における３次元位置であるが、０が付されたランドマークは鼻の位置であるため、Unityにおける仮想空間の３次元位置に変換する場合に、計算により首の少し上の位置に合わせている。
【0110】
アバターの頭の回転は、MediaPipe Face Meshから出力される顔の４６８点のランドマークから算出される。アバターの左手首および右手首の各々の３次元位置は、MediaPipe Poseから出力される鼻先（０が付されたランドマーク）の位置を基準とした左手首および右手首（１５および１６が付されたランドマーク）の各々の２次元位置（ｘｙ座標）と、右目の位置に対する左手首および右手首の各々の奥行方向の位置（ｚ座標）から算出される。アバターの左手首および右手首の各々の回転は、MediaPipe Handsから出力される手の２１個のランドマークのうち、０、５および９が付されたランドマークの３次元位置から算出される。
【0111】
ただし、MediaPipeの出力からFinalIK VRIKの入力情報を算出する場合には、MediaPipeにおける座標系からUnityにおけるワールド座標系に変換（座標変換）することも含まれまる。以下、同様である。
【0112】
なお、撮影画像１５０に操作者の左手または／および右手の画像が含まれていない場合には、予め定義（用意）された待機アニメーションまたは待機モーションが再生される。ただし、待機アニメーションまたは待機モーションは、一般的な３次元コンピュータグラフィックスの仮想のゲームなどで用いられる関節角アニメーションを意味する。
【0113】
アバターの左肘および右肘の各々の３次元位置と回転は、MediaPipe Poseから出力される左肘および右肘（１３および１４が付されたランドマーク）の各々の３次元位置と、左肩および右肩（１１および１２が付されたランドマーク）の３次元位置から算出される。ただし、図５に示すように、撮影画像１５０に操作者の左肘または／および右肘の画像が含まれていない場合であっても、FinalIK VRIKでは、アバターが自然な姿勢または動きとなるように、アバターの左肘または／および右肘の３次元位置と回転が決定される。アバターの腰の回転は、MediaPipe Poseから出力される左肩および右肩（１１および１２が付されたランドマーク）の３次元位置から算出される。
【0114】
また、MediaPipe Handsの出力からアバターの左手および右手の各々の指の関節角度が算出される。さらに、MediaPipe Face Meshの出力からアバターの表情パラメータの入力情報が生成される。詳細な説明は省略するが、表情パラメータは、アバターが無表情の場合を基準として、口の動き（口の位置、形状および開き具合）、目の動き（瞼の開き具合、目尻の上げ下げ具合）、眉の動き（眉の位置、形状）についてのパラメータである。
【0115】
上述したFinalIK VRIKでは、アバターの左腕および右腕の各々の関節角度を算出するためには、少なくとも、アバターが配置される現実空間のワールド座標系におけるアバターの左手首および右手首の各々の３次元位置および回転を入力する必要がある。しかしながら、上述したように、MediaPipe Poseでは、奥行き方向の情報についての信頼度が低いため、左腕および右腕の各々の関節角度を正しく算出することができない。
【0116】
このため、この実施例では、別の方法で、左手首および右手首の各々の奥行き方向の位置を求めるようにしてある。ただし、左手首および右手首の各々の奥行方向の位置は、操作者の右目（左目でもよい）の位置に対する奥行き方向の位置である。以下、具体的に説明する。
【0117】
標準的な人間の虹彩の横幅（以下、「標準幅」という）を１２ｍｍに決定し、同じく標準的な人間の手のひら（中指の付け根から手首まで）の長さ（以下、「標準長さ」という）を８０ｍｍに決定する。ただし、標準幅と標準長さについては、複数の人間について計測した結果から決定してある。
【0118】
撮影画像から人間（この実施例では、操作者）の右目の虹彩の横幅（以下、「虹彩の検出値」という）を検出するとともに、その撮影画像から人間の左手および右手の各々の手のひらの長さ（以下、「手のひらの検出値」という）を検出する。上述したように、虹彩の横幅は、MediaPipe Face Meshでrefine_landmarksオプションを使用することが選択された場合に、MediaPipe Face Meshの出力に含まれる。また、左手おうび右手の各々の手のひらの長さは、左手および右手の各々について、MediaPipe Handsの出力に含まれる０が付されたランドマークの３次元位置（３次元座標）と９が付されたランドマークの３次元位置（３次元座標）の３次元の距離を算出することで求められる。したがって、左手および右手の各々の手のひらの向きに関係なく、左手および右手の各々の手のひらの長さを求めることができる。ただし、虹彩の横幅および手のひらの長さは、撮影画像の縦横の画素数を０－１の座標に正規化した場合の数値で表される。
【0119】
虹彩の検出値に対する左手および右手の各々の手のひらの検出値の比率（以下、「検出比率」）が標準幅に対する標準長さの比率（以下、「標準比率」）と同じである場合には、奥行き方向において、人間の右目の位置と人間の左手および右手の各々の位置は同じ位置である。また、検出比率が標準比率よりも大きい場合には、奥行き方向において、人間の右目の位置よりも人間の左手および右手の各々の位置は前（手前）である（カメラ６８に近い）。逆に、検出比率が標準比率よりも小さい場合には、奥行き方向において、人間の右目の位置よりも操作者の左手および右手の各々の位置は後（奥）である（カメラ６８から遠い）。
【0120】
ただし、標準比率は、（標準長さ）／（標準幅）＝８０／１２である。また、検出比率は、（手のひらの検出値）／（虹彩の検出値）である。検出比率は、左手および右手の各々について算出される。
【0121】
図９はカメラ位置に対する人間の右目の位置および左手（左手首）の位置を現実空間の上方から見た場合の図の一例を示す。この実施例では、図９に示すように、カメラ６８の位置Ｃに対する、人間の右目の位置Ａの水平距離と、人間の手（ここでは、左手）の位置Ｂの水平距離が同じである場合、位置Ａに対する位置Ｂの距離ｄは０である。図９では、人間の左手について説明するが、右手についても同じである。
【0122】
右目の位置Ａに対して左手の位置Ｂが最も前である場合の位置Ａに対する位置Ｂの距離ｄは、右目の位置Ａを基準とした場合に、標準的な人間の腕の長さに基づいて決定された距離ｄ１であり、この場合に撮影画像から算出される検出比率が最大値（この実施例では、８００／１２）に設定される。
【0123】
また、右目の位置Ａに対して左手の位置Ｂが最も後である場合の位置Ａに対する位置Ｂの距離ｄは、右目の位置Ａを基準とした場合に、後方に所定の距離ｄ２であり、この場合に撮影画像から算出される検出比率が最小値（この実施例では、７２／１２）に設定される。ただし、この実施例では、後方に所定の距離ｄ２は、人間が左手を耳の少し後ろの位置に置いた場合の距離に設定される。なお、図９では分かり易く示すために、虹彩の基準幅に合わせて、標準比率、最大値および最小値を示してある。
【0124】
したがって、検出比率が標準比率よりも大きい場合には、最大値から標準比率を減算した値に対する、検出比率から標準比率を減算した値の割合を算出し、算出した割合を距離ｄ１に乗算することで、右目の位置Ａに対する左手の位置Ｂの手前方向の距離ｄが算出される。つまり、右目の位置Ａに対する前方向の左手の位置Ｂが算出される。また、仮想空間におけるアバターの腕の長さが標準的な人間の腕の長さと異なる場合には、アバターの腕の長さに基づいて距離ｄ１を設定してもよいし、算出した距離ｄを腕の長さの比率で換算してもよい。ただし、腕の長さは、UpperArm（上腕）の関節からHand（手首）の関節までの長さである。
【0125】
また、検出比率が標準比率よりも小さい場合には、標準比率から検出比率を減算した値に対する、標準比率から最小値を減算した値の割合を算出し、算出した割合を距離ｄ２に乗算することで、右目の位置Ａに対する左手の位置の後ろ方向の距離ｄが算出される。つまり、右目の位置Ａに対する後ろ方向の左手の位置Ｂが算出される。
【0126】
ただし、検出比率が、最大値と最小値で決定される範囲を超える場合には、その範囲内の数値に修正される。この実施例では、検出比率が最大値を超える場合には、検出比率は最大値に修正される。また、検出比率が最小値よりも小さい場合には、検出比率は最小値に修正される。
【0127】
手動モードでは、アバターの画像１０２の画像データは、撮影画像に基づいて毎フレーム生成され、利用者側端末１２に送信される。利用者側端末１２では、表示装置３０にアバターの画像１０２を含むアバター画面１００が表示（または、更新）される。したがって、操作者の動作に応じてアバターが動作されるとともに、操作者の表情がアバターの表情に反映される。また、上述したように、操作者が発話する場合は、操作者の音声データも利用者側端末１２に送信され、アバターの画像１０２はリップシンクされる。
【0128】
一方、自動モードでは、操作者の動作に関係無く、アバターの画像１０２が生成される。上述したように、この実施例では、アバターの画像１０２の生成にはUnityを使用するため、自動モードにおいては、アバターの動きに応じて予め記憶された、アバターの関節角度、アバターの手の指の関節角度およびアバターの顔の表情パラメータの時系列に従うデータ（以下、「自動動作データ」という）を、フレーム毎にアバターに当てはめるようにしてある。
【0129】
つまり、操作者側端末１６には、自動モードにおける様々なアバターの動きの各々に応じて自動動作データが記憶されており、所定の方法で決定されたアバターの動きに応じて、アバターに当てはめる自動動作データが決定される。
【0130】
この実施例では、操作者が発話する場合には、操作者のしゃべる内容に応じてアバターの動きが決定される。操作者のしゃべる内容に応じてアバターの動きを決定する方法としては、特開２０２０－６４８２に開示された方法を適用することができる。ただし、この特開２０２０－６４８２では、アンドロイド（登録商標）のジェスチャ（すなわち、腕の動き）を決定するため、同じ手法でアバターの動きを決定するように適宜変更される。
【0131】
利用者が発話する場合には、利用者の音声が途切れたタイミング、または、利用者が操作者に同意を求めている内容を発話したタイミングで、アバターに頷き動作を行わせることが決定される。利用者の音声が途切れたことは、利用者の音声の音量が予め設定される所定のレベル以下である状態が第２所定時間（たとえば、数ｍｓｅｃ）継続した場合に判断される。また、利用者が操作者に同意を求めている内容を発話したことは、利用者の音声を認識し、利用者が予め設定される所定の同意を求める内容を発話しているかどうかで判断される。同意を求める内容は、「～ですよね」および「よろしいですか」などである。
【0132】
また、利用者が発話する場合には、利用者の音声が第３所定時間（たとえば、３０秒）以上継続する場合には、アバターの視線を正面から逸らせるように、頭部の向きを左斜め上方または右斜め上方に向ける動作を行わせることが決定される。
【0133】
操作者と利用者の両方が発話していない状況が第４所定時間（たとえば、５～１０秒）以上継続する場合には、アバターに無意識動作を行わせることが決定される。無意識動作は、手でおでこを触ったり、首を傾げたりするような動作である。
【0134】
なお、いずれの場合であっても、アバターの表情パラメータは、所定の表情（たとえば、微笑み）を表現するように設定されている。ただし、アバターの表情パラメータについては自動動作データに含めずに、操作者または利用者の音声に基づいて判断した感情に応じて表情パラメータを選択し、選択した表情パラメータをアバターに当てはめるようにしてもよい。
【0135】
自動モードでは、アバターの画像１０２の画像データは、自動で毎フレーム生成され、利用者側端末１２に送信される。自動モードにおいても、利用者側端末１２では、表示装置３０にアバターの画像１０２を含むアバター画面１００が表示（または、更新）される。したがって、操作者の動作によらないでアバターが動作されるとともに、所定の表情が反映される。また、上述したように、操作者が発話する場合は、操作者の音声データも利用者側端末１２に送信され、アバターの画像１０２はリップシンクされる。
【0136】
また、対話中では、操作者が所定のジェスチャを行うことで、操作者側端末１６ではアバターの動作モードが手動モードまたは自動モードに設定される。この実施例では、操作者は、手で所定のジェスチャを行う。一例として、操作者は、左手または右手の第３指と第４指をそれぞれ第２関節で折り曲げ、第１指、第２指および第５指を延ばした形状にする。
【0137】
【0138】
図１０に示す撮影画像１５０は一例であり、操作者の手の向きは別の向きでもよいし、右手を所定の形状にしてもよい。ただし、当然のことではあるが、所定のジェスチャを行っている手をカメラ６８で撮影できない場合には、すなわち、撮影画像１５０に操作者の手の画像が含まれていない場合には、所定のジェスチャを検出することはできない。
【0139】
この実施例では、操作者のジェスチャ（この実施例では、手の形状）は、MediaPipe Handsから出力される２１個の特徴点に基づいて検出される。具体的には、２１個の特徴点から指の関節角度が算出され、算出された指の関節角度から操作者の手の形状が検出（または、認識）される。そして、検出された左手または右手の形状が所定の形状であるかどうかが判断される。
【0140】
上述したように、動作モードが手動モードである場合には、MediaPipe Horisticに含まれるMediaPipe Handsを動作させるので、その出力を用いて操作者の手の形状が検出される。一方、動作モードが自動モードである場合には、MediaPipe Horisticを動作させないため、操作者の手の形状を検出する場合に、MediaPipe Handsを動作させる。
【0141】
この実施例では、利用者と操作者が対話を開始したとき、動作モードは手動モードに設定される。ただし、開始時の動作モードは、自動モードに設定されるようにすることもできる。
【0142】
動作モードが手動モードある場合に、所定のジェスチャが検出されると、動作モードが自動モードに切り替えられる。つまり、動作モードが自動モードに設定される。一方、動作モードが自動モードである場合に、所定のジェスチャが検出されると、動作モードが手動モードに切り替えられる。つまり、動作モードが手動モードに設定される。
【0143】
このように、操作者は所定のジェスチャを行うことで、動作モードを手動モードまたは自動モードに切り替える（または、設定する）ことができる。つまり、動作モードを、手動モードと自動モードの間でシームレスに切り替えることができる。
【0144】
上述したように、自動モードでは、アバターの画像１０２は自動で描画（または、生成）および表示されるため、操作者は、利用者と対話しながら、他の作業を行うことができる。
【0145】
また、この実施例では、動作モードを手動モードから自動モードに切り替える場合と自動モードから手動モードに切り替える場合とで、操作者は同じ所定のジェスチャを行い、この同じ所定のジェスチャを検出するようにしてあるが、限定される必要はない。他の例では、動作モードを手動モードから自動モードに切り替える場合と自動モードから手動モードに切り替える場合とで、操作者は異なる所定のジェスチャを行い、異なる所定のジェスチャをそれぞれ検出するようにしてもよい。
【0146】
この場合、異なる所定のジェスチャは、上記の所定のジェスチャと、この所定のジェスチャとは別の所定の形状である。別の所定の形状としては、第３指、第４指および第５指を第２関節から折り、第１指および第２指を延ばした形状、第４指と第５指を第２関節から折り、第１指、第２指および第３指を延ばした形状、第３指だけを第２関節から折り、他の４本の指を延ばした形状、グーまたはチョキの形状などが該当する。
【0147】
なお、この実施例では、手を所定の形状にすることで所定のジェスチャを行うが、他の例では、手を所定の方向に動かすようにしてもよい。たとえば、左手または右手を、体の前で、左から右に、または、右から左に所定の長さ（たとえば、５０ｃｍ）以上移動させたり、上から下に、または、下から上に所定の長さ（たとえば、３０ｃｍ）以上移動させたり、体の前で、左手と右手をクロスさせたり、体の前で、左手または右手を、円を描くように移動させたりすることなどが該当する。腕の動きは、MediaPipe Poseの出力に基づいて検出することができる。ただし、腕の動きは、複数のフレーム分（たとえば、１秒）の撮影画像に基づいて検出される。
【0148】
図１１は、利用者側端末１２に内蔵されるＲＡＭ２２のメモリマップ３００の一例を示す。図１１に示すように、ＲＡＭ２２は、プログラム記憶領域３０２およびデータ記憶領域３０４を含む。プログラム記憶領域３０２には、この実施例の利用者側端末１２の制御プログラムが記憶されている。
【0149】
制御プログラムは、メイン処理プログラム３０２ａ、操作検出プログラム３０２ｂ、通信プログラム３０２ｃ、画像生成プログラム３０２ｄ、画像出力プログラム３０２ｅ、音検出プログラム３０２ｆおよび音出力プログラム３０２ｇなどを含む。
【0150】
メイン処理プログラム３０２ａは、この実施例の利用者側端末１２の制御プログラムのメインルーチンの処理（全体的な処理）を実行するためのプログラムである。
【0151】
操作検出プログラム３０２ｂは、利用者の操作に従って入力装置２８から入力される操作データ３０４ａを検出し、データ記憶領域３０４に記憶するためのプログラムである。
【0152】
通信プログラム３０２ｃは、外部の機器、この実施例では、所定のサービスを提供するサイトを運営するためのサーバ（この実施例では、サーバ１８）および操作者側端末１６と有線または無線で通信（データの送信および受信）するためのプログラムである。
【0153】
画像生成プログラム３０２ｄは、表示装置３０に表示するための各種の画面の全部または一部に対応する画像データを、画像生成データ３０４ｄを用いて生成するためのプログラムである。
【0154】
画像出力プログラム３０２ｅは、画像生成プログラム３０２ｄに従って生成した画像データを表示装置３０に出力するためのプログラムである。
【0155】
音検出プログラム３０２ｆは、マイク３２から入力される操作者の音声を検出するためのプログラムである。
【0156】
音出力プログラム３０２ｇは、受信した操作者の音声データを出力するためのプログラムである。
【0157】
図示は省略するが、プログラム記憶領域３０２には、利用者側端末１２のオペレーティングシステムなどのミドルウェア、ブラウザ機能を実行するためのプログラム、本願の制御プログラム以外の他のアプリケーション・プログラムも記憶される。
【0158】
また、データ記憶領域３０４には、操作データ３０４ａ、送信データ３０４ｂ、受信データ３０４ｃおよび画像生成データ３０４ｄなどが記憶される。
【0159】
操作データ３０４ａは、操作検出プログラム３０２ｂに従って検出された操作データである。
【0160】
送信データ３０４ｂは、操作者側端末１６に送信するデータであり、主として、利用者の音声についての音声データ、操作者側端末１６への対話終了の通知データである。
【0161】
受信データ３０４ｃは、操作者側端末１６から送信され、受信したデータであり、主として、操作者の音声についての音声データ、アバターの画像１０２の画像データ、操作者側端末１６からの対話終了の通知データである。
【0162】
画像生成データ３０４ｄは、利用者側端末１２の表示装置３０に表示される各種の画面（アバター画面１００など）を生成するためのデータである。
【0163】
図示は省略するが、データ記憶領域３０４には、制御処理を実行するために必要な他のデータが記憶されたり、タイマ（カウンタ）およびフラグが設けられたりする。
【0164】
図１２は、操作者側端末１６に内蔵されるＲＡＭ５２のメモリマップ５００の一例を示す。図１２に示すように、ＲＡＭ５２は、プログラム記憶領域５０２およびデータ記憶領域５０４を含む。プログラム記憶領域５０２には、この実施例の操作者側端末１６の制御プログラムが記憶されている。
【0165】
制御プログラムは、メイン処理プログラム５０２ａ、操作検出プログラム５０２ｂ、通信プログラム５０２ｃ、アバター画像生成プログラム５０２ｄ、撮影プログラム５０２ｅ、姿勢認識プログラム５０２ｆ、手認識プログラム５０２ｇ、顔認識プログラム５０２ｈ、深度推定プログラム５０２ｉ、深度修正プログラム５０２ｊ、ジェスチャ判断プログラム５０２ｋ、動作モード切替プログラム５０２ｍ、音検出プログラム５０２ｎおよび音出力プログラム５０２ｐなどが記憶される。
【0166】
メイン処理プログラム５０２ａは、この実施例の操作者側の制御プログラムのメインルーチンの処理（全体的な処理）を実行するためのプログラムである。
【0167】
操作検出プログラム５０２ｂは、操作者の操作に従って入力装置５８から入力される操作データ５０４ａを検出し、データ記憶領域５０４に記憶するためのプログラムである。
【0168】
通信プログラム５０２ｃは、外部の機器、この実施例では、利用者側端末１２およびサーバ１８と有線または無線で通信するためのプログラムである。
【0169】
アバター画像生成プログラム５０２ｄは、アバター画像生成データ５０４ｄを用いて、アバターの画像１０２を含むアバター画面１００の画像データを生成するためのプログラムである。この実施例では、アバター画像生成プログラム５０２ｄは、FinalIK VRIKが適用されたUnityである。
【0170】
撮影プログラム５０２ｅは、カメラ６８に撮影処理を実行させ、センサＩ／Ｆ６６を介してカメラ６８から入力される撮影画像データ５０４ｆを記憶するためのプログラムである。
【0171】
姿勢認識プログラム５０２ｆは、MediaPipe Poseであり、現在のフレームの撮影画像１５０から人間についての３３個のランドマークの３次元位置を検出（推測）および追跡するためのプログラムである。ただし、姿勢についてのランドマークの３次元位置は、現実空間におけるワールド座標系における３次元位置である。
【0172】
手認識プログラム５０２ｇは、MediaPipe Handsであり、現在のフレームの撮影画像１５０から左手および右手のそれぞれについて、２１個のランドマークの３次元位置を検出（推測）および追跡するためのプログラムである。ただし、手についてのランドマークの３次元位置は、撮影画像の左上の頂点を原点とした場合のローカル座標系における３次元位置であり、奥行き方向の位置は手首の位置を基準に決定される。
【0173】
顔認識プログラム５０２ｈは、MediaPipe Face Meshであり、現在のフレームの撮影画像１５０から顔についての４６８個のランドマークの３次元位置を検出（推測）および追跡するためのプログラムである。この実施例では、refine_landmarksオプションを使用することが選択されており、MediaPipe Face Meshでは、上記の顔のランドマークに加えて、虹彩についての所定数（１０個）のランドマークの３次元位置および虹彩の横幅も検出される。
【0174】
ただし、上述したように、この実施例では、MediaPipe Poseと、MediaPipe Handsと、MediaPipe Face Meshを同時に並行して動作させるMediaPipe Horisticが使用される。
【0175】
深度推定プログラム５０２ｉは、撮影画像１５０から検出された操作者の虹彩の横幅に対する、撮影画像１５０から検出された操作者の手のひらの長さについての検出比率と標準比率を用いて、操作者の目の位置Ａに対する奥行き方向の手首の位置Ｂを推定するためのプログラムである。
【0176】
深度修正プログラム５０２ｊは、深度推定プログラム５０２ｉで推定された操作者の目の位置Ａに対する奥行き方向の手首の位置Ｂが最大値および最小値で決まる範囲を超える場合に、その範囲内に修正するためのプログラムである。
【0177】
ジェスチャ判断プログラム５０２ｋは、手認識プログラム５０２ｇに従って認識された操作者の手の形状（２１個のランドマークから決定される手の形状）が所定の形状を示すかどうかを判断するためのプログラムである。
【0178】
動作モード切替プログラム５０２ｍは、ジェスチャ判断プログラム５０２ｋに従って操作者の手の形状が所定の形状を示すことが判断されたことに応じて、動作モードを、手動モードから自動モードに切り替えたり、自動モードから手動モードに切り替えたりするためのプログラムである。
【0179】
音検出プログラム５０２ｎは、マイク６２から入力される操作者の音声を検出するためのプログラムである。
【0180】
音出力プログラムは５０２ｐ、受信した利用者の音声データを出力するためのプログラムである。
【0181】
図示は省略するが、プログラム記憶領域５０２には、操作者側端末１６のオペレーティングシステムおよびミドルウェアとは別に、ブラウザ機能を実行するためのプログラム、画像生成プログラム、画像出力プログラム、本願の制御プログラム以外の他のアプリケーション・プログラムも記憶される。
【0182】
図１３は図１２に示したＲＡＭ５２のデータ記憶領域５０４の具体的な内容を示す図である。図１３に示すように、データ記憶領域５０４には、操作データ５０４ａ、送信データ５０４ｂ、受信データ５０４ｃ、アバター画像生成データ５０４ｄ、切替ジェスチャデータ５０４ｅ、撮影画像データ５０４ｆ、姿勢特徴点データ５０４ｇ、手特徴点データ５０４ｈ、顔特徴点データ５０４ｉ、入力情報データ５０４ｊ、指関節データ５０４ｋ、表情パラメータデータ５０４ｍ、腕関節データ５０４ｎ、自動動作データ５０４ｐおよび動作モードデータ５０４ｑなどが記憶される。
【0183】
操作データ５０４ａは、操作検出プログラム５０２ｂに従って検出された操作データである。
【0184】
送信データ５０４ｂは、利用者側端末１２に送信するデータであり、主として、操作者の音声についての音声データ、アバターの画像１０２の画像データ、利用者側端末１２への対話終了の通知データである。
【0185】
受信データ５０４ｃは、利用者側端末１２から送信され、受信したデータであり、主として、利用者の音声についての音声データ、対話終了の通知データである。
【0186】
アバター画像生成データ５０４ｄは、アバターの画像１０２の画像データを生成するためのデータであって、アバターについてのボーン、ポリゴンおよびテクスチャについてのデータである。ただし、複数のアバターを用意し、いずれかのアバターを選択可能にする場合には、複数のアバターの各々についてアバター画像生成データ５０４ｄが記憶される。
【0187】
切替ジェスチャデータ５０４ｅは、所定のジェスチャすなわち所定の形状についてのデータであり、予め登録される。
【0188】
撮影画像データ５０４ｆは、カメラ６８で撮影された撮影画像のデータである。この実施例では、撮影画像は、操作者の上半身の画像を含む。
【0189】
姿勢特徴点データ５０４ｇは、MediaPipe Poseで検出および追跡される姿勢についての３３個のランドマークの現実空間のワールド座標系における３次元位置（３次元座標）についてのデータである。
【0190】
手特徴点データ５０４ｈは、MediaPipe Handsで検出および追跡される左手または／および右手の各々についての２１個のランドマークのローカル座標系における３次元位置（３次元座標）についてのデータである。
【0191】
顔特徴点データ５０４ｉは、MediaPipe Face Meshで検出および追跡される顔についての４６８個のランドマークのローカル座標系における３次元位置（３次元座標）についてのデータである。また、顔特徴点データ５０４ｉは、虹彩についての１０個のランドマークのローカル座標系における３次元位置（３次元座標）および虹彩の横幅についてのデータを含む。
【0192】
入力情報データ５０４ｊは、FinalIK VRIKに入力する入力情報についてのデータである。具体的には、入力情報は、Unity内のワールド座標系における、アバターの頭の回転、アバターの手首（左手首または／および右手首）の３次元位置、アバターの手首（左手首または／および右手首）の回転、アバターの肘の３次元位置と回転およびアバターの腰の回転である。
【0193】
指関節データ５０４ｋは、アバターの左手または／および右手に指の関節角度についてのデータである。
【0194】
表情パラメータデータ５０４ｍは、アバターの顔の表情についての表情パラメータのデータである。
【0195】
腕関節データ５０４ｎは、アバターの左腕および右腕の関節角度についてのデータである。
【0196】
自動動作データ５０４ｐは、自動モードにおける様々なアバターの動きの各々に応じた、アバターの関節角度、アバターの手の指の関節角度およびアバターの顔の表情パラメータの時系列に従うデータである。
【0197】
動作モードデータ５０４ｑは、動作モードを識別するためのデータであり、具体的には、手動モードまたは自動モードの別を示すデータである。
【0198】
図示は省略するが、データ記憶領域５０４には、制御処理を実行するために必要な他のデータが記憶されたり、タイマ（カウンタ）およびフラグが設けられたりする。
【0199】
図１４は、利用者側端末１２のＣＰＵ２０の制御処理を示すフロー図である。図示は省略するが、ＣＰＵ２０は、制御処理と並行して、操作データおよび音声データを検出する処理を実行するとともに、操作者側端末１６からの各種のデータを受信する処理を実行する。
【0200】
図１４に示すように、利用者側端末１２のＣＰＵ２０は、制御処理を開始すると、ステップＳ１で、操作者側端末１６から音声データを受信したかどうかを判断する。
【0201】
ステップＳ１で“ＹＥＳ”であれば、つまり、操作者側端末１６から音声データを受信すれば、ステップＳ３で、受信した音声データをスピーカ３４に出力し、ステップＳ５で、音声データの出力に合わせて発話するアバターの画像データを表示装置３０に出力して、ステップＳ１３に進む。この実施例では、ステップＳ５では、アバターの画像１０２を含むアバター画面１００の画像データが表示装置３０に出力される。また、ステップＳ５では、アバターの画像１０２は、スピーカ３４から出力される音声にリップシンクされる。したがって、アバターの画像１０２が喋っているように表現される。
【0202】
また、ステップＳ１で“ＮＯ”であれば、つまり、操作者側端末１６から音声データを受信していなければ、ステップＳ７で、音声データを検出したかどうかを判断する。ここでは、ＣＰＵ２０は、マイク３２で検出された音声の音声データが入力されたかどうかを判断する。
【0203】
ステップＳ７で“ＮＯ”であれば、つまり、音声データを検出していなければ、ステップＳ１１に進む。一方、ステップＳ７で“ＹＥＳ”であれば、つまり、音声データを検出すれば、ステップＳ９で、検出した音声データを操作者側端末１６に送信する。したがって、操作者は利用者の音声を聞くことができる。
【0204】
次のステップＳ１１では、アバターの画像データを表示装置３０に出力する。この実施例では、ステップＳ１１では、アバターの画像１０２を含むアバター画面１００の画像データが表示装置３０に出力される。
【0205】
そして、ステップＳ１３では、対話の終了かどうかを判断する。ここでは、ＣＰＵ２０は、利用者から対話の終了の指示があるかどうか、および、操作者側端末１６から対話の終了の通知を受信したかどうかを判断する。
【0206】
ステップＳ１３で“ＮＯ”であれば、つまり、対話の終了でなければ、ステップＳ１に戻る。一方、ステップＳ１３で“ＹＥＳ”であれば、つまり、対話の終了であれば、制御処理を終了する。ただし、利用者の指示に従って対話を終了する場合には、対話を終了することが操作者側端末１６に通知される。
【0207】
図１５は、操作者側端末１６のＣＰＵ５０の制御処理を示すフロー図である。図示は省略するが、ＣＰＵ５０は、制御処理と並行して、撮影処理、操作データおよび音声データを検出する処理、および、利用者側端末１２からの各種のデータを受信する処理を実行する。また、ＣＰＵ５０の制御処理について説明するが、同じ処理内容については簡単に説明することにする。なお、制御処理の開始時には、動作モードは手動モードに設定されている。
【0208】
図１５に示すように、操作者側端末１６のＣＰＵ５０は、制御処理を開始すると、ステップＳ３１で、動作モードデータ５０４ｑを参照して、動作モードが手動モードであるかどうかを判断する。
【0209】
【0210】
一方、ステップＳ３１で“ＮＯ”であれば、つまり、動作モードが自動モードであれば、ステップＳ３５で、自動モードのアバター画像生成処理を実行して、ステップＳ３７に進む。上述したように、ステップＳ３５では、ＣＰＵ５０は、所定の方法でアバターの動きを決定し、決定したアバターの動きに応じた自動動作データ５０４ｐを選択して、選択した自動動作データ５０４ｐをアバターに適用してアバターの画像１０２の画像データを生成する。
【0211】
ステップＳ３７では、アバターの画像１０２の画像データを利用者側端末１２に送信する。次のステップＳ３９では、音声データを受信したかどうかを判断する。ステップＳ３９で“ＹＥＳ”であれば、つまり、音声データを受信していれば、ステップＳ４１で、受信した音声データをスピーカ６４に出力して、ステップＳ４７に進む。
【0212】
一方、ステップＳ３９で“ＮＯ”であれば、つまり、音声データを受信していなければ、ステップＳ４３で、音声データを検出したかどうかを判断する。ステップＳ４３で“ＮＯ”であれば、つまり、音声データを検出していなければ、ステップＳ４７に進む。一方、ステップＳ４３で“ＹＥＳ”であれば、つまり、音声データを検出していれば、ステップＳ４５で、音声データを利用者側端末１２に送信して、ステップＳ４７に進む。
【0213】
ステップＳ４７では、ジェスチャを検出する。この実施例では、MediaPipe Handsを動作させ、検出した左手または右手の形状が、切替ジェスチャデータ５０４ｅが示す所定の形状であるかどうかを判断する。ただし、自動モードでは、ステップＳ３３でMediaPipe Handsが動作しているため、ＣＰＵ５０は、ステップＳ４７では、MediaPipe Handsを動作させずに、ステップＳ３３の処理結果からジェスチャを検出する。
【0214】
次のステップＳ４９で、動作モードの切り替えかどうかを判断する。ステップＳ４９では、ＣＰＵ５０は、ステップＳ４７で検出したジェスチャすなわち手の形状が所定の形状と同じであるかどうかを判断する。
【0215】
ステップＳ４９で“ＹＥＳ”であれば、つまり、動作モードの切り替えであれば、ステップＳ５１で、動作モードを切り替えて、ステップＳ３１に戻る。ステップＳ５１では、ＣＰＵ５０は、動作モードデータ５０４ｑを参照して、現在の動作モードが手動モードであれば、自動モードに切り替え、現在の動作モードが自動モードであれば、手動モードに切り替える。
【0216】
一方、ステップＳ４９で“ＮＯ”であれば、つまり、動作モードの切り替えでなければ、ステップＳ５３で、対話の終了かどうかを判断する。ここでは、ＣＰＵ５０は、操作者から対話の終了の指示があるかどうか、および、利用者側端末１２から対話の終了の通知を受信したかどうかを判断する。
【0217】
ステップＳ５３で“ＮＯ”であれば、つまり、対話の終了でなければ、ステップＳ３１に戻る。一方、ステップＳ５３で“ＹＥＳ”であれば、つまり、対話の終了であれば、制御処理を終了する。ただし、操作者の指示に従って対話を終了する場合には、対話を終了することが利用者側端末１２に通知される。
【0218】
図１６および図１７は、図１５に示したステップＳ３３の手動モードのアバター画像生成処理の一例を示すフロー図である。図１６に示すように、ＣＰＵ５０は、手動モードのアバター画像生成処理を開始すると、ステップＳ１０１で、撮影画像１５０に対してMediaPipe Horisticを適用する。つまり、撮影画像１５０に対して、MediaPipe Pose、MediaPipe HandsおよびMediaPipe Face Meshが同時に並行して動作される。
【0219】
次のステップＳ１０３では、MediaPipe Poseの出力から現実空間のワールド座標系における左手首および右手首の各々の２次元座座標（２次元位置）と、左肘および右肘の各々の３次元位置と、左肩および右肩の各々の３次元位置を取得する。続くステップＳ１０５では、MediaPipe Handsの出力からローカル座標系における左手および右手の各々の特徴点の３次元位置を取得する。続いて、ステップＳ１０７は、MediaPipe Face Meshの出力からローカル座標系における顔の特徴点の３次元位置および右目の虹彩の横幅を取得する。
【0220】
さらに、ステップＳ１０９で、右目の位置に対する奥行方向における左手首および右手首の各々の位置を推定（算出）する。ここでは、上述したように、虹彩の横幅の検出値に対する手のひらの長さの検出値の検出比率と、標準比率とに基づいて、目の位置Ａに対する奥行方向における手首の位置Ｂが算出される。ただし、上述したように、手のひらの長さの検出値は、MediaPipe Handsの出力のうち、０が付されたランドマークの３次元位置と９が付されたランドマークの３次元位置の距離を算出することで求められる。また、検出比率は、左手および右手の各々について算出され、左手首および右手首の各々の位置Ｂが算出される。
【0221】
次のステップＳ１１１では、ステップＳ１０９で算出した手首の位置が所定の範囲を超えているかどうかを判断する。ここでは、ＣＰＵ５０は、検出比率が目の位置に対する奥行方向における手首の位置の比率の最大値と最小値で決定される範囲を超えているかどうかを判断する。
【0222】
ステップＳ１１１で“ＹＥＳ”であれば、つまり、手首の位置が所定の範囲を超えている場合には、ステップＳ１１３で、所定の範囲に収まるように手首の位置を修正して、図１７に示すステップＳ１１５に進む。ステップＳ１１１で“ＮＯ”であれば、つまり、手首の位置が所定の範囲を超えていない場合には、ステップＳ１１５に進む。
【0223】
なお、ステップＳ１１１－ステップＳ１１３の処理については、左手首および右手首の各々について実行される。
【0224】
図１７に示すように、ステップＳ１１５では、アバターを配置する仮想空間のワールド座標系での頭の回転を算出する。上述たように、アバターの頭の回転は、MediaPipe Face Meshから出力される顔の４６８点のランドマークから算出される。
【0225】
続くステップＳ１１７では、アバターを配置する仮想空間のワールド座標系での左手首および右手首の各々の３次元位置および回転を算出する。アバターの左手首および右手首の各々の３次元位置は、MediaPipe Poseから出力される鼻先（０が付されたランドマーク）の位置を基準とした左手首および右手首（１５および１６が付されたランドマーク）の２次元位置と、ステップＳ１０９で算出またはステップＳ１１３で修正された目の位置に対する左手首および右手首の各々の奥行方向の位置から算出される。また、アバターの左手首および右手首の回転は、MediaPipe Handsから出力される左手首および右手首の各々の２１個のランドマークの３次元位置から算出される。
【0226】
続いて、ステップＳ１１９は、アバターを配置する仮想空間のワールド座標系での左肘および右肘の各々の位置および回転を算出する。アバターの左肘および右肘の各々の３次元位置と回転は、MediaPipe Poseから出力される左肘および右肘（１３および１４が付されたランドマーク）の３次元位置と、左肩および右肩（１１および１２が付されたランドマーク）の３次元位置から算出される。
【0227】
次のステップＳ１２１では、アバターを配置する仮想空間のワールド座標系での腰の回転を算出する。アバターの腰の回転は、MediaPipe Poseから出力される左肩および右肩（１１および１２が付されたランドマーク）の３次元位置から算出される。
【0228】
続くステップＳ１２３では、MediaPipe Handsの出力からアバターの左手および右手の各々の指の関節角度を算出する。ただし、撮影画像に操作者の左手または／および右手の画像が含まれていない場合には、アバターの左手または／および右手の各々の指の関節角度は算出されない。
【0229】
続いて、ステップＳ１２５では、MediaPipe Face Meshの出力からアバターの顔の表情パラメータの入力情報を算出する。さらに、ステップＳ１２７で、アバターの関節角度を算出する。
【0230】
そして、ステップＳ１２９で、アバターの画像１０２の画像データを生成して、手動モードのアバター画像生成処理を終了して、図１５に示した制御処理にリターンする。ステップＳ１２９では、ＣＰＵ５０は、ステップＳ１２３で算出したアバターの手の指の関節角度、ステップＳ１２５で算出したアバターの顔の表情パラメータの入力情報、およびステップＳ１２７で算出したアバターの関節角度をアバターに適用し、現フレームにおけるアバターの画像１０２の画像データを生成する。
【0231】
この実施例によれば、操作者の所定のジェスチャに応じて、アバターの画像を自動で生成する自動モードと、アバターの画像を操作者の動作に基づいて生成する手動モードを切り替えるので、キーボード入力、ボタン操作または音声入力を行う必要が無く、動作モードを円滑に切り替えることができる。
【0232】
また、この実施例によれば、対話中に操作者は所定のジェスチャを行うだけなので、ユーザに違和感または不快感を与えることはほとんどない。
【0233】
また、この実施例では、操作者の所定のジェスチャに応じて、アバターの画像を自動で生成する自動モードと、アバターの画像を操作者の動作に基づいて生成する手動モードを切り替えるので、自動モードを設定した場合には、操作者は手を自由に使うことができる。このため、操作者は利用者と対話しながら他の作業を行うことができる。
【0234】
さらに、この実施例によれば、撮影画像に基づいて検出される操作者の虹彩の横幅に対する手のひらの長さに基づいて、操作者の目の位置に対する奥行方向の手首の位置を算出するので、深度を検出するセンサ等を設けずに、操作者の腕の動きに応じてアバターの腕の動きを制御することができる。
【0235】
なお、この実施例では、MediaPipeのような画像処理ライブラリのソリューションであるMediaPipe Horisticを用いるようにしたが、これに限定される必要はない。
【0236】
全身（姿勢）の特徴点（ランドマーク）を検出するソリューションとしては、ThreeDPoseTrackerを用いることもできる。また、手の特徴点を検出するソリューションとしては、Motion Gestures SDKを用いることもできる。さらに、顔の特徴点を検出するソリューションとしては、ＡＣＭ(Active Contour Model)、ＡＳＭ(Active Shape Model)、ＡＡＭ(Active Appearance Model)、ＳＤＭ(Supervised Descent Method)を用いることもできる。さらにまた、虹彩の特徴点を検出するソリューションとしては、DlibとOpenCVを用いることもできる（参照：https://qiita.com/sassa4771/items/fbfb0012744350cf4d93）。Dlibを用いて顔ランドマークが検出され、OpenCVを用いて虹彩の区画が切り出される。
【0237】
なお、この実施例では、動作モードが自動モードに設定されている場合には、操作者の動作に関係無く、アバターの画像の全部を自動生成するようにしたが、アバターの画像の一部を自動生成するようにしてもよい。たとえば、自動モードにおいては、アバターの手腕の動きを自動生成し、顔の表情および動きは、操作者の顔の表情および動きに従って制御されてもよい。かかる場合であっても、操作者は、利用者と対話しながら手だけ他の作業を行うことができる。
【0238】
また、アバターの画像を自動生成する場合(自動モード)に加え、一部の画像を自動生成する場合（半自動モード）を設けることで、実施例で示した所定の形状が検出された場合には、自動モードに切り替え、他のジェスチャ（たとえば、他の所定の形状）が検出された場合には、半自動モードに切り替えるようにすることもできる。この場合、半自動モードにおいて、他の所定の形状が検出されると、手動モードに切り替えられる。
【0239】
また、この実施例では、操作者側端末でアバターの画像データを生成するようにしたが、利用者側端末でアバターの画像データを生成するようにしてもよい。かかる場合には、操作者側端末は撮影画像のデータを利用者側端末に送信し、利用者側端末は、撮影画像のデータを取得して、図１５－図１７に示した制御処理および手動モードのアバター画像生成処理も実行する。
【0240】
さらに、上述の各実施例では、利用者と操作者が対話する場合について説明したが、これに限定される必要はない。ウェブ会議またはビデオ通話を行う場合にも適用でき、ウェブ会議またはビデオ通話においてアバターの画像を表示する場合に、対応する人間の撮影画像に基づいてアバターが動作される。
【0241】
さらにまた、上述の各実施例では、起動条件を満たす場合に、アバターの画像を表示するようにしたが、所定のサービスのウェブ画面が表示されるときに、アバターの画像を表示するようにしてもよい。
【0242】
なお、上述の各実施例で示したフロー図の各ステップは同じ結果が得られる場合には、処理する順番を変更することが可能である。
【0243】
また、上述の各実施例で挙げた各種の画面、角度などの具体的数値はいずれも単なる例示であり、必要に応じて適宜変更可能である。
【符号の説明】
【0244】
１０ …情報処理システム
１２ …利用者側端末
１４ …ネットワーク
１６ …操作者側端末
１８ …サーバ
２０、５０ …ＣＰＵ
２２、５２ …ＲＡＭ
２４、５４ …通信Ｉ／Ｆ
２６、５６ …入出力Ｉ／Ｆ
２８、５８ …入力装置
３０、６０ …表示装置
３２、６２ …マイク
３４、６４ …スピーカ
６６ …センサＩ／Ｆ
６８ …カメラ
１２ …利用者側端末
１４ …ネットワーク
１６ …操作者側端末
１８ …サーバ
２０、５０ …ＣＰＵ
２２、５２ …ＲＡＭ
２４、５４ …通信Ｉ／Ｆ
２６、５６ …入出力Ｉ／Ｆ
２８、５８ …入力装置
３０、６０ …表示装置
３２、６２ …マイク
３４、６４ …スピーカ
６６ …センサＩ／Ｆ
６８ …カメラ
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】