JP2019530546A - 音響信号の聴取試験および変調 - Google Patents

Abstract

通信ネットワーク内のネットワークエンティティとユーザーが有するユーザー装置との間に確立された通信リンクを介してユーザーに対して聴取試験を行い、聴取試験が、通信リンクを介してユーザー装置に複数種の試験周波数にて聴覚刺戟を与えることと、ユーザー装置から受信した聴覚刺戟に対する応答を監視することとを含むステップと、聴取試験の結果に基づいて聴取プロファイルを生成するステップと、聴取プロファイルおよびユーザーに関連する情報をネットワークエンティティ内のメモリーに保存することでユーザー装置への音響信号の変調のために前記聴取プロファイルを利用可能とするステップとを含む方法。

Description

本開示は聴取試験に関する。本開示はまた、当該聴取試験の結果を用いて、発話や音楽などといった音響信号を変調することにも関する。特には、携帯電話通信網などの通信網を介する音響信号を強調することで、対処可能な難聴や何らかの必要に応じて、人々へ与える音響信号を拡張することに適しているが、それに限定する意図は無い。

携帯機器や固定機器（携帯電話や固定電話など）を介した音響拡張をするための現行のソリューションでは、ソフトウェアアプリケーションを提供しており、これを典型的なユーザー装置に読み込ませるか実装するようにして、携帯端末や固定端末上で補聴器をシミュレートしている。こうしたシミュレートとしては例えば、デジタル技術をユーザー装置のローカル処理に使い、軽度の難聴から重度の難聴までを患う人々のための補聴器をエミュレートするものがある。しかしこの手法では、専門家による処置や医療施術が必要になるような重篤な難聴から極めて重篤な難聴に対しては不適切である。またその他のソリューションとしては、複雑な装置付属品を携帯装置へのアドオンとして与えて、このアドオンを軽度から重度の難聴の人の為の補聴器もしくはインプラントと置換したりあるいはそれらと協働させたりする手法もある。

しかしこうしたソリューションでは、ユーザー装置および／または付加的ハードウェアもしくはファームウェアのための処理電力が必要になってしまう。

したがって、中央システムが（ネットワークレベルなどで）実施できる音響拡張の利便性への需要があるわけである。すなわち、そうした音響拡張であればユーザー装置にとって透過的なので、任意のユーザー装置（携帯電話、固定電話、もしくはスタンドアロン型スピーカーその他の通信手法であってよい）の上で実施したり任意のユーザー装置へ与えたりできる。しかも、処理電力とローカルリソースが嵩むような高性能エンドユーザー装置に頼る必要もない。さらには、装置付属品が必須でなくなり、ハードウェアやファームウェア要件が軽くなると、音響拡張をさらに多くのユーザーで利用できるようにもなると考えられるし、また実装コストやエネルギー消費も減らせるので、音響拡張がより広汎なユーザー層に訴求できるようにもなってくるであろう。

或る態様では、以下を含む方法が提供され、すなわち、
通信ネットワーク内のネットワークエンティティと、ユーザーが有するユーザー装置との間に確立された通信リンクを介して、ユーザーに対して聴取試験を行い、前記聴取試験が、前記通信リンクを介して前記ユーザー装置に複数種の試験周波数にて聴覚刺戟を与えることと、前記ユーザー装置から受信した前記聴覚刺戟に対する応答を監視することとを含むステップと、
前記聴取試験の結果に基づいて、聴取プロファイルを生成するステップと、
前記聴取プロファイルおよび前記ユーザーに関連する情報を、ネットワークエンティティ内のメモリーに保存することで、前記ユーザー装置への音響信号の変調のために前記聴取プロファイルを利用可能とするステップと
を含むことを特徴とする方法が提供される。

前記ユーザーに関する情報が、前記ユーザーの識別子、および／または前記ユーザー装置の識別子を含んでもよい。

或る実施形態では、聴取プロファイルを保存するネットワークエンティティが、ユーザー装置との通信リンクを有するネットワークエンティティと同一であってもよい。

或る実施形態では、聴取プロファイルを保存するネットワークエンティティが第二のネットワークエンティティを含んでいて、かつ、ユーザー装置との通信リンクを有するネットワークエンティティが第一のネットワークエンティティを含み、この第一のネットワークエンティティと第二のネットワークエンティティとが互いに通信していてもよい。

或る実施形態では、識別子が唯一識別子を含んでいてもよい。

或る実施形態では、識別子がMSISDNを含んでいてもよい。

聴覚刺戟は白色雑音を含んでいてもよく、その白色雑音が一種以上のヒトの声に基づいていてもよい。

聴覚刺戟が、1/3オクターヴ幅帯域の雑音を含んでいてもよい。

ユーザーに複数種の試験周波数にて聴覚刺戟を与えるに際して、500Hz、1000Hz、2000Hz、3000Hz、6000Hzのうちの二種以上で聴覚刺戟を与えることを含めてもよい。

或る実施形態では、複数種の試験周波数を、ユーザーへ段階的に提供するようにしてもよい。

或る実施形態に係る方法は、聴覚刺戟を行うに先立って、ユーザー装置の時計と、そのユーザー装置との通信リンクを有するネットワークエンティティの時計とを同期するステップを含んでもよい。

また当該方法が、ユーザーの難聴の指標を得るステップと、その難聴の指標を用いて聴取試験の初期音量を決定するステップとを含んでもよい。

また当該方法が、応答の監視に応じて各試験周波数における聴覚刺戟の音量を調節するステップを含んでもよい。

当該方法が、ユーザーからの肯定的応答に対して、聴覚刺戟の音量を下げるステップを含んでもよい。

或る実施形態では、音量を下げる工程に、音量を5dB刻みで下げる工程が含まれていてもよい。

当該方法が、ユーザーから無応答であることに対して、聴覚刺戟の音量を上げるステップを含んでもよい。

或る実施形態では、音量を上げる工程に、音量を10dB刻みで上げる工程が含まれていてもよい。

各聴覚刺戟の期間は、1000msもしくは約1000msであってよい。

各聴覚刺戟が、音量を暗騒音レベルから60dBもしくは約60dBまでのあいだで上げるかまたは下げるような一箇所以上の傾斜を含んでもよい。

当該方法が、ユーザーおよび／もしくはオペレーターに対して、聴取試験の結果を視覚的に表示するステップを含んでもよい。

当該方法が、保存したユーザーの聴取プロファイルを用いて、ユーザーへの音響信号をネットワークエンティティにてリアルタイムに変調し、変調された音響信号がユーザーの有するユーザー装置へと送達されるようにするステップを含んでもよい。

音響信号の変調には、音響信号のフィルタリング、音響信号の振幅調整、音響信号の周波数調整、音響信号の音高および／もしくは音程の調整のうちの一種以上を含んでよい。

或る実施形態では、音響信号の変調を、ネットワークインターフェイスを有する音声処理エンジンによって実行できる。

音響信号の変調が、ユーザーと第二のユーザーとのあいだの通話において、第二のユーザーの音声信号を変調する工程を含んでもよい。

当該方法が、音響信号の変調を行うための設定の選択的な有効化または無効化を行うステップを含んでもよい。

また当該方法が、ユーザー装置が有する一個以上のマイクロホンを用いて周囲騒音を測定するステップと、ユーザー装置との通信リンクを有するネットワークエンティティにてユーザー装置からの周囲騒音情報を受信するステップと、ユーザーのための音響信号の変調に使うために聴取プロファイルを保存するネットワークエンティティにて受信した周囲騒音情報を保存するステップとを含んでもよい。

当該方法が、ユーザー装置へ音響信号を送達するためのチャネル挿入利得を決定するステップを含んでもよい。

或る実施形態では、決定されるチャネル挿入利得がユーザー定義によるものであってもよい。

或る実施形態では、チャネル挿入利得を決定する工程が、利得を動的に変化させる工程を含んでもよい。

当該方法が、音響信号をマルチチャネルに分割するステップを含んでもよい。

或る実施形態では、マルチチャネルが三個もしくは四個のチャネルを有していてよい。

当該方法が、各チャネルの出力レベルを決定するステップを含んでもよい。

或る実施形態では、チャネル挿入利得を決定する工程が、ユーザーパラメータを用いる工程を含んでもよい。

或る実施形態では、ユーザーパラメータには以下のうちの一種以上が含まれてよい。すなわち、ユーザー聴取閾値の初期見積値、ユーザー音量設定の初期値、ユーザーの難聴と聴取閾値の生成に用いる装置の組み合わせ入力パラメータに基づいたユーザーの聴力図もしくは組み合わせデジタル聴取閾値情報、ユーザーの年齢、ユーザーの補聴器情報、ユーザーの性別。

ユーザーへの音響信号の動的圧縮に先立って、チャネル挿入利得の適用を行ってもよい。

或る実施形態では、動的圧縮工程に、各チャネル毎にattackレベルとreleaseレベルを決定する工程を含んでよい。

或る実施形態では、attackレベルが利得信号が最終値に対して安定するまでの時間を含み、かつreleaseレベルが利得信号が最終値に対して安定するまでの時間を含んでよい。

或る実施形態では、動的圧縮をする圧縮器（コンプレッサー）に35dBの変化が適用された際に、attackレベルが利得信号が最終値から3dB以内に安定するまでの時間を含み、かつreleaseレベルが利得信号が最終値から4dB以内に安定するまでの時間を含んでよい。

或る実施形態に係る方法が、ユーザーへ音響信号フレームを伝達するに先立って、音響信号フレームを処理するステップを含み、ここで音響信号フレームの処理には、当該音響信号フレームに有限インパルス応答（FIR）フィルターを適用することを含むようにしてもよい。

或る実施形態には、上述した方法の特徴のいずれかを有する方法を実行するように構成されたサーバを含んでよい。

別の態様では、
ユーザー装置と、通信ネットワーク内のネットワークエンティティとの間に確立された通信リンクを介するユーザーへの聴取試験に参加して、ユーザーの聴取プロファイルを提供し、前記聴取試験が、前記通信リンクを介して前記ユーザー装置が複数種の試験周波数にて聴覚刺戟を受信することと、前記聴覚刺戟への一種以上の応答を前記ネットワークエンティティへ提供することとを含むステップと、
その後に、前記聴取プロファイルに依って変調させた音響信号を、前記ユーザー装置にて受信するステップと
を含む方法も提供できる。

或る実施形態では、この方法を実施するように構成されるユーザー装置も含まれてよい。

また或る態様では、ディスプレイと、複数個のマイクロホンとを含んだユーザー装置も提供できる。或る実施形態では、複数個のマイクロホンが方向集束性を有してよい。

或る実施形態では、ユーザー装置のオペレーティングシステムと通信できるように、マイクロホンが構成されていてもよい。

或る実施形態に係るマイクロホンは、周囲騒音を検知できるように構成されてもよい。

或る実施形態ではユーザー装置が、周囲騒音の情報をネットワークエンティティへ提供するように構成してもよい。

或る実施形態に係るユーザー装置は、コーティングまたは層を有していてもよい。

或る実施形態では、このコーティングまたは層を、アンテナ、および／もしくは誘導ループ、および／もしくはテレコイル（tele-coil）として機能するように構成してもよい。

或る実施形態では、このコーティングまたは層が、バッテリー、および／もしくはプロセッサー、および／もしくはメモリーを含んでいてもよい。

或る実施形態では、このコーティングまたは層が、タグ付け機能および／もしくはIoT機能を有していてもよい。

或る実施形態では、このコーティングまたは層が、ユーザー装置に着脱自在なケースの形態であってもよい。

或る実施形態では、本開示に係る方法と関連させてユーザー装置を使用できる。

別の態様では、第一のユーザーへの音響信号をリアルタイムで拡張するための方法も提供できる。これにより、過度な遅延をすることなくリアルタイム拡張を行うことができる。すなわち、ネットワーク上で第一のユーザーへの音響信号のリアルタイム拡張をするための方法であって、唯一性のある聴取プロファイルにおいて第一のユーザーの聴取の特徴づけを行い、当該聴取プロファイルには所定のパラメータが含まれ、当該パラメータは所定の入力周波数における第一のユーザーの聴取能力から導かれるステップと、聴取プロファイルの所定のパラメータを用いて第一のユーザーへの音響信号をリアルタイムに拡張するステップと、を含む方法が提供される。

音響信号の拡張工程には、第一のユーザーの聴取プロファイルの所定のパラメータに応じて、元の音響信号をフィルタすること、ならびに／または、振幅および／もしくは周波数を調整することを任意に含めてもよい。

また当該方法が、
唯一性のある音声プロファイルにおいて第二のユーザーの声の特徴づけをし、当該音声プロファイルは、第二のユーザーの声の音高および／もしくは音程から導かれる所定のパラメータを含むステップと、
音声プロファイルの所定のパラメータを使って、第一のユーザーへの音響信号をリアルタイムに拡張するステップと
を任意に含んでもよい。

音響信号の拡張工程には、第一のユーザーの聴取プロファイルにより定義される要件に対して、第二のユーザーの声のプロファイルに係る第二のユーザーの声の音高および／もしくは音程をずらすことを任意に含めてもよい。

また当該方法がさらに、
所定の周囲騒音パラメータを含んだ周囲騒音プロファイルにおいて、ネットワークの周囲騒音の特徴づけを行うステップと、
所定の周囲騒音パラメータを用いて、第一のユーザーへの音響信号をリアルタイムに拡張するステップと
を任意に含んでもよい。

所定の周囲騒音パラメータには、信号雑音比（S/N比）、反響、装置の変換器効果、またはデータパケット損失のうちの一種以上を任意に含めてよい。

また任意に、ネットワーク独立インターフェイスを含んだ音声処理エンジンによって、音響信号処理を実行してもよい。

このネットワーク独立インターフェイスには、パラメータデータベースを備える第一のインターフェイスと、音響信号をリアルタイムに傍受して拡張するための音響信号データパケットインターフェイスを備える第二のインターフェイスとを任意に含めてもよい。

第二のインターフェイスがRTPインターフェイスを任意に含んでいてもよい。

