JP2010218013A - データ配信システム - Google Patents

Abstract

【課題】ソース装置とサーバ装置の通信回線が中断してもクライアント装置に配信されるデータを途切れさせないようにしたデータ配信システムの提供。
【解決手段】このシステムでは、音声データなどのリアルタイムデータをソース装置ＲＣａからサーバ装置ＳＶを介してクライアント装置ＣＬａ１，ＣＬａ２に配信する。ソースＲＣａは、リアルタイムデータをバッファ２Ｂに実時間レートで順次入力してバッファリングし、サーバＳＶと通信可能な通常状態ではバッファリングしたデータを実時間レートで読み出しサーバＳＶに転送し、サーバＳＶと通信不能になり再び通信可能状態に回復すると、通信不能状態の間にバッファメモリ２Ｂに蓄積された音声データを実時間レートより速いレートで読み出してサーバＳＶに転送する。サーバＳＶは、ソースＲＣａから転送されてくるデータをバッファリングし実時間レートでクライアントＣＬａ１，ＣＬａ２に配信する。
【選択図】図１

Description

この発明は、音声データなどのリアルタイムデータを、データ供給源であるソース装置からサーバ装置を介してクライアント装置に配信するデータ配信システムに関する。

従来より、サーバ装置から音声データなどのデータをクライアント装置に配信するシステムが知られている。例えば、特許文献１の録音データ配信システムでは、リアルタイムデータではないが、録音データをサーバ装置にアップし、その後クライアント装置で聴取することができる。また、特許文献２のオーディオ配信システムでは、サーバ装置から複数のクライアント装置にオーディオデータをストリーミング配信する際、オーディオデータバッファ量が目標値を維持できるよう読出速度を制御し、全てのクライアント装置の再生を同期させることができる。さらに、携帯用電話機、「スカイプ」と呼ばれるインターネット電話サービス及びパーソナルコンピュータ（ＰＣ）を使い、インターネット上で主として音声データで番組をリアルタイムに配信するネットラジオシステムがある。

特開２００５−３１６８９１号公報 特開２００５−１４８５６５号公報

ここで、音声データなどのリアルタイムデータを情報発信元のソース装置からサーバ装置を介してクライアント装置に配信することを考えた場合、ソース装置とサーバ装置の通信回線が中断している間は情報を発信すること自体ができない。例えば、ソース装置が携帯用電話機の場合、電車で山間部の電波の届きにくいところにさしかかるとサーバ装置との通信が中断して中継できなくなり、後で通信が再開したときに「いやー先ほどの景色はすごかったですね。生でお伝えできなかったのが残念です。」というしかない。

この発明は、このような事情に鑑み、音声データなどのリアルタイムデータをソース装置からサーバ装置を介してクライアント装置に配信する際、ソース装置とサーバ装置の通信回線が中断してもソース装置からクライアント装置に配信されるデータを途切れさせないようにすることができるデータ配信システムを提供することを目的とする。

この発明の主たる特徴に従うと、ソース装置（ＲＣ：例えば、ＲＣａ）、サーバ装置（ＳＶ）及び１以上のクライアント装置（ＣＬ：例えば、ＣＬａ１，ＣＬａ２）から成るデータ配信システムであって、ソース装置（ＲＣ）は、リアルタイムデータをバッファリングするソースバッファリング手段（２Ｂ；Ｒ３）と、サーバ装置（ＳＶ）との間の通信状態を検知するソース通信状態検知手段（Ｒ６，Ｒ７）と、ソース通信状態検知手段によりサーバ装置（ＳＶ）との通信が可であると検知されている間（Ｒ４＝ＹＥＳ）、ソースバッファリング手段によりバッファリングされたデータを実時間レートで順次サーバ装置（ＳＶ）に転送する第１転送手段（Ｒ５）と、ソース通信状態検知手段によりサーバ装置（ＳＶ）との通信が不可となった後に再び可となったことが検知されたときに（Ｒ６→Ｒ４＝ＮＯ→Ｒ８＝ＹＥＳ）、第１転送手段によるデータ転送に先立って、通信不可の間にソースバッファリング手段によりバッファリングされたデータを実時間レートより速いレートでサーバ装置（ＳＶ）に転送する第２転送手段（Ｒ９）とを具備し、サーバ装置（ＳＶ）は、第１転送手段（Ｒ５）及び第２転送手段（Ｒ９）により転送されるデータ（Ｄｒｓ，Ｄｒｂ）をバッファリングするサーババッファリング手段（ＳＢ：Ｓ７，Ｓ８）と、サーババッファリング手段によりバッファリングされたデータ（Ｄｓ）を実時間レートでクライアント装置（ＣＬ）に配信するバッファリングデータ配信手段（Ｓ１１）とを具備するデータ配信システム〔請求項１〕が提供される。なお、括弧書きは、理解の便のために付記した実施例の参照記号や用語等であり、以下においても同様である。

この発明によるデータ配信システムにおいて、サーバ装置（ＳＶ）は、さらに、ソース装置（ＳＶ）との間の通信状態を検知するサーバ通信状態検知手段と、サーバ通信状態検知手段によりソース装置との通信が不可であることが検知されている間（Ｓ１０＝ＮＯ）、予め用意された別のコンテンツデータ（Ｄｅ）をクライアント装置（ＣＬ）に配信する別データ配信手段（Ｓ１２）とを具備する〔請求項２〕ように構成することができる。

