JP5669818B2 - マルチメディアコンテンツを受信及び送信するための方法並びに電子装置及びサーバー装置 - Google Patents

Description

本発明は、一般的に電子装置に関し、特にマルチメディアコンテンツを受信及び送信するための方法並びに電子装置及びサーバー装置に関するのである。

現在のマルチメディアのストリーミングサービスは多くのウェブサイトで提供しているし、個人携帯端末の普及で多くの人が簡単に屋外でもマルチメディアのストリーミングサービスによってマルチメディアコンテンツを利用している。
また高画質、大容量のマルチメディアコンテンツに対する要求が最近多く上がっている。

ネットワークを通じてメディアデータを送信する方式にはダウンロード方式とストリーミング方式がある。
ストリーミング方式は、サーバーがリアルタイムでメディアデータを送信し、クライアント（クライアント装置）は受信されたメディアデータをリアルタイムで再生する方式である。つまり、ストリーミング方式はオーディオ／ビデオを含んでいるマルチメディアコンテンツをダウンロードではなく、リアルタイムで取り交わす技術を意味し、情報を一度にすべてダウンロードして処理するのではなく、処理に十分な情報をパケット単位で少しずつ持続的に受けて処理する技術である。それによってユーザーはマルチメディアコンテンツを一度にダウンロードする必要がない。

メディアデータをすべて送受信した後にメディアデータの再生が開始されるダウンロード方式と異なり、ストリーミング方式はサーバーとクライアントの間に設定された通信チャンネルを通じてリアルタイムでメディアデータが送受信されて再生される。
しかしながら、高画質コンテンツの場合は既存よりも多くのデータ量をリアルタイムで送信されるため、ストリーミング再生時のバッファリング現象が頻繁に見られる可能性があり、そのためにストリーミング速度を上げてシームレスにマルチメディアコンテンツを見られる方法及び装置が必要となっている問題がある。

韓国公開特許第１０−２０１０−００５８４０４号公報

本発明は上記従来のストリーミング方式における問題点に鑑みてなされたものであって、本発明の目的は、初期にデータをすぐに送信するサーバーの送信特性を利用してマルチメディアコンテンツを受信及び送信するための方法並びに電子装置及びサーバー装置を提供することにある。

本発明の他の目的は、マルチメディアのストリーミング性能を向上させて、マルチメディアコンテンツをバッファリングなしに再生させるためのマルチメディアコンテンツを受信及び送信するための方法並びに電子装置及びサーバー装置を提供することにある。
本発明のまた他の目的は、ストリーミング送信のための接続時間を減らして、ストリーミング電力消費効率が向上するマルチメディアコンテンツを受信及び送信するための方法並びに電子装置及びサーバー装置を提供することにある。

上記目的を達成するためになされた本発明によるマルチメディアコンテンツを受信するための方法は、マルチメディアコンテンツを受信するための方法において、サーバーがデータを送信する区間の中で初期の送信速度が高い区間を持つ送信特性に基づいて、前記マルチメディアコンテンツを要求する段階と、前記要求したマルチメディアコンテンツを前記サーバーから受信する段階とを有することを特徴とする。

上記目的を達成するためになされた本発明による電子装置は、メモリーと、一つ以上のプロセッサと、前記メモリーに保存され、前記一つ以上のプロセッサによって実行可能なように構成される一つ以上のモジュールとを有する電子装置であって、前記モジュールは、サーバーがデータを送信する区間の中で初期の送信速度が高い区間を持つ送信特性に基づいて、マルチメディアコンテンツを要求し、前記要求したマルチメディアコンテンツを前記サーバーから受信する複数の命令語を含むことを特徴とする。

上記目的を達成するためになされた本発明によるマルチメディアコンテンツを送信するための方法は、マルチメディアコンテンツを送信するための方法において、データを送信する区間の中で初期の送信速度が高い区間を持つ送信特性に基づいて、クライアントから前記マルチメディアコンテンツの要求を受ける段階と、前記要求を受けたマルチメディアコンテンツを前記クライアントに送信する段階とを有することを特徴とする。

上記目的を達成するためになされた本発明によるサーバー装置は、マルチメディアコンテンツを送信するためのサーバー装置において、データを送信する区間の中で初期の送信速度が高い区間を持つ送信特性に基づいて、クライアントから前記マルチメディアコンテンツの要求を受けて、前記要求を受けたマルチメディアコンテンツを前記クライアントに送信する制御部を有することを特徴とする。

本発明に係るマルチメディアコンテンツを受信及び送信するための方法並びに電子装置及びサーバー装置によれば、マルチメディアのストリーミングの時、サーバーの送信特性値に基づいてマルチメディアのストリーミング性能を向上させることができるという効果がある。
また、クライアントから多様なマルチメディアのストリーミングサービスを受信する時、さらに早い速度に再生可能であり、これにより、頻繁なバッファリングを減らすことができるという効果がある。
また、高画質マルチメディアデータのストリーミングの時により多くの効果を見られ、最近のタブレットＰＣなどのモバイル機器での性能を差別化することができる。また、すぐ受信した後にネットワーク接続を遮断することで、電力消費の改善機能が最大化することができるという効果がある。

本発明によるマルチメディアのストリーミングサービスシステムを示す図である。 本発明によるサーバーの送信特性を示すグラフである。 本発明の第１の実施形態によるマルチメディアのストリーミングサービスを説明するためのフローチャートである。 本発明の第２の実施形態によるマルチメディアのストリーミングサービスを説明するためのフローチャートである。 本発明の第３の実施形態によるマルチメディアのストリーミングサービスを説明するためのフローチャートである。 本発明の実施形態による送信特性を測定するためのフローチャートである。 本発明の実施形態による電子装置を示すブロック図である。 本発明の実施形態によるサーバー装置を示すブロック図である。

次に、本発明に係るマルチメディアコンテンツを受信及び送信するための方法並びに電子装置及びサーバー装置を実施するための形態の具体例を図面を参照しながら説明する。

本発明を説明するにあたって、係わる公知機能あるいは構成に対する具体的な説明が本発明の要旨を不必要に不明確にすると判断された場合、その詳細な説明は略する。そして後述する用語は本発明での機能を考慮して定義した用語としてこれはユーザー、運用者の意図または慣例などによって変えることができる。したがって、その定義は本明細書の全般にわたる内容を基盤として下されなければならない。

以下、本発明は、初期にデータをすぐに送信するサーバーの送信特性を利用してマルチメディアコンテンツを受信及び送信するための方法並びに電子装置及びサーバー装置に関して説明することにする。
具体的には、ストリーミングサーバーからマルチメディアコンテンツの提供を受ける時に、サーバーの特性を判断して最適のしきい値を求めた後、クライアントのダウンロード速度を向上させ、ストリーミングを加速する方法及び装置に関するものである。

図１は、本発明によるマルチメディアのストリーミングサービスシステムを示す図である。
図１を参照すると、サーバー１００は、ネットワーク１１０を通じてクライアント（クライアント装置）１２０にストリーミングサービスを提供する。

クライアント１２０は、インターネットプロトコルとマルチメディアサービス機能をサポートする電子装置とすることができる。
電子装置はポータブル電子装置であることができ、ポータブル端末（Ｐｏｒｔａｂｌｅ Ｔｅｒｍｉｎａｌ）、移動電話（Ｍｏｂｉｌｅ Ｐｈｏｎｅ）、移動パッド（Ｍｏｂｉｌｅ Ｐａｄ）、メディアプレーヤー（Ｍｅｄｉａ Ｐｌａｙｅｒ）、タブレットコンピュータ（Ｔａｂｌｅｔ Ｃｏｍｐｕｔｅｒ）、ハンドヘルドコンピュータ（Ｈａｎｄｈｅｌｄ Ｃｏｍｐｕｔｅｒ）又はＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）のような装置であることができる。

