JP2009535735A - コンテンツ・マネージメント・システムおよび方法 - Google Patents

Abstract

コンテンツのランタイム・ステートの外部的な保存を伴うコンテンツ・マネージメントのための技術。この技術にしたがって形成されるシステムは、プレイバック・デバイスからコンテンツのランタイム・ステートを受信するサーバを備え、リクエストに応じてそれにあるいは別のプレイバック・デバイスにランタイム・ステートを提供する。この技術にしたがって構成されたプレイバック・デバイスは、プレイバック・デバイスに対して外部的に以前保存されたランタイム・ステートを復活させるためのコンテンツ・ステート・リカバリー・エンジンを備えるかもしれない。この技術にしたがった方法は、ランタイム・ステートをローカルに生成し、ランタイム・ステートを外部的に保存し、ランタイム・ステートを再取得する。

Description

モバイル・デバイスや記憶容量が限られたその他のデバイスでは、そのデバイスのユーザが望む量のデータを記憶できない。このようなデバイスのユーザは、そのデバイスに見合うよりも大きいコンテンツを利用するライセンスを所有しているかもしれない。コンテンツがオンラインで購入される場合、デバイスの容量はユーザがダウンロードを望んでいるであろうコンテンツの量に直接影響を与えることから、これは更にやっかいになる可能性がある。更に、ユーザは、ユーザ、および／またはライセンスされたコンテンツと関連付けられ、不揮発性のデバイスに記憶される必要のある何らかのコンテンツを生成するかもしれない。このユーザ生成コンテンツには、ゲームの進行状態、達成度、資産、個人情報などが含まれ得る。

あるアプリケーションでは、ユーザはタイトル（あるいはそのアイデンティティ）を指定することによりコンテンツをリクエストし、サーバは、コンテンツと生成されたユーザライセンスとを提供することで応答する。言い換えれば、コンテンツとユーザ生成データは、ステートや将来このコンテンツを実行あるいは利用する能力が失われるリスクがない状態で破棄できないかもしれない。

ユーザがコンテンツを破棄するとき、コンテンツと関連付けられたステートもまた一般に破棄される。ある場合には、コンテンツあるいは多数の異なるコンテンツのためのステートは、比較的大きなスペースを取り（コンテンツが破棄されたときにステートを保存できたとしても）新たなコンテンツおよび新たなコンテンツに関連付けられる任意のステートのための場所を確保するためにステートを破棄することが望ましいかもしれない。ステートが破棄されると、ユーザがコンテンツに対するライセンスを保持し、そのコンテンツを再び後でダウンロードしてもそれは失われる。ユーザの資産（購入されたコンテンツとステート）のストレージおよびリトリーバルにとって柔軟なメカニズムを持つことは有益である。

上述された関連技術の例とそれに関連した制限は、例示であって他を排除するものではない。関連技術の他の制限は、明細書を読み、図面を検討することで当業者にとって明らかとなる。

以下の実施形態とそれらの目的は、代表例、例示を意図したシステム、ツール、方法と組み合わせて記述され説明されるもので、範囲を限定するものではない。様々な実施形態において、上述の問題は軽減されあるいは除去されるが、他の実施形態は別の改良に向けられている。

ユーザの資産（アセット）に対する柔軟なマネージメントのためのメカニズムを提供するバーチャル・ボールトに関係する技術が説明される。この技術は、ユーザをその資産に関連付けるためのｅ−チケットと呼ばれるデータ構造の利用に関する（購入されたタイトルとユーザ生成ステート・ファイル）。これはユーザに対して、例えばローカルなストレージ・デバイスの容量を節約するためにタイトルのコンテンツを破棄しながらも、タイトルに対するライセンスを維持することを可能にする。タイトルは、例えばタイトルＩＤと関連付けられ、これによりタイトル・コンテンツは後で、タイトルＩＤをインデックスとして用いることにより「バーチャル・ボールト」から復元することができる。同様に、任意のステート・ファイル、例えばゲーム保存データは、ｅ−チケットを用いてリトリーブすることができる。

特に、もしコンテンツの安全性が高く、ｅ−チケットが署名されたデータ構造であるのであれば、ボールト・サービスは第三者によって提供されてもよい。復元技術の例には、例えばタイトルＩＤを、コンテンツをユーザのために復活させるのに利用できるロケーション／ダウンロード・プロトコル（例えばＵＲＬ）に変換するサービスを提供するものが含まれる。

好ましくは、タイトルは、ユーザがタイトルを利用すると生成されるアプリケーション保存データ、あるいはランタイム・ステートを有するかもしれない。バーチャル・ボールト・サービス・プロバイダは、タイトルが破棄されたときにステートがアップロードされるようにサービスを提供することができる。タイトル、ユーザかつ／またはデバイスとコンテンツの間の結合を含んだタイトルに対するライセンスを参照することにより、ステートは、タイトル・コンテンツが復活されたときに復活できる。

本発明の実施形態は、図面に示される。しかし、実施形態と図面は、限定的なものではなく例示的なもので、それらは本発明を例示するものである。

以下の説明では、本発明の実施形態の十分な理解を与えるために幾つかの特定の具体的な構成が提示される。しかし、当業者であれば、１つ以上のこれら特定の具体的な構成がなくとも、あるいは他の構成部などとの組み合わせなどにより、本発明を実施することが可能であることが理解されるであろう。また別の例では、様々な実施形態における本発明の側面を覆い隠すことがないように、周知の具体的構成は、図示または詳細に説明されていない。

