JP4859976B2

JP4859976B2 - 動的コンテンツのデリバリを再開する方法、装置、およびシステム

Info

Publication number: JP4859976B2
Application number: JP2009500688A
Authority: JP
Inventors: 彭錦; 高洪涛
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2006-03-17
Filing date: 2007-01-12
Publication date: 2012-01-25
Anticipated expiration: 2027-01-12
Also published as: KR20080103594A; EP1998525A1; US8412793B2; EP1998525B2; CN100591016C; KR101048730B1; ES2467840T3; CN1859123A; ES2467840T5; US20090013039A1; JP2009530724A; WO2007107069A1; EP1998525A4; EP1998525B1

Description

発明の詳細な説明

〔技術分野〕
本発明は、通信分野に関するものであり、特に、クライアント／サーバ（Ｃ／Ｓ）アーキテクチャに基づいた、動的コンテンツのデリバリを再開する方法、並びに、対応するクライアント、動的コンテンツデリバリサーバ、および、動的コンテンツデリバリシステムに関する。

〔背景技術〕
動的コンテンツのデリバリは、Ｃ／Ｓアーキテクチャの基盤における、モバイルクライアントのユーザに、カスタマイズされたコンテンツを送信する技術である。ユーザは、コンテンツを予約する。そして、サーバは、ユーザのパラメータ、位置、所在などの情報に従って、コンテンツをカスタマイズし、予約された時間に、クライアントのユーザにコンテンツをデリバリする。

動的コンテンツをデリバリする処理の間、しばしば、クライアントまたはサーバは、ネットワークの混雑、クライアントの電力消耗、または、その他の理由によって、アクセス不能になり得る。その結果、クライアントとサーバとの接続が切断され、動的コンテンツのデリバリが中断される。このとき、正常な通信相手（party）は、停止状態に陥る。接続が回復した後、ハイパーテキスト転送プロトコル（Hyper Text Transport Protocol：ＨＴＴＰ）、ファイル転送プロトコル（File Transfer Protocol：ＦＴＰ）、または、他のプロトコルにおける、再開（レジューム）技術によって、動的コンテンツが、再び最初からデリバリされるのではなく、直前のブレイクポイントからデリバリされる。

ＨＴＴＰにおける、デリバリ再開方法を以下に示す。

クライアントが、ファイルをサーバからダウンロードする要求を行った場合、ＨＴＴＰメッセージのヘッダは、以下に示すとおりである。

GET http://host.foo.bar/pic-dir/picture.gif
Host: host.foo.bar
Accept: image/gif, image/jpg
サーバからのＨＴＴＰレスポンスメッセージは、以下に示すとおりである。

HTTP/1.1 200 OK
Server: CoolServer/1.3.12
Content-Length: 25432
Content-Type: image/gif
Accept-Ranges: bytes
ETag: fasd987sadf98@example.com/1.1
… GIF picture…
Content-LengthフィールドおよびAccept-Rangesフィールドは、ファイルサイズが２５４３２バイトであることを示している。何らかの理由で、１０３４バイトを送信した後、接続が切断されたとする。そして、クライアントがサーバに対して引き続きデリバリすることを要求する場合、ＨＴＴＰリクエストメッセージは、以下に示すとおりである。

GET http://host.foo.bar/pic-dir/picture.gif
Host: host.foo.bar
Accept: image/gif, image/jpg
Range: 1034-25431
If-Match: fasd987sadf98@example.com/1.1
Rangeフィールドは、要求された、再開するデリバリの範囲、すなわち、ファイルの１０３４バイト目からデリバリを開始することを示している。サーバからのレスポンスメッセージは、以下に示すとおりである。

HTTP/1.1 206 Partial Content
Server: CoolServer/1.3.12
Content-range: bytes 1034-25431/25432
Content-Type: image/gif
Accept-Ranges: bytes
ETag: fasd987sadf98@example.com/1.1
レスポンスメッセージは、今から部分的なデリバリを開始することを示す、状態コード‘２０６’を用いる。Content-Lengthフィールドは、デリバリされる部分を示し、バイトで示される。サーバがクライアントに上述したメッセージを応答した後、引き続き行われるコンテンツデリバリ処理は、通常のデリバリ処理と同様になる。

しかしながら、従来の、ブレイクポイントからデリバリを再開する方法は、以下に示す欠点がある。