また任意に、音声処理エンジンがサーバ上に設置され、拡張された音響信号が、第一のユーザーの有する装置（拡張前）に送達されるようにしてもよい。

また音声処理エンジンが第一のユーザーの有する装置上に設置されており、音声処理エンジンが所定のパラメータを受信した後に、拡張された音響信号が第一のユーザーに与えられるようにしてもかまわない。

IPネットワーク上の音響データパケット中にて、音響信号を搬送するようにしてもよい。そしてその音響データパケットが、メディアゲートウェイを介したSIPを用いて、音声処理エンジンへと流れるようにしてもかまわない。

一種以上の人間の声に基づく白色雑音を伴う所定の周波数におけるユーザーの聴取試験によって、聴取プロファイルパラメータを導き出してもよい。

各ユーザーの識別を、唯一識別の照会によって行ってもよい。

音響信号の拡張の有効化／無効化を、リアルタイムで定められるようにしてもよい。

ユーザー装置の時計とサーバの時計をそれぞれ同期させた後に、聴取プロファイルのパラメータを決定するようにしてもよい。

ユーザーの年齢、ユーザーの性別、または聴取プロファイルパラメータを最後に導出してからの経過時間のうちのいずれか一種以上に基づいて、聴取プロファイルパラメータを変更してもかまわない。

声のプロファイルを、ユーザー唯一識別の照会（MSISDNなど）と関連づけることで、そのユーザーが既知のMSISDNを使用している場合には、声のプロファイルにおいてユーザーの声をあらためて特徴づける必要が無くなるようにしてもよい。

別の態様によれば、上述の方法を実施するように構成されるプロセッサを含んだユーザー装置も提供できる。

別の態様によれば、上述の方法の一種以上を行うように構成されるサーバーも提供できる。

別の態様によれば、コンピュータ装置のためのコンピュータプログラム製品も提供できる。当該コンピュータプログラム製品には、コンピュータ装置上でプログラムが実行された際に、上述した方法態様のいずれかが有する工程を実施するためのソフトウェアコード部分が含まれる。そうしたコンピュータ装置としては、サーバ、コンピュータ、ユーザー装置、携帯電話、スマートフォン、またはその他の適切な装置が含まれてよい。

別の態様によれば、実行された際にプロセッサに上述の方法のいずれかを行わせるための命令を含んだコンピュータ可読媒体も提供できる。

一個以上のプロセッサ上で実行された際に、前述の方法のいずれかを行わせるように構成されるプログラムコードを含んだコンピュータプログラム。

以上のようにさまざまな実施形態群を記載した。だが上述した実施形態のうちのいずれか二種以上を組み合わせることで、さらなる実施形態も提供できることも理解されたい。

あくまで例示のために、下記図面を参照しつつ実施形態群を説明していく。各図面を通して、類似する要素には類似する参照番号を付してある。
或る実施形態により提供される音響拡張を介した、ユーザー二名での通信のアーキテクチャ的概要を示す。 PSTNを介した発呼の高レベル例を示しており、かつ或る実施形態に係る音声拡張サービスを提供する呼の切替と経路制御も示してある。 或る実施形態に応じて音響拡張を行う際に伴うデータプロトコル流を描いたものである。 或る実施形態に係る第一のネットワークおよび第二のネットワークに関してデプロイされる音響拡張コンポーネントを描いたものである。 或る実施形態に係る、発呼と音声処理エンジンによる音響拡張とに伴うデータ流を描いたものである。 或る実施形態に係るユーザーの聴取・声プロファイルを得るにあたって行われる処理を描いており、この処理は入力時の調整（図6A）、出力時の調整（図6B）、および周囲の調整（図6C）によって行われる。 或る実施形態に係る、音響拡張を行う音声処理エンジンが請け負う処理工程を描いたものである。 音響拡張の周波数応答を示す。 16kHzでの広帯域音声処理を用いた、リアルタイム音響拡張の周波数スペクトラムを示す。 8kHzでの狭帯域音声処理を用いた、リアルタイム音響拡張の周波数スペクトラムを示す。 或る実施形態に係るユーザー装置例を示す。 方法のフローチャートの一例である。 方法のフローチャートの一例である。 或る実施例に係るユーザー装置を描くものである。

概観
本開示は、特には通信網（携帯電話通信網など）を介した、音声信号の聴取試験および音響拡張を示すものである。本開示では、ユーザーに関連づけられたパラメータを、予め定義する基準に則ってまず推測し、そして聴取試験で精度を上げてから、そのユーザーに関連する音響を拡張するために用いるという手法を採る。この手法は、ユーザーが通信網を介して通信する場合にはいつも、中央集約的に行うのが好ましい。任意のユーザーの聴取特性に関連づけられたパラメーターのことを、そのユーザーの聴取生体認証（hearing biometrics）と称する。そうした聴取生体認証を、ネットワーク中で暗号化して保護することで、情報への不正アクセスを回避できるようにしてもよい。

つまり、中央通信網によって、クラウドサービスその他の中央リソースを介して、固定アクセスもしくは携帯アクセスに音響拡張を与えられるということである。すなわち、双方のユーザーがアクセス可能ないずれかの中央リソースを手段として拡張音響信号を提供できる。このとき、そのユーザーのうちの少なくとも一方は、音声パラメータおよび／もしくは聴取パラメータをプロファイルの形態で登録しておき、そのパラメータを音響信号に適用することで、そのユーザーに合わせた（そのユーザーが発するか、および／もしくはユーザーに送達されることになる）唯一性のある拡張信号が得られる。この手法は好ましくは中央集約的に行えるし、あるいはさらにユーザー装置にて行ってもかまわない。

アーキテクチャ
図1は、或る実施形態にて提供される音響拡張を介して通信する二名のユーザーを、アーキテクチャ的に概観したものである。第一のネットワーク 11 に接続する通信装置を有する第一のユーザー 10 と、第二のネットワーク 13 に接続する通信装置を有する第二のユーザー 14 とは、通信手段 12 を介して通信できる。第一のネットワークおよび第二のネットワークには、モバイル（携帯電話）通信ネットワーク、固定電話ネットワーク、またはVoIPネットワークのいずれが含まれていてもよい。通信手段 12 には、PSTN、インターネット、WAN、LAN、遠距離通信サービスの伝達が可能な衛星もしくは何らかの搬送・交換ネットワーク（例えば固定電話線などだがこれに限定はされない）、WiFi、IPネットワーク、構内交換機（PBX）、アプリ、エッジ処理、フェムトセル、VoIP、VoLTE、および／またはIoT（Internet of Things）が含まれていてよい。基本的には、デジタル信号もしくはアナログ信号を伝達／分配でき、そして音響拡張を含んだ信号を処理できるユーザー端末へと音響信号を送達できるような任意の手段を使用できる。例えば、国営または地方の配電回路網（英国のthe National Grid）が使用できる。別の実施形態では、アプリや埋込ファームウェアの形態を以って、音響拡張をユーザー装置上で処理してもよい。

図1では、第一のユーザー 10は、ここに開示する音響拡張サービスの加入者 15A であってもよいし、あるいは非加入者 15B であってもよい。加入者 15A は、後述する音響拡張コンポーネント 20 を用いた音響拡張処理にアクセスできる。

図1のアーキテクチャ構造に基づいた図2では、PSTN 12 を介した第一のユーザー 10 による発呼の高レベル例を説明している。発呼されると、第一のネットワーク 11 は、第一のユーザー 10 が加入者 15A であるかの是非を検出する。是であれば、音響拡張は音響拡張コンポーネント 20 を用いて提供される。非であれば、通常の呼が第一のネットワーク 11 からPSTN 12 を介して第二のユーザー 14 へと転送される。

音響拡張コンポーネント 20 （破線で囲んだ領域として示してある）には、メディアゲートウェイ制御手段 21A と、メディアゲートウェイ 21B と、音声処理エンジン 22 と、設定管理モジュール 23 とが含まれており、通信網の中枢網（この実施形態では第一のネットワーク 11 ）内に設置できる。図2の実施形態では、想定されるとおりセッション開始プロトコル（SIP） 16 を使って発呼をする（し、さらなる音響拡張サービスの生成を許可する）。この発呼には、音響拡張コンポーネント 20 が有するメディアゲートウェイ 21B が関与することになる。または、その他の適切な非IPプロトコルを使ってもかまわない。本開示に係る実施形態では、標準ネットワークインターフェイスコンポーネントおよびプロトコル（IP、SIP、およびVoIPなどのプロトコル）を利用でき、また、遠隔通信網その他の基幹ネットワークと通信するための、セッションボーダーコントローラー（SBC）などの種々のコンポーネントや、メディアゲートウェイとその制御手段やその等価物といったものも利用できる。こうしたネットワークでの現行技術に立脚する信号伝達とインターフェイスを、固定電話網や携帯電話網と通信する際に、レガシーなCAMEL/IN、ISDN、IMSといったネットワーク仕様に合わせて変更してもかまわないことは理解されたい。

ネットワーク 11, 13 を、ユーザーとの接続のために用いる「ラストマイル」アクセスとコアネットワーク技術に基づいて改変してもよいことは理解されたい。メディアゲートウェイ 21B は、信号伝達の際の変換を担うだけではなく、想定される種々の標準からのトラフィックの変換も行う。そうした例としては、レガシーな交換手通信網から、より新しいIPソリューションへのトラフィックが挙げられる。SIPは信号伝達に、RTPは音声サービスのトラフィック流のためのものである。

音響拡張コンポーネント 20 について詳述するに先立ち、まずは図1のアーキテクチャを基幹として音響拡張をする際の、音響拡張コンポーネント 20 が関与するデータプロトコルの流れを図3で説明する。メディアゲートウェイ制御手段 21A は、拡張された音声発呼（この実施形態ではSIPパケットを用いる）を扱う。メディアゲートウェイ 21B は、マルチメディアリアルタイムプロトコル（multimedia real time protocol; RTP）のパケット 17 を扱う。このRTPパケット 17 は、音声処理エンジン 22 とのインターフェイスを有する（後で述べるインターフェイス「D」や「X」を参照されたい）。またメディアゲートウェイ 21B が通話中に、第一のユーザー 10 と送受信する第一のネットワーク 11 と、第二のユーザー 14 と送受信する第二のネットワーク 13 とのあいだの通信を取り持つことになるのは理解できるであろう。SIP 16 の発動後に、音声処理エンジン 22 は、第一のユーザー 10 からのRTPパケット 17 および／もしくは第一のユーザー 10 へ与えるRTPパケット 17 に包含される音響ストリームを変調する。これにより第一のユーザー 10 （図1の実施形態における音響拡張処理サービスへの加入者 15A ）が、設定管理モジュール 23 が保存している聴取・声プロファイルに基づいた音響拡張を享受できるようになる。音声処理エンジンがさらに、双方向で別の聴取・声プロファイルを使えるようにしてもよく、そうすることで聴覚に障害のある二名のユーザーが同時に音響拡張に与れるようにもできる（図5とその説明を参照）。

後述するように別の実施形態では、インターフェイス「D」と「X」によって、例えば任意の国の携帯電話通信網に関連するネットワークなどのネットワークの分散ノード上に、音声処理エンジン 22 を設置できる。あるいは、ユーザー装置が充分な処理電力とローカルリソースを有しているような場合には、音声処理エンジン 22 が、ユーザー装置にプリインストールされたコーデックとして設置されていてもよい。こうした実施形態では、音響拡張を行う際にコーデックが利用するパラメータを、設定管理モジュール 23 が提供できる。したがって聴取生体認証データをネットワーク内に中央集約的に保持できるため、設定管理システム 23 が実行される地点やメディアゲートウェイ 21B が稼動している地点とは異なる地点にて物理的に稼動するサーバが有する分散機能ノードとして、音声拡張機能を実行可能である。こうした音声拡張の分散機能は、ユーザー 10, 14 の有する装置に近いネットワークのエッジにて実行されていると考えてもよい。あるいは、互換性と共通運用性が許せば、ユーザー装置自体の中で、サポートする音声コーデックの一種として、音声拡張の分散機能を実施してもよい。

音響拡張モジュールのインターフェイスと性能
音響拡張コンポーネント 20 と第一のネットワーク 11 および第二のネットワーク 13 との相互作用について、ここからさらに詳述していく。図4では、第一のネットワーク 11 と第二のネットワーク 13 に関してデプロイされる音響拡張コンポーネント 20 を示している。ここでは第一のネットワーク 11 と第二のネットワーク 13 は、SIP/VoIP環境を与えるものであって、例えばIP PBX、IMS、CAMEL/INその他のSIP環境を提供できる。

音響拡張コンポーネント 20 は、メディアゲートウェイ制御手段 21A にてインターフェイス「A」を、メディアゲートウェイ 21B にてインターフェイス「M」を、また設定管理モジュール 23 にてインターフェイス「B」をそれぞれ用いることで、ネットワーク 11, 13 と連動できる。

インターフェイス「A」は、コアネットワーク 11, 13 とやりとりされる信号伝達を含む。通話する第一のユーザー 10 と第二のユーザー 14 にはそれぞれ唯一識別子を振り、また通話のRTPパケット 17 の経路情報も与える。インターフェイス「M」のRTPパケット 17 には、メディアゲートウェイ 21B を介して音声処理エンジン 22 が処理することになる音声搬送パケットが含まれる。インターフェイス「B」には、設定管理モジュール 23 とオペレーターが使う運用支援システム（OSS） 26 とのあいだでの動作・維持接続が含まれる。

さて上述したように音響拡張コンポーネント 20 には、メディアゲートウェイ制御手段 21A と、メディアゲートウェイ 21B と、音声処理エンジン 22 と、設定管理モジュール 23 とが含まれている。