また、この発明によるデータ配信システムにおいて、サーバ装置（ＳＶ）は、さらに、第２転送手段（Ｒ８）により転送されるデータ（Ｄｒｂ）及びこのデータ転送に続く所定時間の間第１転送手段（Ｒ５）により転送されるデータ（Ｄｒｓ）の時間軸を実時間より短縮する速度変換手段（ＳＡ：Ｓ８）を具備し、サーババッファリング手段（ＳＢ：Ｓ７，Ｓ８）は、速度変換手段（ＳＡ）により時間軸が短縮されたデータをバッファリングする（ＳＢ：Ｓ８）〔請求項３〕ように構成することができる。

この発明によるデータ配信システムは（請求項１）、ソース装置（ＲＣ：例えば、ＲＣａ）、サーバ装置（ＳＶ）及び１以上のクライアント装置（ＣＬ：例えば、ＣＬａ１，ＣＬａ２）から成る。ソース装置（ＲＣ）は、音声や音楽、映像などのリアルタイムデータをバッファリングし（２Ｂ；Ｒ３）、通信可能な通常状態では、バッファリングしたデータ（Ｄｒｓ）を実時間レートでサーバ装置（ＳＶ）に転送するが（Ｒ５）、サーバ装置（ＳＶ）との通信が不可となった後に再び可となったことが検知されたときには（Ｒ６→Ｒ４＝ＮＯ→Ｒ８＝ＹＥＳ）、通信不可の間にバッファリングされたデータ（Ｄｒｂ）を実時間レートより速いレートでサーバ装置（ＳＶ）に転送する（Ｒ９）。サーバ装置（ＳＶ）は、ソース装置（ＲＣ）から実時間レートで転送される通常時（Ｓ５＝ＹＥＳ→Ｓ６＝ＮＯ）のデータ（Ｄｒｓ）及び実時間より速いレートで転送される通信復旧時（Ｓ４＝ＹＥＳ）のデータ（Ｄｒｂ）をバッファリングし（Ｓ７，Ｓ８）、バッファリングされたデータ（Ｄｓ）を実時間レートでクライアント装置（ＣＬ）に配信する（Ｓ１１）。

従って、この発明によれば、音声データなどのリアルタイムデータをソース装置からサーバ装置を介してクライアント装置に配信する際、ソース装置とサーバ装置の通信回線が中断してもソース装置からクライアント装置に配信されるデータは途切れさせないようにすることができる

また、この発明によるデータ配信システムでは、サーバ装置（ＳＶ）は、ソース装置（ＳＶ）との通信が不可である間（Ｓ１０＝ＮＯ）、予め用意された別のコンテンツデータ（Ｄｅ）をクライアント装置（ＣＬ）に配信する（Ｓ１２）ようにしている（請求項２）。従って、この発明によれば、音声データなどのリアルタイムデータの配信を受けているクライアント装置に対して、ソース装置・サーバ装置間の通信が中断している間は、予め用意した別のコンテンツを配信することができ、例えば、音声データの番組を聴いているクライアントに、予め用意した別の音声データによる番組を聴いてもらうことができる。

さらに、この発明によるデータ配信システムでは、サーバ装置（ＳＶ）において、ソース装置（ＲＣ）・サーバ装置（ＳＶ）間の通信が再開した際に（Ｓ４＝ＹＥＳ）ソース装置（ＲＣ）から実時間レートより速いレートで転送されるデータ〔通信不可の間、ソース装置（ＲＣ）でバッファリングされたデータＤｒｂ〕及びこのデータ転送に続く所定時間の間〔バッファリングデータＤｂ（Ｐｒ〜Ｐｗ）が最小時間分になる（Ｓ６＝ＹＥＳ）までの間〕実時間レートで転送されるデータ（Ｄｒｓ）の時間軸を実時間より短縮し（ＳＡ：Ｓ８）、時間軸が短縮されたデータ（Ｄａ）をバッファリングする（ＳＢ：Ｓ８）ようにしている（請求項３）。従って、この発明によれば、データが実時間レートでクライアント装置に配信されているにも拘わらず、ソース装置・サーバ装置間の通信再開時に、クライアント装置では、このデータに基づいて音声や音楽、映像などを高速に再生し、通信不可が復旧したときの遅れを回復して行きやがて最小の遅れをもつ元のデータ受信状態に復帰することができる。

この発明の一実施例によるデータ配信システムの構成例を示す。 この発明の一実施例によるソース装置データ転送処理フローの例を示す。 この発明の一実施例によるサーバ装置データ配信処理フローの例を示す。 この発明の一実施例によるサーバ装置でのバッファリング説明図である。 この発明の一実施例によるクライアント装置の動作説明図である。