クライアント１２０は、ネットワーク１１０を通じてサーバー１００にマルチメディアのストリーミングサービスを要求することができる。
例えば、クライアント１２０は、ストリーミング方式でサーバー１００にあるマルチメディアコンテンツを再生させるため、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）ＧＥＴメッセージ１３０を通じてマルチメディアコンテンツに対応するファイル１４０を複数のパケットで受信する。

第１ＨＴＴＰ ＧＥＴメッセージを通じてコンテンツに対応するファイルの中で０〜ｎバイトパケットをサーバー１００に要求して、第２ＨＴＴＰ ＧＥＴメッセージを通じてコンテンツに対応するファイルの中でｎ〜２ｎバイトパケットをサーバー１００に要求して、同様に、マルチメディアコンテンツに対応するファイルをすべて受信するまでＨＴＴＰ ＧＥＴメッセージを通じて要求する。
本発明でクライアント１２０は、サーバー１００の送信特性に基づいて要求データ区間、ネットワークソケットの接続数、及びネットワークソケットの接続時点を決定する。
詳細な説明は図３〜図６で説明することとする。

サーバー１００は、クライアント１２０の要求に応じて、マルチメディアのストリーミングサービスを提供し、そのために各種マルチメディアコンテンツをデータベース化して保存する。

図２は、本発明によるサーバーの送信特性を示すグラフである。
図２を参照すると、ストリーミングサーバーのネットワーク送信パターンを表現しており、ほとんどのストリーミングサーバーが持つ送信パターンとすることができる。
ストリーミングサーバーの送信特性を見ると、クライアントの初期バッファリング時間を短縮するため、サーバーはクライアントの初期データの要求の時にメディアデータをすぐに送信する特性がある。
例えば、サーバーは、０〜ｘ時間の間ではマルチメディアコンテンツの送信速度が高くて、以後には緩やかな送信速度を示す特性がある。

図３は、本発明の第１の実施形態によるマルチメディアのストリーミングサービスを説明するためのフローチャートである。
図３を参照すると、クライアントはＳ３００段階でマルチメディアコンテンツ再生イベントが発生したかどうかを判断しマルチメディアコンテンツ再生イベントが発生した時、Ｓ３０２段階に進行してサーバーの送信特性値がデータベースにあるかどうかを確認する。

サーバーの送信特性値は、クライアントの内部メモリーに保存されて更新される値である。
具体的には、別途のサーバーに保存して更新することができるし、この時、クライアントは該当のサーバーにサーバーの送信特性値を要求するとか、複数のサーバーに対して送信特性値のリストを要求することができる。
次に、クライアントはＳ３０４段階でサーバーの送信特性値がデータベースにある時、Ｓ３０６段階に進行し、サーバーの送信特性値がデータベースに存在しない時はＳ３１０段階に進行する。

クライアントは、Ｓ３０６段階でサーバーの送信特性値に基づいて要求データ区間、ネットワークソケットの接続数及びネットワークソケットの接続時点を決定する。
例えば、初期にデータパケットをすぐに送信する区間を要求データ区間に決定し、要求データのサイズによってネットワークソケットの接続数を決定する。
ネットワークソケットの接続を同時に一つ以上行い、同じ時間でより多くのデータを受けることができる。

そして、ネットワーク接続時点は、要求データ区間が終了する前に新しいネットワーク接続を試みる。
例えば、サーバーでデータを要求データ区間に対応する１ＭＢを送信する場合は、新しいネットワーク接続はクライアントが８００ＫＢ程度を受信する時点で新しいネットワーク接続を試みる。また、ストリーミングプレーヤーのバッファリングサイズが分かっていたら、バッファリングサイズだけ初めに満たすことで新しい接続数を最小化することができる。これはバッファリング区間内で新しいネットワーク接続が頻繁に追加されると従来よりもバッファリング時間がかかる現象ができるからである。

一方、ネットワーク接続数を決定することにおいて、要求データのサイズによって同じ時刻に通常、二つ以上のネットワークソケットの接続ができるが、一つのネットワークソケットの接続を選択することもできる。
例えば、サーバーが同じクライアントで一つ以上のネットワークストリーミングソケットの接続をサポートしていない場合、あるいはクライアントのネットワーク環境又はクライアントの制約的な性能などの理由によって一つの接続が最適な場合である。

クライアントは、一つの接続が最適であると判断されると、同時に二つ以上のネットワークストリーミングソケットの接続による性能向上の代わりに、要求データ区間に対して接続と切断を繰り返して性能を向上させることができる。これはサーバーがネットワークソケットの接続初期にデータをすぐに送ってくれる点を活用してすぐに送ってくれる部分がずっとつながる効果を得ることができるからである。
すなわち、決定された要求データの区間だけのデータを要求した後、すべてのデータを受信するようになればネットワークソケットの接続を切って、またネットワークソケットを接続して前で要求したデータ区間だけ再要求するようにする。このような工程を繰り返すことで、サーバーで早い速度で与える効果をずっと引き継いで行くことができる。

次に、クライアントは、Ｓ３０８段階で決定された要求データのサイズ、ネットワーク接続数、及びネットワークソケットの接続時点に基づいて、マルチメディアコンテンツをサーバーに要求する。

一方、クライアントは、サーバーの送信特性値がデータベースに存在しない時は、Ｓ３１０段階でデフォルト値によってマルチメディアコンテンツをサーバーに要求する。
デフォルト値は、サーバー送信特性に対する統計値に決定することができる。
次に、クライアントはＳ３１２段階でサーバーからマルチメディアコンテンツを複数のパケットで受信する。

次に、クライアントはＳ３１４段階でサーバーからマルチメディアコンテンツを複数のパケットで受信する間に、サーバーの送信特性測定アルゴリズムを実行して送信特性値を測定する。
次に、クライアントはＳ３１６段階で以前のデータベースにある送信特性値の代わりに測定された送信特性値に更新する。
次に、本発明の手続きを終了する。

第１の実施形態では、データベースに送信特性値の有無に関係なく、いつもサーバーの送信特性測定アルゴリズムを実行して送信特性値を測定して更新する。
しかし、第２の実施形態のように、データベースに送信特性値がない時にだけ、サーバーの送信特性測定アルゴリズムを実行して送信特性値を測定して更新する。
また第３の実施形態のように、データベースに送信特性値がない時、サーバーの送信特性測定アルゴリズムを実行して送信特性値を測定して、測定以後に現在の接続を切って測定された送信特性値を利用して新しい接続を要求することもできる。

図４は、本発明の第２の実施形態によるマルチメディアのストリーミングサービスを説明するためのフローチャートである。
図４を参照すると、クライアントは、Ｓ４００段階でマルチメディアコンテンツ再生イベントが発生したかどうかを判断しマルチメディアコンテンツ再生イベントが発生した時、Ｓ４０２段階に進行してサーバーの送信特性値がデータベースにあるかどうかを確認する。

