JP2009534002A - 複数のモバイル・プラットフォームのためにカスタマイズされたコンテンツを送達するシステムおよび方法 - Google Patents

Abstract

モバイル・アプリケーション開発プラットフォームが、モバイル・アプリケーションのための開発プロセスを合理化するよう構成されたツールセットを有する。合理化開発プロセスは、ビデオ・ストリーミングおよびアップロードならびに画像送達およびアップロードといったアプリケーションの開発のために効率を可能にできる。開発プラットフォームは多言語サポートを提供する。開発プラットフォームはまた、プロジェクト管理統合をも提供する。開発プラットフォームはまた、コンテンツを複数のモバイル・デバイス・プラットフォームにわたって配送するための展開技術をも提供する。

Description

〈関連出願情報〉
本願は2006年4月17日に出願された“Systems and Methods for Delivering Content Customized for a Plurality of Mobile Platforms”という名称の米国特許出願第11/379,033号の優先権を主張するものである。

１．発明の分野
本発明は概括的にはモバイル・プラットフォームのためのアプリケーションの開発（development）に、より詳細には複数のモバイル・プラットフォームと互換なアプリケーションを開発するためのシステムおよび方法に関する。

２．本発明の背景
携帯電話技術および携帯電話に組み込まれる技術の近年の進展により、携帯電話はもはや単に音声通信のために使われるものではない。今日の携帯電話は、テキスト・メッセージ交換、ビデオおよび画像の伝送および従来の携帯情報端末（PDA）がしてきたのと同様なユーザーの連絡先やカレンダーの維持のために使われる。携帯電話技術はこれらの新たな用途をサポートするよう進化してきた。たとえば、今日の携帯電話は、伝統的にはPDAがサポートしてきたような機能性といった増加した機能性をサポートするために、より強力なプロセッサおよびより高いメモリ密度を含んでいる。LCD技術の進展は、より大きな画面、カラー画面および携帯電話にダウンロードまたはストリーミングされた写真およびビデオの表示機能につながった。さらに、今日の携帯電話の多くはデジタル・カメラ、さらにはデジタル・ビデオ・カメラが装備されてくるので、ユーザーは、写真またはビデオを撮影し、携帯電話ディスプレイで写真およびビデオを表示させることができる。

これらの技術的進展は北米および全世界での携帯電話の売り上げ増につながった。2005年末までにはモバイル・サービス加入者は世界中で２０億人になると推定されており、2005年には７億３５００万台の携帯電話が販売されると推定されている。さらに、2004年についての米国のワイヤレス歳入は１４５０億に達した。これらの数字は今後も成長し続けるはずである。

携帯電話の進化する使用を立証すると、携帯電話ユーザーの４７％は2008年までに携帯電話を使ってビデオを受信できるようになるであろう。現在、アメリカ人は携帯電話を使って一か月当たり２５億通のテキスト・メッセージを送っている。そしておそらくは携帯電話の進化する使用に関して最も説得力があるものとして、過去２年間で携帯電話を使って掲示されたウェブログ（または「ブログ」）は１５０万に上った。これらの「ブログ」は典型的には、ユーザーによって携帯電話を使ってウェブ・ページにアップロードされたテキスト、写真および／またはビデオを含む。

だが、これらの進展は問題も作り出してきた。たとえば、携帯電話上で展開されるべきアプリケーションを開発するためには幅広い多様なプラットフォームがある。事業者も複数あって、そのそれぞれが携帯電話を使って情報およびデータが転送される仕方について独自のプロトコルおよび仕様をもつ可能性がある。さらに、今日使われる携帯電話の間には、幅広いハードウェアの変異がある。これらの変異には、異なる画面サイズ、異なるメモリ機能、変動するプロセッサ速度などが含まれる。実際、北米だけで、１４５の異なる携帯電話タイプがある。

上記の変数すべてのため、複数の携帯電話タイプにまたがるアプリケーションを設計し、展開することが難しくなっている。結果として、アプリケーションがプラットフォームごとに開発されるので新しいアプリケーションのための市場がセグメント化される。

かほどに多くの異なる携帯電話プラットフォームがあってこれらのプラットフォームにまたがる標準がほとんどないことに内在する問題は、たとえば、携帯電話ユーザーにとってますます人気が出てきている二つのアプリケーションによって立証できる。これら二つのアプリケーションとは、携帯電話からのデジタル写真のアップロードと、「ビデオ・ブログ」として知られるようになった、携帯電話からウェブ・ページにビデオがアップロードされ、後刻アクセスできるというものである。携帯電話から主要なウェブ・サービスによってホストされているウェブ・ページに写真をアップロードするためには、ユーザーはまず「カメラ付き電話」のシステム要件を検証する必要がある。しかしながら、まず、ユーザーは自分の電話をウェブ・サーバーに登録していなければならない。カメラ付き電話のシステム要件を検証したのち、その電話についての登録情報が確認される。次いでユーザーはカメラ付き電話で写真を撮ることができる。ユーザーは次いでウェブ・サーバーによってホストされる電子メールアカウントに、写真を添付して電子メールを送ることができる。次いで電子メールはウェブ・サーバーによって受信され、添付の写真は自動的に、その登録された携帯電話に関連付けられたモバイル・アップロード・アルバム・アカウントにアップロードされる。

ウェブ・サーバーにそのような電子メールを送るために、写真を撮り、写真を保存し、電子メールを作成し、写真を電子メールに添付するプロセスは、実際にはきわめて時間がかかることがある。結果として、複数の写真を掲示することは重荷になる。すべての携帯電話タイプによって写真をアップロードするための単一のアプリケーションが使えれば、この重荷の多くは軽減できる。だが、携帯電話および携帯電話が動作するシステムの相違が単一のアプリケーションの使用を妨げている。

同じウェブ・サービスを使った「ビデオ・ブログ」は、カメラ付き電話のシステム要件を検証し、携帯電話の登録を検証するという非常によく似たプロセスを必要とする。次に、ユーザーは携帯電話の使用インターフェース、たとえばキーパッドなどを使って「ブログ項目」を作成できる。「ブログ項目（blog entry）」は写真、テキストまたはその両方を含むことができる。ブログ項目は次いで、携帯電話を使ってユーザーが作成する電子メールに添付されることができる。次いで、その電子メールがウェブ・サーバーに送られることができる。ここでもまた、「ブログ項目」の作成、電子メールの作成およびウェブ・サービスに送るためのブログ項目の電子メールへの添付は、無理なほど時間がかかることがある。

「電話ブログ（phone blogging）」のためのある競合するウェブ・サービスは、やや異なるプロセスをもつ。ここではユーザーはたとえば、カメラ付き電話で写真を撮り、次いでその写真を含むメッセージをあらかじめ決定された番号に送ることができる。この番号は、写真を受け取り、ウェブサイト上に掲示して後刻見られるようにするウェブ・サービスに関連している。他のサービスは、ユーザーが写真を撮り、何らかのテキストを作成し、次いでそれをウェブ・ページまたは電子メール・アドレスに送って、そこからウェブサイトに掲示されて後刻見られるようにすることができるようにする。上記のウェブ・サービスと同様、これらのプロセスは無理なほど時間がかかると判明することがある。

それでも、そのようなサービスは非常に人気があると判明しつつある。そのようなサービスを使うことにまつわる無理なほどの時間遅延が解消できれば、そのようなサービスの人気は、したがって使用も、ますます伸びる可能性がある。そのような時間遅延の解消は、多分に、すべての携帯電話タイプによって、そしてすべてのシステムにおいて使用できる一様なアプリケーションを開発することに依存する。

コンテンツ管理システムが、複数のモバイル・デバイスへの配送のためのコンテンツを受信するよう構成される。コンテンツ管理システムは、前記コンテンツを、さまざまなデバイス・プラットフォームのためにカスタマイズされた複数のバージョンに変換するよう構成されることができる。次いで各モバイル・デバイスに正しいバージョンがダウンロードできる。変換プロセスは、各デバイスのために前記コンテンツを最適化し、それにより前記コンテンツが最も効率的な仕方で閲覧され、あるいはアクセスされることができるようにする。

ある側面では、前記コンテンツ管理システムは、前記コンテンツをリアルタイムで変換するよう構成されることができる。

