特開 2022-103490 情報処理装置、情報処理方法、及びコンピュータプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022103490

(43)【公開日】2022-07-08

(54)【発明の名称】情報処理装置、情報処理方法、及びコンピュータプログラム

(51)【国際特許分類】

   H04M 11/00 20060101AFI20220701BHJP

【ＦＩ】

H04M11/00 302

【審査請求】未請求

【請求項の数】8

【出願形態】ＯＬ

(21)【出願番号】P 2020218157

(22)【出願日】2020-12-28

(71)【出願人】

【識別番号】390002761

【氏名又は名称】キヤノンマーケティングジャパン株式会社

(71)【出願人】

【識別番号】592135203

【氏名又は名称】キヤノンＩＴソリューションズ株式会社

(74)【代理人】

【識別番号】100189751

【弁理士】

【氏名又は名称】木村 友輔

(72)【発明者】

【氏名】佐野 彰彦

【テーマコード（参考）】

5K201

【Ｆターム（参考）】

5K201BA05

5K201BD02

5K201BD04

5K201CA01

5K201CC02

5K201DC05

5K201EC06

5K201ED05

5K201ED07

5K201EF03

5K201EF10

5K201FA02

(57)【要約】

【課題】 発信側と着信側の音声データをテキスト化し、テキスト化した両者の音声データの結果を比較することで、ネットワークやＷｅｂ－ＲＴＣによるデータの遅延や劣化を判断し、ユーザに通知することが可能となる技術を提供する。
【解決手段】コミュニケーション画面を有する情報処理装置において、音声データの入力を受け付けて、受け付けた音声データが遅延若しくは劣化しているかを判定して、判定結果に対応する通知を行う。
【選択図】 図４

【特許請求の範囲】

【請求項1】

コミュニケーション画面を有する情報処理装置であって、
音声データの入力を受け付ける入力手段と、
前記入力手段によって入力を受付けた音声データをテキスト化する作成手段と、
前記作成手段によって作成された送信側と受信側の音声テキストデータを比較する比較手段と、
前記比較手段での比較結果に基づいて、遅延及び劣化が発生しているか否かを判定する判定手段と、
を備えることを特徴とする情報処理装置。

【請求項2】

前記情報処理装置は、
前記判定手段による判定結果に対応する通知を行う通知手段と、
を備えることを特徴とする請求項１に記載の情報処理装置。

【請求項3】

前記判定手段は、送信側の音声テキストデータと受信側の音声テキストデータの一致度を比較することで遅延及び劣化が発生しているかを判定することを特徴とする請求項１または２に記載の情報処理装置。

【請求項4】

前記判定手段は、送信側の音声テキストデータと受信側の音声テキストデータの一致度に応じて、遅延の度合い及び劣化の度合いを判定することを特徴とする請求項１乃至３に記載の情報処理装置。

【請求項5】

前記通知手段は、前記判定手段により判定された遅延の度合い及び劣化の度合いに対応する通知を行うことを特徴とする請求項１乃至４に記載の情報処理装置。

【請求項6】

前記通知手段は、遅延若しくは劣化が発生している旨を前記コミュニケーション画面に重畳表示することを特徴とする請求項１乃至５に記載の情報処理装置。

【請求項7】

コミュニケーション画面を有する情報処理装置の制御方法であって、
前記情報処理装置は、
音声データの入力を受け付ける入力ステップと、
前記入力ステップによって入力を受付けた音声データをテキスト化する作成ステップと、
前記作成ステップによって作成された送信側と受信側の音声テキストデータを比較する比較ステップと、
前記比較ステップでの比較結果に基づいて、遅延及び劣化が発生しているか否かを判定する判定ステップと、
を実行することを特徴とする情報処理装置。

【請求項8】

コミュニケーション画面を有する情報処理装置を、
音声データの入力を受け付ける入力手段と、
前記入力手段によって入力を受付けた音声データをテキスト化する作成手段と、
前記作成手段によって作成された送信側と受信側の音声テキストデータを比較する比較手段と、
前記比較手段での比較結果に基づいて、遅延及び劣化が発生しているか否かを判定する判定手段と、
して機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、音声解析・リアルタイムコミュニケーションに関する。

【背景技術】

【0002】