接続が正常に回復する前に、クライアントの能力（capability）や、クライアントの現在の状態などの、ユーザのクライアントの動的情報（dynamic information）が変更され得る。例えば、ユーザが自動車を運転しており、交通状況情報を要求した場合、サーバは、ユーザの現在位置に従って、所定の道路の交通状況情報を送信するための動的コンテンツを、クライアントにデリバリする。ネットワーク障害などの原因により、デリバリ処理中に接続が切断された場合、接続が正常に回復した後、サーバが、直ちに従来のレジューム方法を用いて、クライアントに完全にデリバリされていない交通状況情報を送信すると、ユーザは、その情報によって誤った方向に進み得る。なぜならば、ユーザは移動状態にあり、ユーザの地理的位置は変化しているからである。それゆえ、元の道路の交通状況情報は、その時点では不要となる。そのため、従来技術では、動的コンテンツデリバリが再開されたとき、完全にデリバリされていない動的コンテンツが、クライアントの動的情報を解析することなく、直前のブレイクポイントから直ちにクライアントにデリバリされるので、デリバリされた動的コンテンツがユーザの要求に合ったものでない場合、ネットワーク帯域の浪費のみならず、ユーザエクスペリエンスが悪化する。

〔発明の概要〕
本発明は、デリバリが再開されるとき、クライアントの動的情報に従ってデリバリ再開方法が選択されず、それゆえ、デリバリされた動的コンテンツが不必要な情報となり、ネットワーク帯域を浪費することになるといった、従来技術の問題を克服するための、動的コンテンツのデリバリ再開方法を提供する。

本発明は、さらに、クライアント、動的コンテンツデリバリサーバ、および、動的コンテンツデリバリシステムを提供する。

動的コンテンツのデリバリ再開方法は、動的コンテンツデリバリサーバが、動的コンテンツを受信しているクライアントとのデリバリチャンネルが正常に回復したことを検出した後、または、動的コンテンツデリバリサーバが、クライアントから、動的コンテンツのデリバリ再開要求を受信した後、（１）動的コンテンツデリバリサーバによって、デリバリ再開モードを決定するステップと、（２）上記決定されたデリバリ再開モードでクライアントに動的コンテンツをデリバリするステップを実行するものである。

クライアントは、（１）動的コンテンツデリバリサーバに動的コンテンツのデリバリ再開要求を送信する第１デリバリ再開処理モジュールと、（２）動的コンテンツデリバリサーバがデリバリ再開要求を受信した後、決定されたデリバリ再開モードにて、動的コンテンツデリバリサーバからデリバリされる動的コンテンツを受信するか、または、動的コンテンツデリバリサーバが、クライアントとのデリバリチャンネルが正常に回復したことを検出した後、決定されたデリバリ再開モードにて、動的コンテンツデリバリサーバからデリバリされる動的コンテンツを受信する動的コンテンツ受信モジュールとを備えている。

動的コンテンツデリバリサーバは、（１）クライアントから送信される動的コンテンツのデリバリ再開要求を受信する、および／または、クライアントとのデリバリチャンネルが正常に回復したことを検出するデリバリ再開開始モジュールと、（２）クライアントからデリバリ再開要求を受けたとき、および／または、クライアントとのデリバリチャンネルが正常に回復したことが検出されたとき、動的コンテンツをクライアントにデリバリするために用いるデリバリ再開モードを決定するデリバリ再開モード決定モジュールと、（３）決定されたデリバリ再開モードにてクライアントに動的コンテンツをデリバリする動的コンテンツデリバリモジュールとを備えている。

動的コンテンツデリバリシステムは、クライアントおよび動的コンテンツデリバリサーバを含んでいる。動的コンテンツを受信するクライアントとのデリバリチャンネルが正常に回復したことを検出するか、または、クライアントから動的コンテンツのデリバリ再開要求を受信した後、動的コンテンツデリバリサーバが、デリバリ再開モードを決定し、当該決定したデリバリ再開モードにて、クライアントに動的コンテンツをデリバリする。

上述した方法およびシステムでは、動的コンテンツのデリバリを再開するとき、クライアントの動的情報、および、デリバリされるコンテンツの種類に応じて、適切なデリバリ再開モードが選択される。このように、動的コンテンツはクライアントにとって必要なコンテンツであることが保証され、それゆえ、ネットワーク転送資源の浪費を避けることができる。

〔図面の簡単な説明〕
図１は、本発明の実施形態１に係るサーバがクライアントへ問合せメッセージを送信する処理の流れを示したフローチャートである。

図２は、本発明の実施形態１に係るクライアントからサーバへ応答メッセージを返信する処理の流れを示したフローチャートである。

図３は、本発明の実施形態１に係るサーバが応答メッセージを受信する処理の流れを示したフローチャートである。

図４は、本発明の実施形態１に係る信号のやりとりを示す概略図である。

図５は、本発明の実施形態２に係る信号のやりとりを示す概略図である。

図６は、本発明の実施形態に係るクライアントの構成図である。

図７は、本発明の実施形態に係る動的コンテンツデリバリサーバの構成図である。

図８は、本発明の実施形態に係る動的コンテンツデリバリシステムの構成図である。

