JP2006260213A - コンテンツ配信方法及びユーザ端末 - Google Patents

Abstract

【課題】 他の通信のためのパケット・ベアラを利用する場合でも、不都合なくコンテンツをダウンロードすることを可能とする。
【解決手段】 ユーザ端末１０１が、コンテンツのダウンロードを開始するためのメッセージを受信した時に、ユーザ端末１０１が過去から継続してパケット・ベアラを利用した他の通信を行っている場合には、他の通信が終了してから、ユーザ端末１０１が、コンテンツの送信の要求をサーバ１０２に送信するステップと、サーバ１０２が、コンテンツをユーザ端末１０１に送信するステップと、を行う。また、繰り返しタイマが所定時間の経過を知らせる度に、他の通信が終了しているか否かを判断するステップを更に備える。
【選択図】 図１３

Description

本発明は、コンテンツをユーザ端末に配信するためのコンテンツ配信方法及びユーザ端末に関し、特に、複数のコンテンツをまとめてユーザ端末に送信するためのコンテンツ配信方法及びユーザ端末に関する。

近年、携帯電話機は、通話のみならず、電子メールの送受信及びＷＥＢブラウジングにも用いられている。また、携帯電話機は、音楽、ゲーム、電子コミック、動画等のコンテンツをダウンロードすることができるようになっている。携帯電話機は、ダウンロードした音楽を再生する再生機として機能し、ダウンロードしたゲームを実行するゲーム機として機能し、ダウンロードした電子コミックを表示する電子ブックとして機能し、ダウンロードした動画を再生するビデオ再生機として機能する。

本発明に関連した技術としては、以下のものがある。

例えば、コンテンツ配信装置が、複数のコンテンツをレイアウト仕様データにおいて予め設定されたレイアウトで自動的に合成して１つの合成データファイルを生成するので、コンテンツを配信する側でコンテンツデータ毎に配置すべき位置を指定しなくてもよく、配信用データの作成の手間を省くことができる技術がある（例えば、特許文献１第４２段落参照。）。

また、ユーザ端末装置がメタファイルを受信し、そのメタファイルに記述されている複数のコンテンツを別々のコンテンツ配信サーバ装置からそれぞれ受信し、それらのコンテンツを連続して再生する技術がある（例えば、特許文献２第３５乃至３９段落参照。）。

更に、サーバが、移動機に対して契約されたコンテンツをプッシュ配信することにより、移動機のユーザが、左右キーを押すことにより、複数のチャンネルをザッピングすることができる技術がある（例えば、非特許文献１参照。）。

更に、ユーザが登録した番組のデータを毎週決まった曜日の深夜乃至早朝に携帯電話機に対して定期配信する技術がある（例えば、非特許文献２参照）。
特開２００４−３１０３２６号公報 特開２００３−２７１４９１号公報 「携帯向けＦｌａｓｈ放送？〜「Ｆｌａｓｈ Ｃａｓｔ」って何だ」、平成１６年１１月４日、 インターネット＜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)
というメッセージの送信は成功したことを前提としたものであり、図５に示すシーケンスと比較すると、このメッセージの送信のみが削除されている点が異なる。このメッセージの送信も終了していない場合には、ユーザ端末１０１は、このメッセージの送信をキャスティング・サーバ１０２に要求するための通信を、キャスティング・サーバ１０２との間で行い、その後、図５に示す一連のシーケンスの通信を再度行う。

