JP2011210240A - サーバ装置、クライアント装置、配信方法、プログラム - Google Patents

Abstract

【課題】家庭内ネットワークにおいて配信コンテンツの変更要求に対しサーバが適切に対応できるようにする。
【解決手段】配信中に、或るクライアント装置から配信コンテンツ変更要求があったら、第１の期間内にさらなる変更要求の受信状況を確認する。そして第１の期間内における変更要求の受信状況に応じて第１の期間の経過後の処理を決定する。例えば変更要求に対応したり、変更要求を無効とする処理などを行う。また、配信中に、或るクライアント装置から配信コンテンツ変更要求があったら、そのクライアント装置にのみ、変更要求に係るコンテンツ変更を行い、他のクライアント装置に対しては、引き続き共通の配信を行う。
【選択図】図５

Description

本開示は、例えば家庭内ネットワークを構成するサーバ装置とクライアント装置、及びサーバ装置の配信方法、プログラムに関する。特に配信コンテンツの変更要求への対応処理に関する。

特開２０００−２２４６７３号公報 特開２００４−２２８６４７号公報

いわゆる家庭内ネットワークシステムとして、コンテンツサーバ装置とクライアント装置から成るシステムが提案されている。
この家庭内ネットワークシステムでは、例えば家の各部屋に映像や音声の出力装置であるクライアント装置を配置する。例えばテレビジョンモニタやスピーカ等を有する機器である。
そして、所定の部屋に設置されたコンテンツサーバ装置と、複数のクライアント装置を所定の通信網（有線又は無線）を介して通信可能に接続する。
これにより、コンテンツサーバ装置から配信する映像や音声のコンテンツを、家庭内の各部屋で視聴・聴取可能とする。

このような家庭内ネットワークシステムにおいては、その配信動作として、オンデマンドモードと、パーティモードとの２種類の形式が考えられる。
オンデマンドモードとは、コンテンツサーバ装置に対して、各部屋のクライアント装置に別々のコンテンツを配信するモードである。
パーティモードとは、コンテンツサーバ装置から同じコンテンツを各部屋のクライアント装置に共通に配信して同期（同時）再生させるモードである。

オンデマンドモードの場合には、各部屋に設置されたクライアント装置に対し、ユーザがコンテンツを選択する操作を行う。この操作情報は、ネットワーク通信によりコンテンツサーバ装置に送信される。コンテンツサーバ装置は、操作情報に応じて、その操作情報の送信元のクライアント装置に対し、指定されたコンテンツの配信を行う。つまりコンテンツサーバ装置は、各クライアント装置に対してそれぞれ異なるコンテンツを配信する。
従って、このオンデマンドモードの場合、各部屋にいる各ユーザは、それぞれクライアント装置に対して操作入力を行うことで、自分の聴きたい音楽コンテンツや、見たい映像コンテンツの配信を受け、各部屋で異なるコンテンツを楽しむことができる。
コンテンツサーバ装置側としては、例えばコンテンツデータの格納部として、例えばマルチヘッドのＨＤＤ（Hard Disk Drive）を用いている場合などは、複数のコンテンツデータを同時に再生し、それぞれを所定の機器に配信することができる。

一方、パーティモードの場合には、例えばパーティの招待客などが居間や台所や応接部屋などの各部屋に散らばっている場合などに、各部屋に共通のコンテンツを配信して、同時に同じコンテンツを楽しむことができる。この場合、ある部屋からある部屋に移動しても同じコンテンツを継続して楽しむことができ、例えば再生されているコンテンツに関する話題で会話がはずむようなことを目的としている。

ところで、パーティモードの場合にも、クライアント装置からの操作による要求を受け付けるようにすることが考えられる。
例えば音楽コンテンツをパーティモードで配信する場合を例に挙げる。ユーザにとっては、単に配信されている音楽をＢＧＭ（バックグラウンドミュージック）として聴くだけでなく、会話の流れ、或いは聴いている音楽からの連想等で、積極的に他の曲を聴きたいと思うこともある。そのような場合、その人の居る部屋のクライアント装置に対して操作入力を行い、他の曲をリクエスト（配信コンテンツの変更要求）することができると好適である。

ところが、各クライアント装置で、同時期にコンテンツ変更要求が行われ、その都度、全体に配信されている音楽が度々切り換えられると、他の部屋の人は、気が散ったり、不快に感じたりすることがある。さらには、曲を元に戻す操作を行う者、或いはさらに他の曲を要求する者などが現れることもあり、いわゆるチャンネル争いのように、続けて変更要求が行われてしまうことも懸念される。
つまり、操作者以外の人（他の部屋に居る人）にとっては、例えばＢＧＭ的に流れている音楽が、曲の途中でどんどん切り替わってしまい、その結果気が散ってしまいパーティを楽しめなかったり会話に集中できなかったりする。また、流れている音楽を聞きながらその演奏者を話題に会話を楽しんでいる最中に全然関係ない別な曲に切り替わってしまうと、折角の会話も台無しになってしまい、結果的にしらけてしまうということもある。

このような状態を解決するひとつの方法として、上記特許文献１では、複数のサブユニット（クライアント装置に相当）の中から特定のサブユニットに対して優先権を与え、これにより結果的にチャンネル争いが発生しても優先権が与えられていない他のサブユニットからの要求は排他的に処理する内容が開示されている。
また上記特許文献２では、ネットワークに接続されている機器に対して複数のリモコンから同時にコマンドが送信された場合に、排他的な処理をするもの開示されている。

しかし、所定のクライアント装置に優先権を与え、他のクライアント装置からの制御を排他的にすることでチャンネル争いを回避はできるものの、配信するコンテンツの変更を他のクライアント装置からはできなくなる。この場合、別の部屋にいるユーザがコンテンツ変更を希望する場合には、一々優先権の与えられているクライアント装置が設置されている部屋に行って操作を行わなければならないという煩わしさがある。
また、優先権を与える場合に何を規準にどのクライアント装置に優先権を与えればいいかの判断が、パーティモード動作を行う家庭内ネットワークにおいては困難である。

そこで本開示では、家庭内ネットワークシステムで、上記のパーティモードの配信動作を行う場合に、各クライアント装置からコンテンツ変更要求を可能とする。その上で、変更要求の錯綜（短期間内での多数の変更要求の発生）に適切に対処できるようにしたり、或いは錯綜の悪影響が生じないようにすることを目的とする。

本開示のサーバ装置は、ネットワーク通信が可能とされた複数のクライアント装置との間で通信を行う通信部と、コンテンツデータの再生を行う再生部と、上記再生部で再生されたコンテンツデータを上記通信部から各クライアント装置に対して共通に配信させるとともに、共通のコンテンツを配信中に、上記通信部によりクライアント装置からの配信コンテンツの変更を求める変更要求を受信した場合、或るクライアント装置からの当該受信を元に計数が開始される第１の期間内に他のクライアント装置からのさらなる変更要求の受信状況を確認し、上記第１の期間内における変更要求の受信状況に応じて上記第１の期間の経過後の処理を決定する制御部とを備える。
また、上記制御部は、上記第１の期間内に所定数以上の変更要求を検知した場合、上記第１の期間の経過後に計数が開始される第２の期間は、受信される変更要求を無効とする処理を行う。
或いは、上記制御部は、上記第１の期間内に所定数以上の変更要求を検知した場合、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止信号を送信させる。
或いは、上記制御部は、上記第１の期間内に所定数以上の変更要求を検知した場合、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止信号を送信させ、さらに、上記第１の期間の経過後に計数が開始される第２の期間の経過後、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止解除信号を送信させる。

また、上記制御部は、上記第１の期間の経過時点までに受信された有効な変更要求を決定し、該有効な変更要求に関するコンテンツデータを再生するよう上記再生部を制御し、各々のクライアント装置に再生されたコンテンツデータを送信するよう上記送信部を制御する。
そして上記制御部は、上記第１の期間内に所定数以上の変更要求を検知した場合、上記第１の期間の開始前に配信していたコンテンツデータ配信を継続するように上記再生部を制御し、上記通信部から各クライアント装置に対して送信するように上記通信部を制御する。

また上記制御部は、上記第１の期間の経過までに受信された変更要求に対しては、その変更要求に応じた配信コンテンツの変更制御は行わない。
そして上記制御部は、上記第１の期間内に所定数以上の変更要求を検知した場合、上記第１の期間の経過後も、上記第１の期間内に検知した変更要求に応じた配信コンテンツの変更制御は行わない。
一方、上記制御部は、上記第１の期間内に所定数未満の変更要求を検知した場合、上記第１の期間の経過後は、上記第１の期間内に最後に検知した変更要求に応じたコンテンツデータを再生するよう上記再生部を制御し、上記通信部から各クライアント装置に対して送信するよう上記通信部を制御する。
また上記制御部は、上記第１の期間の経過時点までにおける変更要求の受信に対応して、該変更要求を告知する告知信号を、上記通信部から全部又は一部のクライアント装置に対して送信させる。
また上記制御部は、上記第１の期間内に、上記告知信号の送信後、上記通信部によりクライアント装置からの賛否情報信号が受信されることに応じて、賛否情報の集計処理を行い、該集計処理結果に基づいて、上記第１の期間の経過後の配信コンテンツを決定する。

本開示の他のサーバ装置は、ネットワーク通信が可能とされた複数のクライアント装置との間で通信を行う通信部と、コンテンツデータの再生を行う再生部と、上記再生部で再生された共通のコンテンツデータを上記通信部から各クライアント装置に対し共通に配信させるとともに、共通のコンテンツデータ配信中に、或るクライアント装置からの変更要求に応じて、共通のコンテンツデータと変更要求に応じたコンテンツデータを両方とも再生するよう上記再生部を制御し、上記或るクライアント装置からの変更要求のみに応じて上記変更要求に応じたコンテンツデータを送信するとともに、該或るクライアント装置以外の他のクライアント装置に上記共通のコンテンツデータを送信するよう上記通信部を制御する制御部とを備える。
また上記或るクライアント装置への上記変更要求に応じたコンテンツデータの送信が終了した場合に、上記制御部は、上記或るクライアント装置を含めた全てのクライアント装置への共通のコンテンツデータの配信に復帰するよう上記再生部を制御する。

本開示のクライアント装置は、ネットワーク通信が可能とされたサーバ装置との間で通信を行う通信部と、上記サーバ装置から配信され上記通信部で受信したコンテンツデータの再生処理を行う再生処理部と、ユーザ操作に応じて、配信コンテンツの変更を求める変更要求を、上記通信部から上記サーバ装置に送信させるとともに、上記サーバ装置からの送信禁止信号を受信した場合は、該受信後に計数が開始される所定期間、ユーザ操作に応じた変更要求の送信処理を実行しない制御部とを備える。
また本開示の他のクライアント装置は、ネットワーク通信が可能とされたサーバ装置との間で通信を行う通信部と、上記サーバ装置から配信され上記通信部で受信したコンテンツデータの再生処理を行う再生処理部と、ユーザ操作に応じて、配信コンテンツの変更を求める変更要求を上記通信部から上記サーバ装置に送信させる処理と、他のクライアント装置からの変更要求を告知する告知信号を上記サーバ装置から受信したときに上記告知信号の内容を提示する処理と、ユーザ操作に応じて、上記告知信号の内容に関する賛否情報を示した賛否情報信号を上記通信部から上記サーバ装置に送信させる処理と、を行う制御部とを備える。

本開示の配信方法は、サーバ装置と、複数のクライアント装置とがネットワーク通信可能とされた配信システムにおける上記サーバ装置の配信方法として、再生したコンテンツデータを各クライアント装置に対して共通に配信するステップと、上記共通のコンテンツ配信中に、クライアント装置からの配信コンテンツの変更を求める変更要求を受信したことに応じて、クライアント装置からの当該受信を元に計数を開始する所定期間内にさらなる変更要求の受信状況を確認するステップと、上記所定期間内における変更要求の受信状況に応じて上記所定期間の経過後の処理を決定するステップとを備える。
本開示のプログラムは、上記各ステップを演算処理装置に実行させる。

また本開示の他の配信方法は、サーバ装置と、複数のクライアント装置とがネットワーク通信可能とされた配信システムにおける上記サーバ装置の配信方法として、
再生したコンテンツデータを各クライアント装置に対して共通に配信するステップと、
配信コンテンツの変更を求めるために使用される変更要求が、共通配信中に、クライアント装置のうちの一つから受信された場合に、共通配信コンテンツデータの再生を継続している間、変更要求に応じてコンテンツデータを再生し、クライアント装置のうちの一つからの変更要求に応じてコンテンツデータを送信すると同時に、共通配信コンテンツデータをその他のクライアント装置に送信するステップとを備える。
本開示の他のプログラムは、上記各ステップを演算処理装置に実行させる。

これらの本開示では、サーバ装置は、クライアント装置からの配信コンテンツの変更要求が、所定期間（第１の期間）内に、所定数以上、発生したか否かを確認し、それによって変更要求の錯綜が生じる状況の有無を判断する。そして、例えば変更要求の錯綜が生じた場合は、例えば所定期間（第２の期間）に、変更要求を無効化する処理等を行い、パーティモードとして全体に流れる音楽等のむやみな変更が行われないようにする。

或いは、そもそも変更要求の錯綜の悪影響が生じないようにするため、変更要求があった場合、そのクライアント装置を、パーティモードから離脱させ、そのクライアント装置にのみ、オンデマンドモードのような配信を行う。これにより、他のクライアント装置による配信出力を視聴しているユーザに影響が生じないようにする。

本開示によれば、家庭内ネットワークシステム等におけるパーティモードの動作、つまり各クライアント装置に共通のコンテンツデータを配信する際に適切な動作が実現される。まず、各クライアント装置からの配信コンテンツ変更要求を受け付けることが可能であるため、各ユーザは、パーティモード動作中でも、見聞きしたいコンテンツの配信を要求できる。
その上で、複数の変更要求が錯綜した場合でも、他のユーザの雰囲気を害するようなむやみなコンテンツの変更は行われず、パーティモード動作として適切な配信が可能となる。
或いは、変更要求を行ったクライアント装置に対してのみ、配信コンテンツを変更することでも、他のユーザに対する悪影響を与えない、パーティモード動作として適切な配信が可能となる。

本開示の実施の形態の家庭内ネットワークのシステム構成の説明図である。 実施の形態のコンテンツサーバ装置のブロック図である。 実施の形態のクライアント装置のブロック図である。 実施の形態のサーバ・クライアント兼用装置のブロック図である。 第１の実施の形態の動作の説明図である。 第１の実施の形態の動作の説明図である。 第１の実施の形態のコンテンツサーバ装置の機能構成の説明図である。 第１の実施の形態のクライアント装置の機能構成の説明図である。 第１の実施の形態のコンテンツサーバ装置の処理のフローチャートである。 第１の実施の形態のクライアント装置の処理のフローチャートである。 第２の実施の形態の動作の説明図である。 第２の実施の形態のコンテンツサーバ装置の機能構成の説明図である。 第２の実施の形態のクライアント装置の機能構成の説明図である。 第２の実施の形態のコンテンツサーバ装置の処理のフローチャートである。 第２の実施の形態のクライアント装置の処理のフローチャートである。 第３の実施の形態の動作の説明図である。 第３の実施の形態のコンテンツサーバ装置の機能構成の説明図である。 第３の実施の形態のクライアント装置の機能構成の説明図である。 第３の実施の形態のコンテンツサーバ装置の処理のフローチャートである。 第３の実施の形態のクライアント装置の処理のフローチャートである。 第４の実施の形態の動作の説明図である。 第４の実施の形態の動作の説明図である。 第４の実施の形態のコンテンツサーバ装置の機能構成の説明図である。 第４の実施の形態のクライアント装置の機能構成の説明図である。 第４の実施の形態のコンテンツサーバ装置の処理のフローチャートである。 第４の実施の形態のクライアント装置の処理のフローチャートである。 第５の実施の形態の動作の説明図である。 第５の実施の形態のコンテンツサーバ装置の機能構成の説明図である。 第５の実施の形態のクライアント装置の機能構成の説明図である。 第５の実施の形態のコンテンツサーバ装置の処理のフローチャートである。 第５の実施の形態のクライアント装置の処理のフローチャートである。 第６の実施の形態の動作の説明図である。 第６の実施の形態のコンテンツサーバ装置の機能構成の説明図である。 第６の実施の形態のコンテンツサーバ装置の処理のフローチャートである。 実施の形態の変形例の説明図である。

以下、本開示の実施の形態を次の順序で説明する。

＜１．実施の形態の家庭内ネットワークシステムの構成＞
［１−１：システム構成］
［１−２：コンテンツサーバ装置］
［１−３：クライアント装置］
［１−４：サーバ・クライアント兼用装置］
＜２．第１の実施の形態＞
［２−１：動作概要］
［２−２：サーバ・クライアントの機能構成］
［２−３：サーバ・クライアントの処理例］
＜３．第２の実施の形態＞
［３−１：動作概要］
［３−２：サーバ・クライアントの機能構成］
［３−３：サーバ・クライアントの処理例］
＜４．第３の実施の形態＞
［４−１：動作概要］
［４−２：サーバ・クライアントの機能構成］
［４−３：サーバ・クライアントの処理例］
＜５．第４の実施の形態＞
［５−１：動作概要］
［５−２：サーバ・クライアントの機能構成］
［５−３：サーバ・クライアントの処理例］
＜６．第５の実施の形態＞
［６−１：動作概要］
［６−２：サーバ・クライアントの機能構成］
［６−３：サーバ・クライアントの処理例］
＜７．第６の実施の形態＞
［７−１：動作概要］
［７−２：サーバ・クライアントの機能構成］
［７−３：サーバ・クライアントの処理例］
＜８．プログラム＞

＜１．実施の形態の家庭内ネットワークシステムの構成＞
［１−１：システム構成］

まず、実施の形態の家庭内ネットワークシステムの構成を図１で説明する。
図１では、或る家屋において、ルームＲ０からルームＲ３の４部屋で、家庭内ネットワークシステムを使用する例を示している。
ここで「家庭内ネットワークシステム」と呼んでいるが、もちろん本例のシステムが使用される場所は「家庭」に限られない。例えば会社、学校、公共施設などでも使用可能である。また、必ずしも同一の建物内の「部屋」でなくとも、敷地内の庭、ガレージ、倉庫など、屋外や別の建物内も、ここでいう「ルーム」と考えて良い。つまり本例の場合、パーティモードとして同一の音楽コンテンツや映像コンテンツを、各「ルーム」で視聴できるように配信するものであるが、同一のコンテンツを配信する先の「ルーム」は多様に考えられる。但し、インターネット等の公衆ネットワークで実行されるような広い範囲での配信ではなく、或る程度狭い範囲での配信を行うシステムと考えることが適切である。

実施の形態の家庭内ネットワークシステムは、１以上のコンテンツサーバ装置１と、少なくとも２以上の複数のクライアント装置２がネットワーク４を介して相互に通信可能に構成される。
図１の例では、コンテンツサーバ装置１はルームＲ０に設置されているとしている。またクライアント装置２が、ルームＲ０〜Ｒ３のそれぞれに配置されている。

