JP2001283015A - コンテンツデータ配信システムおよび方法 - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】複数のコンテンツデータ配信手段からユーザが
自己に適した希望するコンテンツデータ配信手段を容易
に選択することができ、かつコンテンツ配信事業者にと
ってもトラブルを回避することができるコンテンツデー
タ配信システムを提供する。 【解決手段】コンテンツ管理サーバとユーザ端末からの
要求に応じてコンテンツデータのダウンロードを行う複
数の配信サーバおよび流通経路伝達サーバを備え、コン
テンツ管理サーバは、ユーザ端末からのダウンロード要
求に応じる条件と配信サーバの稼動状況を参照して現況
のコンテンツ供給能力との比較を行って、設定した条件
でユーザ端末にコンテンツデータを供給する能力のある
配信サーバを特定し、該配信サーバからの配信に要する
課金情報を含む流通経路情報を流通経路伝達サーバとユ
ーザ端末とに送信し、ユーザ端末はその中から自己に適
した経路を選択し流通経路伝達サーバに送信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、音楽データあるい
は映像データなどのコンテンツデータを配信（供給）す
るシステムに関する。

【０００２】

【従来の技術】インターネットを利用した配信システム
において、ユーザはその端末から配信サイト（コンテン
ツ配信サーバ上でも、ラインセンス課金サーバ上でも、
他のサーバ上でもよい。）にアクセスし、コンテンツ・
リストからコンテンツデータとそのフォーマット（圧縮
形式など）を選択する。ユーザが購入を選択すると、ユ
ーザ端末はライセンス・課金サーバにリンクし、支払い
手続きを開始する。支払い手続きとは、通常 支払い方法の選択 支払い能力の調査（決済機関データベースへの問い合
わせ） 支払いの確定 の順番で行われる。支払い手続きが終わると、ライセン
スサーバはコンテンツデータの暗号化を解くキーをユー
ザに送信する。ライセンスサーバはこの後決済機関との
間で決済手続きを行い、配信料金を権利者に分配する。
キーを得たユーザ端末はコンテンツ配信サーバに接続
し、コンテンツデータの受信を行う。

【０００３】尚、ライセンス・課金サーバ，コンテンツ
配信サーバはキー及びコンテンツデータの送信履歴をコ
ンテンツホルダに報告する。

【０００４】特開平11−312175号公報には、インターネ
ット及び専用回線を利用して音楽配信をする技術が開示
されている。

【０００５】

【発明が解決しようとする課題】（１）オンデマンド型
の配信 （ア）ユーザの要求に応じて配信を行うもの。インター
ネットを利用したものや電話回線を直接的に利用したも
のなど、方式は色々であるが、基本的には１対１の通信
方式である。有料配信システムではコンテンツ暗号化さ
れ、それを解くキーは通常ライセンスサーバと呼ばれる
Web サーバから支払い手続きを経てダウンロードされ
る。

【０００６】（イ）長所 ユーザは居ながらにしてオンデマンドでコンテンツデ
ータを受信できる。 コンテンツホルダ側ではパッケージ生産がないため、
初期コストが比較的安価である。

【０００７】（ウ）短所 現状では電話回線が伝送路として一般的だが、受信時
間がかかり、ユーザのコスト負担が大きい。 ダウンロード回数が多い場合、サーバの過負荷やネッ
トワークのトラフィックの問題を引き起こし、結局、受
信時間が更にかかることになる。ユーザの待ち時間が増
加するとコンテンツホルダのビジネスチャンスが減少す
る虞がある。 （２）マルチキャスト型配信 （ア）インターネット上で特定の複数ユーザ（登録ユー
ザ）に向かってあるコンテンツデータを同時に配信して
１対多の通信を実現する方式である。有料配信システム
ではコンテンツは暗号化され、それを解くキーは通常ラ
イセンスサーバと呼ばれるWebサーバから有料でダウン
ロードされる。

【０００８】（イ）長所 多数のユーザに同時にコンテンツ配信ができるため、
ユーザ端末での受信回数が多い場合比較的コストパフォ
ーマンスが良い。 配信頻度（配信間隔）が高ければ、ユーザの待ち時間
が比較的少ない。

【０００９】（ウ）短所 現状では電話回線が伝送路として一般的だが、ユーザ
端末での受信に時間がかかり、ユーザの待ち時間が長
い。 配信頻度が高すぎる場合、ルータの負担が増し、関係
するネットワークのパフォーマンスが下がる。受信する
ユーザ端末が少ないと、コストパフォーマンスが悪い。 配信頻度（配信間隔）が低い場合、ユーザの待ち時間
が長い。

【００１０】（３）ブロードキャスト型配信 （ア）コンテンツデータを暗号化してＣＳデータ放送な
どで配信し、受信装置で受信する形態を指す。有料配信
システムではコンテンツデータは暗号化され、それを解
くキーは通常ライセンスサーバと呼ばれるWeb サーバか
ら有料でダウンロードされる。

【００１１】（イ）長所 多数のユーザに同時にコンテンツ配信ができるため、
ユーザ端末での受信回数が多い場合、コストパフォーマ
ンスが良い。 配信頻度が高ければ、ユーザの待ち時間が少ない。

【００１２】（ウ）短所 配信頻度（配信間隔）が高い場合、受信するユーザ端
末が少ないと、コストパフォーマンスが悪い。 配信頻度（配信間隔）が低い場合、ユーザの待ち時間
が長い。

【００１３】（４）パッケージ型 （ア）ＣＤ等に代表される形態。今回はパッケージの通
信販売を主に想定する。

【００１４】（イ）長所 大量に生産する場合には、オンデマンド型，ブロード
キャスト型に比べてユーザ負担コスト，コンテンツホル
ダの負担コストが少ない。 長時間のもの（アルバムなど）に適している。