〔発明の詳細な説明〕
以下では、添付の図面を参照しながら、各実施形態にて、本発明に係る方法についてより詳細に述べる。

（実施形態１）
動的コンテンツデリバリサーバ（以下では、“サーバ”と略記する）は、デリバリ再開処理をアクティブにする。

図１は、サーバがデリバリ再開処理をアクティブにしたとき、サーバがクライアントへ問合せメッセージを送信する処理の流れを示したフローチャートである。各ステップを以下に示す。

ステップＳ１１：コンテンツのデリバリが中断され、コンテンツが完全にデリバリされていないことをサーバが検出したとき、サーバは、コンテンツをデリバリするセッションのコンテキストを保持する。すなわち、サーバは、セッション識別子（ＩＤ）、コンテンツＩＤ、デリバリ済みの範囲、および、クライアントＩＤを記録する。

ステップＳ１２：サーバは、クライアントを探知する。

ステップＳ１３：サーバは、クライアントが見つかったか否かを判定する。クライアントが見つかれば、ステップＳ１４に進む。一方、見つからなければ、ステップＳ１２に戻り、周期的にクライアントを探知する。

ステップＳ１４：サーバは、カスタマイズされたエンジンユニットを介してクライアントの動的情報を取得し、デリバリ再開モードを決定するために当該取得した動的情報を解析する。

このステップでは、動的情報が多様化していること（例えば、位置情報、所在情報、およびクライアントの動的な能力情報など）、および、様々な種類の動的コンテンツがデリバリされることにより、クライアントの動的情報の重要度が異なる。そのため、様々な種類の動的コンテンツ毎に、クライアントの様々な動的情報が、対応するレベルで設定され、デリバリ再開モードは、より高いレベルの動的情報が考慮されて決定される。

例えば、動的コンテンツが娯楽用のビデオコンテンツである場合、対応する動的情報のレベルは、クライアントの所在情報、クライアントの動的能力（メモリサイズ）、および、クライアントの位置情報（Ｌｏｃ）の順に、上位から下位に設定される。なぜならば、クライアントに娯楽用のビデオコンテンツをデリバリするためには、クライアントのユーザの所在が最も重要であるからである（ユーザが働いている場合、そのようなコンテンツはデリバリすべきでない。ユーザが暇である場合、そのようなコンテンツはデリバリしてもよい）。次に重要なのは、クライアントのメモリサイズが、ビデオ情報を受信するのに十分であるか否かである。クライアントの位置に関しては、娯楽用のビデオコンテンツをデリバリするにはあまり重要でない。それゆえ、サーバは、デリバリ再開モードを決定するために、まず、クライアントの所在情報を取得する。クライアントの位置情報は考慮しない。他の例を挙げると、デリバリされる動的コンテンツが交通状況情報である場合、対応するクライアントの動的情報のレベルは、クライアントの位置情報、クライアントのユーザの所在、および、クライアントの動的能力の順に、上位から下位に設定される。それゆえ、クライアントに交通状況情報のデリバリを再開する準備ができたとき、サーバは、デリバリ再開モードを決定するために、まず、クライアントの位置情報を取得する。そして、クライアントの動的能力は、考慮しない。

デリバリ再開モードは、以下を含むが、これに限定されるものではない。

正常（即時）再開：完全にデリバリされていない動的コンテンツを、ブレイクポイントから再開してクライアントにデリバリする。

延期再開：完全にデリバリされていない動的コンテンツを、所定期間後に、クライアントにデリバリする。

再パーソナライズ：デリバリを再開する前に、クライアントの動的情報に従って、デリバリされる動的コンテンツを再びパーソナライズする。

このステップでは、サーバは、クライアントの動的情報およびデリバリされる動的コンテンツの種類に従って、１つのデリバリ再開モードを決定してもよいし、いくつかの選択可能なデリバリ再開モードを決定してもよい。本実施形態では、サーバは、いくつかの選択可能なデリバリ再開モードを決定するものとする。

ステップＳ１５：サーバは、クライアントに問合せメッセージを送信する。当該メッセージには、いくつかの選択可能なデリバリ再開モードに対応するデリバリ再開オプションが含まれる。問合せメッセージは、さらに、コンテンツＩＤ、ファイルサイズ、および／または、デリバリ再開のためのセッションＩＤを含んでいる。

サーバにおいて中断状態時のコンテンツデリバリセッションが切断されていない場合、問合せメッセージは、セッションを識別可能なＩＤであるセッションＩＤを含んでいてもよい。クライアントは、対応するセッションについて調べたり、中断状態時のセッションを回復するために、セッションＩＤを用いることができる。セッションが切断されている場合、クライアントはセッションＩＤを無視し、サーバと新たなセッションを確立してデリバリの再開を実行する。