コンテンツサーバ装置１は、オーデイオ／ビデオ／テキスト／ゲームなどのコンテンツデータを、ネットワーク４を介して各クライアント装置２に配信できる。例えばコンテンツサーバ装置１は、コンテンツデータを、ハードデイスクドライブ（ＨＤＤ）、フラッシュメモリ、複数毎の光デイスク、例えばＣＤ（Compact Disc），ＤＶＤ（Digital Versatile Disc）、ＢＤ（Blu-ray Disc（登録商標））等を収納した交換型光デイスクプレーヤなどから再生する。そして再生したコンテンツデータを、各クライアント装置２に配信する。

各クライアント装置２は、一体又は別体の出力デバイスとして、モニタディスプレイやスピーカ等を備える。そして、ネットワーク４を介して配信されてくるコンテンツデータを受信し、出力デバイスから映像や音声として出力する。
これにより、各ルームＲ０〜Ｒ３に居るユーザは、配信されてくるコンテンツデータを見聞きすることができる。

また、例えば各クライアント装置２に対しては、そのクライアント装置２の筐体上の操作ボタン、モニタ上で操作するタッチパネル部、或いは図示するリモートコマンダー３などが用意されており、ユーザは操作入力が可能とされる。
ユーザによる操作入力の情報は、ネットワーク４を介してコンテンツサーバ装置１に送信される。この操作入力により、ユーザは、後述するコンテンツ変更要求等の操作を行うことができる。

ネットワーク４は、例えば家庭内の通信が可能とされる有線又は無線の伝送路により構成される。
例えば有線の場合、電灯線、テレビ用ＲＦケーブル、ＤＬＮＡ（Digital Living Network Alliance）、ＨＤＭＩ（High Definition Multimedia Interface）などが考えられる。また無線の場合、ＩＥＥＥ１３９４．１１ａ，ｂ，ｎ、ブルートゥース（Blue tooth）、２．４ＧＨｚ帯を用いた他の通信方式などが考えられる。

この家庭内ネットワークシステムでは、コンテンツサーバ装置１は、オンデマンドモードでの配信と、パーティモードでの配信が可能とされる。
上述したようにオンデマンドモードとは、各クライアント装置２に対して個別に、要求に応じたコンテンツデータを配信するモードである。一方パーティモードは、全クライアント装置２に対し、共通のコンテンツデータを同時的に配信するモードである。

［１−２：コンテンツサーバ装置］

コンテンツサーバ装置１の構成例を図２で説明する。
コンテンツサーバ装置１は、制御部１１，コンテンツ格納／再生部１２，メモリ部１３，送信部１４，受信部１５を備える。

制御部１１は、ＣＰＵ(Central Processing Unit)、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）等を備えたマイクロコンピュータにより構成される。
制御部１１内のＲＯＭには、例えばＣＰＵが実行すべきプログラムの他、配信動作のための各種の設定情報などが記憶される。ＲＡＭは、ＣＰＵのための主記憶装置部とされる。
この制御部１１は、コンテンツサーバ装置１としての動作全体を制御する。即ちパーティモード及びオンデマンドモードでの配信動作のため、コンテンツ格納／再生部１２での再生動作制御、送信部１４からのコンテンツデータＣＴ等の送信制御、受信部１５で受信した、クライアント装置２からの変更要求ＲＱ等に対する対応処理などを行う。

メモリ部１３は、ＲＡＭ、ＲＯＭ、フラッシュメモリなどの記憶部を総括的に示している。このメモリ部１３は制御部１１の処理のワーク領域として用いられたり、プログラムの格納領域として用いられても良い。また配信動作のための各種の設定情報、パラメータ等を記憶することにも用いられる。
またメモリ部１３は、配信のためにコンテンツ格納／再生部１２で再生されたコンテンツデータの送信バッファとしても用いられることもある。

コンテンツ格納／再生部１２は、各種コンテンツデータＣＴを再生することができる装置部である。コンテンツデータＣＴは、例えばハードディスク、フラッシュメモリ、光ディスクなどに格納されている。コンテンツ格納／再生部１２は、制御部１１の指示に基づき、これらの記憶媒体からのコンテンツデータＣＴの再生を行う。従って、コンテンツ格納／再生部１２は、例えばＨＤＤ、フラッシュメモリプレーヤ、光ディスクプレーヤ、交換型光デイスクプレーヤなどとして実現される。

送信部１４及び受信部１５は、ネットワーク４を介した各クライアント装置２との間での通信部として機能する。
送信部１４は、制御部１１の制御に基づき、主にコンテンツ格納／再生部１２で再生されたコンテンツデータＣＴについて所定のエンコードを行い、ネットワーク送信、つまり各クライアント装置２への配信を行う。
また受信部１５は、各クライアント装置２から送信されてくる信号、例えば配信するコンテンツデータＣＴの変更を求める変更要求ＲＱ等の信号の受信を行う。そして受信した信号をデコードし、受信情報内容を制御部１１に伝達する。
このような処理を行うため、送信部１４及び受信部１５は、ネットワーク４での有線又は無線での通信方式に対応したエンコード、デコード、及び送受信処理を行う。

なお、図２では示していないが、コンテンツサーバ装置１についてユーザが入力を行うための操作部や、対応するリモートコマンダーからのコマンド受信部等が設けられても良い。或いは、コンテンツサーバ装置１への操作入力は、クライアント装置２に対する入力としてユーザが実行できるようにし、クライアント装置２からコンテンツサーバ装置１自体に対する操作情報が供給されるようにしてもよい。
また本実施の形態では、オンデマンドモードとパーティモードで配信が可能とされるが、これらのモード選択の操作も、コンテンツサーバ装置１に設けられた操作子で操作したり、或いは後述するクライアント装置２からの操作入力により行うことができるようにしてもよい。

［１−３：クライアント装置］

続いてクライアント装置２の構成を図３で説明する。
クライアント装置２は、制御部２１，再生処理部２２、メモリ部２３、送信部２４、受信部２５、出力デバイス２６、パネル操作部２７、コマンド受信部２８、表示部２９を備える。

制御部２１は、ＣＰＵ、ＲＯＭ、ＲＡＭ等を備えたマイクロコンピュータにより構成される。
制御部２１内のＲＯＭには、例えばＣＰＵが実行すべきプログラムの他、配信コンテンツの再生動作やコンテンツサーバ装置１との通信動作等のための各種の設定情報などが記憶される。ＲＡＭは、ＣＰＵのための主記憶装置部とされる。
この制御部２１は、クライアント装置２としての動作全体を制御する。即ちパーティモード及びオンデマンドモードでの配信において、コンテンツデータＣＴ等の受信制御や、ユーザの操作に応じた変更要求ＲＱ等の送信制御処理などを行う。

メモリ部２３は、ＲＡＭ、ＲＯＭ、フラッシュメモリなどの記憶部を総括的に示している。このメモリ部２３は制御部２１の処理のワーク領域として用いられたり、プログラムの格納領域として用いられても良い。また再生動作や通信動作のための各種の設定情報、パラメータ等を記憶することにも用いられる。
さらにメモリ部２３は、受信したコンテンツデータＣＴのバッファメモリとしても用いられる。

送信部２４及び受信部２５は、ネットワーク４を介したコンテンツサーバ装置１との間での通信部として機能する。
受信部２５は、コンテンツサーバ装置１から送信されてくる信号、例えば配信されているコンテンツデータＣＴや、その他の各種の指示信号などの受信を行う。そして受信した信号をデコードする。配信によるコンテンツデータＣＴの受信の際には、受信して通信方式に対するデコード処理を行ったコンテンツデータＣＴ（ストリームデータ）を、制御部２１の制御に基づき例えばメモリ部２３に転送してバッファリングさせる。
またコンテンツサーバ装置１からの指示、通知等の信号が受信されてきた場合は、受信部２５はその信号をデコードし、受信情報内容を制御部２１に伝達する。
送信部２４は、制御部２１の制御に基づき、コンテンツサーバ装置１への送信信号について所定のエンコードを行い、ネットワーク４に対する送信出力を行う。例えばコンテンツの変更要求ＲＱなどの送信処理を行う。
このような処理を行うため、送信部２４及び受信部２５は、ネットワーク４での有線又は無線での通信方式に対応したエンコード、デコード、及び送受信処理を行うものとなる。

再生処理部２２は、受信したコンテンツデータＣＴについて出力デバイス２６での再生出力のための処理を行う。例えば受信したコンテンツデータＣＴはメモリ部２３にバッファリングされるが、バッファリングされたコンテンツデータＣＴを構成する各データは、逐次所定タイミングで再生処理部２２に転送される。再生処理部２２はコンテンツデータＣＴに対して出力のための処理、例えば圧縮処理に対するデコード、エラー訂正、Ｄ／Ａ変換処理などを行い、映像信号、音声信号を出力デバイス２６に供給する。
出力デバイス２６は、例えばモニタディスプレイ装置や、スピーカ装置とされる。この出力デバイス２６によって、コンテンツデータＣＴとしての映像や音声が出力され、ユーザの視聴に供される。
なお、出力デバイス２６としてのモニタディスプレイ装置やスピーカ装置は、クライアント装置２としての筐体に一体的に設けられても良いが、別体機器とされても良いことは当然である。

表示部２９は、例えばクライアント装置２の筐体上に設けられる小型の表示パネルであり、制御部２１の制御により、動作状態表示やメニュー表示、アイコン表示、イコライザ表示、タイトル表示、メッセージ表示などを行う。表示部２９は、例えば液晶パネルや有機ＥＬパネルなどで構成される。
なお、これらの表示を出力デバイス２６のモニタディスプレイ装置を用いて行うこともでき、その場合、表示部２９を設けないことも考えられる。
またメッセージ表示に代えて、或いはメッセージ表示と共に、メッセージ音声を出力することも考えられるが、その場合は、出力デバイス２６のスピーカを利用することが考えられる。

パネル操作部２７は、例えばクライアント装置２の筐体上に設けられる操作キー、ジョグダイヤルなどの操作子を総括的に示している。なお、表示部２９、或いは出力デバイス２６のモニタディスプレイ装置においてタッチパネル入力が可能とされる場合、そのタッチパネル機構も、パネル操作部２７の一つとなる。
また、コマンド受信部２８は、リモートコマンダー３からのコマンド情報の受信を行う。リモートコマンダー３は電波、赤外線、或いは有線方式で、ユーザの操作に応じたコマンド情報を送信する機器とされるが、そのリモートコマンダー３から送信されてくるコマンド情報は、コマンド受信部２８で受信、復調され、制御部２１に伝えられる。

ユーザは、パネル操作部２７の操作子の操作や、表示部２９（又は出力デバイス２６のモニタディスプレイ装置）のメニュー表示、アイコン表示に対するタッチパネル操作、さらにはリモートコマンダー３を用いた操作により、各種の操作入力を行うことができる。
制御部２１は、ユーザの操作入力に応じて、クライアント装置２内の動作や設定等の処理を行ったり、送信部１４からコンテンツサーバ装置１に対する信号送信処理を行う。
本実施の形態では、ユーザは、配信コンテンツの変更を求める操作入力を行うことができる。その操作入力を検知した場合、制御部２１は、送信部１４から変更要求ＲＱをコンテンツサーバ装置１に送信させる処理を行う。

［１−４：サーバ・クライアント兼用装置］

上記図２，図３のコンテンツサーバ装置１とクライアント装置２は、それぞれ異なる装置であるとして説明したが、実際にはコンテンツサーバ装置１とクライアント装置２の両方の機能を備えるサーバ・クライアント兼用装置も想定される。
例えば図１の各ルームＲ０〜Ｒ３には、サーバ・クライアント兼用装置が配置され、各機器が任意にコンテンツサーバ装置１或いはクライアント装置２として機能するようにしてもよい。

図４にはサーバ・クライアント兼用装置の構成例を示す。
この場合、制御部３１，コンテンツ格納／再生部１２、メモリ部３３、再生処理部２２、出力デバイス２６、パネル操作部２７、コマンド受信部２８、表示部２９、送信部３４、受信部３５を備える例としている。
コンテンツ格納／再生部１２、再生処理部２２、出力デバイス２６、パネル操作部２７、コマンド受信部２８、表示部２９の動作は上述と同様である。

制御部３１は、上記制御部１１，２１の両方の機能を備える。即ちコンテンツサーバ装置１として機能する場合は、制御部１１と同様の処理を行い、クライアント装置２として機能する場合は制御部２１と同様の処理を行う。
メモリ部３３も、コンテンツサーバ装置１及びクライアント装置２として必要な情報記憶やバッファリングを行う。
送信部３４、受信部３５は、制御部３１の制御に基づき、コンテンツサーバ装置１として機能する場合と、クライアント装置２として機能する場合に、それぞれ必要な通信動作を行う。

このようなサーバ・クライアント兼用装置として構成し、これを各ルームＲ０〜Ｒ３に配置すれば、ユーザは、任意に、特定のサーバ・クライアント兼用装置をマスター、即ちコンテンツサーバ装置１として選択して、他のサーバ・クライアント兼用装置に対し配信を実行させるような使用形態が可能となる。

＜２．第１の実施の形態＞
［２−１：動作概要］

以下、各実施の形態の配信動作を説明していく。なお各実施の形態では、仮に配信するコンテンツデータＣＴは音楽コンテンツであるとして説明するが、全て、他の種類のコンテンツ、例えば映像コンテンツ、ゲームコンテンツ、テキストコンテンツ等の配信の場合も適用できるものである。
また、各実施の形態の動作は、パーティモードで配信している場合の動作に特徴を有するものとなるため、パーティモード動作を説明し、オンデマンドモードの動作についての詳細説明は避ける。
また、説明上、複数のクライアント装置２を区別するため、クライアント装置２Ａ、２Ｂ、２Ｃ等の符号を用いる。同様にコンテンツデータＣＴを区別するため、コンテンツデータＣＴ−Ａ、ＣＴ−Ｂ等の符号を用いる。音楽コンテンツの配信の場合、コンテンツデータＣＴ−ＡとコンテンツデータＣＴ−Ｂは、例えば別の楽曲であると考えればよい。

図５、図６で第１の実施の形態の動作の概要を説明する。
図５は、時間軸に沿って、パーティモードで配信されているコンテンツデータＣＴを示している。
まず、コンテンツサーバ装置１は時点ｔ０まで、或るコンテンツデータＣＴ−Ａを全クライアント装置２に対して配信していたとする。
この時点ｔ０において、或るクライアント装置２Ｂの部屋にいるユーザは、他の曲を聴きたいと思って、クライアント装置２Ｂに対する操作入力で、他のコンテンツデータＣＴ−Ｂの配信を求める操作を行ったとする。クライアント装置２Ｂは、そのような内容の変更要求ＲＱをコンテンツサーバ装置１に送信する。

コンテンツサーバ装置１では、このように時点ｔ０に送信されてくる変更要求ＲＱを受け付ける。そしてコンテンツサーバ装置１は、変更要求ＲＱに応じて、配信コンテンツをコンテンツデータＣＴ−Ｂに変更し、各クライアント装置２に配信する。
つまり、ルームＲ０〜Ｒ３の全てで、配信されている楽曲が切り換えられることになる。

ここで、他の部屋に居るユーザが、コンテンツデータＣＴ−Ｂに変更されたことを不服に思い、時点ｔ１で、クライアント装置２Ａに対する操作入力で、元のコンテンツデータＣＴ−Ａの配信を求める操作を行ったとする。クライアント装置２Ａは、そのような内容の変更要求ＲＱをコンテンツサーバ装置１に送信する。
コンテンツサーバ装置１では、このように時点ｔ１に送信されてくる変更要求ＲＱを受け付ける。そしてコンテンツサーバ装置１は、変更要求ＲＱに応じて、配信コンテンツを再びコンテンツデータＣＴ−Ａに変更し、各クライアント装置２に配信する。
つまり、ルームＲ０〜Ｒ３の全てで、配信されている楽曲が再びコンテンツデータＣＴ−Ａに切り換えられることになる。

この図５では、その後、時点ｔ２，ｔ３などで、クライアント装置２Ｂのユーザと、クライアント装置２Ａのユーザが、争って変更要求ＲＱを出し合い、変更要求ＲＱが錯綜した状態を示している。
コンテンツサーバ装置１は、変更要求ＲＱの受信のたびに配信コンテンツを変更するので、全ルームＲ０〜Ｒ３では、流れている音楽が何度も切り替わり、非常に聞き苦しい状況が生じている。
このような状況は、例えばパーティ中などでは非常に好ましくないため、第１の実施の形態の動作としては、頻繁な変更要求ＲＱの発生を、そのまま許容しないようにする。

具体的には、コンテンツサーバ装置１は、時点ｔ０で最初の変更要求ＲＱが受信されたときから、第１の期間ＴＭ１の計数を開始する。
この期間ＴＭ１が経過する時点ｔ４までは、さらなる変更要求の受信状況を確認する。つまり他の変更要求ＲＱが受信されるか否かを確認する。そして受信した場合には、その変更要求ＲＱを受け付け、配信コンテンツの変更を行う。
ところが期間ＴＭ１内の変更要求ＲＱが多発した場合、コンテンツサーバ装置１は、期間ＴＭ１の経過後、第２の期間ＴＭ２の間は、変更要求ＲＱを無効とする処理を行う。つまり、いわゆるチャンネル争いのような状況（変更要求ＲＱの錯綜）があった場合は、期間ＴＭ２では、クライアント装置２からの変更要求ＲＱを受信しても、それを無効とし、配信コンテンツの変更は行わない。
またコンテンツサーバ装置１は、期間ＴＭ１の経過後は、期間ＴＭ１内の錯綜した変更要求ＲＱを事後的に無効とし、時点ｔ４からは、元々配信されていたコンテンツデータＣＴ−Ａの配信を行う。
またコンテンツサーバ装置１は、第２の期間ＴＭ２の経過後は、変更要求ＲＱを無効とする処理を終了させ、通常どおり、変更要求ＲＱを受け付ける状態に戻る。その後は、また変更要求ＲＱがあった場合は、その最初の変更要求ＲＱの受信から期間ＴＭ１の計数を行い、同様の処理を行うことになる。

一方、図６は、期間ＴＭ１内に、さらなる変更要求ＲＱが受信されなかった場合を示している。
コンテンツサーバ装置１は、時点ｔ０で例えばクライアント装置２Ｂからの変更要求ＲＱの受信があった場合は、上記図５の場合と同様に配信コンテンツをコンテンツデータＣＴ−Ｂに変更する。そして、期間ＴＭ１の計数を開始する。
この期間ＴＭ１内に、他の変更要求ＲＱの受信されなかった場合、又は受信されたが、時点ｔ０から期間ＴＭ１を経過する時点ｔ４までの変更要求ＲＱの受信が所定数未満であった場合は、コンテンツサーバ装置１は、変更要求ＲＱの錯綜が生じていないと判断する。その場合は、時点ｔ４以降、変更要求ＲＱを無効とする処理は行わない。そして時点ｔ０で切り換えたコンテンツデータＣＴ−Ｂの配信をそのまま継続する。

