(57)【要約】【課題】  多数のユーザ端末が大容量のコンテンツをダウンロードする場合であっても、通話、メール送信又はＷＥＢブラウジングのための回線容量を圧迫しないようにする。【解決手段】  サーバが、ユーザ端末にコンテンツのダウンロードをさせるためのメッセージを、ユーザ端末に送信するステップと、ユーザ端末が、メッセージを受信した時に、ユーザ端末が存在する場所の現在時刻がユーザ端末が存在する場所の特定時間帯に属しているか否かを判断するステップと、現在時刻が特定時間帯に属していると判断された場合にのみ、ユーザ端末が、コンテンツをダウンロードするステップと、を備える。【選択図】        図１３
2006260214.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツをサーバからユーザ端末に配信するためのコンテンツ配信方法であって、
前記サーバが、前記ユーザ端末に前記コンテンツのダウンロードをさせるためのメッセージを、前記ユーザ端末に送信するステップと、
前記ユーザ端末が、前記メッセージを受信した時に、前記ユーザ端末が存在する場所の現在時刻が前記ユーザ端末が存在する場所の特定時間帯に属しているか否かを判断するステップと、
前記現在時刻が前記特定時間帯に属していると判断された場合にのみ、前記ユーザ端末が、前記コンテンツをダウンロードするステップと、
を備えることを特徴とするコンテンツ配信方法。
【請求項２】
請求項１に記載のコンテンツ配信方法において、
前記ユーザ端末が、前記ユーザ端末が存在する場所のグリニッジ標準時に対する時差を取得するステップと、
前記ユーザ端末が、現在のグリニッジ標準時を取得するステップと、
前記ユーザ端末が、前記ユーザ端末が存在する場所のグリニッジ標準時に対する時差及び前記現在のグリニッジ標準時を基に、前記ユーザ端末が存在する場所の現在時刻を算出するステップと、
を備えることを特徴とするコンテンツ配信方法。
【請求項３】
請求項２に記載のコンテンツ配信方法において、
前記ユーザ端末が、前記ユーザ端末が存在する場所のグリニッジ標準時に対する時差を取得するステップは、
前記ユーザ端末が、前記ユーザ端末が存在する場所の国識別子を取得するステップと、
前記ユーザ端末が、前記国識別子に対応する、グリニッジ標準時に対する時差を取得するステップと、
を備えることを特徴とするコンテンツ配信方法。
【請求項４】
請求項２に記載のコンテンツ配信方法において、
前記ユーザ端末が、現在のグリニッジ標準時を取得するステップは、
前記ユーザ端末が、前記現在のグリニッジ標準時を伴うメッセージを前記サーバから取得するステップを備えることを特徴とするコンテンツ配信方法。
【請求項５】
請求項２に記載のコンテンツ配信方法において、
前記ユーザ端末が、現在のグリニッジ標準時を取得するステップは、
前記ユーザ端末が、内蔵するグリニッジ標準時を計測する時計から前記現在のグリニッジ標準時を取得するステップを備えることを特徴とするコンテンツ配信方法。
【請求項６】
請求項２に記載のコンテンツ配信方法において、
前記ユーザ端末が、現在のグリニッジ標準時を取得するステップは、
前記ユーザ端末が、ＧＰＳ端末から前記現在のグリニッジ標準時を取得するステップを備えることを特徴とするコンテンツ配信方法。
【請求項７】
コンテンツをサーバからユーザ端末に配信するためのコンテンツ配信方法において、
前記サーバが、前記ユーザ端末に前記コンテンツのダウンロードをさせるためのメッセージを、前記ユーザ端末に複数回送信するステップと、
前記ユーザ端末が、前記メッセージを受信する度に、前記ユーザ端末が存在する場所の現在時刻が前記ユーザ端末が存在する場所の特定時間帯に属していて、且つ、今回分の前記コンテンツをまだダウンロードしていないか否かを判断するステップと、
前記現在時刻が前記特定時間帯に属していて、且つ、今回分の前記コンテンツをまだダウンロードしていないと判断された場合にのみ、前記ユーザ端末が、前記コンテンツをダウンロードするステップと、
を備えることを特徴とするコンテンツ配信方法。
【請求項８】
請求項７に記載のコンテンツ配信方法において、
前記ユーザ端末が、前記ユーザ端末が存在する場所のグリニッジ標準時に対する時差を取得するステップと、
前記ユーザ端末が、現在のグリニッジ標準時を取得するステップと、
前記ユーザ端末が、前記ユーザ端末が存在する場所のグリニッジ標準時に対する時差及び前記現在のグリニッジ標準時を基に、前記ユーザ端末が存在する場所の現在時刻を算出するステップと、
を備えることを特徴とするコンテンツ配信方法。
【請求項９】
請求項８に記載のコンテンツ配信方法において、
前記ユーザ端末が、前記ユーザ端末が存在する場所のグリニッジ標準時に対する時差を取得するステップは、
前記ユーザ端末が、前記ユーザ端末が存在する場所の国識別子を取得するステップと、
前記ユーザ端末が、前記国識別子に対応する、グリニッジ標準時に対する時差を取得するステップと、
を備えることを特徴とするコンテンツ配信方法。
【請求項１０】
請求項８に記載のコンテンツ配信方法において、
前記ユーザ端末が、現在のグリニッジ標準時を取得するステップは、
前記ユーザ端末が、前記現在のグリニッジ標準時を伴うメッセージを前記サーバから取得するステップを備えることを特徴とするコンテンツ配信方法。
【請求項１１】
請求項８に記載のコンテンツ配信方法において、
前記ユーザ端末が、現在のグリニッジ標準時を取得するステップは、
前記ユーザ端末が、内蔵するグリニッジ標準時を計測する時計から前記現在のグリニッジ標準時を取得するステップを備えることを特徴とするコンテンツ配信方法。
【請求項１２】
請求項８に記載のコンテンツ配信方法において、
前記ユーザ端末が、現在のグリニッジ標準時を取得するステップは、
前記ユーザ端末が、ＧＰＳ端末から前記現在のグリニッジ標準時を取得するステップを備えることを特徴とするコンテンツ配信方法。
【請求項１３】
コンテンツをサーバからユーザ端末に配信するためのコンテンツ配信方法であって、
前記サーバが、前記ユーザ端末に前記コンテンツのダウンロードをさせるためのメッセージを、前記ユーザ端末に送信するステップと、
前記ユーザ端末が、前記メッセージを受信した時に、前記ユーザ端末が存在する場所の現在時刻から前記ユーザ端末が存在する場所の特定時間帯に属する所定の時刻までの時間長を算出するステップと、
前記ユーザ端末が、前記メッセージを受信した時から前記時間長が経過した時刻において、前記コンテンツをダウンロードするステップと、
を備えることを特徴とするコンテンツ配信方法。
【請求項１４】
請求項１３に記載のコンテンツ配信方法において、
前記ユーザ端末が、前記ユーザ端末が存在する場所のグリニッジ標準時に対する時差を取得するステップと、
前記ユーザ端末が、現在のグリニッジ標準時を取得するステップと、
前記ユーザ端末が、前記ユーザ端末が存在する場所のグリニッジ標準時に対する時差及び前記現在のグリニッジ標準時を基に、前記ユーザ端末が存在する場所の現在時刻を算出するステップと、
を備えることを特徴とするコンテンツ配信方法。
【請求項１５】
請求項１４に記載のコンテンツ配信方法において、
前記ユーザ端末が、前記ユーザ端末が存在する場所のグリニッジ標準時に対する時差を取得するステップは、
前記ユーザ端末が、前記ユーザ端末が存在する場所の国識別子を取得するステップと、
前記ユーザ端末が、前記国識別子に対応する、グリニッジ標準時に対する時差を取得するステップと、
を備えることを特徴とするコンテンツ配信方法。
【請求項１６】
請求項１４に記載のコンテンツ配信方法において、
前記ユーザ端末が、現在のグリニッジ標準時を取得するステップは、
前記ユーザ端末が、前記現在のグリニッジ標準時を伴うメッセージを前記サーバから取得するステップを備えることを特徴とするコンテンツ配信方法。
【請求項１７】
請求項１４に記載のコンテンツ配信方法において、
前記ユーザ端末が、現在のグリニッジ標準時を取得するステップは、
前記ユーザ端末が、内蔵するグリニッジ標準時を計測する時計から前記現在のグリニッジ標準時を取得するステップを備えることを特徴とするコンテンツ配信方法。
【請求項１８】
請求項１４に記載のコンテンツ配信方法において、
前記ユーザ端末が、現在のグリニッジ標準時を取得するステップは、
前記ユーザ端末が、ＧＰＳ端末から前記現在のグリニッジ標準時を取得するステップを備えることを特徴とするコンテンツ配信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツをユーザ端末に配信するためのコンテンツ配信方法に関し、特に、複数のコンテンツをまとめてユーザ端末に送信するためのコンテンツ配信方法に関する。
【背景技術】
【０００２】
近年、携帯電話機は、通話のみならず、電子メールの送受信及びＷＥＢブラウジングにも用いられている。また、携帯電話機は、音楽、ゲーム、電子コミック、動画等のコンテンツをダウンロードすることができるようになっている。携帯電話機は、ダウンロードした音楽を再生する再生機として機能し、ダウンロードしたゲームを実行するゲーム機として機能し、ダウンロードした電子コミックを表示する電子ブックとして機能し、ダウンロードした動画を再生するビデオ再生機として機能する。
【０００３】
本発明に関連した技術としては、以下のものがある。
【０００４】
例えば、コンテンツ配信装置が、複数のコンテンツをレイアウト仕様データにおいて予め設定されたレイアウトで自動的に合成して１つの合成データファイルを生成するので、コンテンツを配信する側でコンテンツデータ毎に配置すべき位置を指定しなくてもよく、配信用データの作成の手間を省くことができる技術がある（例えば、特許文献１第４２段落参照。）。
【０００５】
また、ユーザ端末装置がメタファイルを受信し、そのメタファイルに記述されている複数のコンテンツを別々のコンテンツ配信サーバ装置からそれぞれ受信し、それらのコンテンツを連続して再生する技術がある（例えば、特許文献２第３５乃至３９段落参照。）。
【０００６】
更に、サーバが、移動機に対して契約されたコンテンツをプッシュ配信することにより、移動機のユーザが、左右キーを押すことにより、複数のチャンネルをザッピングすることができる技術がある（例えば、非特許文献１参照。）。
【０００７】
更に、ユーザが登録した番組のデータを毎週決まった曜日の深夜乃至早朝に携帯電話機に対して定期配信する技術がある（例えば、非特許文献２参照）。
【特許文献１】特開２００４−３１０３２６号公報
【特許文献２】特開２００３−２７１４９１号公報
【非特許文献１】「携帯向けＦｌａｓｈ放送？〜「Ｆｌａｓｈ  Ｃａｓｔ」って何だ」、平成１６年１１月４日、  インターネット＜URL：http://www.itmedia.co.jp/mobile/articles/0411/04/news003.html, http://www.itmedia.co.jp/mobile/articles/0411/04/news003_2.html＞
【非特許文献２】「ＥＺチャンネル」、平成１６年１２月１５日、  インターネット＜URL： http://www.au.kddi.com/ezweb/au_dakara/ez_channel/index.html, http://www.au.kddi.com/ezweb/au_dakara/ez_channel/contents/tanoshimikata.html＞
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかし、ユーザは、起床している時間にコンテンツを楽しむが、ユーザが起床している時間においては、電話網は、通話、メールの送信、ＷＥＢページの送信のために用いられている。従って、ユーザが起床している時間に、多くのユーザ端末がコンテンツをダウンロードすると、通話、メールの送信、ＷＥＢページの送信のための回線容量を圧迫することとなる。特に、複数のチャンネルのコンテンツを多数のユーザ端末にダウンロードするためのサービスを行うとなると、このような圧迫は無視できないものとなる。
【０００９】
また、非特許文献１に記載されている発明によれば、各チャンネル毎にコンテンツの更新を行うことにより、更新する頻度が異なるチャンネルを別々にダウンロードできるようになっている。
【００１０】
更に、非特許文献２に記載されている発明によれば、更新するタイミングは、深夜又は早朝であるが、各チャンネル毎にコンテンツをユーザ端末にダウンロードする。
【００１１】
更に、非特許文献１に記載されている発明によれば、コンテンツはキャッシュとしてユーザ端末に格納されるため、バック・ナンバを楽しむことができない。
【００１２】
ところが、各チャンネル毎にコンテンツをユーザ端末にダウンロードすると、各チャンネルをダウンロードする度に、ダウンロードのための一連のシーケンスを実行しなければならないので処理が効率的ではない。
【００１３】
また、各チャンネル毎にコンテンツをユーザ端末にダウンロードすると、各チャンネル毎にコンテンツのファイルが存在することとなるので、バック・ナンバの管理の処理が複雑となる。
【００１４】
更に、通話、メール送信又はＷＥＢブラウジングのトラフィック量が多い時に、多数のユーザ端末が大容量のコンテンツをダウンロードすると、通話、メール送信又はＷＥＢブラウジングのための回線容量を圧迫することとなる。
【００１５】
そこで、本発明は、多数のユーザ端末が大容量のコンテンツをダウンロードする場合であっても、通話、メール送信又はＷＥＢブラウジングのための回線容量を圧迫しないことを可能とするコンテンツ配信方法を提供することを目的とする。
【課題を解決するための手段】
【００１６】
本発明の第１の観点によれば、コンテンツをサーバからユーザ端末に配信するためのコンテンツ配信方法であって、前記サーバが、前記ユーザ端末に前記コンテンツのダウンロードをさせるためのメッセージを、前記ユーザ端末に送信するステップと、前記ユーザ端末が、前記メッセージを受信した時に、前記ユーザ端末が存在する場所の現在時刻が前記ユーザ端末が存在する場所の特定時間帯に属しているか否かを判断するステップと、前記現在時刻が前記特定時間帯に属していると判断された場合にのみ、前記ユーザ端末が、前記コンテンツをダウンロードするステップと、を備えることを特徴とするコンテンツ配信方法が提供される。
【００１７】
本発明の第２の観点によれば、コンテンツをサーバからユーザ端末に配信するためのコンテンツ配信方法において、前記サーバが、前記ユーザ端末に前記コンテンツのダウンロードをさせるためのメッセージを、前記ユーザ端末に複数回送信するステップと、前記ユーザ端末が、前記メッセージを受信する度に、前記ユーザ端末が存在する場所の現在時刻が前記ユーザ端末が存在する場所の特定時間帯に属していて、且つ、今回分の前記コンテンツをまだダウンロードしていないか否かを判断するステップと、前記現在時刻が前記特定時間帯に属していて、且つ、今回分の前記コンテンツをまだダウンロードしていないと判断された場合にのみ、前記ユーザ端末が、前記コンテンツをダウンロードするステップと、を備えることを特徴とするコンテンツ配信方法が提供される。
【００１８】
本発明の第３の観点によれば、コンテンツをサーバからユーザ端末に配信するためのコンテンツ配信方法であって、前記サーバが、前記ユーザ端末に前記コンテンツのダウンロードをさせるためのメッセージを、前記ユーザ端末に送信するステップと、前記ユーザ端末が、前記メッセージを受信した時に、前記ユーザ端末が存在する場所の現在時刻から前記ユーザ端末が存在する場所の特定時間帯に属する所定の時刻までの時間長を算出するステップと、前記ユーザ端末が、前記メッセージを受信した時から前記時間長が経過した時刻において、前記コンテンツをダウンロードするステップと、を備えることを特徴とするコンテンツ配信方法が提供される。
【００１９】
上記のコンテンツ配信方法において、前記ユーザ端末が、前記ユーザ端末が存在する場所のグリニッジ標準時に対する時差を取得するステップと、前記ユーザ端末が、現在のグリニッジ標準時を取得するステップと、前記ユーザ端末が、前記ユーザ端末が存在する場所のグリニッジ標準時に対する時差及び前記現在のグリニッジ標準時を基に、前記ユーザ端末が存在する場所の現在時刻を算出するステップと、を備えるようにしてもよい。
【００２０】
上記のコンテンツ配信方法において、前記ユーザ端末が、前記ユーザ端末が存在する場所のグリニッジ標準時に対する時差を取得するステップは、前記ユーザ端末が、前記ユーザ端末が存在する場所の国識別子を取得するステップと、前記ユーザ端末が、前記国識別子に対応する、グリニッジ標準時に対する時差を取得するステップと、を備えるようにしてもよい。
【００２１】
上記のコンテンツ配信方法において、前記ユーザ端末が、現在のグリニッジ標準時を取得するステップは、前記ユーザ端末が、前記現在のグリニッジ標準時を伴うメッセージを前記サーバから取得するステップを備えるようにしてもよい。
【００２２】
上記のコンテンツ配信方法において、前記ユーザ端末が、現在のグリニッジ標準時を取得するステップは、前記ユーザ端末が、内蔵するグリニッジ標準時を計測する時計から前記現在のグリニッジ標準時を取得するステップを備えるようにしてもよい。
【００２３】
上記のコンテンツ配信方法において、前記ユーザ端末が、現在のグリニッジ標準時を取得するステップは、前記ユーザ端末が、ＧＰＳ端末から前記現在のグリニッジ標準時を取得するステップを備えるようにしてもよい。
【００２４】
本発明の第４の観点によれば、当該ユーザ端末がコンテンツのダウンロードをするためのメッセージを受信する手段と、前記メッセージを受信した時に、当該ユーザ端末が存在する場所の現在時刻が当該ユーザ端末が存在する場所の特定時間帯に属しているか否かを判断する手段と、前記現在時刻が前記特定時間帯に属していると判断された場合にのみ、前記コンテンツをダウンロードする手段とを備えることを特徴とするユーザ端末が提供される。
【００２５】
本発明の第５の観点によれば、当該ユーザ端末がコンテンツのダウンロードをするためのメッセージを複数回送信するサーバから、該メッセージを受信する度に、当該ユーザ端末が存在する場所の現在時刻が当該ユーザ端末が存在する場所の特定時間帯に属していて、且つ、今回分の前記コンテンツをまだダウンロードしていないか否かを判断する手段と、前記現在時刻が前記特定時間帯に属していて、且つ、今回分の前記コンテンツをまだダウンロードしていないと判断された場合にのみ、前記コンテンツをダウンロードする手段と、を備えることを特徴とするユーザ端末が提供される。
【００２６】
本発明の第６の観点によれば、当該ユーザ端末がコンテンツのダウンロードをするためのメッセージを受信する手段と、前記メッセージを受信した時に、当該ユーザ端末が存在する場所の現在時刻から当該ユーザ端末が存在する場所の特定時間帯に属する所定の時刻までの時間長を算出する手段と、前記メッセージを受信した時から前記時間長が経過した時刻において、前記コンテンツをダウンロードする手段と、を備えることを特徴とするユーザ端末。
【００２７】
上記のユーザ端末において、当該ユーザ端末が存在する場所のグリニッジ標準時に対する時差を取得する手段と、現在のグリニッジ標準時を取得する手段と、当該ユーザ端末が存在する場所のグリニッジ標準時に対する時差及び前記現在のグリニッジ標準時を基に、当該ユーザ端末が存在する場所の現在時刻を算出する手段と、を備えるようにしてもよい。
【００２８】
上記のユーザ端末において、当該ユーザ端末が存在する場所のグリニッジ標準時に対する時差を取得する手段は、当該ユーザ端末が存在する場所の国識別子を取得する手段と、前記国識別子に対応する、グリニッジ標準時に対する時差を取得する手段と、を備えるようにしてもよい。
【００２９】
上記のユーザ端末において、現在のグリニッジ標準時を取得する手段は、前記現在のグリニッジ標準時を伴うメッセージを前記サーバから取得する手段を備えるようにしてもよい。
【００３０】
上記のユーザ端末において、現在のグリニッジ標準時を取得する手段は、内蔵するグリニッジ標準時を計測する時計から前記現在のグリニッジ標準時を取得する手段を備えるようにしてもよい。
【００３１】
上記のユーザ端末において、現在のグリニッジ標準時を取得する手段は、当該ユーザ端末が、ＧＰＳ端末から前記現在のグリニッジ標準時を取得する手段を備えるようにしてもよい。
【００３２】
本発明の第７の観点によれば、同一のコンテンツをユーザ端末にダウンロードさせるためのメッセージを複数回前記ユーザ端末に送信する手段を備えることを特徴とするサーバが提供される。
【００３３】
本発明の第８の観点によれば、同一のコンテンツをユーザ端末にダウンロードさせるためのメッセージを複数回前記ユーザ端末に送信するステップを備えることを特徴とするメッセージ送信方法が提供される。
【発明の効果】
【００３４】
本発明によれば、サーバが、ユーザ端末にコンテンツのダウンロードをさせるためのメッセージを、ユーザ端末に送信するステップと、ユーザ端末が、メッセージを受信した時に、ユーザ端末が存在する場所の現在時刻がユーザ端末が存在する場所の特定時間帯に属しているか否かを判断するステップと、現在時刻が特定時間帯に属していると判断された場合にのみ、ユーザ端末が、コンテンツをダウンロードするステップと、を備えるので、多数のユーザ端末が大容量のコンテンツをダウンロードする場合であっても、通話、メール送信又はＷＥＢブラウジングのための回線容量を圧迫しないことが可能となる。
【発明を実施するための最良の形態】
【００３５】
以下、図面を参照して本発明を実施するための最良の形態について詳細に説明する。
【００３６】
図１は、本発明の実施形態によるコンテンツ配信方法を行うための通信システムの構成を示す図である。
【００３７】
図１を参照すると、この通信システムでは、ユーザ端末（例えば、携帯電話機、ＰＤＡ、パーソナルコンピュータ）１０１とキャスティング・サーバ１０２との間には、ＲＡＮ（Radio Access Network; ラジオ・アクセス・ネットワーク）１０３、ＳＧＳＮ(Serving GPRS Support Node; サービング・ＧＰＲＳ・サポート・ノード)１０４、ＧＧＳＮ(Gateway GPRS Support Node; ゲートウェイ・ＧＰＲＳ・サポート・ノード)１０５及びＷＰＧ(WAP Gateway; ＷＡＰゲートウェイ)１０６を介した通信路と、ＲＡＮ１０３、ＭＳＣ(Mobile service Switching Center; モバイル・サービス・スイッチング・センタ)１０７、ＳＭＳ−Ｃ(Short Message Service-Center; ショート・メッセージ・サービス・センタ)１０８及びＰＰＧ(Push Proxy Gateway; プッシュ・プロキシ・ゲートウェイ)１０９を介した通信路が確立される。
【００３８】
ＳＧＳＮ１０４とＭＳＣ１０７は、ＨＬＲ(Home Location Register)１１０と接続されている。
【００３９】
また、キャスティング・サーバ１０２には、Ｓｕｂｓ．ＤＢ(Subscribers Database; 契約者データベース)１１１が接続されている。更に、キャスティング・サーバ１０２には、ＣＰ(Contents Provider)−１、ＣＰ−２、ＣＰ−３、ＣＰ−４、・・・（符号１１２−１、１１２−２、１１２−３、１１２−４、・・・）が接続されている。
【００４０】
ＣＰ−１、ＣＰ−２、ＣＰ−３、ＣＰ−４、・・・（符号１１２−１、１１２−２、１１２−３、１１２−４、・・・）は、それぞれ、各チャンネルのコンテンツを保持又は生成し、キャスティング・サーバ１０２に供給する。
【００４１】
Ｓｕｂｓ．ＤＢ１１１には、各契約者毎に、コンテンツ配信のサービスを受ける契約を締結しているか否かの情報、締結している場合には、配信することが希望されているチャンネルの識別情報が格納されている。
【００４２】
キャスティング・サーバ１０２は、Ｓｕｂｓ．ＤＢ１１１に格納されている情報に基づいて、ＣＰ−１、ＣＰ−２、ＣＰ−３、ＣＰ−４、・・・（符号１１２−１、１１２−２、１１２−３、１１２−４、・・・）から供給される各チャンネルのコンテンツ及びインデックス・パートを合成して、マルチ・パート形式のコンテンツを生成し、それをユーザ端末１０１に配信する。
【００４３】
図２は、ユーザ端末１０１のアプリケーション等の構成を示す図である。
【００４４】
図２を参照すると、ＷＡＰ２．０通信部１２１の上層に、キャスティング・アプリケーション１２２、キャスティング・データ・フォルダ１２３、ブラウザ１２４、メディア・プレイヤ１２５及びメーラ１２６が存在する。
【００４５】
キャスティング・アプリケーション１２２は、キャスティング・サーバ１０２との間で通信を行い、コンテンツのダウンロード及び管理を行う。キャスティング・データ・フォルダ１２３には、複数のマルチ・パート形式のコンテンツが格納される。複数のマルチ・パート形式のコンテンツには、バック・ナンバが含まれる。
【００４６】
図３は、各チャンネル毎・各曜日毎のコンテンツの一例を示す図である。
【００４７】
図３を参照すると、チャンネルとしては、チャンネルＡ〜Ｕがある。チャンネルＡ〜Ｉは小容量のコンテンツのチャンネルであり、コンテンツの容量は１００キロバイト以下に制限されている。チャンネルＺ〜Ｕは大容量のコンテンツのチャンネルであり、コンテンツの容量は５００キロバイト以下に制限されている。
【００４８】
例えば、チャンネルＡ〜Ｅのように全ての曜日にコンテンツが配信されるチャンネルもあるが、その他のチャンネルのように一部の曜日だけコンテンツが配信されるチャンネルもある。
【００４９】
ユーザは、コンテンツの配信を受けるための契約を締結したならば、配信を希望する１乃至複数のチャンネルを選択する。図３の例では、ユーザは、チャンネルＣ、Ｆ、Ｇ、Ｈ、Ｚ及びＹを選択している。
【００５０】
図４は、マルチ・パート形式のコンテンツを生成する方法を説明するための図である。
【００５１】
ユーザが選択したチャンネルは、一例として、チャンネルＣ、Ｆ、Ｇ、Ｈ、Ｚ及びＹである。キャスティング・サーバ１０２は、これらのチャンネルのコンテンツを集めて、マルチ・パート形式の１つのコンテンツを生成する。更に、キャスティング・サーバ１０２は、他の各パートへのハイパーリンクを含むインデックス・ページを生成し、そのインデックス・ページを１つのパートとしてマルチ・パート形式のコンテンツに追加する。
【００５２】
なお、当該曜日に配信するべきコンテンツが無いチャンネルのパートを省略しても良い。
【００５３】
キャスティング・サーバ１０２は、このようにして得られた１つのマルチ・パート形式のコンテンツを、毎日、ユーザ端末に配信する。
【００５４】
配信は、特定の時間帯に行う。特定の時間帯は、例えば、携帯通話網におけるトラフィック量が所定値以下である時間帯であってもよい。又は、特定の時間帯は、深夜又は早朝の時間帯であっても良い。深夜又は早朝の時間帯として、例えば、午後９時から午前４時までの間の何れかの時刻から始まり、１０時間以下の所定の期間だけ継続し、遅くとも午前７時までには終了する時間帯を選択しても良い。このように特定の時間帯を選択することにより、他の通信（通話、メール、ＷＥＢブラウジング等のための通信）のための回線容量を圧迫することを避けることができる。
【００５５】
図５は、コンテンツ配信のための手順を表すシーケンス図である。
【００５６】
図５を参照すると、キャスティング・サーバ１０２は、ＳＭＳ(Short Message Service; ショート・メッセージ・サービス)を利用して、
Push (SL: Application ID = x-wap-application:casting.ua
href = http://www.vodafone.com/cast/20041015.html)
というメッセージを、ＰＰＧ１０９を介して、ユーザ端末１０１に送信する。ここで、ＳＬは、service loading（サービス・ローディング）の略称であり、x-wap-application:casting.uaは、このメッセージにより起動するべきキャスティング・アプリケーション１２２の名称であり、http://www.vodafone.com/cast/20041015.htmlは、配信するべき本日分のマルチ・パート形式のコンテンツの所在位置情報であるＵＲＬ(Uniform Resource Locator)である。このＵＲＬを有するサーバは、キャスティング・サーバ１０２である。但し、配信するべきコンテンツを格納しているのであれば、他のサーバであってもよい。
【００５７】
次に、キャスティング・アプリケーション１２２が起動され、このキャスティング・アプリケーション１２２が、キャスティング・サーバ１０２との間で、ＴＣＰセッションを確立し、キャスティング・サーバ１０２に対して、http://www.vodafone.com/cast/20041015.htmlで示される１つのマルチ・パート形式のコンテンツの送信を要求する。キャスティング・サーバ１０２は、この要求に応じて、http://www.vodafone.com/cast/20041015.htmlで示される１つのマルチ・パート形式のコンテンツをキャスティング・アプリケーション１２２に送信する。
【００５８】
複数チャンネルのコンテンツをまとめて、１つのマルチ・パート形式のコンテンツにすることにより、１つのユーザ端末については、一日に一回だけ図５に示すシーケンスの通信を行えば、一日分の全ての選択したチャンネルのコンテンツをユーザ端末に配信することができる。一方、複数のチャンネルのコンテンツをまとめずに、各チャンネル毎にコンテンツの配信を行うとすると、全ての選択したチャンネルの数だけ図５に示すシーケンス又はこれに類似するシーケンスの通信を一日に行う必要が生ずる。従って、本実施形態である前者は、後者に比べ、通信の効率を高めることができる。
【００５９】
図６は、キャスティング・アプリケーション１２２によるコンテンツの管理方法を説明するための図である。
【００６０】
図６を参照すると、キャスティング・アプリケーション１２２は、複数日分のマルチ・パート形式のコンテンツをＦＩＦＯ(First-In First-Out;ファースト・イン−ファースト・アウト)形式でキャスティング・データ・フォルダ１２３に蓄積する。容量計算により、最新のマルチ・パート形式のコンテンツをキャスティング・データ・フォルダ１２３に追加すると、キャスティング・データ・フォルダ１２３がオーバ・フローすると判断したならば、格納された日時の最も古いマルチ・パート形式のコンテンツを削除する。図６は、２００４年１０月１５日分のマルチ・パート形式のコンテンツをキャスティング・データ・フォルダ１２３に追加すると、キャスティング・データ・フォルダ１２３がオーバ・フローすると判断し、２００４年１０月８日分のマルチ・パート形式のコンテンツを削除する例を示している。
【００６１】
格納された日時の最も古いマルチ・パート形式のコンテンツを削除しても、オーバ・フローが解消されないのであれば、次に古いマルチ・パート形式のコンテンツを削除する。
【００６２】
図３を参照して説明したように、各チャンネル毎のコンテンツの容量に上限を設けている。従って、それを考慮し、合計の容量が所定容量を超えないようにユーザが選択できるチャンネルの数を制限することが可能である。従って、そのような制限を設定した上で、更に、キャスティング・データ・フォルダ１２３の容量をその所定容量に保証蓄積日数を乗じて得た容量とすることにより、ユーザに対し、バック・ナンバの蓄積日数を保証することができる。
【００６３】
キャスティング・データ・フォルダ１２３の容量が余っているのであれば、保証蓄積日数を経過したバック・ナンバもキャスティング・データ・フォルダ１２３に残しておいても良い。
【００６４】
図７は、キャスティング・アプリケーション１２２が、コンテンツを選択して、ブラウザ１２４に渡す方法を説明するための図である。
【００６５】
図７を参照すると、キャスティング・アプリケーション１２２は、最新のコンテンツ又は１乃至複数のバック・ナンバのうちのユーザにより選択されたものをキャスティング・データ・フォルダ１２３から１つのマルチ・パート形式のコンテンツとして読み出し、これをブラウザ１２４に渡す。ブラウザ１２４に渡す際には、マルチ・パート形式のコンテンツをバッファ（図示せず。）に、１つのファイルとして格納する。
【００６６】
ブラウザ１２４がインデックス・ページを読むようにするためには、マルチ・パート形式のコンテンツのヘッダ部において、最初にブラウザ１２４が読み込むべきパートを指定する。
【００６７】
図８は、マルチ・パート形式のコンテンツの具体的な記述内容の一例を示した図である。
【００６８】
第１行目で、パートの境界となる文字列として「ｂｏｕｎｄａｒｙ」が指定されている。そして、パートの境界には、「――ｂｏｕｎｄａｒｙ」が記述されている。インデックス・ページには、各チャンネルのコンテンツへのハイパーリンク（例えば、<a href = "ch-c.html"星占い</a>）が記述されている。
【００６９】
第３行目で、ブラウザが最初に読み込むべきパートの名称として「index.htm」が指定されている。また、インデックス・ページに含まれる第７行目には、インデックス・ページのパートの名称として「index.htm」が記述されている。上述したように、これらを利用して、ブラウザは、最初にインデックス・ページを読み込む。
【００７０】
図９は、ユーザが最新のマルチ・パート形式のコンテンツのうちの星占いのチャンネルのコンテンツを選択する場合の画面の遷移を示す。
【００７１】
キャスティング・アプリケーション１２２は、キャスティング・メニュー１３１を表示する。ユーザが、最新コンテンツ１３１ａを選択すると、キャスティング・アプリケーション１２２は、最新のコンテンツをキャスティング・データ・フォルダ１２３から１つのマルチ・パート形式のコンテンツとして読み出し、これをブラウザ１２４に渡す。ブラウザ１２４に渡す際には、マルチ・パート形式のコンテンツをバッファ（図示せず。）に、１つのファイルとして格納する。すると、ブラウザ１２４は、インデックス・ページ１３２を表示する。ブラウザ１２４がインデックス・ページを読むようにするためには、マルチ・パート形式のコンテンツのヘッダ部において、最初にブラウザ１２４が読み込むべきパートを指定する。ユーザが、星占いの項目１３２ａを選択すると、この項目に設定されているハイパーリンクの情報を基に、最新のコンテンツのうちの星占いのチャンネルのコンテンツを読み出し、これを基に星占いのページ１３３を表示する。星占いのページで、マルチ・パート形式のコンテンツに含まれるパートへハイパーリンクするための情報に関連付けられている項目が選択されれば、そのパートにジャンプし、インターネットに接続されているＷＷＷサーバに格納されているページへハイパーリンクするための情報に関連付けられている項目が選択されれば、そのページへジャンプする。
【００７２】
図１０は、ユーザがバック・ナンバであるマルチ・パート形式のコンテンツのうちの星占いのチャンネルのコンテンツを選択する場合の画面の遷移を示す。
【００７３】
キャスティング・アプリケーション１２２は、キャスティング・メニュー１３１を表示する。ユーザが、バック・ナンバ１３１ｂを選択すると、キャスティング・アプリケーション１２２は、バックナンバ・メニュー１３４を表示する。ユーザが、２００４年１０月１０日の項目１３４ａを選択すると、キャスティング・アプリケーション１２２は、２００４年１０月１０日のコンテンツをキャスティング・データ・フォルダ１２３から１つのマルチ・パート形式のコンテンツとして読み出し、これをブラウザ１２４に渡す。ブラウザ１２４に渡す際には、マルチ・パート形式のコンテンツをバッファ（図示せず。）に、１つのファイルとして格納する。すると、ブラウザ１２４は、インデックス・ページ１３５を表示する。ブラウザ１２４がインデックス・ページを読むようにするためには、マルチ・パート形式のコンテンツのヘッダ部において、最初にブラウザ１２４が読み込むべきパートを指定する。ユーザが、星占いの項目１３５ａを選択すると、この項目に設定されているハイパーリンクの情報を基に、２００４年１０月１０日のコンテンツのうちの星占いのチャンネルのコンテンツを読み出し、これを基に星占いのページ１３３と同様なページ（図示せず。）を表示する。
【００７４】
図５に示す一連のシーケンスの通信が上述したような特定の時間帯に行われ、それが成功した場合には、最新のコンテンツの全てのパートをブラウザが表示することが可能となる。しかし、例えば、電波情況が悪い等の理由により、必ずしも図５に示す一連のシーケンスの通信が特定の時間帯に成功裏に終了するとは限らない。失敗した場合には、例えば、あるチャンネルのコンテンツが表示できないことにより、ユーザは失敗を認識することができる。このような場合に対応するために、特定の時間帯が経過した後であっても、ユーザの操作により、最新のコンテンツをユーザ端末にダウンロードできるようにする。このダウンロードに対しては、課金をしてもよいし、しなくてもよい。特定時間外のこのようなダウンロードに対して課金をすることが前提となっている場合には、自動的にではなく、ユーザの操作により、最新のコンテンツをユーザ端末にダウンロードできるようにし、更に、ユーザがその操作をする際に課金されることを知ることができるような画面をユーザ端末が表示することにより、ユーザが、不用意にダウンロードに対して課金されるという事態を避けることができる。
【００７５】
図１１は、ユーザの操作により、最新のコンテンツをユーザ端末にダウンロードすることを起動するための画面を示す。チャンネル選択等を表示する画面１４１において、ユーザがアップデートの項目１４１ａを選択すると、図１２に示すような一連のシーケンスの通信が開始する。なお、図１１の例では、この通信に対して課金することを表示している。ユーザは、この画面を見て、再ダウンロードに対しては課金されることを知ることができる。
【００７６】
図１２に示すシーケンスは、図５に示したキャスティング・サーバ１０２からユーザ端末１０１への、ＳＭＳを利用した
Push (SL: Application ID = x-wap-application:casting.ua
href = http://www.vodafone.com/cast/20041015.html)
というメッセージの送信は成功したことを前提としたものであり、図５に示すシーケンスと比較すると、このメッセージの送信のみが削除されている点が異なる。このメッセージの送信も終了していない場合には、ユーザ端末１０１は、このメッセージの送信をキャスティング・サーバ１０２に要求するための通信を、キャスティング・サーバ１０２との間で行い、その後、図５に示す一連のシーケンスの通信を再度行う。
【００７７】
上述した実施形態は、ユーザ端末１０１及びキャスティング・サーバ１０２が同一の国に存在することを想定したものである。この想定の上で、キャスティング・サーバ１０２からユーザ端末１０１にキャスティング・アプリケーション１２２を起動するためのショート・メッセージが特定の時間帯に属するある時刻に送られると、その直後に、図５に示す一連のシーケンスが実行される。従って、ダウンロードは、特定時間帯に行われることとなる。
【００７８】
ところで、国際ローミングを利用して、例えば、米国に旅行している日本国民が所持するユーザ端末１０１が、日本に存在するキャスティング・サーバ１０２との間で図５に示すような一連のシーケンスを実行することが可能である。この場合、キャスティング・サーバ１０２からユーザ端末１０１にキャスティング・アプリケーション１２２を起動するためのショート・メッセージが日本における特定の時間帯に属するある時刻に送られると、その直後に、図５に示す一連のシーケンスが実行される。例えば、日本における特定時間帯が午前０時から午前６時までであるとすると、米国の東部の時刻は日本の時刻に対して１４時間遅れているので、その特定時間帯は、米国においては、午前１０時から午後４時に対応する。ところが、米国においては、午前１０時から午後４時はトラフィック量が多いため、この間に米国に旅行している日本国民が所持するユーザ端末１０１がキャスティング・サーバ１０２からコンテンツのダウンロードをすることは好ましくない。従って、このようなダウンロードを禁止するのが好ましい。
【００７９】
図１３は、日本に存在するコンテンツ・サーバ１０２が東京に存在するユーザ端末及びニュー・ヨークに存在するユーザ端末にショート・メッセージを送信し、東京に存在するユーザ端末はダウンロードを行うが、ニュー・ヨークに存在するユーザ端末はダウンロードを行わない様子を示している。
【００８０】
しかし、こうすると、ニュー・ヨークに存在するユーザ端末１０１は、コンテンツの供給を受ける機会が奪われることとなり、ユーザにとって不都合である。
【００８１】
図１４は、これを解消するための第１の方法を示したものである。
【００８２】
図１４を参照すると、一例として、日本に存在するコンテンツ・サーバ１０２は、東京に存在するユーザ端末及びニュー・ヨークに存在するユーザ端末に一時間毎にショート・メッセージを送信する。
【００８３】
東京に存在するユーザ端末は、日本の特定時間帯において、最初にショート・メッセージを受信した時に、ダウンロードを行う。一方、東京に存在するユーザ端末は、日本の特定時間帯において、２度目以降にショート・メッセージを受信した時には、ダウンロードを行わない。但し、日本の特定時間帯において、最初にショート・メッセージを受信した時に行ったダウンロードが失敗に終わっている場合には、東京に存在するユーザ端末は、日本の特定時間帯において、２度目にショート・メッセージを受信した時に、ダウンロードを行う。日本の特定時間帯において、最初にショート・メッセージを受信した時に行ったダウンロード及び２度目にショート・メッセージを受信した時に行ったダウンロードの双方が失敗に終わっている場合には、東京に存在するユーザ端末は、日本の特定時間帯において、３度目にショート・メッセージを受信した時に、ダウンロードを行う。以下、同様である。
【００８４】
また、東京に存在するユーザ端末は、日本の特定時間帯に属さない時刻にショート・メッセージを受信した時に、ダウンロードを行わない。
【００８５】
同様に、ニュー・ヨークに存在するユーザ端末は、米国東部の特定時間帯において、最初にショート・メッセージを受信した時に、ダウンロードを行う。一方、ニュー・ヨークに存在するユーザ端末は、米国東部の特定時間帯において、２度目以降にショート・メッセージを受信した時には、ダウンロードを行わない。但し、米国東部の特定時間帯において、最初にショート・メッセージを受信した時に行ったダウンロードが失敗に終わっている場合には、ニュー・ヨークに存在するユーザ端末は、米国東部の特定時間帯において、２度目にショート・メッセージを受信した時に、ダウンロードを行う。米国東部の特定時間帯において、最初にショート・メッセージを受信した時に行ったダウンロード及び２度目にショート・メッセージを受信した時に行ったダウンロードの双方が失敗に終わっている場合には、ニュー・ヨークに存在するユーザ端末は、米国東部の特定時間帯において、３度目にショート・メッセージを受信した時に、ダウンロードを行う。以下、同様である。
【００８６】
また、ニュー・ヨークに存在するユーザ端末は、米国東部の特定時間帯に属さない時刻にショート・メッセージを受信した時に、ダウンロードを行わない。
【００８７】
図１５は、図１３を参照して説明した方法の問題を解決するための第２の方法を示したものである。
【００８８】
図１５を参照すると、一例として、日本に存在するコンテンツ・サーバ１０２は、東京に存在するユーザ端末１０１及びニュー・ヨークに存在するユーザ端末に、グリニッジ標準時（ＧＭＴ）の０時にショート・メッセージを送信する。
【００８９】
東京に存在するユーザ端末は、グリニッジ標準時の０時を日本における時刻（午前９時）に変換し、その日本における時刻から日本の特定時間帯に属する所定の時刻までの時間長を計算し、その時間長が経過したならば、コンテンツをダウンロードする。
【００９０】
同様に、ニュー・ヨークに存在するユーザ端末は、グリニッジ標準時の０時を米国東部における時刻（午後７時）に変換し、その米国東部における時刻から米国の特定時間帯に属する所定の時刻までの時間長を計算し、その時間長が経過したならば、コンテンツをダウンロードする。
【００９１】
次に、図１３、図１４、図１５を参照して説明した方法を実現するための具体的な方法の一例について説明する。
【００９２】
図１６は、準備段階として、ユーザ端末１０１が、時差を取得するための方法を示すフロー・チャートである。
【００９３】
図１６を参照すると、まず、ユーザ端末１０１は、システム情報ブロック信号（ＳＩＢ(System Information Blocks) Ｓｉｇｎａｌ）を受信する（ステップＳ２０１）。
【００９４】
次に、ユーザ端末１０１は、システム情報ブロック信号に含まれている国識別子（ＭＣＣ(Mobile Country Code)）を読み出す（ステップＳ２０２）。日本の場合であれば、国識別子の値は、４４０〜４４１であり、米国の場合であれば、国識別子の値は、３１０〜３１６である。
【００９５】
次に、ユーザ端末１０１は、ステップＳ２０２で読み出した国識別子に対応する、グリニッジ標準時に対する時差を記憶部から読み出す（ステップＳ２０３）。なお、各国識別子毎の「国識別子」対「グリニッジ標準時に対する時差」は、予めユーザ端末１０１の記憶部に格納されているものとする。又は、各国識別子毎の「国識別子」対「グリニッジ標準時に対する時差」の対応関係を保持するサーバを設け、ユーザ端末１０１は、そのサーバからグリニッジ標準時に対する時差を取得しても良い。米国の場合には、時差が複数あるが、例えば、米国東部の時差で代表する。
【００９６】
次に、ユーザ端末１０１は、ステップＳ２０３で読み出した、グリニッジ標準時に対する時差を記憶部に格納する。
【００９７】
図１７は、図１３に示す方法を実現するための具体的な方法を示すフロー・チャートである。
【００９８】
図１７を参照すると、まず、ユーザ端末１０１は、キャスティング・サーバ１０２からキャスティング・アプリケーション１２２を起動させるためのショート・メッセージを受信する（ステップＳ２１１）。
【００９９】
次に、ユーザ端末１０１は、現在のグリニッジ標準時を取得する（ステップＳ２１２）。そのためには、例えば、ユーザ端末１０１は、グリニッジ標準時を計測するための時計を備えていて、それから取得しても良い。又は、ステップＳ２１１で受信するメッセージにグリニッジ標準時を含ませておいて、それを読み出しても良い。具体的には、ショート・メッセージのヘッダ部にグリニッジ標準時を含ませておき、これを読み出せば良い。又は、キャスティング・アプリケーション１２２がキャスティング・サーバ１０２等のサーバにグリニッジ標準時を問い合わせても良い。又は、ユーザ端末１０１は、ＧＰＳ(Global Positioning System；グローバル・ポジショニング・システム)端末を備えていて、それから、グリニッジ標準時を取得しても良い。
【０１００】
次に、ユーザ端末１０１は、ステップＳ２１２で取得したグリニッジ標準時とステップＳ２０４（図１６参照）で格納した、グリニッジ標準時に対する時差とを基にユーザ端末１０１が存在する国における現在時刻を算出する（ステップＳ２１３）。
【０１０１】
次に、ステップＳ２１３で算出した時刻が特定時間帯に属するか否かを判断する（ステップＳ２１４）。なお、ユーザ端末１０１は、ここで参照する特定時間帯を予め保持している。又は、ステップＳ２１１で受信するメッセージに特定時間帯を含ませておいても良い。又は、キャスティング・アプリケーション１２２がキャスティング・サーバ１０２等のサーバに特定時間帯を問い合わせても良い。
【０１０２】
ステップＳ２１３で算出した時刻が特定時間帯に属すると判断されたならば（ステップＳ２１４でＹＥＳ）、キャスティング・アプリケーション１２２は、ダウンロードを実行し、そうでなければ（ステップＳ２１４でＮＯ）、キャスティング・アプリケーション１２２は、ダウンロードを実行しない。
【０１０３】
図１８は、図１４に示す方法を実現するための具体的な方法を示すフロー・チャートである。
【０１０４】
図１８を参照すると、ステップＳ２２１、Ｓ２２２、Ｓ２２３及びＳ２２４は、図１７を参照して説明したステップＳ２１１、Ｓ２１２、Ｓ２１３及びＳ２１４と同様であるので、説明を省略する。
【０１０５】
ステップＳ２２３で算出した時刻が特定時間帯に属すると判断されたならば（ステップＳ２２４でＹＥＳ）、特定時間帯フラグをセットする（ステップＳ２２５）。次に、完了フラグがリセットされているか否かを判断する（ステップＳ２２６）。完了フラグがリセットされていない（すなわち、完了フラグがセットされている）と判断されたならば（ステップＳ２２６でＮＯ）、キャスティング・アプリケーション１２２は、ダウンロードを実行しない。
【０１０６】
完了フラグがリセットされていると判断されたならば（ステップＳ２２６でＹＥＳ）、キャスティング・アプリケーション１２２は、ダウンロードを実行する（ステップＳ２２７）。次に、ダウンロードが成功したか否かを判断する（ステップＳ２２８）。ダウンロードが成功したと判断されたならば（ステップＳ２２８でＹＥＳ）、完了フラグをセットする。ダウンロードが失敗したと判断されたならば（ステップＳ２２８でＮＯ）、完了フラグを変化させない。
【０１０７】
ステップＳ２２３で算出した時刻が特定時間帯に属しないと判断されたならば（ステップＳ２２５でＮＯ）、ステップＳ２２１で受信したショート・メッセージが特定時間経過後の最初のショート・メッセージであるか否かを判断する（ステップＳ２３０）。この判断は、特定時間帯フラグがセットされているか否かを判断することにより実現することができる。
【０１０８】
ステップＳ２２１で受信したショート・メッセージが特定時間経過後の最初のショート・メッセージであると判断されたならば（ステップＳ２３０でＹＥＳ）、完了フラグをリセットし（ステップＳ２３１）、特定時間帯フラグをリセットする（ステップＳ２３２）。
【０１０９】
図１４及び図１８を参照して、具体例を説明する。
【０１１０】
東京に存在するユーザ端末１０１が、グリニッジ標準時の１５時３０分にショート・メッセージを受信した場合には、日本の現在の時刻は日本の特定時間帯（午前０時〜午前６時）に属しており、また、完了フラグはリセットされているので、ステップＳ２２１、Ｓ２２２、Ｓ２２３、Ｓ２２４、Ｓ２２５、Ｓ２２６、Ｓ２２７、Ｓ２２８及びＳ２２９が実行される。従ってユーザ端末１０１は、コンテンツをダウンロードし、また、完了フラグをセットする。
【０１１１】
次に、東京に存在するユーザ端末１０１が、グリニッジ標準時の１６時３０分にショート・メッセージを受信した場合には、日本の現在の時刻は日本の特定時間帯に属しており、また、完了フラグはセットされているので、ステップＳ２２１、Ｓ２２２、Ｓ２２３、Ｓ２２４、Ｓ２２５及びＳ２２６が実行される。従ってユーザ端末１０１は、コンテンツをダウンロードしない。
【０１１２】
但し、東京に存在するユーザ端末１０１が、グリニッジ標準時の１５時３０分にショート・メッセージを受信した場合において、ダウンロードが失敗しているならば、東京に存在するユーザ端末１０１が、グリニッジ標準時の１６時３０分にショート・メッセージを受信した場合には、日本の現在の時刻は日本の特定時間帯に属しており、また、完了フラグはリセットされているので、ステップＳ２２１、Ｓ２２２、Ｓ２２３、Ｓ２２４、Ｓ２２５、Ｓ２２６、Ｓ２２７、Ｓ２２８及びＳ２２９が実行される。従ってユーザ端末１０１は、コンテンツをダウンロードし、また、完了フラグをセットする。
【０１１３】
次に、東京に存在するユーザ端末１０１が、グリニッジ標準時の１７時３０分、１８時３０分、１９時３０分及び２０時３０分にショート・メッセージを受信した場合には、東京に存在するユーザ端末１０１が、グリニッジ標準時の１６時３０分にショート・メッセージを受信した場合と同様なことが行われる。
【０１１４】
次に、東京に存在するユーザ端末１０１が、グリニッジ標準時の２１時３０分にショート・メッセージを受信した場合には、日本の現在の時刻は日本の特定時間帯に属しておらず、また、特定時間帯フラグはセットされているので、ステップＳ２２１、Ｓ２２２、Ｓ２２３、Ｓ２２４、Ｓ２２５、Ｓ２３０、Ｓ２３１及びＳ２３２が実行される。従ってユーザ端末１０１は、コンテンツをダウンロードせず、完了フラグをリセットし、特定時間帯フラグをリセットする。
【０１１５】
次に、東京に存在するユーザ端末１０１が、グリニッジ標準時の２２時３０分にショート・メッセージを受信した場合には、日本の現在の時刻は日本の特定時間帯に属しておらず、また、特定時間帯フラグはリセットされているので、ステップＳ２２１、Ｓ２２２、Ｓ２２３、Ｓ２２４、Ｓ２２５及びＳ２３０が実行される。従ってユーザ端末１０１は、コンテンツをダウンロードしない。完了フラグ及び特定時間帯フラグはリセットされたままである。
【０１１６】
次に、東京に存在するユーザ端末１０１が、グリニッジ標準時の２３時３０分、０時３０分、・・・、１４時３０分にショート・メッセージを受信した場合には、東京に存在するユーザ端末１０１が、グリニッジ標準時の２２時３０分にショート・メッセージを受信した場合と同様なことが行われる。
【０１１７】
図１９は、図１５に示す方法を実現するための具体的な方法を示すフロー・チャートである。
【０１１８】
図１９を参照すると、ステップＳ２４１、Ｓ２４２及びＳ２４３は、図１７を参照して説明したステップＳ２１１、Ｓ２１２及びＳ２１３と同様であるので、説明を省略する。
【０１１９】
ステップＳ２４３の次に、現在時刻と特定時間帯中の所定の時刻を基に、待機時間を算出する（ステップＳ２４４）。具体的には、
待機時間＝特定時間帯中の所定の時刻−現在時刻
である。
【０１２０】
次に、ユーザ端末１０１は、タイマーに待機時間を設定する（ステップＳ２４５）。
【０１２１】
次に、ユーザ端末１０１は、タイマー値がゼロになるまで待ち（ステップＳ２４６のループ）、タイマー値がゼロになったならば（ステップＳ２４６でＹＥＳ）、ダウンロードを実行する（ステップＳ２４７）。
【産業上の利用可能性】
【０１２２】
本発明は、コンテンツをユーザ端末に配信するための利用することができる。
【図面の簡単な説明】
【０１２３】
【図１】本発明の実施形態によるコンテンツ配信方法を行うための通信システムの構成を示す図である。
【図２】本発明の実施形態によるユーザ端末のアプリケーション等の構成を示す図である。
【図３】本発明の実施形態による各チャンネル毎・各曜日毎のコンテンツの一例を示す図である。
【図４】本発明の実施形態によるマルチ・パート形式のコンテンツを生成する方法を説明するための図である。
【図５】本発明の実施形態によるコンテンツ配信のための手順を表すシーケンス図である。
【図６】本発明の実施形態によるキャスティング・アプリケーションによるコンテンツの管理方法を説明するための図である。
【図７】本発明の実施形態によるキャスティング・アプリケーションが、コンテンツを選択して、ブラウザに渡す方法を説明するための図である。
【図８】本発明の実施形態によるマルチ・パート形式のコンテンツの具体的な記述内容の一例を示した図である。
【図９】本発明の実施形態によるユーザが最新のマルチ・パート形式のコンテンツのうちの星占いのチャンネルのコンテンツを選択する場合の画面の遷移を示す図である。
【図１０】本発明の実施形態によるユーザがバック・ナンバであるマルチ・パート形式のコンテンツのうちの星占いのチャンネルのコンテンツを選択する場合の画面の遷移を示す図である。
【図１１】本発明の実施形態によるユーザの操作により、最新のコンテンツをユーザ端末にダウンロードすることを起動するための画面を示す図である。
【図１２】本発明の実施形態によるユーザの操作により、最新のコンテンツをユーザ端末にダウンロードするための手順を表すシーケンス図である。
【図１３】本発明の実施形態において、日本に存在するコンテンツ・サーバが東京に存在するユーザ端末及びニュー・ヨークに存在するユーザ端末にショート・メッセージを送信し、東京に存在するユーザ端末はダウンロードを行うが、ニュー・ヨークに存在するユーザ端末はダウンロードを行わない様子を示す図である。
【図１４】本発明の実施形態において、日本に存在するコンテンツ・サーバが東京に存在するユーザ端末及びニュー・ヨークに存在するユーザ端末にショート・メッセージを複数回送信し、東京に存在するユーザ端末は日本の特定時間帯にダウンロードを行い、ニュー・ヨークに存在するユーザ端末は米国東部の特定時間帯にダウンロードを行う様子を示す図である。
【図１５】本発明の実施形態において、日本に存在するコンテンツ・サーバが東京に存在するユーザ端末及びニュー・ヨークに存在するユーザ端末にショート・メッセージを１日に１回送信し、東京に存在するユーザ端末は日本の特定時間帯にダウンロードを行い、ニュー・ヨークに存在するユーザ端末は米国東部の特定時間帯にダウンロードを行う様子を示す図である。
【図１６】本発明の実施形態において、ユーザ端末が存在する場所のグリニッジ標準時に対する時差を取得し、格納する方法を示すフロー・チャートである。
【図１７】本発明の実施形態による、図１０１に示す方法を実現するための詳細な方法を示すフロー・チャートである。
【図１８】本発明の実施形態による、図１０２に示す方法を実現するための詳細な方法を示すフロー・チャートである。
【図１９】本発明の実施形態による、図１０３に示す方法を実現するための詳細な方法を示すフロー・チャートである。
【符号の説明】
【０１２４】
１０１  ユーザ端末（ＵＴ）
１０２  キャスティング・サーバ
１０３  ラジオ・アクセス・ネットワーク（ＲＡＮ）
１０４  サービング・ＧＰＲＳ・サポート・ノード（ＳＧＳＮ）
１０５  ゲートウェイ・ＧＰＲＳ・サポート・ノード（ＧＧＳＮ）
１０６  ＷＡＰ・ゲートウェイ（ＷＰＧ）
１０７  モバイル・サービス・スイッチング・センタ（ＭＳＣ）
１０８  ショート・メッセージ・サービス・センタ（ＳＭＳ−Ｃ）
１０９  プッシュ・プロキシ・ゲートウェイ（ＰＰＧ）
１１０  ホーム・ロケーション・レジスタ（ＨＬＲ）
１１１  契約者データベース（Ｓｕｂｓ．ＤＢ）
１１２−１、１１２−２、１１２−３、１１２−４  コンテンツプロバイダ（ＣＰ）
１２２  キャスティング・アプリケーション
１２３  キャスティング・データ・フォルダ
１２４  ブラウザ
【図１】
2006260214.tif 000003
【図２】
2006260214.tif 000004
【図３】
2006260214.tif 000005
【図４】
2006260214.tif 000006
【図５】
2006260214.tif 000007
【図６】
2006260214.tif 000008
【図７】
2006260214.tif 000009
【図８】
2006260214.tif 000010
【図９】
2006260214.tif 000011
【図１０】
2006260214.tif 000012
【図１１】
2006260214.tif 000013
【図１２】
2006260214.tif 000014
【図１３】
2006260214.tif 000015
【図１４】
2006260214.tif 000016
【図１５】
2006260214.tif 000017
【図１６】
2006260214.tif 000018
【図１７】
2006260214.tif 000019
【図１８】
2006260214.tif 000020
【図１９】
2006260214.tif 000021