サーバにおけるコンテンツデリバリセッションが、タイムアウトなどの理由によって切断されている場合、サーバが、新たなセッションで、クライアントに、デリバリを再開する旨の問合せメッセージを送信したとき、サーバは、中断された最後のセッションのセッションＩＤを、問合せメッセージに含めなくてもよい。

問合せメッセージは、さらに、デリバリを再開する範囲（range of delivery resume）を含んでいてもよい。問合せメッセージのデリバリ再開オプションが“再パーソナライズ”である場合、問合せメッセージは、デリバリを再開する範囲を含まない。

サーバとクライアントとの間でやりとりするメッセージには、拡張マークアップ言語（eXtended Markup Language：ＸＭＬ）プロトコルを用いる。問合せメッセージでは、ＸＭＬラベルは、表１に示すように定義される。

例えば、デリバリ再開オプションが“即時再開”である場合、以下の問合せメッセージが生成される。

<DCD>
<Cmd>ResumeRequest<Cmd> 
<Para>
<Initiator>Server</Initiator> 
<ContentID>123456</ContentID> 
<Range>1034-25431</Range> 
<Options>
<Item>
<Name>ResumeInstant</Name> 
<Info>…</Info> 
</Item>
</Options>
</Para>
</DCD>
クライアントが問合せメッセージを受信した後、クライアントからサーバに応答メッセージを返信する処理の流れを図２に示す。当該処理は、以下のステップを含んでいる。

ステップＳ２１：クライアントは、問合せメッセージ内のデリバリ再開オプションを、ユーザに提示し、選択させる。

ステップＳ２２：クライアントは、ユーザがデリバリの再開を選択したか否かを判定する。デリバリの再開が選択された場合、ステップＳ２３に進む。デリバリの再開が選択されなかった場合、ステップＳ２８に進む。

ステップＳ２３：クライアントは、デリバリを再開する範囲を計算する。その方法は、クライアントとはデリバリされたコンテンツのサイズを調べ、サーバから送信された問合せメッセージに含まれるファイルサイズにしたがって、デリバリを再開する範囲を取得する。そして、ステップＳ２４に進む。

ステップＳ２４：クライアントは、さらに、ユーザが“正常（即時）再開”を選択した否かを判定する。ユーザが、“正常（即時）再開”を選択した場合、ステップＳ２５に進む。そうでなければ、ステップＳ２８に進む。

ステップＳ２５：クライアントは、計算された、デリバリを再開する範囲に従って、デリバリされるコンテンツのサイズを計算する。そして、ローカルメモリのサイズと、上記計算されたコンテンツのサイズとを比較して、ステップＳ２６に進む。

ステップＳ２６：クライアントは、メモリ空間が十分であるか否かを判定する。メモリ空間が十分でなければ、ステップＳ２７に進む。十分であれば、ステップＳ２８に進む。

ステップＳ２７：クライアントは、ユーザに、メモリ空間が十分でないことを促し、ユーザにオプションを提供する。例えば、クライアントは、デリバリの再開を行なう前にメモリ空間を開放するために他のファイルを削除するか、または、デリバリの再開を延期するか、または、デリバリの再開をキャンセルするかなどの選択を、ユーザに要求する。そして、ユーザの選択を受け付け、ステップＳ２８に進む。

ステップＳ２８：クライアントは、サーバに、ユーザにより設定されたデリバリ再開パラメータを含む応答メッセージを返信する。さらに、応答メッセージは、クライアントにより計算された、デリバリを再開する範囲を含んでいてもよい。

デリバリを再開する範囲は、動的コンテンツデリバリ（Dynamic Content Delivery：ＤＣＤ）プロトコルの底層（bottom）プロトコルによってデリバリされる。例えは、ＨＴＴＰメッセージのヘッダ、または、ＤＣＤメッセージに含めることができる。ユーザの選択が“再パーソナライズ”である場合、応答メッセージは、デリバリを再開する範囲を含まない。

応答メッセージの例を以下に示す。

<DCD>
<Cmd>ResumeResponse<Cmd> 
<Para>
<Initiator>Server</Initiator> 
<ContentID>123456</ContentID> 
<Range>1034-25431</Range> 
<Options>
<Item>
<Name>ResumeDefer</Name> 
<Info>60</Info> 
</Item>
</Options>
</Para>
</DCD>
問合せメッセージを送信した後、サーバは、クライアントから返信される応答メッセージを待つ。当該処理の流れを図３に示す。当該処理は、以下のステップを含む。

ステップＳ３１：サーバは、クライアントから返信される応答メッセージを待つ。

ステップＳ３２：サーバは、応答メッセージを受信したか否かを判定する。クライアントから応答メッセージを受信したとき、ステップＳ３５に進む。待ち時間を超えた場合、ステップＳ３３に進む。