〔システム構成例〕
図１は、この発明の一実施例によるシステム構成例を示し、図１（１）は、ソース装置のハードウエア構成例であり、図１（２）はデータ配信システムの全体構成例である。全体のデータ配信システムは、図１（２）に示すように、ソース装置ＲＣ：ＲＣａ；ＲＣｂ；…、サーバ装置ＳＶ及びクライアント装置ＣＬ：ＣＬａ１，ＣＬａ２，…；ＣＬｂ１，ＣＬｂ２，…；…から構成され、参照記号“ＲＣ”，“ＣＬ”は、夫々ソース装置及びクライアント装置を代表的に示す。ソース装置ＲＣは、携帯電話機や無線通信手段を備えた音声入力機能付きモバイルコンピュータのように携帯型通信端末装置が用いられ、図１（１）の例では、中央処理装置（ＣＰＵ）１、ランダムアクセスメモリ（ＲＡＭ）２、読出専用メモリ（ＲＯＭ）３、外部記憶装置４、設定操作入力装置５、表示装置６、Ａ／Ｄ変換回路７、Ｄ／Ａ変換回路８、通信インターフェース（通信Ｉ／Ｆ）９等の要素を備え、これら要素１〜９はバス１０を介して互いに接続される。

装置全体を制御するＣＰＵ１は、ＲＡＭ２及びＲＯＭ３と共に、各種制御プログラムに従って各種処理を実行するデータ処理部を構成し、各種制御プログラムに従い、タイマ１１によるクロックを利用してソース装置データ送信処理を含む種々の処理を実行する。ＲＡＭ２は、これらの処理に際して必要な各種データを一時的に記憶し、このための通常のワークエリアに加えて、サーバ装置ＳＶに送信する音声データを順次保持し順次出力するバッファメモリ２Ｂを備えている。ＲＯＭ３は、ソースデータ送信プログラムを含む各種制御プログラムや必要な制御データを記憶しておくことができる。

外部記憶装置４は、ハードディスク（ＨＤ）や、コンパクトディスク・リード・オンリィ・メモリ（ＣＤ−ＲＯＭ）、フレキシブルディスク（ＦＤ）、光磁気（ＭＯ）ディスク、ディジタル多目的ディスク（ＤＶＤ）、メモリカード等の記憶媒体を用いた記憶手段であり、必要な任意のデータを記録することができる。

設定操作入力装置（入力操作部）５は、各種設定操作を行うためのパネル操作部を有し、パネル操作部でのユーザによるパネル操作の内容を設定操作情報としてデータ処理部に導入する。表示装置（表示部）６は、これに接続されるディスプレイ（ＬＣＤ等の表示器）の表示内容をデータ処理部からの指令に従って制御し、設定操作入力装置５の操作に対する表示援助を行い、また、映像データに基づく映像を表示することもできる。

Ａ／Ｄ変換回路７は、ソース装置ユーザにより入力される音声を入力音声信号に変換するマイク装置１２に接続され、マイク装置１２からの入力音声信号をＡ／Ｄ変換して入力音声データをデータ処理部（バッファメモリ２Ｂ）に導入する。Ｄ／Ａ変換回路８は、データ処理部（２Ｂ）で処理されソース装置外部に送信される送信音声データ、ソース装置外部から送られてくる外部音声データ或いはデータ処理部で生成された案内音声データをＤ／Ａ変換して出力音声信号をスピーカ装置１３に送り、スピーカ装置１３から出力音声を放音させる。なお、Ｄ／Ａ変換回路８及びスピーカ装置１３は、このソース装置ＲＣに必須の構成要素ではなく省略することができる。

通信Ｉ／Ｆ９は、インターネット、電話回線などの通信ネットワークＣＮに無線で接続される各種インターフェースであり、通信ネットワークＣＮに接続されるサーバ装置ＳＶや他の通信端末と各種情報を授受することができる。データ配信システムが形成される場合には、通信ネットワークＣＮに、図１（２）のようにサーバ装置ＳＶが接続され、ソース装置ＲＣからサーバ装置ＳＶに音声データが送信される。

サーバ装置ＳＶのハードウエアは、図１（１）のソース装置ＲＣと同様に構成されるが、Ａ／Ｄ変換回路７、Ｄ／Ａ変換回路８、マイク装置１２及びスピーカ装置１３は不要であり、典型的なサーバ装置ＳＶでは、通信Ｉ／Ｆは通信ネットワークＣＮと有線で接続する。また、ＲＡＭに設けられるバッファメモリ（ＳＢ）には、ソース装置ＲＣから送信される音声データが通信ネットワークＣＮ及び通信Ｉ／Ｆを介して導入され、バッファメモリ（２Ｂ）から出力される音声データは、通信ネットワークＣＮ及び通信Ｉ／Ｆを介してクライアント装置ＣＬに送信される。

クライアント装置ＣＬのハードウエアも、図１（１）のソース装置ＲＣと同様に構成されるが、Ａ／Ｄ変換回路７及びマイク装置１２は不要であり、バッファメモリを設ける必要はなく、通信Ｉ／Ｆと通信ネットワークＣＮとの接続は無線でも有線でもよい。データ配信システムが形成される場合には、通信ネットワークＣＮには、図１（２）のように、ソース装置ＲＣだけでなく、クライアント装置ＣＬが接続され、ソース装置ＲＣからの音声データがサーバ装置ＳＶからクライアント装置ＣＬに送信される。この場合、クライアント装置ＣＬでは、通信Ｉ／Ｆから入力される音声データがＤ／Ａ変換回路でＤ／Ａ変換し、対応する音声をスピーカ装置から放音される。