サーバーの送信特性値はクライアントの内部メモリーに保存されて更新される値である。
具体的には、別途のサーバーに保存して更新することができるし、この時、クライアントは該当のサーバーにサーバーの送信特性値を要求するとか、複数のサーバーに対して送信特性値のリストを要求することができる。
次に、クライアントは、Ｓ４０４段階でサーバーの送信特性値がデータベースにある時、Ｓ４０６段階に進行し、サーバーの送信特性値がデータベースに存在しない時は、Ｓ４１２段階に進行する。

クライアントは、Ｓ４０６段階でサーバーの送信特性値に基づいて要求データ区間、ネットワークソケットの接続数及びネットワークソケットの接続時点を決定する。
例えば、初期にデータパケットをすぐに送信する区間を要求データ区間に決定し、要求データのサイズによってネットワークソケットの接続数を決定する。
ネットワークソケットの接続を同時に一つ以上行い、同じ時間でより多くのデータを受けることができる。
そして、ネットワーク接続時点は、要求データ区間が終了する前に新しいネットワーク接続を試みる。

一方、ネットワーク接続数を決定することにおいて、要求データのサイズによって同じ時刻に通常、二つ以上のネットワークソケットの接続ができるが、一つのネットワークソケットの接続を選択することもできる。
例えば、サーバーが同じクライアントで一つ以上のネットワークストリーミングソケットの接続をサポートしていない場合、あるいはクライアントのネットワーク環境又はクライアントの制約的な性能などの理由によって一つの接続が最適な場合である。

クライアントは、一つの接続が最適であると判断されると、同時に二つ以上のネットワークストリーミングソケットの接続による性能向上の代わりに、要求データ区間に対して接続と切断を繰り返して性能を向上させることができる。これはサーバーがネットワークソケットの接続初期にデータをすぐに送ってくれる点を活用してすぐに送ってくれる部分がずっとつながる効果を得ることができるからである。
すなわち、決定された要求データの区間だけのデータを要求した後、すべてのデータを受信するようになると、ネットワークソケットの接続を切って、またネットワークソケットを接続して前で要求したデータ区間だけ再要求するようにする。このような工程を繰り返すことで、サーバーで早い速度で与える効果をずっと引き継いで行くことができる。

次に、クライアントは、Ｓ４０８段階で決定された要求データのサイズ、ネットワーク接続数、及びネットワークソケットの接続時点に基づいて、マルチメディアコンテンツをサーバーに要求して、Ｓ４１０段階でサーバーからマルチメディアコンテンツを複数のパケットで受信する。

一方、クライアントは、サーバーの送信特性値がデータベースに存在しない時、Ｓ４１２段階でデフォルト値によってマルチメディアコンテンツをサーバーに要求する。
デフォルト値は、サーバー送信特性に対する統計値に決定することができる。

次に、クライアントは、Ｓ４１４段階でサーバーからマルチメディアコンテンツを複数のパケットで受信する。
次に、クライアントは、Ｓ４１６段階でサーバーからマルチメディアコンテンツを複数のパケットで受信する間に、サーバーの送信特性測定アルゴリズムを実行して送信特性値を測定する。
次に、クライアントは、Ｓ４１８段階でデータベースに測定された送信特性値として保存する。
次に、本発明の手続きを終了する。

図５は、本発明の第の実施形態によるマルチメディアのストリーミングサービスを説明するためのフローチャートである。
図５を参照すると、クライアントは、Ｓ５００段階でマルチメディアコンテンツ再生イベントが発生したかどうかを判断しマルチメディアコンテンツ再生イベントが発生した時、Ｓ５０２段階に進行してサーバーの送信特性値がデータベースにあるかどうかを確認する。

サーバーの送信特性値は、クライアントの内部メモリーに保存されて更新される値である。
具体的には、別途のサーバーに保存して更新することができるし、この時、クライアントは該当のサーバーにサーバーの送信特性値を要求するとか、複数のサーバーに対して送信特性値のリストを要求することができる。
次に、クライアントは、Ｓ５０４段階でサーバーの送信特性値がデータベースにある時、Ｓ５０６段階に進行してサーバーの送信特性値がデータベースに存在しない時は５１２段階に進行する。

クライアントは、Ｓ５０６段階でサーバーの送信特性値に基づいて要求データ区間、ネットワークソケットの接続数、及びネットワークソケットの接続時点を決定する。
例えば、初期にデータパケットをすぐに送信する区間を要求データ区間に決定し、要求データのサイズによってネットワークソケットの接続数を決定する。
ネットワークソケットの接続を同時に一つ以上行い、同じ時間でより多くのデータを受けることができる。
そして、ネットワーク接続時点は、要求データ区間が終了する前に新しいネットワーク接続を試みる。

一方、ネットワーク接続数を決定することにおいて、要求データのサイズによって同じ時刻に通常、二つ以上のネットワークソケットの接続ができるが、一つのネットワークソケットの接続を選択することもできる。
例えば、サーバーが同じクライアントで一つ以上のネットワークストリーミングソケットの接続をサポートしていない場合、あるいはクライアントのネットワーク環境又はクライアントの制約的な性能などの理由によって一つの接続が最適な場合である。

クライアントは、一つの接続が最適であると判断されると、同時に二つ以上のネットワークストリーミングソケットの接続による性能向上の代わりに、要求データ区間に対して接続と切断を繰り返して性能を向上させることができる。これはサーバーがネットワークソケットの接続初期にデータをすぐに送ってくれる点を活用してすぐに送ってくれる部分がずっとつながる効果を得ることができるからである。
すなわち、決定された要求データの区間だけのデータを要求した後、すべてのデータを受信するようになれば、ネットワークソケットの接続を切ってまたネットワークソケットを接続して前で要求したデータ区間だけ再要求するようにする。このような工程を繰り返すことで、サーバーで早い速度で与える効果をずっと引き継いで行くことができる。

次に、クライアントは、Ｓ５０８段階で決定された要求データのサイズ、ネットワーク接続数、及びネットワークソケットの接続時点に基づいて、マルチメディアコンテンツをサーバーに要求して、Ｓ５１０段階でサーバーからマルチメディアコンテンツを複数のパケットで受信する。

一方、クライアントはサーバーの送信特性値がデータベースに存在しない時、Ｓ５１２段階でデフォルト値によってマルチメディアコンテンツをサーバーに要求する。
デフォルト値は、サーバー送信特性に対する統計値に決定することができる。

次に、クライアントは、Ｓ５１４段階でサーバーからマルチメディアコンテンツを複数のパケットで受信する。
次に、クライアントは、Ｓ５１６段階でサーバーからマルチメディアコンテンツを複数のパケットで受信する間に、サーバーの送信特性測定アルゴリズムを実行して送信特性値を測定する。
次に、クライアントは、Ｓ５１８段階でデータベースに測定された送信特性値として保存する。

次に、クライアントは、Ｓ５２０段階で現在のマルチメディアコンテンツに対する接続を切って、Ｓ５２２段階で測定された送信特性値を用いてマルチメディアコンテンツをサーバーに要求する。
次に、本発明の手続きを終了する。

図６は、本発明の実施形態による送信特性を測定するためのフローチャートである。
図６を参照すると、クライアントは、Ｓ６００段階で「ｍ」＝０に設定する。
「ｍ」は、送信特性値を更新するためのパラメーターである。

次に、クライアントは、Ｓ６０２段階でＨＴＴＰ ＧＥＴの要求に応じて、サーバーから受信されるパケットに対してリアルタイムビット送信速度（ｂｉｔ ｒａｔｅ）「ｎ」を測定する。
ビット送信速度「ｎ」は一定の間隔（例えば、１００ｍｓ〜１ｓ間隔）の間に測定された平均値である。ビット送信速度の測定は本発明に限定されないし、従来の他のビット送信速度の測定方法を適用することもできる。

次に、クライアントは、Ｓ６０４段階でパケットの受信がなだらかではない（一定ではない）場合、Ｓ６０６段階に進行して予め定義された測定値を用いる。
ここで、パケットの受信が円滑かどうかを判断する理由は、ネットワークパケットの受信が一定していないとかひどく電波状態が悪い場合（すなわち、チャンネルの状態が悪い環境）には測定値に信頼性が落ちるようになる。また、他の様々な理由で測定ができない場合もある。この時、あらかじめ定義された測定値を用いることができ、これは多くの実験データを通じて算出されたものである。また、あらかじめ定義された値は、多様な動画特性又はサービス特性によって多様な値を定義することができる。

次に、クライアントは、Ｓ６０４段階でパケットの受信が円滑な場合、Ｓ６０８段階に進行して、ｎ＜ｍなのかを判断する。
すなわち、以前のビット送信速度（ｍ）が現在の測定されたビット送信速度（ｎ）より大きいかを判断する。
もし、以前のビット送信速度（ｍ）が現在の測定されたビット送信速度（ｎ）より大きい時、Ｓ６１４段階に進行する。

一方、以前のビット送信速度（ｍ）が現在の測定されたビット送信速度（ｎ）より同じとか小さい時、Ｓ６１０段階に進行して、以前のビット送信速度（ｍ）を現在の測定されたビット送信速度（ｎ）に設定する。
次に、Ｓ６１２段階に進行して持続的に「ｍ」値が変化するかどうかを判断して、「ｍ」値が持続的に変化する時、Ｓ６０２段階に進行し、「ｍ」値が持続的に変化がない時、Ｓ６１４段階に進行する。

「ｍ」値が持続的に変化するというのは、図２のように初期サーバーがすぐに送信する区間が持続することを示すものであり、「ｍ」値が持続的に変化しないというのは、図２のように初期サーバーがすぐに送信する区間以後に緩やかな送信速度が維持されることを意味する。
すなわち、持続的に測定値「ｍ」の変化があれば、ずっとリアルタイムネットワークビット送信速度を測定して、もし、持続的に測定値「ｍ」が変化がなければ、これはサーバーが初期にデータをすぐに送信する区間以後に現われる緩やかな送信速度を維持している状態と判断する。

次に、クライアントは、Ｓ６１４段階でＳ６０６段階のあらかじめ定義された測定値を用いた場合、測定された値が以前より小さくなった場合のＳ６０８段階、又は持続的に測定値の変化がない場合のＳ６１２段階によって、サーバーですぐに送信するデータのサイズを決定する。
例えば、図２の０〜ｘまでの時間だけストリーミングサーバーから送信を受けたデータのサイズを測定する。

一方、クライアントはサーバーの送信特性の測定が完了した後には、ネットワークソケットの接続時点及びネットワークソケットの接続数と、要求データ区間を決定する。
これは、ネットワークソケットの接続を同時に一つ以上行い、同じ時間でより多くのデータを受けることができるためであり、要求データ区間は最大のストリーミング性能を出すために適切なデータ区間を要求するものである。

しかし、ネットワーク接続数を決定することにおいては、同じ時刻に通常、二つ以上のネットワークソケットの接続をするが、一つのネットワークソケットの接続を選択することもできる。
例えば、サーバーが同じクライアントで一つ以上のネットワークストリーミングソケットの接続をサポートしていない場合や、クライアントでネットワーク環境又はクライアントの制約的な性能などの理由によって一つのネットワークソケットの接続が最適であると判断する場合である。

一つのネットワークソケットの接続が最適であると判断されると、同時に二つ以上のネットワークストリーミングソケットの接続による性能向上の代わりに、一つのネットワークソケットの接続で要求データ区間に対して接続と切断を繰り返して性能を向上させることができる。
これは、サーバーがネットワークソケットの接続初期にデータをすぐに送ってくれる点を活用してすぐに送ってくれる部分がずっとつながる効果を得ることができるからである。
すなわち、決定された要求データの区間だけのデータを要求した後すべて受信すると、ネットワークソケットの接続を切って、またネットワークソケットを接続して前で要求したデータ区間だけ再要求するようにする。このような工程を繰り返すことで、サーバーで早い速度で与える効果をずっと引き継いで行くことができる。

一方、サーバーの送信特性測定値を利用して要求データ区間を決定する時、測定された値を要求データのサイズに決定することができる。
しかし、ネットワークストリーミングは悪い電波状態又はネットワーク特性によってパケットが再送信されることもあるので、この時、最大の効率を高めるために再送信する重複されるデータ量を減らすことができる。
したがって、再送信の時に要求データ区間をＩフレーム（Ｉｎｔｒａ−ｃｏｄｅｄ Ｆｒａｍｅ）又はＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅｓ）単位を参考して決定することもできる。
または再送信に関係なく、Ｉフレーム又はＧＯＰ単位で要求データ区間を決定することもできる。

図７は、本発明の実施形態による電子装置を示すブロック図である。
電子装置７００は、ポータブル電子装置であることができ、ポータブル端末、移動電話、移動パッド、メディアプレーヤー、タブレットコンピュータ、ハンドヘルドコンピュータ又はＰＤＡのような装置であることができる。また、このような装置たちの中で二つの以上の機能を結合した装置を含む任意のポータブル電子装置であることができる。

図７を参照すると、電子装置７００は、メモリー７１０、プロセッサユニット（Ｐｒｏｃｅｓｓｏｒ Ｕｎｉｔ）７２０、第１無線通信サブシステム７３０、第２無線通信サブシステム７３１、外部ポート７６０、オーディオザブシステム７５０、スピーカー７５１、マイクロホン７５２、入出力（ＩＯ、Ｉｎｐｕｔ Ｏｕｔｐｕｔ）システム７７０、タッチスクリーン７８０、及びその他の入力又は制御装置７９０を含む。
メモリー７１０と外部ポート７６０は、複数個使用することができる。

プロセッサユニット７２０は、メモリーインターフェース７２１、一つ以上のプロセッサ７２２、及び周辺装置インターフェース（Ｐｅｒｉｐｈｅｒａｌ Ｉｎｔｅｒｆａｃｅ）７２３を含むことができる。場合によっては、プロセッサユニット７２０全体をプロセッサに呼ぶこともある。
メモリーインターフェース７２１、一つ以上のプロセッサ７２２及び／又は周辺装置インターフェース７２３は、別個の構成要素であることができ、又、一つ以上の集積化された回路に集積化することができる。

プロセッサ７２２は、様々なソフトウェアプログラムを実行して電子装置７００のための多くの機能を実行し、また、音声通信及びデータ通信のための処理及び制御を実行する。
また、このような通常的な機能に加えて、プロセッサ７２２はメモリー７１０に保存されている特定のソフトウェアモジュール（命令語セット）を実行して、そのモジュールに対応する特定の様々の機能を実行する役割もする。
すなわち、プロセッサ７２２は、メモリー７１０に保存されたソフトウェアモジュールたちと連動して本発明の実施形態に係るマルチメディアコンテンツを受送信するための方法を実行する。

本発明の一実施形態では、プロセッサ７２２がサーバーが初期のすぐに送信するデータのサイズ及び時間を測定する。
これは多様なストリーミングサーバーの特性が異なる点を把握することができる。
プロセッサ７２２はマルチメディアのストリーミングの時にリアルタイムでデータのサイズ及び時間を測定するのが難しい場合は、あらかじめ定義した値を用いる。

また、プロセッサ７２２は、サーバーの送信特性値に基づいてストリーミング性能を最大化することができるネットワークソケットの接続時点のしきい値を決定する。
例えば、新しいネットワークソケットの接続時点がクライアントであまり遅れればマルチメディアのストリーミングの時にダウンロードの速度性能が低下させることができるし、反対に、新しいネットワークソケットの接続時点がとても早ければ頻繁なソケット生成又は消滅と、頻繁にネットワーク接続通路生成又は消滅が繰り返されてサーバー又はクライアントに必要以上の負荷を与え得る。そして、ネットワークソケットの接続数もサーバーの送信特性値に基づいて決定する。

また、プロセッサ７２２は、一つのネットワークソケットの接続でデータを持続的にどれだけ受けるかを判断して、要求データ区間を決定する。
要求データ区間は、既存でクライアントがサーバーに要求したデータ区間より小さいか同じでなければならない。
データ区間がとても短すぎたり、長すぎたりするとマルチメディアのストリーミングのダウンロード性能が低下する可能性がある。
本発明の実施形態による上記方法は、図３〜図６で述べた説明を参照する。

プロセッサ７２２は、一つ以上のデータプロセッサ、イメージプロセッサ、又はマルチメディアコンテンツストリーミングアクセレレーターを含むことができる。
データプロセッサ、イメージプロセッサ、又はマルチメディアコンテンツストリーミングアクセレレーターは個別に構成することもできる。また、異なる機能を実行するいくつかのプロセッサで構成することもできる。

周辺装置インターフェース７２３は、電子装置７００の入出力システム７７０及び様々な周辺装置をプロセッサ７２２及びメモリー７１０（メモリーインターフェースを通じて）に接続させる。
電子装置７００の多様な構成要素たちは一つ以上の通信バス（図示せず）又はストリームライン（図示せず）によって接続される。
外部ポート７６０は、電子装置７００を他の電子装置に直接接続するか、ネットワーク（例えば、インターネット、イントラネット、無線ＬＡＮなど）を通じて他の電子装置に間接的に接続するために使用される。外部ポート７６０は、例えば、これらに限定されないが、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ポートまたはＦｉｒｅＷｉｒｅ（登録商標）ポートなどを言う。

センサー７９１は、周辺装置インターフェース７２３に接続されて様々な機能を可能にすることができる。
例えば、動きセンサー及び光センサーが周辺装置インターフェース７２３に接続されてそれぞれ電子装置の動き感知及び外部からの光の感知が可能にすることができる。加えて、位置測定システム、温度センサー又は生体センサーなどのような他のセンサーたちが周辺装置インターフェース７２３に接続されて関連機能たちを実行することができる。
カメラザブシステム７９３は、センサー７９１と接続して、写真及びビデオクリップレコーディングのようなカメラ機能を実行することができる。

一つ以上の無線通信ザブシステム（７３０、７３１）を通じて通信機能が実行される。
無線通信ザブシステム（７３０、７３１）は、無線周波数（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）受信機及び送受信機及び／又は光（例えば、赤外線）受信機及び送受信機を含むことができる。
第１無線通信ザブシステム７３０と第２無線通信ザブシステム７３１は、電子装置７００が通信する通信ネットワークによって区分することができる。

例えば、通信ネットワークは、これらに限定しないが、ＧＳＭ(登録商標)（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ Ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）ネットワーク、ＥＤＧＥ（Ｅｎｈａｎｃｅｄ Ｄａｔａ ＧＳＭ(登録商標) Ｅｎｖｉｒｏｎｍｅｎｔ）ネットワーク、ＣＤＭＡ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）ネットワーク、Ｗ−ＣＤＭＡ（Ｗ−Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）ネットワーク、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）ネットワーク、ＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）ネットワーク、Ｗｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）ネットワーク、ＷｉＭａｘネットワーク及び／又はブルートゥース（登録商標）（Ｂｌｕｅｔｏｏｔｈ（登録商標））ネットワークなどを通じて動作するように設計される通信ザブシステムを含むことができる。第１無線通信ザブシステム７３０と第２無線通信ザブシステム７３１は合わせて一つの無線通信ザブシステムとして構成することもできる。

オーディオザブシステム７５０にスピーカー７５１及びマイクロホン７５２が接続されて音声認識、音声複製、デジタルレコーディング、及び電話機能のようなオーディオストリームの入力と出力を担当する。
すなわち、オーディオザブシステム７５０は、スピーカー７５１及びマイクロホン７５２を通じてユーザーとコミュニケーションをとる。

オーディオザブシステム７５０は、プロセッサユニット７２０の周辺装置インターフェース７２３を通じてデータストリームを受信して、受信したデータストリームを電気ストリームに変換する。
変換された電気ストリーム（Ｅｌｅｃｔｒｉｃ Ｓｉｇｎａｌ）はスピーカー７５１に伝達される。スピーカーは電気ストリームを人が聞くことができる音波（Ｓｏｕｎｄ Ｗａｖｅ）に変換して出力する。マイクロホン７５２は、人やその他の音源（Ｓｏｕｎｄ Ｓｏｕｒｃｅ）から伝達された音波を電気ストリームに変換する。

オーディオザブシステム７５０は、マイクロホン７５２から変換された電気ストリームを受信する。オーディオザブシステム７５０は受信した電気ストリームをオーディオデータストリームに変換し、変換されたオーディオデータストリームを周辺インターフェース７２３に送信する。
オーディオザブシステム７５０は、着脱可能なイヤホン（ｅａｒｐｈｏｎ）、ヘッドホン（ｈｅａｄｐｈｏｎｅ）又はヘッドセット（ｈｅａｄｓｅｔ）を含むことができる。

入出力システム７７０は、タッチスクリーン制御器７７１及び／又はその他の入力制御器７７２を含むことができる。
タッチスクリーン制御器７７１は、タッチスクリーン７８０に接続される。
タッチスクリーン７８０及びタッチスクリーン制御器７７１は、以下に限定されないが、タッチスクリーン７８０との一つ以上の接点を決定するための容量性、抵抗性、赤外線及び表面音響波技術だけでなく、その他の近接センサー配列又はその他の要素を含む任意のマルチタッチ感知技術を利用して接触及び動き、又はこれらの中断を検出することができる。

その他の入力制御器７７２は、その他の入力／制御装置たち７９０と接続される。
その他の入力／制御装置たち７９０に一つ以上のボタン［スピーカー７５１とマイクロホン７５２のボリューム制御のためのアップ／ダウンのボタンを含むことができる。また、ボタンはプッシュボタン（Ｐｕｓｈ Ｂｕｔｔｏｎ）又はロッカーボタン（Ｒｏｃｋｅｒ Ｂｕｔｔｏｎ）などを用いることができる）］、ロッカースィッチ、サムホイール（Ｔｈｕｍｂ−Ｗｈｅｅｌ）、ダイヤル、ステッキ、及び／又はスタイラスのようなポインター装置を含むことができる。

タッチスクリーン７８０は、電子装置７００とユーザー間の入力／出力インターフェースを提供する。
すなわち、タッチスクリーン７８０は、ユーザーのタッチ入力を電子装置７００に伝達する。また、電子装置７００からの出力をユーザーに示す媒介体である。
すなわち、タッチスクリーン７８０はユーザーに視覚的な出力を示す。このような視覚的出力はテキスト、グラフィック、ビデオとこれらの組み合わせの形態で現われる。

タッチスクリーン７８０は、様々なディスプレイを用いることができる。
例えば、ここに限定しないが、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）、ＬＥＤ（Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）、ＬＰＤ（Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｐｏｌｙｍｅｒ Ｄｉｓｐｌａｙ）、ＯＬＥＤ（Ｏｒｇａｎｉｃ Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）、ＡＭＯＬＥＤ（Ａｃｔｉｖｅ Ｍａｔｒｉｘ Ｏｒｇａｎｉｃ Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）又はＦＬＥＤ（Ｆｌｅｘｉｂｌｅ ＬＥＤ）を用いることができる。

メモリー７１０は、メモリーインターフェース７２１に接続される。
メモリー７１０は、一つ以上の磁気ディスク記憶装置のような高速ランダムアクセスメモリー及び／又は非揮発性メモリー、一つ以上の光記憶装置及び／又はフラッシュメモリー（例えば、ＮＡＮＤ、ＮＯＲ）を含むことができる。
メモリー７１０はソフトウェアを保存する。

ソフトウェアの構成要素は、運営体制モジュール７１１、通信モジュール７１２、グラフィックモジュール７１３、ユーザーインターフェースモジュール７１４、及びＤＢモジュール７１５、カメラモジュール７１６、一つ以上のアプリケーションモジュール７１７などを含む。
また、ソフトウェアの構成要素であるモジュールは、命令語の集合として表現することができるので、モジュールを命令語セットと表現することもある。モジュールはまたプログラムと表現することもある。

運営体制（オペレーションシステム）モジュール７１１［例えば、ＷＩＮＤＯＷＳ（登録商標）、ＬＩＮＵＸ（登録商標）、ダーウィン（Ｄａｒｗｉｎ）、ＲＴＸＣ、ＵＮＩＸ（登録商標）、ＯＳ Ｘ（登録商標）、又はＶｘＷｏｒｋｓ（登録商標）のような内蔵運営体制］は一般的なシステム動作を制御する様々のソフトウェアの構成要素を含む。
このような一般的なシステム動作の制御は、例えば、メモリー管理及び制御、保存ハードウェア（装置）制御及び管理、電力制御及び管理などを意味する。このような運営体制ソフトウェアは様々のハードウェア（装置）とソフトウェアの構成要素（モジュール）の間の通信を円滑にする機能も実行する。

通信モジュール７１２は、無線通信サブシステム（７３０、７３１）や外部ポート７６０を通じてコンピュータ、サーバー及び／又はポータブル端末など他の電子装置と通信を可能にする。
グラフィックモジュール７１３は、タッチスクリーン７８０上にグラフィックを提供して表示するための様々なソフトウェアの構成要素を含む。グラフィックと言う用語はテキスト（ｔｅｘｔ）、ウェブページ（ｗｅｂ ｐａｇｅ）、アイコン（ｉｃｏｎ）、デジタルイメージ（ｄｉｇｉｔａｌ ｉｍａｇｅ）、ビデオ（ｖｉｄｅｏ）、アニメーション（ａｎｉｍａｔｉｏｎ）などを含む意味で用いられる。

ユーザーインターフェースモジュール７１４は、ユーザーインターフェースに関した様々なソフトウェアの構成要素を含む。
ユーザーインターフェースの状態がどのように変更されるのか、又はユーザーインターフェース状態の変更がどのような条件で行われるのかなどの内容を含む。
ＤＢモジュール７１５は、測定されたサーバーの送信特性値とデフォルトサーバーの送信特性値をデータベースに保存する。

カメラモジュール７１６は、カメラ関連プロセス及び機能が実行できるようにするカメラ関連ソフトウェアの構成要素を含む。
アプリケーションモジュール７１７は、ブラウザー（ｂｒｏｗｓｅｒ）、電子メール（ｅｍａｉｌ）、インスタントメッセージ（ｉｎｓｔａｎｔ ｍｅｓｓａｇｅ）、ワードプロセシング（ｗｏｒｄ ｐｒｏｃｅｓｓｉｎｇ）、キーボードエミュレーション（ｋｅｙｂｏａｒｄ ｅｍｕｌａｔｉｏｎ）、アドレス帳（ａｄｄｒｅｓｓ ｂｏｏｋ）、接触リスト（ｔｏｕｃｈ ｌｉｓｔ）、ウィジェット（ｗｉｄｇｅｔ）、デジタル著作権管理（ＤＲＭ、Ｄｉｇｉｔａｌ Ｒｉｇｈｔ Ｍａｎａｇｅｍｅｎｔ）、音声認識（ｖｏｉｃｅ ｒｅｃｏｇｎｉｔｉｏｎ）、音声複製、位置決定機能（ｐｏｓｉｔｉｏｎ ｄｅｔｅｒｍｉｎｉｎｇ ｆｕｎｃｔｉｏｎ）、位置情報サービス（ｌｏｃａｔｉｏｎ ｂａｓｅｄ ｓｅｒｖｉｃｅ）などを含む。
メモリー７１０は、上述したモジュールに加えて、追加的なモジュール（命令語たち）を含むことができる。または、必要に応じて、一部のモジュール（命令語たち）を使用していないこともある。

本発明に加えて、マルチメディアコンテンツのストリーミングサービスを実行するためのアプリケーションモジュール７１７は、マルチメディアのストリーミング処理と関連したソフトウェアの構成要素を含む。
アプリケーションモジュール７１７は、本発明の実施形態で示した上記方法に対応する命令語セットを含む。

本発明の実施形態に係る命令語は、マルチメディアコンテンツの再生イベントが発生する時、サーバーの送信特性値がデータベースにあるかどうかを確認して、サーバーの送信特性値がデータベースにある時、サーバーの送信特性値に基づいて要求データ区間、ネットワークソケットの接続数及びネットワークソケットの接続時点を決定し、決定された要求データのサイズ、ネットワークの接続数及びネットワークソケットの接続時点に基づいて、マルチメディアコンテンツをサーバーに要求して、サーバーからマルチメディアコンテンツを複数のパケットで受信する。そして、クライアントは、サーバーの送信特性値がデータベースに存在しない時、デフォルト値によってマルチメディアコンテンツをサーバーに要求して、以後、サーバーからマルチメディアコンテンツを複数のパケットで受信する。また、サーバーからマルチメディアコンテンツを複数のパケットで受信する間に、サーバーの送信特性測定アルゴリズムを実行して送信特性値を測定して、以後、クライアントはデータベースに測定された送信特性値として保存させる命令語を含む。

本発明の他の実施形態に係る命令語は、サーバーの送信特性値がデータベースに存在しない時に、デフォルト値によってマルチメディアコンテンツをサーバーに要求して、サーバーからマルチメディアコンテンツを複数のパケットで受信して、サーバーからマルチメディアコンテンツを複数のパケットで受信する間に、サーバーの送信特性測定アルゴリズムを実行して送信特性値を測定して、データベースに測定された送信特性値として保存して、現在のマルチメディアコンテンツに対する接続を切って測定された送信特性値を用いてマルチメディアコンテンツをサーバーに要求する命令語を含む。