離れた場所同士でのコミュニケーションを行うためのシステムは広く存在してきており、例えば、工事現場において、現場の作業者は、スマートフォンやタブレット等の情報処理端末を用いて、遠隔地にいる監督者やオペレーターとコミュニケーションを行いながら、作業を行うことができるようになってきている。
お互いの映像や音声を送信することで、コミュニケーションを行うが、通信環境によっては、映像や音声データの遅延や劣化が発生することがある。この遅延や劣化に対応する為に、音声をテキスト化することで円滑にコミュニケーションを図ろうとする技術がある。例えば、特許文献１や特許文献２である。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０２０－８８８１８号公報

【特許文献2】特表２０１６－５２９８３９号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

特許文献１には、発信端末と着信端末との間の通話をテキストに変換して、変換されたテキストを発信端末および着信端末に表示させることにより、通話内容のテキストを一致させる音声テキスト化技術が開示されている。
特許文献２には、音声通信において、通信チャネルが混雑している際に音声データではなくデータサイズの小さいテキストに変換することでコミュニケーションを維持する技術が記載されている。

【0005】

しかしながら、特許文献１に記載の発明では、発信側と着信側の双方の間で通話内容のテキストを一致させるだけであり、また、特許文献２に記載の発明においても、通信チャネルが混雑している際に音声データではなくデータサイズの小さいテキストに変換することでコミュニケーションを維持することは出来るが、コミュニケーションをとっている当人同士において、どの程度のネットワークやＷｅｂ－ＲＴＣによるデータの劣化が発生しているのかを知ることはできない。

【0006】

音声をテキスト化することで、音声データが遅延する場合でもどのような内容を話したかは表示される音声テキストを確認することが出来るが、実際にどの程度、音声データの遅延が発生しているかは把握することが出来ない。
例えば、コミュニケーションの相手に映像内の様子を基に話をする場合、どの程度の音声データの遅延が発生しているかが不明であると、コミュニケーションの相手に、映像内のどの点について話をしているのが伝わらず、ディスコミュニケーションになってしまう。

【0007】

本発明は、上記問題を鑑みて成されたものであり、音声を含むコミュニケーションにおいて、データの遅延や劣化の状況を認識できる仕組みを提供することを目的とする。

【課題を解決するための手段】

【0008】

上記、課題を解決するための本発明は、コミュニケーション画面を有する情報処理装置であって、音声データの入力を受け付ける入力手段と、入力手段によって入力を受付けた音声データをテキスト化する作成手段と、作成手段によって作成された送信側と受信側の音声テキストデータを比較する比較手段と、比較手段での比較結果に基づいて、遅延及び劣化が発生しているか否かを判定する判定手段とを備えることを特徴とする。

【発明の効果】

【0009】

本発明によれば、音声を含むコミュニケーションにおいて、データの遅延や劣化の状況を認識することが可能となる。

【図面の簡単な説明】

【0010】

【図1】本発明の実施形態における、コミュニケーションシステムの全体構成の一例を示す図である。

【図2】スマートフォン１０１、タブレット端末１０２、クライアントＰＣ１１１等のハードウェア構成の一例を示す構成図である。

【図3】Ｗｅｂ－ＲＴＣシステムを使用した音声コミュニケーションシステムの音声送受信の概要を示すシーケンス図である。

【図4】本発明の実施形態における、話し手と聞き手間で行われるクライアントのコミュニケーション処理の一例を示すフローチャート図である。

【図5】図４のコミュニケーション処理ループ内のコミュニケーション中の処理のフローを示す図である。

【図6】図５のコミュニケーション中の処理のフロー内の遅延判断登録処理のフローを示す図である。

【図7】本発明の実施形態における、遅延判断システムの遅延判断受付通知処理の一例を示すフローチャート図である。

【図8】図７の遅延判断受付通知処理内の遅延判断処理の一例を示すフローチャート図である。

【図9】本発明の実施形態における、遅延判断システムのデータの保持形態の一例を示す図である。

【図10】本発明の実施形態における、モバイルコミュニケーションアプリケーションの通常時の画面構成イメージ図である。

【図11】本発明の実施形態における、ユーザ１（自分）が遅延している場合のモバイルコミュニケーションアプリケーションの画面構成イメージ図である。