【００１５】（ウ）短所 製造，流通に時間がかかる。 売れ残るとコンテンツホルダ側の負担が大きい。

【００１６】本発明は、前述のように長所，短所のある
複数のコンテンツ配信手段からユーザがコンテンツデー
タの配信を受ける場合に、自己に適した希望するコンテ
ンツ配信手段を容易に選択することができ、かつコンテ
ンツ配信事業者にとってもトラブルを回避することがで
きるコンテンツ配信システムを提供することを目的とす
る。

【００１７】

【課題を解決するための手段】本発明では、コンテンツ
データ毎の流通経路や配信スケジュールをユーザ端末と
コンテンツ管理サーバとで共有するための「流通経路情
報」を定義し、ユーザ端末側でこの情報を利用して様々
な配信サーバへリンクできるアプリケーション、或いは
ホームページ上のスクリプト或いは装置を用意し、ユー
ザに配布する。

【００１８】配信しようとするコンテンツデータは、オ
ンデマンド型配信サーバ，マルチキャスト型配信サー
バ、及びブロードキャスト型配信サーバにアップロード
され、マルチキャスト型とブロードキャスト型配信シス
テムの配信頻度を初期値に設定（初期値はコンテンツ毎
に変えても良い）する。

【００１９】ユーザはコンテンツリストからコンテンツ
データとフォーマットを選択し、購入を決定する。

【００２０】ユーザ端末上で購入を確定すると、ユーザ
端末は暗号を解くキーのダウンロードに移る。ダウンロ
ードはライセンス課金サーバから行われる。支払い方法
はクレジットカード，プリペイドカードなど様々である
が、キーのダウンロード時に支払い条件を調査し、ＯＫ
であればキーをダウンロードさせる。ライセンス課金サ
ーバはコンテンツ管理サーバにキーのダウンロード要求
が発生したことを伝える。

【００２１】コンテンツ管理サーバはその時点でのそれ
ぞれの配信サーバの指定されたコンテンツの供給能力と
キーのダウンロード要求回数を比較し、オンデマンド型
サーバの増減（オンデマンド配信サイトの増減）、マル
チキャスト型，ブロードキャスト型サーバの配信頻度の
増減を行い、そのコンテンツの流通経路情報を更新す
る。この流通経路の更新はキーのダウンロード毎、或い
は決められた回数毎、或いは決められた時間毎に行うも
のとする。流通経路の更新は数式等により自動的に頻度
を変えても、手動で行っても良い。流通経路の更新は即
座に上記の「流通経路情報」に反映させる。

【００２２】ユーザ端末側ではキーのダウンロードに引
き続き、流通経路情報のダウンロードが行われる。ユー
ザは意図するか、もしくは自動選択により適当な流通経
路を選択し、ダウンロードを開始する。

【００２３】オンデマンド型を選択した場合は即座にコ
ンテンツのダウンロードに移る。

【００２４】マルチキャスト型，ブロードキャスト型を
選択した場合、受信待機状態の後、スケジュールによっ
て知らされた配信開始時刻にダウンロードを開始する。

【００２５】本発明は、コンテンツデータ配信システム
において、複数の配信手段（インターネットによる配信
（オンデマンド型およびマルチキャスト型），ＣＳデー
タ放送（ブロードキャスト型）及び通信販売（パッケー
ジ型））を備え、ユーザが希望する配信手段によりコン
テンツデータを配信することができることを特徴として
いる。

【００２６】本発明のコンテンツデータ配信システム
は、コンテンツ管理サーバを備えており、コンテンツ管
理サーバが、各配信手段の供給能力に関する流通経路情
報をユーザ端末に提供する。ユーザ端末は、流通経路情
報を参照して、コンテンツデータを購入するのに適した
（短いダウンロード時間，低コスト等の）配信手段を選
択することができる。

【００２７】本発明は、具体的には次に掲げる装置を提
供する。

【００２８】本発明は、コンテンツデータおよび権利者
情報を蓄積したコンテンツ管理サーバを介してユーザ端
末にユーザからの要求に従ってコンテンツデータを配信
するコンテンツデータ配信システムにおいて、前記コン
テンツ管理サーバとユーザ端末との間にコンテンツデー
タの配信の要求があったときにコンテンツデータの配信
を行う複数の配信サーバおよび流通経路伝達サーバを備
え、前記コンテンツ管理サーバは、ユーザ端末からの配
信要求に応じる条件と前記配信サーバの稼動状況を参照
して現況のコンテンツ供給能力との比較を行って、設定
した条件でユーザ端末にコンテンツデータを供給する能
力のある配信サーバを特定し、かつ特定された配信サー
バと該配信サーバからの配信に要する課金とからなる流
通経路情報を流通経路伝達サーバとユーザ端末とに送信
し、ユーザ端末から確定された流通経路情報が前記流通
経路伝達サーバに送信されるコンテンツデータ配信シス
テムを提供する。

【００２９】本発明は、更に複数の配信サーバは、複数
のオンデマンド型配信サーバ、またはオンデマンド型配
信サーバとマルチキャスト型配信サーバ、またはオンデ
マンド型配信サーバとブロードキャスト型配信サーバ、
またはこれらの３種類の配信サーバの組み合わせからな
るコンテンツデータ配信システムを提供する。

【００３０】本発明は、更に前記流通経路伝達サーバ
は、ユーザ端末へのコンテンツデータの配信受信の確認
を待って決済処理を行うコンテンツデータ配信システム
を提供する。