メディアゲートウェイ制御手段 21A は、インターフェイス「A」、インターフェイス「C」、およびインターフェイス「E」を有する。インターフェイス「C」は、音響拡張コンポーネント 20 内部のインターフェイスであって、メディアゲートウェイ制御手段 21A とメディアゲートウェイ 21B とのあいだに在る。インターフェイス「C」にはメディア部と制御部が含まれる。或る実施形態に係るインターフェイス「C」は、1Gbイーサネット（登録商標）からなる物理層を含み、加えてメディア部のためのUDP（user datagram protocol）を介したRTPと、制御部のためのUDPを介したMGCP（media gateway control protocol）とからなるアプリケーション層を含んでいてよい。またインターフェイス「E」を使って、設定管理モジュール 23 がメディアゲートウェイ制御手段 21A の監視と制御をできるようにしてもよい。

メディアゲートウェイ 21B は、音声処理においてRTPプロキシの作成を許可する。このRTPプロキシ内ではリアルタイム音声データを展開でき、処理してから同じゲートウェイに返して経路制御させるようにできる。要するにメディアゲートウェイとはSIPルーターであって、対象のネットワークからSIP 16 への信号変換を行うとともに、RTP 17 を音声処理エンジン 22 へと導くトラフィックの経路制御も行うものである。

設定管理モジュール 23 は、データベース 25 と、インターフェイス「B」と、インターフェイス「D」と、ユーザーインターフェイス 24 とを含む。また設定管理モジュール 23 はwebポータルを有してもよく、例えばラップトップ装置やハンドヘルド装置のためのwebポータルを有してよい。こうしたwebポータルは、音声で起動するものであってもよいし、および／または、ヘッドセットやその他の聴取・マイクロホン一式などの周辺機器の設定と組み合わせて使用できるものであってもよい。またユーザーインターフェイス 24 は、インターフェイス「F」および／もしくはインターフェイス「G」を含む。ユーザーインターフェイス 24 により、ユーザーは音響拡張コンポーネント 20 へアクセス可能になる。ユーザーインターフェイス 24 が有するインターフェイス「F」は、ユーザーの聴取・声プロファイルのキャプチャ（生体認証登録）のためのユーザー設定を提供し、音声処理アルゴリズムのための初期較正および進行中較正とパラメータを用いる（図6で後述する）。インターフェイス「G」は、管理者・支援機能を含む。インターフェイス「F」とインターフェイス「G」が、同一のインターフェイスの一部であってもよい。またデータベース 25 は、生体認証データに関するユーザー情報と、後述する音声処理エンジン 22 と共に用いる聴取・声プロファイル情報とを含む。インターフェイス「D」は、ユーザーの聴取・声プロファイルにて定義される音声処理パラメータを、音声処理エンジン 22 が要求してきた際に渡す役割を担う。

図5では、携帯電話通信始点（mobile origination point; MO）などを用いた第一のユーザー 10 （すなわち音響拡張サービスの加入者 15A ）からの発呼が、携帯電話通信終点（mobile termination point; MT）などの第二のユーザー 14 へ至るさまを描いている。ここに示しているデータフロー 50 は、その発呼と音声処理エンジン 22 による音響拡張とに関係している。コアネットワーク 11, 13 からは、音響拡張コンポーネント 20 の内部機能は不可視になっている。すなわちネットワークは単にユーザー識別子（MSISDNなどの各ユーザーにとっての唯一識別子など）をどのユーザーへ使えばよいかを知っていれば足りるというわけである。

図1の例では、端点 10, 14 の双方に関連するMSISDN番号を、アプリケーションサーバ（メディアゲートウェイ制御手段 21A ）によって通話のセッションIDに関連づける。関連パラメータは、インターフェイス「X」を介して音声処理エンジン 22 へと渡される。例えば第一のユーザー 10 の唯一識別子を、インターフェイス「A」を介してメディアゲートウェイ制御手段 21A に与え、続いてインターフェイス「C」を介してメディアゲートウェイ 21B に渡し、さらにインターフェイス「X」を介して音声処理エンジン 22 へと送ることができる。

その後に音声処理エンジンは、特定の通話を発呼したところのユーザーに対応する生体認証を、インターフェイス「D」を介して設定管理モジュール 23 の有するデータベース 25 に要求する。この生体認証は、聴取・声プロファイルの形態となる。このプロファイルが音声処理エンジン 22 に返ると、RTPパケット 17 の音響拡張をリアルタイムで進めることができる。

図5の例では、そのようにして第一のユーザー 10 が音響拡張を享受できている。

音響拡張をしながらの通話では、MOとMTの双方についてのMSISDN番号に関連づけられる生体認証を、データベース 25 に照会することになる。

MOとMTの双方が音響拡張サービスに登録しているような実施形態では、データベース 25 に保存されている各ユーザーの生体認証プロファイルから得たパラメータを、会話の両端に対して音声処理エンジンが適用することになる。この手法には、聴取プロファイル、声プロファイル、またはその両方に関して、各ユーザーに関してそれぞれ独立に、音響拡張を採用する工程が含まれていてもよい。

特定のユーザーが音声拡張サービスに登録していなかった場合であっても、ユーザーの音声生体認証プロファイルをキャプチャしてそのユーザーの唯一MSISDN番号と併せてデータベース 25 に保存することで、登録済ユーザーとの通信を行う際にいつでも、未登録ユーザーの初期入力信号が登録済ユーザーにとって最適化されるように調整できるので、登録済ユーザーは高度な拡張を享受できる。

上述したように音声処理エンジン 22 は、音声処理アルゴリズムに流し込むためのパラメータを得るために、聴取・声プロファイルを必要とする。データベース 25 には、個別のユーザーの聴取・声プロファイルに関連づけられた値を保持しており、例えば探索表を用いて保持できる。

各ユーザーの聴取・声プロファイルは、そのユーザーの有する特定の聴覚障害に対応可能であって、それはそのユーザーから得られる声を拡張することと、そのユーザーへ送達される声を拡張することの両方によって実現できる。電話反響（変換器効果; transducer effect）および／または周囲騒音を任意に考慮してもよい。

図6には、ユーザーの聴取・声プロファイルを得るにあたって行われる処理を描いており、この処理は声の入力時の調整（図6A）、聴取するための出力時の調整（図6B）、および任意付加的な周囲の調整（図6C）によって行われる。これら入力調整、出力調整、周囲調整のうちの一部または全部は、ユーザーの求めに応じて有効化したり無効化したりできる。例えば音響拡張サービスのユーザーが、電話を保留し、友人へ転送して会話を続ける場合を考える。このときユーザーとその友人は聴覚障害を持っておらず、その友人にとっては音響拡張は不要ということがありえるわけである。

さて図6Aでは、難聴のある登録済加入者 15A としてのユーザー 10 へ、音声処理エンジン 22 を介して音声を届ける際の調整を示している。まずステップ 61 として、セッション中の通話の開始時と途中にて、着信してくる音声をユーザー（図1でのユーザー 14 ）の有する通信装置から採取するか、あるいはユーザー 14 の唯一識別子（MSISDN番号など）に関連する別の入力装置から採取する。ステップ 62 では、信号を時間域から周波数域へと変換する。そしてステップ 63 で周波数域信号 Fi が得られる。ステップ 64 では、声の種類（ソプラノ、メゾソプラノ、コントラルト、カウンターテナー、テナー、バリトン、またはバスなど）と音量を解析する。ステップ 65 でその解析結果を声プロファイルに収め、話者の声についての声プロファイル（すなわち発話者の特徴づけ）を導出する。この手法では、着信してくる声を受けるまたは聴くユーザー（この例ではユーザー 10 ）の聴取特性に係る聴取プロファイルに対し、誤差関数として一種以上の周波数（音程）段階を用いることで、その元の発声者（すなわちユーザー 14 ）の音を任意に自動的に変化させられる。こうした声プロファイルは、ステップ 66 にて、懸案対象であって発声者であるユーザーについての唯一IDと共に、データベース 25 に保存される。同じユーザー（ユーザー 14 ）が、また同じ回線（MSISDN）を使って通話する場合には、声プロファイルに収めたこの結果を改めて導出しなおす必要は無い。声の統計的ばらつきもキャプチャーしてよい。また多くの人々が使う特定の回線（MSISDNなど）については、新しい通話が行われる都度に声の特徴づけを行う必要が出てくる可能性もある。と言うのは、通話をするであろうユーザー（声）がどれなのかを確実に予測するのが難しいためである。

次に図6Bでは、信号を調整し、ユーザーが音声処理エンジン 22 から聞くことになる場合を示してある。まずステップ 67 では音響聴取試験信号が、ユーザーの有する通信装置、または設定管理モジュール 25 のユーザーインターフェイス 24 と関連づけられた別の出力装置へと与えられる。ステップ 68 では、聴取音程と音量を解析する。ステップ 69 でその結果を聴取プロファイルに収める（すなわちセンサーとユーザーの耳の特徴づけをする）。聴取プロファイルには、加入者であるユーザーに提示される音声波形上での種々の周波数の均衡を取るためのパラメータが含まれる。これは言ってみればユーザーの聴取能力についての模擬処方箋というわけである。こうして、着信する声がその聴取プロファイルに合致していれば、どのユーザーも着信する音声をとても効率的に、かつとても明瞭に聞くことができる。

この聴取プロファイルは、ステップ 70 にて、懸案対象であるユーザーについての唯一IDと共に、データベース 25 に保存される。このプロファイルは、測定される変換器と関連して考慮されるユーザーの難聴と、聴取試験に絡む系雑音の影響との組み合わせであると考えてもよい。すなわちこのプロファイルからは、電気通信網に即し、かつその時点・そのユーザーに特化した組み合わせ聴取閾値が得られるというわけである。こうした組み合わせ聴取閾値は、そのユーザーに関して唯一性があるものであってよい。つまり、そのユーザーに合わせたデジタルの「声紋」閾値と考えてもよい。ここでの「閾値」thresholdという語は、聴取閾値のことであると考えてもよいし、同様にユーザーが音響信号を充分に聞くことができる何らかの量（音量および／もしくは周波数など）のことであってもよい。つまりこの閾値は、難聴についての閾値よりも低くなる場合もある。こうした聴取閾値の表現は、聴力図などの従来技術に係る基準とは対照的なものであって、特には難聴を如何にして通信網上で機能できる態様へと翻案し、変調し転送するようにするかの手法が異なっている。

ステップ 67 で行う聴取試験についてさらに詳述していく。

ユーザーの難聴についてわかっている程度（種々の制度で定める基準に則っての所見無し、軽度、中度、重度、または重度から重篤）に基づいて、聴取試験の初期音量を決定する。初期音量をユーザーが決めるような実施形態があってもよい。或る実施形態では、初期音量の設定にあたって、ユーザーの性別および／または年齢を代替的にかまたは付加的に考慮してもよい。

聴取試験は以下のように始まる。

1. 聴取試験の開始

(a) ユーザーに対し、ユーザーインターフェイス 24 を介して聴取試験を受けられる旨を案内する。

(b) メディアゲートウェイ制御手段 21B が、ユーザーの電話に着呼をする。

ここでは、ユーザーインターフェイス 24 （ユーザーのためのwebポータルや音声で起動するインターフェイスなど）を提供する基幹ネットワーク（広帯域ネットワークなど）と、声をユーザーの持つハンドセットや装置へ届けるための音声通信網（電話やVoIPなど）とが介在していることは理解されたい。これらのネットワークは、それぞれ違う時計に従って動いており、例えばブラウザやラップトップの時計と、遠隔通信網の時計とのあいだの関係などを想定できるだろう。すると、ユーザーがその装置から聞く音程と、webポータル上で聞いて確認済の音程とのあいだには遅延があるのがわかっているので、自動試験に反応する時間に関して、聴取試験に誤差や不正確性が出てしまうおそれもある。そこで、自動試験に反応する時間をネットワーク間での時計のずれに応じて変更することも考えられる。また、特定の聴取試験周波数にて真偽結果を誤って判定してしまうこともありえるので、ユーザーの聴取能力の閾値の計測結果にも影響を及ぼすおそれもあり、ひいてはユーザーの生体認証プロファイルに悪影響が出てしまう（後述する）。したがって、クライアントプラットフォームとサーバ（メディアゲートウェイ制御手段）プラットフォームとについて、マスターとなる時計と計時手段を同期するわけである。

サーバの時計とユーザー装置の時計を同期する手法の一例を以下に述べる。まずユーザー（クライアント）装置が、聴取試験開始の要請をする時刻において、複数回（例えば五回）のpingをサーバから要求する。その複数回のpingのうちの一回以上には、声を代表する周波数を分散させたものや、または白色雑音を含めてもよい。この特徴は、特定の単一周波数音程を用いる標準的な聴取試験とは対照をなすものであると言える。サーバはpingパケットに、サーバの現在時刻を示すデータペイロードを添えて送信する。このpingパケットをクライアント装置が受信すると、所定の時間間隔（一秒など）の後に送信する。さらなる時間間隔（二秒など）の後に、そのpingパケットの複製が送り返される。この工程を数回繰り返すことができ、そうするとサーバは複数個のpingパケットを受信し、その各々がクライアント装置から送り返されてきた対応する元のパケットに関することになる。これらのパケットからサーバは、ユーザーからサーバまで到達するのにかかる時間を計算でき、さらにクライアントの時計とサーバの時計の偏り傾向も知ることができる。この手法により、上述したような聴取試験における真偽結果の誤りを回避できるわけである。

さらに、聴取試験の音量を下げていく（後述）につれて、聴取試験を聞き逃してキーを押下する際の遅延が生じ、試験結果にとって重大な問題になる。試験結果は、段階の幅を半分にすること（10dBに対して5dB）で微調整できる。正確な時計同期情報を持つことで、試験にかかる時間を短縮でき、半分幅の段階の回数を減らすこともできる。

(c) ユーザーの電話に対しての音声拡張機能を無効化する。

(d) ユーザーの電話に対して基準音声を流し、ユーザーにハンドセットの音量を基準音声が聞き取りやすいように調整するよう促す。

(e) 計時手段を同期し、試験のための聴取閾値を500Hzにする。

(f) 計時手段を同期し、試験のための聴取閾値を1000Hzにする。

(g) 計時手段を同期し、試験のための聴取閾値を2000Hzにする。

(h) 計時手段を同期し、試験のための聴取閾値を3000Hzにする。

