JP2014525616A - オンラインコンテンツポータルへのコンテンツ関連メタデータの大量取り込み - Google Patents

Abstract

本技術は、オンラインサーバによってサポートされるアプリケーションに関連する消費財に関連するメタデータの大量取り込みをサポートする。オンラインサーバが、消費財に関連するメタデータの大量提供を容易にするための、メタデータフィールド、許容されるフォーマット値、およびその他のパラメータを定義する仕様を公表する。その仕様に従って用意されたメタデータが、データストリームを介して、または、複数の消費財を定義しているメタデータを含む文書の提供を通して、オンラインサーバに供給されてもよい。仕様は、サーバがサポートするアプリケーションにおける消費財の多様な用途を説明するように合理的に設計されている。本明細書でさらに記述するとおり、この仕様は、特に、加入コンテンツ、アプリケーション内購入、ゲームの成績、およびゲームの特典の消費財に関係のある、固有のイベントを説明する。あらゆるタイプの消費財を、同一文書内で提供することができる。

Description

［関連出願の相互参照］
本願は、２０１１年８月２６日に出願され、「ＭＡＳＳ ＩＮＧＥＳＴＩＯＮ ＯＦ ＣＯＮＴＥＮＴ ＲＥＬＡＴＥＤ ＭＥＴＡＤＡＴＡ ＴＯ ＡＮ ＯＮＬＩＮＥ ＣＯＮＴＥＮＴ ＰＯＲＴＡＬ（オンラインコンテンツポータルへのコンテンツ関連メタデータの大量取り込み）」と題された、米国特許出願第１３／２１９，２９８号の優先権を主張するものであり、それを全体として参照により本願に援用する。

［技術分野］
本開示は、オンラインコンテンツポータルへのデータの提供に関し、より詳細には、オンラインコンテンツポータルへのコンテンツメタデータの大量提供に関する。

オンライン市場（マーケットプレイス）の出現は、製品の開発者に、自社製品を世界中の消費者に販売できるようにするオンラインフォーラムをもたらした。自社製品を記述しているメタデータをオンライン市場にアップロードするだけで、開発者は、何百万人もの消費者が自宅のコンピュータまたは移動デバイスで自社製品を直接入手できるようにすることができる。オンライン市場によって世界中の多数の消費者に製品を提供することが非常に容易になる一方で、マーケティング担当者は、自社製品を記述しているメタデータをロードするという膨大な作業に直面している。

製品を記述しているメタデータは、オンラインで提供される製品を識別するのに用いられる。現状では、製品を記述しているメタデータ、例えば、製品の開発者、製品名、価格、説明および画像は、入力される個々の製品について開発者がコンテンツプロバイダのサーバ上で入力しなければならない。この作業には大変な手間がかかり、しかも開発者がコンテンツプロバイダのサーバにログオンすることが必要となる。また、個々の製品についてすべてのフィールドに入力しなければならない。そのため、開発者が複数の類似する品目を入力する場合、開発者は、すべての関連品目について一度というのではなく、個別の品目についてメタデータを記入しなければならない。従って、開発者がオンライン市場にメタデータを提出するためのより便利で効率的な方策が必要である。

以下の記述の中で、本開示のさらなる特徴および利点について述べるが、それらの一部分は記述から明らかであるか、または本明細書で開示された原理の実施によって分かるものである。本開示の特徴および利点は、添付の請求項において具体的に示す機器および組み合わせによって実現され、得られうるものである。本開示のこれらの特徴およびその他の特徴は、以下の記述および添付の請求項からさらに十分に明らかになるか、または本明細書で述べた原理の実施によっても分かるものである。

開示するのは、オンラインサーバがサポートするアプリケーションに関連する消費財(consumable)に関連するメタデータの大量取り込みのためのシステム、方法、デバイス、および非一時的なコンピュータ可読記憶媒体である。

一部の実施形態では、オンラインサーバは、消費財に関連するメタデータの大量提供を容易にするためのメタデータフィールド、許容されるフォーマット値、およびその他のパラメータを定義する仕様を公表する。その仕様に従って用意されたメタデータが、データストリームを介して、または、複数の消費財を定義しているメタデータを含む文書の提供を通して、オンラインサーバに供給されてもよい。

仕様は、サーバによってサポートされるアプリケーションにおける消費財の多様な用途を説明するように合理的に設計されている。本明細書でさらに記述するように、この仕様は、特に、加入コンテンツ、アプリケーション内購入、ゲームの成績、およびゲームの特典の消費財に関係のある、固有のイベントを説明するものである。あらゆるタイプの消費財を、同一文書内で提供することができる。

公表された仕様に基づいて、開発者は、自社のメタデータを管理するためのツールを実装し、サーバに提供する文書の作成を自動化してもよい。

サーバは、コンテンツフォーマットおよび内容についてメタデータを検証してもよく、一部の実施形態では、提供されたメタデータを、開発者とサーバとの間の契約合意と比較してもよい。

検証されたメタデータは、さらに、サーバによって公表され、開発者のアプリケーションによってアクセスされてもよく、アプリケーション内購入、ゲームの特典のデータ、加入、およびその他の消費財をサポートするのに用いられてもよい。

本開示の上記およびその他の利点および特徴をどのようにして得ることができるかを説明するため、上記で簡単に説明した原理を、添付の図面に示す特定の実施形態を参照しながら、より具体的に記述する。これらの図面は、本開示の例示的な実施形態を示しているだけであり、それゆえ、本開示の範囲を限定しているとみなされてはならないことを理解した上で、添付の図面を用いてさらに具体的かつ詳細に本明細書の原理を記述して説明する。

例示的な汎用コンピュータデバイスを示す図である。

例示的なコンピュータシステムを示す図である。

仕様で指定されるフォーマットにおける例示的なメタデータファイルを示す図である。

複数の消費財全体でデータフィールドが共有されている例示的なメタデータファイルを示す図である。

ゲームセンタの消費財を定義する例示的なメタデータファイルを示す図である。

オンラインコンテンツポータルへのメタデータの大量提供のための例示的な方法を示す図である。