〔データ配信システムの基本動作〕
１つのデータを配信する１つのデータ配信システムは、１つのソース装置ＲＣ、１つのサーバ装置ＳＶ及び１乃至複数のクライアント装置ＣＬで成り立ち、図１（２）の例は、ソース装置Ａ（ＲＣａ）・共通のサーバ装置（ＳＶ）・２台のクライアント装置Ａ１，Ａ２（ＣＬａ１，ＣＬａ２）により第１のデータ配信システムが形成され、ソース装置Ｂ（ＲＣｂ）・共通のサーバ装置（ＳＶ）・２台のクライアント装置Ｂ１，Ｂ２（ＣＬｂ１，ＣＬｂ２）により第２のデータ配信システムが形成されることを示している。

第１のデータ配信システムを例にして、この発明の一実施例によるデータ配信システムの基本的な構成を説明すると、このデータ配信システムは、ソース装置ＲＣａ、サーバ装置ＳＶ及び１以上のクライアント装置ＣＬａ１，ＣＬａ２から成り、音声データなどのリアルタイムデータをソース装置からサーバ装置を介してクライアント装置に配信する。ソース装置ＲＣａは、音声入力手段１２−７などから入力されるリアルタイムデータをバッファメモリ２Ｂに実時間レートで順次入力してバッファリングし、サーバ装置ＳＶと通信可能な通常状態では、バッファメモリ２Ｂによりバッファリングしたデータを先頭から実時間レートで読み出しサーバ装置ＳＶに転送する。ここで、サーバ装置ＳＶと通信不能状態になると、バッファメモリ２Ｂからの読出しを停止し、バッファメモリ２Ｂにはリアルタイムデータが蓄積され、サーバ装置ＳＶと通信可能な元の通常状態に回復すると、通信不能状態の間にバッファメモリ２Ｂに蓄積されバッファリングされたデータを、読出し停止直後の部分（通信不能になる直前に最後にサーバ装置ＳＶに送られたデータ部分の直後のデータ部分）から、実時間レートより速いレートで読み出してサーバ装置ＳＶに転送する。サーバ装置ＳＶは、ソース装置ＲＣａから通常状態時に実時間レートで転送されてくるデータ及び通信回復時に実時間レートより速いレートで転送されてくるデータを順次サーバ装置ＳＶのバッファメモリに入力してバッファリングし、バッファリングされたデータを実時間レートでクライアント装置ＣＬａ１，ＣＬａ２に配信する。

なお、サーバ装置ＳＶは、ソース装置ＲＣａとの通信が不可である間、予め用意された別のデータをクライアント装置ＣＬａ１，ＣＬａ２に配信することができる。また、通信不可の間にソース装置ＲＣａでバッファリングされ、ソース装置ＲＣａ・サーバ装置ＳＶ間の通信が再開した際に高速レートで転送されてくるデータの時間軸を実時間より短縮する変換（速度変換という）を行い、時間軸短縮の速度変換がなされたデータをバッファリングする。つまり、サーバ装置ＳＶからクライアント装置ＣＬに実時間レートでデータが配信されるにも拘わらず、ソース装置ＲＣａ・サーバ装置ＳＶ間の通信再開時に、クライアント装置ＣＬは、速度変換されたデータに基づいて音声などを高速に再生し、通信不可が復旧したときの遅れを回復して行きやがて最小の遅れになると元のデータ受信状態に復帰するようになる。

〔各装置の動作〕
以下、図１（１）のように、入力されるリアルタイムデータに音声データを用いた場合の各装置の動作を説明する。図２、図３及び図４、図５は、この発明の一実施例によるデータ配信システムにおけるソース装置、サーバ装置、クライアント装置の動作を説明するための図であり、図２、図３及び図５（１）は、それぞれ、ソース装置データ転送処理、サーバ装置データ配信処理及びクライアント装置データ受信処理の例を表わすフローチャートを示す。ソース装置ＲＣでは、所定の操作によりソース装置データ転送処理が開始し、サーバ装置ＳＶにアクセスし番組の公開（データ配信サービス実行）を指示する操作があると、ＣＰＵ１は、図２のステップＲ１で、ソース装置ＲＣをサーバ装置ＳＶに接続し番組の公開を指示する。これにより、ソース装置ＲＣからの音声データを配信するデータ配信システムの動作が開始する。

これに対して、サーバ装置ＳＶでは、図３のステップＳ１で、ＣＰＵがソース装置ＲＣからの接続を受け付け、番組公開の指示に従って、これからソース装置ＲＣから転送される音声データの配信サービスを配信可能な番組に追加し、予めサーバ装置ＳＶに登録されているソース装置ＲＣの番組情報に従って番組表示データを作成すると共に、ソース装置ＲＣ用音声バッファ（図４：ＳＢ）をクリアし、ソース装置ＲＣからの音声データの受信、バッファリング及びクライアント装置ＣＬへの配信の準備をする。

