JP2014505299A - マイクロウェブログのメッセージを処理するための方法および装置 - Google Patents

Abstract

本発明の実施形態は、マイクロウェブログシステムにおいてマイクロウェブログのメッセージを処理するための方法および装置を開示し、統一されたリッチメディアの制御が、マイクロウェブログシステムのそれぞれのクライアント側で構成され、リッチメディアの制御が、リッチメディア情報の操作の種類およびメディアの種類に応じてリッチメディア情報処理ロジックをカプセル化することによって得られる。方法は、マイクロウェブログシステムのクライアント側によって、マイクロウェブログのメッセージのリッチメディア情報を処理するための操作要求を受信するステップと、マイクロウェブログシステムのクライアント側によって、要求されたリッチメディア情報の操作の種類およびメディアの種類に応じて対応するリッチメディアの制御を呼び出し、その制御を実行してリッチメディア情報を適切に処理するステップとを含む。本発明の実施形態は、マイクロウェブログシステムのクライアント側のメッセージのページでリッチメディア情報を処理する同じまたは同様のロジックの再利用を可能にする。

Description

本発明は、コンピュータ技術の分野に関し、詳細には、マイクロウェブログシステムにおいてマイクロウェブログのメッセージを処理するための方法および装置に関する。

近年、オンラインインスタントメッセージ（Ｉｎｓｔａｎｔ Ｍｅｓｓａｇｉｎｇ、ＩＭ）ツールが、大多数のウェブユーザに受け入れられており、ユーザのなくてはならないソフトウェアツールとなった。オンラインインスタントメッセージツールは、日々の楽しみだけでなく、ユーザの仕事にも広く応用されている。したがって、ユーザは、使い勝手、安定性、セキュリティなどの点で、ＩＭソフトウェアに高い要求を課す。ＩＭソフトウェアは、主として、２人の友人の間の１対１のチャットと、グループまたはディスカッショングループ（ｄｉｓｃｕｓｓｉｏｎ ｇｒｏｕｐ）での１対多のメッセージとを可能にする。インターネットアプリケーションの発達につれて、ツイッターのようなマイクロ・ブログ（ｍｉｃｒｏ ｂｌｏｇ）（用語「ブログ」はウェブログに由来し、ウェブログとしても知られる）アプリケーションが活況を呈している（ツイッターは、ツイッターのウェブサイトで使用されるインスタントメッセージの形態の変化型であり、ユーザがそのユーザの最新ニュースおよび考えをショートメッセージサービスによって無線端末またはパーソナライズされたウェブサイトのグループに送信することを可能にする）。そのようなマイクロ・ブログ（略して「マイクロブログ」）サービスは、ユーザが１４０文字の漢字を公開することを可能にする。そのような手段は、情報の非常に速い伝搬および送信につながり、ユーザのメッセージチャットの形態を１対１および１対多から１対無限に広げる。１対無限の形態は、個人が無数の人にメッセージを伝搬する可能性があり、さらに、数万人のユーザによって公開された情報を受信する可能性があることを意味する。したがって、そのような技術は、大量のユーザによって使用されるアプリケーションに新たな要求を課す。

ＩＭは、ダイアログの形式で生じる。ＩＭは、最も原始的で、最も自然なインタラクションの形態を特徴とするが、効率が低い。概して、ＩＭは、完全な意味（ｍｅａｎｉｎｇ）を表すために多くのダイアログ（ｄｉａｌｏｇ）を使う。ブログは、文書の形式で生じ、はっきりと限定された閲覧者（ａｕｄｉｅｎｃｅ）を対象としない。ブログの意味は比較的完全であるが、ブログを始めることは比較的難しい。マイクロブログは、ショートメッセージの形式で生じ、はっきりと限定された閲覧者を対象としないが、マイクロブログの意味は比較的完全である。マイクロ・ブログを始めることは容易である。例えば、ユーザは、文または顔文字を公開することができる。したがって、ＩＭのメッセージおよびブログと比べて、マイクロブログは、情報を伝える効率がより高く、始めるのがより容易であることを特徴とする。ＩＭのメッセージ伝搬メカニズムを拡張する新しい製品および新しいアプリケーションとして、マイクロブログは急速に成長する。

マイクロブログのクライアント側のソフトウェアによって提示される情報は、主としてメッセージである。既存のマイクロブログのクライアント側の製品においては、情報は、主としてメッセージの形式で提示されるが、画像、音楽、および動画などのリッチメディア情報は、ほとんど提示されない。既存のマイクロブログのクライアント側の製品においては、ホームページなどのさまざまなページの形式のマイクロブログのコンテンツが、さまざまな寸法で、読むためにユーザに提示される。（「マイクロブログユーザ検索（Ｓｅａｒｃｈ Ｍｉｃｒｏｂｌｏｇ Ｕｓｅｒｓ）」および「マイ閲覧者リストメッセージ（Ｍｙ Ａｕｄｉｅｎｃｅ Ｌｉｓｔ Ｍｅｓｓａｇｅ）」などを含む）リストページなどのその他の種類のページも、マイクロブログのメッセージコンテンツを提示する必要がある。

既存のマイクロブログシステムの（上述のさまざまなページまたはホームページのような）メッセージページおよびリストページなどのさまざまなページは、マイクロブログのメッセージコンテンツを異なる方法で提示し、異なるページの間での再利用はない。このように、さまざまなページでリッチメディア情報を運ぶマイクロブログのメッセージを処理するためには、各ページで対応するロジックをそれぞれ実行する必要があり、このことは、コードのロジックの冗長性、より低いマイクロブログシステムの効率、および保守の難しさなどの多くの問題を引き起こすことが避けられない。

マイクロブログのクライアント側のソフトウェア製品の発達につれて、マイクロブログアプリケーションを（ダウンロードサービスなどの）さまざまなサービスと組み合わせることが必要である。マイクロブログシステムは、さまざまなサービスロジックを与えるための共通のプラットフォーム領域を提供する。共通のプラットフォーム領域上では、さまざまなサービスがマイクロブログのさらなる発展を促進することができるように、さまざまなサービスロジックに関して制御ポリシーが発揮される必要がある。

本発明の実施形態は、マイクロウェブログシステムのクライアント側のメッセージのページでリッチメディア情報を処理する同じまたは同様のロジックを再利用するようにマイクロウェブログのメッセージを処理するための方法および装置を提供する。

本発明の一実施形態によるマイクロウェブログのメッセージを処理するための方法においては、統一されたリッチメディアの制御が、マイクロウェブログシステムのそれぞれのクライアント側で構成され、リッチメディアの制御が、リッチメディア情報の操作の種類およびメディアの種類に応じてリッチメディア情報処理ロジックをカプセル化することによって得られる。その方法は、
マイクロウェブログシステムのクライアント側によって、マイクロウェブログのメッセージのリッチメディア情報を処理するための操作要求を受信するステップと、
マイクロウェブログシステムのクライアント側によって、要求されたリッチメディア情報の操作の種類およびメディアの種類に応じて対応するリッチメディアの制御を呼び出し、その制御を実行してリッチメディア情報を適切に処理するステップとを含む。

本発明の一実施態様によるマイクロウェブログのメッセージを処理するための装置は、
統一されたリッチメディアの制御を構成するように構成された構成モジュールであって、リッチメディアの制御は、リッチメディア情報の操作の種類およびメディアの種類に応じてリッチメディア情報処理ロジックをカプセル化することによって得られる、構成モジュールと、
マイクロウェブログのメッセージのリッチメディア情報を処理するための操作要求を受信するように構成された受信モジュールと、
要求されたリッチメディア情報の操作の種類およびメディアの種類に応じて対応するリッチメディアの制御を呼び出し、その制御を実行してリッチメディア情報を適切に処理するように構成された処理モジュールとを含む。

本発明の実施態様により、リッチメディア情報処理ロジックは、統一されたリッチメディアの制御を得るためにリッチメディア情報の操作の種類およびメディアの種類に応じて前もってカプセル化され、リッチメディアの制御は、マイクロウェブログシステムのそれぞれのクライアント側で構成される。このように、マイクロウェブログのメッセージのリッチメディア情報を処理するための操作要求を受信すると、マイクロウェブログシステムのクライアント側は、要求されたリッチメディア情報の操作の種類およびメディアの種類に応じて対応するリッチメディアの制御を呼び出し、その制御を実行してリッチメディア情報を適切に処理することができる。したがって、一方でマイクロウェブログのメッセージのリッチメディア情報が処理され、他方では、リッチメディアの制御がクライアント側で一様に構成されるので、異なるページでリッチメディア情報の再利用が実現され得る。つまり、対応するロジックをカプセル化することによって、マイクロウェブログシステムのクライアント側のさまざまなメッセージのページで再利用が実現される可能性があり、ユーザは情報を提示するより多くの方法を持つ。

本発明の実施形態のまたは従来技術の技術的な解決策をより明瞭に示すために、以下で、実施形態または従来技術を説明するために必要とされる添付の図面を簡単に説明する。明らかに、以下の説明の添付の図面は、本発明の一部の実施形態を示すに過ぎず、当業者は、創造的な努力をすることなくこれらの図面からその他の図面を導出することができる。

