"ネットワーク通信が可能とされた複数のクライアント装置との間で通信を行う通信部と、コンテンツデータの再生を行う再生部と、上記再生部で再生されたコンテンツデータを上記通信部から各クライアント装置に対して共通に配信させるとともに、共通のコンテンツを配信中に、上記通信部によりクライアント装置からの配信コンテンツの変更を求める変更要求を受信した場合、或るクライアント装置からの当該受信を元に計数が開始される第1の期間内に他のクライアント装置からのさらなる変更要求の受信状況を確認し、上記第1の期間内における変更要求の受信状況に応じて上記第1の期間の経過後の処理を決定する制御部と、を備えたサーバ装置。上記制御部は、上記第1の期間内に所定数以上の変更要求を検知した場合、上記第1の期間の経過後に計数が開始される第2の期間は、受信される変更要求を無効とする処理を行う請求項1に記載のサーバ装置。上記制御部は、上記第1の期間内に所定数以上の変更要求を検知した場合、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止信号を送信させる請求項1に記載のサーバ装置。上記制御部は、上記第1の期間内に所定数以上の変更要求を検知した場合、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止信号を送信させ、さらに、上記第1の期間の経過後に計数が開始される第2の期間の経過後、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止解除信号を送信させる請求項1に記載のサーバ装置。上記制御部は、上記第1の期間の経過時点までに受信された有効な変更要求を決定し、該有効な変更要求に関するコンテンツデータを再生するよう上記再生部を制御し、各々のクライアント装置に再生されたコンテンツデータを送信するよう上記送信部を制御する請求項1に記載のサーバ装置。上記制御部は、上記第1の期間内に所定数以上の変更要求を検知した場合、上記第1の期間の開始前に配信していたコンテンツデータ配信を継続するように上記再生部を制御し、上記通信部から各クライアント装置に対して送信するように上記通信部を制御する請求項5に記載のサーバ装置。上記制御部は、上記第1の期間の経過までに受信された変更要求に対しては、その変更要求に応じた配信コンテンツの変更制御は行わない請求項1に記載のサーバ装置。上記制御部は、上記第1の期間内に所定数以上の変更要求を検知した場合、上記第1の期間の経過後も、上記第1の期間内に検知した変更要求に応じた配信コンテンツの変更制御は行わない請求項7に記載のサーバ装置。上記制御部は、上記第1の期間内に所定数未満の変更要求を検知した場合、上記第1の期間の経過後は、上記第1の期間内に最後に検知した変更要求に応じたコンテンツデータを再生するよう上記再生部を制御し、上記通信部から各クライアント装置に対して送信するよう上記通信部を制御する請求項7に記載のサーバ装置。上記制御部は、上記第1の期間の経過時点までにおける変更要求の受信に対応して、該変更要求を告知する告知信号を、上記通信部から全部又は一部のクライアント装置に対して送信させる請求項7に記載のサーバ装置。上記制御部は、上記第1の期間内に、上記告知信号の送信後、上記通信部によりクライアント装置からの賛否情報信号が受信されることに応じて、賛否情報の集計処理を行い、該集計処理結果に基づいて、上記第1の期間の経過後の配信コンテンツを決定する請求項10に記載のサーバ装置。ネットワーク通信が可能とされた複数のクライアント装置との間で通信を行う通信部と、コンテンツデータの再生を行う再生部と、上記再生部で再生された共通のコンテンツデータを上記通信部から各クライアント装置に対し共通に配信させるとともに、共通のコンテンツデータ配信中に、或るクライアント装置からの変更要求に応じて、共通のコンテンツデータと変更要求に応じたコンテンツデータを両方とも再生するよう上記再生部を制御し、上記或るクライアント装置からの変更要求のみに応じて上記変更要求に応じたコンテンツデータを送信するとともに、該或るクライアント装置以外の他のクライアント装置に上記共通のコンテンツデータを送信するよう上記通信部を制御する制御部と、を備えたサーバ装置。上記或るクライアント装置への上記変更要求に応じたコンテンツデータの送信が終了した場合に、上記制御部は、上記或るクライアント装置を含めた全てのクライアント装置への共通のコンテンツデータの配信に復帰するよう上記再生部を制御する請求項12に記載のサーバ装置。ネットワーク通信が可能とされたサーバ装置との間で通信を行う通信部と、上記サーバ装置から配信され上記通信部で受信したコンテンツデータの再生処理を行う再生処理部と、ユーザ操作に応じて、配信コンテンツの変更を求める変更要求を、上記通信部から上記サーバ装置に送信させるとともに、上記サーバ装置からの送信禁止信号を受信した場合は、該受信後に計数が開始される所定期間、ユーザ操作に応じた変更要求の送信処理を実行しない制御部と、を備えたクライアント装置。ネットワーク通信が可能とされたサーバ装置との間で通信を行う通信部と、上記サーバ装置から配信され上記通信部で受信したコンテンツデータの再生処理を行う再生処理部と、ユーザ操作に応じて、配信コンテンツの変更を求める変更要求を上記通信部から上記サーバ装置に送信させる処理と、他のクライアント装置からの変更要求を告知する告知信号を上記サーバ装置から受信したときに上記告知信号の内容を提示する処理と、ユーザ操作に応じて、上記告知信号の内容に関する賛否情報を示した賛否情報信号を上記通信部から上記サーバ装置に送信させる処理と、を行う制御部と、を備えたクライアント装置。サーバ装置と、複数のクライアント装置とがネットワーク通信可能とされた配信システムにおける上記サーバ装置の配信方法として、再生したコンテンツデータを各クライアント装置に対して共通に配信するステップと、上記共通のコンテンツ配信中に、クライアント装置からの配信コンテンツの変更を求める変更要求を受信したことに応じて、クライアント装置からの当該受信を元に計数を開始する所定期間内にさらなる変更要求の受信状況を確認するステップと、上記所定期間内における変更要求の受信状況に応じて上記所定期間の経過後の処理を決定するステップと、を備えた配信方法。サーバ装置と、複数のクライアント装置とがネットワーク通信可能とされた配信システムにおける上記サーバ装置の配信方法として、再生したコンテンツデータを各クライアント装置に対して共通に配信するステップと、配信コンテンツの変更を求めるために使用される変更要求が、共通配信中に、クライアント装置のうちの一つから受信された場合に、共通配信コンテンツデータの再生を継続している間、変更要求に応じてコンテンツデータを再生し、クライアント装置のうちの一つからの変更要求に応じてコンテンツデータを送信すると同時に、共通配信コンテンツデータをその他のクライアント装置に送信するステップと、を備えた配信方法。再生したコンテンツデータをネットワーク通信可能とされた各クライアント装置に対して共通に配信するステップと、上記共通のコンテンツ配信中に、クライアント装置からの配信コンテンツの変更を求める変更要求を受信したことに応じて、クライアント装置からの当該受信を元に計数を開始する所定期間内にさらなる変更要求の受信状況を確認するステップと、上記所定期間内における変更要求の受信状況に応じて上記所定期間の経過後の処理を決定するステップと、を演算処理装置に実行させるプログラム。再生したコンテンツデータをネットワーク通信可能とされた各クライアント装置に対して共通に配信するステップと、配信コンテンツの変更を求めるために使用される変更要求が、共通配信中に、クライアント装置のうちの一つから受信された場合に、共通配信コンテンツデータの再生を継続している間、変更要求に応じてコンテンツデータを再生し、クライアント装置のうちの一つからの変更要求に応じてコンテンツデータを送信すると同時に、共通配信コンテンツデータをその他のクライアント装置に送信するステップと、を演算処理装置に実行させるプログラム。ところで、パーティモードの場合にも、クライアント装置からの操作による要求を受け付けるようにすることが考えられる。例えば音楽コンテンツをパーティモードで配信する場合を例に挙げる。ユーザにとっては、単に配信されている音楽をBGMバックグラウンドミュージックとして聴くだけでなく、会話の流れ、或いは聴いている音楽からの連想等で、積極的に他の曲を聴きたいと思うこともある。そのような場合、その人の居る部屋のクライアント装置に対して操作入力を行い、他の曲をリクエスト配信コンテンツの変更要求することができると好適である。ところが、各クライアント装置で、同時期にコンテンツ変更要求が行われ、その都度、全体に配信されている音楽が度々切り換えられると、他の部屋の人は、気が散ったり、不快に感じたりすることがある。さらには、曲を元に戻す操作を行う者、或いはさらに他の曲を要求する者などが現れることもあり、いわゆるチャンネル争いのように、続けて変更要求が行われてしまうことも懸念される。つまり、操作者以外の人他の部屋に居る人にとっては、例えばBGM的に流れている音楽が、曲の途中でどんどん切り替わってしまい、その結果気が散ってしまいパーティを楽しめなかったり会話に集中できなかったりする。また、流れている音楽を聞きながらその演奏者を話題に会話を楽しんでいる最中に全然関係ない別な曲に切り替わってしまうと、折角の会話も台無しになってしまい、結果的にしらけてしまうということもある。このような状態を解決するひとつの方法として、上記特許文献1では、複数のサブユニットクライアント装置に相当の中から特定のサブユニットに対して優先権を与え、これにより結果的にチャンネル争いが発生しても優先権が与えられていない他のサブユニットからの要求は排他的に処理する内容が開示されている。また上記特許文献2では、ネットワークに接続されている機器に対して複数のリモコンから同時にコマンドが送信された場合に、排他的な処理をするもの開示されている。しかし、所定のクライアント装置に優先権を与え、他のクライアント装置からの制御を排他的にすることでチャンネル争いを回避はできるものの、配信するコンテンツの変更を他のクライアント装置からはできなくなる。この場合、別の部屋にいるユーザがコンテンツ変更を希望する場合には、一々優先権の与えられているクライアント装置が設置されている部屋に行って操作を行わなければならないという煩わしさがある。また、優先権を与える場合に何を規準にどのクライアント装置に優先権を与えればいいかの判断が、パーティモード動作を行う家庭内ネットワークにおいては困難である。そこで本開示では、家庭内ネットワークシステムで、上記のパーティモードの配信動作を行う場合に、各クライアント装置からコンテンツ変更要求を可能とする。その上で、変更要求の錯綜短期間内での多数の変更要求の発生に適切に対処できるようにしたり、或いは錯綜の悪影響が生じないようにすることを目的とする。本開示のサーバ装置は、ネットワーク通信が可能とされた複数のクライアント装置との間で通信を行う通信部と、コンテンツデータの再生を行う再生部と、上記再生部で再生されたコンテンツデータを上記通信部から各クライアント装置に対して共通に配信させるとともに、共通のコンテンツを配信中に、上記通信部によりクライアント装置からの配信コンテンツの変更を求める変更要求を受信した場合、或るクライアント装置からの当該受信を元に計数が開始される第1の期間内に他のクライアント装置からのさらなる変更要求の受信状況を確認し、上記第1の期間内における変更要求の受信状況に応じて上記第1の期間の経過後の処理を決定する制御部とを備える。また、上記制御部は、上記第1の期間内に所定数以上の変更要求を検知した場合、上記第1の期間の経過後に計数が開始される第2の期間は、受信される変更要求を無効とする処理を行う。或いは、上記制御部は、上記第1の期間内に所定数以上の変更要求を検知した場合、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止信号を送信させる。或いは、上記制御部は、上記第1の期間内に所定数以上の変更要求を検知した場合、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止信号を送信させ、さらに、上記第1の期間の経過後に計数が開始される第2の期間の経過後、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止解除信号を送信させる。また、上記制御部は、上記第1の期間の経過時点までに受信された有効な変更要求を決定し、該有効な変更要求に関するコンテンツデータを再生するよう上記再生部を制御し、各々のクライアント装置に再生されたコンテンツデータを送信するよう上記送信部を制御する。そして上記制御部は、上記第1の期間内に所定数以上の変更要求を検知した場合、上記第1の期間の開始前に配信していたコンテンツデータ配信を継続するように上記再生部を制御し、上記通信部から各クライアント装置に対して送信するように上記通信部を制御する。また上記制御部は、上記第1の期間の経過までに受信された変更要求に対しては、その変更要求に応じた配信コンテンツの変更制御は行わない。そして上記制御部は、上記第1の期間内に所定数以上の変更要求を検知した場合、上記第1の期間の経過後も、上記第1の期間内に検知した変更要求に応じた配信コンテンツの変更制御は行わない。一方、上記制御部は、上記第1の期間内に所定数未満の変更要求を検知した場合、上記第1の期間の経過後は、上記第1の期間内に最後に検知した変更要求に応じたコンテンツデータを再生するよう上記再生部を制御し、上記通信部から各クライアント装置に対して送信するよう上記通信部を制御する。また上記制御部は、上記第1の期間の経過時点までにおける変更要求の受信に対応して、該変更要求を告知する告知信号を、上記通信部から全部又は一部のクライアント装置に対して送信させる。また上記制御部は、上記第1の期間内に、上記告知信号の送信後、上記通信部によりクライアント装置からの賛否情報信号が受信されることに応じて、賛否情報の集計処理を行い、該集計処理結果に基づいて、上記第1の期間の経過後の配信コンテンツを決定する。本開示の他のサーバ装置は、ネットワーク通信が可能とされた複数のクライアント装置との間で通信を行う通信部と、コンテンツデータの再生を行う再生部と、上記再生部で再生された共通のコンテンツデータを上記通信部から各クライアント装置に対し共通に配信させるとともに、共通のコンテンツデータ配信中に、或るクライアント装置からの変更要求に応じて、共通のコンテンツデータと変更要求に応じたコンテンツデータを両方とも再生するよう上記再生部を制御し、上記或るクライアント装置からの変更要求のみに応じて上記変更要求に応じたコンテンツデータを送信するとともに、該或るクライアント装置以外の他のクライアント装置に上記共通のコンテンツデータを送信するよう上記通信部を制御する制御部とを備える。また上記或るクライアント装置への上記変更要求に応じたコンテンツデータの送信が終了した場合に、上記制御部は、上記或るクライアント装置を含めた全てのクライアント装置への共通のコンテンツデータの配信に復帰するよう上記再生部を制御する。本開示のクライアント装置は、ネットワーク通信が可能とされたサーバ装置との間で通信を行う通信部と、上記サーバ装置から配信され上記通信部で受信したコンテンツデータの再生処理を行う再生処理部と、ユーザ操作に応じて、配信コンテンツの変更を求める変更要求を、上記通信部から上記サーバ装置に送信させるとともに、上記サーバ装置からの送信禁止信号を受信した場合は、該受信後に計数が開始される所定期間、ユーザ操作に応じた変更要求の送信処理を実行しない制御部とを備える。また本開示の他のクライアント装置は、ネットワーク通信が可能とされたサーバ装置との間で通信を行う通信部と、上記サーバ装置から配信され上記通信部で受信したコンテンツデータの再生処理を行う再生処理部と、ユーザ操作に応じて、配信コンテンツの変更を求める変更要求を上記通信部から上記サーバ装置に送信させる処理と、他のクライアント装置からの変更要求を告知する告知信号を上記サーバ装置から受信したときに上記告知信号の内容を提示する処理と、ユーザ操作に応じて、上記告知信号の内容に関する賛否情報を示した賛否情報信号を上記通信部から上記サーバ装置に送信させる処理と、を行う制御部とを備える。本開示の配信方法は、サーバ装置と、複数のクライアント装置とがネットワーク通信可能とされた配信システムにおける上記サーバ装置の配信方法として、再生したコンテンツデータを各クライアント装置に対して共通に配信するステップと、上記共通のコンテンツ配信中に、クライアント装置からの配信コンテンツの変更を求める変更要求を受信したことに応じて、クライアント装置からの当該受信を元に計数を開始する所定期間内にさらなる変更要求の受信状況を確認するステップと、上記所定期間内における変更要求の受信状況に応じて上記所定期間の経過後の処理を決定するステップとを備える。本開示のプログラムは、上記各ステップを演算処理装置に実行させる。また本開示の他の配信方法は、サーバ装置と、複数のクライアント装置とがネットワーク通信可能とされた配信システムにおける上記サーバ装置の配信方法として、再生したコンテンツデータを各クライアント装置に対して共通に配信するステップと、配信コンテンツの変更を求めるために使用される変更要求が、共通配信中に、クライアント装置のうちの一つから受信された場合に、共通配信コンテンツデータの再生を継続している間、変更要求に応じてコンテンツデータを再生し、クライアント装置のうちの一つからの変更要求に応じてコンテンツデータを送信すると同時に、共通配信コンテンツデータをその他のクライアント装置に送信するステップとを備える。本開示の他のプログラムは、上記各ステップを演算処理装置に実行させる。これらの本開示では、サーバ装置は、クライアント装置からの配信コンテンツの変更要求が、所定期間第1の期間内に、所定数以上、発生したか否かを確認し、それによって変更要求の錯綜が生じる状況の有無を判断する。そして、例えば変更要求の錯綜が生じた場合は、例えば所定期間第2の期間に、変更要求を無効化する処理等を行い、パーティモードとして全体に流れる音楽等のむやみな変更が行われないようにする。或いは、そもそも変更要求の錯綜の悪影響が生じないようにするため、変更要求があった場合、そのクライアント装置を、パーティモードから離脱させ、そのクライアント装置にのみ、オンデマンドモードのような配信を行う。これにより、他のクライアント装置による配信出力を視聴しているユーザに影響が生じないようにする。本開示によれば、家庭内ネットワークシステム等におけるパーティモードの動作、つまり各クライアント装置に共通のコンテンツデータを配信する際に適切な動作が実現される。まず、各クライアント装置からの配信コンテンツ変更要求を受け付けることが可能であるため、各ユーザは、パーティモード動作中でも、見聞きしたいコンテンツの配信を要求できる。その上で、複数の変更要求が錯綜した場合でも、他のユーザの雰囲気を害するようなむやみなコンテンツの変更は行われず、パーティモード動作として適切な配信が可能となる。或いは、変更要求を行ったクライアント装置に対してのみ、配信コンテンツを変更することでも、他のユーザに対する悪影響を与えない、パーティモード動作として適切な配信が可能となる。以下、本開示の実施の形態を次の順序で説明する。<1.実施の形態の家庭内ネットワークシステムの構成>[1-1:システム構成][1-2:コンテンツサーバ装置][1-3:クライアント装置][1-4:サーバクライアント兼用装置]<2.第1の実施の形態>[2-1:動作概要][2-2:サーバクライアントの機能構成][2-3:サーバクライアントの処理例]<3.第2の実施の形態>[3-1:動作概要][3-2:サーバクライアントの機能構成][3-3:サーバクライアントの処理例]<4.第3の実施の形態>[4-1:動作概要][4-2:サーバクライアントの機能構成][4-3:サーバクライアントの処理例]<5.第4の実施の形態>[5-1:動作概要][5-2:サーバクライアントの機能構成][5-3:サーバクライアントの処理例]<6.第5の実施の形態>[6-1:動作概要][6-2:サーバクライアントの機能構成][6-3:サーバクライアントの処理例]<7.第6の実施の形態>[7-1:動作概要][7-2:サーバクライアントの機能構成][7-3:サーバクライアントの処理例]<8.プログラム><1.実施の形態の家庭内ネットワークシステムの構成>[1-1:システム構成]まず、実施の形態の家庭内ネットワークシステムの構成を図1で説明する。図1では、或る家屋において、ルームR0からルームR3の4部屋で、家庭内ネットワークシステムを使用する例を示している。ここで家庭内ネットワークシステムと呼んでいるが、もちろん本例のシステムが使用される場所は家庭に限られない。例えば会社、学校、公共施設などでも使用可能である。また、必ずしも同一の建物内の部屋でなくとも、敷地内の庭、ガレージ、倉庫など、屋外や別の建物内も、ここでいうルームと考えて良い。つまり本例の場合、パーティモードとして同一の音楽コンテンツや映像コンテンツを、各ルームで視聴できるように配信するものであるが、同一のコンテンツを配信する先のルームは多様に考えられる。但し、インターネット等の公衆ネットワークで実行されるような広い範囲での配信ではなく、或る程度狭い範囲での配信を行うシステムと考えることが適切である。実施の形態の家庭内ネットワークシステムは、1以上のコンテンツサーバ装置1と、少なくとも2以上の複数のクライアント装置2がネットワーク4を介して相互に通信可能に構成される。図1の例では、コンテンツサーバ装置1はルームR0に設置されているとしている。またクライアント装置2が、ルームR0~R3のそれぞれに配置されている。コンテンツサーバ装置1は、オーデイオ/ビデオ/テキスト/ゲームなどのコンテンツデータを、ネットワーク4を介して各クライアント装置2に配信できる。例えばコンテンツサーバ装置1は、コンテンツデータを、ハードデイスクドライブHDD、フラッシュメモリ、複数毎の光デイスク、例えばCDCompactDisc,DVDDigitalVersatileDisc、BDBlurayDisc登録商標等を収納した交換型光デイスクプレーヤなどから再生する。そして再生したコンテンツデータを、各クライアント装置2に配信する。各クライアント装置2は、一体又は別体の出力デバイスとして、モニタディスプレイやスピーカ等を備える。そして、ネットワーク4を介して配信されてくるコンテンツデータを受信し、出力デバイスから映像や音声として出力する。これにより、各ルームR0~R3に居るユーザは、配信されてくるコンテンツデータを見聞きすることができる。また、例えば各クライアント装置2に対しては、そのクライアント装置2の筐体上の操作ボタン、モニタ上で操作するタッチパネル部、或いは図示するリモートコマンダー3などが用意されており、ユーザは操作入力が可能とされる。ユーザによる操作入力の情報は、ネットワーク4を介してコンテンツサーバ装置1に送信される。この操作入力により、ユーザは、後述するコンテンツ変更要求等の操作を行うことができる。ネットワーク4は、例えば家庭内の通信が可能とされる有線又は無線の伝送路により構成される。例えば有線の場合、電灯線、テレビ用RFケーブル、DLNADigitalLivingNetworkAlliance、HDMIHighDefinitionMultimediaInterfaceなどが考えられる。また無線の場合、IEEE1394.11a,b,n、ブルートゥースBluetooth、2.4GHz帯を用いた他の通信方式などが考えられる。この家庭内ネットワークシステムでは、コンテンツサーバ装置1は、オンデマンドモードでの配信と、パーティモードでの配信が可能とされる。上述したようにオンデマンドモードとは、各クライアント装置2に対して個別に、要求に応じたコンテンツデータを配信するモードである。一方パーティモードは、全クライアント装置2に対し、共通のコンテンツデータを同時的に配信するモードである。[1-2:コンテンツサーバ装置]コンテンツサーバ装置1の構成例を図2で説明する。コンテンツサーバ装置1は、制御部11,コンテンツ格納/再生部12,メモリ部13,送信部14,受信部15を備える。制御部11は、CPU、ROMReadOnlyMemory、RAMRandomAccessMemory等を備えたマイクロコンピュータにより構成される。制御部11内のROMには、例えばCPUが実行すべきプログラムの他、配信動作のための各種の設定情報などが記憶される。RAMは、CPUのための主記憶装置部とされる。この制御部11は、コンテンツサーバ装置1としての動作全体を制御する。即ちパーティモード及びオンデマンドモードでの配信動作のため、コンテンツ格納/再生部12での再生動作制御、送信部14からのコンテンツデータCT等の送信制御、受信部15で受信した、クライアント装置2からの変更要求RQ等に対する対応処理などを行う。メモリ部13は、RAM、ROM、フラッシュメモリなどの記憶部を総括的に示している。このメモリ部13は制御部11の処理のワーク領域として用いられたり、プログラムの格納領域として用いられても良い。また配信動作のための各種の設定情報、パラメータ等を記憶することにも用いられる。またメモリ部13は、配信のためにコンテンツ格納/再生部12で再生されたコンテンツデータの送信バッファとしても用いられることもある。コンテンツ格納/再生部12は、各種コンテンツデータCTを再生することができる装置部である。コンテンツデータCTは、例えばハードディスク、フラッシュメモリ、光ディスクなどに格納されている。コンテンツ格納/再生部12は、制御部11の指示に基づき、これらの記憶媒体からのコンテンツデータCTの再生を行う。従って、コンテンツ格納/再生部12は、例えばHDD、フラッシュメモリプレーヤ、光ディスクプレーヤ、交換型光デイスクプレーヤなどとして実現される。送信部14及び受信部15は、ネットワーク4を介した各クライアント装置2との間での通信部として機能する。送信部14は、制御部11の制御に基づき、主にコンテンツ格納/再生部12で再生されたコンテンツデータCTについて所定のエンコードを行い、ネットワーク送信、つまり各クライアント装置2への配信を行う。また受信部15は、各クライアント装置2から送信されてくる信号、例えば配信するコンテンツデータCTの変更を求める変更要求RQ等の信号の受信を行う。そして受信した信号をデコードし、受信情報内容を制御部11に伝達する。このような処理を行うため、送信部14及び受信部15は、ネットワーク4での有線又は無線での通信方式に対応したエンコード、デコード、及び送受信処理を行う。なお、図2では示していないが、コンテンツサーバ装置1についてユーザが入力を行うための操作部や、対応するリモートコマンダーからのコマンド受信部等が設けられても良い。或いは、コンテンツサーバ装置1への操作入力は、クライアント装置2に対する入力としてユーザが実行できるようにし、クライアント装置2からコンテンツサーバ装置1自体に対する操作情報が供給されるようにしてもよい。また本実施の形態では、オンデマンドモードとパーティモードで配信が可能とされるが、これらのモード選択の操作も、コンテンツサーバ装置1に設けられた操作子で操作したり、或いは後述するクライアント装置2からの操作入力により行うことができるようにしてもよい。[1-3:クライアント装置]続いてクライアント装置2の構成を図3で説明する。クライアント装置2は、制御部21,再生処理部22、メモリ部23、送信部24、受信部25、出力デバイス26、パネル操作部27、コマンド受信部28、表示部29を備える。制御部21は、CPU、ROM、RAM等を備えたマイクロコンピュータにより構成される。制御部21内のROMには、例えばCPUが実行すべきプログラムの他、配信コンテンツの再生動作やコンテンツサーバ装置1との通信動作等のための各種の設定情報などが記憶される。RAMは、CPUのための主記憶装置部とされる。この制御部21は、クライアント装置2としての動作全体を制御する。即ちパーティモード及びオンデマンドモードでの配信において、コンテンツデータCT等の受信制御や、ユーザの操作に応じた変更要求RQ等の送信制御処理などを行う。メモリ部23は、RAM、ROM、フラッシュメモリなどの記憶部を総括的に示している。このメモリ部23は制御部21の処理のワーク領域として用いられたり、プログラムの格納領域として用いられても良い。また再生動作や通信動作のための各種の設定情報、パラメータ等を記憶することにも用いられる。さらにメモリ部23は、受信したコンテンツデータCTのバッファメモリとしても用いられる。送信部24及び受信部25は、ネットワーク4を介したコンテンツサーバ装置1との間での通信部として機能する。受信部25は、コンテンツサーバ装置1から送信されてくる信号、例えば配信されているコンテンツデータCTや、その他の各種の指示信号などの受信を行う。そして受信した信号をデコードする。配信によるコンテンツデータCTの受信の際には、受信して通信方式に対するデコード処理を行ったコンテンツデータCTストリームデータを、制御部21の制御に基づき例えばメモリ部23に転送してバッファリングさせる。またコンテンツサーバ装置1からの指示、通知等の信号が受信されてきた場合は、受信部25はその信号をデコードし、受信情報内容を制御部21に伝達する。送信部24は、制御部21の制御に基づき、コンテンツサーバ装置1への送信信号について所定のエンコードを行い、ネットワーク4に対する送信出力を行う。例えばコンテンツの変更要求RQなどの送信処理を行う。このような処理を行うため、送信部24及び受信部25は、ネットワーク4での有線又は無線での通信方式に対応したエンコード、デコード、及び送受信処理を行うものとなる。再生処理部22は、受信したコンテンツデータCTについて出力デバイス26での再生出力のための処理を行う。例えば受信したコンテンツデータCTはメモリ部23にバッファリングされるが、バッファリングされたコンテンツデータCTを構成する各データは、逐次所定タイミングで再生処理部22に転送される。再生処理部22はコンテンツデータCTに対して出力のための処理、例えば圧縮処理に対するデコード、エラー訂正、D/A変換処理などを行い、映像信号、音声信号を出力デバイス26に供給する。出力デバイス26は、例えばモニタディスプレイ装置や、スピーカ装置とされる。この出力デバイス26によって、コンテンツデータCTとしての映像や音声が出力され、ユーザの視聴に供される。なお、出力デバイス26としてのモニタディスプレイ装置やスピーカ装置は、クライアント装置2としての筐体に一体的に設けられても良いが、別体機器とされても良いことは当然である。表示部29は、例えばクライアント装置2の筐体上に設けられる小型の表示パネルであり、制御部21の制御により、動作状態表示やメニュー表示、アイコン表示、イコライザ表示、タイトル表示、メッセージ表示などを行う。表示部29は、例えば液晶パネルや有機ELパネルなどで構成される。なお、これらの表示を出力デバイス26のモニタディスプレイ装置を用いて行うこともでき、その場合、表示部29を設けないことも考えられる。またメッセージ表示に代えて、或いはメッセージ表示と共に、メッセージ音声を出力することも考えられるが、その場合は、出力デバイス26のスピーカを利用することが考えられる。パネル操作部27は、例えばクライアント装置2の筐体上に設けられる操作キー、ジョグダイヤルなどの操作子を総括的に示している。なお、表示部29、或いは出力デバイス26のモニタディスプレイ装置においてタッチパネル入力が可能とされる場合、そのタッチパネル機構も、パネル操作部27の一つとなる。また、コマンド受信部28は、リモートコマンダー3からのコマンド情報の受信を行う。リモートコマンダー3は電波、赤外線、或いは有線方式で、ユーザの操作に応じたコマンド情報を送信する機器とされるが、そのリモートコマンダー3から送信されてくるコマンド情報は、コマンド受信部28で受信、復調され、制御部21に伝えられる。ユーザは、パネル操作部27の操作子の操作や、表示部29又は出力デバイス26のモニタディスプレイ装置のメニュー表示、アイコン表示に対するタッチパネル操作、さらにはリモートコマンダー3を用いた操作により、各種の操作入力を行うことができる。制御部21は、ユーザの操作入力に応じて、クライアント装置2内の動作や設定等の処理を行ったり、送信部14からコンテンツサーバ装置1に対する信号送信処理を行う。本実施の形態では、ユーザは、配信コンテンツの変更を求める操作入力を行うことができる。その操作入力を検知した場合、制御部21は、送信部14から変更要求RQをコンテンツサーバ装置1に送信させる処理を行う。[1-4:サーバクライアント兼用装置]上記図2,図3のコンテンツサーバ装置1とクライアント装置2は、それぞれ異なる装置であるとして説明したが、実際にはコンテンツサーバ装置1とクライアント装置2の両方の機能を備えるサーバクライアント兼用装置も想定される。例えば図1の各ルームR0~R3には、サーバクライアント兼用装置が配置され、各機器が任意にコンテンツサーバ装置1或いはクライアント装置2として機能するようにしてもよい。図4にはサーバクライアント兼用装置の構成例を示す。この場合、制御部31,コンテンツ格納/再生部12、メモリ部33、再生処理部22、出力デバイス26、パネル操作部27、コマンド受信部28、表示部29、送信部34、受信部35を備える例としている。コンテンツ格納/再生部12、再生処理部22、出力デバイス26、パネル操作部27、コマンド受信部28、表示部29の動作は上述と同様である。制御部31は、上記制御部11,21の両方の機能を備える。即ちコンテンツサーバ装置1として機能する場合は、制御部11と同様の処理を行い、クライアント装置2として機能する場合は制御部21と同様の処理を行う。メモリ部33も、コンテンツサーバ装置1及びクライアント装置2として必要な情報記憶やバッファリングを行う。送信部34、受信部35は、制御部31の制御に基づき、コンテンツサーバ装置1として機能する場合と、クライアント装置2として機能する場合に、それぞれ必要な通信動作を行う。このようなサーバクライアント兼用装置として構成し、これを各ルームR0~R3に配置すれば、ユーザは、任意に、特定のサーバクライアント兼用装置をマスター、即ちコンテンツサーバ装置1として選択して、他のサーバクライアント兼用装置に対し配信を実行させるような使用形態が可能となる。<2.第1の実施の形態>[2-1:動作概要]以下、各実施の形態の配信動作を説明していく。なお各実施の形態では、仮に配信するコンテンツデータCTは音楽コンテンツであるとして説明するが、全て、他の種類のコンテンツ、例えば映像コンテンツ、ゲームコンテンツ、テキストコンテンツ等の配信の場合も適用できるものである。また、各実施の形態の動作は、パーティモードで配信している場合の動作に特徴を有するものとなるため、パーティモード動作を説明し、オンデマンドモードの動作についての詳細説明は避ける。また、説明上、複数のクライアント装置2を区別するため、クライアント装置2A、2B、2C等の符号を用いる。同様にコンテンツデータCTを区別するため、コンテンツデータCT-A、CT-B等の符号を用いる。音楽コンテンツの配信の場合、コンテンツデータCT-AとコンテンツデータCT-Bは、例えば別の楽曲であると考えればよい。図5、図6で第1の実施の形態の動作の概要を説明する。図5は、時間軸に沿って、パーティモードで配信されているコンテンツデータCTを示している。まず、コンテンツサーバ装置1は時点t0まで、或るコンテンツデータCT-Aを全クライアント装置2に対して配信していたとする。この時点t0において、或るクライアント装置2Bの部屋にいるユーザは、他の曲を聴きたいと思って、クライアント装置2Bに対する操作入力で、他のコンテンツデータCT-Bの配信を求める操作を行ったとする。クライアント装置2Bは、そのような内容の変更要求RQをコンテンツサーバ装置1に送信する。コンテンツサーバ装置1では、このように時点t0に送信されてくる変更要求RQを受け付ける。そしてコンテンツサーバ装置1は、変更要求RQに応じて、配信コンテンツをコンテンツデータCT-Bに変更し、各クライアント装置2に配信する。つまり、ルームR0~R3の全てで、配信されている楽曲が切り換えられることになる。ここで、他の部屋に居るユーザが、コンテンツデータCT-Bに変更されたことを不服に思い、時点t1で、クライアント装置2Aに対する操作入力で、元のコンテンツデータCT-Aの配信を求める操作を行ったとする。クライアント装置2Aは、そのような内容の変更要求RQをコンテンツサーバ装置1に送信する。コンテンツサーバ装置1では、このように時点t1に送信されてくる変更要求RQを受け付ける。そしてコンテンツサーバ装置1は、変更要求RQに応じて、配信コンテンツを再びコンテンツデータCT-Aに変更し、各クライアント装置2に配信する。つまり、ルームR0~R3の全てで、配信されている楽曲が再びコンテンツデータCT-Aに切り換えられることになる。この図5では、その後、時点t2,t3などで、クライアント装置2Bのユーザと、クライアント装置2Aのユーザが、争って変更要求RQを出し合い、変更要求RQが錯綜した状態を示している。コンテンツサーバ装置1は、変更要求RQの受信のたびに配信コンテンツを変更するので、全ルームR0~R3では、流れている音楽が何度も切り替わり、非常に聞き苦しい状況が生じている。このような状況は、例えばパーティ中などでは非常に好ましくないため、第1の実施の形態の動作としては、頻繁な変更要求RQの発生を、そのまま許容しないようにする。具体的には、コンテンツサーバ装置1は、時点t0で最初の変更要求RQが受信されたときから、第1の期間TM1の計数を開始する。この期間TM1が経過する時点t4までは、さらなる変更要求の受信状況を確認する。つまり他の変更要求RQが受信されるか否かを確認する。そして受信した場合には、その変更要求RQを受け付け、配信コンテンツの変更を行う。ところが期間TM1内の変更要求RQが多発した場合、コンテンツサーバ装置1は、期間TM1の経過後、第2の期間TM2の間は、変更要求RQを無効とする処理を行う。つまり、いわゆるチャンネル争いのような状況変更要求RQの錯綜があった場合は、期間TM2では、クライアント装置2からの変更要求RQを受信しても、それを無効とし、配信コンテンツの変更は行わない。またコンテンツサーバ装置1は、期間TM1の経過後は、期間TM1内の錯綜した変更要求RQを事後的に無効とし、時点t4からは、元々配信されていたコンテンツデータCT-Aの配信を行う。またコンテンツサーバ装置1は、第2の期間TM2の経過後は、変更要求RQを無効とする処理を終了させ、通常どおり、変更要求RQを受け付ける状態に戻る。その後は、また変更要求RQがあった場合は、その最初の変更要求RQの受信から期間TM1の計数を行い、同様の処理を行うことになる。一方、図6は、期間TM1内に、さらなる変更要求RQが受信されなかった場合を示している。コンテンツサーバ装置1は、時点t0で例えばクライアント装置2Bからの変更要求RQの受信があった場合は、上記図5の場合と同様に配信コンテンツをコンテンツデータCT-Bに変更する。そして、期間TM1の計数を開始する。この期間TM1内に、他の変更要求RQの受信されなかった場合、又は受信されたが、時点t0から期間TM1を経過する時点t4までの変更要求RQの受信が所定数未満であった場合は、コンテンツサーバ装置1は、変更要求RQの錯綜が生じていないと判断する。その場合は、時点t4以降、変更要求RQを無効とする処理は行わない。そして時点t0で切り換えたコンテンツデータCT-Bの配信をそのまま継続する。このように第1の実施の形態では、パーティモードでの配信中に、或るクライアント装置からの配信コンテンツの変更を求める変更要求RQを受信した場合、まず、その受信を元に計数が開始される第1の期間TM1内に、さらなる変更要求RQの受信状況を確認する。そして期間TM1内における変更要求の受信状況に応じて期間TM1の経過後の処理を決定する。特に、期間TM1内に所定数以上の変更要求RQを検知した場合、第1の期間TM1の経過後に計数が開始される第2の期間TM2は、受信される変更要求RQを無効とする処理を行う。また、その場合は、期間TM1内の変更要求RQ図5の時点t0,t1,t2,t3の各変更要求RQを無効とし、時点t4からは、元のコンテンツデータCT-Aの配信を行う。例えば時刻t0の時点で配信していたコンテンツの配信箇所から配信を再開する。一方、期間TM1内に所定数未満の変更要求RQしか検知されなかった場合、第1の期間TM1の経過後は、変更要求RQを無効とする処理を行わない。配信コンテンツも、期間TM1内の最後の変更要求RQにより変更した後のコンテンツデータの配信を継続する。[2-2:サーバクライアントの機能構成]このような動作を実現するためのコンテンツサーバ装置1及びクライアント装置2の構成、特に制御部11、21の機能構成について説明する。図7はコンテンツサーバ装置1の構成を示し、特に制御部11について、そのハードウェア及びソフトウェアプログラムにより実現される機能構成例を示している。制御部11の機能構成として、配信制御部41、カウンタ部42、閾値メモリ部43、比較部、タイマ部45を備える。配信制御部41は、パーティモードやオンデマンドモードでの配信動作を制御する機能部位である。配信制御部41は、コンテンツ格納/再生部12に対して、配信するコンテンツデータCTを指定して再生を実行させ、再生されたコンテンツデータCTを送信部14から各クライアント装置2に配信させる制御を行う。クライアント装置2からの変更要求RQは、受信部15で受信されて制御部11に供給される。変更要求RQは、制御部11内では、カウンタ部42と配信制御部41に伝えられる。配信制御部41は、変更要求RQに応じて、要求されたコンテンツデータCTの配信を実行するため、コンテンツ格納/再生部12に、再生するコンテンツデータCTの変更を指示する。なお、上記図5の期間TM2のように、変更要求RQを無効とする場合には、配信制御部41は変更要求RQを無効な信号として処理することになる。カウンタ部42は、受信された変更要求RQの数CCをカウントする計数機能である。上記期間TM1における変更要求RQの数が、カウント値変更要求数CCとしてカウントされる。閾値メモリ部43は、変更要求RQの数の判断のための閾値CCthを記憶する機能である。比較部44は、カウンタ部42が出力する変更要求数CCと閾値CCthを比較する。そしてCC≧CCthであるか否かの比較結果信号を配信制御部41に出力する。配信制御部41は、期間TM1内において、変更要求数CCが閾値CCth以上であれば、変更要求RQの錯綜が生じていると判断され、一方、変更要求数CCが閾値CCth未満であれば変更要求RQの錯綜は生じていないと判断する。タイマ部45は、配信制御部41が起動する時間計数機能であり、期間TM1,TM2の計数を行う。配信制御部はリセット信号/スタート信号R/Sをタイマ部45に与えて計数を実行させる。またタイマ部45は、期間TM1、TM2の経過時に、タイマーオーバフロー信号OFを配信制御部41に与え、期間TM1、TM2の経過を通知する。具体的には配信制御部41は、最初の期間TM1,TM2計数を行っていない場合における最初の変更要求RQがあったら、タイマ部45に計数スタート信号を与え、期間TM1の計数を開始させる。配信制御部41は、期間TM1の経過は、タイマ部45からのオーバフロー信号OFで知ることができる。配信制御部41は、期間TM2に変更要求RQの無効化を行う場合は、期間TM1の経過後、タイマ部45にリセット/スタート信号を与え、期間TM2の計数を開始させる。配信制御部41は、期間TM2の経過は、同様にタイマ部45からのオーバフロー信号OFで知ることができる。図8はクライアント装置2の構成、特に制御部21について、そのハードウェア及びソフトウェアプログラムにより実現される機能構成例を示している。制御部21の機能構成として、再生制御部61、バッファ処理部62、送信制御部63、操作検知部64を備える。再生制御部61は、配信されたコンテンツデータCTの再生出力の制御を行う機能である。またバッファ処理部62は、受信されたコンテンツデータCTのバッファリングを管理する機能である。コンテンツサーバ装置1から配信されてくるコンテンツデータCTは受信部25で受信され、まずバッファ処理部62の制御により、メモリ部23にバッファリングされる。バッファ処理部62は、バッファリングしたデータを逐次メモリ部43から読み出して再生制御部61に受け渡す。再生制御部61は、該データを再生処理部22に転送し、再生処理部22に必要な処理、例えば圧縮に対するデコード処理等を実行させ、出力デバイス26から出力させる制御を行う。操作検知部64は、コマンド信号CMDを検知する機能である。また送信制御部63は、送信動作の制御を行う機能である。上述のようにユーザは、パネル操作部27、タッチパネル、或いはリモートコマンダー3を用いて操作入力を行うことができる。これらを用いた操作の1つとして変更要求操作がある。操作検知部64は、変更要求としてのコマンド信号CMDを検知した場合、その情報を送信制御部63に通知する。送信制御部63は、当該変更要求としてのコマンド信号CMDに応じて、変更要求RQとしての送信データを生成し、送信部24からコンテンツサーバ装置1に対して送信させる制御を行う。[2-3:サーバクライアントの処理例]以上の機能構成によって図5,図6で説明した動作が実現される。以下、コンテンツサーバ装置1及びクライアント装置2の処理例を説明する。まず図7の機能構成によるコンテンツサーバ装置1の制御部11主に配信制御部41の処理例を図9を参照して述べる。ステップF101は電源オンによって起動される処理を示している。制御部11は電源オンとされ起動したらステップF102に進み各種変数の初期化を行う。ステップF103では、制御部11はパーティモード、オンデマンドモードのモード設定を確認する。このモード設定については、ユーザの設定操作などによるが、例えば前回の動作時にパーティモードで終了していれば、今回もパーティモードで開始するなどとしてモード判断を行う。或いは起動時に、ユーザにモード選択を行わせるようにしても良い。ステップF103で、今回はオンデマンドモードと判断した場合は、制御部11はオンデマンドモードでの処理に移行する。オンデマンドモードでの処理については説明を省略する。一方、パーティモードと判断した場合は、制御部11はステップF104に進み、パーティモードの開始処理を行う。例えば配信するコンテンツの決定処理などを行う。そしてステップF105で制御部11は配信開始制御を行う。即ち制御部11は、コンテンツ格納/再生部12に所定のコンテンツデータCTの再生開始を指示する。そして再生したコンテンツデータCTを送信部14に供給させ、送信部14から全クライアント装置2に対する配信を実行させる。以降、制御部11は、コンテンツ格納/再生部12及び送信部14に、順次連続してコンテンツデータCTの再生及び配信を実行させる。再生するコンテンツデータCT、コンテンツ格納/再生部12において記録媒体に記憶されたコンテンツナンバの順でもよいし、制御部11がランダムに選択して逐次指示しても良い。いずれにしても、ステップF105以降は、配信終了となるまで、基本的には多数の曲が順次、全クライアント装置2に共通に配信されることになる。このようにパーティモードでの配信中には、制御部11は、ステップF106での変更要求RQの受信の監視、及びステップF120での配信終了トリガの監視を行う。ステップF120では、制御部11は配信終了のトリガとしての操作や状態を監視する。例えばユーザの配信終了操作によって配信を終了する場合や、電源オフ操作により配信を終了する場合などである。或いは、全てのコンテンツもしくは配信対象として選択した全てのコンテンツの再生及び配信が終了したことで配信を終了する場合もある。それらの終了のトリガが検知された場合、制御部11はステップF120からF123に進み、パーティモードでの配信動作を終了する処理を行う。またステップF106では、制御部11は変更要求RQが受信部15で受信されたか否かを監視する。制御部11は、このステップF106で変更要求RQの受信を検知した場合、図5,図6で説明した動作のための処理を開始することとなる。このステップF106で検知する変更要求RQとは、図5,図6における時点t0、つまり期間TM1の計数の起点となる変更要求RQのこととなる。まずステップF107で制御部11は、変更要求RQの受信時点で配信していたコンテンツデータCTの中断ポイントを記憶する。図5の例で言えば時点t0までコンテンツデータCT-Aを配信していたので、このコンテンツデータCT-Aとしての楽曲の途中の時点t0の再生ポイントが、ここでいう中断ポイントとなる。次に制御部11はステップF108で、変更要求RQに応じた配信コンテンツの変更制御を行う。例えばコンテンツデータCT-Bの再生及び配信を、コンテンツ格納/再生部12及び送信部14に実行させる。また制御部11は、ステップF109で、カウンタ部42の機能として、変更要求数CCをインクリメントする。最初はCC=1とする。さらに制御部11はステップF110で、タイマ部45の機能としての期間TM1の計数処理を行う。ここではタイマ部45での計数値としてのTM1をインクリメントする。その後、計数値TM1がオーバフローとなるまで、つまり図5、図6で言う期間TM1が経過するまで、ステップF112の変更要求RQの受信の監視、及びステップF121での配信終了のトリガの監視を行いながら、ステップF110でのインクリメントを行っていく。つまり期間TM1としてのタイムカウントを進行させる。制御部11は、期間TM1が経過する前に、配信終了トリガが発生したら、ステップF121からF123に進み配信終了処理を行う。また制御部11は、期間TM1が経過する前に、他の変更要求RQが受信されたら、ステップF112からF108に戻る。この場合、制御部11はステップF108で、新たな変更要求RQに応じた配信コンテンツの変更制御を行う。これによって配信される楽曲が変更されることになる。また制御部11は、ステップF109で、カウンタ部42の機能として、変更要求数CCをインクリメントする。このように、期間TM1の経過までに変更要求RQが受信される毎に、配信コンテンツの変更と変更要求数CCのインクリメントが行われる。タイマ部45での計数値TM1がオーバフローし、つまり期間TM1の経過となったら、制御部11はステップF111からF113に進み、この時点で比較部44の機能による比較結果を確認する。即ち期間TM1内に、閾値CCthとしての所定数以上の変更要求RQの受信があったか否かである。閾値CCth=3と設定しているのであれば、例えば最初の変更要求RQを含めて3つ以上の変更要求RQの受信があったか否かの判断となる。もしCC<CCthであれば、制御部11は期間TM1での変更要求RQの錯綜配信コンテンツの選択の争いは生じていないとし、ステップF119に進む。そして各変数、即ちこの場合は計数値TM1、変更要求数CCをリセットして、ステップF106、F120の監視ループに戻る。これは図6で説明した場合の動作となる。一方、CC≧CCthであれば、制御部11は期間TM1において変更要求RQの錯綜が生じていると判定し、ステップF114に進む。まず制御部11はステップF114で配信箇所を変更する。ここでは、ステップF107で記憶した配信中断ポイントからの配信を再開するようにコンテンツ格納/再生部12を制御し、再生及び配信をコンテンツ格納/再生部12及び送信部14に実行させる。つまり、期間TM1を経過する時点までの変更要求RQ、即ちステップF106又はF112で検知した変更要求RQは、無かったものとして、その変更要求RQの受信前の配信状態に戻すものである。次に制御部11はステップF115で、変更要求RQの無効化設定を行う。つまり、以降、変更要求RQを受け付けても、それを無効として配信コンテンツの変更は行わないものとする。そしてステップF116で、タイマ部45の機能としての期間TM2の計数処理を行う。ここではタイマ部45での計数値としてのTM2をインクリメントする。その後、計数値TM2がオーバフローとなるまで、つまり図5で言う期間TM2が経過するまで、ステップF122で配信終了のトリガの監視を行いながら、ステップF116でのインクリメントを行っていく。つまり期間TM2としてのタイムカウントを進行させる。制御部11は、期間TM2が経過する前に、配信終了トリガが発生したら、ステップF121からF123に進み配信終了処理を行う。なお期間TM2が経過する前に、変更要求RQが受信される場合があるが、上記ステップF115で無効化設定をおこなっているため、制御部11は変更要求RQの受信があっても、それを変更要求RQとして認識しない。つまり期間TM2の経過までは、変更要求RQは無視する。タイマ部45での計数値TM2がオーバフローし、つまり期間TM2の経過となったら、制御部11はステップF117からF118に進み、変更要求RQの無効化設定を解除する。そしてステップF119で各変数、即ちこの場合は計数値TM1TM2、変更要求数CCをリセットして、ステップF106、F120の監視ループに戻る。これが、図5の場合の動作となる。次にクライアント装置2の制御部21の処理例を図10で説明する。ステップF201は電源オンによって起動される処理を示している。制御部21は電源オンとされ起動したらステップF202に進み各種の初期処理を行う。ステップF203では、コンテンツサーバ装置1からの配信開始を待機する。配信、つまり受信部25でのコンテンツデータCTの受信が開始されたら、ステップF203からF204に進み、制御部11はコンテンツデータCTの受信及び出力処理を行う。即ち、以降、受信されたコンテンツデータCTのバッファリング処理、再生処理部22への供給を実行し、出力デバイスからの音声や映像の出力を実行させる。配信開始後は、制御部21は、このステップF204の処理を行いながら、ステップF205で配信終了の監視処理、ステップF206での変更要求のユーザ操作の監視を行う。コンテンツサーバ装置1からの配信が終了し、コンテンツデータCTが受信されなくなったら、制御部21はステップF205からF208に進む。そして受信されたコンテンツデータCTのバッファリング処理及び再生処理部22への供給を停止して、出力デバイスからのコンテンツデータCTとしての音声や映像の出力を終了させる。ユーザ操作として、変更要求の操作を検知した場合は、制御部21はステップF206からF207に進む。そしてステップF207で、変更要求RQを送信部24からコンテンツサーバ装置1に対して送信させる処理を行う。なお、実際には他のユーザ操作に対応する処理もあるが、図10では省略している。このようにクライアント装置2では、配信コンテンツの出力を行いながら、ユーザ操作に応じて変更要求RQの送信を行う。従ってクライアント装置2のユーザは、配信中に任意の時点で、配信コンテンツの変更を要求できることとなる。以上の図9,図10の処理をコンテンツサーバ装置1及びクライアント装置2が実行することで、図5,図6で説明した動作が実現される。そしてこのような第1の実施の形態では、次の効果が得られる。まず、パーティモードでの配信中に、各ルームR0~R3のクライアント装置2のユーザは、自由に配信コンテンツの変更の要求を行うことができる。そして、変更要求RQの送信により、配信コンテンツは変更される。従って、或るユーザが、特定の曲や映像などを見聞きしたいと思ったときに便利である。そして、特にコンテンツ選択の争いが無ければ、そのまま変更されたコンテンツが配信される図6の状態。つまりパーティモードでありながらユーザの希望に沿った配信が実現される。一方で、変更要求RQが一時的に多発し、配信コンテンツ選択の争いが生じることがある。度々配信コンテンツが変更されると、他のユーザの気分を害したり、パーティ等の雰囲気を壊す恐れがある。そこで、頻繁な変更を許すのは期間TM1内の短時間のみとし、続く期間TM2は変更要求RQを無効とする。つまり変更要求RQで争いがある場合は、その争いの影響が配信コンテンツに現れるのを一時的なものとし、すぐに頻繁なコンテンツ変更の無い平穏な状態期間TM2とする。このように頻繁なコンテンツ変更が起こりえる期間を限定していることにより、他のユーザに対する悪影響を最低限とすることができる。つまり、第1の実施の形態では、頻繁なコンテンツ変更が生ずる期間は許容できる短い期間のみとすることで、雰囲気をさほど悪化させない配信を行いつつ、争いがなければ、或るユーザの希望に応じた配信が可能となるものである。さらにこれにより、無用な権限争いを防止できるのみならず、コンテンツ変更要求を受け付けない禁止時間を長めに設定することでユーザーは変更を諦め、結果的に無用な権限争いを再発することを防止できるという効果も期待できる。なお、期間TM1では、変更要求RQに応じて無条件に配信コンテンツが変更されることから、あまり期間TM1を長くするのは適切ではない。そこで期間TM1は30秒から~3分程度とすることが考えられる。但し、もちろん使用形態、使用時の状況、パーティの客層などに応じて適切な時間は多様に考えられ、例えば期間TM1を10分程度とするなども想定される。従って、期間TM1の長さをユーザが設定できるようにすることも考えられる。また、期間TM2に関しては、争いがあった場合の制裁的な処理とも考えることができるため、或る程度長い方が良い場合が多い。例えば期間TM1の5~10倍程度の時間を設定することが考えられる。但し、あまり無効期間を長くしないという設定も考えられるし、期間TM2もユーザが設定できるようにすることも考えられる。なお、争いがあったか否かの判断は、変更要求数CCが閾値CCth以上であるか否かで判断しているが、CCthの値は、期間TM1の長さや、どの程度のコンテンツ変更を許容するかなどに応じて適切な値が設定されればよい。また争いがあった場合に、期間TM1の経過後は、最初の変更要求RQの受信時までに配信していたコンテンツデータCTの中断箇所から配信を再開するものとしたが、他の例も考えられる。例えば、中断箇所でなく、その変更要求RQの前の配信コンテンツの最初曲の頭から再開してもよい。或いは、期間TM1の終了時点で配信しているコンテンツデータCTをそのまま配信することとしてもよい。また、上記例では、期間TM2において、全てのクライアント装置2からの変更要求RQを無効化するものとしたが、特定のクライアント装置2からの変更要求RQを無効化するものとしてもよい。即ち、期間TM1において変更要求RQの錯綜を生じさせたクライアント装置2のみ、例えば図5の例におけるクライアント装置2B、2Aのみについて、無効化し、他のクライアント装置2C等からの変更要求RQは有効としてコンテンツ変更処理を行うことも考えられる。また上記図9の処理例では、期間TM1を経過した時点での変更要求数CCと閾値CCthを比較したが、期間TM1の計時中に絶えず変更要求数CCと閾値CCthとを比較してもよい。その場合、変更要求数CCが閾値CCth以上となった時点で、期間TM1を終了とし、ステップF114以降の処理、つまり元のコンテンツの配信への変更、変更要求RQの無効化、及び期間TM2の計測を行ってもよい。<3.第2の実施の形態>[3-1:動作概要]続いて第2の実施の形態を説明する。図11は第2の実施の形態の動作の概要を示すものである。上述した図5と同様に、時間軸に沿って、パーティモードで配信されているコンテンツデータCTを示している。まず、コンテンツサーバ装置1は時点t0まで、或るコンテンツデータCT-Aを全クライアント装置2に対して配信していたとする。時点t0において、クライアント装置2Bから変更要求RQが送信されてきたとする。コンテンツサーバ装置1は、上記第1の実施の形態と同様、時点t0で最初の変更要求RQがあったら、配信コンテンツを変更するとともに、期間TM1の間は、他の変更要求RQも受け付け、配信コンテンツの変更を行う。この図11では、その後、時点t1,t2,t3などで、クライアント装置2Bのユーザと、クライアント装置2Aのユーザが、争って変更要求RQを出し合い、変更要求RQが錯綜した状態を示している。コンテンツサーバ装置1は、変更要求RQの受信のたびに配信コンテンツを変更するので、全ルームR0~R3では、流れている音楽が何度も切り替わり、一時的に聞き苦しい状況が生じている。第2の実施の形態でも、期間TM1においてこのような状況が発生するか否かを判断して、期間TM1経過後の動作を決定する。具体的には、コンテンツサーバ装置1は、期間TM1内の変更要求RQが多発した場合、期間TM1の経過後、各クライアント装置2に対して変更要求の送信禁止信号enRQを送信する。これに応じて各クライアント装置2は変更要求RQの送信禁止処理を行う。つまりクライアント装置2は、ユーザは変更要求操作を行ったとしても、変更要求RQをコンテンツサーバ装置1に送信しない。またコンテンツサーバ装置1は、期間TM1の経過後は、期間TM1内の錯綜した変更要求RQを事後的に無効とし、時点t4からは、元々配信されていたコンテンツデータCT-Aの配信を行う。また、コンテンツサーバ装置1は期間TM1の経過時点から期間TM2を計測し、期間TM2が経過した後に、送信禁止解除信号okRQを各クライアント装置2に送信する。これに応じて各クライアント装置2は変更要求RQの送信禁止処理を解除する。つまりクライアント装置2は、その後はユーザの変更要求操作に応じて、変更要求RQをコンテンツサーバ装置1に送信するようにする。従ってコンテンツサーバ装置1には、第2の期間TM2の経過後は、再び変更要求RQが送信されてくる可能性が生ずる。変更要求RQがあった場合は、その最初の変更要求RQの受信から期間TM1の計数を行い、同様の処理を行うことになる。なお、期間TM1内で、変更要求RQの錯綜が発生しなかった場合は、上記第1の実施の形態の図6と同様の動作となる。このように第2の実施の形態では、パーティモードでの配信中に、或るクライアント装置からの配信コンテンツの変更を求める変更要求RQを受信した場合、まず、その受信を元に計数が開始される第1の期間TM1内に、さらなる変更要求RQの受信状況を確認する。そして期間TM1内における変更要求の受信状況に応じて期間TM1の経過後の処理を決定する。特に、期間TM1内に所定数以上の変更要求RQを検知した場合、各クライアント装置2に対し、変更要求の送信禁止信号enRQを送信し、さらに、期間TM2の経過後、各クライアント装置2に対し、変更要求の送信禁止解除信号okRQを送信する。これにより、期間TM2は、クライアント装置2側で変更要求RQの送信ができないようにする。また、その場合は、期間TM1内の変更要求RQ図11の時点t0,t1,t2,t3の各変更要求RQを無効とし、時点t4からは、元のコンテンツデータCT-Aの配信を行う。例えば時刻t0の時点で配信していたコンテンツの配信箇所から配信を再開する。一方、期間TM1内に所定数未満の変更要求RQしか検知されなかった場合、第1の期間TM1の経過後は、変更要求RQの送信を禁止させる処理は行わない。配信コンテンツも、期間TM1内の最後の変更要求RQにより変更した後のコンテンツデータの配信を継続する。[3-2:サーバクライアントの機能構成]このような動作を実現するためのコンテンツサーバ装置1及びクライアント装置2の制御部11、21の機能構成を図12,図13に示す。図12に示すコンテンツサーバ装置1の制御部11は、機能構成として配信制御部41、カウンタ部42、閾値メモリ部43、比較部44、タイマ部45を備えることは第1の実施の形態と同様である。この場合、配信制御部41は、送信禁止信号enRQ、送信禁止解除信号okRQを発生させ、送信部14から各クライアント装置2に送信できるようにする点が第1の実施の形態と異なる。また図13に示すクライアント装置2の制御部21についても、第1の実施の形態と同様に再生制御部61、バッファ処理部62、送信制御部63、操作検知部64を備える。この場合、受信部25でコンテンツデータCT以外に、送信禁止信号enRQ、送信禁止解除信号okRQが受信されることもあることから、その処理機能が加わる。即ち受信部25で受信された送信禁止信号enRQ、送信禁止解除信号okRQは、送信制御部63に供給され、送信制御部63は、これらに応じて変更要求RQの送信許否の設定を行う。具体的には送信制御部63は、送信禁止信号enRQが入力されたら送信禁止設定を行い、以降は、操作検知部64で変更要求RQの操作が検知されても、変更要求RQの送信処理を行わない。またその後、送信禁止解除信号okRQが入力されたら、送信禁止設定を解除する。[3-3:サーバクライアントの処理例]この第2の実施の形態のコンテンツサーバ装置1及びクライアント装置2の処理例を説明する。まず図14でコンテンツサーバ装置1の制御部11主に配信制御部41の処理例を述べる。なお第1の実施の形態の図9と同一の処理は同一のステップ番号を付し、重複説明を避ける。まず、ステップF101~F105は図9と同様である。またパーティモード配信開始後のステップF106~F114、F120,F121,F124も図3と同様である。即ち、パーティモードでの配信中に変更要求RQが受信部15で受信されたら、制御部11は、期間TM1の処理を図9と同様に行う。ステップF113~F119を説明する。期間TM1の経過時に、ステップF113でCC<CCthであれば、制御部11は期間TM1での変更要求RQの錯綜配信コンテンツの選択の争いは生じていないとし、ステップF119に進む。そして各変数、即ちこの場合は計数値TM1、変更要求数CCをリセットして、ステップF106、F120の監視ループに戻る。期間TM1の経過時に、ステップF113でCC≧CCthであれば、制御部11は期間TM1において変更要求RQの錯綜が生じていると判定し、ステップF114に進む。まず制御部11はステップF114で配信箇所を変更する。ここでは、ステップF107で記憶した配信中断ポイントからの配信を再開するようにコンテンツ格納/再生部12を制御し、再生及び配信をコンテンツ格納/再生部12及び送信部14に実行させる。つまり、期間TM1を経過する時点までの変更要求RQ、即ちステップF106又はF112で検知した変更要求RQは、無かったものとして、その変更要求RQの受信前の配信状態に戻す。次に制御部11はステップF115Aで、変更要求の送信禁止信号enRQの送信制御を行い、送信部14から各クライアント装置2に送信禁止信号enRQを送信させる。そしてステップF116で、タイマ部45の機能としての期間TM2の計数処理を行う。その後、計数値TM2がオーバフローとなるまで、つまり図11で言う期間TM2が経過するまで、ステップF122で配信終了のトリガの監視を行いながら、ステップF116でのインクリメントを行っていく。つまり期間TM2としてのタイムカウントを進行させる。制御部11は、期間TM2が経過する前に、配信終了トリガが発生したら、ステップF121からF123に進み配信終了処理を行う。なお、期間TM2が経過するまでの期間においては、変更要求RQを受信することはない。各クライアント装置2が、送信禁止信号enRQに従って、変更要求RQを送信してこないためである。タイマ部45での計数値TM2がオーバフローし、つまり期間TM2の経過となったら、制御部11はステップF117からF118Aに進み、送信禁止解除信号okRQの送信制御を行い、送信部14から各クライアント装置2に送信禁止解除信号okRQを送信させる。そしてステップF119で各変数、即ちこの場合は計数値TM1TM2、変更要求数CCをリセットして、ステップF106、F120の監視ループに戻る。次にクライアント装置2の制御部21の処理例を図15で説明する。これも第1の実施の形態の図10と同様の処理には同様のステップ番号を付して説明を省略する。ステップF201~F205、F208は図10と同様である。配信開始後は、制御部21はステップF204のコンテンツデータCTの受信及び出力処理を行いながら、ステップF205での配信終了の監視処理に加え、ステップF210,F212,F214の監視処理を行う。ステップF210では、送信禁止信号enRQの受信を監視する。制御部21は、コンテンツサーバ装置1からの送信禁止信号enRQを受信した場合は、ステップF211で変更要求RQの送信禁止設定を行う。ステップF212では、送信禁止解除信号okRQの受信を監視する。制御部21は、コンテンツサーバ装置1からの送信禁止解除信号okRQを受信した場合は、ステップF213で変更要求RQの送信禁止設定を解除する。ユーザ操作として、変更要求の操作を検知した場合は、制御部21はステップF214からF215に進む。そして、現在送信禁止設定がされているか否かを確認する。送信禁止設定がされていなければ、制御部21はステップF216に進み、変更要求RQを送信部24からコンテンツサーバ装置1に対して送信させる処理を行う。送信禁止設定がされていれば、制御部21はステップF217に進み、ユーザの変更要求の操作を無効操作として処理し、変更要求RQの送信処理は行わない。以上の図14,図15の処理をコンテンツサーバ装置1及びクライアント装置2が実行することで、第2の実施の形態としての図11で説明した動作が実現される。そしてこの第2の実施の形態では、第1の実施の形態と同様の効果が得られる。即ち、パーティモードでの配信中に、各ルームR0~R3のクライアント装置2のユーザは、自由に配信コンテンツの変更の要求を行うことができる。そして、特にコンテンツ選択の争いが無ければ、そのまま変更されたコンテンツが配信される。一方で、変更要求RQが一時的に多発しても、頻繁な配信コンテンツの変更を許すのは期間TM1内の短時間のみとし、続く期間TM2は変更要求RQを送信できないものとする。従って、他のユーザの不快感や雰囲気の悪化が長引かない。さらに、第2の期間TM2はクライアント装置2から変更要求RQが送信できないため、その後の無用な権限争いの再発を防止できる。なお、期間TM1、TM2の設定、閾値CCthの設定は、第1の実施の形態と同様に考えればよい。また争いがあった場合に、期間TM1の経過後に配信するコンテンツデータCTの選択も、第1の実施の形態と同様の変形例が考えられる。また、上記例では、期間TM2において、全てのクライアント装置2に送信禁止信号enRQを送信するものとしたが、特定のクライアント装置2にのみ送信禁止信号enRQを送信するものとしてもよい。即ち、期間TM1において変更要求RQの錯綜を生じさせたクライアント装置2のみ、送信禁止信号enRQを送信し、他のクライアント装置2は、引き続き変更要求RQの送信を可能な状態を維持させてもよい。また上記図14の処理例では、期間TM1を経過した時点での変更要求数CCと閾値CCthを比較したが、期間TM1の計時中に絶えず変更要求数CCと閾値CCthとを比較してもよい。その場合、変更要求数CCが閾値CCth以上となった時点で、期間TM1を終了とし、ステップF114以降の処理、つまり元のコンテンツの配信への変更、送信禁止信号enRQの送信、及び期間TM2の計測を行ってもよい。また、図15のクライアント装置2の処理として、ステップF217でユーザの操作を無効化する場合には、故障等と勘違いさせないようにすることや、争い防止のために送信禁止されたことを積極的に提示するために、例えば表示部29等で、変更要求RQの送信が禁止されていることのメッセージ表示等を行うことが好適である。<4.第3の実施の形態>[4-1:動作概要]続いて第3の実施の形態を説明する。図15は第3の実施の形態の動作の概要として、時間軸に沿って、パーティモードで配信されているコンテンツデータCTを示している。まず、コンテンツサーバ装置1は時点t0まで、或るコンテンツデータCT-Aを全クライアント装置2に対して配信していたとする。時点t0において、クライアント装置2Bから変更要求RQが送信されてきたとする。コンテンツサーバ装置1は、上記第1の実施の形態と同様、時点t0で最初の変更要求RQがあったら、配信コンテンツを変更するとともに、期間TM1の間は、他の変更要求RQも受け付け、配信コンテンツの変更を行う。この図15では、その後、時点t1,t2,t3などで、クライアント装置2Bのユーザと、クライアント装置2Aのユーザが、争って変更要求RQを出し合い、変更要求RQが錯綜した状態を示している。コンテンツサーバ装置1は、変更要求RQの受信のたびに配信コンテンツを変更するので、全ルームR0~R3では、流れている音楽が何度も切り替わり、一時的に聞き苦しい状況が生じている。第3の実施の形態でも、期間TM1においてこのような状況が発生するか否かを判断して、期間TM1経過後の動作を決定する。具体的には、コンテンツサーバ装置1は、期間TM1内の変更要求RQが多発した場合、期間TM1の経過後、各クライアント装置2に対して変更要求の送信禁止信号enRQを送信する。これに応じて各クライアント装置2は変更要求RQの送信禁止処理を行う。つまりクライアント装置2は、ユーザは変更要求操作を行ったとしても、変更要求RQをコンテンツサーバ装置1に送信しない。またコンテンツサーバ装置1は、期間TM1の経過後は、期間TM1内の錯綜した変更要求RQを事後的に無効とし、時点t4からは、元々配信されていたコンテンツデータCT-Aの配信を行う。ここまでは、上記第2の実施の形態と同様である。但しこの第3の実施の形態の場合、クライアント装置2側で、第2の期間TM2を計測する。即ちクライアント装置2は送信禁止信号enRQを受信したら、期間TM2の計数を行い、期間TM2が経過するまでは、変更要求RQの送信禁止設定を維持する。そして期間TM2の経過後、自主的に送信禁止設定を解除する。従ってコンテンツサーバ装置1には、第2の期間TM2の経過後は、再び変更要求RQが送信されてくる可能性が生ずる。変更要求RQがあった場合は、その最初の変更要求RQの受信から期間TM1の計数を行い、同様の処理を行うことになる。なお、期間TM1内で、変更要求RQの錯綜が発生しなかった場合は、上記第1の実施の形態の図6と同様の動作となる。このように第2の実施の形態では、パーティモードでの配信中に、或るクライアント装置からの配信コンテンツの変更を求める変更要求RQを受信した場合、まず、その受信を元に計数が開始される第1の期間TM1内に、さらなる変更要求RQの受信状況を確認する。そして期間TM1内における変更要求の受信状況に応じて期間TM1の経過後の処理を決定する。特に、期間TM1内に所定数以上の変更要求RQを検知した場合、各クライアント装置2に対し、変更要求の送信禁止信号enRQを送信する。これに応じてクライアント装置2では、自主的に期間TM2の間、変更要求RQの送信を行わないようにする。[4-2:サーバクライアントの機能構成]このような動作を実現するためのコンテンツサーバ装置1及びクライアント装置2の制御部11、21の機能構成を図17,図18に示す。図17に示すコンテンツサーバ装置1の制御部11は、機能構成として配信制御部41、カウンタ部42、閾値メモリ部43、比較部44、タイマ部45を備えることは第1、第2の実施の形態と同様である。この場合、配信制御部41は、送信禁止信号enRQを発生させ、送信部14から各クライアント装置2に送信できるようにする点が第1、第2の実施の形態と異なる。またタイマ部45は、第1の期間TM1の計測を行う機能とされる。また図18に示すクライアント装置2の制御部21については、第1、第2の実施の形態と同様に再生制御部61、バッファ処理部62、送信制御部63、操作検知部64を備える。これに加えてタイマ部65を備える。この第3の実施の形態の場合、受信部25ではコンテンツデータCT以外に、送信禁止信号enRQが受信されることがある。受信部25で受信された送信禁止信号enRQは、送信制御部63に供給され、送信制御部63は、これらに応じて変更要求RQの送信禁止の設定を行う。具体的には送信制御部63は、送信禁止信号enRQが入力されたら送信禁止設定を行い、以降は、操作検知部64で変更要求RQの操作が検知されても、変更要求RQの送信処理を行わない。さらに、タイマ部65による期間TM2の計数を開始させる。そしてタイマ部65での期間TM2の計数が終了したら、送信制御部63は送信禁止設定を解除する。[4-3:サーバクライアントの処理例]この第3の実施の形態のコンテンツサーバ装置1及びクライアント装置2の処理例を説明する。まず図19でコンテンツサーバ装置1の制御部11主に配信制御部41の処理例を述べる。なお図9、図14と同一の処理は同一のステップ番号を付し、重複説明を避け、ステップF113~F119のみ説明する。期間TM1の経過時に、ステップF113でCC<CCthであれば、制御部11は期間TM1での変更要求RQの錯綜は生じていないとし、ステップF119に進む。そして各変数、即ち計数値TM1、変更要求数CCをリセットして、ステップF106、F120の監視ループに戻る。期間TM1の経過時に、ステップF113でCC≧CCthであれば、制御部11は期間TM1において変更要求RQの錯綜が生じていると判定し、ステップF114に進む。まず制御部11はステップF114で配信箇所を変更する。ここでは、ステップF107で記憶した配信中断ポイントからの配信を再開するようにコンテンツ格納/再生部12を制御し、再生及び配信をコンテンツ格納/再生部12及び送信部14に実行させる。つまり、期間TM1を経過する時点までの変更要求RQ、即ちステップF106又はF112で検知した変更要求RQは、無かったものとして、その変更要求RQの受信前の配信状態に戻す。次に制御部11はステップF115Aで、変更要求の送信禁止信号enRQの送信制御を行い、送信部14から各クライアント装置2に送信禁止信号enRQを送信させる。そしてステップF119で各変数、即ち計数値TM1、変更要求数CCをリセットして、ステップF106、F120の監視ループに戻る。なお、ステップF115Aで送信禁止信号enRQを送信した後は、ステップF119を経てステップF106、F120の監視ループに戻るが、クライアント装置2側で第2の期間TM2のカウントが完了するまでは、変更要求RQが送信されてくることはない。次にクライアント装置2の制御部21の処理例を図15で説明する。これも図10、図15と同様の処理には同様のステップ番号を付して説明を省略する。配信開始後は、制御部21はステップF204のコンテンツデータCTの受信及び出力処理を行いながら、ステップF205での配信終了の監視処理に加え、ステップF210,F221,F214の監視処理を行う。ステップF210では、送信禁止信号enRQの受信を監視する。制御部21は、コンテンツサーバ装置1からの送信禁止信号enRQを受信した場合は、ステップF211で変更要求RQの送信禁止設定を行う。そしてステップF220で、タイマ部65の機能による期間TM2のカウントを開始させる。ステップF221では、タイマ部65のカウント中において、TM2のカウントがオーバフローしたか否かを確認する。つまり期間TM2の経過の確認である。なお、この確認処理は、ステップF220でカウントスタートさせた以後のみの処理であり、通常時期間TM2のカウントを行っていない期間は、否定結果として処理を抜ければよい。ステップF220でカウントスタートさせた以後において、期間TM2の経過が確認された場合は、制御部21はステップF222に進み、変更要求RQの送信禁止設定を解除する。そしてステップF223で期間TM2のカウント値としての変数TM2をリセットする。ユーザ操作として、変更要求の操作を検知した場合は、制御部21はステップF214からF215に進む。そして、現在送信禁止設定がされているか否かを確認する。送信禁止設定がされていなければ、制御部21はステップF216に進み、変更要求RQを送信部24からコンテンツサーバ装置1に対して送信させる処理を行う。送信禁止設定がされていれば、制御部21はステップF217に進み、ユーザの変更要求の操作を無効操作として処理し、変更要求RQの送信処理は行わない。以上の図19,図20の処理をコンテンツサーバ装置1及びクライアント装置2が実行することで、第3の実施の形態としての図16で説明した動作が実現される。そしてこの第3の実施の形態では、第1の実施の形態と同様の効果が得られる。即ち、パーティモードでの配信中に、各ルームR0~R3のクライアント装置2のユーザは、自由に配信コンテンツの変更の要求を行うことができる。そして、特にコンテンツ選択の争いが無ければ、そのまま変更されたコンテンツが配信される。一方で、変更要求RQが一時的に多発しても、頻繁な配信コンテンツの変更を許すのは期間TM1内の短時間のみとし、続く期間TM2はクライアント装置2側で変更要求RQを送信できないものとしている。従って、他のユーザの不快感や雰囲気の悪化が長引かない。さらに、第2の期間TM2はクライアント装置2から変更要求RQが送信できないため、その後の無用な権限争いの再発を防止できる。また、この第3の実施の形態では、クライアント装置2側で期間TM2の計数、及びそれに応じた送信禁止設定の解除が行われるため、コンテンツサーバ装置1の処理負担が軽減されるという効果も生ずる。なお、期間TM1、TM2の設定、閾値CCthの設定は、第1の実施の形態と同様に考えればよい。また争いがあった場合に、期間TM1の経過後に配信するコンテンツデータCTの選択も、第1の実施の形態と同様の変形例が考えられる。また、上記例では、期間TM2において、全てのクライアント装置2に送信禁止信号enRQを送信するものとしたが、特定のクライアント装置2にのみ送信禁止信号enRQを送信するものとしてもよい。即ち、期間TM1において変更要求RQの錯綜を生じさせたクライアント装置2のみ、送信禁止信号enRQを送信し、他のクライアント装置2は、引き続き変更要求RQの送信を可能な状態を維持させてもよい。また上記図19の処理例では、期間TM1を経過した時点での変更要求数CCと閾値CCthを比較したが、期間TM1の計時中に絶えず変更要求数CCと閾値CCthとを比較してもよい。その場合、変更要求数CCが閾値CCth以上となった時点で、期間TM1を終了とし、ステップF114、F115Aの処理、つまり元のコンテンツの配信への変更、送信禁止信号enRQの送信を行ってもよい。また、図20のクライアント装置2の処理として、ステップF217でユーザの操作を無効化する場合には、第2の実施の形態の場合と同様、例えば表示部29等で、変更要求RQの送信が禁止されていることのメッセージ表示等を行うことが好適である。<5.第4の実施の形態>[5-1:動作概要]第4の実施の形態の動作の概要を図21、図22で説明する。図21、図22は、時間軸に沿って、パーティモードで配信されているコンテンツデータCTを示している。まず、コンテンツサーバ装置1は時点t0まで、或るコンテンツデータCT-Aを全クライアント装置2に対して配信していたとする。そして時点t0において、或るクライアント装置2Bから変更要求RQがあったとする。コンテンツサーバ装置1では、このように時点t0に送信されてくる変更要求RQを受け付ける。但し、この第4の実施の形態では、コンテンツサーバ装置1は、最初の変更要求RQに応じて、すぐに配信コンテンツを変更することは行わない。ルームR0~R3の全てに対して配信されている楽曲はコンテンツデータCT-Aのままである。そして、このときコンテンツサーバ装置1は、全クライアント装置2に対して、変更要求RQがあったことを告知する告知信号ANを送信する。各クライアント装置2では、告知信号ANを受信することに応じて、メッセージ表示やメッセージ音声出力などにより、各クライアント装置2のある部屋にいるユーザに対して、或るユーザからの配信コンテンツの変更要求RQがあったことを告知する。またコンテンツサーバ装置1は、告知信号ANに、変更を求めているコンテンツデータCTの内容、例えば楽曲や曲名や映像コンテンツの名称などのタイトル情報も含めるようにし、各クライアント装置2は、それらのタイトル情報をメッセージ表示音声に含めて提示するとよい。つまり、変更要求RQを送ったユーザ以外の各ユーザが、どのようなコンテンツデータCTに切り換えられようとしているかがわかるようにするとよい。なお、ここでは全クライアント装置2に対して告知信号ANを送信する例としているが、変更要求RQを送信したクライアント装置2Bを除いて、他のクライアント装置2に対して送信するものとしてもよい。つまりクライアント装置2Bのユーザは、自分又は同じ部屋にいる人が変更要求RQを送信させたものであるから、変更要求RQの発生を承知していると考えられるためである。但し、本例では上記のように、例えば時点t0で変更要求RQを受け付けても、コンテンツサーバ装置1はすぐに配信コンテンツの変更を行わない。このため、クライアント装置2Bのユーザにとっては、変更要求RQが正しく送信されているか否か分からないことがある。そこで、クライアント装置2Bに対しても告知信号AN又は受付完了信号を送信するようにし、クライアント装置2Bにおいて、受付の旨をメッセージ表示することも適切である。本例の場合、最初に時点t0で変更要求RQを受け付けることに応じて、コンテンツサーバ装置1は、その時点t0を起点として、期間TM1の計数を行う。この期間TM1が経過する時点t4までは、さらなる変更要求の受信状況を確認する。つまり他の変更要求RQが受信されるか否かを確認する。そして、この期間TM1内に、他の変更要求RQの受信されなかった場合など、時点t0から期間TM1を経過する時点t4までの変更要求RQの受信が所定数未満であった場合に、コンテンツサーバ装置1は、変更要求RQに応じた配信コンテンツの変更を行う。例えば図22は、時点t0で変更要求RQが生じた後、期間TM1を経過するまでに他の変更要求RQが受信されなかった場合を示している。この場合、コンテンツサーバ装置1は変更要求RQの錯綜が生じていないと判断する。その場合は、時点t4以降、その時点の最新の変更要求RQに応じて、配信コンテンツの変更を行う。例えば時点t0の変更要求RQが、コンテンツデータCT-Bの配信を求めるものであったら、時点t4からコンテンツデータCT-Bの配信に切り換える。これにより、ルームR0~R3の全てで、配信されている楽曲が切り換えられることになる。一方、各クライアント装置2でのメッセージ出力により、時点t0の変更要求RQがあったことを知った他のユーザは、そのような配信コンテンツの変更を不服に思うことがある。その場合に、当該他のユーザが、図21の時点t1で、或るクライアント装置2Aに対する操作入力で、元のコンテンツデータCT-A又は他のコンテンツデータの配信を求める操作を行ったとする。クライアント装置2Aは、そのような内容の変更要求RQをコンテンツサーバ装置1に送信する。コンテンツサーバ装置1では、このように時点t1に送信されてくる変更要求RQを受け付ける。この場合もコンテンツサーバ装置1は、変更要求RQを受け付けるが、未だ期間TM1を経過していないため、時点t1では配信コンテンツの変更は行わない。その一方で、変更要求RQの受信に応じて、各クライアント装置2に対し告知信号ANを送信する。従って、他のユーザに時点t1での変更要求RQの受信及び内容が提示される。この図5では、その後、時点t2,t3などで、クライアント装置2Bのユーザと、クライアント装置2Aのユーザが、争って変更要求RQを出し合い、変更要求RQが錯綜した状態を示している。但しコンテンツサーバ装置1は、これらの変更要求RQの受信に即座に応じた配信コンテンツの変更は行っていないため、全ルームR0~R3では、流れている音楽の切り替わりは生じていない。そしてコンテンツサーバ装置1は、期間TM1を経過した時点t4で、変更要求RQの受信数を確認する。期間TM1内の変更要求RQが多発した場合、コンテンツサーバ装置1は、変更要求RQの錯綜があったとして、時点t4での配信コンテンツの変更は行わない。つまり図21での各時点t0,t1,t2,t3の変更要求RQは事後的に無効とする。このため、全ての部屋に流れている音楽コンテンツデータCT-Aは切り換えられないことになる。なお、もちろん時点t4以前、又はそれ以降で、コンテンツデータCT-Aが終了した場合曲が終わった場合は、所定の順序での次のコンテンツデータCTに切り替わることになる。またコンテンツサーバ装置1は、変更要求RQの錯綜があったと判定した場合、時点t4で、各クライアント装置2に対して変更要求の送信禁止信号enRQを送信する。これに応じて各クライアント装置2は変更要求RQの送信禁止処理を行う。つまりクライアント装置2は、ユーザが変更要求操作を行ったとしても、変更要求RQをコンテンツサーバ装置1に送信しない。各クライアント装置2側では、第2の期間TM2を計測する。即ちクライアント装置2は送信禁止信号enRQを受信したら、期間TM2の計数を行い、期間TM2が経過するまでは、変更要求RQの送信禁止設定を維持する。そして期間TM2の経過後、自主的に送信禁止設定を解除する。従ってコンテンツサーバ装置1には、第2の期間TM2の経過後は、再び変更要求RQが送信されてくる可能性が生ずる。変更要求RQがあった場合は、その最初の変更要求RQの受信から期間TM1の計数を行い、同様の処理を行うことになる。このように第4の実施の形態では、パーティモードでの配信中に、或るクライアント装置からの配信コンテンツの変更を求める変更要求RQを受信した場合、その時点では配信コンテンツの変更は行わない。そして最初の変更要求RQの受信を元に計数が開始される第1の期間TM1内に、さらなる変更要求RQの受信状況を確認する。そして期間TM1内における変更要求の受信状況に応じて期間TM1の経過後の処理を決定する。特に、期間TM1内に所定数以上の変更要求RQを検知した場合、各クライアント装置2に対し、変更要求の送信禁止信号enRQを送信する。これに応じてクライアント装置2では、自主的に期間TM2の間、変更要求RQの送信を行わないようにする。結果的に、期間TM1の経過までの変更要求RQに応じた配信コンテンツの変更は行われないことになる。一方、期間TM1内に所定数未満の変更要求RQしか検知されなかった場合、第1の期間TM1の経過後は、変更要求RQを無効とする処理を行わない。配信コンテンツも、期間TM1内の最後の変更要求RQにより変更した後のコンテンツデータの配信に切り換える。[5-2:サーバクライアントの機能構成]このような動作を実現するためのコンテンツサーバ装置1及びクライアント装置2の制御部11、21の機能構成を図23,図24に示す。図23に示すコンテンツサーバ装置1の制御部11は、機能構成として配信制御部41、カウンタ部42、閾値メモリ部43、比較部44、タイマ部45を備えることは第1~第3の実施の形態と同様である。この場合、配信制御部41は、送信禁止信号enRQを発生させ、送信部14から各クライアント装置2に送信できるようにすることに加え、変更要求RQの受信時に告知信号ANを発生させ、送信部14から各クライアント装置2に送信する点が第1~第3の実施の形態と異なる。タイマ部45は、第1の期間TM1の計測を行う機能とされる。また図24に示すクライアント装置2の制御部21については、第3の実施の形態と同様に再生制御部61、バッファ処理部62、送信制御部63、操作検知部64、タイマ部65を備え、これに加えて告知制御部66を備える。この第4の実施の形態の場合、受信部25ではコンテンツデータCT以外に、送信禁止信号enRQ及び告知信号ANが受信されることがある。受信部25で受信された送信禁止信号enRQは、送信制御部63に供給され、送信制御部63は、これらに応じて変更要求RQの送信禁止の設定を行う。具体的には送信制御部63は、送信禁止信号enRQが入力されたら送信禁止設定を行い、以降は、操作検知部64で変更要求RQの操作が検知されても、変更要求RQの送信処理を行わない。さらに、タイマ部65による期間TM2の計数を開始させる。そしてタイマ部65での期間TM2の計数が終了したら、送信制御部63は送信禁止設定を解除する。また受信部25で受信された告知信号ANは、告知制御部66に供給され、告知制御部66は、これらに応じて表示部29でのメッセージ表示の制御を行う。即ち告知制御部66は、告知信号ANに基づいて、或るクライアント装置2から変更要求RQがあったことと、変更を求めているコンテンツデータCTのタイトルを含むメッセージを、表示部29からユーザに提示させる。例えばへの変更の操作がありましたは曲名などとのメッセージ表示を実行させる。なお、メッセージ表示を行うのは、出力デバイス26におけるモニタディスプレイ上としてもよい。また、メッセージ音声を出力する場合、告知制御部66は、再生処理部22を介してメッセージ音声を出力デバイス26におけるスピーカから出力させるようにする。[5-3:サーバクライアントの処理例]この第4の実施の形態のコンテンツサーバ装置1及びクライアント装置2の処理例を説明する。まず図25でコンテンツサーバ装置1の制御部11主に配信制御部41の処理例を述べる。なお図9、図14、図19と同一の処理は同一のステップ番号を付している。ここではステップF101~F105の説明は省略し、ステップF105でパーティモードでのコンテンツ配信が開始された後の処理を説明する。パーティモードでの配信中には、制御部11は、ステップF106での変更要求RQの受信の監視、及びステップF120での配信終了トリガの監視を行う。配信終了のトリガが検知された場合、制御部11はステップF120からF123に進み、パーティモードでの配信動作を終了する処理を行う。制御部11は、ステップF106で変更要求RQの受信を検知した場合、図21,図22で説明した動作のための処理を開始することとなる。このステップF106で検知する変更要求RQとは、図21,図22における時点t0、つまり期間TM1の計数の起点となる変更要求RQのこととなる。まずステップF130で制御部11は、各クライアント装置2に対して告知信号ANを送信させる。即ち制御部21は、受信した変更要求RQの内容変更を求めるコンテンツデータCTのタイトル等を含む告知信号ANを生成し、送信部14から送信させる。また制御部11は、ステップF109で、カウンタ部42の機能として、変更要求数CCをインクリメントする。最初はCC=1とする。さらに制御部11はステップF110で、タイマ部45の機能としての期間TM1の計数処理を行う。ここではタイマ部45での計数値としてのTM1をインクリメントする。その後、計数値TM1がオーバフローとなるまで、つまり図21,図22でいう期間TM1が経過するまで、ステップF112の変更要求RQの受信の監視、及びステップF121での配信終了のトリガの監視を行いながら、ステップF110でのインクリメントを行っていく。つまり期間TM1としてのタイムカウントを進行させる。制御部11は、期間TM1が経過する前に、配信終了トリガが発生したら、ステップF121からF123に進み配信終了処理を行う。また制御部11は、期間TM1が経過する前に、他の変更要求RQが受信されたら、ステップF112からF109に戻る。この場合、制御部11はステップF109で、カウンタ部42の機能として、変更要求数CCをインクリメントする。このように、期間TM1の経過までに変更要求RQが受信される毎に、変更要求数CCのインクリメントが行われる。但し期間TM1の経過までには、配信コンテンツの変更制御は行わない。タイマ部45での計数値TM1がオーバフローし、つまり期間TM1の経過となったら、制御部11はステップF111からF113に進み、この時点で比較部44の機能による比較結果を確認する。即ち期間TM1内に、閾値CCthとしての所定数以上の変更要求RQの受信があったか否かである。もしCC<CCthであれば、制御部11は期間TM1での変更要求RQの錯綜配信コンテンツの選択の争いは生じていないとし、ステップF131に進んで、配信コンテンツの変更処理を行う。即ち制御部11は、期間TM1を経過するまでにおける最新の変更要求RQに応じた配信コンテンツの変更制御を行う。例えば図22の例の場合、コンテンツデータCT-Bの再生及び配信を、コンテンツ格納/再生部12及び送信部14に実行させる。そしてステップF119に進み、各変数、即ちこの場合は計数値TM1、変更要求数CCをリセットして、ステップF106、F120の監視ループに戻る。これは図22で説明した場合の動作となる。一方、CC≧CCthであれば、制御部11は期間TM1において変更要求RQの錯綜が生じていると判定し、ステップF115Aに進む。制御部11はステップF115Aで、変更要求の送信禁止信号enRQの送信制御を行い、送信部14から各クライアント装置2に送信禁止信号enRQを送信させる。そしてステップF119で各変数、即ち計数値TM1、変更要求数CCをリセットして、ステップF106、F120の監視ループに戻る。これは図21で説明した場合の動作となる。結局、期間TM1での変更要求RQに応じた配信コンテンツの変更は行われないことになる。なお、ステップF115Aで送信禁止信号enRQを送信した後は、ステップF119を経てステップF106、F120の監視ループに戻るが、クライアント装置2側で第2の期間TM2のカウントが完了するまでは、変更要求RQが送信されてくることはない。次にクライアント装置2の制御部21の処理例を図26で説明する。図10、図15、図20と同様の処理には同じステップ番号を付している。配信開始後のステップF204から説明する。配信開始後は、制御部21はステップF204のコンテンツデータCTの受信及び出力処理を行いながら、ステップF205での配信終了の監視処理に加え、ステップF230,F210,F221,F214の監視処理を行う。ステップF230では、告知信号ANの受信を監視する。制御部21は、コンテンツサーバ装置1からの告知信号ANを受信した場合は、ステップF231で、提示制御部66の機能により、告知信号ANに応じた提示制御を行う。例えば表示部29等でのメッセージ表示や、出力デバイス26におけるスピーカを用いたメッセージ音声出力を行う。例えばへの変更要求がありましたというようなメッセージ提示で、変更要求の発生及び変更が求められたコンテンツタイトルの表示等を行う。ステップF210では、送信禁止信号enRQの受信を監視する。制御部21は、コンテンツサーバ装置1からの送信禁止信号enRQを受信した場合は、ステップF211で変更要求RQの送信禁止設定を行う。そしてステップF220で、タイマ部65の機能による期間TM2のカウントを開始させる。ステップF221では、タイマ部65のカウント中において、TM2のカウントがオーバフローしたか否かを確認する。つまり期間TM2の経過の確認である。なお、この確認処理は、ステップF220でカウントスタートさせた以後のみの処理であり、通常時期間TM2のカウントを行っていない期間は、否定結果として処理を抜ければよい。ステップF220でカウントスタートさせた以後において、期間TM2の経過が確認された場合は、制御部21はステップF222に進み、変更要求RQの送信禁止設定を解除する。そしてステップF223で期間TM2のカウント値としての変数TM2をリセットする。ユーザ操作として、変更要求の操作を検知した場合は、制御部21はステップF214からF215に進む。そして、現在送信禁止設定がされているか否かを確認する。送信禁止設定がされていなければ、制御部21はステップF216に進み、変更要求RQを送信部24からコンテンツサーバ装置1に対して送信させる処理を行う。送信禁止設定がされていれば、制御部21はステップF217に進み、ユーザの変更要求の操作を無効操作として処理し、変更要求RQの送信処理は行わない。以上の図25,図26の処理をコンテンツサーバ装置1及びクライアント装置2が実行することで、図21,図22で説明した動作が実現される。そしてこのような第4の実施の形態では、次の効果が得られる。即ち、パーティモードでの配信中に、各ルームR0~R3のクライアント装置2のユーザは、自由に配信コンテンツの変更の要求を行うことができる。そして、特にコンテンツ選択の争いが無ければ、変更要求RQから多少の待機期間後、つまり最初の変更要求RQから期間TM1を経過した後、配信コンテンツの変更が行われる。一方で、変更要求RQが多発しても、配信コンテンツの変更は行われない。従って、配信コンテンツの変更によって他のユーザが不快に思ったり、パーティ等の雰囲気が悪化するということは生じない。つまり、第4の実施の形態では、頻繁なコンテンツ変更は生じさせないことで、他のユーザには快適な配信を提供できる。その上で、争いがなければ、或るユーザの希望に応じた配信変更が可能となるものである。さらに、第2の期間TM2はクライアント装置2から変更要求RQが送信できないため、その後の無用な権限争いの再発を防止できるという利点も生ずる。また、上記第3の実施の形態と同様、クライアント装置2側で期間TM2の計数、及びそれに応じた送信禁止設定の解除が行われるため、コンテンツサーバ装置1の処理負担が軽減される。なお、期間TM1、TM2の設定、閾値CCthの設定は、第1の実施の形態と同様に考えればよい。また、上記例では、変更要求RQの錯綜があった場合、全てのクライアント装置2に送信禁止信号enRQを送信するものとしたが、特定のクライアント装置2にのみ送信禁止信号enRQを送信するものとしてもよい。即ち、期間TM1において変更要求RQの錯綜を生じさせたクライアント装置2のみ、送信禁止信号enRQを送信し、他のクライアント装置2は、引き続き変更要求RQの送信を可能な状態を維持させてもよい。また上記図25の処理例では、期間TM1を経過した時点での変更要求数CCと閾値CCthを比較したが、期間TM1の計時中に絶えず変更要求数CCと閾値CCthとを比較してもよい。その場合、変更要求数CCが閾値CCth以上となった時点で、期間TM1を終了とし、ステップF115Aの送信禁止信号enRQの送信を行ってもよい。また、第4の実施の形態では、変更要求RQの錯綜があった場合に、第3の実施の形態と同様に、送信禁止信号enRQを送信し、クライアント装置2側で期間TM2をカウントする例を挙げたが、この際に、第1,第2の実施の形態と同様の処理を行うことも考えられる。即ち期間TM2はコンテンツサーバ装置1側でカウントしつつ、その間、変更要求RQを無効としてもよいし、或いは期間TM2の経過後に送信禁止解除信号okRQを送信するようにしてもよい。また、クライアント装置2の処理として、ステップF231の告知信号ANに基づいた提示内容は多様に考えられる。例えば変更要求がありましたというようなメッセージ提示で、変更要求の発生のみを告知しても良い。またクライアントナンバ3より変更要求がありましたというようなメッセージ提示で、変更要求の発生元も知らせるようにしても良い。また15時35分にクライアントナンバ3より変更要求がありましたというような操作時刻を含めたメッセージ提示を行っても良い。もちろん、これらのメッセージ内容とする場合は、コンテンツサーバ装置1が、当該内容の情報を告知信号ANに含めるようにすればよい。さらに、変更要求RQを行ったクライアント装置2では、変更要求RQが受け付けられたことと、変更可能性を提示してもよい。つまり、いずれにしても期間TM1を経過するまでは、配信コンテンツの変更は行われないため、配信コンテンツの変更まで、少々お待ち下さい等のメッセージ提示を行うようにすることがよい。また、ステップF217でユーザの操作を無効化する場合には、第2、第3の実施の形態の場合と同様、例えば表示部29等で、変更要求RQの送信が禁止されていることのメッセージ表示等を行うことが好適である。さらに、その場合、変更要求RQを行ったクライアント装置2については、先に送信した変更要求RQが無効とされたことになるため、変更要求はキャンセルされました変更要求が多数あったため、変更要求はキャンセルされました等のメッセージ提示を行うことも考えられる。<6.第5の実施の形態>[6-1:動作概要]第5の実施の形態の動作の概要を図27で説明する。図27は、時間軸に沿って、パーティモードで配信されているコンテンツデータCTを示している。まず、コンテンツサーバ装置1は時点t0まで、或るコンテンツデータCT-Aを全クライアント装置2に対して配信していたとする。そして時点t0において、或るクライアント装置2Bから変更要求RQがあったとする。コンテンツサーバ装置1では、このように時点t0に送信されてくる変更要求RQを受け付けるが、変更要求RQに応じて、すぐに配信コンテンツをコンテンツデータを変更することは行わない。またコンテンツサーバ装置1は、全クライアント装置2に対して、変更要求RQがあったことを告知する告知信号ANを送信する。各クライアント装置2では、告知信号ANを受信することに応じて、メッセージ表示やメッセージ音声出力などにより、各クライアント装置2のある部屋にいるユーザに対して、変更要求RQがあったことを告知する。また、最初に時点t0で変更要求RQを受け付けることに応じて、コンテンツサーバ装置1は、その時点t0を起点として、期間TM1の計数を行う。以上の点は、上記第4の実施の形態と同様である。この第5の実施の形態の場合、期間TM1が経過する時点t4までは、さらなる変更要求RQの受信状況を確認するとともに、クライアント装置2からの賛否情報信号P/Cの確認も行う。賛否情報信号P/Cとは、複数の変更要求RQが競合した場合に、競合した当事者以外のユーザが、どの変更要求に賛同するか或いはどの変更要求にも反対するかの意思表示を示す信号である。いわゆる投票と考えることができる。このためクライアント装置2では、ユーザが、提示された複数の配信コンテンツの変更について、自分の投票としての操作入力を行うことができるようにされる。その操作に応じて各クライアント装置2はコンテンツサーバ装置1に対して賛否情報信号P/Cを送信する。図27の例では、まず時点t0で変更要求RQがあり、各クライアント装置2に告知信号ANが送信される。この時点で各クライアント装置2では、コンテンツデータCT-Bへの変更要求の発生の旨を提示すると共に、変更要求に係るコンテンツデータCT-Bに賛同するか、或いは配信コンテンツを変更しないに賛同するかの投票メニューを表示させ、ユーザが操作入力可能とする。また時点t1で、2つめの変更要求RQが或るクライアント装置2Aからあったとする。コンテンツサーバ装置1は、この時点でも配信コンテンツの変更は行わないが、変更要求RQに応じて告知信号ANを各クライアント装置2に送信する。この場合のクライアント装置2Aからの変更要求RQが、コンテンツデータCT-Cへの変更要求であったら、各クライアント装置2では、コンテンツデータCT-Cへの変更要求の発生の旨を提示する。そしてそれと共に、コンテンツデータCT-Bに賛同するか、コンテンツデータCT-Cに賛同するか、或いは配信コンテンツを変更しないに賛同するかの投票メニューを表示させ、ユーザが操作入力可能とする。なお、このときのクライアント装置2Aからの変更要求RQが、現在配信中のコンテンツデータCT-Aへの変更要求つまりコンテンツデータCT-Bへの変更の拒否の内容であったら、各クライアント装置2は、コンテンツデータCT-Bに賛同するか、或いは配信コンテンツを変更しないに賛同するかの投票メニューを表示させればよい。例えばこのような提示に対し、例えば他のクライアント装置2C、2Dのユーザは、操作入力を行い、賛否情報信号P/Cを送信させる。図27では時点t2,t3に、クライアント装置2C、2Dからの賛否情報信号P/Cが受信されたことを示している。コンテンツサーバ装置1は、賛否情報信号P/Cの受信に応じて、集計処理を行う。そしてコンテンツサーバ装置1は、期間TM1を経過した時点t4以降の配信動作を、変更要求RQの受信数及び賛否情報信号P/Cの集計結果に基づいて決定する。例えば、期間TM1内の変更要求RQの受信が多発していない場合、つまり変更要求RQの受信が1回又は2回程度であった場合は、特にコンテンツの変更の争いは起きていないとして、最新の変更要求RQに応じた配信コンテンツの変更を行う。一方、期間TM1内に多数回の変更要求RQの受信があった場合は、コンテンツサーバ装置1は、変更要求RQの錯綜があったとして、時点t4での配信コンテンツの変更を、賛否情報信号P/Cの集計結果に応じて決定する。そして時点t4以降は、その集計結果に応じたコンテンツ配信を行う。このように第5の実施の形態では、パーティモードでの配信中に、或るクライアント装置からの配信コンテンツの変更を求める変更要求RQを受信した場合、その時点では配信コンテンツの変更は行わない。そして最初の変更要求RQの受信を元に計数が開始される第1の期間TM1内に、さらなる変更要求RQや賛否情報信号P/Cを確認する。そして期間TM1内における変更要求の受信状況や賛否情報信号P/Cの集計結果に応じて期間TM1の経過後の処理を決定する。この場合、配信コンテンツを決定する。[6-2:サーバクライアントの機能構成]このような動作を実現するためのコンテンツサーバ装置1及びクライアント装置2の制御部11、21の機能構成を図28,図29に示す。図28に示すコンテンツサーバ装置1の制御部11は、機能構成として配信制御部41、カウンタ部42、閾値メモリ部43、比較部44、タイマ部45を備える。これらの各機能は第4の実施の形態と同様である。これに加えて、集計部46を備える。受信部15では、変更要求RQ以外に、賛否情報信号P/Cを受信することがある。受信された賛否情報信号P/Cは集計部46に供給され、集計処理される。集計結果は配信制御部41に供給される。また図29に示すクライアント装置2の制御部21については、再生制御部61、バッファ処理部62、送信制御部63、操作検知部64、告知制御部66を備える。再生制御部61、バッファ処理部62、送信制御部63、操作検知部64の各機能は上記第1の実施の形態と同様である。また告知制御部66は、上記第4の実施の形態の場合と同様の変更要求RQの提示制御に加え、この第5の実施の形態の場合、投票メニューの表示等の制御も行う。[6-3:サーバクライアントの処理例]この第5の実施の形態のコンテンツサーバ装置1及びクライアント装置2の処理例を説明する。まず図30でコンテンツサーバ装置1の制御部11主に配信制御部41の処理例を述べる。なお図9、図14、図19、図25と同一の処理は同一のステップ番号を付している。ここではステップF101~F105の説明は省略し、ステップF105でパーティモードでのコンテンツ配信が開始された後の処理を説明する。パーティモードでの配信中には、制御部11は、ステップF106での変更要求RQの受信の監視、及びステップF120での配信終了トリガの監視を行う。配信終了のトリガが検知された場合、制御部11はステップF120からF123に進み、パーティモードでの配信動作を終了する処理を行う。制御部11は、ステップF106で変更要求RQの受信を検知した場合、図27で説明した動作のための処理を開始する。このステップF106で検知する変更要求RQとは、図27における時点t0、つまり期間TM1の計数の起点となる変更要求RQのこととなる。まずステップF130で制御部11は、各クライアント装置2に対して告知信号ANを送信させる。即ち制御部21は、受信した変更要求RQの内容変更を求めるコンテンツデータCTのタイトル等を含む告知信号ANを生成し、送信部14から送信させる。また制御部11は、ステップF109で、カウンタ部42の機能として、変更要求数CCをインクリメントする。さらに制御部11はステップF110で、タイマ部45の機能としての期間TM1の計数処理を行う。ここではタイマ部45での計数値としてのTM1をインクリメントする。その後、計数値TM1がオーバフローとなるまで、つまり図27でいう期間TM1が経過するまで、ステップF112の変更要求RQの受信の監視、ステップF141での賛否情報信号P/Cの受信の監視、及びステップF121での配信終了のトリガの監視を行いながら、ステップF110でのインクリメントを行っていく。つまり期間TM1としてのタイムカウントを進行させる。制御部11は、期間TM1が経過する前に、配信終了トリガが発生したら、ステップF121からF123に進み配信終了処理を行う。また制御部11は、期間TM1が経過する前に、他の変更要求RQが受信されたら、ステップF112からF109に戻る。この場合、制御部11はステップF109で、カウンタ部42の機能として、変更要求数CCをインクリメントする。このように、期間TM1の経過までに変更要求RQが受信される毎に、変更要求数CCのインクリメントが行われる。但し期間TM1の経過までには、配信コンテンツの変更制御は行わない。また制御部11は、期間TM1が経過する前に、賛否情報信号P/Cが受信されたら、ステップF141からF142に進み、集計部46の機能により集計処理を行う。例えばその時点での1又は複数の変更要求RQにかかるコンテンツ及びコンテンツ変更しないについて票を計上する処理を行う。タイマ部45での計数値TM1がオーバフローし、つまり期間TM1の経過となったら、制御部11はステップF111からF113に進み、この時点で比較部44の機能による比較結果を確認する。即ち期間TM1内に、閾値CCthとしての所定数以上の変更要求RQの受信があったか否かである。もしCC<CCthであれば、制御部11は期間TM1での変更要求RQの錯綜配信コンテンツの選択の争いは生じていないとし、ステップF145に進んで、配信コンテンツの変更処理を行う。即ち制御部11は、期間TM1を経過するまでにおける最新の変更要求RQに応じた配信コンテンツの変更制御を行う。例えば期間TM1を経過するまでの中で最新の変更要求RQがコンテンツデータCT-Bを求めるものであったら、コンテンツデータCT-Bの再生及び配信を、コンテンツ格納/再生部12及び送信部14に実行させる。そしてステップF119に進み、各変数、即ち計数値TM1、変更要求数CCをリセットして、ステップF106、F120の監視ループに戻る。一方、CC≧CCthであれば、制御部11は期間TM1において変更要求RQの錯綜が生じていると判定し、ステップF143に進む。制御部11はステップF143で、争いがあった複数の変更要求RQについての、賛否情報信号P/Cによる投票の集計結果を確認し、それによって配信コンテンツを決定する。そしてステップF145に進んで、集計結果に応じた決定に基づく配信コンテンツの変更処理を行う。そしてステップF119に進み、各変数、即ち計数値TM1、変更要求数CCをリセットして、ステップF106、F120の監視ループに戻る。次にクライアント装置2の処理を図31で説明する。図10、図15、図20、図27と同様の処理には同じステップ番号を付している。配信開始後のステップF204から説明する。配信開始後は、制御部21はステップF204のコンテンツデータCTの受信及び出力処理を行いながら、ステップF205での配信終了の監視処理に加え、ステップF230,F210,F221,F214の監視処理を行う。ステップF206では、ユーザによる変更要求の操作入力を監視する。ユーザ操作として、変更要求の操作を検知した場合は、制御部21はステップF206からF207に進み、変更要求RQを送信部24からコンテンツサーバ装置1に対して送信させる処理を行う。ステップF241では、投票メニュー表示に対するユーザによる賛否情報の操作入力を監視する。ユーザ操作として、賛否情報の操作入力を検知した場合は、制御部21はステップF241からF242に進み、賛否情報信号P/Cを送信部24からコンテンツサーバ装置1に対して送信させる処理を行う。ステップF243では、告知信号ANの受信を監視する。制御部21は、コンテンツサーバ装置1からの告知信号ANを受信した場合は、ステップF244で、提示制御部66の機能により、告知信号ANに応じた提示制御を行う。例えば表示部29等でのメッセージ表示や、出力デバイス26におけるスピーカを用いたメッセージ音声出力を行う。さらに制御部21は、メッセージ表示制御と共に、表示部29や出力デバイス26におけるモニタディスプレイを用いて、投票メニューの表示を実行させる。この投票メニュー表示に対して、ユーザは賛否情報の入力を行うことができる。以上の図30,図31の処理をコンテンツサーバ装置1及びクライアント装置2が実行することで、図27で説明した動作が実現される。そしてこのような第5の実施の形態では、次の効果が得られる。即ち、パーティモードでの配信中に、各ルームR0~R3のクライアント装置2のユーザは、自由に配信コンテンツの変更の要求を行うことができる。一方で、変更要求RQが多発しても、期間TM1を経過するまでは配信コンテンツの変更は行われない。従って、配信コンテンツの頻繁な変更によって他のユーザが不快に思ったり、パーティ等の雰囲気が悪化するということは生じない。なお、期間TM1の設定、閾値CCthの設定は、第1の実施の形態と同様に考えればよい。また図30の処理ではコンテンツサーバ装置1はステップF143で集計結果から配信コンテンツの決定を行うが、このときの集計及び決定の手法、或いは賛否情報信号P/Cの送受信に関しては多様な例が考えられる。まず、各クライアント装置2のユーザに対しては、変更要求RQが発生した場合に投票メニューの表示が行われるが、必ずしも各クライアント装置2のユーザが投票の操作を行うとは限らない。そこで、賛否情報信号P/Cを送信してこなかったクライアント装置2については、変更容認変更しない無効票などの解釈があり得る。例えば投票メニューが或るコンテンツデータCTへの変更を支持変更を不支持というような場合は、表示賛否情報信号P/Cを送信してこなかったクライアント装置2の票は、変更を支持とみなしてもよい。また投票メニューがコンテンツデータCT-Bへ変更コンテンツデータCT-Cへ変更変更しないのようなものであれば、表示賛否情報信号P/Cを送信してこなかったクライアント装置2の票は、変更しないとみなしてもよい。また投票メニューがコンテンツデータCT-Bへ変更コンテンツデータCT-Cへ変更のようなものであれば、表示賛否情報信号P/Cを送信してこなかったクライアント装置2の票は、無効票とみなすことが考えられる。もちろんこれらは一例であるが、このようにすると、配信コンテンツに無関心なユーザについての意志として適している。また、変更要求RQの発生数に応じて、投票内容も各種考えられる。図27の例に即した例でいえば、時点t0~t1では変更要求RQが1つ発生している。このときクライアント装置2では、変更容認変更しないの投票メニューを表示し、ユーザの投票操作を求める。そして投票操作に応じて賛否情報信号P/Cを送信する。時点t1では2つめの変更要求RQが発生している。そこで時点t1以降は、クライアント装置2では、コンテンツデータCT-Bへ変更コンテンツデータCT-Cへ変更変更しないの投票メニューに切り換え、ユーザの投票操作を求める。そして投票操作に応じて賛否情報信号P/Cを送信する。その後、時点t2,t3では賛否情報信号P/Cがコンテンツサーバ装置1に受信されるが、それは、時点t1以降の投票メニューに対するものとして集計する。なお、時点t0~t1の間に、或るクライアント装置2からの賛否情報信号P/Cが受信される場合もある。コンテンツサーバ装置1は、時点t1で投票メニューが切り替わることに応じて、時点t1以前の賛否情報信号P/Cは無効としてもよいし、例えば同じ選択肢の票として集計することとしてもよい。例えば時点t1より前に或るクライアント装置2から変更容認の賛否情報信号P/Cが受信されており、それがコンテンツデータCT-Bへの変更を容認するものであったら、時点t1以降の投票メニューにおけるコンテンツデータCT-Bへ変更への票として計上する。例えばこのように、変更要求RQの数に応じて、投票メニューを切り換えていきながら、期間TM1の終了時点での集計を行い、時点t4以降、最多票の選択肢に応じた配信を行うようにする。なお、既に1回賛否情報信号P/Cを送信していたクライアント装置2から、再度の賛否情報信号P/Cが受信されたら、コンテンツサーバ装置1はそれを無効としてもよいし、或いは最新の賛否情報信号P/Cを有効として以前の賛否情報信号P/Cは無効としてもよい。また、クライアント装置2側では、所定数以上、例えば2以上の変更要求RQがあったときのみ、投票メニューの表示を行い、ユーザに賛否情報信号P/Cの送信の操作を求めるようにしても良い。例えば図31のステップF244の処理として、1回目の告知信号ANの受信時には、変更要求発生のメッセージ表示のみとし、2回目以降の告知信号ANの受信時には、変更要求発生のメッセージと共に、投票メニューの表示を行う。この場合、ユーザは、2以上の変更要求の内容を含む選択肢に対して、所望の投票操作を行う。特に、変更要求RQの錯綜が生じたときに他のユーザの投票で配信コンテンツを決めるという考え方においては、このような処理が適している。また、変更要求RQを送信したクライアント装置2については、投票メニューの表示及び賛否情報信号P/Cの送信を実行できないようにすることも考えられる。ユーザが自己の変更要求RQに賛成する投票を防ぐためである。なお、図27で説明した例では、期間TM1を経過した後も、各クライアント装置2からは任意に変更要求RQを送信することができる。これに対して時点t4以降、第1、第2,第3の実施の形態の手法を用いて、期間TM2において変更要求RQを禁止しても良い。また、期間TM1を経過した後、コンテンツサーバ装置1は集計結果を各クライアント装置2に通知し、各クライアント装置2で集計結果の提示を行うことも考えられる。<7.第6の実施の形態>[7-1:動作概要]第6の実施の形態の概要を図32で説明する。上記第1~第5の実施の形態では、全部の部屋でパーティモードを継続するという前提の動作であるが、この第6の実施の形態は、変更要求RQを送信したクライアント装置2をパーティモードから離脱させる動作である。即ち当該クライアント装置2のみ、オンデマンドモードとして、その部屋だけに要求されたコンテンツデータCTを配信する。図32は、時間軸に沿って、配信されているコンテンツデータCTを示している。まず、コンテンツサーバ装置1は時点t0まで、パーティモードで或るコンテンツデータCT-Aを全クライアント装置2に対して配信していたとする。そして時点t0において、或るクライアント装置2Bから変更要求RQがあったとする。コンテンツサーバ装置1では、このように時点t0に送信されてくる変更要求RQを受け付ける。そしてクライアント装置2Bをパーティモードから切り離し、オンデマンドモードとして、クライアント装置2Bにのみ、要求されたコンテンツデータCT-Xを配信する。他のクライアント装置2に対しては、パーティモードを継続し、例えばコンテンツデータCT-Aの配信を継続する。また例えば時点t1でコンテンツデータCT-Aが終了曲の終了したら、そのパーティモードにおける所定の順序或いはランダム選定として決められる次の曲コンテンツデータCT-Bの配信を行う。一方、クライアント装置2Bに対してオンデマンド配信されているコンテンツデータCT-Xが、時点t2で終了したとする。この場合、コンテンツサーバ装置1は、クライアント装置2Bをパーティモードに復帰させる。従って時点t2以降は、クライアント装置2Bを含めて全クライアント装置2に、コンテンツデータCT-Bが配信されることになる。このように第6の実施の形態では、パーティモードでの配信中に、或るクライアント装置2Bからの配信コンテンツの変更を求める変更要求RQを受信した場合、当該変更要求RQの送信元のクライアント装置2B以外のクライアント装置2に対する共通のコンテンツ配信は継続する。そして変更要求RQの送信元のクライアント装置2Bのみに対して、変更要求RQに応じたコンテンツデータを配信する。また、変更要求RQに応じたコンテンツデータの送信を終了した後は、変更要求RQの送信元のクライアント装置2Bを、他のクライアント装置2と共通のコンテンツデータの配信先に復帰させる。[7-2:サーバクライアントの機能構成]このような動作を実現するためのコンテンツサーバ装置1の制御部11の機能構成を図33に示す。図33に示すコンテンツサーバ装置1の制御部11は、機能構成として配信制御部41、変更要求認識部47、クライアント管理部48を備える。配信制御部41は、パーティモードやオンデマンドモードでの配信動作を制御する機能部位である。配信制御部41は、コンテンツ格納/再生部12に対して、配信するコンテンツデータCTを指定して再生を実行させ、再生されたコンテンツデータCTを送信部14から各クライアント装置2に配信させる制御を行う。変更要求認識部47は、受信部15で受信されて制御部11に供給されるクライアント装置2からの変更要求RQを認識し、その情報、つまり送信元のクライアント装置2及び配信を求めるコンテンツデータCTの情報をクライアント管理部48に伝える。クライアント管理部48は、クライアント装置2毎の配信モードを管理する。即ち各クライアント装置2について、パーティモードとしてのグループに入れているか、個別のオンデマンドモードとするかを設定する。そしてその各クライアント装置2のモードを配信制御部41に伝える。具体的には、パーティモード配信先の各クライアント装置2と、オンデマンド配信先のクライアント装置2のIPアドレスの通知などを行う。またクライアント管理部48は、或るクライアント装置2に対してオンデマンドモードでの配信が終了した場合は、そのクライアント装置2をパーティモードに復帰させるよう配信制御部41に指示する。なお、クライアント装置2の制御部21の機能構成は、第1の実施の形態の図8と同様になるため、説明を省略する。[7-3:サーバクライアントの処理例]この第6の実施の形態のコンテンツサーバ装置1の処理例を説明する。図34でコンテンツサーバ装置1の制御部11主に配信制御部41の処理例を示している。なお図9、図14、図19、図25、図30と同一の処理は同一のステップ番号を付している。ここではステップF101~F105の説明は省略し、ステップF105でパーティモードでのコンテンツ配信が開始された後の処理を説明する。パーティモードでの配信中には、制御部11は、ステップF106での変更要求RQの受信の監視、及びステップF120での配信終了トリガの監視を行う。また特に、或るクライアント装置2に対してオンデマンドモード配信の実行中については、監視ループは、ステップF153からF154に進み、要求されたコンテンツデータCTの配信が終了したか否かを監視する。制御部11は、ステップF106で、上記変更要求認識部47の機能で変更要求RQの受信を検知した場合、ステップF151に進む。そして制御部11は、クライアント管理部48の機能により、変更要求RQの送信元のクライアント装置2について、パーティモードから離脱させる処理を行う。そして制御部11はステップF152で、配信制御部41の機能により、その離脱させたクライアント装置2に対して、要求されたコンテンツデータCTを配信を開始させる。即ち制御部11は、他のクライアント装置2に対するパーティモードでの配信のための再生動作及び送信動作を、コンテンツ格納/再生部12,送信部14に実行させつつ、さらに要求元のクライアント装置2に対するオンデマンド配信のための、コンテンツデータCTの再生及び送信を実行させる。これによって、図32の時点t1以降の配信動作が行われる。そして制御部11はステップF106からの監視ループに戻る。オンデマンド配信実行中には、制御部11はステップF154で要求されたコンテンツデータCTの配信終了を監視している。要求されたコンテンツデータCTの配信が終了したら、制御部11はステップF155に進み、オンデマンド配信先としていたクライアント装置2をパーティモードに復帰させる。これにより図32の時点t2以降のように、当該クライアント装置2を含めたパーティモード配信状態となる。そして制御部11はステップF106からの監視ループに戻る。制御部11は、ステップF120でパーティモードでの配信終了のトリガが検知された場合はステップF123に進み、パーティモードでの配信動作を終了する処理を行う。なお、この第6の実施の形態の場合、クライアント装置2の処理は、第1の実施の形態で説明した図10と同様となるため、説明を省略する。上記図34の処理をコンテンツサーバ装置1が行い、またクライアント装置2が図10の処理を行うことで、図32で説明した動作が実現される。そしてこのような第6の実施の形態では、次の効果が得られる。即ち第6の実施の形態では、パーティモードでの各部屋のコンテンツ配信を邪魔することなしに、コンテンツの変更要求RQを行った部屋クライアント装置2の要求にも応じることができる。これにより、パーティモード配信を実行しながら、他人に全く迷惑を掛けずに、個々のユーザの要望に的確に答えることができる。例えばパーティ中にあるアーテイストのあるコンテンツの話題になり、その部屋でそのコンテンツの視聴をしたい場合には、他の部屋の再生しているコンテンツを邪魔することなく、その部屋だけでそのコンテンツを視聴しながら会話を楽しむなどが可能となる。さらにこの場合、複数のクライアント装置2からの変更要求RQの錯綜などの無用な争いも生じない。また、パーティモードから離脱したクライアント装置2に対する要求に応じたコンテンツCTの配信を終了した後は、自動的にパーティモードに復帰させる処理を行うことで、ユーザの操作負担もなく、パーティモード配信を適切に継続できる。なお実施の形態では、クライアント装置2からの変更要求RQに応じて、そのクライアント装置2をパーティモードから離脱させるものとしたが、クライアント装置2側でパーティモードとオンデマンドモードを選択できるようにしてもよい。例えば図35のように、各クライアント装置2において、パネル操作部27にOndemandとPartyの操作キーを設け、ユーザが選択操作可能とする。もちろん、1つのキーのトグル操作で交互にパーティモードとオンデマンドモードを切り換えるようにしてもよい。また表示部27等にOndemandとPartyの操作アイコンを表示させ、タッチパネル操作等でユーザが選択可能としてもよい。またリモートコマンダー3の操作によるものとしても良い。この場合、コンテンツサーバ装置1は、まずパーティモード動作として、コンテンツデータCTを各部屋に配信する。パーティモードから離脱したい部屋クライアント装置2のユーザは、操作によりオンデマンドモードを選択する。クライアント装置2はその操作に応じてパーティモードでの受信/再生を中止し、パーティモードから一旦離脱する。その後オンデマンドモード下で所望のコンテンツ配信を要求するようにすればよい。また、オンデマンドモード下で所望のコンテンツ配信を行っている最中に再びパーティモードに復帰したくなったら、ユーザは、操作によりパーティモードを指定することでパーティモードに復帰するようにしてもよい。<8.プログラム>本開示の実施の形態のプログラムは、コンテンツサーバ装置1の制御部11マイクロコンピュータに、図9、図14、図19、図25、図30、又は図34の処理を実行させるプログラムである。また実施の形態のプログラムは、クライアント装置2の制御部21マイクロコンピュータに図10、図15、図20、図26、又は図31の処理を実行させるプログラムである。これらのプログラムにより、上述した効果を得るコンテンツサーバ装置1、クライアント装置2を、特別な専用装置を用いずに実現できる。例えばパーソナルコンピュータ等を用いてコンテンツサーバ装置1、クライアント装置2を実現することもできる。さらに、そのようなプログラムが記録されたプログラム記録媒体によれば、コンテンツ再生機器等において、実施の形態のコンテンツサーバ装置1、クライアント装置2を実現することも容易となる。本実施の形態のプログラムは、パーソナルコンピュータや、撮像装置等の機器に内蔵されている記録媒体としてのHDDや、CPUを有するマイクロコンピュータ内のROM等に予め記録しておくことができる。あるいはまた、フレキシブルディスク、CD-ROM、MOディスク、DVD、ブルーレイディスクBlurayDisc:登録商標、磁気ディスク、半導体メモリ、メモリカードなどのリムーバブル記録媒体に、一時的あるいは永続的に格納記録しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。また、本開示のプログラムは、リムーバブル記録媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、LAN、インターネットなどのネットワークを介してダウンロードすることもできる。なお本技術は以下のような構成も採ることができる。1ネットワーク通信が可能とされた複数のクライアント装置との間で通信を行う通信部と、コンテンツデータの再生を行う再生部と、上記再生部で再生されたコンテンツデータを上記通信部から各クライアント装置に対して共通に配信させるとともに、共通のコンテンツを配信中に、上記通信部によりクライアント装置からの配信コンテンツの変更を求める変更要求を受信した場合、或るクライアント装置からの当該受信を元に計数が開始される第1の期間内に他のクライアント装置からのさらなる変更要求の受信状況を確認し、上記第1の期間内における変更要求の受信状況に応じて上記第1の期間の経過後の処理を決定する制御部と、を備えたサーバ装置。2上記制御部は、上記第1の期間内に所定数以上の変更要求を検知した場合、上記第1の期間の経過後に計数が開始される第2の期間は、受信される変更要求を無効とする処理を行う上記1に記載のサーバ装置。3上記制御部は、上記第1の期間内に所定数以上の変更要求を検知した場合、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止信号を送信させる上記1又は2に記載のサーバ装置。4上記制御部は、上記第1の期間内に所定数以上の変更要求を検知した場合、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止信号を送信させ、さらに、上記第1の期間の経過後に計数が開始される第2の期間の経過後、上記通信部により、全部又は一部のクライアント装置に対し、新たな変更要求の送信禁止解除信号を送信させる上記1乃至3のいずれかに記載のサーバ装置。5上記制御部は、上記第1の期間の経過時点までに受信された有効な変更要求を決定し、該有効な変更要求に関するコンテンツデータを再生するよう上記再生部を制御し、各々のクライアント装置に再生されたコンテンツデータを送信するよう上記送信部を制御する上記1乃至4のいずれかに記載のサーバ装置。6上記制御部は、上記第1の期間内に所定数以上の変更要求を検知した場合、上記第1の期間の開始前に配信していたコンテンツデータ配信を継続するように上記再生部を制御し、上記通信部から各クライアント装置に対して送信するように上記通信部を制御する上記5に記載のサーバ装置。7上記制御部は、上記第1の期間の経過までに受信された変更要求に対しては、その変更要求に応じた配信コンテンツの変更制御は行わない上記1乃至6のいずれかに記載のサーバ装置。8上記制御部は、上記第1の期間内に所定数以上の変更要求を検知した場合、上記第1の期間の経過後も、上記第1の期間内に検知した変更要求に応じた配信コンテンツの変更制御は行わない上記7に記載のサーバ装置。9上記制御部は、上記第1の期間内に所定数未満の変更要求を検知した場合、上記第1の期間の経過後は、上記第1の期間内に最後に検知した変更要求に応じたコンテンツデータを再生するよう上記再生部を制御し、上記通信部から各クライアント装置に対して送信するよう上記通信部を制御する上記7又は8に記載のサーバ装置。10上記制御部は、上記第1の期間の経過時点までにおける変更要求の受信に対応して、該変更要求を告知する告知信号を、上記通信部から全部又は一部のクライアント装置に対して送信させる上記7乃至10のいずれかに記載のサーバ装置。11上記制御部は、上記第1の期間内に、上記告知信号の送信後、上記通信部によりクライアント装置からの賛否情報信号が受信されることに応じて、賛否情報の集計処理を行い、該集計処理結果に基づいて、上記第1の期間の経過後の配信コンテンツを決定する上記10に記載のサーバ装置。"