図１Ａおよび図１Ｂは、バーチャル・ボールトを含むシステム１００の一例を示す。図１Ａの例では、システム１００はサーバ１０２、プラットホーム１０４、ボールト１０６を含む。サーバ１０２、プラットホーム１０４、そしてボールト１０６は、ネットワーク１０８を介して互いに連結される。図１Ａは、初期の段階（プラットホーム１０４がサーバ１０２から１つのタイトルに対してライセンスを得たとき）を示すことを意図し、図１Ｂは、もっと後の段階（プラットホーム１０４が複数のタイトルに対して多数のライセンスを持ち、ボールト１０６がこれらのライセンスに関連付けられたコンテンツを含むとき）を示すことを意図している。なお、ボールトは、サーバから物理的に独立したコンテンツ・ストレージを持たないかもしれない。それは、プラットホームのユーザが、ある複数のタイトルの権利を取得し、それらをリトリーブすることができるという事実のバーチャルな表現である。タイトル・コンテンツは、ユーザの大きな集団の間で共有されることから一度だけ保存されればよい。

図１Ａの例では、サーバ１０２は複数のタイトルＩＤ１１０−１〜１１０−Ｎ（集合的にはＩＤ１１０として参照される）、複数のタイトル１１２−１〜１１２−Ｎ（集合的にはタイトル１１２として参照される）、複数のコンテンツ１１４−１〜１１４−Ｎ（集合的にはコンテンツ１１４として参照される）を有する。コンテンツ１１４には、周知のあるいは手頃などのような電子コンテンツが含まれてもよく、限定されるものではないが、ムービ、ミュージック、ゲーム、プログラム、オブジェクト、データ、ＵＲＬなどが含まれる。１つのタイトルＩＤ（例えば、タイトルＩＤ１１０−１）、タイトル（例えば、タイトル１１２−１）、そしてコンテンツ（例えば、１１４−１）は、タイトルやタイトルＩＤと関連付けられたレコードとして参照される。レコードは、サーバ１０２のデータベースに存在するものとして参照されるかもしれない。サーバ１０２は、図示されない、様々なコンポーネントを含み、限定的ではないが、プロセッサ、コミュニケーション・インターフェース、入出力コントローラおよび／または装置、ディスプレイ装置、メモリ、不揮発性ストレージなどが含まれる。

図１Ａの例では、プラットホーム１０４は、タイトル１１２−１、コンテンツ１１４−１、そしてＥ−チケット１１６−１を含む。Ｅ−チケット１１６−１は、タイトルＩＤ１１０−１とユーザのアイデンティフィケーションかつ／またはユーザのデバイスを含む。タイトル１１２−１は、図１Ａでは、関係を表すことを意図した線でＥ−チケット１１６−１に連結されて描かれている。同様に、コンテンツ１１４−１は、図１Ａでは、関係を表すことを意図した線でＥ−チケット１１６−１に連結されて描かれている。タイトルＩＤ１１０−１、タイトル１１２−１、そしてコンテンツ１１４−１は、サーバ１０２のデータベースからのレコードと仮定される。なお、別の実施形態では、プラットホームのタイトルまたはコンテンツは、サーバのデータベース内のレコードとは僅かに、顕著に、あるいは完全に違っているかもしれない。しかし、説明の便宜上、図１Ａの例ではそれらは同じであると仮定される。

プラットホーム１０４は、限定的ではないが、コンテンツを記憶するキャッシュ、メモリ、あるいはストレージを備えるモバイル・デバイス、ゲーム・コンソール、ＰＤＡ、携帯電話、スマートフォン、コンピュータ、家電や、他の電子装置を含む様々な装置のいかなるものであってもよい。例えば、Ｅ−チケットは、周知のあるいは手頃な、任意の電子コンテンツに対するライセンスである。Ｅ−チケットは、例えばプラットホーム１０４に関連付けられたユーザがサーバ１０２のエージェントとのトランザクションを開始すると（あるいはエージェントが、少なくともサーバ１０２にあるデータベースの一部とアフィリエートすると）取得される。

ある実施形態では、Ｅ−チケットはタイトルのためのものであり、またこのタイトルと関連付けられたコンテンツのためのものである。ある実施形態ではタイトルとコンテンツは共通のそして少なくともある程度一意的なタイトルＩＤによってリンクされた状態に維持されるが、好都合なことに、Ｅ−チケットが、タイトルとコンテンツ双方のためのものであることから、タイトルとコンテンツは分離できる。Ｅ−チケットがタイトルとコンテンツ双方のものであることから、ユーザは、例えば制限された容量のローカルなストレージ・デバイスにおける容量を節約するためにコンテンツをはきすることができるかもしれない。Ｅ−チケットは、プラットホーム１０４に残すことができるため、非限定的な実施形態において、タイトルＩＤをインデックスとして用い、コンテンツをボールト１０６から後で復活させることができる。

ボールトは、ストレージとシステムにおけるユーザへのリトリーバル・サービスを提供できるエンティティ（実体）である。ボールトは、ユーザからの入力を処理する能力があってもよく、ルールのセットを適用し、出力を配信し、かつ／または入力さらたコンテンツあるいはデータを受信する。図１Ａの例では、ボールト１０６は、タイトルＩＤ１１０−１とコンテンツ１１４−１を有する。別の実施形態では、ボールト１０６は、タイトルＩＤ１１０−１と関連付けられた全レコードを有していてもよい。図１Ａの例では、サーバ１０２、プラットホーム１０４、そしてボールト１０６は、互いに離れて配置される。しかし、別の実施形態では、ボールト１０６とサーバ１０２は、互いにローカルに配置されていてもよい。

