(57)【要約】【課題】  広告入り番組をクライアントシステムにダウンロードして配信する番組配信システムにおいて、配信日時に合わせた広告を挿入された番組の配信ができなかった。また、ひとつの番組に指定された複数の広告からランダムに選択されたか、または指定の割合により選択された広告が結合されたものを配信して、ひとつの番組にも複数の広告主がつくような仕組みは無かった。【解決手段】  クライアントからのダウンロード要求に対して、ダウンロード要求ファイルを意図的に存在させずエラーを発生させ、そのエラーを検知してプログラムを起動させ、リアルタイムに広告入り番組を生成してクライアントに配信したりあらかじめ、作成しておいたファイルの中からランダムに選択して配信することにより課題を解決した。【選択図】図１０
2007299196.tif 000002
【特許請求の範囲】
【請求項１】
広告入り番組を保存する広告入り番組保存手段と前記広告入り番組を配信する広告入り番組配信手段とを有する配信サーバシステムから、番組視聴手段によりネットワークを介して前記広告入り番組をダウンロードして前記広告入り番組を視聴する番組配信システムであって、
前記番組を保存する番組保存手段と、
前記広告を保存する広告保存手段と、
前記保存された番組及び広告を選択的に結合して広告入り番組を作成する番組広告結合手段と
を備えたことを特徴とする番組配信システム。
【請求項２】
請求項１の番組配信システムにおいて、
前記番組広告結合手段は、１ないしは複数の番組と１ないしは複数の広告の中から、所定の番組と所定の広告を組合わせる組合わせ指示表に従い、前記所定の番組と前記所定の広告を結合する
ことを特徴とする番組配信システム。
【請求項３】
請求項１または請求項２の何れかの番組配信システムにおいて、
前記番組広告結合手段は、前記広告入り番組の配信時刻に応じた前記組合わせ指示表に従い、前記所定の番組と前記所定の広告を結合する
ことを特徴とする番組配信システム。
【請求項４】
請求項１から請求項３の何れかの番組配信システムにおいて、
前記番組広告結合手段は、前記番組にあらかじめ挿入されている無音部分に前記広告を差し替えて結合する
ことを特徴とする番組配信システム。
【請求項５】
請求項１から請求項４の何れかの番組配信システムにおいて、
前記配信サーバシステムへのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）に記載されているファイルへのダウンロードが要求された際に、
前記配信サーバシステム上に前記ＵＲＩ記載のファイルを存在させず、意図的に前記配信サーバシステムに前記ファイルが存在しない旨のエラーを生じさせ、
その前記ファイルが存在しない旨のエラーを前記配信サーバシステムが検知して、所定のファイルを前記配信サーバシステムからクライアントに送信する
ことを特徴とする番組配信システム。
【請求項６】
請求項５の番組配信システムにおいて、
前記配信サーバシステムへのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）に記載されているファイルへのダウンロードが要求された際に、
前記配信サーバシステム上に前記ＵＲＩ記載の前記ファイルを存在させず、意図的に前記配信サーバシステムに前記ファイルが存在しない旨のエラーを生じさせ、
その前記ファイルが存在しない旨のエラーを前記配信サーバシステムが検知して、前記配信サーバシステムから前記クライアントに送信する前記所定のファイルが、異なる前記広告を結合された複数の異なる前記広告入り番組のファイルからランダムに選択されたひとつのファイルである
ことを特徴とする番組配信システム。
【請求項７】
請求項１から請求項６の何れかの番組配信システムにおいて、
前記広告入り番組配信手段は、前記広告入り番組に含まれる前記広告がどの時間帯にどの番組と結合されて何回配信されたかを記録する、広告配信記録手段を持つ
ことを特徴とする番組配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上のサーバクライアントシステムによる番組配信に関し、特に番組に広告を挿入する方法に関する。
【背景技術】
【０００２】
従来、ネットワークを通して音声番組や映像番組を配信する方法があるが、それら番組中に広告を挿入して配信し、広告主に課金する方法があった。特にストリーミング再生を用いて、閲覧を希望するコンテンツをユーザに複数選択させて、該選択に従うコンテンツ連続送信要求に基づいて、広告コンテンツの再生項目を含む再生リストを作成し、ユーザに広告コンテンツを違和感無く提供する方法があった（特許文献１参照）。
【０００３】
最近、ポッドキャストによる音声配信など、ストリーミングによる配信方法と異なり一つのファイルをクライアントにダウンロードさせて、クライアントがコンピュータや移動端末などに一旦取り込んで視聴する番組の配信方法が盛んになってきた。この方法の場合、上記のストリーミングのように番組ごとや広告ごとに異なるファイルに分かれているものを再生リストに従って連続的にユーザに配信することはできず、あらかじめ番組と広告を結合したひとつの広告入り番組ファイルを作成しておかないと、ユーザに広告の入った番組を配信することはできない。しかし、広告には適時性があり、期間限定のキャンペーンの告知広告では、キャンペーン期間が終わればその広告の告知の意味は無くなる。また、一般のテレビジョン放送における広告がその放送時間に最も多く視聴する対象の年齢層、性別をターゲットにして選択されるのと同様に、ネット配信の番組でもダウンロード時間による視聴ターゲット層が異なるので、視聴層に合わせた広告の配信が必要である。しかし、これまで配信日時に合わせた広告を挿入する番組の配信システムは無かった。
【０００４】
また、ひとつの番組に指定された複数の広告からランダムに選択されたか、または指定の割合により選択された広告が結合されたものを配信して、ひとつの番組にも複数の広告主がつくような仕組みは無かった。
【０００５】
【特許文献１】特開２００４−１３５０７７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
解決しようとする問題点は、広告入り番組をサーバクライアントシステムを用いてユーザにダウンロードして配信する番組配信システムにおいて、配信日時に合わせた広告を挿入された番組の配信ができなかった点である。また、ひとつの番組に指定された複数の広告からランダムに選択されたか、または指定の割合により選択された広告が結合されたものを配信することにより、ひとつの番組でも複数の広告主がつくようにする仕組みが無かった点である。
【課題を解決するための手段】
【０００７】
本発明は、番組配信システムにおいて、広告入り番組を保存する広告入り番組保存手段と前記広告入り番組を配信する広告入り番組配信手段とを有する配信サーバシステムから、番組視聴手段によりネットワークを介して前記広告入り番組をダウンロードして前記広告入り番組を視聴する番組配信システムであって、前記番組を保存する番組保存手段と、前記広告を保存する広告保存手段と、前記保存された番組及び広告を選択的に結合して広告入り番組を作成する番組広告結合手段とを備えたことを最も主要な特徴とする。
【０００８】
また、前記配信サーバシステムへのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）に記載されているファイルへのダウンロードが要求された際に、前記配信サーバシステム上に前記ＵＲＩ記載のファイルを存在させず、意図的に前記配信サーバシステムに前記ファイルが存在しない旨のエラーを生じさせ、その前記ファイルが存在しない旨のエラーを前記配信サーバシステムが検知して、所定のファイルを前記配信サーバシステムからクライアントに送信することを特徴とする。
【０００９】
また、前記広告入り番組配信手段は、前記広告入り番組に含まれる前記広告がどの時間帯にどの番組と結合されて何回配信されたかを記録する、広告配信記録手段を持つことを特徴とする。
【発明の効果】
【００１０】
本発明は、番組配信システムにおいて、広告入り番組を保存する広告入り番組保存手段と前記広告入り番組を配信する広告入り番組配信手段とを有する配信サーバシステムから、番組視聴手段によりネットワークを介して前記広告入り番組をダウンロードして前記広告入り番組を視聴する番組配信システムであって、前記番組を保存する番組保存手段と、前記広告を保存する広告保存手段と、前記保存された番組及び広告を選択的に結合して広告入り番組を作成する番組広告結合手段とを備えたことを最も主要な特徴とするため、配信日時にあわせた広告入りの番組を配信することが可能となった。
【００１１】
また、前記配信サーバシステムへのＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）に記載されているファイルへのダウンロードが要求された際に、前記配信サーバシステム上に前記ＵＲＩ記載のファイルを存在させず、意図的に前記配信サーバシステムに前記ファイルが存在しない旨のエラーを生じさせ、その前記ファイルが存在しない旨のエラーを前記配信サーバシステムが検知して、所定のファイルを前記配信サーバシステムからクライアントに送信することを特徴とするため、クライアントからの固定ファイルへのダウンロード要求を配信サーバでの動的なファイルの送信という処理に替えることが可能となったので、ひとつの番組に指定された複数の広告からランダムに選択されたか、または指定の割合により選択された広告が結合されたものを配信して、ひとつの番組にも複数の広告主がつくような仕組みを実現することができた。
【００１２】
また、前記広告入り番組配信手段は、前記広告入り番組に含まれる前記広告がどの時間帯にどの番組と結合されて何回配信されたかを記録する、広告配信記録手段を持つことを特徴とするため、広告配信情報と広告課金情報を得ることが可能となった。
【発明を実施するための最良の形態】
【００１３】
広告入り番組をクライアントシステムにダウンロードして配信する番組配信システムにおいて、配信日時に合わせた広告を番組に挿入するために、番組と広告を配信前に結合して作成する方法により実現した。
【実施例１】
【００１４】
本発明の実施例として、インターネットを通じての音声配信を実現する番組配信システムであって、特にポッドキャストに対応したＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）通信方式でのダウンロード型の音声番組配信システムの実施例について説明する。
【００１５】
［ネットワーク構成］
図１に本実施例のネットワーク構成図を示す。
【００１６】
インターネット５０１を通して、クライアントコンピュータである多数のクライアントＰＣ（４０１〜４０７）が、ラジオ放送局のウェブサーバ１０１とポッドキャストウェブサーバ２０１と配信サーバシステム３９９の内のウェブサーバであるＣＭサーバ３０１（広告サーバ）とが接続されている。
【００１７】
配信サーバシステム３９９は、前記ＣＭサーバ３０１とＣＭバンクサーバ３５１から構成されており、ＣＭバンクサーバ３５１は、ＣＭサーバ３０１とローカルなネットワークで接続されており、ＣＭバンクサーバ３５１は、インターネット５０１と直接に接続されてはいない。
【００１８】
ＣＭバンクサーバには、番組と広告がデータベース中に登録されており、所定の指示に従い、前記番組と前記広告を結合して広告入り番組ファイルを作成し、ＣＭサーバ３０１がアクセスできるディレクトリ上にファイルを保存する。
【００１９】
クライアントＰＣのユーザは、視聴を行いたい番組を作成しているラジオ放送局のウェブサーバ１０１にブラウザプログラムでアクセスしたり、ポッドキャストウェブサーバ２０１にＲＳＳ対応の音楽管理ソフトプログラム（例えばｉＴｕｎｅｓ）でアクセスしたりする。
【００２０】
ポッドキャストウェブサーバとは、ポッドキャスト対応番組を紹介するポータルサイトを稼動しているウェブサーバのことであり、例えば、前記ポータルサイトの例としてＡｐｐｌｅ（登録商標）社のｉＴｕｎｅｓ  Ｍｕｓｉｃ  Ｓｔｏｒｅなどがある。
【００２１】
ポッドキャストウェブサーバには、例えば配信希望の広告入り番組のＲＳＳファイルへのリンクが載せられている。そしてそのリンク先は、ＣＭサーバ３０１のウェブサーバとなっている。
【００２２】
まず、クライアントブラウザから放送局ウェブサーバを経由した配信方法については、以下のように行われる。
【００２３】
クライアントＰＣ  Ａ４０１が番組作成者であるラジオ放送局のウェブサーバ１０１にブラウザプログラムでアクセスすると、インターネットで配信可能な番組のリストがリンクとして掲載されている。実際の番組は、ＣＭサーバ３０１上にあり、前記番組のリスト上のリンクをクライアントＰＣ  Ａ４０１のブラウザ上で選択することにより、クライアントＰＣ  Ａ４０１より、ＣＭサーバ３０１上の前記選択された番組のダウンロード要求が発生し、ダウンロード要求を受けたＣＭサーバ３０１がクライアントＰＣ  Ａ４０１に前記番組を送信する。
【００２４】
次に、クライアントのＲＳＳ対応の音楽管理ソフトプログラムから、ポッドキャストウェブサーバを経由した配信方法については、以下のように行われる。
【００２５】
クライアントＰＣ  Ａ４０１がＲＳＳ対応の音楽管理ソフトプログラムを立ち上げると、前記ブラウザと同様に放送番組のリストがＲＳＳ対応の音楽管理ソフトプログラム上に表示さる。
【００２６】
また、事前の設定により新規に配信された番組があるか確認するように指定することができるが、その場合ＲＳＳ対応の音楽管理ソフトが立ち上がると、新規番組確認に指定してあるポッドキャスト番組に新規のファイルがないかどうかを確認するために、ＲＳＳ対応の音楽管理ソフトがＣＭサーバ３０１上のＲＳＳファイルをダウンロードして、クライアントＰＣ  Ａ４０１のローカルにダウンロードされている番組との比較を行う。新規の番組が有る場合は、クライアントＰＣ  Ａ４０１より、ＣＭサーバ３０１上の前記新規の番組のダウンロード要求が発生し、ダウンロード要求を受けたＣＭサーバ３０１がクライアントＰＣ  Ａ４０１に前記新規の番組を送信する。
【００２７】
上記に述べた方法でクライアントＰＣ（クライアントコンピュータ）は、番組をＣＭサーバからダウンロードし、クライアントＰＣに搭載されている音声再生プログラムやマルチメディア再生プログラム（例えばＲＳＳ対応の音楽管理ソフト）などにより、ダンロードされた番組を視聴することができる（番組視聴手段）。
【００２８】
［ＣＭサーバの構成］
配信サーバシステムの内のウェブサーバであるＣＭサーバ３０１の内部構成を図２に示す。
【００２９】
ＣＭサーバ３０１には、ウェブサーバのＨＴＭＬ上に記述した、スクリプト言語ＰＨＰ（Ｈｙｐｅｒｔｅｘｔ  Ｐｒｅｐｒｏｃｅｓｓｏｒ）を処理するＰＨＰプログラム３０３、通常のＨＴＴＰ標準ポート番号である８０番ポートを使用するウェブサーバである、ａｐａｃｈｅ（その１）３０５、音声番組ファイルであるＭＰ３のダウンロード処理専用に用いられる、８０番以外のポート番号を使用するウェブサーバである、ａｐａｃｈｅ（その２）３０７、がＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）３０９の上で動作している。ＯＳ３０９としては、ＦｒｅｅＢＳＤまたはＬｉｎｕｘで稼動させることができる。
【００３０】
ａｐａｃｈｅ（その１）３０５及びａｐａｃｈｅ（その２）３０７は、広告入り番組をユーザに配信する広告入り番組配信手段を有する。
【００３１】
［ＣＭバンクサーバの構成］
配信サーバシステムの内の番組と広告を保持し、番組と広告を結合する機能を持つＣＭバンクサーバ３５１の構成について図３に示す。
【００３２】
ＣＭバンクサーバ３５１は、ＤＢサーバ３５３を有する。
【００３３】
また、広告ファイルを保存するＣＭファイル保存ディレクトリ３５５を有する（広告保存手段）。
【００３４】
また、番組ファイルを保存する番組ファイル保存ディレクトリ３５７を有する（番組保存手段）。
【００３５】
また、視聴者からのダウンロード要求があると、前記広告ファイルと番組ファイルを結合してリアルタイムに広告入り番組を作成する番組リアル生成機能３９１を有する（番組広告結合手段）。
【００３６】
また、所定の時間になると起動して、前記広告ファイルと番組ファイルを結合して広告入り番組を作成してストックしておく番組ストック生成機能３８１を有する（番組広告結合手段）。
【００３７】
また、前記番組リアル生成機能３９１や前記番組ストック生成機能３８１で作成された前記広告入り番組を保存しておくダウンロードディレクトリ３５９を有する（広告入り番組保存手段）。
【００３８】
［ＣＭバンクサーバにおける広告入り番組作成の仕組み］
ＣＭバンクサーバの動作について、図４を用いてより詳細に説明する。
【００３９】
ＭＰ３フォーマットの番組ファイル１．ｍｐ３（９０１）及び、ＭＰ３フォーマットの広告ファイルである、ＣＭファイル１．ｍｐ３（９０３）をＣＭバンクサーバに接続されるブラウザプログラム３９０を用いて登録する。
【００４０】
登録する際には、番組マスタ登録機能３７１を用いてＣＭバンクサーバ３５１上のデータベース（ＤＢ）３５３の上に番組マスタテーブル３６１を作成する。
【００４１】
番組の内容の変更及び更新は、番組マスタ更新機能３７２を用いて同じく前記番組マスタテーブル３６１の内容を更新する。
【００４２】
番組ファイル１．ｍｐ３（９０１）は、番組ファイル登録機能３７３により、ファイルが分割されて分割ファイルへのポインタを持つ番組ファイル１．ＩＤ３（９０１Ａ）、と分割された音声ファイルである番組ファイル１−１．ｍｐ３（９０１Ｂ）、番組ファイル１−２．ｍｐ３（９０１Ｃ）、番組ファイル１−３．ｍｐ３（９０１Ｄ）に分割され、番組ファイル保存ディレクトリ３５７に出力される。
【００４３】
放送局などの番組制作者が番組を制作するときには、図５Ａに示すように、あらかじめ番組のどこでコマーシャルを入れるかの個所を決めて、その部分に無音部分を挿入して番組ファイルが作成される。
【００４４】
前記番組ファイル登録機能３７３は、この無音部分を検知して、ファイルを図５Ｂに示すように、無音部分を除いた番組ファイル１−１．ｍｐ３、番組ファイル１−２．ｍｐ３、番組ファイル１−３．ｍｐ３の３つに分割する。
【００４５】
分割されたファイルは、後にＣＭと結合されて図５Ｃに示す、ＣＭ入り番組ファイル１．ｍｐ３が作成される（結合に関しては詳細後述）。
【００４６】
番組ファイル保存ディレクトリ３５７に保存された分割された番組ファイルの情報は、番組ファイル登録機能３７３及び番組ファイル更新機能３７４により、データベース３５３中の番組単位テーブル３６２、番組ファイル管理テーブル３６３に書き込まれる。
【００４７】
ＣＭファイル１．ｍｐ３（９０３）は、ブラウザ３９０を通して、ＣＭファイル登録機能３７５により、ＣＭファイル保存ディレクトリ３５５に保存され、その情報をデータベース３５３中のＣＭファイル管理テーブル３６４に記録される。
【００４８】
ＣＭファイルの内容の変更及び更新は、ＣＭファイル更新機能３７６を用いて同じく前記ＣＭファイル管理テーブル３６４の内容を更新する。
【００４９】
これらの更新情報は、ＣＭのダウンロード回数を管理して、広告主に対する広告ダウンロードの回数や時間帯、組み合わされた番組などの情報を記録する広告配信記録手段であるＣＭダウンロードテーブル３６５にも記録される。
【００５０】
［番組ストック生成機能］
図６及び図７を用いて番組ストック生成機能について説明する。
【００５１】
広告ファイルと番組ファイルを結合して広告入り番組ファイルを作成する処理をダウンロード要求が来るたびに行うのではなく、あらかじめ広告入り番組ファイルを作成しておく機能を番組ストック生成機能と呼ぶ。
【００５２】
図６はＣＭバンクサーバの番組ストック生成機能に関した機能ブロック図である。ＣＭバンクサーバ３５１は、番組ストック生成機能３８１を備えており、この機能は、ｃｒｏｎ３８３による起動で処理が開始され、番組ストック生成機能処理の設定を記述してある組合わせ指示表である設定ファイル３８５、番組ストック生成機能動作の記録をとる動作ログファイル３８７、番組ストック生成機能動作中にエラーが発生した際の記録をとるエラーログファイル３８９、生成した広告入り番組ファイルをダウンロードしておくためのダウンロードディレクトリ３５９からなる。
【００５３】
次に図７のフローチャートを用いて番組ストック生成機能の動作の流れについて説明する。
【００５４】
ｃｒｏｎ３８３により指定した時間（本実施例の場合は１５分毎）毎に番組ストック生成が開始される。
【００５５】
Ｓ１１で、番組単位テーブル３６２から、公開可能条件が整っている番組を探し出し、その番組番号及び放送番号を取得する。各番組には配信開始日時が指定されており、番組が配信開始日時を過ぎていれば公開可能条件が整っているとみなす。
【００５６】
Ｓ１３で、番組ファイル管理テーブル３６３から前ステップのＳ１１で取得した番組番号及び放送番号を基に、ファイル分割後の枝番号、ファイルパスを取得する。この情報を取得したことにより、番組ファイル保存ディレクトリ３５７の中から、分割された番組ファイルのセット（例えば９０１Ａ〜９０１Ｄ）を探し出すことができる。
【００５７】
Ｓ１５で、ＣＭファイル管理テーブル３６４及びＣＭダウンロードテーブル３６５から、使用可能なＣＭファイル情報を取得する。本ステップによりＣＭファイル保存ディレクトリ３５５の中から指定されたＣＭファイル（例えばＣＭファイル１．ｍｐ３；９０３）を探し出すことができる。
【００５８】
Ｓ１７で、前記Ｓ１３で得た情報を基に番組ファイルを取得。
【００５９】
Ｓ１９で、前記Ｓ１５で得た情報を基にＣＭファイルを取得。
【００６０】
Ｓ２１で、前記Ｓ１７で得た番組ファイルと前記Ｓ１９で得たＣＭファイルを結合して広告入り番組ファイル９５１を生成する。生成した広告入り番組ファイルは、ａｐａｃｈｅサーバがアクセスできる、ダウンロードディレクトリ３５９に保存されるが、ダウンロードディレクトリ３５９は、４つの異なるディレクトリＤＬディレクトリ（０）、ＤＬディレクトリ（１）、ＤＬディレクトリ（２）、ＤＬディレクトリ（３）から構成されており、ダウンロードされる時刻が００〜１４分台の場合は、ＤＬディレクトリ（０）の中の広告入り番組ファイルがダウンロードされ、以下同様に１５〜２９分台はＤＬディレクトリ（１）、３０〜４４分台はＤＬディレクトリ（２）、４５〜５９分台はＤＬディレクトリ（３）となっているため、設定に応じて、指定のディレクトリに広告入り番組ファイルを保存する。
【００６１】
以上により、ストック生成機能の動作は終了する。
【００６２】
［番組リアル生成機能］
図８及び図９を用いて番組リアル生成機能について説明する。
【００６３】
広告ファイルと番組ファイルを結合して広告入り番組ファイルを作成する処理をダウンロード要求が来るたびに行うことも可能となっている。しかし結合には処理時間がかかるため、すべてのダウンロード要求に対して常にリアルタイムに結合処理を行ってしまっていては、サーバがすぐに処理限界に陥ってしまうので、本実施例では、リアルタイム生成とストック生成のハイブリッド方式とした。
【００６４】
図８に番組リアル生成機能の機能ブロック図を示す。
【００６５】
ＣＭバンクサーバ３５１は、データベース３５３を有する。
【００６６】
また、ＣＭバンクサーバ３５１は、番組リアル生成機能３９１を持ち、組合わせ指示表である設定ファイル３９５に従い、番組リアル生成機能を実行する。実行の動作は、動作ログファイル３９７に記録され、動作中にエラーが発生した際には、エラーログファイル３９８に記録される。生成された広告入り番組ファイルは、ａｐａｃｈｅサーバを通して、クライアントに送信されると同時にダウンロードディレクトリ３５９に保存される。
【００６７】
次に図９のフローチャートを用いて、番組リアル生成機能の動作の流れについて説明する。
【００６８】
クライアントからのダウンロード要求をＣＭサーバ中のａｐａｃｈｅサーバが受け取り、ＣＭバンクサーバ３５１にダウンロード要求を引き渡す。ダウンロード要求がａｐａｃｈｅから来たことにより動作が開始する。
【００６９】
まず、Ｓ３１で番組マスタテーブル及び番組単位テーブルからダウンロード要求ファイル名を基に番組番号と番組単位テーブルの公開日を取得する。
【００７０】
次に、Ｓ３３でダウンロード要求された番組の放送番号が指定回数世代（本実施例では２世代前）より新しいかどうかの判断が行われる。
【００７１】
ダウンロード要求されたファイルが指定世代より古い場合は、Ｓ５１に動作を移行し、リアル生成が行われる。
【００７２】
ダウンロード要求されたファイルが指定世代より新しい場合は、Ｓ７１に動作を移行し、ストック生成が行われる。
【００７３】
これは、ポッドキャスト配信においては、番組をひいきにして新番組が配信されると毎回ダウンロードする視聴者がかなり多いために、最新番組や、最新から一回分前の番組へのダウンロード要求回数が多いことが統計結果として出ている。よってこれら頻繁なリクエストのある最新番組については、要求回数が多いのでストック生成とすることにし、その他の古い番組についてはリアル生成を行うことにしても、要求回数が少ないのでサーバに異常な負荷をかけることがないという理由により上記の世代によるリアル生成とストック生成の振り分けを行った。
【００７４】
次にＳ５１からのリアル生成について説明する。
【００７５】
Ｓ５１で、ダウンロード要求ファイル名を基に番組ファイル管理テーブル３６３よりファイル分割後の枝番号及びファイルパスを取得する。
【００７６】
Ｓ５３で、ＣＭファイル管理テーブル３６４及びＣＭダウンロードテーブル３６５から使用可能なＣＭファイルの情報を取得する。
【００７７】
Ｓ５５で、番組ファイル保存ディレクトリ３５７から、番組ファイルを取得（例えば９０１Ａ〜９０１Ｄ）。
【００７８】
Ｓ５７で、ＣＭ保存ディレクトリ３５５から、ＣＭファイル（例えばＣＭファイル１．ｍｐ３；９０３）を取得。
【００７９】
Ｓ５９で、結合ルーチンを呼び出し、番組ファイルとＣＭファイルを結合して広告入り番組ファイル９５１を生成する。
【００８０】
Ｓ６１で、前記ステップで生成された広告入り番組ファイルをａｐａｃｈｅに渡してダウンロードさせる。
【００８１】
Ｓ６３で、ダウンロードに指定した番組ファイル名から放送番号及びＣＭ番号を取得し、それぞれ番組ダウンロードテーブル３６６及びＣＭダウンロードテーブル３６５のダウンロード数を追加する。
【００８２】
以上によりリアル生成の流れは終了する。
【００８３】
次に、Ｓ７１のストック生成の流れについて説明する。
【００８４】
Ｓ７１で、ダウンロード要求ファイル名を基に番組ファイル管理テーブル３６３よりファイル分割後の枝番号及びファイルパスを取得。
【００８５】
Ｓ７３で４つの異なるディレクトリで構成されているＤＬディレクトリ３５９の中から動作時刻に従って以下のようにディレクトリを指定する。時刻が００〜１４分台の場合は、ダウンロードディレクトリ（０）を指定。以下、１５〜２９分台はダウンロードディレクトリ（１）、３０〜４４分台はダウンロードディレクトリ（２）、４５〜５９分台はダウンロードディレクトリ（３）を指定して、その指定されたディレクトリの中にある、広告入り番組ファイルの中から一つをランダムに選択して取得する。
【００８６】
Ｓ７５で、前記取得された広告入り番組ファイルをａｐａｃｈｅに渡し、ダウンロードさせる。
【００８７】
Ｓ７７で、ダウンロードに指定した番組ファイル名から放送番号及びＣＭ番号を取得し、それぞれ番組ダウンロードテーブル３６６及びＣＭダウンロードテーブル３６５のダウンロード数を追加する。
【００８８】
以上により動作が終了する。
【００８９】
［ＣＭバンクサーバとＣＭサーバによるＣＭ差し替えの仕組み］
次に、ＣＭバンクサーバーとＣＭサーバによるＣＭ差し替えの仕組みについて説明する。
【００９０】
本実施例のバンクサーバでは、クライアントからのダウンロード要求ファイルが来たときに、その要求ファイルを該当のダウンロードディレクトリにおかず、ウェブサーバに意図的にファイルが無い旨の４０４エラーを生じさせ、生じたエラーをＣＭサーバのａｐａｃｈｅサーバが検知して、ＰＨＰプログラムによりダウンロードするファイルを選択してａｐａｃｈｅサーバに渡すことが可能となっている。
【００９１】
このため、サーバ側であらかじめ準備してある視聴者の指定した番組と、複数種類の異なる広告が結合された複数種類の広告入り番組ファイルからランダムに選択してファイルを返すことが可能となった。また、前記ランダムに選択するのではなく、ダウンロード時刻やクライアントのＩＰアドレスを基に割り出したユーザのターゲット層に適した広告の入った番組をダウンロードさせることが可能となった。
【００９２】
また、あらかじめ用意した広告入り番組を利用するのではなく、リアルタイムに前記ランダムに広告入り番組を配信したり、前記ターゲット層に適した広告が入っている番組を配信することも可能となった。これらの仕組みをＣＭ差し替えと呼ぶ。
【００９３】
以下に図１０のフローチャートを用いてＣＭ差し替えの仕組みの動作の流れについて説明する。
【００９４】
Ｓ８１で、クライアントは、ブラウザ画面を用いて番組を配信している例えばラジオ放送局のホームページから配信されている番組のリンクをクリックしてダウンロードを要求する。
【００９５】
また、クライアントはＳ８３で、ＲＳＳ対応の音楽管理ソフトを用いてＲＳＳ対応の音楽管理ソフトがポッドキャストサーバからリンクされているＲＳＳファイルを自動的に取得し、新しくアップロードされている番組ファイルがあれば、前記ＲＳＳ対応の音楽管理ソフトが前記新しくアップロードされている番組ファイルのダウンロードを開始する。
【００９６】
前記Ｓ８１及びＳ８３のダウンロードリクエストは、ＣＭサーバのａｐａｃｈｅ（その１）３０１が受け取る。ａｐａｃｈｅ（その１）は、ダウンロード要求が指定した音声ファイル（本実施例でのＭＰ３ファイル）以外であれば、そのままａｐａｃｈｅ（その１）がＨＴＴＰプロトコルを扱う通常のポート番号８０番を通して処理する。（Ｓ８５）
ダウンロード要求がＭＰ３ファイルの場合には、その指定ディレクトリよりダウンロード要求の指定ＭＰ３ファイルをダウンロードしようとするが、指定ディレクトリは意図的に空にしてある、そこでａｐａｃｈｅ（その１）サーバは４０４エラー（ファイルが存在しない）を生じさせ、その処理をＣＭサーバにあるもう一台のａｐａｃｈｅサーバａｐａｃｈｅ（その２）３０７にポート番号１００８０番（他の空きポート番号でも可能）を通して渡す。（Ｓ８７）
ＭＰ３ファイルのダウンロード要求を受け取ったａｐａｃｈｅ（その２）は、Ｓ９１で、再度ａｐａｃｈｅ（その１）の上記動作と同様に指定されたＭＰ３格納フォルダにダウンロード要求ＭＰ３ファイルがあるかどうかを確認しに行く。しかし、前記ＭＰ３格納フォルダは上述したように意図的にあらかじめ空にしてある。
【００９７】
Ｓ９３で、ａｐａｃｈｅ（その２）は、ダウンロード要求のあったＭＰ３ファイルが存在しなかったので、ファイルが存在しないエラー（４０４エラー）を発生する。
【００９８】
Ｓ９５で、エラーの発生時には、エラー処理がａｐａｃｈｅ動作ファイルであるｈｔｔｐｄ．ｃｏｎｆの記述に従うが、４０４エラーの際は、ＰＨＰで書かれているプログラムｉｎｄｅｘ．ｐｈｐが起動するように、ｈｔｔｐｄ．ｃｏｎｆに記述してあるため、Ｓ９７でｉｎｄｅｘ．ｐｈｐが起動する。
【００９９】
Ｓ９７では、ａｐａｃｈｅの環境変数（ＲＥＤＩＲＥＣＴ＿ＵＲＬ）によりクライアントのダウンロード要求のあったＭＰ３ファイル名を取得する。
【０１００】
次に、図８のフローチャートが起動し、フローチャートの流れに従ってダウンロードする広告入り番組ファイルが取得される。
【０１０１】
次に、視聴者側にダウンロードファイルを返すときのエラーの無いヘッダーファイルを作成する。Ｓ９３にて４０４エラーが発生したままにクライアントに返信するとヘッダー中に含まれる４０４エラーの情報を基に、クライアントが予期せぬ動作を行い、配信する広告入り番組を視聴できない可能性があるので、本ステップでエラーの無いヘッダーを作成する。
【０１０２】
次に、クライアントに広告入り番組を前記エラーの無いヘッダーと共に返す。
【０１０３】
ダウンロード数集計カウンタ（番組及びＣＭの両方）を加算する。
【０１０４】
以上により差し替えの一連の動作を終了する。
【０１０５】
なお、Ｓ８５におけるａｐａｃｈｅ（その１）のファイルが存在しない旨の４０４エラーの発生時の処理は、ＭＰ３番組ファイルの置かれているはず（意図的にファイルを置いていない）のディレクトリ内で発生したときにのみ、その処理をａｐａｃｈｅ（その２）サーバに移管するようになっており、それ以外のディレクトリで発生した４０４エラーについては、通常のエラー処理を行う。
【０１０６】
［実施例の効果］
本実施例により、クライアントからのＭＰ３ファイルの要求時に、サーバサイドであらかじめ指定した広告入り番組ファイルをクライアントに返すことが可能となった。
【０１０７】
広告入り番組ファイルは、ダウンロードの要求時にリアルタイムに作成することも可能であるし、あらかじめ作成してストックされたものから配信してもよい。
【０１０８】
上記の方法により、一つの番組の配信においても、複数種類の広告と結合された番組をクライアントに配信することができるようになったので、一つの番組に複数の広告主をつけることが可能となった。
【０１０９】
また、どの広告をどの割合で流すのか、またランダムに流すのかを配信システム側でコントロールが可能なので、広告主の希望にしたがった頻度で広告を配信することが可能となった。
【０１１０】
また、クライアントがダウンロードする時間帯により、配信する番組の広告を差し替えることが可能となったのでクライアントのターゲット層に応じたより効果の高い広告効果が得られることになった。
【０１１１】
クライアントがダウンロードする時間帯だけでなく、ＩＰアドレスに基づく、ターゲット層の絞込みや、より進んでクッキーを利用して顧客を認証することによる、より細かい広告対策が可能となった。
【０１１２】
本実施例のＣＭ差し替えの方法により、ＲＳＳ対応の音楽管理ソフトにおいて番組内容は同じだが、広告内容だけ変えてもＲＳＳ対応の音楽管理ソフトがすでにダウンロードした番組と同じと判断して、複数回の同番組の無駄なダウンロードの発生を妨げることが可能となった。
[その他]
本実施例では、ＭＰ３による音声番組についての説明を行ったが、ＭＰ３以外のフォーマットの音声番組でも実施可能である。また音声番組だけではなく、映像番組でも同様に実施可能である。
【０１１３】
本実施例では、ＣＭサーバとＣＭバンクサーバとの２台で配信サーバシステムを構成したが、これを一台のコンピュータで構成することも可能である。また、ＣＭサーバを複数台のコンピュータによる構成としたり、ＣＭバンクサーバを複数台のコンピュータで構成したりすることも可能である。
【０１１４】
本実施例では、ウェブサーバプログラムとしてａｐａｃｈｅを用いたが、他のウェブサーバプログラムでも同様に動作可能である。
【図面の簡単な説明】
【０１１５】
【図１】クライアントサーバの配信システムのネットワーク構成図である（実施例１）。
【図２】ＣＭサーバのブロック構成図である（実施例１）。
【図３】ＣＭバンクサーバの構成図である（実施例１）。
【図４】ＣＭバンクサーバのブラウザからの登録機能の機能ブロック図である（実施例１）。
【図５】番組ファイルの構造図と番組ファイルと広告ファイルの結合の概念図である（実施例１）。
【図６】ＣＭバンクサーバの番組ストック生成機能の機能ブロック図である（実施例１）。
【図７】ＣＭバンクサーバの番組ストック生成機能のフローチャートである（実施例１）。
【図８】ＣＭバンクサーバの番組リアル生成機能の機能ブロック図である（実施例１）。
【図９】ＣＭバンクサーバの番組リアル生成機能のフローチャートである（実施例１）。
【図１０】ＣＭバンクサーバのＣＭ差し替え機能のフローチャートである（実施例１）。
【符号の説明】
【０１１６】
３０１  ＣＭサーバ
３０３  ＰＨＰプログラム実行機能
３０５  ａｐａｃｈｅ（その１）（広告入り番組配信手段）
３０７  ａｐａｃｈｅ（その２）（広告入り番組配信手段）
３５１  ＣＭバンクサーバ
３５３  データベース
３５５  ＣＭファイル保存ディレクトリ（広告保存手段）
３５７  番組ファイル保存ディレクトリ（番組保存手段）
３５９  ダウンロードディレクトリ
３８１  番組ストック生成機能（番組広告結合手段）
３８５  ストック生成機能用設定ファイル（組合わせ指示表）
３９１  番組リアル生成機能（番組広告結合手段）
３９５  リアル生成機能用設定ファイル（組合わせ指示表）
９０１  番組ファイル
９０３  広告ファイル
９５１  広告入り番組ファイル
【図１】
2007299196.tif 000003
【図２】
2007299196.tif 000004
【図３】
2007299196.tif 000005
【図４】
2007299196.tif 000006
【図５】
2007299196.tif 000007
【図６】
2007299196.tif 000008
【図７】
2007299196.tif 000009
【図８】
2007299196.tif 000010
【図９】
2007299196.tif 000011
【図１０】
2007299196.tif 000012