このように第１の実施の形態では、パーティモードでの配信中に、或るクライアント装置からの配信コンテンツの変更を求める変更要求ＲＱを受信した場合、まず、その受信を元に計数が開始される第１の期間ＴＭ１内に、さらなる変更要求ＲＱの受信状況を確認する。そして期間ＴＭ１内における変更要求の受信状況に応じて期間ＴＭ１の経過後の処理を決定する。
特に、期間ＴＭ１内に所定数以上の変更要求ＲＱを検知した場合、第１の期間ＴＭ１の経過後に計数が開始される第２の期間ＴＭ２は、受信される変更要求ＲＱを無効とする処理を行う。また、その場合は、期間ＴＭ１内の変更要求ＲＱ（図５の時点ｔ０，ｔ１，ｔ２，ｔ３の各変更要求ＲＱ）を無効とし、時点ｔ４からは、元のコンテンツデータＣＴ−Ａの配信を行う。例えば時刻ｔ０の時点で配信していたコンテンツの配信箇所から配信を再開する。
一方、期間ＴＭ１内に所定数未満の変更要求ＲＱしか検知されなかった場合、第１の期間ＴＭ１の経過後は、変更要求ＲＱを無効とする処理を行わない。配信コンテンツも、期間ＴＭ１内の最後の変更要求ＲＱにより変更した後のコンテンツデータの配信を継続する。

［２−２：サーバ・クライアントの機能構成］

このような動作を実現するためのコンテンツサーバ装置１及びクライアント装置２の構成、特に制御部１１、２１の機能構成について説明する。

図７はコンテンツサーバ装置１の構成を示し、特に制御部１１について、そのハードウェア及びソフトウェア（プログラム）により実現される機能構成例を示している。
制御部１１の機能構成として、配信制御部４１、カウンタ部４２、閾値メモリ部４３、比較部、タイマ部４５を備える。

配信制御部４１は、パーティモードやオンデマンドモードでの配信動作を制御する機能部位である。配信制御部４１は、コンテンツ格納／再生部１２に対して、配信するコンテンツデータＣＴを指定して再生を実行させ、再生されたコンテンツデータＣＴを送信部１４から各クライアント装置２に配信させる制御を行う。
クライアント装置２からの変更要求ＲＱは、受信部１５で受信されて制御部１１に供給される。変更要求ＲＱは、制御部１１内では、カウンタ部４２と配信制御部４１に伝えられる。
配信制御部４１は、変更要求ＲＱに応じて、要求されたコンテンツデータＣＴの配信を実行するため、コンテンツ格納／再生部１２に、再生するコンテンツデータＣＴの変更を指示する。
なお、上記図５の期間ＴＭ２のように、変更要求ＲＱを無効とする場合には、配信制御部４１は変更要求ＲＱを無効な信号として処理することになる。

カウンタ部４２は、受信された変更要求ＲＱの数ＣＣをカウントする計数機能である。上記期間ＴＭ１における変更要求ＲＱの数が、カウント値（変更要求数）ＣＣとしてカウントされる。
閾値メモリ部４３は、変更要求ＲＱの数の判断のための閾値ＣＣｔｈを記憶する機能である。
比較部４４は、カウンタ部４２が出力する変更要求数ＣＣと閾値ＣＣｔｈを比較する。そしてＣＣ≧ＣＣｔｈであるか否かの比較結果信号を配信制御部４１に出力する。
配信制御部４１は、期間ＴＭ１内において、変更要求数ＣＣが閾値ＣＣｔｈ以上であれば、変更要求ＲＱの錯綜が生じていると判断され、一方、変更要求数ＣＣが閾値ＣＣｔｈ未満であれば変更要求ＲＱの錯綜は生じていないと判断する。

タイマ部４５は、配信制御部４１が起動する時間計数機能であり、期間ＴＭ１，ＴＭ２の計数を行う。配信制御部はリセット信号／スタート信号（Ｒ／Ｓ）をタイマ部４５に与えて計数を実行させる。またタイマ部４５は、期間ＴＭ１、ＴＭ２の経過時に、タイマーオーバフロー信号ＯＦを配信制御部４１に与え、期間ＴＭ１、ＴＭ２の経過を通知する。
具体的には配信制御部４１は、最初の（期間ＴＭ１，ＴＭ２計数を行っていない場合における最初の）変更要求ＲＱがあったら、タイマ部４５に計数スタート信号を与え、期間ＴＭ１の計数を開始させる。
配信制御部４１は、期間ＴＭ１の経過は、タイマ部４５からのオーバフロー信号ＯＦで知ることができる。
配信制御部４１は、期間ＴＭ２に変更要求ＲＱの無効化を行う場合は、期間ＴＭ１の経過後、タイマ部４５にリセット／スタート信号を与え、期間ＴＭ２の計数を開始させる。
配信制御部４１は、期間ＴＭ２の経過は、同様にタイマ部４５からのオーバフロー信号ＯＦで知ることができる。

図８はクライアント装置２の構成、特に制御部２１について、そのハードウェア及びソフトウェア（プログラム）により実現される機能構成例を示している。
制御部２１の機能構成として、再生制御部６１、バッファ処理部６２、送信制御部６３、操作検知部６４を備える。

再生制御部６１は、配信されたコンテンツデータＣＴの再生出力の制御を行う機能である。またバッファ処理部６２は、受信されたコンテンツデータＣＴのバッファリングを管理する機能である。
コンテンツサーバ装置１から配信されてくるコンテンツデータＣＴは受信部２５で受信され、まずバッファ処理部６２の制御により、メモリ部２３にバッファリングされる。バッファ処理部６２は、バッファリングしたデータを逐次メモリ部４３から読み出して再生制御部６１に受け渡す。再生制御部６１は、該データを再生処理部２２に転送し、再生処理部２２に必要な処理、例えば圧縮に対するデコード処理等を実行させ、出力デバイス２６から出力させる制御を行う。

操作検知部６４は、コマンド信号ＣＭＤを検知する機能である。また送信制御部６３は、送信動作の制御を行う機能である。
上述のようにユーザは、パネル操作部２７、タッチパネル、或いはリモートコマンダー３を用いて操作入力を行うことができる。これらを用いた操作の１つとして変更要求操作がある。操作検知部６４は、変更要求としてのコマンド信号ＣＭＤを検知した場合、その情報を送信制御部６３に通知する。
送信制御部６３は、当該変更要求としてのコマンド信号ＣＭＤに応じて、変更要求ＲＱとしての送信データを生成し、送信部２４からコンテンツサーバ装置１に対して送信させる制御を行う。

［２−３：サーバ・クライアントの処理例］

以上の機能構成によって図５，図６で説明した動作が実現される。以下、コンテンツサーバ装置１及びクライアント装置２の処理例を説明する。

まず図７の機能構成によるコンテンツサーバ装置１の制御部１１（主に配信制御部４１）の処理例を図９を参照して述べる。
ステップＦ１０１は電源オンによって起動される処理を示している。制御部１１は電源オンとされ起動したらステップＦ１０２に進み各種変数の初期化を行う。
ステップＦ１０３では、制御部１１はパーティモード、オンデマンドモードのモード設定を確認する。このモード設定については、ユーザの設定操作などによるが、例えば前回の動作時にパーティモードで終了していれば、今回もパーティモードで開始するなどとしてモード判断を行う。或いは起動時に、ユーザにモード選択を行わせるようにしても良い。
ステップＦ１０３で、今回はオンデマンドモードと判断した場合は、制御部１１はオンデマンドモードでの処理に移行する。オンデマンドモードでの処理については説明を省略する。

一方、パーティモードと判断した場合は、制御部１１はステップＦ１０４に進み、パーティモードの開始処理を行う。例えば配信するコンテンツの決定処理などを行う。
そしてステップＦ１０５で制御部１１は配信開始制御を行う。即ち制御部１１は、コンテンツ格納／再生部１２に所定のコンテンツデータＣＴの再生開始を指示する。そして再生したコンテンツデータＣＴを送信部１４に供給させ、送信部１４から全クライアント装置２に対する配信を実行させる。
以降、制御部１１は、コンテンツ格納／再生部１２及び送信部１４に、順次連続してコンテンツデータＣＴの再生及び配信を実行させる。再生するコンテンツデータＣＴ、コンテンツ格納／再生部１２において記録媒体に記憶されたコンテンツナンバの順でもよいし、制御部１１がランダムに選択して逐次指示しても良い。
いずれにしても、ステップＦ１０５以降は、配信終了となるまで、基本的には多数の曲が順次、全クライアント装置２に共通に配信されることになる。

このようにパーティモードでの配信中には、制御部１１は、ステップＦ１０６での変更要求ＲＱの受信の監視、及びステップＦ１２０での配信終了トリガの監視を行う。
ステップＦ１２０では、制御部１１は配信終了のトリガとしての操作や状態を監視する。例えばユーザの配信終了操作によって配信を終了する場合や、電源オフ操作により配信を終了する場合などである。或いは、全てのコンテンツ（もしくは配信対象として選択した全てのコンテンツ）の再生及び配信が終了したことで配信を終了する場合もある。
それらの終了のトリガが検知された場合、制御部１１はステップＦ１２０からＦ１２３に進み、パーティモードでの配信動作を終了する処理を行う。

またステップＦ１０６では、制御部１１は変更要求ＲＱが受信部１５で受信されたか否かを監視する。
制御部１１は、このステップＦ１０６で変更要求ＲＱの受信を検知した場合、図５，図６で説明した動作のための処理を開始することとなる。このステップＦ１０６で検知する変更要求ＲＱとは、図５，図６における時点ｔ０、つまり期間ＴＭ１の計数の起点となる変更要求ＲＱのこととなる。

まずステップＦ１０７で制御部１１は、変更要求ＲＱの受信時点で配信していたコンテンツデータＣＴの中断ポイントを記憶する。図５の例で言えば時点ｔ０までコンテンツデータＣＴ−Ａを配信していたので、このコンテンツデータＣＴ−Ａとしての楽曲の途中の時点ｔ０の再生ポイントが、ここでいう中断ポイントとなる。
次に制御部１１はステップＦ１０８で、変更要求ＲＱに応じた配信コンテンツの変更制御を行う。例えばコンテンツデータＣＴ−Ｂの再生及び配信を、コンテンツ格納／再生部１２及び送信部１４に実行させる。

また制御部１１は、ステップＦ１０９で、カウンタ部４２の機能として、変更要求数ＣＣをインクリメントする。最初はＣＣ＝１とする。
さらに制御部１１はステップＦ１１０で、タイマ部４５の機能としての期間ＴＭ１の計数処理を行う。ここではタイマ部４５での計数値としての「ＴＭ１」をインクリメントする。

その後、計数値ＴＭ１がオーバフローとなるまで、つまり図５、図６で言う期間ＴＭ１が経過するまで、ステップＦ１１２の変更要求ＲＱの受信の監視、及びステップＦ１２１での配信終了のトリガの監視を行いながら、ステップＦ１１０でのインクリメントを行っていく。つまり期間ＴＭ１としてのタイムカウントを進行させる。

制御部１１は、期間ＴＭ１が経過する前に、配信終了トリガが発生したら、ステップＦ１２１からＦ１２３に進み配信終了処理を行う。
また制御部１１は、期間ＴＭ１が経過する前に、他の変更要求ＲＱが受信されたら、ステップＦ１１２からＦ１０８に戻る。
この場合、制御部１１はステップＦ１０８で、新たな変更要求ＲＱに応じた配信コンテンツの変更制御を行う。これによって配信される楽曲が変更されることになる。
また制御部１１は、ステップＦ１０９で、カウンタ部４２の機能として、変更要求数ＣＣをインクリメントする。
このように、期間ＴＭ１の経過までに変更要求ＲＱが受信される毎に、配信コンテンツの変更と変更要求数ＣＣのインクリメントが行われる。

タイマ部４５での計数値「ＴＭ１」がオーバフローし、つまり期間ＴＭ１の経過となったら、制御部１１はステップＦ１１１からＦ１１３に進み、この時点で比較部４４の機能による比較結果を確認する。即ち期間ＴＭ１内に、閾値ＣＣｔｈとしての所定数以上の変更要求ＲＱの受信があったか否かである。
閾値ＣＣｔｈ＝３と設定しているのであれば、例えば最初の変更要求ＲＱを含めて３つ以上の変更要求ＲＱの受信があったか否かの判断となる。

もしＣＣ＜ＣＣｔｈであれば、制御部１１は期間ＴＭ１での変更要求ＲＱの錯綜（配信コンテンツの選択の争い）は生じていないとし、ステップＦ１１９に進む。そして各変数、即ちこの場合は計数値「ＴＭ１」、変更要求数ＣＣをリセットして、ステップＦ１０６、Ｆ１２０の監視ループに戻る。
これは図６で説明した場合の動作となる。

一方、ＣＣ≧ＣＣｔｈであれば、制御部１１は期間ＴＭ１において変更要求ＲＱの錯綜が生じていると判定し、ステップＦ１１４に進む。
まず制御部１１はステップＦ１１４で配信箇所を変更する。ここでは、ステップＦ１０７で記憶した配信中断ポイントからの配信を再開するようにコンテンツ格納／再生部１２を制御し、再生及び配信をコンテンツ格納／再生部１２及び送信部１４に実行させる。つまり、期間ＴＭ１を経過する時点までの変更要求ＲＱ、即ちステップＦ１０６又はＦ１１２で検知した変更要求ＲＱは、無かったものとして、その変更要求ＲＱの受信前の配信状態に戻すものである。

次に制御部１１はステップＦ１１５で、変更要求ＲＱの無効化設定を行う。つまり、以降、変更要求ＲＱを受け付けても、それを無効として配信コンテンツの変更は行わないものとする。
そしてステップＦ１１６で、タイマ部４５の機能としての期間ＴＭ２の計数処理を行う。ここではタイマ部４５での計数値としての「ＴＭ２」をインクリメントする。

その後、計数値ＴＭ２がオーバフローとなるまで、つまり図５で言う期間ＴＭ２が経過するまで、ステップＦ１２２で配信終了のトリガの監視を行いながら、ステップＦ１１６でのインクリメントを行っていく。つまり期間ＴＭ２としてのタイムカウントを進行させる。

制御部１１は、期間ＴＭ２が経過する前に、配信終了トリガが発生したら、ステップＦ１２１からＦ１２３に進み配信終了処理を行う。
なお期間ＴＭ２が経過する前に、変更要求ＲＱが受信される場合があるが、上記ステップＦ１１５で無効化設定をおこなっているため、制御部１１は変更要求ＲＱの受信があっても、それを変更要求ＲＱとして認識しない。つまり期間ＴＭ２の経過までは、変更要求ＲＱは無視する。

タイマ部４５での計数値「ＴＭ２」がオーバフローし、つまり期間ＴＭ２の経過となったら、制御部１１はステップＦ１１７からＦ１１８に進み、変更要求ＲＱの無効化設定を解除する。そしてステップＦ１１９で各変数、即ちこの場合は計数値「ＴＭ１」「ＴＭ２」、変更要求数ＣＣをリセットして、ステップＦ１０６、Ｆ１２０の監視ループに戻る。これが、図５の場合の動作となる。

次にクライアント装置２の制御部２１の処理例を図１０で説明する。
ステップＦ２０１は電源オンによって起動される処理を示している。制御部２１は電源オンとされ起動したらステップＦ２０２に進み各種の初期処理を行う。
ステップＦ２０３では、コンテンツサーバ装置１からの配信開始を待機する。配信、つまり受信部２５でのコンテンツデータＣＴの受信が開始されたら、ステップＦ２０３からＦ２０４に進み、制御部１１はコンテンツデータＣＴの受信及び出力処理を行う。即ち、以降、受信されたコンテンツデータＣＴのバッファリング処理、再生処理部２２への供給を実行し、出力デバイスからの音声や映像の出力を実行させる。

配信開始後は、制御部２１は、このステップＦ２０４の処理を行いながら、ステップＦ２０５で配信終了の監視処理、ステップＦ２０６での変更要求のユーザ操作の監視を行う。
コンテンツサーバ装置１からの配信が終了し、コンテンツデータＣＴが受信されなくなったら、制御部２１はステップＦ２０５からＦ２０８に進む。そして受信されたコンテンツデータＣＴのバッファリング処理及び再生処理部２２への供給を停止して、出力デバイスからのコンテンツデータＣＴとしての音声や映像の出力を終了させる。

ユーザ操作として、変更要求の操作を検知した場合は、制御部２１はステップＦ２０６からＦ２０７に進む。そしてステップＦ２０７で、変更要求ＲＱを送信部２４からコンテンツサーバ装置１に対して送信させる処理を行う。
なお、実際には他のユーザ操作に対応する処理もあるが、図１０では省略している。

このようにクライアント装置２では、配信コンテンツの出力を行いながら、ユーザ操作に応じて変更要求ＲＱの送信を行う。従ってクライアント装置２のユーザは、配信中に任意の時点で、配信コンテンツの変更を要求できることとなる。

以上の図９，図１０の処理をコンテンツサーバ装置１及びクライアント装置２が実行することで、図５，図６で説明した動作が実現される。
そしてこのような第１の実施の形態では、次の効果が得られる。

まず、パーティモードでの配信中に、各ルームＲ０〜Ｒ３のクライアント装置２のユーザは、自由に配信コンテンツの変更の要求を行うことができる。そして、変更要求ＲＱの送信により、配信コンテンツは変更される。従って、或るユーザが、特定の曲や映像などを見聞きしたいと思ったときに便利である。
そして、特にコンテンツ選択の争いが無ければ、そのまま変更されたコンテンツが配信される（図６の状態）。つまりパーティモードでありながらユーザの希望に沿った配信が実現される。
一方で、変更要求ＲＱが一時的に多発し、配信コンテンツ選択の争いが生じることがある。度々配信コンテンツが変更されると、他のユーザの気分を害したり、パーティ等の雰囲気を壊す恐れがある。
そこで、頻繁な変更を許すのは期間ＴＭ１内の短時間のみとし、続く期間ＴＭ２は変更要求ＲＱを無効とする。つまり変更要求ＲＱで争いがある場合は、その争いの影響が配信コンテンツに現れるのを一時的なものとし、すぐに頻繁なコンテンツ変更の無い平穏な状態（期間ＴＭ２）とする。このように頻繁なコンテンツ変更が起こりえる期間を限定していることにより、他のユーザに対する悪影響を最低限とすることができる。

つまり、第１の実施の形態では、頻繁なコンテンツ変更が生ずる期間は許容できる短い期間のみとすることで、雰囲気をさほど悪化させない配信を行いつつ、争いがなければ、或るユーザの希望に応じた配信が可能となるものである。
さらにこれにより、無用な権限争いを防止できるのみならず、コンテンツ変更要求を受け付けない禁止時間を長めに設定することでユーザーは変更を諦め、結果的に無用な権限争いを再発することを防止できるという効果も期待できる。