消費財ローダアプリケーションのグラフィカルユーザインタフェースの例示的なスクリーンショットを示す図である。

スプレッドシートフォーマットのグラフィカルユーザインタフェースを提供する消費財ローダアプリケーションの例示的なスクリーンショットを示す図である。

加入として購入されうる消費財を定義しているメタデータファイルの例示的な実施形態を示す図である。

販売地域に基づいて消費財の発売日が変わる、メタデータファイルの例示的な実施形態を示す図である。

本開示のさまざまな実施形態について、以下に詳しく論じる。特定の実装について論じているが、これは例示する目的に限定して行われていることを理解されたい。当業者には、本開示の趣旨および範囲から逸脱することなく他のコンポーネントや構成が用いられうることは、認識されると思う。

図１は、例示的なシステムを示しており、このシステムには、処理ユニット（ＣＰＵすなわちプロセッサ）１２０を含む汎用コンピュータデバイス１００と、読み取り専用メモリ（ＲＯＭ）１４０およびランダムアクセスメモリ（ＲＡＭ）１５０のようなシステムメモリ１３０を含めて各種のシステムコンポーネントをプロセッサ１２０に接続するシステムバス１１０とが含まれている。システム１００には、プロセッサ１２０に直接接続されているか、近接しているか、あるいはその一部として統合されている高速メモリのキャッシュ１２２が含まれていてもよい。システム１００は、データをメモリ１３０および／またはストレージデバイス１６０からキャッシュ１２２へコピーして、プロセッサ１２０が高速でアクセスできるようにする。このようにして、キャッシュ１２２は、データを待っている間のプロセッサ１２０の遅延を回避するパフォーマンスブーストを提供する。これらおよびその他のモジュールは、各種の動作を行うようにプロセッサ１２０を制御するか、または制御するように構成されてもよい。また、その他のシステムメモリ１３０が同様に利用できてもよい。メモリ１３０には、異なる性能特性を持つ複数の異なるタイプのメモリが含まれていてもよい。理解されると思うが、本開示は、処理能力を高めるために、複数のプロセッサ１２０を持つコンピュータデバイス１００上で、または、ネットワーク化されたコンピュータデバイスのグループまたはクラスタ上で動作してもよい。プロセッサ１２０には、いかなる汎用プロセッサが含まれてもよいし、プロセッサ１２０を制御するように構成されたハードウェアモジュールまたはソフトウェアモジュール、例えばストレージデバイス１６０の中に格納されたモジュール１ １６２、モジュール２ １６４、モジュール １６６が含まれてもよいし、実際のプロセッサ設計の中にソフトウェア命令が組み込まれている専用プロセッサが含まれてもよい。プロセッサ１２０は本質的に、複数のコアまたはプロセッサ、バス、メモリコントローラ、キャッシュ等を含んでいる、完全に自己完結型のコンピュータシステムであってもよい。マルチコアプロセッサは、対称でも非対称でもよい。

システムバス１１０は、メモリバスまたはメモリコントローラ、周辺バス、多様なバスアーキテクチャのいずれかを用いたローカルバスを含めて、複数のタイプのバス構造のいずれであってもよい。ＲＯＭ１４０等に格納された基本的な入力／出力（ＢＩＯＳ）が、起動時等にコンピュータデバイス１００の中の要素間で情報を転送するのに役立つ基本的なルーチンを提供してもよい。コンピュータデバイス１００はさらに、ハードディスクドライブ、磁気ディスクドライブ、光ディスクドライブ、テープドライブ等のようなストレージデバイス１６０を含んでいる。ストレージデバイス１６０は、プロセッサ１２０を制御するためのソフトウェアモジュール１６２、１６４、１６６を含んでいてもよい。その他のハードウェアモジュールやソフトウェアモジュールも考えられる。ストレージデバイス１６０は、ドライブインタフェースによってシステムバス１１０に接続されている。これらのドライブや、関連のコンピュータ可読記憶媒体は、コンピュータデバイス１００についてのコンピュータ可読命令、データ構造、プログラムモジュールおよびその他のデータの不揮発性の記憶を提供する。一態様では、或る機能を行うハードウェアモジュールは、プロセッサ１２０、バス１１０、ディスプレイ１７０等のような、その機能を実行するのに必要なハードウェアコンポーネントと関連して非一時的なコンピュータ可読媒体の中に格納されたソフトウェアコンポーネントを含んでいる。基本的なコンポーネントは、当業者には公知であり、デバイス１００が小型の手持ち式のコンピュータデバイスなのか、デスクトップコンピュータなのか、コンピュータサーバなのかといったデバイスのタイプによって、適切な変形形態が考えられる。

本明細書に記述した例示的な実施形態はハードディスク１６０を用いているが、磁気カセット、フラッシュメモリカード、ＤＶＤ、カートリッジ、ランダムアクセスメモリ（ＲＡＭ）１５０、読み取り専用メモリ（ＲＯＭ）１４０、ビットストリーム等を含むケーブルまたはワイヤレス信号のような、コンピュータによってアクセス可能なその他のタイプのコンピュータ可読媒体が例示的操作環境において用いられうることは、当業者には理解されると思う。エネルギー、搬送波信号、電磁波、および本質的な信号のような媒体は、非一時的なコンピュータ可読記憶媒体から明確に除外される。

ユーザとコンピュータデバイス１００との対話を可能にするため、入力デバイス１９０は、音声用マイクロフォン、ジェスチャまたはグラフィカル入力用のタッチセンシティブスクリーン、キーボード、マウス、動作入力、音声等、いくつもの入力メカニズムを表している。また、出力デバイス１７０も、当業者には公知の複数の出力メカニズムのうちの１つ以上であってもよい。場合によっては、マルチモーダルシステムによって、ユーザが、コンピュータデバイス１００と通信するための複数のタイプの入力を行うことが可能になる。通常、通信インタフェース１８０が、ユーザ入力とシステム出力とを管理する。特定のハードウェア構成上で動作することについての制限はなく、従って、本明細書での基本的な機能は、改良型のハードウェア構成やファームウェア構成が開発されれば、それらと容易に置き換わりうる。