ステップＳ３３：サーバは、予め設定された待ち期間が満了したか否かを判定する。予め設定された待ち期間が満了していないとき、ステップＳ３１に戻り、クライアントからの応答メッセージを待ち続ける。予め設定された待ち期間が満了したとき、ステップＳ３４に進む。

ステップＳ３４：サーバは、デリバリ再開処理を終了する。

ステップＳ３５：サーバは、コンテンツ全体が完全にデリバリされるまで、応答メッセージに含まれる、ユーザにより選択されたデリバリ再開モードにて、クライアントにコンテンツをデリバリする。

上述した実施形態１における、クライアントとサーバとの間でやりとりされる信号のフローチャートを図４に示す。このフローチャートは以下を含んでいる。

１．サーバとクライアントとの間でコンテンツデリバリが中断されたとき、サーバは、次に示す前処理を実行する。すなわち、クライアントの動的情報を取得し、当該取得した動的情報およびデリバリする動的コンテンツの種類に従って、選択可能なデリバリ再開モードを決定する。そして、クライアントとのデリバリチャンネルが正常に回復したか否かを検知する。

２．クライアントとサーバとの接続が回復した後、サーバは、クライアントとのコンテンツデリバリセッションを確立／復旧する。

３．サーバは、クライアントに問合せメッセージを送信する。なお、サーバにより提供されるデリバリ再開オプションの他、当該オプションの説明／理由、コンテンツＩＤ、セッションＩＤ、および、デリバリされるファイルのサイズなどが、問合せメッセージに含まれていてもよい。

４．クライアントは、デリバリ再開モードをユーザに選択させるために、問合せメッセージに含まれるデリバリ再開オプションを提示する。

５．クライアントは、ユーザの選択に従って、サーバに応答メッセージを返信する。クライアントのデリバリ再開パラメータは、応答メッセージに含まれていてもよい。

６．応答メッセージを受信した後、サーバは、ユーザにより選択されたデリバリ再開モードを取得する。

７．サーバは、ユーザにより選択されたデリバリ再開モードにてクライアントに動的コンテンツをデリバリする。

８．コンテンツデリバリが完了した後、コンテンツデリバリセッションを終了する。

（実施形態２）
クライアントが、能動的に、デリバリ再開処理を開始する。

クライアントとサーバとの接続が回復した後、クライアントは、サーバに対して、コンテンツＩＤ、デリバリを再開する範囲を含めた再開要求メッセージを送信することによって、能動的にデリバリの再開を開始してもよい。また、セッションＩＤを含めてもよい。デリバリを再開する範囲は、ＤＣＤプロトコルの底層（bottom）プロトコルによってデリバリされる。例えば、ＨＴＴＰメッセージのヘッダ、または、ＤＣＤメッセージに含めることができる。

クライアントによって開始されたデリバリ再開要求メッセージの例を以下に示す。

<DCD>
<Cmd>ResumeRequest<Cmd> 
<Para>
<Initiator>Client</Initiator> 
<ContentID>123456</ContentID> 
<Range>1034-25431</Range> 
</Para>
</DCD>
再開要求を受信した後、サーバは、図１に示したステップＳ１４およびＳ１５の処理を引き続き行なうので、再度説明を行なわない。

サーバから送信される問合せメッセージの例を以下に示す。

<DCD>
<Cmd>ResumeReponse<Cmd> 
<Para>
<Initiator>Client</Initiator> 
<ContentID>123456</ContentID>
<Options>
<Item>
<Name>ResumeInstant</Name> 
<Info>…</Info>
</Item>
</Options>
</Para>
</DCD>
クライアントは、問合せメッセージを受信した後、図２に示す各ステップを実行する。そして、サーバは、応答メッセージを受信した後、図３に示す各ステップを実行する。

上述した実施形態２における、クライアントとサーバとの間でやりとりされる信号のフローチャートを図５に示す。このフローチャートは以下を含んでいる。

１．クライアントとサーバとの通信チャンネルが正常に回復した後、サーバとクライアントとのコンテンツデリバリセッションが確立される。

２．クライアントは、コンテンツＩＤおよびデリバリを再開する範囲を含んだ、デリバリ再開要求を、サーバに送信する。要求メッセージには、セッションＩＤを含めてもよい。

３．デリバリ再開要求を受信した後、サーバは、次に示す前処理を実行する。すなわち、サーバは、クライアントの動的情報を取得し、当該取得した動的情報およびデリバリされる動的コンテンツの種類に従って、選択可能なデリバリ再開モードを決定する。

４．サーバは、クライアントに問合せメッセージを送信する。なお、サーバにより提供されるデリバリ再開オプションの他、当該オプションの説明／理由、コンテンツＩＤ、セッションＩＤ、および、ファイルサイズなどが、問合せメッセージに含まれていてもよい。