なお、期間ＴＭ１では、変更要求ＲＱに応じて無条件に配信コンテンツが変更されることから、あまり期間ＴＭ１を長くするのは適切ではない。そこで期間ＴＭ１は３０秒から〜３分程度とすることが考えられる。
但し、もちろん使用形態、使用時の状況、パーティの客層などに応じて適切な時間は多様に考えられ、例えば期間ＴＭ１を１０分程度とするなども想定される。従って、期間ＴＭ１の長さをユーザが設定できるようにすることも考えられる。

また、期間ＴＭ２に関しては、争いがあった場合の制裁的な処理とも考えることができるため、或る程度長い方が良い場合が多い。例えば期間ＴＭ１の５〜１０倍程度の時間を設定することが考えられる。
但し、あまり無効期間を長くしないという設定も考えられるし、期間ＴＭ２もユーザが設定できるようにすることも考えられる。

なお、争いがあったか否かの判断は、変更要求数ＣＣが閾値ＣＣｔｈ以上であるか否かで判断しているが、ＣＣｔｈの値は、期間ＴＭ１の長さや、どの程度のコンテンツ変更を許容するかなどに応じて適切な値が設定されればよい。

また争いがあった場合に、期間ＴＭ１の経過後は、最初の変更要求ＲＱの受信時までに配信していたコンテンツデータＣＴの中断箇所から配信を再開するものとしたが、他の例も考えられる。
例えば、中断箇所でなく、その変更要求ＲＱの前の配信コンテンツの最初（曲の頭）から再開してもよい。
或いは、期間ＴＭ１の終了時点で配信しているコンテンツデータＣＴをそのまま配信することとしてもよい。

また、上記例では、期間ＴＭ２において、全てのクライアント装置２からの変更要求ＲＱを無効化するものとしたが、特定のクライアント装置２からの変更要求ＲＱを無効化するものとしてもよい。即ち、期間ＴＭ１において変更要求ＲＱの錯綜を生じさせたクライアント装置２のみ、例えば図５の例におけるクライアント装置２Ｂ、２Ａのみについて、無効化し、他のクライアント装置２Ｃ等からの変更要求ＲＱは有効としてコンテンツ変更処理を行うことも考えられる。

また上記図９の処理例では、期間ＴＭ１を経過した時点での変更要求数ＣＣと閾値ＣＣｔｈを比較したが、期間ＴＭ１の計時中に絶えず変更要求数ＣＣと閾値ＣＣｔｈとを比較してもよい。
その場合、変更要求数ＣＣが閾値ＣＣｔｈ以上となった時点で、期間ＴＭ１を終了とし、ステップＦ１１４以降の処理、つまり元のコンテンツの配信への変更、変更要求ＲＱの無効化、及び期間ＴＭ２の計測を行ってもよい。

＜３．第２の実施の形態＞
［３−１：動作概要］

続いて第２の実施の形態を説明する。図１１は第２の実施の形態の動作の概要を示すものである。上述した図５と同様に、時間軸に沿って、パーティモードで配信されているコンテンツデータＣＴを示している。

まず、コンテンツサーバ装置１は時点ｔ０まで、或るコンテンツデータＣＴ−Ａを全クライアント装置２に対して配信していたとする。
時点ｔ０において、クライアント装置２Ｂから変更要求ＲＱが送信されてきたとする。
コンテンツサーバ装置１は、上記第１の実施の形態と同様、時点ｔ０で最初の変更要求ＲＱがあったら、配信コンテンツを変更するとともに、期間ＴＭ１の間は、他の変更要求ＲＱも受け付け、配信コンテンツの変更を行う。

この図１１では、その後、時点ｔ１，ｔ２，ｔ３などで、クライアント装置２Ｂのユーザと、クライアント装置２Ａのユーザが、争って変更要求ＲＱを出し合い、変更要求ＲＱが錯綜した状態を示している。
コンテンツサーバ装置１は、変更要求ＲＱの受信のたびに配信コンテンツを変更するので、全ルームＲ０〜Ｒ３では、流れている音楽が何度も切り替わり、一時的に聞き苦しい状況が生じている。
第２の実施の形態でも、期間ＴＭ１においてこのような状況が発生するか否かを判断して、期間ＴＭ１経過後の動作を決定する。

具体的には、コンテンツサーバ装置１は、期間ＴＭ１内の変更要求ＲＱが多発した場合、期間ＴＭ１の経過後、各クライアント装置２に対して変更要求の送信禁止信号ｅｎＲＱを送信する。
これに応じて各クライアント装置２は変更要求ＲＱの送信禁止処理を行う。つまりクライアント装置２は、ユーザは変更要求操作を行ったとしても、変更要求ＲＱをコンテンツサーバ装置１に送信しない。
またコンテンツサーバ装置１は、期間ＴＭ１の経過後は、期間ＴＭ１内の錯綜した変更要求ＲＱを事後的に無効とし、時点ｔ４からは、元々配信されていたコンテンツデータＣＴ−Ａの配信を行う。

また、コンテンツサーバ装置１は期間ＴＭ１の経過時点から期間ＴＭ２を計測し、期間ＴＭ２が経過した後に、送信禁止解除信号ｏｋＲＱを各クライアント装置２に送信する。これに応じて各クライアント装置２は変更要求ＲＱの送信禁止処理を解除する。つまりクライアント装置２は、その後はユーザの変更要求操作に応じて、変更要求ＲＱをコンテンツサーバ装置１に送信するようにする。
従ってコンテンツサーバ装置１には、第２の期間ＴＭ２の経過後は、再び変更要求ＲＱが送信されてくる可能性が生ずる。変更要求ＲＱがあった場合は、その最初の変更要求ＲＱの受信から期間ＴＭ１の計数を行い、同様の処理を行うことになる。

なお、期間ＴＭ１内で、変更要求ＲＱの錯綜が発生しなかった場合は、上記第１の実施の形態の図６と同様の動作となる。

このように第２の実施の形態では、パーティモードでの配信中に、或るクライアント装置からの配信コンテンツの変更を求める変更要求ＲＱを受信した場合、まず、その受信を元に計数が開始される第１の期間ＴＭ１内に、さらなる変更要求ＲＱの受信状況を確認する。そして期間ＴＭ１内における変更要求の受信状況に応じて期間ＴＭ１の経過後の処理を決定する。
特に、期間ＴＭ１内に所定数以上の変更要求ＲＱを検知した場合、各クライアント装置２に対し、変更要求の送信禁止信号ｅｎＲＱを送信し、さらに、期間ＴＭ２の経過後、各クライアント装置２に対し、変更要求の送信禁止解除信号ｏｋＲＱを送信する。これにより、期間ＴＭ２は、クライアント装置２側で変更要求ＲＱの送信ができないようにする。
また、その場合は、期間ＴＭ１内の変更要求ＲＱ（図１１の時点ｔ０，ｔ１，ｔ２，ｔ３の各変更要求ＲＱ）を無効とし、時点ｔ４からは、元のコンテンツデータＣＴ−Ａの配信を行う。例えば時刻ｔ０の時点で配信していたコンテンツの配信箇所から配信を再開する。
一方、期間ＴＭ１内に所定数未満の変更要求ＲＱしか検知されなかった場合、第１の期間ＴＭ１の経過後は、変更要求ＲＱの送信を禁止させる処理は行わない。配信コンテンツも、期間ＴＭ１内の最後の変更要求ＲＱにより変更した後のコンテンツデータの配信を継続する。

［３−２：サーバ・クライアントの機能構成］

このような動作を実現するためのコンテンツサーバ装置１及びクライアント装置２の制御部１１、２１の機能構成を図１２，図１３に示す。

図１２に示すコンテンツサーバ装置１の制御部１１は、機能構成として配信制御部４１、カウンタ部４２、閾値メモリ部４３、比較部４４、タイマ部４５を備えることは第１の実施の形態と同様である。
この場合、配信制御部４１は、送信禁止信号ｅｎＲＱ、送信禁止解除信号ｏｋＲＱを発生させ、送信部１４から各クライアント装置２に送信できるようにする点が第１の実施の形態と異なる。

また図１３に示すクライアント装置２の制御部２１についても、第１の実施の形態と同様に再生制御部６１、バッファ処理部６２、送信制御部６３、操作検知部６４を備える。この場合、受信部２５でコンテンツデータＣＴ以外に、送信禁止信号ｅｎＲＱ、送信禁止解除信号ｏｋＲＱが受信されることもあることから、その処理機能が加わる。即ち受信部２５で受信された送信禁止信号ｅｎＲＱ、送信禁止解除信号ｏｋＲＱは、送信制御部６３に供給され、送信制御部６３は、これらに応じて変更要求ＲＱの送信許否の設定を行う。具体的には送信制御部６３は、送信禁止信号ｅｎＲＱが入力されたら送信禁止設定を行い、以降は、操作検知部６４で変更要求ＲＱの操作が検知されても、変更要求ＲＱの送信処理を行わない。またその後、送信禁止解除信号ｏｋＲＱが入力されたら、送信禁止設定を解除する。

［３−３：サーバ・クライアントの処理例］

この第２の実施の形態のコンテンツサーバ装置１及びクライアント装置２の処理例を説明する。

まず図１４でコンテンツサーバ装置１の制御部１１（主に配信制御部４１）の処理例を述べる。なお第１の実施の形態の図９と同一の処理は同一のステップ番号を付し、重複説明を避ける。

まず、ステップＦ１０１〜Ｆ１０５は図９と同様である。
またパーティモード配信開始後のステップＦ１０６〜Ｆ１１４、Ｆ１２０，Ｆ１２１，Ｆ１２４も図３と同様である。
即ち、パーティモードでの配信中に変更要求ＲＱが受信部１５で受信されたら、制御部１１は、期間ＴＭ１の処理を図９と同様に行う。

ステップＦ１１３〜Ｆ１１９を説明する。
期間ＴＭ１の経過時に、ステップＦ１１３でＣＣ＜ＣＣｔｈであれば、制御部１１は期間ＴＭ１での変更要求ＲＱの錯綜（配信コンテンツの選択の争い）は生じていないとし、ステップＦ１１９に進む。そして各変数、即ちこの場合は計数値「ＴＭ１」、変更要求数ＣＣをリセットして、ステップＦ１０６、Ｆ１２０の監視ループに戻る。

期間ＴＭ１の経過時に、ステップＦ１１３でＣＣ≧ＣＣｔｈであれば、制御部１１は期間ＴＭ１において変更要求ＲＱの錯綜が生じていると判定し、ステップＦ１１４に進む。
まず制御部１１はステップＦ１１４で配信箇所を変更する。ここでは、ステップＦ１０７で記憶した配信中断ポイントからの配信を再開するようにコンテンツ格納／再生部１２を制御し、再生及び配信をコンテンツ格納／再生部１２及び送信部１４に実行させる。つまり、期間ＴＭ１を経過する時点までの変更要求ＲＱ、即ちステップＦ１０６又はＦ１１２で検知した変更要求ＲＱは、無かったものとして、その変更要求ＲＱの受信前の配信状態に戻す。

次に制御部１１はステップＦ１１５Ａで、変更要求の送信禁止信号ｅｎＲＱの送信制御を行い、送信部１４から各クライアント装置２に送信禁止信号ｅｎＲＱを送信させる。
そしてステップＦ１１６で、タイマ部４５の機能としての期間ＴＭ２の計数処理を行う。

その後、計数値ＴＭ２がオーバフローとなるまで、つまり図１１で言う期間ＴＭ２が経過するまで、ステップＦ１２２で配信終了のトリガの監視を行いながら、ステップＦ１１６でのインクリメントを行っていく。つまり期間ＴＭ２としてのタイムカウントを進行させる。
制御部１１は、期間ＴＭ２が経過する前に、配信終了トリガが発生したら、ステップＦ１２１からＦ１２３に進み配信終了処理を行う。
なお、期間ＴＭ２が経過するまでの期間においては、変更要求ＲＱを受信することはない。各クライアント装置２が、送信禁止信号ｅｎＲＱに従って、変更要求ＲＱを送信してこないためである。

タイマ部４５での計数値「ＴＭ２」がオーバフローし、つまり期間ＴＭ２の経過となったら、制御部１１はステップＦ１１７からＦ１１８Ａに進み、送信禁止解除信号ｏｋＲＱの送信制御を行い、送信部１４から各クライアント装置２に送信禁止解除信号ｏｋＲＱを送信させる。
そしてステップＦ１１９で各変数、即ちこの場合は計数値「ＴＭ１」「ＴＭ２」、変更要求数ＣＣをリセットして、ステップＦ１０６、Ｆ１２０の監視ループに戻る。

次にクライアント装置２の制御部２１の処理例を図１５で説明する。これも第１の実施の形態の図１０と同様の処理には同様のステップ番号を付して説明を省略する。
ステップＦ２０１〜Ｆ２０５、Ｆ２０８は図１０と同様である。

配信開始後は、制御部２１はステップＦ２０４のコンテンツデータＣＴの受信及び出力処理を行いながら、ステップＦ２０５での配信終了の監視処理に加え、ステップＦ２１０，Ｆ２１２，Ｆ２１４の監視処理を行う。

ステップＦ２１０では、送信禁止信号ｅｎＲＱの受信を監視する。制御部２１は、コンテンツサーバ装置１からの送信禁止信号ｅｎＲＱを受信した場合は、ステップＦ２１１で変更要求ＲＱの送信禁止設定を行う。
ステップＦ２１２では、送信禁止解除信号ｏｋＲＱの受信を監視する。制御部２１は、コンテンツサーバ装置１からの送信禁止解除信号ｏｋＲＱを受信した場合は、ステップＦ２１３で変更要求ＲＱの送信禁止設定を解除する。

ユーザ操作として、変更要求の操作を検知した場合は、制御部２１はステップＦ２１４からＦ２１５に進む。そして、現在送信禁止設定がされているか否かを確認する。
送信禁止設定がされていなければ、制御部２１はステップＦ２１６に進み、変更要求ＲＱを送信部２４からコンテンツサーバ装置１に対して送信させる処理を行う。
送信禁止設定がされていれば、制御部２１はステップＦ２１７に進み、ユーザの変更要求の操作を無効操作として処理し、変更要求ＲＱの送信処理は行わない。

以上の図１４，図１５の処理をコンテンツサーバ装置１及びクライアント装置２が実行することで、第２の実施の形態としての図１１で説明した動作が実現される。
そしてこの第２の実施の形態では、第１の実施の形態と同様の効果が得られる。

即ち、パーティモードでの配信中に、各ルームＲ０〜Ｒ３のクライアント装置２のユーザは、自由に配信コンテンツの変更の要求を行うことができる。そして、特にコンテンツ選択の争いが無ければ、そのまま変更されたコンテンツが配信される。
一方で、変更要求ＲＱが一時的に多発しても、頻繁な配信コンテンツの変更を許すのは期間ＴＭ１内の短時間のみとし、続く期間ＴＭ２は変更要求ＲＱを送信できないものとする。従って、他のユーザの不快感や雰囲気の悪化が長引かない。
さらに、第２の期間ＴＭ２はクライアント装置２から変更要求ＲＱが送信できないため、その後の無用な権限争いの再発を防止できる。

なお、期間ＴＭ１、ＴＭ２の設定、閾値ＣＣｔｈの設定は、第１の実施の形態と同様に考えればよい。
また争いがあった場合に、期間ＴＭ１の経過後に配信するコンテンツデータＣＴの選択も、第１の実施の形態と同様の変形例が考えられる。

また、上記例では、期間ＴＭ２において、全てのクライアント装置２に送信禁止信号ｅｎＲＱを送信するものとしたが、特定のクライアント装置２にのみ送信禁止信号ｅｎＲＱを送信するものとしてもよい。即ち、期間ＴＭ１において変更要求ＲＱの錯綜を生じさせたクライアント装置２のみ、送信禁止信号ｅｎＲＱを送信し、他のクライアント装置２は、引き続き変更要求ＲＱの送信を可能な状態を維持させてもよい。

また上記図１４の処理例では、期間ＴＭ１を経過した時点での変更要求数ＣＣと閾値ＣＣｔｈを比較したが、期間ＴＭ１の計時中に絶えず変更要求数ＣＣと閾値ＣＣｔｈとを比較してもよい。
その場合、変更要求数ＣＣが閾値ＣＣｔｈ以上となった時点で、期間ＴＭ１を終了とし、ステップＦ１１４以降の処理、つまり元のコンテンツの配信への変更、送信禁止信号ｅｎＲＱの送信、及び期間ＴＭ２の計測を行ってもよい。

また、図１５のクライアント装置２の処理として、ステップＦ２１７でユーザの操作を無効化する場合には、故障等と勘違いさせないようにすることや、争い防止のために送信禁止されたことを積極的に提示するために、例えば表示部２９等で、変更要求ＲＱの送信が禁止されていることのメッセージ表示等を行うことが好適である。

＜４．第３の実施の形態＞
［４−１：動作概要］

続いて第３の実施の形態を説明する。図１５は第３の実施の形態の動作の概要として、時間軸に沿って、パーティモードで配信されているコンテンツデータＣＴを示している。

まず、コンテンツサーバ装置１は時点ｔ０まで、或るコンテンツデータＣＴ−Ａを全クライアント装置２に対して配信していたとする。
時点ｔ０において、クライアント装置２Ｂから変更要求ＲＱが送信されてきたとする。
コンテンツサーバ装置１は、上記第１の実施の形態と同様、時点ｔ０で最初の変更要求ＲＱがあったら、配信コンテンツを変更するとともに、期間ＴＭ１の間は、他の変更要求ＲＱも受け付け、配信コンテンツの変更を行う。

この図１５では、その後、時点ｔ１，ｔ２，ｔ３などで、クライアント装置２Ｂのユーザと、クライアント装置２Ａのユーザが、争って変更要求ＲＱを出し合い、変更要求ＲＱが錯綜した状態を示している。
コンテンツサーバ装置１は、変更要求ＲＱの受信のたびに配信コンテンツを変更するので、全ルームＲ０〜Ｒ３では、流れている音楽が何度も切り替わり、一時的に聞き苦しい状況が生じている。
第３の実施の形態でも、期間ＴＭ１においてこのような状況が発生するか否かを判断して、期間ＴＭ１経過後の動作を決定する。

具体的には、コンテンツサーバ装置１は、期間ＴＭ１内の変更要求ＲＱが多発した場合、期間ＴＭ１の経過後、各クライアント装置２に対して変更要求の送信禁止信号ｅｎＲＱを送信する。
これに応じて各クライアント装置２は変更要求ＲＱの送信禁止処理を行う。つまりクライアント装置２は、ユーザは変更要求操作を行ったとしても、変更要求ＲＱをコンテンツサーバ装置１に送信しない。

またコンテンツサーバ装置１は、期間ＴＭ１の経過後は、期間ＴＭ１内の錯綜した変更要求ＲＱを事後的に無効とし、時点ｔ４からは、元々配信されていたコンテンツデータＣＴ−Ａの配信を行う。