説明を分かりやすくするために、例示的なシステムの実施形態は、「プロセッサ」またはプロセッサ１２０とラベルを付けた機能ブロックを含めて、個別の機能ブロックを含むかたちで提示されている。これらのブロックが表す機能は、ソフトウェアを実行することができるハードウェアや、プロセッサ１２０のような、汎用プロセッサ上で実行されるソフトウェアとの等価物として動作する専用のハードウェアを含めて、共有ハードウェアまたは専用ハードウェアを利用して提供されてもよいが、それらに限定されない。例えば、図１に示す１つ以上のプロセッサの機能は、単一の共有プロセッサまたは複数のプロセッサによって提供されてもよい。（「プロセッサ」という用語の使用は、ソフトウェアを実行することのできるハードウェアのみに言及すると解釈されるべきではない。）例示的な実施形態には、マイクロプロセッサおよび／またはデジタルシグナルプロセッサ（ＤＳＰ）ハードウェア、以下に論じる動作を行うソフトウェアを格納するための読み取り専用メモリ（ＲＯＭ）１４０、および、結果を格納するためのランダムアクセスメモリ（ＲＡＭ）１５０が含まれてもよい。また、大規模集積（ＶＬＳＩ）ハードウェア実施形態だけでなく、汎用ＤＳＰ回路と組み合わせたカスタムＶＬＳＩ回路機構も、提供されてよい。

各種の実施形態の論理演算は、（１）汎用コンピュータ内のプログラム可能回路上で実行される、コンピュータで行われる一連のステップ、動作、または手順、（２）特定用途のプログラム可能回路上で実行される、コンピュータで行われる一連のステップ、動作、または手順、および／または（３）プログラム可能回路内の、相互接続されたマシンのモジュールまたはプログラムエンジンとして実施される。図１に示すシステム１００は、列挙された方法の全部または一部を実行してもよいし、列挙されたシステムの一部であってもよいし、および／または、列挙された非一時的なコンピュータ可読記憶媒体の中の命令に従って動作してもよい。そのような論理演算は、モジュールのプログラミングに従って具体的な機能を実行するためにプロセッサ１２０を制御するように構成されたモジュールとして実施されてもよい。例えば、図１は、プロセッサ１２０を制御するように構成されたモジュールであるＭｏｄ１ １６２、Ｍｏｄ２ １６４、Ｍｏｄ３ １６６という３つのモジュールを示す。これらのモジュールは、ストレージデバイス１６０上に格納されて実行時にＲＡＭ１５０またはメモリ１３０にロードされてもよいし、当分野では公知のように他のコンピュータ可読メモリ位置に格納されてもよい。

コンピュータシステムの一部のコンポーネントをここまで開示してきたが、次に、図２について考える。図２は、開発者が、消費財を記述しているコンテンツメタデータをオンラインコンテンツポータルに大量に提供できるようなコンピュータ環境を示す。開発者が、ユーザに提供されることになる消費財を開発してもよい。消費財とは、消費者が入手できるものであって、サーバのサポートが行われることが必要なものであれば、いかなるものであってもよい。例えば、消費財には、アプリケーション、アプリケーション内購入、アプリケーションの更新、ゲームの成果、加入、電子媒体等が含まれていてもよい。一部の実施形態では、消費財とは、電子形式で提供された雑誌や書籍のような出版物であってもよい。一部の実施形態では、消費財とは、ゲームアプリケーションの中で換金されることになるコインのようなアプリケーション内購入であってもよい。一部の実施形態では、消費財とは、購入される必要のない品目であり、例えば、消費財とは、ユーザがゲームアプリケーションを利用することによって達成されうるゲームの成果であったり、ダウンロードされて無料でインストールされうる既存のアプリケーションの更新であったりしてもよい。一部の実施形態では、消費財とは、サービスまたは製品への加入であってもよい。例えば、消費財とは、電子形式または物理形式あるいはそれら両方で配達されうる雑誌への加入であってもよい。あるいは、消費財とは、コンピュータデバイスのサポートサービスへの加入やウェブサイトへの加入であってもよい。一部の実施形態では、消費財とは、電子的に購入もしくは貸借されうる物理的商品を表す。

消費財の開発を終えると、開発者は、通信ネットワークを通して１つ以上のチャネルを使ってユーザに消費財を提供するコンテンツプロバイダに消費財を送信することによって、消費者が消費財を利用できるようにしてもよい。一部の実施形態では、消費財は、アップルのｉＴｕｎｅｓ（登録商標）のようなオンラインストアで提供され、別の実施形態では、消費財は、ウェブサイト上で入手できるようにされてもよい。別の実施形態では、消費財は、アプリケーションの中で入手できるようにされてもよい。消費財を提供するために、コンテンツプロバイダは、消費財を定義しているメタデータを必要とする。消費財を定義しているメタデータは、消費財を記述しているならばいかなるデータで構成されてもよい。例えば、消費財を定義しているメタデータは、タイトル、価格、説明、機能性、開発者、スクリーンショット、親、得点、互換性、言語、バージョン、ソフトウェア、サイズ、場所、フォーマット、参照名、カテゴリ、製品、著作権、キーワード、ＵＲＬ、ファイル名、暗号化、コード、強度、在庫一掃セール、価格段階、セール開始日、間隔、資産等で構成されてもよい。

メタデータをコンテンツプロバイダに提供するため、開発者は、メタデータ値を集めたもの(compilation)から成るファイルを作成してもよい。このファイルは、通信ネットワーク２１０を介してコンテンツサーバ２３０と通信するように構成されうる開発者のコンピュータデバイス２２０上で作成されてもよい。メタデータファイルは、コンテンツサーバ２３０によって指定またはサポートされる仕様に従って作成されるべきである。仕様は、メタデータファイルを作成する時に従わなければならない構文規則を提供することによって、文書のフォーマットと必要なフィールドとを定義してもよい。例えば、一部の実施形態では、仕様は、所定のメタデータフィールドが所定のタグ領域内に配置されることを求める、カスタマイズされたタグを持つＸＭＬファイルのようなデータ配信言語ファイルを作成するための構文規則を提供してもよい。仕様の中の構文規則に従うことによって、開発者は、複数の消費財を定義するメタデータファイルを作成してもよい。メタデータファイルは、作成された後、通信ネットワーク２１０を介してコンテンツサーバ２３０へ送信され、そこで取り込まれ、最終的に１つ以上のチャネルを通して公表されてもよい。