５．クライアントは、デリバリ再開モードをユーザに選択させるために、問合せメッセージに含まれるデリバリ再開オプションを提示する。

６．クライアントは、ユーザの選択に従って、サーバに応答メッセージを返信する。

７．応答メッセージを受信した後、サーバは、ユーザにより選択されたデリバリ再開モードを取得する。

８．サーバは、ユーザにより選択されたデリバリ再開モードにてクライアントに動的コンテンツをデリバリする。

９．コンテンツが完全にデリバリされた後、コンテンツデリバリセッションを終了する。

上述した実施形態１および２において、サーバは、クライアントの動的情報およびデリバリされる動的コンテンツの種類に従って、１つのデリバリ再開モードを決定する場合、クライアントに動的コンテンツをデリバリするために、直ちに、決定されたデリバリ再開モードを用いてもよい。

また、サーバは、クライアントにデリバリ再開モードを通知させ、クライアントにデリバリ再開モードの受け入れを要求するために、クライアントに通知メッセージを送信してもよい。クライアントは、通知メッセージを受信した後、デリバリ再開モードを受け入れる旨、または、拒否する旨の応答メッセージを返信する。サーバは、クライアントから、デリバリ再開モードを受け入れる旨の応答メッセージを受信すると、決定したデリバリ再開モードにて、クライアントに動的コンテンツをデリバリする。また、サーバは、クライアントから、デリバリ再開モードを拒否する旨の応答メッセージを受信すると、動的コンテンツデリバリ処理を直ちに終了する。

パーソナライズに対するユーザの要求を十分に満足させ、かつ、サーバとクライアントとの間でやりとりされるメッセージを減らすために、デリバリ再開モードは、ユーザにより予め設定され、サーバに格納されていてもよい。クライアントにて動的コンテンツのデリバリを再開する必要が生じたとき、サーバは、直ちに、ユーザにより予め設定されたデリバリ再開モードにて動的コンテンツをデリバリする。このようにすれば、サーバとクライアントとの間で、デリバリ再開モードをネゴシエーションする処理が除かれ、また、ユーザに確認／選択を要求することによって生じる問題が減少される。

また、デリバリ再開モードは、オペレータにより予め設定され、サーバに格納されていてもよい。

クライアントにて動的コンテンツのデリバリを再開する必要が生じたとき、サーバは、まず、動的コンテンツ用にローカルに格納されている、予め設定されたデリバリ再開モードが存在するか否かを判定する。そのようなデリバリ再開モードが存在する場合、サーバは、さらに、デリバリ再開モードを設定した者を判定する。デリバリ再開モードがクライアントにより設定されている場合、サーバは、当該デリバリ再開モードにて、動的コンテンツをクライアントにデリバリする。

デリバリ再開モードがオペレータにより設定されている場合、サーバは、クライアントに、デリバリ再開モードを通知する。サーバは、クライアントからデリバリ再開モードを受け入れる旨の応答メッセージを受信した後、当該デリバリ再開モードにて、クライアントに動的コンテンツをデリバリする。クライアントからデリバリ再開モードを拒否する旨の応答メッセージを受信した場合、サーバは、図１にて示したステップＳ１４およびＳ１５の処理へ進む。つまり、サーバは、クライアントの動的情報およびデリバリされるコンテンツの種類に従ってデリバリ再開モードを決定し、デリバリ再開モードをクライアントに選択させるために、クライアントに問合せメッセージを送信し、そして、クライアントから返信されたデリバリ再開モードにてコンテンツをデリバリする。

本発明の実施形態に係る、動的コンテンツのデリバリ再開方法に基づいて、本発明はクライアントを提供する。クライアントの構成図を図６に示す。クライアントは、（１）動的コンテンツデリバリサーバに動的コンテンツのデリバリの再開要求を送信する、第１デリバリ再開処理モジュール、および、（２）デリバリ再開要求を受信した動的コンテンツデリバリサーバから、決定されたデリバリ再開モードにて、デリバリされた動的コンテンツを受信した後、または、動的コンテンツデリバリサーバがクライアントとのデリバリチャンネルが正常に回復したことを検出した後、決定されたデリバリ再開モードにて動的コンテンツデリバリサーバによりデリバリされた動的コンテンツを受信する、動的コンテンツ受信モジュールを含んでいる。

クライアントは、さらに、（３）動的コンテンツデリバリサーバに、動的コンテンツのデリバリ再開モードを予め設定する要求を送信するとともに、予め設定された動的コンテンツのデリバリ再開モードを格納させるために動的コンテンツデリバリサーバに送信する、第２デリバリ再開処理モジュール、および、（４）動的コンテンツデリバリサーバによって送信される、デリバリ再開モードに関する通知メッセージまたは問合せメッセージを受信する、第３デリバリ再開処理モジュールを含んでいる。