別の側面では、前記コンテンツ管理システムは、モバイル・デバイスのタイプをあらかじめ知ることなく、前記コンテンツの正しいバージョンがモバイル・デバイスによってアクセスされることを許容するよう構成されることができる。これは、モバイル・デバイスのタイプについての情報を判別するためにモバイル・デバイスに問い合わせすることによって達成される。

本発明のこれらおよびその他の特徴、側面および実施形態が下記の「発明を実施するための最良の実施形態」と題するセクションで記述される。

本発明の特徴、側面および実施形態が付属の図面と一緒に記述される。

図１は、本稿に記載されるシステムおよび方法のある実施形態に基づく、アプリケーションを開発し、複数のモバイル・デバイス・プラットフォームのうちの任意のものに向けて「プッシュ・アウト」することを許容するよう構成されることのできる開発プラットフォーム１００の図である。以下の記述および請求項において使用される「モバイル・デバイス」の用語は、任意のタイプのモバイル通信デバイスを指すことが意図されており、伝統的なセルラー電話、PCS電話、スマートフォン、セルラーもしくはPCS通信機能を含むPDAデバイスまたは音声通信のために使用できる他の任意のポータブル・デバイスを含む。よって、以下の実施形態の記述では「モバイル・デバイス」の用語が使われるが、この用語の使用は、それらの実施形態をいかなる特定のタイプのデバイスや通信プラットフォームに限定するものと見るべきでもない。

見て取れるように、プラットフォーム１００は、デバイス不可知なアプリケーション（device agnostic application）の開発において使用できる複数のモジュールを有する。図１に示された実施形態では、これらのモジュールは三つのカテゴリーに編成される。これらのカテゴリーは、開発モジュール１０２、プロダクション・モジュール１１６およびサービス・モジュール１１８である。開発モジュール１０２は、既存の多くのモバイル・デバイス・タイプによって現在サポートされるさまざまな開発プラットフォームのいずれとも互換なアプリケーションの開発を可能にするために使用できる。プロダクション・モジュール１１６は、幅広い多様なモバイル・デバイス・プラットフォームにわたる、開発モジュール１０２を使って開発されたアプリケーションの送達を許容するために使用できる。サービス・モジュール１１８は、開発モジュール１０２を使って開発され、プロダクション・モジュール１１６を使って送達されたアプリケーションに関係するサービスのプロビジョニングおよび追跡を可能にするために使用できる。

開発モジュール１０２はコンパイラ・モジュール１０４を含む。コンパイラ・モジュール１０４は、複数の標準言語の一つで開発されたアプリケーションをコンパイルし、そのアプリケーションが複数のプラットフォームによってサポートされることができるようそのアプリケーションを他のアプリケーションに変換することを容易にするよう構成されることができる
開発モジュール１０２はコア・エンジン・モジュール１０６をも含む。コア・エンジン・モジュール１０６は、コンパイラ・モジュール１０４によってコンパイルされたコードを受け、元のアプリケーションが書かれていた言語とは異なる言語をサポートするプラットフォームに対して互換なコードを生成するよう構成されることができる。

開発モジュール１０２はオプション・モジュール１０８をも含む。オプション・モジュール１０８は、コア・エンジン１０６を使って開発されたアプリケーションを最適化するよう構成されることができる。たとえば、オプション・モジュール１０８は、アプリケーションを、マルチメディア・アプリケーション、「ブログ」アプリケーションおよびさまざまな圧縮技術のために最適化するよう構成されることができる。

開発モジュール１０２はまた、基礎モジュール１１０をも含む。基礎モジュール１１０は、アプリケーションをジャンル固有アプリケーションのためにカスタマイズするよう構成される。たとえば、アプリケーションがゲームであれば、基礎モジュール１１０はそのゲームをさまざまなプラットフォームのためにカスタマイズできる。

開発モジュール１０２はまた、資産管理モジュール１１２をも含むことができる。資産管理モジュール１１２は、個別的なアプリケーションに関連付けられた資産を管理するよう構成されることができる。たとえば、ゲーム・アプリケーションにおいて、資産管理モジュール１１２は、アプリケーションが、ゲームに関連する地図データ、プレーヤー・データおよび画像といった情報を管理できるようにするよう構成される。

開発モジュール１０２はまた、コンテンツ・ネットワーキング・コンポーネント１１４をも含むことができる。コンテンツ・ネットワーキング・コンポーネント１１４は、アプリケーションのコンポーネント間でのコンテンツ・ネットワーキングを可能にするまたは最適化するよう構成されることができる。

プラットフォーム１００およびプラットフォーム１００を構成するモジュールは、アプリケーションが、ある標準的な言語で書かれ、その後経済的な仕方で他の言語に変換され、できるだけ多くのモバイル・デバイス・プラットフォームに向けて「プッシュ・アウト」されることができるようにするよう構成される。

図２は、ある言語で開発されたアプリケーションを別の言語のアプリケーションに変換するプロセスを示す図である。このように、図２では、基礎または特定のアプリ・コード（app code）で書かれたアプリケーションがコンパイラ・モジュール１０４に提供されることができる。たとえば、基礎言語はJava（登録商標）であることができる。Java（登録商標）言語のアプリケーション１１０は次いでコンパイラ１０４に提供されることができる。コンパイラ１０４はJava（登録商標）言語のアプリケーション１１０のファイルをCまたはC++のような標準的な言語での有効なファイルに変換するよう構成されている。よって、コンパイラ１０４はJava（登録商標）言語のアプリケーション１１０を有効な.cppおよび.hファイルに変換できる。

コンパイラ１０４によって開発されたファイルは次いで、エンジン・モジュール１０６に提供されることができる。各エンジン・モジュール１０６は、コンパイラ・モジュール１０４によって提供されたファイルをその特定のエンジン・モジュールに関連付けられた標準的な言語に変換するよう構成されることができる。図２の例では、コンパイラ１０４はファイルを二つのエンジン・モジュール１０６ａおよび１０６ｂに提供する。エンジン１０６ａは、ファイルをBREWプラットフォーム固有アプリケーションに変換するよう構成されることができる。エンジン１０６ｂは、ファイルをJ2ME言語固有アプリケーションに変換するよう構成されることができる。

次いで、エンジン１０６ａおよび１０６ｂによって生成されるアプリケーションはたとえば、BREWおよびJ2MEモバイル・デバイス・プラットフォームに、たとえばプロダクション・モジュール１１６を使って送達されることができる。

図３は、プラットフォーム１００を使って複数のモバイル・デバイス・プラットフォームに「プッシュ・アウト」できるアプリケーションを開発するためのプロセスを示すフローチャートである。このように、ステップ３０２では、アプリケーションを開発するためにBREWまたはJ2ME開発ツールキットのような標準的な言語開発キットを使うことができる。ステップ３０４では、アプリケーションは、エンジン・モジュール１０６の一つによってサポートされるコードに変換されることができる。

このコードは次いで、ステップ３０６において、あるモバイル・デバイス上で試験されることができる。試験が成功であれば、コードはコンパイラ・モジュール１０２にステップ３０８において供給されることができる。コンパイラ・モジュール１０２は前記コードを、第二のエンジン・モジュール１０６によってサポートされるコードに変換する。このコードは次いでステップ３１０においてあるモバイル・デバイス上で試験されることができる。ステップ３１０において試験が成功であれば、第二のエンジン１０６のために開発されたコードは、ステップ３１２においてバグまたは不効率性について見直されることができる。

図４に示されるように、プラットフォーム１００は、送達システム４０２を介して、複数のモバイル・プラットフォーム４０６にわたる、無制限な量のコンテンツ４００の統合および送達を可能にする。送達システム４０２は、通信チャネル４０８を通じてモバイル・デバイス４０６と通信するよう構成された送達機関（deliver authority）４０４を有する。プラットフォーム１００を使って開発されたアプリケーションは、たとえばサーバー４０４を使ってモバイル・デバイス４０６に「プッシュ・アウト」されることができる。アプリケーションは、デバイス４０６がコンテンツ４００を受け取れるようにするよう構成されている。コンテンツ４００はまた。サーバー４０４を介して送達されることもできる。アプリケーションがプラットフォーム１００を構成する標準的なモジュールを使って開発されているので、コンテンツ４００は、経済的かつ効率的な仕方でプッシュ・アウトされることができる。さらに、コンテンツはセグメント化されない。たとえば、すべてのコンテンツがすべてのモバイル・デバイス４０６によって受信され、使用されることができる。換言すれば、ある種のコンテンツはある種のデバイス４０６のために設計されていて他のデバイス４０６のためには設計されていないというようにコンテンツがセグメント化されることはない。