【００３１】本発明は、コンテンツデータおよび権利者
情報を蓄積したコンテンツ管理サーバを介してユーザ端
末にユーザからの要求に従ってコンテンツデータを配信
するコンテンツデータ配信方法において、コンテンツ管
理サーバとユーザ端末との間の複数の配信サーバの稼動
状況を参照して現況のコンテンツ供給能力からユーザ端
末からの要求に応じる条件を設定し、設定した条件でユ
ーザ端末にコンテンツデータを供給する能力のある配信
サーバを特定せしめ、かつ特定された配信サーバと該配
信サーバからの配信に要する課金とからなる流通経路情
報をユーザ端末に送信するコンテンツデータ配信方法を
提供する。

【００３２】本発明は、更に複数の配信サーバは、複数
のオンデマンド型配信サーバ、またはオンデマンド型配
信サーバとマルチキャスト型配信サーバ、またはオンデ
マンド型配信サーバとブロードキャスト型配信サーバ、
またはこれらの３種類の配信サーバの組み合わせからな
るコンテンツデータ配信方法を提供する。

【００３３】

【発明の実施の形態】以下、本発明にかかる実施例を図
面に基づいて説明する。

【００３４】図１は、本発明の実施例にかかるブロック
図である。図において、コンテンツ管理サーバ１にはコ
ンテンツホルダ２から提供されたコンテンツデータおよ
びそのコンテンツデータの権利者の登録３がなされる。
コンテンツ管理サーバ１は、コンテンツ・ストレージ４
およびマスターデータベース（ＤＢ）５を備え、マスタ
ーＤＢ５には権利者情報並びにユーザ情報が蓄積され
る。コンテンツ管理サーバ１は、イントラまたはインタ
ーネットなどの通信網６を介してオンデマンド配信サー
バ７，マルチキャスト型配信サーバ８，ブロードキャス
ト型配信サーバ９，流通経路伝達サーバ１０，ライセン
ス・課金サーバ１１およびパッケージ通販サーバ１２に
接続される。オンデマンド配信サーバ７，マルチキャス
ト型配信サーバ８，流通経路伝達サーバ１０およびライ
センス・課金サーバ１１はインターネット１３を介して
ユーザ（利用者）のユーザ端末１４に接続される。ブロ
ードキャスト型配信サーバ９は衛星およびパラボラ衛星
放送受信装置からなる衛星放送網１５を介してユーザ端
末１４に接続される。パッケージ通販サーバ１２は、ト
ラックなどの運搬手段１６によってユーザ端末１４に接
続される。

【００３５】このようなコンテンツデータ配信システム
において、コンテンツデータおよび権利者情報を登録・
蓄積したコンテンツ管理サーバ１を介してユーザ端末１
４にユーザからの要求に従ってコンテンツデータが配信
される。

【００３６】ユーザからコンテンツ配信の要求があった
時に、統計されたその要求の大きさによってオンデマン
ド配信サーバ７に対してコンテンツアップロード配信サ
イト変更（追加，削除等）１７がなされ、マルチキャス
ト型配信サーバ８に対してコンテンツアップロード配信
スケジュール変更１８がなされ、ブロードキャスト型配
信サーバ９に対してコンテンツ配信スケジュール変更１
９がなされる。

【００３７】コンテンツ管理サーバ１から流通経路サー
バ１０に対して流通経路・配信スケジュールの伝達２０
がなされ、ライセンス・課金サーバ１１に対してキーの
登録・キーのダウンロード状況の調査指令２１がなされ
る。

【００３８】前述したように、コンテンツデータ配信シ
ステムは、複数の配信手段を備える。すなわち、コンテ
ンツデータ配信システムは、インターネットによる配信
手段（オンデマンド型およびマルチキャスト型），ＣＳ
データ放送手段（ブロードキャスト型）及び通信販売手
段（パッケージ型）を備え、ユーザが希望する配信手段
によりコンテンツデータの配信を受けることができる。
複数のオンデマンド型、またはオンデマンド型とマルチ
キャスト型、またはオンデマンド型とブロードキャスト
型、または３種類の配信手段を組み合わせてユーザ端末
１４にコンテンツデータを配信することができる。パッ
ケージ通販手段を組み合わせてもよい。

【００３９】コンテンツデータ配信システムは、前述の
ようにコンテンツ管理サーバ１を備えており、コンテン
ツ管理サーバ１が各配信手段の供給能力に関する流通経
路情報を流通経路伝達サーバ１０を介してユーザ端末１
４に提供する。ユーザは、ユーザ端末１４を介して提供
された流通経路情報を参照して、コンテンツデータを購
入するのに適した配信手段を短いダウンロード時間，低
コスト等の条件を考慮して選択することができる。

【００４０】このコンテンツデータ配信システムによれ
ば、コンテンツデータ配信事業者は、回線の過負荷を招
くこと、配信に長時間を要すること等のトラブルを回避
して安定したコンテンツデータのユーザへの提供が可能
になる。また、ユーザも、自分の都合に合わせて最適な
配信手段を選択することができ、これによってダウンロ
ードの長時間化，回線使用料の増加等の不満が無くコン
テンツデータを入手することができることになる。

【００４１】流通経路の変更は、各配信手段のコンテン
ツ配信能力に加えて、条件に対応した課金のグラフも考
慮して計算される。

【００４２】コンテンツデータ配信システムを介してユ
ーザに提供されるサービス情報は、基本サービスおよび
アドバンスト・サービスとに分けられそれらの内容は以
下に示すようなものとなる。

