ホーム > 特許ランキング > ナレルシステム株式会社
特許7239963グループ音声通信と過去音声確認のためのコンピュータプログラム、方法及び装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-03-07
(45)【発行日】2023-03-15
(54)【発明の名称】グループ音声通信と過去音声確認のためのコンピュータプログラム、方法及び装置
(51)【国際特許分類】
H04L 67/02 20220101AFI20230308BHJP
H04M 3/56 20060101ALI20230308BHJP
【ＦＩ】
H04L67/02
H04M3/56 Z
【請求項の数】
3
(21)【出願番号】P 2018074337
(22)【出願日】2018-04-07
(65)【公開番号】P2019185329
(43)【公開日】2019-10-24
【審査請求日】2021-04-07
(73)【特許権者】
【識別番号】301062798
【氏名又は名称】ナレルシステム株式会社
(72)【発明者】
【氏名】中村圭介
【審査官】岩田 玲彦
(56)【参考文献】
【文献】特開２００８－１７７８９６（ＪＰ，Ａ）
【文献】特開２０１３－０８９１３０（ＪＰ，Ａ）
【文献】特開平１１－２８１７７４（ＪＰ，Ａ）
【文献】特開２００９－１３９５９２（ＪＰ，Ａ）
【文献】特開２００６－１９００１０（ＪＰ，Ａ）
【文献】特開２０１６－１１４３９５（ＪＰ，Ａ）
【文献】特開２００３－３０８２７２（ＪＰ，Ａ）
【文献】特開２０００－２８６８８５（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｌ ６７／０２
Ｈ０４Ｍ ３／５６
(57)【特許請求の範囲】
【請求項1】
端末の音声入力装置から入力される所定デシベル未満の連続的な期間を区切り基準として
又は
該入力される内容の特殊性（所定の予約語の発音等）を区切り基準として
自動的に区切った音声単位
（他えば、一息の発言、「ピリオどうぞ」までの一文、等）に
対応する音声データを、
該入力された音声単位の順にサーバーに送信し記憶されるようにする
コンピュータプログラムであって、
サーバーに記憶された前記音声単位を新しい音声単位から順に
通信を利用して端末で再生するコンピュータプログラムであって
古い音声単位をさかのぼっている最中に、
新しい音声単位が記憶されたときは、
その音声単位が選ばれる
ことを特徴とするコンピュータプログラム。
【請求項2】
請求項１に記載のコンピュータプログラムを用いた通信方法。
【請求項3】
請求項１に記載のコンピュータプログラムを用いた通信装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、グループ音声通信のためのコンピュータプログラム、方法及び装置に関する。
【背景技術】
【0002】
従来、インターネットを介した複数関係者間のグループ通話は、操作が煩雑であったりしたため、高齢者の気軽な井戸端会議や家族間の日常的な連絡、頻度の高い会社業務連絡、等にはあまり用いられなかった。また、会話の内容を後で確認する操作・手続も、テキストチャットに比べて煩雑であり、ほとんど活用されてこなかった。また、特許文献１－２はそれらをある程度解決しようとしたものだったが、同一チャンネル（テーマを共有する会話仲間、グループ）に属する複数人が同時に発話した際にリアルタイム配信品質を保証することが困難であり、また、複数の介護施設のルーターをまたぐ広域のインターネット通話プロトコル（独自ポート番号によるＴＣＰ／ＩＰ通信等）を開通させることも現実的に困難であった。
【先行技術文献】
【特許文献】
【0003】
【文献】特願２０１２－１１０１２５
【文献】特願２０１７－０００２８７
【非特許文献】
【0004】
【文献】「ＳＫＹＰＥ 会議通話」 http://www.skype.com/intl/ja/features/allfeatures/conference-calls/
【発明の概要】
【発明が解決しようとする課題】
【0005】
したがって、本発明があ解決すべき課題は、複数人が同時に発話したときも配信品質（別の／元の端末で再生されるときの元々の音声単位の再現性）
が保証されること、複数の介護施設のルーターをまたぐ広域のインターネット通信プロトコルを開通し易くすること、又は、その両方により、現実的で手軽に・頻繁に利用できる、ある程度のグループ通話も可能な音声掲示板を実現することである。
が保証されること、複数の介護施設のルーターをまたぐ広域のインターネット通信プロトコルを開通し易くすること、又は、その両方により、現実的で手軽に・頻繁に利用できる、ある程度のグループ通話も可能な音声掲示板を実現することである。
【課題を解決するための手段】
【0006】
かかる課題を解決するため、
本発明の請求項１は、
端末の音声入力装置から入力される音量の少なさの連続性を区切り基準として又は該入力される内容の特殊性（所定の予約語の発音等）を区切り基準として
自動的に区切った音声単位（他えば、一息の発言、「ピリオどうぞ」までの一文、等）に対応する音声データを、
該入力された音声単位の順にサーバーに送信し記憶されるようにする
コンピュータプログラムを提供する。
：なお、「ピリオどうぞ」以外の「所定の予約語」としては、例えば「どうぞどうぞ」「くぎりますどうぞ」「カットカットカット」など、会話の内容と混同することの少ない様々な造語が考えられる。
＞これにより、サーバーにおけるリアルタイム処理の必要性（特に同一時間帯における複数話者からの同時音声のリアルタイム合成の必要性）をなくし、配信品質（別の端末／元の端末で再生されるときの元々の音声単位の再現性）を向上することができる。
また、本発明の請求項２は、
前記送信をＨＴＴＰＳで行うことを特徴とする
請求項１に記載のコンピュータプログラムを提供する。
＞これにより、独自プロトコルに比して、関係するルータのポートがもともと空いている可能性と、各関連サイトの管理者に新たにポートを開けてもらえる可能性が高くなるため（最も有名で信頼性も高いプロトコルであるため）、広域のインターネト通信プロトコルを開通し、新しいチャンネル（グループ）を設定・構成することが容易になる。
また、本発明の請求項３は、
端末の音声入力装置から入力される音量の少なさの連続性（前記の連続性よりも大きな連続性に限る）を区切り基準として又は該入力される内容（所定の予約語の発音等）を区切り基準として、
サーバーに記憶された前記音声単位を新しい音声単位から順に通信を利用して端末で再生することを特徴とする
請求項１又は２に記載のコンピュータプログラムを提供する。
＞これにより、子供や高齢者でも過去の発言を容易に確認することができ、家庭や会社でも手軽にかつ頻繁にグループ音声通話を利用することができるようになる。
：ここで「音声単位」に対応するものは、多くの場合、相手の反応を待つに至るまでの一利用者による一区切りのの発言（文、疑問文、文＋疑問文、文の並び＋疑問文、等）である。また、時間的に連続した発言としてまとまったＷＡＶファイル等に対応し、サーバーおよび端末のＯＳにおけるファイル名は「利用者ＩＤ＿チャンネルＵＲＩのＩＤ＿開始時分秒＿終了時分秒.ＷＡＶ」等であってよく、これらは、チャンネルＵＲＩごと、利用者ＩＤごとに階層的にディレクトリ管理されていてもよく、この場合には、ファイル名の一部が省略される等してもよい。
また、本発明の請求項４は、
複数の端末で前記サーバー又は細分化された該サーバーのＵＲＩを共有できるようにし、
該サーバー又は細分化された該サーバーのＵＲＩに関連づけて記憶する音声単位の順番を、音声単位の開始時刻、終了時刻又はそれらの中央の時刻により決定するようにし、
該サーバー又は細分化された該サーバーのＵＲＩ宛に他の端末から送信された音声単位も
該サーバー又は細分化された該サーバーのＵＲＩを共有する該複数の端末において請求項３に沿って再生するようにした
コンピュータプログラムを提供する。
＞これにより、音声単位の端末における再生順序を、サーバーの負荷をかけずに簡易に決定することができるようになり、リアルタイム性が損なわれるかわりに、安価で、現実的なグループ通話サービス（しかも過去発言が伝言板と同様に確認できる）を提供することが可能になる。
また、本発明の請求項５は、
端末が複数のサーバー又は細分化された該サーバーの複数のＵＲＩにアクセス可能になっており、
該端末からアクセスするサーバー又は細分化された該サーバーのＵＲＩを利用者により切り替え可能なように構成した
請求項１から４のいずれか一項に記載のコンピュータプログラムを提供する。
：この「切り替え」は、特許文献１のようにダイアル等で構成してもよく、音声認識により行ってもよく、健康管理スケジュール、レジャースケジュール、リフレッシュスケジュール、コミュニケーションスケジュール、報連相スケジュール、社員教育スケジュール、等にもとづいて所定の管理者が事前定義した自動タイマーでおこなってもよい
＞これにより、一つの端末で複数のチャンネル（家族連絡チャンネル、ご近所井戸端チャンネル、〇〇町俳句の会チャンネル、等）を管理することが可能になる。
また、本発明の請求項６は、
前記切り替えを
端末の音声入力装置から入力される内容により利用者が指示できるようにした
請求項５に記載のコンピュータプログラムを提供する。
：「入力される内容」は、例えば「おばチャンネル１」「おばちゃんねる俳句」「おしゃべりＢＢＳチャンネル１」等、「造語」とチャンネルの識別子を組み合わせたものなどであってもよく、それらの定義とチャンネルＵＲＩや各パスワードとのとの紐づけは利用者とは別の設定管理者がＵＳＢ接続等で端末の不揮発メモリ等にアクセスしてその中のファイルにＣＳＶ表形式等で設定することができる。
＞これにより、高齢者や子供などの利用者にも使いやすい手軽なチャンネル切替が実現し、ビジネス用途でもより多くの利用頻度が期待される。
また、本発明の請求項７は、
端末の電源もしくは音声入力装置のＯＮ／ＯＦＦ、入出力音量の大小、又は、それらの組合せについて、
端末の音声入力装置から入力される内容により利用者が指示できるようにした
請求項１から６のいずれか一項に記載のコンピュータプログラムを提供する。
：たとえば伝毛ののＯＮやＯＦＦは「おばチャンネル電源オン」「おばチャンネル電源オフ」、入出力音量のＵＰは「おばチャンネル音量プラスプラスプラス」（３度ＵＰを意味する）、ＤＯＷＮは「おばチャンネル音量マイナスマイナス」（２度のＤＯＷＮを意味する）などであってよい。
＞これにより、両手がふさがっている場合でも制御が可能となる。
また、本発明の請求項８は、
サーバーに記憶され端末に通信された音声単位を端末が記憶し、
音声単位を再生すべき再度の機会に再度同様の通信をすることなく再生できるようにした
請求項３に記載のコンピュータプログラムを提供する。
：これは例えば、コンピュータプログラムが、端末のフラッシュメモリやハードディスクに、一意に識別可能なファイル名で音声単位に対応する対象ＷＡＶファイルを複数覚えておくことにより、実現することができる。
＞これにより通信料を節約し、サーバーや回線を含めたサービスコストを削減するとともに、利用者の待ち時間も提言することができ、コスト的にもサービス品質的にも軽く、現実的なサービスを実現することができる。
：サーバーに保存するＷＡＶファイル等（音声単位に対応する）のチャンネルごとのファイル名は、明らかに一意にすることができ、そのファイルが存在するかどうかのみで、通信「キャッシュ」が有効かどうかを決定することができる。キャッシュの領域が不足したときは、最も使用（再生）されていないＷＡＶファイルを自動削除する等して対応することができる。
また、本発明の請求項９は、
端末において、音声単位の再生を開始すると決定したとき、又は、音声単位の再生が終了したとき、
次に再生すべき音声単位を
該当するサーバー又は細分化されたサーバーの該当するＵＲＩに
該端末が問い合わせするようにした
請求項１から８のいずれか一項に記載のコンピュータプログラムを提供する。
：問い合わせは、例えば、ＨＴＴＰＳのＧＥＴを用いて、接続するサーバーＵＲＩ（チャンネル）に登録してある利用者ＩＤ（多くの場合、端末ＩＤと同じでよい）、当該利用者ＩＤに（当該チャンネルにおいて）対応する利用者パスワード、最後に再生した当該チャンネル内ファイル番号、等をパラメータとして行うことができる。
＞端末に通信されて戻される内容は、多くの場合、最後に再生した当該チャンネル内ファイル番号から１を減じたものとなるが、減じる前の値が１の場合や、そのチャンネルに（多くは他人端末からの）新しい音声単位（したがって、最大のチャンネル内ファイル番号が付加されている）が記憶されている場合はには、そのチャンネル内ファイル番号（最大値）が通信されて端末に返され、最新の音声単位がもっとも優先されて端末で再生され、連絡の利便性に資することになる。、
また、本発明の請求項１０は、
サーバーに記憶する音声単位として
端末における利用者の発言以外に
各サーバー又は細分化された該サーバーの複数の各ＵＲＩに関連づけた
該当利用者層が暗記したい内容、リフレッシュのために聞きたい音楽、勉強したいテキスト又はニュース記事の系列を記憶した
請求項１から９のいずれか一項に記載のコンピュータプログラムを提供する。
：暗記したい内容は、たとえば英単語とその意味の組からなる系列（一組を一音声単位としてもよく、一定難易度レベルの複数組からなる系列を一音声単位としてもよい）。音楽も一曲を一音声単位としてもよく、アルバム等ごとにグルーピングした複数曲の系列を一音声単位としてもよい。勉強したいテキストやニュース（の読み上げ）についての音声単位への収容も同様に考えることができる。
＞これにより、当該サービスの対象となる端末を携帯する利便性がさらに向上し、有用性の高いものになる。
また、本発明の請求項１１は、
サーバーに記憶する音声単位として
端末における利用者の発言に加えて又は代えて
各サーバー又は細分化された該サーバーの複数の各ＵＲＩに関連づけた
各自動応答システムによる
応答を記憶するようにした
請求項１から１０のいずれか一項に記載のコンピュータプログラムを提供する。
：「加えて」の場合、グループの構成員の発言についてアドバイスするアドバイザーの端末が増えたような聞かせ方（利用者端末における再生シーケンス）となる。また、利用者の発言が質問形式である場合、ＱＡ形式のノート的な聞かせ方にすることができる。
：「代えて」の場合、利用者の発言（誤解等もありうる）を省略するため、タイムリーに利用者に有用な正しい知識のみを、グループ内の他の利用者に対して提供することができ、誤解による発言の内容が正としてひろまるリスクを抑えることができる。
：これはたとえばＵＲＩ１に対しては、お笑い系の自動応答システムをひもづけて発言に体操した応答によりリラックス効果を生むことができ、ＵＲＩ２に対しては教養系の自動応答システムをひもづけて発言に関連する教養内容を通信して返すとともに後で聞き返しすることを可能にするものである。
＞これにより、通話だけでなく、知識体系やカリキュラムシステムやニュースシステム（各社のＷＥＢーＡＰＩ等）と連携させた汎用コミュニケーション（プラットフォーム）端末としてサービスや端末設定を構成することも容易となる。
また、本発明の請求項１２は、
請求項１から１１のいずれか一項に記載のコンピュータプログラムを用いた通信方法を提供する。
また、本発明の請求項１３は、
請求項１から１１のいずれか一項に記載のコンピュータプログラムを用いた通信装置を提供する。
本発明の請求項１は、
端末の音声入力装置から入力される音量の少なさの連続性を区切り基準として又は該入力される内容の特殊性（所定の予約語の発音等）を区切り基準として
自動的に区切った音声単位（他えば、一息の発言、「ピリオどうぞ」までの一文、等）に対応する音声データを、
該入力された音声単位の順にサーバーに送信し記憶されるようにする
コンピュータプログラムを提供する。
：なお、「ピリオどうぞ」以外の「所定の予約語」としては、例えば「どうぞどうぞ」「くぎりますどうぞ」「カットカットカット」など、会話の内容と混同することの少ない様々な造語が考えられる。
＞これにより、サーバーにおけるリアルタイム処理の必要性（特に同一時間帯における複数話者からの同時音声のリアルタイム合成の必要性）をなくし、配信品質（別の端末／元の端末で再生されるときの元々の音声単位の再現性）を向上することができる。
また、本発明の請求項２は、
前記送信をＨＴＴＰＳで行うことを特徴とする
請求項１に記載のコンピュータプログラムを提供する。
＞これにより、独自プロトコルに比して、関係するルータのポートがもともと空いている可能性と、各関連サイトの管理者に新たにポートを開けてもらえる可能性が高くなるため（最も有名で信頼性も高いプロトコルであるため）、広域のインターネト通信プロトコルを開通し、新しいチャンネル（グループ）を設定・構成することが容易になる。
また、本発明の請求項３は、
端末の音声入力装置から入力される音量の少なさの連続性（前記の連続性よりも大きな連続性に限る）を区切り基準として又は該入力される内容（所定の予約語の発音等）を区切り基準として、
サーバーに記憶された前記音声単位を新しい音声単位から順に通信を利用して端末で再生することを特徴とする
請求項１又は２に記載のコンピュータプログラムを提供する。
＞これにより、子供や高齢者でも過去の発言を容易に確認することができ、家庭や会社でも手軽にかつ頻繁にグループ音声通話を利用することができるようになる。
：ここで「音声単位」に対応するものは、多くの場合、相手の反応を待つに至るまでの一利用者による一区切りのの発言（文、疑問文、文＋疑問文、文の並び＋疑問文、等）である。また、時間的に連続した発言としてまとまったＷＡＶファイル等に対応し、サーバーおよび端末のＯＳにおけるファイル名は「利用者ＩＤ＿チャンネルＵＲＩのＩＤ＿開始時分秒＿終了時分秒.ＷＡＶ」等であってよく、これらは、チャンネルＵＲＩごと、利用者ＩＤごとに階層的にディレクトリ管理されていてもよく、この場合には、ファイル名の一部が省略される等してもよい。
また、本発明の請求項４は、
複数の端末で前記サーバー又は細分化された該サーバーのＵＲＩを共有できるようにし、
該サーバー又は細分化された該サーバーのＵＲＩに関連づけて記憶する音声単位の順番を、音声単位の開始時刻、終了時刻又はそれらの中央の時刻により決定するようにし、
該サーバー又は細分化された該サーバーのＵＲＩ宛に他の端末から送信された音声単位も
該サーバー又は細分化された該サーバーのＵＲＩを共有する該複数の端末において請求項３に沿って再生するようにした
コンピュータプログラムを提供する。
＞これにより、音声単位の端末における再生順序を、サーバーの負荷をかけずに簡易に決定することができるようになり、リアルタイム性が損なわれるかわりに、安価で、現実的なグループ通話サービス（しかも過去発言が伝言板と同様に確認できる）を提供することが可能になる。
また、本発明の請求項５は、
端末が複数のサーバー又は細分化された該サーバーの複数のＵＲＩにアクセス可能になっており、
該端末からアクセスするサーバー又は細分化された該サーバーのＵＲＩを利用者により切り替え可能なように構成した
請求項１から４のいずれか一項に記載のコンピュータプログラムを提供する。
：この「切り替え」は、特許文献１のようにダイアル等で構成してもよく、音声認識により行ってもよく、健康管理スケジュール、レジャースケジュール、リフレッシュスケジュール、コミュニケーションスケジュール、報連相スケジュール、社員教育スケジュール、等にもとづいて所定の管理者が事前定義した自動タイマーでおこなってもよい
＞これにより、一つの端末で複数のチャンネル（家族連絡チャンネル、ご近所井戸端チャンネル、〇〇町俳句の会チャンネル、等）を管理することが可能になる。
また、本発明の請求項６は、
前記切り替えを
端末の音声入力装置から入力される内容により利用者が指示できるようにした
請求項５に記載のコンピュータプログラムを提供する。
：「入力される内容」は、例えば「おばチャンネル１」「おばちゃんねる俳句」「おしゃべりＢＢＳチャンネル１」等、「造語」とチャンネルの識別子を組み合わせたものなどであってもよく、それらの定義とチャンネルＵＲＩや各パスワードとのとの紐づけは利用者とは別の設定管理者がＵＳＢ接続等で端末の不揮発メモリ等にアクセスしてその中のファイルにＣＳＶ表形式等で設定することができる。
＞これにより、高齢者や子供などの利用者にも使いやすい手軽なチャンネル切替が実現し、ビジネス用途でもより多くの利用頻度が期待される。
また、本発明の請求項７は、
端末の電源もしくは音声入力装置のＯＮ／ＯＦＦ、入出力音量の大小、又は、それらの組合せについて、
端末の音声入力装置から入力される内容により利用者が指示できるようにした
請求項１から６のいずれか一項に記載のコンピュータプログラムを提供する。
：たとえば伝毛ののＯＮやＯＦＦは「おばチャンネル電源オン」「おばチャンネル電源オフ」、入出力音量のＵＰは「おばチャンネル音量プラスプラスプラス」（３度ＵＰを意味する）、ＤＯＷＮは「おばチャンネル音量マイナスマイナス」（２度のＤＯＷＮを意味する）などであってよい。
＞これにより、両手がふさがっている場合でも制御が可能となる。
また、本発明の請求項８は、
サーバーに記憶され端末に通信された音声単位を端末が記憶し、
音声単位を再生すべき再度の機会に再度同様の通信をすることなく再生できるようにした
請求項３に記載のコンピュータプログラムを提供する。
：これは例えば、コンピュータプログラムが、端末のフラッシュメモリやハードディスクに、一意に識別可能なファイル名で音声単位に対応する対象ＷＡＶファイルを複数覚えておくことにより、実現することができる。
＞これにより通信料を節約し、サーバーや回線を含めたサービスコストを削減するとともに、利用者の待ち時間も提言することができ、コスト的にもサービス品質的にも軽く、現実的なサービスを実現することができる。
：サーバーに保存するＷＡＶファイル等（音声単位に対応する）のチャンネルごとのファイル名は、明らかに一意にすることができ、そのファイルが存在するかどうかのみで、通信「キャッシュ」が有効かどうかを決定することができる。キャッシュの領域が不足したときは、最も使用（再生）されていないＷＡＶファイルを自動削除する等して対応することができる。
また、本発明の請求項９は、
端末において、音声単位の再生を開始すると決定したとき、又は、音声単位の再生が終了したとき、
次に再生すべき音声単位を
該当するサーバー又は細分化されたサーバーの該当するＵＲＩに
該端末が問い合わせするようにした
請求項１から８のいずれか一項に記載のコンピュータプログラムを提供する。
：問い合わせは、例えば、ＨＴＴＰＳのＧＥＴを用いて、接続するサーバーＵＲＩ（チャンネル）に登録してある利用者ＩＤ（多くの場合、端末ＩＤと同じでよい）、当該利用者ＩＤに（当該チャンネルにおいて）対応する利用者パスワード、最後に再生した当該チャンネル内ファイル番号、等をパラメータとして行うことができる。
＞端末に通信されて戻される内容は、多くの場合、最後に再生した当該チャンネル内ファイル番号から１を減じたものとなるが、減じる前の値が１の場合や、そのチャンネルに（多くは他人端末からの）新しい音声単位（したがって、最大のチャンネル内ファイル番号が付加されている）が記憶されている場合はには、そのチャンネル内ファイル番号（最大値）が通信されて端末に返され、最新の音声単位がもっとも優先されて端末で再生され、連絡の利便性に資することになる。、
また、本発明の請求項１０は、
サーバーに記憶する音声単位として
端末における利用者の発言以外に
各サーバー又は細分化された該サーバーの複数の各ＵＲＩに関連づけた
該当利用者層が暗記したい内容、リフレッシュのために聞きたい音楽、勉強したいテキスト又はニュース記事の系列を記憶した
請求項１から９のいずれか一項に記載のコンピュータプログラムを提供する。
：暗記したい内容は、たとえば英単語とその意味の組からなる系列（一組を一音声単位としてもよく、一定難易度レベルの複数組からなる系列を一音声単位としてもよい）。音楽も一曲を一音声単位としてもよく、アルバム等ごとにグルーピングした複数曲の系列を一音声単位としてもよい。勉強したいテキストやニュース（の読み上げ）についての音声単位への収容も同様に考えることができる。
＞これにより、当該サービスの対象となる端末を携帯する利便性がさらに向上し、有用性の高いものになる。
また、本発明の請求項１１は、
サーバーに記憶する音声単位として
端末における利用者の発言に加えて又は代えて
各サーバー又は細分化された該サーバーの複数の各ＵＲＩに関連づけた
各自動応答システムによる
応答を記憶するようにした
請求項１から１０のいずれか一項に記載のコンピュータプログラムを提供する。
：「加えて」の場合、グループの構成員の発言についてアドバイスするアドバイザーの端末が増えたような聞かせ方（利用者端末における再生シーケンス）となる。また、利用者の発言が質問形式である場合、ＱＡ形式のノート的な聞かせ方にすることができる。
：「代えて」の場合、利用者の発言（誤解等もありうる）を省略するため、タイムリーに利用者に有用な正しい知識のみを、グループ内の他の利用者に対して提供することができ、誤解による発言の内容が正としてひろまるリスクを抑えることができる。
：これはたとえばＵＲＩ１に対しては、お笑い系の自動応答システムをひもづけて発言に体操した応答によりリラックス効果を生むことができ、ＵＲＩ２に対しては教養系の自動応答システムをひもづけて発言に関連する教養内容を通信して返すとともに後で聞き返しすることを可能にするものである。
＞これにより、通話だけでなく、知識体系やカリキュラムシステムやニュースシステム（各社のＷＥＢーＡＰＩ等）と連携させた汎用コミュニケーション（プラットフォーム）端末としてサービスや端末設定を構成することも容易となる。
また、本発明の請求項１２は、
請求項１から１１のいずれか一項に記載のコンピュータプログラムを用いた通信方法を提供する。
また、本発明の請求項１３は、
請求項１から１１のいずれか一項に記載のコンピュータプログラムを用いた通信装置を提供する。
【発明を実施するための形態】
【0007】
図１は、本発明の例としての一実施形態におけるクライアント（端末）側のコンピュータプログラムの動作を示す説明図である。
図（図２も同じ）において、「□」は処理を、「〇」はループ（繰り返し、タイマー割込みによるものを含む）、「◇」は分岐または分岐を含む処理を示す。
このような制御や処理を行える通信端末の仕組み、ＯＳ、プログラミング環境自体は周知であるため詳述しないが、当業者であれば、図１を参考にすれば、明らかに本発明によるクライアント端末を容易に実装することが可能である。
＝＝＝以下、図１と同文＝＝＝
■クライアント（ＮａｎｏＰｉ、ラズパイ又は安価なWindows端末などの端末）
□クライアント（端末）電源ＯＮ
□音声入力装置（マイクデバイス）と入力バッファを初期化し、音声入力をバッファリングし始める（音声入力スレッドを開始、1000～3000ms期間中の最大デシベルを大域変数に格納）
□音声出力装置（スピーカデバイス）と出力バッファを初期化し、再生可能にする（音声出力（再生）スレッドを初期化）
□利用者ＩＤ、及び、＜端末内チャンネル番号，チャンネルＵＲＩ，利用者毎チャンネルＵＲＩパスワード＞の対応表（端末の設定管理者がＣＳＶで設定）を所定ファイルからロードする
□前回使用していた端末内チャンネル番号および音量データ（再生用、録音用）をファイルからロードする
□チャンネル番号の変更フラグをたてる
〇メインループ（１０００～３０００ｍｓに１回タイマー割込処理する）
｜ □メインループへの再入禁止フラグが立っている（ＴＲＵＥの）場合、ここでＢＲＥＡＫする（何もしない）
｜ ◇チャンネル番号の変更フラグが立っている場合
｜ ｜ □利用者音声ファイルを初期化する（空にする）
｜ ｜ □再生中のファイルがないことにする（再生フラグ←ＦＡＬＳＥ）
｜ ｜ □メインループの再入禁止フラグを初期化する（再入禁止フラグ←ＦＡＬＳＥ）
｜ ｜ □チャンネルの変更フラグをおろす
｜ ◇入力バッファに所定デシベル以上の利用者音声があり、かつ、区切りを意味する所定予約語がない場合（前回からの１０００～３０００ｍｓの間に）
｜ ｜ □利用者音声を録音する（＝現在の利用者音声ファイルに１０００～３０００ｍｓ分を追加する）
｜ ｜ □メインループをＢＲＥＡＫする（ただし、音声出力（再生）スレッドには影響を与えない）
｜ ◇入力バッファに所定デシベル以上の利用者音声がない場合（前回からの１０００～３０００ｍｓの間に）又は所定予約語により発言を区切った場合
｜ ◇未送信の利用者音声ファイル内容がある場合（すなわち、利用者が発言を終えた（＝所定デシベル未満の連続的な期間や所定予約語により発言を区切った）直後の場合）
｜ ｜ ※再生中のファイルがある場合も、ない場合も、音声出力（再生）スレッドには影響を与えない
｜ ｜ □メインループへの再入禁止フラグをたてる（ＴＲＵＥにする）
｜ ｜ □未送信の利用者音声ファイルをＰＯＳＴする（利用者ＩＤ，チャンネルＵＲＩ、利用者の該チャンネルＵＲＩのパスワード、音声ファイルをエンコードしたものの４つをパラメータにする）
｜ ｜ □メインループへの再入禁止フラグをおろす（ＦＡＬＳＥにする）
｜ ｜ □利用者音声ファイルを初期化する（空にする）
｜ ◇未送信の利用者音声ファイル内容がない場合
｜ ◇再生中のファイルがある場合
｜ ｜ □メインループをＢＲＥＡＫする。すなわち、そのまま再生しつづける（なにもせず、マルチスレッド処理で音声出力（再生）スレッドは生きたまま）
｜ ◇再生中のファイルがない場合
｜ □サーバーから何を再生すべきかＧＥＴする（利用者ＩＤ，チャンネルＵＲＩ、利用者の該チャンネルＵＲＩのパスワード、そのチャンネルで最後に再生した記事番号をパラメータにする）
｜ ◇再生すべきファイル（音声単位）がすでにダウンロード（キャッシュ）されている場合
｜ ｜ □ダウンロード（キャッシュ）されているそのファイル（音声単位）の再生を開始する
｜ ◇再生すべきファイル（音声単位）がいまだダウンロード（キャッシュ）されていない場合
｜ □サーバーから新たにそのファイル（音声単位）をＧＥＴしキャッシュ（領域が足らない場合、最も古いものを削除してキャッシュ）して、そのファイルの再生を開始する
□現在のチャンネル番号および音量データ（再生用、録音用）をファイルにセーブする
□クライアント（端末）電源ＯＦＦ
＝＝＝以上、図１と同文＝＝＝
図２は、本発明の例としての一実施形態におけるサーバー側のコンピュータプログラムの動作を示す説明図である。
サーバーソフトウエアについても、当業者は、図２を参考にすれば、容易に実装可能である。
＝＝＝以下、図２と同文＝＝＝
■サーバー
〇メインループ
□要求（ＨＴＴＰＳのＧＥＴ又はＰＯＳＴ）の利用者ＩＤ／パスワードにより、チャンネル（ＵＲＩ）として許容していない利用者（クライアント、端末）からの要求（ＧＥＴやＰＯＳＴ）をはじく
｜ ※チャンネルの利用者ＩＤ／パスワードの管理はディレクトリで階層化したプレインテキスト（パスワードはハッシュで照合する）とする
◇ＧＥＴで次に再生すべきファイル（音声単位）を要求された場合
｜ ◇そのチャンネルのファイル数の更新がない場合、ＧＥＴのパラメータに含まれるチャンネルＵＲＩとチャンネル内記事番号から、一つ前のファイル番号を計算して通信して返す
｜ ◇そのチャンネルのファイル数の更新がある場合、又は、チャンネル内記事番号が１の場合、そのチャンネルの最大ファイル番号（最新を聞いてもらう為）を通信して返す
◇ＧＥＴで再生ファイル（音声単位）そのものを要求された場合
｜ □再生ファイル（音声単位）を通信して返す
◇ＰＯＳＴで保存して配信すべきファイル（音声単位）を受領した場合
□保存し、そのチャンネル（サーバーＵＲＩ）のファイル数（＝最大ファイル番号）を記憶するファイルを更新する
＝＝＝以上、図２と同文＝＝＝
他の実施の形態においては、以下のようなバリエーションもありうる。
端末の音声入力装置から入力される音量の少なさではなく、内容の特殊性を区切り基準として
自動的に区切った音声単位に対応する音声データを、
該入力された順にサーバーに送信し記憶されるようにすることもできる。
通信はＨＴＴＰＳ（インターネット）のほかに、やＨＴＴＰ（イントラネット）でも行いうる。
サーバーに記憶された音声単位は新しい音声単位から順に通信を利用して端末で再生する。古い音声単位をさかのぼっている最中に、新しい音声単位が記憶されたときは、その音声単位が選ばれるモードと、いったん古い音声単位の記事番号が１となるまでさかのぼるモードを用意することもできる。
複数の端末で前記サーバーのＵＲＩを共有できるようにし、
ＵＲＩに関連づけて記憶する音声単位の再生順番を開始時刻だけでなく終了時刻等により決定する。
端末は異なるチャンネルを構成する複数サーバーＵＲＩにアクセス可能になっており、
利用者音声による音声認識又はジョグダイアルにより切り替え可能なように構成している。
切り替えは、端末の音声入力装置から入力される内容により利用者が指示できる。
端末の電源もしくは音声入力装置のＯＮ／ＯＦＦ、入出力音量の大小、等についても利用者が音声で指示可能である。
サーバーに記憶され端末に通信された音声単位は端末でキャッシュされ複数回の再生に対応する。
端末において、音声単位の再生を開始すると決定したとき、又は、音声単位の再生が終了したとき、
次に再生すべき音声単位を該当するサーバーＵＲＩに該端末が問い合わせをする（これらはＧＥＴでなくＰＯＳＴでも構わない）。
サーバーに記憶する音声単位として、端末における利用者の発言以外に、各ＵＲＩ等に関連づけた該当利用者層が暗記したい内容やリフレッシュのために聞きたい音楽やニュース記事等の系列を記憶する。
サーバーに記憶する音声単位として、端末における利用者の発言に加えて又は代えて、各自動応答システムによる応答を記憶するようにする。
図（図２も同じ）において、「□」は処理を、「〇」はループ（繰り返し、タイマー割込みによるものを含む）、「◇」は分岐または分岐を含む処理を示す。
このような制御や処理を行える通信端末の仕組み、ＯＳ、プログラミング環境自体は周知であるため詳述しないが、当業者であれば、図１を参考にすれば、明らかに本発明によるクライアント端末を容易に実装することが可能である。
＝＝＝以下、図１と同文＝＝＝
■クライアント（ＮａｎｏＰｉ、ラズパイ又は安価なWindows端末などの端末）
□クライアント（端末）電源ＯＮ
□音声入力装置（マイクデバイス）と入力バッファを初期化し、音声入力をバッファリングし始める（音声入力スレッドを開始、1000～3000ms期間中の最大デシベルを大域変数に格納）
□音声出力装置（スピーカデバイス）と出力バッファを初期化し、再生可能にする（音声出力（再生）スレッドを初期化）
□利用者ＩＤ、及び、＜端末内チャンネル番号，チャンネルＵＲＩ，利用者毎チャンネルＵＲＩパスワード＞の対応表（端末の設定管理者がＣＳＶで設定）を所定ファイルからロードする
□前回使用していた端末内チャンネル番号および音量データ（再生用、録音用）をファイルからロードする
□チャンネル番号の変更フラグをたてる
〇メインループ（１０００～３０００ｍｓに１回タイマー割込処理する）
｜ □メインループへの再入禁止フラグが立っている（ＴＲＵＥの）場合、ここでＢＲＥＡＫする（何もしない）
｜ ◇チャンネル番号の変更フラグが立っている場合
｜ ｜ □利用者音声ファイルを初期化する（空にする）
｜ ｜ □再生中のファイルがないことにする（再生フラグ←ＦＡＬＳＥ）
｜ ｜ □メインループの再入禁止フラグを初期化する（再入禁止フラグ←ＦＡＬＳＥ）
｜ ｜ □チャンネルの変更フラグをおろす
｜ ◇入力バッファに所定デシベル以上の利用者音声があり、かつ、区切りを意味する所定予約語がない場合（前回からの１０００～３０００ｍｓの間に）
｜ ｜ □利用者音声を録音する（＝現在の利用者音声ファイルに１０００～３０００ｍｓ分を追加する）
｜ ｜ □メインループをＢＲＥＡＫする（ただし、音声出力（再生）スレッドには影響を与えない）
｜ ◇入力バッファに所定デシベル以上の利用者音声がない場合（前回からの１０００～３０００ｍｓの間に）又は所定予約語により発言を区切った場合
｜ ◇未送信の利用者音声ファイル内容がある場合（すなわち、利用者が発言を終えた（＝所定デシベル未満の連続的な期間や所定予約語により発言を区切った）直後の場合）
｜ ｜ ※再生中のファイルがある場合も、ない場合も、音声出力（再生）スレッドには影響を与えない
｜ ｜ □メインループへの再入禁止フラグをたてる（ＴＲＵＥにする）
｜ ｜ □未送信の利用者音声ファイルをＰＯＳＴする（利用者ＩＤ，チャンネルＵＲＩ、利用者の該チャンネルＵＲＩのパスワード、音声ファイルをエンコードしたものの４つをパラメータにする）
｜ ｜ □メインループへの再入禁止フラグをおろす（ＦＡＬＳＥにする）
｜ ｜ □利用者音声ファイルを初期化する（空にする）
｜ ◇未送信の利用者音声ファイル内容がない場合
｜ ◇再生中のファイルがある場合
｜ ｜ □メインループをＢＲＥＡＫする。すなわち、そのまま再生しつづける（なにもせず、マルチスレッド処理で音声出力（再生）スレッドは生きたまま）
｜ ◇再生中のファイルがない場合
｜ □サーバーから何を再生すべきかＧＥＴする（利用者ＩＤ，チャンネルＵＲＩ、利用者の該チャンネルＵＲＩのパスワード、そのチャンネルで最後に再生した記事番号をパラメータにする）
｜ ◇再生すべきファイル（音声単位）がすでにダウンロード（キャッシュ）されている場合
｜ ｜ □ダウンロード（キャッシュ）されているそのファイル（音声単位）の再生を開始する
｜ ◇再生すべきファイル（音声単位）がいまだダウンロード（キャッシュ）されていない場合
｜ □サーバーから新たにそのファイル（音声単位）をＧＥＴしキャッシュ（領域が足らない場合、最も古いものを削除してキャッシュ）して、そのファイルの再生を開始する
□現在のチャンネル番号および音量データ（再生用、録音用）をファイルにセーブする
□クライアント（端末）電源ＯＦＦ
＝＝＝以上、図１と同文＝＝＝
図２は、本発明の例としての一実施形態におけるサーバー側のコンピュータプログラムの動作を示す説明図である。
サーバーソフトウエアについても、当業者は、図２を参考にすれば、容易に実装可能である。
＝＝＝以下、図２と同文＝＝＝
■サーバー
〇メインループ
□要求（ＨＴＴＰＳのＧＥＴ又はＰＯＳＴ）の利用者ＩＤ／パスワードにより、チャンネル（ＵＲＩ）として許容していない利用者（クライアント、端末）からの要求（ＧＥＴやＰＯＳＴ）をはじく
｜ ※チャンネルの利用者ＩＤ／パスワードの管理はディレクトリで階層化したプレインテキスト（パスワードはハッシュで照合する）とする
◇ＧＥＴで次に再生すべきファイル（音声単位）を要求された場合
｜ ◇そのチャンネルのファイル数の更新がない場合、ＧＥＴのパラメータに含まれるチャンネルＵＲＩとチャンネル内記事番号から、一つ前のファイル番号を計算して通信して返す
｜ ◇そのチャンネルのファイル数の更新がある場合、又は、チャンネル内記事番号が１の場合、そのチャンネルの最大ファイル番号（最新を聞いてもらう為）を通信して返す
◇ＧＥＴで再生ファイル（音声単位）そのものを要求された場合
｜ □再生ファイル（音声単位）を通信して返す
◇ＰＯＳＴで保存して配信すべきファイル（音声単位）を受領した場合
□保存し、そのチャンネル（サーバーＵＲＩ）のファイル数（＝最大ファイル番号）を記憶するファイルを更新する
＝＝＝以上、図２と同文＝＝＝
他の実施の形態においては、以下のようなバリエーションもありうる。
端末の音声入力装置から入力される音量の少なさではなく、内容の特殊性を区切り基準として
自動的に区切った音声単位に対応する音声データを、
該入力された順にサーバーに送信し記憶されるようにすることもできる。
通信はＨＴＴＰＳ（インターネット）のほかに、やＨＴＴＰ（イントラネット）でも行いうる。
サーバーに記憶された音声単位は新しい音声単位から順に通信を利用して端末で再生する。古い音声単位をさかのぼっている最中に、新しい音声単位が記憶されたときは、その音声単位が選ばれるモードと、いったん古い音声単位の記事番号が１となるまでさかのぼるモードを用意することもできる。
複数の端末で前記サーバーのＵＲＩを共有できるようにし、
ＵＲＩに関連づけて記憶する音声単位の再生順番を開始時刻だけでなく終了時刻等により決定する。
端末は異なるチャンネルを構成する複数サーバーＵＲＩにアクセス可能になっており、
利用者音声による音声認識又はジョグダイアルにより切り替え可能なように構成している。
切り替えは、端末の音声入力装置から入力される内容により利用者が指示できる。
端末の電源もしくは音声入力装置のＯＮ／ＯＦＦ、入出力音量の大小、等についても利用者が音声で指示可能である。
サーバーに記憶され端末に通信された音声単位は端末でキャッシュされ複数回の再生に対応する。
端末において、音声単位の再生を開始すると決定したとき、又は、音声単位の再生が終了したとき、
次に再生すべき音声単位を該当するサーバーＵＲＩに該端末が問い合わせをする（これらはＧＥＴでなくＰＯＳＴでも構わない）。
サーバーに記憶する音声単位として、端末における利用者の発言以外に、各ＵＲＩ等に関連づけた該当利用者層が暗記したい内容やリフレッシュのために聞きたい音楽やニュース記事等の系列を記憶する。
サーバーに記憶する音声単位として、端末における利用者の発言に加えて又は代えて、各自動応答システムによる応答を記憶するようにする。
【図面の簡単な説明】
【0008】
【図1】本発明の例としての一実施形態におけるクライアント（端末）側のコンピュータプログラムの動作を示す説明図である。
【図2】本発明の例としての一実施形態におけるサーバー側のコンピュータプログラムの動作を示す説明図である。
【図1】
【図2】