ここまでは、上記第２の実施の形態と同様である。但しこの第３の実施の形態の場合、クライアント装置２側で、第２の期間ＴＭ２を計測する。即ちクライアント装置２は送信禁止信号ｅｎＲＱを受信したら、期間ＴＭ２の計数を行い、期間ＴＭ２が経過するまでは、変更要求ＲＱの送信禁止設定を維持する。
そして期間ＴＭ２の経過後、自主的に送信禁止設定を解除する。
従ってコンテンツサーバ装置１には、第２の期間ＴＭ２の経過後は、再び変更要求ＲＱが送信されてくる可能性が生ずる。変更要求ＲＱがあった場合は、その最初の変更要求ＲＱの受信から期間ＴＭ１の計数を行い、同様の処理を行うことになる。

なお、期間ＴＭ１内で、変更要求ＲＱの錯綜が発生しなかった場合は、上記第１の実施の形態の図６と同様の動作となる。

このように第２の実施の形態では、パーティモードでの配信中に、或るクライアント装置からの配信コンテンツの変更を求める変更要求ＲＱを受信した場合、まず、その受信を元に計数が開始される第１の期間ＴＭ１内に、さらなる変更要求ＲＱの受信状況を確認する。そして期間ＴＭ１内における変更要求の受信状況に応じて期間ＴＭ１の経過後の処理を決定する。
特に、期間ＴＭ１内に所定数以上の変更要求ＲＱを検知した場合、各クライアント装置２に対し、変更要求の送信禁止信号ｅｎＲＱを送信する。
これに応じてクライアント装置２では、自主的に期間ＴＭ２の間、変更要求ＲＱの送信を行わないようにする。

［４−２：サーバ・クライアントの機能構成］

このような動作を実現するためのコンテンツサーバ装置１及びクライアント装置２の制御部１１、２１の機能構成を図１７，図１８に示す。

図１７に示すコンテンツサーバ装置１の制御部１１は、機能構成として配信制御部４１、カウンタ部４２、閾値メモリ部４３、比較部４４、タイマ部４５を備えることは第１、第２の実施の形態と同様である。
この場合、配信制御部４１は、送信禁止信号ｅｎＲＱを発生させ、送信部１４から各クライアント装置２に送信できるようにする点が第１、第２の実施の形態と異なる。
またタイマ部４５は、第１の期間ＴＭ１の計測を行う機能とされる。

また図１８に示すクライアント装置２の制御部２１については、第１、第２の実施の形態と同様に再生制御部６１、バッファ処理部６２、送信制御部６３、操作検知部６４を備える。これに加えてタイマ部６５を備える。

この第３の実施の形態の場合、受信部２５ではコンテンツデータＣＴ以外に、送信禁止信号ｅｎＲＱが受信されることがある。受信部２５で受信された送信禁止信号ｅｎＲＱは、送信制御部６３に供給され、送信制御部６３は、これらに応じて変更要求ＲＱの送信禁止の設定を行う。具体的には送信制御部６３は、送信禁止信号ｅｎＲＱが入力されたら送信禁止設定を行い、以降は、操作検知部６４で変更要求ＲＱの操作が検知されても、変更要求ＲＱの送信処理を行わない。さらに、タイマ部６５による期間ＴＭ２の計数を開始させる。
そしてタイマ部６５での期間ＴＭ２の計数が終了したら、送信制御部６３は送信禁止設定を解除する。

［４−３：サーバ・クライアントの処理例］

この第３の実施の形態のコンテンツサーバ装置１及びクライアント装置２の処理例を説明する。

まず図１９でコンテンツサーバ装置１の制御部１１（主に配信制御部４１）の処理例を述べる。なお図９、図１４と同一の処理は同一のステップ番号を付し、重複説明を避け、ステップＦ１１３〜Ｆ１１９のみ説明する。

期間ＴＭ１の経過時に、ステップＦ１１３でＣＣ＜ＣＣｔｈであれば、制御部１１は期間ＴＭ１での変更要求ＲＱの錯綜は生じていないとし、ステップＦ１１９に進む。そして各変数、即ち計数値「ＴＭ１」、変更要求数ＣＣをリセットして、ステップＦ１０６、Ｆ１２０の監視ループに戻る。

期間ＴＭ１の経過時に、ステップＦ１１３でＣＣ≧ＣＣｔｈであれば、制御部１１は期間ＴＭ１において変更要求ＲＱの錯綜が生じていると判定し、ステップＦ１１４に進む。
まず制御部１１はステップＦ１１４で配信箇所を変更する。ここでは、ステップＦ１０７で記憶した配信中断ポイントからの配信を再開するようにコンテンツ格納／再生部１２を制御し、再生及び配信をコンテンツ格納／再生部１２及び送信部１４に実行させる。つまり、期間ＴＭ１を経過する時点までの変更要求ＲＱ、即ちステップＦ１０６又はＦ１１２で検知した変更要求ＲＱは、無かったものとして、その変更要求ＲＱの受信前の配信状態に戻す。

次に制御部１１はステップＦ１１５Ａで、変更要求の送信禁止信号ｅｎＲＱの送信制御を行い、送信部１４から各クライアント装置２に送信禁止信号ｅｎＲＱを送信させる。
そしてステップＦ１１９で各変数、即ち計数値「ＴＭ１」、変更要求数ＣＣをリセットして、ステップＦ１０６、Ｆ１２０の監視ループに戻る。
なお、ステップＦ１１５Ａで送信禁止信号ｅｎＲＱを送信した後は、ステップＦ１１９を経てステップＦ１０６、Ｆ１２０の監視ループに戻るが、クライアント装置２側で第２の期間ＴＭ２のカウントが完了するまでは、変更要求ＲＱが送信されてくることはない。

次にクライアント装置２の制御部２１の処理例を図１５で説明する。これも図１０、図１５と同様の処理には同様のステップ番号を付して説明を省略する。

配信開始後は、制御部２１はステップＦ２０４のコンテンツデータＣＴの受信及び出力処理を行いながら、ステップＦ２０５での配信終了の監視処理に加え、ステップＦ２１０，Ｆ２２１，Ｆ２１４の監視処理を行う。

ステップＦ２１０では、送信禁止信号ｅｎＲＱの受信を監視する。制御部２１は、コンテンツサーバ装置１からの送信禁止信号ｅｎＲＱを受信した場合は、ステップＦ２１１で変更要求ＲＱの送信禁止設定を行う。
そしてステップＦ２２０で、タイマ部６５の機能による期間ＴＭ２のカウントを開始させる。

ステップＦ２２１では、タイマ部６５のカウント中において、ＴＭ２のカウントがオーバフローしたか否かを確認する。つまり期間ＴＭ２の経過の確認である。
なお、この確認処理は、ステップＦ２２０でカウントスタートさせた以後のみの処理であり、通常時（期間ＴＭ２のカウントを行っていない期間）は、否定結果として処理を抜ければよい。

ステップＦ２２０でカウントスタートさせた以後において、期間ＴＭ２の経過が確認された場合は、制御部２１はステップＦ２２２に進み、変更要求ＲＱの送信禁止設定を解除する。
そしてステップＦ２２３で期間ＴＭ２のカウント値としての変数「ＴＭ２」をリセットする。

ユーザ操作として、変更要求の操作を検知した場合は、制御部２１はステップＦ２１４からＦ２１５に進む。そして、現在送信禁止設定がされているか否かを確認する。
送信禁止設定がされていなければ、制御部２１はステップＦ２１６に進み、変更要求ＲＱを送信部２４からコンテンツサーバ装置１に対して送信させる処理を行う。
送信禁止設定がされていれば、制御部２１はステップＦ２１７に進み、ユーザの変更要求の操作を無効操作として処理し、変更要求ＲＱの送信処理は行わない。

以上の図１９，図２０の処理をコンテンツサーバ装置１及びクライアント装置２が実行することで、第３の実施の形態としての図１６で説明した動作が実現される。
そしてこの第３の実施の形態では、第１の実施の形態と同様の効果が得られる。

即ち、パーティモードでの配信中に、各ルームＲ０〜Ｒ３のクライアント装置２のユーザは、自由に配信コンテンツの変更の要求を行うことができる。そして、特にコンテンツ選択の争いが無ければ、そのまま変更されたコンテンツが配信される。
一方で、変更要求ＲＱが一時的に多発しても、頻繁な配信コンテンツの変更を許すのは期間ＴＭ１内の短時間のみとし、続く期間ＴＭ２はクライアント装置２側で変更要求ＲＱを送信できないものとしている。従って、他のユーザの不快感や雰囲気の悪化が長引かない。
さらに、第２の期間ＴＭ２はクライアント装置２から変更要求ＲＱが送信できないため、その後の無用な権限争いの再発を防止できる。

また、この第３の実施の形態では、クライアント装置２側で期間ＴＭ２の計数、及びそれに応じた送信禁止設定の解除が行われるため、コンテンツサーバ装置１の処理負担が軽減されるという効果も生ずる。

なお、期間ＴＭ１、ＴＭ２の設定、閾値ＣＣｔｈの設定は、第１の実施の形態と同様に考えればよい。
また争いがあった場合に、期間ＴＭ１の経過後に配信するコンテンツデータＣＴの選択も、第１の実施の形態と同様の変形例が考えられる。

また、上記例では、期間ＴＭ２において、全てのクライアント装置２に送信禁止信号ｅｎＲＱを送信するものとしたが、特定のクライアント装置２にのみ送信禁止信号ｅｎＲＱを送信するものとしてもよい。即ち、期間ＴＭ１において変更要求ＲＱの錯綜を生じさせたクライアント装置２のみ、送信禁止信号ｅｎＲＱを送信し、他のクライアント装置２は、引き続き変更要求ＲＱの送信を可能な状態を維持させてもよい。

また上記図１９の処理例では、期間ＴＭ１を経過した時点での変更要求数ＣＣと閾値ＣＣｔｈを比較したが、期間ＴＭ１の計時中に絶えず変更要求数ＣＣと閾値ＣＣｔｈとを比較してもよい。
その場合、変更要求数ＣＣが閾値ＣＣｔｈ以上となった時点で、期間ＴＭ１を終了とし、ステップＦ１１４、Ｆ１１５Ａの処理、つまり元のコンテンツの配信への変更、送信禁止信号ｅｎＲＱの送信を行ってもよい。
また、図２０のクライアント装置２の処理として、ステップＦ２１７でユーザの操作を無効化する場合には、第２の実施の形態の場合と同様、例えば表示部２９等で、変更要求ＲＱの送信が禁止されていることのメッセージ表示等を行うことが好適である。

＜５．第４の実施の形態＞
［５−１：動作概要］

第４の実施の形態の動作の概要を図２１、図２２で説明する。図２１、図２２は、時間軸に沿って、パーティモードで配信されているコンテンツデータＣＴを示している。
まず、コンテンツサーバ装置１は時点ｔ０まで、或るコンテンツデータＣＴ−Ａを全クライアント装置２に対して配信していたとする。そして時点ｔ０において、或るクライアント装置２Ｂから変更要求ＲＱがあったとする。

コンテンツサーバ装置１では、このように時点ｔ０に送信されてくる変更要求ＲＱを受け付ける。
但し、この第４の実施の形態では、コンテンツサーバ装置１は、最初の変更要求ＲＱに応じて、すぐに配信コンテンツを変更することは行わない。ルームＲ０〜Ｒ３の全てに対して配信されている楽曲はコンテンツデータＣＴ−Ａのままである。
そして、このときコンテンツサーバ装置１は、全クライアント装置２に対して、変更要求ＲＱがあったことを告知する告知信号ＡＮを送信する。
各クライアント装置２では、告知信号ＡＮを受信することに応じて、メッセージ表示やメッセージ音声出力などにより、各クライアント装置２のある部屋にいるユーザに対して、或るユーザからの配信コンテンツの変更要求ＲＱがあったことを告知する。
またコンテンツサーバ装置１は、告知信号ＡＮに、変更を求めているコンテンツデータＣＴの内容、例えば楽曲や曲名や映像コンテンツの名称などのタイトル情報も含めるようにし、各クライアント装置２は、それらのタイトル情報をメッセージ表示（音声）に含めて提示するとよい。つまり、変更要求ＲＱを送ったユーザ以外の各ユーザが、どのようなコンテンツデータＣＴに切り換えられようとしているかがわかるようにするとよい。

なお、ここでは全クライアント装置２に対して告知信号ＡＮを送信する例としているが、変更要求ＲＱを送信したクライアント装置２Ｂを除いて、他のクライアント装置２に対して送信するものとしてもよい。つまりクライアント装置２Ｂのユーザは、自分（又は同じ部屋にいる人）が変更要求ＲＱを送信させたものであるから、変更要求ＲＱの発生を承知していると考えられるためである。
但し、本例では上記のように、例えば時点ｔ０で変更要求ＲＱを受け付けても、コンテンツサーバ装置１はすぐに配信コンテンツの変更を行わない。このため、クライアント装置２Ｂのユーザにとっては、変更要求ＲＱが正しく送信されているか否か分からないことがある。そこで、クライアント装置２Ｂに対しても告知信号ＡＮ（又は受付完了信号）を送信するようにし、クライアント装置２Ｂにおいて、受付の旨をメッセージ表示することも適切である。

本例の場合、最初に時点ｔ０で変更要求ＲＱを受け付けることに応じて、コンテンツサーバ装置１は、その時点ｔ０を起点として、期間ＴＭ１の計数を行う。この期間ＴＭ１が経過する時点ｔ４までは、さらなる変更要求の受信状況を確認する。つまり他の変更要求ＲＱが受信されるか否かを確認する。
そして、この期間ＴＭ１内に、他の変更要求ＲＱの受信されなかった場合など、時点ｔ０から期間ＴＭ１を経過する時点ｔ４までの変更要求ＲＱの受信が所定数未満であった場合に、コンテンツサーバ装置１は、変更要求ＲＱに応じた配信コンテンツの変更を行う。
例えば図２２は、時点ｔ０で変更要求ＲＱが生じた後、期間ＴＭ１を経過するまでに他の変更要求ＲＱが受信されなかった場合を示している。

この場合、コンテンツサーバ装置１は変更要求ＲＱの錯綜が生じていないと判断する。その場合は、時点ｔ４以降、その時点の最新の変更要求ＲＱに応じて、配信コンテンツの変更を行う。例えば時点ｔ０の変更要求ＲＱが、コンテンツデータＣＴ−Ｂの配信を求めるものであったら、時点ｔ４からコンテンツデータＣＴ−Ｂの配信に切り換える。
これにより、ルームＲ０〜Ｒ３の全てで、配信されている楽曲が切り換えられることになる。

一方、各クライアント装置２でのメッセージ出力により、時点ｔ０の変更要求ＲＱがあったことを知った他のユーザは、そのような配信コンテンツの変更を不服に思うことがある。
その場合に、当該他のユーザが、図２１の時点ｔ１で、或るクライアント装置２Ａに対する操作入力で、元のコンテンツデータＣＴ−Ａ（又は他のコンテンツデータ）の配信を求める操作を行ったとする。クライアント装置２Ａは、そのような内容の変更要求ＲＱをコンテンツサーバ装置１に送信する。
コンテンツサーバ装置１では、このように時点ｔ１に送信されてくる変更要求ＲＱを受け付ける。
この場合もコンテンツサーバ装置１は、変更要求ＲＱを受け付けるが、未だ期間ＴＭ１を経過していないため、時点ｔ１では配信コンテンツの変更は行わない。
その一方で、変更要求ＲＱの受信に応じて、各クライアント装置２に対し告知信号ＡＮを送信する。従って、他のユーザに時点ｔ１での変更要求ＲＱの受信及び内容が提示される。

この図５では、その後、時点ｔ２，ｔ３などで、クライアント装置２Ｂのユーザと、クライアント装置２Ａのユーザが、争って変更要求ＲＱを出し合い、変更要求ＲＱが錯綜した状態を示している。
但しコンテンツサーバ装置１は、これらの変更要求ＲＱの受信に即座に応じた配信コンテンツの変更は行っていないため、全ルームＲ０〜Ｒ３では、流れている音楽の切り替わりは生じていない。

そしてコンテンツサーバ装置１は、期間ＴＭ１を経過した時点ｔ４で、変更要求ＲＱの受信数を確認する。
期間ＴＭ１内の変更要求ＲＱが多発した場合、コンテンツサーバ装置１は、変更要求ＲＱの錯綜があったとして、時点ｔ４での配信コンテンツの変更は行わない。つまり図２１での各時点ｔ０，ｔ１，ｔ２，ｔ３の変更要求ＲＱは事後的に無効とする。
このため、全ての部屋に流れている音楽（コンテンツデータＣＴ−Ａ）は切り換えられないことになる。なお、もちろん時点ｔ４以前、又はそれ以降で、コンテンツデータＣＴ−Ａが終了した場合（曲が終わった場合）は、所定の順序での次のコンテンツデータＣＴに切り替わることになる。

またコンテンツサーバ装置１は、変更要求ＲＱの錯綜があったと判定した場合、時点ｔ４で、各クライアント装置２に対して変更要求の送信禁止信号ｅｎＲＱを送信する。
これに応じて各クライアント装置２は変更要求ＲＱの送信禁止処理を行う。つまりクライアント装置２は、ユーザが変更要求操作を行ったとしても、変更要求ＲＱをコンテンツサーバ装置１に送信しない。

各クライアント装置２側では、第２の期間ＴＭ２を計測する。即ちクライアント装置２は送信禁止信号ｅｎＲＱを受信したら、期間ＴＭ２の計数を行い、期間ＴＭ２が経過するまでは、変更要求ＲＱの送信禁止設定を維持する。
そして期間ＴＭ２の経過後、自主的に送信禁止設定を解除する。
従ってコンテンツサーバ装置１には、第２の期間ＴＭ２の経過後は、再び変更要求ＲＱが送信されてくる可能性が生ずる。変更要求ＲＱがあった場合は、その最初の変更要求ＲＱの受信から期間ＴＭ１の計数を行い、同様の処理を行うことになる。

このように第４の実施の形態では、パーティモードでの配信中に、或るクライアント装置からの配信コンテンツの変更を求める変更要求ＲＱを受信した場合、その時点では配信コンテンツの変更は行わない。そして最初の変更要求ＲＱの受信を元に計数が開始される第１の期間ＴＭ１内に、さらなる変更要求ＲＱの受信状況を確認する。そして期間ＴＭ１内における変更要求の受信状況に応じて期間ＴＭ１の経過後の処理を決定する。
特に、期間ＴＭ１内に所定数以上の変更要求ＲＱを検知した場合、各クライアント装置２に対し、変更要求の送信禁止信号ｅｎＲＱを送信する。
これに応じてクライアント装置２では、自主的に期間ＴＭ２の間、変更要求ＲＱの送信を行わないようにする。
結果的に、期間ＴＭ１の経過までの変更要求ＲＱに応じた配信コンテンツの変更は行われないことになる。
一方、期間ＴＭ１内に所定数未満の変更要求ＲＱしか検知されなかった場合、第１の期間ＴＭ１の経過後は、変更要求ＲＱを無効とする処理を行わない。配信コンテンツも、期間ＴＭ１内の最後の変更要求ＲＱにより変更した後のコンテンツデータの配信に切り換える。

［５−２：サーバ・クライアントの機能構成］

このような動作を実現するためのコンテンツサーバ装置１及びクライアント装置２の制御部１１、２１の機能構成を図２３，図２４に示す。