【図12】本発明の実施形態における、ユーザ２（コミュニケーションの相手側）が遅延している場合のモバイルコミュニケーションアプリケーションの画面構成イメージ図である。

【図13】本発明の実施形態における、ＰＣコミュニケーションアプリケーションの通常時の画面構成イメージ図である。

【図14】本発明の実施形態における、ユーザ１（自分）が遅延している場合のＰＣコミュニケーションアプリケーションの画面構成イメージ図である。

【図15】本発明の実施形態における、ユーザ２（コミュニケーションの相手側）が遅延している場合のＰＣコミュニケーションアプリケーションの画面構成イメージ図である

【発明を実施するための形態】

【0011】

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

【0012】

図１は、ユーザ同士のコミュニケーションをとり、音声のテキスト化による遅延判断による通知表示を行うモバイルコミュニケーションアプリケーション（以下モバイルアプリ）、ＰＣコミュニケーションアプリケーション（以下ＰＣアプリ）および、クラウドでコミュニケーションを制御するコミュニケーションシステムサーバおよび、遅延判断を行う遅延判断システムサーバおよび、音声を文字テキストに変換するＳｐｅｅｃｈＴｏＴｅｘｔシステムサーバの全体構成の一例を示す図である。本実施例においてはクラウド上に構成されるものとして説明するが、クラウド上に構成されなくてもよい。
ユーザ同士とは、コミュニケーションを実行する話し手側と聞き手側のことである。

【0013】

説明の便宜上、以後、コミュニケーションを実行する話し手側をユーザ１、話し手側のコミュニケーションを受ける聞き手側をユーザ２として、説明する。
尚、本説明では便宜上、話し手側、聞き手側としているが、両者の立場を入れ替えてコミュニケーションを行うことは勿論、可能である。

【0014】

コミュニケーションを行うユーザ１は、モバイルアプリ１００をスマートフォン１０１やタブレット端末１０２にインストールすることで、スマートフォン１０１やタブレット端末１０２でモバイルアプリ１００を使用することが出来る。

【0015】

モバイルアプリ１００は、インターネット１３０を介して、クラウドシステム１２０のコミュニケーションシステムサーバ１２１、遅延判断システムサーバ１２２、ＡＩ／ＤＬ ＳｐｅｅｃｈＴｏＴｅｘｔシステムサーバ１２３、及びユーザ２のクライアントＰＣ上のＰＣコミュニケーションアプリケーションと接続される構成となっている。

【0016】

コミュニケーションを行うユーザ２には、ＰＣアプリ１１０と、クライアントＰＣ１１１がある。ＰＣアプリ１１０は、クライアントＰＣ１１１にインストールすることで、ＰＣ上で動作する。ＰＣアプリは、インターネット１３０を介して、クラウドシステム１２０のコミュニケーションシステムサーバ１２１、遅延判断システムサーバ１２２、ＡＩ／ＤＬ ＳｐｅｅｃｈＴｏＴｅｘｔシステムサーバ１２３、及びユーザ１のスマートフォン１０１やタブレット端末１０２上のモバイルアプリと接続される構成となっている。

【0017】

上記実施例では、ユーザ１がモバイルアプリ、ユーザ２がＰＣアプリを使用する例として記載しているが、コミュニケーションの中では、話し手側のユーザ、聞き手側のユーザが逆になることが可能なアプリケーションである。また、組み合わせがモバイルアプリ同士、ＰＣアプリ同士であっても同様の仕組みで動くものである。また、１対１のコミュニケーションの例を記載しているが、複数人によるコミュニケーションであっても同様の仕組みで動作することを可能とするものである。

【0018】

クラウドシステムには、コミュニケーションシステムサーバ１２１と、遅延判断システムサーバ１２２、ＡＩ／ＤＬ ＳｐｅｅｃｈＴｏＴｅｘｔシステムサーバ１２３で構成されている。それぞれのサーバはインターネット１３０を介して接続される構成となっている。

【0019】

データ１４０には、音声データ１４１、音声テキストデータ１４２、遅延判断結果データ１４３がある。音声データは、入力デバイスからインプットされた音声ストリーミングデータのことである。音声テキストデータは、音声データを変換し、テキストデータとして扱えるようにしたものである。遅延判断結果データは、音声テキストデータやそのデータのタイムスタンプを比較し、遅延判断を行った結果のデータであり、遅延判断管理テーブル９２０で保管するデータである。