開発者は、複数のやり方でメタデータファイルを作成することができる。例えば、一部の実施形態では、開発者は、仕様の中に記述された定義済の構文規則に単純に従うことによって、ワードプロセッサまたはコードエディタを使ってメタデータファイルを作成してもよい。別の実施形態では、開発者は、定義された仕様に従ってメタデータファイルを作成する社内ツールを作成することによって、プロセスを自動化してもよい。別の実施形態では、メタデータファイルは、この目的でコンテンツプロバイダによって提供される消費財ローダアプリケーションを用いて作成されてもよい。消費財ローダアプリケーションは、アプリケーション内のフィールドに記入することによってメタデータの追加や定義を行うためのグラフィカルユーザインタフェース（ＧＵＩ）を開発者に提供するアプリケーションであってもよい。一部の実施形態では、消費財ローダアプリケーションは、コンテンツサーバ２３０上で実行され、通信ネットワーク２１０を介して開発者のコンピュータデバイス２２０によってアクセスされてもよい。別の実施形態では、消費財ローダアプリケーションは、開発者のコンピュータデバイス２２０上で実行され、メタデータがコンテンツサーバ２３０へ送信される準備ができるまでは、通信ネットワーク２１０にアクセスすることを必要とせず、開発者が、すべてのメタデータを消費財ローダアプリケーションにオフラインでロードしてもよい。消費財ローダアプリケーションは、ＧＵＩの中で開発者によって入力されたデータを取り込んで、仕様の構文規則に適合するメタデータファイルを作成するように構成されてもよい。一部の実施形態では、ＧＵＩは、開発者が自社のスプレッドシートから転送またはインポートすることによって容易に情報を入力できるようなスプレッドシートのレイアウトを提供してもよい。

コンテンツサーバ２３０は、メタデータファイルを取り込んで、通信ネットワーク２１０を介してユーザデバイス２４０がデータを入手できるようにするように構成されてもよい。メタデータファイルを取り込むのは、メタデータファイルを受け入れる自動プロセスであってもよい。一部の実施形態では、取り込みは、データフィードからメタデータファイルを受け入れることであってもよい。一部の実施形態では、取り込みは、コンテンツサーバ上で実行される消費財ローダアプリケーションからメタデータファイルを受信することであってもよい。一部の実施形態では、メタデータファイルは、個別に取り込まれてもよい。一部の実施形態では、メタデータファイルは、まとめて受け入れられてもよい。また、コンテンツサーバ２３０は、各消費財に関するコンテンツプロバイダと開発者との間の契約の中で定義された仕様とコンテンツプロバイダの方針とにメタデータが適合していることを保証するために、メタデータを検証してもよい。コンテンツプロバイダは、消費財を公表することに関する方針をいくつでも設定してよい。例えば、一部の実施形態では、コンテンツプロバイダは、既存のアプリケーションの見直しがすでに行われて受け入れられている場合を除いて、アプリケーション内購入または既存のアプリケーションに関連する更新は受け入れないという方針を有していてもよい。従って、アプリケーション内購入を定義しているメタデータファイルがコンテンツサーバ２３０で受信された場合、コンテンツサーバ２３０は、公表に先立って関連のアプリケーションの見直しが行われたことを保証するため、チェックを行うであろう。関連のアプリケーションが拒否されたかまたはまだ承認を待っている場合、コンテンツサーバ２３０は、メタデータを公表せず、このコンテンツは方針に適合していないため公表されなかったというメッセージを開発者に送信してもよい。

また、仕様に適合していることを保証するため、メタデータファイルが検証されてもよい。これには、ファイル文書内の構文エラーやミススペリングのような単純ミスのチェックが含まれてもよい。また、入力された情報のタイプに基づいてすべてのデータフィールドが適切であることの検証が含まれてもよい。例えば、一部の実施形態では、消費財のタイプに基づいて、異なるデータフィールドが必要とされてもよい。コンテンツプロバイダが、アプリケーション内購入を入力する時に画像と価格とを含んでいることを必要としてもよい。また、一部の実施形態では、仕様は、データタイプに基づいて所定のデータフィールドが省略されることを必要としてもよい。例えば、消費財が更新である場合、仕様は、価格データが入力されないことを必要としてもよい。コンテンツサーバ２３０は、メタデータファイルが仕様のこれらの規則に適合していることを検証してもよく、そして適合していない場合、開発者に誤りを警告してもよい。一部の実施形態では、検証は、メタデータファイルの取り込みより前に行われてもよい。これは、無効なファイルを取り込むのに時間とリソースとが浪費されないようにするために行われてもよい。一部の実施形態では、検証は、取り込みプロセスの後かまたはその一部として行われてもよい。

コンテンツサーバ２３０によってメタデータファイルが取り込まれて検証された後、データを公表する準備が行われ、用意が整ってもよい。一部の実施形態では、メタデータが抽出されて、別のフォーマットのファイルを作成するのに用いられてもよい。一部の実施形態では、別のファイルまたはプログラムが、公表の際にファイルから直接メタデータを抽出してもよく、新たなファイルは作成されない。開発者は、準備されたデータにエラーがなく自社の承認に合致していることを保証するため、準備されたデータに関して自分自身の検証を行いたいと思うことがありうる。従って、開発者は、準備されたデータが検証用に開発者のコンピュータデバイス２２０へ返信されることを要求する要求を、開発者のコンピュータデバイス２２０からコンテンツサーバ２３０へ、通信ネットワーク２１０を介して、送信してもよい。要求が受信された後、コンテンツサーバ２３０は、準備されたデータを開発者のコンピュータシステム２２０へ通信ネットワーク２１０を用いて返信してもよい。開発者のコンピュータシステム２２０によって受信した後、開発者は、サンドボックスされた試験環境において品質試験を行ってもよい。

