JP3926513B2 - 情報配信装置、情報配信方法および情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体 - Google Patents
情報配信装置、情報配信方法および情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体 Download PDFInfo
- Publication number
- JP3926513B2 JP3926513B2 JP22574099A JP22574099A JP3926513B2 JP 3926513 B2 JP3926513 B2 JP 3926513B2 JP 22574099 A JP22574099 A JP 22574099A JP 22574099 A JP22574099 A JP 22574099A JP 3926513 B2 JP3926513 B2 JP 3926513B2
- Authority
- JP
- Japan
- Prior art keywords
- distribution
- receiving devices
- information
- receive
- inquiry
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/55—Push-based network services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、リアルタイム再生が可能なコンテンツ情報（動画データ、音声データ）を複数の受信装置へ配信する情報配信装置、情報配信方法および情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体に関するものであり、特に、配信者側で当該コンテンツ情報の受信者数を把握することが可能な情報配信装置、情報配信方法および情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体に関するものである。
【０００２】
近時、インターネットやイントラネットの普及により、従来のテレビジョン放送と同様にして、講演会やコンサートの様子をライブ放送するシステムが注目されている。このシステムにおいては、ストリーミング技術により、画像データおゆび音声データから、受信装置側でリアルタイム再生が可能なコンテンツ情報を生成し、このコンテンツ情報をインターネット等を介して複数の受信装置へ一斉に配信している。このような単向方式の通信環境下では、配信者側で、当該コンテンツ情報を受信する、受信しないといった受信者側の情報が得られない。このことから、従来より、ライブ放送を効果的に実現するために、配信者側で受信者側の情報を把握する手段、方法が切望されている。
【０００３】
【従来の技術】
従来より、インターネットやイントラネットの環境下においては、講演会やコンサードの様子をコンテンツ情報（動画、音声）として、リアルタイムで受信者に配信する情報配信システムが普及しつつある。この情報配信システムは、講演会、コンサートの会場にそれぞれ設置されたビデオカメラおよびマイクと、ビデオカメラおよびマイクからの画像データおよび音声データから、ストリーミング技術を用いてリアルタイム再生が可能なストリーミングパケット（コンテンツ情報）を生成し、これを複数の受信装置へインターネット等を介して配信する配信装置とを備えている。
【０００４】
また、複数の受信装置では、ストリーミングパケットをそれぞれ受信し、リアルタイムでコンテンツ情報（動画、音声）を再生する。このように、情報配信システムは、インターネット等に接続された受信装置さえあれば、リアルタイムでコンテンツ情報の配信を受けることができることから、近時、注目されている。
【０００５】
【発明が解決しようとする課題】
ところで、情報配信システムを用いてライブ放送を企画する際には、通常、配信者側（主催者側）は、事前に、電子メール、ホームページ、紙媒体等の広告媒体を用いて、ライブ放送が開始される日時を宣伝することで、ライブ放送の受信者の数を増加させる努力をしている。
【０００６】
しかしながら、従来においては、伝送方式が単方向方式（配信装置→受信装置）であるため、実際にライブ放送を視聴する受信者の実数を配信者側で把握する手段が存在しない。したがって、実際には、ライブ放送を行うのに十分な数の受信者がいるという前提で、ライブ放送を開始していた。このように、受信者数を正確に把握できない状況では、受信者がほとんどいないにもかかわらずライブ放送が行われてしまうことも想定され、このような状況下では、まったく意味をなさないライブ放送を無駄に行ってしまうという問題があった。
【０００７】
本発明は、上記に鑑みてなされたもので、配信者側で情報の配信を受ける受信者の数を正確に把握でき、この把握結果に基づいて効果的に情報の配信を行うことができる情報配信装置、および情報配信方法および情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するために、請求項１にかかる発明は、ライブ放送を複数の受信装置（後述する実施の形態３の受信装置６０1 〜６０m に相当）へ配信する情報配信装置において、ライブ放送の配信を開始する前に、前記複数の受信装置に対して前記ライブ放送の配信を受けるか否かを問い合わせる問い合わせ手段（後述する実施の形態３の配信制御部３２に相当）と、前記複数の受信装置に対して前記問い合わせが行われてからの待機時間を計時する計時手段（後述する実施の形態３のタイマ８２に相当）と、前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計手段（後述する実施の形態３の集計制御部３７に相当）と、前記待機時間とあらかじめ設定された待機時間設定値とを比較する第１の比較手段（後述する実施の形態３の集計制御部８１に相当）と、前記集計結果に基づいて、前記配信を受ける受信装置の数とあらかじめ設定された配信開始しきい値とを比較する第２の比較手段（後述する実施の形態３の集計制御部８１に相当）と、前記第１の比較手段および前記第２の比較手段のそれぞれの比較結果に基づいて、前記待機時間が前記待機時間設定値以上であって、かつ前記配信を受ける受信装置の数が前記配信開始しきい値に満たない場合、前記配信を中止する配信制御手段（後述する実施の形態３の配信制御部３２に相当）とを備えることを特徴とする。
【０００９】
この請求項１にかかる発明によれば、ライブ放送の配信を開始する前に、問い合わせ手段により、複数の受信装置に対して配信を受けるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、集計手段に対して、配信を受ける旨の回答または配信を受けない旨の回答をそれぞれ出す。これにより、集計手段は、複数の受信装置から順次回答される結果を集計し、配信を受ける受信装置の数、配信を受けない受信装置の数を集計する。また、このとき、第１の比較手段により、待機時間と待機時間設定値とが比較されるとともに、第２の比較手段により、配信を受ける受信装置の数と配信開始しきい値とが比較される。そして、配信制御手段は、待機時間が待機時間設定値以上になり、かつ配信を受ける受信装置の数が配信開始しきい値に満たない場合、ライブ放送の配信を中止する。
【００１０】
このように、請求項１にかかる発明によれば、第１の比較手段を設けて、待機時間と待機時間設定値とを比較し、さらに第２の比較手段を設けて、配信を受ける受信装置の数と配信開始しきい値以上とを比較し、これら２つの比較結果に基づいて、ライブ放送の配信中止の可否を判断するようにしたので、経過時間を過ぎてもなお、配信を受ける受信装置の数が配信開始しきい値に満たない場合に、自動的にライブ放送の配信を中止することができる。
【００１１】
また、請求項２にかかる発明は、請求項１に記載の情報配信装置において、配信者に前記集計結果を報知する報知手段（後述する実施の形態３の表示部３６に相当）を備えることを特徴とする。
【００１２】
この請求項２にかかる発明によれば、報知手段により回答の集計結果が報知される。したがって、配信者は、報知された集計結果に基づいて、配信を行うかまたは中止するかを判断することが可能となる。
【００１３】
このように、請求項２にかかる発明によれば、報知手段により回答の集計結果を報知するようにしたので、配信者側で、配信を受ける受信者（受信装置）の数を正確に把握することができ、この把握結果に基づいて、配信を開始または中止するかを判断することができる。
【００１４】
また、請求項３にかかる発明は、請求項１または２に記載の情報配信装置において、前記集計結果に基づいて、前記配信を受ける受信装置の数とあらかじめ設定された配信決定しきい値とを比較する第３の比較手段（後述する実施の形態２の集計制御部７１に相当）を備え、前記配信制御手段は、前記第３の比較手段の比較結果に基づいて、前記配信を受ける受信装置の数が前記配信決定しきい値以上になった時点で、前記配信を行うこととすることを特徴とする。
【００１５】
この請求項３にかかる発明によれば、ライブ放送の配信を開始する前に、問い合わせ手段により、複数の受信装置に対して配信を受けるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、集計手段に対して、配信を受ける旨の回答または配信を受けない旨の回答をそれぞれ出す。これにより、集計手段は、複数の受信装置から順次回答される結果を集計し、配信を受ける受信装置の数、配信を受けない受信装置の数を集計する。また、このとき、第３の比較手段により、配信を受ける受信装置の数と配信決定しきい値とが比較される。そして、配信制御手段は、配信を受ける受信装置の数が配信決定しきい値以上になった時点で、情報の配信を行うこととする。
【００１６】
このように、請求項３にかかる発明によれば、第３の比較手段を設けて、配信を受ける受信装置の数と配信決定しきい値以上とを比較し、この比較結果に基づいて、ライブ放送の配信開始の可否を判断するようにしたので、配信者の判断を待たずに、自動的にライブ放送の配信を行うことができる。
【００１７】
また、請求項４にかかる発明は、請求項１または２に記載の情報配信装置において、前記集計結果に基づいて、前記配信を受けない受信装置の数とあらかじめ設定された配信中止しきい値とを比較する第４の比較手段（後述する実施の形態２の集計制御部７１に相当）を備え、前記配信制御手段は、前記比較手段の比較結果に基づいて、前記配信を受けない受信装置の数が前記配信中止しきい値以上になった時点で、前記配信を中止することを特徴とする。
【００１８】
この請求項４にかかる発明によれば、ライブ放送の配信を開始する前に、問い合わせ手段により、複数の受信装置に対して配信を受けるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、集計手段に対して、配信を受ける旨の回答または配信を受けない旨の回答をそれぞれ出す。これにより、集計手段は、複数の受信装置から順次回答される結果を集計し、配信を受ける受信装置の数、配信を受けない受信装置の数を集計する。また、このとき、第４の比較手段により、配信を受けない受信装置の数と配信中止しきい値とが比較される。そして、配信制御手段は、配信を受けない受信装置の数が配信中止しきい値以上になった時点で、ライブ放送の配信を中止する。
【００１９】
このように、請求項４にかかる発明によれば、第４の比較手段を設けて、配信を受けない受信装置の数と配信中止しきい値以上とを比較し、この比較結果に基づいて、ライブ放送の配信中止の可否を判断するようにしたので、配信者の判断を待たずに、自動的にライブ放送の配信を中止することができる。
【００２０】
また、請求項５にかかる発明は、リアルタイム再生が可能な情報を複数の受信装置（後述する実施の形態４の受信装置９０ 1 〜９０ m に相当）へ配信する情報配信装置において、緊急情報の配信を開始する前に、前記複数の受信装置に対して前記緊急情報を受信することが可能であるか否かを問い合わせる問い合わせ手段（後述する実施の形態４の配信制御部３２に相当）と、前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計手段（後述する実施の形態４の集計制御部３７に相当）と、前記集計手段の集計結果に基づいて、緊急情報の配信を開始または中止する配信制御手段（後述する実施の形態４の配信制御部３２に相当）とを備えることを特徴とする。
【００２１】
この請求項５にかかる発明によれば、緊急情報の配信を開始する前に、問い合わせ手段により、複数の受信装置に対して前記情報を受信することが可能であるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、装置の状態を確認した後、集計手段に対して、緊急情報を受信することが可能であるか否かの回答をそれぞれ出す。これにより、集計手段は、複数の受信装置から順次回答される結果を集計し、配信を受けることが可能な受信装置の数、配信を受けることができない受信装置の数を集計する。そして、配信制御手段は、集計手段の集計結果に基づいて、緊急情報の配信を開始または中止する。
【００２２】
このように、請求項５にかかる発明によれば、複数の受信装置に対して緊急情報を受信することが可能であるか否かの問い合わせを行い、問い合わせに対応する回答の集計結果に基づいて、緊急情報の配信を開始または中止するようにしたので、受信者の意志に関わりなく、緊急の情報を受信可能な受信装置へ配信するという緊急配信を効果的に行うことができる。
【００２３】
また、請求項６にかかる発明は、ライブ放送を複数の受信装置へ配信する情報配信方法において、ライブ放送の配信を開始する前に、前記複数の受信装置に対して前記ライブ放送の配信を受けるか否かを問い合わせる問い合わせ工程（後述する実施の形態３のステップＳＥ１に相当）と、前記複数の受信装置に対して前記問い合わせが行われてからの待機時間を計時する計時工程（後述する実施の形態３のステップＳＥ２に相当）と、前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計工程（後述する実施の形態３のステップＳＥ３に相当）と、前記待機時間とあらかじめ設定された待機時間設定値とを比較する第１の比較工程（後述する実施の形態３のステップＳＥ５に相当）と、前記集計結果に基づいて、前記配信を受ける受信装置の数とあらかじめ設定された配信開始しきい値とを比較する第２の比較工程（後述する実施の形態３のステップＳＥ６に相当）と、前記第１の比較工程および前記第２の比較工程のそれぞれの比較結果に基づいて、前記待機時間が前記待機時間設定値以上であって、かつ前記配信を受ける受信装置の数が前記配信開始しきい値に満たない場合、前記配信を中止する配信制御工程（後述する実施の形態３のステップＳＥ９に相当）とを含むことを特徴とする。
【００２４】
この請求項６にかかる発明によれば、ライブ放送の配信を開始する前に、問い合わせ工程では、複数の受信装置に対して配信を受けるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、配信を受ける旨の回答または配信を受けない旨の回答をそれぞれ出す。これにより、集計工程では、複数の受信装置から順次回答される結果が集計され、配信を受ける受信装置の数、配信を受けない受信装置の数が集計される。そして、第１の比較工程では、待機時間とあらかじめ設定された待機時間設定値とが比較され、第２の比較工程では、集計結果に基づいて、配信を受ける受信装置の数とあらかじめ設定された配信開始しきい値とが比較される。そして、配信制御工程では、待機時間が待機時間設定値以上になり、かつ配信を受ける受信装置の数が配信開始しきい値に満たない場合、情報の配信が中止される。
【００２５】
このように、請求項６にかかる発明によれば、待機時間と待機時間設定値とを比較し、配信を受ける受信装置の数と配信開始しきい値以上とを比較し、これら２つの比較結果に基づいて、ライブ放送の配信中止の可否を判断するようにしたので、経過時間を過ぎてもなお、配信を受ける受信装置の数が配信開始しきい値に満たない場合に、自動的にライブ放送の配信を中止することができる。
【００２６】
また、請求項７にかかる発明は、ライブ放送を複数の受信装置へ配信する情報配信装置に適用される情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体であって、ライブ放送の配信を開始する前に、前記複数の受信装置に対して前記ライブ放送の配信を受けるか否かを問い合わせる問い合わせ工程（後述する実施の形態３のステップＳＥ１に相当）と、前記複数の受信装置に対して前記問い合わせが行われてからの待機時間を計時する計時工程（後述する実施の形態３のステップＳＥ２に相当）と、前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計工程（後述する実施の形態３のステップＳＥ３に相当）と、前記待機時間とあらかじめ設定された待機時間設定値とを比較する第１の比較工程（後述する実施の形態３のステップＳＥ５に相当）と、前記集計結果に基づいて、前記配信を受ける受信装置の数とあらかじめ設定された配信開始しきい値とを比較する第２の比較工程（後述する実施の形態３のステップＳＥ６に相当）と、前記第１の比較工程および前記第２の比較工程のそれぞれの比較結果に基づいて、前記待機時間が前記待機時間設定値以上であって、かつ前記配信を受ける受信装置の数が前記配信開始しきい値に満たない場合、前記配信を中止する配信制御工程（後述する実施の形態３のステップＳＥ９に相当）と、をコンピュータに実行させるための情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００２７】
この請求項７にかかる発明によれば、ライブ放送の配信を開始する前に、問い合わせ工程では、複数の受信装置に対して配信を受けるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、配信を受ける旨の回答または配信を受けない旨の回答をそれぞれ出す。これにより、集計工程では、複数の受信装置から順次回答される結果が集計され、配信を受ける受信装置の数、配信を受けない受信装置の数が集計される。そして、第１の比較工程では、待機時間とあらかじめ設定された待機時間設定値とが比較され、第２の比較工程では、集計結果に基づいて、配信を受ける受信装置の数とあらかじめ設定された配信開始しきい値とが比較される。そして、配信制御工程では、待機時間が待機時間設定値以上になり、かつ配信を受ける受信装置の数が配信開始しきい値に満たない場合、情報の配信が中止される。
【００２８】
このように、請求項７にかかる発明によれば、待機時間と待機時間設定値とを比較し、配信を受ける受信装置の数と配信開始しきい値以上とを比較し、これら２つの比較結果に基づいて、ライブ放送の配信中止の可否を判断するようにしたので、経過時間を過ぎてもなお、配信を受ける受信装置の数が配信開始しきい値に満たない場合に、自動的にライブ放送の配信を中止することができる。
【００２９】
また、請求項８にかかる発明は、リアルタイム再生が可能な情報を複数の受信装置へ配信する情報配信方法において、緊急情報の配信を開始する前に、前記複数の受信装置に対して前記緊急情報を受信することが可能であるか否かを問い合わせる問い合わせ工程（後述する実施の形態４のステップＳＡ１に相当）と、前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計工程（後述する実施の形態４のステップＳＡ２に相当）と、前記集計工程の集計結果に基づいて、緊急情報の配信を開始または中止する配信制御工程（後述する実施の形態４のステップＳＡ５またはステップＳＡ６に相当）と、を含むことを特徴とする。
【００３０】
この請求項８にかかる発明によれば、問い合わせ工程では、緊急情報の配信を開始する前に、複数の受信装置に対して情報を受信することが可能であるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、装置の状態を確認した後、緊急情報を受信することが可能であるか否かの回答をそれぞれ出す。これにより、集計工程では、複数の受信装置から順次回答される結果が集計され、配信を受けることが可能な受信装置の数、配信を受けることができない受信装置の数が集計される。そして、配信制御工程では、集計結果に基づいて、緊急情報の配信が開始または中止される。
【００３１】
このように、請求項８にかかる発明によれば、複数の受信装置に対して緊急情報を受信することが可能であるか否かの問い合わせを行い、問い合わせに対応する回答の集計結果に基づいて、緊急情報の配信を開始または中止するようにしたので、受信者の意志に関わりなく、緊急の情報を受信可能な受信装置へ配信するという緊急配信を効果的に行うことができる。
【００３２】
また、請求項９にかかる発明は、リアルタイム再生が可能な情報を複数の受信装置へ配信する情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体であって、緊急情報の配信を開始する前に、前記複数の受信装置に対して前記緊急情報を受信することが可能であるか否かを問い合わせる問い合わせ工程（後述する実施の形態４のステップＳＡ１に相当）と、前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計工程（後述する実施の形態４のステップＳＡ２に相当）と、前記集計工程の集計結果に基づいて、緊急情報の配信を開始または中止する配信制御工程（後述する実施の形態４のステップＳＡ５またはステップＳＡ６に相当）と、をコンピュータに実行させるための情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００３３】
この請求項９にかかる発明によれば、問い合わせ工程では、緊急情報の配信を開始する前に、複数の受信装置に対して情報を受信することが可能であるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、装置の状態を確認した後、緊急情報を受信することが可能であるか否かの回答をそれぞれ出す。これにより、集計工程では、複数の受信装置から順次回答される結果が集計され、配信を受けることが可能な受信装置の数、配信を受けることができない受信装置の数が集計される。そして、配信制御工程では、集計結果に基づいて、緊急情報の配信が開始または中止される。
【００３４】
このように、請求項９にかかる発明によれば、複数の受信装置に対して緊急情報を受信することが可能であるか否かの問い合わせを行い、問い合わせに対応する回答の集計結果に基づいて、緊急情報の配信を開始または中止するようにしたので、受信者の意志に関わりなく、緊急の情報を受信可能な受信装置へ配信するという緊急配信を効果的に行うことができる。
【００３５】
【発明の実施の形態】
以下、図面を参照して本発明にかかる情報配信装置、情報配信方法および情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体の実施の形態１〜４について詳細に説明する。
【００３６】
（実施の形態１）
図１は、本発明にかかる実施の形態１の構成を示すブロック図である。この図に示した情報配信システムは、ストリーミング技術を用いて、コンテンツ情報（動画データ、画像データ）を複数の受信装置へリアルタイムで配信し、受信装置側で、配信されたコンテンツ情報をリアルタイムで再生するシステムである。したがって、この情報配信システムは、リアルタイム再生が可能であることから、講演会やコンサート等のライブ放送に利用される。また、情報配信システムにおける配信プロトコルとしては、たとえば、ＵＤＰ（User Datagram Protocol）が挙げられるが、配信プロトコルの種別は問わない。さらに、情報配信システムにおいては、ＭＢｏｎｅ（virtual Multicast Backbone On the interNEt）技術を用いて、コンテンツ情報の配信を行うようにしてもよい。
【００３７】
図１に示したネットワークＮは、イントラネット、インターネット等であり、後述するストリーミングパケットＳＰ0 〜ＳＰn 等を伝送する。このネットワークＮには、配信者側に設置された配信装置３０と、ストリームサーバ４０1 〜４０n と、管理サーバ５０と、ユーザ側（受信者側）にそれぞれ設置された受信装置６０1 〜６０m （ｍ≧ｎ）とがそれぞれ接続されている。
【００３８】
上記配信装置３０は、受信装置６０1 〜６０m へ配信すべきストリーミングパケットＳＰ0 （コンテンツ情報）を生成する。このストリーミングパケットＳＰ0 は、ストリーム帯域、フレームレート、画面サイズ等をパラメータとして、動画データおよび音声データからなるコンテンツ情報が圧縮されたパケットである。ここで、ストリーム帯域は、ストリーミングパケットＳＰ0 がネットワークＮに送信された際の占有伝送帯域である。フレームレートは、ユーザ側でリアルタイム再生されるコンテンツ情報の毎秒あたりの画面数であり、このフレームレートが大きいほど、なめらかな動画再生が可能となるが、その分だけ広いストリーム帯域が必要となる。また、画面サイズは、ユーザ側でリアルタイム再生されるコンテンツ情報の表示画面を構成する画素数（縦ピクセル数×横ピクセル数）である。
【００３９】
ビデオカメラ１０は、講演会場やコンサート会場に設置されており、講演会やコンサートの様子をリアルタイムで撮像し、撮像結果を動画データＤ1 として配信装置３０へ出力する。同様にして、マイクロフォン２０も講演会場やコンサード会場に設置されている。このマイクロフォン２０は、講演者の音声や、コンサート会場の音声を音声データＤ2 に変換し、これを配信装置３０へリアルタイムで出力する。
【００４０】
ここで、上述した配信装置３０の構成について図２を参照して詳述する。図２においては、図１の各部にそれぞれ対応する部分には同一の符号を付ける。この図に示した配信装置３０において、エンコード部３１は、上述したストリーム帯域、フレームレート、画面サイズ等のパラメータに基づいて、ビデオカメラ１０およびマイクロフォン２０からキャプチャリングされた動画データＤ1 および音声データＤ2 を符号化することで、ストリーミングパケットＳＰ0 を生成する。
【００４１】
具体的には、エンコード部３１は、動画データＤ1 および音声データＤ2 をそれぞれディジタルデータに変換した後、画面サイズやフレームレート等を考慮してディジタルデータの情報量を減らす。さらに、エンコード部３１は、コーデック技術を用いて、上記ディジタルデータをリアルタイムで圧縮し、動画データＤ1 と音声データＤ2 との同期がとられたストリーミングパケットＳＰ0 を生成する。
【００４２】
配信制御部３２は、ストリーミングパケットＳＰ0 （コンテンツ情報）の配信制御、受信装置６０1 〜６０m に対してコンテンツ情報の配信がある旨を告知するための配信通知等を行う。この配信制御部３２の動作の詳細については、後述する。ネットワーク制御部３３は、配信プロトコルを用いて、ネットワークＮの伝送帯域に応じた転送レートでストリーミングパケットＳＰ0 をネットワークＮへ送信する機能を備えている。また、ネットワーク制御部３３は、ネットワークＮの輻輳により、ストリーミングパケットＳＰ0 の伝送中にパケットロスが生じた場合に、ストリーミングパケットＳＰ0 を蓄積するバッファリング機能も備えている。
【００４３】
さらに、ネットワーク制御部３３は、配信プロトコルの他にＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol ）を用いて、管理サーバ５０（図１参照）との間で、配信制御情報の送受信を行う。この配信制御情報としては、つぎの（１）項および（２）項の情報が挙げられる。
【００４４】
（１）受信装置６０1 〜６０m （図１参照）に対してコンテンツ情報の配信を行う旨を事前に通知すべきことを管理サーバ５０へ指示するための配信通知指示情報
（２）受信装置６０1 〜６０m からの上記配信通知に対する応答通知に関する応答通知情報
ここで、上記（２）項の応答通知としては、ユーザがコンテンツ情報の受信を承諾する旨の通知、または受信を拒否する旨の通知という２種類がある。このように、配信装置３０と受信装置６０1 〜６０m との間では、管理サーバ５０を経由して情報の送受信が行われる。
【００４５】
ユーザインタフェース制御部３４は、配信制御部３２と、入力部３５、表示部３６および集計制御部３７との間のインタフェースをとる。入力部３５は、マウス、キーボード等の入力デバイスである。表示部３６は、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode-Ray Tube）等であり、配信操作に必要な各種情報を表示する。この各種情報としては、配信先のアドレス情報や、図５（ｂ）に示した配信装置側選択画面２００がある。配信装置側選択画面２００は、配信を開始するか、または中止するかを配信者に選択させるための画面である。この配信装置側選択画面２００の詳細については、後述する。
【００４６】
図２に戻り、集計制御部３７は、上述した（２）項の情報、すなわち、受信装置６０1 〜６０m からの複数の応答通知を集計し、集計結果をユーザインタフェース制御部３４を介して、配信制御部３２へ渡す。つまり、集計制御部３７は、コンテンツ情報の配信を受けるユーザの人数と、配信を配信を受けないユーザの人数とを集計する。
【００４７】
図１に戻り、ストリームサーバ４０1 〜４０n は、分散配置されたｎ台のサーバであり、受信装置６０1 〜６０m へストリーミングパケットＳＰ1 〜ＳＰn をそれぞれ配信する。ここで、ストリームサーバ４０1 〜４０n において、ストリームサーバ４０1 は、プライマリサーバとしての機能を備えており、その他のストリームサーバ４０2 〜４０n は、セカンダリサーバとしての機能をそれぞれ備えている。
【００４８】
また、ストリームサーバ４０1 〜４０n においては、負荷分散を目的として、配信先がグルーピングされている。すなわち、ストリームサーバ４０1 の配信先は、受信装置６０1 であり、ストリームサーバ４０2 の配信先は、受信装置６０2 および６０3 （図示略）である。以下、同様にして、ストリームサーバ４０n の配信先は、受信装置６０m-1 （図示略）および６０m である。また、このような負荷分散は、管理サーバ５０が受信装置６０1 〜６０m に対して接続すべきストリームサーバを指示することにより実現される。
【００４９】
ストリームサーバ４０1 （プライマリサーバ）は、配信装置３０からネットワークＮを介してストリーミングパケットＳＰ0 の供給を受け、これをストリームサーバ４０2 〜４０n （セカンダリサーバ）へそれぞれ分配する。ストリームサーバ４０1 〜４０n は、ストリーミングパケットＳＰ0 をストリーミングパケットＳＰ1 〜ＳＰn としてそれぞれの配信先へ配信する。このように、ストリームサーバ４０1 〜４０n からは、同一の情報であるストリーミングパケットＳＰ1 〜ＳＰn が受信を承諾した受信装置６０1 〜６０m へ一斉に配信される。
【００５０】
管理サーバ５０は、前述した配信装置３０からの配信通知指示情報にしたがって、コンテンツ情報の配信前に、一斉に受信装置６０1 〜６０m へ配信通知を行う。また、管理サーバ５０は、受信装置６０1 〜６０m からの配信通知に対する応答通知を受け、これらを応答通知情報として、ネットワークＮを介して配信装置３０へ渡す。
【００５１】
受信装置６０1 〜６０m は、ストリームサーバ４０1 〜４０n からネットワークＮを介してそれぞれ配信されるストリーミングパケットＳＰ1 〜ＳＰn を受信し、ストリーミングパケットＳＰ1 〜ＳＰn から同一のコンテンツ情報（動画データ、音声データ）をそれぞれ再生する装置である。また、受信装置６０1 〜６０m は、コンテンツ情報の配信前に、管理サーバ５０から配信通知を受けて、これに対応する応答通知を管理サーバ５０へ返す。この応答通知としては、前述したように、ストリーミングパケットＳＰ1 〜ＳＰn を受信するか否か、いいかえれば、コンテンツ情報の配信を受けるか否かに関するものである。
【００５２】
ここで、上述した受信装置６０1 の構成について図３を参照して詳述する。図３においては、図１の各部にそれぞれ対応する部分には同一の符号を付ける。この図に示した配信制御部６１は、配信されたストリーミングパケットＳＰ1 （コンテンツ情報）の再生制御、配信装置３０（管理サーバ５０）に対してストリーミングパケットＳＰ1 を受信するか否かに関する応答通知等を行う。なお、配信制御部６１の動作の詳細については、後述する。
【００５３】
ユーザインタフェース制御部６２は、配信制御部６１と、受信制御部６４、入力部６５、表示部６６およびスピーカ６７との間のインタフェースをとる。ネットワーク制御部６３は、配信プロトコルを用いて、ストリームサーバ４０1 （図１参照）からのストリーミングパケットＳＰ1 を受信する機能を備えている。また、ネットワーク制御部６３は、配信プロトコルの他にＴＣＰ／ＩＰを用いて、管理サーバ５０（図１参照）との間で、前述した配信制御情報の送受信を行う。
【００５４】
受信制御部６４は、配信制御部６１からの指示にしたがって、ネットワーク制御部６３におけるストリーミングパケットＳＰ1 の受信を制御する。具体的には、配信制御部６１により受信が指示された場合に、受信制御部６４は、ストリーミングパケットＳＰ1 を受信するようにネットワーク制御部６３を制御する。
【００５５】
入力部６５は、マウス、キーボード等の入力デバイスである。表示部６６は、ＬＣＤ、ＣＲＴ等であり、コンテンツ情報のうち動画を再生する。また、表示部６６は、配信前に管理サーバ５０（配信装置３０）からの配信通知を受けて、図５（ａ）に示した受信装置側選択画面１００を表示する。この受信装置側選択画面１００は、ライブ放送を受信するか否か、すなわち、コンテンツ情報の配信を受けるか否かをユーザに選択させるための画面である。この受信装置側選択画面１００の詳細については、後述する。スピーカ６７は、コンテンツ情報のうち音声を再生する。
【００５６】
つぎに、実施の形態１の動作について図４に示したフローチャートを参照しつつ説明する。以下においては、図５（ａ）に示した配信者（Yuji Matsuzaki）が講演者として、「ストリーミングシステムについて」と題する講演会を行い、この講演会の様子をライブ放送する場合を例にして説明する。すなわち、以下においては、上記講演会にかかる動画および音声をコンテンツ情報（ストリーミングパケットＳＰ0 〜ＳＰn ）として受信装置６０1 〜６０m へ配信する場合について説明する。
【００５７】
図１において、受信装置６０1 〜６０m は、起動されると、図４に示したステップＳＢ１へそれぞれ進み、管理サーバ５０（配信装置３０）からの配信通知を受けたか否かをそれぞれ判断し、この場合、判断結果を「Ｎｏ」として同判断をそれぞれ繰り返す。ここで、以下においては、受信装置６０2 〜６０m の動作が受信装置６０1 の動作と同様であるため、図３に示した受信装置６０1 の動作を中心にして説明する。
【００５８】
そして、ライブ放送の開始前に、配信者（または他のオペレータ）により、入力部３５（図２参照）を用いて、配信通知をすべきことを指示する情報が入力されると、配信制御部３２は、図４に示したステップＳＡ１へ進み、受信装置６０1 〜６０m へ配信通知を行うことを指示するための配信通知指示情報をネットワークＮを介して管理サーバ５０へ送信する。
【００５９】
また、配信制御部３２は、図５（ｂ）に示した配信装置側選択画面２００を表示部３６に表示させる。この配信装置側選択画面２００には、ライブ放送のタイトル（「ストリーミングシステムについて」）、当該ライブ放送を受信する受信者数の確認文（「現在、・・・・受信準備をして、待機しています。」）が表示されている。ここで、受信者数表示領域２０１には、受信承諾者数ｘが表示されている。この受信承諾者数ｘは、ライブ放送の受信を承諾したユーザ（受信者）の人数である。したがって、配信者は、上記受信承諾者数ｘを目視確認することで、ライブ放送を受信するユーザ（受信者）の人数を把握する。ただし、この場合、初期状態であるため、受信承諾者数ｘは０である。また、配信装置側選択画面２００には、配信の開始に関する質問文（「配信を開始しますか？」）が表示されている。
【００６０】
さらに、配信装置側選択画面２００には、いずれもソフトボタンである配信開始ボタン２０２および配信中止ボタン２０３が表示されている。これらの配信開始ボタン２０２および配信中止ボタン２０３は、配信の開始または中止を選択するための選択ボタンである。すなわち、配信開始ボタン２０２は、配信を開始する場合にソフト的に押下されるボタンであり、配信中止ボタン２０３は、配信を中止する場合にソフト的に押下されるボタンである。これらの配信開始ボタン２０２および配信中止ボタン２０３は、入力部３５（図２参照）のマウスによるドラッグ・アンド・ドロップ操作によりそれぞれ押下される。
【００６１】
そして、図１において、配信通知指示情報を受信すると、管理サーバ５０は、一斉に受信装置６０1 〜６０m へ配信通知を行う。そして、上記配信通知を受けると、図３に示した受信装置６０1 の配信制御部６１は、ステップＳＢ１の判断結果を「Ｙｅｓ」として、ステップＳＢ２へ進む。ステップＳＢ２では、配信制御部６１は、ユーザインタフェース制御部６２を制御して、表示部６６に図５（ａ）に示した受信装置側選択画面１００を表示させた後、ステップＳＢ３へ進む。
【００６２】
この受信装置側選択画面１００には、ライブ放送が行われる旨の告知文（「これから以下のライブ放送があります。」）、配信者（「Yuji Matsuzaki」）およびタイトル（「ストリーミングシステムについて」）からなるライブ放送内容に関する情報１０１が表示されている。したがって、ユーザは、上記告知文および情報１０１を目視確認することにより、ライブ放送が行われること、およびその内容を認識する。
【００６３】
また、受信装置側選択画面１００には、ライブ放送を受信するか否かの質問文（「このライブ放送を受信しますか？」）が表示されている。したがって、ユーザは、上記質問文を目視確認することで、ライブ放送を受信するか否かを判断する。さらに受信装置側選択画面１００には、いずれもソフトボタンである受信承諾ボタン１０２および受信拒否ボタン１０３が表示されている。
【００６４】
これらの受信承諾ボタン１０２および受信拒否ボタン１０３は、受信するか否かを選択するための選択ボタンである。すなわち、受信承諾ボタン１０２は、受信を承諾する場合にソフト的に押下されるボタンであり、受信拒否ボタン１０３は、受信を拒否する場合にソフト的に押下されるボタンである。これらの受信承諾ボタン１０２および受信拒否ボタン１０３は、入力部６５（図３参照）のマウスによるドラッグ・アンド・ドロップ操作によりそれぞれ押下される。
【００６５】
ステップＳＢ３では、受信装置６０1 （図３参照）の配信制御部６１は、ユーザにより選択ボタン（受信承諾ボタン１０２または受信拒否ボタン１０３）が押下されたか否かを判断し、この場合、押下されていないものとすると、判断結果を「Ｎｏ」として、同判断を繰り返す。
【００６６】
そして、図５（ａ）に示した受信装置側選択画面１００を目視確認したユーザは、ライブ放送を受信するという意志表示を行うため、入力部６５を用いて、受信承諾ボタン１０２を押下する。これにより、配信制御部６１は、受信承諾ボタン１０２が押下されているため、ステップＳＢ３の判断結果を「Ｙｅｓ」として、ステップＳＢ４へ進む。ステップＳＢ４では、受信装置６０1 の配信制御部６１は、管理サーバ５０（配信装置３０）に対して、受信承諾である旨の応答通知を行った後、一連の処理を終了する。
【００６７】
一方、ライブ放送を受信しないという意志表示を行う場合、ユーザは、入力部６５を用いて、受信拒否ボタン１０３を押下する。これにより、配信制御部６１は、受信拒否ボタン１０３が押下されているため、ステップＳＢ３の判断結果を「Ｙｅｓ」として、ステップＳＢ５へ進む。ステップＳＢ５では、受信装置６０1 の配信制御部６１は、管理サーバ５０（配信装置３０）に対して、受信拒否である旨の応答通知を行った後、一連の処理を終了する。また、他の受信装置６０2 〜６０m も、受信装置６０1 と同様にして、管理サーバ５０（配信装置３０）へ受信承諾または受信拒否の応答通知を、順次行った後、一連の処理を終了する。
【００６８】
そして、受信装置６０1 〜６０m から応答通知を順次受けると、管理サーバ５０は、受け取った順に、上記応答通知を応答通知情報としてとしてネットワークＮを介して配信装置３０へ渡す。これにより、ステップＳＡ２では、図２に示した集計制御部３７は、応答通知を集計する。具体的には、集計制御部３７は、受信承諾である旨の応答通知を１件受ける毎と、受信承諾者数ｘ（図５（ｂ）参照）を１インクリメントし、同様にして、受信拒否である旨の応答通知を１件受ける毎に、受信拒否者数ｙを１インクリメントすることで、応答通知の集計を行う。そして、集計制御部３７は、集計結果（受信承認者数ｘ、受信拒否者数ｙ）をユーザインタフェース制御部３４を介して配信制御部３２へ渡す。
【００６９】
これにより、ステップＳＡ３では、配信制御部３２は、上記集計結果（受信承諾者数ｘ、受信拒否者数ｙ）のうち現在の受信承諾者数ｘを図５（ｂ）に示した受信者数表示領域２０１に表示させた後、ステップＳＡ４へ進む。ステップＳＡ４では、配信制御部３２は、ユーザにより選択ボタン（配信開始ボタン２０２または配信中止ボタン２０３）が押下されたか否かを判断し、この場合、押下されていないものとすると、判断結果を「Ｎｏ」とする。したがって、この場合ステップＳＡ４の判断結果が「Ｙｅｓ」となるまで、ステップＳＡ２およびステップＳＡ３においては、応答通知を受ける毎に、応答通知の集計および集計結果（受信承諾者数ｘ）が表示される。
【００７０】
ここで、配信者は、図５（ｂ）に示した配信装置側選択画面２００の受信者数表示領域２０１に表示されている受信承諾者数ｘを目視確認した後、この受信承諾者数ｘが当初予定していた予定人数に達してるか否かを判断する。この場合、受信承諾者数ｘが予定人数に満たないものとすると、配信者は、いずれの操作もすることなく、待機する。この待機中においては、受信承諾の応答通知を受ける毎に、図５（ａ）に示した受信承諾者数ｘが１インクリメントされる。
【００７１】
そして、受信承諾者数ｘが予定人数に達すると、配信者は、入力部３５を用いて、配信開始ボタン２０２を押下した後、講演を開始する。これにより、配信制御部３２は、配信開始ボタン２０２が押下されているため、ステップＳＡ４の判断結果を「Ｙｅｓ」として、ステップＳＡ５へ進む。ステップＳＡ５では、配信制御部３２は、装置各部を制御して配信処理を行う。
【００７２】
この配信処理において、図２に示したビデオカメラ１０およびマイクロフォン２０からは、講演に関する動画データＤ1 および音声データＤ2 が出力される。そして、これらの動画データＤ1 および音声データＤ2 がエンコード部３１にキャプチャリングされると、エンコード部３１は、ストリーム帯域等のパラメータに基づいて、動画データＤ1 および音声データＤ2 を符号化・圧縮することで、ストリーミングパケットＳＰ0 を生成する。
【００７３】
このストリーミングパケットＳＰ0 は、ネットワーク制御部３３およびネットワークＮを介して、図１に示したストリームサーバ４０1 〜４０n へそれぞれ分配される。これにより、ストリームサーバ４０1 〜４０n は、ストリーミングパケットＳＰ0 をストリーミングパケットＳＰ1 〜ＳＰn として、配信先の受信装置６０1 〜６０m へそれぞれ配信する。
【００７４】
ただし、受信装置６０1 〜６０m において、受信拒否である旨の応答通知を行った受信装置へはストリーミングパケットが配信されない。したがって、受信拒否である旨の応答通知を行った受信装置においては、コンテンツ情報が再生されない。
【００７５】
一方、受信装置６０1 〜６０m において、受信承諾である旨の応答通知を行った受信装置は、受信制御部（図３：受信制御部６４参照）の制御により、ストリーミングパケットを受信した後、コンテンツ情報を再生する。たとえば、図３に示した受信装置６０1 において、ストリーミングパケットＳＰ1 がネットワーク制御部６３により受信されると、このストリーミングパケットＳＰ1 は、配信制御部６１へ渡される。
【００７６】
これにより、配信制御部６１は、ストリーミングパケットＳＰ1 を復元することで、動画データおよび音声データを生成する。つぎに、配信制御部６１は、同期がとられた動画データおよび音声データを、ユーザインタフェース制御部６２を経由して表示部６６およびスピーカ６７へそれぞれ供給する。これにより、表示部６６においては、講演の様子を表す動画がリアルタイムで再生され、スピーカ６７においては、講演者の音声が上記動画に同期してリアルタイムで再生される。
【００７７】
一方、配信通知を行ってからの待機時間が所定の時間を超えても、なお、受信承諾者数ｘが予定人数に達しない場合、配信者は、入力部３５を用いて、配信中止ボタン２０３を押下した後、講演を中止する。これにより、配信制御部３２は、配信中止ボタン２０３が押下されているため、ステップＳＡ４の判断結果を「Ｙｅｓ」として、ステップＳＡ６へ進む。ステップＳＡ６では、配信制御部３２は、装置各部を制御して配信中止処理を行う。この配信中止処理においては、配信制御部３２は、管理サーバ５０を経由して受信装置６０1 〜６０m へライブ放送（講演）が中止になった旨を通知する。
【００７８】
以上説明したように、実施の形態１によれば、複数の受信装置６０1 〜６０m に対して配信を受けるか否かを問い合わせる配信通知を行い、この配信通知に対する応答通知の集計結果に基づいて、コンテンツ情報の配信を開始または中止するようにしたので、配信者側でコンテンツ情報の配信を受ける受信者の数を正確に把握し、この把握結果に基づいて効果的にコンテンツ情報の配信を行うことができる。
【００７９】
また、実施の形態１によれば、表示部３６に集計制御部３７の集計結果（受信承認者数ｘ）を表示するようにしたので、配信者側で、配信を受ける受信者の数を正確に把握することができ、この把握結果に基づいて、配信を開始または中止するかを判断することができる。
【００８０】
（実施の形態２）
さて、前述した実施の形態１においては、受信承諾者数ｘ（図５（ｂ）参照）を確認することで、配信を開始するか、または中止するかを配信者が判断する例について説明したが、あらかじめ設定されたしきい値に基づいて、上記判断を行うようにしてもよい。以下、この場合を実施の形態２として説明する。
【００８１】
図６は、本発明にかかる実施の形態２の構成を示すブロック図である。この図において、図１の各部に対応する部分には同一の符号を付け、その説明を省略する。図６においては、図１に示した配信装置３０に代えて、配信装置７０が設けられている。この配信装置７０の基本的な機能は、配信装置３０と同様である。しかしながら、配信装置７０は、上述したしきい値を用いて配信を開始するか、または中止するかを判断している点が配信装置３０と異なる。
【００８２】
ここで、上述した配信装置７０の構成について図７を参照して詳述する。図７においては、図２の各部にそれぞれ対応する部分には同一の符号を付け、その説明を省略する。この図においては、図２に示した集計制御部３７に代えて、集計制御部７１が新たに設けられており、さらに、しきい値設定部７２が新たに設けられている。
【００８３】
図７に示した集計制御部７１は、集計制御部３７と同様にして、受信装置６０1 〜６０m （図６参照）からの複数の応答通知を集計し、集計結果（受信承諾者数ｘ、受信拒否者数ｙ）をユーザインタフェース制御部３４を介して、配信制御部３２へ渡す。
【００８４】
また、集計制御部７１は、動作例１として、受信承諾者数ｘと、しきい値設定部７２によりあらかじめ設定された配信開始しきい値ＴＨ1 とを比較し、受信承諾者数ｘが配信開始しきい値ＴＨ1 以上になった時点で、配信者の判断にかかわらず、自動的に配信処理を実行する。さらに、集計制御部７１は、動作例２として、受信拒否者数ｙとしきい値設定部７２によりあらかじめ設定された配信中止しきい値ＴＨ2 とを比較し、受信拒否者数ｙが配信中止しきい値ＴＨ2 以上になった時点で、配信者の判断にかかららず、自動的に配信中止処理を実行する。しきい値設定部７２は、集計制御部７１に配信開始しきい値ＴＨ1 または配信中止しきい値ＴＨ2 を設定する。
【００８５】
つぎに、実施の形態２の動作例１について図８に示したフローチャートを参照しつつ説明する。配信装置７０側の動作であるステップＳＣ１〜ＳＣ７において、ステップＳＣ４を除く、ステップＳＣ１〜ステップＳＣ３およびステップＳＣ５〜ステップＳＣ７は、前述した図４に示したステップＳＡ１〜ステップＳＡ６と同様である。さらに、図８に示したステップＳＢ１〜ステップＳＢ５からなる受信装置６０1 〜６０m 側の動作は、図４に示したものと同一である。また、以下の動作例１において、図７に示した集計制御部７１には、配信開始しきい値ＴＨ1 が設定されているものとする。
【００８６】
図６において、受信装置６０1 〜６０m は、起動されると、図８に示したステップＳＢ１へ進み、管理サーバ５０（配信装置７０）からの配信通知を受けたか否かをそれぞれ判断し、この場合、判断結果を「Ｎｏ」として同判断をそれぞれ繰り返す。そして、ライブ放送の開始前に、配信者（または他のオペレータ）により、入力部３５（図７参照）を用いて、配信通知をすべきことを指示する情報が入力されると、配信制御部３２は、図８に示したステップＳＣ１へ進み、受信装置６０1 〜６０m へ配信通知を行うことを指示するための配信通知指示情報をネットワークＮを介して管理サーバ５０へ送信する。以後、前述した実施の形態１と同様の動作が行われる。
【００８７】
すなわち、上記配信通知を受けると、受信装置６０1 〜６０m は、ステップＳＢ１の判断結果を「Ｙｅｓ」として、ステップＳＢ２へ進む。これにより、ステップＳＢ２では、受信装置側選択画面１００（図５（ａ）参照）が表示され、ステップＳＢ３では、受信装置６０1 〜６０m は、ユーザにより選択ボタン（受信承諾ボタン１０２または受信拒否ボタン１０３）が押下されたか否かを判断する。
【００８８】
そして、ユーザにより受信承諾ボタン１０２が押下されると、受信装置６０1 〜６０m は、ステップＳＢ３の判断結果を「Ｙｅｓ」として、ステップＳＢ４へ進む。ステップＳＢ４では、受信装置６０1 〜６０m は、管理サーバ５０（配信装置７０）に対して、受信承諾である旨の応答通知を行った後、一連の処理を終了する。
【００８９】
一方、ユーザにより受信拒否ボタン１０３が押下されると、受信装置６０1 〜６０m は、ステップＳＢ３の判断結果を「Ｙｅｓ」として、ステップＳＢ５へ進む。ステップＳＢ５では、受信装置６０1 〜６０m は、管理サーバ５０（配信装置７０）に対して、受信拒否である旨の応答通知を行った後、一連の処理を終了する。
【００９０】
そして、受信装置６０1 〜６０m から応答通知を順次受けると、管理サーバ５０は、受け取った順に、上記応答通知を応答通知情報としてとしてネットワークＮを介して配信装置７０へ渡す。これにより、ステップＳＣ２では、図７に示した集計制御部７１は、応答通知を集計した後、集計結果（受信承諾者数ｘ、受信拒否者数ｙ）をユーザインタフェース制御部３４を介して配信制御部３２へ渡す。
【００９１】
これにより、ステップＳＣ３では、配信制御部３２は、ステップＳＡ３（図４参照）と同様にして、上記集計結果（受信承諾者数ｘ、受信拒否者数ｙ）のうち現在の受信承諾者数ｘを図５（ｂ）に示した受信者数表示領域２０１に表示させる。つぎのステップＳＣ４では、集計制御部７１は、現在の受信承諾者数ｘと配信開始しきい値ＴＨ1 とを比較し、受信承諾者数ｘが配信開始しきい値ＴＨ1 以上であるか否かを判断し、この場合、受信承諾者数ｘが配信開始しきい値ＴＨ1 より小であるものとすると、判断結果を「Ｎｏ」とする。
【００９２】
つぎのステップＳＣ５では、配信制御部３２は、ステップＳＡ４（図４参照）と同様にして、ユーザにより選択ボタン（配信開始ボタン２０２または配信中止ボタン２０３）が押下されたか否かを判断し、この場合、押下されていないものとすると、判断結果を「Ｎｏ」とする。したがって、この場合、ステップＳＣ４の判断結果が「Ｙｅｓ」、またはステップＳＣ５の判断結果が「Ｙｅｓ」となるまで、ステップＳＣ２およびステップＳＣ３においては、応答通知を受ける毎に、応答通知の集計および集計結果（受信承諾者数ｘ）が表示される。
【００９３】
ここで、受信承諾者数ｘが配信開始しきい値ＴＨ1 以上になると、集計制御部７１は、ステップＳＣ４の判断結果を「Ｙｅｓ」として、ステップＳＣ６へ進み、配信者の判断にかかわらず、エンコード部３１を制御することで、自動的に配信処理を実行する。すなわち、この場合には、配信者により、配信開始ボタン２０２が押下されていない状態で、配信処理が実行されたのである。
【００９４】
この配信処理においては、ステップＳＡ５（図４参照）と同様にして、講演に関する動画データＤ1 および音声データＤ2 がエンコード部３１にキャプチャリングされると、エンコード部３１は、ストリーム帯域等のパラメータに基づいて、動画データＤ1 および音声データＤ2 を符号化・圧縮することで、ストリーミングパケットＳＰ0 を生成する。そして、ストリーミングパケットＳＰ0 は、ネットワーク制御部３３およびネットワークＮを介して、図６に示したストリームサーバ４０1 〜４０n へそれぞれ分配される。これにより、ストリームサーバ４０1 〜４０n は、ストリーミングパケットＳＰ0 をストリーミングパケットＳＰ1 〜ＳＰn として、配信先の受信装置６０1 〜６０m へそれぞれ配信する。
【００９５】
また、ステップＳＣ４の判断結果が「Ｎｏ」である間に、配信開始ボタン２０２が押下されると、ステップＳＣ５の判断結果が「Ｙｅｓ」となり、ステップＳＣ６で配信処理が実行される。このとき実行される配信処理は、配信者の判断によるものである。一方、ステップＳＣ４の判断結果が「Ｎｏ」である間に、配信中止ボタン２０３が押下されると、ステップＳＣ５の判断結果が「Ｙｅｓ」となり、ステップＳＣ７で、ステップＳＡ６（図４参照）と同様にして、配信中止処理が実行される。
【００９６】
つぎに、実施の形態２の動作例２について図９に示したフローチャートを参照しつつ説明する。図９において、図８の各部に対応する部分には同一の符号を付ける。配信装置７０側の動作であるステップＳＤ１〜ＳＤ７において、ステップＳＤ４を除く、ステップＳＤ１〜ステップＳＤ３およびステップＳＤ５〜ステップＳＤ７は、前述した図８に示したステップＳＣ１〜ステップＳＣ３およびステップＳＣ５〜ステップＳＣ７と同様である。また、以下の動作２において、図７に示したしきい集計制御部７１には、配信中止しきい値ＴＨ2 が設定されているものとする。
【００９７】
図６において、受信装置６０1 〜６０m は、起動されると、図９に示したステップＳＢ１へ進み、管理サーバ５０（配信装置７０）からの配信通知を受けたか否かをそれぞれ判断し、この場合、判断結果を「Ｎｏ」として同判断をそれぞれ繰り返す。そして、ライブ放送の開始前に、配信者（または他のオペレータ）により、入力部３５（図７参照）を用いて、配信通知をすべきことを指示する情報が入力されると、配信制御部３２は、図９に示したステップＳＤ１へ進み、受信装置６０1 〜６０m へ配信通知を行うことを指示するための配信通知指示情報をネットワークＮを介して管理サーバ５０へ送信する。以後、前述した実施の形態１と同様の動作が行われる。
【００９８】
すなわち、上記配信通知を受けると、受信装置６０1 〜６０m は、ステップＳＢ１の判断結果を「Ｙｅｓ」として、ステップＳＢ２以降の工程を実行する。ここで、ユーザにより受信承諾ボタン１０２が押下されると、前述した動作を経て、ステップＳＢ４では、受信装置６０1 〜６０m は、管理サーバ５０（配信装置７０）に対して、受信承諾である旨の応答通知を行った後、一連の処理を終了する。
【００９９】
一方、ユーザにより受信拒否ボタン１０３が押下されると、前述した動作を経て、ステップＳＢ５では、受信装置６０1 〜６０m は、管理サーバ５０（配信装置７０）に対して、受信拒否である旨の応答通知を行った後、一連の処理を終了する。
【０１００】
そして、受信装置６０1 〜６０m から応答通知を順次受けると、管理サーバ５０は、受け取った順に、上記応答通知を応答通知情報としてとしてネットワークＮを介して配信装置７０へ渡す。これにより、ステップＳＤ２では、図７に示した集計制御部７１は、応答通知を集計した後、集計結果（受信承諾者数ｘ、受信拒否者数ｙ）をユーザインタフェース制御部３４を介して配信制御部３２へ渡す。
【０１０１】
これにより、ステップＳＤ３では、配信制御部３２は、ステップＳＡ３（図４参照）と同様にして、上記集計結果（受信承諾者数ｘ、受信拒否者数ｙ）のうち現在の受信承諾者数ｘを図５（ｂ）に示した受信者数表示領域２０１に表示させる。なお、この動作例２においては、受信者数表示領域２０１に受信拒否者数ｙを表示させてもよい。つぎのステップＳＤ４では、集計制御部７１は、現在の受信拒否者数ｙと配信中止しきい値ＴＨ2 とを比較し、受信拒否者数ｙが配信中止しきい値ＴＨ2 以上であるか否かを判断し、この場合、受信拒否者数ｙが配信中止しきい値ＴＨ2 より小であるものとすると、判断結果を「Ｎｏ」とする。
【０１０２】
つぎのステップＳＤ５では、配信制御部３２は、ステップＳＡ４（図４参照）と同様にして、ユーザにより選択ボタン（配信開始ボタン２０２または配信中止ボタン２０３）が押下されたか否かを判断し、この場合、押下されていないものとすると、判断結果を「Ｎｏ」とする。したがって、この場合、ステップＳＤ４の判断結果が「Ｙｅｓ」、またはステップＳＤ５の判断結果が「Ｙｅｓ」となるまで、ステップＳＤ２およびステップＳＤ３においては、応答通知を受ける毎に、応答通知の集計および集計結果（受信承諾者数ｘ）が表示される。
【０１０３】
ここで、受信拒否者数ｙが配信中止しきい値ＴＨ2 以上になると、集計制御部７１は、ステップＳＤ４の判断結果を「Ｙｅｓ」として、ステップＳＤ７へ進み、エンコード部３１を制御することで、自動的に配信中止処理を実行する。この配信中止処理においては、集計制御部７１は、管理サーバ５０を経由して受信装置６０1 〜６０m へライブ放送（講演）が中止になった旨を通知する。すなわち、この場合には、配信者により、配信中止ボタン２０３が押下されていない状態で、配信中止処理が実行されたのである。
【０１０４】
また、ステップＳＤ４の判断結果が「Ｎｏ」である間に、配信開始ボタン２０２が押下されると、ステップＳＤ５の判断結果が「Ｙｅｓ」となり、ステップＳＤ６で配信処理が実行される。このとき実行される配信処理は、配信者の判断によるものである。一方、ステップＳＤ４の判断結果が「Ｎｏ」である間に、配信中止ボタン２０３が押下されると、ステップＳＤ５の判断結果が「Ｙｅｓ」となり、ステップＳＤ７で、ステップＳＡ６（図４参照）と同様にして、配信中止処理が実行される。
【０１０５】
以上説明したように、実施の形態２によれば、集計制御部７１を設けて、受信承認者数ｘと配信開始しきい値ＴＨ1 とを比較し、この比較結果に基づいて、コンテンツ情報の配信開始の可否を判断するようにしたので、配信者の判断を待たずに、自動的にコンテンツ情報の配信を開始することができる。
【０１０６】
また、実施の形態２によれば、集計制御部７１を設けて、受信拒否者数ｙと配信中止しきい値ＴＨ2 とを比較し、この比較結果に基づいて、コンテンツ情報の配信中止の可否を判断するようにしたので、配信者の判断を待たずに、自動的に情報の配信を中止することができる。
【０１０７】
（実施の形態３）
さて、前述した実施の形態１および２においては、配信通知を行ってから配信中止処理を実行するまでの待機時間の長短を配信者の意志に基づいて決定した例について説明したが、この待機時間としきい値とを比較し、この比較結果に基づいて、配信中止処理を行うようにしてもよい。以下、この場合を実施の形態３として説明する。
【０１０８】
図１０は、本発明にかかる実施の形態３の構成を示すブロック図である。この図において、図１の各部に対応する部分には同一の符号を付け、その説明を省略する。図１０においては、図１に示した配信装置３０に代えて、配信装置８０が設けられている。ここで、上述した配信装置８０の構成について図１１を参照して詳述する。
【０１０９】
なお、図１１においては、図２の各部にそれぞれ対応する部分には同一の符号を付け、その説明を省略する。この図においては、図２に示した集計制御部３７に代えて、集計制御部８１が新たに設けられており、さらに、タイマ８２、待機時間設定部８３およびしきい値設定部８４が新たに設けられている。この配信装置８０の基本的な機能は、配信装置３０と同様である。しかしながら、配信装置８０は、上述したしきい値を用いて配信中止処理を行うか否かを判断している点が配信装置３０と異なる。
【０１１０】
配信装置８０において、集計制御部８１は、集計制御部３７と同様にして、受信装置６０1 〜６０m （図１１参照）からの複数の応答通知を集計し、集計結果（受信承諾者数ｘ、受信拒否者数ｙ）をユーザインタフェース制御部３４を介して、配信制御部３２へ渡す。タイマ８２は、配信通知を行ってからの待機時間を計時するものであり、計時結果を待機時間Ｔとして集計制御部８１へ出力する。待機時間設定部８３は、集計制御部８１に待機時間設定値ＴＨ4 を設定する。この待機時間設定値ＴＨ4 は、待機時間Ｔとの比較において配信中止処理を実行するか否かの判断基準の一つとして用いられる。
【０１１１】
しきい値設定部８４は、集計制御部８１に配信開始しきい値ＴＨ3 を設定する。この配信開始しきい値ＴＨ3 は、受信承諾者数ｘとの比較において配信中止処理を実行するか否かの判断基準の一つとして用いられる。ここで、集計制御部８１は、上述した待機時間Ｔと待機時間設定値ＴＨ4 との比較、および受信承諾者数ｘと配信開始しきい値ＴＨ3 との比較を行い、両比較結果に基づいて、配信中止処理を実行するか否かを判断する。
【０１１２】
つぎに、実施の形態３の動作について図１２に示したフローチャートを参照しつつ説明する。図１２において、図４の各部に対応する部分には同一の符号を付ける。図１０において、受信装置６０1 〜６０m は、起動されると、図１２に示したステップＳＢ１へ進み、管理サーバ５０（配信装置８０）からの配信通知を受けたか否かをそれぞれ判断し、この場合、判断結果を「Ｎｏ」として同判断をそれぞれ繰り返す。
【０１１３】
そして、ライブ放送の開始前に、配信者（または他のオペレータ）により、入力部３５（図７参照）を用いて、配信通知をすべきことを指示する情報が入力されると、配信制御部３２は、図１２に示したステップＳＥ１へ進み、受信装置６０1 〜６０m へ配信通知を行うことを指示するための配信通知指示情報をネットワークＮを介して管理サーバ５０へ送信する。つぎのステップＳＥ２では、集計制御部８１は、タイマ８２をリセット（待機時間Ｔ＝０）する。これにより、タイマ８２による計時が開始される。
【０１１４】
そして、配信通知を受けると、受信装置６０1 〜６０m は、ステップＳＢ１の判断結果を「Ｙｅｓ」として、ステップＳＢ２以降の工程を実行する。ここで、ユーザにより受信承諾ボタン１０２が押下されると、前述した動作を経て、ステップＳＢ４では、受信装置６０1 〜６０m は、管理サーバ５０（配信装置８０）に対して、受信承諾である旨の応答通知を行った後、一連の処理を終了する。
【０１１５】
一方、ユーザにより受信拒否ボタン１０３が押下されると、前述した動作を経て、ステップＳＢ５では、受信装置６０1 〜６０m は、管理サーバ５０（配信装置８０）に対して、受信拒否である旨の応答通知を行った後、一連の処理を終了する。
【０１１６】
そして、受信装置６０1 〜６０m から応答通知を順次受けると、管理サーバ５０は、受け取った順に、上記応答通知を応答通知情報としてとしてネットワークＮを介して配信装置８０へ渡す。これにより、ステップＳＥ３では、図１１に示した集計制御部８１は、応答通知を集計した後、集計結果（受信承諾者数ｘ、受信拒否者数ｙ）をユーザインタフェース制御部３４を介して配信制御部３２へ渡す。
【０１１７】
これにより、ステップＳＥ４では、配信制御部３２は、ステップＳＡ３（図４参照）と同様にして、上記集計結果（受信承諾者数ｘ、受信拒否者数ｙ）のうち現在の受信承諾者数ｘを図５（ｂ）に示した受信者数表示領域２０１に表示させる。なお、実施の形態３においては、受信者数表示領域２０１に受信拒否者数ｙを表示させてもよい。つぎのステップＳＥ５では、集計制御部８１は、現在の待機時間Ｔと待機時間設定値ＴＨ4 とを比較し、待機時間Ｔが待機時間設定値ＴＨ4 以上であるか否かを判断し、この場合、待機時間Ｔが待機時間設定値ＴＨ4 未満であるものとすると、判断結果を「Ｎｏ」とする。
【０１１８】
つぎのステップＳＥ７では、配信制御部３２は、ステップＳＡ４（図４参照）と同様にして、ユーザにより選択ボタン（配信開始ボタン２０２または配信中止ボタン２０３）が押下されたか否かを判断し、この場合、押下されていないものとすると、判断結果を「Ｎｏ」とする。したがって、以後、応答通知を受ける毎に、応答通知の集計および集計結果（受信承諾者数ｘ）が表示される。
【０１１９】
ここで、待機時間Ｔが待機時間設定値ＴＨ4 以上になると、集計制御部８１は、ステップＳＥ５の判断結果を「Ｙｅｓ」として、ステップＳＥ６へ進む。ステップＳＥ６では、集計制御部８１は、現在の受信承諾者数ｘと配信開始しきい値ＴＨ3 とを比較し、受信承諾者数ｘが配信開始しきい値ＴＨ3 未満であるか否かを判断する。この場合、判断結果が「Ｙｅｓ」であるものとすると、集計制御部８１は、ステップＳＥ９へ進む。
【０１２０】
なお、受信承諾者数ｘが配信開始しきい値ＴＨ3 以上である場合、集計制御部８１は、ステップＳＥ６の判断結果を「Ｎｏ」とする。つまり、配信通知を行ってからの待機時間Ｔが待機時間設定値ＴＨ4 以上であり、かつ受信承諾者数ｘが配信開始しきい値ＴＨ3 未満であるという２つの条件を満たした場合には、集計制御部８１により配信中止処理が実行される。
【０１２１】
ステップＳＥ９では、集計制御部８１は、エンコード部３１を制御することで、自動的に配信中止処理を実行する。この配信中止処理においては、集計制御部８１は、管理サーバ５０を経由して受信装置６０1 〜６０m へライブ放送（講演）が中止になった旨を通知する。すなわち、この場合には、配信者により、配信中止ボタン２０３が押下されていない状態で、配信中止処理が実行されるのである。
【０１２２】
また、ステップＳＥ５の判断結果が「ＹＥＳ」で、かつステップＳＥ６の判断結果が「Ｎｏ」である間に、配信開始ボタン２０２が押下されると、ステップＳＥ７の判断結果が「Ｙｅｓ」となり、ステップＳＥ８で配信処理が実行される。このとき実行される配信処理は、配信者の判断によるものである。一方、ステップＳＥ５の判断結果が「Ｙｅｓ」で、かつステップＳＥ６の判断結果が「Ｎｏ」である間に、配信中止ボタン２０３が押下されると、ステップＳＥ５の判断結果が「Ｙｅｓ」となり、ステップＳＥ９で、ステップＳＡ６（図４参照）と同様にして、配信中止処理が実行される。
【０１２３】
以上説明したように、実施の形態３によれば、集計制御部８１を設けて、待機時間Ｔと待機時間設定値ＴＨ4 とを比較し、さらに受信承認者数ｘと配信開始しきい値ＴＨ3 とを比較し、これら２つの比較結果に基づいて、コンテンツ情報の配信中止の可否を判断するようにしたので、配信者の判断を待たずに、所定の待機時間を過ぎてもなお、受信承認者数ｘの数が配信開始しきい値ＴＨ3 に満たない場合に、自動的に情報の配信を中止することができる。
【０１２４】
（実施の形態４）
さて、前述した実施の形態１〜３においては、配信の前に、受信装置６０1 〜６０m に対して配信通知を行い、この配信通知に対応する応答通知の集計結果に基づいて、ライブ放送の受信を承諾したユーザの受信装置へコンテンツ情報を配信する例について説明したが、ユーザの意志にかかわらず、強制的にコンテンツ情報を配信するようにしてもよい。このような形態の配信は、緊急配信と呼ばれている。以下、この場合を実施の形態４として説明する。
【０１２５】
図１３は、本発明にかかる実施の形態４の構成を示すブロック図である。この図において、図１の各部に対応する部分には同一の符号を付け、その説明を省略する。図１３においては、図１に示した受信装置６０1 〜６０m に代えて、受信装置９０1 〜９０m が設けられている。
【０１２６】
ここで、図１３に示した受信装置９０1 の構成について図１４を参照して詳述する。なお、他の受信装置９０2 〜９０m の構成は、以下に説明する受信装置９０1 の構成と同一である。図１４においては、図３の各部にそれぞれ対応する部分には同一の符号を付け、その説明を省略する。この図においては、状態監視部９１が新たに設けられている。この状態監視部９１は、受信装置９０1 がストリーミングパケットＳＰ1 を受信可能な状態にあるか否かを監視し、監視結果を配信制御部６１へ渡す。ここで、受信可能な状態とは、受信装置９０1 の各部が正常に動作している状態をいう。配信制御部６１は、配信制御部６１の監視結果に基づいて、配信装置３０（管理サーバ５０）へ受信可能（または受信不可）である旨の応答を通知する。
【０１２７】
つぎに、実施の形態４の動作について図１５に示したフローチャートを参照しつつ説明する。図１５において、配信装置３０側の動作は、図４に示したものと同様である。以下においては、緊急配信という性質上、緊急演説の様子をライブ放送する例について説明する。図１３において、受信装置９０1 〜９０m （図１３：配信制御部６１）は、起動されると、図１５に示したステップＳＦ１へ進み、管理サーバ５０（配信装置３０）からの配信通知を受けたか否かをそれぞれ判断し、この場合、判断結果を「Ｎｏ」として同判断をそれぞれ繰り返す。
【０１２８】
そして、ライブ放送の開始前に、配信者（または他のオペレータ）により、入力部３５（図２参照）を用いて、配信通知をすべきことを指示する情報が入力されると、配信制御部３２は、図１５に示したステップＳＡ１へ進み、受信装置９０1 〜９０m へ配信通知を行うことを指示するための配信通知指示情報をネットワークＮを介して管理サーバ５０へ送信する。
【０１２９】
上記配信通知を受けると、受信装置９０1 〜９０m （配信制御部６１）は、ステップＳＦ１の判断結果を「Ｙｅｓ」として、ステップＳＦ２へ進む。ステップＳＦ２では、図１３に示した受信装置９０1 〜９０m （配信制御部６１）は、状態監視部９１の監視結果に基づいて、装置が受信可能な状態にあるか否かを判断する。
【０１３０】
ここで、受信可能な状態にある場合、受信装置９０1 〜９０m （配信制御部６１）は、管理サーバ５０（配信装置３０）に対して、受信可能である旨の応答通知を行った後、処理を終了する。一方、装置故障等により受信不可能な状態にある場合、受信装置９０1 〜９０m （配信制御部６１）は、管理サーバ５０（配信装置３０）に対して、受信不可である旨の応答通知を行った後、処理を終了する。
【０１３１】
そして、受信装置９０1 〜９０m から応答通知を順次受けると、管理サーバ５０は、受け取った順に、上記応答通知を応答通知情報としてとしてネットワークＮを介して配信装置３０へ渡す。これにより、ステップＳＡ２では、図７に示した集計制御部７１は、応答通知を集計した後、集計結果（受信承諾者数ｘ、受信拒否者数ｙ）をユーザインタフェース制御部３４を介して配信制御部３２へ渡す。ここで、受信承認者数ｘは、受信装置９０1 〜９０m のうち受信可能な状態にある受信装置の数に対応しており、受信拒否者数ｙは、受信装置９０1 〜９０m のうち受信不可能な状態にある受信装置の数に対応している。
【０１３２】
つぎのステップＳＡ３では、配信制御部３２は、上記集計結果（受信承諾者数ｘ、受信拒否者数ｙ）のうち、図５（ｂ）に示した受信者数表示領域２０１に、現在の受信承諾者数ｘを表示させた後、ステップＳＡ４へ進む。ステップＳＡ４では、配信制御部３２は、ユーザにより選択ボタン（配信開始ボタン２０２または配信中止ボタン２０３）が押下されたか否かを判断し、この場合、押下されていないものとすると、判断結果を「Ｎｏ」とする。したがって、この場合、ステップＳＡ４の判断結果が「Ｙｅｓ」となるまで、ステップＳＡ２およびステップＳＡ３においては、応答通知を受ける毎に、応答通知の集計および集計結果（受信承諾者数ｘ）が表示される。
【０１３３】
そして、受信承諾者数ｘがある程度の人数に達すると、配信者は、入力部３５を用いて、配信開始ボタン２０２を押下した後、緊急演説を開始する。これにより、配信制御部３２は、配信開始ボタン２０２が押下されているため、ステップＳＡ４の判断結果を「Ｙｅｓ」として、ステップＳＡ５へ進む。ステップＳＡ５では、配信制御部３２は、装置各部を制御して配信処理を行う。
【０１３４】
この配信処理において、図２に示したビデオカメラ１０およびマイクロフォン２０からは、緊急演説に関する動画データＤ1 および音声データＤ2 が出力される。そして、これらの動画データＤ1 および音声データＤ2 がエンコード部３１にキャプチャリングされると、エンコード部３１は、ストリーム帯域等のパラメータに基づいて、動画データＤ1 および音声データＤ2 を符号化・圧縮することで、ストリーミングパケットＳＰ0 を生成する。
【０１３５】
このストリーミングパケットＳＰ0 は、ネットワーク制御部３３およびネットワークＮを介して、図１に示したストリームサーバ４０1 〜４０n へそれぞれ分配される。これにより、ストリームサーバ４０1 〜４０n は、ストリーミングパケットＳＰ0 をストリーミングパケットＳＰ1 〜ＳＰn として、配信先の受信装置９０1 〜９０m へそれぞれ配信する。ここで、受信装置９０1 〜９０m において、受信可能な状態にあるすべての受信装置では、ユーザの意志に関わりなく、緊急演説に関するコンテンツ情報がリアルタイムで再生される。
【０１３６】
なお、配信者により配信中止ボタン２０３が押下されると、配信制御部３２は、ステップＳＡ４の判断結果を「Ｙｅｓ」として、ステップＳＡ６へ進む。ステップＳＡ６では、配信制御部３２は、装置各部を制御して配信中止処理を行う。
【０１３７】
以上説明したように、実施の形態４によれば、複数の受信装置９０1 〜９０m に対して、コンテンツ情報（ストリーミングパケットＳＰ1 〜ＳＰn ）を受信することが可能な状態であるか否かを問い合わせる配信通知を行い、この配信通知に対応する応答通知の集計結果に基づいて、コンテンツ情報の配信を開始または中止するようにしたので、受信者の意志に関わりなく、緊急のコンテンツ情報を受信可能状態にある受信装置へ配信するという緊急配信を効果的に行うことができる。
【０１３８】
以上本発明の実施の形態１〜４について図面を参照して詳述してきたが、具体的な構成例はこれら実施の形態１〜４に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等があっても本発明に含まれる。たとえば、前述した実施の形態１〜４においては、前述した機能を実現するための情報配信プログラムを図１６に示したコンピュータ読み取り可能な記録媒体４００に記録して、この記録媒体４００に記録された情報配信プログラムを同図に示したコンピュータ３００に読み込ませ、実行するようにしてもよい。
【０１３９】
図１６に示したコンピュータ３００は、上記情報配信プログラムを実行するＣＰＵ３０１と、キーボード、マウス等の入力装置３０２と、各種データを記憶するＲＯＭ（Read Only Memory）３０３と、演算パラメータ等を記憶するＲＡＭ（Random Access Memory）３０４と、記録媒体４００から情報配信プログラムを読み取る読取装置３０５と、ディスプレイ、プリンタ等の出力装置３０６と、装置各部を接続するバスＢＵとから構成されている。
【０１４０】
ＣＰＵ３０１は、読取装置３０５を経由して記録媒体４００に記録されている情報配信プログラムを読み込んだ後、情報配信プログラムを実行することにより、前述したコンテンツ情報の配信を行う。なお、記録媒体４００には、光ディスク、フロッピーディスク、ハードディスク等の可搬型の記録媒体が含まれることはもとより、ネットワークのようにデータを一時的に記録保持するような伝送媒体も含まれる。
【０１４１】
【発明の効果】
以上説明したように、請求項１、６、７にかかる発明によれば、待機時間と待機時間設定値とを比較し、配信を受ける受信装置の数と配信開始しきい値以上とを比較し、これら２つの比較結果に基づいて、ライブ放送の配信中止の可否を判断するようにしたので、経過時間を過ぎてもなお、配信を受ける受信装置の数が配信開始しきい値に満たない場合に、自動的にライブ放送の配信を中止することができるという効果を奏する。
【０１４２】
また、請求項２にかかる発明によれば、報知手段により回答の集計結果が報知される。したがって、配信者は、報知された集計結果に基づいて、配信を行うかまたは中止するかを判断することが可能となるという効果を奏する。
【０１４３】
また、請求項３にかかる発明によれば、第３の比較手段を設けて、配信を受ける受信装置の数と配信決定しきい値以上とを比較し、この比較結果に基づいて、ライブ放送の配信開始の可否を判断するようにしたので、配信者の判断を待たずに、自動的にライブ放送の配信を行うことができるという効果を奏する。
【０１４４】
また、請求項４にかかる発明によれば、第４の比較手段を設けて、配信を受けない受信装置の数と配信中止しきい値以上とを比較し、この比較結果に基づいて、ライブ放送の配信中止の可否を判断するようにしたので、配信者の判断を待たずに、自動的にライブ放送の配信を中止することができるという効果を奏する。
【０１４５】
また、請求項５、８、９にかかる発明によれば、複数の受信装置に対して緊急情報を受信することが可能であるか否かの問い合わせを行い、問い合わせに対応する回答の集計結果に基づいて、緊急情報の配信を開始または中止するようにしたので、受信者の意志に関わりなく、緊急の情報を受信可能な受信装置へ配信するという緊急配信を効果的に行うことができるという効果を奏する。
【図面の簡単な説明】
【図１】本発明にかかる実施の形態１の構成を示すブロック図である。
【図２】図１に示した配信装置３０の構成を示すブロック図である。
【図３】図１に示した受信装置６０1 の構成を示すブロック図である。
【図４】同実施の形態１の動作を説明するフローチャートである。
【図５】実施の形態１〜４における受信装置側選択画面１００および配信装置側選択画面２００を示す図である。
【図６】本発明にかかる実施の形態２の構成を示すブロック図である。
【図７】図６に示した配信装置７０の構成を示すブロック図である。
【図８】同実施の形態２の動作例１を説明するフローチャートである。
【図９】同実施の形態２の動作例２を説明するフローチャートである。
【図１０】本発明にかかる実施の形態３の構成を示すブロック図である。
【図１１】図１０に示した配信装置８０の構成を示すブロック図である。
【図１２】同実施の形態３の動作を説明するフローチャートである。
【図１３】本発明にかかる実施の形態４の構成を示すブロック図である。
【図１４】図１３に示した受信装置９０1 の構成を示すブロック図である。
【図１５】同実施の形態４の動作を説明するフローチャートである。
【図１６】本発明にかかる実施の形態１〜４の変形例を示すブロック図である。
【符号の説明】
３０ 配信装置
３２ 配信制御部
３５ 入力部
３６ 表示部
３７ 集計制御部
６０1 〜６０m 受信装置
７０ 配信装置
７１ 集計制御部
８０ 配信装置
８１ 集計制御部
８２ タイマ
９０1 〜９０m 受信装置
３００ コンピュータ
４００ 記録媒体
【発明の属する技術分野】
本発明は、リアルタイム再生が可能なコンテンツ情報（動画データ、音声データ）を複数の受信装置へ配信する情報配信装置、情報配信方法および情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体に関するものであり、特に、配信者側で当該コンテンツ情報の受信者数を把握することが可能な情報配信装置、情報配信方法および情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体に関するものである。
【０００２】
近時、インターネットやイントラネットの普及により、従来のテレビジョン放送と同様にして、講演会やコンサートの様子をライブ放送するシステムが注目されている。このシステムにおいては、ストリーミング技術により、画像データおゆび音声データから、受信装置側でリアルタイム再生が可能なコンテンツ情報を生成し、このコンテンツ情報をインターネット等を介して複数の受信装置へ一斉に配信している。このような単向方式の通信環境下では、配信者側で、当該コンテンツ情報を受信する、受信しないといった受信者側の情報が得られない。このことから、従来より、ライブ放送を効果的に実現するために、配信者側で受信者側の情報を把握する手段、方法が切望されている。
【０００３】
【従来の技術】
従来より、インターネットやイントラネットの環境下においては、講演会やコンサードの様子をコンテンツ情報（動画、音声）として、リアルタイムで受信者に配信する情報配信システムが普及しつつある。この情報配信システムは、講演会、コンサートの会場にそれぞれ設置されたビデオカメラおよびマイクと、ビデオカメラおよびマイクからの画像データおよび音声データから、ストリーミング技術を用いてリアルタイム再生が可能なストリーミングパケット（コンテンツ情報）を生成し、これを複数の受信装置へインターネット等を介して配信する配信装置とを備えている。
【０００４】
また、複数の受信装置では、ストリーミングパケットをそれぞれ受信し、リアルタイムでコンテンツ情報（動画、音声）を再生する。このように、情報配信システムは、インターネット等に接続された受信装置さえあれば、リアルタイムでコンテンツ情報の配信を受けることができることから、近時、注目されている。
【０００５】
【発明が解決しようとする課題】
ところで、情報配信システムを用いてライブ放送を企画する際には、通常、配信者側（主催者側）は、事前に、電子メール、ホームページ、紙媒体等の広告媒体を用いて、ライブ放送が開始される日時を宣伝することで、ライブ放送の受信者の数を増加させる努力をしている。
【０００６】
しかしながら、従来においては、伝送方式が単方向方式（配信装置→受信装置）であるため、実際にライブ放送を視聴する受信者の実数を配信者側で把握する手段が存在しない。したがって、実際には、ライブ放送を行うのに十分な数の受信者がいるという前提で、ライブ放送を開始していた。このように、受信者数を正確に把握できない状況では、受信者がほとんどいないにもかかわらずライブ放送が行われてしまうことも想定され、このような状況下では、まったく意味をなさないライブ放送を無駄に行ってしまうという問題があった。
【０００７】
本発明は、上記に鑑みてなされたもので、配信者側で情報の配信を受ける受信者の数を正確に把握でき、この把握結果に基づいて効果的に情報の配信を行うことができる情報配信装置、および情報配信方法および情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体を提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するために、請求項１にかかる発明は、ライブ放送を複数の受信装置（後述する実施の形態３の受信装置６０1 〜６０m に相当）へ配信する情報配信装置において、ライブ放送の配信を開始する前に、前記複数の受信装置に対して前記ライブ放送の配信を受けるか否かを問い合わせる問い合わせ手段（後述する実施の形態３の配信制御部３２に相当）と、前記複数の受信装置に対して前記問い合わせが行われてからの待機時間を計時する計時手段（後述する実施の形態３のタイマ８２に相当）と、前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計手段（後述する実施の形態３の集計制御部３７に相当）と、前記待機時間とあらかじめ設定された待機時間設定値とを比較する第１の比較手段（後述する実施の形態３の集計制御部８１に相当）と、前記集計結果に基づいて、前記配信を受ける受信装置の数とあらかじめ設定された配信開始しきい値とを比較する第２の比較手段（後述する実施の形態３の集計制御部８１に相当）と、前記第１の比較手段および前記第２の比較手段のそれぞれの比較結果に基づいて、前記待機時間が前記待機時間設定値以上であって、かつ前記配信を受ける受信装置の数が前記配信開始しきい値に満たない場合、前記配信を中止する配信制御手段（後述する実施の形態３の配信制御部３２に相当）とを備えることを特徴とする。
【０００９】
この請求項１にかかる発明によれば、ライブ放送の配信を開始する前に、問い合わせ手段により、複数の受信装置に対して配信を受けるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、集計手段に対して、配信を受ける旨の回答または配信を受けない旨の回答をそれぞれ出す。これにより、集計手段は、複数の受信装置から順次回答される結果を集計し、配信を受ける受信装置の数、配信を受けない受信装置の数を集計する。また、このとき、第１の比較手段により、待機時間と待機時間設定値とが比較されるとともに、第２の比較手段により、配信を受ける受信装置の数と配信開始しきい値とが比較される。そして、配信制御手段は、待機時間が待機時間設定値以上になり、かつ配信を受ける受信装置の数が配信開始しきい値に満たない場合、ライブ放送の配信を中止する。
【００１０】
このように、請求項１にかかる発明によれば、第１の比較手段を設けて、待機時間と待機時間設定値とを比較し、さらに第２の比較手段を設けて、配信を受ける受信装置の数と配信開始しきい値以上とを比較し、これら２つの比較結果に基づいて、ライブ放送の配信中止の可否を判断するようにしたので、経過時間を過ぎてもなお、配信を受ける受信装置の数が配信開始しきい値に満たない場合に、自動的にライブ放送の配信を中止することができる。
【００１１】
また、請求項２にかかる発明は、請求項１に記載の情報配信装置において、配信者に前記集計結果を報知する報知手段（後述する実施の形態３の表示部３６に相当）を備えることを特徴とする。
【００１２】
この請求項２にかかる発明によれば、報知手段により回答の集計結果が報知される。したがって、配信者は、報知された集計結果に基づいて、配信を行うかまたは中止するかを判断することが可能となる。
【００１３】
このように、請求項２にかかる発明によれば、報知手段により回答の集計結果を報知するようにしたので、配信者側で、配信を受ける受信者（受信装置）の数を正確に把握することができ、この把握結果に基づいて、配信を開始または中止するかを判断することができる。
【００１４】
また、請求項３にかかる発明は、請求項１または２に記載の情報配信装置において、前記集計結果に基づいて、前記配信を受ける受信装置の数とあらかじめ設定された配信決定しきい値とを比較する第３の比較手段（後述する実施の形態２の集計制御部７１に相当）を備え、前記配信制御手段は、前記第３の比較手段の比較結果に基づいて、前記配信を受ける受信装置の数が前記配信決定しきい値以上になった時点で、前記配信を行うこととすることを特徴とする。
【００１５】
この請求項３にかかる発明によれば、ライブ放送の配信を開始する前に、問い合わせ手段により、複数の受信装置に対して配信を受けるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、集計手段に対して、配信を受ける旨の回答または配信を受けない旨の回答をそれぞれ出す。これにより、集計手段は、複数の受信装置から順次回答される結果を集計し、配信を受ける受信装置の数、配信を受けない受信装置の数を集計する。また、このとき、第３の比較手段により、配信を受ける受信装置の数と配信決定しきい値とが比較される。そして、配信制御手段は、配信を受ける受信装置の数が配信決定しきい値以上になった時点で、情報の配信を行うこととする。
【００１６】
このように、請求項３にかかる発明によれば、第３の比較手段を設けて、配信を受ける受信装置の数と配信決定しきい値以上とを比較し、この比較結果に基づいて、ライブ放送の配信開始の可否を判断するようにしたので、配信者の判断を待たずに、自動的にライブ放送の配信を行うことができる。
【００１７】
また、請求項４にかかる発明は、請求項１または２に記載の情報配信装置において、前記集計結果に基づいて、前記配信を受けない受信装置の数とあらかじめ設定された配信中止しきい値とを比較する第４の比較手段（後述する実施の形態２の集計制御部７１に相当）を備え、前記配信制御手段は、前記比較手段の比較結果に基づいて、前記配信を受けない受信装置の数が前記配信中止しきい値以上になった時点で、前記配信を中止することを特徴とする。
【００１８】
この請求項４にかかる発明によれば、ライブ放送の配信を開始する前に、問い合わせ手段により、複数の受信装置に対して配信を受けるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、集計手段に対して、配信を受ける旨の回答または配信を受けない旨の回答をそれぞれ出す。これにより、集計手段は、複数の受信装置から順次回答される結果を集計し、配信を受ける受信装置の数、配信を受けない受信装置の数を集計する。また、このとき、第４の比較手段により、配信を受けない受信装置の数と配信中止しきい値とが比較される。そして、配信制御手段は、配信を受けない受信装置の数が配信中止しきい値以上になった時点で、ライブ放送の配信を中止する。
【００１９】
このように、請求項４にかかる発明によれば、第４の比較手段を設けて、配信を受けない受信装置の数と配信中止しきい値以上とを比較し、この比較結果に基づいて、ライブ放送の配信中止の可否を判断するようにしたので、配信者の判断を待たずに、自動的にライブ放送の配信を中止することができる。
【００２０】
また、請求項５にかかる発明は、リアルタイム再生が可能な情報を複数の受信装置（後述する実施の形態４の受信装置９０ 1 〜９０ m に相当）へ配信する情報配信装置において、緊急情報の配信を開始する前に、前記複数の受信装置に対して前記緊急情報を受信することが可能であるか否かを問い合わせる問い合わせ手段（後述する実施の形態４の配信制御部３２に相当）と、前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計手段（後述する実施の形態４の集計制御部３７に相当）と、前記集計手段の集計結果に基づいて、緊急情報の配信を開始または中止する配信制御手段（後述する実施の形態４の配信制御部３２に相当）とを備えることを特徴とする。
【００２１】
この請求項５にかかる発明によれば、緊急情報の配信を開始する前に、問い合わせ手段により、複数の受信装置に対して前記情報を受信することが可能であるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、装置の状態を確認した後、集計手段に対して、緊急情報を受信することが可能であるか否かの回答をそれぞれ出す。これにより、集計手段は、複数の受信装置から順次回答される結果を集計し、配信を受けることが可能な受信装置の数、配信を受けることができない受信装置の数を集計する。そして、配信制御手段は、集計手段の集計結果に基づいて、緊急情報の配信を開始または中止する。
【００２２】
このように、請求項５にかかる発明によれば、複数の受信装置に対して緊急情報を受信することが可能であるか否かの問い合わせを行い、問い合わせに対応する回答の集計結果に基づいて、緊急情報の配信を開始または中止するようにしたので、受信者の意志に関わりなく、緊急の情報を受信可能な受信装置へ配信するという緊急配信を効果的に行うことができる。
【００２３】
また、請求項６にかかる発明は、ライブ放送を複数の受信装置へ配信する情報配信方法において、ライブ放送の配信を開始する前に、前記複数の受信装置に対して前記ライブ放送の配信を受けるか否かを問い合わせる問い合わせ工程（後述する実施の形態３のステップＳＥ１に相当）と、前記複数の受信装置に対して前記問い合わせが行われてからの待機時間を計時する計時工程（後述する実施の形態３のステップＳＥ２に相当）と、前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計工程（後述する実施の形態３のステップＳＥ３に相当）と、前記待機時間とあらかじめ設定された待機時間設定値とを比較する第１の比較工程（後述する実施の形態３のステップＳＥ５に相当）と、前記集計結果に基づいて、前記配信を受ける受信装置の数とあらかじめ設定された配信開始しきい値とを比較する第２の比較工程（後述する実施の形態３のステップＳＥ６に相当）と、前記第１の比較工程および前記第２の比較工程のそれぞれの比較結果に基づいて、前記待機時間が前記待機時間設定値以上であって、かつ前記配信を受ける受信装置の数が前記配信開始しきい値に満たない場合、前記配信を中止する配信制御工程（後述する実施の形態３のステップＳＥ９に相当）とを含むことを特徴とする。
【００２４】
この請求項６にかかる発明によれば、ライブ放送の配信を開始する前に、問い合わせ工程では、複数の受信装置に対して配信を受けるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、配信を受ける旨の回答または配信を受けない旨の回答をそれぞれ出す。これにより、集計工程では、複数の受信装置から順次回答される結果が集計され、配信を受ける受信装置の数、配信を受けない受信装置の数が集計される。そして、第１の比較工程では、待機時間とあらかじめ設定された待機時間設定値とが比較され、第２の比較工程では、集計結果に基づいて、配信を受ける受信装置の数とあらかじめ設定された配信開始しきい値とが比較される。そして、配信制御工程では、待機時間が待機時間設定値以上になり、かつ配信を受ける受信装置の数が配信開始しきい値に満たない場合、情報の配信が中止される。
【００２５】
このように、請求項６にかかる発明によれば、待機時間と待機時間設定値とを比較し、配信を受ける受信装置の数と配信開始しきい値以上とを比較し、これら２つの比較結果に基づいて、ライブ放送の配信中止の可否を判断するようにしたので、経過時間を過ぎてもなお、配信を受ける受信装置の数が配信開始しきい値に満たない場合に、自動的にライブ放送の配信を中止することができる。
【００２６】
また、請求項７にかかる発明は、ライブ放送を複数の受信装置へ配信する情報配信装置に適用される情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体であって、ライブ放送の配信を開始する前に、前記複数の受信装置に対して前記ライブ放送の配信を受けるか否かを問い合わせる問い合わせ工程（後述する実施の形態３のステップＳＥ１に相当）と、前記複数の受信装置に対して前記問い合わせが行われてからの待機時間を計時する計時工程（後述する実施の形態３のステップＳＥ２に相当）と、前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計工程（後述する実施の形態３のステップＳＥ３に相当）と、前記待機時間とあらかじめ設定された待機時間設定値とを比較する第１の比較工程（後述する実施の形態３のステップＳＥ５に相当）と、前記集計結果に基づいて、前記配信を受ける受信装置の数とあらかじめ設定された配信開始しきい値とを比較する第２の比較工程（後述する実施の形態３のステップＳＥ６に相当）と、前記第１の比較工程および前記第２の比較工程のそれぞれの比較結果に基づいて、前記待機時間が前記待機時間設定値以上であって、かつ前記配信を受ける受信装置の数が前記配信開始しきい値に満たない場合、前記配信を中止する配信制御工程（後述する実施の形態３のステップＳＥ９に相当）と、をコンピュータに実行させるための情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００２７】
この請求項７にかかる発明によれば、ライブ放送の配信を開始する前に、問い合わせ工程では、複数の受信装置に対して配信を受けるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、配信を受ける旨の回答または配信を受けない旨の回答をそれぞれ出す。これにより、集計工程では、複数の受信装置から順次回答される結果が集計され、配信を受ける受信装置の数、配信を受けない受信装置の数が集計される。そして、第１の比較工程では、待機時間とあらかじめ設定された待機時間設定値とが比較され、第２の比較工程では、集計結果に基づいて、配信を受ける受信装置の数とあらかじめ設定された配信開始しきい値とが比較される。そして、配信制御工程では、待機時間が待機時間設定値以上になり、かつ配信を受ける受信装置の数が配信開始しきい値に満たない場合、情報の配信が中止される。
【００２８】
このように、請求項７にかかる発明によれば、待機時間と待機時間設定値とを比較し、配信を受ける受信装置の数と配信開始しきい値以上とを比較し、これら２つの比較結果に基づいて、ライブ放送の配信中止の可否を判断するようにしたので、経過時間を過ぎてもなお、配信を受ける受信装置の数が配信開始しきい値に満たない場合に、自動的にライブ放送の配信を中止することができる。
【００２９】
また、請求項８にかかる発明は、リアルタイム再生が可能な情報を複数の受信装置へ配信する情報配信方法において、緊急情報の配信を開始する前に、前記複数の受信装置に対して前記緊急情報を受信することが可能であるか否かを問い合わせる問い合わせ工程（後述する実施の形態４のステップＳＡ１に相当）と、前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計工程（後述する実施の形態４のステップＳＡ２に相当）と、前記集計工程の集計結果に基づいて、緊急情報の配信を開始または中止する配信制御工程（後述する実施の形態４のステップＳＡ５またはステップＳＡ６に相当）と、を含むことを特徴とする。
【００３０】
この請求項８にかかる発明によれば、問い合わせ工程では、緊急情報の配信を開始する前に、複数の受信装置に対して情報を受信することが可能であるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、装置の状態を確認した後、緊急情報を受信することが可能であるか否かの回答をそれぞれ出す。これにより、集計工程では、複数の受信装置から順次回答される結果が集計され、配信を受けることが可能な受信装置の数、配信を受けることができない受信装置の数が集計される。そして、配信制御工程では、集計結果に基づいて、緊急情報の配信が開始または中止される。
【００３１】
このように、請求項８にかかる発明によれば、複数の受信装置に対して緊急情報を受信することが可能であるか否かの問い合わせを行い、問い合わせに対応する回答の集計結果に基づいて、緊急情報の配信を開始または中止するようにしたので、受信者の意志に関わりなく、緊急の情報を受信可能な受信装置へ配信するという緊急配信を効果的に行うことができる。
【００３２】
また、請求項９にかかる発明は、リアルタイム再生が可能な情報を複数の受信装置へ配信する情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体であって、緊急情報の配信を開始する前に、前記複数の受信装置に対して前記緊急情報を受信することが可能であるか否かを問い合わせる問い合わせ工程（後述する実施の形態４のステップＳＡ１に相当）と、前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計工程（後述する実施の形態４のステップＳＡ２に相当）と、前記集計工程の集計結果に基づいて、緊急情報の配信を開始または中止する配信制御工程（後述する実施の形態４のステップＳＡ５またはステップＳＡ６に相当）と、をコンピュータに実行させるための情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００３３】
この請求項９にかかる発明によれば、問い合わせ工程では、緊急情報の配信を開始する前に、複数の受信装置に対して情報を受信することが可能であるか否かの問い合わせが行われる。そして、問い合わせを受けると、複数の受信装置は、装置の状態を確認した後、緊急情報を受信することが可能であるか否かの回答をそれぞれ出す。これにより、集計工程では、複数の受信装置から順次回答される結果が集計され、配信を受けることが可能な受信装置の数、配信を受けることができない受信装置の数が集計される。そして、配信制御工程では、集計結果に基づいて、緊急情報の配信が開始または中止される。
【００３４】
このように、請求項９にかかる発明によれば、複数の受信装置に対して緊急情報を受信することが可能であるか否かの問い合わせを行い、問い合わせに対応する回答の集計結果に基づいて、緊急情報の配信を開始または中止するようにしたので、受信者の意志に関わりなく、緊急の情報を受信可能な受信装置へ配信するという緊急配信を効果的に行うことができる。
【００３５】
【発明の実施の形態】
以下、図面を参照して本発明にかかる情報配信装置、情報配信方法および情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体の実施の形態１〜４について詳細に説明する。
【００３６】
（実施の形態１）
図１は、本発明にかかる実施の形態１の構成を示すブロック図である。この図に示した情報配信システムは、ストリーミング技術を用いて、コンテンツ情報（動画データ、画像データ）を複数の受信装置へリアルタイムで配信し、受信装置側で、配信されたコンテンツ情報をリアルタイムで再生するシステムである。したがって、この情報配信システムは、リアルタイム再生が可能であることから、講演会やコンサート等のライブ放送に利用される。また、情報配信システムにおける配信プロトコルとしては、たとえば、ＵＤＰ（User Datagram Protocol）が挙げられるが、配信プロトコルの種別は問わない。さらに、情報配信システムにおいては、ＭＢｏｎｅ（virtual Multicast Backbone On the interNEt）技術を用いて、コンテンツ情報の配信を行うようにしてもよい。
【００３７】
図１に示したネットワークＮは、イントラネット、インターネット等であり、後述するストリーミングパケットＳＰ0 〜ＳＰn 等を伝送する。このネットワークＮには、配信者側に設置された配信装置３０と、ストリームサーバ４０1 〜４０n と、管理サーバ５０と、ユーザ側（受信者側）にそれぞれ設置された受信装置６０1 〜６０m （ｍ≧ｎ）とがそれぞれ接続されている。
【００３８】
上記配信装置３０は、受信装置６０1 〜６０m へ配信すべきストリーミングパケットＳＰ0 （コンテンツ情報）を生成する。このストリーミングパケットＳＰ0 は、ストリーム帯域、フレームレート、画面サイズ等をパラメータとして、動画データおよび音声データからなるコンテンツ情報が圧縮されたパケットである。ここで、ストリーム帯域は、ストリーミングパケットＳＰ0 がネットワークＮに送信された際の占有伝送帯域である。フレームレートは、ユーザ側でリアルタイム再生されるコンテンツ情報の毎秒あたりの画面数であり、このフレームレートが大きいほど、なめらかな動画再生が可能となるが、その分だけ広いストリーム帯域が必要となる。また、画面サイズは、ユーザ側でリアルタイム再生されるコンテンツ情報の表示画面を構成する画素数（縦ピクセル数×横ピクセル数）である。
【００３９】
ビデオカメラ１０は、講演会場やコンサート会場に設置されており、講演会やコンサートの様子をリアルタイムで撮像し、撮像結果を動画データＤ1 として配信装置３０へ出力する。同様にして、マイクロフォン２０も講演会場やコンサード会場に設置されている。このマイクロフォン２０は、講演者の音声や、コンサート会場の音声を音声データＤ2 に変換し、これを配信装置３０へリアルタイムで出力する。
【００４０】
ここで、上述した配信装置３０の構成について図２を参照して詳述する。図２においては、図１の各部にそれぞれ対応する部分には同一の符号を付ける。この図に示した配信装置３０において、エンコード部３１は、上述したストリーム帯域、フレームレート、画面サイズ等のパラメータに基づいて、ビデオカメラ１０およびマイクロフォン２０からキャプチャリングされた動画データＤ1 および音声データＤ2 を符号化することで、ストリーミングパケットＳＰ0 を生成する。
【００４１】
具体的には、エンコード部３１は、動画データＤ1 および音声データＤ2 をそれぞれディジタルデータに変換した後、画面サイズやフレームレート等を考慮してディジタルデータの情報量を減らす。さらに、エンコード部３１は、コーデック技術を用いて、上記ディジタルデータをリアルタイムで圧縮し、動画データＤ1 と音声データＤ2 との同期がとられたストリーミングパケットＳＰ0 を生成する。
【００４２】
配信制御部３２は、ストリーミングパケットＳＰ0 （コンテンツ情報）の配信制御、受信装置６０1 〜６０m に対してコンテンツ情報の配信がある旨を告知するための配信通知等を行う。この配信制御部３２の動作の詳細については、後述する。ネットワーク制御部３３は、配信プロトコルを用いて、ネットワークＮの伝送帯域に応じた転送レートでストリーミングパケットＳＰ0 をネットワークＮへ送信する機能を備えている。また、ネットワーク制御部３３は、ネットワークＮの輻輳により、ストリーミングパケットＳＰ0 の伝送中にパケットロスが生じた場合に、ストリーミングパケットＳＰ0 を蓄積するバッファリング機能も備えている。
【００４３】
さらに、ネットワーク制御部３３は、配信プロトコルの他にＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol ）を用いて、管理サーバ５０（図１参照）との間で、配信制御情報の送受信を行う。この配信制御情報としては、つぎの（１）項および（２）項の情報が挙げられる。
【００４４】
（１）受信装置６０1 〜６０m （図１参照）に対してコンテンツ情報の配信を行う旨を事前に通知すべきことを管理サーバ５０へ指示するための配信通知指示情報
（２）受信装置６０1 〜６０m からの上記配信通知に対する応答通知に関する応答通知情報
ここで、上記（２）項の応答通知としては、ユーザがコンテンツ情報の受信を承諾する旨の通知、または受信を拒否する旨の通知という２種類がある。このように、配信装置３０と受信装置６０1 〜６０m との間では、管理サーバ５０を経由して情報の送受信が行われる。
【００４５】
ユーザインタフェース制御部３４は、配信制御部３２と、入力部３５、表示部３６および集計制御部３７との間のインタフェースをとる。入力部３５は、マウス、キーボード等の入力デバイスである。表示部３６は、ＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode-Ray Tube）等であり、配信操作に必要な各種情報を表示する。この各種情報としては、配信先のアドレス情報や、図５（ｂ）に示した配信装置側選択画面２００がある。配信装置側選択画面２００は、配信を開始するか、または中止するかを配信者に選択させるための画面である。この配信装置側選択画面２００の詳細については、後述する。
【００４６】
図２に戻り、集計制御部３７は、上述した（２）項の情報、すなわち、受信装置６０1 〜６０m からの複数の応答通知を集計し、集計結果をユーザインタフェース制御部３４を介して、配信制御部３２へ渡す。つまり、集計制御部３７は、コンテンツ情報の配信を受けるユーザの人数と、配信を配信を受けないユーザの人数とを集計する。
【００４７】
図１に戻り、ストリームサーバ４０1 〜４０n は、分散配置されたｎ台のサーバであり、受信装置６０1 〜６０m へストリーミングパケットＳＰ1 〜ＳＰn をそれぞれ配信する。ここで、ストリームサーバ４０1 〜４０n において、ストリームサーバ４０1 は、プライマリサーバとしての機能を備えており、その他のストリームサーバ４０2 〜４０n は、セカンダリサーバとしての機能をそれぞれ備えている。
【００４８】
また、ストリームサーバ４０1 〜４０n においては、負荷分散を目的として、配信先がグルーピングされている。すなわち、ストリームサーバ４０1 の配信先は、受信装置６０1 であり、ストリームサーバ４０2 の配信先は、受信装置６０2 および６０3 （図示略）である。以下、同様にして、ストリームサーバ４０n の配信先は、受信装置６０m-1 （図示略）および６０m である。また、このような負荷分散は、管理サーバ５０が受信装置６０1 〜６０m に対して接続すべきストリームサーバを指示することにより実現される。
【００４９】
ストリームサーバ４０1 （プライマリサーバ）は、配信装置３０からネットワークＮを介してストリーミングパケットＳＰ0 の供給を受け、これをストリームサーバ４０2 〜４０n （セカンダリサーバ）へそれぞれ分配する。ストリームサーバ４０1 〜４０n は、ストリーミングパケットＳＰ0 をストリーミングパケットＳＰ1 〜ＳＰn としてそれぞれの配信先へ配信する。このように、ストリームサーバ４０1 〜４０n からは、同一の情報であるストリーミングパケットＳＰ1 〜ＳＰn が受信を承諾した受信装置６０1 〜６０m へ一斉に配信される。
【００５０】
管理サーバ５０は、前述した配信装置３０からの配信通知指示情報にしたがって、コンテンツ情報の配信前に、一斉に受信装置６０1 〜６０m へ配信通知を行う。また、管理サーバ５０は、受信装置６０1 〜６０m からの配信通知に対する応答通知を受け、これらを応答通知情報として、ネットワークＮを介して配信装置３０へ渡す。
【００５１】
受信装置６０1 〜６０m は、ストリームサーバ４０1 〜４０n からネットワークＮを介してそれぞれ配信されるストリーミングパケットＳＰ1 〜ＳＰn を受信し、ストリーミングパケットＳＰ1 〜ＳＰn から同一のコンテンツ情報（動画データ、音声データ）をそれぞれ再生する装置である。また、受信装置６０1 〜６０m は、コンテンツ情報の配信前に、管理サーバ５０から配信通知を受けて、これに対応する応答通知を管理サーバ５０へ返す。この応答通知としては、前述したように、ストリーミングパケットＳＰ1 〜ＳＰn を受信するか否か、いいかえれば、コンテンツ情報の配信を受けるか否かに関するものである。
【００５２】
ここで、上述した受信装置６０1 の構成について図３を参照して詳述する。図３においては、図１の各部にそれぞれ対応する部分には同一の符号を付ける。この図に示した配信制御部６１は、配信されたストリーミングパケットＳＰ1 （コンテンツ情報）の再生制御、配信装置３０（管理サーバ５０）に対してストリーミングパケットＳＰ1 を受信するか否かに関する応答通知等を行う。なお、配信制御部６１の動作の詳細については、後述する。
【００５３】
ユーザインタフェース制御部６２は、配信制御部６１と、受信制御部６４、入力部６５、表示部６６およびスピーカ６７との間のインタフェースをとる。ネットワーク制御部６３は、配信プロトコルを用いて、ストリームサーバ４０1 （図１参照）からのストリーミングパケットＳＰ1 を受信する機能を備えている。また、ネットワーク制御部６３は、配信プロトコルの他にＴＣＰ／ＩＰを用いて、管理サーバ５０（図１参照）との間で、前述した配信制御情報の送受信を行う。
【００５４】
受信制御部６４は、配信制御部６１からの指示にしたがって、ネットワーク制御部６３におけるストリーミングパケットＳＰ1 の受信を制御する。具体的には、配信制御部６１により受信が指示された場合に、受信制御部６４は、ストリーミングパケットＳＰ1 を受信するようにネットワーク制御部６３を制御する。
【００５５】
入力部６５は、マウス、キーボード等の入力デバイスである。表示部６６は、ＬＣＤ、ＣＲＴ等であり、コンテンツ情報のうち動画を再生する。また、表示部６６は、配信前に管理サーバ５０（配信装置３０）からの配信通知を受けて、図５（ａ）に示した受信装置側選択画面１００を表示する。この受信装置側選択画面１００は、ライブ放送を受信するか否か、すなわち、コンテンツ情報の配信を受けるか否かをユーザに選択させるための画面である。この受信装置側選択画面１００の詳細については、後述する。スピーカ６７は、コンテンツ情報のうち音声を再生する。
【００５６】
つぎに、実施の形態１の動作について図４に示したフローチャートを参照しつつ説明する。以下においては、図５（ａ）に示した配信者（Yuji Matsuzaki）が講演者として、「ストリーミングシステムについて」と題する講演会を行い、この講演会の様子をライブ放送する場合を例にして説明する。すなわち、以下においては、上記講演会にかかる動画および音声をコンテンツ情報（ストリーミングパケットＳＰ0 〜ＳＰn ）として受信装置６０1 〜６０m へ配信する場合について説明する。
【００５７】
図１において、受信装置６０1 〜６０m は、起動されると、図４に示したステップＳＢ１へそれぞれ進み、管理サーバ５０（配信装置３０）からの配信通知を受けたか否かをそれぞれ判断し、この場合、判断結果を「Ｎｏ」として同判断をそれぞれ繰り返す。ここで、以下においては、受信装置６０2 〜６０m の動作が受信装置６０1 の動作と同様であるため、図３に示した受信装置６０1 の動作を中心にして説明する。
【００５８】
そして、ライブ放送の開始前に、配信者（または他のオペレータ）により、入力部３５（図２参照）を用いて、配信通知をすべきことを指示する情報が入力されると、配信制御部３２は、図４に示したステップＳＡ１へ進み、受信装置６０1 〜６０m へ配信通知を行うことを指示するための配信通知指示情報をネットワークＮを介して管理サーバ５０へ送信する。
【００５９】
また、配信制御部３２は、図５（ｂ）に示した配信装置側選択画面２００を表示部３６に表示させる。この配信装置側選択画面２００には、ライブ放送のタイトル（「ストリーミングシステムについて」）、当該ライブ放送を受信する受信者数の確認文（「現在、・・・・受信準備をして、待機しています。」）が表示されている。ここで、受信者数表示領域２０１には、受信承諾者数ｘが表示されている。この受信承諾者数ｘは、ライブ放送の受信を承諾したユーザ（受信者）の人数である。したがって、配信者は、上記受信承諾者数ｘを目視確認することで、ライブ放送を受信するユーザ（受信者）の人数を把握する。ただし、この場合、初期状態であるため、受信承諾者数ｘは０である。また、配信装置側選択画面２００には、配信の開始に関する質問文（「配信を開始しますか？」）が表示されている。
【００６０】
さらに、配信装置側選択画面２００には、いずれもソフトボタンである配信開始ボタン２０２および配信中止ボタン２０３が表示されている。これらの配信開始ボタン２０２および配信中止ボタン２０３は、配信の開始または中止を選択するための選択ボタンである。すなわち、配信開始ボタン２０２は、配信を開始する場合にソフト的に押下されるボタンであり、配信中止ボタン２０３は、配信を中止する場合にソフト的に押下されるボタンである。これらの配信開始ボタン２０２および配信中止ボタン２０３は、入力部３５（図２参照）のマウスによるドラッグ・アンド・ドロップ操作によりそれぞれ押下される。
【００６１】
そして、図１において、配信通知指示情報を受信すると、管理サーバ５０は、一斉に受信装置６０1 〜６０m へ配信通知を行う。そして、上記配信通知を受けると、図３に示した受信装置６０1 の配信制御部６１は、ステップＳＢ１の判断結果を「Ｙｅｓ」として、ステップＳＢ２へ進む。ステップＳＢ２では、配信制御部６１は、ユーザインタフェース制御部６２を制御して、表示部６６に図５（ａ）に示した受信装置側選択画面１００を表示させた後、ステップＳＢ３へ進む。
【００６２】
この受信装置側選択画面１００には、ライブ放送が行われる旨の告知文（「これから以下のライブ放送があります。」）、配信者（「Yuji Matsuzaki」）およびタイトル（「ストリーミングシステムについて」）からなるライブ放送内容に関する情報１０１が表示されている。したがって、ユーザは、上記告知文および情報１０１を目視確認することにより、ライブ放送が行われること、およびその内容を認識する。
【００６３】
また、受信装置側選択画面１００には、ライブ放送を受信するか否かの質問文（「このライブ放送を受信しますか？」）が表示されている。したがって、ユーザは、上記質問文を目視確認することで、ライブ放送を受信するか否かを判断する。さらに受信装置側選択画面１００には、いずれもソフトボタンである受信承諾ボタン１０２および受信拒否ボタン１０３が表示されている。
【００６４】
これらの受信承諾ボタン１０２および受信拒否ボタン１０３は、受信するか否かを選択するための選択ボタンである。すなわち、受信承諾ボタン１０２は、受信を承諾する場合にソフト的に押下されるボタンであり、受信拒否ボタン１０３は、受信を拒否する場合にソフト的に押下されるボタンである。これらの受信承諾ボタン１０２および受信拒否ボタン１０３は、入力部６５（図３参照）のマウスによるドラッグ・アンド・ドロップ操作によりそれぞれ押下される。
【００６５】
ステップＳＢ３では、受信装置６０1 （図３参照）の配信制御部６１は、ユーザにより選択ボタン（受信承諾ボタン１０２または受信拒否ボタン１０３）が押下されたか否かを判断し、この場合、押下されていないものとすると、判断結果を「Ｎｏ」として、同判断を繰り返す。
【００６６】
そして、図５（ａ）に示した受信装置側選択画面１００を目視確認したユーザは、ライブ放送を受信するという意志表示を行うため、入力部６５を用いて、受信承諾ボタン１０２を押下する。これにより、配信制御部６１は、受信承諾ボタン１０２が押下されているため、ステップＳＢ３の判断結果を「Ｙｅｓ」として、ステップＳＢ４へ進む。ステップＳＢ４では、受信装置６０1 の配信制御部６１は、管理サーバ５０（配信装置３０）に対して、受信承諾である旨の応答通知を行った後、一連の処理を終了する。
【００６７】
一方、ライブ放送を受信しないという意志表示を行う場合、ユーザは、入力部６５を用いて、受信拒否ボタン１０３を押下する。これにより、配信制御部６１は、受信拒否ボタン１０３が押下されているため、ステップＳＢ３の判断結果を「Ｙｅｓ」として、ステップＳＢ５へ進む。ステップＳＢ５では、受信装置６０1 の配信制御部６１は、管理サーバ５０（配信装置３０）に対して、受信拒否である旨の応答通知を行った後、一連の処理を終了する。また、他の受信装置６０2 〜６０m も、受信装置６０1 と同様にして、管理サーバ５０（配信装置３０）へ受信承諾または受信拒否の応答通知を、順次行った後、一連の処理を終了する。
【００６８】
そして、受信装置６０1 〜６０m から応答通知を順次受けると、管理サーバ５０は、受け取った順に、上記応答通知を応答通知情報としてとしてネットワークＮを介して配信装置３０へ渡す。これにより、ステップＳＡ２では、図２に示した集計制御部３７は、応答通知を集計する。具体的には、集計制御部３７は、受信承諾である旨の応答通知を１件受ける毎と、受信承諾者数ｘ（図５（ｂ）参照）を１インクリメントし、同様にして、受信拒否である旨の応答通知を１件受ける毎に、受信拒否者数ｙを１インクリメントすることで、応答通知の集計を行う。そして、集計制御部３７は、集計結果（受信承認者数ｘ、受信拒否者数ｙ）をユーザインタフェース制御部３４を介して配信制御部３２へ渡す。
【００６９】
これにより、ステップＳＡ３では、配信制御部３２は、上記集計結果（受信承諾者数ｘ、受信拒否者数ｙ）のうち現在の受信承諾者数ｘを図５（ｂ）に示した受信者数表示領域２０１に表示させた後、ステップＳＡ４へ進む。ステップＳＡ４では、配信制御部３２は、ユーザにより選択ボタン（配信開始ボタン２０２または配信中止ボタン２０３）が押下されたか否かを判断し、この場合、押下されていないものとすると、判断結果を「Ｎｏ」とする。したがって、この場合ステップＳＡ４の判断結果が「Ｙｅｓ」となるまで、ステップＳＡ２およびステップＳＡ３においては、応答通知を受ける毎に、応答通知の集計および集計結果（受信承諾者数ｘ）が表示される。
【００７０】
ここで、配信者は、図５（ｂ）に示した配信装置側選択画面２００の受信者数表示領域２０１に表示されている受信承諾者数ｘを目視確認した後、この受信承諾者数ｘが当初予定していた予定人数に達してるか否かを判断する。この場合、受信承諾者数ｘが予定人数に満たないものとすると、配信者は、いずれの操作もすることなく、待機する。この待機中においては、受信承諾の応答通知を受ける毎に、図５（ａ）に示した受信承諾者数ｘが１インクリメントされる。
【００７１】
そして、受信承諾者数ｘが予定人数に達すると、配信者は、入力部３５を用いて、配信開始ボタン２０２を押下した後、講演を開始する。これにより、配信制御部３２は、配信開始ボタン２０２が押下されているため、ステップＳＡ４の判断結果を「Ｙｅｓ」として、ステップＳＡ５へ進む。ステップＳＡ５では、配信制御部３２は、装置各部を制御して配信処理を行う。
【００７２】
この配信処理において、図２に示したビデオカメラ１０およびマイクロフォン２０からは、講演に関する動画データＤ1 および音声データＤ2 が出力される。そして、これらの動画データＤ1 および音声データＤ2 がエンコード部３１にキャプチャリングされると、エンコード部３１は、ストリーム帯域等のパラメータに基づいて、動画データＤ1 および音声データＤ2 を符号化・圧縮することで、ストリーミングパケットＳＰ0 を生成する。
【００７３】
このストリーミングパケットＳＰ0 は、ネットワーク制御部３３およびネットワークＮを介して、図１に示したストリームサーバ４０1 〜４０n へそれぞれ分配される。これにより、ストリームサーバ４０1 〜４０n は、ストリーミングパケットＳＰ0 をストリーミングパケットＳＰ1 〜ＳＰn として、配信先の受信装置６０1 〜６０m へそれぞれ配信する。
【００７４】
ただし、受信装置６０1 〜６０m において、受信拒否である旨の応答通知を行った受信装置へはストリーミングパケットが配信されない。したがって、受信拒否である旨の応答通知を行った受信装置においては、コンテンツ情報が再生されない。
【００７５】
一方、受信装置６０1 〜６０m において、受信承諾である旨の応答通知を行った受信装置は、受信制御部（図３：受信制御部６４参照）の制御により、ストリーミングパケットを受信した後、コンテンツ情報を再生する。たとえば、図３に示した受信装置６０1 において、ストリーミングパケットＳＰ1 がネットワーク制御部６３により受信されると、このストリーミングパケットＳＰ1 は、配信制御部６１へ渡される。
【００７６】
これにより、配信制御部６１は、ストリーミングパケットＳＰ1 を復元することで、動画データおよび音声データを生成する。つぎに、配信制御部６１は、同期がとられた動画データおよび音声データを、ユーザインタフェース制御部６２を経由して表示部６６およびスピーカ６７へそれぞれ供給する。これにより、表示部６６においては、講演の様子を表す動画がリアルタイムで再生され、スピーカ６７においては、講演者の音声が上記動画に同期してリアルタイムで再生される。
【００７７】
一方、配信通知を行ってからの待機時間が所定の時間を超えても、なお、受信承諾者数ｘが予定人数に達しない場合、配信者は、入力部３５を用いて、配信中止ボタン２０３を押下した後、講演を中止する。これにより、配信制御部３２は、配信中止ボタン２０３が押下されているため、ステップＳＡ４の判断結果を「Ｙｅｓ」として、ステップＳＡ６へ進む。ステップＳＡ６では、配信制御部３２は、装置各部を制御して配信中止処理を行う。この配信中止処理においては、配信制御部３２は、管理サーバ５０を経由して受信装置６０1 〜６０m へライブ放送（講演）が中止になった旨を通知する。
【００７８】
以上説明したように、実施の形態１によれば、複数の受信装置６０1 〜６０m に対して配信を受けるか否かを問い合わせる配信通知を行い、この配信通知に対する応答通知の集計結果に基づいて、コンテンツ情報の配信を開始または中止するようにしたので、配信者側でコンテンツ情報の配信を受ける受信者の数を正確に把握し、この把握結果に基づいて効果的にコンテンツ情報の配信を行うことができる。
【００７９】
また、実施の形態１によれば、表示部３６に集計制御部３７の集計結果（受信承認者数ｘ）を表示するようにしたので、配信者側で、配信を受ける受信者の数を正確に把握することができ、この把握結果に基づいて、配信を開始または中止するかを判断することができる。
【００８０】
（実施の形態２）
さて、前述した実施の形態１においては、受信承諾者数ｘ（図５（ｂ）参照）を確認することで、配信を開始するか、または中止するかを配信者が判断する例について説明したが、あらかじめ設定されたしきい値に基づいて、上記判断を行うようにしてもよい。以下、この場合を実施の形態２として説明する。
【００８１】
図６は、本発明にかかる実施の形態２の構成を示すブロック図である。この図において、図１の各部に対応する部分には同一の符号を付け、その説明を省略する。図６においては、図１に示した配信装置３０に代えて、配信装置７０が設けられている。この配信装置７０の基本的な機能は、配信装置３０と同様である。しかしながら、配信装置７０は、上述したしきい値を用いて配信を開始するか、または中止するかを判断している点が配信装置３０と異なる。
【００８２】
ここで、上述した配信装置７０の構成について図７を参照して詳述する。図７においては、図２の各部にそれぞれ対応する部分には同一の符号を付け、その説明を省略する。この図においては、図２に示した集計制御部３７に代えて、集計制御部７１が新たに設けられており、さらに、しきい値設定部７２が新たに設けられている。
【００８３】
図７に示した集計制御部７１は、集計制御部３７と同様にして、受信装置６０1 〜６０m （図６参照）からの複数の応答通知を集計し、集計結果（受信承諾者数ｘ、受信拒否者数ｙ）をユーザインタフェース制御部３４を介して、配信制御部３２へ渡す。
【００８４】
また、集計制御部７１は、動作例１として、受信承諾者数ｘと、しきい値設定部７２によりあらかじめ設定された配信開始しきい値ＴＨ1 とを比較し、受信承諾者数ｘが配信開始しきい値ＴＨ1 以上になった時点で、配信者の判断にかかわらず、自動的に配信処理を実行する。さらに、集計制御部７１は、動作例２として、受信拒否者数ｙとしきい値設定部７２によりあらかじめ設定された配信中止しきい値ＴＨ2 とを比較し、受信拒否者数ｙが配信中止しきい値ＴＨ2 以上になった時点で、配信者の判断にかかららず、自動的に配信中止処理を実行する。しきい値設定部７２は、集計制御部７１に配信開始しきい値ＴＨ1 または配信中止しきい値ＴＨ2 を設定する。
【００８５】
つぎに、実施の形態２の動作例１について図８に示したフローチャートを参照しつつ説明する。配信装置７０側の動作であるステップＳＣ１〜ＳＣ７において、ステップＳＣ４を除く、ステップＳＣ１〜ステップＳＣ３およびステップＳＣ５〜ステップＳＣ７は、前述した図４に示したステップＳＡ１〜ステップＳＡ６と同様である。さらに、図８に示したステップＳＢ１〜ステップＳＢ５からなる受信装置６０1 〜６０m 側の動作は、図４に示したものと同一である。また、以下の動作例１において、図７に示した集計制御部７１には、配信開始しきい値ＴＨ1 が設定されているものとする。
【００８６】
図６において、受信装置６０1 〜６０m は、起動されると、図８に示したステップＳＢ１へ進み、管理サーバ５０（配信装置７０）からの配信通知を受けたか否かをそれぞれ判断し、この場合、判断結果を「Ｎｏ」として同判断をそれぞれ繰り返す。そして、ライブ放送の開始前に、配信者（または他のオペレータ）により、入力部３５（図７参照）を用いて、配信通知をすべきことを指示する情報が入力されると、配信制御部３２は、図８に示したステップＳＣ１へ進み、受信装置６０1 〜６０m へ配信通知を行うことを指示するための配信通知指示情報をネットワークＮを介して管理サーバ５０へ送信する。以後、前述した実施の形態１と同様の動作が行われる。
【００８７】
すなわち、上記配信通知を受けると、受信装置６０1 〜６０m は、ステップＳＢ１の判断結果を「Ｙｅｓ」として、ステップＳＢ２へ進む。これにより、ステップＳＢ２では、受信装置側選択画面１００（図５（ａ）参照）が表示され、ステップＳＢ３では、受信装置６０1 〜６０m は、ユーザにより選択ボタン（受信承諾ボタン１０２または受信拒否ボタン１０３）が押下されたか否かを判断する。
【００８８】
そして、ユーザにより受信承諾ボタン１０２が押下されると、受信装置６０1 〜６０m は、ステップＳＢ３の判断結果を「Ｙｅｓ」として、ステップＳＢ４へ進む。ステップＳＢ４では、受信装置６０1 〜６０m は、管理サーバ５０（配信装置７０）に対して、受信承諾である旨の応答通知を行った後、一連の処理を終了する。
【００８９】
一方、ユーザにより受信拒否ボタン１０３が押下されると、受信装置６０1 〜６０m は、ステップＳＢ３の判断結果を「Ｙｅｓ」として、ステップＳＢ５へ進む。ステップＳＢ５では、受信装置６０1 〜６０m は、管理サーバ５０（配信装置７０）に対して、受信拒否である旨の応答通知を行った後、一連の処理を終了する。
【００９０】
そして、受信装置６０1 〜６０m から応答通知を順次受けると、管理サーバ５０は、受け取った順に、上記応答通知を応答通知情報としてとしてネットワークＮを介して配信装置７０へ渡す。これにより、ステップＳＣ２では、図７に示した集計制御部７１は、応答通知を集計した後、集計結果（受信承諾者数ｘ、受信拒否者数ｙ）をユーザインタフェース制御部３４を介して配信制御部３２へ渡す。
【００９１】
これにより、ステップＳＣ３では、配信制御部３２は、ステップＳＡ３（図４参照）と同様にして、上記集計結果（受信承諾者数ｘ、受信拒否者数ｙ）のうち現在の受信承諾者数ｘを図５（ｂ）に示した受信者数表示領域２０１に表示させる。つぎのステップＳＣ４では、集計制御部７１は、現在の受信承諾者数ｘと配信開始しきい値ＴＨ1 とを比較し、受信承諾者数ｘが配信開始しきい値ＴＨ1 以上であるか否かを判断し、この場合、受信承諾者数ｘが配信開始しきい値ＴＨ1 より小であるものとすると、判断結果を「Ｎｏ」とする。
【００９２】
つぎのステップＳＣ５では、配信制御部３２は、ステップＳＡ４（図４参照）と同様にして、ユーザにより選択ボタン（配信開始ボタン２０２または配信中止ボタン２０３）が押下されたか否かを判断し、この場合、押下されていないものとすると、判断結果を「Ｎｏ」とする。したがって、この場合、ステップＳＣ４の判断結果が「Ｙｅｓ」、またはステップＳＣ５の判断結果が「Ｙｅｓ」となるまで、ステップＳＣ２およびステップＳＣ３においては、応答通知を受ける毎に、応答通知の集計および集計結果（受信承諾者数ｘ）が表示される。
【００９３】
ここで、受信承諾者数ｘが配信開始しきい値ＴＨ1 以上になると、集計制御部７１は、ステップＳＣ４の判断結果を「Ｙｅｓ」として、ステップＳＣ６へ進み、配信者の判断にかかわらず、エンコード部３１を制御することで、自動的に配信処理を実行する。すなわち、この場合には、配信者により、配信開始ボタン２０２が押下されていない状態で、配信処理が実行されたのである。
【００９４】
この配信処理においては、ステップＳＡ５（図４参照）と同様にして、講演に関する動画データＤ1 および音声データＤ2 がエンコード部３１にキャプチャリングされると、エンコード部３１は、ストリーム帯域等のパラメータに基づいて、動画データＤ1 および音声データＤ2 を符号化・圧縮することで、ストリーミングパケットＳＰ0 を生成する。そして、ストリーミングパケットＳＰ0 は、ネットワーク制御部３３およびネットワークＮを介して、図６に示したストリームサーバ４０1 〜４０n へそれぞれ分配される。これにより、ストリームサーバ４０1 〜４０n は、ストリーミングパケットＳＰ0 をストリーミングパケットＳＰ1 〜ＳＰn として、配信先の受信装置６０1 〜６０m へそれぞれ配信する。
【００９５】
また、ステップＳＣ４の判断結果が「Ｎｏ」である間に、配信開始ボタン２０２が押下されると、ステップＳＣ５の判断結果が「Ｙｅｓ」となり、ステップＳＣ６で配信処理が実行される。このとき実行される配信処理は、配信者の判断によるものである。一方、ステップＳＣ４の判断結果が「Ｎｏ」である間に、配信中止ボタン２０３が押下されると、ステップＳＣ５の判断結果が「Ｙｅｓ」となり、ステップＳＣ７で、ステップＳＡ６（図４参照）と同様にして、配信中止処理が実行される。
【００９６】
つぎに、実施の形態２の動作例２について図９に示したフローチャートを参照しつつ説明する。図９において、図８の各部に対応する部分には同一の符号を付ける。配信装置７０側の動作であるステップＳＤ１〜ＳＤ７において、ステップＳＤ４を除く、ステップＳＤ１〜ステップＳＤ３およびステップＳＤ５〜ステップＳＤ７は、前述した図８に示したステップＳＣ１〜ステップＳＣ３およびステップＳＣ５〜ステップＳＣ７と同様である。また、以下の動作２において、図７に示したしきい集計制御部７１には、配信中止しきい値ＴＨ2 が設定されているものとする。
【００９７】
図６において、受信装置６０1 〜６０m は、起動されると、図９に示したステップＳＢ１へ進み、管理サーバ５０（配信装置７０）からの配信通知を受けたか否かをそれぞれ判断し、この場合、判断結果を「Ｎｏ」として同判断をそれぞれ繰り返す。そして、ライブ放送の開始前に、配信者（または他のオペレータ）により、入力部３５（図７参照）を用いて、配信通知をすべきことを指示する情報が入力されると、配信制御部３２は、図９に示したステップＳＤ１へ進み、受信装置６０1 〜６０m へ配信通知を行うことを指示するための配信通知指示情報をネットワークＮを介して管理サーバ５０へ送信する。以後、前述した実施の形態１と同様の動作が行われる。
【００９８】
すなわち、上記配信通知を受けると、受信装置６０1 〜６０m は、ステップＳＢ１の判断結果を「Ｙｅｓ」として、ステップＳＢ２以降の工程を実行する。ここで、ユーザにより受信承諾ボタン１０２が押下されると、前述した動作を経て、ステップＳＢ４では、受信装置６０1 〜６０m は、管理サーバ５０（配信装置７０）に対して、受信承諾である旨の応答通知を行った後、一連の処理を終了する。
【００９９】
一方、ユーザにより受信拒否ボタン１０３が押下されると、前述した動作を経て、ステップＳＢ５では、受信装置６０1 〜６０m は、管理サーバ５０（配信装置７０）に対して、受信拒否である旨の応答通知を行った後、一連の処理を終了する。
【０１００】
そして、受信装置６０1 〜６０m から応答通知を順次受けると、管理サーバ５０は、受け取った順に、上記応答通知を応答通知情報としてとしてネットワークＮを介して配信装置７０へ渡す。これにより、ステップＳＤ２では、図７に示した集計制御部７１は、応答通知を集計した後、集計結果（受信承諾者数ｘ、受信拒否者数ｙ）をユーザインタフェース制御部３４を介して配信制御部３２へ渡す。
【０１０１】
これにより、ステップＳＤ３では、配信制御部３２は、ステップＳＡ３（図４参照）と同様にして、上記集計結果（受信承諾者数ｘ、受信拒否者数ｙ）のうち現在の受信承諾者数ｘを図５（ｂ）に示した受信者数表示領域２０１に表示させる。なお、この動作例２においては、受信者数表示領域２０１に受信拒否者数ｙを表示させてもよい。つぎのステップＳＤ４では、集計制御部７１は、現在の受信拒否者数ｙと配信中止しきい値ＴＨ2 とを比較し、受信拒否者数ｙが配信中止しきい値ＴＨ2 以上であるか否かを判断し、この場合、受信拒否者数ｙが配信中止しきい値ＴＨ2 より小であるものとすると、判断結果を「Ｎｏ」とする。
【０１０２】
つぎのステップＳＤ５では、配信制御部３２は、ステップＳＡ４（図４参照）と同様にして、ユーザにより選択ボタン（配信開始ボタン２０２または配信中止ボタン２０３）が押下されたか否かを判断し、この場合、押下されていないものとすると、判断結果を「Ｎｏ」とする。したがって、この場合、ステップＳＤ４の判断結果が「Ｙｅｓ」、またはステップＳＤ５の判断結果が「Ｙｅｓ」となるまで、ステップＳＤ２およびステップＳＤ３においては、応答通知を受ける毎に、応答通知の集計および集計結果（受信承諾者数ｘ）が表示される。
【０１０３】
ここで、受信拒否者数ｙが配信中止しきい値ＴＨ2 以上になると、集計制御部７１は、ステップＳＤ４の判断結果を「Ｙｅｓ」として、ステップＳＤ７へ進み、エンコード部３１を制御することで、自動的に配信中止処理を実行する。この配信中止処理においては、集計制御部７１は、管理サーバ５０を経由して受信装置６０1 〜６０m へライブ放送（講演）が中止になった旨を通知する。すなわち、この場合には、配信者により、配信中止ボタン２０３が押下されていない状態で、配信中止処理が実行されたのである。
【０１０４】
また、ステップＳＤ４の判断結果が「Ｎｏ」である間に、配信開始ボタン２０２が押下されると、ステップＳＤ５の判断結果が「Ｙｅｓ」となり、ステップＳＤ６で配信処理が実行される。このとき実行される配信処理は、配信者の判断によるものである。一方、ステップＳＤ４の判断結果が「Ｎｏ」である間に、配信中止ボタン２０３が押下されると、ステップＳＤ５の判断結果が「Ｙｅｓ」となり、ステップＳＤ７で、ステップＳＡ６（図４参照）と同様にして、配信中止処理が実行される。
【０１０５】
以上説明したように、実施の形態２によれば、集計制御部７１を設けて、受信承認者数ｘと配信開始しきい値ＴＨ1 とを比較し、この比較結果に基づいて、コンテンツ情報の配信開始の可否を判断するようにしたので、配信者の判断を待たずに、自動的にコンテンツ情報の配信を開始することができる。
【０１０６】
また、実施の形態２によれば、集計制御部７１を設けて、受信拒否者数ｙと配信中止しきい値ＴＨ2 とを比較し、この比較結果に基づいて、コンテンツ情報の配信中止の可否を判断するようにしたので、配信者の判断を待たずに、自動的に情報の配信を中止することができる。
【０１０７】
（実施の形態３）
さて、前述した実施の形態１および２においては、配信通知を行ってから配信中止処理を実行するまでの待機時間の長短を配信者の意志に基づいて決定した例について説明したが、この待機時間としきい値とを比較し、この比較結果に基づいて、配信中止処理を行うようにしてもよい。以下、この場合を実施の形態３として説明する。
【０１０８】
図１０は、本発明にかかる実施の形態３の構成を示すブロック図である。この図において、図１の各部に対応する部分には同一の符号を付け、その説明を省略する。図１０においては、図１に示した配信装置３０に代えて、配信装置８０が設けられている。ここで、上述した配信装置８０の構成について図１１を参照して詳述する。
【０１０９】
なお、図１１においては、図２の各部にそれぞれ対応する部分には同一の符号を付け、その説明を省略する。この図においては、図２に示した集計制御部３７に代えて、集計制御部８１が新たに設けられており、さらに、タイマ８２、待機時間設定部８３およびしきい値設定部８４が新たに設けられている。この配信装置８０の基本的な機能は、配信装置３０と同様である。しかしながら、配信装置８０は、上述したしきい値を用いて配信中止処理を行うか否かを判断している点が配信装置３０と異なる。
【０１１０】
配信装置８０において、集計制御部８１は、集計制御部３７と同様にして、受信装置６０1 〜６０m （図１１参照）からの複数の応答通知を集計し、集計結果（受信承諾者数ｘ、受信拒否者数ｙ）をユーザインタフェース制御部３４を介して、配信制御部３２へ渡す。タイマ８２は、配信通知を行ってからの待機時間を計時するものであり、計時結果を待機時間Ｔとして集計制御部８１へ出力する。待機時間設定部８３は、集計制御部８１に待機時間設定値ＴＨ4 を設定する。この待機時間設定値ＴＨ4 は、待機時間Ｔとの比較において配信中止処理を実行するか否かの判断基準の一つとして用いられる。
【０１１１】
しきい値設定部８４は、集計制御部８１に配信開始しきい値ＴＨ3 を設定する。この配信開始しきい値ＴＨ3 は、受信承諾者数ｘとの比較において配信中止処理を実行するか否かの判断基準の一つとして用いられる。ここで、集計制御部８１は、上述した待機時間Ｔと待機時間設定値ＴＨ4 との比較、および受信承諾者数ｘと配信開始しきい値ＴＨ3 との比較を行い、両比較結果に基づいて、配信中止処理を実行するか否かを判断する。
【０１１２】
つぎに、実施の形態３の動作について図１２に示したフローチャートを参照しつつ説明する。図１２において、図４の各部に対応する部分には同一の符号を付ける。図１０において、受信装置６０1 〜６０m は、起動されると、図１２に示したステップＳＢ１へ進み、管理サーバ５０（配信装置８０）からの配信通知を受けたか否かをそれぞれ判断し、この場合、判断結果を「Ｎｏ」として同判断をそれぞれ繰り返す。
【０１１３】
そして、ライブ放送の開始前に、配信者（または他のオペレータ）により、入力部３５（図７参照）を用いて、配信通知をすべきことを指示する情報が入力されると、配信制御部３２は、図１２に示したステップＳＥ１へ進み、受信装置６０1 〜６０m へ配信通知を行うことを指示するための配信通知指示情報をネットワークＮを介して管理サーバ５０へ送信する。つぎのステップＳＥ２では、集計制御部８１は、タイマ８２をリセット（待機時間Ｔ＝０）する。これにより、タイマ８２による計時が開始される。
【０１１４】
そして、配信通知を受けると、受信装置６０1 〜６０m は、ステップＳＢ１の判断結果を「Ｙｅｓ」として、ステップＳＢ２以降の工程を実行する。ここで、ユーザにより受信承諾ボタン１０２が押下されると、前述した動作を経て、ステップＳＢ４では、受信装置６０1 〜６０m は、管理サーバ５０（配信装置８０）に対して、受信承諾である旨の応答通知を行った後、一連の処理を終了する。
【０１１５】
一方、ユーザにより受信拒否ボタン１０３が押下されると、前述した動作を経て、ステップＳＢ５では、受信装置６０1 〜６０m は、管理サーバ５０（配信装置８０）に対して、受信拒否である旨の応答通知を行った後、一連の処理を終了する。
【０１１６】
そして、受信装置６０1 〜６０m から応答通知を順次受けると、管理サーバ５０は、受け取った順に、上記応答通知を応答通知情報としてとしてネットワークＮを介して配信装置８０へ渡す。これにより、ステップＳＥ３では、図１１に示した集計制御部８１は、応答通知を集計した後、集計結果（受信承諾者数ｘ、受信拒否者数ｙ）をユーザインタフェース制御部３４を介して配信制御部３２へ渡す。
【０１１７】
これにより、ステップＳＥ４では、配信制御部３２は、ステップＳＡ３（図４参照）と同様にして、上記集計結果（受信承諾者数ｘ、受信拒否者数ｙ）のうち現在の受信承諾者数ｘを図５（ｂ）に示した受信者数表示領域２０１に表示させる。なお、実施の形態３においては、受信者数表示領域２０１に受信拒否者数ｙを表示させてもよい。つぎのステップＳＥ５では、集計制御部８１は、現在の待機時間Ｔと待機時間設定値ＴＨ4 とを比較し、待機時間Ｔが待機時間設定値ＴＨ4 以上であるか否かを判断し、この場合、待機時間Ｔが待機時間設定値ＴＨ4 未満であるものとすると、判断結果を「Ｎｏ」とする。
【０１１８】
つぎのステップＳＥ７では、配信制御部３２は、ステップＳＡ４（図４参照）と同様にして、ユーザにより選択ボタン（配信開始ボタン２０２または配信中止ボタン２０３）が押下されたか否かを判断し、この場合、押下されていないものとすると、判断結果を「Ｎｏ」とする。したがって、以後、応答通知を受ける毎に、応答通知の集計および集計結果（受信承諾者数ｘ）が表示される。
【０１１９】
ここで、待機時間Ｔが待機時間設定値ＴＨ4 以上になると、集計制御部８１は、ステップＳＥ５の判断結果を「Ｙｅｓ」として、ステップＳＥ６へ進む。ステップＳＥ６では、集計制御部８１は、現在の受信承諾者数ｘと配信開始しきい値ＴＨ3 とを比較し、受信承諾者数ｘが配信開始しきい値ＴＨ3 未満であるか否かを判断する。この場合、判断結果が「Ｙｅｓ」であるものとすると、集計制御部８１は、ステップＳＥ９へ進む。
【０１２０】
なお、受信承諾者数ｘが配信開始しきい値ＴＨ3 以上である場合、集計制御部８１は、ステップＳＥ６の判断結果を「Ｎｏ」とする。つまり、配信通知を行ってからの待機時間Ｔが待機時間設定値ＴＨ4 以上であり、かつ受信承諾者数ｘが配信開始しきい値ＴＨ3 未満であるという２つの条件を満たした場合には、集計制御部８１により配信中止処理が実行される。
【０１２１】
ステップＳＥ９では、集計制御部８１は、エンコード部３１を制御することで、自動的に配信中止処理を実行する。この配信中止処理においては、集計制御部８１は、管理サーバ５０を経由して受信装置６０1 〜６０m へライブ放送（講演）が中止になった旨を通知する。すなわち、この場合には、配信者により、配信中止ボタン２０３が押下されていない状態で、配信中止処理が実行されるのである。
【０１２２】
また、ステップＳＥ５の判断結果が「ＹＥＳ」で、かつステップＳＥ６の判断結果が「Ｎｏ」である間に、配信開始ボタン２０２が押下されると、ステップＳＥ７の判断結果が「Ｙｅｓ」となり、ステップＳＥ８で配信処理が実行される。このとき実行される配信処理は、配信者の判断によるものである。一方、ステップＳＥ５の判断結果が「Ｙｅｓ」で、かつステップＳＥ６の判断結果が「Ｎｏ」である間に、配信中止ボタン２０３が押下されると、ステップＳＥ５の判断結果が「Ｙｅｓ」となり、ステップＳＥ９で、ステップＳＡ６（図４参照）と同様にして、配信中止処理が実行される。
【０１２３】
以上説明したように、実施の形態３によれば、集計制御部８１を設けて、待機時間Ｔと待機時間設定値ＴＨ4 とを比較し、さらに受信承認者数ｘと配信開始しきい値ＴＨ3 とを比較し、これら２つの比較結果に基づいて、コンテンツ情報の配信中止の可否を判断するようにしたので、配信者の判断を待たずに、所定の待機時間を過ぎてもなお、受信承認者数ｘの数が配信開始しきい値ＴＨ3 に満たない場合に、自動的に情報の配信を中止することができる。
【０１２４】
（実施の形態４）
さて、前述した実施の形態１〜３においては、配信の前に、受信装置６０1 〜６０m に対して配信通知を行い、この配信通知に対応する応答通知の集計結果に基づいて、ライブ放送の受信を承諾したユーザの受信装置へコンテンツ情報を配信する例について説明したが、ユーザの意志にかかわらず、強制的にコンテンツ情報を配信するようにしてもよい。このような形態の配信は、緊急配信と呼ばれている。以下、この場合を実施の形態４として説明する。
【０１２５】
図１３は、本発明にかかる実施の形態４の構成を示すブロック図である。この図において、図１の各部に対応する部分には同一の符号を付け、その説明を省略する。図１３においては、図１に示した受信装置６０1 〜６０m に代えて、受信装置９０1 〜９０m が設けられている。
【０１２６】
ここで、図１３に示した受信装置９０1 の構成について図１４を参照して詳述する。なお、他の受信装置９０2 〜９０m の構成は、以下に説明する受信装置９０1 の構成と同一である。図１４においては、図３の各部にそれぞれ対応する部分には同一の符号を付け、その説明を省略する。この図においては、状態監視部９１が新たに設けられている。この状態監視部９１は、受信装置９０1 がストリーミングパケットＳＰ1 を受信可能な状態にあるか否かを監視し、監視結果を配信制御部６１へ渡す。ここで、受信可能な状態とは、受信装置９０1 の各部が正常に動作している状態をいう。配信制御部６１は、配信制御部６１の監視結果に基づいて、配信装置３０（管理サーバ５０）へ受信可能（または受信不可）である旨の応答を通知する。
【０１２７】
つぎに、実施の形態４の動作について図１５に示したフローチャートを参照しつつ説明する。図１５において、配信装置３０側の動作は、図４に示したものと同様である。以下においては、緊急配信という性質上、緊急演説の様子をライブ放送する例について説明する。図１３において、受信装置９０1 〜９０m （図１３：配信制御部６１）は、起動されると、図１５に示したステップＳＦ１へ進み、管理サーバ５０（配信装置３０）からの配信通知を受けたか否かをそれぞれ判断し、この場合、判断結果を「Ｎｏ」として同判断をそれぞれ繰り返す。
【０１２８】
そして、ライブ放送の開始前に、配信者（または他のオペレータ）により、入力部３５（図２参照）を用いて、配信通知をすべきことを指示する情報が入力されると、配信制御部３２は、図１５に示したステップＳＡ１へ進み、受信装置９０1 〜９０m へ配信通知を行うことを指示するための配信通知指示情報をネットワークＮを介して管理サーバ５０へ送信する。
【０１２９】
上記配信通知を受けると、受信装置９０1 〜９０m （配信制御部６１）は、ステップＳＦ１の判断結果を「Ｙｅｓ」として、ステップＳＦ２へ進む。ステップＳＦ２では、図１３に示した受信装置９０1 〜９０m （配信制御部６１）は、状態監視部９１の監視結果に基づいて、装置が受信可能な状態にあるか否かを判断する。
【０１３０】
ここで、受信可能な状態にある場合、受信装置９０1 〜９０m （配信制御部６１）は、管理サーバ５０（配信装置３０）に対して、受信可能である旨の応答通知を行った後、処理を終了する。一方、装置故障等により受信不可能な状態にある場合、受信装置９０1 〜９０m （配信制御部６１）は、管理サーバ５０（配信装置３０）に対して、受信不可である旨の応答通知を行った後、処理を終了する。
【０１３１】
そして、受信装置９０1 〜９０m から応答通知を順次受けると、管理サーバ５０は、受け取った順に、上記応答通知を応答通知情報としてとしてネットワークＮを介して配信装置３０へ渡す。これにより、ステップＳＡ２では、図７に示した集計制御部７１は、応答通知を集計した後、集計結果（受信承諾者数ｘ、受信拒否者数ｙ）をユーザインタフェース制御部３４を介して配信制御部３２へ渡す。ここで、受信承認者数ｘは、受信装置９０1 〜９０m のうち受信可能な状態にある受信装置の数に対応しており、受信拒否者数ｙは、受信装置９０1 〜９０m のうち受信不可能な状態にある受信装置の数に対応している。
【０１３２】
つぎのステップＳＡ３では、配信制御部３２は、上記集計結果（受信承諾者数ｘ、受信拒否者数ｙ）のうち、図５（ｂ）に示した受信者数表示領域２０１に、現在の受信承諾者数ｘを表示させた後、ステップＳＡ４へ進む。ステップＳＡ４では、配信制御部３２は、ユーザにより選択ボタン（配信開始ボタン２０２または配信中止ボタン２０３）が押下されたか否かを判断し、この場合、押下されていないものとすると、判断結果を「Ｎｏ」とする。したがって、この場合、ステップＳＡ４の判断結果が「Ｙｅｓ」となるまで、ステップＳＡ２およびステップＳＡ３においては、応答通知を受ける毎に、応答通知の集計および集計結果（受信承諾者数ｘ）が表示される。
【０１３３】
そして、受信承諾者数ｘがある程度の人数に達すると、配信者は、入力部３５を用いて、配信開始ボタン２０２を押下した後、緊急演説を開始する。これにより、配信制御部３２は、配信開始ボタン２０２が押下されているため、ステップＳＡ４の判断結果を「Ｙｅｓ」として、ステップＳＡ５へ進む。ステップＳＡ５では、配信制御部３２は、装置各部を制御して配信処理を行う。
【０１３４】
この配信処理において、図２に示したビデオカメラ１０およびマイクロフォン２０からは、緊急演説に関する動画データＤ1 および音声データＤ2 が出力される。そして、これらの動画データＤ1 および音声データＤ2 がエンコード部３１にキャプチャリングされると、エンコード部３１は、ストリーム帯域等のパラメータに基づいて、動画データＤ1 および音声データＤ2 を符号化・圧縮することで、ストリーミングパケットＳＰ0 を生成する。
【０１３５】
このストリーミングパケットＳＰ0 は、ネットワーク制御部３３およびネットワークＮを介して、図１に示したストリームサーバ４０1 〜４０n へそれぞれ分配される。これにより、ストリームサーバ４０1 〜４０n は、ストリーミングパケットＳＰ0 をストリーミングパケットＳＰ1 〜ＳＰn として、配信先の受信装置９０1 〜９０m へそれぞれ配信する。ここで、受信装置９０1 〜９０m において、受信可能な状態にあるすべての受信装置では、ユーザの意志に関わりなく、緊急演説に関するコンテンツ情報がリアルタイムで再生される。
【０１３６】
なお、配信者により配信中止ボタン２０３が押下されると、配信制御部３２は、ステップＳＡ４の判断結果を「Ｙｅｓ」として、ステップＳＡ６へ進む。ステップＳＡ６では、配信制御部３２は、装置各部を制御して配信中止処理を行う。
【０１３７】
以上説明したように、実施の形態４によれば、複数の受信装置９０1 〜９０m に対して、コンテンツ情報（ストリーミングパケットＳＰ1 〜ＳＰn ）を受信することが可能な状態であるか否かを問い合わせる配信通知を行い、この配信通知に対応する応答通知の集計結果に基づいて、コンテンツ情報の配信を開始または中止するようにしたので、受信者の意志に関わりなく、緊急のコンテンツ情報を受信可能状態にある受信装置へ配信するという緊急配信を効果的に行うことができる。
【０１３８】
以上本発明の実施の形態１〜４について図面を参照して詳述してきたが、具体的な構成例はこれら実施の形態１〜４に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等があっても本発明に含まれる。たとえば、前述した実施の形態１〜４においては、前述した機能を実現するための情報配信プログラムを図１６に示したコンピュータ読み取り可能な記録媒体４００に記録して、この記録媒体４００に記録された情報配信プログラムを同図に示したコンピュータ３００に読み込ませ、実行するようにしてもよい。
【０１３９】
図１６に示したコンピュータ３００は、上記情報配信プログラムを実行するＣＰＵ３０１と、キーボード、マウス等の入力装置３０２と、各種データを記憶するＲＯＭ（Read Only Memory）３０３と、演算パラメータ等を記憶するＲＡＭ（Random Access Memory）３０４と、記録媒体４００から情報配信プログラムを読み取る読取装置３０５と、ディスプレイ、プリンタ等の出力装置３０６と、装置各部を接続するバスＢＵとから構成されている。
【０１４０】
ＣＰＵ３０１は、読取装置３０５を経由して記録媒体４００に記録されている情報配信プログラムを読み込んだ後、情報配信プログラムを実行することにより、前述したコンテンツ情報の配信を行う。なお、記録媒体４００には、光ディスク、フロッピーディスク、ハードディスク等の可搬型の記録媒体が含まれることはもとより、ネットワークのようにデータを一時的に記録保持するような伝送媒体も含まれる。
【０１４１】
【発明の効果】
以上説明したように、請求項１、６、７にかかる発明によれば、待機時間と待機時間設定値とを比較し、配信を受ける受信装置の数と配信開始しきい値以上とを比較し、これら２つの比較結果に基づいて、ライブ放送の配信中止の可否を判断するようにしたので、経過時間を過ぎてもなお、配信を受ける受信装置の数が配信開始しきい値に満たない場合に、自動的にライブ放送の配信を中止することができるという効果を奏する。
【０１４２】
また、請求項２にかかる発明によれば、報知手段により回答の集計結果が報知される。したがって、配信者は、報知された集計結果に基づいて、配信を行うかまたは中止するかを判断することが可能となるという効果を奏する。
【０１４３】
また、請求項３にかかる発明によれば、第３の比較手段を設けて、配信を受ける受信装置の数と配信決定しきい値以上とを比較し、この比較結果に基づいて、ライブ放送の配信開始の可否を判断するようにしたので、配信者の判断を待たずに、自動的にライブ放送の配信を行うことができるという効果を奏する。
【０１４４】
また、請求項４にかかる発明によれば、第４の比較手段を設けて、配信を受けない受信装置の数と配信中止しきい値以上とを比較し、この比較結果に基づいて、ライブ放送の配信中止の可否を判断するようにしたので、配信者の判断を待たずに、自動的にライブ放送の配信を中止することができるという効果を奏する。
【０１４５】
また、請求項５、８、９にかかる発明によれば、複数の受信装置に対して緊急情報を受信することが可能であるか否かの問い合わせを行い、問い合わせに対応する回答の集計結果に基づいて、緊急情報の配信を開始または中止するようにしたので、受信者の意志に関わりなく、緊急の情報を受信可能な受信装置へ配信するという緊急配信を効果的に行うことができるという効果を奏する。
【図面の簡単な説明】
【図１】本発明にかかる実施の形態１の構成を示すブロック図である。
【図２】図１に示した配信装置３０の構成を示すブロック図である。
【図３】図１に示した受信装置６０1 の構成を示すブロック図である。
【図４】同実施の形態１の動作を説明するフローチャートである。
【図５】実施の形態１〜４における受信装置側選択画面１００および配信装置側選択画面２００を示す図である。
【図６】本発明にかかる実施の形態２の構成を示すブロック図である。
【図７】図６に示した配信装置７０の構成を示すブロック図である。
【図８】同実施の形態２の動作例１を説明するフローチャートである。
【図９】同実施の形態２の動作例２を説明するフローチャートである。
【図１０】本発明にかかる実施の形態３の構成を示すブロック図である。
【図１１】図１０に示した配信装置８０の構成を示すブロック図である。
【図１２】同実施の形態３の動作を説明するフローチャートである。
【図１３】本発明にかかる実施の形態４の構成を示すブロック図である。
【図１４】図１３に示した受信装置９０1 の構成を示すブロック図である。
【図１５】同実施の形態４の動作を説明するフローチャートである。
【図１６】本発明にかかる実施の形態１〜４の変形例を示すブロック図である。
【符号の説明】
３０ 配信装置
３２ 配信制御部
３５ 入力部
３６ 表示部
３７ 集計制御部
６０1 〜６０m 受信装置
７０ 配信装置
７１ 集計制御部
８０ 配信装置
８１ 集計制御部
８２ タイマ
９０1 〜９０m 受信装置
３００ コンピュータ
４００ 記録媒体
Claims (9)
- ライブ放送を複数の受信装置へ配信する情報配信装置において、
ライブ放送の配信を開始する前に、前記複数の受信装置に対して前記ライブ放送の配信を受けるか否かを問い合わせる問い合わせ手段と、
前記複数の受信装置に対して前記問い合わせが行われてからの待機時間を計時する計時手段と、
前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計手段と、
前記待機時間とあらかじめ設定された待機時間設定値とを比較する第１の比較手段と、
前記集計結果に基づいて、前記配信を受ける受信装置の数とあらかじめ設定された配信開始しきい値とを比較する第２の比較手段と、
前記第１の比較手段および前記第２の比較手段のそれぞれの比較結果に基づいて、前記待機時間が前記待機時間設定値以上であって、かつ前記配信を受ける受信装置の数が前記配信開始しきい値に満たない場合、前記配信を中止する配信制御手段と、
を備えることを特徴とする情報配信装置。 - 配信者に前記集計結果を報知する報知手段をさらに備えること特徴とする請求項１に記載の情報配信装置。
- 前記集計結果に基づいて、前記配信を受ける受信装置の数とあらかじめ設定された配信決定しきい値とを比較する第３の比較手段を備え、前記配信制御手段は、前記第３の比較手段の比較結果に基づいて、前記配信を受ける受信装置の数が前記配信決定しきい値以上になった時点で、前記配信を行うこととすることを特徴とする請求項１または２に記載の情報配信装置。
- 前記集計結果に基づいて、前記配信を受けない受信装置の数とあらかじめ設定された配信中止しきい値とを比較する第４の比較手段を備え、前記配信制御手段は、前記第４の比較手段の比較結果に基づいて、前記配信を受けない受信装置の数が前記配信中止しきい値以上になった時点で、前記配信を中止することを特徴とする請求項１または２に記載の情報配信装置。
- リアルタイム再生が可能な情報を複数の受信装置へ配信する情報配信装置において、
緊急情報の配信を開始する前に、前記複数の受信装置に対して前記緊急情報を受信することが可能であるか否かを問い合わせる問い合わせ手段と、
前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計手段と、
前記集計手段の集計結果に基づいて、緊急情報の配信を開始または中止する配信制御手段と、
を備えることを特徴とする情報配信装置。 - ライブ放送を複数の受信装置へ配信する情報配信方法において、
ライブ放送の配信を開始する前に、前記複数の受信装置に対して前記ライブ放送の配信を受けるか否かを問い合わせる問い合わせ工程と、
前記複数の受信装置に対して前記問い合わせが行われてからの待機時間を計時する計時工程と、
前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計工程と、
前記待機時間とあらかじめ設定された待機時間設定値とを比較する第１の比較工程と、
前記集計結果に基づいて、前記配信を受ける受信装置の数とあらかじめ設定された配信開始しきい値とを比較する第２の比較工程と、
前記第１の比較工程および前記第２の比較工程のそれぞれの比較結果に基づいて、前記待機時間が前記待機時間設定値以上であって、かつ前記配信を受ける受信装置の数が前記配信開始しきい値に満たない場合、前記配信を中止する配信制御工程と、
を含むことを特徴とする情報配信方法。 - ライブ放送を複数の受信装置へ配信する情報配信装置に適用される情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
ライブ放送の配信を開始する前に、前記複数の受信装置に対して前記ライブ放送の配信を受けるか否かを問い合わせる問い合わせ工程と、
前記複数の受信装置に対して前記問い合わせが行われてからの待機時間を計時する計時工程と、
前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計工程と、
前記待機時間とあらかじめ設定された待機時間設定値とを比較する第１の比較工程と、
前記集計結果に基づいて、前記配信を受ける受信装置の数とあらかじめ設定された配信開始しきい値とを比較する第２の比較工程と、
前記第１の比較工程および前記第２の比較工程のそれぞれの比較結果に基づいて、前記待機時間が前記待機時間設定値以上であって、かつ前記配信を受ける受信装置の数が前記配信開始しきい値に満たない場合、前記配信を中止する配信制御工程と、
をコンピュータに実行させるための情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体。 - リアルタイム再生が可能な情報を複数の受信装置へ配信する情報配信方法において、
緊急情報の配信を開始する前に、前記複数の受信装置に対して前記緊急情報を受信することが可能であるか否かを問い合わせる問い合わせ工程と、
前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計工程と、
前記集計工程の集計結果に基づいて、緊急情報の配信を開始または中止する配信制御工程と、
を含むことを特徴とする情報配信方法。 - リアルタイム再生が可能な情報を複数の受信装置へ配信する情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
緊急情報の配信を開始する前に、前記複数の受信装置に対して前記緊急情報を受信することが可能であるか否かを問い合わせる問い合わせ工程と、
前記問い合わせに対応する前記複数の受信装置からの回答を集計する集計工程と、
前記集計工程の集計結果に基づいて、緊急情報の配信を開始または中止する配信制御工程と、
をコンピュータに実行させるための情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP22574099A JP3926513B2 (ja) | 1999-08-09 | 1999-08-09 | 情報配信装置、情報配信方法および情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体 |
| US09/519,694 US6633911B1 (en) | 1999-08-09 | 2000-03-07 | Information distribution apparatus, information distribution method, and computer readable recording medium on which information distribution program is recorded |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP22574099A JP3926513B2 (ja) | 1999-08-09 | 1999-08-09 | 情報配信装置、情報配信方法および情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001054097A JP2001054097A (ja) | 2001-02-23 |
| JP3926513B2 true JP3926513B2 (ja) | 2007-06-06 |
Family
ID=16834102
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP22574099A Expired - Fee Related JP3926513B2 (ja) | 1999-08-09 | 1999-08-09 | 情報配信装置、情報配信方法および情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6633911B1 (ja) |
| JP (1) | JP3926513B2 (ja) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001325516A (ja) * | 2000-05-16 | 2001-11-22 | Sony Corp | 情報提供装置および方法、情報処理装置および方法、並びにプログラム格納媒体 |
| FR2823343B1 (fr) * | 2001-04-05 | 2003-07-04 | Cit Alcatel | Dispositif de generation d'un fichier multimedia a destination d'un terminal de telecommunications et fichier multimedia associe |
| US7263666B2 (en) * | 2001-04-09 | 2007-08-28 | Triveni Digital, Inc. | Targeted remote GUI for metadata generator |
| JP2003023613A (ja) * | 2001-07-06 | 2003-01-24 | Enchante:Kk | コンテンツ配信システム |
| JP2003037836A (ja) * | 2001-07-24 | 2003-02-07 | Ntt Docomo Inc | 画像配信方法、画像配信システム、コンピュータ読取可能な記録媒体及びコンピュータ・プログラム |
| DE60129328T2 (de) * | 2001-09-28 | 2008-03-13 | Motorola, Inc., Schaumburg | Verfahren und Vorrichtung zur IP-Mehrfachsendung über einen Rundfunkkanal |
| WO2005091585A1 (en) * | 2004-03-22 | 2005-09-29 | Codemate Aps | Distribution method, preferably applied in a streaming system |
| WO2005116979A2 (en) | 2004-05-17 | 2005-12-08 | Visible Path Corporation | System and method for enforcing privacy in social networks |
| CA2573214C (en) * | 2004-07-09 | 2013-06-11 | Codemate Aps | Peer of a peer-to-peer network and such network |
| US20060036641A1 (en) | 2004-07-28 | 2006-02-16 | Antony Brydon | System and method for using social networks for the distribution of communications |
| JP5260908B2 (ja) * | 2007-07-20 | 2013-08-14 | 日本電気通信システム株式会社 | 制御装置、通信装置、制御システム、制御方法及び制御プログラム |
| JP2011254144A (ja) * | 2010-05-31 | 2011-12-15 | Yamaha Corp | 録音方法、この録音方法によりオーディオ信号が記録された記録媒体、およびオーディオ信号の配信方法 |
| JP2012209880A (ja) * | 2011-03-30 | 2012-10-25 | Sony Corp | 通信装置及び通信システム |
| US10154317B2 (en) | 2016-07-05 | 2018-12-11 | BoxCast, LLC | System, method, and protocol for transmission of video and audio data |
| US10647045B1 (en) | 2016-11-03 | 2020-05-12 | Specialty Earth Sciences, Llc | Shaped or sized encapsulated reactant and method of making |
| JP6378811B1 (ja) * | 2017-07-18 | 2018-08-22 | 株式会社 ディー・エヌ・エー | ライブ動画を配信するためのシステム、方法、及びプログラム |
| JP7077174B2 (ja) * | 2018-07-27 | 2022-05-30 | 株式会社 ディー・エヌ・エー | ライブ動画を配信するためのシステム、方法、及びプログラム |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5689641A (en) * | 1993-10-01 | 1997-11-18 | Vicor, Inc. | Multimedia collaboration system arrangement for routing compressed AV signal through a participant site without decompressing the AV signal |
| US5537141A (en) * | 1994-04-15 | 1996-07-16 | Actv, Inc. | Distance learning system providing individual television participation, audio responses and memory for every student |
| CA2153445C (en) | 1994-09-08 | 2002-05-21 | Ashok Raj Saxena | Video optimized media streamer user interface |
| US5867653A (en) * | 1996-04-18 | 1999-02-02 | International Business Machines Corporation | Method and apparatus for multi-cast based video conferencing |
| US5974446A (en) * | 1996-10-24 | 1999-10-26 | Academy Of Applied Science | Internet based distance learning system for communicating between server and clients wherein clients communicate with each other or with teacher using different communication techniques via common user interface |
| US6253375B1 (en) * | 1997-01-13 | 2001-06-26 | Diva Systems Corporation | System for interactively distributing information services |
| US6305019B1 (en) * | 1997-01-13 | 2001-10-16 | Diva Systems Corporation | System for interactively distributing information services having a remote video session manager |
| US6268849B1 (en) * | 1998-06-30 | 2001-07-31 | United Video Properties, Inc. | Internet television program guide system with embedded real-time data |
| US6288753B1 (en) * | 1999-07-07 | 2001-09-11 | Corrugated Services Corp. | System and method for live interactive distance learning |
-
1999
- 1999-08-09 JP JP22574099A patent/JP3926513B2/ja not_active Expired - Fee Related
-
2000
- 2000-03-07 US US09/519,694 patent/US6633911B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US6633911B1 (en) | 2003-10-14 |
| JP2001054097A (ja) | 2001-02-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3926513B2 (ja) | 情報配信装置、情報配信方法および情報配信プログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| US6453336B1 (en) | Video conferencing with adaptive client-controlled resource utilization | |
| US20060101499A1 (en) | Method and system for secure sharing, gifting, and purchasing of content on television and mobile devices | |
| JP2007534076A (ja) | ネットワークチャット環境におけるチャット負荷管理のためのシステム及び方法 | |
| EP3131257B1 (en) | Program, information processing apparatus, and information processing system for use in an electronic conference system | |
| US9396084B2 (en) | Device management apparatus, device management system, and device management method | |
| CN106488169A (zh) | 一种数据传输的方法、系统以及相关设备 | |
| CN1992986B (zh) | 通信方法、通信系统、中继设备以及通信设备 | |
| JP2006304177A (ja) | 同報送信システム、サーバ装置、端末装置、データ配信方法およびプログラム | |
| JP2010160542A (ja) | 情報処理システム | |
| CN102378046A (zh) | 服务器及利用其实现机顶盒影音节目共享的方法 | |
| JPH03273732A (ja) | マルチメディアメール処理システム | |
| JPH07202887A (ja) | 分散会議システム | |
| JP2012217068A (ja) | 遠隔会議システム | |
| JP5227863B2 (ja) | 会議システム、中継装置、および交換機の会議サーバへの接続方法 | |
| JP5141162B2 (ja) | テレビ会議システムおよび端末装置 | |
| JP2009294865A (ja) | プレゼンテーションシステム及びプレゼンテーション方法 | |
| JP5234744B2 (ja) | 映像会議装置、映像会議方法、映像会議プログラムおよび記録媒体 | |
| JP6369212B2 (ja) | 情報処理装置、情報処理システム、プログラム、及び記録媒体 | |
| WO2005074286A1 (ja) | コンテンツメール転送結合システム | |
| JP2008306475A (ja) | 音声・画像会議装置 | |
| US9137277B2 (en) | Communication method, communication system, repeating apparatus, communication apparatus, and computer program product | |
| JP6610076B2 (ja) | 情報処理装置、情報処理システム、プログラム、及び記録媒体 | |
| JP2004015183A (ja) | コミュニケーションシステム、コミュニケーションサーバ、プログラム及びコミュニケーション方法 | |
| JP3475883B2 (ja) | 在席離席状態を確認可能な計算機端末および在席離席状態確認システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060629 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061017 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061211 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070227 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070228 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100309 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110309 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |