マルチメディアメッセージ処理サービスのための方法及びシステム
本発明は、通常はメッセージの開始部分であるマルチメディアメッセージの一部がモバイル端末に予め送信及び格納されることを可能にする。ユーザがメッセージの閲覧を所望するとき、ローカルに格納されているメッセージ部分が即座に再生されると同時に、モバイル端末にあるユーザエージェントがストリーミング技術を利用して、残りのコンテンツを取得するためメディアサーバにアクセスする。これにより、再生には認識可能な遅延はほとんど発生しないため、メッセージ全体がローカルに格納されているという印象をユーザに与えることができ、より良好なユーザ体感を提供することができる。コンテンツのダウンロードされる部分は、マルチメディアメッセージ全体の一部、あるいは宣伝として第三者により提供される無関係のリッチメディアメッセージとすることができる。このようにして、モバイル端末上のローカルな記憶スペースの利用がより効率的なものとなるであろう。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に無線通信技術に関し、より詳細には、マルチメディアメッセージ処理サービスのための方法及びシステムに関する。
【背景技術】
【０００２】
携帯電話などのモバイル端末は、他の人々と通信するための一般的な手段となってきている。現在、多数のサービスがモバイル端末上で利用可能である。これら一般的サービスの１つとして、画像、発話、音声及び映像コンテンツを含むモバイルマルチメディアサービス（ＭＭＳ）がある。このサービスは、ユーザ間のメッセージ処理を向上させるものであり、コンテンツプッシュ（ｃｏｎｔｅｎｔ−ｐｕｓｈ）サービスへの下準備を行う。ますます多くのリッチメディア対応のモバイル端末とネットワーク構成が利用可能になる従い、オンデマンドモバイルマルチメディアサービスが、モバイルブラウジング処理及びコンテンツアクセス処理を向上させるメディアストリーミング及びダウンロード技術を介しユーザに提供されるであろう。
【０００３】
高機能マルチメディアサービスは、モバイルネットワークにおける使用、運営者収入及び帯域幅の利用を促進することが期待される。しかしながら現在、リッチメディアメッセージは、比較的小さなユーザスペース（典型的には、２Ｍバイト）しか備えないモバイル端末がローカルに格納するには大きくなり過ぎている。例えば、毎秒１０フレーム（１０ｆｐｓ）で再生される２分間のＭＰＥＧ−４符号化ＱＣＩＦ（Ｑｕａｒｔｅｒ Ｃｏｍｍｏｎ Ｉｎｔｅｒｍｅｄｉａｔｅ Ｆｏｒｍａｔ）は、約１．５Ｍバイトのスペースを要するであろう。このことは、市場で販売されている大部分の携帯電話にとっては、様々なアプリケーションによりその小さな記憶スペースが共有されているため許容できないものである。
【０００４】
図１は、第３世代システムの仕様を策定する組織である３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）により規定されるようなＭＭＳ基準アーキテクチャ１０を示す。図１において、ＭＭＳリレイ/サーバ２０は、課金システム３２、ＭＭＳ付加価値サービス（ＶＡＳ）アプリケーション３４、ＭＭＳユーザデータベース３６、ＨＬＲ（Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ）３８、及び電子メール、ファックス、ＳＭＳなどの機能を提供する複数の外部サーバ４２〜４８を有する各種要素に接続される。サーバ４８は、映像を含むリッチメディアコンテンツを格納するメディアサーバである。あるいは、サーバ４８は、ＭＭＳリレイ/サーバ２０に配置されてもよいし、あるいはウェブサーバであってもよい。ＭＭＳリレイ/サーバ２０はまた、他のＭＭＳＥ（マルチメディアメッセージサービス環境）にある「外部の」ＭＭＳリレイ/サーバ４０に接続される。ＭＭＳＥは、一元的な管理制御下にあるＭＭＳに固有のネットワーク要素群を意味し、複数のＭＭＳリレイ/サーバを有するかもしれない。ＭＭＳユーザエージェントＡ、Ｂ及びＣは、ＭＭＳリレイ/サーバを介し互いにマルチメディアメッセージを送信することができる。ＭＭＳユーザエージェントは、ユーザのためにＭＭＳに固有の処理を実行する外部装置またはモバイル端末（例えば、ユーザ装置（ＵＥ）、モバイルステーション（ＭＳ）など）上のアプリケーションを意味する。
【０００５】
図２は、マルチメディアメッセージ（ＭＭ）送信プロセスのフローチャートである。それは、従来方法によるストリーミングを介したマルチメディアメッセージの送信方法を示す。ＭＭＳメッセージ通知を受信すると、ＭＭＳユーザエージェントは、関連するモバイル端末のユーザに新しいＭＭが到着したことを通知する（ステップ１０２）。ユーザが当該ＭＭの閲覧を選ぶと（ステップ１０６）、ＭＭに付属する添付データが構文解析され（ステップ１１２）、ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）が添付されているか判断する（ステップ１１６）。ＳＤＰファイルには、セッションの記述（セッション名、作成者などを含む）、提供されるメディアのタイプ及びメディアのビットレートが含まれる。ＳＤＰファイルが添付されていない場合、それは、ＭＭがプレーンテキストのみを有するメッセージなどのストリーミング不可であるコンテンツを含むためであるかもしれない。このような場合、ＭＭＳユーザエージェントは、当該ＭＭを即座に提供する。他方、ＳＤＰファイルが添付されている場合、それを構文解析する（ステップ１２２）。ＳＤＰファイルからのパラメータにより、ＭＭＳユーザエージェントは、ＲＴＰ（Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ）/ＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）プロトコルを介しメディアサーバとモバイル端末を接続し（ステップ１２６）、ストリーミングを介しメディアサーバからコンテンツを受信することができる（ステップ１３２）。同時に、ＭＭＳユーザエージェントは、当該ＭＭを提供することができる（ステップ１３６）。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、無線環境におけるメディアサーバからのライブによるストリーミングは、２分間のＭＰＥＧ−４ＱＣＩＦ映像メッセージに対して約８〜１５秒というかなりの時間を要する。より大きな映像メッセージでは、２分間の各映像セグメントが到着するのに８〜１５秒間待機しなければならないため、ユーザは不連続なセグメントにより当該メッセージを閲覧しなければならなくなるであろう。各映像メッセージに対し６〜１５秒間の初期的な待機時間を通常必要とするインターネット上の映像ストリーミングが実行されると、映像メッセージのサイズと無関係に、無線環境における遅延は許容できないほど長いものとなり、ユーザはいらいらしながら待機しなければならなくなるであろう。
【０００７】
従って、ＭＭの受信及び閲覧に関するユーザの体感を大きく向上させるＭＭＳシステムが必要とされる。
【課題を解決するための手段】
【０００８】
本発明は、通常はメッセージの開始部分（例えば、メッセージの最初の１０秒間など）であるマルチメディアメッセージの一部がモバイル端末に予め送信及び格納されることを可能にする。例えば、１０秒間のＭＰＥＧ−４符号化ＱＣＩＦ映像は、約８０〜１２０Ｋスペースを占有するが、これはメッセージ全体を格納するのに要する容量よりはるかに小さい。ユーザがメッセージの閲覧を所望するとき、ローカルに格納されているメッセージの当該部分が即座に再生されると同時に、モバイル端末にあるユーザエージェントがストリーミング技術を利用して、残りのコンテンツを取得するためメディアサーバにアクセスする。
【発明の効果】
【０００９】
これにより、再生には認識可能な遅延はほとんど発生しないため、メッセージ全体がローカルに格納されているという印象をユーザに与えることができ、より良好なユーザ体感を提供することができる。コンテンツのダウンロードされる部分は、マルチメディアメッセージ全体の一部、あるいは宣伝として第三者により提供される無関係のリッチメディアメッセージとすることができる。このようにして、モバイル端末上のローカルな記憶スペースの利用がより効率的なものとなるであろう。
【００１０】
本発明のより完全な理解と共に他の課題および効果は、添付された図面に関してなされる以下の説明及び請求項を参照することにより明確化され、理解されるであろう。
【発明を実施するための最良の形態】
【００１１】
本発明は、通常はメッセージの開始部分（例えば、メッセージの最初の１０秒間など）であるマルチメディアメッセージ（ＭＭ）の一部がモバイル端末またはユーザ装置（ＵＥ）に予め送信されることを可能にする。例えば、１０秒間のＭＰＥＧ−４符号化ＱＣＩＦ映像は、約８０〜１２０Ｋスペースを占有するが、これはメッセージ全体を格納するのに要する容量よりはるかに小さい。ユーザがＭＭの閲覧を所望するとき、ローカルに格納されているメッセージの当該部分が即座に再生されると同時に、ＵＥ上のユーザエージェントが３ＧＰＰ標準仕様に規定されるストリーミング技術を利用して、残りのコンテンツを取得するためメディアサーバにアクセスする。これにより、再生には認識可能な遅延はほとんど発生しないため、メッセージ全体がローカルに格納されているという印象をユーザに与えることができ、より良好なユーザ体感を提供することができる。コンテンツの予めダウンロードされる部分は、マルチメディアメッセージ全体の一部、あるいは広告として第三者により提供される無関係のリッチメディアメッセージとすることができる。
【００１２】
図３は、本発明の第１実施例によるＭＭの送受信に関して、モバイル端末上のＭＭＳユーザエージェントにより実行されるプロセス２００を示すフローチャートである。図示されるように、ユーザエージェントがＭＭＳメッセージ通知を受信した後（ステップ２０２）、ユーザエージェントはメッセージ通知の添付データの構文解析を試行し（ステップ２０６）、ＳＤＰファイルが添付されているか判断する（ステップ２１２）。前述のように、ＳＤＰファイルには、セッションの記述（セッション名、作成者など）、提供されるメディアのタイプ及びメディアのビットレートが含まれる。例えば、ＭＭがテキストメッセージのみなどのストリーミング不可であるコンテンツを含むなどの理由から、ＳＤＰファイルが添付されていない場合、ユーザエージェントはユーザに新たに到着したＭＭを通知し（ステップ２２０）、ユーザはメッセージを閲覧する選択肢を有することが可能となる。
【００１３】
しかしながら、ＳＤＰファイルが添付され、ユーザエージェントが当該ＳＤＰファイルを構文解析した後、リッチメディアコンテンツへのリンクがＳＤＰファイルに含まれていると認めると（ステップ２１４）、ＲＴＰプロトコルを利用して、例えば１５秒間などの所定の期間に対するメッセージ部分をメディアサーバから即座にダウンロードしようとする（ステップ２２２）。ユーザエージェントはまた、ネットワーク特性、モバイル端末容量及びユーザ選好に関する情報を有するモバイル端末内のデータベースに問い合わせることにより、ＭＭの当該部分がどの程度予め取得されるべきか判断するようにしてもよい。その後、ダウンロードが成功したか判断される（ステップ２３２）。ダウンロードがネットワークやメディアサーバに関する問題などにより失敗した場合、ユーザエージェントはユーザに新たに到着したＭＭを通知し（ステップ２２０）、図２に示されるような従来方法によりメッセージを送信する。
【００１４】
他方、ダウンロードが成功すると、ＭＭの１５秒分などのＭＭの一部を受信することにより、ユーザエージェントは当該受信部分をローカルに保存し、以降の利用のため、ローカルに格納されたコンテンツサイズ、当該コンテンツの残りの部分を取得する場所、残りの部分のサイズなどを記述するなどによりＳＤＰファイルを変更する（ステップ２３６）。その後、ユーザエージェントは、新たなＭＭが到着したことをユーザに通知する（ステップ２２０）。ユーザがＭＭの閲覧を所望する場合、ユーザエージェントは、当該受信部分を即座に再生すると同時に、ＭＭの残りの部分に対して従来方法によりメディアサーバとのストリーミング接続を設定するようにする。大部分の状況下では、ＭＭの受信部分が再生されている期間中にはメディアサーバとの接続を設定するための十分な時間があり、このため、ユーザはＭＭの残りのコンテンツをシームレスに閲覧することができるであろう。このようにして、ユーザは、ＭＭの閲覧を開始するのに要した８〜１５秒の待機時間を解消することにより、ＭＭに迅速にアクセスすることができるであろう。本発明はまた、ＭＭをローカルに閲覧しているという印象をユーザに与え、これにより、典型的なユーザのイライラを緩和することができるであろう。ユーザが再生されているコンテンツが面白くないと感じた場合、さらに時間を費やすことなく接続を即座に中断することができる。
【００１５】
図４は、本発明の第２実施例によるＭＭＳサーバ（例えば、ＭＭＳリレイ/サーバ２０など）により実行されるＭＭ送信プロセス３００を示すフローチャートである。ＭＭを受信すると（ステップ３０２）、ＭＭＳサーバはリッチメディアコンテンツが含まれているか判断する（ステップ３０６）。テキストのみしか含んでいない場合、ＭＭをユーザに即座に利用可能とするため、ＭＭＳサーバは変更することなく当該メッセージを直接ＵＥに送信する（ステップ３１０）。他方、テキスト以外の情報を有する場合、ＭＭＳサーバは当該メッセージを変更する必要がある。ＭＭＳサーバは、まずリッチメディアコンテンツを有する当該メッセージをメディアサーバなどの予め選択されている場所に格納し（ステップ３１２）、最初の１５秒分などの当該メッセージの一部をコピーする（ステップ３１６）。その後、ＭＭＳサーバは、メッセージの位置、メッセージのコピーされた部分の長さ及び他の情報を含むＳＤＰファイルを生成する（ステップ３２６）。その後、ＭＭＳサーバは、新たなＭＭを生成するため、もとのメッセージのコピーされた部分にこのＳＤＰファイルを添付する（ステップ３３２）。あるいは、ＭＭＳサーバはまた、広告などの第三者のコンテンツにＳＤＰファイルを添付するようにしてもよい。この新たに生成されたＭＭは、ユーザエージェントに送信される（ステップ３１０）。
【００１６】
ＭＭＳサーバから新たなＭＭを受信すると、ユーザエージェントは、ダウンロードされたメッセージと同様にしてそれを保存する。ユーザがメッセージを閲覧しようとするとき、ユーザエージェントはまず、ローカルに格納されているコンテンツを再生すると同時に、添付されたＳＤＰファイルにより与えられる情報を利用して、メディアサーバとのストリーミング接続を確立しようとする。これにより、ユーザは当該メッセージの残りのコンテンツをシームレスに閲覧することが可能となるであろう。このようにして、モバイル端末上のローカル記憶スペースをより効率的に利用することが可能となる。
【００１７】
上述のように、ユーザエージェントにより受信された部分的にダウンロードされたコンテンツは、もとのＭＭの一部であるか、あるいは第三者により広告として与えられた無関係なリッチメディアメッセージとすることができる。後者の場合、第三者は、ユーザが添付した広告をすべて閲覧すれば、ユーザが無料でＭＭにアクセスすることを許可するかもしれない。同様にして、複数のＭＭが同一の広告などのローカルに格納されている同一のコンテンツにリンクすることができる。
【００１８】
本発明が特定の実施例に関して説明されたが、上記説明に基づき多数の代替、改良及び変形が当業者に明らかとなるは明白である。従って、そのようなすべての代替、改良及び変形は添付された請求項の趣旨及び範囲に属するものとする。
【図面の簡単な説明】
【００１９】
【図１】図１は、３ＧＰＰにより規定されるようなＭＭＳ基準構成を示す。
【図２】図２は、従来のマルチメディアメッセージ送信プロセスのフローチャートである。
【図３】図３は、本発明の第１実施例によるマルチメディアメッセージの送受信に関してＭＭＳユーザエージェントにより実行されるプロセスを示すフローチャートである。
【図４】図４は、本発明の第２実施例によるＭＭＳサーバにより実行されるマルチメディアメッセージ送信プロセスを示すフローチャートである。
【技術分野】
【０００１】
本発明は、一般に無線通信技術に関し、より詳細には、マルチメディアメッセージ処理サービスのための方法及びシステムに関する。
【背景技術】
【０００２】
携帯電話などのモバイル端末は、他の人々と通信するための一般的な手段となってきている。現在、多数のサービスがモバイル端末上で利用可能である。これら一般的サービスの１つとして、画像、発話、音声及び映像コンテンツを含むモバイルマルチメディアサービス（ＭＭＳ）がある。このサービスは、ユーザ間のメッセージ処理を向上させるものであり、コンテンツプッシュ（ｃｏｎｔｅｎｔ−ｐｕｓｈ）サービスへの下準備を行う。ますます多くのリッチメディア対応のモバイル端末とネットワーク構成が利用可能になる従い、オンデマンドモバイルマルチメディアサービスが、モバイルブラウジング処理及びコンテンツアクセス処理を向上させるメディアストリーミング及びダウンロード技術を介しユーザに提供されるであろう。
【０００３】
高機能マルチメディアサービスは、モバイルネットワークにおける使用、運営者収入及び帯域幅の利用を促進することが期待される。しかしながら現在、リッチメディアメッセージは、比較的小さなユーザスペース（典型的には、２Ｍバイト）しか備えないモバイル端末がローカルに格納するには大きくなり過ぎている。例えば、毎秒１０フレーム（１０ｆｐｓ）で再生される２分間のＭＰＥＧ−４符号化ＱＣＩＦ（Ｑｕａｒｔｅｒ Ｃｏｍｍｏｎ Ｉｎｔｅｒｍｅｄｉａｔｅ Ｆｏｒｍａｔ）は、約１．５Ｍバイトのスペースを要するであろう。このことは、市場で販売されている大部分の携帯電話にとっては、様々なアプリケーションによりその小さな記憶スペースが共有されているため許容できないものである。
【０００４】
図１は、第３世代システムの仕様を策定する組織である３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）により規定されるようなＭＭＳ基準アーキテクチャ１０を示す。図１において、ＭＭＳリレイ/サーバ２０は、課金システム３２、ＭＭＳ付加価値サービス（ＶＡＳ）アプリケーション３４、ＭＭＳユーザデータベース３６、ＨＬＲ（Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ）３８、及び電子メール、ファックス、ＳＭＳなどの機能を提供する複数の外部サーバ４２〜４８を有する各種要素に接続される。サーバ４８は、映像を含むリッチメディアコンテンツを格納するメディアサーバである。あるいは、サーバ４８は、ＭＭＳリレイ/サーバ２０に配置されてもよいし、あるいはウェブサーバであってもよい。ＭＭＳリレイ/サーバ２０はまた、他のＭＭＳＥ（マルチメディアメッセージサービス環境）にある「外部の」ＭＭＳリレイ/サーバ４０に接続される。ＭＭＳＥは、一元的な管理制御下にあるＭＭＳに固有のネットワーク要素群を意味し、複数のＭＭＳリレイ/サーバを有するかもしれない。ＭＭＳユーザエージェントＡ、Ｂ及びＣは、ＭＭＳリレイ/サーバを介し互いにマルチメディアメッセージを送信することができる。ＭＭＳユーザエージェントは、ユーザのためにＭＭＳに固有の処理を実行する外部装置またはモバイル端末（例えば、ユーザ装置（ＵＥ）、モバイルステーション（ＭＳ）など）上のアプリケーションを意味する。
【０００５】
図２は、マルチメディアメッセージ（ＭＭ）送信プロセスのフローチャートである。それは、従来方法によるストリーミングを介したマルチメディアメッセージの送信方法を示す。ＭＭＳメッセージ通知を受信すると、ＭＭＳユーザエージェントは、関連するモバイル端末のユーザに新しいＭＭが到着したことを通知する（ステップ１０２）。ユーザが当該ＭＭの閲覧を選ぶと（ステップ１０６）、ＭＭに付属する添付データが構文解析され（ステップ１１２）、ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）が添付されているか判断する（ステップ１１６）。ＳＤＰファイルには、セッションの記述（セッション名、作成者などを含む）、提供されるメディアのタイプ及びメディアのビットレートが含まれる。ＳＤＰファイルが添付されていない場合、それは、ＭＭがプレーンテキストのみを有するメッセージなどのストリーミング不可であるコンテンツを含むためであるかもしれない。このような場合、ＭＭＳユーザエージェントは、当該ＭＭを即座に提供する。他方、ＳＤＰファイルが添付されている場合、それを構文解析する（ステップ１２２）。ＳＤＰファイルからのパラメータにより、ＭＭＳユーザエージェントは、ＲＴＰ（Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ）/ＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）プロトコルを介しメディアサーバとモバイル端末を接続し（ステップ１２６）、ストリーミングを介しメディアサーバからコンテンツを受信することができる（ステップ１３２）。同時に、ＭＭＳユーザエージェントは、当該ＭＭを提供することができる（ステップ１３６）。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、無線環境におけるメディアサーバからのライブによるストリーミングは、２分間のＭＰＥＧ−４ＱＣＩＦ映像メッセージに対して約８〜１５秒というかなりの時間を要する。より大きな映像メッセージでは、２分間の各映像セグメントが到着するのに８〜１５秒間待機しなければならないため、ユーザは不連続なセグメントにより当該メッセージを閲覧しなければならなくなるであろう。各映像メッセージに対し６〜１５秒間の初期的な待機時間を通常必要とするインターネット上の映像ストリーミングが実行されると、映像メッセージのサイズと無関係に、無線環境における遅延は許容できないほど長いものとなり、ユーザはいらいらしながら待機しなければならなくなるであろう。
【０００７】
従って、ＭＭの受信及び閲覧に関するユーザの体感を大きく向上させるＭＭＳシステムが必要とされる。
【課題を解決するための手段】
【０００８】
本発明は、通常はメッセージの開始部分（例えば、メッセージの最初の１０秒間など）であるマルチメディアメッセージの一部がモバイル端末に予め送信及び格納されることを可能にする。例えば、１０秒間のＭＰＥＧ−４符号化ＱＣＩＦ映像は、約８０〜１２０Ｋスペースを占有するが、これはメッセージ全体を格納するのに要する容量よりはるかに小さい。ユーザがメッセージの閲覧を所望するとき、ローカルに格納されているメッセージの当該部分が即座に再生されると同時に、モバイル端末にあるユーザエージェントがストリーミング技術を利用して、残りのコンテンツを取得するためメディアサーバにアクセスする。
【発明の効果】
【０００９】
これにより、再生には認識可能な遅延はほとんど発生しないため、メッセージ全体がローカルに格納されているという印象をユーザに与えることができ、より良好なユーザ体感を提供することができる。コンテンツのダウンロードされる部分は、マルチメディアメッセージ全体の一部、あるいは宣伝として第三者により提供される無関係のリッチメディアメッセージとすることができる。このようにして、モバイル端末上のローカルな記憶スペースの利用がより効率的なものとなるであろう。
【００１０】
本発明のより完全な理解と共に他の課題および効果は、添付された図面に関してなされる以下の説明及び請求項を参照することにより明確化され、理解されるであろう。
【発明を実施するための最良の形態】
【００１１】
本発明は、通常はメッセージの開始部分（例えば、メッセージの最初の１０秒間など）であるマルチメディアメッセージ（ＭＭ）の一部がモバイル端末またはユーザ装置（ＵＥ）に予め送信されることを可能にする。例えば、１０秒間のＭＰＥＧ−４符号化ＱＣＩＦ映像は、約８０〜１２０Ｋスペースを占有するが、これはメッセージ全体を格納するのに要する容量よりはるかに小さい。ユーザがＭＭの閲覧を所望するとき、ローカルに格納されているメッセージの当該部分が即座に再生されると同時に、ＵＥ上のユーザエージェントが３ＧＰＰ標準仕様に規定されるストリーミング技術を利用して、残りのコンテンツを取得するためメディアサーバにアクセスする。これにより、再生には認識可能な遅延はほとんど発生しないため、メッセージ全体がローカルに格納されているという印象をユーザに与えることができ、より良好なユーザ体感を提供することができる。コンテンツの予めダウンロードされる部分は、マルチメディアメッセージ全体の一部、あるいは広告として第三者により提供される無関係のリッチメディアメッセージとすることができる。
【００１２】
図３は、本発明の第１実施例によるＭＭの送受信に関して、モバイル端末上のＭＭＳユーザエージェントにより実行されるプロセス２００を示すフローチャートである。図示されるように、ユーザエージェントがＭＭＳメッセージ通知を受信した後（ステップ２０２）、ユーザエージェントはメッセージ通知の添付データの構文解析を試行し（ステップ２０６）、ＳＤＰファイルが添付されているか判断する（ステップ２１２）。前述のように、ＳＤＰファイルには、セッションの記述（セッション名、作成者など）、提供されるメディアのタイプ及びメディアのビットレートが含まれる。例えば、ＭＭがテキストメッセージのみなどのストリーミング不可であるコンテンツを含むなどの理由から、ＳＤＰファイルが添付されていない場合、ユーザエージェントはユーザに新たに到着したＭＭを通知し（ステップ２２０）、ユーザはメッセージを閲覧する選択肢を有することが可能となる。
【００１３】
しかしながら、ＳＤＰファイルが添付され、ユーザエージェントが当該ＳＤＰファイルを構文解析した後、リッチメディアコンテンツへのリンクがＳＤＰファイルに含まれていると認めると（ステップ２１４）、ＲＴＰプロトコルを利用して、例えば１５秒間などの所定の期間に対するメッセージ部分をメディアサーバから即座にダウンロードしようとする（ステップ２２２）。ユーザエージェントはまた、ネットワーク特性、モバイル端末容量及びユーザ選好に関する情報を有するモバイル端末内のデータベースに問い合わせることにより、ＭＭの当該部分がどの程度予め取得されるべきか判断するようにしてもよい。その後、ダウンロードが成功したか判断される（ステップ２３２）。ダウンロードがネットワークやメディアサーバに関する問題などにより失敗した場合、ユーザエージェントはユーザに新たに到着したＭＭを通知し（ステップ２２０）、図２に示されるような従来方法によりメッセージを送信する。
【００１４】
他方、ダウンロードが成功すると、ＭＭの１５秒分などのＭＭの一部を受信することにより、ユーザエージェントは当該受信部分をローカルに保存し、以降の利用のため、ローカルに格納されたコンテンツサイズ、当該コンテンツの残りの部分を取得する場所、残りの部分のサイズなどを記述するなどによりＳＤＰファイルを変更する（ステップ２３６）。その後、ユーザエージェントは、新たなＭＭが到着したことをユーザに通知する（ステップ２２０）。ユーザがＭＭの閲覧を所望する場合、ユーザエージェントは、当該受信部分を即座に再生すると同時に、ＭＭの残りの部分に対して従来方法によりメディアサーバとのストリーミング接続を設定するようにする。大部分の状況下では、ＭＭの受信部分が再生されている期間中にはメディアサーバとの接続を設定するための十分な時間があり、このため、ユーザはＭＭの残りのコンテンツをシームレスに閲覧することができるであろう。このようにして、ユーザは、ＭＭの閲覧を開始するのに要した８〜１５秒の待機時間を解消することにより、ＭＭに迅速にアクセスすることができるであろう。本発明はまた、ＭＭをローカルに閲覧しているという印象をユーザに与え、これにより、典型的なユーザのイライラを緩和することができるであろう。ユーザが再生されているコンテンツが面白くないと感じた場合、さらに時間を費やすことなく接続を即座に中断することができる。
【００１５】
図４は、本発明の第２実施例によるＭＭＳサーバ（例えば、ＭＭＳリレイ/サーバ２０など）により実行されるＭＭ送信プロセス３００を示すフローチャートである。ＭＭを受信すると（ステップ３０２）、ＭＭＳサーバはリッチメディアコンテンツが含まれているか判断する（ステップ３０６）。テキストのみしか含んでいない場合、ＭＭをユーザに即座に利用可能とするため、ＭＭＳサーバは変更することなく当該メッセージを直接ＵＥに送信する（ステップ３１０）。他方、テキスト以外の情報を有する場合、ＭＭＳサーバは当該メッセージを変更する必要がある。ＭＭＳサーバは、まずリッチメディアコンテンツを有する当該メッセージをメディアサーバなどの予め選択されている場所に格納し（ステップ３１２）、最初の１５秒分などの当該メッセージの一部をコピーする（ステップ３１６）。その後、ＭＭＳサーバは、メッセージの位置、メッセージのコピーされた部分の長さ及び他の情報を含むＳＤＰファイルを生成する（ステップ３２６）。その後、ＭＭＳサーバは、新たなＭＭを生成するため、もとのメッセージのコピーされた部分にこのＳＤＰファイルを添付する（ステップ３３２）。あるいは、ＭＭＳサーバはまた、広告などの第三者のコンテンツにＳＤＰファイルを添付するようにしてもよい。この新たに生成されたＭＭは、ユーザエージェントに送信される（ステップ３１０）。
【００１６】
ＭＭＳサーバから新たなＭＭを受信すると、ユーザエージェントは、ダウンロードされたメッセージと同様にしてそれを保存する。ユーザがメッセージを閲覧しようとするとき、ユーザエージェントはまず、ローカルに格納されているコンテンツを再生すると同時に、添付されたＳＤＰファイルにより与えられる情報を利用して、メディアサーバとのストリーミング接続を確立しようとする。これにより、ユーザは当該メッセージの残りのコンテンツをシームレスに閲覧することが可能となるであろう。このようにして、モバイル端末上のローカル記憶スペースをより効率的に利用することが可能となる。
【００１７】
上述のように、ユーザエージェントにより受信された部分的にダウンロードされたコンテンツは、もとのＭＭの一部であるか、あるいは第三者により広告として与えられた無関係なリッチメディアメッセージとすることができる。後者の場合、第三者は、ユーザが添付した広告をすべて閲覧すれば、ユーザが無料でＭＭにアクセスすることを許可するかもしれない。同様にして、複数のＭＭが同一の広告などのローカルに格納されている同一のコンテンツにリンクすることができる。
【００１８】
本発明が特定の実施例に関して説明されたが、上記説明に基づき多数の代替、改良及び変形が当業者に明らかとなるは明白である。従って、そのようなすべての代替、改良及び変形は添付された請求項の趣旨及び範囲に属するものとする。
【図面の簡単な説明】
【００１９】
【図１】図１は、３ＧＰＰにより規定されるようなＭＭＳ基準構成を示す。
【図２】図２は、従来のマルチメディアメッセージ送信プロセスのフローチャートである。
【図３】図３は、本発明の第１実施例によるマルチメディアメッセージの送受信に関してＭＭＳユーザエージェントにより実行されるプロセスを示すフローチャートである。
【図４】図４は、本発明の第２実施例によるＭＭＳサーバにより実行されるマルチメディアメッセージ送信プロセスを示すフローチャートである。
【特許請求の範囲】
【請求項１】
モバイル端末であって、
入力マルチメディアメッセージの通知を受信する手段と、
前記入力メッセージがリッチメディアコンテンツを有するか判断する手段と、
前記入力メッセージがリッチメディアコンテンツを有する場合、ユーザが当該端末上で閲覧する所定の時間を有する前記入力メッセージの一部をダウンロードする手段と、
を有することを特徴とする端末。
【請求項２】
請求項１記載のモバイル端末であって、
前記判断する手段は、前記入力メッセージがリッチメディアコンテンツを有するか判断するため、前記入力メッセージのメディアタイプに関する情報を有する前記通知の添付データを構文解析する手段を有することを特徴とする端末。
【請求項３】
請求項２記載のモバイル端末であって、
前記添付データは、ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ファイルを有することを特徴とする端末。
【請求項４】
請求項１記載のモバイル端末であって、さらに、
ユーザのコマンドに応答して、前記入力メッセージのダウンロードされた部分を当該モバイル端末上に表示する手段を有することを特徴とする端末。
【請求項５】
請求項４記載のモバイル端末であって、さらに、
記憶要素と、
前記入力メッセージのダウンロードされた部分を前記記憶要素上に保存する手段と、
を有することを特徴とする端末。
【請求項６】
請求項１記載のモバイル端末であって、さらに、
前記入力メッセージをユーザに通知する手段を有することを特徴とする端末。
【請求項７】
請求項１記載のモバイル端末であって、さらに、
前記入力メッセージの残りにアクセスする手段を有することを特徴とする端末。
【請求項８】
請求項７記載のモバイル端末であって、
前記アクセスする手段は、該アクセスする手段によるアクセスのため、前記入力メッセージの開始ポイントを示すよう前記入力メッセージの添付ファイルを修正する手段を有することを特徴とする端末。
【請求項９】
請求項８記載のモバイル端末であって、
前記添付ファイルは、ＳＤＰファイルを有することを特徴とする端末。
【請求項１０】
請求項１記載のモバイル端末であって、さらに、
前記入力メッセージの残りへのアクセスのため、前記入力メッセージを格納しているサーバと当該モバイル端末を接続する手段を有し、
前記所定の時間は、前記ユーザが前記入力メッセージの全体を連続的に閲覧するのを可能にするため、前記接続する手段が当該モバイル端末と前記サーバを接続するのに十分な長さを有することを特徴とする端末。
【請求項１１】
入力マルチメディアメッセージを受信する手段と、
前記入力メッセージがリッチメディアコンテンツを有するか判断する手段と、
前記入力メッセージがリッチメディアコンテンツを有する場合、新たなマルチメディアメッセージを受信モバイル端末に送信する手段と、
を有することを特徴とするマルチメディアメッセージサービスサーバ。
【請求項１２】
請求項１１記載のマルチメディアメッセージサービスサーバであって、
前記新たなマルチメディアメッセージは、所定の時間を有する前記入力メッセージの一部を有することを特徴とするサーバ。
【請求項１３】
請求項１１記載のマルチメディアメッセージサービスサーバであって、
前記新たなマルチメディアメッセージは、所定の時間を有する広告を有することを特徴とするサーバ。
【請求項１４】
請求項１１記載のマルチメディアメッセージサービスサーバであって、さらに、
前記入力メッセージがアクセス可能な場所を示す前記新たなマルチメディアメッセージへの添付ファイルを生成する手段を有することを特徴とするサーバ。
【請求項１５】
請求項１４記載のマルチメディアメッセージサービスサーバであって、
前記添付ファイルは、ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ファイルを有することを特徴とするサーバ。
【請求項１６】
請求項１１記載のマルチメディアメッセージサービスサーバであって、さらに、
前記新たなマルチメディアメッセージを生成する手段を有することを特徴とするサーバ。
【請求項１７】
請求項１６記載のマルチメディアメッセージサービスサーバであって、さらに、
前記入力メッセージを予め選択された場所に保存する手段と、
前記新たなマルチメディアメッセージに含めるため、前記入力メッセージの一部をコピーする手段と、
を有することを特徴とするサーバ。
【請求項１８】
請求項１７記載のマルチメディアメッセージサービスサーバであって、
前記予め選択された場所は、メディアサーバの記憶要素に存在することを特徴とするサーバ。
【請求項１９】
請求項１２記載のマルチメディアメッセージサービスサーバであって、
前記所定の時間は、ユーザが前記入力メッセージの全体を連続的に前記端末上で閲覧するのを可能にするため、前記受信モバイル端末が前記入力メッセージを格納しているサーバと接続するのに十分な長さを有することを特徴とするサーバ。
【請求項２０】
請求項１３記載のマルチメディアメッセージサービスサーバであって、
前記所定の時間は、ユーザが前記入力メッセージの全体を実質連続的に前記端末上で閲覧するのを可能にするため、前記受信モバイル端末が前記入力メッセージを格納しているサーバと接続するのに実質的に要する時間と同一であることを特徴とするサーバ。
【請求項２１】
モバイル端末において実行される方法であって、
入力マルチメディアメッセージの通知を受信するステップと、
前記入力メッセージがリッチメディアコンテンツを有するか判断するステップと、
前記入力メッセージがリッチメディアコンテンツを有する場合、ユーザが前記端末上で閲覧する所定の時間を有する前記入力メッセージの一部をダウンロードするステップと、
を有することを特徴とする方法。
【請求項２２】
請求項２１記載の方法であって、
前記判断するステップは、前記入力メッセージがリッチメディアコンテンツを有するか判断するため、前記入力メッセージのメディアタイプに関する情報を有する前記通知の添付データを構文解析するステップを有することを特徴とする方法。
【請求項２３】
請求項２２記載の方法であって、
前記添付データは、ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ファイルを有することを特徴とする方法。
【請求項２４】
請求項２１記載の方法であって、さらに、
ユーザのコマンドに応答して、前記入力メッセージのダウンロードされた部分を前記端末上に表示するステップを有することを特徴とする方法。
【請求項２５】
請求項２４記載の方法であって、さらに、
前記入力メッセージのダウンロードされた部分を前記端末の記憶要素上に保存するステップを有することを特徴とする方法。
【請求項２６】
請求項２１記載の方法であって、さらに、
前記入力メッセージをユーザに通知するステップを有することを特徴とする方法。
【請求項２７】
請求項２１記載の方法であって、さらに、
前記入力メッセージの残りにアクセスするステップを有することを特徴とする方法。
【請求項２８】
請求項２７記載の方法であって、さらに、
アクセスのため、前記入力メッセージの開始ポイントを示すよう前記入力メッセージの添付ファイルを修正するステップを有することを特徴とする方法。
【請求項２９】
請求項２８記載の方法であって、
前記添付ファイルは、ＳＤＰファイルを有することを特徴とする方法。
【請求項３０】
請求項２１記載の方法であって、さらに、
前記入力メッセージの残りへのアクセスのため、前記入力メッセージを格納しているサーバと前記端末を接続するステップを有し、
前記所定の時間は、前記ユーザが前記入力メッセージの全体を連続的に閲覧するのを可能にするため、前記端末と前記サーバを接続するのに十分な長さを有することを特徴とする方法。
【請求項３１】
マルチメディアメッセージサービスサーバにおいて実行される方法であって、
入力マルチメディアメッセージを受信するステップと、
前記入力メッセージがリッチメディアコンテンツを有するか判断するステップと、
前記入力メッセージがリッチメディアコンテンツを有する場合、新たなマルチメディアメッセージを受信モバイル端末に送信するステップと、
を有することを特徴とする方法。
【請求項３２】
請求項３１記載の方法であって、
前記新たなマルチメディアメッセージは、所定の時間を有する前記入力メッセージの一部を有することを特徴とする方法。
【請求項３３】
請求項３１記載の方法であって、
前記新たなマルチメディアメッセージは、所定の時間を有する広告を有することを特徴とする方法。
【請求項３４】
請求項３１記載の方法であって、さらに、
前記入力メッセージがアクセス可能な場所を示す前記新たなマルチメディアメッセージへの添付ファイルを生成するステップを有することを特徴とする方法。
【請求項３５】
請求項３４記載の方法であって、
前記添付ファイルは、ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ファイルを有することを特徴とする方法。
【請求項３６】
請求項３１記載の方法であって、さらに、
前記新たなマルチメディアメッセージを生成するステップを有することを特徴とする方法。
【請求項３７】
請求項３６記載の方法であって、さらに、
前記入力メッセージを予め選択された場所に保存するステップと、
前記新たなマルチメディアメッセージに含めるため、前記入力メッセージの一部をコピーするステップと、
を有することを特徴とする方法。
【請求項３８】
請求項３７記載の方法であって、
前記予め選択された場所は、メディアサーバの記憶要素に存在することを特徴とする方法。
【請求項３９】
請求項３２記載の方法であって、
前記所定の時間は、ユーザが前記入力メッセージの全体を連続的に前記端末上で閲覧するのを可能にするため、前記受信モバイル端末が前記入力メッセージを格納しているサーバと接続するのに十分な長さを有することを特徴とする方法。
【請求項４０】
請求項３３記載の方法であって、
前記所定の時間は、ユーザが前記入力メッセージの全体を実質連続的に前記端末上で閲覧するのを可能にするため、前記受信モバイル端末が前記入力メッセージを格納しているサーバと接続するのに実質的に要する時間と同一であることを特徴とする方法。
【請求項１】
モバイル端末であって、
入力マルチメディアメッセージの通知を受信する手段と、
前記入力メッセージがリッチメディアコンテンツを有するか判断する手段と、
前記入力メッセージがリッチメディアコンテンツを有する場合、ユーザが当該端末上で閲覧する所定の時間を有する前記入力メッセージの一部をダウンロードする手段と、
を有することを特徴とする端末。
【請求項２】
請求項１記載のモバイル端末であって、
前記判断する手段は、前記入力メッセージがリッチメディアコンテンツを有するか判断するため、前記入力メッセージのメディアタイプに関する情報を有する前記通知の添付データを構文解析する手段を有することを特徴とする端末。
【請求項３】
請求項２記載のモバイル端末であって、
前記添付データは、ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ファイルを有することを特徴とする端末。
【請求項４】
請求項１記載のモバイル端末であって、さらに、
ユーザのコマンドに応答して、前記入力メッセージのダウンロードされた部分を当該モバイル端末上に表示する手段を有することを特徴とする端末。
【請求項５】
請求項４記載のモバイル端末であって、さらに、
記憶要素と、
前記入力メッセージのダウンロードされた部分を前記記憶要素上に保存する手段と、
を有することを特徴とする端末。
【請求項６】
請求項１記載のモバイル端末であって、さらに、
前記入力メッセージをユーザに通知する手段を有することを特徴とする端末。
【請求項７】
請求項１記載のモバイル端末であって、さらに、
前記入力メッセージの残りにアクセスする手段を有することを特徴とする端末。
【請求項８】
請求項７記載のモバイル端末であって、
前記アクセスする手段は、該アクセスする手段によるアクセスのため、前記入力メッセージの開始ポイントを示すよう前記入力メッセージの添付ファイルを修正する手段を有することを特徴とする端末。
【請求項９】
請求項８記載のモバイル端末であって、
前記添付ファイルは、ＳＤＰファイルを有することを特徴とする端末。
【請求項１０】
請求項１記載のモバイル端末であって、さらに、
前記入力メッセージの残りへのアクセスのため、前記入力メッセージを格納しているサーバと当該モバイル端末を接続する手段を有し、
前記所定の時間は、前記ユーザが前記入力メッセージの全体を連続的に閲覧するのを可能にするため、前記接続する手段が当該モバイル端末と前記サーバを接続するのに十分な長さを有することを特徴とする端末。
【請求項１１】
入力マルチメディアメッセージを受信する手段と、
前記入力メッセージがリッチメディアコンテンツを有するか判断する手段と、
前記入力メッセージがリッチメディアコンテンツを有する場合、新たなマルチメディアメッセージを受信モバイル端末に送信する手段と、
を有することを特徴とするマルチメディアメッセージサービスサーバ。
【請求項１２】
請求項１１記載のマルチメディアメッセージサービスサーバであって、
前記新たなマルチメディアメッセージは、所定の時間を有する前記入力メッセージの一部を有することを特徴とするサーバ。
【請求項１３】
請求項１１記載のマルチメディアメッセージサービスサーバであって、
前記新たなマルチメディアメッセージは、所定の時間を有する広告を有することを特徴とするサーバ。
【請求項１４】
請求項１１記載のマルチメディアメッセージサービスサーバであって、さらに、
前記入力メッセージがアクセス可能な場所を示す前記新たなマルチメディアメッセージへの添付ファイルを生成する手段を有することを特徴とするサーバ。
【請求項１５】
請求項１４記載のマルチメディアメッセージサービスサーバであって、
前記添付ファイルは、ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ファイルを有することを特徴とするサーバ。
【請求項１６】
請求項１１記載のマルチメディアメッセージサービスサーバであって、さらに、
前記新たなマルチメディアメッセージを生成する手段を有することを特徴とするサーバ。
【請求項１７】
請求項１６記載のマルチメディアメッセージサービスサーバであって、さらに、
前記入力メッセージを予め選択された場所に保存する手段と、
前記新たなマルチメディアメッセージに含めるため、前記入力メッセージの一部をコピーする手段と、
を有することを特徴とするサーバ。
【請求項１８】
請求項１７記載のマルチメディアメッセージサービスサーバであって、
前記予め選択された場所は、メディアサーバの記憶要素に存在することを特徴とするサーバ。
【請求項１９】
請求項１２記載のマルチメディアメッセージサービスサーバであって、
前記所定の時間は、ユーザが前記入力メッセージの全体を連続的に前記端末上で閲覧するのを可能にするため、前記受信モバイル端末が前記入力メッセージを格納しているサーバと接続するのに十分な長さを有することを特徴とするサーバ。
【請求項２０】
請求項１３記載のマルチメディアメッセージサービスサーバであって、
前記所定の時間は、ユーザが前記入力メッセージの全体を実質連続的に前記端末上で閲覧するのを可能にするため、前記受信モバイル端末が前記入力メッセージを格納しているサーバと接続するのに実質的に要する時間と同一であることを特徴とするサーバ。
【請求項２１】
モバイル端末において実行される方法であって、
入力マルチメディアメッセージの通知を受信するステップと、
前記入力メッセージがリッチメディアコンテンツを有するか判断するステップと、
前記入力メッセージがリッチメディアコンテンツを有する場合、ユーザが前記端末上で閲覧する所定の時間を有する前記入力メッセージの一部をダウンロードするステップと、
を有することを特徴とする方法。
【請求項２２】
請求項２１記載の方法であって、
前記判断するステップは、前記入力メッセージがリッチメディアコンテンツを有するか判断するため、前記入力メッセージのメディアタイプに関する情報を有する前記通知の添付データを構文解析するステップを有することを特徴とする方法。
【請求項２３】
請求項２２記載の方法であって、
前記添付データは、ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ファイルを有することを特徴とする方法。
【請求項２４】
請求項２１記載の方法であって、さらに、
ユーザのコマンドに応答して、前記入力メッセージのダウンロードされた部分を前記端末上に表示するステップを有することを特徴とする方法。
【請求項２５】
請求項２４記載の方法であって、さらに、
前記入力メッセージのダウンロードされた部分を前記端末の記憶要素上に保存するステップを有することを特徴とする方法。
【請求項２６】
請求項２１記載の方法であって、さらに、
前記入力メッセージをユーザに通知するステップを有することを特徴とする方法。
【請求項２７】
請求項２１記載の方法であって、さらに、
前記入力メッセージの残りにアクセスするステップを有することを特徴とする方法。
【請求項２８】
請求項２７記載の方法であって、さらに、
アクセスのため、前記入力メッセージの開始ポイントを示すよう前記入力メッセージの添付ファイルを修正するステップを有することを特徴とする方法。
【請求項２９】
請求項２８記載の方法であって、
前記添付ファイルは、ＳＤＰファイルを有することを特徴とする方法。
【請求項３０】
請求項２１記載の方法であって、さらに、
前記入力メッセージの残りへのアクセスのため、前記入力メッセージを格納しているサーバと前記端末を接続するステップを有し、
前記所定の時間は、前記ユーザが前記入力メッセージの全体を連続的に閲覧するのを可能にするため、前記端末と前記サーバを接続するのに十分な長さを有することを特徴とする方法。
【請求項３１】
マルチメディアメッセージサービスサーバにおいて実行される方法であって、
入力マルチメディアメッセージを受信するステップと、
前記入力メッセージがリッチメディアコンテンツを有するか判断するステップと、
前記入力メッセージがリッチメディアコンテンツを有する場合、新たなマルチメディアメッセージを受信モバイル端末に送信するステップと、
を有することを特徴とする方法。
【請求項３２】
請求項３１記載の方法であって、
前記新たなマルチメディアメッセージは、所定の時間を有する前記入力メッセージの一部を有することを特徴とする方法。
【請求項３３】
請求項３１記載の方法であって、
前記新たなマルチメディアメッセージは、所定の時間を有する広告を有することを特徴とする方法。
【請求項３４】
請求項３１記載の方法であって、さらに、
前記入力メッセージがアクセス可能な場所を示す前記新たなマルチメディアメッセージへの添付ファイルを生成するステップを有することを特徴とする方法。
【請求項３５】
請求項３４記載の方法であって、
前記添付ファイルは、ＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）ファイルを有することを特徴とする方法。
【請求項３６】
請求項３１記載の方法であって、さらに、
前記新たなマルチメディアメッセージを生成するステップを有することを特徴とする方法。
【請求項３７】
請求項３６記載の方法であって、さらに、
前記入力メッセージを予め選択された場所に保存するステップと、
前記新たなマルチメディアメッセージに含めるため、前記入力メッセージの一部をコピーするステップと、
を有することを特徴とする方法。
【請求項３８】
請求項３７記載の方法であって、
前記予め選択された場所は、メディアサーバの記憶要素に存在することを特徴とする方法。
【請求項３９】
請求項３２記載の方法であって、
前記所定の時間は、ユーザが前記入力メッセージの全体を連続的に前記端末上で閲覧するのを可能にするため、前記受信モバイル端末が前記入力メッセージを格納しているサーバと接続するのに十分な長さを有することを特徴とする方法。
【請求項４０】
請求項３３記載の方法であって、
前記所定の時間は、ユーザが前記入力メッセージの全体を実質連続的に前記端末上で閲覧するのを可能にするため、前記受信モバイル端末が前記入力メッセージを格納しているサーバと接続するのに実質的に要する時間と同一であることを特徴とする方法。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２００６−５１０３１０（Ｐ２００６−５１０３１０Ａ）
【公表日】平成１８年３月２３日（２００６．３．２３）
【国際特許分類】
【出願番号】特願２００４−５６０１２９（Ｐ２００４−５６０１２９）
【出願日】平成１５年１２月１７日（２００３．１２．１７）
【国際出願番号】ＰＣＴ／ＩＢ２００３／００６０２３
【国際公開番号】ＷＯ２００４／０５６０６７
【国際公開日】平成１６年７月１日（２００４．７．１）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【氏名又は名称原語表記】Ｋｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｅｌｅｃｔｒｏｎｉｃｓ Ｎ．Ｖ．
【住所又は居所原語表記】Ｇｒｏｅｎｅｗｏｕｄｓｅｗｅｇ １，５６２１ ＢＡ Ｅｉｎｄｈｏｖｅｎ， Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ
【Ｆターム（参考）】
【公表日】平成１８年３月２３日（２００６．３．２３）
【国際特許分類】
【出願日】平成１５年１２月１７日（２００３．１２．１７）
【国際出願番号】ＰＣＴ／ＩＢ２００３／００６０２３
【国際公開番号】ＷＯ２００４／０５６０６７
【国際公開日】平成１６年７月１日（２００４．７．１）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【氏名又は名称原語表記】Ｋｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｅｌｅｃｔｒｏｎｉｃｓ Ｎ．Ｖ．
【住所又は居所原語表記】Ｇｒｏｅｎｅｗｏｕｄｓｅｗｅｇ １，５６２１ ＢＡ Ｅｉｎｄｈｏｖｅｎ， Ｔｈｅ Ｎｅｔｈｅｒｌａｎｄｓ
【Ｆターム（参考）】
[ Back to top ]