図３のプロセスは、コンテンツがすべてのモバイル・デバイス４０６上に存在するアプリケーションによって受信され、使用されることができることを保証する。したがって、プラットフォーム１００は、任意の種類のコンテンツを受けてそれを任意のタイプのモバイル・デバイスにプッシュ・アウトするために使うことのできるモバイル・コンテンツ展開（deployment）プラットフォーム中に組み込むことができる。

図５は、開発プラットフォーム１００を含むモバイル・コンテンツ展開プラットフォーム５０４を有するコンテンツ送達システム５００を示す図である。このように、モバイル・コンテンツ展開プラットフォーム５０４は、コンテンツ５０２を受け、それをモバイル・デバイス５０８にプッシュ・アウトすることを、コンテンツ５０２のタイプやデバイス５０８のタイプに関わりなくできる。展開プラットフォーム５０４がこれを達成できるのは、開発プラットフォーム１００が複数の言語、プロトコルまたは標準５０８のうちの任意のものに準拠するアプリケーションを開発するために使うことができるからである。

換言すれば、開発プラットフォーム１００は、種々のプラットフォーム５０８の要求に準拠し、かつコンテンツ５０２を使用または活用するよう構成されるアプリケーションを開発するために使われることができる。これらのアプリケーションは次いで、デバイス５０８にプッシュ・アウトされることができる。その際、コンテンツ５０２は、展開プラットフォーム５０４を介してデバイス５０８に提供されることもできる。他の実施形態では、コンテンツ５０２は代替的なプラットフォームまたはサーバーまたはサービスを通じてデバイス５０８に提供されることができる。

たとえば、開発プラットフォーム１００を使って開発され、複数の異なるタイプのモバイル通信デバイス５０８にコンテンツ送達システム５００を介してプッシュ・アウトされることのできるアプリケーションの一つのタイプは、ビデオ・ブログ（video blogging）すなわち「ヴロガー（vlogger）」アプリケーションである。

図６ないし図２０は、開発プラットフォーム１００を使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。図６ないし図１７のスクリーンショットはあくまでも例であって、これらのスクリーンショットは本稿に記載されるシステムおよび方法をいかなる特定のタイプのスクリーン・サイズ、解像度、ディスプレイ・タイプなどに限定するものとも見るべきではない。

従来のブログ・アプリケーションの問題は、写真、ビデオまたはテキストといった任意の種類のブログ・コンテンツをアップロードすることがきわめて時間がかかることである。この遅延は多分に、モバイル・デバイス上に常駐する従来のブログ・アプリケーションがないという事実に起因する。よって、真の意味ではモバイル通信デバイスのための従来のブログ・アプリケーションはない。むしろ、そのようなサービスは、デバイス常駐の写真撮影、電子メールなどといった複数のアプリケーションを利用している。しかしながら、常駐ブログ・アプリケーションがないので、デバイスは、ブログ・コンテンツをウェブ・サーバーにアップロードするのに介する必要のある通信ネットワーク、すなわちインターネットと直接インターフェースをもつことができない。結果として、ユーザーは、ブログ・コンテンツをウェブ・サーバーにアップロードするために多くのステップを経なければならない。たとえば、上に説明したように、従来のアプリケーションはユーザーに、コンテンツを保存し、ウェブ・サーバーに宛てられた電子メールを作成し、コンテンツを電子メールに添付し、次いで電子メールを送信することを要求する。他の従来のアプリケーションは、テキスト・メッセージまたは通信ネットワーク上でかけられる電話コールを使うことができる。いずれにせよ、関わってくるステップは時間がかかるものであり、大量のコンテンツをアプロードするときには特にそうである。

従来のブログ・アプリケーションがないという一つの理由は、各デバイス、そして各異なるネットワークが、インターネットにアクセスするための異なるプロトコルおよび手順をもつということである。さらに、各モバイル・デバイスは、インターネット・アクセスおよびインターネット・アクセス時のパフォーマンスに関して異なる機能をもつことがある。結果として、設計者は、任意のモバイル・デバイス上で走ることができ、立ち上げられたときに当該デバイスとインターネットとをインターフェースさせることのできる単一のアプリケーションを設計することができない。しかしながら、開発プラットフォーム１００を使って開発されたアプリケーションは任意のデバイス・タイプ、開発プラットフォームおよびネットワーク・プロトコルと互換なので、開発プラットフォーム１００を使って開発されたアプリケーションは、そのアプリケーションの立ち上げ時に、そのアプリケーションが存在しているモバイル・デバイスにインターネットとインターフェースさせるために使うことができる。換言すれば、前記アプリケーションは、デバイス資源を活用し、そのアプリケーションが立ち上げられるときに当該デバイスに直接、インターネットとのインターフェースをもたせることができるのである。

結果として、ウェブ・サーバーにコンテンツをアップロードするプロセスは合理化され、必要な時間は大幅に短縮される。本質的には、ブログ・アプリケーションが立ち上げられるとき、当該デバイスにインターネットと、そしてブログ・サービスを提供するウェブ・サーバーと接続させることができる。するとユーザーは、たとえばモバイル・デバイス上で送信入力を作動させることによって、簡単にコンテンツを選択してそれを迅速かつ効率的に送ることができる。こうして、写真またはビデオを送るプロセスは、写真またはビデオを撮影し、ブログ・アプリケーションを立ち上げ、写真またはビデオ・ファイルを選択して送信を押すことになることができる。代替的に、最初にブログ・アプリケーションが立ち上げられ、写真またはビデオが撮影され、撮影された写真またはビデオが次いで単に送信ボタンを押すことによって送られることもできる。

コンテンツが送られるべきであることを指示する機構はデバイスによって変わりうることは理解されるであろう。たとえば、ある種の実施形態では、コンテンツが送られるべきであることを指示するためにボタンまたはキーパッド入力が使用されることができる。他の実施形態では、たとえば指またはスタイラスを使って、ディスプレイ上のアクティブ入力が作動されることができる。他の実施形態では、コンテンツが送られるべきであることを指示するためにメニュー項目が選択されることができる。送信指示がどのように入力されるかに関わりなく、プロセス全体はより高速で、より効率的となることができる。これは、ブログ・アプリケーションがデバイス上に常駐しており、デバイスの資源すべてを利用できるからである。

同様に、開発プラットフォーム１００を使って開発されたブログ・アプリケーションは、ネットワーク資源のすべてをフルに活用することもできる。結果として、アプリケーションは個別的なネットワーク資源およびプロトコルのために開発されることができるので、コンテンツはより高速のデータレートでアップロードおよびダウンロードできる。

図６〜図２０のスクリーンショットは、開発プラットフォーム１００を使って開発されたアプリケーションによって提供される機能を示すために使うことができる。図６〜図２０のスクリーンショットはヴロガー・アプリケーションに関係しており、ビデオまたは写真コンテンツがどのように迅速かつ簡単にヴロガー・サービスを提供するウェブ・サーバーにアップロードできるかを示している。このように、ユーザーはヴロガー・アプリケーションを自分のモバイル・デバイス上で立ち上げることができ、ヴロガー・アプリケーションがそのデバイスに、ヴロガー・サービスをホストするサーバーとの接続６１２を生成させる。図６の例では、見て取れるように、最初にヴロガー・アプリケーションが立ち上げられると、アプリケーション画面６１０がデバイス６０８上に表示されることができる。画面は、ユーザーがデバイス６０８のユーザー・インターフェースを使ってアクセスできるオプションのメニューを有していてもよい。たとえば、ユーザーがメニュー上のビデオ・ブログを選択しようとする場合、図のようなサブメニューをもつディスプレイ６０４が現れることができる。ユーザーがこのサブメニュー中の項目の一つを選択すると、画面６０６が表示されることができる。図６の例では、ユーザーは画面６０４中のギャラリー・オプションを選択しており、画面６０６ではデバイスがギャラリー情報にアクセスする間、広告が表示されている。