【００４３】このサービスがユーザに提供するサービス
情報は次の通りである。 ［基本サービス］ １．コンテンツ・リスト コンテンツデータのタイトル名，アーティスト名，静止
画像などからなるデータベースを閲覧できるもの。 ２．流通手段の情報 （ア）オンデマンド配信サイトのＩＰアドレス（複数
個） （イ）マルチキャスト型配信のＩＰアドレス、及び配信
スケジュール （ウ）ブロードキャスト用配信チャンネル情報、及び配
信スケジュール （エ）上記流通手段を用いた場合の受信完了までの時間
の予測値など ［アドバンスト・サービス］様々な配信方式のコンテン
ツデータのダウンロード情報（どのコンテンツデータが
いつ，誰に，どのような手段で伝送されたか、という情
報）を統合的に管理する。即ち、ユーザを識別する識別
子（会員制とし、UserIDを発行する），コンテンツデー
タを識別する識別子（ContentIDとする），流通手段を
識別する識別子（MediaIDとする）などをデータベース
として管理し、ユーザのコンテンツ購入のたびにＤＢを
更新していくシステムの構築する。このデータベースを
利用することにより、下記のサービスが実現可能とな
る。 １．ユーザの趣味・嗜好をデータとして把握できるた
め、宣伝用のダイレクトメールや、E-mailの自動発信が
可能。 ２．キャッシュバックサービス（電子マネー，ウェブ
（Web）マネーなどによる）。

【００４４】（ア）コンテンツデータを購入したユーザ
に対して、次の別のコンテンツデータ購入時にキャッシ
ュバックするサービスが可能。キャッシュバックはＤＢ
に反映させる。

【００４５】（イ）あるコンテンツデータ（シングル盤
のようなもの）を購入したユーザに対して、そのコンテ
ンツデータを含むコンテンツデータ集合（アルバム）の
購入の際にキャッシュバックする。（このサービスによ
りシングル楽曲購入層にアルバム購入を促す）。

【００４６】（ウ）あるコンテンツデータを購入したユ
ーザに対して、そのコンテンツデータを異なるフォーマ
ットで購入する際にキャッシュバックする。

【００４７】配信に加えてパッケージ通販型を組み合わ
せるとより多様なサービスが実現できる。この場合、パ
ッケージ通販のデリバリ情報（費用，納期など）を前記
の「経路伝達手段」に掲載する。パッケージ通販が選択
された場合、通常のインターネット通販ルーチンに移行
する。 １．パッケージ購入したユーザに対して安価、或いは無
料でデリバリまでの期間限定の配信楽曲を配布するサー
ビス。 ２．新譜のパッケージ予約をしたユーザに対して安価、
或いは無料で発売までの期間限定のスタジオ流出楽曲
（フルコーラスでなくともよい）を配布するサービス。

【００４８】図２にユーザ端末，ライセンス課金サー
バ，流通経路伝達サーバ及びコンテンツ管理サーバの動
作を示すフローチャートを示す。ユーザは、コンテンツ
データの購入を決定（Ｓ１）すると、ユーザ端末１４か
ら流通経路情報の検索を行う（Ｓ２）。流通経路情報の
受信（Ｓ３）をして、ユーザが好みの流通経路を選択
（Ｓ４）し、選択した流通経路の通知（Ｓ５）を行う。
次いで、コンテンツデータの暗号を復号するためのキー
受信をし、各コンテンツ配信サーバからコンテンツデー
タを受信（Ｓ７）し、コンテンツ受信完了通知（Ｓ８）
を行って終了する（Ｓ９）。

【００４９】ライセンス・課金サーバは、流通経路を流
通経路通知（Ｓ５）ステップによって受信（Ｓ１１）
し、コンテンツ管理サーバへ流通経路を通知する(Ｓ１
２)。次いで、キー送信（Ｓ１３）する。ステップＳ６
でキー受信する。コンテンツ受信完了通知ステップ（Ｓ
８）から完了通知を受けて支払い手続を終了（Ｓ１４）
し、決済機関との間で決済処理（Ｓ１５）を行い、ステ
ップＳ１１〜Ｓ１５を繰り返す。

【００５０】流通経路伝達サーバは、流通経路情報の検
索ステップＳ２から検索を受け、流通経路情報の提供を
行う流通経路情報サービス（Ｓ２１）を行う。このサー
ビスに当っては、すべての流通経路について、それぞれ
のダウンロード或いはデリバリ終了までの予想待ち時
間，予想通信費及びコンテンツのクオリティ（圧縮方
式，転送レート）などの条件が伝達される。

【００５１】コンテンツ管理サーバは、各コンテンツ配
信サーバの状況監視（コンテンツ供給の際の予想時間，
予想コスト，コンテンツのクオリティなどの取得）(Ｓ
３１)を行い、ステップＳ１２のコンテンツ管理サーバ
への流通経路の通知を受けてキーのダウンロード回数積
算（単位時間あたり）（Ｓ３２）を行い、流通経路の変
更および流通経路情報更新（Ｓ３３）を行い、その結果
をステップ２１の流通経路情報サービスに伝える。

【００５２】上述したフローチャートに示す手順の他
に、コンテンツデータの受信と支払い手続きの順序が逆
の場合もある。

【００５３】支払い条件は、クレジットカード，ビット
キャッシュやウェブマネーのようなプリペイドカード方
式によるものが多いと考えられるが、銀行振込の後に、
Ｅ−Ｍailでキーを配布するケースであってもよい。

【００５４】図３は、ユーザのコンテンツ購入決定のル
ーチンを示すフローチャートである。

【００５５】ユーザは、Web サイトでの楽曲検索（Ｓ４
１）し、購入曲決定（Ｓ４２）する。流通経路情報の取
得（Ｓ４３）を行う。すべての流通経路について、それ
ぞれのダウンロード或いはデリバリ終了までの予想待ち
時間，予想通信費及びコンテンツデータのクオリティ
（圧縮方式，転送レート）などがディスプレイされる。
好みの流通経路を選択（Ｓ４４）し、オンデマンド選択
するか？（Ｓ４５）を判定する。「はい」の場合、キー
受信（Ｓ４６）し、ダウンロードサイトに接続(Ｓ４７)
し、コンテンツデータの受信（Ｓ４８）をし、コンテン
ツ受信完了通知（Ｓ４９）して終了する(Ｓ５０)。ステ
ップ４５で「いいえ」の場合は、マルチキャスト選択(Ｓ
５１)を判定し、「はい」の場合は、キーおよびマルチキ
ャストＩＰ・アドレスを受信(Ｓ５２)する。コンテンツ
配信開始？（Ｓ５３）を判定し、「はい」の場合、ステ
ップ４８に移行してコンテンツデータの受信を行う。
「いいえ」の場合はステップＳ５３を繰り返す。

