ユーザ・デバイスにおけるゲーム使用の制御メカニズム
ユーザ・デバイスにおけるゲーム使用を制御するための方法及びシステムが解説される。実施形態の１つにおいて、この方法には、第１のユーザ・デバイスのためにユーザが選択したゲームを識別するステップと、第２のユーザ・デバイスのために、ユーザがそのゲームを購入済みであることを確認するステップと、第１のユーザ・デバイスで楽しむため、ユーザがそのゲームを利用できるようにするステップが含まれている。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線ゲームに関するものであり、とりわけ、本発明は、ユーザ・デバイスにおけるゲーム使用の制御に関するものである。
【背景技術】
【０００２】
今日の現代世界では、電子ゲームが娯楽産業の主要部分になっている。独立型端末で行う電子ゲームが流行するようになってからずいぶん時が経つ。しかし、昨今は、これらのゲームが、無線ネットワーク環境を含むネットワーク環境に移行してきた。
【０００３】
無線ネットワーク環境の場合、一般に、電子ゲームのメーカや出版社が、エンドユーザと直接交流することはない。すなわち、エンドユーザは、通常、無線通信事業者（例えば、ＡＴ＆Ｔ（登録商標）、Ｓｐｒｉｎｔ ＰＣＳ（登録商標）、Ｖｅｒｉｚｏｎ（登録商標）等）から電子ゲームを購入し、ゲーム関連サービスを受ける。結果として、ゲーム・プレーヤのコミュニティは、特定無線通信事業者のユーザに制限される。さらに、電子ゲームのメーカや出版社は、ゲーム・プレーヤとの直接的な関係を発展させることができないので、ゲーム・プレーヤに関する詳細な情報を収集し、新しいゲームのターゲットを絞った広告を促進することができない。さらに、ユーザが、無線通信事業者の１つからゲームを購入し、その後、異なる無線通信事業者の携帯電話に切り替える場合、ユーザは、新しい携帯電話でそのゲームをできるようにするためには、異なる無線通信業者からもう一度このゲームを購入しなければならない。
【発明の開示】
【課題を解決するための手段】
【０００４】
ユーザ・デバイスにおけるゲーム使用を制御するための方法及びシステムについて解説する。態様の１つにおいて、この方法には、第１のユーザ・デバイスのためにユーザが選択したゲームを識別するステップと、そのゲームが、第２のユーザ・デバイスのためにユーザによって既に購入済みのものであることを確認するステップと、第１のユーザ・デバイスで楽しむために、ユーザがそのゲームを使用できるようにするステップが含まれている。
【０００５】
本発明の他の特徴については、添付の図面及び下記の詳細説明から明らかになるであろう。
【発明を実施するための最良の形態】
【０００６】
本発明については、下記の詳細な説明、本発明のさまざまな実施形態に関する添付の図面からより完全な理解が得られるが、それらは、本発明を特定の実施形態に制限するものと理解すべきではなく、説明を行い、理解を得るためのものでしかない。
【０００７】
ユーザ・デバイスにおけるゲーム使用を制御するための方法及びデバイスが明らかにされる。以下の説明では、多くの細部にわたる記述がなされる。しかしながら、当該技術者には明らかなように、本発明は、これら具体的な詳述がなされなくても、実施可能である。他の例では、周知の構造やデバイスは、本発明を曖昧にするのを避けるため、細部にわたってではなく、ブロック図の形で示されているものもある。
【０００８】
以下の詳細な説明の一部には、コンピュータ・メモリ内におけるデータ・ビットに関するオペレーションのアルゴリズム表現や記号表現として提示されているものもある。これらのアルゴリズムの記述や表現は、データ処理技術者によって、他の当該技術者にその作業の主題を最も有効に伝達するために用いられる手段である。アルゴリズムは、ここでは、一般に、所望の結果をもたらすことになる、首尾一貫した一連のステップである。これらのステップは、物理量の物理的操作を必要とするものである。通常、必ずしもそうとは限らないが、これらの量は、記憶、転送、組み合わせ、比較、あるいは、別様のオペレーション可能な電気または磁気信号の形をとる。時には、主として共通使用のため、これらの信号を、ビット、値、要素、記号、文字、項、数等と呼ぶのが好都合であることが立証されている。
【０００９】
しかしながら、これらの用語及び同様の用語の全てが、適合する物理的量に関連していなければならず、これらの量に適用される、単なる好都合なラベルにすぎないという点に留意すべきである。下記論考から明らかなように、特に別段の指定のない限り、説明の全体を通じて、「処理」または「計算」または「算出」または「決定」または「表示」等のような用語を用いる論考は、コンピュータ・システムのレジスタやメモリ内における物理的（電子的）量として表現されるデータを操作して、コンピュータ・システムのメモリまたはレジスタ、あるいは、他のこうした情報記憶、伝送、または、表示デバイス内における物理的量として同様に表現される他のデータに変換する、コンピュータ・システム、または、同様の電子計算デバイスの動作及びプロセスに言及するものである。
【００１０】
本発明は、また、本明細書のオペレーションを実施するためのデバイスに関連するものである。このデバイスは、要求される目的に合わせて特別に構成することが可能であり、あるいは、コンピュータに記憶されたコンピュータ・プログラムによって、選択的に起動または再構成される汎用コンピュータを含むことが可能である。こうしたコンピュータ・プログラムは、制限するわけではないが、フロッピ・ディスク、光ディスク、ＣＤ−ＲＯＭ、磁気光ディスクのような任意のタイプのディスク、読み取り専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気または光カード、または、電子命令の記憶に適した任意のタイプの媒体のような、それぞれ、コンピュータ・システム・バスに結合された、コンピュータ可読記憶媒体に記憶することが可能である。
【００１１】
本明細書に提示のアルゴリズム及び表示は、本質的に、いかなる特定のコンピュータまたは他のデバイスにも関連するものではない。本明細書の教示によるプログラムには、さまざまな汎用システムを用いることもできるし、あるいは、必要とされる方法ステップの実施により特化されたデバイスを作り上げるのが好都合であると立証される場合もある。これらのさまざまなシステムに必要な構造は、下記の説明から明らかになるであろう。さらに、本発明の説明は、いかなる特定のプログラム言語にも関連したものではない。さまざまなプログラム言語を利用して、本明細書に記載の本発明の教示を実施することができるのは明らかである。
【００１２】
機械可読媒体には、機械（例えば、コンピュータ）による読み取りが可能な形式の情報を記憶または伝送するための任意のメカニズムが含まれる。例えば、機械可読媒体には、読み取り専用メモリ（「ＲＯＭ」）、ランダム・アクセス・メモリ（「ＲＡＭ」）、磁気ディスク記憶媒体、光記憶媒体、フラッシュ・メモリデバイス、電気、光、音響、または、他の形態の伝搬信号（例えば、搬送波、赤外線信号、ディジタル信号等）などが含まれる。
【００１３】
概要
本発明の実施形態によって、電子ゲームのプロバイダは電子ゲームのプレーヤの使用を管理することが可能になる。電子ゲームのプロバイダには、ゲーム・メーカ、ゲーム出版社、無線通信事業者、または、電子ゲームへのユーザ・アクセスを制御する任意の他のエンティティを含むことが可能である。
【００１４】
図１は、本発明の実施形態が機能することが可能なシステム１００の実施形態の１つに関するブロック図である。システム１００には、広域ネットワーク（例えば、インターネット）１０４、無線ネットワーク１０６、クライアント・デバイス１０８、１１０、ゲーム管理システム１０２が含まれている。
【００１５】
クライアント・デバイス１０８は、無線ネットワーク１０６を介してゲーム管理システム１０２に結合されたモバイル・デバイスである。モバイル・デバイス１０８は、そのユーザが無線ゲームを行えるようにすることが可能な、対話型双方向通信デバイスである。例えば、モバイル・デバイス１０８は、無線電話、手のひらサイズの計算デバイス、携帯端末（ＰＤＡ）等とすることが可能である。こうした双方向通信デバイスは、無線ネットワーク１０６を介して、ゲーム管理システム１０２と無線通信することが可能である。ゲーム管理システム１０２とモバイル・デバイス１０８との間の通信は、対応する無線通信事業者（例えば、ＡＴ＆Ｔ（登録商標）、Ｓｐｒｉｎｔ ＰＣＳ（登録商標）、Ｖｅｒｉｚｏｎ（登録商標）等）によって提供される。
【００１６】
クライアント・デバイス１１０は、広域ネットワーク（例えば、インターネット）を介してゲーム管理システム１０２に結合されている。クライアント・デバイス１０８は、そのユーザが、ゲーム機用ゲーム、ウェブ・ゲーム、または、パーソナル・コンピュータ（ＰＣ）・ゲームを行えるようにすることが可能な、対話型双方向通信デバイスである。例えば、クライアント・デバイス１１０は、ＰＣシステム、携帯端末（ＰＤＴ）、プレイ・ステーション、家庭用電子機器等とすることが可能である。
【００１７】
実施形態の１つでは、クライアント・デバイス１０８、１１０は、関連クライアント・デバイス１０８、１１０で行われるゲームに関連したデータを収集して、このデータをゲーム管理システム１０２に提供する、ゲーミング・データ・モジュール１１２のようなクライアント・ベースのアプリケーションを提供する。実施形態の１つでは、ゲーミング・データ・モジュール１１２は、関連クライアント・デバイス１０８または１１０のプラットフォームをベースにして構成される。実施形態の１つでは、ゲーミング・データ・モジュール１１２は、関連クライアント・デバイス１０８または１１０において行われるゲームに組み込まれる。もう１つの実施形態では、ゲーミング・データ・モジュール１１２は、関連クライアント・デバイス１０８または１１０に常駐する独立アプリケーションである。
【００１８】
ゲーム管理システム１０２は、クライアント・デバイス１０８、１１０にゲームを配備し、管理し、サポートするサービスを提供し、従って、さまざまなデバイスのプラットフォーム（例えば、ＰＣプラットフォーム、無線デバイスプラットフォーム、ウェブ・ベースのハンド・ヘルド式デバイスのプラットフォーム、ゲーム機プラットフォーム等）に対してゲーム・サービスを提供する。ゲーム管理システム１０２は、ゲーム・メーカ、ゲーム出版社、ネットワーク通信事業者、または、他の任意のゲーム・サービス・プロバイダによって保守することが可能である。
【００１９】
実施形態の１つでは、ゲーム管理システム１０２は、ゲーミング・データ・モジュール１１２と協働して、クライアント・デバイス１０８、１１０におけるアプリケーションとの双方向メッセージ通信を可能にする。実施形態の１つでは、ゲーミング・データ・モジュール１１２は、ゲーム管理システム１０２にメッセージを転送し（クライアント・デバイスがネットワークから切断されている場合には、メッセージを記憶し）、ゲーム管理システム１０２によって促進される、ゲーム中リアルタイム機能（例えば、ゲーム中広告、マルチプレーヤ・ゲーム・プレイ、ユーザ登録、ゲーム・メトリクス収集等）をサポートする。
【００２０】
実施形態の１つにおいて、ゲーム管理システム１０２のスケーラビリティが、複数サーバを利用することによって得られる。例えば、各タイプのクライアント・アプリケーションは、１つ以上の指定サーバと関連づけることが可能である。さらに、無線クライアント・アプリケーションの場合、各無線通信事業者は、１つ以上の指定サーバと関連づけられる。例えば、各通信事業者は、指定データベース・サーバ（例えば、４−ＣＰＵデータベース・サーバ）と随伴するアプリケーション・サーバ（例えば、６つのウェブ・アプリケーション・サーバ）に関連付けられる。あるいはまた、無線通信事業者によっては、サーバを共用する場合もある。サーバまたはサーバ・グループのどれかに機能が不十分なものがあれば、システムは、別のサーバ・グループによって関連通信事業者のユーザにサービスを提供するように再構成される。
【００２１】
ゲーム管理システム
図２Ａは、ゲーム管理システム２００の実施形態の１つに関するブロック図である。実施形態の１つでは、ゲーム管理システム２００は、モバイル・ゲームまたは無線ゲームをサポートする。もう１つの実施形態では、ゲーム管理システム２００は、ＰＣゲーム、ウェブ・ゲーム、ゲーム機用ゲームといった他のタイプのゲームもサポートする。
【００２２】
ゲーム管理システム２００は、ユーザ登録モジュール２０２、ゲーム使用コントローラ２０４、ゲーム・メトリクス・コレクタ２０６、マルチプレーヤ・ゲームプレイ・サポータ２０８、広告モジュール２１０、ビリング・モジュール２１２、ゲーム・ダウンロード・モジュール２１４、バージョニング・モジュール２２２、ユーザ・アカウント・マネージャ２２４、ゲーム・ファインダ２２６、ユーザ・データベース２１６、ゲーム・メトリクス・データベース２１８、ビリング・データベース２２０、及び／または、図２には示されていない他の各種モジュールを含むことが可能である。
【００２３】
ユーザ登録モジュール２０２は、新規ユーザを登録し、ユーザ・データベース２１６に新規ユーザの識別情報を記憶し、既存のユーザのログインを容易にする責務を担っている。ユーザ登録プロセスは、ゲーム管理システム２００に関連したウェブサイトにおける登録リンクをユーザが起動するか、ユーザのクライアント・デバイス１０８または１１０にユーザがゲームをダウンロードするように要求するか、ユーザが新ゲームを開始しようとするか、あるいは、ユーザが他の任意のイベントを開始すると、呼び出しが可能になる。ユーザ識別情報には、例えば、ユーザＩＤ、パスワード、Ｅメール・アドレス、ユーザによって選択されたゲームに関連する一意性コード等を含むことが可能である。
【００２４】
ゲーム使用コントローラ２０４は、新ゲームのユーザ購入に関連した情報を受信し、ユーザ・データベース２１６にこの情報を記憶し、各種ユーザ・デバイスにおけるこのゲームの使用を制御する責務を担っている。ゲーム使用コントローラ２０４は、ゲーム管理システム２００によって購入が促進される場合には、ビリング・モジュール２１０からの、ユーザがゲーム管理システムにゲームを登録する場合には、ユーザ登録モジュール２０２からの、あるいは、新ゲームの購入を促進する外部システムからの、新ゲームの購入に関連した情報を受信することが可能である。実施形態の１つでは、ユーザが、ある特定モバイル・デバイス１０６のために新ゲームを購入する場合、ゲーム使用コントローラ２０４は、ユーザ・データベース２１６にその購入を記録する。その後、ユーザが、異なるモバイル・デバイスのためにこのゲームを選択すると、ゲーム使用コントローラ２０４は、ユーザ・データベース２１６において選択されたゲームに関連した記録を見つけ出し、他のモバイル・デバイスで楽しむために、このゲームをユーザが利用できるようにする。実施形態の１つにおいて、ゲーム使用コントローラ２０４は、ＰＣ、ハンドヘルド式コンピュータ、ゲーム機、または、他の任意のデバイス１０８で楽しむために、ユーザがモバイル・デバイス１０６用に購入したゲームを利用できるようにことも可能である。同様に、実施形態の１つにおいて、ゲーム使用コントローラ２０４は、ユーザが非モバイル・デバイス１０８用に購入したゲームを、ユーザがモバイル・デバイス１０６で楽しむために利用できるようにすることも可能である。さらに、ゲーム使用コントローラ２０４は、ユーザがクライアント・デバイスからのゲームを既に消去済みの場合（例えば、スペースを考慮して）、同じクライアント・デバイスにそのゲームを再ロードできるようにすることも可能である。
【００２５】
実施形態の１つにおいて、ゲーム使用コントローラ２０４は、ユーザが１つ以上のゲーム・アンロック基準を満たす場合（例えば、ゲーム・アンロック数が予め定めたしきい値を超えない）、ユーザがゲームを利用できるようにする。実施形態の１つにおいて、ゲーム使用コントローラ２０４は、ユーザが１つ以上のゲーム・ロック基準を満たす（例えば、ユーザが義務不履行者である）と判定すると、ユーザがゲームを利用できないか、もはや、入手できないようにすることも可能である。
【００２６】
ゲーム・メトリクス・コレクタ２０６は、各種ゲームのプレーヤからゲーム・メトリクスを受信し、ゲーム・メトリクス・データベース２１８にゲーム・メトリクスを記憶する責務を担っている。ゲーム・メトリクスは、例えば、行われるゲームのバージョン、ゲームのスコア、ゲームが行われた時間等を明示する。ゲーム・プロデューサや出版社は、ゲーム・メトリクスを利用して、ゲームプレイを分析し、データ・マイニングを実施する。ゲーム・メトリクス・コントローラ２０６は、ゲーム・メトリクスに基づくレポート（例えば、タイトルやジャンルに従ってゲームの性能を評価する、タイトルや通信事業者単位のレポート）を作成する責務を担う。
【００２７】
マルチプレーヤ・ゲームプレイ・サポータ２０８は、さまざまなデバイスのプラットフォーム（例えば、ＰＣプラットフォーム、無線デバイスプラットフォーム、ウェブ・ベースのハンド・ヘルド式デバイスのプラットフォーム、ゲーム機プラットフォーム等）に対してマルチプレーヤ機能を提供する責務を担っている。マルチプレーヤ機能には、例えば、ゲームに関するプレーヤの組み合わせを容易にするとか（例えば、名前、ランク、または、ランク範囲によるプレーヤのサーチを可能にすることによって）、ゲームにおけるプレーヤの順番を管理するとか、ゲーム中のチャット・メッセージの交換をサポートするとか、ゲーム・プレーヤが、情報の交換、利用可能なプレーヤ／チーム及び回数のサーチ、一対一ゲームの設定等を行えるようにするため、さまざまなゲームのためのロビーを持続するといった機能を含む。実施形態の１つにおいて、マルチプレーヤ・ゲームプレイ・サポータ２０８は、クライアント・デバイスから高スコア・データ（例えば、ユーザの名前とスコア）を収集し、異なるユーザのスコアと比較し、トップ・スコアのリストをクライアント・デバイスに戻し、ユーザに高スコアを獲得したか否かを通知する責務も担っている。さらに、マルチプレーヤ・ゲームプレイ・サポータ２０８は、ゲーム・プレーヤのランク付けをし（例えば、敗戦、勝利、行われるゲームの難度に基づいて）、要求があると、ユーザにプレーヤ・ランキングを提供し、トーナメントを開始し（または、ユーザが開始できるようにし）、トーナメント参加基準を決める（または、ユーザが決めるようにする）こともある。
【００２８】
実施形態の１つにおいて、マルチプレーヤ・ゲームプレイ・サポータ２０８は、さらに、各プレーヤがネットワークにまだ接続しているか否かを定期的にチェックする責務を担っている。さらに、しきい値を設定して、プレーヤの誰かがネットワークから外れる場合、ゲームが別様に処理されることになるゲーム検証ポイントにマーク付けする。この機能によって、スコアが振るわない場合に、早めに切断しようとするプレーヤと、ネットワーク問題により切断されるプレーヤを見分けることが可能になる。
【００２９】
広告モジュール２１０は、広告（テキストと図形の両方）を維持管理し、クライアント・デバイスに対する広告のゲーム中配信を促進する（上述のクライアント・ベースのモジュールを利用して）責務を担っている。実施形態の１つでは、広告は、クライアント・ベースのモジュール及び／または基準集合（例えば、最近の１０日間にゲームＡを１０回行ったユーザは、ゲームＡの新バージョンに関する広告を受信すべきである）によって収集されたユーザのプロフィール・データに基づいて、クライアント・デバイスに配信する広告が選択される。実施形態の１つでは、広告は、カルーセルに割り当てられ、タイトル、インプレッション回数またはタイム・スケジュール、クライアント・デバイスタイプに従って輪番させられる。タイトル・ベースの広告より、通信事業者特定プロモーションが優先される場合もある。実施形態の１つでは、ゲーム開始時に、広告が検索される（例えば、クライアント・ベース・モジュールが、ゲーム開始メッセージを送り、広告モジュール２１０が、これに応答して、テキスト及び／または図形広告を送る）。実施形態の１つでは、ユーザによって行われるゲームのより新しいバージョンが存在する場合には、広告モジュール２１０が、新バージョン・アラート・メッセージを送り出す（例えば、クライアント・ベース・モジュールが、現行バージョンのゲームに関してゲーム開始メッセージを送り、広告モジュール２１０が、これに応答して、新バージョン・アラート・メッセージを送る）。
【００３０】
実施形態の１つでは、広告モジュール２１０によって、ユーザは、ゲーム・リストを閲覧し、ユーザがリストから選択したゲームに関する記述、１つ以上のスクリーン・ショットを表示することが可能になる。もう１つの実施形態では、広告モジュール２１０は、リストから選択されたデモバージョンのゲームのダウンロードを容易にする。デモバージョンは、部分的な（制限された）ゲーム機能性だけを提供するバージョンである。例えば、デモバージョンは、ユーザが、限られた時間（例えば、５分間）または基本レベルでしかゲームを楽しむことができないようにする（すなわち、デモバージョンは、ユーザがゲームで上級レベルに達すると停止する）ことが可能である。
【００３１】
実施形態の１つでは、広告モジュール２１０は、データベース２１６、２１８に記憶されているデータに基づいて、特定広告の受信者を選択し、選択されたクライアント・デバイスに対する広告のゲーム中配信を促進する責務を担っている。実施形態の１つでは、広告モジュール２１０は、ゲームの潜在的顧客を識別して、潜在的顧客に新ゲームを試すように、勧誘状を送り、潜在的顧客から承諾を受けると、潜在的顧客のモバイル・デバイスに対する新ゲームのデモバージョンのダウンロードを容易にする責務も担っている。
【００３２】
ビリング・モジュール２１２は、コンテンツの購入やリースといった、支払請求可能なイベントに関連した請求書作成業務を実施し、ビリング・データベース２２０に請求書作成業務に関する情報を記憶する責務を担っている。実施形態の１つでは、ビリング・モジュール２１２は、ゲーム購入のユーザ要求を受信すると、関連クライアント・デバイスに確認応答を送る（例えば、「ゲームＡに関して、貴殿の口座に対し＄３．９５が請求されました」）、ゲーム使用コントローラ２０４に対し、関連クライアント・デバイスにおいてゲームＡをアンロックするように指令する（すなわち、ユーザがゲームＡを利用できるようにする）。さらに、ビリング・モジュール２１２は、請求書作成業務を完了するか、または、対応するネットワーク通信事業者に請求書作成要求を送る（例えば、ユーザの電話代請求書として請求されるようにする）ため、ユーザにビリング情報（例えば、ゲーム管理システムによって保守されるユーザの識別子、クレジットカード番号等）の提供を要求する。実施形態の１つでは、ビリング・モジュール２１２によって、ユーザは、さまざまなゲーム関連機能（例えば、高スコア送信、マルチプレーヤ・メッセージング、チャット・メッセージング、ゲーム・コンテンツのアップグレード、ピクチャ及びサウンド・ファイルのリフレッシュ等）、非アプリケーション・データ（例えば、楽器用ディジタル・インターフェイス（ＭＩＤＩ）ファイル、グラフィック・ファイル等）に関して個別に要求し、支払うことが可能になる。
【００３３】
実施形態の１つでは、ビリング・モジュール２１２は、義務不履行ユーザを識別して、この情報をゲーム使用コントローラ２０４に送り、その結果、ゲームを「ロックする」（すなわち、ゲームに対するユーザ・アクセスが打ち切られる）。実施形態の１つでは、ビリング・モジュール２１２は、通信事業者からビリング・データ要求を受信し、ビリング・データベース２２０から通信事業者のビリング・システムに要求されたデータをインポートする責務も担っている。
【００３４】
ゲーム・ダウンロード・モジュール２１４は、関連クライアント・デバイスに対するゲームのダウンロードを容易にする責務を担っている。実施形態の１つでは、ゲーム・ダウンロード・モジュール２１４は、ダウンロード可能なゲーム・コードを記憶する。代替案として、ゲーム・ダウンロード・モジュール２１４は、ダウンロード可能なゲーム・コードの外部記憶場所に関する情報を記憶する（例えば、ダウンロードに利用可能なゲーム・コードのＵＲＬ）。実施形態の１つでは、ゲーム・ダウンロード・モジュール２１４は、ＭＩＤＩファイル、ポータブル・ネットワーク・グラフィックス（ＰＮＧ）ファイル等のような非アプリケーション・データのダウンロードも容易にする。
【００３５】
バージョニング・モジュール２２２は、ユーザが所有するゲームのバージョンを識別するデータを受信し、そのゲームの新バージョンが利用可能か否かを確認し、クライアント・デバイスにメッセージを送ってユーザに新ゲーム・バージョンを知らせて、対応するダウンロード可能なゲーム・コードの記憶場所を指示する責務を担っている。
【００３６】
ユーザ・アカウント・マネージャ２２４は、クライアント・デバイスからユーザ・アカウント情報を収集し、この情報をユーザ・データベース２１６に記憶し、そのアカウントに対するウェブ・ベースのユーザ・ログインを可能にする責務を担っている。ユーザ・アカウント情報には、例えば、勝利したゲームのリスト、ユーザ・ランキング、地位、メッセージ・ボード、システム情報等を含む。
【００３７】
ゲーム・ファインダ２２６は、ロビーを介してマルチプレーヤ・ゲームを見つけ出し（例えば、ゲームするのを待っているユーザを見つけ出し）、これらのゲームに対するユーザ・アクセスを可能にする責務を担っている。
【００３８】
実施形態の１つでは、ゲーム管理システム２００には、さまざまなサービスとデータに対するさまざまなレベルのユーザ・アクセスを可能にする責務を担う管理モジュール（不図示）を含む。例えば、ゲーム出版社の管理者には、ゲーム管理システム２００によって提供される全てのデータとサービスに対する最高のアクセス・レベルを与えることが可能であるが、通信事業者の管理者には、この通信事業者のユーザに提供されるサービスとデータに対するアクセスだけしか許されない、より低いアクセス・レベルを与えることが可能である。実施形態の１つでは、管理モジュールは、個々の通信事業者にデフォルト設定と許可を与え、通信事業者に応じてデフォルト設定と許可をカスタマイズできるようにする責務も担っている。実施形態の１つでは、管理モジュールは、ゲーム管理システム２００をリアルタイムに再構成して、デフォルト設定と許可と共に新規の通信事業者を追加する責務も担っている。
【００３９】
ゲーム管理システム２００は、さまざまなネットワーク通信事業者のユーザにサービスを提供するので、ゲーム・プレーヤ・コミュニティは、もはや、特定通信事業者または特定デバイス・プラットフォームのユーザに制限されない。さらに、ゲーム管理システム２００は、電子ゲームのメーカや出版社が、モバイル・ゲーム、ＰＣゲーム、ウェブ・ベース・ゲーム、ゲーム機用ゲームのプレーヤとの直接的関係を発展させ、これらのゲーム・プレーヤに関する詳細な情報を収集し、電子ゲームのターゲットを絞った広告を促進できるようにする。さらに、ゲーム管理システム２００は、ゲーム・プレーヤが、これらのモバイル・デバイスに関連した通信事業者に関係なく、さまざまなモバイル・デバイスで購入したゲームを使用できるようにする。
【００４０】
クライアント・ベース・モジュール
上述のように、ゲーム管理システムによるサービスを受ける各クライアント・デバイスには、ゲーム・アプリケーション（例えば、モバイル・ゲーム・アプリケーション、ＰＣゲーム・アプリケーション、ウェブ・ベース・ゲーム・アプリケーション、ゲーム機用ゲーム・アプリケーション等）と統合することもできるし、あるいは、独立したアプリケーションとして機能することも可能な、クライアント・ベース・モジュール（本明細書において、ゲーミング・データ・モジュールとも呼ばれる）が設けられている。実施形態の１つでは、ゲーミング・データ・モジュールは、ゲーム・タイプに応じて変化することが可能な、アプリケーション・プログラミング・インターフェイス（ＡＰＩ）である。例えば、ＰＣゲームのクライアントＡＰＩは、ＰＣに関するシステム情報（例えば、ディスクとメモリのサイズ、オペレーティング・システム情報、ビデオ・カード・タイプ等）を検索し、このシステム情報をゲーム管理システム１０２に送ることが可能である。さらに、クライアントＡＰＩ機能は、さまざまなゲームに合わせて変化してもよい。例えば、特定ゲームのためのクライアントＡＰＩは、ゲーム中広告またはゲーム・メトリクス収集をサポートすることができない。
【００４１】
ゲーミング・データ・モジュールは、ゲーム管理システムにメッセージを送り（クライアント・デバイスがネットワークから切断されている場合には、メッセージを記憶し）、ゲーム管理システムによって促進されるリアル・タイムのゲーム中機能（例えば、ゲーム中広告、マルチプレーヤ・ゲームプレイ、ユーザ登録、ゲーム・メトリクス収集等）をサポートする責務を担っている。
【００４２】
図２Ｂは、ゲーミング・データ・モジュール２４０の実施形態の１つに関するブロック図である。ゲーミング・データ・モジュール２４０には、ビリング・コンポーネント２４２、ゲーム・アクセス・コンポーネント２４４、高スコア・コンポーネント２４６、バージョニング・アラート・コンポーネント２４８、広告コンポーネント２５０、マーケティング・コンポーネント２５２、ユーザ・プロフィール・コンポーネント２５４、ゲーム・ブラウザ・コンポーネント２５６、ゲーム・ダウンロード・コンポーネント２５８、ユーザ・データベース２６０が含まれている。
【００４３】
ビリング・コンポーネント２４２は、ゲーム管理システムにビリング・データ（例えば、ゲームのタイトル、デバイスＩＤ、ユーザＩＤ、ユーザ・ビリング情報等）を送り、ゲーム管理システムから購入確認応答を受信し、購入確認応答をユーザに表示する責務を担っている。
【００４４】
ゲーム・アクセス・コンポーネント２４４は、ゲーム管理システムにゲーム・キー（例えば、ゲーム・タイトル、デバイスＩＤ、ユーザＩＤ）を送り、ゲーム管理システムからアンロック命令を受信すると、ゲームをアンロックする責務を担っている。実施形態の１つでは、ゲーム・アクセス・コンポーネント２４４は、ユーザがゲームを開始する毎に、ゲーム管理システムをチェックし、ゲームを再ロックすべきか否かを判定する（例えば、会員期限が切れている場合、ゲームが盗用されることになる等）。実施形態の１つでは、ゲーム・アクセス・コンポーネント２４４は、高優先順位メッセージ（例えば、ゲーム購入メッセージ）のフラグを立てて、ゲーム管理システムにすぐに送るか、あるいは、サービスが得られない場合（例えば、ユーザが、サービス・エリア外にいる間に、ゲームを購入したいと思う場合）、再送に備えてレコード・ファイルに記憶する。
【００４５】
高スコア・コンポーネント２４６は、ゲームが終わると、ユーザのスコアをゲーム管理システムに送り、高スコアの現行リストを受信し、その現行リストをユーザに表示する責務を担っている。
【００４６】
バージョニング・アラート・コンポーネント２４８は、ゲームが開始されるとき、ゲーム・バージョン情報をゲーム管理システムに送り、ゲーム管理システムからより新しいバージョンに関する情報を受信し、ゲームの開始前に、この情報をユーザに表示する責務を担っている。
【００４７】
ユーザ・プロフィール・コンポーネント２５４は、ユーザ・プロフィール・データを収集し、そのユーザ・プロフィール・データをユーザ・データベース２６０に記憶する責務を担っている。ユーザ・プロフィール・データは、ゲーム管理システムによって決められる関心のある情報に基づいて収集する。ユーザ・プロフィール・データは、例えば、このクライアント・デバイスでユーザが行うのがどのゲームか、ゲームがいつ行われるのか、ゲームで獲得されたユーザ・スコア、ユーザ・デバイス情報（例えば、デバイスタイプ、ＣＰＵ等）等を明らかにする。
【００４８】
広告コンポーネント２５０は、ゲーム管理システムに新しいユーザ・プロフィール・データを送り、ユーザ・プロフィール・データと１組のルールに基づいてゲーム管理システムが選択した広告を受信し、その広告をユーザに表示する責務を担っている。
【００４９】
マーケティング・コンポーネント２５２は、ゲーム・メトリクスを収集して、ゲーム管理システムに送る責務を担っている。ゲーム・メトリクスは、例えば、行われたゲームのバージョン、ゲームのスコア、ゲームが行われた時間がどれくらいか等を明らかにすることが可能である。
【００５０】
ゲーム・ブラウザ・コンポーネント２５６によって、ユーザは、ゲーム開始時にログインして、好みのものを参照し、ゲーム管理システムで利用可能な現行ゲームを閲覧することが可能になる。実施形態の１つでは、ゲーム・ブラウザ・コンポーネント２５６によって、ユーザは、ゲームのスクリーン・ショット、記述、価格を参照することができる。
【００５１】
ゲーム・ダウンロード・コンポーネント２５８によって、ユーザは、新ゲームをダウンロードすることが可能になる。
【００５２】
ユーザのさまざまなデバイスによる電子ゲームの使用
図３、４は、ユーザのさまざまなデバイスによる電子ゲームの使用を容易にするためのプロセスに関する２つの実施形態の流れ図である。このプロセスは、ハードウェア（例えば、専用ロジック、プログラマブル・ロジック、マイクロコード等）、ソフトウェア（汎用コンピュータ・システムまたは専用機で実行されるような）、または、両方の組み合わせを含むことが可能な処理ロジックによって実施可能である。実施形態の１つでは、プロセスは、ゲーム管理システム１０２または２００によって実施される。
【００５３】
図３を参照すると、プロセス３００は、ユーザがゲーム管理システムに登録すると、処理ロジックがユーザ識別情報を受信することから開始される（処理ブロック３０２）。ユーザ識別情報には、例えば、ユーザＩＤ、パスワード、Ｅメール・アドレス、ユーザが選択したゲームに関連する一意性コード（例えば、小売店で購入のスクラッチ・カード番号）等を含む。ユーザが、ゲーム管理システムに関連したウェブ・サイトで登録リンクを起動すると、あるいは、ゲーム管理システムからゲームを購入する要求を送ると、ゲーム管理システムに登録することが可能になる。あるいはまた、ユーザが、ユーザのデバイス（例えば、ユーザの携帯電話）にゲームをダウンロードする要求を出すと、あるいは、ユーザが新ゲームを開始すると、処理ロジックは、ゲーム管理システムに登録するように、ユーザに要求するメッセージを送る。
【００５４】
処理ブロック３０４において、処理ロジックは、ユーザがデバイス１のために購入したゲームＸの識別データを受信する。デバイス１は、例えば、モバイル・デバイス（例えば、携帯電話）、ＰＣ、ゲーム・ステーション、家庭用電子機器などである。ユーザがゲーム管理システムに登録すると、あるいは、ユーザ登録の後、ゲームＸの識別データを受信することが可能になる。例えば、ユーザがゲーム管理システムからゲームＸを購入すると、あるいは、ユーザが、小売店で購入したゲーム・スクラッチ・カードの番号をデバイス１で入力すると、ゲームＸの識別データを受信することが可能になる。処理ロジックは、ユーザ識別情報、ゲームＸの指定データをデータベースに記憶する。
【００５５】
その後、処理ロジックは、デバイス２のためのゲームＸのユーザ選択を受信する（処理ブロック３０６）。デバイス２は、デバイス１の通信事業者と同じかまたは異なる通信事業者のモバイル・デバイス、ＰＣ、ゲーム・ステーション、家庭用電子機器等とすることが可能である。処理ロジックは、ゲーム管理システムに関連したウェブ・サイトで、ユーザがデバイス２のためにゲームＸを選択すると、あるいは、ユーザがデバイス２からゲームＸのダウンロードを要求すると、デバイス２のためのゲームＸのユーザ選択を受信する。
【００５６】
次に、処理ロジックは、ユーザに対して、ユーザの識別情報を提供するように要求する（処理ブロック３０８）。あるいはまた、処理ロジックは、デバイス２のためのゲームＸのユーザ選択を受信する前に、ユーザ識別情報を受信することも可能である。判断記号３１０において、処理ロジックは、ユーザが１つ以上のゲーム・アンロック基準を満たしているか否かを判定する。ゲーム・アンロック基準は、ゲームの使用を許可するために（すなわち、ゲームを「アンロックする」ために）構成可能なパラメータを指定する。ゲーム・アンロック基準は、ゲーム・タイプ及び／または通信事業者によって異なってもよい。ゲーム・アンロック基準は、例えば、ユーザに関する「アンロック」数が所定のしきい値未満であること、単一ユーザ・デバイスに関する「アンロック」数が所定のしきい値未満であること、ユーザが義務不履行者でないこと等を要求する。
【００５７】
判断記号３１０においてなされる判定が肯定の場合、処理ロジックは、ユーザ識別情報とゲーム・データを突き合せるためデータベースをサーチする。一致することが分ると（判断記号３１２）、処理ロジックは、ゲームＸがユーザによって既に購入されているものと判断し、デバイス２で楽しむため、ユーザがゲームＸを利用できるようにする（処理ブロック３１４）。実施形態の１つでは、処理ロジックは、ゲームＸをデバイス２にダウンロードすることによって、ユーザがゲームＸを利用できるようにする。もう１つの実施形態では、さらに詳細に後述するように、処理ロジックは、ゲームＸ（例えばゲームＸに関連したクライアントＡＰＩに）にアンロック・メッセージを送ることによって、ユーザがゲームＸを利用できるようにする。
【００５８】
あるいはまた、ユーザがゲーム・アンロック基準を満たしておらず、かつ、ゲームをまだ購入していないか、あるいは、そのいずれかである場合、処理ロジックは、デバイス２においてユーザがゲームＸを利用できないようにする（処理ブロック３１６）。実施形態の１つでは、処理ロジックは、デバイス２へのゲームＸのダウンロードを阻止することによって、ゲームＸを利用できないようにする。もう１つの実施形態では、さらに詳細に後述するように、処理ロジックは、ゲームＸに（例えば、ゲームＸに関連したクライアントＡＰＩに）ロック・メッセージを送ることによって、ゲームＸを利用できないようにする。
【００５９】
ある代替実施形態（不図示）の場合、処理ロジックは、ユーザがゲームを購入済みであることを確認した後、ユーザがゲーム・アンロック基準を満たすか否かを判定する。
【００６０】
ユーザがデバイス２においてゲームＸを行うのを許されると、処理ロジックは、ユーザのゲームプレイをサポートし、上述のゲーム中広告とマルチプレーヤ・ゲームプレイ機能を手助けする。実施形態の１つでは、マルチプレーヤ・ゲームプレイ機能が、さまざまな通信事業者によって複数ユーザに提供される（例えば、対応する通信事業者に関係なく、ゲームのスコア・リストが全参加者について維持管理される）。さらに、処理ロジックは、デバイス２からゲームＸに関連したメトリクスを受信して、ユーザの他のデバイスから受信したゲーム・メトリクスと共に、そのゲーム・メトリクスをデータベースに記憶し、それによって、ゲームが行われたユーザ・デバイスに関係なく、このゲームに関連した完全なユーザ・メトリクス集合が維持管理されるようにする。
【００６１】
図４は、ユーザの異なるデバイスによる電子ゲームの使用を容易にするためのプロセスに関する代替実施形態の流れ図である。
【００６２】
図４を参照すると、プロセス４００は、処理ロジックが、モバイル・デバイスからゲームのユーザ選択を受信することから開始される。モバイル・デバイスは、第１の無線通信事業者に関連している。実施形態の１つでは、処理ロジックは、第１の無線通信事業者に関連したモバイル・デバイスにゲームをダウンロードするユーザ要求がなされた時点で、ゲームのユーザ選択を受信する。次に、処理ブロック４０４において、処理ロジックは、第１の無線通信事業者のモバイル・デバイスにデモバージョンのゲームをダウンロードする。
【００６３】
代替実施形態（不図示）の場合、処理ロジックは、第１の無線通信事業者のモバイル・デバイスにダウンロード済みのデモバージョンのゲーム（例えば、広告の一部として）のユーザ選択がなされた時点で、ゲームのユーザ選択を受信する。
【００６４】
処理ブロック４０６において、処理ロジックは、ユーザに対し、ログイン情報（例えば、ユーザＩＤとパスワード）を提供するように要求する。この要求は、ゲームをダウンロードするユーザ要求の前または後、あるいは、デモバージョンのゲームがモバイル・デバイスにダウンロードされた後（例えば、課せられた制限のために、デモが停止になる場合）、モバイル・デバイスに送ることが可能である。
【００６５】
次に、処理ロジックは、ユーザが１つ以上のアンロック基準を満たすか否かを判定する（判断記号４０８）。ユーザがアンロック基準を満たさない場合、処理ロジックは、モバイル・デバイスにロック・メッセージを送る（処理ブロック４１４）。ロック・メッセージは、ゲームに課せられた制限を有効のままにしておくべきであることを指示する。
【００６６】
ユーザがゲーム・アンロック基準を満たす場合、処理ロジックは、ユーザ・データベースをサーチして、ユーザが、このモバイル・デバイスまたは異なるモバイル・デバイス（例えば、異なる無線通信事業者のモバイル・デバイス）のためにこのゲームを購入済みであるか否かを判定する（判断記号４１０）。この判定が肯定の場合、処理ロジックは、モバイル・デバイスにアンロック・メッセージを送る（処理ブロック４１２）。アンロック・メッセージは、デモバージョンのゲームに課せられた制限を無効にすべきであることを指示する（例えば、ユーザが制限された期間にわたってゲームを行えるようにするタイマを無効にする）。結果として、ユーザは、今や、現モバイル・デバイスのためにゲームを購入することを必要とせずに、現モバイル・デバイスで無制限バージョンのゲームを行うことが可能になる。
【００６７】
ゲームがユーザによって購入済みでなければ、処理ロジックは、ユーザにゲームの購入を要求する。ユーザが購入を承認しなければ、処理ロジックは、モバイル・デバイスにロック・メッセージを送る（処理ブロック４１４）。ユーザが購入を承認すると、処理ロジックは、モバイル・デバイスにアンロック・メッセージを送る（処理ブロック４１２）。
【００６８】
もう１つの実施形態（不図示）では、ゲームがユーザによって購入済みでなければ、処理ロジックは、ゲームの価格をユーザ・アカウントに自動的に請求し、モバイル・デバイスにアンロック・メッセージを送る。
【００６９】
ゲームがアンロックされると、処理ロジックは、次に、ユーザが１つ以上のゲーム・ロック基準を満たすか否か（例えば、ユーザが義務不履行者か否か、各種デバイスに対してダウンロードされるゲーム例が多すぎるか否か等）を定期的にチェックする。ゲーム・ロック基準は、ゲームに対するユーザ・アクセスを中断する（すなわちゲームをロックする）ために構成可能なパラメータを指定する。ゲーム・ロック基準は、ゲーム・タイプ及び／または通信事業者によって異なってもよい。ユーザが、ゲーム・ロック基準を満たす場合、処理ロジックは、モバイル・デバイスにロック・メッセージを送って、ゲームへのユーザ・アクセスを中断させる。
【００７０】
図５は、ゲーム広告プロセスに関する実施形態の１つの流れ図である。プロセスは、ハードウェア（例えば、専用ロジック、プログラマブル・ロジック、マイクロコード等）、ソフトウェア（汎用コンピュータ・システムまたは専用機で実行されるような）、または、両方の組み合わせを含む処理ロジックによって実施可能である。実施形態の１つでは、プロセスは、ゲーム管理システム１０２または２００によって実施される。
【００７１】
図５を参照すると、プロセス５００は、処理ロジックが、新ゲームまたは既存のゲームの新バージョンの候補として、ユーザを選択することから開始される（処理ブロック５０２）。実施形態の１つにおいて、選択は、ユーザが購入したゲーム、これらのゲームに関連したユーザ・パラメータを明らかにする、ゲーム管理システムによって維持管理されているデータに基づいて行われる。
【００７２】
処理ブロック５０４において、処理ロジックは、ユーザの現行モバイル・デバイスを識別する。現行モバイル・デバイスは、最新ゲームのアンロックが実施されたデバイス、または、最新ゲーム・メトリクスが収集されたデバイスなどである。
【００７３】
処理ブロック５０６において、処理ロジックは、ユーザが現行モバイル・デバイスでゲームを行っていることを検出し、新ゲームを試すよう勧誘する広告を現行モバイル・デバイスに送る。
【００７４】
次に、処理ロジックは、新ゲームを試す旨のユーザ承諾を受信すると（処理ブロック５０８）、新ゲームのデモバージョンを現行モバイル・デバイスにダウンロードする（処理ブロック５１０）。
【００７５】
デモが課せられた制限（例えば、上級レベルに達する）によって停止になると、処理ロジックは、ユーザが新ゲームを購入したいか否かを尋ねるメッセージを送る。ユーザが新ゲームの購入を承諾すると（判断記号５１２）、処理ロジックは、ユーザがゲーム・アンロック基準を満たすか否かを判定する（判断記号５１４）。この判定が肯定の場合、処理ロジックは、ゲーム・アンロック・メッセージをモバイル・デバイスに送り（処理ブロック５１６）、ゲームをアンブロックさせる。あるいはまた、処理ロジックは、拒否メッセージを送り（処理ブロック５１８）、ユーザにゲームをアンロックできないことを通知する。
【００７６】
図６には、ゲーム・アンロック・プロセスの実施形態の１つが例示されている。ゲーム・アンロック・プロセスは、クライアント・アプリケーションを設けているユーザ・デバイスとゲーム管理システムの間で、ネットワークを介してメッセージ交換することによって実施される。ネットワークは、無線ネットワークまたはインターネットのような広域ネットワークである。ユーザ・デバイスは、モバイル・デバイス、パーソナル・コンピュータ、ゲーム機、家庭用電子機器などである。ユーザ・デバイスのクライアント・アプリケーションは、ゲームがロックされる場合には、制限されたゲーミング機能性（デモバージョンとして）を提供し、ゲームがアンロックされる場合には、完全な無制限のゲーミング機能性を提供するように構成されている。ユーザ・デバイスとゲーム管理システムの間で交換されるメッセージは、例えば、拡張可能マーク付け言語（ＸＭＬ）列の形をとるハイパーテキスト転送プロトコル（ＨＴＴＰ）・メッセージまたはショート・メッセージ・サービス（ＳＭＳ）・メッセージである。ゲーム管理システムは、全ての交換メッセージを記録する。
【００７７】
ゲーム・アンロック・プロセスは、ユーザ・デバイスが、ゲームのアンロックを要求するメッセージを送ることによって開始される。メッセージには、ユーザが購入しなかったゲームのタイトル、ユーザ・デバイスの識別子またはユーザＩＤ及びパスワードのようなユーザ識別情報が含まれる。
【００７８】
これに応答して、ゲーム管理システムは、ユーザ識別情報を認証し、ユーザ識別情報が有効であれば、ユーザ・デバイスに対して、タイトル・キーと共に、要求承認メッセージを戻す。あるいはまた、ユーザ識別情報が無効であれば、ゲーム管理システムは、ユーザ・デバイスに対して要求失敗メッセージを送り、アンチハッキング検出または他の何らかの問題を指示するものとして、失敗を記録する。
【００７９】
次に、ユーザ・デバイスが、要求承認メッセージを受信しない場合（例えば、ゲーム・アンロック・メッセージが送られた時、サービスが提供されない場合）、あるいは、要求失敗メッセージを受信する場合、ユーザ・デバイスは、要求失敗メッセージをユーザに表示する。あるいはまた、ユーザ・デバイスが、要求承認メッセージを受信する場合、ユーザ・デバイスは、ユーザ・デバイスに記憶されているタイトル・キーによって受信したタイトル・キーを認証する。２つのキーが一致すると、ユーザ・デバイスは、ゲームをアンロックし、ゲーム管理システムに対して、ユーザＩＤとゲーム・タイトルと共に、成功したアンロック・メッセージを送り、ゲーム管理システムは、成功したアンロック・メッセージを記憶し、ビリング・システムにビリング・メッセージを送り、ユーザ・デバイスに対して、結果生じる請求書作成業務に関する情報（例えば、「貴殿の口座に対し＄３．９９が請求されることになります．．．」）と共に、アンロックの承認を戻す。ユーザ・デバイスは、アンロック承認メッセージを受信して、ユーザに表示する。
【００８０】
ゲーム管理システムから受信したタイトル・キーが、ユーザ・デバイスに記憶されているタイトル・キーと一致しなければ、ユーザ・デバイスは、ゲームをロック状態に保ち、ゲーム管理システムに対してアンロック失敗メッセージを送り、ユーザにアンロック失敗メッセージを表示する。ゲーム管理システムは、アンチハッキング検出または他の何らかの問題を指示するものとして、失敗したアンロックを記録する。
【００８１】
実施形態によっては、ゲーム・アンロック機構を用いて、ゲームの各開始毎に１つ以上のコインを要求する標準アーケード・ゲームに似た、業務用ゲーム機のゲーム・モデルを使用可能にするものもある。業務用ゲーム機のゲーム・モデルによれば、ゲームは、完了すると、自動的にロックされる。ユーザは、ゲームの再開を要求すると、ゲームのアンロックを承認するように求められる。こうした承認が受信されると、ユーザ・アカウントに料金が請求され、ゲームは、次の完了までアンロックされる。あるいはまた、ユーザのゲーム・リプレイを促すため、再開要求に応答して、ユーザ・アカウントに対する信用取引を行うことも可能である。
【００８２】
さらに他の実施形態には、ゲーム・アンロック機構を用いて、ユーザ・デバイスで選択されたゲームの実施だけを許可する、バンドル・ゲーム・モデルを使用可能にするものもある。バンドル・ゲーム・モデルによれば、一群のゲーム（例えば、全カタログのゲーム）がユーザ・デバイスにダウンロードされ、次に、これらのゲームの一部が、アンロックされるが、他のゲームは、ロック状態のままである。アンロックするゲームの選択は、所定のビジネス・ルールに基づく。例えば、ユーザは、所定の期間（例えば、１ヶ月）について、ある特定の数のゲームまたは特定ゲームを申し込むことが可能であり、この申込み期間中、これらのゲームだけがアンロックされる。残りのゲームは、クライアント・デバイスに存在しても、その申込み期間中、機能しない。
【００８３】
図７〜１２はゲーム・アンロック・プロセスの各種実施形態を例示した流れ図である。
【００８４】
図７を参照すると、ゲーム・ロック・プロセス７００によって、クライアント・デバイスは、ゲーム管理システム（ＧＭＳ）・サーバが利用できない場合に、その後、利用される状況キャッシュを生成する。例えば、ＧＭＳサーバのサービスがダウンしている場合、クライアント・デバイスがネットワーク・アクセスできない場合、あるいは、他の何らかの理由で、ＧＭＳサーバを利用できない可能性がある。状況キャッシュは、ゲームの状況、ゲームが最後に行われた時点、ゲームが行われたモード等を明らかにする。
【００８５】
ブロック７０２において、クライアントにデモ・モード（すなわち、制限された機能性、発売前の広告挿入に関連したモード）で存在するアプリケーションが、ＧＭＳサーバにゲーム開始イベントを送る。
【００８６】
ブロック７０４において、クライアント・アプリケーションは、ＧＭＳサーバが連絡可能か否かを判定する。可能でなければ、クライアント・アプリケーションは、デモ・モードのゲーム開始を承認する（ブロック７２８）。可能であれば、クライアント・アプリケーションは、ユーザがゲームの完全な（無制限の）アンロックを承認できるようにする（ブロック７０６）。実施形態の１つでは、ユーザは、任意の利用可能な支払い機構を介してゲームの料金を支払うことによって、完全なアンロックを承認する。
【００８７】
ユーザが完全なアンロックを選択しない場合、クライアント・アプリケーションは、デモ・モードによるゲームの開始を承認する（ブロック７１０）。あるいはまた、ユーザが完全なアンロックを選択する場合、ＧＭＳサーバは、ＧＭＳサーバに関するユーザ・アカウントを確認し（または、新規ユーザのアカウントを作成し）（ブロック７１２）、クライアント・アプリケーションにデバイス状況キャッシュを生成するように命令し（ブロック７１４）、このゲームが、現在、このデバイスだけで起動中であるか否かを判定する（ブロック７１６）。そうであれば、ＧＭＳサーバは、クライアント・アプリケーションに対し、ユーザがこのゲームの使用を許可されたことを指示するデータによって、デバイス状況キャッシュを更新するように命令し（ブロック７２４）、完全モードによるゲーム開始の承認を送る（ブロック７２６）。
【００８８】
このゲームが、現在、２つ以上のデバイスで起動中の場合、ＧＭＳサーバは、クライアント・アプリケーションに対して、ユーザがこのゲームの使用を許可されていないことを指示するデータによって、デバイス状況キャッシュを更新するように命令し（ブロック７１８）、クライアント・アプリケーションにロック・コマンドを送る（ブロック７２０）。クライアント・アプリケーションは、ゲームをロックし、ビジネス・ルールに基づいて作成することが可能であり、ゲームのアンロック方法に関する命令を含むユーザ・フィードバックを表示する（ブロック７２２）。例えば、フィードバックには、ゲーム購入リンクを含み、さらにゲームが、このユーザのログイン時に別のハンドセットで起動中である旨の通知等を含む。さらに、文脈依存型ヘルプを提供することが可能である（例えば、家族の他の誰かが別のデバイスでログインしていないことを確認した後、再試行するようにユーザに求めるメッセージ）。
【００８９】
図８を参照すると、ゲーム・アンロック・プロセス８００によって、クライアント・デバイスは、ＧＭＳサーバが利用できない場合、状況キャッシュを利用することが可能になる。状況キャッシュは、ゲームの状況、ゲームが最後に行われた時点、ゲームが行われたモード、試行期間の条件等を明らかにする。
【００９０】
ブロック８０２において、クライアントに存在するアプリケーションは、ＧＭＳサーバにゲーム開始イベントを送る。
【００９１】
ブロック８０４において、クライアント・アプリケーションは、ＧＭＳサーバが連絡可能であるか否かを判定する。可能でなければ、クライアント・アプリケーションは、クライアント・デバイスに存在する状況キャッシュを読み取る（ブロック８０６）。状況キャッシュに、データが含まれていない場合（ブロック８０８）、クライアント・アプリケーションは、状況キャッシュを更新し（ブロック８１０）、デモ・モードによるゲームの開始を承認する（ブロック８１２）。
【００９２】
状況キャッシュにデータが含まれている場合（ブロック８０８）、クライアント・アプリケーションは、キャッシュ・データが、ユーザがデモ・モードによるゲームの実施を許可されていることを示しているのか、または、完全モードによるゲームの実施を許可されていることを示しているのかを判定する（ブロック８１４）。ユーザが、完全モードによるゲームの実施を許可されている場合、クライアント・アプリケーションは、完全モードによるゲームの開始を承認する（ブロック８１６）。
【００９３】
ユーザがデモ・モードによるゲームの実施を許可されている場合、クライアント・アプリケーションは、デモ・モードが期限切れになっているか否かをチェックする（ブロック８１８）。期限切れでなければ、デモ・モードでゲームが開始される（ブロック８２０）。期限切れの場合、クライアント・アプリケーションは、状況キャッシュを更新し（ブロック８２２）、ゲームをロックし（ブロック８４０）、ビジネス・ルールに基づいて作成することが可能であり、ゲームのアンロック方法に関する情報と文脈依存型ヘルプを含むフィードバックをユーザに表示する（ブロック８４２）。
【００９４】
ＧＭＳサーバが連絡可能であれば（ブロック８０４）、クライアント・アプリケーションは、ＧＭＳサーバに対して、ユーザのアンロック状況を確認するように求める（ブロック８２４）。ＧＭＳサーバは、次に、ゲームが試行モード（例えば、評価のため、無料で楽しめるようにダウンロードされたもの）であるか否かを判定する（ブロック８２６）。そうであれば、ＧＭＳサーバは、試行モードがまだ有効であるか否かを判定する（例えば、許可された試行回数、許可された時間期間等のようなビジネス・ルールを用いて）（ブロック８３４）。試行モードがまだ有効であれば、ＧＭＳサーバは、試行モードによるゲーム開始を承認する（ブロック８３６）。
【００９５】
試行モードがもはや有効ではなければ、ＧＭＳサーバは、クライアント・アプリケーションに対して、デバイス状況キャッシュを更新するように命令し（ブロック８３８）、クライアント・アプリケーションにロック・コマンドを送るが（ブロック８４０）、その結果、ゲームがロックされ、ユーザにフィードバックが表示される（ブロック８４２）。
【００９６】
ゲームが試行モードでなければ（すなわち、製品モードにある）（ブロック８２６）、ＧＭＳサーバは、クライアント・アプリケーションに対して、デバイス状況キャッシュを更新するように命令し（ブロック８２８）、ゲームが有効であるか否か（例えば、ユーザが既に購入済みであるか否か）を判定する（ブロック８３０）。有効でなければ、ＧＭＳサーバは、クライアント・アプリケーションにロック・コマンドを送り（ブロック８４０）、これによって、ゲームがロックされ、ユーザにフィードバックが表示される（ブロック８４２）。有効であれば、ＧＭＳサーバは、このゲームが、現在、このデバイスだけで起動中であるか否かを判定する（ブロック８３２）。そうであれば、ＧＭＳサーバは、完全モードによるゲームの開始の承認を送る（ブロック８１６）。
【００９７】
このゲームが、現在、２つ以上のデバイスで起動中の場合、ＧＭＳサーバは、クライアント・アプリケーションにロック・コマンドを送る（ブロック８４０）。クライアント・アプリケーションは、その結果、ゲームをロックし、ユーザにフィードバックを表示する（ブロック８４２）。
【００９８】
図９を参照すると、ゲーム・アンロック・プロセス９００によって、クライアント・デバイスは、ＧＭＳサーバが利用できない場合、完全アンロック・モードのために状況キャッシュを利用することが可能になる。
【００９９】
ブロック９０２において、クライアントに存在するアプリケーションは、ＧＭＳサーバにゲーム開始イベントを送る。
【０１００】
ブロック９０４において、クライアント・アプリケーションは、ＧＭＳサーバが連絡可能であるか否かを判定する。連絡可能でなければ、クライアント・アプリケーションは、クライアント・デバイスに存在する状況キャッシュを読み取る（ブロック９０６）。状況キャッシュにデータが含まれていなければ（ブロック９０８）、クライアント・アプリケーションは、ゲームをロックし（ブロック９１８）、ユーザにフィードバックを表示する（ブロック９２０）。
【０１０１】
状況キャッシュにデータが含まれていると（ブロック９０８）、クライアント・アプリケーションは、キャッシュ・データが、ユーザが完全モードによるゲームの実施を許可されていることを示しているか否かを判定する（ブロック９１０）。許可されている場合、クライアント・アプリケーションは、完全モードによるゲームの開始を承認する（ブロック９１２）。
【０１０２】
ユーザが完全モードによるゲームの実施を許可されていなければ、クライアント・アプリケーションは、ゲームをロックし（ブロック９１８）、ユーザにフィードバックを表示する（ブロック９２０）。
【０１０３】
ＧＭＳサーバが連絡可能であれば、クライアント・アプリケーションは、ＧＭＳサーバと共にユーザのアンロック状況を確認する（ブロック９１４）。ゲームが登録されている（例えば、既に購入済みである）場合（ブロック９１６）、ＧＭＳサーバは、クライアント・アプリケーションに対して、デバイス状況キャッシュを更新するように命令し（ブロック９１７）、このゲームが、現在、このデバイスだけで起動中であるか否かを判定する（ブロック９１９）。そうであれば、ＧＭＳサーバは、クライアント・アプリケーションに対して、ユーザがこのゲームの使用を許可されていることを指示するデータによって、デバイス状況キャッシュを更新するように命令し（ブロック９２４）、完全モードによるゲーム開始の承認を送る（ブロック９２６）。
【０１０４】
このゲームが、現在、２つ以上のデバイスで起動中の場合、ＧＭＳサーバは、クライアント・アプリケーションに対して、ユーザがこのゲームの使用を許可されていないことを指示するデータによって、デバイス状況キャッシュを更新するように命令し（ブロック９２２）、クライアント・アプリケーションに対してロック・コマンドを送る（ブロック９１８）。クライアント・アプリケーションは、ゲームをロックし、ユーザにフィードバックを表示する（ブロック９２０）。
【０１０５】
ゲームが登録されていない（例えば、これまでに購入済みではない）場合（ブロック９１６）、ＧＭＳサーバは、クライアント・アプリケーションにロック・コマンドを送る（ブロック９１８）。クライアント・アプリケーションは、ゲームをロックし、ユーザにフィードバックを表示する（ブロック９２０）。
【０１０６】
図１０を参照すると、ゲーム・リース（例えば、ユーザが所定の期間にわたるゲームのリース料金を支払う）に関連したゲーム・アンロック・プロセス１０００によって、クライアント・デバイスは、ＧＭＳサーバが利用できない場合に、完全アンロック・モードのために状況キャッシュを利用することが可能になる。状況キャッシュは、ゲームの状況、ゲームが最後に行われた時点、ゲームが行われたモード、リース条件等を明らかにすることが可能である。
【０１０７】
ブロック１００２において、クライアントに存在するアプリケーションは、ＧＭＳサーバにゲーム開始イベントを送る。
【０１０８】
ブロック１００４において、ゲーム・アプリケーションは、ＧＭＳサーバが連絡可能であるか否かを判定する。連絡可能でなければ、クライアント・アプリケーションは、クライアント・デバイスに存在する状況キャッシュを読み取る（ブロック１００６）。状況キャッシュにデータが含まれていなければ（ブロック１００８）、クライアント・アプリケーションは、ゲームをロックし（ブロック１０１８）、ユーザにフィードバックを表示する（ブロック１０２０）。
【０１０９】
状況キャッシュにデータが含まれている場合（ブロック１００８）、クライアント・アプリケーションは、キャッシュ・データが、ユーザが完全モードによるリース・ゲームの実施を許可されていることを指示しているか否かの判定を行う（ブロック１０１０）。許可されている場合、クライアント・アプリケーションは、完全モードによるゲームの開始を承認する（ブロック１０１２）。
【０１１０】
ユーザが、完全モードによるリース・ゲームの実施を許可されていない場合、クライアント・アプリケーションは、ゲームをロックし（ブロック１０１８）、ユーザにフィードバックを表示する（ブロック１０２０）。
【０１１１】
ＧＭＳサーバが連絡可能であれば、クライアント・アプリケーションは、ＧＭＳサーバと共にユーザのリース状況を確認する（ブロック１０１４）。ゲームが登録されている（例えば、ユーザがゲームのリース料金を支払っている）場合（ブロック１０１６）、ＧＭＳサーバは、クライアント・アプリケーションに対して、デバイス状況キャッシュを更新するように命令し（ブロック１０２２）、このゲームが、現在、このデバイスだけで起動中であるか否かを判定する（ブロック１０２４）。そうであれば、ＧＭＳサーバは、クライアント・アプリケーションに対して、ユーザがこのゲームの使用を許可されていることを指示するデータによって、デバイス状況キャッシュを更新するように命令し（ブロック１０２８）、完全モードによるゲーム開始の承認を送る（ブロック１０３０）。
【０１１２】
このゲームが、現在、２つ以上のデバイスで起動中の場合、ＧＭＳサーバは、クライアント・アプリケーションに対して、ユーザがこのゲームの使用を許可されていないことを指示するデータによって、デバイス状況キャッシュを更新するように命令し（ブロック１０２６）、クライアント・アプリケーションに対してロック・コマンドを送る（ブロック１０１８）。クライアント・アプリケーションは、ゲームをロックし、ユーザにフィードバックを表示する（ブロック１０２０）。実施形態の１つでは、ＧＭＳサーバは、ユーザ・アカウント／ゲームの組み合わせに関するロック・コマンドを出す。すなわち、ユーザがそのアカウント情報を他のユーザと共有する場合、このアカウント／ゲーム組み合わせの全てのインスタンスが、ロックされて、ユーザはそのアカウント情報の共有を抑制することになる。
【０１１３】
ゲームが登録されていない（例えば、ユーザがリース料金を支払っていないか、または、リース期限が切れている）場合（ブロック１０１６）、ＧＭＳサーバは、クライアント・アプリケーションにロック・コマンドを送る（ブロック１０１８）。クライアント・アプリケーションは、ゲームをロックし、ユーザにフィードバックを表示する（ブロック１０２０）。
【０１１４】
図１１を参照すると、業務用ゲーム機のゲーム・モデルに関連したゲーム・アンロック・プロセス１１００によって、クライアント・デバイスは、ＧＭＳサーバが利用できない場合に、完全アンロック・モードのために状況キャッシュを利用することが可能になる。状況キャッシュは、ゲームの状況、ゲームが最後に行われた時点、ゲームが行われたモード、ゲームの再開毎に請求される、ユーザの電子財布アカウントの状況等を明らかにすることが可能である。
【０１１５】
ブロック１１０２において、クライアントに存在するアプリケーションは、ＧＭＳサーバにゲーム開始イベントを送る。
【０１１６】
ブロック１１０４において、ゲーム・アプリケーションは、ＧＭＳサーバが連絡可能であるか否かを判定する。連絡可能でなければ、クライアント・アプリケーションは、クライアント・デバイスに存在する状況キャッシュを読み取る（ブロック１１０６）。状況キャッシュにデータが含まれていなければ（ブロック１１０８）、クライアント・アプリケーションは、ゲームをロックし（ブロック１１３０）、ユーザにフィードバックを表示する（ブロック１１３２）。
【０１１７】
状況キャッシュにデータが含まれている場合（ブロック１１０８）、クライアント・アプリケーションは、キャッシュ・データが、ユーザの電子財布アカウントが有効であり、資金を有していることを示しているか否かの判定を行う（ブロック１１１０）。そうであれば、クライアント・アプリケーションは、キャッシュにデビット・イベントを記憶し、最新の分っている預金残高と対照して負債を累算し（ブロック１１１２）、完全モードによるゲームの開始を承認する（ブロック１１１４）。
【０１１８】
キャッシュ・データが、ユーザの電子財布アカウントが有効ではないか、あるいは、資金を有していないことを示す場合、クライアント・アプリケーションは、ゲームをロックし（ブロック１１３０）、ユーザにフィードバックを表示する（ブロック１１３２）。
【０１１９】
ＧＭＳサーバが連絡可能である場合、クライアント・アプリケーションは、ＧＭＳサーバと共にユーザの電子財布アカウントの状況を確認する（ブロック１１１６）。このゲームの開始料金を賄うのに十分なクレジットが利用できる場合（ブロック１１１８）、ＧＭＳサーバは、開始料金の額だけ電子財布アカウントの借方につけ（ブロック１１２０）、クライアント・アプリケーションに対して、デバイス状況キャッシュを更新するように命令し（ブロック１１２２）、完全モードによるゲーム開始の承認を送る（ブロック１１２４）。実施形態の１つでは、ユーザは、支払請求可能なイベントが生じる毎に、その電子財布と対照して料金を承認するように求められる。代替実施形態では、ユーザの承認を求めることなく、電子財布に自動的に勘定がつけられる。
【０１２０】
電子財布アカウントに、このゲームの開始料金を賄うのに十分な資金がなければ（ブロック１１１８）、ＧＭＳサーバは、電子財布に再入金する解決法を呼び出し、ユーザに対して、電子財布アカウントに資金を追加するように勧める（ブロック１１２６）。ユーザがアカウントに十分な資金を追加すると、ＧＭＳサーバは、ブロック１１２０に戻る。さもなければ、ＧＭＳサーバは、クライアント・アプリケーションにロック・コマンドを送る（ブロック１１３０）。クライアント・アプリケーションは、ゲームをロックして、ユーザにフィードバックを表示する（ブロック１１３２）。
【０１２１】
代替実施形態において、ユーザの電子財布アカウントは、ゲーミング・パラメータ（例えば、高スコア等）に基づいて信用取引が可能である。例えば、ユーザが請求することが可能な賞金（例えば、ゲームまたは、他のプレミアム・アプリケーション・サービスに関する）としての電子財布通貨によって、コンテストを維持することが可能である。この通貨は、実際の電子財布通貨とは別個に監視することができるので、例えば、賞金通貨で１０のアプリケーションを購入したユーザが、課せられる料金について信用取引を要求することはできないし、仮想通貨から実際の通貨への変換が許可されることもあり得ない。
【０１２２】
さらに他の実施形態の場合、プレミアムＳＭＳメッセージを利用して、ユーザの電子財布アカウントに「請求する」ことが可能である（例えば、通信事業者に直接請求書を送ることができない場合）。例えば、ユーザは、アカウントにユーザの電話番号を登録することが可能であり、ＧＭＳサーバにＳＭＳメッセージを送る。これによって、プレミアムＳＭＳ応答がトリガされ、受け入れられれば、プレミアムＳＭＳメッセージの値がユーザの電子財布アカウントの貸方に記入される。従って、これは、ユーザがつけで支払うことが可能な（アンロック、リース、業務用ゲーム機等のために）仮想バンクになる。使い果たすと、業務用ゲーム機モデルや任意の反復リース・モデルは、電子財布アカウントに再入金されるまで、「失効」する。例えば、リース・モデルによって決められた反復使用料が存在する可能性があり（例えば、スポーツ・パッケージは毎月５ドルかかる）、従って、これは、電子財布アカウントの借方に記入されるか、代替清算機関（スポーツ・リーグ、通信事業者自体等）に請求書が送られる可能性がある。次に、この請求が受け入れられるか、拒否されるかに応じて、アンロック機構は、然るべく応答する。
【０１２３】
上記方法の組み合わせも可能である。例えば、新規ユーザまたは入金相殺の履歴のあるユーザに関するファイルでは、最小限の信用取引を堅持することが可能であり、ユーザは、規定の下限の信用取引（例えば、５ドル）を行うことが可能になる。この限界に達すると、ＧＭＳサーバは、通信事業者または他のビリング・プロバイダにリアルタイムで請求処理を試みることが可能であるが、アプリケーションは、残高が０に達するまで、依然として機能することが可能である。
【０１２４】
図１２を参照すると、プレミアムＳＭＳメッセージを利用するゲーム・アンロック・プロセス１２００が例示されている。プロセス１２００は、デモ・モードによる組み込みゲームを提供する通信事業者のシステムによって実施可能である。
【０１２５】
ブロック１１０２において、クライアント・アプリケーションは、ユーザに対し、ユーザのクライアント・デバイスに送られるプレミアムＳＭＳメッセージによって、完全アンロックを承認するように促すメニューを表示する。
【０１２６】
ブロック１２０４において、クライアント・アプリケーションは、ユーザがプレミアムＳＭＳメッセージによる完全アンロックの要求を承諾するか否か（すなわち、ユーザがプレミアムＳＭＳの金額を支払うことを承諾するか否か）を判定する。承諾しなければ、クライアント・アプリケーションは、デモ・モードによるゲームの開始を承認する（ブロック１２０６）。承諾すれば、クライアント・アプリケーションは、ＳＭＳ要求を送り（ブロック１２０８）、ユーザがＳＭＳ購入の続行を選択するか否かを判定する（ブロック１２１０）。
【０１２７】
ユーザがＳＭＳ購入の続行を望まない場合、クライアント・アプリケーションは、デモ・モードによるゲーム開始を承認する（ブロック１２０６）。さもまければ、プレミアムＳＭＳメッセージが、ユーザのクライアント・デバイスに送られる（ブロック１２１２）。ユーザがプレミアムＳＭＳメッセージを受け入れると（ブロック１２１４）、ＳＭＳペイロードが、クライアント・アプリケーションによって解釈され、完全機能性が使用可能になり（ブロック１２１６）、その結果、アプリケーションが完全モードでアンロックされる（ブロック１２１８）。
【０１２８】
ユーザがプレミアムＳＭＳメッセージを受け入れなければ（ブロック１２１４）、クライアント・アプリケーションは、デモ・モードによるゲーム開始を承認する（ブロック１２０６）。
【０１２９】
典型的なコンピュータ・システム
図１３は、本明細書に解説の１つ以上のオペレーションを実施するために利用することが可能な、典型的なコンピュータ・システム１３００のブロック図である。代替実施形態の場合、この機械には、ネットワーク・ルータ、ネットワーク・スイッチ、ネットワーク・ブリッジ、携帯端末（ＰＤＡ）、携帯電話、ウェブ機器、または、その機械が行うべき動作を指定する一連の命令を実行することが可能な任意の機械を含む。
【０１３０】
コンピュータ・システム１３００には、バス１３０８を介して相互通信する、プロセッサ１３０２、主メモリ１３０４、スタティック・メモリ１３０６が含まれている。コンピュータ・システム１３００には、さらに、ビデオ・ディスプレイデバイス１３１０（例えば、液晶ディスプレイ（ＬＣＤ）またはブラウン管（ＣＲＴ））を含む。コンピュータ・システム１３００には、英数字入力デバイス１３１２（例えば、キーボード）、カーソル制御デバイス１３１４（例えば、マウス）、ディスク・ドライブデバイス１３１６、信号発生デバイス１３２０（例えば、スピーカ）、ネットワーク・インターフェイスデバイス１３２２も含まれている。
【０１３１】
ディスク・ドライブデバイス１３１６には、上述の技法の任意の１つまたは全てを具現化した命令集合（すなわち、ソフトウェア）１３２６が記憶されている、コンピュータ可読媒体１３２４が含まれている。ソフトウェア１３２６は、完全にまたは少なくとも部分的に、主メモリ１３０４及び／またはプロセッサ１３０２内に納めれている。ソフトウェア１３２６は、さらに、ネットワーク・インターフェイスデバイス１３２２を介して送信または受信することが可能である。本明細書の目的上、「コンピュータ可読媒体」という用語は、コンピュータによって実行するための一連の命令を記憶または符号化することが可能であり、コンピュータに本発明の技法の任意の１つを実施させる、任意の媒体を含むものと解釈しなければならない。「コンピュータ可読媒体」という用語は、従って、制限するわけではないが、固体メモリ、光ディスクと磁気ディスク、搬送波信号を含むものと解釈しなければならない。
【０１３２】
上記説明の読了後、通常の当該技術者であれば、きっと、本発明の多くの改変及び修正が明らかになるであろうが、もちろん、例証のため示され、解説されたどの特定の実施形態も、決して制限とみなされることを意図したものではない。従って、各種実施形態の細部に対する言及は、それ自体、本発明にとって必須であるとみなされる特徴だけを列挙した請求の範囲を制限することを意図したものではない。
【図面の簡単な説明】
【０１３３】
【図１】本発明の実施形態が機能するシステムの実施形態の１つに関するブロック図である。
【図２Ａ】ゲーム管理システムの実施形態の１つのブロック図である。
【図２Ｂ】ゲーミング・データ・モジュールの実施形態の１つのブロック図である。
【図３】ユーザ・デバイスによる電子ゲームの使用を制御するためのプロセスに関する２つの実施形態の流れ図である。
【図４】ユーザ・デバイスによる電子ゲームの使用を制御するためのプロセスに関する２つの実施形態の流れ図である。
【図５】ゲーム広告プロセスの実施形態の１つの流れ図である。
【図６】ゲーム・アンロック・プロセスの実施形態の１つを例示した図である。
【図７】ゲーム・アンロック・プロセスの各種実施形態を例示した図である。
【図８】ゲーム・アンロック・プロセスの各種実施形態を例示した図である。
【図９】ゲーム・アンロック・プロセスの各種実施形態を例示した図である。
【図１０】ゲーム・アンロック・プロセスの各種実施形態を例示した図である。
【図１１】ゲーム・アンロック・プロセスの各種実施形態を例示した図である。
【図１２】ゲーム・アンロック・プロセスの各種実施形態を例示した図である。
【図１３】典型的なコンピュータ・システムのブロック図である。
【技術分野】
【０００１】
本発明は、無線ゲームに関するものであり、とりわけ、本発明は、ユーザ・デバイスにおけるゲーム使用の制御に関するものである。
【背景技術】
【０００２】
今日の現代世界では、電子ゲームが娯楽産業の主要部分になっている。独立型端末で行う電子ゲームが流行するようになってからずいぶん時が経つ。しかし、昨今は、これらのゲームが、無線ネットワーク環境を含むネットワーク環境に移行してきた。
【０００３】
無線ネットワーク環境の場合、一般に、電子ゲームのメーカや出版社が、エンドユーザと直接交流することはない。すなわち、エンドユーザは、通常、無線通信事業者（例えば、ＡＴ＆Ｔ（登録商標）、Ｓｐｒｉｎｔ ＰＣＳ（登録商標）、Ｖｅｒｉｚｏｎ（登録商標）等）から電子ゲームを購入し、ゲーム関連サービスを受ける。結果として、ゲーム・プレーヤのコミュニティは、特定無線通信事業者のユーザに制限される。さらに、電子ゲームのメーカや出版社は、ゲーム・プレーヤとの直接的な関係を発展させることができないので、ゲーム・プレーヤに関する詳細な情報を収集し、新しいゲームのターゲットを絞った広告を促進することができない。さらに、ユーザが、無線通信事業者の１つからゲームを購入し、その後、異なる無線通信事業者の携帯電話に切り替える場合、ユーザは、新しい携帯電話でそのゲームをできるようにするためには、異なる無線通信業者からもう一度このゲームを購入しなければならない。
【発明の開示】
【課題を解決するための手段】
【０００４】
ユーザ・デバイスにおけるゲーム使用を制御するための方法及びシステムについて解説する。態様の１つにおいて、この方法には、第１のユーザ・デバイスのためにユーザが選択したゲームを識別するステップと、そのゲームが、第２のユーザ・デバイスのためにユーザによって既に購入済みのものであることを確認するステップと、第１のユーザ・デバイスで楽しむために、ユーザがそのゲームを使用できるようにするステップが含まれている。
【０００５】
本発明の他の特徴については、添付の図面及び下記の詳細説明から明らかになるであろう。
【発明を実施するための最良の形態】
【０００６】
本発明については、下記の詳細な説明、本発明のさまざまな実施形態に関する添付の図面からより完全な理解が得られるが、それらは、本発明を特定の実施形態に制限するものと理解すべきではなく、説明を行い、理解を得るためのものでしかない。
【０００７】
ユーザ・デバイスにおけるゲーム使用を制御するための方法及びデバイスが明らかにされる。以下の説明では、多くの細部にわたる記述がなされる。しかしながら、当該技術者には明らかなように、本発明は、これら具体的な詳述がなされなくても、実施可能である。他の例では、周知の構造やデバイスは、本発明を曖昧にするのを避けるため、細部にわたってではなく、ブロック図の形で示されているものもある。
【０００８】
以下の詳細な説明の一部には、コンピュータ・メモリ内におけるデータ・ビットに関するオペレーションのアルゴリズム表現や記号表現として提示されているものもある。これらのアルゴリズムの記述や表現は、データ処理技術者によって、他の当該技術者にその作業の主題を最も有効に伝達するために用いられる手段である。アルゴリズムは、ここでは、一般に、所望の結果をもたらすことになる、首尾一貫した一連のステップである。これらのステップは、物理量の物理的操作を必要とするものである。通常、必ずしもそうとは限らないが、これらの量は、記憶、転送、組み合わせ、比較、あるいは、別様のオペレーション可能な電気または磁気信号の形をとる。時には、主として共通使用のため、これらの信号を、ビット、値、要素、記号、文字、項、数等と呼ぶのが好都合であることが立証されている。
【０００９】
しかしながら、これらの用語及び同様の用語の全てが、適合する物理的量に関連していなければならず、これらの量に適用される、単なる好都合なラベルにすぎないという点に留意すべきである。下記論考から明らかなように、特に別段の指定のない限り、説明の全体を通じて、「処理」または「計算」または「算出」または「決定」または「表示」等のような用語を用いる論考は、コンピュータ・システムのレジスタやメモリ内における物理的（電子的）量として表現されるデータを操作して、コンピュータ・システムのメモリまたはレジスタ、あるいは、他のこうした情報記憶、伝送、または、表示デバイス内における物理的量として同様に表現される他のデータに変換する、コンピュータ・システム、または、同様の電子計算デバイスの動作及びプロセスに言及するものである。
【００１０】
本発明は、また、本明細書のオペレーションを実施するためのデバイスに関連するものである。このデバイスは、要求される目的に合わせて特別に構成することが可能であり、あるいは、コンピュータに記憶されたコンピュータ・プログラムによって、選択的に起動または再構成される汎用コンピュータを含むことが可能である。こうしたコンピュータ・プログラムは、制限するわけではないが、フロッピ・ディスク、光ディスク、ＣＤ−ＲＯＭ、磁気光ディスクのような任意のタイプのディスク、読み取り専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気または光カード、または、電子命令の記憶に適した任意のタイプの媒体のような、それぞれ、コンピュータ・システム・バスに結合された、コンピュータ可読記憶媒体に記憶することが可能である。
【００１１】
本明細書に提示のアルゴリズム及び表示は、本質的に、いかなる特定のコンピュータまたは他のデバイスにも関連するものではない。本明細書の教示によるプログラムには、さまざまな汎用システムを用いることもできるし、あるいは、必要とされる方法ステップの実施により特化されたデバイスを作り上げるのが好都合であると立証される場合もある。これらのさまざまなシステムに必要な構造は、下記の説明から明らかになるであろう。さらに、本発明の説明は、いかなる特定のプログラム言語にも関連したものではない。さまざまなプログラム言語を利用して、本明細書に記載の本発明の教示を実施することができるのは明らかである。
【００１２】
機械可読媒体には、機械（例えば、コンピュータ）による読み取りが可能な形式の情報を記憶または伝送するための任意のメカニズムが含まれる。例えば、機械可読媒体には、読み取り専用メモリ（「ＲＯＭ」）、ランダム・アクセス・メモリ（「ＲＡＭ」）、磁気ディスク記憶媒体、光記憶媒体、フラッシュ・メモリデバイス、電気、光、音響、または、他の形態の伝搬信号（例えば、搬送波、赤外線信号、ディジタル信号等）などが含まれる。
【００１３】
概要
本発明の実施形態によって、電子ゲームのプロバイダは電子ゲームのプレーヤの使用を管理することが可能になる。電子ゲームのプロバイダには、ゲーム・メーカ、ゲーム出版社、無線通信事業者、または、電子ゲームへのユーザ・アクセスを制御する任意の他のエンティティを含むことが可能である。
【００１４】
図１は、本発明の実施形態が機能することが可能なシステム１００の実施形態の１つに関するブロック図である。システム１００には、広域ネットワーク（例えば、インターネット）１０４、無線ネットワーク１０６、クライアント・デバイス１０８、１１０、ゲーム管理システム１０２が含まれている。
【００１５】
クライアント・デバイス１０８は、無線ネットワーク１０６を介してゲーム管理システム１０２に結合されたモバイル・デバイスである。モバイル・デバイス１０８は、そのユーザが無線ゲームを行えるようにすることが可能な、対話型双方向通信デバイスである。例えば、モバイル・デバイス１０８は、無線電話、手のひらサイズの計算デバイス、携帯端末（ＰＤＡ）等とすることが可能である。こうした双方向通信デバイスは、無線ネットワーク１０６を介して、ゲーム管理システム１０２と無線通信することが可能である。ゲーム管理システム１０２とモバイル・デバイス１０８との間の通信は、対応する無線通信事業者（例えば、ＡＴ＆Ｔ（登録商標）、Ｓｐｒｉｎｔ ＰＣＳ（登録商標）、Ｖｅｒｉｚｏｎ（登録商標）等）によって提供される。
【００１６】
クライアント・デバイス１１０は、広域ネットワーク（例えば、インターネット）を介してゲーム管理システム１０２に結合されている。クライアント・デバイス１０８は、そのユーザが、ゲーム機用ゲーム、ウェブ・ゲーム、または、パーソナル・コンピュータ（ＰＣ）・ゲームを行えるようにすることが可能な、対話型双方向通信デバイスである。例えば、クライアント・デバイス１１０は、ＰＣシステム、携帯端末（ＰＤＴ）、プレイ・ステーション、家庭用電子機器等とすることが可能である。
【００１７】
実施形態の１つでは、クライアント・デバイス１０８、１１０は、関連クライアント・デバイス１０８、１１０で行われるゲームに関連したデータを収集して、このデータをゲーム管理システム１０２に提供する、ゲーミング・データ・モジュール１１２のようなクライアント・ベースのアプリケーションを提供する。実施形態の１つでは、ゲーミング・データ・モジュール１１２は、関連クライアント・デバイス１０８または１１０のプラットフォームをベースにして構成される。実施形態の１つでは、ゲーミング・データ・モジュール１１２は、関連クライアント・デバイス１０８または１１０において行われるゲームに組み込まれる。もう１つの実施形態では、ゲーミング・データ・モジュール１１２は、関連クライアント・デバイス１０８または１１０に常駐する独立アプリケーションである。
【００１８】
ゲーム管理システム１０２は、クライアント・デバイス１０８、１１０にゲームを配備し、管理し、サポートするサービスを提供し、従って、さまざまなデバイスのプラットフォーム（例えば、ＰＣプラットフォーム、無線デバイスプラットフォーム、ウェブ・ベースのハンド・ヘルド式デバイスのプラットフォーム、ゲーム機プラットフォーム等）に対してゲーム・サービスを提供する。ゲーム管理システム１０２は、ゲーム・メーカ、ゲーム出版社、ネットワーク通信事業者、または、他の任意のゲーム・サービス・プロバイダによって保守することが可能である。
【００１９】
実施形態の１つでは、ゲーム管理システム１０２は、ゲーミング・データ・モジュール１１２と協働して、クライアント・デバイス１０８、１１０におけるアプリケーションとの双方向メッセージ通信を可能にする。実施形態の１つでは、ゲーミング・データ・モジュール１１２は、ゲーム管理システム１０２にメッセージを転送し（クライアント・デバイスがネットワークから切断されている場合には、メッセージを記憶し）、ゲーム管理システム１０２によって促進される、ゲーム中リアルタイム機能（例えば、ゲーム中広告、マルチプレーヤ・ゲーム・プレイ、ユーザ登録、ゲーム・メトリクス収集等）をサポートする。
【００２０】
実施形態の１つにおいて、ゲーム管理システム１０２のスケーラビリティが、複数サーバを利用することによって得られる。例えば、各タイプのクライアント・アプリケーションは、１つ以上の指定サーバと関連づけることが可能である。さらに、無線クライアント・アプリケーションの場合、各無線通信事業者は、１つ以上の指定サーバと関連づけられる。例えば、各通信事業者は、指定データベース・サーバ（例えば、４−ＣＰＵデータベース・サーバ）と随伴するアプリケーション・サーバ（例えば、６つのウェブ・アプリケーション・サーバ）に関連付けられる。あるいはまた、無線通信事業者によっては、サーバを共用する場合もある。サーバまたはサーバ・グループのどれかに機能が不十分なものがあれば、システムは、別のサーバ・グループによって関連通信事業者のユーザにサービスを提供するように再構成される。
【００２１】
ゲーム管理システム
図２Ａは、ゲーム管理システム２００の実施形態の１つに関するブロック図である。実施形態の１つでは、ゲーム管理システム２００は、モバイル・ゲームまたは無線ゲームをサポートする。もう１つの実施形態では、ゲーム管理システム２００は、ＰＣゲーム、ウェブ・ゲーム、ゲーム機用ゲームといった他のタイプのゲームもサポートする。
【００２２】
ゲーム管理システム２００は、ユーザ登録モジュール２０２、ゲーム使用コントローラ２０４、ゲーム・メトリクス・コレクタ２０６、マルチプレーヤ・ゲームプレイ・サポータ２０８、広告モジュール２１０、ビリング・モジュール２１２、ゲーム・ダウンロード・モジュール２１４、バージョニング・モジュール２２２、ユーザ・アカウント・マネージャ２２４、ゲーム・ファインダ２２６、ユーザ・データベース２１６、ゲーム・メトリクス・データベース２１８、ビリング・データベース２２０、及び／または、図２には示されていない他の各種モジュールを含むことが可能である。
【００２３】
ユーザ登録モジュール２０２は、新規ユーザを登録し、ユーザ・データベース２１６に新規ユーザの識別情報を記憶し、既存のユーザのログインを容易にする責務を担っている。ユーザ登録プロセスは、ゲーム管理システム２００に関連したウェブサイトにおける登録リンクをユーザが起動するか、ユーザのクライアント・デバイス１０８または１１０にユーザがゲームをダウンロードするように要求するか、ユーザが新ゲームを開始しようとするか、あるいは、ユーザが他の任意のイベントを開始すると、呼び出しが可能になる。ユーザ識別情報には、例えば、ユーザＩＤ、パスワード、Ｅメール・アドレス、ユーザによって選択されたゲームに関連する一意性コード等を含むことが可能である。
【００２４】
ゲーム使用コントローラ２０４は、新ゲームのユーザ購入に関連した情報を受信し、ユーザ・データベース２１６にこの情報を記憶し、各種ユーザ・デバイスにおけるこのゲームの使用を制御する責務を担っている。ゲーム使用コントローラ２０４は、ゲーム管理システム２００によって購入が促進される場合には、ビリング・モジュール２１０からの、ユーザがゲーム管理システムにゲームを登録する場合には、ユーザ登録モジュール２０２からの、あるいは、新ゲームの購入を促進する外部システムからの、新ゲームの購入に関連した情報を受信することが可能である。実施形態の１つでは、ユーザが、ある特定モバイル・デバイス１０６のために新ゲームを購入する場合、ゲーム使用コントローラ２０４は、ユーザ・データベース２１６にその購入を記録する。その後、ユーザが、異なるモバイル・デバイスのためにこのゲームを選択すると、ゲーム使用コントローラ２０４は、ユーザ・データベース２１６において選択されたゲームに関連した記録を見つけ出し、他のモバイル・デバイスで楽しむために、このゲームをユーザが利用できるようにする。実施形態の１つにおいて、ゲーム使用コントローラ２０４は、ＰＣ、ハンドヘルド式コンピュータ、ゲーム機、または、他の任意のデバイス１０８で楽しむために、ユーザがモバイル・デバイス１０６用に購入したゲームを利用できるようにことも可能である。同様に、実施形態の１つにおいて、ゲーム使用コントローラ２０４は、ユーザが非モバイル・デバイス１０８用に購入したゲームを、ユーザがモバイル・デバイス１０６で楽しむために利用できるようにすることも可能である。さらに、ゲーム使用コントローラ２０４は、ユーザがクライアント・デバイスからのゲームを既に消去済みの場合（例えば、スペースを考慮して）、同じクライアント・デバイスにそのゲームを再ロードできるようにすることも可能である。
【００２５】
実施形態の１つにおいて、ゲーム使用コントローラ２０４は、ユーザが１つ以上のゲーム・アンロック基準を満たす場合（例えば、ゲーム・アンロック数が予め定めたしきい値を超えない）、ユーザがゲームを利用できるようにする。実施形態の１つにおいて、ゲーム使用コントローラ２０４は、ユーザが１つ以上のゲーム・ロック基準を満たす（例えば、ユーザが義務不履行者である）と判定すると、ユーザがゲームを利用できないか、もはや、入手できないようにすることも可能である。
【００２６】
ゲーム・メトリクス・コレクタ２０６は、各種ゲームのプレーヤからゲーム・メトリクスを受信し、ゲーム・メトリクス・データベース２１８にゲーム・メトリクスを記憶する責務を担っている。ゲーム・メトリクスは、例えば、行われるゲームのバージョン、ゲームのスコア、ゲームが行われた時間等を明示する。ゲーム・プロデューサや出版社は、ゲーム・メトリクスを利用して、ゲームプレイを分析し、データ・マイニングを実施する。ゲーム・メトリクス・コントローラ２０６は、ゲーム・メトリクスに基づくレポート（例えば、タイトルやジャンルに従ってゲームの性能を評価する、タイトルや通信事業者単位のレポート）を作成する責務を担う。
【００２７】
マルチプレーヤ・ゲームプレイ・サポータ２０８は、さまざまなデバイスのプラットフォーム（例えば、ＰＣプラットフォーム、無線デバイスプラットフォーム、ウェブ・ベースのハンド・ヘルド式デバイスのプラットフォーム、ゲーム機プラットフォーム等）に対してマルチプレーヤ機能を提供する責務を担っている。マルチプレーヤ機能には、例えば、ゲームに関するプレーヤの組み合わせを容易にするとか（例えば、名前、ランク、または、ランク範囲によるプレーヤのサーチを可能にすることによって）、ゲームにおけるプレーヤの順番を管理するとか、ゲーム中のチャット・メッセージの交換をサポートするとか、ゲーム・プレーヤが、情報の交換、利用可能なプレーヤ／チーム及び回数のサーチ、一対一ゲームの設定等を行えるようにするため、さまざまなゲームのためのロビーを持続するといった機能を含む。実施形態の１つにおいて、マルチプレーヤ・ゲームプレイ・サポータ２０８は、クライアント・デバイスから高スコア・データ（例えば、ユーザの名前とスコア）を収集し、異なるユーザのスコアと比較し、トップ・スコアのリストをクライアント・デバイスに戻し、ユーザに高スコアを獲得したか否かを通知する責務も担っている。さらに、マルチプレーヤ・ゲームプレイ・サポータ２０８は、ゲーム・プレーヤのランク付けをし（例えば、敗戦、勝利、行われるゲームの難度に基づいて）、要求があると、ユーザにプレーヤ・ランキングを提供し、トーナメントを開始し（または、ユーザが開始できるようにし）、トーナメント参加基準を決める（または、ユーザが決めるようにする）こともある。
【００２８】
実施形態の１つにおいて、マルチプレーヤ・ゲームプレイ・サポータ２０８は、さらに、各プレーヤがネットワークにまだ接続しているか否かを定期的にチェックする責務を担っている。さらに、しきい値を設定して、プレーヤの誰かがネットワークから外れる場合、ゲームが別様に処理されることになるゲーム検証ポイントにマーク付けする。この機能によって、スコアが振るわない場合に、早めに切断しようとするプレーヤと、ネットワーク問題により切断されるプレーヤを見分けることが可能になる。
【００２９】
広告モジュール２１０は、広告（テキストと図形の両方）を維持管理し、クライアント・デバイスに対する広告のゲーム中配信を促進する（上述のクライアント・ベースのモジュールを利用して）責務を担っている。実施形態の１つでは、広告は、クライアント・ベースのモジュール及び／または基準集合（例えば、最近の１０日間にゲームＡを１０回行ったユーザは、ゲームＡの新バージョンに関する広告を受信すべきである）によって収集されたユーザのプロフィール・データに基づいて、クライアント・デバイスに配信する広告が選択される。実施形態の１つでは、広告は、カルーセルに割り当てられ、タイトル、インプレッション回数またはタイム・スケジュール、クライアント・デバイスタイプに従って輪番させられる。タイトル・ベースの広告より、通信事業者特定プロモーションが優先される場合もある。実施形態の１つでは、ゲーム開始時に、広告が検索される（例えば、クライアント・ベース・モジュールが、ゲーム開始メッセージを送り、広告モジュール２１０が、これに応答して、テキスト及び／または図形広告を送る）。実施形態の１つでは、ユーザによって行われるゲームのより新しいバージョンが存在する場合には、広告モジュール２１０が、新バージョン・アラート・メッセージを送り出す（例えば、クライアント・ベース・モジュールが、現行バージョンのゲームに関してゲーム開始メッセージを送り、広告モジュール２１０が、これに応答して、新バージョン・アラート・メッセージを送る）。
【００３０】
実施形態の１つでは、広告モジュール２１０によって、ユーザは、ゲーム・リストを閲覧し、ユーザがリストから選択したゲームに関する記述、１つ以上のスクリーン・ショットを表示することが可能になる。もう１つの実施形態では、広告モジュール２１０は、リストから選択されたデモバージョンのゲームのダウンロードを容易にする。デモバージョンは、部分的な（制限された）ゲーム機能性だけを提供するバージョンである。例えば、デモバージョンは、ユーザが、限られた時間（例えば、５分間）または基本レベルでしかゲームを楽しむことができないようにする（すなわち、デモバージョンは、ユーザがゲームで上級レベルに達すると停止する）ことが可能である。
【００３１】
実施形態の１つでは、広告モジュール２１０は、データベース２１６、２１８に記憶されているデータに基づいて、特定広告の受信者を選択し、選択されたクライアント・デバイスに対する広告のゲーム中配信を促進する責務を担っている。実施形態の１つでは、広告モジュール２１０は、ゲームの潜在的顧客を識別して、潜在的顧客に新ゲームを試すように、勧誘状を送り、潜在的顧客から承諾を受けると、潜在的顧客のモバイル・デバイスに対する新ゲームのデモバージョンのダウンロードを容易にする責務も担っている。
【００３２】
ビリング・モジュール２１２は、コンテンツの購入やリースといった、支払請求可能なイベントに関連した請求書作成業務を実施し、ビリング・データベース２２０に請求書作成業務に関する情報を記憶する責務を担っている。実施形態の１つでは、ビリング・モジュール２１２は、ゲーム購入のユーザ要求を受信すると、関連クライアント・デバイスに確認応答を送る（例えば、「ゲームＡに関して、貴殿の口座に対し＄３．９５が請求されました」）、ゲーム使用コントローラ２０４に対し、関連クライアント・デバイスにおいてゲームＡをアンロックするように指令する（すなわち、ユーザがゲームＡを利用できるようにする）。さらに、ビリング・モジュール２１２は、請求書作成業務を完了するか、または、対応するネットワーク通信事業者に請求書作成要求を送る（例えば、ユーザの電話代請求書として請求されるようにする）ため、ユーザにビリング情報（例えば、ゲーム管理システムによって保守されるユーザの識別子、クレジットカード番号等）の提供を要求する。実施形態の１つでは、ビリング・モジュール２１２によって、ユーザは、さまざまなゲーム関連機能（例えば、高スコア送信、マルチプレーヤ・メッセージング、チャット・メッセージング、ゲーム・コンテンツのアップグレード、ピクチャ及びサウンド・ファイルのリフレッシュ等）、非アプリケーション・データ（例えば、楽器用ディジタル・インターフェイス（ＭＩＤＩ）ファイル、グラフィック・ファイル等）に関して個別に要求し、支払うことが可能になる。
【００３３】
実施形態の１つでは、ビリング・モジュール２１２は、義務不履行ユーザを識別して、この情報をゲーム使用コントローラ２０４に送り、その結果、ゲームを「ロックする」（すなわち、ゲームに対するユーザ・アクセスが打ち切られる）。実施形態の１つでは、ビリング・モジュール２１２は、通信事業者からビリング・データ要求を受信し、ビリング・データベース２２０から通信事業者のビリング・システムに要求されたデータをインポートする責務も担っている。
【００３４】
ゲーム・ダウンロード・モジュール２１４は、関連クライアント・デバイスに対するゲームのダウンロードを容易にする責務を担っている。実施形態の１つでは、ゲーム・ダウンロード・モジュール２１４は、ダウンロード可能なゲーム・コードを記憶する。代替案として、ゲーム・ダウンロード・モジュール２１４は、ダウンロード可能なゲーム・コードの外部記憶場所に関する情報を記憶する（例えば、ダウンロードに利用可能なゲーム・コードのＵＲＬ）。実施形態の１つでは、ゲーム・ダウンロード・モジュール２１４は、ＭＩＤＩファイル、ポータブル・ネットワーク・グラフィックス（ＰＮＧ）ファイル等のような非アプリケーション・データのダウンロードも容易にする。
【００３５】
バージョニング・モジュール２２２は、ユーザが所有するゲームのバージョンを識別するデータを受信し、そのゲームの新バージョンが利用可能か否かを確認し、クライアント・デバイスにメッセージを送ってユーザに新ゲーム・バージョンを知らせて、対応するダウンロード可能なゲーム・コードの記憶場所を指示する責務を担っている。
【００３６】
ユーザ・アカウント・マネージャ２２４は、クライアント・デバイスからユーザ・アカウント情報を収集し、この情報をユーザ・データベース２１６に記憶し、そのアカウントに対するウェブ・ベースのユーザ・ログインを可能にする責務を担っている。ユーザ・アカウント情報には、例えば、勝利したゲームのリスト、ユーザ・ランキング、地位、メッセージ・ボード、システム情報等を含む。
【００３７】
ゲーム・ファインダ２２６は、ロビーを介してマルチプレーヤ・ゲームを見つけ出し（例えば、ゲームするのを待っているユーザを見つけ出し）、これらのゲームに対するユーザ・アクセスを可能にする責務を担っている。
【００３８】
実施形態の１つでは、ゲーム管理システム２００には、さまざまなサービスとデータに対するさまざまなレベルのユーザ・アクセスを可能にする責務を担う管理モジュール（不図示）を含む。例えば、ゲーム出版社の管理者には、ゲーム管理システム２００によって提供される全てのデータとサービスに対する最高のアクセス・レベルを与えることが可能であるが、通信事業者の管理者には、この通信事業者のユーザに提供されるサービスとデータに対するアクセスだけしか許されない、より低いアクセス・レベルを与えることが可能である。実施形態の１つでは、管理モジュールは、個々の通信事業者にデフォルト設定と許可を与え、通信事業者に応じてデフォルト設定と許可をカスタマイズできるようにする責務も担っている。実施形態の１つでは、管理モジュールは、ゲーム管理システム２００をリアルタイムに再構成して、デフォルト設定と許可と共に新規の通信事業者を追加する責務も担っている。
【００３９】
ゲーム管理システム２００は、さまざまなネットワーク通信事業者のユーザにサービスを提供するので、ゲーム・プレーヤ・コミュニティは、もはや、特定通信事業者または特定デバイス・プラットフォームのユーザに制限されない。さらに、ゲーム管理システム２００は、電子ゲームのメーカや出版社が、モバイル・ゲーム、ＰＣゲーム、ウェブ・ベース・ゲーム、ゲーム機用ゲームのプレーヤとの直接的関係を発展させ、これらのゲーム・プレーヤに関する詳細な情報を収集し、電子ゲームのターゲットを絞った広告を促進できるようにする。さらに、ゲーム管理システム２００は、ゲーム・プレーヤが、これらのモバイル・デバイスに関連した通信事業者に関係なく、さまざまなモバイル・デバイスで購入したゲームを使用できるようにする。
【００４０】
クライアント・ベース・モジュール
上述のように、ゲーム管理システムによるサービスを受ける各クライアント・デバイスには、ゲーム・アプリケーション（例えば、モバイル・ゲーム・アプリケーション、ＰＣゲーム・アプリケーション、ウェブ・ベース・ゲーム・アプリケーション、ゲーム機用ゲーム・アプリケーション等）と統合することもできるし、あるいは、独立したアプリケーションとして機能することも可能な、クライアント・ベース・モジュール（本明細書において、ゲーミング・データ・モジュールとも呼ばれる）が設けられている。実施形態の１つでは、ゲーミング・データ・モジュールは、ゲーム・タイプに応じて変化することが可能な、アプリケーション・プログラミング・インターフェイス（ＡＰＩ）である。例えば、ＰＣゲームのクライアントＡＰＩは、ＰＣに関するシステム情報（例えば、ディスクとメモリのサイズ、オペレーティング・システム情報、ビデオ・カード・タイプ等）を検索し、このシステム情報をゲーム管理システム１０２に送ることが可能である。さらに、クライアントＡＰＩ機能は、さまざまなゲームに合わせて変化してもよい。例えば、特定ゲームのためのクライアントＡＰＩは、ゲーム中広告またはゲーム・メトリクス収集をサポートすることができない。
【００４１】
ゲーミング・データ・モジュールは、ゲーム管理システムにメッセージを送り（クライアント・デバイスがネットワークから切断されている場合には、メッセージを記憶し）、ゲーム管理システムによって促進されるリアル・タイムのゲーム中機能（例えば、ゲーム中広告、マルチプレーヤ・ゲームプレイ、ユーザ登録、ゲーム・メトリクス収集等）をサポートする責務を担っている。
【００４２】
図２Ｂは、ゲーミング・データ・モジュール２４０の実施形態の１つに関するブロック図である。ゲーミング・データ・モジュール２４０には、ビリング・コンポーネント２４２、ゲーム・アクセス・コンポーネント２４４、高スコア・コンポーネント２４６、バージョニング・アラート・コンポーネント２４８、広告コンポーネント２５０、マーケティング・コンポーネント２５２、ユーザ・プロフィール・コンポーネント２５４、ゲーム・ブラウザ・コンポーネント２５６、ゲーム・ダウンロード・コンポーネント２５８、ユーザ・データベース２６０が含まれている。
【００４３】
ビリング・コンポーネント２４２は、ゲーム管理システムにビリング・データ（例えば、ゲームのタイトル、デバイスＩＤ、ユーザＩＤ、ユーザ・ビリング情報等）を送り、ゲーム管理システムから購入確認応答を受信し、購入確認応答をユーザに表示する責務を担っている。
【００４４】
ゲーム・アクセス・コンポーネント２４４は、ゲーム管理システムにゲーム・キー（例えば、ゲーム・タイトル、デバイスＩＤ、ユーザＩＤ）を送り、ゲーム管理システムからアンロック命令を受信すると、ゲームをアンロックする責務を担っている。実施形態の１つでは、ゲーム・アクセス・コンポーネント２４４は、ユーザがゲームを開始する毎に、ゲーム管理システムをチェックし、ゲームを再ロックすべきか否かを判定する（例えば、会員期限が切れている場合、ゲームが盗用されることになる等）。実施形態の１つでは、ゲーム・アクセス・コンポーネント２４４は、高優先順位メッセージ（例えば、ゲーム購入メッセージ）のフラグを立てて、ゲーム管理システムにすぐに送るか、あるいは、サービスが得られない場合（例えば、ユーザが、サービス・エリア外にいる間に、ゲームを購入したいと思う場合）、再送に備えてレコード・ファイルに記憶する。
【００４５】
高スコア・コンポーネント２４６は、ゲームが終わると、ユーザのスコアをゲーム管理システムに送り、高スコアの現行リストを受信し、その現行リストをユーザに表示する責務を担っている。
【００４６】
バージョニング・アラート・コンポーネント２４８は、ゲームが開始されるとき、ゲーム・バージョン情報をゲーム管理システムに送り、ゲーム管理システムからより新しいバージョンに関する情報を受信し、ゲームの開始前に、この情報をユーザに表示する責務を担っている。
【００４７】
ユーザ・プロフィール・コンポーネント２５４は、ユーザ・プロフィール・データを収集し、そのユーザ・プロフィール・データをユーザ・データベース２６０に記憶する責務を担っている。ユーザ・プロフィール・データは、ゲーム管理システムによって決められる関心のある情報に基づいて収集する。ユーザ・プロフィール・データは、例えば、このクライアント・デバイスでユーザが行うのがどのゲームか、ゲームがいつ行われるのか、ゲームで獲得されたユーザ・スコア、ユーザ・デバイス情報（例えば、デバイスタイプ、ＣＰＵ等）等を明らかにする。
【００４８】
広告コンポーネント２５０は、ゲーム管理システムに新しいユーザ・プロフィール・データを送り、ユーザ・プロフィール・データと１組のルールに基づいてゲーム管理システムが選択した広告を受信し、その広告をユーザに表示する責務を担っている。
【００４９】
マーケティング・コンポーネント２５２は、ゲーム・メトリクスを収集して、ゲーム管理システムに送る責務を担っている。ゲーム・メトリクスは、例えば、行われたゲームのバージョン、ゲームのスコア、ゲームが行われた時間がどれくらいか等を明らかにすることが可能である。
【００５０】
ゲーム・ブラウザ・コンポーネント２５６によって、ユーザは、ゲーム開始時にログインして、好みのものを参照し、ゲーム管理システムで利用可能な現行ゲームを閲覧することが可能になる。実施形態の１つでは、ゲーム・ブラウザ・コンポーネント２５６によって、ユーザは、ゲームのスクリーン・ショット、記述、価格を参照することができる。
【００５１】
ゲーム・ダウンロード・コンポーネント２５８によって、ユーザは、新ゲームをダウンロードすることが可能になる。
【００５２】
ユーザのさまざまなデバイスによる電子ゲームの使用
図３、４は、ユーザのさまざまなデバイスによる電子ゲームの使用を容易にするためのプロセスに関する２つの実施形態の流れ図である。このプロセスは、ハードウェア（例えば、専用ロジック、プログラマブル・ロジック、マイクロコード等）、ソフトウェア（汎用コンピュータ・システムまたは専用機で実行されるような）、または、両方の組み合わせを含むことが可能な処理ロジックによって実施可能である。実施形態の１つでは、プロセスは、ゲーム管理システム１０２または２００によって実施される。
【００５３】
図３を参照すると、プロセス３００は、ユーザがゲーム管理システムに登録すると、処理ロジックがユーザ識別情報を受信することから開始される（処理ブロック３０２）。ユーザ識別情報には、例えば、ユーザＩＤ、パスワード、Ｅメール・アドレス、ユーザが選択したゲームに関連する一意性コード（例えば、小売店で購入のスクラッチ・カード番号）等を含む。ユーザが、ゲーム管理システムに関連したウェブ・サイトで登録リンクを起動すると、あるいは、ゲーム管理システムからゲームを購入する要求を送ると、ゲーム管理システムに登録することが可能になる。あるいはまた、ユーザが、ユーザのデバイス（例えば、ユーザの携帯電話）にゲームをダウンロードする要求を出すと、あるいは、ユーザが新ゲームを開始すると、処理ロジックは、ゲーム管理システムに登録するように、ユーザに要求するメッセージを送る。
【００５４】
処理ブロック３０４において、処理ロジックは、ユーザがデバイス１のために購入したゲームＸの識別データを受信する。デバイス１は、例えば、モバイル・デバイス（例えば、携帯電話）、ＰＣ、ゲーム・ステーション、家庭用電子機器などである。ユーザがゲーム管理システムに登録すると、あるいは、ユーザ登録の後、ゲームＸの識別データを受信することが可能になる。例えば、ユーザがゲーム管理システムからゲームＸを購入すると、あるいは、ユーザが、小売店で購入したゲーム・スクラッチ・カードの番号をデバイス１で入力すると、ゲームＸの識別データを受信することが可能になる。処理ロジックは、ユーザ識別情報、ゲームＸの指定データをデータベースに記憶する。
【００５５】
その後、処理ロジックは、デバイス２のためのゲームＸのユーザ選択を受信する（処理ブロック３０６）。デバイス２は、デバイス１の通信事業者と同じかまたは異なる通信事業者のモバイル・デバイス、ＰＣ、ゲーム・ステーション、家庭用電子機器等とすることが可能である。処理ロジックは、ゲーム管理システムに関連したウェブ・サイトで、ユーザがデバイス２のためにゲームＸを選択すると、あるいは、ユーザがデバイス２からゲームＸのダウンロードを要求すると、デバイス２のためのゲームＸのユーザ選択を受信する。
【００５６】
次に、処理ロジックは、ユーザに対して、ユーザの識別情報を提供するように要求する（処理ブロック３０８）。あるいはまた、処理ロジックは、デバイス２のためのゲームＸのユーザ選択を受信する前に、ユーザ識別情報を受信することも可能である。判断記号３１０において、処理ロジックは、ユーザが１つ以上のゲーム・アンロック基準を満たしているか否かを判定する。ゲーム・アンロック基準は、ゲームの使用を許可するために（すなわち、ゲームを「アンロックする」ために）構成可能なパラメータを指定する。ゲーム・アンロック基準は、ゲーム・タイプ及び／または通信事業者によって異なってもよい。ゲーム・アンロック基準は、例えば、ユーザに関する「アンロック」数が所定のしきい値未満であること、単一ユーザ・デバイスに関する「アンロック」数が所定のしきい値未満であること、ユーザが義務不履行者でないこと等を要求する。
【００５７】
判断記号３１０においてなされる判定が肯定の場合、処理ロジックは、ユーザ識別情報とゲーム・データを突き合せるためデータベースをサーチする。一致することが分ると（判断記号３１２）、処理ロジックは、ゲームＸがユーザによって既に購入されているものと判断し、デバイス２で楽しむため、ユーザがゲームＸを利用できるようにする（処理ブロック３１４）。実施形態の１つでは、処理ロジックは、ゲームＸをデバイス２にダウンロードすることによって、ユーザがゲームＸを利用できるようにする。もう１つの実施形態では、さらに詳細に後述するように、処理ロジックは、ゲームＸ（例えばゲームＸに関連したクライアントＡＰＩに）にアンロック・メッセージを送ることによって、ユーザがゲームＸを利用できるようにする。
【００５８】
あるいはまた、ユーザがゲーム・アンロック基準を満たしておらず、かつ、ゲームをまだ購入していないか、あるいは、そのいずれかである場合、処理ロジックは、デバイス２においてユーザがゲームＸを利用できないようにする（処理ブロック３１６）。実施形態の１つでは、処理ロジックは、デバイス２へのゲームＸのダウンロードを阻止することによって、ゲームＸを利用できないようにする。もう１つの実施形態では、さらに詳細に後述するように、処理ロジックは、ゲームＸに（例えば、ゲームＸに関連したクライアントＡＰＩに）ロック・メッセージを送ることによって、ゲームＸを利用できないようにする。
【００５９】
ある代替実施形態（不図示）の場合、処理ロジックは、ユーザがゲームを購入済みであることを確認した後、ユーザがゲーム・アンロック基準を満たすか否かを判定する。
【００６０】
ユーザがデバイス２においてゲームＸを行うのを許されると、処理ロジックは、ユーザのゲームプレイをサポートし、上述のゲーム中広告とマルチプレーヤ・ゲームプレイ機能を手助けする。実施形態の１つでは、マルチプレーヤ・ゲームプレイ機能が、さまざまな通信事業者によって複数ユーザに提供される（例えば、対応する通信事業者に関係なく、ゲームのスコア・リストが全参加者について維持管理される）。さらに、処理ロジックは、デバイス２からゲームＸに関連したメトリクスを受信して、ユーザの他のデバイスから受信したゲーム・メトリクスと共に、そのゲーム・メトリクスをデータベースに記憶し、それによって、ゲームが行われたユーザ・デバイスに関係なく、このゲームに関連した完全なユーザ・メトリクス集合が維持管理されるようにする。
【００６１】
図４は、ユーザの異なるデバイスによる電子ゲームの使用を容易にするためのプロセスに関する代替実施形態の流れ図である。
【００６２】
図４を参照すると、プロセス４００は、処理ロジックが、モバイル・デバイスからゲームのユーザ選択を受信することから開始される。モバイル・デバイスは、第１の無線通信事業者に関連している。実施形態の１つでは、処理ロジックは、第１の無線通信事業者に関連したモバイル・デバイスにゲームをダウンロードするユーザ要求がなされた時点で、ゲームのユーザ選択を受信する。次に、処理ブロック４０４において、処理ロジックは、第１の無線通信事業者のモバイル・デバイスにデモバージョンのゲームをダウンロードする。
【００６３】
代替実施形態（不図示）の場合、処理ロジックは、第１の無線通信事業者のモバイル・デバイスにダウンロード済みのデモバージョンのゲーム（例えば、広告の一部として）のユーザ選択がなされた時点で、ゲームのユーザ選択を受信する。
【００６４】
処理ブロック４０６において、処理ロジックは、ユーザに対し、ログイン情報（例えば、ユーザＩＤとパスワード）を提供するように要求する。この要求は、ゲームをダウンロードするユーザ要求の前または後、あるいは、デモバージョンのゲームがモバイル・デバイスにダウンロードされた後（例えば、課せられた制限のために、デモが停止になる場合）、モバイル・デバイスに送ることが可能である。
【００６５】
次に、処理ロジックは、ユーザが１つ以上のアンロック基準を満たすか否かを判定する（判断記号４０８）。ユーザがアンロック基準を満たさない場合、処理ロジックは、モバイル・デバイスにロック・メッセージを送る（処理ブロック４１４）。ロック・メッセージは、ゲームに課せられた制限を有効のままにしておくべきであることを指示する。
【００６６】
ユーザがゲーム・アンロック基準を満たす場合、処理ロジックは、ユーザ・データベースをサーチして、ユーザが、このモバイル・デバイスまたは異なるモバイル・デバイス（例えば、異なる無線通信事業者のモバイル・デバイス）のためにこのゲームを購入済みであるか否かを判定する（判断記号４１０）。この判定が肯定の場合、処理ロジックは、モバイル・デバイスにアンロック・メッセージを送る（処理ブロック４１２）。アンロック・メッセージは、デモバージョンのゲームに課せられた制限を無効にすべきであることを指示する（例えば、ユーザが制限された期間にわたってゲームを行えるようにするタイマを無効にする）。結果として、ユーザは、今や、現モバイル・デバイスのためにゲームを購入することを必要とせずに、現モバイル・デバイスで無制限バージョンのゲームを行うことが可能になる。
【００６７】
ゲームがユーザによって購入済みでなければ、処理ロジックは、ユーザにゲームの購入を要求する。ユーザが購入を承認しなければ、処理ロジックは、モバイル・デバイスにロック・メッセージを送る（処理ブロック４１４）。ユーザが購入を承認すると、処理ロジックは、モバイル・デバイスにアンロック・メッセージを送る（処理ブロック４１２）。
【００６８】
もう１つの実施形態（不図示）では、ゲームがユーザによって購入済みでなければ、処理ロジックは、ゲームの価格をユーザ・アカウントに自動的に請求し、モバイル・デバイスにアンロック・メッセージを送る。
【００６９】
ゲームがアンロックされると、処理ロジックは、次に、ユーザが１つ以上のゲーム・ロック基準を満たすか否か（例えば、ユーザが義務不履行者か否か、各種デバイスに対してダウンロードされるゲーム例が多すぎるか否か等）を定期的にチェックする。ゲーム・ロック基準は、ゲームに対するユーザ・アクセスを中断する（すなわちゲームをロックする）ために構成可能なパラメータを指定する。ゲーム・ロック基準は、ゲーム・タイプ及び／または通信事業者によって異なってもよい。ユーザが、ゲーム・ロック基準を満たす場合、処理ロジックは、モバイル・デバイスにロック・メッセージを送って、ゲームへのユーザ・アクセスを中断させる。
【００７０】
図５は、ゲーム広告プロセスに関する実施形態の１つの流れ図である。プロセスは、ハードウェア（例えば、専用ロジック、プログラマブル・ロジック、マイクロコード等）、ソフトウェア（汎用コンピュータ・システムまたは専用機で実行されるような）、または、両方の組み合わせを含む処理ロジックによって実施可能である。実施形態の１つでは、プロセスは、ゲーム管理システム１０２または２００によって実施される。
【００７１】
図５を参照すると、プロセス５００は、処理ロジックが、新ゲームまたは既存のゲームの新バージョンの候補として、ユーザを選択することから開始される（処理ブロック５０２）。実施形態の１つにおいて、選択は、ユーザが購入したゲーム、これらのゲームに関連したユーザ・パラメータを明らかにする、ゲーム管理システムによって維持管理されているデータに基づいて行われる。
【００７２】
処理ブロック５０４において、処理ロジックは、ユーザの現行モバイル・デバイスを識別する。現行モバイル・デバイスは、最新ゲームのアンロックが実施されたデバイス、または、最新ゲーム・メトリクスが収集されたデバイスなどである。
【００７３】
処理ブロック５０６において、処理ロジックは、ユーザが現行モバイル・デバイスでゲームを行っていることを検出し、新ゲームを試すよう勧誘する広告を現行モバイル・デバイスに送る。
【００７４】
次に、処理ロジックは、新ゲームを試す旨のユーザ承諾を受信すると（処理ブロック５０８）、新ゲームのデモバージョンを現行モバイル・デバイスにダウンロードする（処理ブロック５１０）。
【００７５】
デモが課せられた制限（例えば、上級レベルに達する）によって停止になると、処理ロジックは、ユーザが新ゲームを購入したいか否かを尋ねるメッセージを送る。ユーザが新ゲームの購入を承諾すると（判断記号５１２）、処理ロジックは、ユーザがゲーム・アンロック基準を満たすか否かを判定する（判断記号５１４）。この判定が肯定の場合、処理ロジックは、ゲーム・アンロック・メッセージをモバイル・デバイスに送り（処理ブロック５１６）、ゲームをアンブロックさせる。あるいはまた、処理ロジックは、拒否メッセージを送り（処理ブロック５１８）、ユーザにゲームをアンロックできないことを通知する。
【００７６】
図６には、ゲーム・アンロック・プロセスの実施形態の１つが例示されている。ゲーム・アンロック・プロセスは、クライアント・アプリケーションを設けているユーザ・デバイスとゲーム管理システムの間で、ネットワークを介してメッセージ交換することによって実施される。ネットワークは、無線ネットワークまたはインターネットのような広域ネットワークである。ユーザ・デバイスは、モバイル・デバイス、パーソナル・コンピュータ、ゲーム機、家庭用電子機器などである。ユーザ・デバイスのクライアント・アプリケーションは、ゲームがロックされる場合には、制限されたゲーミング機能性（デモバージョンとして）を提供し、ゲームがアンロックされる場合には、完全な無制限のゲーミング機能性を提供するように構成されている。ユーザ・デバイスとゲーム管理システムの間で交換されるメッセージは、例えば、拡張可能マーク付け言語（ＸＭＬ）列の形をとるハイパーテキスト転送プロトコル（ＨＴＴＰ）・メッセージまたはショート・メッセージ・サービス（ＳＭＳ）・メッセージである。ゲーム管理システムは、全ての交換メッセージを記録する。
【００７７】
ゲーム・アンロック・プロセスは、ユーザ・デバイスが、ゲームのアンロックを要求するメッセージを送ることによって開始される。メッセージには、ユーザが購入しなかったゲームのタイトル、ユーザ・デバイスの識別子またはユーザＩＤ及びパスワードのようなユーザ識別情報が含まれる。
【００７８】
これに応答して、ゲーム管理システムは、ユーザ識別情報を認証し、ユーザ識別情報が有効であれば、ユーザ・デバイスに対して、タイトル・キーと共に、要求承認メッセージを戻す。あるいはまた、ユーザ識別情報が無効であれば、ゲーム管理システムは、ユーザ・デバイスに対して要求失敗メッセージを送り、アンチハッキング検出または他の何らかの問題を指示するものとして、失敗を記録する。
【００７９】
次に、ユーザ・デバイスが、要求承認メッセージを受信しない場合（例えば、ゲーム・アンロック・メッセージが送られた時、サービスが提供されない場合）、あるいは、要求失敗メッセージを受信する場合、ユーザ・デバイスは、要求失敗メッセージをユーザに表示する。あるいはまた、ユーザ・デバイスが、要求承認メッセージを受信する場合、ユーザ・デバイスは、ユーザ・デバイスに記憶されているタイトル・キーによって受信したタイトル・キーを認証する。２つのキーが一致すると、ユーザ・デバイスは、ゲームをアンロックし、ゲーム管理システムに対して、ユーザＩＤとゲーム・タイトルと共に、成功したアンロック・メッセージを送り、ゲーム管理システムは、成功したアンロック・メッセージを記憶し、ビリング・システムにビリング・メッセージを送り、ユーザ・デバイスに対して、結果生じる請求書作成業務に関する情報（例えば、「貴殿の口座に対し＄３．９９が請求されることになります．．．」）と共に、アンロックの承認を戻す。ユーザ・デバイスは、アンロック承認メッセージを受信して、ユーザに表示する。
【００８０】
ゲーム管理システムから受信したタイトル・キーが、ユーザ・デバイスに記憶されているタイトル・キーと一致しなければ、ユーザ・デバイスは、ゲームをロック状態に保ち、ゲーム管理システムに対してアンロック失敗メッセージを送り、ユーザにアンロック失敗メッセージを表示する。ゲーム管理システムは、アンチハッキング検出または他の何らかの問題を指示するものとして、失敗したアンロックを記録する。
【００８１】
実施形態によっては、ゲーム・アンロック機構を用いて、ゲームの各開始毎に１つ以上のコインを要求する標準アーケード・ゲームに似た、業務用ゲーム機のゲーム・モデルを使用可能にするものもある。業務用ゲーム機のゲーム・モデルによれば、ゲームは、完了すると、自動的にロックされる。ユーザは、ゲームの再開を要求すると、ゲームのアンロックを承認するように求められる。こうした承認が受信されると、ユーザ・アカウントに料金が請求され、ゲームは、次の完了までアンロックされる。あるいはまた、ユーザのゲーム・リプレイを促すため、再開要求に応答して、ユーザ・アカウントに対する信用取引を行うことも可能である。
【００８２】
さらに他の実施形態には、ゲーム・アンロック機構を用いて、ユーザ・デバイスで選択されたゲームの実施だけを許可する、バンドル・ゲーム・モデルを使用可能にするものもある。バンドル・ゲーム・モデルによれば、一群のゲーム（例えば、全カタログのゲーム）がユーザ・デバイスにダウンロードされ、次に、これらのゲームの一部が、アンロックされるが、他のゲームは、ロック状態のままである。アンロックするゲームの選択は、所定のビジネス・ルールに基づく。例えば、ユーザは、所定の期間（例えば、１ヶ月）について、ある特定の数のゲームまたは特定ゲームを申し込むことが可能であり、この申込み期間中、これらのゲームだけがアンロックされる。残りのゲームは、クライアント・デバイスに存在しても、その申込み期間中、機能しない。
【００８３】
図７〜１２はゲーム・アンロック・プロセスの各種実施形態を例示した流れ図である。
【００８４】
図７を参照すると、ゲーム・ロック・プロセス７００によって、クライアント・デバイスは、ゲーム管理システム（ＧＭＳ）・サーバが利用できない場合に、その後、利用される状況キャッシュを生成する。例えば、ＧＭＳサーバのサービスがダウンしている場合、クライアント・デバイスがネットワーク・アクセスできない場合、あるいは、他の何らかの理由で、ＧＭＳサーバを利用できない可能性がある。状況キャッシュは、ゲームの状況、ゲームが最後に行われた時点、ゲームが行われたモード等を明らかにする。
【００８５】
ブロック７０２において、クライアントにデモ・モード（すなわち、制限された機能性、発売前の広告挿入に関連したモード）で存在するアプリケーションが、ＧＭＳサーバにゲーム開始イベントを送る。
【００８６】
ブロック７０４において、クライアント・アプリケーションは、ＧＭＳサーバが連絡可能か否かを判定する。可能でなければ、クライアント・アプリケーションは、デモ・モードのゲーム開始を承認する（ブロック７２８）。可能であれば、クライアント・アプリケーションは、ユーザがゲームの完全な（無制限の）アンロックを承認できるようにする（ブロック７０６）。実施形態の１つでは、ユーザは、任意の利用可能な支払い機構を介してゲームの料金を支払うことによって、完全なアンロックを承認する。
【００８７】
ユーザが完全なアンロックを選択しない場合、クライアント・アプリケーションは、デモ・モードによるゲームの開始を承認する（ブロック７１０）。あるいはまた、ユーザが完全なアンロックを選択する場合、ＧＭＳサーバは、ＧＭＳサーバに関するユーザ・アカウントを確認し（または、新規ユーザのアカウントを作成し）（ブロック７１２）、クライアント・アプリケーションにデバイス状況キャッシュを生成するように命令し（ブロック７１４）、このゲームが、現在、このデバイスだけで起動中であるか否かを判定する（ブロック７１６）。そうであれば、ＧＭＳサーバは、クライアント・アプリケーションに対し、ユーザがこのゲームの使用を許可されたことを指示するデータによって、デバイス状況キャッシュを更新するように命令し（ブロック７２４）、完全モードによるゲーム開始の承認を送る（ブロック７２６）。
【００８８】
このゲームが、現在、２つ以上のデバイスで起動中の場合、ＧＭＳサーバは、クライアント・アプリケーションに対して、ユーザがこのゲームの使用を許可されていないことを指示するデータによって、デバイス状況キャッシュを更新するように命令し（ブロック７１８）、クライアント・アプリケーションにロック・コマンドを送る（ブロック７２０）。クライアント・アプリケーションは、ゲームをロックし、ビジネス・ルールに基づいて作成することが可能であり、ゲームのアンロック方法に関する命令を含むユーザ・フィードバックを表示する（ブロック７２２）。例えば、フィードバックには、ゲーム購入リンクを含み、さらにゲームが、このユーザのログイン時に別のハンドセットで起動中である旨の通知等を含む。さらに、文脈依存型ヘルプを提供することが可能である（例えば、家族の他の誰かが別のデバイスでログインしていないことを確認した後、再試行するようにユーザに求めるメッセージ）。
【００８９】
図８を参照すると、ゲーム・アンロック・プロセス８００によって、クライアント・デバイスは、ＧＭＳサーバが利用できない場合、状況キャッシュを利用することが可能になる。状況キャッシュは、ゲームの状況、ゲームが最後に行われた時点、ゲームが行われたモード、試行期間の条件等を明らかにする。
【００９０】
ブロック８０２において、クライアントに存在するアプリケーションは、ＧＭＳサーバにゲーム開始イベントを送る。
【００９１】
ブロック８０４において、クライアント・アプリケーションは、ＧＭＳサーバが連絡可能であるか否かを判定する。可能でなければ、クライアント・アプリケーションは、クライアント・デバイスに存在する状況キャッシュを読み取る（ブロック８０６）。状況キャッシュに、データが含まれていない場合（ブロック８０８）、クライアント・アプリケーションは、状況キャッシュを更新し（ブロック８１０）、デモ・モードによるゲームの開始を承認する（ブロック８１２）。
【００９２】
状況キャッシュにデータが含まれている場合（ブロック８０８）、クライアント・アプリケーションは、キャッシュ・データが、ユーザがデモ・モードによるゲームの実施を許可されていることを示しているのか、または、完全モードによるゲームの実施を許可されていることを示しているのかを判定する（ブロック８１４）。ユーザが、完全モードによるゲームの実施を許可されている場合、クライアント・アプリケーションは、完全モードによるゲームの開始を承認する（ブロック８１６）。
【００９３】
ユーザがデモ・モードによるゲームの実施を許可されている場合、クライアント・アプリケーションは、デモ・モードが期限切れになっているか否かをチェックする（ブロック８１８）。期限切れでなければ、デモ・モードでゲームが開始される（ブロック８２０）。期限切れの場合、クライアント・アプリケーションは、状況キャッシュを更新し（ブロック８２２）、ゲームをロックし（ブロック８４０）、ビジネス・ルールに基づいて作成することが可能であり、ゲームのアンロック方法に関する情報と文脈依存型ヘルプを含むフィードバックをユーザに表示する（ブロック８４２）。
【００９４】
ＧＭＳサーバが連絡可能であれば（ブロック８０４）、クライアント・アプリケーションは、ＧＭＳサーバに対して、ユーザのアンロック状況を確認するように求める（ブロック８２４）。ＧＭＳサーバは、次に、ゲームが試行モード（例えば、評価のため、無料で楽しめるようにダウンロードされたもの）であるか否かを判定する（ブロック８２６）。そうであれば、ＧＭＳサーバは、試行モードがまだ有効であるか否かを判定する（例えば、許可された試行回数、許可された時間期間等のようなビジネス・ルールを用いて）（ブロック８３４）。試行モードがまだ有効であれば、ＧＭＳサーバは、試行モードによるゲーム開始を承認する（ブロック８３６）。
【００９５】
試行モードがもはや有効ではなければ、ＧＭＳサーバは、クライアント・アプリケーションに対して、デバイス状況キャッシュを更新するように命令し（ブロック８３８）、クライアント・アプリケーションにロック・コマンドを送るが（ブロック８４０）、その結果、ゲームがロックされ、ユーザにフィードバックが表示される（ブロック８４２）。
【００９６】
ゲームが試行モードでなければ（すなわち、製品モードにある）（ブロック８２６）、ＧＭＳサーバは、クライアント・アプリケーションに対して、デバイス状況キャッシュを更新するように命令し（ブロック８２８）、ゲームが有効であるか否か（例えば、ユーザが既に購入済みであるか否か）を判定する（ブロック８３０）。有効でなければ、ＧＭＳサーバは、クライアント・アプリケーションにロック・コマンドを送り（ブロック８４０）、これによって、ゲームがロックされ、ユーザにフィードバックが表示される（ブロック８４２）。有効であれば、ＧＭＳサーバは、このゲームが、現在、このデバイスだけで起動中であるか否かを判定する（ブロック８３２）。そうであれば、ＧＭＳサーバは、完全モードによるゲームの開始の承認を送る（ブロック８１６）。
【００９７】
このゲームが、現在、２つ以上のデバイスで起動中の場合、ＧＭＳサーバは、クライアント・アプリケーションにロック・コマンドを送る（ブロック８４０）。クライアント・アプリケーションは、その結果、ゲームをロックし、ユーザにフィードバックを表示する（ブロック８４２）。
【００９８】
図９を参照すると、ゲーム・アンロック・プロセス９００によって、クライアント・デバイスは、ＧＭＳサーバが利用できない場合、完全アンロック・モードのために状況キャッシュを利用することが可能になる。
【００９９】
ブロック９０２において、クライアントに存在するアプリケーションは、ＧＭＳサーバにゲーム開始イベントを送る。
【０１００】
ブロック９０４において、クライアント・アプリケーションは、ＧＭＳサーバが連絡可能であるか否かを判定する。連絡可能でなければ、クライアント・アプリケーションは、クライアント・デバイスに存在する状況キャッシュを読み取る（ブロック９０６）。状況キャッシュにデータが含まれていなければ（ブロック９０８）、クライアント・アプリケーションは、ゲームをロックし（ブロック９１８）、ユーザにフィードバックを表示する（ブロック９２０）。
【０１０１】
状況キャッシュにデータが含まれていると（ブロック９０８）、クライアント・アプリケーションは、キャッシュ・データが、ユーザが完全モードによるゲームの実施を許可されていることを示しているか否かを判定する（ブロック９１０）。許可されている場合、クライアント・アプリケーションは、完全モードによるゲームの開始を承認する（ブロック９１２）。
【０１０２】
ユーザが完全モードによるゲームの実施を許可されていなければ、クライアント・アプリケーションは、ゲームをロックし（ブロック９１８）、ユーザにフィードバックを表示する（ブロック９２０）。
【０１０３】
ＧＭＳサーバが連絡可能であれば、クライアント・アプリケーションは、ＧＭＳサーバと共にユーザのアンロック状況を確認する（ブロック９１４）。ゲームが登録されている（例えば、既に購入済みである）場合（ブロック９１６）、ＧＭＳサーバは、クライアント・アプリケーションに対して、デバイス状況キャッシュを更新するように命令し（ブロック９１７）、このゲームが、現在、このデバイスだけで起動中であるか否かを判定する（ブロック９１９）。そうであれば、ＧＭＳサーバは、クライアント・アプリケーションに対して、ユーザがこのゲームの使用を許可されていることを指示するデータによって、デバイス状況キャッシュを更新するように命令し（ブロック９２４）、完全モードによるゲーム開始の承認を送る（ブロック９２６）。
【０１０４】
このゲームが、現在、２つ以上のデバイスで起動中の場合、ＧＭＳサーバは、クライアント・アプリケーションに対して、ユーザがこのゲームの使用を許可されていないことを指示するデータによって、デバイス状況キャッシュを更新するように命令し（ブロック９２２）、クライアント・アプリケーションに対してロック・コマンドを送る（ブロック９１８）。クライアント・アプリケーションは、ゲームをロックし、ユーザにフィードバックを表示する（ブロック９２０）。
【０１０５】
ゲームが登録されていない（例えば、これまでに購入済みではない）場合（ブロック９１６）、ＧＭＳサーバは、クライアント・アプリケーションにロック・コマンドを送る（ブロック９１８）。クライアント・アプリケーションは、ゲームをロックし、ユーザにフィードバックを表示する（ブロック９２０）。
【０１０６】
図１０を参照すると、ゲーム・リース（例えば、ユーザが所定の期間にわたるゲームのリース料金を支払う）に関連したゲーム・アンロック・プロセス１０００によって、クライアント・デバイスは、ＧＭＳサーバが利用できない場合に、完全アンロック・モードのために状況キャッシュを利用することが可能になる。状況キャッシュは、ゲームの状況、ゲームが最後に行われた時点、ゲームが行われたモード、リース条件等を明らかにすることが可能である。
【０１０７】
ブロック１００２において、クライアントに存在するアプリケーションは、ＧＭＳサーバにゲーム開始イベントを送る。
【０１０８】
ブロック１００４において、ゲーム・アプリケーションは、ＧＭＳサーバが連絡可能であるか否かを判定する。連絡可能でなければ、クライアント・アプリケーションは、クライアント・デバイスに存在する状況キャッシュを読み取る（ブロック１００６）。状況キャッシュにデータが含まれていなければ（ブロック１００８）、クライアント・アプリケーションは、ゲームをロックし（ブロック１０１８）、ユーザにフィードバックを表示する（ブロック１０２０）。
【０１０９】
状況キャッシュにデータが含まれている場合（ブロック１００８）、クライアント・アプリケーションは、キャッシュ・データが、ユーザが完全モードによるリース・ゲームの実施を許可されていることを指示しているか否かの判定を行う（ブロック１０１０）。許可されている場合、クライアント・アプリケーションは、完全モードによるゲームの開始を承認する（ブロック１０１２）。
【０１１０】
ユーザが、完全モードによるリース・ゲームの実施を許可されていない場合、クライアント・アプリケーションは、ゲームをロックし（ブロック１０１８）、ユーザにフィードバックを表示する（ブロック１０２０）。
【０１１１】
ＧＭＳサーバが連絡可能であれば、クライアント・アプリケーションは、ＧＭＳサーバと共にユーザのリース状況を確認する（ブロック１０１４）。ゲームが登録されている（例えば、ユーザがゲームのリース料金を支払っている）場合（ブロック１０１６）、ＧＭＳサーバは、クライアント・アプリケーションに対して、デバイス状況キャッシュを更新するように命令し（ブロック１０２２）、このゲームが、現在、このデバイスだけで起動中であるか否かを判定する（ブロック１０２４）。そうであれば、ＧＭＳサーバは、クライアント・アプリケーションに対して、ユーザがこのゲームの使用を許可されていることを指示するデータによって、デバイス状況キャッシュを更新するように命令し（ブロック１０２８）、完全モードによるゲーム開始の承認を送る（ブロック１０３０）。
【０１１２】
このゲームが、現在、２つ以上のデバイスで起動中の場合、ＧＭＳサーバは、クライアント・アプリケーションに対して、ユーザがこのゲームの使用を許可されていないことを指示するデータによって、デバイス状況キャッシュを更新するように命令し（ブロック１０２６）、クライアント・アプリケーションに対してロック・コマンドを送る（ブロック１０１８）。クライアント・アプリケーションは、ゲームをロックし、ユーザにフィードバックを表示する（ブロック１０２０）。実施形態の１つでは、ＧＭＳサーバは、ユーザ・アカウント／ゲームの組み合わせに関するロック・コマンドを出す。すなわち、ユーザがそのアカウント情報を他のユーザと共有する場合、このアカウント／ゲーム組み合わせの全てのインスタンスが、ロックされて、ユーザはそのアカウント情報の共有を抑制することになる。
【０１１３】
ゲームが登録されていない（例えば、ユーザがリース料金を支払っていないか、または、リース期限が切れている）場合（ブロック１０１６）、ＧＭＳサーバは、クライアント・アプリケーションにロック・コマンドを送る（ブロック１０１８）。クライアント・アプリケーションは、ゲームをロックし、ユーザにフィードバックを表示する（ブロック１０２０）。
【０１１４】
図１１を参照すると、業務用ゲーム機のゲーム・モデルに関連したゲーム・アンロック・プロセス１１００によって、クライアント・デバイスは、ＧＭＳサーバが利用できない場合に、完全アンロック・モードのために状況キャッシュを利用することが可能になる。状況キャッシュは、ゲームの状況、ゲームが最後に行われた時点、ゲームが行われたモード、ゲームの再開毎に請求される、ユーザの電子財布アカウントの状況等を明らかにすることが可能である。
【０１１５】
ブロック１１０２において、クライアントに存在するアプリケーションは、ＧＭＳサーバにゲーム開始イベントを送る。
【０１１６】
ブロック１１０４において、ゲーム・アプリケーションは、ＧＭＳサーバが連絡可能であるか否かを判定する。連絡可能でなければ、クライアント・アプリケーションは、クライアント・デバイスに存在する状況キャッシュを読み取る（ブロック１１０６）。状況キャッシュにデータが含まれていなければ（ブロック１１０８）、クライアント・アプリケーションは、ゲームをロックし（ブロック１１３０）、ユーザにフィードバックを表示する（ブロック１１３２）。
【０１１７】
状況キャッシュにデータが含まれている場合（ブロック１１０８）、クライアント・アプリケーションは、キャッシュ・データが、ユーザの電子財布アカウントが有効であり、資金を有していることを示しているか否かの判定を行う（ブロック１１１０）。そうであれば、クライアント・アプリケーションは、キャッシュにデビット・イベントを記憶し、最新の分っている預金残高と対照して負債を累算し（ブロック１１１２）、完全モードによるゲームの開始を承認する（ブロック１１１４）。
【０１１８】
キャッシュ・データが、ユーザの電子財布アカウントが有効ではないか、あるいは、資金を有していないことを示す場合、クライアント・アプリケーションは、ゲームをロックし（ブロック１１３０）、ユーザにフィードバックを表示する（ブロック１１３２）。
【０１１９】
ＧＭＳサーバが連絡可能である場合、クライアント・アプリケーションは、ＧＭＳサーバと共にユーザの電子財布アカウントの状況を確認する（ブロック１１１６）。このゲームの開始料金を賄うのに十分なクレジットが利用できる場合（ブロック１１１８）、ＧＭＳサーバは、開始料金の額だけ電子財布アカウントの借方につけ（ブロック１１２０）、クライアント・アプリケーションに対して、デバイス状況キャッシュを更新するように命令し（ブロック１１２２）、完全モードによるゲーム開始の承認を送る（ブロック１１２４）。実施形態の１つでは、ユーザは、支払請求可能なイベントが生じる毎に、その電子財布と対照して料金を承認するように求められる。代替実施形態では、ユーザの承認を求めることなく、電子財布に自動的に勘定がつけられる。
【０１２０】
電子財布アカウントに、このゲームの開始料金を賄うのに十分な資金がなければ（ブロック１１１８）、ＧＭＳサーバは、電子財布に再入金する解決法を呼び出し、ユーザに対して、電子財布アカウントに資金を追加するように勧める（ブロック１１２６）。ユーザがアカウントに十分な資金を追加すると、ＧＭＳサーバは、ブロック１１２０に戻る。さもなければ、ＧＭＳサーバは、クライアント・アプリケーションにロック・コマンドを送る（ブロック１１３０）。クライアント・アプリケーションは、ゲームをロックして、ユーザにフィードバックを表示する（ブロック１１３２）。
【０１２１】
代替実施形態において、ユーザの電子財布アカウントは、ゲーミング・パラメータ（例えば、高スコア等）に基づいて信用取引が可能である。例えば、ユーザが請求することが可能な賞金（例えば、ゲームまたは、他のプレミアム・アプリケーション・サービスに関する）としての電子財布通貨によって、コンテストを維持することが可能である。この通貨は、実際の電子財布通貨とは別個に監視することができるので、例えば、賞金通貨で１０のアプリケーションを購入したユーザが、課せられる料金について信用取引を要求することはできないし、仮想通貨から実際の通貨への変換が許可されることもあり得ない。
【０１２２】
さらに他の実施形態の場合、プレミアムＳＭＳメッセージを利用して、ユーザの電子財布アカウントに「請求する」ことが可能である（例えば、通信事業者に直接請求書を送ることができない場合）。例えば、ユーザは、アカウントにユーザの電話番号を登録することが可能であり、ＧＭＳサーバにＳＭＳメッセージを送る。これによって、プレミアムＳＭＳ応答がトリガされ、受け入れられれば、プレミアムＳＭＳメッセージの値がユーザの電子財布アカウントの貸方に記入される。従って、これは、ユーザがつけで支払うことが可能な（アンロック、リース、業務用ゲーム機等のために）仮想バンクになる。使い果たすと、業務用ゲーム機モデルや任意の反復リース・モデルは、電子財布アカウントに再入金されるまで、「失効」する。例えば、リース・モデルによって決められた反復使用料が存在する可能性があり（例えば、スポーツ・パッケージは毎月５ドルかかる）、従って、これは、電子財布アカウントの借方に記入されるか、代替清算機関（スポーツ・リーグ、通信事業者自体等）に請求書が送られる可能性がある。次に、この請求が受け入れられるか、拒否されるかに応じて、アンロック機構は、然るべく応答する。
【０１２３】
上記方法の組み合わせも可能である。例えば、新規ユーザまたは入金相殺の履歴のあるユーザに関するファイルでは、最小限の信用取引を堅持することが可能であり、ユーザは、規定の下限の信用取引（例えば、５ドル）を行うことが可能になる。この限界に達すると、ＧＭＳサーバは、通信事業者または他のビリング・プロバイダにリアルタイムで請求処理を試みることが可能であるが、アプリケーションは、残高が０に達するまで、依然として機能することが可能である。
【０１２４】
図１２を参照すると、プレミアムＳＭＳメッセージを利用するゲーム・アンロック・プロセス１２００が例示されている。プロセス１２００は、デモ・モードによる組み込みゲームを提供する通信事業者のシステムによって実施可能である。
【０１２５】
ブロック１１０２において、クライアント・アプリケーションは、ユーザに対し、ユーザのクライアント・デバイスに送られるプレミアムＳＭＳメッセージによって、完全アンロックを承認するように促すメニューを表示する。
【０１２６】
ブロック１２０４において、クライアント・アプリケーションは、ユーザがプレミアムＳＭＳメッセージによる完全アンロックの要求を承諾するか否か（すなわち、ユーザがプレミアムＳＭＳの金額を支払うことを承諾するか否か）を判定する。承諾しなければ、クライアント・アプリケーションは、デモ・モードによるゲームの開始を承認する（ブロック１２０６）。承諾すれば、クライアント・アプリケーションは、ＳＭＳ要求を送り（ブロック１２０８）、ユーザがＳＭＳ購入の続行を選択するか否かを判定する（ブロック１２１０）。
【０１２７】
ユーザがＳＭＳ購入の続行を望まない場合、クライアント・アプリケーションは、デモ・モードによるゲーム開始を承認する（ブロック１２０６）。さもまければ、プレミアムＳＭＳメッセージが、ユーザのクライアント・デバイスに送られる（ブロック１２１２）。ユーザがプレミアムＳＭＳメッセージを受け入れると（ブロック１２１４）、ＳＭＳペイロードが、クライアント・アプリケーションによって解釈され、完全機能性が使用可能になり（ブロック１２１６）、その結果、アプリケーションが完全モードでアンロックされる（ブロック１２１８）。
【０１２８】
ユーザがプレミアムＳＭＳメッセージを受け入れなければ（ブロック１２１４）、クライアント・アプリケーションは、デモ・モードによるゲーム開始を承認する（ブロック１２０６）。
【０１２９】
典型的なコンピュータ・システム
図１３は、本明細書に解説の１つ以上のオペレーションを実施するために利用することが可能な、典型的なコンピュータ・システム１３００のブロック図である。代替実施形態の場合、この機械には、ネットワーク・ルータ、ネットワーク・スイッチ、ネットワーク・ブリッジ、携帯端末（ＰＤＡ）、携帯電話、ウェブ機器、または、その機械が行うべき動作を指定する一連の命令を実行することが可能な任意の機械を含む。
【０１３０】
コンピュータ・システム１３００には、バス１３０８を介して相互通信する、プロセッサ１３０２、主メモリ１３０４、スタティック・メモリ１３０６が含まれている。コンピュータ・システム１３００には、さらに、ビデオ・ディスプレイデバイス１３１０（例えば、液晶ディスプレイ（ＬＣＤ）またはブラウン管（ＣＲＴ））を含む。コンピュータ・システム１３００には、英数字入力デバイス１３１２（例えば、キーボード）、カーソル制御デバイス１３１４（例えば、マウス）、ディスク・ドライブデバイス１３１６、信号発生デバイス１３２０（例えば、スピーカ）、ネットワーク・インターフェイスデバイス１３２２も含まれている。
【０１３１】
ディスク・ドライブデバイス１３１６には、上述の技法の任意の１つまたは全てを具現化した命令集合（すなわち、ソフトウェア）１３２６が記憶されている、コンピュータ可読媒体１３２４が含まれている。ソフトウェア１３２６は、完全にまたは少なくとも部分的に、主メモリ１３０４及び／またはプロセッサ１３０２内に納めれている。ソフトウェア１３２６は、さらに、ネットワーク・インターフェイスデバイス１３２２を介して送信または受信することが可能である。本明細書の目的上、「コンピュータ可読媒体」という用語は、コンピュータによって実行するための一連の命令を記憶または符号化することが可能であり、コンピュータに本発明の技法の任意の１つを実施させる、任意の媒体を含むものと解釈しなければならない。「コンピュータ可読媒体」という用語は、従って、制限するわけではないが、固体メモリ、光ディスクと磁気ディスク、搬送波信号を含むものと解釈しなければならない。
【０１３２】
上記説明の読了後、通常の当該技術者であれば、きっと、本発明の多くの改変及び修正が明らかになるであろうが、もちろん、例証のため示され、解説されたどの特定の実施形態も、決して制限とみなされることを意図したものではない。従って、各種実施形態の細部に対する言及は、それ自体、本発明にとって必須であるとみなされる特徴だけを列挙した請求の範囲を制限することを意図したものではない。
【図面の簡単な説明】
【０１３３】
【図１】本発明の実施形態が機能するシステムの実施形態の１つに関するブロック図である。
【図２Ａ】ゲーム管理システムの実施形態の１つのブロック図である。
【図２Ｂ】ゲーミング・データ・モジュールの実施形態の１つのブロック図である。
【図３】ユーザ・デバイスによる電子ゲームの使用を制御するためのプロセスに関する２つの実施形態の流れ図である。
【図４】ユーザ・デバイスによる電子ゲームの使用を制御するためのプロセスに関する２つの実施形態の流れ図である。
【図５】ゲーム広告プロセスの実施形態の１つの流れ図である。
【図６】ゲーム・アンロック・プロセスの実施形態の１つを例示した図である。
【図７】ゲーム・アンロック・プロセスの各種実施形態を例示した図である。
【図８】ゲーム・アンロック・プロセスの各種実施形態を例示した図である。
【図９】ゲーム・アンロック・プロセスの各種実施形態を例示した図である。
【図１０】ゲーム・アンロック・プロセスの各種実施形態を例示した図である。
【図１１】ゲーム・アンロック・プロセスの各種実施形態を例示した図である。
【図１２】ゲーム・アンロック・プロセスの各種実施形態を例示した図である。
【図１３】典型的なコンピュータ・システムのブロック図である。
【特許請求の範囲】
【請求項１】
第１のユーザ・デバイスのためにユーザが選択したゲームを識別するステップと、
第２のユーザ・デバイスのために前記ユーザが前記ゲームを購入済みであることを確認するステップと、
前記第１のユーザ・デバイスで楽しむために、前記ユーザが前記ゲームを利用できるようにするステップと
が含まれている方法。
【請求項２】
前記第１のユーザ・デバイスが、第１の無線通信事業者に関連した無線デバイスで、
前記第２のユーザ・デバイスが、第２の無線通信事業者に関連した無線デバイスであることを特徴とする請求項１に記載の方法。
【請求項３】
前記第１のユーザ・デバイスが無線デバイスで、
前記第２のユーザ・デバイスが、パーソナル・コンピュータ、ハンドヘルド・コンピュータ、ビデオ・ゲーム機の任意の１つであることを特徴とする請求項１に記載の方法。
【請求項４】
前記ユーザが前記ゲームを購入済みであることを確認するステップに、
ユーザ識別情報を受信するステップと、
データベース内で前記ゲームに関連した、一致するユーザ識別情報を見つけるステップが含まれることを特徴とする請求項１に記載の方法。
【請求項５】
さらに、
前記ユーザが前記第２のユーザ・デバイスのために前記ゲームを購入する際に、前記一致するユーザ識別情報を受信するステップと、
前記ゲームに関連した前記一致するユーザ識別情報を前記データベースに記憶するステップが含まれることを特徴とする請求項４に記載の方法。
【請求項６】
前記ユーザ識別情報に、ユーザ識別子とパスワードが含まれることを特徴とする請求項４に記載の方法。
【請求項７】
前記ユーザ識別情報に、前記ゲームに関連した一意性コードが含まれることを特徴とする請求項４に記載の方法。
【請求項８】
さらに、
前記ユーザが前記ゲームを利用できるようにする前に、前記ユーザが１つ以上のゲーム・アンロック基準を満たすか否かを判定するステップが含まれることを特徴とする請求項１に記載の方法。
【請求項９】
さらに、
前記ユーザが１つ以上のゲーム・ロック基準を満たすことを確認するステップと、
前記ゲームに対するユーザ・アクセスを打ち切るステップと
が含まれることを特徴とする請求項１に記載の方法。
【請求項１０】
前記ユーザが選択した前記ゲームを識別するステップに、
前記第１のユーザ・デバイスに前記ゲームのデモ・バージョンをダウンロードするユーザ要求を検出するステップが含まれることを特徴とする請求項１に記載の方法。
【請求項１１】
前記ゲームの前記デモ・バージョンによって、前記ゲームの制限された機能性が提供されることを特徴とする請求項１０に記載の方法。
【請求項１２】
前記ユーザが前記ゲームを利用できるようにするステップに、
前記ゲームの前記デモ・バージョンに関連した制限を無効にするステップが含まれる特徴とする請求項１１に記載の方法。
【請求項１３】
さらに、
前記ユーザに新ゲームについて通知するステップと、
前記新ゲームを試行するユーザ承諾を受信するステップと、
前記第１のユーザ・デバイスに前記新ゲームのデモをダウンロードするステップと、
前記ユーザが前記新ゲームを購入したことを確認すると、前記第１のユーザ・デバイスで楽しむために、前記ユーザが前記新ゲームを利用できるようにするステップと
が含まれることを特徴とする請求項１に記載の方法。
【請求項１４】
さらに、
前記第１のユーザ・デバイスから前記ゲームのメトリクスを受信するステップと、
前記第２のユーザ・デバイスから受信した前記ゲーム・メトリクスと共に、前記第１のユーザ・デバイスから受信した前記メトリクスを記憶するステップと
が含まれることを特徴とする請求項１に記載の方法。
【請求項１５】
さらに、
複数のデバイスプラットフォームにわたる前記ゲームの複数のプレーヤを網羅する、前記ゲームに関するスコア・リストを維持管理するステップと、
前記スコア・リストを前記ユーザに表示するステップと
が含まれることを特徴とする請求項１に記載の方法。
【請求項１６】
さらに、
前記ユーザに関連した記憶データを分析するステップと、
前記分析データに基づいて、前記ユーザに表示すべき広告を選択するステップと
が含まれることを特徴とする請求項１に記載の方法。
【請求項１７】
無線デバイスに存在するゲームをアンロックする要求を前記無線デバイスから受信するステップと、
前記無線デバイスのユーザがアンロック基準を満たしていることを判定するステップと、
前記無線デバイスに対して、前記ゲームのアンロック命令を伝達するステップと
が含まれている方法。
【請求項１８】
さらに、
前記無線デバイスのユーザが前記アンロック基準を満たすことを確認すると、前記ゲームの価格を前記ユーザに請求する要求をビリング・システムに送るステップと、
請求額を識別するデータを前記無線デバイスに送るステップと
が含まれることを特徴とする請求項１７に記載の方法。
【請求項１９】
アンロックの前に、前記クライアント・デバイスに存在する前記ゲームが、制限モードで機能し、
前記ゲームをアンロックする前記命令によって、前記ゲームが完全モードで機能することを特徴とする請求項１７に記載の方法。
【請求項２０】
さらに、
前記ユーザが前記アンロック基準を満たさないことを確認するステップと、
前記無線デバイスに前記ゲームをロックする命令を伝達するステップと
が含まれることを特徴とする請求項１７に記載の方法。
【請求項２１】
さらに、
前記ゲームをアンロックする前記命令を伝達する前に、前記ゲームが１つの無線デバイスだけで起動中であることを確認するステップが含まれることを特徴とする請求項１７に記載の方法。
【請求項２２】
クライアント・デバイスのユーザがゲームを開始しようとする毎に、前記クライアント・デバイスから、前記ゲームのアンロック要求を受信するステップと、
前記ゲームを開始するために、支払請求可能なイベントが生じる毎に、前記ゲームのアンロック命令を前記クライアント・デバイスに伝達するステップと
が含まれている方法。
【請求項２３】
前記ゲームが完了する毎に、前記ゲームが自動的にロックされることを特徴とする請求項２２に記載の方法。
【請求項２４】
前記ゲームをアンロックする前記ユーザ要求を受信すると、前記支払請求可能なイベントが生じることを特徴とする請求項２２に記載の方法。
【請求項２５】
さらに、
前記ゲームをアンロックする前記ユーザ要求を受信すると、前記ゲームの開始料金が前記ユーザのアカウントに請求されるようにするステップが含まれることを特徴とする請求項２４に記載の方法。
【請求項２６】
前記ユーザの電子財布アカウントに、前記ゲーム開始料金を賄うのに十分な資金が納められていることを確認すると、前記支払請求可能なイベントが生じることを特徴とする請求項２２に記載の方法。
【請求項２７】
さらに、
前記料金が前記ユーザの前記電子財布アカウントの借方に記入されることを特徴とする請求項２６に記載の方法。
【請求項２８】
さらに、
前記ユーザの前記電子財布アカウントに、前記ゲーム開始料金を賄うのに十分な資金が納められていないことを確認するステップと、
前記ユーザが前記電子財布アカウントに再入金できるようにするステップと、
前記ユーザが、前記電子財布アカウントに、前記ゲーム開始料金を賄うのに十分な資金を追加したことを確認するステップと
が含まれることを特徴とする請求項２６に記載の方法。
【請求項２９】
前記クライアント・デバイスが、携帯電話、パーソナル・コンピュータ、ハンドヘルド・コンピュータ、ビデオ・ゲーム機の任意の１つであることを特徴とする請求項２２に記載の方法。
【請求項３０】
ユーザに関連したデータを記憶するためのデータベースと、
第１のユーザ・デバイスのために前記ユーザが選択したゲームを識別し、前記データベースをサーチして、前記ゲームが、前記ユーザによって第２のユーザ・デバイスのために購入済みであることを確認し、前記第１のユーザ・デバイスで楽しむために、前記ユーザが前記ゲームを利用できるようにするゲーム使用コントローラと
が含まれているシステム。
【請求項３１】
無線デバイスのユーザに関連したデータを記憶するためのデータベースと、
前記無線デバイスから、前記無線デバイスに存在するゲームのアンロック要求を受信すると、前記ユーザに関連した前記データを利用して、前記無線デバイスのユーザがアンロック基準を満たすことを確認し、前記無線デバイスに前記ゲームのアンロック命令を伝達するゲーム使用コントローラと
が含まれているシステム。
【請求項３２】
クライアント・デバイスのユーザがゲームを開始しようとする毎に、前記クライアント・デバイスから、前記ゲームのアンロック要求を受信し、前記ゲームを開始するため、支払請求可能なイベントが生じる毎に、前記クライアント・デバイスに前記ゲームのアンロック命令を伝達するゲーム使用コントローラが含まれているシステム。
【請求項３３】
第１のユーザ・デバイスのためにユーザが選択したゲームを識別する手段と、
第２のユーザ・デバイスのために前記ユーザが前記ゲームを購入済みであることを確認する手段と、
前記第１のユーザ・デバイスで楽しむために、前記ユーザが前記ゲームを利用できるようにするための手段と
が含まれているデバイス。
【請求項３４】
無線デバイスから、前記無線デバイスに存在するゲームのアンロック要求を受信する手段と、
前記無線デバイスのユーザがアンロック基準を満たすことを確認する手段と、
前記無線デバイスに前記ゲームのアンロック命令を伝達する手段と
が含まれているデバイス。
【請求項３５】
クライアント・デバイスのユーザがゲームを開始しようとする毎に、前記クライアント・デバイスから前記ゲームのアンロック要求を受信する手段と、
前記ゲームを開始するため、支払請求可能なイベントが生じる毎に、前記ゲームのアンロック命令を前記クライアント・デバイスに伝達する手段と
が含まれているデバイス。
【請求項３６】
処理システムにおける実行時に、
第１のユーザ・デバイスのためにユーザが選択したゲームを識別するステップと、
第２のユーザ・デバイスのために前記ユーザが前記ゲームを購入済みであることを確認するステップと、
前記第１のユーザ・デバイスで楽しむために、前記ユーザが前記ゲームを利用できるようにするステップと
が含まれている方法を前記処理システムに実施させる、実行可能命令を含んでいるコンピュータ可読媒体。
【請求項３７】
処理システムにおける実行時に、
無線デバイスから、前記無線デバイスに存在するゲームのアンロック要求を受信するステップと、
前記無線デバイスのユーザがアンロック基準を満たすことを確認するステップと、
前記ゲームのアンロック命令を前記無線デバイスに伝達するステップと
が含まれている方法を前記処理システムに実施させる、実行可能命令を含んでいるコンピュータ可読媒体。
【請求項３８】
処理システムにおける実行時に、
クライアント・デバイスのユーザがゲームを開始しようとする毎に、前記クライアント・デバイスから、前記ゲームのアンロック要求を受信するステップと、
前記ゲームを開始するために、支払請求可能なイベントが生じる毎に、前記ゲームのアンロック命令を前記クライアント・デバイスに伝達するステップと
が含まれている方法を前記処理システムに実施させる、実行可能命令を含んでいるコンピュータ可読媒体。
【請求項１】
第１のユーザ・デバイスのためにユーザが選択したゲームを識別するステップと、
第２のユーザ・デバイスのために前記ユーザが前記ゲームを購入済みであることを確認するステップと、
前記第１のユーザ・デバイスで楽しむために、前記ユーザが前記ゲームを利用できるようにするステップと
が含まれている方法。
【請求項２】
前記第１のユーザ・デバイスが、第１の無線通信事業者に関連した無線デバイスで、
前記第２のユーザ・デバイスが、第２の無線通信事業者に関連した無線デバイスであることを特徴とする請求項１に記載の方法。
【請求項３】
前記第１のユーザ・デバイスが無線デバイスで、
前記第２のユーザ・デバイスが、パーソナル・コンピュータ、ハンドヘルド・コンピュータ、ビデオ・ゲーム機の任意の１つであることを特徴とする請求項１に記載の方法。
【請求項４】
前記ユーザが前記ゲームを購入済みであることを確認するステップに、
ユーザ識別情報を受信するステップと、
データベース内で前記ゲームに関連した、一致するユーザ識別情報を見つけるステップが含まれることを特徴とする請求項１に記載の方法。
【請求項５】
さらに、
前記ユーザが前記第２のユーザ・デバイスのために前記ゲームを購入する際に、前記一致するユーザ識別情報を受信するステップと、
前記ゲームに関連した前記一致するユーザ識別情報を前記データベースに記憶するステップが含まれることを特徴とする請求項４に記載の方法。
【請求項６】
前記ユーザ識別情報に、ユーザ識別子とパスワードが含まれることを特徴とする請求項４に記載の方法。
【請求項７】
前記ユーザ識別情報に、前記ゲームに関連した一意性コードが含まれることを特徴とする請求項４に記載の方法。
【請求項８】
さらに、
前記ユーザが前記ゲームを利用できるようにする前に、前記ユーザが１つ以上のゲーム・アンロック基準を満たすか否かを判定するステップが含まれることを特徴とする請求項１に記載の方法。
【請求項９】
さらに、
前記ユーザが１つ以上のゲーム・ロック基準を満たすことを確認するステップと、
前記ゲームに対するユーザ・アクセスを打ち切るステップと
が含まれることを特徴とする請求項１に記載の方法。
【請求項１０】
前記ユーザが選択した前記ゲームを識別するステップに、
前記第１のユーザ・デバイスに前記ゲームのデモ・バージョンをダウンロードするユーザ要求を検出するステップが含まれることを特徴とする請求項１に記載の方法。
【請求項１１】
前記ゲームの前記デモ・バージョンによって、前記ゲームの制限された機能性が提供されることを特徴とする請求項１０に記載の方法。
【請求項１２】
前記ユーザが前記ゲームを利用できるようにするステップに、
前記ゲームの前記デモ・バージョンに関連した制限を無効にするステップが含まれる特徴とする請求項１１に記載の方法。
【請求項１３】
さらに、
前記ユーザに新ゲームについて通知するステップと、
前記新ゲームを試行するユーザ承諾を受信するステップと、
前記第１のユーザ・デバイスに前記新ゲームのデモをダウンロードするステップと、
前記ユーザが前記新ゲームを購入したことを確認すると、前記第１のユーザ・デバイスで楽しむために、前記ユーザが前記新ゲームを利用できるようにするステップと
が含まれることを特徴とする請求項１に記載の方法。
【請求項１４】
さらに、
前記第１のユーザ・デバイスから前記ゲームのメトリクスを受信するステップと、
前記第２のユーザ・デバイスから受信した前記ゲーム・メトリクスと共に、前記第１のユーザ・デバイスから受信した前記メトリクスを記憶するステップと
が含まれることを特徴とする請求項１に記載の方法。
【請求項１５】
さらに、
複数のデバイスプラットフォームにわたる前記ゲームの複数のプレーヤを網羅する、前記ゲームに関するスコア・リストを維持管理するステップと、
前記スコア・リストを前記ユーザに表示するステップと
が含まれることを特徴とする請求項１に記載の方法。
【請求項１６】
さらに、
前記ユーザに関連した記憶データを分析するステップと、
前記分析データに基づいて、前記ユーザに表示すべき広告を選択するステップと
が含まれることを特徴とする請求項１に記載の方法。
【請求項１７】
無線デバイスに存在するゲームをアンロックする要求を前記無線デバイスから受信するステップと、
前記無線デバイスのユーザがアンロック基準を満たしていることを判定するステップと、
前記無線デバイスに対して、前記ゲームのアンロック命令を伝達するステップと
が含まれている方法。
【請求項１８】
さらに、
前記無線デバイスのユーザが前記アンロック基準を満たすことを確認すると、前記ゲームの価格を前記ユーザに請求する要求をビリング・システムに送るステップと、
請求額を識別するデータを前記無線デバイスに送るステップと
が含まれることを特徴とする請求項１７に記載の方法。
【請求項１９】
アンロックの前に、前記クライアント・デバイスに存在する前記ゲームが、制限モードで機能し、
前記ゲームをアンロックする前記命令によって、前記ゲームが完全モードで機能することを特徴とする請求項１７に記載の方法。
【請求項２０】
さらに、
前記ユーザが前記アンロック基準を満たさないことを確認するステップと、
前記無線デバイスに前記ゲームをロックする命令を伝達するステップと
が含まれることを特徴とする請求項１７に記載の方法。
【請求項２１】
さらに、
前記ゲームをアンロックする前記命令を伝達する前に、前記ゲームが１つの無線デバイスだけで起動中であることを確認するステップが含まれることを特徴とする請求項１７に記載の方法。
【請求項２２】
クライアント・デバイスのユーザがゲームを開始しようとする毎に、前記クライアント・デバイスから、前記ゲームのアンロック要求を受信するステップと、
前記ゲームを開始するために、支払請求可能なイベントが生じる毎に、前記ゲームのアンロック命令を前記クライアント・デバイスに伝達するステップと
が含まれている方法。
【請求項２３】
前記ゲームが完了する毎に、前記ゲームが自動的にロックされることを特徴とする請求項２２に記載の方法。
【請求項２４】
前記ゲームをアンロックする前記ユーザ要求を受信すると、前記支払請求可能なイベントが生じることを特徴とする請求項２２に記載の方法。
【請求項２５】
さらに、
前記ゲームをアンロックする前記ユーザ要求を受信すると、前記ゲームの開始料金が前記ユーザのアカウントに請求されるようにするステップが含まれることを特徴とする請求項２４に記載の方法。
【請求項２６】
前記ユーザの電子財布アカウントに、前記ゲーム開始料金を賄うのに十分な資金が納められていることを確認すると、前記支払請求可能なイベントが生じることを特徴とする請求項２２に記載の方法。
【請求項２７】
さらに、
前記料金が前記ユーザの前記電子財布アカウントの借方に記入されることを特徴とする請求項２６に記載の方法。
【請求項２８】
さらに、
前記ユーザの前記電子財布アカウントに、前記ゲーム開始料金を賄うのに十分な資金が納められていないことを確認するステップと、
前記ユーザが前記電子財布アカウントに再入金できるようにするステップと、
前記ユーザが、前記電子財布アカウントに、前記ゲーム開始料金を賄うのに十分な資金を追加したことを確認するステップと
が含まれることを特徴とする請求項２６に記載の方法。
【請求項２９】
前記クライアント・デバイスが、携帯電話、パーソナル・コンピュータ、ハンドヘルド・コンピュータ、ビデオ・ゲーム機の任意の１つであることを特徴とする請求項２２に記載の方法。
【請求項３０】
ユーザに関連したデータを記憶するためのデータベースと、
第１のユーザ・デバイスのために前記ユーザが選択したゲームを識別し、前記データベースをサーチして、前記ゲームが、前記ユーザによって第２のユーザ・デバイスのために購入済みであることを確認し、前記第１のユーザ・デバイスで楽しむために、前記ユーザが前記ゲームを利用できるようにするゲーム使用コントローラと
が含まれているシステム。
【請求項３１】
無線デバイスのユーザに関連したデータを記憶するためのデータベースと、
前記無線デバイスから、前記無線デバイスに存在するゲームのアンロック要求を受信すると、前記ユーザに関連した前記データを利用して、前記無線デバイスのユーザがアンロック基準を満たすことを確認し、前記無線デバイスに前記ゲームのアンロック命令を伝達するゲーム使用コントローラと
が含まれているシステム。
【請求項３２】
クライアント・デバイスのユーザがゲームを開始しようとする毎に、前記クライアント・デバイスから、前記ゲームのアンロック要求を受信し、前記ゲームを開始するため、支払請求可能なイベントが生じる毎に、前記クライアント・デバイスに前記ゲームのアンロック命令を伝達するゲーム使用コントローラが含まれているシステム。
【請求項３３】
第１のユーザ・デバイスのためにユーザが選択したゲームを識別する手段と、
第２のユーザ・デバイスのために前記ユーザが前記ゲームを購入済みであることを確認する手段と、
前記第１のユーザ・デバイスで楽しむために、前記ユーザが前記ゲームを利用できるようにするための手段と
が含まれているデバイス。
【請求項３４】
無線デバイスから、前記無線デバイスに存在するゲームのアンロック要求を受信する手段と、
前記無線デバイスのユーザがアンロック基準を満たすことを確認する手段と、
前記無線デバイスに前記ゲームのアンロック命令を伝達する手段と
が含まれているデバイス。
【請求項３５】
クライアント・デバイスのユーザがゲームを開始しようとする毎に、前記クライアント・デバイスから前記ゲームのアンロック要求を受信する手段と、
前記ゲームを開始するため、支払請求可能なイベントが生じる毎に、前記ゲームのアンロック命令を前記クライアント・デバイスに伝達する手段と
が含まれているデバイス。
【請求項３６】
処理システムにおける実行時に、
第１のユーザ・デバイスのためにユーザが選択したゲームを識別するステップと、
第２のユーザ・デバイスのために前記ユーザが前記ゲームを購入済みであることを確認するステップと、
前記第１のユーザ・デバイスで楽しむために、前記ユーザが前記ゲームを利用できるようにするステップと
が含まれている方法を前記処理システムに実施させる、実行可能命令を含んでいるコンピュータ可読媒体。
【請求項３７】
処理システムにおける実行時に、
無線デバイスから、前記無線デバイスに存在するゲームのアンロック要求を受信するステップと、
前記無線デバイスのユーザがアンロック基準を満たすことを確認するステップと、
前記ゲームのアンロック命令を前記無線デバイスに伝達するステップと
が含まれている方法を前記処理システムに実施させる、実行可能命令を含んでいるコンピュータ可読媒体。
【請求項３８】
処理システムにおける実行時に、
クライアント・デバイスのユーザがゲームを開始しようとする毎に、前記クライアント・デバイスから、前記ゲームのアンロック要求を受信するステップと、
前記ゲームを開始するために、支払請求可能なイベントが生じる毎に、前記ゲームのアンロック命令を前記クライアント・デバイスに伝達するステップと
が含まれている方法を前記処理システムに実施させる、実行可能命令を含んでいるコンピュータ可読媒体。
【図１】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２Ａ】
【図２Ｂ】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公表番号】特表２００８−５１３１８４（Ｐ２００８−５１３１８４Ａ）
【公表日】平成２０年５月１日（２００８．５．１）
【国際特許分類】
【出願番号】特願２００７−５３３６８５（Ｐ２００７−５３３６８５）
【出願日】平成１７年９月２１日（２００５．９．２１）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０３４３２０
【国際公開番号】ＷＯ２００６／０３４４８２
【国際公開日】平成１８年３月３０日（２００６．３．３０）
【出願人】（５０７０９２０６７）ティーエイチキュー・ワイヤレス・インコーポレーテッド (2)
【Ｆターム（参考）】
【公表日】平成２０年５月１日（２００８．５．１）
【国際特許分類】
【出願日】平成１７年９月２１日（２００５．９．２１）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０３４３２０
【国際公開番号】ＷＯ２００６／０３４４８２
【国際公開日】平成１８年３月３０日（２００６．３．３０）
【出願人】（５０７０９２０６７）ティーエイチキュー・ワイヤレス・インコーポレーテッド (2)
【Ｆターム（参考）】
[ Back to top ]