ヴロガー・アプリケーションはブログ・コンテンツ、すなわち写真およびビデオを、ヴロガー・サービスを提供するウェブ・サーバーによってホストされるウェブ・ページにアップロードするために使用できる。スクリーンショット６０２は、ユーザーが、たとえばコンピュータからユーザーのヴロガー・アカウントにアクセスするときに表示されることのできるウェブ・ページを示すスクリーンショットである。

開発プラットフォーム１００を使うことによって、カスタムなダウンロード可能なアプリケーションがたとえばモバイル・デバイス６０８に提供されることができる。よって、図６〜図１７のスクリーンショットを使って示されるヴロガー・アプリケーションのような開発プラットフォーム１００を使って開発されたアプリケーションがモバイル・デバイス上にローカルに存在する。開発プラットフォーム１００を使って開発されたカスタムなダウンロードされたアプリケーションは、標章付けされた経験をユーザーに提供する機会をも提供する。標章付けされた（branded）経験とは、個々のユーザーに特有な、ウェブ・サービスに特有な、あるいは特定の広告主に特有な、デバイス６０８上に表示されるコンテンツを含むことができる。実際、高度にターゲットを絞られたカスタム広告が複数のモバイル・デバイスにまたがってプッシュ・アウトされることを許容できるモバイル広告管理バックエンド・システムが、前記ウェブ・サービスに統合できる。

以下ではモバイル広告管理システムについてより詳細に述べるが、ここで記載されるシステムおよび方法によって可能にされる特有な標章付けの一部は図６〜図１７のスクリーンショットに図示されている。このように、図６〜図１７のスクリーンショットに関係する以下の記述では、ここで記載されるシステムおよび方法によって提供されるモバイル広告機能の一部が記述される。

図７は、開発プラットフォーム１００を使って設計されたヴロガー・アプリケーションが最初に立ち上げられるときに表示されることのできる表示のスクリーンショットである。スクリーンショット７０２で見て取れるように、表示は広告７０４を含むことができる。この事例では、広告７０４はヴロガー・ウェブ・サービスをホストするウェブサイトについての広告である。

図８は、広告７０４に続いて表示されることのできる表示のスクリーンショット８１０である。スクリーンショット８１０で見て取れるように、この表示は広告８０４を含むことができる。ここで、広告８０４はサードパーティーの製品またはサービスについてのものである。表示はまた、ヴロガー・アプリケーションの状態を示すよう構成されたステータス・バー８０２をも含むことができる。この場合、ステータス・バー８０２はヴロガー・アプリケーションがまだロード中であることを示している。この表示はまた、第二の広告を蓄えるよう構成された広告バー８０６をも含む。この場合、広告バー８０６はヴロガー・アプリケーションを提供するウェブサイトについての広告を含んでいる。

図９は、ひとたびヴロガー・アプリケーションがロードされたときに表示されることのできる表示のスクリーンショット９１０である。この表示はメニュー９０２を含むことができる。見て取れるように、メニュー９０２は写真６１０またはユーザーを同定する他のコンテンツをもって標章付けできる。この場合、コンテンツ６１０はユーザーの写真である。

図１０は、メニュー９０２内の項目の一つが選択されるときに表示されることのできる表示のスクリーンショット１０１０である。この表示はサブメニュー１００２を含む。この場合、ユーザーはメニュー９０２において、マイ・プロフォールを選択している。するとマイ・アカウント・サブメニュー１００２に連れて行かれる。

図１１は、サブメニュー１００２内の項目の一つが選択されたあとに表示されることのできる表示を示すスクリーンショットである。ここでもまた、メニュー１００２においてなされた選択に関連したコンテンツまたはアプリケーションがロードしている間、広告１１０２が表示されることができる。この場合、広告１１０２はサードパーティーの製品またはサービスについてのものである。ステータス・バー１１０４は、選択された項目およびメニュー１００２に関連付けられたアプリケーションまたはコンテンツのロードに関係した進行を示す。

見て取れるように、広告１１０２は広告１１０２に関連付けられたコンテンツへのダイナミック・リンクを含むことができる。ここで、「ここをクリック（click here）」のリンクが広告１１０２の下部に示されている。さらに、案内１１０６がユーザーに対して、広告１１０２に関係したさらなる情報を得るためにはデバイス・キーパッド上の「５」を押すことができることを知らせている。

図１２は、ヴロガー・アプリケーションに関連付けられたメニュー１２０２を含んでいる表示１２１０のスクリーンショットである。このように、ユーザーは、新しいコンテンツを取得してそれをヴログ・サービスに関連付けられたウェブサイトにアップロードするために、メニュー１２０２を使うことができる。

図１３は、ヴロガー・アプリケーションが立ち上げられる画像が取得されているときに表示されることのできる表示のスクリーンショット１３１０を示している。このように、メニュー１２０２において新たなビデオまたは写真選択が選択されるときに画像１３０２が表示されることができる。写真１３０２はデバイス６０８に含まれるビデオ・カメラまたはカメラを介して提供されている。この表示は、ユーザーにどんなステップを行うべきかを案内する案内バー１３０４を含むことができる。ここで、案内バー１３０４はユーザーに、写真１３０２を撮影するためにはキーパッド上の５を押すよう案内している。

図１４は、たとえばキーパッド上の５を押すことによってひとたび画像１３０２が撮影されたときに表示されることのできる表示を示すスクリーンショット１４１０である。ひとたび画像１３０２が撮影されると、それはディスプレイの上の部分に表示されることができる。さらに、メニュー１４０２が表示されて、ユーザーに写真１３０２を編集し、写真１３０２を保存し、あるいは別の写真に戻ることを許容することができる。さらに、ユーザーはテキスト入力ボックス１４０４において写真１３０２に名前を付けることができる。

ひとたび写真１３０２に名前が付けられると、ユーザーは、メニュー１４０２における保存の項目を選択することによってその写真を保存することを選択できる。これはヴロガー・アプリケーションに写真１３０２のウェブ・サーバーへのアップロードをさせることになる。

図１５は、ひとたび保存オプションが選択されたときに表示されることのできる表示を示すスクリーンショット１５１０である。ここでもまた、写真がアップロードされている間、広告１５０２が表示されることができる。ステータス・バー１５０４はアップロード手順の状態を提供できる。

図１６は、ユーザーが画像１３０２をアップロードしたあとに表示されることのできる表示を示すスクリーンショット１６１０である。表示１６１０はユーザーがフィールド１６０２で写真に名前を付け、フィールド１６０４でコンテンツを説明し、フィールド１６０６でウェブ・ページ上に保存されることになる写真についてのサマリーを追加することを許容する。

図１７は、写真１３０２が保存されたあとに表示されることのできる表示を示すスクリーンショット１７１０である。この表示は、ウェブ・ページ上に保存された写真またはファイルのメニュー１７０２を含んでいる。メニュー１７０４はユーザーが、保存された写真またはファイルを追加し、編集し、削除し、それらの間を行き来することを許容する。

ひとたびユーザーがブログ・コンテンツをアップロードしたら、ユーザーは、デスクトップ・コンピュータまたはラップトップ・コンピュータといったコンピュータを使って、ブログ・コンテンツを閲覧するためにウェブ・ページにアクセスできる。

図２１は、ここで記載されるシステムおよび方法のある実施形態に基づいてブログ・サービスを提供するよう構成されることのできる例示的な通信システム２１００を示す図である。システム２１００は、常駐のブログ・アプリケーション２１２０を有する複数のモバイル通信デバイス２１０２を含むことができる。便宜上、単一のモバイル通信デバイス２１０２が示されている。