(i) 計時手段を同期し、試験のための聴取閾値を6000Hzにする。

(j) ユーザーの電話に対しての音声拡張機能を有効化する。

(k) 計時手段を同期し、ユーザーの電話へ基準音声を流して、ユーザーインターフェイスを介してユーザーへ音量指数を調整するよう促す。

2. 聴取試験の完了
上述した聴取試験が終了すると、パラメータは聴取プロファイル（生体認証データ）としてキャプチャされ、設定管理モジュール 23 が持つデータベース 25 内に保存される。これらのパラメータは、ユーザーが有する難聴、系雑音、および変換器効果のうちの一種以上に依存していてもよい。

典型的には聴取試験のための聴覚刺戟を、500Hz、1000Hz、2000Hz、3000Hz、6000Hz、またはそれ以上の周波数を中心とした1/3オクターヴ幅帯域の雑音であるようにできる。一例として、各試験の期間は約1000msとし、そのうちに暗騒音レベルから-60dBまでのあいだで聴覚刺戟の音量を上げる20msの傾斜（ramp）と下げる20msの傾斜とが含まれているのが好ましい。聴覚刺戟が有するスペクトル傾斜（slope）は、急勾配であるのが好ましく、また90dB/oct以上であるのが好ましい。

こうした1/3オクターヴ幅の白色雑音は実際には一種以上の人間の声の混合を含み、使用する通信系の能力の限界まで周波数帯を上げて試験する。人間の声を含んだ白色雑音によって、会話がユーザーへどのように送達されるかを反映しかつ発話者パラメータ（声帯）とセンサーパラメータ（ユーザーの耳）の双方をより正確に特徴づけられるような現実世界により近い試験ができるという利益が得られる。各試験に使う白色雑音が、ユーザーへと送る別の発音（種々のアルファベット）を特徴づけることで、聴取プロファイルパラメータを微調整できるようにしてもかまわない。

試験の順番としては以下を提案できる。すなわち、500Hz、1000Hz、2000Hz、3000Hz、6000Hz以上（広帯域または超広帯域音声コーデックの場合）、あるいは3000〜3400Hzを上限とする（狭帯域コーデックの場合）。狭帯域コーデックと広帯域コーデックは、レガシーな遠隔通信系で普通に用いられるコーデックである。基幹通信手段（ネットワークなど）の、狭帯域または広帯域を介して音声を伝送する能力に合わせて、試験を設えてもよい。或る一種類の中心周波数において測定を完了させてから、次の中心周波数を選ぶようにするのが好ましい。

各試験周波数の詳しい手順について、一例を以下に述べていく。

(a) 上述したように見積った初期音量を以って音声を与える。

(b) 音声の終了後、例えば二秒以内に、応答が「是」であった場合は、「当たり」として扱い、次の音声の音量を10dB下げる。音声の終了後二秒以内に応答が無かった場合には、「外れ」として記録し、次の音声の音量を10dB上げる。

(c) 次の試験音声を可変時間間隔の後に与えて、ユーザーが「是」をおてつきしてしまうのを避ける。前回の音声への応答が当たりだった場合、次の音声を与えるのは、前の「是」応答の後の0.5〜2秒の範囲から無作為に選んだ遅延を以って行うのが好ましい。前回の音声への応答が外れだった場合、次の音声を与えるのは、前の音声の終了後の例えば2.5〜4秒の範囲から無作為に選んだ遅延を以って行うのが好ましい。

(d) ステップ(b)を、外れの後に一回以上当たりが出るまで繰り返す。外れの後には、音量を10dB上げて信号を与える。
a. 応答が当たりであれば、外れが出るまで信号を5dB刻みで下げていく。当たりが出たうちで最も低かった音量を、その周波数についての閾値として扱う。
b. 応答が外れであれば、当たりが出るまで音量を5dB刻みで上げていく。その後は、外れが出るまで音量を5dB刻みで下げていく。当たりが出たうちで最も低かった音量を、その周波数についての閾値として扱う。

この手順を各試験周波数ごとに繰り返す。ただし、前回の試験音声への最初の応答が外れだった場合（つまり、初期音量が低すぎると思われる場合）には、現行の中心周波数の開始音量を、前回の周波数における閾値に所定量を足したもの、例えば25dBを足したものに設定する。

ユーザーの生体認証パラメータが変化するほどの長期間が経った後に、聴取試験を再度行ってもよく、こうすることでキャプチャーしていた閾値パラメータの標準偏差を小さくできる。

こうして、組み合わせ聴取閾値の最終結果、または「デジタル声紋」を、そのユーザーに特化したかたちで、視覚的にかおよび／もしくは何らかの別の手法を以ってユーザーへ提示できる。この結果には例えば、聴取結果を聞くこと、試験結果を保存すること、試験結果を取り消すこと、または再試験をすることといったものが含まれていてもよいと考えられる。聴取試験結果を聞く際に、処理済の声と未処理の声を聞き比べられるようにしてもよい。こうすると、記録された聴取閾値がより良く調整されるようにもなるし、そうならないこともありえる。例えば圧縮比および／もしくは周波数レベルを適合させるようにすることで、デジタル声紋または元の組み合わせ聴取閾値が、さらに正確にユーザー設定・調性を反映し、難聴の程度や要望が計時変化した後にも使えるようになるかもしれない。すなわち上述したように、個人の難聴や要望を反映し、それと共に系雑音と変換器効果を反映するように組み合わせ聴取閾値を測定すれば、こうしたデジタル的微調整が可能となる。言い換えればユーザーは、スクリーン越しにそのユーザーの難聴を記録し解析することができるというわけである。つまり、系の「雑音」に変換器の影響を加えて組み合わせたものを使って、デジタル閾値を生成できるということである。こうした視覚的出力のことを、難聴の閾値と装置・変換器効果とを結合したグラフィカルな表現であると考えてもよい。

図6Cでは、周囲騒音、信号雑音比、反響、パケット損失、およびその他の有害な効果のうちの一種以上を考慮する場合を示す。まずステップ 71 にて、周波数域信号Fi（ステップ 63 のそれと同一の信号であってもよいし、現況の要求に沿って新たに得られた信号であってもよい）を用意する。ステップ 72 でこのFiを、人声検出アルゴリズムにより処理し、ステップ 73 で解析する。ステップ 74 でその解析結果を周囲騒音プロファイルに収める（すなわち、音声送達に用いるチャネルを特徴づける）。こうした雑音プロファイルは、ステップ 75 にて、懸案対照であるユーザーについての唯一IDと共に、データベース 25 に保存される。周囲騒音調整の拡張として、認知情報の交換を難しくしてしまうような音声の信号雑音比の指標となるアラームまたはその他の信号を発動条件として使って、何らかの記録済メッセージを呼に関わっているユーザーへと送るようにすることで、ユーザーに周囲騒音の問題があることを気づかせて、雑音が目立たなくなるような環境へと移動してもらうようにできる。こうしたアラームに対してユーザーは承諾も拒否もできるし、また認知情報の交換が難しくなっているであろうことを個々のユーザーが気づくようなときに、適宜アラームを今後も鳴らすようにフィードバックしてもよい。会話の記録機能などのその他の機能を与えて、聴覚に障害のあるユーザーが、後から会話を顧みて検証する援けとなるようにしてもよい。例えば、ユーザーからのフィードバックと併せて通話を記録して保存しておくことで、その知見から、将来に特定の音声体験が起こるであろう際の状況を導き出し、予め定義して想定しておくことで、それを解決できるようになると考えられる。具体的には、音声処理エンジン 22 が人工知能を使って、ありえる厄介な音声の状況を認識し、回避または補償できる術を学習できるようになる。時間をかけて知見データバンクを積み上げてゆき、データベース 25 に保存しておくことで、それを共有し活用して、その他の状況におけるさらに包括的な用途へと、音響拡張・処理アルゴリズムを開発し拡張していけるようになる。例えば、そのときの環境および／またはネットワーク信号強度（固定ネットワーク、携帯ネットワーク、無線ネットワークなどであるかどうか）に応じた音声・周囲状況の範囲で、聴取閾値を微調整することなどが考えられる。通常は、ユーザー体験の向上のためにAIを使うとしても、遠隔通信網／IPネットワークにてリアルタイムに使うというわけではない。このため本開示は、難聴に因る対処可能な要求に応えるような、音声体験の向上を図ることができるものである。

図7には、音響拡張をしている音声処理エンジン 22 が請け負う処理工程を示す。図6Aと図6B（と任意に図6C）に示したプロファイリング工程で導出されるパラメータを使って、受信するユーザー（図1の例で言うとユーザー 10 ）の必要に応じて音響拡張をしていることがわかる。

まず最初にステップ 80 では、ユーザー 14 から加入者であるユーザー 10 へと至る入力音声信号が取得され、そしてステップ 81 で復号される。ステップ 82 でその音声信号を周波数域へ変換し、その変換結果をステップ 83 で周波数域信号とする。ステップ 84 では図6Cと同様の手法により周囲雑音の評価をし、ステップ 85 でその周囲雑音を除去する。そして音声調整のためのステップ 66 においてデータベース 25 に保存されていた声プロファイルパラメータを、ステップ 86 で適用し、ステップ 87 で拡張音声出力を得る（なお、ここではまだ周波数域にある）。

ステップ 88 では、ステップ 70 において受信者（加入者であるユーザー 10 ）に関してデータベース 25 に保存されていた聴取プロファイルパラメータを適用する。そしてステップ 89 にて、拡張された音声出力を（周波数域で）得る。ステップ 90 にて拡張された音声出力を時間域へと変換し、ステップ 91 で拡張された時間域信号を得る。ステップ 92 では拡張された音声出力を規格化して刈り込みを回避する。そしてステップ 93 で規格化された音声出力を得る。最後にステップ 94 で基幹伝送プロトコルのために出力を符号化して、ステップ 95 にて加入者である受信ユーザー 10 の聴取に合わせて設えた拡張音声（いわば声紋）が得られる。

一例として図9および図10には、拡張音響を提供している音声処理エンジンにより生成される波形（周波数域）を示してある。

まず図8を見ると、音響拡張の周波数応答が、示した応答曲線のいずれかまたは全部によって合わせられていることがわかる。横軸は周波数帯を示す。また縦軸には、前述したような聴取試験で定められる閾値（その周波数にてユーザーが聴取できる限界）をそれぞれ示してある。閾値の軸の尺は、音量の指標となる音圧レベルを表す。

Flat（無）な応答、すなわちその周波数では変化がないという応答を、番号 100 で示している。またLow（低） 101 は低い周波数で、Mid（中） 102 は中程度の周波数帯で、High（高） 103 は高い周波数帯で、それぞれ音声が拡張されていることを示す。

図9には、16kHzの広帯域音声処理を行う音声シミュレータをくぐるリアルタイム音声サンプルの周波数スペクトラムを示してある。また図10は、8kHzで狭帯域音声を使った同様のものを示している。ここに示した狭帯域周波数と広帯域周波数は、あくまで例示に過ぎないことを理解されたい。入力信号のその他種々の帯域も取り扱うことができる。

音響信号（発声や音楽など）のリアルタイム拡張が進行している際には、特定のユーザーに関してデータベース 25 に保存されている聴取・声プロファイルパラメータに依って、flat、low、mid、およびhighフィルターのいずれかまたは全部を任意の時点で適用できる。

上述したような特定のユーザーに関する声プロファイルと聴取プロファイルの派生と同様に、加入者であるユーザーへと送達されることになる入力音声も、ステップ 64 とステップ 65 に関して述べたように音声の受信者の有する声の種類に従って変化させた入力音程を、リアルタイムに持つようにしてもよい。この手法は、音声処理エンジン 22 にて（フィルタバンクなどを介して）適用される、音響信号に対して働く誤差関数を使用することで行える。望ましい音程の変更を、そのユーザーの他のプロファイルデータと共に保存しておき、将来の活用に備えるようにしてもよい。既知のMSISDNから加入者であるかもしくは非加入者であるユーザーが、加入者であるユーザーへと発呼した際に、そうした音程の変更を自動的に行うようにしてもよい。特定のMSISDNからの声の修理をデータベース 25 に保存しておくことで、同じMSISDNから別のユーザーが発呼してきたときでも、音声処理エンジン 22 に組込まれた人工知能を使って、自動音程変更を切るようにできる。或る実施例では、声プロファイルを表すパラメータの標準偏差を観察し、これを学習した閾値と比較するようにしてもよい。標準偏差の値が学習した閾値を超えている場合には、音声処理エンジン 22 が、着信してきている回線を使っているのはおそらく別の人物であると推測し、音程変更を自動的に切るようにできる。

加入者であるユーザーへと送達されることになる入力に関する聴取プロファイルと周囲プロファイルと同様に、受信されることになる声の音量を、以下に示すような種々の手法で調節してもよい。

◆ 最後の処理段階（ステップ 92 ）での出力の音量を単に増幅。

◆ 周囲騒音の除去（ステップ 85 ）の後の入力信号のデジタル範囲を増幅。この増幅は、或る期間（現行の会話から20処理時間間隔が経つまでなど）に亙って評価したフィードバックパラメータを用いる誤差関数に基づいてよい。

◆ 上述したフィードバックパラメータを長整数型変数として、データベース 25 中のユーザーのプロファイル情報に格納してもよい。

◆ 多数の会話などの長時間が経過した後に、音声処理エンジン 20 が使った初期パラメータを、現実世界でのユーザー間の会話を踏まえて最適化し、ユーザーにとって最適化された声紋を得るようにしてもよい。