本発明の一実施形態によるマイクロブログのメッセージのサービスロジックブロックの概略図である。 本発明の一実施形態によるマイクロブログのメッセージを処理するための方法の概略的なフローチャートである。 本発明の一実施形態によるサムネイルをダウンロードする概略的なフローチャートある。 本発明の一実施形態による元の画像を表示する概略的なフローチャートある。 本発明の一実施形態によるマイクロブログに基づくリッチメディアのエクスポートプロセスでマイクロブログのメッセージを処理するための方法の概略的なフローチャートである。 本発明の一実施形態によるメッセージリストを表示する概略図ある。 本発明の一実施形態によるマイクロブログに基づくリッチメディアのエクスポートプロセスでマイクロブログのメッセージを処理するための方法の別の概略的なフローチャートである。 本発明の一実施形態によるマイクロブログに基づくリッチメディアのエクスポートプロセスでマイクロブログのメッセージを処理するための方法の別の概略的なフローチャートである。 本発明の一実施形態によるマイクロブログに基づくリッチメディアのエクスポートプロセスでマイクロブログのメッセージを処理するための方法の別の概略的なフローチャートである。 本発明の一実施形態によるマイクロウェブログのメッセージを処理するための装置の概略的な構造図である。 本発明の一実施形態によるマイクロブログに基づくリッチメディアのエクスポートプロセスに適用される処理モジュールの概略的な構造図である。 本発明の一実施形態によるメッセージリスト管理サブモジュールの概略的な構造図である。 本発明の一実施形態によるメッセージフィルタリングサブモジュールの概略的な構造図である。 本発明の一実施形態によるリッチメディアエクスポートサブモジュールの概略的な構造図である。

本発明の実施形態は、マイクロブログのリッチメディアメッセージの再利用を実施するための技術的な解決策を提供する。ユーザによって公開されるマイクロブログのメッセージは、１４０文字以下の漢字であるこれまでのテキスト情報を含むだけでなく、画像、音楽、動画などのリッチメディア情報をさまざまに提示することもでき、ユーザがマイクロブログのメッセージコンテンツを多くの方法で提示することを可能にし、ユーザの多様な要求を満足する。ユーザのマイクロブログのメッセージのコンテンツが、マイクロブログのクライアント側で複数のケースで提示される必要があると、リッチメディア情報は、適切にカプセル化される可能性があり、リッチメディア情報を提示するロジックは、適切に制御される可能性がある。この技術的な解決策によって、複数のメッセージページおよびリストページが、同じ処理ロジックを再利用することができる。

本発明の実施形態が、添付の図面を参照して以下で詳細に説明される。

本発明の実施形態においては、マイクロブログのメッセージにリッチメディア情報を運ばせるために、およびマイクロブログのメッセージでのリッチメディア情報の処理を容易にするために、特定のサービスロジックブロックが、もっぱら画像、音楽、および動画などのサービスのリッチメディア情報を運ぶためにマイクロブログのメッセージに設定される可能性がある。図１に示されるように、サービスロジックブロック「ＲｉｃｈＭｅｄｉａＣｔｒｌ」が、メディアの種類、リンクアドレス、表示される画像のサイズ、音声／動画の長さなどの、画像１、画像２、動画１、動画２、および音楽３のメディア関連情報を運ぶためにマイクロブログのメッセージに設定される。このように、変数「ＣＷＢｌｏｇＭｓｇＤａｔａ」が、マイクロブログのメッセージのリッチメディア情報が続いて処理される必要があるときに、対応するリッチメディア情報についての情報を送信するために使用される可能性があり、それによって、呼び出されるべき制御および／または制御に適用される実行プロセスを決定する。

図２に示されるように、本発明の一実施形態において提供されるマイクロブログのメッセージを処理するための方法は、２つの段階を含み得る。発生段階（ステップ２０１）において、リッチメディア情報処理ロジックが、マイクロブログのメッセージのリッチメディアの操作の種類（例えば、音声のリンクをクリックする、サムネイルをクリックする、画像をロードするなど）およびメディアの種類（例えば、画像、音声、動画など）に応じて、対応する制御に前もってカプセル化される。制御は、クライアント側で設定される可能性がある（制御がクライアント側のインストールプログラムにカプセル化される場合、クライアント側の制御の設定は、クライアント側のインストールが完了すると完了する）。適用段階（ステップ２０２）において、ページのリッチメディア情報を処理するための操作要求を受信した後、マイクロブログシステムのクライアント側が、要求されたリッチメディア情報の操作の種類およびメディアの種類に応じて対応するリッチメディアの制御を呼び出し、制御を実行することによってリッチメディア情報を適切に処理する。

特に、発生段階において、マイクロブログのページでのユーザの操作を処理する処理ロジックが、リッチメディアの制御にカプセル化され得る。より細かい粒度の下位制御が、リッチメディアの制御に含まれる可能性がある。下位制御は、互いに独立している。例えば、カーソルを中に動かすこと、カーソルを外に動かすこと、クリックすることなどの、ページでのユーザの操作の種類に応じて、対応する処理ロジックが設定され、リッチメディアの制御に下位制御としてカプセル化され、および／またはマイクロブログのページをロードする操作に応じて、対応する処理ロジックが設定され、リッチメディアの制御に下位制御としてカプセル化される。さまざまなリッチメディア情報の処理をサポートするために、それぞれの操作の種類に関して、それぞれの異なる種類のリッチメディア情報の処理ロジックが、メディアの種類に応じて、対応するリッチメディアの制御としてそれぞれカプセル化され得る。

例えば、カーソルによって画像のサムネイルをクリックする操作および音声／動画のリンクをクリックする操作に関して、処理ロジックがそれぞれ設定され、カプセル化される。このように、マイクロブログのメッセージページまたはリストページなどのページでのリッチメディア情報の処理に関連するそれぞれのページ要素に関して、ＲｉｃｈＭｅｄｉａＣｔｒｌのインスタンス変数のみが保存される必要がある。したがって、ユーザがページ要素を操作すると、対応する制御が、インスタンスを生成するために呼び出され、インスタンスを実行することによって、対応するリッチメディア情報が、インスタンス変数によって伝えられるパラメータに応じて処理される。別の例においては、処理ロジックが、画像をロードする操作、音声をロードする操作、および動画をロードする操作に関してそれぞれ設定され、カプセル化される。

さらに、リッチメディアの制御の中で、以下の機能のうちの１つ、または以下の機能の任意の組み合わせが設定され得る。

（１）それぞれのサービスの優先順位にしたがってすべてのサービスロジックの表示順を維持すること。ここで、サービスは、プラットフォームに関連して名付けられる。伝送プラットフォームとしては、具体的なサービスである音楽、動画、画像などが、処理される必要がある。各サービスは、異なる優先順位を持っており、優先順位は、サービスの属性である。特に、異なる表示の優先順位が、リッチメディア情報の種類に応じて設定される可能性がある。サービスの優先順位は、そのサービスが最初に表示されるのか、それとも後で表示されるのかを決定する。例えば、画像をロードする制御に対して最高の優先順位が設定される場合、マイクロブログのクライアント側がマイクロブログのページを初期化すると、画像が最初に表示される。

（２）ログインプロセスで必要に応じてある種類のリッチメディア情報を表示するかまたは非表示にするように制御すること。特に、設定インターフェースが、マイクロブログのクライアント側に提供され得る。設定インターフェースで、ユーザは、１つまたは複数の種類のリッチメディア情報に関する表示もしくは非表示の属性を設定することができる（またはデフォルト設定がシステムで適用される可能性もある）。それに対応して、クライアント側がマイクロブログのページを初期化すると、対応するメディアの種類のロードの制御を呼び出すべきかどうかが、属性の設定にしたがって決定され得る。このように、マイクロブログのクライアント側がマイクロブログのページを初期化するたびに、対応する種類のリッチメディア情報が、設定にしたがって表示されるかまたは非表示にされる可能性がある。

（３）同じ種類のリッチメディア情報の提示回数の制御を内部に保持すること。

（４）さまざまなバージョンの公開されるクライアント側に関して、必要に応じて、本発明の実施形態で利用可能な機能を一度に有効化すること。

上述の構成情報は、以下のようにして、すなわち、構成ファイルの形式で対応する機能の制御パラメータを暗号化し、次に、それらのファイルをクライアント側のバージョンと一緒にカプセル化し、例えば、それらのファイルをクライアント側のインストールプログラムまたはバージョン更新プログラムの各バージョンと一緒にカプセル化して設定されてもよく、したがって、構成情報は、クライアント側をインストールするかまたはバージョンを更新するプロセスでクライアント側に設定される。このように、サーバ側のローミング制御が実行される可能性があり、制御パラメータの設定がいつでも更新される可能性がある。

以下、画像処理プロセスを例に、リッチメディアの制御内で画像の制御を実施するためのロジックについて詳細に説明する。

概して、マイクロブログのメッセージの本文または元のファイルが画像を含む場合、画像のサムネイルが、マイクロブログのページで提示される。図３に示されるように、サムネイルをダウンロードするプロセスは、以下のステップを含む。

ステップ３０１：ページが初期化されるときに、クライアント側が、マイクロブログのメッセージの本文または元のファイルに画像が存在すると判定する場合、画像のサムネイルをロードするための制御を呼び出す。