【0020】

上記は、音声をコミュニケーションとして伝える説明をしているが、音声に加えて映像を一緒にやり取りできる一般的なコミュニケーションシステムの例である。
以上で図１の説明を終了する。

【0021】

次に図２を参照して、本発明の実施形態におけるクライアント端末に適用可能なハードウェア構成の一例について説明する。

【0022】

図２において、２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。

【0023】

２０３はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは外部メモリ２１１からＲＡＭ２０３にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。

【0024】

また、２０５は入力コントローラで、入力デバイス２０９からの入力を制御する。入力デバイス２０９としては、キーボード、タッチパネル、及びマウス等のポインティングデバイス等が挙げられる。

【0025】

なお、入力デバイス２０９がタッチパネルの場合、ユーザがタッチパネルに表示されたアイコンやカーソルやボタンに合わせて押下（指等でタッチ）することにより、各種の指示を行うことができることとする。

【0026】

また、タッチパネルは、マルチタッチスクリーンなどの、複数の指でタッチされた位置を検出することが可能なタッチパネルであってもよい。

【0027】

２０６はビデオコントローラで、ディスプレイ２１０等の表示機への表示を制御する。なお、ディスプレイ２１０は、ＣＲＴ、液晶ディスプレイ等の表示機のことを指す。または、その他の表示機であってもよい。

【0028】

尚、本体と一体になったノート型パソコンのディスプレイも含まれるものとする。外部出力装置はディスプレイに限ったものははく、例えばプロジェクタであってもよい。

【0029】

また、図２のハードウェア構成を適用する装置が前述のタッチ操作を受け付け可能な装
置である場合には、ディスプレイ２１０が入力デバイス２０９としての機能を提供する。

【0030】

２０７はメモリコントローラで、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤＤ）や、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

【0031】

２０８は通信Ｉ／Ｆコントローラで、ネットワークを介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。

【0032】

なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォント展開（ラスタライズ）処理を実行することにより、ディスプレイ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ディスプレイ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

【0033】

本発明を実現するための後述する各種プログラムは、ＲＯＭ２０２あるいは外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。

【0034】

さらに、上記プログラムの実行時に用いられる定義ファイル及び各種情報、テーブル等も、外部メモリ２１１に格納されており、これらについての詳細な説明も後述する。

【0035】

カメラコントローラ２１２は、カメラ２１４等による映像取得を制御し、音声コントローラ２１３はマイク／スピーカ２１５等による音声取得制御やスピーカへの出力を制御する。

【0036】

カメラ２１４は、図２のハードウェア構成を適用する装置に内蔵されているカメラである。また、マイク／スピーカ２１５は、図２のハードウェア構成を適用する装置に内蔵されているマイク及びスピーカである。以上で図２の説明を終了する。

【0037】

次に図３を用いて、Ｗｅｂ－ＲＴＣシステムなどの一般的なコミュニケーションシステムにおける音声の送受信処理について説明する。以下に簡単に説明をする。

【0038】

ステップＳ３０１では、話し手による発話を検出する。

【0039】

ステップＳ３０２では、ステップＳ３０１で検出した発話内容を音声データとして取得する。

【0040】

ステップＳ３０３では、モバイルアプリが、マイクによって取得された音声データをクラウド上のＷｅｂ－ＲＴＣシステムにＷｅｂ－ＲＴＣの音声データとして送信する。

【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】

その際に、ステップＳ６０３では、リクエストデータとして、ＡＰＩキー、音声データを要求する。

【0067】

ステップＳ６０４では、ＳｐｅｅｃｈＴｏＴｅｘｔシステムからの受信結果の音声テキストデータを遅延判断システムに送信する。ステップＳ６０４の処理は、音声データをテキスト化した音声テキストデータを遅延判断システムに送信することで、遅延判断システムに音声データを解析させるために行う。ステップＳ６０４では、リクエストデータとして、コミュニケーションＩＤ、音声テキストデータ、登録者、送信側か受信側かの情報、発言者、発言時間、登録時間を要求する。

【0068】

