(57)【特許請求の範囲】
【請求項１】
複数の音声メッセージに対し、前記音声メッセージの属性情報に応じた重みを設定する重み付け手段と、
前記音声メッセージの中から、前記音声メッセージの重みに基づいて、再生時間の合計が制限時間内になるように、１つ以上の音声メッセージを選択し、選択した音声メッセージの再生順序を前記選択された音声メッセージの属性情報に基づき決定するスケジューリング手段と、
前記再生順序にしたがって前記選択された音声メッセージを整列および結合することにより再生データを生成する再生データ作成手段と、
前記再生データまたは前記再生データへのリンク情報を、ユーザ端末に送信する送信手段と、
計時装置から時刻を取得する取得手段を備え、
前記属性情報は、発話時刻に関する情報を含み、
前記重み付け手段は、前記取得手段により取得した時刻と、前記発話時刻との差分に応じて、前記重みを設定する
再生データ生成装置。
【請求項２】
前記取得手段により取得した時刻と前記発話時刻との差分が大きいほど、前記重みを小さくする
請求項１に記載の再生データ生成装置。
【請求項３】
複数の音声メッセージに対し、前記音声メッセージの属性情報に応じた重みを設定する重み付け手段と、
前記音声メッセージの中から、前記音声メッセージの重みに基づいて、再生時間の合計が制限時間内になるように、１つ以上の音声メッセージを選択し、選択した音声メッセージの再生順序を前記選択された音声メッセージの属性情報に基づき決定するスケジューリング手段と、
前記再生順序にしたがって前記選択された音声メッセージを整列および結合することにより再生データを生成する再生データ作成手段と、
前記再生データまたは前記再生データへのリンク情報を、ユーザ端末に送信する送信手段と、を備え、
前記スケジューリング手段は、（１）前記選択された音声メッセージにおいて第１音声メッセージが第２音声メッセージへの返信である場合、前記第１音声メッセージを前記第２音声メッセージの後に並べ、または、（２）前記選択された音声メッセージにおいて第１音声メッセージがタスクフローの第２音声メッセージよりも後方のタスクで取得されたものである場合、前記第１音声メッセージを前記第２音声メッセージの後に並べる
再生データ生成装置。
【請求項４】
前記スケジューリング手段は、前記重みの合計が最大または閾値以上になるように、前記音声メッセージを選択する
請求項１ないし３のいずれか一項に記載の再生データ生成装置。
【請求項５】
前記ユーザ端末から再生要求を受信する受信手段と、
前記再生要求に応じて、音声メッセージ群の中から再生対象とする音声メッセージの候補を抽出する抽出手段と、をさらに備え、
前記重み付け手段は、前記抽出手段により抽出された音声メッセージに対し、前記重みを設定し、
前記スケジューリング手段は、前記抽出手段により抽出された音声メッセージの中から前記１つ以上の音声メッセージを選択する
請求項１ないし４のいずれか一項に記載の再生データ生成装置。
【請求項６】
前記属性情報は、発話者に関連する情報、メッセージ内容の種類情報、音声メッセージに含まれるキーワードに関する情報、前記音声メッセージへの返信回数に関する情報、前記音声メッセージへのユーザ評価に関する情報、および話題に関する情報のうちの少なくとも１つの情報をさらに含み、
前記重み付け手段は、前記少なくとも１つの情報をさらに用いて前記重みを設定する
請求項１ないし５のいずれか一項に記載の再生データ生成装置。
【請求項７】
前記再生要求は、前記再生対象とする音声メッセージの候補の抽出条件を含み、
前記抽出手段は、前記抽出条件と前記属性情報とに基づいて、前記再生対象とする音声メッセージの候補を抽出する
請求項５に記載の再生データ生成装置。
【請求項８】
前記スケジューリング手段は、前記選択した音声メッセージのそれぞれの冒頭に、前記選択した音声メッセージの属性情報に基づく合成音声または前記合成音声を表すテキストを追加する
請求項１ないし７のいずれか一項に記載の再生データ生成装置。
【請求項９】
前記スケジューリング手段は、連続する音声メッセージ間で共通する内容の合成音声またはテキストについては、連続する音声メッセージの先頭の音声メッセージにのみ前記共通する内容の合成音声またはテキストを追加する
請求項８に記載の再生データ生成装置。
【請求項１０】
前記属性情報は、再生不要な単語を表すキーワードを含み、
前記スケジューリング手段は、前記選択した音声メッセージから前記キーワードの音声データを削除する
請求項１ないし９のいずれか一項に記載の再生データ生成装置。
【請求項１１】
前記ユーザ端末の現在位置と、前記ユーザ端末のユーザの訪問先の位置とに基づき前記訪問先までの移動所要時間を算出し、前記移動所要時間に基づいて前記制限時間を算出する
請求項１ないし１０のいずれか一項に記載の再生データ生成装置。
【請求項１２】
複数の音声メッセージに対し、前記音声メッセージの属性情報に応じた重みを設定する重み付けステップと、
前記音声メッセージの中から、前記音声メッセージの重みに基づいて、再生時間の合計が制限時間内になるように、１つ以上の音声メッセージを選択し、選択した音声メッセージの再生順序を前記選択された音声メッセージの属性情報に基づき決定するスケジューリングステップと、
前記再生順序にしたがって前記選択された音声メッセージを整列および結合することにより再生データを生成する再生データ作成ステップと、
前記再生データまたは前記再生データへのリンク情報を、ユーザ端末に送信する送信ステップと、
計時装置から時刻を取得する取得ステップとを備え、
前記属性情報は、発話時刻に関する情報を含み、
前記重み付けステップは、前記取得ステップにより取得した時刻と、前記発話時刻との差分に応じて、前記重みを設定する
再生データ生成方法。  
【請求項１３】
複数の音声メッセージに対し、前記音声メッセージの属性情報に応じた重みを設定する重み付けステップと、
前記音声メッセージの中から、前記音声メッセージの重みに基づいて、再生時間の合計が制限時間内になるように、１つ以上の音声メッセージを選択し、選択した音声メッセージの再生順序を前記選択された音声メッセージの属性情報に基づき決定するスケジューリングステップと、
前記再生順序にしたがって前記選択された音声メッセージを整列および結合することにより再生データを生成する再生データ作成ステップと、
前記再生データまたは前記再生データへのリンク情報を、ユーザ端末に送信する送信ステップと、を備え、
前記スケジューリングステップは、（１）前記選択された音声メッセージにおいて第１音声メッセージが第２音声メッセージへの返信である場合、前記第１音声メッセージを前記第２音声メッセージの後に並べ、または、（２）前記選択された音声メッセージにおいて第１音声メッセージがタスクフローの第２音声メッセージよりも後方のタスクで取得されたものである場合、前記第１音声メッセージを前記第２音声メッセージの後に並べる
再生データ生成方法。  
【発明の詳細な説明】
【技術分野】
【０００１】
本実施形態は、再生データ生成装置および再生データ生成方法に関する。
【背景技術】
【０００２】
複数職種の複数職員が分散・非同期に業務を実施する医療現場、とくに地域医療などの現場においては、職員間で、患者についての観察結果や気付き、連絡事項などを密に情報共有する必要がある。
【０００３】
職員は一般的に、電子カルテシステムへの入力や、電話やＦＡＸといった手段を用いて情報共有を行っているが、音声メッセージを用いた情報共有システムが知られている（以降、音声つぶやきシステムと呼ぶ）。
【０００４】
音声つぶやきシステムでは、職員がスマートフォンを用いて音声メッセージを登録すると、サーバで音声認識し、音声に含まれるキーワードを抽出する。同時に、メッセージの対象患者IDや発話者の職員ID、発話時刻、発話場所、推定業務などの情報、メッセージの重要度や種類（以降、タグと呼ぶ）を音声メッセージに自動添付もしくはユーザ（すなわち職員）が添付した上で、必要な範囲の職員に配信する。このような音声メッセージと付随情報からなる情報を、以降、音声つぶやきと呼ぶ。
【０００５】
職員は、受信した音声つぶやきあるいはサーバに蓄積された音声つぶやきを、携帯端末やパソコンで、患者ごとに時間順に整理して視聴することで、患者の最近の状況を把握することができる。その際、音声認識結果やキーワードを画面上で閲覧することもできるが、徒歩や車などでの移動中の場合は、音声そのものを聞く方が都合がよい。また画面で音声認識結果やキーワード、その他の付随情報をみながら、音声を聞くこともある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開2011-113490号公報
【特許文献２】特開2011-61263号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし蓄積された一連の音声つぶやきを聞く場合、移動時間などの限られた時間内に再生が完了する保証がない。また職員自身が、実際に音声つぶやきを聞くまでは、どのような順序を再生すれば理解しやすいかは分からない。
【０００８】
先行技術として、コールセンターでの談話についての音声認識結果を、所定のテンプレートによる構造にしたがって解析し、要約を作成する技術が知られている。しかしながら、この技術では、再生に関する制限時間を考慮できない問題や、理解しやすいように並べ替えることができない問題があった。
【０００９】
この発明の一側面は、限られた時間内で、聞き手にとって理解しやすいように音声メッセージを選択・整列した再生データを生成することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一態様としての再生データ生成装置は、重み付け手段と、スケジューリング手段と、再生データ作成手段と、送信手段とを備える。
【００１１】
前記重み付け手段は、複数の音声メッセージに対し、前記音声メッセージの属性情報に応じた重みを設定する。
【００１２】
前記スケジューリング手段は、前記音声メッセージの中から、前記音声メッセージの重みに基づいて、再生時間の合計が制限時間内になるように、１つ以上の音声メッセージを選択し、選択した音声メッセージの再生順序を前記選択された音声メッセージの属性情報に基づき決定する。
【００１３】
前記再生データ作成手段は、前記再生順序にしたがって前記音声メッセージを整列および結合することにより再生データを生成する。
【００１４】
前記送信手段は、前記再生データまたは前記再生データへのリンク情報を、ユーザ端末に送信する。
【図面の簡単な説明】
【００１５】
【図１】第1の実施例に係る再生データ生成装置としてのつぶやき再生装置のブロック図である。
【図２】ユーザ端末から受信した音声つぶやき再生要求に対する再生データの作成フローを示す図である。
【図３】各つぶやきへの重みの算出フローの一例を示す図である。
【図４】第6の実施例に係る動作フローを示す図である。
【図５】ラティス構造を活かした再生順序の決定を説明するための図である。
【発明を実施するための形態】
【００１６】
以下、図面を参照しながら、本発明の実施例を説明する。
【００１７】
（第1の実施例）
図1は、本発明の第1の実施例に係る再生データ生成装置としてのつぶやき再生装置のブロック図である。  
本実施例では、複数職種の複数職員が分散・非同期に業務を実施する医療現場、とくに地域医療などの現場に本再生データ生成装置を適用する場合を説明する。ただし、本実施例は、医療現場に制限されず、エレベータ等の設備保守現場など、複数の職員が分散・非同期に業務を実施する現場であれば、多種多様な現場に適用可能である。
【００１８】
つぶやき再生装置101は、ネットワーク103を介して、職員の端末（ユーザ端末）102と通信可能なサーバである。ユーザ端末101は、職員により持ち運び可能な移動体端末であり、たとえば携帯端末、ノート型PC、スマートフォン等が挙げられる。ただし、ユーザ端末101はこれらの形態に限定されず、デスクトップ型PC等の固定設置型端末でも構わない。
【００１９】
つぶやき再生装置101は、通信装置11、CPU12、および記憶装置13を備える。記憶装置13は、データを記憶または読み出し可能な任意の装置であり、たとえばメモリ装置、ハードディスク装置、または、CD-ROMやUSBメモリ等の記録媒体からデータを読み込む読み込みドライブである。記憶装置13は、これらのうちの2つ以上の組み合わせたものでもよい。なお、つぶやき再生装置101内には、通信装置11、CPU12、および記憶装置13以外にも、CPU12が実行するプログラムを展開したり、CPU12の一時的な作業領域として機能するRAMや、構成要素間の接続するバス等も存在するが、これらの図示は省略している。
【００２０】
通信装置11は、ネットワーク103を介して、ユーザ端末102と通信を行う。ネットワーク103は、無線ネットワークでもよいし、有線ネットワークでもよいし、これらの複合でもよい。ネットワーク103は、インターネットを含んでも良い。
【００２１】
ユーザ端末102は、音声つぶやきの再生要求を、つぶやき再生装置101宛に送信する再生要求送信手段を含む。
【００２２】
音声つぶやき再生要求は、たとえば、以下の項目を含む。一部が空の場合もあり得る。
【００２３】
・ ユーザID
・ 対象患者ID
・ 再生の制限時間
【００２４】
通信装置11は、再生要求受信手段1および再生データ送信手段7を含む。
【００２５】
再生要求受信手段1は、ユーザ端末102からの再生要求を受信する。再生要求受信手段1は、受信した再生要求を、CPU12の再生つぶやき候補抽出手段3に渡す。
【００２６】
CPU12は、再生つぶやき候補抽出手段3、重み付け手段4、再生つぶやきスケジューリング手段5、および再生データ作成手段6を含む。これらの手段は、プログラムをCPU12に実行させることにより実現される。プログラムは、記憶装置13等に記憶されており、RAM等の不揮発性メモリに読み出されて、CPU12により実行される。
【００２７】
記憶装置13は、つぶやき保持手段2を含む。つぶやき保持手段2は、ユーザが登録した音声つぶやきを保持する手段である。具体的にはリレーショナルデータベースやＸＭＬデータベースを用いることができる。つぶやき保持手段2は、サーバ内でなく、サーバに外付けされた記憶装置内に設けられても良いし、サーバがアクセス可能なネットワーク上に配置されてもよい。
【００２８】
各音声つぶやきは、以下の付随情報（属性情報）を含む。一部が空の場合もある。例えば話題の患者IDが空の場合は、そのつぶやきは、どの患者についてのつぶやきでもなく、職員間の事務的連絡といったつぶやきである。以下の情報は一例であり、さらに追加の情報が含まれても良い。音声データ（音声メッセージ）のＵＲＬの代わりに、音声データそのものを含んでも良い。
【００２９】
・ つぶやきID
・ つぶやきの音声データのＵＲＬ（あるいは音声データのファイルパス）
・ 音声データの発話時間（秒あるいはミリ秒）
・ 発話者ID
・ 発話日時
・ 発話内のキーワード（複数）  
・ 話題の患者ID 
・ 返信先つぶやきID 
・ イイね回数（登録されたつぶやき閲覧したユーザが、そのつぶやきを評価した回数） 
・ タグ（重要度、あるいはつぶやきの種類など、システムの設定による） 
・ 発話場所（緯度経度、最寄Bluetooth端末IDなど）
・ 発話時の動作（歩行中、会議中、作業中など）および具体的業務内容
【００３０】
再生つぶやき候補抽出手段3は、再生要求受信手段1から受け取った再生要求に基づき、再生の候補となるつぶやきを、つぶやき保持手段2に問い合わせる。具体的には、再生の候補となるつぶやきを抽出するクエリを発行し、発行したクエリをつぶやき保持手段2に出力する。これにより、再生つぶやき候補抽出手段3は、つぶやき保持手段2から、再生候補となるつぶやきを取得する。
【００３１】
重み付け手段4は、再生つぶやき候補抽出手段3が抽出したつぶやきに重みを付与する。重みは実数もしくは整数である。重みは、たとえばつぶやきの付随情報（属性情報）に基づき決定する。
【００３２】
再生つぶやきスケジューリング手段5は、重みの付与されたつぶやき候補の中から、再生時間の合計が制限時間以内になるように、つぶやき候補を選出する。たとえば、再生時間の合計が制限時間以内、かつ、重みの合計が最大になるように、つぶやき候補の組を選出する。また、再生つぶやきスケジューリング手段5は、選出されたつぶやき候補の属性情報に基づき、これらつぶやきの再生順序を決定する。再生つぶやきスケジューリング手段5は、決定した順序にしたがって、再生対象となるつぶやきを整列する。
【００３３】
再生データ作成手段6は、再生つぶやきスケジューリング手段5により整列されたつぶやき列に基づいて、再生データを作成する。再生データは音声データ（wavなど）を含み、さらにテキストデータ（端末で音声合成する場合など）を含んでも良い。音声データは、必要に応じて、つぶやきに含まれるＵＲＬからダウンロードする。テキストデータは、たとえば属性情報に基づき作成され、ユーザ端末で音声合成または表示する場合に使用する。音声データは、属性情報の内容を音声データ化したものを含んでも良い。再生データには属性情報は含めなくても良いし、あるいはユーザがつぶやきの再生中に属性情報を端末で表示または音声合成できるようにテキストとして含めても良い。
【００３４】
再生データ送信手段7は、再生データ作成手段6の作成した再生データもしくはそのリンク情報（ＵＲＬ等）を、再生要求を送信したユーザ端末に送信する。リンク情報を送信する場合、つぶやき再生装置は、当該リンク情報に該当する位置に再生データを格納する。格納先は、つぶやき再生装置内でもよいし、ユーザ端末からアクセス可能なネットワーク上のサーバでもよい。
【００３５】
（再生データの作成方法の例）
図2は、ユーザ端末からの音声つぶやき再生要求に対する再生データの作成フローを示す。
【００３６】
ステップS11：再生要求受信
再生要求受信手段1が、ユーザ端末からの再生要求を受信し、再生つぶやき候補抽出手段3に再生要求を渡す。再生要求には、前記のとおり、ユーザのユーザID、再生したいつぶやきの対象患者ID、ユーザ端末上での再生の制限時間が含まれる。
【００３７】
ここで再生要求において、対象患者IDが空の場合もある。どの患者についてのつぶやきでもない、職員間の一般連絡についてのつぶやきを再生したい場合がこれに該当する。
【００３８】
また制限時間が空の場合もある。この場合、後述する方法により、制限時間をユーザ端末上あるいはサーバ上で算出し、算出した値を用いることができる。
【００３９】
ステップS12：再生つぶやき候補クエリ発行
再生つぶやき候補抽出手段3が、再生要求に基づいて、再生候補の対象となるつぶやきを、つぶやき保持手段2から抽出するためのクエリを発行し、つぶやき保持手段2にクエリを出力する。クエリには、つぶやきを抽出するための条件が含まれる。
【００４０】
ステップS13：再生つぶやき候補の取得
つぶやき保持手段2は、再生つぶやき候補抽出手段3からのクエリに該当するつぶやきを抽出し、再生つぶやき候補抽出手段3に抽出結果を返す。抽出結果は、抽出したつぶやきのデータオブジェクトの配列を含む。データオブジェクトの構成は以下の通りである。音声データのＵＲＬの代わりに、音声データそのものが含まれてもよい。
【００４１】
［つぶやきデータオブジェクトの構成メンバ］
・つぶやきID
・つぶやきの音声データのＵＲＬ（あるいは音声データのファイルパス）
・音声データの発話時間（秒あるいはミリ秒）
・発話者ID
・発話日時
・発話内のキーワード（テキスト、複数）  
・話題の患者ID 
・返信先つぶやきID 
・イイね回数
・タグ（複数）
・発話時の業務
・発話場所
・重み（ステップS13の時点ではデフォルト値が設定されている）
・既読者ID
【００４２】
ステップS14：再生つぶやき候補への重み付与
抽出された再生つぶやき候補（データオブジェクト）に対し、重みを算出し、付与する。
【００４３】
図3に、再生つぶやきの候補（N個）に関し、各つぶやきi（1〜N）への重みwiの算出フローの一例を示す。
【００４４】
図3中の、ステップS21でつぶやきiの指数kiを算出し、続くステップS22で時間逓減係数αiを算出し、続くステップS23で、これらに基づく重みwiを計算する。
【００４５】
・  ki = k1*イイね回数＋k2*返信回数＋k3*発話者重み＋k4*Σタグ重み＋k5*Σキーワード距離
・  αi = 1/(t-ti), t：現在時刻, ti：つぶやきiの発話時刻
・  wi =αi×ki
【００４６】
指数kiの算出式におけるk1〜k5は数値である。
【００４７】
イイね回数は、前記のとおり、つぶやきを閲覧したユーザが、そのつぶやきを評価した回数である。
【００４８】
返信回数は、つぶやきiを返信先とするつぶやきの個数である。
【００４９】
発話者重みは、つぶやきの発話者もしくは発話者の職種により決定される数値である。
【００５０】
発話者の職種は、サーバのユーザマスタから取得できる。
【００５１】
タグ重みとは、タグ（つぶやきの内容による種類を示す。医師の指示や看護師の指示受け、返信、質問など）の種類により決定される数値である。重要な内容に対応するタグほどタグ重みが大きい。
【００５２】
キーワード距離とは、当該つぶやきの発話内に含まれるキーワードが、直近のつぶやきに含まれるキーワードの分布の中心からどれくらい近いかを示す数値である。すなわち、直近の症状等に関係のあるつぶやきの重みが高くなるようにする。キーワード距離は、キーワード距離関数を用いて計算することができる。たとえば、単語を辞書順に整列したベクトルを用意しておき、つぶやきの中に同じ単語が含まれていれば該当する位置の要素を1、含まれていなければ0として、上記ベクトルと同じ要素数の単語ベクトルを生成する。他のつぶやきの単語ベクトルと同じ位置の値を比較し、同じ値であれば0、異なる値であれば1とし、1の数をカウントする。これをキーワード距離とすることができる。
【００５３】
時間逓減係数αiは一例であり、現時点から時間が遡るごとに単調減少する関数であれば他の形態でもよい。
【００５４】
ステップS15：再生つぶやきスケジューリング
再生つぶやきスケジューリング手段5 が、再生時間の合計が制限時間内になるように、かつ重みの合計が最大または閾値以上になるように、つぶやき候補から再生対象のつぶやきを選択および整列する。詳細は後述する。
【００５５】
ステップS16：再生データ作成
再生データ作成手段6が、再生つぶやきスケジューリング手段5 により選択・整列された再生対象つぶやきに基づいて、再生データを作成する。ここで、再生データは、上記整列の結果に含まれる、つぶやきの音声データと付随情報（属性情報）の合成音声とを、再生順に結合した音声データ（wav形式など）である。付随情報の部分は再生データの上ではテキストデータとし、ユーザ端末上で音声合成してもよい。
【００５６】
ステップS 17：再生データ送信
再生データ送信手段7は、再生つぶやきスケジューリング手段5 が作成した再生データを、再生要求を送信したユーザ端末に送信する。別の方法として、再生データへのリンク情報をユーザ端末に送信してもよい。この場合、ユーザは、当該リンク情報へアクセスすることで再生データをダウンロードする。また、サーバは、当該リンク先に再生データを保存しておく。リンク先は、サーバ内であっても、ネットワーク上の別の装置であってもよい。
【００５７】
（再生つぶやきスケジューリングの実施例）
再生つぶやきスケジューリング手段5 による、再生対象のつぶやきの選択および整列の実施例を示す。
【００５８】
再生つぶやきのスケジューリングは、以下のように最適化問題として定式化できる。
【００５９】
・max. Σ（選択されたつぶやきの重み）
・s.t. 選択・整列されたつぶやき再生時間の合計＜制限時間 
【００６０】
上記、最適化問題を解くアルゴリズムの例を示す。
【００６１】
［再生対象つぶやき選択・整列アルゴリズム］
（ステップ１）つぶやき候補を、重みの降順に、つぶやき候補リスト（L1）に整列する。
（ステップ２）重みの大きい順に、つぶやき候補をつぶやき候補リスト（L1）から取りだす。 
（ステップ３）取り出したつぶやき候補を、再生つぶやきリスト（L2）に挿入する。リストは発話時刻の昇順とする。 
この際、後述の“配置ルール”を適用し、実際の発話時刻と異なる位置に挿入し、再生時に理解しやすいようにつぶやきを配置したり、同種のつぶやきをまとめることもできる。 
また、後述の“省略ルール”を適用し、無駄な音声をとりのぞくこともできる。
【００６２】
（ステップ４）再生つぶやきリスト（L2）の合計再生時間を算出する。制限時間を越えていれば、上で挿入したつぶやきを再生つぶやきリスト（L2）から取り除く。 
（ステップ５）つぶやき候補リスト（L1）が空であれば終了、そうでなければ2に戻る。 
上記のアルゴリズムの変形例として、重みの合計が閾値以上になった時点で処理を終了してもよい。この場合、短い時間で処理を完了させることが可能である。
【００６３】
（再生対象つぶやき選択・整列アルゴリズムにおける再生時間の算出の実施例）
再生対象つぶやき選択・整列アルゴリズムのステップ4の再生つぶやきリストの合計再生時間の算出方法を示す。
【００６４】
再生つぶやきリストに整列した各つぶやきについては、基本的に、発話者氏名（あるいは通称）の合成音声、発話日時の合成音声、つぶやきの音声データの順で再生するものとする。ここで発話日時は、発話日だけにしてもよい。現在日時と同一週の場合は、曜日だけにしてもよい。
【００６５】
ただし、上記のままだと連続するつぶやきが同じ発話者のものの場合に、同じ氏名が繰り返し再生され時間の無駄になる。 その他、もともとの音声データに無駄な音声が含まれているので、以下の省略ルールを適用して無駄な音声再生を取り除くことができる。
【００６６】
［省略ルール］
・再生リスト（L2）内のあるつぶやきの発話者IDが、その直前のつぶやきの発話者IDと同一の場合、発話者氏名（あるいは通称）の合成音声を取り除く。 
・再生リスト（L2）内のあるつぶやきの発話日時の年月日が、その直前のつぶやきの発話日時の年月日と同一の場合、年月日の合成音声を取り除く。 
・情報量の少ない言葉の音声を取り除く（対象の患者名や“ええーっと”など）。
【００６７】
ある患者についてのつぶやきを再生する場合、どの患者についてのつぶやきかは、再生の冒頭のみに合成音声で再生すればよい。このため個々のつぶやきの音声データに患者名が含まれる場合はこれを削除してもよい。
【００６８】
既存の音声認識技術により、患者名や“ええーっと”などの単語も再生不要なキーワードとして抽出でき、かつこれらのキーワードの開始時刻と終了時刻（音声データの開始時刻からの相対時刻）も特定できる。つぶやき保持手段2において、これらの情報を、キーワードの付随情報として保持可能である。このため音声データからこれらのキーワードの開始時刻から終了時刻までの部分を削除することで、情報量の少ない音声部分を取り除くことができる。
【００６９】
（再生時に理解しやすいつぶやき再生列の作成）
あるつぶやきについての返信つぶやきは、返信先のつぶやきの直後に配置した方が、再生時に理解しやすい。 また、キーワードや発話時の業務に基づく因果関係（後述）を持つつぶやきも、“因”のつぶやきの直後に、“果”のつぶやきを配置することで、再生時に理解しやすくすることができる。
【００７０】
このため、［再生対象つぶやき選択・整列アルゴリズム］のステップ3における、つぶやき候補の再生つぶやきリスト（L2）への挿入において、以下の配置ルールを適用することで、上記の目的を達成できる。 
［配置ルール１］
・返信つぶやき（因果の“果”つぶやき）の挿入ルール 
つぶやき候補リスト（L1）から取り出したあるつぶやきiが、再生リスト（L2）内のいずれかのつぶやきjの返信である場合、つぶやきiをつぶやきjの直後に挿入する。 
・返信先つぶやき（因果の“因”つぶやき）の挿入ルール 
つぶやき候補リスト（L1）から取り出したあるつぶやきiが、再生リスト（L2）内のいくつかのつぶやきjの返信先である場合、つぶやきiを、全てのつぶやきjの中で最も先頭にあるもの直前に挿入する。 
以上2つのルールで配置された、連続する同種の返信つぶやき（“果”のつぶやき）を、以下のようにまとめることで、同一内容で情報量の少ないつぶやきの再生を圧縮できる。 
“連続する同種の返信つぶやきの全発話者氏名（あるいは通称）の合成音声の列＋返信の内容の合成音声”
たとえば、Ａさん、Ｂさん、Ｃさんが、あるつぶやきに対し、全員“了解”あるいは“了解しました”といった返信つぶやきを発した場合、上記まとめにより得られる再生音声は、“Ａさん、Ｂさん、Ｃさん、了解”となる。 
【００７１】
［配置ルール２］
別のつぶやき配置ルールとして、下記のような実施例も可能である。ユーザによる返信関係や医療上の処置の順序など業務上の知識を用いてつぶやき間の因果関係が抽出可能な場合、一連のつぶやき群は束（ラティス）構造を形成する。このとき、因果関係による順序関係を保つ範囲で、同一発話者のつぶやきを時間順序に基づき再生する。因果関係による順序関係がある場合は、発話者をチェンジし、最も古いつぶやきの発話者を選択する。発話者が変わる場合はタグの音声合成を実施する。
【００７２】
図5に、ラティス構造を活かした再生順序の決定の例を示す。図中の楕円はつぶやきを模式的に表している。自分、A医師、B看護師、C介護士の患者K氏に関するつぶやきが再生対象として選択されている。これらのつぶやきの再生順序が楕円内の数字によって表されている。基本的に最も古いつぶやきを持つ順に発話者が選択され、同一発話者では、古いのもから新しい順につぶやきが再生されるように、つぶやきの再生順序が決定される。ただし、因果関係による順序関係を保つ範囲で、適宜発話者をチェンジする。図示の例では、A医師のつぶやき１５は、自分のつぶやき５とB看護師のつぶやき１２と因果関係があり、自分のつぶやき５とB看護師のつぶやき１２よりも後に再生されるようにする（条件1）。また、C介護士のつぶやき１７はB看護師のつぶやき12と因果関係にあり、B看護師のつぶやき12よりも後に再生されるようにする（条件2）。これらの条件1および条件2を満たすように、上記の原則にしたがって、つぶやきの再生順序を決定する。本例では、まず、最も古いつぶやき（つぶやき１）をもつのは自分であるため、自分のつぶやきが古いものから順に再生されるよう再生順序が決定される。次に古いつぶやき（つぶやき８）を持つのはC介護士であるため、C介護士のつぶやきが古いものから順に再生されるよう再生順序が決定される。この際、C介護士のつぶやき１７は、B看護師のつぶやき１２の後に再生される必要があるため、つぶやき１７の再生前に発話者がチェンジされる。次に古いつぶやき（つぶやき１１）を持つのはB看護師であるため、発話者がB看護師にチェンジされる。B看護師のつぶやきが古いものから順に再生されるように再生順序が決定される。次に、A医師の最も古いつぶやき１５が、C介護士のつぶやき１７よりも古いため、A医師に発話者がチェンジされ、A医師のつぶやきを古いものから順に再生するように再生順序が決定される。最後に、C介護士のつぶやき１７、１８がこの順で再生されるように再生順序が決定される。この結果、図に示される数字の順序で、つぶやきの再生順序が決定される。
【００７３】
（つぶやきの配置における業務フローの適用の実施例）  
前述のつぶやきの整列において適用されるつぶやき間の因果関係を表すものとして、医療の業務フローがある。地域医療の業務フローの例として、
訪問看護師による観察 → 医師の処方 → 薬剤師の調剤・配薬 → 訪問看護師による残薬確認
というタスクの連鎖からなるフローが考えられる。上記の各タスク実施時に、各医療職がある患者についてつぶやきを登録すると、音声つぶやきシステムでは、当該医療職の業務予定、位置、発話のキーワードなどから、発話時のタスクを推定し、つぶやきに付随情報として推定タスクを自動添付する。
【００７４】
この推定タスクを用いて、再生つぶやき候補の整列時に、ある推定タスクについてのつぶやきを、フロー上で前方のタスクの直後に配置することができる。このような再生列の配置により、ユーザが再生音声を聞くとき、業務の流れにしたがった状況理解をすることができる。
【００７５】
（第2の実施例：再生対象つぶやき候補の絞り込み抽出）
前記した［再生対象つぶやき選択・整列アルゴリズム］におけるステップ2およびステップ3の再生つぶやき候補の抽出において、再生つぶやき候補を絞り込んで抽出することができる。具体的には、つぶやき保持手段2へのつぶやき候補抽出のクエリとして、以下のような指定をしたものを発行することで、絞り込みができる。これらの指定を組み合わせたクエリでもよい。これらのクエリの実装はSQLおよび抽出結果に対する整列処理で可能である。
【００７６】
・  対象患者ID（つぶやき再生要求に含まれる場合）
・  未読のつぶやき
・  最近のつぶやきであって、音声データの発話時間の合計が制限時間のK倍以下（K＝2など）
・  発話日時が過去1か月以内
・  発話者が特定の職種（ユーザマスタ上で各ユーザの職種が指定されている）発話者が特定のユーザ
・  単なる返信つぶやき以外（単なる返信つぶやきかは、たとえば「単なる返信」を表す所定のキーワードのみを含むかで判断できる）
【００７７】
（第3 の実施例：再生時間制約のバリエーション）
前記した再生対象のつぶやきの選択および整列におけるつぶやきの再生の制限時間としては、以下のような指定方法がある。
【００７８】
・ユーザの現在位置からつぎの訪問先までの移動所要時間の推定値を用いる
スマートフォンなどの携帯端末では、GPSデータを受信することで、ユーザの現在位置の緯度経度を取得することができる。ユーザの次の訪問先の緯度経度もしくは住所がサーバ上に登録されていれば、これらに基づいて、既存の地図情報アプリケーション（google mapsなど）を用いて、次の訪問先までの移動所要時間を推定することができる。この推定値自体もしくは、これに定数時間を足した時間を、つぶやきの再生の制限時間とすることができる。ユーザの現在位置は携帯端末からサーバに送信することができ、次の訪問先の緯度経度もしくは住所はサーバから携帯端末に送信することができる。よって、上記の制限時間を算出する機能および手段は、携帯端末上とサーバのどちらにも配置することができる。
【００７９】
・ユーザが携帯端末上で制限時間を指定する
再生要求送信時に、携帯端末の画面上で制限時間を指定することができる。
【００８０】
・デフォルトの値を用いる（5分など）
以上のどちらの方法も用いない場合、デフォルトの制限時間を用いることができる。
【００８１】
（第4の実施例：つぶやきの再生速度や再生内容の変更）
ユーザの端末上でのつぶやき再生において、倍速指定など、再生速度を早くするかどうか選択できるようにしてもよい。 
・  つぶやきの種類（指示、実施報告、返信など）、キーワードや発話者、発話者の職種に応じた再生速度の指定も可能。 
・  単なる返信（“了解”など）は倍速 
・  医師の指示のつぶやきは常に通常再生 
【００８２】
（第5の実施例：再生中に気になったつぶやきにチェック）
以上の方法によって再生される音声つぶやきを聞いている最中、ユーザがよく理解できない音声つぶやきや、気になった音声つぶやきがあった場合に、当該つぶやきにチェックをつけることができるようにする。
【００８３】
たとえば、ユーザがその音声つぶやきの再生中もしくは再生直後に、携帯端末の画面操作もしくはヘッドセットのボタン操作により、チェックを付ける。チェックにより、“気になったつぶやきのIDのリスト”に、当該つぶやきのIDが追加される。
【００８４】
再生が完了すると、あるいはユーザの画面操作やヘッドセットのボタン操作により、前記つぶやきのIDリスト内のIDに対応するつぶやきの音声を、連続再生する。あるいは再生中につぶやきの音声再生をスキップできるようにしてもよい。
【００８５】
上記のように一連のつぶやきの連続再生が終わってから気になったつぶやきを改めて聞く以外に、気になった時点で、気になったつぶやきを聞きなおすことができるようにしてもよい。たとえば、ユーザの画面操作やヘッドセットのボタン操作により、一連のつぶやきの連続再生を一旦停止して、気になったつぶやきを聞きなおす。このつぶやきを起点に、因果関係にあるつぶやきの再生を行うことができるようにしてもよい。
【００８６】
（第6の実施例：制限時間内の再生に限定しないつぶやき再生方法）
これまで述べた再生つぶやきスケジューリングでは、過去のつぶやきや、重要でないと判断されたつぶやきが再生データから排除されることがある。しかしながら、ユーザにとって、このことが望ましくない場合がある。
【００８７】
そこで本実施例では、このようなケースにおいては、図 4に示すフローチャートに従う方法を実行する。図4（A）はサーバ側のフロー、図4（B）はユーザ端末側のフローである。
【００８８】
サーバでは、ユーザ端末から未読のつぶやきの再生要求を受信し（S51）、当該未読のつぶやきの抽出クエリを発行して（S52）、未読のつぶやきを取得し（S53）、取得した未読のつぶやきをユーザ端末に送信する（S54）。ユーザ端末では、未読のつぶやきを受信したら（S55）、まず一連のつぶやきの概要を短時間で再生し（S56）、気になった音声つぶやきにユーザがチェックを付け、概要の再生が終わった後、改めてユーザがチェックしたつぶやきの音声を聞く（S57）。
【００８９】
ステップS56の再生では、未読のつぶやきについて、つぶやきの発話者氏名、発話時刻、対象の患者指名、つぶやきに含まれるキーワード、つぶやきの種類（観察、指示、実施報告、質問など）を合成音声により、つぶやきの発話時刻順に再生すればよい。
【００９０】
あるいは、未読のつぶやきを対象患者ごとにまとめてから、各対象患者についてのつぶやきを発話時刻順に再生してもよい。その場合は、対象患者指名の合成音声は、当該患者の一連のつぶやき概要の再生の冒頭においてのみ再生すればよい。
【００９１】
また前述の実施例と同様に、連続するつぶやきの発話者や発話日が同一の場合は、一連のつぶやきの中の最初のつぶやきの概要再生においてのみ、発話者氏名や発話日の合成音声を再生すればよい。
【００９２】
ユーザは、未読のつぶやきの概要が再生されている最中に、気になったつぶやき概要があれば、当該概要の再生中に、携帯端末の画面操作もしくはヘッドセットのボタン操作により、当該つぶやきにチェックをつけることができる。概要の再生が完了すると、自動的に、もしくはユーザの画面操作やヘッドセットのボタン操作により、前記気になったつぶやきのIDリスト内のIDに対応するつぶやきの音声が連続再生される（S57）。再生中につぶやきの音声再生をスキップすることもできる。再生時に、前述の実施例と同様に、携帯端末上で、つぶやきの並べ替えやまとめ、情報量の少ない音声の省略などを適用したスケジューリングを施すことができる。あるいは、前記気になったつぶやきのIDリストをサーバに送信し、サーバ上で気になったつぶやきについて前述の実施例と同様なスケジューリングを実施し、携帯端末に再生データを作成・送信することによっても、同じ目的を達することができる。
【００９３】
また図 4のフローチャートは、未読のつぶやきを対象としているが、ステップS52の抽出条件として、第2の実施例に列挙した条件およびそれらの条件の組み合わせを用いることで、“未読のつぶやき”以外のつぶやきについても、上記方法を適用できる。
【００９４】
上記実施形態では、音声メッセージを対象としたが、映像データにも本実施形態は適用可能である。この場合、再生候補となる映像データを抽出し、当該映像データに重み付けし、再生時間が制限時間以内になるようにこれらの中から映像データを選択および整列して、再生映像データを生成することとなる。これまでの説明におけるつぶやきあるいは音声メッセージ等の用語を映像データに読み替えることで、映像データの場合も同様にして実施可能である。
【００９５】
なお、本発明は前記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。また、以下に例示するような種々の変形が可能である。
【要約】
【課題】限られた時間内で、聞き手にとって理解しやすいように音声メッセージを選択・整列した再生データを生成する。
【解決手段】本発明の一態様としての再生データ生成装置は、複数の音声メッセージに対し、その属性情報に応じて重みを設定する重み付け手段と、前記音声メッセージの重みに基づいて、再生時間の合計が制限時間内になるように、前記音声メッセージの中から１つ以上の音声メッセージを選択し、選択した音声メッセージの再生順序を前記属性情報に基づき決定するスケジューリング手段と、再生順序にしたがって前記音声メッセージを整列および結合した再生データを生成する再生データ作成手段と、前記再生データまたは前記再生データへのリンク情報をユーザ端末に送信する送信手段と、を備える。
【選択図】図１【図１】
0005414865.tif 000002
【図２】
0005414865.tif 000003
【図３】
0005414865.tif 000004
【図４】
0005414865.tif 000005
【図５】
0005414865.tif 000006