(57)【要約】動画メッセージングサービスを無線遠隔通信ネットワーク内の１つ以上のモバイルユーザ機器に提供する方法を開示する。本発明の方法は次のステップを含む：（ａ）少なくとも１つのメディアコンテンツファイルを、所定のメディア記憶部にて受信及び格納するステップと、（ｂ）前記少なくとも１つのメディアコンテンツファイルに関連付けられている少なくとも１つのメタファイルを生成するステップであって、該メタファイルは、（ｉ）前記少なくとも１つのメディアコンテンツファイルの第１のＵＲＬ（Uniform Resource Locator）と、（ｉｉ）前記少なくとも１つのメディアコンテンツファイルを前記所定のメディア記憶部から前記１つ以上のモバイルユーザ機器へと転送することを実効化するように構成された１つ以上の第１の自律的に実施可能な命令とを少なくとも備えている、生成するステップと、（ｃ）サードパーティメッセージングサービスを活用しつつプッシュ技術を介して前記少なくとも１つのメタファイルを、前記１つ以上のモバイルユーザ機器へと送信するステップと、（ｄ）前記１つ以上の第１の自律的に実施可能な命令に応答して、プル技術を介して、前記少なくとも１つのメディアコンテンツファイルを、前記所定のメディア記憶部から前記１つ以上のモバイルユーザ機器へとダウンロードするステップと、（ｅ）前記少なくとも１つのメディアコンテンツファイルのダウンロード完了に応答して、前記１つ以上のモバイルユーザ機器にて、前記少なくとも１つの動画コンテンツファイルの利用可能性について通知するステップと、（ｆ）所定のユーザ入力に応答して、前記１つ以上のモバイルユーザ機器に配されているメディアプレイヤアプリケーションを活用して前記少なくとも１つのメディアコンテンツファイルにアクセスするステップ。
2020537385.tif 000002
【特許請求の範囲】
【請求項１】
無線遠隔通信ネットワーク内の１つ以上のモバイルユーザ機器に動画メッセージングサービスを提供する方法であって、
（ａ）少なくとも１つのメディアコンテンツファイルを、所定のメディア記憶部にて受信及び格納するステップと、
（ｂ）前記少なくとも１つのメディアコンテンツファイルに関連付けられている少なくとも１つのメタファイルを生成するステップであって、該メタファイルは、（ｉ）前記少なくとも１つのメディアコンテンツファイルの第１のＵＲＬ（Uniform Resource Locator）と、（ｉｉ）前記少なくとも１つのメディアコンテンツファイルを前記所定のメディア記憶部から前記１つ以上のモバイルユーザ機器へと転送することを実効化するように構成された１つ以上の第１の自律的に実施可能な命令とを少なくとも備えている、生成するステップと、
（ｃ）サードパーティメッセージングサービスを活用しつつプッシュ技術を介して前記少なくとも１つのメタファイルを、前記１つ以上のモバイルユーザ機器へと送信するステップと、
（ｄ）前記１つ以上の第１の自律的に実施可能な命令に応答して、プル技術を介して、前記少なくとも１つのメディアコンテンツファイルを、前記所定のメディア記憶部から前記１つ以上のモバイルユーザ機器へとダウンロードするステップと、
（ｅ）前記少なくとも１つのメディアコンテンツファイルのダウンロード完了に応答して、前記１つ以上のモバイルユーザ機器にて、前記少なくとも１つの動画コンテンツファイルの利用可能性について通知するステップと、
（ｆ）所定のユーザ入力に応答して、前記１つ以上のモバイルユーザ機器に配されているメディアプレイヤアプリケーションを活用して前記少なくとも１つのメディアコンテンツファイルにアクセスするステップとを含む、方法。
【請求項２】
請求項１に記載の方法において、前記ステップ（ａ）、（ｂ）、（ｃ）、（ｄ）、（ｅ）及び（ｆ）は順次実行される、方法。
【請求項３】
前記請求項のいずれか１つに記載の方法において、前記少なくとも１つのメタファイルは、前記１つ以上のモバイルユーザ機器上の前記メディアプレイヤアプリケーションの動的適合可能メディアプレイヤインタフェースの作成を実効化するように構成された１つ以上の第２の自律的に実施可能な命令をさらに備える、方法。
【請求項４】
請求項１〜２のいずれか１つに記載の方法において、前記少なくとも１つのメタファイルは、前記１つ以上のモバイルユーザ機器に配されている前記メディアプレイヤアプリケーションの１つ以上のインタフェース特性を動的に修正するように構成された１つ以上の第３の自律的に実施可能な命令をさらに備える、方法。
【請求項５】
前記請求項のいずれか１つに記載の方法において、前記少なくとも１つのメディアコンテンツファイルは次のいずれか１つを備える、方法：少なくとも１つの動画ファイル、１つ以上のグラフィカルユーザインタフェース（ＧＵＩ）構成要素、及び外部メディアコンテンツをリンク及び／又は起動するように構成された１つ以上のＣＴＡ（Call To Action、召喚コール）機能性構成要素。
【請求項６】
請求項５に記載の方法において、前記少なくとも１つの動画ファイル、前記１つ以上のグラフィカルユーザインタフェース（ＧＵＩ）構成要素、及び前記１つ以上のＣＴＡ（Call To Action、召喚コール）機能性構成要素のうちの任意のものは、前記ユーザによって提供されたプロファイルデータに基づいて選択されるのであって、前記プロファイルデータは１つ以上のプロファイルパラメータを含む、方法。
【請求項７】
請求項６に記載の方法において、前記プロファイルデータは、所定のユーザプロファイル情報及び／又は所定のユーザプリファレンスを備える、方法。
【請求項８】
請求項６〜７のいずれか１つに記載の方法において、前記少なくとも１つのメディアコンテンツファイルは、前記１つ以上のＣＴＡ機能性構成要素と操作可能にリンクされている少なくとも１つの第２のＵＲＬをさらに備える、方法。
【請求項９】
請求項８に記載の方法において、前記少なくとも１つの第２のＵＲＬは前記１つ以上のユーザプロファイルパラメータから生成されたクエリ文字列を備える、方法。
【請求項１０】
前記請求項のいずれか１つに記載の方法において、前記少なくとも１つのメタファイルは前記少なくとも１つのメディアコンテンツファイルと関連付けられているメタデータをさらに備える、方法。
【請求項１１】
前記請求項のいずれか１つに記載の方法において、前記少なくとも１つのメタファイルはＸＭＬフォーマットで提供されてそのファイルサイズが所定のファイルサイズ制限以下とされている、方法。
【請求項１２】
請求項１１に記載の方法において、前記ファイルサイズ制限は４ｋＢとされる、方法。
【請求項１３】
請求項８〜１２のいずれか１つに記載の方法において、前記ステップ（ｄ）、（ｅ）及び（ｆ）の任意のものは、フィードバックデータを生成し、及び、前記サードパーティメッセージングサービスを活用しつつプッシュ技術を介して前記フィードバックデータを送信するステップをさらに含む、方法。
【請求項１４】
請求項１３に記載の方法において、前記フィードバックデータは前記サードパーティメッセージングサービス及び／又はＨＴＴＰを活用しつつプッシュ技術を介して送信される、方法。
【請求項１５】
請求項１３〜１４のいずれか１つに記載の方法において、前記フィードバックデータは、前記メディアプレイヤアプリケーション及び／又は前記少なくとも１つのメディアコンテンツファイルとの相互作用との関連で検出されたユーザ挙動を含む、方法。
【請求項１６】
請求項１３〜１５のいずれか１つに記載の方法において、前記フィードバックデータは前記１つ以上のＣＴＡ機能性構成要素に操作可能にリンクされている、方法。
【請求項１７】
前記請求項のいずれか１つに記載の方法において、前記ステップ（ｄ）の実行は所定の第１の条件に服する、方法。
【請求項１８】
請求項１７に記載の方法において、前記第１の条件は前記無線遠隔通信ネットワークはセルラ電話ネットワークではないということとされている、方法。
【請求項１９】
請求項１７〜１８のいずれか１つに記載の方法において、前記第１の条件は、前記無線遠隔通信ネットワークは無線ＬＡＮ（ＷｉＦｉ）であるということとされている、方法。
【請求項２０】
前記請求項のいずれか１つに記載の方法において、前記ステップ（ｄ）は、前記ダウンロード済みの少なくとも１つのメディアコンテンツファイルについての整合性特性を決定することと、少なくとも１つの第２の条件に服して、プル技術を介して前記所定のメディア記憶部から前記１つ以上のモバイルユーザ機器へとダウンロードすることを反復することとからなるステップをさらに含む、方法。
【請求項２１】
請求項２０のいずれか１つに記載の方法において、前記少なくとも１つの第２の条件は、前記ダウンロード済みの少なくとも１つのメディアコンテンツファイルの前記決定済み整合性特性が前記少なくとも１つのメタファイル内にて提供された閾値と合致するということとされている、方法。
【請求項２２】
請求項２０〜２１のいずれか１つに記載の方法において、前記少なくとも１つのメディアコンテンツファイルの前記整合性特性はチェックサム関数を活用して決定される、方法。
【請求項２３】
前記請求項のいずれか１つに記載の方法において前記サードパーティメッセージングサービスはクラウドベースドメッセージングサービスである、方法。
【請求項２４】
前記請求項のいずれか１つに記載の方法において、前記ステップ（ｄ）は、前記メディアコンテンツファイルについてシーケンスを形成するように前記メディアコンテンツファイルを所定の個数の別個のメディアコンテンツファイル部分に分割するステップをさらに含む、方法。
【請求項２５】
動画メッセージングシステムであって、該システムは、ソフトウェアアプリケーションと、前記ソフトウェアアプリケーションを動作させる少なくとも１つのモバイルユーザ機器と、メディア記憶・配信プラットフォームと、無線遠隔通信ネットワークと、少なくとも１つのサードパーティメッセージングサービスプラットフォームとを備えるのであって、前記動画メッセージングシステムは請求項１〜２４に記載の方法を実行するように構成されている、動画メッセージングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般には無線通信等のテレコミュニケーション分野に関する。特に、本発明は、メディアメッセージングサービスに関するのであり、より具体的には、メディアメッセージをモバイルユーザ機器に提供する方法及びシステムに関するのであり、また、動的に適応されるメディアプレイヤユーザインタフェースをモバイルユーザインタフェース上で生成することにも関する。
【背景技術】
【０００２】
この所１０年でデジタル技術は、消費者及び企業の両者に甚大な影響を及ぼした。当該影響はメディア業界において特に重大であり、通信へのアクセス及び／又はコンテンツへのアクセスのために消費者がよりモバイルデジタル機器を重宝するようになるにつれて、このことが生じた。また、高速ネットワークの普及により、より多くの人が己のモバイル機器にて動画コンテンツを視聴及び／又は伝達するようになるに至った。この変革を受け、遠隔通信プロバイダやアプリケーション開発者が様々なメッセージングサービス及び他の付加価値サービスを開発するに至った。 
【０００３】
モバイル機器がより強力なものとなるにつれて、ＭＭＳ（メディアメッセージングサービス）等のメッセージングサービスはより人気を博するようになった。なぜならば、これによれば、マルチメディアコンテンツ（例えば、音声、動画、テキスト、静止画、又はアニメーション等）をユーザフレンドリな態様でモバイルユーザ機器間で送受信できるようになるからである。通常は、例えばモバイル／セルラネットワークや無線ローカルエリアネットワーク（Ｗｉ-Ｆｉ（登録商標））等の無線ネットワークを介して、データをモバイル機器へと転送したり、そこから転送したりする。もっとも、データを送受信する際には相当の利用料がユーザに賦課され得る。特に、例えば動画クリップ等の大きなメディアファイルを送受信する際、又は、ユーザ機器上で適切なメディアプレイヤを生成するために必要とされる大きなデータファイルをダウンロードする際に、このことが問題となる。
【０００４】
また、多くのＭＭＳサービスプロバイダは送受信できる最大ファイルサイズに制約を課しており、ユーザがより大きなメディアファイルを転送したい場合、代わりにウェブサイトへのリンク（ＵＲＬ）の送受信が必要になり得る。そして、受信側ユーザは、メディアコンテンツをサーバからユーザ機器へとストリーミングするかダウンロードすることを要する。
【０００５】
さらに留意すべきことは、デジタルサービスが正統なモバイルマーケティングツールとなったのであり、これによって世界中の多くの箇所にいる消費者にまで働きかけることが可能であり、例えば、画像やアニメーション、さらには動画クリップ等を用いる広告を個別のモバイルユーザ機器（例えば、スマートフォンやタブレット）へと送ることによって、これをなせる。そのようなモバイルマーケティングを扱うことによって、潜在的顧客に対して時間及び／又は位置に応じたパーソナライズド情報を提供でき、特定の商品役務に関してプロモーションをなすことができる。また、モバイルマーケティングでは、例えばスマートフォンアプリ等のソフトウェアアプリケーションをマーケティング資源又は広告資源として活用する傾向が増大している。なぜならば、これによって役務／商品のプロバイダとターゲット顧客との間の相互作用を大幅に向上できるからである。
【０００６】
もっとも、マーケティング用メディアファイルを、モバイルネットワークを介して潜在的顧客へと送る際には、相当な費用をマーケターに強いることになり得る（即ち、MMSメッセージングを広告駆動型サービスとして用いることの費用は高費用となる可能性が高く、たとえ高度に割引されたバルクメッセージング単価を用いたとしても然り。）。
【０００７】
このため、例えば任意のサイズの動画メッセージをモバイル機器へ及び／又はモバイル機器から転送することができるメディアメッセージングサービスであって実行可能且つ効率的且つ高費用効率なメディアメッセージングサービスが必要とされている。さらに、ユーザ及びサービスプロバイダに対して改良及びカスタマイズされた機能性をもたらし得るシステム及びメディアメッセージングプラットフォームが必要とされており、個々に応じて適合された且つ動的なメディアコンテンツ、広告及び／又はユーザインタフェースを、ユーザ機器上で活用することを可能にすることによって、これがなされ得る。
【発明の概要】
【０００８】
本発明の好適実施形態は、上述の先行手法の欠点の１つ以上を克服することを目指す。
【０００９】
本発明の第１の観点によれば、動画メッセージングサービスを無線遠隔通信ネットワーク内の１つ以上のモバイルユーザ機器に対して提供する方法がもたらされるのであって、該方法は次のステップを含む：
（ａ）少なくとも１つのメディアコンテンツファイルを、所定のメディア記憶部にて受信及び格納するステップと、
（ｂ）前記少なくとも１つのメディアコンテンツファイルに関連付けられている少なくとも１つのメタファイルを生成するステップであって、該メタファイルは、（ｉ）前記少なくとも１つのメディアコンテンツファイルの第１のＵＲＬ（Uniform Resource Locator）と、（ｉｉ）前記少なくとも１つのメディアコンテンツファイルを前記所定のメディア記憶部から前記１つ以上のモバイルユーザ機器へと転送することを実効化するように構成された１つ以上の第１の自律的に実施可能な命令とを少なくとも備えている、生成するステップと、
（ｃ）サードパーティメッセージングサービスを活用しつつプッシュ技術を介して前記少なくとも１つのメタファイルを、前記１つ以上のモバイルユーザ機器へと送信するステップと、
（ｄ）前記１つ以上の第１の自律的に実施可能な命令に応答して、プル技術を介して、前記少なくとも１つのメディアコンテンツファイルを、前記所定のメディア記憶部から前記１つ以上のモバイルユーザ機器へとダウンロードするステップと、
（ｅ）前記少なくとも１つのメディアコンテンツファイルのダウンロード完了に応答して、前記１つ以上のモバイルユーザ機器にて、前記少なくとも１つの動画コンテンツファイルの利用可能性について通知するステップと、
（ｆ）所定のユーザ入力に応答して、前記１つ以上のモバイルユーザ機器に配されているメディアプレイヤアプリケーションを活用して前記少なくとも１つのメディアコンテンツファイルにアクセスするステップ。
【００１０】
これによって、例えば「真性なる」動画メッセージをモバイルユーザ機器へと直接的に送ることができるという利点がもたらされ、また、受信された動画メッセージについては、モバイルユーザ機器にて通知が受信された途端に受信された動画メッセージの全体が完全となって再生準備完了となっているものとすることができる。特に、メタファイル（命令ファイル）がモバイルユーザ機器へとサードパーティメッセージングサービスを介して（例えば、「無料な」Google（登録商標）クラウドメッセンジャ等を介して）プッシュ配信された後、メディアファイルは「バックグラウンド」でアプリケーションが画面上で可視化されずにダウンロードされるのであり、全ての必要なデータがモバイルユーザ機器にダウンロードされた後になって初めてユーザに対して当該データの存在について通知する。メタファイル内にて提供されるメディア要素はコンパイルされておらず、個別のデータファイルとして存在しており、これらは任意の標準的なウェブサーバに配置され得る。また、モバイルユーザ機器へと後に転送される実際のメディアコンテンツファイルについては、ファイルサイズ制限はない。商業的な影響（例えば、サーバからクライアントへのアプリケーション）を考慮するに、送信者が殆ど費用を負担せずにしてメッセージを送信し得るのであり、したがって、広告によって賄われる「ユーザへ到達するのに関して無料」なサービスが資金繰り的に実現可能となる。代替的には、本発明によれば、該方法をＰ２Ｐメディアメッセージングサービスとして使用することを可能とし、この場合、あるエンドユーザがメッセージを他のエンドユーザへと転送できる。
【００１１】
有益な態様について述べるに、ステップ（ａ）、（ｂ）、（ｃ）、（ｄ）、（ｅ）及び（ｆ）は順次実行することができる。好適には、前記少なくとも１つのメタファイルは、前記１つ以上のモバイルユーザ機器上の前記メディアプレイヤアプリケーションの動的適合可能メディアプレイヤインタフェースの作成を実効化するように構成された１つ以上の第２の自律的に実施可能な命令を、さらに備えることができる。代替的には、前記少なくとも１つのメタファイルは、前記１つ以上のモバイルユーザ機器に配されている前記メディアプレイヤアプリケーションの１つ以上のインタフェース特性を動的に修正するように構成された１つ以上の第３の自律的に実施可能な命令をさらに備えることができる。好適には、前記少なくとも１つのメディアコンテンツファイルは次のいずれか１つを備えることができる：少なくとも１つの動画ファイル、１つ以上のグラフィカルユーザインタフェース（ＧＵＩ）構成要素、及び外部メディアコンテンツをリンク及び／又は起動するように構成された１つ以上のＣＴＡ（Call To Action、召喚コール）機能性構成要素。
【００１２】
これにより、動的に適合可能なユーザインタフェースが、オンザフライ態様でモバイルユーザ機器上で生成できるという利点を享受でき、したがって、メデイアコンテンツ（例えば、動画）と、拡張された機能を伴い且つユーザの具体的なニーズに個別化（適合）され得るユーザインタフェースとを提供できる。例えば、メディアプレイヤのメニューオプションは次のことに応じて異なるものとなるように構成されていることができる：動画が現在再生中か停止中であるか、動画を終末まで視聴したか、又は日付若しくはメディアファイル受信時からの経過時間。したがって、メタファイルの受信に際して、モバイルユーザ機器のソフトウェアアプリケーション（例えば、インストール済みアプリ、又は生成／修正されたメディアプレイヤ）は、選択された基準に応じてどのようなタイプのインタフェースやコンテンツが最も望ましいかを決定できることとなり得る。
【００１３】
有利な側面に言及するに、前記少なくとも１つの動画ファイル、前記１つ以上のグラフィカルユーザインタフェース（ＧＵＩ）構成要素、及び前記１つ以上のＣＴＡ（Call To Action、召喚コール）機能性構成要素のうちの任意のものは、前記ユーザによって提供されたプロファイルデータに基づいて選択され得るのであって、前記プロファイルデータは１つ以上のプロファイルパラメータを含む。好適には、前記プロファイルデータは、所定のユーザプロファイル情報及び／又は所定のユーザプリファレンスを備え得る。より好適には、前記少なくとも１つのメディアコンテンツファイルは、前記１つ以上のＣＴＡ機能性構成要素と操作可能にリンクされている少なくとも１つの第２のＵＲＬをさらに備え得る。また、前記少なくとも１つの第２のＵＲＬは前記１つ以上のユーザプロファイルパラメータから生成されたクエリ文字列を備え得る。 
【００１４】
これによって、具体的なユーザ特性やユーザによって提供されたプリファレンスに合わせてメディアコンテンツを個別化できるという利点がもたらされる。 
【００１５】
有利な側面に言及するに、前記少なくとも１つのメタファイルは前記少なくとも１つのメディアコンテンツファイルと関連付けられているメタデータをさらに備え得る。
【００１６】
有利な側面に言及するに、前記少なくとも１つのメタファイルはＸＭＬフォーマットで提供されてそのファイルサイズが所定のファイルサイズ制限以下とされ得る。好適には、前記ファイルサイズ制限は４ｋＢとされ得る。
【００１７】
また、有利な側面に言及するに、前記ステップ（ｄ）、（ｅ）及び（ｆ）の任意のものは、フィードバックデータを生成し、及び、前記サードパーティメッセージングサービスを活用しつつプッシュ技術を介して前記フィードバックデータを送信するステップをさらに含み得る。好適には、前記フィードバックデータは前記サードパーティメッセージングサービス及び／又はＨＴＴＰを活用しつつプッシュ技術を介して送信され得る。さらに好適には、前記フィードバックデータは、前記メディアプレイヤアプリケーション及び／又は前記少なくとも１つのメディアコンテンツファイルとの相互作用との関連で検出されたユーザ挙動を含み得る。有利な側面に言及するに、前記フィードバックデータは前記１つ以上のＣＴＡ機能性構成要素に操作可能にリンクされていることができる。
【００１８】
これによって、ユーザ特性をサービス提供者に提供できるとの利点を得ることができ、よって、サービス提供者はより正確な態様でユーザに向けて具体的なサービスをカスタマイズできるようになる。 
【００１９】
有利な側面に言及するに、前記ステップ（ｄ）の実行は所定の第１の条件に服し得る。好適には、前記第１の条件は前記無線遠隔通信ネットワークはセルラ電話ネットワークではないということとし得る。より好適には、前記第１の条件は、前記無線遠隔通信ネットワークは無線ＬＡＮ（ＷｉＦｉ（登録商標））であるということとし得る。
【００２０】
これによって、モバイルユーザ機器へのデータ転送費用が最小化されるという利点がもたらされる。
【００２１】
有利な側面に言及するに、前記ステップ（ｄ）は、前記ダウンロード済みの少なくとも１つのメディアコンテンツファイルについての整合性特性を決定することと、少なくとも１つの第２の条件に服して、プル技術を介して前記所定のメディア記憶部から前記１つ以上のモバイルユーザ機器へとダウンロードすることを反復することとからなるステップをさらに含み得る。好適には、前記少なくとも１つの第２の条件は、前記ダウンロード済みの少なくとも１つのメディアコンテンツファイルの前記決定済み整合性特性が前記少なくとも１つのメタファイル内にて提供された閾値と合致するということとし得る。より好適には、前記少なくとも１つのメディアコンテンツファイルの前記整合性特性はチェックサム関数を活用して決定され得る。
【００２２】
有利な側面に言及するに、前記サードパーティメッセージングサービスはクラウドベースドメッセージングサービスとし得る。
【００２３】
本発明の第２の態様によれば、動画メッセージングシステムが提供されるのであって、該システムは：ソフトウェアアプリケーションと、前記ソフトウェアアプリケーションを動作させる少なくとも１つのモバイルユーザ機器と、メディア記憶・配信プラットフォームと、無線遠隔通信ネットワークと、少なくとも１つのサードパーティメッセージングサービスプラットフォームとを備えるのであって、前記動画メッセージングシステムは本発明の第１の態様の方法を実行するように構成されている。
【図面の簡単な説明】
【００２４】
添付の図面は本開示の現に例示的な実施形態について例示するのであり、添付の図面は先述の概要的説明と後述の詳細な説明と共に例示によって本開示の原理について説明する。したがって、本発明の好適実施形態については限定的な意味合いではなく例示的意味合いのみで説明するのであり、添付の図面を参照して説明がなされる。
【００２５】
【図１】動画メッセージングシステムの基本的システムアーキテクチャについての概略図である。
【図２】システムコンポーネント間のオペレーションを含む動画メッセージングシステムの詳細なシステムアーキテクチャについての概略図である。
【図３】モバイルユーザ機器と新規動画メッセージの着信を表すアプリインタフェースとについての概略図である。
【図４】aのアプリの通知エリアについての概略図であって、新規動画はメタファイルから取得されたメッセージについての簡単な説明を含み、メニューのアイテムを選択するとメディアプレイヤが起動されて動画クリップが自動再生される、概略図である。
【図５】複数の動画クリップを含むアプリ内動画受信箱についての概略図である。
【図６】動画受信箱内の展開されたカスタムオプションメニューについての概略図である。
【図７】動画再生中のモバイルユーザ機器上のアプリインタフェースについての概略図であって、それは右側に３つのオンスクリーンボタンを含み、オンスクリーンボタンの機能及びグラフィクスはメタファイル内にて定義されている、概略図である。
【図８】例示的なメタファイルについて示す図である。
【発明を実施するための形態】
【００２６】
本発明の例示的実施形態は、無線ネットワークを介して１つ以上のモバイルエンドユーザ機器に提供される動画メッセージングサービス（サーバツークライアントアプリケーション）との関係で説明される。もっとも、当業者ならば、本発明は任意の他のタイプのメディア及びＰ２Ｐアプリケーション構成においても用い得ることに気付くであろう。
【００２７】
説明の為に述べるに、本稿にて用いられる「決定」、「算定」、「演算」、やそれらに類する用語は、可換に用いられているのであり、任意のタイプの方法論、処理、数学的演算や手法を含み得ることに留意されたい。また、「生成」及び「適合」との用語も可換に用いられているのであり、アナログ・デジタルメディアデータ（例えば、音声や動画）を扱うための任意のタイプのデータ・信号処理法を表す。「コンテンツ」又は「メディアコンテンツ」との用語は、音声、テキスト、グラフィクス、動画、画像、アニメーション、及び他のあり得るメディア形態を含むものと解するのが相当である。また、「アプリ」及び「ソフトウェアアプリケーション」との用語は可換に用いられているのであり、特定の目的のために設計されておりモバイルユーザ機器にダウンロード可能なコンピュータプログラム若しくはソフトウェアを表す。本発明を不明確にしないために、周知の技術及び手法については詳述していないことを諸兄らは了承されたい。したがって、本稿にて開示される具体的な構造的及び機能的詳細事項は、限定的な特徴として解されてはならず、単に特許請求の範囲の基礎として及び当業者に教示するための基礎としての役割を果たすに過ぎない。
【００２８】
図１及び２を参照するに、本発明の１つの実施形態では、動画メッセージングシステム１００は少なくとも１つのプッシュサーバ１０２を備えるのであって、該サーバは例えばGoogle（グーグル）（登録商標）クラウドメッセージング（ＧＣＭ）等のサードパーティメッセージングサービス１０６を活用するように構成されてメッセージを１つ以上のモバイルユーザ機器２００へと「プッシュ」する。プッシュサーバ１０２は次のことをなすようにさらに構成されている：ＧＣＭサーバとの接続を「スーパバイズ」（即ち、管理）すること；ユーザデータベースを維持・更新（ユーザフィードバックを維持及び更新）すること；及びコントローラにユーザインタフェースを提供すること。好適には、プッシュサーバ１０２は、高速インターネット接続を介してＧＣＭサーバ１０６と接続されている。
【００２９】
動画メッセージングシステム１００は少なくとも１つのメディアサーバ１０４をさらに備え、該サーバは、プッシュサーバ１０２に動作可能に接続されており、メディアファイルを格納しまた例えばＧＣＭサーバ１０６からのメッセージの受領を受けてメディアファイルを送信するように構成されていることができる。当業者ならば、メディアサーバ１０４から１つ以上のモバイルユーザ機器２００へとメディアファイルを「プル」するために任意の他のトリガを用い得ることに気付くであろう。 
【００３０】
例えばＧｏｏｇｌｅクラウドメッセージング（ＧＣＭ）サービス等のサードパーティメッセージングサービスは次のものを含む：グーグルによって提供されている接続サーバ１０６、接続サーバと相互作用するサードパーティアプリサーバ（不図示）、及びモバイルユーザ機器２００上で実行されているＧＣＭ利用可能クライアントアプリ。 
【００３１】
ＧＣＭサービスを自己のアプリケーションと共に活用することを望むサードパーティ開発者に向けて、ＧＣＭサービス１０６が利用可能とされている。この点で、ＧＣＭソフトウェア核心部は本体たるアンドロイド（登録商標）ＳＤＫの拡張としてフリーな態様で利用可能とされている。ＧＣＭサービス自体は、無償にてグーグルから得ることができ、ある一日において送信できるメッセージ数には制限はない。
【００３２】
この例示的実施形態では、ＧＣＭソフトウェアはモバイルユーザ機器アプリに統合されており、Ｊａｖａ（登録商標）プログラミング様式で言う「リスナー」（イベント駆動関数、一部の他のプログラミング言語では「コールバック」とも称される。）を用いてこれが実装されている。該手法は、ＧＣＭメッセージ受領等のイベントをソフトウェアが扱うに際しては高度に効率的な手法である。常態的に何らかの受領済みメッセージについて確認をすることに代えて、メッセージが着信した際のみに通知がトリガされる。当該通知はＯＳに対してレジスタされるのであって、このような通知を受信するためにアプリケーションが実際に実行中であることを要さない。
【００３３】
本発明と共にＧＣＭを活用するに際して、ＧＣＭサービスはメッセージをモバイルユーザ機器２００へと送る際のより複雑な諸側面の多くを捌く。例えば、固有識別子（ＩＤ）を有するアンドロイド携帯へとメッセージを送るためにＧＣＭを用いることによって開発者は、モバイルユーザ機器２００がどのネットワークに接続されているかという論点については考慮することを要せず該軛からは開放され、また、特定の接続を介してどのようにデータを送るべきかについても考慮せずに済む。また、ＧＣＭは格納／転送機能をも提供するのであり、何らかの理由によってモバイルユーザ機器２００に到達できない場合、メッセージはキューイングされて後程そのメッセージの配信が自動的に再試行される。
【００３４】
また、明示的な通信ネットワークの関与を要していないことにも留意されたい。
【００３５】
ＧＣＭソフトウェアは、ＯＳ２．２以上をサポートするアンドロイド携帯全てで機能するように適合化されているが、ＯＳ３．０迄の旧式モバイルユーザ機器２００に関してはユーザが先ずグーグルアカウントを端末上でセットアップすることを要し得る。ＯＳ４．０．４以降に関しては、グーグルアカウントは必要ではなく、ユーザ関与なくしてＧＣＭが機能する。
【００３６】
当業者ならば、説明した例示的実施形態はグーグルクラウドメッセージングネットワークを活用することを理解できるのであるが、本発明の動画メッセージングサービス及びシステムは、同様にして他のクラウドメッセージングフレームワークをも活用できる。
【００３７】
動画メッセージングサービスアーキテクチャ・フレームワーク
ＧＣＭはサードパーティアンドロイド開発者にとって便利なメッセージ送達機構である。もっとも、プッシュ型メッセージに関してＧＣＭで許される現行の最大ファイル（メッセージ）サイズは僅か４ＫＢ（キロバイト）に過ぎず、これは比較的少量のデータであり、したがって、動画メッセージングを可能とするには容量が足りない。
【００３８】
よって、本発明はＧＣＭを活用してプロプライエタリなＸＭＬベースドメタファイルを送るのであり、これの最大ファイルサイズはＧＣＭサイズ制限（例えば、４ＫＢ）未満とされる。このメタファイルは、例えば、メディアコンテンツ（動画及びあるならばグラフィクス）の全てをどこからダウンロードできるかを表すＵＲＬとかを含み得る。実際のメディアはメディアサーバ１０４上に配置され、メタファイル内のＵＲＬによって指される箇所に配置される。
【００３９】
本発明（システム及び方法）の例示的実施形態の典型的な動作態様について以下説明するのであり、具体的には図２への参照を伴う。プッシュサーバ１０２は先ずメッセージをＧＣＭサーバ１０６へと送るのであって、端末へ小さなメッセージを送ることの全側面がここで扱われる。これは、例えば、モバイルユーザ機器２００がオフラインである場合のメッセージのキューイング及び／又は格納を含む。
【００４０】
モバイルユーザ機器２００上にインストール済みのソフトウェアアプリケーション（アプリ）が利用された初回においては、固有な識別番号（ＩＤ）がその具体的なユーザについて生成されるのであって、そしてそれがＧＣＭサービスにて登録される。固有識別番号（ＩＤ）は、プッシュサーバ１０２へと自動的に送られるのであって、新規モバイルユーザ機器２００の将来における特定が可能となる。
【００４１】
着信ＧＣＭメッセージが受領されたらば、ＧＣＭリスナーフレームワークがコールされて、その小容量バイナリペイロード（即ち、最大で４ＫＢ）がソフトウェアアプリケーションへ配信される。この具体的な例では、ＧＣＭメッセージペイロードはＸＭＬ（eXtensible Markup Language、拡張可能マークアップ言語）ファイルとして解釈され、これは解析器（構文解析器）へと送られて、モバイルユーザ機器２００上に配されているソフトウェアアプリケーション（アプリ）によって必要とされている任意の具体的な情報を抽出する。このようにして伝達できる多くのパラメータについて述べるに、最も肝要なものはメディアコンテンツのＵＲＬであり、これは本体たる動画ファイル及びモバイルユーザ機器のメディアプレイヤによって必要とされる任意の他のメディアのアドレス（ダウンロードリンク）をアプリに提供する。 
【００４２】
ＸＭＬメタファイルを受領したらばソフトウェアアプリケーション（アプリ）はマルチメディアクリップによって必要とされるメディア要素（ボタングラフィクスや説明的テキストを含む）のリストを生成して、そしてそれぞれを順次ダウンロードする。メディアコンテンツがメディアサーバ１０４からバックグラウンドプロセスでダウンロードされる間、モバイルユーザ機器２００は「サイレント」状態に留まる。全てのメディアアイテムがモバイルユーザ機器２００にダウンロードされたらば、ユーザ通知が生成されてモバイルユーザ機器２００上で表示される。
【００４３】
データ（例えば、主動画ファイル）が適正に送信されたことを検証するために、ＸＭＬファイルのメディア記述子内にファイルチェックサムが含められていることができる。もっとも、当業者ならば、任意の適切な送信検証方法を用いて任意のダウンロードコンテンツに適用することができるということを理解できよう。動画ファイルの受領時にモバイルユーザ機器によって決定されるチェックサムがメタファイルから抽出された値と合致しない場合、モバイルユーザ機器に対して成功裏な送信がなされる迄動画ファイルのダウンロードが再試行され続けられる。さらに、代替的ダウンロード元（代替ＵＲＬ）をメタファイル内に提供しておいてダウンロード失敗試行回数が所定回数を超過した場合にこれを用い得る。
【００４４】
使用時においては、次のステップがメディアメッセージングシステムによって実行される：
（ｉ）  オペレーションセンタ内に配されているＰＣワークステーション上でメディアコンテンツ（動画、グラフィクス等）及びＸＭＬメタファイルをこしらえるステップ；
（ｉｉ）  ＸＭＬメタファイルがプッシュサーバ１０２へと例えばインターネットリンクを介してアップロードするステップ；
（ｉｉｉ）  （対応するＸＭＬメタファイルによって参照されている）メディアファイルをメディアサーバ１０４へ例えばインターネットリンクを介してアップロードするステップ；
（ｉｖ）  そしてプッシュサーバ１０２が次のことを行うステップ：  
・  ＧＣＭサーバとのインタフェースを提供するステップ、
・  ユーザＤＢを維持するステップ、 
・  ユーザフィードバック統計を維持するステップ、
・  管理用コントロールパネルを提供するステップ、
（ｖ）  メディアサーバ１０４がメディアファイルを格納するステップ；
（ｖｉ）  プッシュサーバ１０２とＧＣＭサーバ（ＧＣＭＳ）１０６との間の高速インターネットリンクを確立するステップ；リンクによってＸＭＬメタファイルをプッシュサーバ１０２からＧＣＭＳ（１０６）へと「下流」へプッシュすることが、又は、「上流」へのメッセージをモバイルユーザ機器２００からＧＣＭＳ１０６を介してプッシュサーバ１０２へと渡すことができる；
（ｖｉｉ）  例えばＨＴＴＰ  プロトコル（HTTP protocol）を用いて以下の情報を送信するために、モバイルユーザ機器２００からプッシュサーバ１０２へのインターネットリンクをＯＴＡ（Over-The-Air）態様で確立するステップ；
・  ＧＣＭ登録情報、
・  ユーザプレファレンス及び設定（チャンネル定義及び選択を含む）、
（ｖｉｉｉ）  ＸＭＬメタファイルをＧＣＭＳ１０６からモバイルユーザ機器２００へと（ＯＴＡで）「プッシュ」すること及びモバイルユーザ機器２００からＧＣＭＳ１０６を介してプッシュサーバ１０２へと向かう逆行「アップストリーム」フィードバック経路を伴うステップ；
（ｉｘ）  ＧＣＭＳ１０６にてのメッセージ受領を受けて、モバイルユーザ機器２００上にインストール済みのソフトウェアアプリケーション（アプリ）がＸＭＬメタファイルを処理して、必要なメディア全てをメディアサーバ１０４から自動的にダウンロードするステップ； 
（ｘ）メディアサーバから端末へのインターネット（ＯＴＡ）：ＧＣＭＳ１０６を介してのプッシュメッセージ（メタファイル）の受領を受けて、モバイルユーザ機器２００は、必要とされるメディアコンテンツをメディアサーバ１０４から「サイレント」な態様で（即ち、バックグラウンドプロセスとして）「プル」するステップ。
【００４５】
モバイルユーザ機器上での動画メッセージの受信及び再生
次の処理及びユーザ相互作用はモバイルユーザ機器２００上で繰り広げられる。この具体的な例では、専用のソフトウェアアプリケーション（アプリ）がモバイルユーザ機器２００にインストールされている。特に図３乃至７を参照する。
【００４６】
動画メッセージを受領したらば、メッセージ通知を標準通知として、例えばいつものアンドロイド通知エリア２０２内で、こしらえることができる。そして、ユーザは、例えば通知エリアのアイコンを選択することによって動画メッセージを直接的に再生するか、又は、デスクトップアイコンを選択することによってアプリケーションを実行してメッセージ受信箱２０４から新規メッセージを開くことができる。
【００４７】
新規動画メッセージはメッセージについての簡素な説明（対応するメタファイルから取得された情報）を含み得る。通知エリア２０２内の動画メッセージを選択すると、メディアプレイヤが起動され得るのであり、動画クリップ２０６が直接的に（即ち、動画メッセージ受信箱を表示せずに）自動再生される。
【００４８】
この具体的な例では、動画メッセージ受信箱２０４は、各関連付け動画クリップ２０６を再生するのに必要な全てのメディア及びメタファイルを含むディレクトリとして実装されている。各リストアイテムの受領を受けて、ソフトウェアアプリケーション（アプリ）は対応するメタファイルに対してクエリを行って、次の例示的情報を抽出する：
・  動画ファイルの名称、
・  サムネイル画像ファイルの名称、
・  動画クリップの題名、
・  メッセージが新しいもの（未視聴）であることを示すフラグ（即ち、任意の適切な指示子）。
【００４９】
「新規メッセージフラグ」が設定されている場合、動画クリップアイコンの背景は明るい黄色（又は他の適切な色）に着色されていることができる。動画クリップ２０６が一旦再生されたらば、背景色は既定の青灰色（又は他の適切な既定色）に戻される。
【００５０】
メディアアイテムの利用可能個数が利用可能モバイルユーザ機器のウィンドウ空間に収まりきらない場合、受信箱ビューは一般的に知られている方法で上下にスクロールされることができ、また、縦長及び横長の両方で動作し得る。
【００５１】
ユーザが「長押しクリック」でアイテムを押下すると、選択アイテムの再生が即座に開始され得る。ユーザが「通常クリック」で受信箱アイテムを押下すると、メニュー２０８が表示され得る。メニュー２０８は、動画クリップ２０６を再生する選択肢を提供するだけでなく、動画クリップ２０６に関連付けられた様々な他の機能を含み得る。 
【００５２】
図６に示されるメニュー２０８は、受信箱アイテムの１つ、即ち動画クリップ２０６に対しての「通常クリック」に応答して提供され、この特定の動画クリップ２０６に関して利用可能な選択肢をさらに表示する。例えば「再生」や「削除」や「設定」等の幾つかの選択肢は、すべての動画クリップ２０６に関して利用可能とされ得る。しかし、「リンク」アイコン２１０で示されるような他の選択肢は、各動画クリップ２０６のために特別に構成され得る。即ち、「リンク」アイコン２１０で示されるメニューボタンは、ユーザが様々な方法でメディアプレイヤと相互作用することを可能とする選択肢たり得る。「クリップ情報」選択肢を用いると、ユーザに対して、動画クリップについての簡素な説明と小さなサムネイル画像とを伴うポップアップダイアログボックスが、もたらされ得る。「再生」を、上記ポップアップメニューから選択するか、又は通知エリア２０２のプレーヤアイコンをクリックすることによって選択すると、メディアプレイヤ画面がアクティブ化される。
【００５３】
図７は、主画面２１２で再生中の動画を示し、３つの画面上のボタン２１４，２１６，２１８が画面の右側に提供されている。画面上のボタン２１４，２１６，２１８のリンク及びサムネイルグラフィクスはメタファイル内で定義されており、また、ポップアップメニュー２０８のものと同じでも異なっていてもよい。サムネイルグラフィックはボタン定義の一部であり、メディアサーバ１０４からダウンロードされる。典型的なモバイルユーザ機器画面の物理的なサイズ制限により、３つまたは４つの画面上のボタン２１４，２１６，２１８がボタンに関しての実際的な最大数になり得るが、ソフトウェアアプリケーション内には固定の制限個数は設けられていない。ボタン個数を増やす1つの方法としては、スクロール可能なボタン領域を用いることが挙げられ、該領域ではさらに多くのボタンを定義し、そして一般的に知られている方法でスクロールするものとし得る。
【００５４】
また、メイン画面エリア２１２は、動画エリアの全画面にわたって「最大化」されて構成されていることでき、オンスクリーンボタン２１４、２１６、２１８を隠蔽することによって又はオンスクリーンボタン２１４，２１６，２１８と共に動画が示される「最小化」によってこれをなし得る。
【００５５】
ユーザ設定＆プロファイリング
モバイルユーザ機器２００上にて提供されるソフトウェアアプリケーション（アプリ）又はメディアプレイヤは、ユーザが、ユーザが受け取ることを希望するメディアコンテンツのタイプに関する任意の選好を指定することを可能にする。これによって、ユーザが望んでおり且つユーザが興味を有しているメディアコンテンツのみが、顧客（即ち、ユーザ）に送られることが保証される。ソフトウェアアプリケーション又は変更されたプリインストールメディアプレイヤを介して提供されるユーザプレファレンスにより、より具体的な広告ターゲティングが可能となり、したがって、広告機会に関して強化がなされる。
【００５６】
メディアプレイヤの設定とプロファイリング機能は、次の３つのサブカテゴリに分類される：
・  個人プロファイル設定、
・  チャンネル選択、及び
・  アプリケーション設定であり、
これら３つの設定項目の各々に関しては、独自の設定画面が設けられていることができる。
【００５７】
特に、アプリケーションの初回利用時に、プロファイル情報が自動実行セットアップウィザードによって収集される。このプロファイリングプロセスでは、個人プロファイル設定と（存在する場合には）チャンネル選択とに対応する２つのセットアップ画面が表示される。２つの画面及びアプリケーション設定画面には、後でメニューシステムからアクセスして、何らかのプレファレンスや設定を変更することもできる。ユーザの同意を条件として、ユーザプロファイルデータは、メタファイルで提供される基本ＵＲＬとマージすることができる。例えば、音楽ウェブサイトへのリダイレクトがカスタムメニューウェブリンクを定義でき、次の形式を取り得る：http://www.musicwebsite.com/homepage.html?[年齢][音楽の＿プレファレンス]。ここで、ブラケット内のパラメータは、最終ＵＲＬ内にユーザプロファイルからの「年齢」及び「音楽のプレファレンス」を含めるようメディアプレイヤに要請するためのリクエストを示すために用いられるプレースホルダーである。もっとも、当業者であれば、任意の他のパラメータをクエリ文字列に追加してり他のものと代替させたりすることができる、ということに気付くであろう。
【００５８】
メタファイルフォーマット及びカスタマイズドメニュー及びフィードバックオプションの仕様
動画メッセージに必要な全てのメディアアイテムのＵＲＬに加えて、メディアプレイヤが様々な追加機能を提供できるようにする他の情報を提供できる。
【００５９】
例えば、メタファイルは次の項目も含み得る：
・  再生されるべき動画のファイル名及び短い説明文；
・  動画のＵＲＬ及び必要なグラフィクス及びテキストファイル；
・  メディアプレイヤ又はアプリメッセージ受信箱のどちらかから召喚できるカスタマイズドメニューについての何らかの定義（これには任意のカスタマイズドメニューボタン用のサムネイルグラフィクスも含まれ得る）；
・  アプリケーション受信箱２０４及び通知エリア２０２内に表示されているアイコンについてのサムネイルグラフィクス（図５，６，７を参照）；
随意的には次の項目も含まれ得る：
・  ワンクリック検索機能用の検索語句の定義； 
・  フィードバック及び報告データについての定義； 
・  特定の時点にてユーザに対して通知を発するのに適したタイミング機能；
・  特定の時刻にてメッセージを自動削除する為のタイミング機能。
【００６０】
ユーザ応答機構
特定用途目的のソフトウェアアプリケーション（アプリ）を介して動画メッセージにアクセスすると、便利なカスタマイズが可能となる。このようなカスタマイズの1つとしては次のことを挙げ得る：受信したメッセージにすばやく簡単に応答したり対話したりできるようにするフレームワークを提供すること。これを達成するために、オーサリング段階でメタファイル内にて様々なユーザフィードバックオプションを「メッセージ毎に」指定する。ソフトウェアアプリケーションは、メタファイル内の情報を処理して、選択したメッセージに応じて応答オプションを表示する。 
【００６１】
メッセージ毎に、次のカスタムメニューオプションが指定される：
・  メニューオプションについてのラベルテキスト（例えば、トラックを注文、ウェブにさらに載っているぞ等）； 
・  フィードバック応答のタイプ。
【００６２】
また、次のタイプのフィードバック応答（例えば、ＣＴＡ（Call To Action、召喚コール））をサポートすることが可能である：
・  特定の電話番号（販売班の回線）へと発信すること；
・  自動生成されたＳＭＳを特定の電話番号へと送信すること；
・  特定のＵＲＬに関してブラウザを起動すること。
【００６３】
ＳＭＳ及びＵＲＬでブラウズするの両オプションの場合、メタファイルから抽出された追加データを含めて、動画クリップの識別と追跡とを支援できる。また、ＳＭＳ及びＵＲＬでブラウズするの両オプションの場合、ユーザプロファイルからのデータ（許可取得が条件）は、ＸＭＬメタファイルで指定された「基本データ」にマージまたは追加されることができる。これによって、例えば、被アクセスウェブサイトの所有者が、来訪者についての何らかの情報を、アプリケーションから知ることがきるかもしれない。
【００６４】
ＳＭＳフィードバックの場合、このデータはＳＭＳテキスト本文に自動的に含められ、ＵＲＬでブラウズするオプションに関しては同じ情報をクエリ文字列としてメディアサーバ１０４に送ることができる。
【００６５】
したがって、ＵＲＬでブラウズする機能は、次の機能を提供できる：
・  別の動画クリップを識別するためにクエリ文字列内の情報でプッシュサーバ１０２のＵＲＬを指定する機能（したがって、ＵＲＬでブラウズする機能はメディアサーバ１０４から別の動画クリップをリクエストするために用いることができる）；
・  閲覧されているコンテンツに固有な「今購入する」ウェブページへのリンクをユーザにもたらす機能；
・  閲覧されている動画クリップに関連する予め定義された検索語句（メタファイル内）を使用して検索エンジンとリンクする機能（この機能によって、ユーザ入力（例えば、検索キーワードのキーイン等）を何ら必要とせずに「ワンクリック」検索機能を実現し得る）；
・  別の動画クリップを識別するためにクエリ文字列内の情報でプッシュサーバ１０２のＵＲＬを指定する機能（したがって、ＵＲＬでブラウズする機能はメディアサーバ１０４から別の動画クリップをリクエストするために用いることができる）。
【００６６】
データキャプチャ
本発明のソフトウェアアプリケーションは、２通りの方法で分散メッセージに応答してユーザデータを収集するために使用され得る。 
（１）  ＧＣＭサービス１０６を介してプッシュサーバ１０２へと返戻される自動生成メッセージでなされる場合。このメッセージは、動画の「再生」が停止したとき、又は終了したときに自動的に送信できる。このモードは、ユーザの明示的なアクションや介入に依存しないため、「自動レポート」と呼ばれ得る。 
（２）  再生終了ボタン又は主ポップアップメニューからブラウザが起動された場合、データをウェブサーバが収拾することもできる。この場合、ユーザは意識的にフィードバックボタンを押下して特定のウェブサイトを訪れることができる。 
【００６７】
収集可能データには次の事柄が含まれ得る：
・  動画が既視聴であるか；
・  動画を終末まで視聴したか；
・  動画閲覧回数；
・  （プッシュサーバ１０２によって割り当てられた）クリップＩＤ；
・  モバイルユーザ機器のＩＭＥＩ番号；
・  モバイルユーザ機器のアンドロイド識別番号；
・  モバイルユーザ機器の型式； 
・  通信ネットワーク；
・  モバイルユーザ機器の言語設定；
・  動画クリップに関連付けられている任意の検索語句（受信サーバが検索エンジンである場合、これはウェブフィードバックに関して特に役立つ）；
・  任意の選択済みオンスクリーンボタンＩＤ（ウェブフィードバック専用）；
・  任意の選択済みオンスクリーンボタンのテキスト（ウェブフィードバック専用）。
【００６８】
ユーザが個人プレファレンスの設定を済ましている場合、（プライバシの扱いに影響されるが）以下のパラメータについても収集できる：
・  選択チャンネルについてのリスト；
・  ユーザの性別；
・  ユーザの生年月日；
・  個人プレファレンス欄にて提供された他のパラメータ。
【００６９】
この特定の例では、該文脈でのアンドロイドＩＤはオペレーティングシステム（ＯＳ）によって返されたＩＤであり、ＧＣＭサービスによって割り当てられた番号とは異なるものと諸兄は理解されたい。
【００７０】
要約するに、本発明の例示的実施形態の方法（ソフトウェアアプリ）は、数分におよぶ再生長の良質動画メッセージを配信することができる。メッセージ自体は無料で配信され、ネットワークオペレーターの明示的な関与または参加を要さない。ユーザは個人プレファレンスを指定して、サービス運営者がユーザ個々の嗜好に訴求するようにさらに正確に調整したメディアコンテンツを配信できるように支援できる。重要なことに、本発明によれば、受信した動画メッセージに対して応答又は対話することに関して様々な方法をユーザがとれるようになる。このような対話は、例えば、特定のウェブサイトにユーザを誘導して関連するメディアコンテンツをさらにダウンロード又は閲覧させるということであったり、追加の関連情報を検索させるということであったり、又は電子商取引用途に関しては単一押下によるＣＴＡ（Call to Action）たり得る。ユーザ応答オプションの詳細は高度に柔軟であり、クリップのオーサリング段階でメッセージ毎に定義され得る。さらに、本発明は、詳細な利用情報を収集する手段を提供するのであり、広告主にとっての価値をさらに高める。例えば、広告駆動型収益モデルでは、広告を動画機能と組み合わせることができる。これらの形式としては次のものが挙げられる：メインフィーチャの開始時及び／又は終了時の短い動画広告、再生終了後に表示される静的なグラフィック、及び広告主のウェブサイトにリンクするカスタムメニューオプションの採用。 
【００７１】
また、メディアサーバ１０４に別のビデオクリップを要求する機能によって、はるかに長い動画を適切な数の小さなクリップに分割でき、別々の「エピソード」として送信することができる。シリーズ中の各エピソードに関しては３つ以上のオンスクリーンオプションボタンが与えられ得るのであり、これによって次の両方のことを可能たらしめる：（ｉ）シリーズにおける次のエピソードをリクエストすること；及び（ｉｉ）特定の従前のエピソード若しくはエピソードの一般的シリーズのどちらかに関連する他のコンテンツへのＨＴＭＬリンクを提供すること。次のエピソードをリクエストする機能を提供するオンスクリーンボタンには、現在の再生中時間及び／又はエピソード番号をも付加されていることができ（例えば、ＸＭＬメタファイルから取得）、現在のクリップが再生中にこれをリクエストできる。代替的には、シーケンス中の次のエピソードは、現在のエピソードの所定の割合（例えば、全再生時間の５０％）が視聴済みとなった後に自動的にリクエストできる。
【００７２】
受信箱表示オプション
メタファイルに含まれる情報に関して、各動画クリップ２０６にタグ付けして、受信箱２０４内について様々な表示オプションをもたらし得る。 
【００７３】
例えば、タグを追加してフィルタリングを可能として、ユーザが特定のカテゴリーの動画クリップ２０６のみを表示することを選択できるようにできる。 
【００７４】
代替的には、動画クリップ２０６は、アルファベット順に表示若しくはソートされ得るか、又は特定の検索語句に従って表示され得る。例えば、動画クリップ２０６は、シーケンスの複数の部分又は「エピソード」として送信されてもよく、シーケンス中の動画クリップ２０６を次のようにタグ付けできる：全ての構成要素を受信箱２０４にアグレゲートさせて、一連の動画クリップ２０６を受信箱２０４内の単一アイテムとして表示すること。 
【００７５】
Ｐ２Ｐメッセージング転送
本発明の動画メッセージングサービス及びシステムを純粋なサーバ・クライアント・サービスとして使用するだけではなく（即ち、エンドユーザに対してサービスを直接的に提供すること）、本発明の実施形態によれば、エンドユーザ間でＰ２Ｐサービスのために用いることもできる（即ち、あるエンドユーザから別のエンドユーザへと動画メッセージを転送又は送信できるのであり、本発明のメッセージングサービスを活用してこれをなせる）。
【００７６】
以下は、転送を介してなされるＰ２Ｐメッセージング（ステップバイステップ型）についての本発明の使用法を説明する第１の例である。
【００７７】
（１）  モバイルユーザ機器２００にインストールされたソフトウェアアプリケーション（アプリ）が初めて起動されるとき、固有なＧＣＭ割り当て番号（ＩＤ）がクライアントデータベースにログされる。この情報と共に、ユーザを識別できるようにする追加情報（例えば、電話番号及び／又は電子メールアドレス等）が、この固有ユーザIDと共にログされ得る。追加の連絡先情報（電話番号、電子メールアドレス）は、第２のユーザの連絡先情報を所有している第１のユーザが、メディアメッセージ（例えば、元来メディアサーバ１０４から送信された）を、第2のユーザ（例えば、友人または他の連絡先）へと転送することを可能とする。
【００７８】
（２）  モバイルユーザ機器２００から動画メッセージを転送するために、特殊なＨＴＴＰリクエストをメディアサーバ１０４へと送信でき、該リクエストは次のことに関する：（ｉ）動画クリップ２０６が転送されるべき旨；（ｉｉ）動画クリップ２０６を送信する者（即ち、他のユーザ、ＩＤ）が誰であるか；及び（ｉｉｉ）誰が（自局の電話番号又は電子メールによって指定されている）宛先となっているか。  
【００７９】
（３）  このＨＴＴＰリクエストを受信したらば、メディアサーバ１０４は、与えられた宛先人の電話番号又は電子メールから関連するＧＣＭネットワークＩＤを決定して、指定された動画クリップ２０６を指定されたモバイルユーザ機器２００へと送信するリクエストを生成する。したがって、あるユーザから別のユーザへと動画クリップ２０６を転送する処理は、指定された動画クリップ２０６をメディアサーバ１０４から指定されたモバイルユーザ機器２００へと直接的に送信するリクエストを中央サーバへと送信するのと結果的に等価である。 
【００８０】
（４）  指定された電話番号又は電子メールが既存のＧＣＭユーザIDと関連付けられていない（又はデータベース内において見つからない）場合、即ち、宛先人が適切なソフトウェアアプリケーション又はアプリをモバイルユーザ機器２００上にまだインストールしていない場合、テキストメッセージ又は電子メールが自動生成されて指定された宛先人へと送信されてもよいのであり、それには必要とされるソフトウェアアプリケーション又はアプリをダウンロード及びインストールするためのリンクが含まれ得る。
【００８１】
以下は、ユーザによって生成されたメディアコンテンツに関してのＰ２Ｐメッセージング（ステップバイステップ型）についての本発明の使用法を説明する第２の例である。
【００８２】
本発明の実施形態を用いてユーザ自身のモバイル機器２００で撮影された写真または動画等のユーザ生成メディアコンテンツを別のユーザに送信することもできる。必要な手順は、あるユーザから別のユーザにメッセージを転送する手順と同様である。特定のバリエーションでは、「送信リクエスト」が中央メディアサーバ１０４で生成される前に、ユーザが先ずユーザ生成メディアコンテンツを中央メディアサーバ１０４にアップロードすることを要する。イベントのシーケンスは、ＸＭＬ命令ファイル（即ち、メディアコンテンツに関連付けられており且つプッシュサーバ１０２を介してプッシュされたメタファイル）の自動生成及びアップロードと共に自動的にスケジュールされていることがきる。
【００８３】
当業者ならば、上述の実施形態は例示的な意味のみにおいて説明されているのであり何ら限定的な意味合いで説明されてはいないことを理解できるのであり、添付の特許請求の範囲にて画定された発明の範疇から逸脱せずに様々な変更例や改造例が可能である。
【図１】
2020537385.tif 000003
【図２】
2020537385.tif 000004
【図３】
2020537385.tif 000005
【図４】
2020537385.tif 000006
【図５】
2020537385.tif 000007
【図６】
2020537385.tif 000008
【図７】
2020537385.tif 000009
【図８】
2020537385.tif 000010
【国際調査報告】
2020537385.tif 000011
2020537385.tif 000012