様々な実施形態や実装において、サーバ１０２は、プラットホーム１０４がＥ−チケット１１６−１を取得するトランザクションの前、その間、あるいはその後で、コンテンツ１１４−１をボールト１０６に提供してもよい。代わりに、プラットホーム１０４が、プラットホームがＥ−チケット１１６−１を取得するトランザクションの前、その間、あるいはその後で、コンテンツ１１４−１をボールト１０６に提供してもよい。代わりに、ボールトはコンテンツを保存せず、別のサーバ内におけるコンテンツのロケーションを単に参照するだけでもよい。意図された目的に役立つ任意の手頃な設備計画や実装が構想される。

図１Ｂの例では、システム１００は、プラットホーム１０４とボールト１０６を備える（サーバ１０２とネットワーク１０８は図示されていない）。図１Ｂの例では、ボールト１０６は、複数のタイトルＩＤ１１０とコンテンツ１１４を有する。なお、タイトルＩＤ１１０とコンテンツ１１４の一部がボールト１０６に保存されていてもよく、いくつかのタイトルＩＤとコンテンツがサーバ１０２以外の複数のソースからのものであってもよい。タイトルＩＤが十分に一意的である限り、レコードは、どのような数のコンテンツソースからのものであってもよい。

図１Ｂの例では、プラットホーム１０４はタイトル１１２、複数のＥ−チケット１１６−１〜１１６−Ｎ（集合的にはＥ−チケット１１６として参照される）、そして説明の便宜上、コンテンツ１１４−２を備える。

図１Ａから図１Ｂへの動作において、プラットホーム１０４は、コンテンツ１１４にとって周知のあるいは手頃な方法でＥ−チケット１１６を取得する。しかし、プラットホーム１０４は、Ｅ−チケット１１６と関連付けられたコンテンツをある理由から破棄する。例えば、プラットホーム１０４は、ユーザがプラットホーム１０４に明示的にコンテンツを破棄するように指示したことによりコンテンツを破棄するかもしれないし、プラットホーム１０４が一杯のときにコンテンツが破棄されるかもしれず（例えば利用可能なストレージがないとき）、ある期間に利用されなかった場合にコンテンツが破棄されるかもしれず、またある他の理由によりコンテンツは破棄されるかもしれない。

説明に有益なある実施形態では、サーバは、ステートを認証してそのユーザを確認し、かつ／または、リクエストされた「ストレージ／リトリーバル」サービスを提供するために暗号署名されたステートを用いるかもしれない。

理由に関わらず、プラットホーム１０４はついには、説明の便宜上、タイトルＩＤ１１０−２と関連付けられたレコードのコンテンツのみを有する。一方でボールト１０６は、破棄された全てのコンテンツ１１４のレコードを記憶しておく。図１Ｂの例では、ボールト１０６は、破棄されなかったコンテンツ１１４−２と関連付けられたレコードも有する。非限定的な実施形態では、ボールト１０６は、プラットホーム１０４（また実施状況によっては他のプラットホーム）がライセンスを持つ全てのコンテンツ１１４のレコードを有する。

一例として、プラットホーム１０４がコンテンツ１１４−１をボールト１０６から取得しに行くことを仮定する。プラットホーム１０４が十分なストレージを持たないときには、プラットホーム１０４はコンテンツ１１４−２を破棄する。ストレージが十分なときには、プラットホーム１０４は、コンテンツ１１４−２を破棄してもしなくともよい。プラットホーム１０４は、Ｅ−チケット１１６−１をボールト１０６に提供することができる。ボールト１０６は、限定的ではなく例示的に、Ｅ−チケット１１６−１に含まれるタイトルＩＤ１１０−１を、プラットホーム１０４にコンテンツ１１４−１を復活させるのに利用できるロケーションあるいはダウンロード・プロトコル（例えばＵＲＬ）へとトランスレート可能なサービスを含んでいてもよい。

ある実施形態では、ボールト１０６はサービスを提供する第三者によって管理されるかもしれない。更に、もしコンテンツ１１４が暗号化あるいはその他の方法で保護されている場合、第三者はコンテンツを復号あるいは保護を解除する能力さえも備えている必要がない。この場合、プラットホーム１０４は、１つ以上のＥ−チケット１１６と関連付けられたキーなど、コンテンツ１１４を復号するある手段を備えているであろう。

与えられたレコードは、ボールト１０６に保存されたそれと関連付けられたステートを備えるかもしれない。タイトルと関連付けられたコンテンツが破棄されると、プラットホーム１０４は、例えばボールト１０６に情報を提供し、タイトルと関連付けられたステートをアップデートする。ステートは、コンテンツがプラットホーム１０４へ後で提供されたときに更にアップデートされる。具体的な実施や実施形態にしたがって、ステートはコンテンツが保存あるいはリトリーブされたかに関わらずアップデートされてもよいし、されなくともよい。