このステップにおいて、マイクロブログのメッセージ内のロジック制御領域にしたがって、クライアント側は、ページが初期化されるときに、マイクロブログのメッセージが画像を含むことを知る。したがって、クライアント側は、画像のサムネイルをロードするための制御を呼び出し、対応するインスタンスを生成し、ＣＷＢｌｏｇＭｓｇＤａｔａ変数を使用することによって、ロジック制御領域の画像のリンクアドレスをインスタンスの入力パラメータとしてインスタンスに送信することができる。

以下の操作が、クライアント側によって呼び出された制御によって生成されたインスタンスによって実行される。

ステップ３０２：サムネイルが完全にダウンロードされているかどうかを判定する。ダウンロードが完了している場合はステップ３０７に進み、そうでなければ、ステップ３０３に進む。

ステップ３０３：サムネイルが表示される位置にデフォルトの画像を表示し、マイクロブログのメッセージの画像リンクを画像をダウンロードするためのダウンロードリストに追加し、ダウンロードの進行を示すためのアニメーションを開始する。

ステップ３０４：ダウンロードが成功するかどうかを判定する。ダウンロードが成功する場合はステップ３０６に進み、そうでなければ、ステップ３０５に進む。

ステップ３０５：ダウンロードリスト内のダウンロードに失敗した画像リンクを見つけ、ステップ３０６に進む。

ステップ３０６：ダウンロードの進行のアニメーションの表示を停止し、マイクロブログのメッセージの画像リンクをダウンロードリストから削除し、ステップ３０７に進む。

ステップ３０７：ダウンロードが完了したサムネイルを適切な位置に配置する。

上記のプロセスにおいて、サムネイルが既にダウンロードされているかどうかを判定するステップは、任意である。この判定およびそれに応じて実行される処理は、既にダウンロードされているサムネイルを繰り返しダウンロードすることを避け、処理の効率を改善し、ネットワークのオーバーヘッドを省くことができる。

マイクロブログのクライアント側のユーザが「元の画像をチェックする」、「コピー」、または「名前を付けて保存」などの操作を実行すると、元の画像をダウンロードするプロセスがトリガされる。「元の画像をチェックする」アイコンがマイクロブログのページに設定されており、アイコンの属性内のメディアの種類の属性が「画像」であり、メディアの識別子が「画像１」であると仮定する。画像を右クリックするロジック処理操作に対応する制御は、ＳｈｅｌｌＥｘｅｃｕｔｅである。図４に示されるように、プロセスは、以下のステップを含み得る。

ステップ４０１：マイクロブログのクライアント側のユーザがページの「元の画像をチェックする」アイコンを右クリックすると、クライアント側は、このページ要素の属性にしたがって画像を処理する必要性を判定し、メディアの種類およびマウス操作の種類に応じてＳｈｅｌｌＥｘｅｃｕｔｅ制御を呼び出し、さらに、画像に対するユーザの現在の操作を記録し、例えば、画像の識別子（またはリンクなど）およびマウス操作の種類（右クリック）を記録してもよい。

このステップにおいて、ＳｈｅｌｌＥｘｅｃｕｔｅ制御を呼び出した後、クライアント側は、対応するインスタンスを生成し、ＣＷＢｌｏｇＭｓｇＤａｔａ変数を用いて、マイクロブログのメッセージのロジック制御領域の画像のリンクアドレスをインスタンスの入力パラメータとしてインスタンスに送信することができる。

以下の操作が、クライアント側によって呼び出されたＳｈｅｌｌＥｘｅｃｕｔｅ制御によって生成されたインスタンスによって実行される。

ステップ４０２：画像が既にダウンロードされているかどうかを判定する。既にダウンロードされている場合はステップ４０７に進み、そうでなければ、ステップ４０３に進む。

ステップ４０３：画像リンクを画像をダウンロードするためのダウンロードリストに追加し、そうすると、ダウンロードの進行のアニメーションが開始され得る。

ステップ４０４：ダウンロードが成功するかどうかを判定する。ダウンロードが成功する場合はステップ４０６に進み、そうでなければ、ステップ４０５に進む。

ステップ４０５：ダウンロードリスト内のダウンロードに失敗した画像リンクを見つけ、ステップ４０６に進む。

ステップ４０６：ダウンロードの進行のアニメーションの表示を停止し、マイクロブログのメッセージの画像リンクをダウンロードリストから削除し、ステップ４０７に進む。

ステップ４０８：既にダウンロードされている画像を表示する。

上記のプロセスにおいて、画像が既にダウンロードされているかどうかを判定するステップは、任意である。この判定およびそれに応じて実行される処理は、既にダウンロードされている画像を繰り返しダウンロードすることを避け、処理の効率を改善し、ネットワークのオーバーヘッドを省くことができる。

クライアント側のユーザが画像に関して「元の画像をチェックする」、「コピー」、または「名前を付けて保存」などの操作を繰り返し実行すると、画像ダウンロードプロセスが繰り返しトリガされ、このことは、システムリソースのオーバーヘッドにつながる。この問題に対処するために、本発明の実施形態は、以下の措置を講じる。

（１）以下の機能、すなわち、マップを使用して、ダウンロードされている画像のリストを保存することと、画像のリストにしたがって、クライアント側のユーザの操作が同じ画像の繰り返しのダウンロードにつながるかどうかを判定することと、繰り返しのダウンロードが発生する場合に、画像の繰り返しのダウンロードをふるい落とす、つまり、同じ画像に関する繰り返しのダウンロード操作を拒否することとが、制御の中に追加される。

（２）以下の機能、すなわち、マップを用いて、画像に関する最後の操作を保存することと、画像が完全にダウンロードされた後にその最後の操作だけを実行することとが、制御の中に追加される。例えば、ユーザは、最初に、「元の画像をチェックする」を選択し、次に、すぐに、「名前を付けて保存」を選択する。この場合、「元の画像をチェックする」機能を実施するための制御、および「名前を付けて保存」機能を実施する制御が、続けて呼び出される。最後の操作は「名前を付けて保存」である。つまり、最後の操作にしたがって呼び出される制御のみが実行される。

上記の２つの処理プロセスは、別々にまたは組み合わせて使用され得る。つまり、上記の２つの機能が、画像処理の制御に追加される。

さらに、クライアント側がマイクロブログのメッセージの画像フォーマットをサポートする適切な画像ビューワを持たないケースに関しては、本発明の実施形態では、画像処理の制御に機能を追加するか、または画像を表示するための画像ビューワを選択するための制御を追加する。画像ビューワを選択するための制御の追加を例に取ると、処理プロセスは、以下の操作を含み得る。

呼び出された制御が画像を表示しようとするときに、画像フォーマットに対応する画像ビューワが見つからない場合、制御は、特定の値を返す（例えば、ＳｈｅｌｌＥｘｅｃｕｔｅ制御によって返される値は３２未満である）。この場合、クライアント側は、画像ビューワを選択するための制御を呼び出すことができ、その制御を用いて、ユーザが画像ビューワを選択することができる「オープンモード」オプションボックスを開き、画像ビューワを選択すると、ユーザによって選択された画像ビューワによって画像が表示される。

同様の操作が、その他のメディアの種類のリッチメディア情報に適用され得ることに留意されたい。特に、リッチメディアの制御を実行することによってリッチメディア情報を処理するプロセスにおいて、マイクロウェブログシステムのクライアント側がリッチメディア情報のフォーマットをサポートしない場合、クライアント側のユーザは、リッチメディア情報を表示するためのリッチメディア情報のプレーヤーを選択することを可能にされる。

本発明の実施形態は、ソフトウェアを用いて実行されることができ、ソフトウェア開発環境は、ＶＳ２００５のＡＴＬエンジニアリング（ＡＴＬ ｅｎｇｉｎｅｅｒｉｎｇ）であってよい。

上述の説明で明らかにされたように、本発明の実施形態によるマイクロブログのリッチメディアメッセージを再利用することに対する技術的な解決策は、情報を提示するより多くの方法をユーザに提供し、対応するロジックをカプセル化することによって、マイクロブログのクライアント側でそれぞれのメッセージページを再利用することを可能にする。

図５に示されるように、マイクロブログに基づくリッチメディアのエクスポートプロセスにおいて、ステップ２０２は、特に以下を含む。

Ｓ１０１。マイクロブログ端末が、ユーザが現在のメッセージリストに対するフィルタリング操作を実行することを検出すると、分類されたフィルタリングの命令をマイクロブログのサーバ側に送信する。

具体的実践において、ユーザは、図６に示されるフィルタリングの形態にしたがって現在のメッセージリストに関するフィルタリング操作を実行することができ、Ｓ１０１において、ユーザが現在のメッセージリストに関するフィルタリング操作を実行することを検出すると、マイクロブログ端末は、現在のメッセージリストのメッセージインデックスＩＤのリストをカプセル化して、分類されたフィルタリングの命令を生成し、次に、その分類されたフィルタリングの命令をマイクロブログのサーバ側に送信する。分類されたフィルタリングの命令を受信した後、マイクロブログのサーバ側は、分類されたフィルタリングの命令のメッセージインデックスＩＤのリストにしたがって、メッセージインデックスＩＤのリスト内の各メッセージインデックスＩＤに対応するメッセージの本文を抽出し、各メッセージインデックスＩＤに対応するメッセージの本文を分析し、現在のメッセージリスト内の各メッセージのメッセージ種類を判定し、現在のメッセージリストに含まれるすべてのメッセージの種類にしたがって、現在のメッセージリストでフィルタリングに利用可能なリッチメディアの種類をマイクロブログ端末に返し、メッセージの種類は、テキスト型および／またはリッチメディア型を含み、リッチメディア型は、画像型、音楽型、および動画型のうちの少なくとも１つを含む。

