(57)【要約】【課題】同時利用ユーザを増やしてサービス事業者の収入増加を図るとともに、同時利用ユーザ数が、システムの最大能力を超えることによる映像品質の低下を防ぐ。【解決手段】本発明では、ユーザに予め同一番組の複数の番組放映時間帯を提示し、ユーザが視聴希望する時間帯を予め登録する。また、ユーザに対し、同時視聴者数に応じて変更される価格と、視聴希望利用者数を利用者に提示する。例えば、事業者の利益追求のため視聴者数が多くなるに従い、価格を下げてさらなる視聴者数の増加を図る。一方、視聴者が増加しすぎることによりシステムの能力を超えて番組放映の品質が低下しないよう、提示価格を所定の規則で変更する。経済原理によって、番組放映時間帯における利用者数の制御を行うことにより、システムの負荷の平準化を行う。【選択図】図１
2009200769.tif 000002
【特許請求の範囲】
【請求項１】
端末からコンテンツの視聴申込を受け付け、該端末にコンテンツを配信するビデオオンデマンドシステムにおいて、
コンテンツ識別子と、該コンテンツに対する複数の視聴時刻と、コンテンツ識別子及び視聴時刻毎の、視聴申込数に応じた複数の価格とが予め記憶された配信情報記憶領域と、
前記端末からの視聴申込数に基づきコンテンツの価格を求める申込み管理機能部と
を備え、
前記申込み管理機能部は、
複数の端末から、視聴を希望するコンテンツのコンテンツ識別子と、視聴を希望する視聴時刻とを含む視聴申込情報を受信し、
複数の前記端末からの視聴申込情報を集計して、コンテンツ識別子及び視聴時刻ごとの視聴申込数を求め、
コンテンツ識別子と視聴時刻とに基づき前記配信情報記憶領域を参照して、コンテンツ識別子及び視聴時刻に対応する複数の価格のうち、求められた視聴申込数に応じた価格を求め、
前記配信情報記憶領域のコンテンツ識別子と、該コンテンツに対する複数の視聴時刻と、該コンテンツ識別子及び各視聴時刻の求められた価格とを前記端末又は他の端末に送信し、
前記端末から変更要求又は前記他の端末から視聴申込情報を受信する前記ビデオオンデマンドシステム。
【請求項２】
請求項１に記載のビデオオンデマンドシステムにおいて、
前記配信情報記憶領域は、コンテンツ識別子及び視聴時刻毎に、視聴申込数の第１乃至第Ｎの閾値（Ｎは整数）と、視聴申込数が第１の閾値以下の場合の第１の価格と、視聴申込数が第ｉの閾値（ｉは１〜Ｎ−１の整数）より大きく第ｉ＋１の閾値以下の場合の第ｉ＋１の価格とを含むビデオオンデマンドシステム。
【請求項３】
請求項２に記載のビデオオンデマンドシステムにおいて、
前記申込み管理機能部は、
前記配信情報記憶領域の第１乃至第Ｎの閾値と、求められた視聴申込数とに基づき、視聴申込数に応じた第ｊの価格（ｊは１〜Ｎのいずれかの整数）を求め、
視聴申込数と第ｊの閾値の差をとることで第ｊ＋１の価格になるために必要な申込数を求め、
視聴申込数と、求められた第ｊの価格と、前記必要な申込数とを、前記端末又は他の端末にさらに送信するビデオオンデマンドシステム。
【請求項４】
請求項２又は３に記載のビデオオンデマンドシステムにおいて、
予め定められた時間を計測するための時計
をさらに備え、
前記申込み管理機能部は、
前記時計により計測される前記時間内の視聴申込数を求め、求められた前記時間内の視聴申込数が予め定められた値を超えると、前記配信情報記憶領域の第ｉの閾値を増加させるビデオオンデマンドシステム。
【請求項５】
請求項１乃至４のいずれかに記載のビデオオンデマンドシステムにおいて、
前記申込み管理機能部は、
求められた視聴申込数が予め定められた閾値を超えると、視聴申込を受信した前記端末に代替案情報を送信するビデオオンデマンドシステム。
【請求項６】
請求項５に記載のビデオオンデマンドシステムにおいて、
前記予め定められた閾値は、システム能力に応じて定められ、コンテンツの映像品質ならびにサービス品質を劣化せずに視聴可能にするための値であるビデオオンデマンドシステム。
【請求項７】
請求項５又は６に記載のビデオオンデマンドシステムにおいて、
前記申込み管理機能部は、
視聴申込情報に含まれるコンテンツ識別子と視聴時刻に基づき、前記配信情報記憶領域を参照して、コンテンツ識別子に対応する他の視聴時刻を取得し、
該コンテンツ識別子と該他の視聴時刻に対応する価格を求め、
該他の視聴時刻及び価格を含む前記代替案情報を、視聴申込を受信した前記端末に送信するビデオオンデマンドシステム。
【請求項８】
請求項１乃至４のいずれかに記載のビデオオンデマンドシステムにおいて、
前記申込み管理機能部は、
求められた視聴申込数が予め定められた閾値を超えると、視聴希望者に提示するコンテンツの価格を上昇させるビデオオンデマンドシステム。
【請求項９】
請求項１乃至８のいずれかに記載のビデオオンデマンドシステムにおいて、
コンテンツ識別子及び視聴時刻に対応して、視聴申込数に基づき求められた価格が記憶される集計情報記憶領域
をさらに備え、
前記申込み管理機能部は、求められた価格を、コンテンツ識別子と視聴時刻とに対応して前記集計情報記憶領域に記憶するビデオオンデマンドシステム。
【請求項１０】
請求項１乃至９のいずれかに記載のビデオオンデマンドシステムにおいて、
ユーザが視聴申込を送信するための端末と、ユーザがコンテンツを視聴する端末が同一でないことを特徴とするビデオオンデマンドシステム。
【請求項１１】
請求項１乃至１０のいずれかに記載のビデオオンデマンドシステムにおいて、
ユーザが視聴希望の登録に使用する端末が、携帯電話であることを特徴とするビデオオンデマンドシステム。
【請求項１２】
請求項１乃至１１のいずれかに記載のビデオオンデマンドシステムにおいて、
コンテンツの配信をマルチキャストで行うことを特徴とするビデオオンデマンドシステム。
【請求項１３】
請求項５に記載のビデオオンデマンドシステムにおいて、
複数のコンテンツの視聴時刻が、ある時間帯で重なる場合、
前記申込み管理機能部は、該複数のコンテンツに対する各視聴申込数を集計して該時間帯における総視聴申込数を求め、該総視聴申込数が前記予め定められた閾値を超えると、視聴申込を受信した前記端末に代替案情報を送信するビデオオンデマンドシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ビデオオンデマンドシステムに係り、特に、ネットワークに接続したテレビジョン受像機などによって、ユーザが希望する番組を、ユーザが希望する時に視聴可能とするビデオオンデマンド、ニアビデオオンデマンドを実現する共同購入型のビデオオンデマンドシステムに関する。
【背景技術】
【０００２】
従来のビデオオンデマンド方式では、例えば、同時利用ユーザ数が、システムの最大能力を超えると、視聴画像のコマ飛びやフリーズなど映像品質の低下をきたす場合があった。
特許文献１の技術では、例えば、ビデオオンデマンドの番組視聴時に、ユーザが行うことが出来るトリックプレー（巻き戻し、早送りなど）の回数や時間の制限を行うこと、利用時間帯毎のユーザ混雑度を表示あるいは視聴番組に依存しない利用予約等によって、この課題を解決しようとしている。
特許文献３の技術では、例えば、コンテンツの配信対象者見込み数により適切な伝送手段を選択し、その際の配信コストを情報提供者に対し提供する手段が開示されている。
【特許文献１】特開２００３−３３３５７４号公報
【特許文献２】特開２００３−３３９００１号公報
【特許文献３】特開２００１−２９０７２２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
従来のビデオオンデマンド方式では、中央のビデオサーバ装置内に映像コンテンツを蓄積し、複数のユーザがネットワークを介して接続している。ビデオサーバに対して、複数のユーザから同時にアクセス要求があった場合、同時利用ユーザ数が、システムの最大能力を超えると、視聴画像のコマ飛びやフリーズなど映像品質の低下をきたすなどの課題があった。
また、従来のビデオオンデマンド方式では、同一コンテンツは同時視聴者数、視聴時間帯に関わらず同一価格で提供されるため、前述のような同時利用ユーザの集中が発生し、視聴希望者の要求を満たすことが出来ない場合があり、これはサービス事業者にとっては収入機会の損失ともなっていた。
また、サービス事業者の利益を大きくするには、利用者を多くすることが考えられるが、その一方で、利用者数がシステムの能力を超える可能性もある。
特許文献１の技術では、トリックプレー（巻き戻し、早送りなど）の回数や時間の制限は、ユーザ利便性の低下をもたらす。また、時間帯毎のユーザ混雑度の表示は積極的にユーザ混雑を制御する具体的な手段を有していない。
また、特許文献１及び特許文献２等では、利用予約により視聴者が視聴を希望する時間帯を予約可能な手段が開示されているが、ユーザの負荷を分散するための具体的な手段を提供していない。
【０００４】
特許文献３によれば情報提供者は、この情報にもとづき適切な回線選択及び、価格設定が可能となりうるが、配信対象者のプロファイルなどによる視聴見込みに依存しており、不確定性が高い。また、予約者数による価格低減などによる配信対象者数の増加など、情報提供者の収入の最大化に関わる手段が提供されていない。
本発明は、以上の点に鑑み、ビデオオンデマンドシステムの利用者数を増やすことで事業者の利益を大きくし、かつ、システムの能力を超えることによる品質の低下を防ぐことを目的とする。また、本発明は、ユーザに予め複数の番組放映時間帯を提示し、ユーザはこれらの候補時間帯の中から視聴希望する放映時間帯を予め登録して、ユーザの分散を図り、システムの負荷の平準化を目的とする。
【０００５】
本発明は、同時視聴者数に応じて変更される価格と、視聴希望利用者数をユーザに提示し、ユーザは経済的に有利な放映時間帯に乗り換えることが可能なシステムを提供することを目的のひとつとする。また、本発明は、番組放映時間帯における利用者数の制御を提供者側の価格設定により行うことが可能なシステムを提供することを目的のひとつとする。さらに、本発明は、システムの負荷の平準化と、ユーザにとってより経済的な視聴、事業者の利益の追求を可能とすることを目的とする。
本発明は、同時視聴者希望数がビデオオンデマンドシステム装置の最大負荷容量を超えそうな場合、視聴希望者に提示する価格を上昇させることによって、ビデオオンデマンドシステム装置の最大負荷容量内に納まる様に制御し、ユーザが画像品質の劣化なく映像の視聴ができるようにすることを目的のひとつとする。また、本発明は、同時視聴者希望数がビデオオンデマンドシステム装置の最大負荷容量を超えそうな場合、視聴希望者に代替の時間帯及び価格を提示することによって、視聴希望者数がビデオオンデマンドシステム装置の最大負荷容量内に納まる様に制御し、ユーザが画像品質の劣化なく映像の視聴ができるようにすることを目的のひとつとする。
【課題を解決するための手段】
【０００６】
上記課題を解決するため、本発明では、例えば、ユーザに予め同一番組の複数の番組放映時間帯を提示し、ユーザが視聴希望する時間帯を予め登録することによって、システムの負荷の平準化を図り、映像品質の劣化を起こしにくくすることを特徴のひとつとする。また、同時視聴者数に応じて価格を変更し、サービス事業者の利益を追及する。また、前述の手段に加え、ユーザに対し、同時視聴者数に応じて変更される価格と、視聴希望利用者数を利用者に提示することにより、経済原理によって、番組放映時間帯における利用者数の制御を行うことを特徴のひとつとする。
また、前述の手段に加え、視聴希望者数の単位時間内の増加が予め定めた値を越える場合、同時視聴者数に応じて価格を変化させる視聴者数の閾値を変更して、視聴者に提示する価格を維持することにより、同時視聴希望者の輻輳が見込まれるような場合にも、経済原理に基づきビデオオンデマンドシステム装置の最大負荷容量内に納まる様に制御することを特徴のひとつとする。
また、前述の手段に加え、同時視聴者希望数がビデオオンデマンドシステム装置の最大負荷容量を超えそうな場合、視聴希望者に提示する価格を上昇させることにより、経済原理に基づきビデオオンデマンドシステム装置の最大負荷容量内に納まる様に制御してもよい。
【０００７】
一方同時視聴者希望数がビデオオンデマンドシステム装置の最大負荷容量を超えそうな場合、視聴希望者に代替の時間帯及び価格を提示し推奨することによって、視聴希望者数がビデオオンデマンドシステム装置の最大負荷容量内に納まる様に制御してもよい。
また、これら前述の手段に加え、利用者が視聴希望の登録に使用するユーザ端末と同一でないユーザ端末により、利用者が映像を視聴可能とすることにより、利用者の利便性が向上をすることを特徴のひとつとする。
また、前述の手段において、利用者が視聴希望の登録に使用するユーザ端末を携帯電話とすることにより、利用者は外出先からでも利用の登録ができるなど、利用者の利便性が向上をすることを特徴のひとつとする。
１：ｎ（ｎは２以上の整数）で同時に複数の利用者に映像等をマルチキャストする場合において、なるべく多くの利用者が同時に視聴する様に、予め希望登録を行うことにより、経済原理による利用者の誘導などを行うことを特徴のひとつとする。
ビデオオンデマンド方式において、同一時間帯内の複数の番組について視聴者希望者数の集計を行うことによって、当該集計結果がビデオオンデマンドシステム装置の最大負荷容量内に納まる様行うことを特徴のひとつとする。
【０００８】
本発明の解決手段によると、
端末からコンテンツの視聴申込を受け付け、該端末にコンテンツを配信するビデオオンデマンドシステムにおいて、
コンテンツ識別子と、該コンテンツに対する複数の視聴時刻と、コンテンツ識別子及び視聴時刻毎の、視聴申込数に応じた複数の価格とが予め記憶された配信情報記憶領域と、
前記端末からの視聴申込数に基づきコンテンツの価格を求める申込み管理機能部と
を備え、
前記申込み管理機能部は、
複数の端末から、視聴を希望するコンテンツのコンテンツ識別子と、視聴を希望する視聴時刻とを含む視聴申込情報を受信し、
複数の前記端末からの視聴申込情報を集計して、コンテンツ識別子及び視聴時刻ごとの視聴申込数を求め、
コンテンツ識別子と視聴時刻とに基づき前記配信情報記憶領域を参照して、コンテンツ識別子及び視聴時刻に対応する複数の価格のうち、求められた視聴申込数に応じた価格を求め、
前記配信情報記憶領域のコンテンツ識別子と、該コンテンツに対する複数の視聴時刻と、該コンテンツ識別子及び各視聴時刻の求められた価格とを前記端末又は他の端末に送信し、
前記端末から変更要求又は前記他の端末から視聴申込情報を受信する前記ビデオオンデマンドシステムが提供される。
【発明の効果】
【０００９】
本発明によると、ビデオオンデマンドシステムの利用者数を増やすことで事業者の利益を大きくし、かつ、システムの能力を超えることによる品質の低下を防ぐことができる。また、本発明によると、ユーザに予め複数の番組放映時間帯を提示し、ユーザはこれらの候補時間帯の中から視聴希望する放映時間帯を予め登録して、ユーザの分散が図れ、システムの負荷の平準化ができる。
本発明によると、同時視聴者数に応じて変更される価格と、視聴希望利用者数をユーザに提示しており、ユーザは経済的に有利な放映時間帯に乗り換えることが可能となり、番組放映時間帯における利用者数の制御を提供者側の価格設定により行うことが可能となる。従って、システムの負荷の平準化ができるという利点と、ユーザにとってはより経済的な視聴が可能となる。
【００１０】
本発明によると、前述の利点に加え、同時視聴者希望数がビデオオンデマンドシステム装置の最大負荷容量を超えそうな場合、視聴希望者に提示する価格を上昇させることによって、ビデオオンデマンドシステム装置の最大負荷容量内に納まる様に制御することができ、ユーザが画像品質の劣化なく映像の視聴ができる。また、本発明によると、同時視聴者希望数がビデオオンデマンドシステム装置の最大負荷容量を超えそうな場合、視聴希望者に代替の時間帯及び価格を提示することによって、視聴希望者数がビデオオンデマンドシステム装置の最大負荷容量内に納まる様に制御するができ、ユーザが画像品質の劣化なく映像の視聴ができる。
【発明を実施するための最良の形態】
【００１１】
１．第１の実施の形態
以下、図面を参照して本実施の形態を説明する。
図１は、本共同購入型ビデオオンデマンド方式を実現するシステム（ビデオオンデマンドシステム）の一実施の形態を示すブロック構成図である。
このシステムは、例えば、申込み管理部（申込み管理装置）１と、配信制御部２を備える。申込み管理部１、配信制御部２は、ネットワーク３を介してユーザ端末４と通信する。なお、コンテンツを記憶したコンテンツ提供部５をさらに備えてもよい。コンテンツ提供部５は、例えば、コンテンツを含む媒体（例えば、フィルム、記憶部等の記録媒体）等のコンテンツ記憶部と、配信日時、価格等のコンテンツの提供に関する情報を設定するための設定部とを有してもよい。
申込み管理部１は、申込み管理機能部１０１とコンテンツの配信に関わる閾値情報等を記憶したデータベース１０２とユーザデータベース（ユーザＤＢ）１０６とを有する。配信制御部２は、配信制御装置１０３と、ストレージ１０４とを有する。申込み管理部１と、配信制御部２は、ネットワーク３を介してユーザ端末４と接続されている。配信しようとするコンテンツ５０は、配信制御部２のストレージ１０４に予め記憶する。また、配信しようとするコンテンツ５０の配信に関わる配信日時、価格、視聴者数対価格（閾値情報）などの情報は、データベース１０２に記憶される。これらの情報は、コンテンツ固有の識別記号（ＩＤ）によって、申込み管理部１と、配信制御部２の間で関連付けられる。なお、申込み管理部１と配信制御部２は、ひとつの装置で構成されてもよいし、別々の装置であってもよい。
【００１２】
図５に、コンテンツ配信情報テーブルの例を示す。
本テーブルは、図１のデータベース１０２に格納されており、例えば後述する図２のフローチャートにおけるメモリ上の番組情報テーブル１００２に相当する。
コンテンツ配信情報テーブル（配信情報記憶領域）１３００は、コンテンツ提供部５が配信制御部２にコンテンツ登録を行ったときに付与される、コンテンツ固有の識別記号（コンテンツＩＤ）１３０１、当該コンテンツの名称１３０２、配信予定時刻（視聴時刻）１３０３、第一閾値情報１３０４ａ、第二閾値情報１３０４ｂ及びこれに続く閾値情報ならびに最終閾値である第Ｎ閾値情報１３０４ｃが対応して記憶される。また、各閾値情報は次の閾値に移行する視聴者人数の閾値１３０５と当該閾値内での価格１３０６を含む。
例えば、コンテンツ配信情報テーブル１３００は、コンテンツＩＤ１３０１及び視聴時刻１３０３毎に、視聴申込数の第１乃至第Ｎの閾値（Ｎは整数）と、視聴申込数が第１の閾値以下の場合の第１の価格と、視聴申込数が第ｉの閾値（ｉは１〜Ｎ−１の整数）より大きく第ｉ＋１の閾値以下の場合の第ｉ＋１の価格とを含む。例えば、コンテンツＩＤが「Ａ００１」、配信予定時刻が「２１：００」に対して、視聴人数が２９９人（第１の閾値）までは価格が３００円（第１の価格）、３００人から５９９人（第２の閾値）までは１５０円（第２の価格）というように予め設定されている。なお、視聴申込数が第Ｎの閾値を超えた場合には、視聴申込を受け付けないようにしてもよいし、第Ｎの閾値を超えた場合の第Ｎ＋１の価格を記憶しておいてもよい。
【００１３】
各コンテンツは、コンテンツ固有の識別記号（ＩＤ）１３０１によって管理され、申込み管理部１と配信制御部２との間での整合が取られている。各コンテンツには、複数の配信予定時刻１３０３が登録できる。また、それぞれの配信予定時刻ごとに複数の閾値情報１３０４が登録可能であり、各閾値情報は価格１３０５及び視聴人数閾値１３０６の登録が出来る。
また、この例では、同一コンテンツは配信時刻に寄らず１つのコンテンツ固有の識別記号（ＩＤ）１３０１によって管理されているが、配信時刻によってコンテンツ固有の識別記号（ＩＤ）１３０１を割当て、同一コンテンツに複数割当ててもよい。この場合、番組情報テーブル１００２の更新を行おうとした場合に、当該時間帯だけの更新を容易に実現できるというメリットが考えられる。
【００１４】
図１８は、集計情報テーブルの構成例である。
集計情報テーブル（集計情報記憶領域）は、例えば、コンテンツ固有の識別記号（コンテンツＩＤ）と、そのコンテンツの視聴時刻とに対応して、集計された申込み人数（視聴申込数）と、現在価格が記憶される。
図１９は、ユーザ視聴テーブルの構成例である。
ユーザ視聴テーブルは、例えば、ユーザＩＤに対応して、視聴を希望するコンテンツＩＤと、視聴時刻と、最終的に決定した決定価格が記憶される。集計情報テーブル及びユーザ視聴テーブルは、例えば、ユーザデータベース１０６に格納されている。
【００１５】
図４は、コンテンツ登録及び配信情報登録のシーケンス図である。
まず、ログイン認証プロセス１２０１によって、コンテンツ提供部５と配信制御部２との間でユーザ認証が行われる。認証されたコンテンツ提供部５がコンテンツを配信システムに登録しようとする場合、コンテンツ提供部５はコンテンツ登録要求１２０２を配信制御部２に対して送信する。配信制御部２では、コンテンツ登録要求１２０２を受信するとコンテンツ固有の識別記号（ＩＤ）を生成し、コンテンツ提供部５に対しコンテンツ登録許可及び生成されたコンテンツ固有の識別記号（ＩＤ）を１２０３により通知する。なお、コンテンツＩＤは、配信制御部２が生成する以外にも、予め定められていてもよいし、適宜のタイミングで申込み管理部１等が生成してもよい。コンテンツ提供部５は、このコンテンツ固有の識別記号（ＩＤ）に対応したコンテンツデータ及び関連する情報を１２０４により配信制御部２に登録する。
【００１６】
配信制御部２では当該コンテンツ等を受信し、コンテンツＩＤに対応してコンテンツデータを保存し、コンテンツ登録完了通知１２０５をコンテンツ提供部５に送信する。また、コンテンツＩＤ共有情報１２０６が配信制御部２から申込み管理部１に送信され、配信制御部２と申込み管理部１の間で、登録されたコンテンツのコンテンツ固有の識別記号（ＩＤ）が共有される。申込み管理部１ではこのコンテンツ固有の識別記号（ＩＤ）を記憶し、そのＩＤに対応した番組配信情報を登録するテーブルの枠（領域）を作成する。
ここまでのプロセスにより、コンテンツ提供部５は当該コンテンツを配信制御部２への登録が完了する。登録完了後、ログオフプロセス１２０７によって、コンテンツ提供部５と配信制御部２との接続は切断される。
【００１７】
コンテンツの配信に関する情報は、上記コンテンツ本体とは別に申込み管理部１に保存する。コンテンツ提供部５は、コンテンツの配信に関する情報の登録を行うために、まず申込み制御部１との接続をログインプロセス１２０８によって行う。接続完了後、コンテンツ提供部５は配信情報登録要求１２０９を申込み管理部１に送信する。申込み管理部１では、コンテンツの配信情報の登録処理を開始し、どのコンテンツに関わる情報の登録を行うかを確認するため、コンテンツ提供部５に対しコンテンツＩＤ要求１２１０を送信する。コンテンツ提供部５は、申込み管理部１に当該コンテンツを配信制御部２に登録した際に付与されたコンテンツ固有の識別記号（ＩＤ）１２１１を送信する。申込み管理部１では、当該コンテンツ固有の識別記号（ＩＤ）に対応したテーブル枠(領域)を呼び出し、コンテンツ提供部５に対して配信情報登録許可１２１２を送信する。
コンテンツ提供部５は、配信情報登録許可１２１２を受け、当該ＩＤに対応した配信情報登録１２１３を申込み管理部１に送信する。例えば、コンテンツＩＤ、映像名称、配信予定時刻、第１〜第Ｎ閾値情報が送信される。申込み管理部１では、受信した情報に基づきテーブルの更新を行う。例えば、受信したデータをデータベース１０２のコンテンツ配信情報テーブル１３００に記憶する。申込み管理部１は、コンテンツ提供部５に対し配信情報登録完了１２１４を通知し、番組配信情報の登録が完了する。全てのプロセスが終了すると、ログオフプロセス１２１５によって、コンテンツ提供部５と申込み管理部１の接続は断たれる。
【００１８】
図２は、申込み管理部１の動作についてのフローチャートである。
申込み管理部１（例えば、申込み管理機能部１０１、以下同様）は、動作開始後、テーブル初期化１００１によって、メモリ上の番組情報テーブル１００２の初期化を行う。続いて、手順１００３によって、データベース１０２内の番組関連情報を参照する。例えば、図５のコンテンツ配信情報テーブル１３００の情報をメモリ（番組情報テーブル）にロードする。なお、番組情報テーブルは、コンテンツ配信情報テーブル１３００と同様の構成を有することができる。申込み管理装置１０１は、手順１００４により番組情報テーブル１００２内の第一閾値価格１２０６を現在価格に設定する。例えば、それぞれのコンテンツＩＤ及び視聴時刻について、第一閾値価格１２０６を集計情報テーブルの現在価格に記憶する。続いて手順１００５により、番組情報テーブル１００２に基づき視聴希望の登録受付が開始される。手順１００６では、申込み管理装置１０１は、現在の視聴希望者数と、次の閾値までの視聴希望者数を初期設定する。手順１００７は、申込み管理装置１０１が、例えば、番組情報テーブル１００２に記憶される、予め定められた申込み期間の終了を判定するものである。申込み期間内であれば（Ｎｏ）、手順１００８に進み、申込み期間を過ぎた場合には（Ｙｅｓ）、手順１０１３に進む。
【００１９】
手順１００８では、申込み管理装置１０１が、例えば手順１００４、１００６等で計算された、現在の視聴希望者数、現在の価格及び、次の閾値価格までの視聴希望者数をユーザ端末４に表示する手順である。実際の表示には、ネットワーク３を介した通信の結果行われる。
ユーザは、ユーザ端末４に表示された、コンテンツの視聴申込み状況を参考に、視聴希望の申込みを手順１００９により行う。複数のユーザ端末４からの視聴希望申込み結果は、手順１０１０によって集計される。手順１０１１では、申込み管理装置１０１は、手順１０１０によって集計された、視聴希望申込み数が番組情報テーブル１００２内の第Ｘ番目（Ｘは１〜Ｎの整数）の閾値を超えたかどうかの判断を行う。例えば、現在の視聴希望者数から、現在の第ｊ番目の価格（ｊは１〜Ｎのいずれかの整数）を求め、次の第ｊ＋１番目の閾値人数までの視聴希望者数が計算され、手順１００６に戻る。例えば、求められた視聴申込数が、第ｊ−１の閾値と第ｊの閾値の間にあることを求め、対応する第ｊの価格を求める。また、視聴申込数と第ｊ＋１の閾値の差をとることで第ｊ＋１の価格になるために必要な申込数を求める。
【００２０】
また、申込み期間を終了した場合には、申込み管理装置１０１は、手順１０１３により申込みを締め切る。手順１０１４では、申込み管理装置１０１は、締め切られた申込み結果に基づき、最終的な申込み数を集計し、この値に基づき番組情報テーブル１００２から最終的な価格を決定する。申込み管理装置１０１は、この結果を、手順１０１５によりネットワーク３を介してユーザ端末４に送信する。ユーザは、ユーザ端末４に表示された結果に基づき、手順１０１６により最終的な申込みの確認を行う。この申込み確認により手順１０１７で契約の確定を行う。確定した契約内容は、手順１０１８によって、申込み管理装置１０１は、番組配信制御部２にビデオオンデマンドアクセス権情報として伝達する。ここまでの手順により、ユーザは自分の希望する番組を、希望する時間帯に視聴する権利を得ることが出来る。
【００２１】
図３は、視聴希望登録から視聴開始までのシーケンスの例である。
次に前述の申込み管理部１の動作について、図３のシーケンス図を用いて説明する。ログインプロセス１１０１は、申込み管理部１とユーザ端末４との間でユーザ端末４が正しいユーザであるかを確認するためのプロセスである。このプロセスでは、例えば、ユーザ端末４の固有番号、パスワード等の情報とシステム登録情報を照査する。本プロセスが終了すると、申込み管理部１からユーザ端末４に対しログインの完了通知１１０２が送出される。また、申込み管理部１は、配信制御部２に対しユーザ情報通知１１０３を送出する。ユーザ情報通知１１０３は、例えば、ユーザＩＤ、端末ＩＤ、端末種別等を含むことができる。配信制御部２では、ユーザ情報通知１１０３に基づき、配信のための開始処理を行う。
【００２２】
ユーザ端末４では、完了通知１１０２を受信すると、例えばログイン結果を表示する。ログイン結果が正常であれば次に進み、一方、正常でない場合は、再度ログインプロセスが実行される。
申込み管理部１は、正常にログインされたユーザに対し、申込み管理部１がメモリ上の番組情報テーブル１００２又はデータベース１０２上のコンテンツ配信情報テーブルに基づき生成したメニューをメニュー通知１１０４によりユーザ端末４に送出する。送信されるメニューは、例えば、コンテンツＩＤ、映像名称（タイトル）、配信予定時刻（視聴時刻）を含む。さらに、現在価格、現在の申込み数等を含んでもよい。ユーザ端末４ではメニューを画面表示する。例えば、図６に示す画面例（詳細は後述する）を表示することができる。なお、ここでは現在価格、申し込み数、備考欄は省略してもよい。ユーザは視聴希望の選択を行い登録操作を行うと、ユーザ端末４から希望登録（視聴申込）１１０５が申込み管理部１に送信される。希望登録は、例えば、ユーザＩＤ、選択されたコンテンツのＩＤ及び視聴時刻を含む。
【００２３】
申込み管理部１は、希望登録を受信し、ユーザＩＤに対応してコンテンツＩＤと視聴時刻を、ユーザデータベース１０６のユーザ視聴テーブルに記憶する。また、申込み管理部１では、複数のユーザ端末４からの希望登録１１０５を受信しており、これらを集計して希望集計画面を生成する。例えば、申込み管理部１は、コンテンツＩＤ及び視聴時刻で特定されるコンテンツ毎に申し込み数を求め、コンテンツ配信情報テーブルに記憶された閾値情報と比較して、現在価格を求める。また、申込み管理部１は、コンテンツＩＤ及び視聴時刻に対応して、求められた申し込み数と現在価格を、集計情報テーブルに記憶する。さらに、申し込み数が増加することにより価格が変更される次の閾値までの人数を求めてもよい。この希望集計画面は、申込み管理部１は、映像名称と、視聴時刻と、各映像及び視聴時刻の現在価格及び申込み数、申し込み数が増加することにより価格が変更される次の閾値までの人数とを含む集計情報１１０６をユーザ端末４に送信し、ユーザ端末４は、集計情報１１０６を表示する（図６）。
【００２４】
ユーザは、ユーザ端末４に表示される現在の申込み状況に基づき、より有利な配信時間帯に移動する登録を行うことが出来る。希望登録１１０５で登録したコンテンツ及び視聴時刻から変更希望がある場合、ユーザはユーザ端末４から変更登録（変更要求）１１０７を申込み管理部１に送信する。申込み管理部１では、登録締切以前の場合、シーケンス１１０８により希望集計手順に戻り現在の登録状況を集計し、画面の生成を行う。登録締切時間までの間、集計情報１１０６から、１１０８までが繰り返される。
また、申込み管理部１は、締め切り時刻が近づいた段階で、締切予告１１０９をユーザ端末４に対し送出し、ユーザに対し締切時刻が近いことを通知する。申込み管理部１は、締切時刻となったときには、締切通知１１１０をユーザ端末４に送出し、ユーザに申込み締切を通知する。以後、当該コンテンツへの申込み入力を遮断する。
申込み管理部１では、申込みを締切ると最終的な登録内容を確認する。例えば、集計情報テーブルに記憶されている最終的な申し込み人数に基づき、価格を決定する。また、決定された価格を、該当するコンテンツ識別子及び視聴時刻に対応して、ユーザ視聴テーブルに記憶してもよい。視聴希望登録をしたユーザ端末４に対し登録内容確認通知１１１１を送信する。ユーザはユーザ端末４に表示される登録内容を確認し、登録内容に誤りがない場合には登録内容承認通知１１１２を申込み管理部１に送信する。
【００２５】
登録内容承認通知１１１２を受信した申込み管理部１は、申込み情報を本登録し、コンテンツ固有の識別記号（ＩＤ）と配信情報１１１３を配信制御部２に送出する。例えば、申込み管理部１は、ユーザデータベース１０６に記憶されているコンテンツ識別子と、対応するユーザＩＤ及び視聴時刻とを配信制御部２に送出する。配信制御部２では、受信した各情報に基づき配信予定の更新を行う。
また、申込み管理部１は、申込み情報を本登録完了後、ユーザ端末４に対して、登録完了通知１１１４を送出する。本登録完了通知１１１４により、番組視聴のための登録が完了する。
ユーザ端末４は、ユーザが登録した視聴時刻に、番組の視聴を行うことが出来る。番組の視聴を行うには、ユーザ端末４から視聴要求１１１５を申込み管理部１に対して送信する。申込み管理部１では視聴要求１１１５を受け付けた後、配信制御部２に対し、視聴要求１１１６を転送する。この転送された視聴要求に基づき、配信制御部２では番組の配信を開始し、ユーザ端末４に対してコンテンツ１１１７が配信される。なお、コンテンツの配信は１：ｎのマルチキャスト通信でもよい。
【００２６】
図６は、ユーザ端末４に表示される画面の例である。
ユーザがログイン操作を完了した後の、ユーザ端末４のディスプレイ１４００には、図６の様な画面が表示されることができる。タイトル欄１４０１は、視聴可能なコンテンツの表題が示されている。これらの各コンテンツは、それぞれ視聴可能時刻１４０２がひとつ又は複数示されている。また、それぞれの視聴可能時刻ごとに、現在価格１４０３と申込み数１４０４が表示されている。備考欄１４０５には、図２の番組情報テーブル１００２（又は図５のコンテンツ配信情報テーブル）の内容により計算された、次の価格帯に移る閾値までに必要となる申込み人数が表示される。ユーザは、例えばリモコンなどの入力装置を利用し、視聴希望の選択を行う。この際、選択された部分はハイライト１４０６によって、画面上で他の選択肢と明らかに異なる様に表示されてもよい。画面下には、簡単な使い方が１４０７ａから１４０７ｃのように表示されることができる。
ユーザは、ユーザ端末４に表示された内容に基づき、希望する番組とその視聴時間を容易に選択できる。また、現在価格及び次の価格までの所要人数も表示されているため、経済的に自らの希望するコンテンツを視聴することが可能となる。
【００２７】
次に、コンテンツ提供価格を下げてユーザ分散を図った場合でも、収入の最大化又は利益の追求が見込まれることを次に示す。
図７は、利用者数と収入の関係の例を示す。
横軸に利用者数１５０１をとり、縦軸に事業者の収入１５０２を取っている。直線１５０３ａから１５０３ｄは理想的な収入直線を示している。この例では１５０３ａが単価が最も高く、１５０３ｄが単価が最も低い。このため、同じ収入を得るために必要な利用者数は、単価が最大の１５０３ａが最も少なく、単価が最小の１５０３ｄが最も多い。従って、収入を大きくするためには単価を上げることが最良の方法に思われるが、実際には単価毎に異なる利用者の購買意欲を考慮する必要がある。
【００２８】
図８は、利用者数と購入確率すなわち購買意欲を価格ごとに示したグラフの例である。
横軸に対象者数１６０１をとり、縦軸に購入確率１６０２を取っている。曲線１６０３ａから１６０３ｄは価格ごとの購入確率を示した曲線である。曲線１６０３ａが最も単価が高い場合で、１６０３ｄが最も単価が安い場合である。例えば、曲線１６０３ｄでは、購入確率が０．５の人がｂ人いることを示している。これば、ｂ人のうち５０％が購入するであろうことを示し、残りは購入しないことを示す。また曲線１６０３ｄでは、購入確率が０．２の人がｃ人いることを示している。これは、ｃ人のうち２０％が購入することを示し、残りは購入しないことを示す。一方、単価の高い曲線１６０３ａでは、購入確率が０．５の人は、上述のｂ、ｃより少ないａ人しかいないことを示している。
各曲線はこの例では正規分布となっている。最も単価の高い曲線１６０３ａでは、購入確率は利用者数が少ない段階で急速に減少し、やがて０になる。これは、高価な単価での購入をする者の数が少ないことを示している。この傾向は、曲線１６０３ｂから１６０３ｄに移るに従い緩やかになり、単価を安くした場合の購入者の増加が見込まれることが示されている。
【００２９】
図７の利用者数と収入見込みを検討する場合、図８の様な単価毎の利用者数と購入確率を考慮する必要がある。図７の曲線１５０４ａは、直線１５０３ａに図８の確率曲線１６０３ａを掛け合わせることによって、より実際に近い収入見込みを示したものである。また同様に、各価格ごとの曲線１５０３と確率曲線１６０３を掛け合わせて、曲線１５０４を示している。なお、この曲線１５０４は本実施の形態の説明のために便宜的に図７上に示したが、確率曲線１６０３との賭けあわせを行っているため、横軸は単純な利用者数ではなく購入価格による確率を加味した値となっている。
これらの曲線１５０４では、単価の最も高い曲線１５０４ａは利用者の少ない範囲では最も高収入が見込まれるが、ある程度の以上の利用者が望めないため、収入見込みは飽和してしまう。曲線１５０４ａより単価の低い曲線１５０４ｂでは、利用者数の少ない範囲では曲線１５０４ａより収入が低いが、価格を下げていることにより、より多くに利用が期待できるため、最終的に飽和するものの、その際の収入は最も単価の高い曲線１５０４ａに比べて高いものとなる。同様に曲線１５０４ｃ、曲線１５０４ｄでもそれぞれ単価の安い分、利用者数の増加を見込むことが出来るため、収入は大きくなる。
【００３０】
図９に、本実施の形態による利用者数と収入見込みの関係を示す。
横軸は利用者数であり、縦軸は収入見込みである。直線１５０３は、各価格ごとの理想的な収入見込みを示す。曲線１５０５は、本実施の形態により利用希望者数により価格を変更した場合の収入見込みを示している。本実施の形態では予め設定した利用者数を超えると、システム側で予め設定したより安い価格に単価を変更する。このため、曲線１５０５は、鋸の歯状の曲線となる。一旦収入見込みは低下するが、価格低減による利用者の増加により、より多くの収入が見込まれる。
この様に、本実施の形態によれば、単純に単価を下げるのではなく、利用者の需要に応じて単価を下げることが出来るため、収入の最大化を図ることが出来る特徴がある。また、上記実施の形態によれば、経済原理によって、ユーザがより安い時間帯に移行するため、負荷の集中による配信制御部などの過負荷を避けることが出来る。
【００３１】
２．第２の実施の形態
以下、図面を参照して第２の実施の形態を説明する。本実施の形態では、例えば、単位時間内の視聴申込者数が予め定められた閾値を越えた場合に、価格を変更するための視聴人数閾値を変更する。
図１０は、本実施の形態の共同購入型ビデオオンデマンド方式を実現するシステムのブロック構成図である。構成は図１に示したブロック構成図と比べて、時計１０５をさらに有している。
この実施の形態では、システムは申込み管理部１と、配信制御部２とを備える。また、ネットワーク３、ユーザ端末４と、コンテンツ５を備えてもよい。申込み管理部１は、申込み管理機能１０１とコンテンツの配信に関わる閾値情報を記憶したデータベース１０２と、ユーザデータベース１０６とを有する。配信制御部２は、配信制御装置１０３と、ストレージ１０４を有する。また、申込み管理部１には、時計１０５が接続されており、予め定められた単位時間の計測が可能となっている。なお、時計は、申込み管理部１の内部にあってもよい。申込み管理部１と、配信制御部２は、ネットワーク３を介してユーザ端末４と接続されている。配信しようとするコンテンツ５は、配信制御部２のストレージ１０４に予め記憶する。また、配信しようとするコンテンツ５の配信に関わる配信日時、価格、視聴者数対価格などの情報は、データベース１０２に記憶される。これらの情報は、コンテンツ固有の識別記号（ＩＤ）によって、申込み管理部１と、配信制御部２の間で関連付けられる。なお、他の構成は、第１の実施の形態と同様である。
【００３２】
図１２は、本実施の形態におけるコンテンツ配信情報テーブルの構成例である。
番組情報テーブル１００２も同様である。本実施の形態では、番組情報テーブル１００２は実施の形態１の内容に加え、各コンテンツ毎に増加係数情報１３１１をさらに有している。増加係数１３１１は、単位時間申込人数増分の閾値１３１１ａと、閾値人数増分１３１１ｂを含む。
図１１は、第２の実施の形態のフローチャートの例である。
申込み管理部１の動作について、図１１に示すフローチャートに基づき説明する。本フローチャートは、図２に示すフローチャートの一部を変更したものとなっている。図２と同じ等号を記したものは、第１の実施の形態と同様であるので、詳細な説明を省略する。
申込み管理部１は、動作開始後、テーブル初期化１００１によって、番組情報テーブル１００２の初期化を行う。続いて、手順１００３によって、データベース１０２内の番組関連情報を参照する。
【００３３】
申込み管理装置１０１は、手順１００４により番組情報テーブル１００２内の第一閾値価格を現在価格に設定する。続いて手順１００５により、番組情報テーブル１００２に基づき視聴希望の登録受付が開始される。手順１００６では、現在の視聴希望者数に基づき、番組情報テーブル１００２の閾値価格との参照が行われ、現在の視聴希望者数から、第ｊ番目の価格及び、次の第ｊ＋１番目の閾値価格までの視聴希望者数が計算される。手順１００７は、番組情報テーブル１００２で規定される申込み期間の終了を判定するものである。申込み期間内であれば、手順１００８に進み、申込み期間を過ぎた場合には、手順１０１３に進む。
手順１００８では、手順１００６で計算された、現在の視聴希望者数、現在の価格及び、次の閾値価格までの視聴希望者数をユーザ端末４に表示する手順である。実際の表示には、ネットワーク３を介した通信の結果行われる。ユーザは、ユーザ端末４に表示された、コンテンツの視聴申込み状況を参考に、視聴希望の申込みを手順１００９により行う。複数のユーザ端末４からの視聴希望申込み結果は、手順１０１０によって集計される。
【００３４】
本実施の形態では図２のフローチャートと異なり、図１２では、例えば手順１０１０の後に手順１０３１によって、申込み管理部１は、単位時間内の視聴希望申込み者数の増分が、あらかじめ番組情報テーブル１００２に設定した単位時間申込人数増分の閾値１３１１ａの値ｘを超えているか否かの判断をする。単位時間内の視聴希望申込み者数が、単位時間人数増分１３１１ａで設定した値ｘを超えた場合、手順１０３２によって、番組情報テーブル１００２内の、現在の視聴人数閾値１３０５を閾値人数増分１３１１ｂだけ増加させる。この操作によって、視聴者の申込みが殺到するような場合におけるユーザの輻輳を経済原理によって制御することが可能となる。例えば、新作映画の封切り直後の駆け込みの申込みによる輻輳を防ぐことができる。
この後に続く手順については、図２の例と同一であるので省略する。また、シーケンスについても図３、図４の例と同一であるので省略する。
本実施の形態によれば、ユーザの輻輳が発生する可能性の高いコンテンツを、単位時間何の申込み数によって判断し、当初の申込者数の閾値を漸増させることにより価格を維持し、経済原理によって、ユーザの輻輳を避けることが可能となる。
【００３５】
３．第３の実施の形態
以下、図面を参照して第３の実施の形態を説明する。本実施の形態は、利用者の申込み数が配信制御部２のシステム能力を超過する場合に、利用者に代替案を提示することによって、利用者の分散を促し、システム能力の超過を回避するものである。
図１３は、本実施の形態の動作を説明するフローチャートの例である。図２と同じ等号を記したものは、第１の実施の形態と同様であるので、詳細な説明を省略する。なお、全体システム構成は、図1に示すものと同様な構成で実施可能である。
図１３では、第１の実施の形態、第２の実施の形態と異なり、利用者の申込み数が配信制御部２のシステム能力（予め定められた閾値）を超過するか否かを、手順１０４１によって判断する。手順１０４１の判断基準となるシステム能力は、システムに依存するものであり、基本的にはコンテンツに依存しない値である。従って、例えば配信制御部２の固有の値として、申込み管理部１に予め設定をすることができる。なお、この設定値を、番組情報テーブル１００２に記憶させることも、その実施の一方法である。
【００３６】
視聴希望者数は視聴希望者数集計１０１０にて集計され、申込み管理部１は、この集計された視聴希望者数（集計値）と配信制御部２の能力を、手順１０４１にて比較する。この比較の結果、集計値が配信制御部２の能力を超えていない場合には、手順１０１１に進み、第１の実施の形態と同様に価格変更の判断がなされ、その結果に応じてそれに続く手順が実施される。また、比較の結果、集計値が配信制御部２の能力を超えた場合には、代替案の提示１０４２に進み、申込み管理部１はユーザ端末４に、現在希望している以外の代替案を提示する。代替案については、番組情報テーブル１００２に、各コンテンツ毎の代替案を予め記憶することも一方法であるし、別のテーブルとして準備することも出来る。また、例えば、申込み管理機能部１０１が、視聴申込情報に含まれるコンテンツＩＤと視聴時刻に基づき、配信情報テーブル１３００を参照して、コンテンツＩＤに対応する他の視聴時刻を取得し、コンテンツ識別子と他の視聴時刻に対応する価格を例えば集計情報テーブルを参照して求め、他の視聴時刻及び価格を含む代替案情報を、視聴申込を受信した端末に送信するようにしてもよい。
【００３７】
ユーザは、代替案の提示１０４２によって提示された代替案を、代替案承認１０４３において承認すると、優先的に代替案の視聴が可能となるよう、申込み締切１０１３に移行する。また、ユーザが代替案を承認しない場合、視聴希望者閾値判断１０１１に進み、当初コンテンツ視聴の希望が維持される。
この手順の場合、代替案を提示された当該ユーザが代替案を承認しない場合、配信制御部２のシステム能力を超過することが予想される。これを回避する方法としては、判断１０４１に使用する配信制御部２のシステム能力の値を、実際の配信制御部２のシステム能力に対して余裕を持たせる方法、また、代替案の提示１０４２を同時に複数のユーザに対し行うことにより、代替案を承認するユーザが存在する可能性を高める方法などが考えられる。これらを組み合わせた方法も考えられる。なお、代替案を複数のユーザに提示する場合、代替案を提示するユーザの選定には、申込み順が最後の者から提示する方法、申込者の中からランダムに抽出する方法、申込み時にユーザに代替案承諾の可否を登録させ、代替案承諾可としたものに提示する方法などが考えられる。
【００３８】
また、複数のコンテンツの視聴時刻がある時間帯で重なる場合、申込み管理機能部１０１が、複数のコンテンツに対する各視聴申込数を集計してその時間帯における総視聴申込数を求め、総視聴申込数が予め定められた閾値を超えると、視聴申込を受信した前記端末に代替案情報を送信するようにしてもよい。
本実施形態によれば、システム能力を超えるユーザ数を受け付けないため、ユーザは配信制御部１の能力の範囲内で利用が可能となるため、映像の劣化などを受けることなく高品質な映像の視聴が可能となる。
この例の他に、利用者の申込み数が配信制御部２のシステム能力を超過する場合に利用者の超過を防ぐ方法として、配信制御部２のシステム能力に合わせ申込みを締め切る方法、配信制御部２のシステム能力を超過する場合に価格を上げ、経済原理により視聴希望者を削減させる方法などが考えられる。
【００３９】
４．第４の実施の形態
以下、図面を参照して第４の実施の形態を説明する。
図１４は、本実施の形態の共同購入型ビデオオンデマンド方式を実現するシステムのブロック構成図である。この実施の形態のシステムは、申込み管理部１と、配信制御部２とを備え、さらに、ネットワーク３、ユーザ端末Ａ４ａ及び４ｂと、コンテンツ５を備えてもよい。ただし、本実施の形態では、上述の各実施の形態におけるユーザ端末４は、映像視聴をするユーザ端末Ａ４ａと、申込み登録を行うユーザ端末Ｂ４ｂに対応する。また、ユーザ端末Ａ４ａ、ユーザ端末Ｂ４ｂはそれぞれネットワーク３ａ、３ｂを介して接続されている。なお、本実施の形態は、上述の第１の乃至第３の実施の形態と組み合わせることができる。
申込み管理部１は、申込み管理機能１０１とコンテンツの配信に関わる閾値情報を記憶したデータベース１０２及び、ユーザの端末情報を記憶したユーザデータベース１０６を有する。ユーザデータベース１０６は、ユーザ毎のユーザ端末Ａ４ａとユーザ端末Ｂ４ｂを関連付ける情報を記憶している。
【００４０】
配信制御部２は、配信制御装置１０３と、ストレージ１０４を有する。申込み管理部１はネットワーク３ｂを介してユーザ端末Ｂ４ｂと接続されている。また、配信制御部２は、ネットワーク３ａを介してユーザ端末Ａ４ａと接続されている。配信しようとするコンテンツ５は、配信制御部２のストレージ１０４に予め記憶する。また、配信しようとするコンテンツ５の配信に関わる配信日時、価格、視聴者数対価格などの情報は、データベース１０２に記憶される。これらの情報は、コンテンツ固有の識別記号（ＩＤ）によって、申込み管理部１と、配信制御部２の間で関連付けられる。
図１５は、ユーザデータベース１０６内のユーザ情報テーブル１７００の構成例である。
ユーザ情報テーブル１７００は、ユーザ名１７０１、視聴端末情報１７０２、登録端末情報１７０３、備考１７０４の要素を含む。視聴端末情報１７０２は更に、端末種別１７０２ａと端末識別記号１７０２ｂを含む。同様に、登録端末１７０３は更に、端末種別１７０３ａと端末識別記号１７０３ｂを含む。これらの要素は、ユーザ名１７０１をキーとして関連付けられている。
【００４１】
また、ユーザは、複数の視聴端末１７０２、登録端末１７０３を登録することが可能である。図１５の例ではユーザＡが視聴端末２台、登録端末２台を登録した例を示している。この例では、便宜的に視聴端末であるユーザ端末Ａ１と登録端末であるユーザ端末Ｂ１が関連付けられ、また、視聴端末であるユーザ端末Ａ２と登録端末であるユーザ端末Ｂ２が関連付けられている様に見えるが、同一ユーザに帰属する全ての視聴端末１７０２と全ての登録端末１７０３は関連付けられ、登録と視聴はどの端末からでも実施可能とすることもできる。
【００４２】
本実施の形態によれば、ユーザは視聴端末と異なる登録端末から視聴希望の申込みが可能となるため、視聴端末が番組の視聴中である場合にも、視聴希望の登録が可能となる。また、ユーザ端末Ｂ４ｂに携帯電話を使用し、ネットワーク３ｂに携帯電話網を使用した場合には、ユーザは外出先などからでも番組視聴希望の登録が可能となる。
図１６は、本実施の形態のユーザデータベース１０６に、複数のユーザ端末をユーザ４に関連付けて登録するための手順を示すシーケンス図である。
この例では、ユーザ端末Ａ４ａは、予めユーザ４所有の端末として登録されており、ユーザ名（又はユーザＩＤ）１７０１、視聴端末情報１７０２がユーザデータベース１０６に登録されているものとする。ユーザ端末Ａ４ａの登録方法については、例えば、書面による登録、端末販売時のＩＤ書込みなどの方法が考えられる。
【００４３】
新たな端末の追加は、ユーザデータベース１０６に既に登録済のユーザ端末Ａ４ａから、申込み管理部１に対し追加登録を行うことにより実施する。以下に本例の手順を示す。
まず、ユーザ端末Ａ４ａからログインプロセス１８０１により申込み管理部１にログインを行う。ログインが完了したことは完了通知１８０２により申込み管理部１からユーザ端末Ａ４ａに通知される。申込み管理部１では、ログイン時にユーザ端末Ａ４ａから送信される端末の識別記号やユーザ名等をユーザ情報テーブルと照合し、ユーザ名１７０１、視聴端末１７０２、登録端末１７０３を確認する。ユーザ端末Ａ４ａでは、申込み管理部１からのメニュー１８０３を表示し、メニューの中から端末追加が選択されると、追加端末登録要求１８０４を申込み管理部１に伝送する。申込み管理部１では、前述のユーザ名１７０１に関連付けられた追加仮ＩＤを生成し、ユーザ情報テーブルに記録するとともに、手順１８０５により追加仮ＩＤをユーザ端末Ａ４ａに伝送する。ユーザ端末Ａ４ａでは、追加仮ＩＤを表示し、利用者はこの追加仮ＩＤにより、端末の追加を行う。
【００４４】
利用者は、新たに追加したい端末Ｂ４ｂを用い、追加仮ＩＤによって申込み管理部１にログインを１８２１により行う。ログインの完了は手順１８２２によって端末Ｂ４ｂに通知される。また、同時に手順１８２２では、追加する端末Ｂ４ｂの端末種別１７０３ａを要求する。端末Ｂ４ｂは、端末識別、端末の識別記号等を申込み管理部１へ送信する。なお、申込み管理部１では、手順１８２４で取得した追加するユーザ端末Ｂ４ｂの情報に基づき、ユーザ名１７０１と関連付けられた正規の端末識別記号１７０３ｂを生成し、手順１８２５により登録内容の確認と同時に識別記号１７０３ｂを発行してもよい。ユーザ端末Ｂ４ｂでは、登録内容を確認し、手順１８２６によって登録内容の承認を申込み管理部１に通知する。申込み管理部１では、手順１８２６によって、ユーザ承認を得たと確認し、ユーザ情報テーブルを更新する。例えば、申込み管理部１は、ユーザ名に対応して、登録端末の端末種別、識別番号を記憶する。ユーザ情報テーブルの更新が完了したことは、手順１８２７によってユーザ端末Ｂ４ｂに伝送され、追加端末の登録が完了する。
上記の例において、手順１８０５によって伝送され端末Ａ４ａに表示される追加端末の仮ＩＤは、追加する端末からアクセスすべきアドレスなどの情報とともに、二次元バーコードなどで表示することも可能であり、携帯電話をユーザ端末Ｂ４ｂとして利用する場合などのユーザ利便性の向上が図れる。
【００４５】
図１７は、本実施の形態における視聴希望登録から視聴開始までの手順を示すシーケンス図である。基本的な手順は図３と同じであるが、視聴希望の登録のための手順１１０１から１１１４はユーザ端末Ｂ４ｂによって行われる。
番組の視聴は、ユーザ端末Ａ４ａによって行われる。ユーザ端末Ａ４ａの申込み管理部１へのログイン後（図１７では省略）、手順１１１５によって、視聴要求が出され、申込み管理部１によって視聴要求１１１６として配信制御部２に伝送された後、手順１１１７によって番組の配信が行われ、ユーザ端末Ａ４ａによって視聴可能となる。
例えば、申込み管理部１は、視聴要求１１１５をユーザ端末Ａ４ａから受信すると、ユーザ情報テーブルの視聴端末を参照して、ユーザ端末Ａ４ａに対応するユーザ名（又はユーザＩＤ）を取得する。申込み管理部１は、ユーザ視聴テーブルを参照して、取得したユーザ名に対応するデータ、例えばコンテンツＩＤ、視聴時刻を取得し、配信制御部２に視聴要求１１１６を送信する。
【産業上の利用可能性】
【００４６】
本発明は、例えば、ビデオオンデマンドシステムに利用可能である。
【図面の簡単な説明】
【００４７】
【図１】本実施の形態のシステムのブロック図の例。
【図２】申込み管理部のフローチャートの例。
【図３】視聴希望登録から視聴開始までのシーケンスの例。
【図４】コンテンツ登録及び配信情報登録のシーケンス例。
【図５】コンテンツ配信情報テーブルの例。
【図６】ユーザ画面表示の例。
【図７】利用者数と収入の関係を示す例。
【図８】価格毎の購入確率曲線の例。
【図９】本発明の実施の形態による利用者数と収入の関係例。
【図１０】第２の実施の形態のシステム構成のブロック図の例。
【図１１】第２の実施の形態のフローチャートの例。
【図１２】第２の実施の形態のコンテンツ配信情報テーブルの例。
【図１３】第３の実施の形態のフローチャートの例。
【図１４】第４の実施の形態のブロック図の例。
【図１５】第４の実施の形態のユーザ情報テーブルの例。
【図１６】ユーザデータベース１０６において、複数のユーザ端末をユーザ４に関連付けるための手順を示すシーケンス図。
【図１７】視聴希望登録から視聴開始までの手順を示すシーケンス図。
【図１８】集計情報テーブルの例
【図１９】ユーザ視聴テーブルの例
【符号の説明】
【００４８】
１  申込み管理部
２  配信制御部
３、３ａ、３ｂ  ネットワーク
４、４ａ、４ｂ  ユーザ端末
５  コンテンツ提供部
１０１  申込み管理機能部
１０２  データベース
１０３  配信制御装置
１０４  ストレージ
１０５  時計
１０６  ユーザデータベース
１３００  コンテンツ配信情報テーブル
１３０１  コンテンツＩＤ
１３０２  映像名称
１３０３  配信予定時刻
１３０４ａ  第一閾値情報
１３０４ｂ  第二閾値情報
１３０４ｃ  第Ｎ閾値情報
１３０５  視聴人数の第一閾値
１３０６  第一閾値における価格
１３１１  増加係数
１３１１ａ  単位時間人数増分
１３１１ｂ  閾値人数増分
１４００  視聴者端末表示画面例
１４０１  タイトル
１４０２  視聴時刻
１４０３  現在価格
１４０４  申し込み数
１４０５  備考
１４０６  選択部のハイライト
１４０７ａ、１４０７ｂ、１４０７ｃ  操作ガイダンス
１５０１  利用者数
１５０２  収入
１５０３  理想収入曲線
１５０４  購入確率を加味した収入曲線
１５０５  本実施の形態における収入見込み曲線
１６０１  対象者数
１６０２  購入確率
１６０３  購入確率曲線
１７００  ユーザ情報テーブル
１７０１  ユーザ名
１７０２  視聴端末
１７０２ａ  端末種別
１７０２ｂ  識別記号
１７０３  登録端末
１７０３ａ  端末種別
１７０３ｂ  識別記号
１７０４  備考
【図１】
2009200769.tif 000003
【図２】
2009200769.tif 000004
【図３】
2009200769.tif 000005
【図４】
2009200769.tif 000006
【図５】
2009200769.tif 000007
【図６】
2009200769.tif 000008
【図７】
2009200769.tif 000009
【図８】
2009200769.tif 000010
【図９】
2009200769.tif 000011
【図１０】
2009200769.tif 000012
【図１１】
2009200769.tif 000013
【図１２】
2009200769.tif 000014
【図１３】
2009200769.tif 000015
【図１４】
2009200769.tif 000016
【図１５】
2009200769.tif 000017
【図１６】
2009200769.tif 000018
【図１７】
2009200769.tif 000019
【図１８】
2009200769.tif 000020
【図１９】
2009200769.tif 000021