図２は、コンテンツ・マネージメント・システム２００の一例を示す。システム２００は、ライセンス・サーバ２０２、コンテンツ・サーバ２０４、ステート・サーバ２０６、プレイバック・デバイス２０８、ネットワーク２１０を備える。どのコンポーネントも相互に離れて配置されてもよいし、ローカルに、あるいは１つ以上の他のコンポーネントに対しては相対的にローカルに配置されてもよい。

図２の例では、ライセンス・サーバ２０２は、コンピュータが読み取り可能な媒体に実装される。ライセンス・サーバ２０２には、例えば、ハードウェア、ソフトウェア、ファームウェア、あるいはそれらの組み合わせが含まれる。名前が示すように、ライセンス・サーバ２０２は、プレイバック・デバイス２０８などのデバイスにライセンスを与える。説明に有益な実施形態では、ライセンスは、ネットワーク２１０を通してリクエストを行っているデバイスへと提供される。また代わりに、ライセンス・サーバ２０２が、ライセンスのリクエストを行っていないデバイスにプッシュされてもよい。別の例としては、ライセンス・サーバ２０２が、ライセンスをローカルに維持し、このライセンスのコピーを送る代わりにこのライセンスに関連したパーミッションを与えてもよい。

以下においては、パーミッションの用語は、ライセンス、ライセンスの一部、あるいは、ライセンスに関連付けられたコンテンツの権利を取得するのに使用できるライセンスに関連付けられたルールを含むものとする。ライセンス・サーバ２０２がパーミッションを送信するとき、パーミッションはＥ−チケットにエンカプセレートされていてもよい。パーミッションに加えてＥ−チケットは、パーミッションに関連付けられたコンテンツのタイトルＩＤなどのデータを含んでいてもよい。

非限定的な実施形態では、Ｅ−チケットはコンテンツのユーセッジを管理できる。例えば、Ｅ−チケットは、限定されるものではないが、コンテンツの利用に設けられた制限を含むコンテンツのユーセッジ・ルールを含むことができる。一般に、Ｅ−チケットは、Ｅ−チケットによって許可された権利に従うコンテンツを利用するプレイバック・デバイス２０８にとって十分な情報、そして場合によってはコンテンツを認証できる情報が記述されている。各Ｅ−チケットは、タイトルＩＤなどの１つ以上のコンテンツ・エレメントと関連付けられたデータ構造を備えていてもよい。Ｅ−チケットは、（１）ライセンスにアクセスしたときにセキュア・プロセッサがコンテンツにアクセスできるという効果をもつコンテンツのための暗号化キーと、（２）ライセンスが簡単に変造されず有効に維持されるという効果がもつデジタルシグネチャあるいはセキュア・ハッシュ値を含む暗号技術を提供することもできる。Ｅ−チケットは、ライセンスがコンテンツに関するライセンシーに許可する権利の説明を含んでもよい。Ｅ−チケットは、許可が与えられた個々の受領者すなわちユーザ毎に、またユーザが許可されたプレイバック・デバイスに対して個別に仕立てられてもよい。

ライセンス・サーバ２０２は、相対的にローカルなライセンス・ジェネレータを備えていても、いなくともよい。ライセンス・ジェネレータは、プレイバック・デバイスのユーザのユーセッジ・ルールや、個人情報、ＵＩＤ情報、ユーザ・サブスクリプション、ユーザに設けられた制限などのユーザ情報を含んでいてもよい。ライセンス・ジェネレータは、コンテンツ・データベース２０４からリトリーブされたコンテンツに関連付けられたタイトルＩＤも取得するかもしれない。

図２の例では、コンテンツ・サーバ２０４は、コンピュータが読み取り可能な媒体に実装される。コンテンツ・サーバ２０４には、例えばハードウェア、ソフトウェア、ファームウェア、あるいはこれらいくつかの組み合わせが含まれる。名前が示すように、コンテンツ・サーバ２０４は、プレイバック・デバイス２０８などのデバイスにコンテンツを提供する。説明に有益な実施形態では、コンテンツはネットワーク２１０を介してリクエストを行っているデバイスに供給される。実施の具体的な形態によっては、コンテンツ・サーバ２０４は、ライセンスを必要としないコンテンツを提供できるが、説明の便宜上この説明では、コンテンツ・サーバ２０４によって提供されるコンテンツは、ライセンス・サーバ２０２によって生成されるライセンスに関連付けられている。

一般に、コンテンツ・サーバ２０４内のコンテンツは、周知のあるいは手頃などのような電子コンテンツを保存していてもよく、限定されるものではないが、ムービ、ミュージック、プログラム、アプリケーション・ソフトウェア、オーディオ／ビデオ・プレゼンテーション、データベース、教育プログラム、ゲームや教育ゲーム、メディアやマルチメディア・コンテンツ、ティーチング・マテリアル、オブジェクト、データ、ＵＲＬ、あるいはそれらの手頃な組み合わせや発生物などが含まれる。コンテンツは、ディレクトリ構造の中のファイルに、ストリーミング用のブロックとして、あるいは他の周知のあるいは手頃な何らかの方法で保存されている。コンテンツは、実行されるかインタープリート（コードあるいはインストラクションに対して）され、あるいは表示あるいは上映される（メディア・コンテンツに対して）。ここで使用される、実行されるあるいは作動されるの用語は、コンテンツのあらゆる利用を含む。

図２の例では、ステート・サーバ２０６は、コンピュータが読み取り可能な媒体に実装される。ステート・サーバ２０６としては、ハードウェア、ソフトウェア、ファイアウェア、あるいはこれらの何れかの組み合わせが含まれる。説明に有益な実施形態では、ステート・サーバ２０６は、ステートに対するストレージ／リトリーバル機能をサービスとして提供する。ステートには、アプリケーション・セーブ・データが含まれてもよい。