Ｓ１０２。マイクロブログ端末が、マイクロブログのサーバ側によって返された、現在のメッセージリストでフィルタリングに利用可能なリッチメディアの種類を受信し、フィルタリングに利用可能なリッチメディアの種類を表示する。

具体的実践においては、Ｓ１０２で、フィルタリングに利用可能なリッチメディアの種類は、図６の破線のボックスによって示される方法で表示される可能性がある。

Ｓ１０３。ユーザがフィルタリングに利用可能なリッチメディアの種類の中のいずれか１つのリッチメディアの種類を選択すると、マイクロブログ端末が、メッセージ取得命令をマイクロブログのサーバ側に送信する。

具体的実践においては、Ｓ１０３で、ユーザがフィルタリングに利用可能なリッチメディアの種類の中のいずれか１つのリッチメディアの種類を選択することを検出すると、マイクロブログ端末は、現在のメッセージリストのメッセージインデックスＩＤのリストを、選択されたリッチメディアの種類の識別子と一緒にカプセル化して、メッセージ取得命令を生成し、そのメッセージ取得命令をマイクロブログのサーバ側に送信する。メッセージ取得命令を受信した後、マイクロブログのサーバ側は、メッセージ取得命令のメッセージインデックスＩＤのリストにしたがって、メッセージインデックスＩＤのリスト内の各メッセージインデックスＩＤに対応するメッセージの本文を抽出し、メッセージ取得命令の選択されたリッチメディアの種類の識別子に応じて、抽出されたメッセージの本文の中でその識別子を含むメッセージの本文を問い合わせ、問い合わされたメッセージの本文に応じて、メッセージ取得命令のメッセージインデックスＩＤのリストを更新し、それから、更新されたメッセージインデックスＩＤのリストを、問い合わされたメッセージの本文と一緒にマイクロブログ端末に返す。

Ｓ１０４。マイクロブログ端末が、マイクロブログのサーバ側によって返された、現在のメッセージリスト内の選択されたリッチメディアの種類のすべてのメッセージを受信し、選択されたリッチメディアの種類のメッセージのリストを表示する。

Ｓ１０４において、マイクロブログ端末は、マイクロブログのサーバ側によって返されたそのリッチメディアの種類のメッセージを受信し（メッセージは、更新されたメッセージインデックスＩＤのリストおよびメッセージの本文を含む）、メッセージの本文を解析し、１対１の関係で、それぞれのメッセージの本文を、受信されたメッセージの更新されたインデックスＩＤのリストとマッチングし、各メッセージのアイテム制御（Ｉｔｅｍ ｃｏｎｔｒｏｌ）を使用して、そのリッチメディアの種類のメッセージのリストを生成し、そのリッチメディアの種類のメッセージのリストを表示する。

Ｓ１０５。ユーザが選択されたリッチメディアの種類のメッセージのリストをエクスポートすることを検出すると、マイクロブログ端末は、エクスポート要求メッセージをマイクロブログのサーバ側に送信する。

具体的実践においては、Ｓ１０５で、ユーザが選択されたリッチメディアの種類のメッセージのリストをエクスポートすることを検出すると、マイクロブログ端末は、そのリッチメディアの種類のメッセージのリストに対応するメッセージインデックスＩＤのリストをカプセル化してエクスポート要求メッセージを生成し、そのエクスポート要求メッセージをマイクロブログのサーバ側に送信する。マイクロブログ端末によって送信されたエクスポート要求メッセージを受信した後、マイクロブログのサーバ側は、エクスポート要求メッセージのメッセージインデックスＩＤのリストにしたがって、メッセージインデックスＩＤのリスト内の各メッセージインデックスＩＤに対応するメッセージの本文を抽出し、抽出されたメッセージの本文に含まれるリッチメディアのＵＲＬアドレスを解析し、ＵＲＬアドレスを処理してリッチメディアのエクスポートアドレスを取得し、それから、そのリッチメディアのエクスポートアドレスをマイクロブログ端末に返し、リッチメディアは、画像、音楽、および動画のうちの少なくとも１つを含む。

異なるリッチメディアの種類に関しては、マイクロブログのサーバ側の処理が変わる。ユーザがリッチメディアの種類として画像型を選択する場合、マイクロブログのメッセージ内のすべての画像はマイクロブログのサーバ側の画像サーバに記憶されているので、マイクロブログのサーバ側は、解析することによって画像のＵＲＬアドレスを取得し、解析することによって得られた画像のＵＲＬアドレスにしたがって、画像のＵＲＬアドレスに対応するすべての画像を画像サーバからダウンロードし、すべての画像を圧縮し、カプセル化して画像エクスポートパッケージを生成する。マイクロブログのサーバ側は、画像エクスポートパッケージを記憶し、画像エクスポートパッケージの記憶アドレスを画像エクスポートアドレスとして使用し、その画像エクスポートアドレスをマイクロブログ端末に返す。ユーザがリッチメディアの種類として音楽または動画型を選択する場合、マイクロブログのメッセージ内の音楽または動画は実際には記憶されていないので、解析によって音楽のＵＲＬアドレスまたは動画のＵＲＬアドレスを取得した後、マイクロブログのサーバ側は、解析によって得られた音楽のＵＲＬアドレスまたは動画のＵＲＬアドレスを直接圧縮し、カプセル化して音楽エクスポートアドレスまたは動画エクスポートアドレスを取得し、そして、その音楽エクスポートアドレスまたは動画エクスポートアドレスをマイクロブログ端末に返す。

Ｓ１０６。マイクロブログ端末が、マイクロブログのサーバ側によって返されたリッチメディアのエクスポートアドレスを受信し、リッチメディアのエクスポートアドレスにしたがって、選択されたリッチメディアの種類のメッセージのリスト内のすべてのリッチメディアをダウンロードする。

上述のように、異なる種類のリッチメディアに関しては、マイクロブログのサーバ側の処理の形態が変わる。したがって、このステップにおいて、マイクロブログ端末は、マイクロブログのサーバ側によって返された画像エクスポートアドレスを受信する場合、画像エクスポートアドレスにしたがって画像エクスポートパッケージをダウンロードする。マイクロブログ端末がマイクロブログのサーバ側によって返された音楽エクスポートアドレスまたは動画エクスポートアドレスを受信する場合、マイクロブログ端末は、音楽エクスポートアドレスまたは動画エクスポートアドレス内のすべてのＵＲＬアドレスにしたがって対応するウェブサイトから音楽または動画をダウンロードする。

本発明の実施形態においては、ユーザの簡単な操作だけで、メッセージリスト内のリッチメディアの種類のメッセージがフィルタリングされ、リストの形式で表示され、パッケージでエクスポートされ得る。したがって、マイクロブログの機能がより多様化され、マイクロブログのメッセージのリッチメディア情報が十分に活用され、ユーザがマイクロブログをより便利に使用することができる。

図７に示されるように、本発明の実施形態は、特定の事例を用いて、マイクロブログに基づくリッチメディアのエクスポートでステップ２０２を実施するプロセスを説明する。

ユーザは、マイクロブログ端末のＩＭクライアント側で、登録されたユーザアカウントおよびパスワードを入力する。マイクロブログ端末は、ユーザアカウントおよびパスワードをまとめ、ログイン要求をマイクロブログのサーバ側に送信する。マイクロブログのサーバ側のログインサーバは、ユーザアカウントおよびパスワードを認証する。認証が成功した後、マイクロブログ端末とマイクロブログのサーバ側との間で接続パスが設定される。マイクロブログ端末は、マイクロブログのサーバ側への接続を保証するためにマイクロブログのサーバ側にハートビートパケットを定期的に送信する。マイクロブログ端末は、ユーザのマイクロブログのホームページ、ホットブロードキャスト（ｈｏｔ ｂｒｏａｄｃａｓｔ）、ブロードキャストホール（ｂｒｏａｄｃａｓｔ ｈａｌｌ）、またはシティブロードキャスト（ｃｉｔｙ ｂｒｏａｄｃａｓｔ）などのメッセージリストを表示することができる。