SpeechToTextは、既知の技術であり、取得した音声データから音声データの特徴を求めたのち、言語処理解析をして、音声データの内容をテキストとして、書き起こす技術である。

【0069】

ステップＳ６０１で文区切りにしたすべての音声データに対してＳ６３、Ｓ６０４の処理が終了すると、図６に示す遅延判断登録処理は終了となる。

【0070】

ステップＳ５０３まで処理が終了すると、コミュニケーション中の処理を終了して、ステップＳ４０９へ進む。

【0071】

ステップＳ５１１では、映像音声デバイスからユーザ１（自身）入力データの音声データを取得する。

【0072】

ステップＳ５１２では、音声データを遅延判断登録処理にインプットする。

【0073】

ステップＳ５１３では、ステップＳ５１２でインプットした音声データに対して、遅延判断登録処理を行う。前述のステップＳ５０３で行われる処理と同様の処理である。
ステップＳ５１３まで処理が終了すると、コミュニケーション中の処理を終了して、ステップＳ４０９へ進む。

【0074】

ステップＳ５２１では、遅延判断システムから遅延通知が届くまで受信待ちする。ステップＳ５２１の遅延判断システムから通知を受信する処理において、コミュニケーション中は、常に遅延判断システムから通知を受信できる状態で待機している。

【0075】

ステップＳ５２２では、遅延通知が届いたかを判定する。遅延通知が届いた場合（判定結果がＹｅｓであった場合）は、ステップＳ５２３に処理を進める。遅延通知が届いていない場合（判定結果がＮｏであった場合）は、ステップＳ５２１に戻り、通知が届くまで待機する。

【0076】

ステップＳ５２３では、遅延通知を受信するとクライアントアプリはクライアント端末上の画面に通知内容を表示し、ユーザに遅延通知を行う。これによりユーザは自分の音声が実際にどれだけ遅延や劣化して相手に伝わっているかを理解することができ、遅延や劣化を考慮したコミュニケーションを行うことで相手とのコミュニケーションを円滑に行うことができる

【0077】

ステップＳ５２３まで処理が終了すると、コミュニケーション中の処理を終了して、ステップＳ４０９へ進む。

【0078】

ステップＳ４０９では、ログアウト指示を受け付ける。

【0079】

ステップＳ４１０では、アプリで終了指示を受け付ける。

【0080】

以上で図５のコミュニケーション中の処理のフローチャートの説明を終了する。

【0081】

続けて、図７を用いて遅延判断受付通知の説明を行う。図７では、遅延判断システムの遅延判断のための全体動作フローの説明を行う。

【0082】

ステップＳ７０１では、遅延判断システムは、ステップS６０４でクライアントアプリから送信された遅延判断登録要求を受付ける。

【0083】

ステップＳ７０２では、受け付けた遅延判断登録内容を図９に示す音声テキスト管理テーブル９００に格納する。音声テキスト管理テーブル９００は、遅延判断登録内容であるテキストＩＤ９０１と、コミュニケーションＩＤ、音声テキストの登録者である登録者９０３、送信であるか受信であるかを管理する送受信９０４、音声の発言者が誰であるかを管理する音声の発言者９０５、発言していた時間を管理する９０７、音声のテキストデータを管理する場所であるテキストデータ９０８を管理するテーブルである。

【0084】

ステップＳ７０３では、上記の音声テキスト管理テーブルに登録された内容に基づいて、受信した遅延判断登録内容が送信側であるか受信側であるかの判定を行う。受信した登録内容が送信側であればステップＳ７０４に進み、クライアントに遅延判断の登録完了を意味する登録成功のレスポンスを送信して、本処理を終了する。

【0085】

ステップＳ７０３の処理は、遅延判断を行う為には送信側と受信側の両方のデータが揃う必要がある。理論的に送信側が先に届くことから、遅延判断は受信側の登録時に実施するため、どちらの登録内容であるかを判断する。登録内容が受信側であれば、ステップＳ７０５に進め、遅延判断処理を行う。

【0086】

ステップＳ７０５で行う遅延判断処理について、図８を用いて説明する。上述の通り、遅延判断は受信側の登録時に実施するため、ステップＳ７０５のタイミングで行う。

【0087】