ステート・サーバ２０６は、プレイバック・デバイス２０８などのデバイスに対するコンテンツ・ステート情報を提供する。説明に有益な実施形態では、情報はネットワーク２１０を通してリクエストを行っているデバイスに提供される。一般的には、ステート・サーバ２０６は、始めにプレイバック・デバイス２０８からステート情報を受け取り、後でリトリーブされる。しかし、プレイバック・デバイス２０８は、プレイバック・デバイス２０８が必要なパーミッションを有するときには、別のデバイス（図示せず）により提供される情報をリクエストできるであろう。あるいは、ステート・サーバ２０６は、プレイバック・デバイス２０８がリクエストするかもしれない予め構成されたステートを保存できる。

図２の例では、プレイバック・デバイス２０８は、限定されるものではないが、モバイル・デバイス、ゲーム・コンソール、パーソナル・デジタル・アシスタント（ＰＤＡ）、携帯電話、スマートフォン、コンピュータ、家電、コンピュータ読み取り可能な媒体を含むポータブルあるいはその他のデバイスを含む様々なデバイスの如何なるものであってもよい。このようなデバイスは、様々なコンポーネント（図示せず）を備えていてもよく、限定されるものではないが、プロセッサ、メモリ、不揮発性記憶装置、入出力コントローラやデバイス、ディスプレイ、かつ／またはその他の周知のあるいは手頃なコンポーネントなどが含まれる。

作動中、プレイバック・デバイス２０８は、ライセンス・サーバ２０２からネットワーク２１０を通してＥ−チケットを取得する。ライセンス・サーバ２０２は、プレイバック・デバイス２０８（すなわちプル）からのリクエストに応じてＥ−チケットを提供してもよく、あるいはライセンス・サーバ２０２は、プレイバック・デバイス２０８にＥ−チケットをプッシュする。Ｅ−チケットをプッシュするには、プレイバック・デバイス２０８は一般的に予め認証（プレアプルーブ）されている必要があり、これはプレイバック・デバイス２０８のためにＥ−チケットを取得するある他のデバイス（図示せず）によって達成されるかもしれず、あるいはライセンス・データは人またはライセンス・サーバ２０２におけるアーティフィシャル・エージェントによって直接入力されてもよい。Ｅ−チケットはコンテンツと同時に、またはコンテンツがプレイバック・デバイス２０８において既に受信された後であっても提供され得るが、説明の便宜上、ここで与えられるある説明では、Ｅ−チケットはコンテンツのリクエストの前に取得される。

作動中、プレイバック・デバイス２０８は、コンテンツ・サーバ２０４からコンテンツを取得する。コンテンツ・サーバ２０４は、例えばプレイバック・デバイス２０８からのリクエストに応答してコンテンツを提供する。コンテンツ・サーバ２０４は、コンテンツの提供に先立ってプレイバック・デバイス２０８がコンテンツを実行するパーミッションを備えていることを要求するかもしれないし、しないかもしれない。例えば、プレイバック・デバイス２０８が、コンテンツをダウンロードできる保証されたプレイバック・デバイスであっても、プレイバック・デバイスがパーミッションを備えるまでコンテンツを再生できない。これは、限定的ではなく例示的に、デモソフトをプレイバック・デバイス２０８に提供するときに有用であろう。プレイバック・デバイス２０８のユーザが、このデモを気に入れば、追加的なコンテンツのダウンロードを行うことなく、このソフトウェアの付加的な機能（例えば有料）を「アンロック」するパーミッションを取得することができる。別の例としては、特定の条件が合えば追加的なコンテンツに対するパーミッションを条件付ライセンスが与えることができる。以下では、説明を簡便なものとするため、プレイバック・デバイス２０８にダウンロードされたプレイバック・デバイス２０８がパーミッションを有するコンテンツの場合についてのみ論じる（プレイバック・デバイス２０８はダウンロードされた全てのコンテンツに対するパーミッションをもつとは限らず、パーミッションも条件的であるかもしれないが）。

作動中、プレイバック・デバイス２０８は、コンテンツを実行する。コンテンツが実行されると、例えばランタイム・ステートが生成される。ランタイム・ステートとしては、再生の遅延や実行される回数など、条件付ライセンスで利用される単純なデータ以上のものが意図される。むしろ、プレイバック・デバイス２０８がパーミッションを有するコンテンツに対する最初のランタイム・ステートは、同じコンテンツに対する２回目のランタイム・ステータスとは異なるエクスペリエンスとなる。ランタイム・ステートの一例は、ゲームのどのレベルにまで達したか、ロール・プレイング・ゲームにおけるアバターのポゼッション、あるいはアドベンチャ・ゲームにおける金貨の獲得数である。

作動中、コンテンツは、プレイバック・デバイス２０８から削除されるかもしれない。コンテンツが削除される前、あるいは同時に、または後で、プレイバック・デバイス２０８はコンテンツと関連付けられたステート（例えば、ゲーム保存データ）をステート・サーバ２０６に送信する。したがって、コンテンツとコンテンツ・ステートは、例えば、プレイバック・デバイス２０８におけるストレージ容量を増大するため、デバイスから削除することができる。コンテンツに関連付けられたＥ−チケットは、プレイバック・デバイス２０８から削除されない。Ｅ−チケットは、プレイバック・デバイス２０８が、削除されたコンテンツをコンテンツ・サーバ２０４（あるいは別のコンテンツ・サーバ）からリカバーすることを可能にする。好ましくは、Ｅ−チケットは、ランタイム・ステートをステート・サーバ２０６からリカバーすることを可能にする。