ソース装置ＲＣでは、ステップＲ１でサーバ装置ＳＶに接続して番組公開を指示した後、ステップＲ２で、バッファメモリ２Ｂをクリアして音声入力手段１２−７から入力される音声データのバッファリングの準備をする。そして、音声データが入力されると、ステップＲ３に進み、入力される音声データを逐次取得し、バッファメモリ２Ｂに積んでいく。つまり、番組公開を指示するとマイク１２から入力された音声がＡ／Ｄ変換回路７でＡ／Ｄ変換され、ＲＡＭ（主記憶装置）２のバッファメモリ２Ｂに蓄えられる。バッファメモリ２Ｂは、音声バッファとも呼ばれ、入力音声データを、順次、録音ポインタ（書込みポインタともいう）が指示する位置に実時間レートで書き込んで行く。録音ポインタは、サーバ装置ＳＶとの通信の可否によらず、時間経過に従ってインクリメントされ、音声データの書込み位置が順次進められていく。

次のステップＲ４では、ソース状態フラグは「正常」であるか否かを判定する。ここで、ソース状態フラグは、サーバ装置ＳＶとの通信状態を検出するために設けられた通信状態検出手段の検出出力に応じてソース装置ＲＣとサーバ装置ＳＶとの間の通信が可であるか不可であるかを示すフラグであり、サーバ装置ＳＶと通信可の状態であれば、ソース状態フラグ＝「正常」であり、音声バッファ２Ｂの読出しポインタは、時間経過（録音ポインタのインクリメント）に従ってインクリメントされ音声データ読出し位置が順次進められる。なお、ソース状態フラグ＝「正常」の場合、読出しポインタが指示する読出し位置から、録音ポインタが指示する書込み位置の直前までは、例えば、ストリーム転送１回分の音声データが書き込まれる。一方、サーバ装置ＳＶと通信不可の状態になると、ソース状態フラグ＝「中断」となり、読出しポインタのインクリメントを停止し音声データ読出しを中断する。これによって、ソース装置ＲＣ・サーバ装置ＳＶ間の通信が中断している間、音声データが音声バッファ２Ｂ内に録音されていく。

さて、ステップＲ４でソース状態フラグが「正常」であると判定したときは（Ｒ４＝ＹＥＳ）、ステップＲ５に進み、読出しポインタの指示に従ってバッファ２Ｂ内の音声データＤｒｓを実時間レートで読み出し、通信Ｉ／Ｆ９から無線で通信ネットワークＣＮを介してサーバ装置ＳＶにストリーム転送（ストリーミング転送ともいう）する。次のステップＲ６では、サーバ装置ＳＶとの通信状態をチェックし、不良であればソース状態フラグを「中断」に変更し、良であれば「正常」を維持する。そして、ステップＲ７で音声バッファ２Ｂの読出しポインタを更新した上、ステップＲ３に戻る。

一方、ソース状態フラグが「正常」ではなく「中断」であると判定したときは（Ｒ４＝ＮＯ）、ステップＲ８に進み、サーバ装置ＳＶとの通信状態が良好であるか否かを判定し、やはり不良であれば（Ｒ８＝ＮＯ）ステップＲ３に戻る。ステップＲ８で、サーバ装置ＳＶとの通信状態が良好であると判定したとき即ちサーバ装置ＳＶとの通信状態が回復したときには（Ｒ８＝ＹＥＳ）、ステップＲ９に進み、中断開始時点から音声バッファ２Ｂ内に蓄えられた音声データＤＲｂを、バルク転送により実時間レートより速く一気にサーバ装置ＳＶに送り、次のステップＲ１０でソース状態フラグを「正常」にする。そして、ステップＲ７で音声バッファ２Ｂの読出しポインタを更新した上、ステップＲ３に戻る。

ステップＲ３に戻った後は、音声入力の進行及び通信状態に応じて、上述したステップＲ３〜Ｒ１０の処理を繰り返し、番組公開の終了を指示する操作がありサーバ装置ＳＶでこの指示が確認されると（図示せず）、このソース装置データ転送処理を終了する。

クライアント装置ＣＬでは、所定の操作によりクライアント装置データ受信処理が開始し、サーバ装置ＳＶにアクセスし配信可能な番組のリストを要求する操作があると、ＣＰＵは、図５（１）のステップＣ１で、クライアント装置ＣＬをサーバ装置ＳＶに接続し配信可能番組リストを要求する。これにより、クライアント装置ＣＬはこのデータ配信システムに参加することができる。

サーバ装置ＳＶでは、前述したように、図３のステップＳ１で、ＣＰＵがソース装置ＲＣからの接続を受けてソース装置ＲＣからの音声データ配信を準備をした後、クライアント装置ＣＬからのリスト要求を受信すると、次のステップＳ２で、クライアント装置ＣＬからの要求に応じて番組リストをクライアント装置ＣＬに返送する。この番組リストは、各ソース装置ＲＣからの番組公開の指示に従って作成された番組表示データに基づいて、現在サーバ装置ＳＶから任意のクライアント装置ＣＬに配信可能な番組（音声データ配信サービス）をリストで表わしたものであり、サーバ装置ＳＶと各ソース装置ＲＣとの間の現在の通信状態を示すサーバ状態情報（Ｃｎ）などの所要の参考情報が含まれている。