上述したクライアントは、さらに、動的能力情報提供ユニット、位置情報提供ユニット、および、所在情報提供ユニットなどを含んでいてもよい。これらユニットは、それぞれ、クライアントの動的能力情報、位置情報、および所在情報を提供するものである。

本発明は、さらに、動的コンテンツデリバリサーバの実施形態を提供する。サーバの構成図を図７に示す。サーバは、（１）クライアントからの動的コンテンツのデリバリ再開要求を受信する、および／または、クライアントとのデリバリチャンネルが正常に回復したか否かを検出するデリバリ再開開始モジュールと、（２）クライアントからの動的コンテンツのデリバリ再開要求、および／または、クライアントとのデリバリチャンネルが正常に回復したことの検出に従って、クライアントに動的コンテンツをデリバリするために用いるデリバリ再開モードを決定するデリバリ再開モード決定モジュールと、（３）決定されたデリバリ再開モードにてクライアントに動的コンテンツをデリバリする動的コンテンツデリバリモジュール、とを含んでいる。

サーバは、さらに、以下を含んでいる。

パーソナライズエンジンユニットは、クライアントの動的情報を記憶する。デリバリ再開モード決定モジュールは、パーソナライズエンジンユニットからクライアントの動的情報を取得し、当該取得したクライアントの動的情報、および、デリバリされる動的コンテンツの種類に従って、デリバリ再開モードを決定する。

デリバリ再開モード記憶モジュールは、クライアントまたはオペレータによって予め設定されたデリバリ再開モードを記憶する。デリバリ再開モード決定モジュールは、（１）決定されたデリバリ再開モードとして、デリバリ再開モード記憶モジュールから、クライアントによって予め設定されたデリバリ再開モードを取得するか、または、（２）デリバリ再開モード決定モジュールは、デリバリ再開モード記憶モジュールから、オペレータによって予め設定されたデリバリ再開モードを取得して、当該予め設定されたデリバリ再開モードをクライアントに通知するとともに、クライアントからデリバリ再開モードを受け入れる旨の応答メッセージを受信した後、デリバリ再開モード決定モジュールは、決定されたデリバリ再開モードとして、オペレータによって予め設定されたデリバリ再開モードを使用する。

上述した実施形態にて提供されるクライアントおよび動的コンテンツデリバリサーバは、図８に示す動的コンテンツデリバリシステムを構成する。そして、当該システムは、クライアント、動的コンテンツデリバリサーバ、および、１または複数のサーバ群を含んでいる。１または複数のサーバ群は、クライアントの動的情報を提供するものであり、クライアントの動的情報を動的コンテンツデリバリサーバに提供するために、クライアントと動的コンテンツデリバリサーバとの間に接続される。クライアントの動的情報を提供するサーバ群は、位置サーバ、所在サーバ、および、クライアント動的能力収集サーバを含むが、これらに限定されるものではない。

最後に、本発明の実施形態を用いると、動的コンテンツのデリバリが再開されたとき、クライアントの動的情報、および、デリバリされる動的コンテンツの種類に従って、適切なデリバリ再開モードが選択される。このように、本発明は、デリバリされる動的コンテンツは、クライアントが必要とする情報であることを保証し、それゆえ、ネットワーク転送資源の浪費が避けられる。

本発明の実施形態にて上述したように、動的コンテンツデリバリサーバにより、１または複数の選択可能なデリバリ再開モードが決定された場合、ユーザは、使用するデリバリ再開モードの決定／選択を要求され、それゆえ、ユーザのサービスエクスペリエンスおよび満足は、さらに改善される。

上述の本発明の実施形態において、他の方法が用いられてもよいが、ユーザがデリバリ再開モードを予め設定し、サーバに格納される。このように、サーバとクライアントとの間でデリバリ再開モードをやりとりする処理が省かれる。その結果、メッセージのやり取りを軽減でき、ユーザの利便性は向上する。

上述の本発明の実施形態において、さらに他の方法が用いられてもよいが、オペレータによりデリバリ再開モードが予め設定され、サーバに格納される。ユーザが、オペレータにより予め設定されたデリバリ再開モードにてデリバリされた動的コンテンツに同意した場合、サーバは、もはやクライアントの動的情報を取得して解析する必要は無い。それゆえ、サーバでの処理負荷が軽減される。

本発明の精神および範囲を逸脱することなく、様々な変形および改良がなされ得ることは、明らかに当業者に認識されるべきものである。それゆえ、これら変形および改良が、本発明の請求項にて定義される範囲およびそれと同等のものに分類される場合、本発明は、これら変形および改良を含むことを意図している。