また別の実施形態では、プレイバック・デバイス２０８は、Ｅ−チケットをも削除できる。そのような実施形態では、プレイバック・デバイス２０８がライセンスをリカバーするための何らかの方法が必要である。これは、限定的ではなく例示的に、ライセンス・サーバ２０２（あるいは別のＥ−チケット・サーバ）から新しいＥ−チケットを得るためにプレイバック・デバイス２０８のユーザがパスワードを入力することを要求するなど、周知のあるいは手頃などのような方法でも実現することができる。Ｅ−チケットをリカバーした後で、プレイバック・デバイス２０８は、コンテンツと、コンテンツに関連付けられたランタイム・ステートとを、前述したようにリカバーすることができる。

図３は、コンテンツ・マネージメント・システム２００（図２）に適当なフロー・ダイアグラムの一例を示す。説明の便宜上、図３の例における矢印は、コンポーネント間の時間を渡った様々なトランザクションを示す。矢印は時間的なポジションを示すために番号が振られているが、トランザクションの順番は変更することができ、また描かれたフローの外側で１つ以上のトランザクションを実行することもできる。

図３の例では、第１のトランザクション（トランザクション１）では、ライセンス・サーバ３０２は、Ｅ−チケットをプレイバック・デバイス３０８に与える。Ｅ−チケットは、リクエスト（例えば、プル・トランザクションにおいて）に応じて提供されるかもしれないし、プッシュされるかもしれない。Ｅ−チケットは、コンテンツ・サーバ３０４に保存されたコンテンツに対するパーミッション；ユーザやプレイバック・デバイス３０８、あるいは両者に関連付けられたユニーク・アイデンディファイア（ＵＩＤ）；タイトル；タイトルＩＤ；コンテンツ・サイズ；かつ／または、他の実装または実施形態に特有なデータを含み得る。

図３の例では、トランザクション２において、プレイバック・デバイス３０８は、リクエスト（パーミッションを含む）をコンテンツ・サーバ３０４へと送信する。プレイバック・デバイスは、Ｅ−チケットのコピーや、コンテンツに対し権利を有することを証明するためのＥ−チケットからの情報の一部（サブセット）など、付加的なパーミッション情報をリクエストとともに送信するかもしれない。

図３の例では、オプショナルなトランザクション３において、コンテンツ・サーバ１０４はライセンス・サーバ３０２にクエリーを行う。もし、プレイバック・デバイス１０８からのパーミッションが、コンテンツに対しプレイバック・デバイス３０８がライセンスを持つことを証明するのに十分な情報を含んでいないときには、コンテンツ・サーバ３０４は、ライセンス・サーバ３０２にオプショナルなクエリーを行うかもしれない。クエリーは、プレイバック・デバイス３０８が実際にコンテンツを受領するパーミッションをもつか否かを判定するためにパーミッション・データを利用するかもしれない。

図３の例では、トランザクション４において、コンテンツ・サーバ３０４はプレイバック・デバイス３０８からのリクエストに応答して、コンテンツをプレイバック・デバイス３０８に提供する。コンテンツの受領後のある時点で、プレイバック・デバイス３０８は、トランザクション５においてコンテンツを実行し、ランタイム・ステートを生成する。

図３の例では、トランザクション６において、プレイバック・デバイス３０８はコンテンツに関連付けられたランタイム・ステートをステート・サーバ３０６に提供する。プレイバック・デバイス３０８は、ステート・サーバ３０６が保存されたステートを提供するように、プレイバック・デバイス３０８が後でリクエストするかもしれない十分なアイデンティファイング情報をも提供してもよい。プレイバック・デバイス３０８が、ランタイム・ステートを提供する時点は、実装、実施形態に特有の誘因（stimuli）や、ユーザの好みに応じて変化し得る。例えば、プレイバック・デバイス３０８は、毎晩真夜中に、あるいは、ランタイム・ステートが関連付けられたコンテンツが削除されたときに、ランタイム・ステートを送るように構成されていてもよい。サーバは、それに認証するためにステート・データの暗号化シグネチャをチェックするように構成されていてもよい。信頼性（オーセンティシティ）は、サーバにとって利用可能とされたデバイス認証（デバイス・サーティフィケート）を用いてチェックされる。デバイス認証には、ステートとコンテンツを所有するものにリクエストを行うユーザを結び付けるアイデンティティが含まれてもよい。

図３の例では、トランザクション７において、ランタイム・ステートがプレイバック・デバイス３０８において削除される。なお、コンテンツは、コンテンツ・ステートが削除される前に、または同時に、あるいは後で削除され得る；あるいは、コンテンツは全く削除されない。更に、ランタイム・ステートは削除される必要は必ずしもない。例えば、プレイバック・デバイス３０８は、現在のランタイム・ステートがより最近のものであっても、古いランタイム・ステートをリクエストすることもできる。