モバイル通信デバイス２１０２は常駐のブログ・アプリケーション２１２０を使って、ブログ・コンテンツをウェブ・サーバー２１０６にインターネット２１０４を通じてアップロードできる。ブログ・コンテンツは、ウェブ・サーバー２１０６によってホストされる複数のウェブ・ページ２１０８の一つに関連付けられることができる。ユーザーは次いで、通信ネットワークを介してウェブ・サーバー２１０６とインターフェースされたコンピュータ２１１２を使ってウェブ・ページ２１０８にアクセスできる。ウェブ・サーバー２１０６とコンピュータ２１１２とをインターフェースさせる通信ネットワークはインターネットをも含むことができることは理解されるであろう。通信ネットワークはまた、有線または無線の構内ネットワーク（LAN）、有線または無線のパーソナル・エリア・ネットワーク（PAN）、有線または無線の広域ネットワーク（WAN）、有線または無線の都市圏ネットワーク（MAN）などあるいはそれらの組み合わせを含むこともできる。

サービスによっては、モバイル・デバイス２１０２のユーザーだけが関連付けられたウェブ・ページ２１０８にアクセスできる。他の実施形態では、他のユーザーがその関連付けられたウェブ・ページにアクセスできる。このように、アクセスは公衆に開かれていることができるし、あるいはたとえばパスワードなどを使うことによって制約されていてもよい。

図１８は、ユーザーがコンピュータ２１１２を使ってウェブ・サーバーにアクセスするときにサーバー２１０６によって表示されることのできるウェブ・ページ１８００を示す図である。見て取れるように、ウェブ・ページ１８００はフィールド１８０２にサインを含むことができる。登録ユーザーは自分のユーザーIDたとえば電子メール・アドレスおよびパスワードを提供して、一つまたは複数のウェブ・ページ２１０８にアクセスすることができる。新規ユーザーはサインアップ・オプション１８０４を選択することによってアカウントを作成できる。

図１９は、ユーザーがサインアップ・オプション１８０４を選択したときに表示されることのできる表示１９００である。サインアップ・フィールド１９０４が表示されることができ、そこでユーザーは電子メール・アドレス１９０６、名前１９０８、パスワード１９１０ならびに自分のモバイル・デバイスの番号１９１２およびモデル１９１４を提供することができる。この情報は、開発プラットフォーム１００を使って開発された常駐のカスタム・アプリケーションをユーザーのモバイル・デバイスにダウンロードするために使われる。

図２１に示され、前述したように、システム２１００は、ウェブ・サーバー２１０６とインターフェースをもつモバイル広告管理バックエンド・システム２１１０を含むことができる。バックエンド広告管理システム２１１０は、広告主が、モバイル・デバイス２１０２にプッシュ・アウトされることのできる広告キャンペーンを作成することを可能にすることができる。しかしながら、開発プラットフォーム１００を使って常駐のカスタム・アプリケーションがデバイス２１０２にプッシュ・アウトしていないので、バックエンド・モバイル広告管理システム２１１０を使って作成された広告キャンペーンは、多様な基準に基づいてカスタム広告を提供できる。カスタム広告機能は、各デバイス２１０２のために最適化された広告がユーザーに送達されることを保証でき、これは広告キャンペーンの価値を高め、カスタマイズされた標章付けを提供する。

図２０に示されるように、ユーザーは、広告選択２００２を使って広告データベースにアクセスできる。ある種の実施形態では、権限のあるユーザーのみが広告データベースにアクセスできる。他の実施形態では、広告主としてサインアップしたい人は誰でも広告データベースにアクセスできる。一般に、広告選択２００２を介したコンテンツ・アクセスは、前記ユーザーに関連付けられた広告に制約される。

図２２は、ユーザーが広告選択２００２を選択するときにユーザーのコンピュータ上に表示されることのできる表示を示すスクリーンショット２２００である。見て取れるように、この表示は広告主ログイン・フィールド２２０２を含むことができる。広告主は、このフィールドで、電子メール・アドレスのようなIDまたはユーザー名２２０４ならびにパスワード２２０６を入力できる。

図２３は、ひとたび広告主がログインに成功したときに表示されることのできる表示を示すスクリーンショット２３００である。見て取れるように、この表示は、広告主にいくつかのオプションを提供するメニュー２３０２を含むことができる。これらのオプションは、新しい広告キャンペーンを作成したり既存のキャンペーンを見直したりする機能、パスワードもしくはユーザーIDを変更する機能およびそのウェブ・サービスについての広告主のアカウントを見直す機能を含むことができる。

図２４は、広告主がメニュー２３０２において前記キャンペーン・オプションを選択するときに表示されることのできる表示を示すスクリーンショット２４００である。見て取れるように、その表示は現在のキャンペーンのリスト２４０２を含む。広告主は、そのリストをスクロールさせて、見直すキャンペーンを選択できる。

図２５は、ひとたびユーザーが特定のキャンペーンを選択したときに表示されることのできる表示を示すスクリーンショット２５００である。この表示は広告情報フィールド２５０２を含む。

図２６は、より詳細にこの情報フィールド２５０２を示している。見て取れるように、情報フィールド２５０２は、カンパニー名２６０４、その広告キャンペーンのための予算２６０６、所望される印象（impression）たとえば閲覧の回数２６０８およびその広告キャンペーンに関連付けられるべき画像２６１０といった情報を含むメイン情報フィールド２６０２を含むことができる。広告主がそのキャンペーンについての特定の画像またはビデオ・ファイルを選択するときには、サブ・ウィンドウ２５０４がポップアップして、広告主にその画像またはビデオ・ファイルを選択することを許容することができる。

情報フィールド２５０２はまた、その広告キャンペーンについてのターゲット・オーディエンスに関する情報を含むフィールド２６１４をも含むことができる。見て取れるように、フィールド２６１４は、ターゲットを絞られたキャンペーンのためにある種のアドレスを選択することを広告主に許容するツールをも含むことができる。

図２７は、フィールド２６１４においてユーザーがａへのアドレス２６１２を選択するときにポップアップできるアドレス・フィールド２７０２を示すスクリーンショットである。アドレス・フィールド２７０２は地図セクション２７０４およびアドレス・フィールド２７０６を含むことができ、アドレス・フィールド２７０６において広告主はフィールド２７０８においてアドレス情報を入力できる。代替的に、広告主は、座標２７１０を単に地図２７０４上で選択することができる。広告主によって入力されたアドレス情報は、地図上で、広告主がターゲットを絞った広告キャンペーンのために指定したいエリアの中心点２７１２を指定するために使われることができる。換言すれば、ユーザーは中心点２７１２を選択することができ、次いでターゲットを絞られた広告キャンペーンのために中心点２７１２のまわりの範囲を指定できる。この範囲は、たとえば、中心点からのマイル数として指定できる。

他の実施形態では、広告主は単に地図上で郵便番号を指定できる。すると、広告キャンペーンはそのエリア・コードについてカスタマイズされることができる。他の地理的指定を使うこともできる。たとえば、実施形態によっては、エリア・コード、市境などが単独で、または他の指定と組み合わせて使われることができる。

図２８に示されるように、フィールド２６１４はフィールド２８０２および２８０４をも含むことができ、それぞれ広告キャンペーンがアクティブになる日付および時間を選択することを広告主に許容することができる。フィールド２８０４は、広告主がフィールド２９０２中のカレンダー上で日付を選択することを許容するよう図２９に示されるように展開されることができる。

このように、バックエンド・モバイル広告管理システム２１１０を介して提供されるツールを使って、広告主はターゲットを絞った広告キャンペーンを生成できる。その際、広告キャンペーン自体、たとえば広告コンテンツは、開発プラットフォーム１００を使って送達のために構築できる。図５に示されるように、コンテンツ５０２は、開発プラットフォーム１００を使って、複数の開発プラットフォーム、プロトコルなどのうちの任意のものに変換できる。結果として、各ユーザーに送達されるコンテンツは、ユーザーのモバイル・デバイス２１０２上に存在する常駐のカスタム・アプリケーションを使った閲覧のためにカスタマイズされることができる。コンテンツは、別個のアプリケーション、たとえばヴロガー・アプリケーションの一部として、ユーザーにプッシュ・アウトされることができる。代替的に、コンテンツは単に、ユーザーのデバイス２１０２上に存在する常駐のカスタム・ビデオ・ストリーミングまたはコンテンツ・ダウンロード・アプリケーションを使ってダウンロードされることもできる。ビデオ・ストリーミングおよびコンテンツ・ダウンロード・アプリケーションについて以下でより詳細に述べる。