図２３に示すコンテンツサーバ装置１の制御部１１は、機能構成として配信制御部４１、カウンタ部４２、閾値メモリ部４３、比較部４４、タイマ部４５を備えることは第１〜第３の実施の形態と同様である。
この場合、配信制御部４１は、送信禁止信号ｅｎＲＱを発生させ、送信部１４から各クライアント装置２に送信できるようにすることに加え、変更要求ＲＱの受信時に告知信号ＡＮを発生させ、送信部１４から各クライアント装置２に送信する点が第１〜第３の実施の形態と異なる。
タイマ部４５は、第１の期間ＴＭ１の計測を行う機能とされる。

また図２４に示すクライアント装置２の制御部２１については、第３の実施の形態と同様に再生制御部６１、バッファ処理部６２、送信制御部６３、操作検知部６４、タイマ部６５を備え、これに加えて告知制御部６６を備える。

この第４の実施の形態の場合、受信部２５ではコンテンツデータＣＴ以外に、送信禁止信号ｅｎＲＱ及び告知信号ＡＮが受信されることがある。受信部２５で受信された送信禁止信号ｅｎＲＱは、送信制御部６３に供給され、送信制御部６３は、これらに応じて変更要求ＲＱの送信禁止の設定を行う。具体的には送信制御部６３は、送信禁止信号ｅｎＲＱが入力されたら送信禁止設定を行い、以降は、操作検知部６４で変更要求ＲＱの操作が検知されても、変更要求ＲＱの送信処理を行わない。さらに、タイマ部６５による期間ＴＭ２の計数を開始させる。
そしてタイマ部６５での期間ＴＭ２の計数が終了したら、送信制御部６３は送信禁止設定を解除する。

また受信部２５で受信された告知信号ＡＮは、告知制御部６６に供給され、告知制御部６６は、これらに応じて表示部２９でのメッセージ表示の制御を行う。
即ち告知制御部６６は、告知信号ＡＮに基づいて、或るクライアント装置２から変更要求ＲＱがあったことと、変更を求めているコンテンツデータＣＴのタイトルを含むメッセージを、表示部２９からユーザに提示させる。例えば「＊＊＊＊への変更の操作がありました」（「＊＊＊＊」は曲名など）とのメッセージ表示を実行させる。
なお、メッセージ表示を行うのは、出力デバイス２６におけるモニタディスプレイ上としてもよい。
また、メッセージ音声を出力する場合、告知制御部６６は、再生処理部２２を介してメッセージ音声を出力デバイス２６におけるスピーカから出力させるようにする。

［５−３：サーバ・クライアントの処理例］

この第４の実施の形態のコンテンツサーバ装置１及びクライアント装置２の処理例を説明する。

まず図２５でコンテンツサーバ装置１の制御部１１（主に配信制御部４１）の処理例を述べる。なお図９、図１４、図１９と同一の処理は同一のステップ番号を付している。ここではステップＦ１０１〜Ｆ１０５の説明は省略し、ステップＦ１０５でパーティモードでのコンテンツ配信が開始された後の処理を説明する。

パーティモードでの配信中には、制御部１１は、ステップＦ１０６での変更要求ＲＱの受信の監視、及びステップＦ１２０での配信終了トリガの監視を行う。
配信終了のトリガが検知された場合、制御部１１はステップＦ１２０からＦ１２３に進み、パーティモードでの配信動作を終了する処理を行う。

制御部１１は、ステップＦ１０６で変更要求ＲＱの受信を検知した場合、図２１，図２２で説明した動作のための処理を開始することとなる。このステップＦ１０６で検知する変更要求ＲＱとは、図２１，図２２における時点ｔ０、つまり期間ＴＭ１の計数の起点となる変更要求ＲＱのこととなる。

まずステップＦ１３０で制御部１１は、各クライアント装置２に対して告知信号ＡＮを送信させる。即ち制御部２１は、受信した変更要求ＲＱの内容（変更を求めるコンテンツデータＣＴのタイトル等）を含む告知信号ＡＮを生成し、送信部１４から送信させる。
また制御部１１は、ステップＦ１０９で、カウンタ部４２の機能として、変更要求数ＣＣをインクリメントする。最初はＣＣ＝１とする。
さらに制御部１１はステップＦ１１０で、タイマ部４５の機能としての期間ＴＭ１の計数処理を行う。ここではタイマ部４５での計数値としての「ＴＭ１」をインクリメントする。

その後、計数値ＴＭ１がオーバフローとなるまで、つまり図２１，図２２でいう期間ＴＭ１が経過するまで、ステップＦ１１２の変更要求ＲＱの受信の監視、及びステップＦ１２１での配信終了のトリガの監視を行いながら、ステップＦ１１０でのインクリメントを行っていく。つまり期間ＴＭ１としてのタイムカウントを進行させる。

制御部１１は、期間ＴＭ１が経過する前に、配信終了トリガが発生したら、ステップＦ１２１からＦ１２３に進み配信終了処理を行う。
また制御部１１は、期間ＴＭ１が経過する前に、他の変更要求ＲＱが受信されたら、ステップＦ１１２からＦ１０９に戻る。
この場合、制御部１１はステップＦ１０９で、カウンタ部４２の機能として、変更要求数ＣＣをインクリメントする。
このように、期間ＴＭ１の経過までに変更要求ＲＱが受信される毎に、変更要求数ＣＣのインクリメントが行われる。
但し期間ＴＭ１の経過までには、配信コンテンツの変更制御は行わない。

タイマ部４５での計数値「ＴＭ１」がオーバフローし、つまり期間ＴＭ１の経過となったら、制御部１１はステップＦ１１１からＦ１１３に進み、この時点で比較部４４の機能による比較結果を確認する。即ち期間ＴＭ１内に、閾値ＣＣｔｈとしての所定数以上の変更要求ＲＱの受信があったか否かである。

もしＣＣ＜ＣＣｔｈであれば、制御部１１は期間ＴＭ１での変更要求ＲＱの錯綜（配信コンテンツの選択の争い）は生じていないとし、ステップＦ１３１に進んで、配信コンテンツの変更処理を行う。
即ち制御部１１は、期間ＴＭ１を経過するまでにおける最新の変更要求ＲＱに応じた配信コンテンツの変更制御を行う。例えば図２２の例の場合、コンテンツデータＣＴ−Ｂの再生及び配信を、コンテンツ格納／再生部１２及び送信部１４に実行させる。
そしてステップＦ１１９に進み、各変数、即ちこの場合は計数値「ＴＭ１」、変更要求数ＣＣをリセットして、ステップＦ１０６、Ｆ１２０の監視ループに戻る。
これは図２２で説明した場合の動作となる。

一方、ＣＣ≧ＣＣｔｈであれば、制御部１１は期間ＴＭ１において変更要求ＲＱの錯綜が生じていると判定し、ステップＦ１１５Ａに進む。
制御部１１はステップＦ１１５Ａで、変更要求の送信禁止信号ｅｎＲＱの送信制御を行い、送信部１４から各クライアント装置２に送信禁止信号ｅｎＲＱを送信させる。
そしてステップＦ１１９で各変数、即ち計数値「ＴＭ１」、変更要求数ＣＣをリセットして、ステップＦ１０６、Ｆ１２０の監視ループに戻る。
これは図２１で説明した場合の動作となる。結局、期間ＴＭ１での変更要求ＲＱに応じた配信コンテンツの変更は行われないことになる。
なお、ステップＦ１１５Ａで送信禁止信号ｅｎＲＱを送信した後は、ステップＦ１１９を経てステップＦ１０６、Ｆ１２０の監視ループに戻るが、クライアント装置２側で第２の期間ＴＭ２のカウントが完了するまでは、変更要求ＲＱが送信されてくることはない。

次にクライアント装置２の制御部２１の処理例を図２６で説明する。図１０、図１５、図２０と同様の処理には同じステップ番号を付している。配信開始後のステップＦ２０４から説明する。

配信開始後は、制御部２１はステップＦ２０４のコンテンツデータＣＴの受信及び出力処理を行いながら、ステップＦ２０５での配信終了の監視処理に加え、ステップＦ２３０，Ｆ２１０，Ｆ２２１，Ｆ２１４の監視処理を行う。

ステップＦ２３０では、告知信号ＡＮの受信を監視する。制御部２１は、コンテンツサーバ装置１からの告知信号ＡＮを受信した場合は、ステップＦ２３１で、提示制御部６６の機能により、告知信号ＡＮに応じた提示制御を行う。例えば表示部２９等でのメッセージ表示や、出力デバイス２６におけるスピーカを用いたメッセージ音声出力を行う。
例えば「＊＊＊＊への変更要求がありました」というようなメッセージ提示で、変更要求の発生及び変更が求められたコンテンツタイトルの表示等を行う。

ステップＦ２１０では、送信禁止信号ｅｎＲＱの受信を監視する。制御部２１は、コンテンツサーバ装置１からの送信禁止信号ｅｎＲＱを受信した場合は、ステップＦ２１１で変更要求ＲＱの送信禁止設定を行う。
そしてステップＦ２２０で、タイマ部６５の機能による期間ＴＭ２のカウントを開始させる。

ステップＦ２２１では、タイマ部６５のカウント中において、ＴＭ２のカウントがオーバフローしたか否かを確認する。つまり期間ＴＭ２の経過の確認である。
なお、この確認処理は、ステップＦ２２０でカウントスタートさせた以後のみの処理であり、通常時（期間ＴＭ２のカウントを行っていない期間）は、否定結果として処理を抜ければよい。

ステップＦ２２０でカウントスタートさせた以後において、期間ＴＭ２の経過が確認された場合は、制御部２１はステップＦ２２２に進み、変更要求ＲＱの送信禁止設定を解除する。
そしてステップＦ２２３で期間ＴＭ２のカウント値としての変数「ＴＭ２」をリセットする。

ユーザ操作として、変更要求の操作を検知した場合は、制御部２１はステップＦ２１４からＦ２１５に進む。そして、現在送信禁止設定がされているか否かを確認する。
送信禁止設定がされていなければ、制御部２１はステップＦ２１６に進み、変更要求ＲＱを送信部２４からコンテンツサーバ装置１に対して送信させる処理を行う。
送信禁止設定がされていれば、制御部２１はステップＦ２１７に進み、ユーザの変更要求の操作を無効操作として処理し、変更要求ＲＱの送信処理は行わない。

以上の図２５，図２６の処理をコンテンツサーバ装置１及びクライアント装置２が実行することで、図２１，図２２で説明した動作が実現される。
そしてこのような第４の実施の形態では、次の効果が得られる。

即ち、パーティモードでの配信中に、各ルームＲ０〜Ｒ３のクライアント装置２のユーザは、自由に配信コンテンツの変更の要求を行うことができる。そして、特にコンテンツ選択の争いが無ければ、変更要求ＲＱから多少の待機期間後、つまり最初の変更要求ＲＱから期間ＴＭ１を経過した後、配信コンテンツの変更が行われる。
一方で、変更要求ＲＱが多発しても、配信コンテンツの変更は行われない。従って、配信コンテンツの変更によって他のユーザが不快に思ったり、パーティ等の雰囲気が悪化するということは生じない。
つまり、第４の実施の形態では、頻繁なコンテンツ変更は生じさせないことで、他のユーザには快適な配信を提供できる。その上で、争いがなければ、或るユーザの希望に応じた配信変更が可能となるものである。
さらに、第２の期間ＴＭ２はクライアント装置２から変更要求ＲＱが送信できないため、その後の無用な権限争いの再発を防止できるという利点も生ずる。

また、上記第３の実施の形態と同様、クライアント装置２側で期間ＴＭ２の計数、及びそれに応じた送信禁止設定の解除が行われるため、コンテンツサーバ装置１の処理負担が軽減される。

なお、期間ＴＭ１、ＴＭ２の設定、閾値ＣＣｔｈの設定は、第１の実施の形態と同様に考えればよい。
また、上記例では、変更要求ＲＱの錯綜があった場合、全てのクライアント装置２に送信禁止信号ｅｎＲＱを送信するものとしたが、特定のクライアント装置２にのみ送信禁止信号ｅｎＲＱを送信するものとしてもよい。即ち、期間ＴＭ１において変更要求ＲＱの錯綜を生じさせたクライアント装置２のみ、送信禁止信号ｅｎＲＱを送信し、他のクライアント装置２は、引き続き変更要求ＲＱの送信を可能な状態を維持させてもよい。

また上記図２５の処理例では、期間ＴＭ１を経過した時点での変更要求数ＣＣと閾値ＣＣｔｈを比較したが、期間ＴＭ１の計時中に絶えず変更要求数ＣＣと閾値ＣＣｔｈとを比較してもよい。
その場合、変更要求数ＣＣが閾値ＣＣｔｈ以上となった時点で、期間ＴＭ１を終了とし、ステップＦ１１５Ａの送信禁止信号ｅｎＲＱの送信を行ってもよい。

また、第４の実施の形態では、変更要求ＲＱの錯綜があった場合に、第３の実施の形態と同様に、送信禁止信号ｅｎＲＱを送信し、クライアント装置２側で期間ＴＭ２をカウントする例を挙げたが、この際に、第１，第２の実施の形態と同様の処理を行うことも考えられる。即ち期間ＴＭ２はコンテンツサーバ装置１側でカウントしつつ、その間、変更要求ＲＱを無効としてもよいし、或いは期間ＴＭ２の経過後に送信禁止解除信号ｏｋＲＱを送信するようにしてもよい。

また、クライアント装置２の処理として、ステップＦ２３１の告知信号ＡＮに基づいた提示内容は多様に考えられる。
例えば「変更要求がありました」というようなメッセージ提示で、変更要求の発生のみを告知しても良い。
また「クライアントナンバ３より変更要求がありました」というようなメッセージ提示で、変更要求の発生元も知らせるようにしても良い。
また「１５時３５分にクライアントナンバ３より変更要求がありました」というような操作時刻を含めたメッセージ提示を行っても良い。
もちろん、これらのメッセージ内容とする場合は、コンテンツサーバ装置１が、当該内容の情報を告知信号ＡＮに含めるようにすればよい。

さらに、変更要求ＲＱを行ったクライアント装置２では、変更要求ＲＱが受け付けられたことと、変更可能性を提示してもよい。つまり、いずれにしても期間ＴＭ１を経過するまでは、配信コンテンツの変更は行われないため、「配信コンテンツの変更まで、少々お待ち下さい」等のメッセージ提示を行うようにすることがよい。

また、ステップＦ２１７でユーザの操作を無効化する場合には、第２、第３の実施の形態の場合と同様、例えば表示部２９等で、変更要求ＲＱの送信が禁止されていることのメッセージ表示等を行うことが好適である。
さらに、その場合、変更要求ＲＱを行ったクライアント装置２については、先に送信した変更要求ＲＱが無効とされたことになるため、「変更要求はキャンセルされました」「変更要求が多数あったため、変更要求はキャンセルされました」等のメッセージ提示を行うことも考えられる。

＜６．第５の実施の形態＞
［６−１：動作概要］

第５の実施の形態の動作の概要を図２７で説明する。図２７は、時間軸に沿って、パーティモードで配信されているコンテンツデータＣＴを示している。
まず、コンテンツサーバ装置１は時点ｔ０まで、或るコンテンツデータＣＴ−Ａを全クライアント装置２に対して配信していたとする。そして時点ｔ０において、或るクライアント装置２Ｂから変更要求ＲＱがあったとする。

コンテンツサーバ装置１では、このように時点ｔ０に送信されてくる変更要求ＲＱを受け付けるが、変更要求ＲＱに応じて、すぐに配信コンテンツをコンテンツデータを変更することは行わない。
またコンテンツサーバ装置１は、全クライアント装置２に対して、変更要求ＲＱがあったことを告知する告知信号ＡＮを送信する。
各クライアント装置２では、告知信号ＡＮを受信することに応じて、メッセージ表示やメッセージ音声出力などにより、各クライアント装置２のある部屋にいるユーザに対して、変更要求ＲＱがあったことを告知する。
また、最初に時点ｔ０で変更要求ＲＱを受け付けることに応じて、コンテンツサーバ装置１は、その時点ｔ０を起点として、期間ＴＭ１の計数を行う。
以上の点は、上記第４の実施の形態と同様である。

この第５の実施の形態の場合、期間ＴＭ１が経過する時点ｔ４までは、さらなる変更要求ＲＱの受信状況を確認するとともに、クライアント装置２からの賛否情報信号Ｐ／Ｃの確認も行う。
賛否情報信号Ｐ／Ｃとは、複数の変更要求ＲＱが競合した場合に、競合した当事者以外のユーザが、どの変更要求に賛同するか（或いはどの変更要求にも反対するか）の意思表示を示す信号である。いわゆる投票と考えることができる。
このためクライアント装置２では、ユーザが、提示された複数の配信コンテンツの変更について、自分の投票としての操作入力を行うことができるようにされる。
その操作に応じて各クライアント装置２はコンテンツサーバ装置１に対して賛否情報信号Ｐ／Ｃを送信する。

図２７の例では、まず時点ｔ０で変更要求ＲＱがあり、各クライアント装置２に告知信号ＡＮが送信される。
この時点で各クライアント装置２では、コンテンツデータＣＴ−Ｂへの変更要求の発生の旨を提示すると共に、変更要求に係る「コンテンツデータＣＴ−Ｂ」に賛同するか、或いは「配信コンテンツを変更しない」に賛同するかの投票メニューを表示させ、ユーザが操作入力可能とする。

また時点ｔ１で、２つめの変更要求ＲＱが或るクライアント装置２Ａからあったとする。コンテンツサーバ装置１は、この時点でも配信コンテンツの変更は行わないが、変更要求ＲＱに応じて告知信号ＡＮを各クライアント装置２に送信する。
この場合のクライアント装置２Ａからの変更要求ＲＱが、「コンテンツデータＣＴ−Ｃ」への変更要求であったら、各クライアント装置２では、コンテンツデータＣＴ−Ｃへの変更要求の発生の旨を提示する。そしてそれと共に、「コンテンツデータＣＴ−Ｂ」に賛同するか、「コンテンツデータＣＴ−Ｃ」に賛同するか、或いは「配信コンテンツを変更しない」に賛同するかの投票メニューを表示させ、ユーザが操作入力可能とする。
なお、このときのクライアント装置２Ａからの変更要求ＲＱが、現在配信中の「コンテンツデータＣＴ−Ａ」への変更要求（つまりコンテンツデータＣＴ−Ｂへの変更の拒否の内容）であったら、各クライアント装置２は、「コンテンツデータＣＴ−Ｂ」に賛同するか、或いは「配信コンテンツを変更しない」に賛同するかの投票メニューを表示させればよい。

例えばこのような提示に対し、例えば他のクライアント装置２Ｃ、２Ｄのユーザは、操作入力を行い、賛否情報信号Ｐ／Ｃを送信させる。
図２７では時点ｔ２，ｔ３に、クライアント装置２Ｃ、２Ｄからの賛否情報信号Ｐ／Ｃが受信されたことを示している。
コンテンツサーバ装置１は、賛否情報信号Ｐ／Ｃの受信に応じて、集計処理を行う。