図３の例では、トランザクション８において、プレイバック・デバイス３０８は、ステート・サーバ３０６にパーミッションを提供する。パーミッションは、トランザクション２においてコンテンツ・サーバ３０４に送られたものと同じであるかもしれないし、そうでないかもしれない。コンテンツ・サーバ３０４に、より高いセキュリティ手段が実装され、ステート・サーバ３０６よりもより安全なパーミッションを要求されることが考えられる。それにも係わらず、ステート・サーバ３０６は、オプショナルなトランザクション９において、パーミッションをベリファイするようにライセンス・サーバ３０６に対してなおクエリーするかもしれない。最後に、トランザクション１０において、ステート・サーバ３０６は、プレイバック・デバイス３０８にステートを提供する。

図４は、コンテンツ・ステート・リカバリー・エンジンプを備えるプレイバック・デバイス４００の一例を示す。プレイバック・デバイス４００は、インタフェース４０２、Ｅ−チケット・データベース（ｄＢ）４０４、コンテンツｄＢ４０６、コンテンツ・ステートｄＢ４０８、コンテンツ・ステート・リカバリー・エンジン４１０、各コンポーネントが連結されたバス４２０を備える。なお、バスの構成は、単なるコンピュータシステムにおける電子的な実装の１周知例に過ぎず、周知のあるいは手頃などのような実装がバスの構成の代わりに用いられてもよい。

インタフェース４０２は、周知のあるいは手頃な方法で、コミュニケーション・ネットワークあるいは外部デバイスと通信するのに用いられるであろう。Ｅ−チケットｄＢ４０４への保存のために、Ｅ−チケットは例えばインタフェース４０２で受信される。同様に、コンテンツはコンテンツｄＢ４０６への保存のために、例えばインタフェース４０２において受信される。説明に有益な実施形態では、ランタイム・ステートがプレイバック・デバイス４００においてローカルに生成されたか、かつ／または、外部ステート・データベースから復元されたか否かで、コンテンツと関連付けられたランタイム・ステートがコンテンツ・ステートｄＢに含まれる。コンテンツ・ステート・リカバリー・エンジン４１０は、プレイバック・デバイス４００のためにステートを復元する。コンテンツ・ステート・リカバリー・エンジン４１０は、インタフェース４０２にステートを送信する役目も負う（外部へのストレージおよび後での復元のため）。

図５は、限られたストレージ容量のプレイバック・デバイスを含むネットワークにサーバがコンテンツを配信可能な方法の一例のフローチャート５００を示す。フローチャート５００は、モジュール５０２から開始され、コンテンツに対するリクエストが受信される。

図５の例では、フローチャート５００はモジュール５０４へと続き、プレイバック・デバイスに関連付けられた情報が取得される。情報には、例えば、プレイバック・デバイスの利用可能なストレージ容量が含まれてもよい。フローチャート５００は、モジュール５０６へと続き、コンテンツに関連付けられた情報が取得される。情報には例えばコンテンツに必要とされるストレージ容量の合計が含まれてもよい。

図５の例では、フローチャート５００はディシジョン・ポイント５０８へと続き、プレイバック・デバイスにコンテンツを記憶するのに利用できるストレージ容量が十分にあるか否かが判断される。もし、十分なストレージがあれば（５０８−Ｙ）、Ｅ−チケットとコンテンツはプレイバック・デバイスへと送られる。一方、もし十分なストレージがなかったら、Ｅ−チケットはプレイバック・デバイスへと送られるが、コンテンツは外部ストレージへと送られる。その後、このフローチャート５００は終了する。

図６は、バーチャル・ボールト・サービスを提供する方法の一例を示すフローチャート６００を図示する。図６の例では、フローチャート６００は、モジュール６０２から開始され、ユーザによって所有されるユーザ生成ステート・データおよびタイトル・コンテンツのためのリトリーバル・サービスとストレージを提供する。ユーザ生成ステート・データには、限定的ではなく例示的に、ゲーム保存データ、アプリケーション保存データ、ランタイム・ステート、あるいはタイトル・コンテンツを実行するにうちにプレイバック・デバイスにおいて生成される他のステートなどが含まれる。

図６の例では、フローチャート６００は、モジュール６０４へと続き、ユーザと関連付けられたステート・データまたはタイトルに対するリクエストを有効に（バリデート）するために、少なくともタイトルとユーザあるいはデバイス・アイデンティティを含む署名されたチケットの暗号認証を行う。好ましくは、外部ストレージは、与えられたユーザ（あるいはデバイス・アイデンティティ）に対するコンテンツとステート・データを保存することができる。そしてユーザは、比較的小さいフットプリントのチケット（すなわち、コンテンツ、および／またはコンテンツ・ステートよりも著しく小さいフットプリントしかもたないチケット）を用いてコンテンツを復元できる。

図６の例では、フローチャート６００はモジュール６０６へと続き、ユーザ生成ステート・データのストレージを受け入れる前にステート・データの有効性（バリディティ）を立証するために、デバイスまたはユーザ生成シグネチャの暗号認証を行う。好ましくは、認証されていないユーザやデバイスは、バーチャル・ボールトのストレージ・リソースを利用し切ることができず、正規のユーザしかそれをできないことを保証する。

ここで使用される、用語「実施形態」は、限定的ではなく例示的な説明を行うための実施形態を意味する。

当業者であれば前述した実施例と実施形態は、代表的なものであり、本発明の範囲を限定するものでないことが理解されるであろう。当業者が明細書を考慮し、図面を検討したときに自明な置き換え、増強、均等物やそれらへの改良が、本発明の要旨と範囲に含まれることを意図している。したがって、添付された特許請求の範囲は、本発明の要旨と範囲内にあるこのような全ての変更、置き換え、均等物を含むことを意図している。