ユーザがそのユーザのマイクロブログのホームページを見ることを選択すると、マイクロブログ端末のメッセージリスト管理モジュールが、ユーザアカウントおよびホームページの識別子をカプセル化してホームページ要求メッセージを生成し、そのホームページ要求メッセージをマイクロブログのサーバ側のインデックスサーバに送信する。ホームページ要求メッセージを受信した後、インデックスサーバは、ユーザアカウントに応じてユーザのすべての閲覧者のアカウントを問い合わせ、問い合わされた閲覧者のアカウントを用いて、閲覧者によって公開されたメッセージインデックスＩＤを取得し、メッセージインデックスＩＤを時系列に並べてメッセージインデックスＩＤのリストを生成し、そのリストをマイクロブログ端末のメッセージリスト管理モジュールに返す。マイクロブログ端末のメッセージリスト管理モジュールは、受信されたメッセージインデックスＩＤのリストをカプセル化してメッセージ本文要求メッセージを生成し、そのメッセージ本文要求メッセージをマイクロブログのサーバ側のメッセージサーバに送信する。メッセージインデックスＩＤのリストを受信した後、メッセージサーバは、メッセージインデックスＩＤのリストにしたがって対応するメッセージの本文を問い合わせ、問い合わされたメッセージの本文の各パケットをメッセージリスト管理モジュールにそれぞれ返す。メッセージリスト管理モジュールは、受信されたメッセージの本文を解析し、それぞれのメッセージの本文をメッセージインデックスＩＤのリストと１対１の関係でマッチングし、各メッセージのアイテム制御を使用してホームページのメッセージを生成し、そのホームページのメッセージをユーザに対して提示する。

ユーザが検索バーに「フィルタ」キーワードを入力すると、メッセージリスト管理モジュールは、ホームページのメッセージリストのメッセージインデックスＩＤのリストを分類されたフィルタリングの命令にカプセル化し、その分類されたフィルタリングの命令をメッセージサーバに送信する。分類されたフィルタリングの命令のメッセージインデックスＩＤのリストにしたがって、メッセージサーバは、メッセージインデックスＩＤのリスト内の各メッセージインデックスＩＤに対応するメッセージの本文を抽出し、各メッセージインデックスＩＤに対応するメッセージの本文を分析し、ホームページのメッセージリスト内の各メッセージのメッセージ種類を判定し、そして、ホームページのメッセージリストでフィルタリングに利用可能なリッチメディアの種類をメッセージリスト管理モジュールに返す。メッセージリスト管理モジュールは、受信されたホームページのメッセージリストでフィルタリングに利用可能なリッチメディアの種類をユーザに対して提示する。

ユーザが画像型を選択すると、メッセージフィルタ管理モジュールが、ホームページのメッセージリストのメッセージインデックスＩＤのリストを画像型の識別子と一緒にカプセル化してメッセージ取得命令を生成し、その命令をメッセージサーバに送信する。メッセージ取得命令のメッセージインデックスＩＤのリストにしたがって、メッセージサーバは、メッセージインデックスＩＤのリスト内の各メッセージインデックスＩＤに対応するメッセージの本文を抽出し、メッセージ取得命令の画像型の識別子に応じて、メッセージサーバは、抽出されたメッセージの本文の中でその識別子を含むメッセージの本文を問い合わせ、問い合わされたメッセージの本文を用いてメッセージ取得命令のメッセージインデックスＩＤのリストを更新する。具体的には、メッセージインデックスＩＤのリストを更新するプロセスとは、メッセージサーバが、問い合わされたメッセージの本文を解析し、受信されたメッセージインデックスＩＤのリストから対応するメッセージインデックスＩＤを抽出し、時系列的にすべての抽出されたメッセージインデックスＩＤを処理して新しいメッセージインデックスＩＤのリストを生成することである。メッセージサーバは、更新されたメッセージインデックスＩＤのリストを問い合わされたメッセージの本文と一緒にメッセージフィルタ管理モジュールに返し、メッセージフィルタ管理モジュールは、受信されたメッセージの本文および新しいメッセージインデックスＩＤのリストを解析し、それら２つを１対１の関係でマッチングし、各メッセージのアイテム制御を使用して画像型のメッセージのリストを生成し、そのリストをユーザに対して提示する。

ユーザは、画像をエクスポートする操作を確認し、リッチメディアエクスポートモジュールは、画像型のメッセージリストのメッセージインデックスＩＤのリストをカプセル化してエクスポート要求メッセージを生成し、そのエクスポート要求メッセージをメッセージサーバに送信する。エクスポート要求メッセージのメッセージインデックスＩＤのリストにしたがって、メッセージサーバは、メッセージインデックスＩＤのリスト内の各メッセージインデックスＩＤに対応するメッセージの本文を抽出し、それぞれの抽出されたメッセージの本文に含まれる画像のＵＲＬアドレスを解析し、その画像のＵＲＬアドレスをエクスポート管理サーバに送信する。マイクロブログのメッセージ内のすべての画像はマイクロブログのサーバ側の画像サーバに記憶されているので、エクスポート管理サーバは、受信された画像のＵＲＬアドレスにしたがって画像サーバからその画像のＵＲＬアドレスに対応するすべての画像をダウンロードし、すべての画像を圧縮し、カプセル化して画像エクスポートパッケージを生成し、画像エクスポートパッケージを記憶し、画像エクスポートパッケージの記憶アドレスを画像エクスポートアドレスとしてリッチメディアエクスポートモジュールに送信する。リッチメディアエクスポートモジュールは、受信された画像エクスポートアドレスにしたがって画像エクスポートパッケージをダウンロードし、ダウンロードされた画像エクスポートパッケージをユーザに対して提示する。

ユーザが音楽または動画を選択し、エクスポートの操作を確認する場合、マイクロブログのメッセージ内の音楽または動画は実際には記憶されていないので、メッセージサーバによって送信された音楽のＵＲＬアドレスまたは動画のＵＲＬアドレスを受信した後、エクスポート管理サーバは、解析することによって得られた音楽のＵＲＬアドレスまたは動画のＵＲＬアドレスを直接圧縮し、カプセル化して音楽エクスポートアドレスまたは動画エクスポートアドレスを取得し、そして、その音楽エクスポートアドレスまたは動画エクスポートアドレスをリッチメディアエクスポートモジュールに送信することに留意されたい。リッチメディアエクスポートモジュールは、受信された音楽エクスポートアドレスまたは動画エクスポートアドレス内のすべてのＵＲＬアドレスにしたがって対応するウェブサイトから音楽または動画をダウンロードし、ダウンロードされた音楽または動画をユーザに対して提示する。

本発明の実施形態についての上記の説明で明らかにされたように、本発明の実施形態は、現在のメッセージリストをユーザに対して表示し、ユーザが現在のメッセージリストに関するフィルタリング操作を実行するときは、フィルタリングに利用可能な種類をユーザに対して提示し、ユーザがフィルタリングに利用可能な種類の中でリッチメディアの種類を選択すると、現在のメッセージリスト内のすべてのリッチメディアの種類のメッセージをユーザに対してリストの形式で提示し、エクスポートインターフェースをユーザに提供し、ユーザがエクスポートインターフェースを使用してリッチメディアの種類のメッセージのリストをエクスポートすることが検出されると、リッチメディアの種類のメッセージのリストに含まれるすべてのリッチメディア情報をカプセル化し、リッチメディア情報をエクスポートし、そのリッチメディア情報をユーザに対して提示する。本発明の実施形態においては、ユーザの簡単な操作だけで、メッセージリスト内のリッチメディアの種類のメッセージがフィルタリングされ、リストの形式で表示され、パッケージでエクスポートされ得る。したがって、マイクロブログの機能がより多様化され、マイクロブログの情報の中のリッチメディア情報が十分に活用され、ユーザがマイクロブログをより便利に使用することができる。

同じ技術的な概念に基づいて、本発明の実施形態は、マイクロウェブログのメッセージを処理するための装置を提供する。装置は、マイクロウェブログシステムのクライアント側に置かれる可能性がある。

図８に示されるように、装置は、
統一されたリッチメディアの制御を構成するように構成された構成モジュール５０１であって、リッチメディアの制御は、リッチメディア情報の操作の種類およびメディアの種類に応じてリッチメディア情報処理ロジックをカプセル化することによって得られる、構成モジュール５０１と、
マイクロウェブログのメッセージのリッチメディア情報を処理するための操作要求を受信するように構成された受信モジュール５０２と、
要求されたリッチメディア情報の操作の種類およびメディアの種類に応じて対応するリッチメディアの制御を呼び出し、その制御を実行してリッチメディア情報を適切に処理するように構成された処理モジュール５０３と、を含み得る。

上記の装置において、受信モジュール５０１は、リッチメディア情報をロードするための操作要求を受信する可能性がある。それに応じて、リッチメディアの制御を呼び出すことによって、処理モジュール５０３は、以下の構成情報項目、すなわち、
メディアの種類に関して設定された表示の優先順位と、
メディアの種類に関して設定された表示／非表示の属性と、
メディアの種類に関して設定された表示されるリッチメディア情報の量とのうちの１つ、またはこれらの任意の組み合わせにしたがって対応するメディア情報をロードすることができる。

構成情報は、マイクロウェブログシステムのクライアント側の各バージョンのインストールプログラムまたは更新プログラムにそれぞれ束ねられ、それに応じて、構成モジュール５０１は、マイクロウェブログのクライアント側をインストールまたは更新するプロセスで、構成情報をマイクロウェブログのクライアント側に設定することができる。