クライアント装置ＣＬでは、これ応じて、図５（１）のステップＣ１でサーバ装置ＳＶから配信可能番組リストを取得すると、取得した配信可能番組リストを表示装置のディスプレイに番組選択画面として提示し、クライアント装置ユーザに所望の番組を選択させる。図５（２）は、番組選択画面の例を示し、この例では、現在公開中の番組の名称やパーソナリティ（ソース装置ユーザのニックネーム）などの基本情報の外に、各ソース装置ＲＣにより番組公開が指示された時から現在までの時間を例えば“時：分”で表わす「経過時間」、上述したサーバ状態情報Ｃｎ、各ソース装置ＲＣから転送されてくる音声データの「音質」、「リスナーの人数」（現在当該番組の配信を受けているクライアント装置ＣＬの数）などのリアルタイムの参考情報が、表示項目に含まれている。なお、サーバ装置ＳＶには、サーバ装置ＳＶとソース装置ＲＣとの通信状態を検出し監視する通信状態監視手段が設けられ、サーバ状態情報は、通信状態監視手段により検出された通信状態に応じて、サーバ装置ＳＶ・各ソース装置ＲＣ間の通信状態を“Ｇｏｏｄ”（良好、正常）、“disConnected”(中断)などの「状態」で表わされる。そこで、表示された番組選択画面に対して、クライアント装置ユーザにより番組選択操作があると、次のステップＣ３で、番組選択操作に応じて、選択された番組の配信をサーバ装置ＳＶに要求する。

これに対して、サーバ装置ＳＶでは、図３のステップＳ３で、クライアント装置ＣＬからの番組配信要求に応じて、配信が要求された番組の配信先（リスナー）に当該クライアント装置ＣＬを追加し、各番組配信処理段階ＳＰに進み、要求された番組について配信処理を行う。各番組配信処理段階ＳＰは、図３に示すように、ソース装置ＲＣからの音声データをバッファメモリ（ＳＢ）に積む前半のバッファリング処理部分ＳＰ１＝ステップＳ４〜Ｓ８と、バッファメモリ（ＳＢ）から音声データをクライアント装置ＣＬにストリーム配信する後半のストリーム配信処理部分ＳＰ２＝ステップＳ９〜Ｓ１２とから成る。

番組配信処理段階ＳＰでは、まず、音声データの受信状態を調べ、最初のステップＳ４進んでバッファリング処理ＳＰ１を開始する。ステップＳ４では、バルク転送により音声データが届いたか否かを判定し、音声データのバルク転送がないときは（Ｓ４＝ＮＯ）、ステップＳ５に進み、ストリーム転送により音声データＤｒｓが届いたか否かを判定する。ここで、音声データＤｒｓがストリーム転送されてきたときは（Ｓ５＝ＹＥＳ）、さらに、ステップＳ６に進んで、バッファメモリ（ＳＢ）に蓄積されている音声データ（Ｄｂ）を調べ、既に受信した音声データがバッファメモリ（ＳＢ）に溜まっているか否かを判定し、溜まっていないときは（Ｓ６＝ＮＯ）、ステップＳ７で、ストリーム転送で届いた音声データをそのままバッファメモリ（ＳＢ）に積む。

一方、ステップＳ４においてバルク転送で音声データＤｒｂが届いたと判定したとき（Ｓ４＝ＹＥＳ）、或いは、ステップＳ６において、ストリーム転送で音声データＤｒｓが届いた際にバッファメモリ（ＳＢ）に既受信データが溜まっていると判定したときには（Ｓ６＝ＹＥＳ）、ステップＳ８で、バルク転送或いはストリーム転送で届いた音声データＤｒｂ，Ｄｒｓを速度変換した上でバッファメモリ（ＳＢ）に積む。

図４は、この発明の一実施例によるサーバ装置におけるバッファリングを説明するための図であり、ここで、サーバ装置のバッファリング機能を図４に従って説明しておく。サーバ装置ＳＶは、ソース装置ＲＣからの音声データＤｒｓ，Ｄｒｂをバッファリングし、バッファリングされた音声データＤｓをクライアント装置ＣＬにストリーム配信するために、速度制御部（時間制御部ともいう）ＳＡ、バッファメモリＳＢ、バルク転送検出部ＳＣ及び溜まり検出部ＳＤの機能をデータ処理部に備えている。

速度制御部ＳＡは、通常は、ソース装置ＲＣから実時間レートでストリーム転送される音声データＤｒｓをそのままバッファメモリＳＢに入力するように動作する。しかしながら、サーバ装置ＳＶ・ソース装置ＲＣ間の通信が中断した後に回復した際は、音声データのバルク転送をバルク転送検出部ＳＣにより検出することにより速度変換機能が起動し、ソース装置ＲＣから回復当初に高速レートでバルク転送されてきた音声データＤｒｂ及びその後実時間レートでストリーム転送される音声データＤｒｓの時間軸を実時間より短縮する速度変換、つまり、いわゆる話速変換或いは早回しを行う。そして、速度制御部ＳＡの速度変換機能により時間軸が短縮されて速度変換された音声データＤａはバッファメモリＳＢに入力される。溜まり検出部ＳＤは、バッファメモリＳＢに蓄積されている音声データＤｂを調べ、所定の最小時間分（クライアント装置ＣＬへのストリーム配信１回分）を超える音声データＤｂが蓄積されていると「溜まっている」と判定する。速度制御部ＳＡの速度変換機能は、バッファメモリＳＢに音声データＤｂが溜まっている間、実行され、音声データＤｂが所定の最小時間分になり、溜まり検出部ＳＤで音声データＤｂの「溜まりがなくなった」と判定されると停止する。つまり、通信が回復してから通常の動作に戻るまでの間（この間の動作状態を追いかけ状態という）、ソース装置ＲＣからの音声データＤｒｂ、Ｄｒｓを速度変換したデータＤａをバッファメモリＳＢに入力する。