そしてコンテンツサーバ装置１は、期間ＴＭ１を経過した時点ｔ４以降の配信動作を、変更要求ＲＱの受信数及び賛否情報信号Ｐ／Ｃの集計結果に基づいて決定する。
例えば、期間ＴＭ１内の変更要求ＲＱの受信が多発していない場合、つまり変更要求ＲＱの受信が１回又は２回程度であった場合は、特にコンテンツの変更の争いは起きていないとして、最新の変更要求ＲＱに応じた配信コンテンツの変更を行う。
一方、期間ＴＭ１内に多数回の変更要求ＲＱの受信があった場合は、コンテンツサーバ装置１は、変更要求ＲＱの錯綜があったとして、時点ｔ４での配信コンテンツの変更を、賛否情報信号Ｐ／Ｃの集計結果に応じて決定する。
そして時点ｔ４以降は、その集計結果に応じたコンテンツ配信を行う。

このように第５の実施の形態では、パーティモードでの配信中に、或るクライアント装置からの配信コンテンツの変更を求める変更要求ＲＱを受信した場合、その時点では配信コンテンツの変更は行わない。そして最初の変更要求ＲＱの受信を元に計数が開始される第１の期間ＴＭ１内に、さらなる変更要求ＲＱや賛否情報信号Ｐ／Ｃを確認する。
そして期間ＴＭ１内における変更要求の受信状況や賛否情報信号Ｐ／Ｃの集計結果に応じて期間ＴＭ１の経過後の処理を決定する。この場合、配信コンテンツを決定する。

［６−２：サーバ・クライアントの機能構成］

このような動作を実現するためのコンテンツサーバ装置１及びクライアント装置２の制御部１１、２１の機能構成を図２８，図２９に示す。

図２８に示すコンテンツサーバ装置１の制御部１１は、機能構成として配信制御部４１、カウンタ部４２、閾値メモリ部４３、比較部４４、タイマ部４５を備える。これらの各機能は第４の実施の形態と同様である。これに加えて、集計部４６を備える。
受信部１５では、変更要求ＲＱ以外に、賛否情報信号Ｐ／Ｃを受信することがある。受信された賛否情報信号Ｐ／Ｃは集計部４６に供給され、集計処理される。集計結果は配信制御部４１に供給される。

また図２９に示すクライアント装置２の制御部２１については、再生制御部６１、バッファ処理部６２、送信制御部６３、操作検知部６４、告知制御部６６を備える。
再生制御部６１、バッファ処理部６２、送信制御部６３、操作検知部６４の各機能は上記第１の実施の形態と同様である。また告知制御部６６は、上記第４の実施の形態の場合と同様の変更要求ＲＱの提示制御に加え、この第５の実施の形態の場合、投票メニューの表示等の制御も行う。

［６−３：サーバ・クライアントの処理例］

この第５の実施の形態のコンテンツサーバ装置１及びクライアント装置２の処理例を説明する。

まず図３０でコンテンツサーバ装置１の制御部１１（主に配信制御部４１）の処理例を述べる。なお図９、図１４、図１９、図２５と同一の処理は同一のステップ番号を付している。ここではステップＦ１０１〜Ｆ１０５の説明は省略し、ステップＦ１０５でパーティモードでのコンテンツ配信が開始された後の処理を説明する。

パーティモードでの配信中には、制御部１１は、ステップＦ１０６での変更要求ＲＱの受信の監視、及びステップＦ１２０での配信終了トリガの監視を行う。
配信終了のトリガが検知された場合、制御部１１はステップＦ１２０からＦ１２３に進み、パーティモードでの配信動作を終了する処理を行う。

制御部１１は、ステップＦ１０６で変更要求ＲＱの受信を検知した場合、図２７で説明した動作のための処理を開始する。このステップＦ１０６で検知する変更要求ＲＱとは、図２７における時点ｔ０、つまり期間ＴＭ１の計数の起点となる変更要求ＲＱのこととなる。

まずステップＦ１３０で制御部１１は、各クライアント装置２に対して告知信号ＡＮを送信させる。即ち制御部２１は、受信した変更要求ＲＱの内容（変更を求めるコンテンツデータＣＴのタイトル等）を含む告知信号ＡＮを生成し、送信部１４から送信させる。
また制御部１１は、ステップＦ１０９で、カウンタ部４２の機能として、変更要求数ＣＣをインクリメントする。
さらに制御部１１はステップＦ１１０で、タイマ部４５の機能としての期間ＴＭ１の計数処理を行う。ここではタイマ部４５での計数値としての「ＴＭ１」をインクリメントする。

その後、計数値ＴＭ１がオーバフローとなるまで、つまり図２７でいう期間ＴＭ１が経過するまで、ステップＦ１１２の変更要求ＲＱの受信の監視、ステップＦ１４１での賛否情報信号Ｐ／Ｃの受信の監視、及びステップＦ１２１での配信終了のトリガの監視を行いながら、ステップＦ１１０でのインクリメントを行っていく。つまり期間ＴＭ１としてのタイムカウントを進行させる。

制御部１１は、期間ＴＭ１が経過する前に、配信終了トリガが発生したら、ステップＦ１２１からＦ１２３に進み配信終了処理を行う。
また制御部１１は、期間ＴＭ１が経過する前に、他の変更要求ＲＱが受信されたら、ステップＦ１１２からＦ１０９に戻る。
この場合、制御部１１はステップＦ１０９で、カウンタ部４２の機能として、変更要求数ＣＣをインクリメントする。
このように、期間ＴＭ１の経過までに変更要求ＲＱが受信される毎に、変更要求数ＣＣのインクリメントが行われる。
但し期間ＴＭ１の経過までには、配信コンテンツの変更制御は行わない。

また制御部１１は、期間ＴＭ１が経過する前に、賛否情報信号Ｐ／Ｃが受信されたら、ステップＦ１４１からＦ１４２に進み、集計部４６の機能により集計処理を行う。
例えばその時点での１又は複数の変更要求ＲＱにかかるコンテンツ及び「コンテンツ変更しない」について票を計上する処理を行う。

タイマ部４５での計数値「ＴＭ１」がオーバフローし、つまり期間ＴＭ１の経過となったら、制御部１１はステップＦ１１１からＦ１１３に進み、この時点で比較部４４の機能による比較結果を確認する。即ち期間ＴＭ１内に、閾値ＣＣｔｈとしての所定数以上の変更要求ＲＱの受信があったか否かである。

もしＣＣ＜ＣＣｔｈであれば、制御部１１は期間ＴＭ１での変更要求ＲＱの錯綜（配信コンテンツの選択の争い）は生じていないとし、ステップＦ１４５に進んで、配信コンテンツの変更処理を行う。
即ち制御部１１は、期間ＴＭ１を経過するまでにおける最新の変更要求ＲＱに応じた配信コンテンツの変更制御を行う。例えば期間ＴＭ１を経過するまでの中で最新の変更要求ＲＱがコンテンツデータＣＴ−Ｂを求めるものであったら、コンテンツデータＣＴ−Ｂの再生及び配信を、コンテンツ格納／再生部１２及び送信部１４に実行させる。
そしてステップＦ１１９に進み、各変数、即ち計数値「ＴＭ１」、変更要求数ＣＣをリセットして、ステップＦ１０６、Ｆ１２０の監視ループに戻る。

一方、ＣＣ≧ＣＣｔｈであれば、制御部１１は期間ＴＭ１において変更要求ＲＱの錯綜が生じていると判定し、ステップＦ１４３に進む。
制御部１１はステップＦ１４３で、争いがあった複数の変更要求ＲＱについての、賛否情報信号Ｐ／Ｃによる投票の集計結果を確認し、それによって配信コンテンツを決定する。
そしてステップＦ１４５に進んで、集計結果に応じた決定に基づく配信コンテンツの変更処理を行う。
そしてステップＦ１１９に進み、各変数、即ち計数値「ＴＭ１」、変更要求数ＣＣをリセットして、ステップＦ１０６、Ｆ１２０の監視ループに戻る。

次にクライアント装置２の処理を図３１で説明する。図１０、図１５、図２０、図２７と同様の処理には同じステップ番号を付している。配信開始後のステップＦ２０４から説明する。

配信開始後は、制御部２１はステップＦ２０４のコンテンツデータＣＴの受信及び出力処理を行いながら、ステップＦ２０５での配信終了の監視処理に加え、ステップＦ２３０，Ｆ２１０，Ｆ２２１，Ｆ２１４の監視処理を行う。

ステップＦ２０６では、ユーザによる変更要求の操作入力を監視する。
ユーザ操作として、変更要求の操作を検知した場合は、制御部２１はステップＦ２０６からＦ２０７に進み、変更要求ＲＱを送信部２４からコンテンツサーバ装置１に対して送信させる処理を行う。

ステップＦ２４１では、投票メニュー表示に対するユーザによる賛否情報の操作入力を監視する。
ユーザ操作として、賛否情報の操作入力を検知した場合は、制御部２１はステップＦ２４１からＦ２４２に進み、賛否情報信号Ｐ／Ｃを送信部２４からコンテンツサーバ装置１に対して送信させる処理を行う。

ステップＦ２４３では、告知信号ＡＮの受信を監視する。制御部２１は、コンテンツサーバ装置１からの告知信号ＡＮを受信した場合は、ステップＦ２４４で、提示制御部６６の機能により、告知信号ＡＮに応じた提示制御を行う。例えば表示部２９等でのメッセージ表示や、出力デバイス２６におけるスピーカを用いたメッセージ音声出力を行う。
さらに制御部２１は、メッセージ表示制御と共に、表示部２９や出力デバイス２６におけるモニタディスプレイを用いて、投票メニューの表示を実行させる。この投票メニュー表示に対して、ユーザは賛否情報の入力を行うことができる。

以上の図３０，図３１の処理をコンテンツサーバ装置１及びクライアント装置２が実行することで、図２７で説明した動作が実現される。
そしてこのような第５の実施の形態では、次の効果が得られる。

即ち、パーティモードでの配信中に、各ルームＲ０〜Ｒ３のクライアント装置２のユーザは、自由に配信コンテンツの変更の要求を行うことができる。
一方で、変更要求ＲＱが多発しても、期間ＴＭ１を経過するまでは配信コンテンツの変更は行われない。従って、配信コンテンツの頻繁な変更によって他のユーザが不快に思ったり、パーティ等の雰囲気が悪化するということは生じない。
なお、期間ＴＭ１の設定、閾値ＣＣｔｈの設定は、第１の実施の形態と同様に考えればよい。

また図３０の処理ではコンテンツサーバ装置１はステップＦ１４３で集計結果から配信コンテンツの決定を行うが、このときの集計及び決定の手法、或いは賛否情報信号Ｐ／Ｃの送受信に関しては多様な例が考えられる。

まず、各クライアント装置２のユーザに対しては、変更要求ＲＱが発生した場合に投票メニューの表示が行われるが、必ずしも各クライアント装置２のユーザが投票の操作を行うとは限らない。そこで、賛否情報信号Ｐ／Ｃを送信してこなかったクライアント装置２については、「変更容認」「変更しない」「無効票」などの解釈があり得る。
例えば投票メニューが或るコンテンツデータＣＴへの「変更を支持」「変更を不支持」というような場合は、表示賛否情報信号Ｐ／Ｃを送信してこなかったクライアント装置２の票は、「変更を支持」とみなしてもよい。
また投票メニューが「コンテンツデータＣＴ−Ｂへ変更」「コンテンツデータＣＴ−Ｃへ変更」「変更しない」のようなものであれば、表示賛否情報信号Ｐ／Ｃを送信してこなかったクライアント装置２の票は、「変更しない」とみなしてもよい。
また投票メニューが「コンテンツデータＣＴ−Ｂへ変更」「コンテンツデータＣＴ−Ｃへ変更」のようなものであれば、表示賛否情報信号Ｐ／Ｃを送信してこなかったクライアント装置２の票は、「無効票」とみなすことが考えられる。
もちろんこれらは一例であるが、このようにすると、配信コンテンツに無関心なユーザについての意志として適している。

また、変更要求ＲＱの発生数に応じて、投票内容も各種考えられる。
図２７の例に即した例でいえば、時点ｔ０〜ｔ１では変更要求ＲＱが１つ発生している。このときクライアント装置２では、「変更容認」「変更しない」の投票メニューを表示し、ユーザの投票操作を求める。そして投票操作に応じて賛否情報信号Ｐ／Ｃを送信する。
時点ｔ１では２つめの変更要求ＲＱが発生している。そこで時点ｔ１以降は、クライアント装置２では、「コンテンツデータＣＴ−Ｂへ変更」「コンテンツデータＣＴ−Ｃへ変更」「変更しない」の投票メニューに切り換え、ユーザの投票操作を求める。そして投票操作に応じて賛否情報信号Ｐ／Ｃを送信する。
その後、時点ｔ２，ｔ３では賛否情報信号Ｐ／Ｃがコンテンツサーバ装置１に受信されるが、それは、時点ｔ１以降の投票メニューに対するものとして集計する。

なお、時点ｔ０〜ｔ１の間に、或るクライアント装置２からの賛否情報信号Ｐ／Ｃが受信される場合もある。コンテンツサーバ装置１は、時点ｔ１で投票メニューが切り替わることに応じて、時点ｔ１以前の賛否情報信号Ｐ／Ｃは無効としてもよいし、例えば同じ選択肢の票として集計することとしてもよい。
例えば時点ｔ１より前に或るクライアント装置２から「変更容認」の賛否情報信号Ｐ／Ｃが受信されており、それがコンテンツデータＣＴ−Ｂへの変更を容認するものであったら、時点ｔ１以降の投票メニューにおける「コンテンツデータＣＴ−Ｂへ変更」への票として計上する。

例えばこのように、変更要求ＲＱの数に応じて、投票メニューを切り換えていきながら、期間ＴＭ１の終了時点での集計を行い、時点ｔ４以降、最多票の選択肢に応じた配信を行うようにする。

なお、既に１回賛否情報信号Ｐ／Ｃを送信していたクライアント装置２から、再度の賛否情報信号Ｐ／Ｃが受信されたら、コンテンツサーバ装置１はそれを無効としてもよいし、或いは最新の賛否情報信号Ｐ／Ｃを有効として以前の賛否情報信号Ｐ／Ｃは無効としてもよい。

また、クライアント装置２側では、所定数以上、例えば２以上の変更要求ＲＱがあったときのみ、投票メニューの表示を行い、ユーザに賛否情報信号Ｐ／Ｃの送信の操作を求めるようにしても良い。
例えば図３１のステップＦ２４４の処理として、１回目の告知信号ＡＮの受信時には、変更要求発生のメッセージ表示のみとし、２回目以降の告知信号ＡＮの受信時には、変更要求発生のメッセージと共に、投票メニューの表示を行う。
この場合、ユーザは、２以上の変更要求の内容を含む選択肢に対して、所望の投票操作を行う。
特に、変更要求ＲＱの錯綜が生じたときに他のユーザの投票で配信コンテンツを決めるという考え方においては、このような処理が適している。

また、変更要求ＲＱを送信したクライアント装置２については、投票メニューの表示及び賛否情報信号Ｐ／Ｃの送信を実行できないようにすることも考えられる。ユーザが自己の変更要求ＲＱに賛成する投票を防ぐためである。

なお、図２７で説明した例では、期間ＴＭ１を経過した後も、各クライアント装置２からは任意に変更要求ＲＱを送信することができる。これに対して時点ｔ４以降、第１、第２，第３の実施の形態の手法を用いて、期間ＴＭ２において変更要求ＲＱを禁止しても良い。
また、期間ＴＭ１を経過した後、コンテンツサーバ装置１は集計結果を各クライアント装置２に通知し、各クライアント装置２で集計結果の提示を行うことも考えられる。

＜７．第６の実施の形態＞
［７−１：動作概要］

第６の実施の形態の概要を図３２で説明する。
上記第１〜第５の実施の形態では、全部の部屋でパーティモードを継続するという前提の動作であるが、この第６の実施の形態は、変更要求ＲＱを送信したクライアント装置２をパーティモードから離脱させる動作である。即ち当該クライアント装置２のみ、オンデマンドモードとして、その部屋だけに要求されたコンテンツデータＣＴを配信する。

図３２は、時間軸に沿って、配信されているコンテンツデータＣＴを示している。
まず、コンテンツサーバ装置１は時点ｔ０まで、パーティモードで或るコンテンツデータＣＴ−Ａを全クライアント装置２に対して配信していたとする。そして時点ｔ０において、或るクライアント装置２Ｂから変更要求ＲＱがあったとする。

コンテンツサーバ装置１では、このように時点ｔ０に送信されてくる変更要求ＲＱを受け付ける。そしてクライアント装置２Ｂをパーティモードから切り離し、オンデマンドモードとして、クライアント装置２Ｂにのみ、要求されたコンテンツデータＣＴ−Ｘを配信する。
他のクライアント装置２に対しては、パーティモードを継続し、例えばコンテンツデータＣＴ−Ａの配信を継続する。
また例えば時点ｔ１でコンテンツデータＣＴ−Ａが終了（曲の終了）したら、そのパーティモードにおける所定の順序（或いはランダム選定）として決められる次の曲（コンテンツデータＣＴ−Ｂ）の配信を行う。

一方、クライアント装置２Ｂに対してオンデマンド配信されているコンテンツデータＣＴ−Ｘが、時点ｔ２で終了したとする。
この場合、コンテンツサーバ装置１は、クライアント装置２Ｂをパーティモードに復帰させる。従って時点ｔ２以降は、クライアント装置２Ｂを含めて全クライアント装置２に、コンテンツデータＣＴ−Ｂが配信されることになる。

このように第６の実施の形態では、パーティモードでの配信中に、或るクライアント装置２Ｂからの配信コンテンツの変更を求める変更要求ＲＱを受信した場合、当該変更要求ＲＱの送信元のクライアント装置２Ｂ以外のクライアント装置２に対する共通のコンテンツ配信は継続する。そして変更要求ＲＱの送信元のクライアント装置２Ｂのみに対して、変更要求ＲＱに応じたコンテンツデータを配信する。
また、変更要求ＲＱに応じたコンテンツデータの送信を終了した後は、変更要求ＲＱの送信元のクライアント装置２Ｂを、他のクライアント装置２と共通のコンテンツデータの配信先に復帰させる。

［７−２：サーバ・クライアントの機能構成］

このような動作を実現するためのコンテンツサーバ装置１の制御部１１の機能構成を図３３に示す。
図３３に示すコンテンツサーバ装置１の制御部１１は、機能構成として配信制御部４１、変更要求認識部４７、クライアント管理部４８を備える。

配信制御部４１は、パーティモードやオンデマンドモードでの配信動作を制御する機能部位である。配信制御部４１は、コンテンツ格納／再生部１２に対して、配信するコンテンツデータＣＴを指定して再生を実行させ、再生されたコンテンツデータＣＴを送信部１４から各クライアント装置２に配信させる制御を行う。
変更要求認識部４７は、受信部１５で受信されて制御部１１に供給されるクライアント装置２からの変更要求ＲＱを認識し、その情報、つまり送信元のクライアント装置２及び配信を求めるコンテンツデータＣＴの情報をクライアント管理部４８に伝える。