図３は、指定されたフォーマットの例示的なメタデータファイル３００を示す図である。図示するとおり、仕様は、メタデータファイル３００が、データフィールドのコンテンツタイプおよびそのサイズも定義しうるデータタグを用いて整理されることを指定してもよい。例えば、開発者３０５を定義するデータフィールドは、＜ｄｅｖｅｌｏｐｅｒ（開発者）＞というラベルの第１のデータタグで始まり、＜／ｄｅｖｅｌｏｐｅｒ＞というラベルの第２のデータタグで終わる。この実施形態では、ＸＭＬにおいて従来行われているように、スラッシュを用いて第２のタグを示している。タグとタグとの間のデータが、メタデータ値である。図示するとおり、開発者フィールド３０５のメタデータ値は、「Ｆａｋｅ Ｄｅｖｅｌｏｐｅｒ（偽の開発者）」と定義されている。また、データフィールドは、他のデータフィールドの中に入れ子にされてもよい。

一部の実施形態では、仕様は、データフィールドが複数の消費財全体で共有されるように構成されてもよい。例えば、図３に示すメタデータファイルは、２つのアプリケーション内購入３１５および３２０を定義している。アプリケーション内購入は両方とも、共通の開発者データフィールド３０５を共有しており、従って、仕様は、開発者が一度指名されることだけを必要としており、それが、アプリケーション内購入３１５および３２０の両方に関連付けられる。

図４は、複数の消費財全体でデータフィールドがどのように共有されうるかについての別の一例を示す図である。図示するとおり、２つのアプリケーション内購入４０５および４１０が定義されている。アプリケーション内購入はいずれも、同じ開発者、画像、価格を有しており、いずれも、在庫一掃セールである。個々のアプリケーション内購入について同じデータを書き直すことを避けるように、アプリケーション内購入はいずれも、同じファミリーデータフィールド４１５に含まれており、従って、共通データフィールド４２０は、一度含まれるだけで、アプリケーション内購入４０５と４１０との両方に関連付けられることができる。

図３に戻って、仕様は、開発者が価格設定間隔を定義できるように構成されてもよい。例えば、開発者は、当初の購入を増やすために当初は新規のアプリケーション内購入を割引価格で販売し、その後、通常金額へと価格を変更することを選んでもよい。一部の実施形態では、価格設定は、ドルによる実際の金額ではなく、段階によって指定されてもよい。一部の実施形態では、価格設定は、消費財がユーザに対して無料であるように、ゼロ値を含んでいてもよい。第２の定義されたアプリケーション内購入３２０は、開発者がデータフィールドの時間範囲を定義できるようにする間隔タグ３２５を含んでいる。２つの間隔３３０および３３５が定義されている。図示するとおり、間隔３３５は、２０１１年１月１日の開始日から２０１１年５月１日の終了日まで、価格は０．９９であると定義している。間隔３３５は、２０１１年５月１日の開始日から、終了日は定義せず、価格は１．９９であると定義している。この例では間隔タグを用いて価格が変更されたが、仕様がそのデータフィールドについて間隔をサポートする場合には、いかなるデータフィールドが間隔に基づいて変更されてもよい。

図９は、加入として購入されうる消費財を定義するメタデータファイルの例示的な実施形態を示す図である。一部の実施形態では、消費財は、ユーザがスケジュール通りに支払いをすることを必要とすることがあり、例えば、消費財は、毎月新たな発行物が発行される雑誌であるか、毎月の支払を必要とするサービスであってもよい。従って、メタデータファイルは、このタイプの価格設定の選択肢を反映してもよい。図示するとおり、加入データフィールド９０５が定義されている。埋め込まれた発行日データフィールド９１０は、１と定義されており、加入価格が、毎月１日に支払われるべきだということを示している。価格データフィールド９１５は、３．９９と定義されており、従って、購入された場合、消費財は、３．９９であり、ユーザは毎月１日に請求されることになる。一部の実施形態では、開発者は、請求が再び行われる日付を設定するのではなく、ユーザに請求する間隔の日数を、例えば３０日毎というように定義してもよい。

図１０は、販売地域に基づいて消費財が定義されるようなメタデータファイルの例示的な実施形態を示す図である。一部の実施形態では、開発者は、消費財を世界中に公表するか、一部の販売地域だけに公表するかを選んでもよい。図示するとおり、２つの消費財のデータフィールド１００５および１０１０が定義されている。消費財１００５の販売地域データフィールド１０１５は、米国を示すためにＵＳと定義されており、他方、消費財１０１０の販売地域データフィールド１０２０は、世界中を示すためにＷＷと定義されている。消費財１００５は、２０１１年１月１日と定義された販売開始日データフィールド１０２５を有しており、他方、消費財１０１０の販売開始日データフィールド１０３０は、２０１１年３月１日と定義されている。従って、消費財１００５は、２０１１年１月１日に米国内で購入できるようになるであろうし、消費財１０１０は、２０１１年３月１日から世界中で入手できるようになるであろう。一部の実施形態では、開発者は、ある販売地域では他の販売地域に先んじて消費財を公表したいと望むことがある。図示する例では、消費財１００５および消費財１０１０は、同じ製品のことを言っている可能性があり、従って、この製品は、２０１１年１月１日に米国で公表され、次いで、２０１１年３月１日から世界中に公表されるであろう。

また、消費財１０１５および１０２０はいずれも、設定された購入金額ではなく、価格段階を用いている。価格段階は、指定された段階の範囲内に価格設定されたすべての消費財が同じ価格であるように、消費財の値段を設定された所定の金額にすることができる。各消費財についての価格段階データフィールド１０３５および１０４０は、段階３として定義されている。段階は、通貨が異なる複数の販売地域全体に渡って、等しい価格設定を保証するのに用いられる。従って、段階３と価格設定された消費財は、ユーロで支払われようと米ドルで支払われようと、比較すれば同じ費用であるべきである。また、段階を用いると、価格を変更する手間が省けることがある。段階の価格を一度変更すれば、その段階の範囲内のすべての消費財の価格を変更することができる。例えば、段階３の所定の価格が３米ドルである場合、この所定の価格を３．２５米ドルに変更すれば、段階３と定義された価格段階データフィールドを持つすべての消費財の価格を変更することになる。