バーチャル・ボールトを含むシステムの一例を示す。 バーチャル・ボールトを含むシステムの一例を示す。 バーチャル・ボールト・システムの代表例のブロック図である。 図１のコンテンツ・マネージメント・システムに適合するフロー・ダイアグラムの一例を示す。 コンテンツ・ステート・リカバリー・エンジンを備えたプレイバック・デバイスの一例を示す。 限られたストレージ容量のプレイバック・デバイスを含むネットワークにサーバがコンテンツを配信可能な方法の一例を示す。 バーチャル・ボールト・サービスを提供するための方法の一例のフローチャートである。

Claims (16)

1. ユーザによって所有されるユーザ生成ステート・データとタイトル・コンテンツのためのリトリーバル・サービスおよびストレージを提供し、
   ユーザに関連付けられたステート・データまたはタイトルに対するリクエストをバリデートするために、少なくともタイトルとユーザまたはデバイス・アイデンティティを含む署名されたチケットの暗号認証を行い、
   ストレージを受け入れる前にステート・データのバリディティを立証するため、デバイスまたはユーザ生成シグネチャの暗号認証を行う
   ことを特徴とする方法。
2. ネットワークと、
   作動中、プレイバック・デバイスにＥ−チケットを提供するライセンス・サーバと、
   作動中、前記コンテンツに関連付けられたアプリケーション保存データを前記プレイバック・デバイスに提供するステート・サーバとを備え、
   前記プレイバック・デバイスが、前記アプリケーション保存データと関連付けられた前記コンテンツを実行するパーミッションを有する
   ことを特徴とするシステム。
3. 前記プレイバック・デバイスが、モバイル・デバイス、ゲーム・コンソール、ＰＤＡ、携帯電話、スマートフォン、コンピュータ、家電、コンピュータ読み取り可能媒体を含む電子デバイスからなるデバイスの群から選択されることを特徴とする請求項２に記載のシステム。
4. 前記プレイバック・デバイスまたは前記プレイバック・デバイスのユーザと関連付けられたデータを含み、前記ライセンス・サーバに結び付けられたユーザ・データベースを備えることを特徴とする請求項２に記載のシステム。
5. 周知または手頃なコンテンツを含み、前記コンテンツ・サーバに結び付けられたコンテンツ・データベースを備えることを特徴とする請求項２に記載のシステム。
6. 前記コンテンツおよび前記プレイバック・デバイス、前記プレイバック・デバイスのユーザ、またはその両者と関連付けられたアプリケーション保存データを含み、前記ステート・サーバに結び付けられたステート・データベースを備えることを特徴とする請求項２に記載のシステム。
7. 前記ライセンス・サーバと前記コンテンツ・サーバは、お互いに対して相対的にローカルであることを特徴とする請求項２に記載のシステム。
8. 前記ステート・サーバと前記コンテンツ・サーバは、お互いに対して相対的にローカルであることを特徴とする請求項２に記載のシステム。
9. 前記プレイバック・デバイスからのコンテンツに対するリクエストが、コンテンツとコンテンツに関連付けられたアプリケーション保存データを含む応答のトリガーとなることを特徴とする請求項２に記載のシステム。
10. プレイバック・デバイスにおいてコンテンツを実行することによりステートを生成し、
    前記ステートをアップロードするとともにステート・サーバに記録し、
    前記コンテンツに関連付けられたライセンスの中の情報を用いて前記ステートを再取得する
    ことを特徴とする方法。
11. 前記ステートが生成されて１つのデバイスからアップロードされ、別のデバイスで再取得されることを特徴とする請求項１０に記載の方法。
12. 前記コンテンツに対するＥ−チケットを取得し、Ｅ−チケット内の情報を使用して前記コンテンツを取得することを特徴とする請求項１０に記載の方法。
13. 前記コンテンツに対するＥ−チケットを取得し、Ｅ−チケット内の情報を使用して前記ランタイム・ステートを再取得することを特徴とする請求項１０に記載の方法。
14. バスに連結されたインタフェースと、
    作動中、コンテンツに関連付けられたＥ−チケットを有し、前記バスに連結されたＥ−チケット・データベースと、
    作動中、前記コンテンツに関連付けられたアプリケーション保存データを再取得し、コンピュータ読み取り可能媒体に実装されるとともに前記バスに連結されたコンテンツ・ステート・リカバリー・エンジンとを備え、
    前記Ｅ−チケットは、前記インタフェースを介して受領され、前記Ｅ−チケット・データベースに保存されるとともに、前記アプリケーション保存データが前記インタフェースを介して受領される
    ことを特徴とするデバイス。
15. 作動中、前記コンテンツが、前記コンテンツに関連付けられた前記Ｅ−チケットを用いて１度以上ダウンロードされ、前記コンテンツを含むコンテンツ・データベースを備えることを特徴とする請求項１４に記載のデバイス。
16. 前記コンテンツと関連付けられた前記アプリケーション保存データを含むコンテンツ・データベースを備え、作動中、前記コンテンツ・ステート・リカバリー・エンジンが、前記コンテンツに関連付けられた前記アプリケーション保存データを前記インタフェースによって外部ストレージへと送ることを特徴とする請求項１４に記載のデバイス。

Images