上記の装置において、受信モジュール５０２は、ページ要素を操作する要求をマイクロウェブログシステムのクライアント側のユーザから受信することができ、それに応じて、処理モジュール５０３は、ユーザにより操作されるページ要素に応じてメディア情報のメディアの種類を判定し、メディアの種類およびユーザの操作の種類に応じて対応するリッチメディアの制御を呼び出し、ページ要素に対応するメディア情報の属性パラメータを制御の入力パラメータとして使用し、その制御を実行して、ページ要素に対応するメディア情報を適切に処理することができる。

上記の装置においては、リッチメディアの制御を実行してリッチメディア情報を処理するプロセスで、処理モジュール５０３は、同じリッチメディア情報を繰り返しダウンロードする場合、リッチメディア情報を繰り返しダウンロードする操作を拒否する可能性がある。

上記の装置においては、リッチメディアの制御を実行してリッチメディア情報を処理するプロセスで、処理モジュール５０３は、同じリッチメディア情報に関して異なるリッチメディアの制御が続けて呼び出される場合、最後に呼び出されたリッチメディアの制御のみを実行する可能性がある。

上記の装置においては、リッチメディアの制御を実行してリッチメディア情報を処理するプロセスで、マイクロウェブログシステムのクライアント側がリッチメディア情報のフォーマットをサポートしない場合、処理モジュール５０３は、ユーザがリッチメディア情報を表示するためのリッチメディア情報のプレーヤーを選択することを可能にすることができる。

本発明の実施形態についての上記の説明で明らかにされたように、当業者は、本発明の実施形態がハードウェアのみを用いて、またはほとんどの場合、好ましくはソフトウェアおよび必要な汎用的ハードウェアプラットフォームを用いて実行され得ることをはっきりと理解する。そのような理解に基づいて、本発明の技術的な解決策の本質、または本発明の技術的な解決策によってなされる寄与は、ソフトウェア製品で具現化され得る。コンピュータソフトウェア製品は、ストレージ媒体に記憶され、（モバイル電話、パーソナルコンピュータ、サーバ、またはネットワークデバイスなどの）端末デバイスが本発明のいずれかの実施形態で開示された方法を実行することを可能にするいくつかの命令を含む。

図９に示されるように、マイクロブログに基づくリッチメディアエクスポートプロセスにおいて、処理モジュール５０３は、特に、メッセージリスト管理サブモジュール５０３１と、メッセージフィルタ管理サブモジュール５０３２と、リッチメディアエクスポートサブモジュール５０３３とを含む。

メッセージリスト管理サブモジュール５０３１は、現在のメッセージリストを表示し、ユーザが現在のメッセージリストに関するフィルタリング操作を実行することを検出すると、分類されたフィルタリングの命令をマイクロブログのサーバ側に送信し、マイクロブログのサーバ側によって返された現在のメッセージリストでフィルタリングに利用可能なリッチメディアの種類を受信し、フィルタリングに利用可能なリッチメディアの種類を表示するように構成される。

具体的実践においては、ユーザは、マイクロブログ端末のＩＭクライアント側の登録されたユーザアカウントおよびパスワードを用いて認証のためにマイクロブログのサーバ側にログインし、ユーザアカウントおよびパスワードが正常に認証される場合、マイクロブログ端末とマイクロブログのサーバ側との間で接続パスが設定される。マイクロブログ端末は、アクセスサーバを通じてマイクロブログのサーバ側にアクセスし、マイクロブログのサーバ側への接続を保証するためにマイクロブログのサーバ側にハートビートパケットを定期的に送信する。マイクロブログ端末は、ユーザのマイクロブログのホームページ、ホットブロードキャスト、ブロードキャストホール、またはシティブロードキャストなどのメッセージリストを表示することができる。メッセージリスト管理サブモジュール５０３１は、ユーザによって選択された表示コンテンツに応じて現在のメッセージリストを表示するように構成される。例えば、ユーザがそのユーザのマイクロブログのホームページを見ることを選択する場合、メッセージリスト管理サブモジュール５０３１は、ユーザアカウントおよびホームページの識別子をカプセル化してホームページ要求メッセージを生成し、そのホームページ要求メッセージをマイクロブログのサーバ側に送信する。ホームページ要求メッセージを受信した後、マイクロブログのサーバ側は、ユーザアカウントに応じてユーザのすべての閲覧者のアカウントを問い合わせ、問い合わされた閲覧者のアカウントを用いて、閲覧者によって公開されたメッセージインデックスＩＤを取得し、メッセージインデックスＩＤを時系列に並べてメッセージインデックスＩＤのリストを生成し、そのリストをメッセージリスト管理サブモジュール５０３１に返す。メッセージインデックスＩＤのリストを受信した後、メッセージリスト管理サブモジュール５０３１は、メッセージインデックスＩＤのリストをカプセル化してメッセージ本文要求メッセージを生成し、そのメッセージ本文要求メッセージをマイクロブログのサーバ側に送信する。インデックスＩＤのリストを受信した後、マイクロブログのサーバ側は、メッセージインデックスＩＤのリストにしたがって対応するメッセージの本文を問い合わせ、問い合わされたメッセージの本文の各パケットをメッセージリスト管理サブモジュール５０３１にそれぞれ返す。メッセージリスト管理サブモジュール５０３１は、メッセージの本文を解析し、それぞれのメッセージの本文を受信されたメッセージインデックスＩＤのリストと１対１の関係でマッチングし、各メッセージのアイテム制御を使用してホームページのメッセージリストを生成し、ホームページのメッセージリストをユーザに対して提示する。

本発明の実施形態において、マイクロブログ端末は、検索バーをユーザに提供する。検索バーで、ユーザは、現在のメッセージリストに関するフィルタリング操作を実行することができる。図６は、本発明の実施形態による、マイクロブログ端末でメッセージリストを表示する概略図である。図６に示されるように、マイクロブログ端末によって提供される検索バーに「フィルタ」キーワードを入力することによって、ユーザは、現在のメッセージリストに関するフィルタリング操作を実施する。メッセージリスト管理サブモジュール５０３１は、ユーザのフィルタリング操作を検出すると、分類されたフィルタリングの命令をマイクロブログのサーバ側に送信し、現在のメッセージリストでフィルタリングに利用可能なリッチメディアの種類をマイクロブログのサーバ側から受信し、フィルタリングに利用可能なリッチメディアの種類をユーザに対して提示し、リッチメディアの種類は、画像型、音楽型、および動画型のうちの少なくとも１つを含むがそれらに限定されない。図６の破線のボックスによって示される部分は、メッセージリスト管理サブモジュール５０３１によって表示された現在のメッセージリストでフィルタリングに利用可能なリッチメディアの種類を示す。フィルタリングに利用可能なリッチメディアの種類は、現在のメッセージリストに含まれるリッチメディアの種類であることに留意されたい。上述のように、現在のメッセージリストは、ホームページのメッセージリストである。ホームページのメッセージリストが画像型のメッセージ、音楽型のメッセージ、および動画型のメッセージを含む場合、ホームページのメッセージリストでフィルタリングに利用可能なリッチメディアの種類は、画像型、音楽型、および動画型を含む。

当然のことながら、マイクロブログのメッセージは、テキストメッセージとリッチメディアメッセージの両方を含み、両方とも、ユーザによって最初に生成されるかまたは転送され得る。したがって、メッセージリスト管理サブモジュール５０３１は、フィルタリングに利用可能なリッチメディアの種類の分類された表示の間、テキスト型も表示する可能性があり、またはフィルタリングに利用可能なリッチメディアの種類の分類された表示の間、元の生成の属性（ｏｒｉｇｉｎａｌ ｃｒｅａｔｉｏｎ ａｔｔｒｉｂｕｔｅ）もしくは転送の属性（ｆｏｒｗａｒｄｉｎｇ ａｔｔｒｉｂｕｔｅ）を表示する可能性がある。そのようなケースは、類似性によって分析される可能性があり、本明細書においてはこれ以上詳細に説明されない。さらに、マイクロブログ端末によって提供される検索バーは、ユーザのフィルタリング操作に関するショートカットを提供する。ショートカットは、既存のマイクロブログ端末の検索バーの機能を利用し、既存の検索プロセスと同様である。しかし、この形態は、例であるに過ぎない。その他のケースもあり得る。例えば、マイクロブログ端末が、インターフェースにフィルタショートカットキーを追加する可能性があり、ユーザが、フィルタショートカットキーをクリックして、現在のメッセージリストに関するフィルタリング操作を実行するか、またはマイクロブログ端末が、フィルタショートカットを含むメニューをユーザに提供する可能性があり、ユーザが、フィルタショートカットを使用して現在のメッセージリストに関するフィルタリング操作を実行する、等々である。そのようなその他のケースは、類似性によって分析される可能性があり、本明細書においてはこれ以上詳細に説明されない。

メッセージフィルタ管理サブモジュール５０３２は、ユーザがメッセージリスト管理サブモジュール５０３１によって表示されるフィルタリングに利用可能なリッチメディアの種類の中のいずれか１つのリッチメディアの種類を選択するとマイクロブログのサーバ側にメッセージ取得命令を送信し、マイクロブログのサーバ側によって返された現在のメッセージリスト内の選択されたリッチメディアの種類のすべてのメッセージを受信し、選択されたリッチメディアの種類のメッセージのリストを表示するように構成される。