【００５６】ステップＳ５１で「いいえ」の場合は、ブロ
ードキャスト選択？(Ｓ５４)を判定し、「はい」の場
合、キーおよびブロードキャストチャンネル識別子など
の受信(Ｓ５５)を行い、コンテンツ配信開始？(Ｓ５６)
を判定する。「はい」の場合、ステップ４８に移行してコ
ンテンツデータの受信を行う。「いいえ」の場合は、ステ
ップＳ５６を繰り返す。ステップＳ５４で「いいえ」の
場合は、パッケージ通販選択？（Ｓ５７）を判定し、
「はい」の場合、通販ルーチンへ移行(Ｓ５８)する。
「いいえ」の場合は、その他固有のルーチンへ移行する
（Ｓ５９）。

【００５７】図４は、流通経路情報更新の方法を示すフ
ローチャート図であり、流通経路がオンデマンド型配信
とマルチキャスト型配信の２通りの場合で、マルチキャ
スト型配信での配信頻度の変更がない例を示す。

【００５８】時刻Ａを基準にして前側にサイクルｎ−
１，サイクルｎ−２そして後側にサイクルｎ，サイクル
ｎ＋１，サイクルｎ＋２を想定する。

【００５９】流通経路変更プログラムをスタートさせ、
サイクル（ｎ−１）と（ｎ−２）のトータルダウンロー
ド回数ＲＴからサイクル（ｎ＋１）のトータルダウンロ
ード要求の予測値ＥＴ（ｎ＋１）を求め（Ｓ６１）、サ
イクル（ｎ−１）でマルチキャスト型配信しているか？
（Ｓ６２）を判定する。「いいえ」の場合は、前記予測
値ＥＴ（ｎ＋１）がオンデマンド型配信用閾値ＴｈＤを
超えるか？（Ｓ６３）を判定する。「はい」の場合、サ
イクル（ｎ＋１）のマルチキャスト型配信リストに空き
があるか？（Ｓ６４）を判定する。「はい」の場合、サ
イクル（ｎ＋１）のマルチキャスト型配信リストにこの
コンテンツデータを加え（Ｓ６５）、サイクル（ｎ＋
１）の流通経路情報を更新（Ｓ６６）し、流通経路変更
終了（Ｓ６７）し、次のサイクルに移行する。ステップ
Ｓ６３あるいはステップＳ６４で「いいえ」の場合は、
直ちにステップＳ６６に移行する。

【００６０】ステップＳ６２で「はい」の場合、 if マルチキャスト型配信のダウンロード数ＲＭ（ｎ−
２）＝０，マルチキャスト型配信のダウンロード要求の
予測値ＥＭ（ｎ＋１）＝ＲＭ（ｎ−１） else ＥＭ(ｎ＋１)＝ＲＭ(ｎ−１)＋２＊（ＲＭ(ｎ−
１)−ＲＭ(ｎ−２)） の条件式から、サイクル（ｎ−１）と（ｎ−２）のマル
チキャスト型配信によるダウンロード数（受信数）ＲＭ
（ｎ−１），ＲＭ（ｎ−２）からサイクル（ｎ＋１）の
マルチキャスト型配信受信数の予測値ＥＭ（ｎ＋１）を
求め（Ｓ６８）、前記予測値ＥＭ（ｎ＋１）がマルチキ
ャスト用閾値ＴｈＭを超えるか？（Ｓ６９）を判定す
る。「いいえ」の場合は、サイクル（ｎ＋１）のマルチ
キャスト型配信リストからこのコンテンツを削除する
（Ｓ７０）。そして、ステップＳ６６に移行する。「は
い」の場合、直ちにステップＳ６６に移行する。

【００６１】マルチキャスト型配信サーバは１サイクル
中に配信リストに登録されたコンテンツデータを全て、
決められたスケジュールで配信するものとする。

【００６２】マルチキャスト型配信リストの例は のようである。このケースではコンテンツ番号の重複は
許されない。

【００６３】ダウンロード要求の予測値は過去の複数サ
イクルの実測値から予測する。予測方法は色々考えられ
るが、この例では最も単純な過去の２サイクルから予測
を行っている。