ステップＳ８０１では、音声テキスト管理テーブル９００から登録内容に含まれる音声テキストデータに該当する送信側が登録したデータの候補を検索する。検索する為の条件は、コミュニケーションＩＤ９０２の人物と音声の発言者９０５が同じ人物であること、発言時間及び登録時間がリクエストデータの登録内容と比較して６０秒以内であることを条件に検索する。

【0088】

この条件は、コミュニケーション相手が同じ内容を復唱したり、少し前に話した内容と同じことをもう一度繰り返し話したりした際に、復唱した内容や繰り返して話した内容を遅延していると判定させないために、採用している。勿論、実際の運用状況に合わせて、適宜検索条件は変更してよい。

【0089】

ステップＳ８０２では、候補の音声テキストデータに対して全文検索をすることで、音声テキスト管理テーブル９００に送信側が登録したデータを特定する。

【0090】

具体的には、検索した結果、ヒットした候補の音声テキストデータに対して、受信側の音声テキストデータをキーにした検索エンジンによる全文検索を行い、送信側の音声テキストデータを検索する。この処理により音声テキスト管理テーブル９００に事前に登録していた送信側の登録データを特定する。

【0091】

ステップＳ８０３では、送信側の登録データと受信側の登録データの発言時間の差分からコミュニケーションの遅延判断を行う。

【0092】

具体的には、送信側の登録データの発言時間とクライアントからの要求に含まれる受信側の発言時間を比較し、差分からコミュニケーションの遅延判断を行う。差分が１秒未満の場合は遅延なしと判断し、１～５秒以内の場合は遅延小、６～１０秒以上の場合は遅延中、１０秒以上の場合は遅延大と判断する。この遅延レベルの評価の結果が各クライアントの端末上でポップアップとして表示される。例えば、図１１に示す１１０１や図１２に示す１２０１、図１４に示す１４０１、図１５に示す１５０１などのように表示される。

【0093】

ステップＳ８０４では、送信側の登録データと受信側の登録データの発言内容の差分からコミュニケーションの劣化判断を行う。

【0094】

具体的には、送信側の登録データの音声テキストデータとクライアントからの要求に含まれる受信側の音声テキストデータを比較し、一致度からコミュニケーションの劣化判断を行う。一致度が９５％以上の場合は劣化なしと判断し、９０～９５％の場合は劣化小、８０～９０％の場合は劣化中、８０％より低い場合は劣化大と判断する。この劣化レベルの評価の結果が各クライアントの端末上でポップアップとして表示される。例えば、図１１に示す１１０１や図１２に示す１２０１、図１４に示す１４０１、図１５に示す１５０１などのように表示される。

【0095】

ステップＳ８０５では、解析結果である遅延判断と劣化判断を図９に示す遅延判断管理格納テーブル９２０の解析結果（結果）９２３、解析結果（劣化）９２４にそれぞれ格納する。

【0096】

遅延判断管理テーブル９２０は、コミュニケーションＩＤを管理するコミュニケーションＩＤ９２１、音声の発言者を管理する音声の発言者９２２、遅延判断の解析結果を管理する解析結果（遅延）９２３、劣化判断の解析結果を管理する解析結果（劣化）９２４、更新された日時を管理する更新日時９２５、撮影された日時を管理する撮影日時９２６を管理するテーブルである。

【0097】

ステップＳ８０６では、遅延若しくは劣化が発生したと判断した場合は、クライアントアプリに遅延若しくは劣化が発生した旨の通知を行う。遅延、劣化が発生したデータと同じコミュニケーションＩＤのデータを音声テキスト管理テーブル９００から検索して、ヒットしたデータの登録者全員に対して遅延若しくは劣化の内容を含む通知イベントを送信する。
モバイルアプリであれば、図１１や図１２のように表示し、ＰＣアプリであれば図１４や図１５のように表示される。
以上が、図８で行われる遅延判断処理の内容である。

【0098】

上述のステップＳ７０５の遅延判断処理が終了すると、ステップＳ７０６の処理へ移行する。
ステップＳ７０６では、クライアントに登録成功のレスポンスを送信する。
以上で図７の遅延判断受付通知の処理は終了する。

【0099】