図５は、ゲームセンタの消費財を記述しているメタデータファイルの例示的な実施形態を示す図である。図示するとおり、２つの消費財が定義されている。第１は、ゲーム内の成果５０５であり、第２は、順位表５１０である。図示するとおり、開発者のデータフィールドは、両方の消費財全体の共通メタデータ値として関連付けられている。

第１の定義されたゲームセンタの消費財は、ゲーム内成果５０５である。ゲーム内成果は、ゲームアプリケーションの範囲内で特定のタスクまたはタスクの集合を実行することに与えられる特典であってもよい。例えば、一部の実施形態では、ゲーム内成果は、所定の時間内に或るレベルに合格することに対して与えられてもよい。一部の実施形態では、ゲーム内成果は、所定数のタスクが実行された場合に与えられてもよい。ゲーム内成果を達成することに与えられる褒美は、開発者が選択するいかなるタイプの特典であってもよい。一部の実施形態では、ユーザは、ゲーム内成果を達成したことについてのポイントを与えられてもよい。一部の実施形態では、ユーザは、ユーザのプロフィールに関連付けられることになるバーチャルなトロフィーを与えられてもよい。一部の実施形態では、ユーザは、Ｔシャツやトロフィーのような物理的な商品を与えられてもよい。図示するとおり、ポイントデータフィールド５１５は、１０として定義されており、従って、ユーザは、定義されたゲーム内成果を達成することについて１０ポイント５１５を与えられる。

一部の実施形態では、開発者は、ゲーム内成果に関連する画像を、ユーザに関するステータスに基づいて変更したいと望むことがある。例えば、開発者は、ユーザがまだ成果を挙げていない間はトロフィーの画像を影付きで表示し、次いで、ユーザがゲーム内成果を達成した後で、そのトロフィーが明るく表示された画像に変更したいと望むことがある。図示するとおり、開発者は、この目標を達成するようにメタデータファイルをすでに構成している。開発者は、獲得前データフィールド５２０の中の画像をｂｅｆｏｒｅｉｍａｇｅ．ｇｉｆとして、獲得後データフィールド５２５の中の画像をａｆｔｅｒｉｍａｇｅ．ｇｉｆとして定義している。従って、ユーザが成果を達成していない間は、前画像が表示されるが、ユーザが成果を達成した後は、後画像が表示されるであろう。

第２の定義されたゲームセンタの消費財は、順位表５１０である。順位表は、ユーザの成果がリストされるものであれば、ゲームアプリケーションに関連するいかなるタイプの順位表であってもよい。一部の実施形態では、順位表は、単純に最高得点をリストしてもよい。一部の実施形態では、順位表は、成果を最も多く達成したユーザのリスト、または単純に、一定の成果を達成したユーザのリストであってもよい。一部の実施形態では、順位表が親順位表に関連付けられることにより、順位表が、親順位表の部分集合をリストしてもよい。例えば、１つの特定の成果を達成したユーザをすべて表示する順位表は、同一のゲームアプリケーションの範囲内で成果の合計数が最も多いユーザを表示する順位表の部分集合であってもよい。図示する実施形態では、親順位表データフィールド５３０が、順位表１として定義されている。定義された順位表５１０は、従って順位表１に関連付けられている。これには、得点または成果の同一データベースからデータをプルすることが含まれてもよい。一部の実施形態では、順位表は、親順位表の定義された部分集合であってもよい。例えば、例示する実施形態では、最小得点データフィールド５４５が１００，０００として定義され、最大得点データフィールドが１，０００，０００として定義されている。定義された順位表５１０は、従って、親順位表である順位表１の部分集合として定義されており、１００，０００から１，０００，０００までの範囲内の得点だけを表示する。また、開発者は、順位表上でデータがどのように表示されるかを定義してもよい。例えば、例示する実施形態では、昇順ソートデータフィールド５３５は、真として設定されている。従って、データは、昇順に表示されることになる。一部の実施形態では、順位表データは、アルファベット順に表示されてもよい。一部の実施形態では、順位表データは、直近の得点や成果が最初にリストされるように、時刻に基づいて表示されてもよい。

図６は、公表するためオンラインコンテンツサーバにメタデータを大量提供して取り込むためのフローチャートを示す。ステップ６１０で、開発者は、複数の消費財を定義する仕様に従って、メタデータを集めたものから成るファイルを作成する。ファイルは、開発者によって手作業で作成されてもよいし、開発者によって作成される自動プロセスを用いて作成されてもよい。あるいは、メタデータファイルは、コンテンツプロバイダによって提供されるアプリケーションローダアプリケーションを用いて作成されてもよい。

メタデータファイルは、作成された後、通信ネットワークを介してコンテンツプロバイダのサーバへ提供されてもよい６２０。一部の実施形態では、コンテンツプロバイダは、ファイルを送信するために利用可能なデータフィードを作成してもよい。

メタデータファイルがコンテンツサーバに提供され、コンテンツサーバによって取り込まれた後６３０、メタデータファイルは、次いで、消費財に関するサーバポリシーに適合していることを保証するために検証されてもよい６４０。また、メタデータは、仕様に適合していることを保証するために検証されてもよい。

メタデータが取り込まれた後６３０、開発者は、品質を保証する目的でメタデータに関する検証を実行するためにデータが返信されるよう望むことがある。取り込まれたメタデータは、このため、開発者に返信されてもよい。

６５０において、メタデータは、コンテンツプロバイダによって公表される。これには、取り込まれたデータをウェブサイト上にかまたはオンライン市場に提供することが含まれてもよい。あるいは、取り込まれたメタデータが、コンテンツプロバイダのサーバと通信して、アプリケーション内で公表されてもよい。