図１３は、ユーザ端末１０１が、
Push (SL: Application ID = x-wap-application:casting.ua
href = http://www.vodafone.com/cast/20041015.html)
というメッセージを、受信して、その直後に、コンテンツの送信をキャスティング・サーバ１０２に要求しようとする時に、ユーザ端末１０１が、パケット・ベアラを利用した通信を過去から継続して行っている場合の動作を示す。図１３では、この通信として、ブラウザ１２４とＷＷＷサーバ１１３との間の通信を示しているが、他の通信であっても良い。パケット・ベアラを利用した通信が行われているか否かは、ＰＤＰ−Ｃｏｎｔｅｘｔ（Packet Data Protocol-Context）がアクティブであるか否かを見ることにより判断できる。

このような場合、キャスティング・アプリケーション１２２は、所定時間をカウント・ダウンするタイマーを起動し、タイマー値がゼロになる度に、パケット・ベアラを利用した他の通信がまだ継続しているか否かを判断する。まだ、継続している場合には、再度、タイマーを起動し、所定時間経過後、再度、同一の判断をする。継続が終了したと判断された時に、図１３に示すように、ＴＣＰセッションの確立、マルチ・パート形式のコンテンツの送信の要求及びマルチ・パート形式のコンテンツの受信を開始する。上述したように、マルチ・パート形式のコンテンツの受信後、キャスティング・アプリケーション１２２は、そのコンテンツをキャスティング・データ・フォルダ１２３に格納する。

仮に、パケット・ベアラを利用した他の通信が過去から継続して行われている時に、マルチ・パート形式のコンテンツに関する通信を開始すると、後者の通信が前者の通信に割り込むことになり、前者の通信のスピードが落ちてしまう。本実施形態では、図１３を参照して説明したように、パケット・ベアラを利用した他の通信が過去から継続して行われている場合には、マルチ・パート形式のコンテンツに関する通信を開始しないので、前者の通信のスピードが落ちることはない。一方、後者の通信の開始が遅れたとしても、深夜又は早朝等の所定時間に最新のコンテンツを見たいというユーザは少ないと見積もられ、また、ユーザはその時に他の通信を楽しんでいるため、ユーザのサービスに対する満足度を低下させることは殆ど無い。

図１４は、キャスティング・アプリケーション１２２とキャスティング・サーバ１０２との間でＴＣＰセッションが確立した後に、ユーザ端末１０１がパケット・ベアラ利用した通信を開始しようとした場合の動作を示す。図１３では、この通信として、ブラウザ１２４とＷＷＷサーバ１２３との間の通信を示しているが、他の通信であっても良い。

このような場合、キャスティング・アプリケーション１２２は、キャスティング・サーバ１０２との間の通信を中断することはなく、マルチ・パート形式のコンテンツの送信の要求及びマルチ・パート形式のコンテンツの受信を継続する。一方、他の通信の開始を遅らせるようなこともせず、他の通信も並列して行われる。１つのＰＤＰを利用して並列した通信を行うためには、複数のポートを利用する。また、複数のＰＤＰを利用して並列した通信を行っても良い。

仮に、他の通信の開始を遅らせると、ユーザが意図したことが即時にできなくなってしまうが、本実施形態によれば、他の通信の開始を遅らせないので、ユーザが意図したことを即時にできるようになる。

また、仮に、マルチ・パート形式のコンテンツの送信の要求及びマルチ・パート形式のコンテンツの受信を中断すると、再度、ＴＣＰセッションの確立からの一連の通信を再度行わなければならなくなり、キャスティング・アプリケーション１２２の動作が複雑となってしまう。本実施形態では、マルチ・パート形式のコンテンツの送信の要求及びマルチ・パート形式のコンテンツの受信を継続するので、キャスティング・アプリケーション１２２の動作は複雑とならない。

なお、音声通話は、パケット・ベアラと異なる音声・ベアラを利用して行われるので、マルチ・パート形式のコンテンツに関する通信と音声通話とは独立して同時に行うことができる。

本発明は、コンテンツをユーザ端末に配信するための利用することができる。

本発明の実施形態によるコンテンツ配信方法を行うための通信システムの構成を示す図である。 本発明の実施形態によるユーザ端末のアプリケーション等の構成を示す図である。 本発明の実施形態による各チャンネル毎・各曜日毎のコンテンツの一例を示す図である。 本発明の実施形態によるマルチ・パート形式のコンテンツを生成する方法を説明するための図である。 本発明の実施形態によるコンテンツ配信のための手順を表すシーケンス図である。 本発明の実施形態によるキャスティング・アプリケーションによるコンテンツの管理方法を説明するための図である。 本発明の実施形態によるキャスティング・アプリケーションが、コンテンツを選択して、ブラウザに渡す方法を説明するための図である。 本発明の実施形態によるマルチ・パート形式のコンテンツの具体的な記述内容の一例を示した図である。 本発明の実施形態によるユーザが最新のマルチ・パート形式のコンテンツのうちの星占いのチャンネルのコンテンツを選択する場合の画面の遷移を示す図である。 本発明の実施形態によるユーザがバック・ナンバであるマルチ・パート形式のコンテンツのうちの星占いのチャンネルのコンテンツを選択する場合の画面の遷移を示す図である。 本発明の実施形態によるユーザの操作により、最新のコンテンツをユーザ端末にダウンロードすることを起動するための画面を示す図である。 本発明の実施形態によるユーザの操作により、最新のコンテンツをユーザ端末にダウンロードするための手順を表すシーケンス図である。 コンテンツの配信を開始しようとする時に、他の通信がパケット・ベアラを利用して行われている場合の、本発明の実施形態によるコンテンツ配信のための手順を表すシーケンス図である。 コンテンツの配信を行っている時に、他の通信がパケット・ベアラを利用して開始される場合の、本発明の実施形態によるコンテンツ配信のための手順を表すシーケンス図である。

符号の説明

１０１ ユーザ端末（ＵＴ）
１０２ キャスティング・サーバ
１０３ ラジオ・アクセス・ネットワーク（ＲＡＮ）
１０４ サービング・ＧＰＲＳ・サポート・ノード（ＳＧＳＮ）
１０５ ゲートウェイ・ＧＰＲＳ・サポート・ノード（ＧＧＳＮ）
１０６ ＷＡＰ・ゲートウェイ（ＷＰＧ）
１０７ モバイル・サービス・スイッチング・センタ（ＭＳＣ）
１０８ ショート・メッセージ・サービス・センタ（ＳＭＳ−Ｃ）
１０９ プッシュ・プロキシ・ゲートウェイ（ＰＰＧ）
１１０ ホーム・ロケーション・レジスタ（ＨＬＲ）
１１１ 契約者データベース（Ｓｕｂｓ．ＤＢ）
１１２−１、１１２−２、１１２−３、１１２−４ コンテンツプロバイダ（ＣＰ）
１２２ キャスティング・アプリケーション
１２３ キャスティング・データ・フォルダ
１２４ ブラウザ

Claims (12)

1. ユーザ端末が、コンテンツをサーバからダウンロードすることを開始するためのメッセージを受信した時に、前記ユーザ端末が過去から継続してパケット・ベアラを利用した他の通信を行っている場合には、前記他の通信が終了してから、前記ユーザ端末が、前記コンテンツの送信の要求を前記サーバに送信するステップと、前記サーバが、前記コンテンツを前記ユーザ端末に送信するステップと、を行うことを特徴とするコンテンツ配信方法。
2. 請求項１に記載のコンテンツ配信方法において、
   繰り返しタイマが所定時間の経過を知らせる度に、前記他の通信が終了しているか否かを判断するステップを更に備えることを特徴とするコンテンツ配信方法。
3. ユーザ端末が、サーバとの間のセッションを確立した後に、前記ユーザ端末がパケット・ベアラを利用した他の通信を開始した場合には、前記ユーザ端末が、コンテンツの送信の要求を前記サーバに送信するステップと、前記サーバが、前記コンテンツを前記ユーザ端末に送信するステップと、を前記セッションの確立から継続して行うことを特徴とするコンテンツ配信方法。
4. 複数のチャンネルのコンテンツをユーザ端末に配信するためのコンテンツ配信方法において、
   サーバが、前記複数のチャンネルのコンテンツをまとめて、マルチ・パート形式のコンテンツを生成するステップと、
   前記サーバが、前記マルチ・パート形式のコンテンツに、各パートへのハイパーリンクを含むインデックスのパートを追加するステップと、
   前記サーバが、前記マルチ・パート形式のコンテンツの所在位置情報を前記ユーザ端末に送信するステップと、
   前記ユーザ端末が、前記所在位置情報を前記サーバから受信するステップと、
   前記ユーザ端末が、前記所在位置情報を用いて、前記マルチ・パート形式のコンテンツの送信の要求を前記サーバに送信するステップと、
   前記サーバが、前記マルチ・パート形式のコンテンツを前記ユーザ端末に送信するステップと、
   を備えることを特徴とするコンテンツ配信方法であって、
   前記ユーザ端末が、前記所在位置情報を前記サーバから受信した時に、前記ユーザ端末が過去から継続してパケット・ベアラを利用した他の通信を行っている場合には、前記他の通信が終了してから、前記ユーザ端末が、前記所在位置情報を用いて、前記マルチ・パート形式のコンテンツの送信の要求を前記サーバに送信するステップと、前記サーバが、前記マルチ・パート形式のコンテンツを前記ユーザ端末に送信するステップと、を行うことを特徴とするコンテンツ配信方法。
5. 請求項４に記載のコンテンツ配信方法において、
   繰り返しタイマが所定時間の経過を知らせる度に、前記他の通信が終了しているか否かを判断するステップを更に備えることを特徴とするコンテンツ配信方法。
6. 複数のチャンネルのコンテンツをユーザ端末に配信するためのコンテンツ配信方法において、
   サーバが、前記複数のチャンネルのコンテンツをまとめて、マルチ・パート形式のコンテンツを生成するステップと、
   前記サーバが、前記マルチ・パート形式のコンテンツに、各パートへのハイパーリンクを含むインデックスのパートを追加するステップと、
   前記サーバが、前記マルチ・パート形式のコンテンツの所在位置情報を前記ユーザ端末に送信するステップと、
   前記ユーザ端末が、前記所在位置情報を前記サーバから受信するステップと、
   前記ユーザ端末が、前記サーバとの間のセッションを確立するステップと、
   前記ユーザ端末が、前記所在位置情報を用いて、前記マルチ・パート形式のコンテンツの送信の要求を前記サーバに送信するステップと、
   前記サーバが、前記マルチ・パート形式のコンテンツを前記ユーザ端末に送信するステップと、
   を備えることを特徴とするコンテンツ配信方法であって、
   前記ユーザ端末が、前記サーバとの間のセッションを確立した後に、前記ユーザ端末がパケット・ベアラを利用した他の通信を開始した場合には、前記ユーザ端末が、前記所在位置情報を用いて、前記マルチ・パート形式のコンテンツの送信の要求を前記サーバに送信するステップと、前記サーバが、前記マルチ・パート形式のコンテンツを前記ユーザ端末に送信するステップと、を前記セッションの確立から継続して行うことを特徴とするコンテンツ配信方法。
7. コンテンツの送信の要求をサーバに送信する送信手段と、
   前記コンテンツを前記サーバから受信する受信手段と、
   前記コンテンツを前記サーバからダウンロードすることを開始するためのメッセージを受信した時に、過去から継続してパケット・ベアラを利用した他の通信を行っている場合には、前記送信手段と前記受信手段とを前記他の通信が終了してから、起動する手段を更に備えることを特徴とするユーザ端末。
8. 請求項７に記載のユーザ端末において、
   繰り返しタイマが所定時間の経過を知らせる度に、前記他の通信が終了しているか否かを判断する手段を更に備えることを特徴とするユーザ端末。
9. コンテンツの送信の要求をサーバに送信する送信手段と、
   前記コンテンツを前記サーバから受信する受信手段と、
   前記サーバとの間のセッションを確立した後に、パケット・ベアラを利用した他の通信を開始した場合には、前記送信手段と前記受信手段とを前記セッションの確立から継続して動作させる手段と、
   を備えることを特徴とするユーザ端末。
10. サーバが、前記複数のチャンネルのコンテンツをまとめて、マルチ・パート形式のコンテンツを生成するステップと、前記マルチ・パート形式のコンテンツに、各パートへのハイパーリンクを含むインデックスのパートを追加するステップとにより生成したマルチ・パート形式のコンテンツの所在位置情報を受信する手段と、
    前記所在位置情報を用いて、前記マルチ・パート形式のコンテンツの送信の要求を前記サーバに送信する送信手段と、
    前記マルチ・パート形式のコンテンツを前記サーバから受信する受信手段と、
    前記所在位置情報を前記サーバから受信した時に、過去から継続してパケット・ベアラを利用した他の通信を行っている場合には、前記他の通信が終了してから、前記送信手段と前記受信手段とを起動する手段を更に備えることを特徴とするユーザ端末。
11. 請求項１０に記載のユーザ端末において、
    繰り返しタイマが所定時間の経過を知らせる度に、前記他の通信が終了しているか否かを判断する手段を更に備えることを特徴とするユーザ端末。
12. サーバが、前記複数のチャンネルのコンテンツをまとめて、マルチ・パート形式のコンテンツを生成するステップと、前記マルチ・パート形式のコンテンツに、各パートへのハイパーリンクを含むインデックスのパートを追加するステップとにより生成したマルチ・パート形式のコンテンツの所在位置情報を受信する手段と、
    前記所在位置情報を用いて、前記マルチ・パート形式のコンテンツの送信の要求を前記サーバに送信する送信手段と、
    前記マルチ・パート形式のコンテンツを前記サーバから受信する受信手段と、
    前記サーバとの間のセッションを確立した後に、前記ユーザ端末がパケット・ベアラを利用した他の通信を開始した場合には、前記送信手段と前記受信手段とを前記セッションの確立から継続して動作させる手段と、
    を備えることを特徴とするユーザ端末。

Images