◆ また、ユーザーが後に聴取試験を受けて聴取プロファイルを更新するか否かには依らずに、ユーザーの聴取能力が劣化していくのを考慮し、聴取プロファイルのパラメータを経時変化させていってもよい。例えばユーザーの聴取閾値を、加齢と共に劣化させていってもよい。本開示に係る方法およびシステムでは、閾値が経時で損失していくのを測定してもよいし、またユーザーからのフィードバック、ユーザーへの質問、および人工知能の組み合わせを介して、ユーザーによる電話の使用方法、ユーザーの年齢、性別、周波数損失に関する難聴データを得て、この難聴データを使って予言的かつ動的な聴取閾値を生成するようにもできる。こうした予言的かつ動的な聴取閾値の生成にあたっては、ユーザーの年齢および性別を単に予想するというだけではなく、そうしたデータを関連する同種の群と比較することにもよって、自動的に修正していくことも可能である。本質的にはそうしたアルゴリズムをAIと結びつけるにあたっては、ユーザーの聴取特性の解釈だけにはとどまらず、特定の会話に関するネットワーク信号伝達強度（固定通信網におけるパケット損失や無線通信網におけるRF信号強度など）の解釈も許している。こうすることで、信号が弱いときには聴取閾値を低めにずらし、音声信号をより強調する（音量を高める）ようにする音声処理を促すようにできる。このような聴取閾値の評価法では、閾値を経時で適合させていくこと（すなわちユーザーの年齢に合わせること）と、信号強度に対して適合させていくこととが唯一無二であって、これはすなわちユーザーの聴取が経時劣化していくことと、いま手中でされている会話との両方に合わせるようにユーザーの聴取特性を調節できるが所以である。

聴取試験と、その聴取試験の結果を使ってユーザーへ与える音響信号を変調する方法について、図12を参照しつつさらに詳述していく。なおこの方法を、上述した方法、図6A〜6Cおよび図7に関して説明した方法（および本開示に係るその他の実施形態に関する方法）と組み合わせて使用可能である旨も理解されたい。

図12に関して説明する方法は、ネットワークエンティティ（通信網内に設置されるサーバなど）と、ユーザー装置を介したサーバとのユーザーの通信とのあいだで行われる聴取試験に関する。この通信網は遠隔通信網であってもよい。ユーザー装置は携帯電話などの電話であってもよいし、あるいはラップトップやタブレットなどでもかまわない。このように通信網を介してユーザー装置を用いた聴取試験を行うことでユーザーの聴取が如何に現実世界の条件に左右されるかをより正確に描写できることがわかるだろう。また、特定のユーザーに特化した考慮もなされる。例えば聴取試験では、干渉や雑音などの通信網効果を考慮に入れることもできるし、あるいはユーザーが使う特定のネットワークプロバイダに特有の特徴（特定の圧縮アルゴリズムなど）を考慮に入れてもよい。さらにはユーザーが用いる特定の装置に関する特徴、例えば装置の有するスピーカーの変換器効果などを考慮してもよい。また、ユーザーが有する別の聴取装置、例えば補聴器および／もしくはインプラントなどを考慮に入れてもかまわない。

さてまず段階 S1 では、通信網中のネットワークエンティティ（音響拡張コンポーネント 20 に含まれたエンティティまたはサーバなど）と、ユーザー（ユーザー 14 など）が有するユーザー装置とのあいだに確立された通信リンクを介して、聴取試験がユーザーに対して行われる。このユーザーがサーバに接続開始したこと（聴取試験を提供するサービスプロバイダーへの連絡番号にユーザーが電話を掛けることなど）を以って、ネットワークエンティティとユーザー装置のあいだに通信リンクが確立されるようにしてもよい。あるいは、サービスプロバイダーがユーザーの持つユーザー装置へと（予め定めた時刻などに）発呼してもよい。ともあれ、通信リンクが確立していても、通信網中のネットワークエンティティとユーザーの持つユーザー装置とのあいだに別の通信リンクを確立しそれを介して聴取試験を行ってもよいことは理解されたい。

或る実施形態では聴取試験がプラットフォームを使ってもよい。そのプラットフォームは、通話に使うメディア拡張プラットフォームと同じものでもよいし、またはそれに類似した別のプラットフォームでもよい。代替的にか追加的に、聴取試験でweb上の試験ポータルを使ってもよい。この際、ユーザーの電話からの自動発呼および／もしくはユーザーの電話への自動着呼をしてもよい。こうしたポータルでは、ユーザーにスクリーン上のプロンプトや指示を与えて試験工程の案内をでき、その際にはメディア拡張プラットフォームを使った相互作用を伴っていてもよい。

聴取試験の実行は、自動的でもよいしまたは半自動的でもよい。例えばユーザーが、サーバ／サービスプロバイダから自動提示されるプロンプトに従ってもよい。あるいは別の手法としてユーザーが、聴取試験を行うサービスプロバイダの人間のオペレーターと直接話すようにしてもよい。こうしたプロンプトは、視覚的プロンプトおよび／または音声的プロンプトであってよい。こうしたプロンプトはユーザーの持つユーザー装置上に表示されてもよい。またこうしたプロンプトの提示が、聴取試験を行うためのサーバと通信しているユーザー装置上でそのままなされてもよい。あるいは別の手法として、プロンプトが別のユーザー装置に提示されてもよい。例えばユーザーがラップトップまたはタブレットに表示されたプロンプトに従って、サービスプロバイダのサーバと通信リンクで結ばれた別のユーザー装置を介して聴取試験を受けるようにしてもかまわない。

段階 S2 では、ユーザーへ聴覚刺戟を与えることが聴取試験に含まれる。こうした聴覚刺戟は、複数種の試験周波数にてユーザー装置へと与えられることになる。

或る実施形態では、聴覚刺戟が白色雑音を含んでよい。こうした白色雑音は一種以上の人間の声に基づくものであってもよく、ユーザー装置上でユーザーが通常耳にする類の音声（電話通話中の声など）を正確に模倣したものであってもよい。或る実施形態では聴覚刺戟が、1/3オクターヴ幅帯域の雑音を含んでよい。

或る実施形態では、複数種の試験周波数にてユーザーへ聴覚刺戟を与える工程が、聴覚刺戟を500Hz、1000Hz、2000Hz、3000Hz、6000Hzのうちの二種以上で聴覚刺戟を与えることを含んでよい。なおこれらの値はあくまで例示であって、別の値を用いてもかまわないし、500Hz未満の周波数や6000Hz超の周波数を用いてもさしつかえない。例えば広帯域音声コーデックや超広帯域音声コーデックのために6000Hz超の値を使うこともできるし、または狭帯域コーデックのために3000〜3400Hz以下を用いてもよい。白色雑音は、所定の順序に従って複数種の試験周波数で再生でき、例えば500Hz、1000Hz、2000Hz、3000Hz、6000Hzの順に再生してよい。周波数の変化は、段階的に行ってよい。

段階 S3 では、ユーザー装置で受信された聴覚刺戟に対する応答を監視する。この工程には、応答を測定することが含まれていてもよい。応答を監視することで、ユーザーが再生される聴覚刺戟を聞いたかどうかを効率的にチェックできる。こうした監視には例えば、ユーザーからのフィードバック（電話または関連するラップトップやタブレットなどといったユーザー装置上での打鍵など）を監視すること、またはユーザーからの音声による応答を監視することも含まれてよい。

聴覚刺戟を再生してユーザーへと与えるに先立って、ユーザーからその聴取能力に関する情報を取得するようにしてもよい。或る実施形態ではそうした情報に、性別および／もしくは年齢に基づいて少なくとも一部を推測したものおよび／または予め定めたものが含まれてもよい。この工程には、ユーザーの難聴の指標を取得することが含まれてもよい。またこの工程には、ユーザーの難聴の程度が、種々の制度で定める基準に則って所見無し、軽度、中度、重度、または重度から重篤であるかについての情報を取得することが含まれてよい。ユーザーにこうした情報の提供を求めてもよい。ユーザーの難聴の指標を使って、聴取試験の初期音量を定めることができる。そして聴取試験中の聴覚刺戟の音量を、監視している応答に沿って調節できる。例えばユーザーから肯定的な応答があったときに、次の聴覚刺戟の音量を下げてもよい。音量を下げるときは5dB刻みで下げることができる。もちろん別の実施形態ではこの刻み幅を変えてもよい。ユーザーから無応答だったら、本方法が聴覚刺戟の音量を上げることを含んでよい。音量を上げる工程には、10dB刻みで音量を上げることが含まれてもよい。もちろん別の実施形態ではこの刻み幅を変えてもよい。或る実施形態では聴覚刺戟の音量を、試験周波数ごとに調節してもよい。

或る実施形態では、各聴覚刺戟の期間が1000msまたは1000ms程度であってよい。もちろんこれは非限定的な例示であって、他の実施形態では聴覚刺戟の期間を別の値にすることもできる。各聴覚刺戟のあいだに音量を変化させてもよいし、それぞれ別の音量を使ってもよい。例えば各聴覚刺戟が、暗騒音レベルから60dB（もしくは60dB近傍）までのあいだで音量を上下させる一箇所以上の傾斜を有してもよい。なおこの60dBという値はあくまで例示であって、他の実施形態では別の値を使ってもよい。

聴取試験に基づき、かつ段階 S4 に示したとおり、聴取プロファイルをユーザーのために生成できる。これを聴取プロファイル閾値と考えてもよい。この聴取プロファイルには、ユーザーの難聴の程度の正確な測定結果が含まれており、通信網効果（信号品質や通信網の雑音など）を考慮に入れるだけではなく、ユーザー装置に関する効果（変換器効果など）をも考慮に入れている。

生成した聴取プロファイルは、ネットワークエンティティのメモリーに保存できる。このネットワークエンティティは、ユーザーの持つユーザー装置と通信リンクを有し聴取試験を行ったネットワークエンティティと同じものであってもよい。あるいは別のネットワークエンティティまたは別の装置に保存してもかまわない。この工程は段階 S5 に示した。さらに聴取プロファイルを別のエンティティに保存するようにしてもよく、例えば他のネットワークのエンティティやユーザー装置に保存するようにしてもかまわない。聴取プロファイルの保存にあたっては、その聴取プロファイルとユーザーおよび／またはユーザー装置とのあいだに関連づけをするようにしてもよい。例えばその関連づけを探索表に保存してもよい。そうすることで、ユーザー装置に音響信号を送り変調する際に、そのユーザーの聴取プロファイルを見出して使用できるようになる。換言すれば、保存した聴取プロファイルを利用して、ユーザー装置への音響信号を変調できるというわけである。当然のことながらネットワークエンティティには、ユーザーおよび／もしくはユーザー装置と、それに関連する聴取プロファイルとの間の関連づけを、複数個（数百、数千、数百万個など）保存できる。或る実施形態では、ユーザーに関連づけられる情報に、そのユーザーの識別子が含まれていてもよい。そうした識別子は唯一識別子でもよい。また識別子が例えばユーザーの氏名であってもよい。追加的にかまたは代替的に、識別子がユーザーの持つユーザー装置の識別子を含んでいてもよい。例えばそうした識別子として、ユーザー装置のMSISDNが挙げられる。

或る実施形態に係る聴取試験には、その聴取試験の出力を処理し微調整する工程が含まれていてもよい。このような工程は、ユーザーがネットワークエンティティと通信している最中に行われてもよいし、あるいはユーザーが聴覚刺戟を聞き終えた後に行うことも可能である。こうすることで、ユーザーの自前の耳に合わせて聴取プロファイルを微調整すること、および／またはユーザーが有する別の聴取装置（補聴器や蝸牛インプラントなど）に合わせて聴取プロファイルを微調整することが可能になる。つまり本方法は、ユーザーおよび／もしくはネットワークエンティティと接続しているオペレーターに対して、聴取試験の結果を視覚的に提示することを含んでよい。こうした微調整は、ユーザーが例えばそのユーザー装置から行ってもよいし、あるいはラップトップやタブレットなどの別の装置から行ってもかまわない。追加的にかまたは代替的に、通信網と接続しているオペレーターが微調整を行ってもよい。そうしたオペレーターとしては例えば、音響変調サービスを提供しているサービスプロバイダーの従業員が挙げられる。

図13は或る実施例に係る方法を示すフローチャートであって、ユーザー装置からの視点で見たものである。

まず段階 S1 にてユーザーは、ネットワークエンティティと通信リンクを確立したユーザー装置を介して、聴取試験に参加する。

段階 S2 でユーザー装置は、通信リンクを介して複数種の試験周波数にて聴覚刺戟を受信する。つまりこの聴取試験は上述したやりかたに沿って行われる。

段階 S3 でユーザーは、聴覚刺戟への応答を一回以上行いネットワークエンティティへ返す。この応答は、ユーザーが聴覚刺戟を聞いているユーザー装置を介して提供されてもよいし、あるいはユーザーが持つ別の装置（ラップトップやタブレットなど）を介して提供されてもかまわない。

その後に段階 S4 でユーザーは、変調された音響信号をユーザー装置で受信できる。この変調された音響信号は、上述したように聴取試験を承けてそのユーザーのために作られた聴取プロファイルに基づいて変調したものである。

変調した音響信号は、ユーザーが持つユーザー装置へとリアルタイムに送達できる（し、最終的にはユーザーの自前の耳、補聴器、またはインプラントなどへと送達できるわけである）。さてここで聴取試験を行って聴取プロファイルが保存されているユーザーのことをユーザーAとおいた例を考えてみよう。ユーザーAの識別子（MSISDNなど）は、通信網中にユーザーAの聴取プロファイルと関連づけて保存されている。そして第二のユーザーであるユーザーBが、ユーザーAへと発呼すると、ユーザーAの聴取プロファイルがメモリから取得され、呼はユーザーBの声（とその他の音響信号）を以って継続するが、そのユーザーBの声はユーザーAの聴取プロファイル（いわば「声紋」）に従って変調されたものとなる。こうした音響信号の変調には、音響信号のフィルタリング、音響信号の振幅調整、音響信号の周波数調整、音響信号の音高および／もしくは音程の調整のうちの一種以上を含んでよい。或る実施形態では音響信号の変調を、そのネットワークエンティティかまたは別のネットワークエンティティに在る音声処理エンジンによって実行可能である。

或る実施形態では、ユーザー装置の在る地点における周囲騒音を記録してもよい。そうした周囲騒音は、ユーザー装置が有する一個以上のマイクロホンを使って録音できる。周囲騒音の情報を通信網へ送ってそこで保存させてもよい。例えば通話中に周囲騒音の情報をリアルタイムに収集して保存してもよい。そうして得られた周囲騒音の情報を使って、変調した音響信号をユーザー装置へリアルタイムで送達できる。