図３０は、広告主が編集選択３００２を使ってカスタム広告キャンペーンのためのカスタム・コンテンツをどのようにして作成することができるかを示すスクリーンショットである。

図３１Ａは、広告主が編集選択３００２を選択したときに表示されることのできる表示を示す３１００のスクリーンショットである。この表示は、広告主がキャンペーンの名前３１０４、予算３１０６、所望される印象数３１０８およびキャンペーンに関連した画像３１１０を編集できるキャンペーン編集フィールド３１０２を含む。

広告主はツールバー３１１２を使って新しい画像３１１０を選択できる。しかしながら、ひとたび画像３１１０が選択されると、該画像はさまざまなデバイス・タイプおよびそれに含まれるディスプレイ・タイプに関連付けられたフォーマットに自動的にフォーマットし直される。結果として、画像３１１０は、図３１Ａ〜３１Ｃに示されるように異なるサイズおよび解像度の複数の画像に複製されることができる。この画像複製が可能なのは、設計プラットフォーム１００が各デバイスおよびディスプレイ・タイプに関連付けられた情報を含んでいるからである。実施形態によっては、ユーザーはより粒子状の（granular）スケールで実際に画像を変更することが許容されることができる。換言すれば、広告主は、より小さなディスプレイのためにはある種の画像３１１０を選択し、より大きなディスプレイのためには異なる画像を使うことができるのである。こうして、ツールバー３１１２のようなツールバーが図３１Ａ〜図３１Ｃの各画像に関連付けられることができる。

開発プラットフォーム１００はまた、モバイル・デバイス２１０２のために位置情報に基づく広告キャンペーンをカスタマイズするよう構成されることもできる。換言すれば、汎用広告キャンペーンが生成でき、次いで提供されるアドレス情報に依存して、特定エリア内のユーザーがその広告キャンペーンのカスタマイズされたバージョンを与えられることができる。

図３２は、ある種の地理的エリア内のユーザーのために汎用広告キャンペーンをカスタマイズすることを示している。明らかに、別の地理的エリアのユーザーはやや異なる広告３２００を見ることになる。

上述したように、開発プラットフォーム１００はまた、常駐のカスタム・ビデオ・ストリーミングおよび／またはコンテンツ・ダウンロード・アプリケーションを開発し、展開するためにも使用できる。従来のストリーミングおよびダウンロード・アプリケーションは、開発者が複数のデバイスにプッシュ・アウトされる汎用アプリケーションを開発しなければならないため、あるいは開発者が単一のデバイスのためのカスタム・アプリケーションを開発することを強いられるために、限定されていた。結果として、あらゆるデバイス・タイプのためにカスタマイズされるアプリケーションを開発することは難しい。しかしながら、プラットフォーム１００は、たとえば図２および図３の開発プロセスを使って、各デバイス・タイプのためにカスタマイズされるアプリケーションを効果的かつ効率的に開発できるので、ビデオ・ストリーミングおよび／またはコンテンツ・ダウンロード・アプリケーションが各デバイス・プラットフォームのためにカスタマイズされ、検証されることができる。結果として、常駐のカスタム・ビデオ・ストリーミングおよび／またはコンテンツ・ダウンロード・アプリケーションを開発するための開発プラットフォーム１００を使って、より高いデータレート、より大きな解像度およびより優れた画質が達成できる。

こうして、上記のシステムおよび方法を使って、カスタムなダウンロード可能なアプリケーションが作成され、複数の異なるデバイス・タイプに迅速かつ効率的に展開されることができる。例示的なアプリケーションは、ビデオ・アップロードおよびストリーミング・アプリケーションと、画像アップロードおよびダウンロード・アプリケーションとを含む。さらに、上記のシステムおよび方法を使ってカスタマイズされたアプリケーションを展開する機能は、カスタム広告管理を許容できる。

たとえば、図３３は、本稿で記載されたシステムおよび方法のある実施形態に基づいて構成されたコンテンツ管理システム３３００を示す図である。コンテンツ管理システム３３００は、クライアント・サーバー３３１４および３３１６からコンテンツを受信し、複数の異なるモバイル・プラットフォームのためにコンテンツを適応させ、次いで適応されたコンテンツを複数のモバイル・デバイス３３１８に送達するよう構成されることができる。モバイル・デバイス３３１８は、適応されたコンテンツを閲覧するまたは扱うために、たとえば開発プラットフォーム１００を使って開発されたアプリケーションを含むことができる。したがって、アプリケーションおよびコンテンツが各モバイル・プラットフォームのために適応されているか最適化されているため、モバイル・デバイス３３１８はコンテンツをより高い効率をもって受信し、扱うことができる。これにより品質およびパフォーマンスが改善できる。

したがって、モバイル・デバイス３３１８（示されているそのようなデバイスが二つなのは単に便宜上でしかない）は、開発プラットフォーム１００を使って開発されたカスタム・アプリケーションを含むことができる。プラットフォーム１００はシステム３３００内に含められることができ、あるいは実施形態によっては別個のシステムの一部をなすこともできる。さらに、システム３３００は、上記したプラットフォーム５０４のようなコンテンツ展開プラットフォームをなすことができる。システム３３００はまた、たとえば図２０〜図３１の広告コンテンツとの関連で記載された、さまざまなモバイル・プラットフォームのためにコンテンツをカスタマイズする機能をも有することができる。

システム３３００は、ライブ・エンコード・サーバー（LES: Live Encoding Server）３３０２、オンデマンド・エンコード・サーバー（ODES: On-Demand Encoding Server）３３０４、配送サーバー（DS: Distribution Server）３３０６、デバイス・プロファイル・サーバー（DPS: Device Profile Server）３３０８、コンテンツ管理サーバー（CMS: Content Management Server）３３１０およびブロードキャスト・サーバー（BS: Broadcast Server）３３１２を含むことができる。システム３３００の上記のコンポーネントのそれぞれが本稿に記載された機能を実行するために必要なハードウェアおよびソフトウェアを含むことができることは理解されるであろう。よって、実施形態によっては、さまざまなコンポーネントの一部または全部が単一のハードウェア・サーバーまたはプラットフォーム上に存在することができる。一方、実施形態によっては、前記コンポーネントの一部または全部が複数の別個のハードウェア・サーバーまたはプラットフォーム上に存在することができる。さらに、システム３３００は、ウェブ・サーバー、ファイル・サーバー、データベース・サーバーなどといった、図３３に示されていない他のコンポーネントを含むことができる。

LES３３０２およびODES３３０４はいずれも、クライアント・サーバー３３１４および３３１６から、変換してモバイル・デバイス３３１８に配送するためのコンテンツを受信するよう構成される。しかしながら、LES３３０２は、後述するようなデバイス３３１８へのストリーミングのためのライブまたはリアルタイムのコンテンツを受信するよう構成されていてもよい。DS３３０６はBS３３１２を介したモバイル・デバイス３３１８へのコンテンツの配送を制御するよう構成されることができる。DPS３３０８は、コンテンツのカスタマイズにおいて使うためのモバイル・デバイス・プラットフォーム・プロファイルを維持するよう構成されることができる。CMS３３１０は、たとえばクライアントごとに、コンテンツの配送プロファイルを維持するよう構成されることができる。

図３４は、ある実施形態に基づくコンテンツ管理システム３３００を使ってコンテンツを配送するための例示的な方法を示すフローチャートである。まず、ステップ３４０２において、クライアント、たとえば広告主またはゲーム開発者がシステム３３００にログオンし、ステップ３４０４でコンテンツをクライアント・サーバー３３１４を介してCMS３３１０に提供することができる。クライアント・サーバー３３１４が、ここに記載されるようにシステム３３００とのインターフェースをもち、システム３３００と通信し、コンテンツをアップロードするためにクライアントが使用するシステムおよび資源を代表していることは理解されるであろう。

クライアントはまた、事前に、あるいはシステム３３００にログオンしている間に、ステップ３４０４でアップロードされるコンテンツの配信についての基準を指定することもできる。たとえば、上記のように、クライアントは、コンテンツが誰に送達されるべきか、いつ送達されるべきか、どの地理的領域がカバーされるべきかといった、広告キャンペーンを定義するパラメータを指定できる。