続けて、図１０を用いて、通常のモバイルアプリのコミュニケーション画面構成イメージについて、説明する。通常のコミュニケーション画面１０００は、カメラを作動し、ルームに入室している際のものである。

【0100】

１００１のアイコンは、スマートフォンを利用して、ルームに入室しているユーザの数を示している。

【0101】

１００２のアイコンは、ＰＣを利用して、ルームに入室しているユーザの数を示している。

【0102】

１００３のアイコンは、カメラのシャッターボタンと、ビデオの撮影開始、ビデオの撮影終了等の処理を指示する操作部である。

【0103】

１００４のアイコンは、カメラモードを示すアイコンである。１００４のカメラアイコンが黄色で色付けされている場合は、カメラモードで撮影されていることを示す。

【0104】

１００５のアイコンは、ビデオモードを示すアイコンである。１００５のビデオアイコンが黄色で色付けされている場合は、ビデオモードで撮影されていることを示す。

【0105】

１００６は、現在ユーザがどのルームに入室しているかが確認できる表示である。
この場合であれば、ルームＡ２に入室していることが分かる。以上で、図１０の説明を終了する。

【0106】

図１１を用いて、ユーザ１（自身）が遅延している場合のモバイルアプリのコミュニケーション画面の画面構成イメージを説明する。

【0107】

ユーザ１（自身）において、コミュニケーションの遅延や劣化が発生すると、１１０１のようなポップアップが通常のコミュニケーション画面に重畳表示される。

【0108】

ポップアップ１１０１では、遅延が発生していることを通知する。そして、遅延レベルと劣化レベルを表示する。また、コミュニケーションの相手方が、ユーザ１（自身）の音声を聞き取りづらくなっていることを通知する。

【0109】

これにより、ユーザ１（自身）は、現在相手方とのコミュニケーションの間で音声データ、映像データの遅延、劣化が発生していることが瞬時に把握できる。

【0110】

また、ユーザ（自身）は、自分の音声が実際にどれだけ遅延や劣化しているかを理解することができ、遅延や劣化を考慮したコミュニケーションを行うことで相手方とのコミュニケーションを円滑に行うことができる。以上で図１１の説明を終了する。

【0111】

続けて、図１２を用いて、ユーザ２（コミュニケーションの相手方）が遅延している場合のモバイルアプリのコミュニケーション画面の画面構成イメージを説明する。

【0112】

ユーザ２（コミュニケーションの相手方）において、コミュニケーションの遅延や劣化が発生すると、１２０１のようなポップアップが通常のコミュニケーション画面に重畳表示される。

【0113】

ポップアップ１２０１では、遅延が発生していることを通知する。そして、遅延レベルを表示する。１２０１のポップアップでは「小」が表示されている。

【0114】

相手が遅延している場合は、実際に音声の劣化が聞いてわかるので、ポップアップ１２０１には、劣化レベルの表示は不要である。

【0115】

また、ユーザ２（コミュニケーションの相手方）のコミュニケーション相手であるユーザ１が劣化に気づいていない可能性がある旨の通知と、遅延を考慮した会話を実施するように促すメッセージを表示する。

【0116】

これにより、ユーザ２は、現在相手方とのコミュニケーションの間で音声データ、映像データの遅延が発生していることが瞬時に把握できる。

【0117】

また、遅延を考慮したコミュニケーションを行うことで、相手方とのコミュニケーションを円滑に行うことが出来る。以上で図１２の説明を終了する。

【0118】

続けて、図１３を用いて、通常のＰＣアプリのコミュニケーション画面の画面構成イメージを説明する。１３００がＰＣアプリのコミュニケーション全体の画面である。

【0119】

１３０１では、コミュニケーションを行うルームを選択することが出来る。

【0120】

１３０２は、ユーザが選択することで、拡大して映像を観ることが可能な画面である。
勿論、ユーザが選択しなくとも一定のタイミングで１３０２の画面に表示される映像が切り替わるようにしてもよい。

【0121】

１３０３、１３０４、１３０５、１３０６はルームに参加する各ユーザから送られてくる映像を表示する領域である。各領域には、ユーザから送られてくる映像と、どのユーザからの映像なのかが分かるようにユーザ名が表示される。

【0122】