音響信号の変調については、その一例を以下でさらに詳述していく。

FFTに基づく信号処理機能の概要
デジタル音声というのは通常、時系列に並ぶ一連の音響サンプル群からなるものと考えてよい。これが連続した音に聞こえるようにしておくためには、新しいサンプルを所定期間毎にアナログに変換していく必要がある。ここで言う所定期間とは、サンプリング周波数の逆数である。しかし、このアルゴリズムを使った実際の音響処理は、サンプル毎に連続して行う必要は無くて、音響サンプルの「フレーム」毎に行えばよい。このフレームとはサンプル128個分の長さになる。各フレームにて行われる読み出しと書き込みは、その前のフレームと50%重複するようにしてもよい。すると音響ストリーム中の各サンプルを実際には倍速で処理できるようになる。

フレームの処理レートは、音響サンプリングレートよりもさらに遅くしてよい。
FsFFT = Fs/(framelength/2)
ここでFsFFTはフレームのサンプリングレートであり、Fsは（音響サンプルの）Hzで表すサンプリングレートであり、framelengthはフレーム中のサンプルの数を示す。処理中のサンプリングレートはいつも一定値（16kHzなど）になるのが通常ではあるが、音響ストリームが別のレートで着信した場合には、サンプリングレート変換をその二種のレートのあいだの値にて行ってもよい。

或る実施形態では、128サンプル長で16kHzでのFFT（高速フーリエ変換）を用いてよい。とまれ、このアルゴリズム上の要請によっては、各FFTフレームに挿入する音響サンプルの個数を使わなくてはいけない場合もありうる。

異なる二種のサンプリングレートが同時に走っているときには、二種の処理を並行して走らせて処理を連続的に行わせる必要が出てくる場合もありうる。
(1) 割り込み方式処理。入力ストリームからサンプルを取り、入力バッファに置くとともに、出力バッファからサンプルを取り、出力ストリームに置く。
(2) フレームに基づく処理。現在の入力／出力サンプルバッファがそれぞれ満杯になるかまたは空になる前に、完了させることができる。

この「重複-加算」overlap-add処理の形態における入力と出力とのあいだの音響時間遅延の最小値は、一例としてフレーム長の1.5倍にできる。割り込み方式処理のためのバッファポインタは、満杯／空になったフラグが立ったときに、1サンプル期間（1/Fs）中に更新できる。さもなくば、音響のスタッタリングが起きている可能性がある。フレーム処理に充分な能力が与えられているならば、入力／出力バッファが尽きるか満杯になる前にフレーム処理を行える筈である。

以下には、処理を表す模擬コード例を示してある。工程の主要機能には太字（訳註:原文では太字になっている）のローマ数字（0、I、II、III、IV、V、VI）をつけた。また処理が有する下位工程は、標準字体で(1)のように番号を振ってある。工程で条件分けがあるときは、条件を小数点以下の数字で1.1、1.2、…のように示した。

(0) 開始: 以下のいずれかがバッファに蓄積されているかを推測する。
(0.0) サンプリングレート8kHzにて音響サンプルが32個、または、
(0.1) サンプリングレート16kHzにて音響サンプルが64個
ここでバッファはinput(i)と称し、サンプリングレートに依ってi = 0....31または0...63である。処理は次に進む。

(I) 全ての音響サンプルを、単精度（4-byte）浮動小数点フォーマットの線形表現サンプルに変換する必要がある。このため、いずれの即時圧縮も元に戻すようにしなくてはならない。
(1.1) サンプルが「mu-law」コーディングされているか、もしくは
(1.2) 「A-law」コーディングされているか、または
(1.3) 何らかの他の非線形コーディングフォーマットであるとき。
これらは（探索表を使った）逆関数で元に戻すことができる。

模擬コード:
xt_lin = inv_law(input);
ここでxt_linは線形フォーマットのサンプル値であり、inputは入信してきている最新のバッファである。inv_law()は、圧縮サンプル値（8bit整数、すなわち256エントリの表で足りる）と、その線形サンプル値の浮動小数点表現とをつなぐマッピング関数である。或る実施形態では、この処理を一度に一つのバッファに対して行うようにして、サンプル毎に関数呼び出しを何度も行わなくてもよいようにもできる。

(II) 二種のサンプリングレートのうちのいずれか、つまり8kHz（標準的電話のレート）かまたは16kHz（広帯域）のいずれかでデータが到着するかを予測する。すなわち或る実施形態では、全ての処理を固定長の「フレーム」において16kHzサンプリングレートで行う。

(1) サンプリングレート変換をFFTストラクチャ内で実行できる。
各FFTフレームは、最新の入力バッファで半分埋まっており、残りの半分は前の入力バッファで埋まる。つまり、隣接フレーム間でサンプルの50%が重複していることになる（各入力バッファは、二つの連続するフレームに現れる）。また挿入された音響サンプルの外をゼロ埋め（zero-padding）してあってもよい。

(2) 128サンプル長を持つ空のフレームを構築し、線形にコードされた音響サンプルを保持させるようにする（指数0〜127）。

模擬コード:
x = zeros(128,1);

(3.1) 音響が8kHzサンプリングレートであれば、最新の32個の音響サンプルが到着した後に、これらのサンプルを、xでの指数位置65, 67, 69.....127にてinput(0......31)へ挿入できる。新たな処理シーケンス中の一番最初のフレームから、アレイの残りを埋めないままにしておいてもよい（すなわち、ゼロで埋めておいてよい）。その他のフレームの全てについては、指数位置1, 3, 5.......63を、前の入力バッファ(0.....31)からの32個のサンプルで埋めるようにしてもよい。

(3.2) 音響が16kHzサンプリングレートであれば、最新の64個の音響サンプルが到着した後に、これらのサンプルをinput(0......63)へ挿入し、フレームの指数位置64, 65, 66, .....127に置くことができる。新たな処理シーケンスの最初のフレームについて、そのフレームの残りを埋めないままにできる(0....63)。その他すべてのフレームについて、指数位置0, 1, 2, 3,.......63を前の入力バッファからの64個のサンプルで埋めるようにできる。

(4) window関数を生成する。これは対称な形状を持つ傾斜（ramp）であり、サイン波で0からpiで表せる。これを予め計算して小さいアレイに収めておき、処理中に再利用してもよい。このwindowの指数iにおけるサンプル値のことをW(i)と称する。

模擬コード:
for i = 0, 1, 2 .........127
W(i) = sin ((i+0.5)*(pi/N))
ここでpi = 3.14159265であり、Nは音響アレイサイズである（N = 128）。

(5) フレームアレイに「window」を開ける。これはつまり、音響ストリームとwindow W(i)とでサンプル毎に乗算しているということである。

模擬コード:
xw(i) = W(i) * x(i); for i = 0.......127

(III) このデータフレーム上に、前方FFTを施す。

(6) 模擬コード:
xf = fwd_fft(xw);
このFFT関数は同一長のアレイを生成するが、データ型は複素数を含めるように変換されることになる。

(a) 出力アレイが、正周波数と負周波数の二つに分かれていると考える。出力アレイ中の各点において、その等価な周波数は以下のように計算できる。
f(i) = i*Fs/N for i = 0,1,.......63 (2)
f(i) = (128-i)*Fs/N for i = 64, 65, ......127 (3)
ここでFsはサンプリングレート（16kHz）、iは128点アレイへの指数である（この関数が完全アレイに復帰していると推定）。Nはアレイのサイズである（N = 128）。式(2)はFFTアレイの「正周波数」側を定義するものであり、一方式(3)はこのFFTアレイの「負周波数」側を定義する。f(i=0)は0Hzであり実数であるので、平均レベル（DCレベル）を表す。Fs = 16,000、N = 128とおくと、「ビンの間隔」bin spacingすなわち(f(i+1)-f(i)) = 125Hzである。

(b) 音響データに合わせて設計された、より具体的には実数のみを含むデータに合わせて設計されたFFT関数を含んだライブラリもいくつかある。こうしたライブラリを使うと、正周波数についての値だけを含んだ半値幅アレイが生成されることになる。こうしたライブラリ関数は内部的には、負周波数成分に対して操作を施して、正しい前方変換と逆変換を生成しており、これによって処理量を削減できている。

(c) FFTから返るアレイが、正周波数成分と負周波数成分の双方を有していた場合には、正周波数領域中の周波数点に対して行った計算のいずれも、負周波数領域で繰り返す必要はない。つまり、等価な正周波数点の複素数結合だけを、跨いで複写すればいいのである。

(6.1) 入力音響ストリームが元々8kHzでサンプリングされていた場合には、FFTアレイ中で f(i) > 4000 (Fs/2) になる成分（アレイの両半分にもなりうる）をゼロにする必要がある。これは「エイリアシング」を除く作業であって、サンプリングレートを8kHzから16kHzへ変換する。

模擬コード:
i_stop_pos = round(4000*Fs/N);
i_stop_neg = round (128 - (4000*Fs/N) );
xf( i > i_stop_pos & i < 63) = 0;
xf( i < i_stop_neg & i > 63) = 0;
このround関数（丸め関数）は、分数の指数ができないようにして、サンプリングレートまたはNが将来変化しないようにするために用いられている。

(6.2) 入力音響ストリームが元々16kHzでサンプリングされていた場合には、処理は不要である。

(IV) コードの中枢: FFT中の挿入利得と圧縮を実装するためのソフトウェア（処理が挿入されない場合には、ループバック関数を使うのが効率的）。

ここでの圧縮システムは、周波数領域で作動するように設計されているが、音響信号を4チャネルに分割し、短期チャネル出力を計算し、これに基づいて動的に変化する利得を適用するものである。この利得は、音響信号を例えば聴力に障害のあるユーザーが快適に聞き取れるようなものに戻すマッピングを行う。

各ユーザーに必要な単発の事前計算をするためのソフトウェア
全てのユーザーは異なる聴取特性を持っているので、各ユーザーについての唯一の聴取支援設定を以下のように計算できる。

(A) 「65」dBのSPL発話のための挿入利得（IG）、すなわちIG65をFFT周波数の関数として得る。
利得の正確な値を、周波数の関数として聴力図測定を介して計算する。

模擬コード:
[freq_ig, gain_dB] = IG65(audiogram, age, hearing aid experience);
ここでfreq_igは対数スケールであってよく、gain_dBはデシベル単位の利得、すなわち線形利得の対数関数を表すことになる。

模擬コード:
gain_dB = 20 log10(gain_linear);
gain_linear = 10^(0.05 * gain_dB);
この利得は周波数領域にて、音響フレームのFFTに適用できる。したがって利得の値は、FFTの[freq_ig, gain_dB]グリッドから線形周波数グリッドへと内挿される。これを行うには、二種の異なる方法がある。第一の方法は、線形利得を線形周波数スケール上に内挿するものである。第二の方法は、対数利得（dB）を対数周波数スケール上に内挿するものである。

以下を前提とする:
f(i) = i*Fs/N for i = 0,1,....... 63 (2)
f(i) = (128-i)*Fs/N for i = 64, 65, ...... 127 (3)
（両側スペクトルFFT計算を推定）

模擬コード:
If (f(i) <min(freq_ig))
Glinf(i) = gain_lin(min(freq_ig));
Glogf(i) = gain_dB(min(freq_ig));
elseif (f(i) > max(freq_ig))
Glinf(i) = gain_lin(max(freq_ig));
Glogf(i) = gain_dB(max(freq_ig));
else
scale
Glinf = lin_interp(freq_ig, gain_lin, f);
Glogf = lin_interp(log10(freq_ig), gain_dB, log10(f));
end

まず最初のifループでは、周波数のための処理利得が、IG65アレイの最低値を下回るかどうかを判定できる。条件が真であれば、対数利得を、最小周波数値を使って対数周波数へと内挿できる。

第二のelseifループでは、周波数のための処理利得が、IG65アレイのそれを上回るかどうかを判定することになる。条件が真であれば、対数利得を、最大周波数値を使って対数周波数へと内挿できる。

いずれの条件も偽であったならば、利得の値を線形に内挿できる。

元の挿入利得アレイの外の周波数にて利得の値を求められる場合には、外挿はされないが、同じ利得の値を、挿入利得アレイの関連する端から展開する。

なお、log10(f)またはlog10(freq_ig)は、f = 0またはf < 0とならないように留意されたい。エラーの原因となりうるからである。