ステップ３４０６では、CMS３３１０はODES３３０４に、変換、すなわち利用可能なモバイル・デバイス・プラットフォームのためのフォーマットのために、コンテンツを提供できる。こうして、ステップ３４０８で、ODES３３０４はコンテンツを受け容れ、変換のために変換待ち行列３３２０に入れることができる。例示的な変換プロセスは、図３５に関連して以下に記載される。

ある種の実施形態では、CMS３３１０は、ステップ３４１０において、クライアントによって指定されたパラメータに従って、モバイル・デバイス３３１８に、コンテンツがコンテンツ管理システム３３００に追加されたことを通知することができる。換言すれば、CMS３３１０は、クライアントによって指定されたユーザーに、新しいコンテンツが追加されたことを通知できる。その際、CMS３３１０は、ユーザーが自分の関連付けられたデバイス３３１８を使ってシステム３３００からコンテンツを引き出すことができるよう、そのコンテンツへのリンク、たとえばURLを提供できる。CMS３３１０はモバイル・デバイス３３１８と、BS３３１２を介して通信できる。

他の実施形態では、クライアントはコンテンツがある種のモバイル・デバイス３３１８にプッシュ・アウトされるべきであると指定することができる。こうして、ステップ３４１２において、コンテンツは、ODES３３０４によって変換されたあと、モバイル・デバイス３３１８にBS３３１２を介してプッシュされることができる。

図３５は、クライアント・サーバー３３１６からアップロードされたコンテンツを変換するための例示的なプロセスを示すフローチャートである。上記のように、コンテンツは変換待ち行列３３２０にロードされる（ステップ３４０８）。ODES３３０４は次いで、DPS３３０８に、あらゆる利用可能なデバイス・プロファイルについて問い合わせをするよう構成されることができる。これらのプロファイルは次いで、コンテンツをステップ３５０４で各デバイス・プラットフォームのためにカスタマイズされた複数のバージョンに変換するために使われることができる。追加コンテンツのためのそのようなプロセスは、図３１Ａ〜図３１Ｃとの関連で上記した。

換言すれば、DPS３３０８は、さまざまなデバイス・プラットフォームについての機能、ディスプレイ・タイプ、ディスプレイ・サイズなどに関する情報を保存できる。この情報は、ODES３３０４によって、コンテンツを各プラットフォームについてカスタマイズされたバージョンに変換するために使用されることができる。そのような変換は、コンテンツのサイズ、コンテンツの解像度をスケーリングすること、ある種のタイプのコンテンツを除去すること、あるいはある種のタイプのコンテンツをある種のデバイスが扱えるタイプに変換することを含むことができる。さらに、コンテンツが実行可能部分を含む場合、たとえばコンテンツがゲームである場合、ODES３３０４は、たとえば開発モジュール１０２を使って、コンテンツをデバイス不可知な実行可能形式に変換できる。

ODES３３０４は、次いでステップ３５０６でBS３３１２に変換されたコンテンツをアップロードするよう構成されることができる。ステップ３５０８では、ODES３３０４はDS３３０６に新しいコンテンツが用意できていることを通知できる。DS３３０６はステップ３５１０でCMS３３１０に問い合わせして、クライアントがそのコンテンツがデバイス３３１８にプッシュ・アウトされることを指示したかどうかを判定できる。そうであれば、ステップ３５１２で、DS３３０６はBS３３１２にそのデータをプッシュ・アウトするよう命令できる。

ある種の実施形態では、コンテンツの正しいバージョンにアクセスするために、ユーザーは、どのデバイス・プラットフォーム、たとえばモバイル・デバイス３３１８を使っているかを指定しなければならない。よって、コンテンツが単純にプッシュ・アウトされる場合、汎用バージョンが使われることができる。システム３３００はすべてのユーザーについてのデバイス・タイプを知らないことがありうるからである。あるいはまた、システム３３００は、正しいバージョンをプッシュ・アウトする前に、ユーザーに、プラットフォーム情報をもって応答することを要求するよう構成されることができる。

なお、DS３３０６および／またはBS３３１２はプロダクション・モジュール１１６およびサービス・モジュール１１８を使ってコンテンツをデバイス３３１８に送達するよう構成されることができる。

他の実施形態では、コンテンツ管理システム３３００はコンテンツをリアルタイムで変換するよう構成されることができる。

図３６は、ある実施形態に基づいてシステム３３００を使ってリアルタイムでコンテンツを変換するための例示的な方法を示すフローチャートである。まずステップ３６０２で、クライアント・サーバー３３１４はライブのまたは事前記録されたコンテンツをシステム３３００に提供するよう構成されることができる。コンテンツは、たとえば、オーディオ、ビデオ、画像またはそれらの何らかの組み合わせを含むことができる。ライブまたは事前記録されたコンテンツは、実際には、ケーブル、衛星、テレビ、DVD、CD、ビデオ・カセット、パーソナル・コンピュータ、ラジオ、MP3プレーヤー、カムコーダー、ゲーム・コンソールなどといった多様なソースのうちの任意のものを介して提供されることができ、したがってサーバー３３１４に関わっても関わらなくてもよい。

コンテンツはLES３３０２に提供される。LES３３０２は、ステップ３６０４で、あらゆるデバイス・プロファイルをDPS３３０８に問い合わせるよう構成されることができる。LES３３０２は、次いでステップ３６０６で、リアルタイムで各プロファイルのためにコンテンツをエンコードし、エンコードされたコンテンツをBS３３１２にアップロードするよう構成されることができる。LES３３０２またはODES３３０４は次いで、ステップ３６０８でDS３３０６に、新しいコンテンツの利用可能性を通知できる。ステップ３６１０では、DS３３０６はCMS３３１０に問い合わせをして、コンテンツがある種のユーザーにプッシュ・アウトされることをクライアントが指示したかどうかを判定できる。そうであれば、DS３３０６は、ステップ３６１２で、BS３３１２を介してコンテンツをプッシュ・アウトさせることができる。ここでもまた、システム３３００は各ユーザーについてのプラットフォーム・タイプは必ずしも知らないので、これはコンテンツの汎用バージョンをプッシュすることを含んでいてもよい。

他の実施形態では、コンテンツへのリンクが各ユーザーに提供されることができる。ユーザーがそのリンクにアクセスすると、DS３３０６は、ステップ３６１４で、ユーザーのデバイス３３１８に問い合わせをして、デバイス・プラットフォームについての情報を見きわめるよう構成されることができる。ステップ３６１６で、DS３３０６は次いでコンテンツの正しいバージョンを引き起こすことができる。したがって、ユーザーは、自分のデバイス・プラットフォーム／タイプに関する情報を知る、あるいは提供することは要求されない。

本発明のある種の実施形態について上に記載してきたが、記載されている実施形態があくまでも例であることは理解されるであろう。したがって、本発明は記載されている実施形態に基づいて限定されるべきではない。むしろ、本稿に記載される本発明の範囲は、上記の記述および付属の図面とともに参酌されるときの付属の請求項に照らしてのみ限定されるべきである。