クライアント管理部４８は、クライアント装置２毎の配信モードを管理する。即ち各クライアント装置２について、パーティモードとしてのグループに入れているか、個別のオンデマンドモードとするかを設定する。そしてその各クライアント装置２のモードを配信制御部４１に伝える。具体的には、パーティモード配信先の各クライアント装置２と、オンデマンド配信先のクライアント装置２のＩＰアドレスの通知などを行う。
またクライアント管理部４８は、或るクライアント装置２に対してオンデマンドモードでの配信が終了した場合は、そのクライアント装置２をパーティモードに復帰させるよう配信制御部４１に指示する。

なお、クライアント装置２の制御部２１の機能構成は、第１の実施の形態の図８と同様になるため、説明を省略する。

［７−３：サーバ・クライアントの処理例］

この第６の実施の形態のコンテンツサーバ装置１の処理例を説明する。
図３４でコンテンツサーバ装置１の制御部１１（主に配信制御部４１）の処理例を示している。なお図９、図１４、図１９、図２５、図３０と同一の処理は同一のステップ番号を付している。ここではステップＦ１０１〜Ｆ１０５の説明は省略し、ステップＦ１０５でパーティモードでのコンテンツ配信が開始された後の処理を説明する。

パーティモードでの配信中には、制御部１１は、ステップＦ１０６での変更要求ＲＱの受信の監視、及びステップＦ１２０での配信終了トリガの監視を行う。
また特に、或るクライアント装置２に対してオンデマンドモード配信の実行中については、監視ループは、ステップＦ１５３からＦ１５４に進み、要求されたコンテンツデータＣＴの配信が終了したか否かを監視する。

制御部１１は、ステップＦ１０６で、上記変更要求認識部４７の機能で変更要求ＲＱの受信を検知した場合、ステップＦ１５１に進む。そして制御部１１は、クライアント管理部４８の機能により、変更要求ＲＱの送信元のクライアント装置２について、パーティモードから離脱させる処理を行う。
そして制御部１１はステップＦ１５２で、配信制御部４１の機能により、その離脱させたクライアント装置２に対して、要求されたコンテンツデータＣＴを配信を開始させる。
即ち制御部１１は、他のクライアント装置２に対するパーティモードでの配信のための再生動作及び送信動作を、コンテンツ格納／再生部１２，送信部１４に実行させつつ、さらに要求元のクライアント装置２に対するオンデマンド配信のための、コンテンツデータＣＴの再生及び送信を実行させる。これによって、図３２の時点ｔ１以降の配信動作が行われる。
そして制御部１１はステップＦ１０６からの監視ループに戻る。

オンデマンド配信実行中には、制御部１１はステップＦ１５４で要求されたコンテンツデータＣＴの配信終了を監視している。
要求されたコンテンツデータＣＴの配信が終了したら、制御部１１はステップＦ１５５に進み、オンデマンド配信先としていたクライアント装置２をパーティモードに復帰させる。これにより図３２の時点ｔ２以降のように、当該クライアント装置２を含めたパーティモード配信状態となる。
そして制御部１１はステップＦ１０６からの監視ループに戻る。

制御部１１は、ステップＦ１２０でパーティモードでの配信終了のトリガが検知された場合はステップＦ１２３に進み、パーティモードでの配信動作を終了する処理を行う。

なお、この第６の実施の形態の場合、クライアント装置２の処理は、第１の実施の形態で説明した図１０と同様となるため、説明を省略する。

上記図３４の処理をコンテンツサーバ装置１が行い、またクライアント装置２が図１０の処理を行うことで、図３２で説明した動作が実現される。
そしてこのような第６の実施の形態では、次の効果が得られる。

即ち第６の実施の形態では、パーティモードでの各部屋のコンテンツ配信を邪魔することなしに、コンテンツの変更要求ＲＱを行った部屋（クライアント装置２）の要求にも応じることができる。これにより、パーティモード配信を実行しながら、他人に全く迷惑を掛けずに、個々のユーザの要望に的確に答えることができる。
例えばパーティ中にあるアーテイストのあるコンテンツの話題になり、その部屋でそのコンテンツの視聴をしたい場合には、他の部屋の再生しているコンテンツを邪魔することなく、その部屋だけでそのコンテンツを視聴しながら会話を楽しむなどが可能となる。
さらにこの場合、複数のクライアント装置２からの変更要求ＲＱの錯綜などの無用な争いも生じない。

また、パーティモードから離脱したクライアント装置２に対する要求に応じたコンテンツＣＴの配信を終了した後は、自動的にパーティモードに復帰させる処理を行うことで、ユーザの操作負担もなく、パーティモード配信を適切に継続できる。

なお実施の形態では、クライアント装置２からの変更要求ＲＱに応じて、そのクライアント装置２をパーティモードから離脱させるものとしたが、クライアント装置２側でパーティモードとオンデマンドモードを選択できるようにしてもよい。
例えば図３５のように、各クライアント装置２において、パネル操作部２７に「On demand」と「Party」の操作キーを設け、ユーザが選択操作可能とする。
もちろん、１つのキーのトグル操作で交互にパーティモードとオンデマンドモードを切り換えるようにしてもよい。また表示部２７等に「On demand」と「Party」の操作アイコンを表示させ、タッチパネル操作等でユーザが選択可能としてもよい。またリモートコマンダー３の操作によるものとしても良い。

この場合、コンテンツサーバ装置１は、まずパーティモード動作として、コンテンツデータＣＴを各部屋に配信する。
パーティモードから離脱したい部屋（クライアント装置２）のユーザは、操作によりオンデマンドモードを選択する。クライアント装置２はその操作に応じてパーティモードでの受信／再生を中止し、パーティモードから一旦離脱する。その後オンデマンドモード下で所望のコンテンツ配信を要求するようにすればよい。
また、オンデマンドモード下で所望のコンテンツ配信を行っている最中に再びパーティモードに復帰したくなったら、ユーザは、操作によりパーティモードを指定することでパーティモードに復帰するようにしてもよい。

＜８．プログラム＞

本開示の実施の形態のプログラムは、コンテンツサーバ装置１の制御部１１（マイクロコンピュータ）に、図９、図１４、図１９、図２５、図３０、又は図３４の処理を実行させるプログラムである。
また実施の形態のプログラムは、クライアント装置２の制御部２１（マイクロコンピュータ）に図１０、図１５、図２０、図２６、又は図３１の処理を実行させるプログラムである。

これらのプログラムにより、上述した効果を得るコンテンツサーバ装置１、クライアント装置２を、特別な専用装置を用いずに実現できる。例えばパーソナルコンピュータ等を用いてコンテンツサーバ装置１、クライアント装置２を実現することもできる。
さらに、そのようなプログラムが記録されたプログラム記録媒体によれば、コンテンツ再生機器等において、実施の形態のコンテンツサーバ装置１、クライアント装置２を実現することも容易となる。

本実施の形態のプログラムは、パーソナルコンピュータや、撮像装置等の機器に内蔵されている記録媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭ等に予め記録しておくことができる。
あるいはまた、フレキシブルディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)、ＭＯ(Magnet optical)ディスク、ＤＶＤ(Digital Versatile Disc)、ブルーレイディスク（Blu-ray Disc：登録商標）、磁気ディスク、半導体メモリ、メモリカードなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、本開示のプログラムは、リムーバブル記録媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、ＬＡＮ(Local Area Network)、インターネットなどのネットワークを介してダウンロードすることもできる。

なお本技術は以下のような構成も採ることができる。
（１）ネットワーク通信が可能とされた複数のクライアント装置との間で通信を行う通信部と、
コンテンツデータの再生を行う再生部と、
上記再生部で再生されたコンテンツデータを上記通信部から各クライアント装置に対して共通に配信させるとともに、共通のコンテンツを配信中に、上記通信部によりクライアント装置からの配信コンテンツの変更を求める変更要求を受信した場合、或るクライアント装置からの当該受信を元に計数が開始される第１の期間内に他のクライアント装置からのさらなる変更要求の受信状況を確認し、上記第１の期間内における変更要求の受信状況に応じて上記第１の期間の経過後の処理を決定する制御部と、
を備えたサーバ装置。
（２）上記制御部は、上記第１の期間内に所定数以上の変更要求を検知した場合、上記第１の期間の経過後に計数が開始される第２の期間は、受信される変更要求を無効とする処理を行う上記（１）に記載のサーバ装置。
（３）上記制御部は、上記第１の期間内に所定数以上の変更要求を検知した場合、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止信号を送信させる上記（１）又は（２）に記載のサーバ装置。
（４）上記制御部は、上記第１の期間内に所定数以上の変更要求を検知した場合、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止信号を送信させ、さらに、上記第１の期間の経過後に計数が開始される第２の期間の経過後、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止解除信号を送信させる上記（１）乃至（３）のいずれかに記載のサーバ装置。
（５）上記制御部は、上記第１の期間の経過時点までに受信された有効な変更要求を決定し、該有効な変更要求に関するコンテンツデータを再生するよう上記再生部を制御し、各々のクライアント装置に再生されたコンテンツデータを送信するよう上記送信部を制御する上記（１）乃至（４）のいずれかに記載のサーバ装置。
（６）上記制御部は、上記第１の期間内に所定数以上の変更要求を検知した場合、上記第１の期間の開始前に配信していたコンテンツデータ配信を継続するように上記再生部を制御し、上記通信部から各クライアント装置に対して送信するように上記通信部を制御する上記（５）に記載のサーバ装置。
（７）上記制御部は、上記第１の期間の経過までに受信された変更要求に対しては、その変更要求に応じた配信コンテンツの変更制御は行わない上記（１）乃至（６）のいずれかに記載のサーバ装置。
（８）上記制御部は、上記第１の期間内に所定数以上の変更要求を検知した場合、上記第１の期間の経過後も、上記第１の期間内に検知した変更要求に応じた配信コンテンツの変更制御は行わない上記（７）に記載のサーバ装置。
（９）上記制御部は、上記第１の期間内に所定数未満の変更要求を検知した場合、上記第１の期間の経過後は、上記第１の期間内に最後に検知した変更要求に応じたコンテンツデータを再生するよう上記再生部を制御し、上記通信部から各クライアント装置に対して送信するよう上記通信部を制御する上記（７）又は（８）に記載のサーバ装置。
（１０）上記制御部は、上記第１の期間の経過時点までにおける変更要求の受信に対応して、該変更要求を告知する告知信号を、上記通信部から全部又は一部のクライアント装置に対して送信させる上記（７）乃至（１０）のいずれかに記載のサーバ装置。
（１１）上記制御部は、上記第１の期間内に、上記告知信号の送信後、上記通信部によりクライアント装置からの賛否情報信号が受信されることに応じて、賛否情報の集計処理を行い、該集計処理結果に基づいて、上記第１の期間の経過後の配信コンテンツを決定する上記（１０）に記載のサーバ装置。

１ コンテンツサーバ装置、２ クライアント装置、３ リモートコマンダー、４ ネットワーク、１１ 制御部、１２ コンテンツ格納／再生部、１３ メモリ部、１４ 送信部、１５ 受信部、２１ 制御部、２２ 再生処理部、２３ メモリ部、２４ 送信部、２５ 受信部、２６ 出力デバイス、２７ パネル操作部、２８ コマンド受信部、２９ 表示部

Claims (19)

1. ネットワーク通信が可能とされた複数のクライアント装置との間で通信を行う通信部と、
   コンテンツデータの再生を行う再生部と、
   上記再生部で再生されたコンテンツデータを上記通信部から各クライアント装置に対して共通に配信させるとともに、共通のコンテンツを配信中に、上記通信部によりクライアント装置からの配信コンテンツの変更を求める変更要求を受信した場合、或るクライアント装置からの当該受信を元に計数が開始される第１の期間内に他のクライアント装置からのさらなる変更要求の受信状況を確認し、上記第１の期間内における変更要求の受信状況に応じて上記第１の期間の経過後の処理を決定する制御部と、
   を備えたサーバ装置。
2. 上記制御部は、上記第１の期間内に所定数以上の変更要求を検知した場合、上記第１の期間の経過後に計数が開始される第２の期間は、受信される変更要求を無効とする処理を行う請求項１に記載のサーバ装置。
3. 上記制御部は、上記第１の期間内に所定数以上の変更要求を検知した場合、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止信号を送信させる請求項１に記載のサーバ装置。
4. 上記制御部は、上記第１の期間内に所定数以上の変更要求を検知した場合、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止信号を送信させ、さらに、上記第１の期間の経過後に計数が開始される第２の期間の経過後、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止解除信号を送信させる請求項１に記載のサーバ装置。
5. 上記制御部は、上記第１の期間の経過時点までに受信された有効な変更要求を決定し、該有効な変更要求に関するコンテンツデータを再生するよう上記再生部を制御し、各々のクライアント装置に再生されたコンテンツデータを送信するよう上記送信部を制御する請求項１に記載のサーバ装置。
6. 上記制御部は、上記第１の期間内に所定数以上の変更要求を検知した場合、上記第１の期間の開始前に配信していたコンテンツデータ配信を継続するように上記再生部を制御し、上記通信部から各クライアント装置に対して送信するように上記通信部を制御する請求項５に記載のサーバ装置。
7. 上記制御部は、上記第１の期間の経過までに受信された変更要求に対しては、その変更要求に応じた配信コンテンツの変更制御は行わない請求項１に記載のサーバ装置。
8. 上記制御部は、上記第１の期間内に所定数以上の変更要求を検知した場合、上記第１の期間の経過後も、上記第１の期間内に検知した変更要求に応じた配信コンテンツの変更制御は行わない請求項７に記載のサーバ装置。
9. 上記制御部は、上記第１の期間内に所定数未満の変更要求を検知した場合、上記第１の期間の経過後は、上記第１の期間内に最後に検知した変更要求に応じたコンテンツデータを再生するよう上記再生部を制御し、上記通信部から各クライアント装置に対して送信するよう上記通信部を制御する請求項７に記載のサーバ装置。
10. 上記制御部は、上記第１の期間の経過時点までにおける変更要求の受信に対応して、該変更要求を告知する告知信号を、上記通信部から全部又は一部のクライアント装置に対して送信させる請求項７に記載のサーバ装置。
11. 上記制御部は、上記第１の期間内に、上記告知信号の送信後、上記通信部によりクライアント装置からの賛否情報信号が受信されることに応じて、賛否情報の集計処理を行い、該集計処理結果に基づいて、上記第１の期間の経過後の配信コンテンツを決定する請求項１０に記載のサーバ装置。
12. ネットワーク通信が可能とされた複数のクライアント装置との間で通信を行う通信部と、
    コンテンツデータの再生を行う再生部と、
    上記再生部で再生された共通のコンテンツデータを上記通信部から各クライアント装置に対し共通に配信させるとともに、共通のコンテンツデータ配信中に、或るクライアント装置からの変更要求に応じて、共通のコンテンツデータと変更要求に応じたコンテンツデータを両方とも再生するよう上記再生部を制御し、上記或るクライアント装置からの変更要求のみに応じて上記変更要求に応じたコンテンツデータを送信するとともに、該或るクライアント装置以外の他のクライアント装置に上記共通のコンテンツデータを送信するよう上記通信部を制御する制御部と、
    を備えたサーバ装置。
13. 上記或るクライアント装置への上記変更要求に応じたコンテンツデータの送信が終了した場合に、上記制御部は、上記或るクライアント装置を含めた全てのクライアント装置への共通のコンテンツデータの配信に復帰するよう上記再生部を制御する請求項１２に記載のサーバ装置。
14. ネットワーク通信が可能とされたサーバ装置との間で通信を行う通信部と、
    上記サーバ装置から配信され上記通信部で受信したコンテンツデータの再生処理を行う再生処理部と、
    ユーザ操作に応じて、配信コンテンツの変更を求める変更要求を、上記通信部から上記サーバ装置に送信させるとともに、上記サーバ装置からの送信禁止信号を受信した場合は、該受信後に計数が開始される所定期間、ユーザ操作に応じた変更要求の送信処理を実行しない制御部と、
    を備えたクライアント装置。
15. ネットワーク通信が可能とされたサーバ装置との間で通信を行う通信部と、
    上記サーバ装置から配信され上記通信部で受信したコンテンツデータの再生処理を行う再生処理部と、
    ユーザ操作に応じて、配信コンテンツの変更を求める変更要求を上記通信部から上記サーバ装置に送信させる処理と、他のクライアント装置からの変更要求を告知する告知信号を上記サーバ装置から受信したときに上記告知信号の内容を提示する処理と、ユーザ操作に応じて、上記告知信号の内容に関する賛否情報を示した賛否情報信号を上記通信部から上記サーバ装置に送信させる処理と、を行う制御部と、
    を備えたクライアント装置。
16. サーバ装置と、複数のクライアント装置とがネットワーク通信可能とされた配信システムにおける上記サーバ装置の配信方法として、
    再生したコンテンツデータを各クライアント装置に対して共通に配信するステップと、
    上記共通のコンテンツ配信中に、クライアント装置からの配信コンテンツの変更を求める変更要求を受信したことに応じて、クライアント装置からの当該受信を元に計数を開始する所定期間内にさらなる変更要求の受信状況を確認するステップと、
    上記所定期間内における変更要求の受信状況に応じて上記所定期間の経過後の処理を決定するステップと、
    を備えた配信方法。
17. サーバ装置と、複数のクライアント装置とがネットワーク通信可能とされた配信システムにおける上記サーバ装置の配信方法として、
    再生したコンテンツデータを各クライアント装置に対して共通に配信するステップと、
    配信コンテンツの変更を求めるために使用される変更要求が、共通配信中に、クライアント装置のうちの一つから受信された場合に、共通配信コンテンツデータの再生を継続している間、変更要求に応じてコンテンツデータを再生し、クライアント装置のうちの一つからの変更要求に応じてコンテンツデータを送信すると同時に、共通配信コンテンツデータをその他のクライアント装置に送信するステップと、
    を備えた配信方法。
18. 再生したコンテンツデータをネットワーク通信可能とされた各クライアント装置に対して共通に配信するステップと、
    上記共通のコンテンツ配信中に、クライアント装置からの配信コンテンツの変更を求める変更要求を受信したことに応じて、クライアント装置からの当該受信を元に計数を開始する所定期間内にさらなる変更要求の受信状況を確認するステップと、
    上記所定期間内における変更要求の受信状況に応じて上記所定期間の経過後の処理を決定するステップと、
    を演算処理装置に実行させるプログラム。
19. 再生したコンテンツデータをネットワーク通信可能とされた各クライアント装置に対して共通に配信するステップと、
    配信コンテンツの変更を求めるために使用される変更要求が、共通配信中に、クライアント装置のうちの一つから受信された場合に、共通配信コンテンツデータの再生を継続している間、変更要求に応じてコンテンツデータを再生し、クライアント装置のうちの一つからの変更要求に応じてコンテンツデータを送信すると同時に、共通配信コンテンツデータをその他のクライアント装置に送信するステップと、
    を演算処理装置に実行させるプログラム。

Images