本発明の実施形態１に係るサーバがクライアントへ問合せメッセージを送信する処理の流れを示したフローチャートである。本発明の実施形態１に係るクライアントからサーバへ応答メッセージを返信する処理の流れを示したフローチャートである。本発明の実施形態１に係るサーバが応答メッセージを受信する処理の流れを示したフローチャートである。本発明の実施形態１に係る信号のやりとりを示す概略図である。本発明の実施形態２に係る信号のやりとりを示す概略図である。本発明の実施形態に係るクライアントの構成図である。本発明の実施形態に係る動的コンテンツデリバリサーバの構成図である。本発明の実施形態に係る動的コンテンツデリバリシステムの構成図である。

Claims

動的コンテンツデリバリサーバが、動的コンテンツを受信するクライアントとのデリバリチャンネルが正常に回復したことを検出した後、または、上記クライアントから、上記動的コンテンツのデリバリの再開要求を受信した後、上記動的コンテンツのデリバリを再開する動的コンテンツデリバリ再開方法であって、
上記動的コンテンツデリバリサーバが、上記動的コンテンツの種類に従って、異なるレベルの上記クライアントの動的情報を設定するステップと、
上記動的コンテンツデリバリサーバが、最も高いレベルの動的情報および上記クライアントのユーザの状態を考慮して、デリバリ再開モードを決定するステップと、
上記決定されたデリバリ再開モードにて、上記動的コンテンツデリバリサーバが、上記クライアントに上記動的コンテンツをデリバリするデリバリステップとを含み、
上記クライアントの上記動的情報は、位置情報、所在情報、および当該クライアントの動的な能力情報を含んでいることを特徴とする動的コンテンツデリバリ再開方法。
選択可能な上記デリバリ再開モードがいくつか利用可能であるとき、上記再開モード決定ステップは、
上記選択可能な上記デリバリ再開モードに対応するデリバリ再開オプションを含む問合せメッセージを上記クライアントに送信し、
上記クライアントから応答メッセージを受信した後、上記応答メッセージに含まれる上記デリバリ再開オプションに従って、対応するデリバリ再開モードを決定することを特徴とする請求項１に記載の動的コンテンツデリバリ再開方法。
上記動的コンテンツデリバリサーバが、所定期間内に上記クライアントから上記応答メッセージを受信しないとき、上記動的コンテンツのデリバリ処理を終了することを特徴とする請求項２に記載の動的コンテンツデリバリ再開方法。
上記クライアントから送信される上記応答メッセージは、さらに、デリバリ再開パラメータを含んでおり、
上記動的コンテンツデリバリサーバは、上記決定されたデリバリ再開モードにて、上記デリバリ再開パラメータに従って、上記クライアントに動的コンテンツをデリバリすることを特徴とする請求項２に記載の動的コンテンツデリバリ再開方法。
クライアントから送信される動的コンテンツのデリバリ再開要求の受信、および、上記クライアントとのデリバリチャンネルが正常に回復したか否かの検出の少なくともいずれかを実行するデリバリ再開開始モジュールと、
上記動的コンテンツの種類に従って、異なるレベルの上記クライアントの動的情報を設定して、最も高いレベルの動的情報および上記クライアントのユーザの状態を考慮して、デリバリ再開モードを決定するデリバリ再開モード決定モジュールと、
上記決定されたデリバリ再開モードにて上記クライアントに上記動的コンテンツをデリバリする動的コンテンツデリバリモジュールとを備え、
上記クライアントの上記動的情報は、位置情報、所在情報、および当該クライアントの動的な能力情報を含んでいることを特徴とする動的コンテンツデリバリサーバ。
クライアントおよび動的コンテンツデリバリサーバを含む動的コンテンツデリバリシステムであって、
上記動的コンテンツを受信する上記クライアントとのデリバリチャンネルが正常に回復したことを検出した後、または、上記クライアントから上記動的コンテンツのデリバリ再開要求を受信した後、上記動的コンテンツデリバリサーバが、上記動的コンテンツの種類に従って、異なるレベルの上記クライアントの動的情報を設定して、最も高いレベルの動的情報および上記クライアントのユーザの状態を考慮して、デリバリ再開モードを決定し、当該決定されたデリバリ再開モードにて、上記クライアントに上記動的コンテンツをデリバリし、
上記クライアントの上記動的情報は、位置情報、所在情報、および当該クライアントの動的な能力情報を含んでいることを特徴とする動的コンテンツデリバリシステム。
上記クライアントの上記動的情報を上記動的コンテンツデリバリサーバに提供するために、上記クライアントと上記動的コンテンツデリバリサーバとの間に接続され、上記クライアントの上記動的情報を提供する、１または複数のサーバを含むことを特徴とする請求項６に記載の動的コンテンツデリバリシステム。