内挿するための模擬コード:
NewY(i) = OldY(f(j)) + (OldY(f(j+1) - OldY(f(j))) * (NewX(i) - OldX(j)) / (OldX(j+1) - OldX(j));
ここでOldX(j)とOldXf(j+1)は、既知の(x,y)関数中のX点であって、NewX(i)の値を束縛する。NewY(i)を計算するのが望ましい。

(B) IG65の適用後に、発声形状の雑音のためのチャネルレベルを計算。
これは較正手順の一部をなす。FFTアレイへ適用される利得には、二つの主段階がある。すなわち(i) 前述した挿入利得（65dBのSPL発話のためのもの）と、(ii) 動的圧縮利得とである。ユーザーに特化した挿入利得は、動的範囲圧縮ソフトウェアに優先して適用できる。65dBのSPLによる発話入力のためには、利得の組み合わせを、前述した挿入利得と同じにする必要がある。補正係数の算出にあたっては、圧縮器のためのチャネル出力が、65dBのSPL発話雑音が適用される際に生成されるそれになるとき、動的圧縮利得が0dBになるようにできる。このような状況下でチャネルレベルを計算するわけである。これをFFT領域で行うわけであるが、好ましい実施形態では挿入利得が指定されるレベルと同じデジタルRMSを備えた信号ファイルを以って完了できる。MASによって望みのスペクトラムを有する2秒の雑音ファイルが得られるが、所定の参照レベルに応じて使用前にスケール変更することもできる。チャネルのエッジ周波数を、圧縮システムのために計算してもよい。こうすることで、FFT処理中に音響信号を別々の3個または4個のチャネルに分割し、それらを半独立的に操作できるようになる。FFT領域で計算が完了するので、帯域フィルタリングが既に済んでいることになるが、それは固定の線形周波数グリッドに対してである。チャネル出力を計算するには、我々が望むチャネルの帯域通過セクションに存する個々のFFTビンからの出力を足し合わせることで行える。FFTビンで出力を足すわけだが、チャネルの「エッジ周波数」はFFTの「ビン」同士の中間になる。つまりn*125 + 125/2 Hzであり、ここでnは整数である。

(a) 発話が300〜3400Hzを占め、信号のエッジにおける遷移帯域が許されるようなPOTS。ここでFFTビン数はChanjFFTbin{Start/End}と称する。
周波数幅 FFTビン数
チャネル(1) 250〜750Hz 2〜6
チャネル(2) 750〜1500Hz 7〜12 (NBは750Hzのビンで二重に数えない)
チャネル(3) 1500〜3500Hz 13〜28 (NBは1500Hzのビンで二重に数えない)
チャネル(4) 3500〜3875Hz 29〜126 (ダミーチャネル、信号の搬送はしない)

(b) 広帯域の発話。ここでFFTビン数はChanjFFTbin{Start/End}と称する。
周波数幅 FFTビン数
チャネル(1) 0(DC)〜750Hz 0〜6
チャネル(2) 750〜1500Hz 7〜12
チャネル(3) 1500〜3500Hz 13〜28
チャネル(4) 3500〜7875Hz 29〜126
このようにして、FFT領域で雑音較正信号を処理し、チャネル出力の平均レベルを構成する。

模擬コード:
(i) アレイの初期化（最初にだけ必要）。
for j = 1, 2, 3 ; ChannelPower65(j) = 0; end

(ii) 挿入利得をxfに適用。
xf_ig(i) = xf(i) * Glin(i);

(iii) 各FFT「ビン」における出力を計算。
BinPower(i) = xf_ig(i) .*conj(xf_ig(i);

(iv) 各ビンの出力を、関連する圧縮チャネルに足し合わせる。開始ビンと終了ビンは上述のとおりであり、変数として ChanjFFTbinStart から ChanjFFTbinEnd を使う。
for j = 1, 2, 3, 4
ChannelPower65(j) = sum( BinPower(i) );
ここで「i」の値はいくつかのビンに跨る。「ChannelPower65」ベクトルは、較正信号の処理中に生成される各フレームごとに計算される（指数としてkを使う）。すると、
CalibPower65(j) = mean (ChannelPower65(j, k));
となり、最後にこの出力をdBに変換する。
CalibLevel65dB(j) = 10*log10(CalibPower65(j) ); for j = 0....3;
なおここで言う10*log10()には、暗黙のsqrt()が含まれており、 CalibPower から CalibMagnitude へ変換できるようになっている。挿入利得とCRは各個別ユーザーごとに選択されるが、その他のパラメータはその限りではなく、良好な音響品質を得るように以下のように定めておいてもよい。

(a) チャネル圧縮閾値 Chan_dBthr は、65dBの発話形状の雑音を搬送するときのチャネルレベル Chan0dBGn_lvl に対するデシベル数で表される。 Chan_dBthr は0から-15の範囲をとる。

(b) チャネル圧縮器のためのattack時間 att とrelease時間 rel とは、ミリ秒単位で表わされ、圧縮器が入力レベルの変化に応答する速度を意味する。attack時間（信号レベルが上昇しているとき）は通常、release時間（信号レベルが降下しているとき）よりも小さくなるが、2:1以上の比になる。

(c) チャネル圧縮リミッターが上述のチャネル圧縮器の出力をカットをする相対レベル deltaFSdB は、デシベル単位で表され、通常は10〜20の範囲になる。

(d) チャネルリミッターについてのattack時間 t_att_lim とrelease時間 t_rel_lim はそれぞれ通常、3msecおよび80msecに設定される。

(C) 処理の一番最初に、以下の計算を"各チャネル毎に"完了しておくことができる（各変数はチャンネル毎に計算しておけるとする）。

(C.1)
Expon = (1 - CR)/CR
ここで[CR]が1を下回ることはないようにできる。

(C.2) 圧縮閾値はdB単位で表され、線形値に変換される。
cthresh = 10^(.05*Chan_dBthr)

(C.3) チャネル較正係数を計算する。これを65dB発話を搬送するときのチャネルレベルに参照する。つまりこれを上記B節のように計算した理由である。
G0dB_norm = (10^(-.05*CalibLevel65dB))^Expon

(C.4) 定数を計算して、短期平均レベル I の算出に用いる系のattack時間とrelease時間を実施する。これらの時間は、圧縮器への入力において35dB幅のレベル変化が適用された際に、利得信号が最終値から3dB以内に安定するまでの時間（attacking）、また利得信号が最終値から4dB以内に安定するまでの時間（releasing）として定義する（なお、この35、3、4という数字はまた下で出てくる）。CRがとても低い値のとき、典型的には CR < 1.2 のときには、総利得変化は3〜4dBをわずかに上回る程度であるが、これは計算にエラーが生じているおそれがあるということである。そこで、少なくともこの利得変化をする圧縮器についてエラーチェックを行う。短期平均レベル I の計算は、算出したサンプリングレートを使ってフレーム毎に更新する。この計算はFFTサイズ（FFTsize）、重複（overlap）の程度、およびサンプルに基づくサンプリングレートに依存する。
FsFFT = Fs/(FFTsize/Overlap) = 16000/(128/2) = 250;
秒あたりのフレームを計算する。FFTフレーム（FFTframes）間の重複は50%なので、"/2"が要るわけである。

計算は以下のようになる。
(i) min_dstpdB = 35/8;
低いCRにて問題が起きていないことを確認するための計算である。用いる値は8で割り、4dB変化幅よりも大きくなるようにするので、 CR <= 1.14 のとき有効である。

(ii) dstp_att = max(min_dstpdB, 35 - 3*CR/(CR - 1));
利得変化の最大値を選び出す。

(iii) dstp_rel = max(min_dstpdB, 35 - 4*CR/(CR - 1));
利得変化の最大値を選び出す。

(iv) k_att = 10^(0.05*(-dstp_att/(t_att*FsFFT/1000)));
t_att をミリ秒単位に換算する。

(v) k_rel = 10^(0.05*(-dstp_rel/(t_rel*FsFFT/1000)));

(C.5) 定数を計算して、各チャネルが過負荷にならないようにするための圧縮器リミッターの持つattack時間とrelease時間を実施してもよい。

(i) CRlim = 100;
非常に高いCRにして、真のリミッターを得る。

(ii) dstp_att = max(min_dstpdB, 35 - 3*CRlim/(CRlim - 1));
dstp_rel = max(min_dstpdB, 35 - 4*CRlim/(CRlim - 1));

(iii) k_att = 10^(0.05*(-dstp_att/(t_att_lim*FsFFT/1000)));
k_rel = 10^(0.05*(-dstp_rel/(t_rel_lim*FsFFT/1000)));

(iv) ExponLim = (1 - CRlim )/CRlim;

(v) deltaFSlin = 10^(-0.05*deltaFSdB);
チャネル圧縮器の動作と、リミッターの動作との差分比。

(C.6) チャネル平均レベルの最新版を搬送することになる「状態」stateベクトルを初期化する。
for j = 1, 2, 3, 4
ChanMeans(j) = Cthresh(j);
ChanLimMeans = Cthresh(j);
End

(D) フレームに基づく処理
すべてのFFTフレームについて、アレイは周波数領域サンプルの(xf)を持つと予想される。処理するFFTアレイと予め計算する定数（挿入利得、圧縮器設定、較正定数）は除くと、チャネル圧縮器の移動平均の「状態」ベクトルが、チャネルリミッターを通過できることになる。

模擬コード:
function [xfproc, ChanMeans, ChanLimMeans] = implement_hearing_aid(xf, ChanMeans, ChanLimMeans );
以下の工程も含む。

(D.1) 利得の線形挿入の実施。
xf_ig(i) = xf(i) * Glin(i)

(D.2) 較正時にチャネルレベルを計算したのと同様の手法で、圧縮器チャネル出力を計算する。

(i) for j = 1, 2, 3 ; ChannelPower65(j) = 0;
アレイの初期化。一番最初のときだけに必要である。

(ii) 挿入利得を xf に適用。
xf_ig(i) = xf(i) * Glin(i);

(iii) 各FFT「ビン」での出力を計算。
BinPower(i) = xf_ig(i) .*conj(xf_ig(i);

(iv) 各ビンの出力を、関連する圧縮チャネルに足し合わせる。開始ビンと終了ビンは上述のとおりであり、変数として ChanjFFTbinStart から ChanjFFTbinEnd を使う。
for j = 1, 2, 3, 4
ChannelPower(j) = sum( BinPower(i) ); （NB 'i' はいくつかのビンに跨る）
ChannelLevel(j) = sqrt( ChannelPower(j) );
end
この計算では、sqrt()関数が重たい演算処理になっているように見える。

(D.3) 各圧縮チャネル毎に一つずつとして、計四つの利得を計算できる。こうして移動平均が得られる。新たな信号レベルが、以前に測定した平均レベルよりも高い場合には、その信号は「attacking」であるとみなす。信号を「attacking」であるとみなしたときは、高速attack時定数を使う。新たな信号レベルが、以前に測定した平均レベルと同じか低い場合には、その信号は「releasing」であるとみなす。信号を「releasing」であるとみなしたときは、低速release時定数を使う。max()関数を使って、 NewChanMeans が圧縮器閾値未満に降下してしまうのを防ぐ。これを実施しなかったならば、無音状態が長く続いた後に高レベルが発生した際に、圧縮器は長時間をかけて非常に低い平均レベルを出力してしまうだろう。

(i) チャネル圧縮器とそのリミッターの双方に対して、新たな平均値を生成。
for j = 1, 2, 3, 4
圧縮器に対して新たな ChannelMean を計算。
if ChannelLevel(j) > ChanMeans(j)
k = k_att;
else
k = k_rel;
end
NewChanMeans(j) = max(cthresh(j), (1-k).* ChannelLevel(j) + k.*ChanMeans);
リミッター値の計算は、平均値の計算と同様の手法でできる。リミッターの平均値は、圧縮器レベルに合わせて動く。
LimiterLevel(j) = ChanLevel(j)*deltaFSlin(j);
if LimiterLevel(j) > ChanLimMeans(j)
k = k_attlim; %% FFT実装ではこれを統一できる。
else
k = k_rellim;
end
NewLimMeans(j) = max(cthresh(j), (1-k).* LimiterLevel(j) + k.*ChanLimMeans(j));
end

(ii) 新たな平均レベルから圧縮器利得を計算するだけでなく、或る実施形態ではリミッター平均と圧縮器平均の比に基づくさらなる利得低減に加える。(a)除算と(b)二回の冪乗が演算的に重たいが、探索表を使って冪乗を不要にすれば軽くできる。
Gain(j) = (NewChanMeans(j) ^ Expon(j) ) * G0dB_norm(j);
if NewChanMeans(j) < NewLimMeans(j) // リミッターが割り込んでくる。
Gain(j) = Gain(j) * (NewLimMeans(j)/NewChanMeans(j)) ^ ExponLim(j));
end

(iii) 4チャネル利得を、FFTアレイサイズにまで拡張する。各利得はビンの指数に割り当てられる。このビンの指数は、対応するチャネル出力の計算に用いたものである。指数は変数 ChanjFFTbinStart から ChanjFFTbinEnd までに格納されている。
処理の最初に一度アレイを初期化。
GainFFT = zeros(1,NFFT);
そしてすべてのフレーム（と、必要であればFFTアレイを埋めるときの負周波数を考慮して）について以下を行う。
for j = 1, 2, 3, 4
GainFFT(ChanjFFTbinStart(j)...... ChanjFFTbinEndChannelPower(j) = Gain(j);
End

(iv) こうすることで、 GainFFT はチャネルエッジにて矩形段を持つアレイとして残される。このため、値を時間領域へ書き戻すときにエラーが出るおそれがある。そこでエッジ値を3タップFIRフィルターを使ってスムージングする。この3タップFIRフィルターの係数は、 Tap3 = [0.28 0.44 0.28] であり、 k を指数にする。このフィルターは、（周波数領域の）アレイの半分に亘って前後に「動く」ことになる。つまりこのフィルタリングは、Gain関数を開始点から「動かす（シフトさせる）」わけではないことに留意されたい。またこのフィルターは対称FIRフィルターなので、前方に動くのも後方に動くのも同じであるから、二度目の通過についても、開始アレイを変える以外は同じコードを適用できる。

(iv.1) 通過1: アレイの終端にてありえる重複／指数の問題を除去。
for i = {0, 63}
SmootheGain1(i) = Gain (i);
end
エッジ値にてFIRフィルターをかける。
for i = 2.....62
SmootheGain1(i) = Gain(i-1)*Tap3(1) + Gain(i)*Tap3(2) + Gain(i+1)*Tap3(3);
end

(iv.2) 通過2: アレイの終端にてありえる重複／指数の問題を除去。
for i = {0, 63}
SmootheGain2(i) = SmootheGain1 (i);
end
エッジ値にてFIRフィルターをかける。
for i = 2.....62
SmootheGain2(i) = SmootheGain1(i-1)*Tap3(1) + SmootheGain1(i)*Tap3(2) + SmootheGain1(i+1)*Tap3(3);
end

(iv.3) 必要であれば、 SmootheGain2 アレイを負周波数に出戻るように拡張。

(iv.4) 圧縮器利得を、既に挿入利得を適用したアレイへと適用する。
for i = 0.....63
xf_proc(i) = xf_ig * SmootheGain2(i);
end

(iv.5) これらの平均レベルを保持している変数を更新して保存。
ChanMeans = NewChanMeans; // 4チャネル
ChanLimMeans = NewLimMeans; // 4チャネル

(iv.6) 更新された平均に従って関数から xf_proc が返る（または、次のフレームまでそのまま保存する）。

(V) このデータフレームに対して逆FFTを行う。

(i) 模擬コード:
xproc = inv_fft(xf);
音響に特化した逆FFT関数を使わなければ、この関数の出力は実数になるはずである。なので出力が複素数のアレイで返った場合には、展開中にチェックを行って虚数部をゼロにしてもよい。チェックを行った後、虚数部を破棄して実数部を残す。さらに、前方と後方のfft()関数が相互的であるなら、音響のスケーリングにおいては何も変更しなくてよいことになる。

(ii) 上記(5)節にて述べたwindowing関数と同様の逐次積算を行う。
模擬コード:
for i = 0.......127
xwproc(i) = W(i) * xproc(i);

(VI) 新たなデータフレームを、出力音響ストリームに挿入。
xwproc のうち最も古い64個のサンプル(0.....63)を、 xwproc の前のフレームの最後の64個のサンプルと重複させ、足し合わせて次に出力ストリームへ送信可能な時間バッファとして指標づけする（最後の出力バッファを出力ストリームが再生し終わったところで用意する）。この工程のことを、「重複足し合わせ」overlap-addプロシージャと呼ぶ。 xwproc からの後者の64個のサンプルは、次の xwproc の版の到着に備えて保存しておく。

(i) 模擬コード:
output16(i) = xwproc(i) + xwproc'(i+64); for i = 0......63
xwproc' = xwproc; // アルゴリズムを次に反復するときのために保存
ここで xwproc' は、以前に計算したフレームである。また"output16"は、音響サンプル64個分の長さを持つアレイであって、サンプリングレートは16kHzである。

(ii) 或る実施形態では、元の音響サンプリングレートが8kHzであった場合に、 output16 の奇数番要素からなる出力バッファを生成する。既に上記工程III(6.1)にてローパスフィルターを掛けてあるのでエイリアス成分は存在しないから、さらにローパスフィルターを掛ける必要がない。
模擬コード:
output8 = output16(1, 3, 5, .........63);

或る実施形態では、元の音響サンプリングレートが16kHzであった場合に、出力バッファを output16 と同一にできる。

まとめるとフレームに基づく処理では入力バッファ（8kHzで32サンプルサイズまたは16kHzで64サンプルサイズ）を取り込んで、ひとつの出力バッファ（8kHzで32サンプルサイズまたは16kHzで64サンプルサイズ）を生成し、入力と出力のあいだで音響が一定に流れつづけるようにできる。

このような重複足し合わせを伴う二重windowing関数では、逆FFT出力アレイが重複するような統一再組換（unity recombination）ができる。そのフレームレートにて出力音声に「蜂音」buzzが混ざった場合には、エラーが生じている可能性がある。

或る実施形態では、ユーザー装置のユーザー、またはネットワークオペレーターが、音響信号の変調を行う設定を選択的に有効化または無効化できるようにしてもよい。こうすることで、例えば何らかの理由でユーザーが音響変調を必要としない場合に有益になる。また、ユーザーの持つユーザー装置を、音響変調を必要としない別の人々も使うような場合にも有益であろう。

図14にはユーザー装置 1400 としてさらなる態様を示してある。ユーザー装置 1400 は携帯電話であってもよいし、あるいは何か別種のデジタル装置でもよい。ユーザー装置 1400 はディスプレイ 1402 を有する。またユーザー装置 1400 は、複数のマイクロホンも含み、図では黒丸 1404 で示してある。この例では、装置が十二個のマイクロホンを有する。他の例では、それより多いか少ない数のマイクロホンが備わっていてもよいことは理解されたい。こうしたユーザー装置は、上述した実施形態と協働できる。マイクロホン 1404 の列は雑音を受信し、その雑音の情報をネットワークへ伝送して上述したように処理できる。マイクロホン 1404 が方向集束性を有してもよい。またマイクロホンが、ユーザー装置 1400 のオペレーティングシステムとリンクしていてもよい。翻ってオペレーティングシステムの方も、ユーザーの聴取プロファイルと通信可能にリンクすることにより、その人に特異的な音響信号調整が可能になるわけである。一例としてユーザー装置 1400 を、机の手前または支柱の上に置いて、音響信号（声や音楽など）を拾えるようにしてもよい。そしてユーザー装置 1400 は音響信号を通信網へと送り、そこで音響信号をそのユーザー装置を持つユーザーに合わせるように、そのユーザーの聴取プロファイルに基づいて処理させることができる。

ユーザー装置 1400 はさらに、コーティングまたは層 1406 を有する。コーティング 1406 は、金属帯の形態またはコイルの形態を取ってよい。コーティング 1406 が、アンテナ、および／もしくは誘導ループ、および／もしくはTコイル（テレコイル）として機能してもよいし、あるいは、ユーザー装置 1400 からユーザーの有する補聴器へと通信するための何らかの他の補助装置または付属品として機能してもかまわない。さらにコーティング 1406 が、バッテリー、および／もしくはプロセッサー、および／もしくはメモリーを含んでいてもよく、これによってユーザー装置 1400 のバッテリー寿命を伸ばしたり、および／または処理能力を高めたり、および／または記憶容量を増やしたりできる。こうすることで、Tコイルその他の用途により補聴器と接続する援けにもなる。またコーティング 1406 が、タグ付け機能および／もしくはIoT機能を組み込まれて有していてもよい。こうした機能では、ユーザーの唯一のHearing Identification Code（聴力識別コード）を特定していてもよい。或る実施形態ではコーティング 1406 が、ユーザー装置 1400 に着脱自在なケースの形態であってもよい。

したがって改良された音響拡張とは、特定のユーザーの聴取上の要請にリアルタイムに応えるものであって、個人について予め測定され構成された難聴と必要に基づき特化したものであると言える。

本開示に係る方法は、コンピュータプログラムによって実施可能である。そうしたコンピュータプログラムは、webアプリケーションまたはいわゆる「アプリ」の形態であってよく、コンピュータまたはプロセッサに上述した方法の有する一種以上の機能を行わせるように構成されるコンピュータ実行可能な命令またはコードを含む。コンピュータプログラムは、コンピュータ可読媒体またはコンピュータプログラム製品としてコンピュータなどの装置に提供されてよい。そうしたコンピュータ可読媒体またはコンピュータプログラム製品には、半導体（固相メモリ）、磁気式メモリ、着脱可能コンピュータメモリスティックもしくはディスケット、ランダムアクセスメモリ（RAM）、読取専用メモリ（ROM）、剛体磁気ディスク、および光学ディスク（CD-ROM、CD-R/W、DVD、もしくはBlu-ray（登録商標）など）といった非一過性媒体が含まれてよい。またコンピュータ可読媒体またはコンピュータプログラム製品には、データ伝送のための搬送波信号または媒体が含まれてよく、例えばインターネットを介したコンピュータプログラムのダウンロードが含まれてよい。

コンピュータなどの装置（デバイス）を、上述した方法の有する一種以上の機能を実施するように構成できる。そうした装置としては、携帯電話、タブレット、ラップトップその他の演算装置が挙げられる。またそうした装置が、データ処理システムの形態を採っていてもよい。そうしたデータ処理システムは、分散型システムであってもよい。例えばデータ処理システムが、ネットワークを介して分散していてもよいし、あるいは専用のローカル接続を介して分散していてもよい。

典型的にはこうした装置は、コンピュータ実行可能な命令を格納するための一個以上のメモリーと、その命令を実行するための一個以上のプロセッサとを含む。

図11は、装置 104 の例のアーキテクチャを示している。この装置 104 は、プロセッサ 110 と、メモリー 115 と、ディスプレイ 135 とを含む。これらは中央バス構造に接続しており、またディスプレイ 135 はディスプレイアダプタ 130 を介して接続している。この例の装置 104 はまた、入力装置 125 （マウス、音声入力装置、および／もしくはキーボードなど）と、出力装置 145 （スピーカーやヘッドホンソケットといった音声出力装置など）と、他の装置やネットワークに接続するための通信アダプタ 105 とを含む。またこの入力装置 125 、出力装置 145 、および通信アダプタ 105 は中央バス構造に接続しており、その接続では入力装置 125 が入力装置アダプタ 120 を、出力装置 145 が出力装置アダプタ 140 を、それぞれ介している。

稼動時において、メモリー 115 に保存されたコンピュータ実行可能な命令を、プロセッサ 110 が実行できる。その処理結果は、ディスプレイ 135 を介してユーザーへ提示できる。コンピュータの動作を制御するためのユーザーの入力は、入力装置 125 を介して受信できる。

Claims (25)

1. 通信ネットワーク内のネットワークエンティティと、ユーザーが有するユーザー装置との間に確立された通信リンクを介して、ユーザーに対して聴取試験を行い、前記聴取試験が、前記通信リンクを介して前記ユーザー装置に複数種の試験周波数にて聴覚刺戟を与えることと、前記ユーザー装置から受信した前記聴覚刺戟に対する応答を監視することとを含むステップと、
   前記聴取試験の結果に基づいて、聴取プロファイルを生成するステップと、
   前記聴取プロファイルおよび前記ユーザーに関連する情報を、ネットワークエンティティ内のメモリーに保存することで、前記ユーザー装置への音響信号の変調のために前記聴取プロファイルを利用可能とするステップと
   を含むことを特徴とする、方法。
2. 前記ユーザーに関する情報が、前記ユーザーの識別子、および／または前記ユーザー装置の識別子を含む、請求項1に記載の方法。
3. 前記聴覚刺戟が、一種以上の人間の声に基づく白色雑音を含む、請求項1または2に記載の方法。
4. 前記聴覚刺戟が、1/3オクターヴ幅帯域の雑音を含む、請求項1〜3のいずれか一項に記載の方法。
5. 複数種の試験周波数にて前記ユーザーに聴覚刺戟を与えるステップが、500Hz、1000Hz、2000Hz、3000Hz、6000Hzのうちの二種以上で聴覚刺戟を与えることを含む、請求項1〜4のいずれか一項に記載の方法。
6. 前記ユーザーの難聴の指標を得るステップと、
   前記難聴の指標を用いて、前記聴取試験の初期音量を決定するステップと
   を含む、請求項1〜5のいずれか一項に記載の方法。
7. 応答の監視に応じて、各試験周波数における前記聴覚刺戟の音量を調節するステップ
   を含む、請求項1〜6のいずれか一項に記載の方法。
8. 前記ユーザーからの肯定的応答に対して、前記聴覚刺戟の音量を下げるステップを含む、請求項7に記載の方法。
9. 前記ユーザーから無応答であることに対して、前記聴覚刺戟の音量を上げるステップを含む、請求項7に記載の方法。
10. 各聴覚刺戟の期間が、1000msもしくは約1000msである、請求項1〜9のいずれか一項に記載の方法。
11. 各聴覚刺戟が、音量を暗騒音レベルから60dBもしくは約60dBまでのあいだで上げるかまたは下げるような一箇所以上の傾斜を含む、請求項1〜10のいずれか一項に記載の方法。
12. 前記ユーザーおよび／もしくはオペレーターに対して、前記聴取試験の結果を視覚的に表示するステップを含む、請求項1〜11のいずれか一項に記載の方法。
13. 保存した前記ユーザーの前記聴取プロファイルを用いて、前記ユーザーへの音響信号を前記ネットワークエンティティにてリアルタイムに変調し、変調された音響信号が前記ユーザーの有する前記ユーザー装置へと送達されるようにするステップを含む、請求項1〜12のいずれか一項に記載の方法。
14. 前記音響信号の変調が、
    前記音響信号のフィルタリング、
    前記音響信号の振幅調整、
    前記音響信号の周波数調整、
    前記音響信号の音高および／もしくは音程の調整
    のうちの一種以上を含む
    ことを特徴とする、請求項13に記載の方法。
15. 前記音響信号の変調が、
    前記ユーザーと第二のユーザーとのあいだの通話において、前記第二のユーザーの音声信号を変調するステップ
    を含む、請求項13または14に記載の方法。
16. 前記音響信号の変調を行うための設定の選択的な有効化または無効化を行うステップを含む、請求項1〜15のいずれか一項に記載の方法。
17. 前記ユーザー装置が有する一個以上のマイクロホンを用いて、周囲騒音を測定するステップと、
    前記ユーザー装置との前記通信リンクを有する前記ネットワークエンティティにて、前記ユーザー装置からの周囲騒音情報を受信するステップと、
    前記ユーザーのための音響信号の変調に使うために、前記聴取プロファイルを保存する前記ネットワークエンティティにて、受信した前記周囲騒音情報を保存するステップと
    を含む、請求項1〜16のいずれか一項に記載の方法。
18. 前記ユーザー装置へ前記音響信号を送達するための、チャネル挿入利得を決定するステップを含む、請求項1〜17のいずれか一項に記載の方法。
19. 前記音響信号をマルチチャネルに分割するステップを含む、請求項1〜18のいずれか一項に記載の方法。
20. 各チャネルごとに出力レベルを決定するステップを含む、請求項1〜19のいずれか一項に記載の方法。
21. 前記ユーザーへの前記音響信号の動的圧縮に先立って、前記チャネル挿入利得が適用される、請求項18またはこれに従属する請求項のいずれか一項に記載の方法。
22. ユーザー装置と、通信ネットワーク内のネットワークエンティティとの間に確立された通信リンクを介するユーザーへの聴取試験に参加して、ユーザーの聴取プロファイルを提供し、前記聴取試験が、前記通信リンクを介して前記ユーザー装置が複数種の試験周波数にて聴覚刺戟を受信することと、前記聴覚刺戟への一種以上の応答を前記ネットワークエンティティへ提供することとを含むステップと、
    その後に、前記聴取プロファイルに依って変調させた音響信号を、前記ユーザー装置にて受信するステップと
    を含む、方法。
23. 請求項1〜21のいずれか一項に記載の方法を実行するように構成されたサーバ。
24. 請求項22に記載の方法を実行するように構成されたユーザー装置。
25. 実行された際、プロセッサに請求項1〜21のいずれか一項に記載の方法または請求項22に記載の方法を行わせる命令を含んだコンピュータ可読媒体。

Images