具体的実践においては、上記の例によれば、メッセージリスト管理サブモジュール５０３１が、図６の破線のボックスによって示されたホームページのメッセージリストでフィルタリングに利用可能なリッチメディアの種類を表示し、ユーザは、それらのリッチメディアの種類の中のいずれか１つのリッチメディアの種類を選択することができる。メッセージフィルタ管理サブモジュール５０３２は、どのリッチメディアの種類がユーザによって選択されるかを検出する。ユーザが画像型を選択することを検出する場合、メッセージフィルタ管理サブモジュール５０３２は、メッセージ取得命令をマイクロブログのサーバ側に送信し、マイクロブログのサーバ側からホームページのメッセージリスト内の画像型のすべてのメッセージを受信し、画像型のメッセージのリストを表示する。

リッチメディアエクスポートサブモジュール５０３３は、メッセージフィルタ管理サブモジュール５０３２によって表示される選択されたリッチメディアの種類のメッセージのリストに関するエクスポート操作をユーザが実行することが検出されると、エクスポート要求メッセージをマイクロブログのサーバ側に送信し、マイクロブログのサーバ側によって返されたリッチメディアのエクスポートアドレスを受信し、リッチメディアのエクスポートアドレスにしたがって、選択されたリッチメディアの種類のメッセージのリストのリッチメディアをダウンロードするように構成される。

具体的実践において、マイクロブログ端末は、ユーザにエクスポートインターフェースを提供する。エクスポートインターフェースは、エクスポートボタンまたはエクスポートメニューである可能性がある。エクスポートボタン、またはエクスポートメニュー内のエクスポート項目をクリックすることによって、ユーザは、選択されたリッチメディアの種類のメッセージの現在表示されているリストをエクスポートすることができる。上記の例によれば、メッセージフィルタ管理サブモジュール５０３２は、選択された画像型のメッセージのリストを表示する。ユーザが選択された画像型のメッセージのリストに関するエクスポート操作を実行することを検出する場合、リッチメディアエクスポートサブモジュール５０３３は、エクスポート要求メッセージをマイクロブログのサーバ側に送信し、マイクロブログのサーバ側によって返された画像のエクスポートアドレスを受信し、画像のエクスポートアドレスにしたがって画像エクスポートパッケージをダウンロードする。ダウンロードされた画像エクスポートパッケージは、マイクロブログ端末の指定された場所に記憶される。ダウンロードを完了すると、リッチメディアエクスポートサブモジュール５０３３が、ダウンロードされたパッケージを見るようにユーザに促すことができ、またはユーザが、マイクロブログ端末の指定された位置の画像エクスポートパッケージを主体的に見ること、編集すること、処理することなどができる。

本発明の実施形態においては、マイクロブログ端末でユーザによって行われる簡単な操作だけで、メッセージリスト内のリッチメディアの種類のメッセージがフィルタリングされ、リストの形式で表示され、パッケージでエクスポートされ得る。したがって、マイクロブログの機能がより多様化され、マイクロブログのメッセージのリッチメディア情報が十分に活用され、ユーザがマイクロブログをより便利に使用することができる。

本発明の技術的な解決策をより明瞭に示すために、以下で、本発明の実施形態のマイクロブログ端末の各モジュールについて詳細を説明する。

図１０は、本発明の一実施形態によるマイクロブログ端末のメッセージリスト管理モジュールの概略的な構造図である。メッセージリスト管理サブモジュール５０３１は、リスト提示ユニット１１、命令カプセル化ユニット１２、送受信ユニット１３、および分類されたディスプレイユニット（ｃｌａｓｓｉｆｉｅｄ ｄｉｓｐｌａｙ ｕｎｉｔ）１４を含む。

リスト提示ユニット１１は、現在のメッセージリストを提示するように構成される。

具体的実践において、マイクロブログ端末は、ユーザのマイクロブログのホームページ、ホットブロードキャスト、ブロードキャストホール、またはシティブロードキャストなどのメッセージリストを表示することができる。リスト提示ユニット１１は、ユーザによって選択された表示コンテンツに応じて現在のメッセージリストを表示するように構成される。例えば、ユーザがマイクロブログのホームページを見ることを選択する場合、リスト提示ユニット１１は、ユーザのホームページのメッセージリストをユーザに対して提示する。

命令カプセル化ユニット１２は、ユーザがリスト提示ユニット１１によって提示された現在のメッセージリストに関するフィルタリング操作を実行することが検出されると、現在のメッセージリストのメッセージインデックスＩＤのリストをカプセル化して、分類されたフィルタリングの命令を生成するように構成される。

上述のように、図６に示されたようにして、ユーザは、リスト提示ユニット１１によって提示されたホームページのメッセージリストに関するフィルタリング操作を実行する。ユーザのフィルタリング操作を検出すると、命令カプセル化ユニット１２は、ホームページのメッセージリストのメッセージインデックスＩＤのリストをカプセル化して、分類されたフィルタリングの命令を生成する。命令カプセル化ユニット１２のカプセル化のプロセスは、従来技術のメッセージカプセル化プロセスと同様であり、本明細書においてこれ以上詳細に説明されない。

送受信ユニット１３は、命令カプセル化ユニット１２によって生成された分類されたフィルタリングの命令をマイクロブログのサーバ側に送信し、マイクロブログのサーバ側によって返された現在のメッセージリストでフィルタリングに利用可能なリッチメディアの種類を受信するように構成される。

分類されたディスプレイユニット１４は、送受信ユニット１３によって受信されるフィルタリングに利用可能なリッチメディアの種類を表示するように構成される。具体的実践において、フィルタリングに利用可能なリッチメディアの種類は、現在のメッセージリストに含まれるリッチメディアの種類である。上述のように、現在のメッセージリストは、ホームページのメッセージリストである。ホームページのメッセージリストが画像型のメッセージ、音楽型のメッセージ、および動画型のメッセージを含む場合、ホームページのメッセージリストでフィルタリングに利用可能なリッチメディアの種類は、画像型、音楽型、および動画型を含む。

以下で、メッセージリスト管理サブモジュール５０３１の各ユニットの動作原理について詳細に説明する。

上述のように、リスト提示ユニット１１がユーザがマイクロブログのホームページを見ることを選択することを確認する場合、命令カプセル化ユニット１２が、ユーザアカウントおよびホームページの識別子をカプセル化してホームページ要求メッセージを生成し、そうすると、ホームページ要求メッセージが、送受信ユニット１３によってマイクロブログのサーバ側に送信される。ホームページ要求メッセージを受信した後、マイクロブログのサーバ側は、ユーザアカウントに応じてユーザのすべての閲覧者のアカウントを問い合わせ、問い合わされた閲覧者のアカウントを用いて、閲覧者によって公開されたメッセージインデックスＩＤを取得し、メッセージインデックスＩＤを時系列に並べてメッセージインデックスＩＤのリストを生成し、そのリストを送受信ユニット１３に返す。命令カプセル化ユニット１２は、受信されたメッセージインデックスＩＤのリストをカプセル化してメッセージ本文要求メッセージを生成し、そうすると、メッセージ本文要求メッセージが、送受信ユニット１３によってマイクロブログのサーバ側に送信される。インデックスＩＤのリストを受信した後、マイクロブログのサーバ側は、メッセージインデックスＩＤのリストにしたがって対応するメッセージの本文を問い合わせ、問い合わされたメッセージの本文の各パケットを送受信ユニット１３にそれぞれ返す。リスト提示ユニット１１は、受信されたメッセージの本文を解析し、それぞれのメッセージの本文を受信されたメッセージインデックスＩＤのリストと１対１の関係でマッチングし、各メッセージのアイテム制御を使用してホームページのメッセージリストを生成し、そのリストをユーザに対して提示する。

図６に示されたようにして、ユーザは、リスト提示ユニット１１によって提示されたホームページのメッセージリストに関するフィルタリング操作を実行する。命令カプセル化ユニット１２は、ホームページのメッセージリストのメッセージインデックスＩＤのリストを分類されたフィルタリングの命令にカプセル化し、そうすると、分類されたフィルタリングの命令が、送受信ユニット１３によってマイクロブログのサーバ側に送信される。分類されたフィルタリングの命令のメッセージインデックスＩＤのリストにしたがって、マイクロブログのサーバ側は、メッセージインデックスＩＤのリスト内の各メッセージインデックスＩＤに対応するメッセージの本文を抽出し、各メッセージインデックスＩＤに対応するメッセージの本文を分析し、ホームページのメッセージリスト内の各メッセージのメッセージ種類を判定し、そして、ホームページのメッセージリストでフィルタリングに利用可能なリッチメディアの種類を送受信ユニット１３に返す。分類されたディスプレイユニット１４が、現在のホームページのメッセージリストでフィルタリングに利用可能なリッチメディアの種類をユーザに対して提示し、それらのリッチメディアの種類は、送受信ユニット１３によって受信される。

本発明の実施形態においては、マイクロブログ端末でユーザによって行われる簡単な操作だけで、メッセージリスト内のリッチメディアの種類のメッセージがフィルタリングされ得る。したがって、マイクロブログの機能がより多様化され、マイクロブログのメッセージのリッチメディア情報が十分に活用され、ユーザがマイクロブログをより便利に使用することができる。