図７は、消費財ローダアプリケーションのグラフィカルユーザインタフェースの例示的な実施形態を示す図である。この実施形態では、システムにすでに入力されているすべての消費財を表示する消費財リストが表示されている７０５。このリストから、開発者は、入力済の消費財をいくらでもクリックすれば、データフィールドへの入力または変更を、１つのデータフィールドまたは全部のデータフィールドに対して一度に行うことができる。例えば、開発者が、３つの異なる消費財について同じ画像を使用したいと望む場合、開発者は、３つすべてをリストから選び、次いで、画像ファイルを画像データフィールド７１０に入力してもよい。開発者は、例えば、記述データフィールド７１５や価格データフィールド７２０など、いずれかの他のデータフィールドでも同じことができる。また、開発者は、間隔開始日データフィールド７２５および間隔終了日データフィールド７３０を記入することによって、いずれのデータフィールドであっても間隔として設定することができる。例えば、開発者は、消費財リスト７０５から消費財を選び、価格データフィールド７２０に値下げした価格を、間隔開始日および間隔終了日を間隔データフィールド７２５および７３０に入力することによって、複数の消費財を選んで１週間値下げした価格で掲載することができる。また、開発者は、フィールド７０５に新規の消費財を追加することもできる。終了した時点で完了ボタン７３５を押せば、入力されたデータに基づき、かつ、コンテンツプロバイダの仕様に従って、メタデータファイルを作成することができる。

図８は、スプレッドシートのレイアウトが開発者に提供されるような消費財ローダアプリケーションの例示的な実施形態を示す図である。このレイアウトによって、開発者は、複数の消費財のメタデータ値を容易に入力できるようになると同時に、すべての入力されたデータをすぐに見ることができるようになる。図示するとおり、開発者は、スプレッドシート８０５に記入することによって、複数の消費財についてのデータ値を入力することができる。あるいは、開発者は、インポートボタン８１０を用いることによって、すでに作成されているスプレッドシートからメタデータをインポートしてもよい。インポートボタン８１０は、開発者が、自社のコンピュータデバイス上の既存のスプレッドシートを選んで、消費財ローダアプリケーションのＧＵＩスプレッドシート８０５にインポートできるように構成されてもよい。スプレッドシートからメタデータをインポートすることに加えて、消費財ローダアプリケーションは、インポートされたスプレッドシートの中のフォーマットまたはメタデータフィールドと、消費財ローダアプリケーションの中に提供されたものとの間に何か不一致があった場合、それを開発者に通知してもよい。

また、本開示の範囲内にある実施形態には、コンピュータで実行可能な命令またはデータ構造を搬送または格納するための、有形の、および／または、非一時的なコンピュータ可読記憶媒体が含まれていることがある。そのような非一時的なコンピュータ可読記憶媒体は、汎用コンピュータまたは、上記で論じたいずれかの専用プロセッサの機能設計を含めて、専用コンピュータによってアクセスされうるいずれかの入手可能な媒体であってもよい。限定ではなく一例として、そのような非一時的コンピュータ可読媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭあるいはその他の光ディスク記憶デバイス、磁気ディスク記憶デバイスまたは他の磁気記憶デバイス、あるいは、コンピュータで実行可能な命令、データ構造、もしくはプロセッサチップ設計の形をした所望のプログラムコード手段を搬送または格納するのに用いられうるいずれかのその他の媒体が含まれてもよい。情報が、ネットワークまたはその他の（ハードワイヤード、ワイヤレス、またはその組み合わせのいずれかの）通信接続を経由してコンピュータに転送または提供される場合、コンピュータは当然、その接続をコンピュータ可読媒体とみなす。従って、いずれかのそのような接続は当然、コンピュータ可読媒体と呼ばれる。また、上記の組み合わせも、コンピュータ可読媒体の範囲内に含まれるべきである。

コンピュータで実行可能な命令には、例えば、汎用コンピュータ、専用コンピュータ、または専用処理デバイスに所定の機能もしくは機能のグループを実行させる命令およびデータが含まれる。また、コンピュータで実行可能な命令には、スタンドアロンまたはネットワーク環境にあるコンピュータによって実行されるプログラムモジュールも含まれる。一般に、プログラムモジュールには、特定のタスクを実行するかまたは特定の抽象データ型を実装するルーチン、プログラム、コンポーネント、データ構造、オブジェクト、および、専用プロセッサの設計に固有の機能等が含まれる。コンピュータで実行可能な命令、関連のデータ構造、およびプログラムモジュールは、本明細書で開示した方法のステップを実行するためのプログラムコード手段の例を表している。そのような実行可能な命令または関連のデータ構造の特定のシーケンスは、そのようなステップで記述された機能を実施するための対応する動作の例を表している。

当業者であれば、本開示のその他の実施形態が、パーソナルコンピュータ、手持ち式デバイス、マルチプロセッサシステム、マイクロプロセッサを利用した家電製品またはプログラマブル家電製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ等を含めて、多くのタイプのコンピュータシステム構成を持つネットワークコンピュータ環境で実施されうることは理解するであろう。また、実施形態は、通信ネットワークを通じて（ハードワイヤード接続、ワイヤレス接続、またはそれらの組み合わせによって）接続されるローカル処理デバイスおよびリモート処理デバイスによってタスクが実行されるような分散ネットワーク環境でも実施されうる。分散コンピュータ環境では、プログラムモジュールは、ローカルな記憶デバイスとリモートの記憶デバイスとの両方に位置することがある。

上記の各種の実施形態は、例示だけの目的で提供されたものであり、本開示の範囲を限定すると解釈されるべきではない。当業者であれば、本明細書に例示して記述した例示的な実施形態および応用例に従うことなく、かつ、本開示の趣旨と範囲とから逸脱することなく、本明細書に記述した原理に対して行われうる各種の修正および変更を容易に理解するであろう。

Claims (23)