ＰＣ上での操作を行うユーザが、ルームに参加しているユーザが送ってくる映像を表示する画面右側の１３０３、１３０４、１３０５、１３０６の領域のうち、いずれかを選択すると、ユーザが選択した領域に表示される映像が、１３０２の画面に拡大して表示される。

【0123】

図１３の例であると、ユーザは１３０５を選択したので、１３０２には、１３０５の領域に映されていた映像を拡大して表示する。ユーザが１３０５を選択すると、１３０５に表示されていた映像が１３０２に移って、表示されていることをメッセージで示す。この場合、ＶＩＥＷと表示される。

【0124】

１３０７は、カメラモードを選択するためのアイコンである。そして、カメラモードを選択すると、画面に表示されている映像をスクリーンショットで撮ることや、ＰＣに内蔵若しくは外部から接続されたカメラを利用して、写真を撮ることが出来る。

【0125】

１３０８は、ビデオモードを選択するためのアイコンである。ビデオモードを選択すると、ビデオの撮影が開始する。画面自体を映像として撮影することも可能であり、また内蔵若しくは外部から接続されたカメラを利用して、ユーザの顔や身体を含む映像を撮ることも可能である。これにより、ジェスチャーなどでもコミュニケーションが可能となる。

【0126】

１３０９は、写真一覧のアイコンである。写真一覧のアイコンを押下すると、撮った写真を確認することができる。

【0127】

１３１０は、画面キャプチャー共有のアイコンである。画面キャプチャー共有のアイコンを押下すると、ユーザがキャプチャーした画面をルームに参加する他のユーザに共有することが出来る。以上で図１３の説明を終了する。

【0128】

図１４は、ユーザ１（自分）が遅延している場合のＰＣアプリのコミュニケーション画面である。

【0129】

１４０１のようなポップアップ形式で、遅延が発生している旨の通知と、遅延レベルと劣化レベルを表示し、音声が聞き取りにくくなっていることを通知する。

【0130】

これにより、現在相手方とのコミュニケーションの間で音声データ、映像データの遅延が発生していることが瞬時に把握できる。以上で図１４の説明を終了する。

【0131】

図１５は、ユーザ２（コミュニケーションの相手方）が遅延している場合のコミュニケーション画面である。

【0132】

遅延が発生しているコミュニケーションの相手方が存在する場合は、１５００のように通知バーを表示して、遅延が発生していることを通知する。通知バー１５００にマウスオーバーすることで、１５０１のようなポップアップのイメージが表示されます。

【0133】

モバイルアプリと同様に、相手が遅延しているかどうかは実際に音声を聞いて分かるので劣化レベルについては表示しない。以上で図１５の説明を終了する。

【0134】

以上、本発明について説明したが、本発明によって、発信側と着信側の音声データをテキスト化し、テキスト化した両者の音声データの結果を比較の上、ネットワークやＷｅｂ－ＲＴＣによるデータの遅延や劣化を判断して、ユーザに通知することが可能となる。

【0135】

これにより、遅延や劣化が発生しているコミュニケーションにおいて、ユーザ同士でお互いの遅延や劣化の状況を把握、考慮しながらコミュニケーションが出来るので、ユーザの煩わしさが軽減できる。

【0136】

従来であれば、ユーザ１（自身）は、相手に自分の声が伝わっているか判断できず、また、自分の声が伝わっているとしても遅延が発生している場合にどの程度の遅延が発生しているのかまでは判断できなかった。しかしながら、本発明によって遅延や劣化の具合がユーザに通知されることで、発言をする側はゆっくり話す、文章を区切って話すなどの工夫をすることが出来る。また、遅延があることを想定しながら発言を行うことが出来るので、発言が被ることが少なくなる。

【0137】

以上、本願の実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

【0138】

また、本発明におけるプログラムは、図４に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体は図４の処理方法をコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは図１の各装置の処理方法ごとのプログラムであってもよい。

【0139】

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。

【0140】

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。

【0141】

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＣＤ－Ｒ、ＤＶＤ－ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。

【0142】

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

【0143】

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

【0144】

また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適用できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

【0145】

さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

【符号の説明】

【0146】

１００ モバイルコミュニケーションアプリケーション
１１０ ＰＣコミュニケーションアプリケーション
１２０ クラウドシステム
１３０ インターネット

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】