【００６４】図の時刻Ａで、サイクル（ｎ−２）とサイ
クル（ｎ−１）期間のトータルダウンロード回数（ＲＴ
（ｎ−２）とＲＴ（ｎ−１））からサイクル（ｎ＋１）
期間のトータルダウンロード要求の予測値ＥＴ（ｎ＋
１）を予測する。 ＥＴ（ｎ＋１）＝ＲＴ(ｎ−１）＋２＊(ＲＴ（ｎ−１）
−ＲＴ（ｎ−２）)

【００６５】予測値とある閾値を比較し、サイクル（ｎ
＋１）期間のマルチキャスト型配信リストを更新する
（即ちサイクル（ｎ＋１）の配信スケジュールを確定す
る）。

【００６６】サイクル（ｎ＋１）を更新するのは、ｎ期
間のマルチキャスト型配信スケジュールは時刻Ａ以前に
ユーザ端末に伝達されているからである。

【００６７】尚、閾値はオンデマンド型サーバが過負荷
になる値でよい。

【００６８】図５は、流通経路情報更新の方法を示すフ
ローチャート図であり、流通経路がオンデマンド型配信
とマルチキャスト型配信の２通りの場合で、マルチキャ
スト型配信での配信頻度の変更がある例を示す。

【００６９】ｎサイクル中のマルチキャスト型配信の配
信回数をＨｍ（ｎ）とする。

【００７０】流通経路変更プログラムをスタートさせ、
サイクル（ｎ−１）と（ｎ−２）のトータルダウンロー
ド回数ＲＴからサイクル（ｎ＋１）のトータルダウンロ
ード要求の予測値ＥＴ（ｎ＋１）を求め（Ｓ７１）、サ
イクル（ｎ−１）でマルチキャスト型配信しているか？
（Ｓ７２）を判定する。「いいえ」の場合は、ＥＴ（ｎ
＋１）がオンデマンド型配信用閾値ＴｈＤを超えている
か？（Ｓ７３）を判定する。「はい」の場合、サイクル
（ｎ＋１）のマルチキャスト型配信リストに空きがある
か？（Ｓ７４）を判定する。「はい」の場合、Ｈｍ（ｎ
＋１）＝１（Ｓ７５）とし、次サイクルの流通経路情報
の更新（Ｓ７６）を行い、流通経路変更を終了（Ｓ７
７）して次サイクルへ移行する。ステップＳ７３，Ｓ７
４で「いいえ」の場合は、直ちにステップＳ７６に移行
する。

【００７１】ステップＳ７２で「はい」の場合、ＥＴ
（ｎ＋１）が閾値ＴｈＤを超えるか？（Ｓ７８）を判定
する。「はい」の場合、 if ＲＭ（ｎ−２）＝０ ＥＭ（ｎ＋１）＝ＲＭ（ｎ−
１） else ＥＭ（ｎ＋１）＝ＲＭ(ｎ−１)＋２＊（ＲＭ(ｎ
−１)−ＲＭ(ｎ−２)） の条件式から、サイクル（ｎ−１）と（ｎ−２）のマル
チキャスト型配信によるダウンロード数（受信数）ＲＭ
（ｎ−１），ＲＭ（ｎ−２）からサイクル（ｎ＋１）の
マルチキャスト型配信受信数の予測値ＥＭ（ｎ＋１）を
求め（Ｓ７９）、ＥＭ（ｎ＋１）とマルチキャスト閾値
ＴｈＭとＨｍ（ｎ−１）の積（即ちＴｈＭ・Ｈｍ（ｎ−
１）を比較（Ｓ８０）する。ＥＭ（ｎ＋１）ＴｈＭ・Ｈ
ｍ（ｎ−１）の場合、次サイクル（ｎ＋１）のマルチキ
ャスト型配信リストに空きがあるか？（Ｓ８１）を判定
する。「はい」の場合、Ｈｍ（ｎ＋１）＝Ｈｍ（ｎ−
１）＋１（Ｓ８２）として、ステップＳ７６に移行す
る。ステップＳ８０でＥＭ（ｎ＋１）＝ＴｈＭ・Ｈｍ
（ｎ−１）の場合、もしくはステップＳ８１で「いい
え」の場合は、Ｈｍ（ｎ＋１）＝Ｈｍ（ｎ−１）（Ｓ８
３）として、ステップ７６に移行する。ステップ８０で
ＥＭ（ｎ＋１）≪ＴｈＮ・Ｈｍ（ｎ−１）の場合は、Ｈ
ｍ（ｎ＋１）＝Ｈｍ（ｎ−１）−１（Ｓ８４）としてス
テップＳ７６に移行する。

【００７２】上述のケースではマルチキャスト型配信リ
スト中のコンテンツ番号の重複を許し、コンテンツ配信
の頻度を変えることができる。

【００７３】閾値ＴｈＤはオンデマンド型配信サーバの
過負荷と判断されるダウンロード要求数でよい。

【００７４】閾値ＴｈＭは１度のマルチキャスト型配信
で十分収益のあがるマルチキャスト型配信の受信者数で
ある。

【００７５】図６は、流通経路情報更新の方法を示すフ
ローチャート図であり、流通経路がオンデマンド型配信
とマルチキャスト型配信とブロードキャスト型配信の３
通りの場合でマルチキャスト型配信，ブロードキャスト
型配信での配信頻度の変更がない例を示す。

【００７６】流通経路プログラムをスタートさせ、サイ
クル（ｎ−１）と（ｎ−２）のトータルダウンロード回
数ＲＴからサイクル（ｎ＋１）のトータルダウンロード
要求の予測値ＥＴ（ｎ＋１）を求め（Ｓ９１）、サイク
ル（ｎ−１）でマルチキャスト型配信しているか？（Ｓ
９２）を判定する。「いいえ」の場合は、前記予測値Ｅ
Ｔ（ｎ＋１）がオンデマンド型配信用閾値ＴｈＤを超え
るか？（Ｓ９３）を判定する。

【００７７】「はい」の場合、サイクル（ｎ＋１）のマ
ルチキャスト型配信リストに空きがあるか？（Ｓ９４）
を判定する。「はい」の場合、サイクル（ｎ＋１）のマ
ルチキャスト型配信リストにこのコンテンツデータを加
え（Ｓ９５）、ステップＳ９９（後述）に移行する。ス
テップＳ９３，ステップＳ９４で「いいえ」の場合は、
直ちにステップＳ９９に移行する。

【００７８】ステップＳ９２で「はい」の場合、サイク
ル（ｎ−１）と（ｎ−２）とのマルチキャストによるダ
ウンロード数（受信数）ＲＭ（ｎ−１），ＲＭ（ｎ−
２）からサイクル（ｎ＋１）のマルチキャスト型配信の
受信数の予測値ＥＭ（ｎ＋１）を求め（Ｓ９６）、前記
予測値ＥＭ（ｎ＋１）がマルチキャスト型配信用閾値Ｔ
ｈＭを超えるか？（Ｓ９７）を判定する。「いいえ」の
場合は、サイクル（ｎ＋１）のマルチキャスト型配信リ
ストからこのコンテンツを削除（Ｓ９８）する。ステッ
プＳ９７で「はい」の場合、直ちにステップＳ９９に移
行する。

【００７９】ステップＳ９９では、サイクル（ｎ−１）
でブロードキャスト型配信しているか？を判定する。
「いいえ」の場合、前記予測値ＥＴ（ｎ＋１）がオンデ
マンド用閾値ＴｈＤを超えるか？（Ｓ１００）を判定す
る。「はい」の場合、サイクル（ｎ＋１）のブロードキ
ャスト型配信リストに空きがあるか？（Ｓ１０１）を判
定する。「はい」の場合、サイクル（ｎ＋１）のブロー
ドキャスト型配信リストにこのコンデンツを加える（Ｓ
１０２）。そして、サイクル（ｎ＋１）の流通経路情報
を更新（Ｓ１０３）し、流通経路変更を終了（Ｓ１０
４）し、次サイクルへ移行する。ステップＳ１００，ス
テップＳ１０１で「いいえ」の場合は、直ちにステップ
Ｓ１０３に移行する。

【００８０】ステップＳ９９で「はい」の場合、 if ブロードキャスト型配信によるダウンロード数ＲＢ
（ｎ−２）＝０， ブロードキャスト型配信の予測値ＥＢ（ｎ＋１）＝ＲＢ
（ｎ−１） else ＥＢ(ｎ＋１)＝ＲＢ(ｎ−１)＋２＊（ＲＢ(ｎ−
１)−ＲＢ(ｎ−２)） の条件式から、サイクル（ｎ−１）と（ｎ−２）のブロ
ードキャスト型配信によるダウンロード数（受信数）Ｒ
Ｂ（（ｎ−１）），ＲＢ（ｎ−２）からサイクル（ｎ＋
１）のブロードキャスト型配信の受信数の予測値ＥＢ
（ｎ＋１）を求め（Ｓ１０５）、前記予測値ＥＢ（ｎ＋
１）がブロードキャスト用閾値ＴｈＢを超えるか？（Ｓ
１０６）を判定する。「いいえ」の場合は、サイクル
（ｎ＋１）のブロードキャスト型配信リストからこのコ
ンテンツデータを削除し（Ｓ１０７）し、ステップＳ１
０３に移行する。ステップＳ１０６で「はい」の場合、
直ちにステップＳ１０３に移行する。

【００８１】図７は、ユーザに提示される流通経路情報
をコンテンツ配信システムのシミュレーションによって
示す。

【００８２】（条件） １．図４，図５に対応するオンデマンド型とマルチキャ
スト型の２通りの流通経路の場合を考える。 ２．１０分でダウンロード可能なコンテンツをオンデマ
ンド型とマルチキャスト型の２通りで配信すると仮定す
る。 ３．マルチキャスト型配信実行時には２４０分に１回の
配信を行い、ダウンロード時間は１０分とする。 ４．予想通信費は流通経路伝達サーバがユーザが契約し
ているプロバイダ、及び回線（キャリア）業者のＤＢ
（データベース）に問い合わせることにより、取得でき
ると仮定する。（通信費は回線使用料とプロバイダ料金
を併せて３分当り１０円（端数切上）で計算。）

【００８３】尚、図５に示す例の場合、マルチキャスト
型配信のスケジュールがわかっている場合、配信時間に
合わせて回線を接続すれば良い。

【００８４】図８は、ユーザに提示される流通経路情報
をコンテンツ型配信システムのシミュレーションによっ
て示す。この例の場合は、コンテンツデータのクオリテ
ィもパラメータとしている。（クオリティもパラメータ
とした場合）

【００８５】（条件） １．図４，図５に対応するオンデマンド型とマルチキャ
スト型の２通りの流通経路の場合を考える。 ２．ひとつのコンテンツにつき２種類のクオリティＡ，
Ｂを用意し、クオリティＡはクオリティＢの倍のデータ
量を使用すると仮定する。例えば楽曲であればクオリテ
ィＡはＣＤ並の音質が得られ、クオリティＢはＦＭ放送
並の音質であると仮定する。 ３．オンデマンド型とマルチキャスト型の２通りで配信
すると仮定する。 ４．オンデマンド型配信ではサーバや回線がビジーでな
いとき、クオリティＡでは１０分、クオリティＢでは５
分の通信時間がかかると仮定する。 ５．マルチキャスト型配信実行時には２４０分に１回ク
オリティＡとＢ２種類の配信を行い、それぞれのダウン
ロード時間は１０分，５分とする。 ６．予想通信費は流通経路伝達サーバがユーザが契約し
ているプロバイダ、及び回線（キャリア）業者のＤＢに
問い合わせることにより、取得できると仮定する。通信
費は回線使用料とプロバイダ料金を併せて３分当り１０
円（端数切上）で計算する。

【００８６】図９は、他のシミュレーション例を示す。

【００８７】（条件） １．図６に対応するオンデマンド型配信とマルチキャス
ト型配信とブロードキャスト型配信の３通りの流通経路
の場合を考える。（オンデマンド型配信，マルチキャス
ト型配信の通信費は回線使用料とプロバイダ料金を併せ
て３分当り１０円（端数切上）で計算。） ２．インターネット経由では１０分、データ放送経由で
は１分ではダウンロード可能なコンテンツデータをオン
デマンド型とマルチキャスト型とブロードキャスト型の
３通りで配信すると仮定する。 ３．マルチキャスト型配信実行時には２４０分に１回の
配信を行い、ダウンロード時間は１０分とする。 ４．ブロードキャスト型配信実行時には４８０分に１回
の配信を行い、ダウンロード時間は１分とする。放送受
信料は１分当たり１０円と仮定。 ５．放送以外の予想通信費は流通経路伝達サーバがユー
ザが契約しているプロバイダ、及び回線（キャリア）業
者のＤＢに問い合わせることにより、取得できると仮定
する。

【００８８】尚、図９の例の場合は、マルチキャスト型
配信のスケジュールがわかっている場合、配信時間に合
わせて回線を接続しなおせば良い。また、ブロードキャ
スト型配信のスケジュールがわかっている場合、キーの
取得後、回線を閉じて良い。

【００８９】

【発明の効果】以上のように、本発明によればユーザが
希望する配信手段によるコンテンツデータを配信するこ
とができ、ユーザ端末から流通経路情報を参照して、コ
ンテンツデータを購入するのに適した配信手段を選択す
ることができる。また、自己の都合に合わせて最適と考
える配信手段を選択することができるため、従来あった
配信時の不満が無く、コンテンツデータを入手すること
ができる。

【００９０】また、コンテンツデータ配信事業者は、回
線の過負荷，配信の長時間化等のトラブルを回避して安
定してコンテンツデータをユーザに供給することができ
るメリットがある。

【図面の簡単な説明】

【図１】本発明の実施例を示すブロック図。

【図２】ユーザー端末，ライセンス課金サーバ，流通経
路伝達サーバ及びコンテンツ管理サーバの動作を示すフ
ローチャート図。

【図３】ユーザのコンテンツ購入決定のルーチンを示す
フローチャート図。

【図４】流通経路情報更新の方法を示すフローチャート
（１）図。

【図５】流通経路情報更新の方法を示すフローチャート
（２）図。

【図６】流通経路情報更新の方法を示すフローチャート
（３）図。

【図７】コンテンツ配信システムのシミュレーション
図。

【図８】コンテンツ配信システムの他のシミュレーショ
ン図。

【図９】コンテンツ配信システムの他のシミュレーショ
ン図。

【符号の説明】

１…コンテンツ管理サーバ、２…コンテンツホルダ、３
…コンテンツ・権利者登録、４…コンテンツストレー
ジ、５…マスターＤＢ、６…イントラまたはインターネ
ットなどの通信網、７…オンデマンド配信サーバ、８…
マルチキャスト型配信サーバ、９…ブロードキャスト型
配信サーバ、１０…流通経路伝達サーバ、１１…ライセ
ンス・課金サーバ、１２…パッケージ通販サーバ、１３
…インターネット、１４…ユーザ端末、１５…衛星放送
網。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 15/00 ３１０ Ｇ０６Ｆ 15/00 ３１０Ａ ３１０Ｄ

Claims (5)

【特許請求の範囲】
1. 【請求項１】コンテンツデータおよび権利者情報を蓄積
   したコンテンツ管理サーバを介してユーザ端末にユーザ
   からの要求に従ってコンテンツデータを配信するコンテ
   ンツデータ配信システムにおいて、 前記コンテンツ管理サーバとユーザ端末との間にコンテ
   ンツデータ配信の要求があったときにコンテンツデータ
   の配信を行う複数の配信サーバおよび流通経路伝達サー
   バを備え、 前記コンテンツ管理サーバは、ユーザ端末からの配信要
   求に応じる条件と前記配信サーバの稼動状況を参照して
   現況のコンテンツ供給能力との比較を行って、設定した
   条件でユーザ端末にコンテンツデータを供給する能力の
   ある配信サーバを特定し、かつ特定された配信サーバと
   該配信サーバからの配信に要する課金とからなる流通経
   路情報を流通経路伝達サーバとユーザ端末とに送信し、 ユーザ端末から確定された流通経路情報が前記流通経路
   伝達サーバに送信されることを特徴とするコンテンツデ
   ータ配信システム。
2. 【請求項２】請求項１において、 複数の配信サーバは、複数のオンデマンド型配信サー
   バ、またはオンデマンド型配信サーバとマルチキャスト
   型配信サーバ、またはオンデマンド型配信サーバとブロ
   ードキャスト型配信サーバ、またはこれらの３種類の配
   信サーバの組み合わせからなることを特徴とするコンテ
   ンツデータ配信システム。
3. 【請求項３】請求項１または２において、 前記流通経路伝達サーバは、ユーザ端末へのコンテンツ
   データの配信受信の確認を待って決済処理を行うことを
   特徴とするコンテンツデータ配信システム。
4. 【請求項４】コンテンツデータおよび権利者情報を蓄積
   したコンテンツ管理サーバを介してユーザ端末にユーザ
   からの要求に従ってコンテンツデータを配信するコンテ
   ンツデータ配信方法において、 コンテンツ管理サーバとユーザ端末との間の複数の配信
   サーバの稼動状況を参照して現況のコンテンツ供給能力
   からユーザ端末からの要求に応じる条件を設定し、設定
   した条件でユーザ端末にコンテンツデータを供給する能
   力のある配信サーバを特定せしめ、かつ特定された配信
   サーバと該配信サーバからの配信に要する課金とからな
   る流通経路情報をユーザ端末に送信することを特徴とす
   るコンテンツデータ配信方法。
5. 【請求項５】請求項４において、 複数の配信サーバは、複数のオンデマンド型配信サー
   バ、またはオンデマンド型配信サーバとマルチキャスト
   型配信サーバ、またはオンデマンド型配信サーバとブロ
   ードキャスト型配信サーバ、またはこれらの３種類の配
   信サーバの組み合わせからなることを特徴とするコンテ
   ンツデータ配信方法。