また命令語は、ＨＴＴＰ ＧＥＴ要求に応じて、サーバーから受信されるパケットに対してリアルタイムビット送信速度「ｎ」を測定して、パケットの受信がなだらかではない（一定ではない）場合は予め定義された測定値を用いて、パケットの受信が円滑な（一定な）場合は、ｎ＜ｍなのかを判断して（すなわち、以前のビット送信速度（ｍ）が現在の測定されたビット送信速度（ｎ）より大きいかを判断して）、以前のビット送信速度（ｍ）が現在の測定されたビット送信速度（ｎ）より大きい時、あらかじめ定義された測定値で送信特性値を決定し、一方、以前のビット送信速度（ｍ）が現在の測定されたビット送信速度（ｎ）より同じか小さい時、以前のビット送信速度（ｍ）を現在の測定されたビット送信速度（ｎ）に設定して、持続的に測定値「ｍ」に変化があれば、ずっとリアルタイムネットワークビット送信速度を測定して、もし、持続的に測定値「ｍ」の変化がなければ、これはサーバーが初期にデータをすぐに送信する区間以後に現われる緩やかな送信速度を維持すると判断する。

また、上述した、そして後述する、本発明による電子装置７００の多様な機能は、一つ以上のストリームプロセシング及び／又はアプリケーション特定集積回路（ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）を含むハードウェア及び／又はソフトウェア及び／又はこれらとの接続で実行される。

図８は、本発明の実施形態によるサーバー装置を示すブロック図である。
図８を参照すると、サーバー装置、は制御器８００、データベース８０２、インターフェース部８０４を含んで構成される。
制御器８００は、全体的なサーバーの動作を制御し、クライアントのマルチメディアコンテンツ要求に応じて、データベース８０２に保存されているコンテンツをインターフェース部８０４を通じてクライアントに送信する。
この時、制御器８００は送信特性によってマルチメディアコンテンツに対するストリーミングをクライアントに提供する。
データベース８０２は、複数のマルチメディアコンテンツを保存して、必要の時に制御器８００に提供する。
インターフェース部８０４は、サーバーとクライアントを接続するインターフェースとして、ネットワークソケット通信をサポートする。

本発明の実施形態では、ストリーミング方式に基づいてマルチメディアコンテンツ受信に対して説明したが、ダウンロード方式に基づいてマルチメディアコンテンツ受信にも適用することができる。

本発明の請求項及び／又は上記明細書に記載した実施形態による方法は、ハードウェア、ソフトウェア、又はハードウェアとソフトウェアの組み合わせの形態で具現することができる。
ソフトウェアで実装する場合、一つ以上のプログラム（ソフトウェアモジュール）を保存するコンピュータ判読可能保存媒体が提供される。
コンピュータ判読可能保存媒体に保存される一つ以上のプログラムは、電子装置内の一つ以上のプロセッサによって実行可能になるように構成される。
一つ以上のプログラムは、電子装置にとって、本発明の請求項及び／または上記明細書に記載した実施形態による方法を実行するための命令語を含む。

このようなプログラム（ソフトウェアモジュール、ソフトウェア）はランダムアクセスメモリー（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、フラッシュメモリーを含む非揮発性（Ｎｏｎ−Ｖｏｌａｔｉｌｅ）メモリー、ロム（ＲＯＭ、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、電気的消去可能プログラム可能ロム（ＥＥＰＲＯＭ、Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、磁気ディスク記憶装置（Ｍａｇｎｅｔｉｃ Ｄｉｓｃ Ｓｔｏｒａｇｅ Ｄｅｖｉｃｅ）、コンパクトディスクロム（ＣＤ−ＲＯＭ、Ｃｏｍｐａｃｔ Ｄｉｓｃ−ＲＯＭ）、デジタル多目的ディスク（ＤＶＤｓ、Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃｓ）または他の形態の光学記憶装置、磁気カセット（Ｍａｇｎｅｔｉｃ Ｃａｓｓｅｔｔｅ）に保存することができる。または、これらの一部又は全部の組み合わせで構成されたメモリーに保存することができる。また、それぞれの構成メモリーは複数個含むこともできる。

また、電子装置にインターネット（Ｉｎｔｅｒｎｅｔ）、イントラネット（Ｉｎｔｒａｎｅｔ）、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＬＡＮ（Ｗｉｄｅ ＬＡＮ）、又はＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）のような通信ネットワーク、又はこれらの組み合わせで構成された通信ネットワークを通じて接続できる取り付けられる保存装置に保存することができる。このような保存装置は外部ポートを通じて電子装置に接続することができる。
また、通信ネットワーク上の別途の保存装置がポータブル電子装置に接続することもできる。

上述のように、マルチメディアのストリーミングの時、サーバーの送信特性値を考慮してマルチメディアのストリーミング性能を向上させることができる利点がある。また、クライアントから多様なマルチメディアのストリーミングサービスを受信する時、さらに早い速度に再生可能であり、これにより、頻繁なバッファリングを減らすことができる。また、高画質マルチメディアデータのストリーミングの時により多くの効果が見られ、最近のタブレットＰＣなどのモバイル機器での性能を差別化することができる。また、すぐ受信した後にネットワーク接続を遮断することで、電力消費の改善機能を最大化することができる。

尚、本発明は、上述の実施形態に限られるものではない。本発明の技術的範囲から逸脱しない範囲内で多様に変更実施することが可能である。

１００ サーバー
１１０ ネットワーク
１２０ クライアント
７００ 電子装置
７１０ メモリー
７２０ プロセッサユニット
７２１ メモリーインターフェース
７２２ プロセッサ
７２３ 周辺装置インターフェース
７３０、７３１ （第１、第２）無線通信サブシステム
７５０ オーディオザブシステム
７６０ 外部ポート
７７０ 入出力システム
７８０ タッチスクリーン
７９０ その他の入力又は制御装置
７９１ センサー
７９３ カメラザブシステム
８００ 制御器
８０２ データベース
８０４ インターフェース部

Claims (32)

1. マルチメディアコンテンツを受信するための方法において、
   サーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間のビット送信速度に基づいて、前記マルチメディアコンテンツを要求する段階と、
   前記要求したマルチメディアコンテンツを前記サーバーから受信する段階とを有することを特徴とするマルチメディアコンテンツを受信するための方法。
2. 前記マルチメディアコンテンツを要求する段階は、前記サーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間のビット送信速度に基づいて、要求データ区間、ネットワークソケットの接続数、及び前記ネットワークソケットの接続時点の内の少なくとも一つを決定する段階と、
   前記の決定された要求データ区間、ネットワークソケットの接続数、及び前記ネットワークソケットの接続時点の内の少なくとも一つに従って、要求メッセージを前記サーバーに送信する段階とを含むことを特徴とする請求項１に記載のマルチメディアコンテンツを受信するための方法。
3. 前記ネットワークソケットの接続数は、ストリーミング再生のためのデータ量、及び、バッファーサイズに基づいて決定されることを特徴とする請求項２に記載のマルチメディアコンテンツを受信するための方法。
4. 前記ネットワークソケットの接続時点が決定されている場合、前記ネットワークソケットの接続時点は、前記要求データ区間が終了する前の時点であることを特徴とする請求項２に記載のマルチメディアコンテンツを受信するための方法。
5. 前記要求データ区間は、前記サーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間に決定されることを特徴とする請求項２に記載のマルチメディアコンテンツを受信するための方法。
6. 前記サーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間のビット送信速度が所定の範囲にない時、予め定義された前記ビット送信速度の測定値を用いてマルチメディアコンテンツを要求する段階をさらに有することを特徴とする請求項１に記載のマルチメディアコンテンツを受信するための方法。
7. 前記要求したマルチメディアコンテンツを前記サーバーから受信する時、ネットワークビット送信速度を測定する段階と、
   前記測定されたネットワークビット送信速度と以前のネットワークビット送信速度とを比較して、前記ビット送信速度が所定の範囲内どうかを判断する段階と、
   前記ビット送信速度が所定の範囲外である時点に基づいて、前記サーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間を決定する段階と、
   前記決定されたサーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間のビット送信速度を、前記ビット送信速度に更新する段階とをさらに有することを特徴とする請求項１に記載のマルチメディアコンテンツを受信するための方法。