1. コンピュータが実装する方法であって、
   ネットワークサーバコンピュータが、仕様に従って用意されていると共に複数の消費財を定義するメタデータ値の集合体を取り込むステップであって、前記消費財は、１以上のチャネルを介してユーザが入手可能なようにされ、また、前記サーバからのサポートを必要とする、ステップと、
   プロセッサを用いて、前記消費財に関係するサーバポリシーとの適合に関して、前記メタデータ値の集合体を検証するステップと、
   を備えることを特徴とする方法。
2. 前記プロセッサを用いて、前記仕様との適合に関して、前記メタデータ値の集合体を検証するステップ
   を更に備えることを特徴とする請求項１に記載の方法。
3. 前記仕様は、共通のメタデータ値を共有する複数の消費財をグループ化するファミリータグを定義する
   ことを特徴とする請求項１に記載の方法。
4. 前記サーバポリシーは、開発者とコンテンツプロバイダとの間の契約関係に基づく
   ことを特徴とする請求項１に記載の方法。
5. 前記仕様は、消費財に関連付けられたメタデータのタイムリミットを定義する間隔タグを定義する
   ことを特徴とする請求項１に記載の方法。
6. 前記メタデータ値の集合体は、消費財ローダアプリケーションにより、前記仕様に従って用意される
   ことを特徴とする請求項１に記載の方法。
7. 前記消費財ローダアプリケーションは、メタデータ値を入力するためのグラフィカルユーザインタフェースを提供する
   ことを特徴とする請求項６に記載の方法。
8. 前記消費財ローダアプリケーションのグラフィカルユーザインタフェースは、メタデータを入力するためのスプレッドシートスタイルのインタフェースを提供する
   ことを特徴とする請求項７に記載の方法。
9. 前記消費財ローダアプリケーションは、複数の消費財のメタデータ値を同時に修正することを可能にする
   ことを特徴とする請求項６に記載の方法。
10. 前記ネットワークサーバコンピュータにおいて、データフィードを介して、前記仕様に従って用意された前記メタデータ値の集合体を受信するステップ
    を更に備えることを特徴とする請求項１に記載の方法。
11. 前記データフィードは、ＸＭＬデータフィードである
    ことを特徴とする請求項１０に記載の方法。
12. 前記取り込まれた、仕様に従って用意されたメタデータ値の集合体を公表するステップ
    を更に備えることを特徴とする請求項１に記載の方法。
13. 前記ネットワークサーバコンピュータが、前記取り込まれた、仕様に従って用意されたメタデータ値の集合体を、開発者のコンピュータデバイスへ送信するステップ
    を更に備えることを特徴とする請求項１に記載の方法。
14. 仕様に従って用意されていると共に複数の消費財を定義するメタデータ値の集合体を取り込むように構成されたネットワークサーバコンピュータであって、前記消費財は、１以上のチャネルを介してユーザが入手可能なようにされ、また、前記サーバからのサポートを必要とする、ネットワークサーバコンピュータと、
    前記仕様に従って用意された前記メタデータ値の集合体を送信するように構成された、前記ネットワークサーバコンピュータと電気通信する開発者コンピュータと、
    前記消費財に関係するサーバポリシーとの適合に関して、前記メタデータ値の集合体を検証するように構成された検証モジュールと、
    を備えることを特徴とするシステム。
15. 前記検証モジュールは、前記メタデータ値の提示のためのフォーマットを定義する前記仕様との適合に関して、前記メタデータ値の集合体を検証するように更に構成される
    ことを特徴とする請求項１４に記載のシステム。
16. 前記サーバポリシーは、開発者とコンテンツプロバイダとの間の契約関係に基づく
    ことを特徴とする請求項１４に記載のシステム。
17. 前記検証されたメタデータ値により定義される前記消費財を、前記ネットワークサーバコンピュータに対して公表するように構成された公表モジュール
    を更に備えることを特徴とする請求項１４に記載のシステム。
18. アプリケーションを実行するように構成されたネットワークユーザデバイスを更に備え、
    前記アプリケーションは、それ自身が、公表された消費財を前記ネットワークユーザデバイス上で提示するために、前記ネットワークサーバコンピュータ上の前記公表された消費財にアクセスするように構成される
    ことを特徴とする請求項１４に記載のシステム。
19. コンピュータ可読命令が記録されたコンピュータ可読媒体であって、前記コンピュータ可読命令は、コンピュータに、
    ネットワークサーバコンピュータが、仕様に従って用意されていると共に複数の消費財を定義するメタデータ値の集合体を取り込むステップであって、前記消費財は、１以上のチャネルを介してユーザが入手可能なようにされ、また、前記サーバからのサポートを必要とする、ステップと、
    プロセッサを用いて、前記消費財に関係するサーバポリシーとの適合に関して、前記メタデータ値の集合体を検証するステップと、
    を実行させることを特徴とするコンピュータ可読媒体。
20. 前記サーバポリシーは、開発者とコンテンツプロバイダとの間の契約関係に基づく
    ことを特徴とする請求項１９に記載のコンピュータ可読媒体。
21. 前記検証されたメタデータ値により定義される前記消費財を、前記ネットワークサーバコンピュータに対して公表するステップ
    を更に備えることを特徴とする請求項１９に記載のコンピュータ可読媒体。
22. 仕様に従って用意されていると共に複数の消費財を定義するメタデータ値の集合体を取り込むように構成されたネットワークインタフェースであって、前記消費財は、１以上のチャネルを介してユーザが入手可能なようにされ、また、前記サーバからのサポートを必要とする、ネットワークインタフェースと、
    前記消費財に関係するサーバポリシーとの適合に関して、前記メタデータ値の集合体を検証するように構成されたプロセッサと、
    を備えることを特徴とするデバイス。
23. 前記検証されたメタデータにより定義される前記消費財を格納するように構成されたストレージデバイスを更に備え、
    前記ストレージデバイスは、前記ネットワークインタフェースを介して消費者デバイスにアクセス可能なように構成され、これにより、前記消費財は、ユーザデバイス上で実行されるアプリケーションが入手可能なようにされる
    ことを特徴とする請求項２２に記載のデバイス。

Images