バッファメモリＳＢは、サーバ装置ＳＶのＲＡＭ（主記憶装置）内に設けられ、データバッファとも呼ばれ、速度制御部ＳＡから入力される音声データＤｒｓ，Ｄａを書込みポインタＰｗが指示する位置に書き込む。書き込みを行うと、書込みポインタＰｗは、書き込まれた時間分だけインクリメントされる。従って、ソース装置ＲＣとの通信が途絶えている（中断している）間は音声データＤｒｓ，Ｄｒｂが送られてこないため書込みポインタは更新されない。一方、クライアント装置ＣＬに対して、ソース装置ＲＣとの通信が正常な間は、時間経過に応じて再生ポインタ（読出しポインタともいう）Ｐｒがインクリメントされ、再生ポインタＰｒが指示する位置から音声データＤｓを取り出してストリーム配信し、ソース装置ＲＣとの通信が中断している間は、再生ポインタＰｒのインクリメントはなく、データバッファＳＢからの音声データＤｓの読出しもない。

さて、ステップＳ５で、音声データがストリーム転送されてこないと判定したとき（Ｓ５＝ＮＯ）、ステップＳ７で、ストリーム転送により届けられた音声データＤｒｓをそのままデータバッファＳＢに積む処理を終えたとき、或いは、ステップＳ８で、バルク転送乃至ストリーム転送により届けられた音声データＤｒｂ，Ｄｒｓを速度制御部ＳＡの速度変換機能に従って速度変換し，速度変換された音声データＤａをデータバッファＳＢに積む処理を終えたときは、一旦、バッファリング処理ＳＰ１を終え、ステップＳ９に進む。

ステップＳ９では、ストリーム配信周期のタイミングに達したか否かを判定し、ストリーム配信タイミングに達していないときは（Ｓ９＝ＮＯ）、バッファリング処理ＳＰ１の第１ステップＳ４に戻り、上述したステップＳ４〜Ｓ８のバッファリング処理ＳＰ１を繰り返す。一方、ストリーム配信タイミングに達すると（Ｓ９＝ＹＥＳ）、ステップＳ１０に進み、ストリーム配信処理ＳＰ２を開始する。

ステップＳ１０では、通信状態監視手段によりソース装置ＲＣとの通信状態が良好であるか否かを判定し、良好であれば（Ｓ１０＝ＹＥＳ）、ステップＳ１１に進んで、データバッファＳＢ内の再生ポインタＰｒが指示する位置にある音声データＤｓを読み出してクライアント装置ＣＬにストリーム配信し、その後、ステップＳ４に戻る。また、ソース装置ＲＣとの通信が中断しているときは（Ｓ１０＝ＮＯ）、ステップＳ１２に進み、予めサーバ装置ＳＶに用意されたコンテンツに基づく別番組の音声データＤｅをクライアント装置ＣＬにストリーム配信し、その後、ステップＳ４に戻る。ここで、別番組の音声データＤｅとしては、例えば、通信中断時用に予めメッセージコンテンツや音楽コンテンツを録音しておき、ソース装置ＲＣとの通信が中断すると、「ただいま通信回線が悪く中継できません。しばらくお待ち下さい」などのメッセージを繰り返し流すようにしたり、「ただいま通信回線が悪く中継できません。しばらく音楽をお聴き下さい」などメッセージを繰り返し挟みつつ音楽を流すようにする。

ステップＳ４に戻った後は、ソース装置ＲＣからのデータ転送状態、データバッファＳＢのデータ溜まり具合及びソース装置ＲＣとの通信状態に応じて、上述したステップＳ４〜Ｓ１２の処理を繰り返し、ソース装置ＲＣから番組公開の終了指示があるとクライアント装置ＣＬに当該番組の終了を通知した上（図示せず）、当該番組に関する番組配信処理ＳＰを終了する。

これに対して、クライアント装置ＣＬでは、図５のステップＣ４で、ソース装置ＲＣを発信源としサーバ装置ＳＶを介してストリーム配信されてくる音声データＤｓ或いはサーバ装置ＳＶに用意されたコンテンツに基づいてサーバ装置ＳＶ自身からストリーム配信されてくる別番組の音声データＤｅを受信する。次のステップＣ５では、受信した音声データＤｓ，ＤｅをＤ／Ａ変換回路及びスピーカで再生する。これにより、サーバ装置ＳＶから番組終了の通知があるまでステップＣ４，Ｃ５の処理を繰り返し、クライアント装置ＣＬのユーザは、自身が選択した番組を楽しむ。そして、サーバ装置ＳＶから番組終了の通知を受けると、このクライアント装置データ受信処理を終了する。