図１１は、本発明の一実施形態によるマイクロブログ端末のメッセージフィルタ管理モジュールの概略的な構造図である。メッセージフィルタ管理サブモジュール５０３２は、メッセージカプセル化ユニット２１、送受信ユニット２２、およびメッセージ表示ユニット２３を含む。

メッセージカプセル化ユニット２１は、メッセージリスト管理サブモジュール５０３１によって表示されるフィルタリングに利用可能なリッチメディアの種類の中のいずれか１つのリッチメディアの種類をユーザが選択することを検出すると、現在のメッセージリストのメッセージインデックスＩＤのリストを選択されたリッチメディアの種類の識別子と一緒にカプセル化して、メッセージ取得命令を生成するように構成される。

送受信ユニット２２は、メッセージカプセル化ユニット２１によって生成されたメッセージ取得命令をマイクロブログのサーバ側に送信し、マイクロブログのサーバ側によって返された現在のメッセージリスト内の選択されたリッチメディアの種類のすべてのメッセージのメッセージインデックスＩＤのリストおよびメッセージの本文を受信するように構成される。

メッセージ表示ユニット２３は、送受信ユニット２２によって受信される選択されたリッチメディアの種類のメッセージのメッセージインデックスＩＤのリストおよびメッセージの本文にしたがって、選択されたリッチメディアの種類のメッセージのリストを生成し、選択されたリッチメディアの種類のメッセージのリストを表示するように構成される。

以下で、メッセージフィルタ管理サブモジュール５０３２の各ユニットの動作原理について詳細に説明する。

上で与えられた例によれば、ユーザが図６のフィルタリングに利用可能なリッチメディアの種類の中で画像型を選択した後、メッセージカプセル化ユニット２１が、ホームページのメッセージリストのメッセージインデックスＩＤのリストを画像型の識別子と一緒にカプセル化してメッセージ取得命令を生成し、そうすると、その命令が、送受信ユニット２２によってマイクロブログのサーバ側に送信される。メッセージ取得命令のメッセージインデックスＩＤのリストにしたがって、マイクロブログのサーバ側は、メッセージインデックスＩＤのリスト内の各メッセージインデックスＩＤに対応するメッセージの本文を抽出し、メッセージ取得命令の画像型の識別子に応じて、マイクロブログのサーバ側は、抽出されたメッセージの本文の中でその識別子を含むメッセージの本文を問い合わせ、問い合わされたメッセージの本文を用いてメッセージ取得命令のメッセージインデックスＩＤのリストを更新する。具体的には、メッセージインデックスＩＤのリストを更新するプロセスとは、サーバ側が、問い合わされたメッセージの本文を解析し、受信されたメッセージインデックスＩＤのリストから対応するメッセージインデックスＩＤを抽出し、時系列的にすべての抽出されたメッセージインデックスＩＤを処理して新しいメッセージインデックスＩＤのリストを生成することである。サーバ側は、更新されたメッセージインデックスＩＤのリストを問い合わされたメッセージの本文と一緒に送受信ユニット２２に返し、メッセージ表示ユニット２３は、受信されたメッセージの本文および更新されたメッセージインデックスＩＤのリストを解析し、それら２つを１対１の関係でマッチングし、各メッセージのアイテム制御を使用して画像型のメッセージのリストを生成し、そのリストをユーザに対して提示する。

本発明の実施形態においては、マイクロブログ端末でユーザによって行われる簡単な操作だけで、メッセージリスト内のリッチメディアの種類のメッセージがリストの形式で表示され得る。したがって、マイクロブログの機能がより多様化され、マイクロブログのメッセージのリッチメディア情報が十分に活用され、ユーザがマイクロブログをより便利に使用することができる。

図１２は、本発明の一実施形態によるマイクロブログ端末のリッチメディアエクスポートモジュールの概略的な構造図である。リッチメディアエクスポートサブモジュール５０３３は、

メッセージフィルタ管理サブモジュール５０３２によって提示される選択されたリッチメディアの種類のメッセージのリストに関するエクスポート操作をユーザが実行することを検出すると、選択されたリッチメディアの種類のメッセージのリストに対応するメッセージインデックスＩＤのリストをカプセル化してエクスポート要求メッセージを生成するように構成されたエクスポートカプセル化ユニット３１と、

エクスポートカプセル化ユニット３１によって生成されたエクスポート要求メッセージをマイクロブログのサーバ側に送信し、マイクロブログのサーバ側から返されたリッチメディアのエクスポートアドレスを受信するように構成された送受信ユニット３２と、

送受信ユニット３２によって受信されたリッチメディアのエクスポートアドレスにしたがって、選択されたリッチメディアの種類のメッセージのリストのすべてのリッチメディアをダウンロードするように構成されたＨＴＴＰダウンロードユニット３３とを含む。

以下で、リッチメディアエクスポートサブモジュール５０３３の各ユニットの動作原理について詳細に説明する。

上記の例によれば、ユーザがマイクロブログ端末によって提供されるエクスポートインターフェースを使用してホームページのメッセージリスト内の画像型のメッセージのリストに対するエクスポート操作を実行すると、エクスポートカプセル化ユニット３１は、画像型のメッセージリストのメッセージインデックスＩＤのリストをカプセル化してエクスポート要求メッセージを生成し、そうすると、エクスポート要求メッセージが、送受信ユニット３２によってマイクロブログのサーバ側に送信される。エクスポート要求メッセージのメッセージインデックスＩＤのリストにしたがって、マイクロブログのサーバ側は、メッセージインデックスＩＤのリスト内の各メッセージインデックスＩＤに対応するメッセージの本文を抽出し、抽出されたメッセージの本文に含まれる画像のＵＲＬアドレスを解析する。マイクロブログのメッセージ内のすべての画像はマイクロブログのサーバ側の画像サーバに記憶されているので、マイクロブログのサーバ側は、解析することによって得られた画像のＵＲＬアドレスにしたがって画像サーバからその画像のＵＲＬアドレスに対応するすべての画像をダウンロードし、すべての画像を圧縮し、カプセル化して画像エクスポートパッケージを生成し、画像エクスポートパッケージを記憶し、画像エクスポートパッケージの記憶アドレスを画像エクスポートアドレスとして送受信ユニット３２に送信する。ＨＴＴＰダウンロードユニット３３は、送受信ユニット３２によって受信された画像エクスポートアドレスにしたがって画像エクスポートパッケージをダウンロードする。

ユーザがリッチメディアの種類として音楽または動画を選択する場合、マイクロブログのメッセージ内の音楽または動画は実際には記憶されていないので、マイクロブログのサーバ側は、解析することによって音楽のＵＲＬアドレスまたは動画のＵＲＬアドレスを取得した後、解析することによって得られた音楽のＵＲＬアドレスまたは動画のＵＲＬアドレスを直接圧縮し、カプセル化して音楽エクスポートアドレスまたは動画エクスポートアドレスを取得し、それから、その音楽エクスポートアドレスまたは動画エクスポートアドレスを送受信ユニット３２に送信することに留意されたい。ＨＴＴＰダウンロードユニット３３は、送受信ユニット３２によって受信された音楽エクスポートアドレスまたは動画エクスポートアドレス内のすべてのＵＲＬアドレスにしたがって対応するウェブサイトから音楽または動画をダウンロードする。

当然のことながら、本発明の実施形態のＨＴＴＰダウンロードモジュールは、単なる例であるに過ぎない。代わりに、ＦＴＰ（ファイル転送プロトコル、Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）の形態またはその他のダウンロードツールが、使用され得る。そのような場合、分析は同様であり、本明細書においてこれ以上詳細に説明されない。

本発明の実施形態においては、マイクロブログ端末でユーザによって行われる簡単な操作だけで、メッセージリスト内のリッチメディアの種類のメッセージがパッケージでエクスポートされ得る。したがって、マイクロブログの機能がより多様化され、マイクロブログのメッセージのリッチメディア情報が十分に活用され、ユーザがマイクロブログをより便利に使用することができる。

上記の説明は単に本発明の好ましい実施形態であるに過ぎず、当業者は本発明の原理を逸脱することなくさまざまな改善および改良を行い得ることに留意されたい。そのような改善および改良は、本発明の保護範囲内に入る。

Claims (29)

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. 前記リッチメディアエクスポートサブモジュールが、
    前記ユーザが前記メッセージフィルタ管理サブモジュールによって提示される前記選択されたリッチメディアの種類の前記メッセージの前記リストに対するエクスポート操作を実行することを検出すると、前記選択されたリッチメディアの種類の前記メッセージの前記リストに対応するメッセージインデックスＩＤのリストをカプセル化して前記エクスポート要求メッセージを生成するように構成されたエクスポートカプセル化ユニットと、
    前記エクスポートカプセル化ユニットによって生成された前記エクスポート要求メッセージを前記マイクロブログのサーバ側に送信し、前記マイクロブログのサーバ側から返された前記リッチメディアのエクスポートアドレスを受信するように構成された送受信ユニットと、
    前記送受信ユニットによって受信された前記リッチメディアのエクスポートアドレスにしたがって、前記選択されたリッチメディアの種類の前記メッセージの前記リストのすべてのリッチメディアをダウンロードするように構成されたＨＴＴＰダウンロードユニットと、を含む請求項２６に記載の装置。

Images