ある実施形態に基づいて構成された例示的な開発プラットフォームを示す図である。 図１の開発プラットフォームを使ってある言語で開発されたアプリケーションを別の言語のアプリケーションに変換する例示的なプロセスを示す図である。 図１の開発プラットフォームを使ってアプリケーションを開発するための例示的なプロセスを示すフローチャートである。 ある実施形態に基づく、図１に示されたプラットフォームのような開発プラットフォームを有する例示的なコンテンツ送達システムを示す図である。 別の実施形態に基づく、図１に示されたプラットフォームのような開発プラットフォームを有する例示的なコンテンツ送達システムを示す図である。 図１の開発プラットフォームを使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。 図１の開発プラットフォームを使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。 図１の開発プラットフォームを使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。 図１の開発プラットフォームを使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。 図１の開発プラットフォームを使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。 図１の開発プラットフォームを使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。 図１の開発プラットフォームを使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。 図１の開発プラットフォームを使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。 図１の開発プラットフォームを使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。 図１の開発プラットフォームを使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。 図１の開発プラットフォームを使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。 図１の開発プラットフォームを使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。 図１の開発プラットフォームを使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。 図１の開発プラットフォームを使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。 図１の開発プラットフォームを使って開発されたヴロガー・アプリケーションとの関係でモバイル通信デバイス上およびウェブサイト上に表示されることのできる例示的な画面を示すスクリーンショットである。 ある実施形態に基づく、ブログ・サービスを提供するよう構成されることのできる例示的な通信システムを示す図である。 図２１のシステムに含まれるバックエンド・モバイル広告管理システムによって表示されることのできる例示的な画面を示すスクリーンショットである。 図２１のシステムに含まれるバックエンド・モバイル広告管理システムによって表示されることのできる例示的な画面を示すスクリーンショットである。 図２１のシステムに含まれるバックエンド・モバイル広告管理システムによって表示されることのできる例示的な画面を示すスクリーンショットである。 図２１のシステムに含まれるバックエンド・モバイル広告管理システムによって表示されることのできる例示的な画面を示すスクリーンショットである。 図２１のシステムに含まれるバックエンド・モバイル広告管理システムによって表示されることのできる例示的な画面を示すスクリーンショットである。 図２１のシステムに含まれるバックエンド・モバイル広告管理システムによって表示されることのできる例示的な画面を示すスクリーンショットである。 図２１のシステムに含まれるバックエンド・モバイル広告管理システムによって表示されることのできる例示的な画面を示すスクリーンショットである。 図２１のシステムに含まれるバックエンド・モバイル広告管理システムによって表示されることのできる例示的な画面を示すスクリーンショットである。 図２１のシステムに含まれるバックエンド・モバイル広告管理システムによって表示されることのできる例示的な画面を示すスクリーンショットである。 図２１のシステムに含まれるバックエンド・モバイル広告管理システムによって表示されることのできる例示的な画面を示すスクリーンショットである。 図２１のシステムに含まれるバックエンド・モバイル広告管理システムによって表示されることのできる例示的な画面を示すスクリーンショットである。 図２１のシステムに含まれるバックエンド・モバイル広告管理システムによって表示されることのできる例示的な画面を示すスクリーンショットである。 ある地理的エリア内のユーザーのための一般的広告キャンペーンのカスタマイズを示すスクリーンショットである。 ある実施形態に基づいて構成される例示的なコンテンツ管理システムを示す図である。 ある実施形態に基づいて図３２のシステムを使ってコンテンツを送達する例示的なプロセスを示すフローチャートである。 ある実施形態に基づいて図３２のシステムを使って送達されるコンテンツを変換する例示的なプロセスのフローチャートである。 ある実施形態に基づいて図３のシステムを使って送達されるべきコンテンツをリアルタイムで変換する例示的なプロセスを示す図である。

Claims (14)

1. クライアント・サーバーから変換してモバイル・デバイスに配送するためのコンテンツを受信するよう構成されたオンデマンド・エンコード・サーバーと；
   モバイル・デバイスへのコンテンツの配送を制御するよう構成された配送サーバーと；
   モバイル・デバイスに通信を送るよう構成されたブロードキャスト・サーバーと；
   前記オンデマンド・エンコード・サーバーによって受信されたコンテンツのカスタマイズにおいて使うためのモバイル・デバイス・プラットフォーム・プロファイルを維持するよう構成されたデバイス・プロファイル・サーバーと；
   前記コンテンツについての配送プロファイルを維持するよう構成されたコンテンツ管理サーバーとを有する、
   コンテンツ管理プラットフォーム。
2. 前記オンデマンド・エンコード・サーバーが、前記デバイス・プロファイル・マネージャによって維持されている利用可能なモバイル・デバイス・プラットフォーム・プロファイルにアクセスし、前記利用可能なプロファイルのそれぞれについてクライアント・サーバーから受信されたコンテンツをカスタマイズして、それにより利用可能な各プラットフォームのために前記コンテンツのカスタマイズされたバージョンを生成するよう構成されている、請求項１記載のコンテンツ管理システム。
3. 前記オンデマンド・エンコード・サーバーがさらに、前記コンテンツの前記カスタマイズされたバージョンを、モバイル・デバイスに配送するために前記ブロードキャスト・サーバーにアップロードするよう構成されている、請求項２記載のコンテンツ管理システム。
4. 前記オンデマンド・エンコード・サーバーがさらに、前記コンテンツの前記カスタマイズされたバージョンが利用可能であることを前記配送サーバーに通知するよう構成されている、請求項３記載のコンテンツ管理システム。
5. 前記配送サーバーがさらに、前記コンテンツ管理サーバーに問い合わせをして、前記コンテンツの前記カスタマイズされたバージョンがある種のモバイル・デバイスにプッシュされるべきであることを関連付けられた配送プロファイルが指示しているかどうかを判定し、前記関連付けられた配送プロファイルに従って前記コンテンツの前記カスタマイズされたバージョンを前記ブロードキャスト・サーバーを介してプッシュするよう構成されている、請求項４記載のコンテンツ管理システム。
6. 前記コンテンツ管理サーバーがさらに、前記ブロードキャスト・サーバーを介して前記コンテンツへのリンクを複数のモバイル・デバイスに送るよう構成されている、請求項４記載のコンテンツ管理システム。
7. 前記配送サーバーが、送られたリンクを介して前記コンテンツにアクセスするモバイル・デバイスに、前記コンテンツの正しいカスタマイズされたバージョンを送るよう構成されている、請求項６記載のコンテンツ管理システム。
8. ライブ・フィードから、変換してモバイル・デバイスに配送するためのコンテンツを受信するよう構成されたライブ・エンコード・サーバーと；
   モバイル・デバイスへのコンテンツの配送を制御するよう構成された配送サーバーと；
   モバイル・デバイスに通信を送るよう構成されたブロードキャスト・サーバーと；
   前記オンデマンド・エンコード・サーバーによって受信されたコンテンツのカスタマイズにおいて使うためのモバイル・デバイス・プラットフォーム・プロファイルを維持するよう構成されたデバイス・プロファイル・サーバーと；
   前記コンテンツについての配送プロファイルを維持するよう構成されたコンテンツ管理サーバーとを有する、
   コンテンツをリアルタイムで変換するよう構成されたコンテンツ管理プラットフォーム。
9. 前記ライブ・エンコード・サーバーが、前記デバイス・プロファイル・マネージャによって維持されている利用可能なモバイル・デバイス・プラットフォーム・プロファイルにアクセスし、前記利用可能なプロファイルのそれぞれについてリアルタイムで前記ライブ・フィードから受信されたコンテンツをカスタマイズして、それにより利用可能な各プラットフォームのために前記コンテンツのカスタマイズされたバージョンを生成するよう構成されている、請求項８記載のコンテンツ管理システム。
10. 前記ライブ・エンコード・サーバーがさらに、前記コンテンツの前記カスタマイズされたバージョンを、モバイル・デバイスに配送するために前記ブロードキャスト・サーバーにアップロードするよう構成されている、請求項９記載のコンテンツ管理システム。
11. 前記ライブ・エンコード・サーバーがさらに、前記コンテンツの前記カスタマイズされたバージョンが利用可能であることを前記配送サーバーに通知するよう構成されている、請求項１０記載のコンテンツ管理システム。
12. 前記配送サーバーがさらに、前記コンテンツ管理サーバーに問い合わせをして、前記コンテンツの前記カスタマイズされたバージョンがある種のモバイル・デバイスにプッシュされるべきであることを関連付けられた配送プロファイルが指示しているかどうかを判定し、前記関連付けられた配送プロファイルに従って前記コンテンツの前記カスタマイズされたバージョンを前記ブロードキャスト・サーバーを介してプッシュするよう構成されている、請求項１１記載のコンテンツ管理システム。
13. 前記コンテンツ管理サーバーがさらに、前記ブロードキャスト・サーバーを介して前記コンテンツへのリンクを複数のモバイル・デバイスに送るよう構成されている、請求項１１記載のコンテンツ管理システム。
14. 前記配送サーバーが、モバイル・デバイスに問い合わせをして関連付けられたデバイス・プラットフォームを判別し、送られたリンクを介して前記コンテンツにアクセスするモバイル・デバイスに、前記コンテンツの正しいカスタマイズされたバージョンを送るよう構成されている、請求項１３記載のコンテンツ管理システム。

Images