8. 前記サーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間が決定された後、現在のネットワークソケットの接続を切って、
   前記更新されたサーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間のビット送信速度に基づいて、前記マルチメディアコンテンツを再要求する段階をさらに有することを特徴とする請求項７に記載のマルチメディアコンテンツを受信するための方法。
9. 前記要求したマルチメディアコンテンツを前記サーバーから受信する段階は、ＨＴＴＰを利用するストリーミング方式又はダウンロード方式に基づいてなされることを特徴とする請求項１に記載のマルチメディアコンテンツを受信するための方法。
10. メモリーと、
    一つ以上のプロセッサと、
    前記メモリーに保存され、前記一つ以上のプロセッサによって実行可能なように構成される一つ以上のモジュールとを有する電子装置であって、
    前記モジュールは、サーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間のビット送信速度に基づいて、マルチメディアコンテンツを要求し、
    前記要求したマルチメディアコンテンツを前記サーバーから受信する複数の命令語を含むことを特徴とする電子装置。
11. 前記マルチメディアコンテンツを要求する命令語は、前記サーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間のビット送信速度に基づいて、要求データ区間、ネットワークソケットの接続数、及び前記ネットワークソケットの接続時点の内の少なくとも一つを決定し、
    前記決定された要求データ区間、ネットワークソケットの接続数、及び前記ネットワークソケットの接続時点の内の少なくとも一つに従って、要求メッセージを前記サーバーに送信する命令語を含むことを特徴とする請求項１０に記載の電子装置。
12. 前記ネットワークソケットの接続数を決定する時は、ストリーミング再生のためのバッファーサイズに基づいてなされることを特徴とする請求項１１に記載の電子装置。
13. 前記ネットワークソケットの接続時点は、前記要求データ区間が終了する前の時点であることを特徴とする請求項１１に記載の電子装置。
14. 前記要求データ区間は、Ｉフレーム又はＧＯＰ単位に基づいて前記サーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間に決定されることを特徴とする請求項１１に記載の電子装置。
15. 前記サーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間のビット送信速度が所定の範囲にない時、予め定義された前記ネットワークビット送信速度の測定値を用いてマルチメディアコンテンツを要求する命令語をさらに含むことを特徴とする請求項１０に記載の電子装置。
16. 前記要求したマルチメディアコンテンツを前記サーバーから受信する時、ネットワークビット送信速度を測定して、
    前記計算されたネットワークビット送信速度と以前のネットワークビット送信速度とを比較して、前記ビット送信速度が持続的に変化するかどうかを判断し、
    前記ビット送信速度が持続的に変化しない時点に基づいて、前記サーバーがデータを送信する区間の中で初期の送信速度が所定値より高い区間を決定し、
    前記決定されたサーバーがデータを送信する区間の中で初期の送信速度が所定値より高い区間のビット送信速度を、前記ビット送信速度に更新する命令語をさらに含むことを特徴とする請求項１０に記載の電子装置。
17. 前記サーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間が決定された後、現在のネットワークソケットの接続を切って、
    前記更新されたサーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間のビット送信速度に基づいて、前記マルチメディアコンテンツを再要求する命令語をさらに含むことを特徴とする請求項１６に記載の電子装置。
18. 前記の要求したマルチメディアコンテンツ受信は、ＨＴＴＰを利用するストリーミング方式又はダウンロード方式に基づいてなされることを特徴とする請求項１０に記載の電子装置。
19. マルチメディアコンテンツを送信するための方法において、
    データを送信する区間の中で初期の送信速度が所定値よりも高い区間のビット送信速度に基づいて、クライアントから前記マルチメディアコンテンツの要求を受ける段階と、
    前記要求を受けたマルチメディアコンテンツを前記クライアントに送信する段階とを有することを特徴とするマルチメディアコンテンツを送信するための方法。
20. 前記サーバーのビット送信速度は、前記クライアントが、要求データ区間、ネットワークソケットの接続数、及び前記ネットワークソケットの接続時点の内の少なくとも一つを決定するのに利用されることを特徴とする請求項１９に記載のマルチメディアコンテンツを送信するための方法。
21. 前記ネットワークソケットの接続数を決定する時は、ストリーミング再生のためのバッファーサイズに基づいてなされることを特徴とする請求項２０に記載のマルチメディアコンテンツを送信するための方法。
22. 前記ネットワークソケットの接続時点は、前記要求データ区間が終了する前の時点であることを特徴とする請求項２０に記載のマルチメディアコンテンツを送信するための方法。
23. 前記要求データ区間は、Ｉフレーム又はＧＯＰ単位に基づいて前記サーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間に決定されることを特徴とする請求項２０に記載のマルチメディアコンテンツを送信するための方法。
24. 前記データを送信する区間の中で初期の送信速度が所定値よりも高い区間のビット送信速度を信頼することができない時、前記クライアントから、予め定義された統計データに基づいてマルチメディアコンテンツが要求される段階をさらに有することを特徴とする請求項１９に記載のマルチメディアコンテンツを送信するための方法。
25. 前記ビット送信速度に基づいて前記マルチメディアコンテンツが前記クライアントによって受信される時、現在のネットワークソケットの接続を切って、
    前記クライアントによって測定されたビット送信速度に基づいて、前記マルチメディアコンテンツが再要求される段階をさらに有することを特徴とする請求項１９に記載の方法。
26. マルチメディアコンテンツを送信するためのサーバー装置において、
    データを送信する区間の中で初期の送信速度が所定値よりも高い区間のビット送信速度に基づいて、クライアントから前記マルチメディアコンテンツの要求を受けて、
    前記要求を受けたマルチメディアコンテンツを前記クライアントに送信する制御部を有することを特徴とするサーバー装置。
27. 前記サーバーのビット送信速度は、前記クライアントが、要求データ区間、ネットワークソケットの接続数及び前記ネットワークソケットの接続時点の内の少なくとも一つを決定するのに利用されることを特徴とする請求項２６に記載のサーバー装置。
28. 前記ネットワークソケットの接続数を決定する時は、ストリーミング再生のためのバッファーサイズに基づいてなされることを特徴とする請求項２７に記載のサーバー装置。
29. 前記ネットワークソケットの接続時点は、前記要求データ区間が終了する前の時点であることを特徴とする請求項２７に記載のサーバー装置。
30. 前記要求データ区間は、前記サーバーがデータを送信する区間の中で初期の送信速度が所定値よりも高い区間に決定されることを特徴とする請求項２７に記載のサーバー装置。
31. 前記制御部は、前記データを送信する区間の中で初期の送信速度が所定値よりも高い区間のビット送信速度を信頼することができない時、前記クライアントから、予め定義された統計データに基づいてマルチメディアコンテンツが要求されることを特徴とする請求項２６に記載のサーバー装置。
32. 前記制御部は、前記ビット送信速度に基づいて前記マルチメディアコンテンツが前記クライアントによって受信される時、現在のネットワークソケットの接続を切って、
    前記クライアントによって測定されたビット送信速度に基づいて、前記マルチメディアコンテンツが再要求されることを特徴とする請求項２６に記載のサーバー装置。

Images