〔種々の実施態様〕
以上、この発明の好適な一実施例について説明したが、これは単なる一例であって、この発明は、発明の精神を逸脱しない範囲で種々の変更が可能であり、種々の態様で実施することができる。例えば、サーバ装置へのストリーム転送或いはクライアント装置へのストリーム配信については、一般的な手法を用いてなされる。送り手が受け手に対して、短い一定周期（例えば、１０ｍｓｅｃ）毎や、所定サンプル数（４８００サンプル）毎に、音声データを送る。その際、送り手側がＴＣＰなどのプロトコルで送り、それが受け手で受信されたか毎回確認するようにしてよい。或いは、ＲＴＰプロトコルのように、送り手側がＵＤＰなどの相手の受信が確認できないプロトコルで送るとともに平行してＴＣＰなどで受け手での確認するようにしてよい。

或いは、受け手がＴＣＰなどの手法で小まめに送り手側に要求を出すようにしてもよい。受け手は要求がこなくなったことで通信の障害を知ることができる。

通信状態の検出については、電波の状態から推測してもよい。或いは、送信側では、一旦通信を試みてそれが失敗したことで知るようにしてもよい。或いは、受信側では、所定タイミングで届くはずのデータが届かないことで知るようにしてもよい。

サーバ装置からデータバッファ（ＳＢ）内のデータをクライアント装置にストリーム配信する条件については、実施例ではソース装置と通信良好（Ｓ１０＝ＹＥＳ）としているが、データバッファ（ＳＢ）内に蓄積されたデータ（Ｄｂ）が無いか所定時間分以下のとき（ポインタＰｒ，Ｐｗが一致又は隣接）としてもよい。

実施例では、速度変換（時間軸短縮）を行って、通信障害から回復したときの遅れを徐々に回復し、やがて、ソース装置とクライアント装置の遅れを最小になるようにしたものを示したが、速度変換（時間軸短縮）を行わなくてもよい。速度変換をしない場合には、障害から回復したときの遅れはそのまま残るが、サーバ装置に設けられたデータバッファ（ＳＢ）の大きさ分だけの遅れは許容される。

実施例では、サーバ装置で速度変換しているが、ソース装置で、バルク転送する際に速度変換を行うようにしてもよい。

音声データの速度変換方法は一般的なものが用いられる。つまり、音声データを時間方向で継ぎ接ぎするものであり、例えば、話速変換のように、音量変化の形状に則した窓をかけて音量クロスフェードしたり、無音部分を考慮して時間軸を短縮する。

配信されるデータは、音声に限らず、映像、演奏データ（ＭＩＤＩ）でもよい。映像の場合、実時間より速度を速めるのにコマ落としをする。また、演奏データ（ＭＩＤＩ）の場合は、イベントをデルタタイムと共に記録してバッファリングすると共に、実時間より速度を速める際には、デルタタイムのもとになるテンポを記録時のものから早める。

ＲＣ：ＲＣａ，ＲＣｂ，… ソース装置、
ＳＶ サーバ装置、
ＣＬ：ＣＬａ１，ＣＬａ２，…；ＣＬｂ１，ＣＬｂ２，… クライアント装置、
Ｄｒｓ，Ｄｒｂ ストリーム転送及びバルク転送される音声データ、
Ｄａ，Ｄｂ 速度変換された音声データ及びバッファリングされている音声データ、
Ｄｓ，Ｄｅ ストリーム配信されるバッファからの音声データ及び別番組の音声データ。

Claims (3)

1. ソース装置、サーバ装置及び１以上のクライアント装置から成るデータ配信システムであって、
   ソース装置は、
   リアルタイムデータをバッファリングするソースバッファリング手段と、
   サーバ装置との間の通信状態を検知するソース通信状態検知手段と、
   ソース通信状態検知手段によりサーバ装置との通信が可であると検知されている間、ソースバッファリング手段によりバッファリングされたデータを実時間レートで順次サーバ装置に転送する第１転送手段と、
   ソース通信状態検知手段によりサーバ装置との通信が不可となった後に再び可となったことが検知されたときに、第１転送手段によるデータ転送に先立って、通信不可の間にソースバッファリング手段によりバッファリングされたデータを実時間レートより速いレートでサーバ装置に転送する第２転送手段と
   を具備し、
   サーバ装置は、
   第１転送手段及び第２転送手段により転送されるデータをバッファリングするサーババッファリング手段と、
   サーババッファリング手段によりバッファリングされたデータを実時間レートでクライアント装置に配信するバッファリングデータ配信手段と
   を具備する
   ことを特徴とするデータ配信システム。
2. サーバ装置は、さらに、
   ソース装置との間の通信状態を検知するサーバ通信状態検知手段と、
   サーバ通信状態検知手段によりソース装置との通信が不可であることが検知されている間、予め用意された別のコンテンツデータをクライアント装置に配信する別データ配信手段と
   を具備することを特徴とする請求項１に記載のデータ配信システム。
3. サーバ装置は、さらに、第２転送手段により転送されるデータ及びこのデータ転送に続く所定時間の間第１転送手段により転送されるデータの時間軸を実時間より短縮する速度変換手段を具備し、
   サーババッファリング手段は、速度変換手段により時間軸が短縮されたデータをバッファリングする
   ことを特徴とする請求項１又は２に記載のデータ配信システム。

Images