JP2015501014A - アプリケーションの収益化プラットフォーム - Google Patents

Abstract

ユーザの賭け行為を支援するアプリケーションを促進するための、コンピュータにより実現されるゲーム管理システムについて、種々の実施形態を示す。ゲーム管理システムは、開発者コンピュータ装置と連絡するコンピュータシステムを備える。このコンピュータシステムは、ユーザプリケーションに対応付けられた不確定事象の設定データを開発者コンピュータ装置から受け取るようにプログラムされており、コンピュータシステムは、設定データが少なくとも１個の所定の基準を満たすか否かを決定し、設定データが少なくとも１個の所定の基準を満たしている場合は、開発者コンピュータ装置に、ユーザプリケーションにより利用されるためのアプリケーションプログラムインターフェイス（ＡＰＩ）証明書を供給し、このＡＰＩ証明書は、不確定事象を決定するためにユーザプリケーションがＡＰＩにアクセスすることを可能とする。
【選択図】図１

Description

本出願の請求項は、２０１１年８月９日に出願された米国仮出願・出願番号６１／５２１，７３３と、２０１２年７月９日に出願された米国仮出願・出願番号６１／６６９，４４３の利益を主張し、いずれも参照のため本出願に取り込むものとする。

本出願は、一般に、ギャンブル及び／又は第三者のゲームに賭けるアプリケーションの賭けの実行に関連する。

近年のコンピュータ技術の発達は、デスクトップ、ラップトップなどの旧来のコンピュータ装置に加え、モバイルスマートフォン、タブレットコンピュータなどの携帯装置を含む、さまざまな種類のコンピュータ装置で実行可能なアプリケーションの市場を増大させてきた。よく知られたアプリケーションのジャンルのひとつはゲームアプリケーションであり、ユーザは、様々な難易度の仮想ゲームをプレイする。多くのアプリケーションが流通しているものの、近年の、開発者によるアプリケーションの収益化の手法は、しばしば不適切である。

ゲームアプリケーションの収益化の手法として存在するひとつの手法は、ゲーム内の広告に依存するものである。広告はアプリケーション自体の中で提供され、ユーザと特定の広告間での相互作用（たとえば、広告の露出回数、クイックスルーの回数等）に基づいて、開発者に売上を提供する。しかしながら、多くのゲームアプリケーションのユーザは、そのような広告を、せいぜい迷惑としか考えていない。広告、すなわち多すぎる広告をそのゲームアプリケーション内に含める開発者は、潜在的ユーザを失うというリスクを負っている。

現存するゲームアプリケーションの収益化の手法の他の手法によれば、開発者は、アプリケーション自体を実行するコードへのアクセス権につき、ユーザに課金している。購入されたアクセス権には、ユーザのコンピュータ装置に、コード（たとえば、実行可能な形態で）をダウンロードすること、及び／又はリモートサーバで実行されるアプリケーションにアクセスすることが含まれる。しかしながら、対応付けられたゲームをプレイする前に、ユーザがアプリケーションに対して支払いをするように仕向けることは難しい。

更に他の収益化の手法によれば、ユーザは当初、ゲームアプリケーションへのアクセスを無料で提供される。ひとたびユーザがアプリケーションにアクセスを開始すると、当該ユーザは、ゲーム内で用いられる仮想の商品、及び／又は追加のレベルなどの追加物を購入する機会を提供される。この手法は、仮想の商品やレベルを購入することを充分に動機付けられたユーザに対しては、高いユーザ当たり収益を発生させる可能性がある。しかしながら、典型的には、多くのユーザは追加物を購入することなく単にゲームの無料部分のゲームをプレイする。したがって、無料から有料への転換率はしばしば比較的低い。したがって、顧客生涯価値（ＣＬＶ）の平均と、ユーザ当たりの平均売上（ＡＲＰＵ）は、しばしば低い。

ユーザの賭け行為を支援するアプリケーションを促進するための、コンピュータにより実現されるゲーム管理システムについて、種々の実施形態を示す。

ゲーム管理システムは、開発者コンピュータ装置と連絡するコンピュータシステムを備える。このコンピュータシステムは、ユーザプリケーションに対応付けられた不確定事象（ｃｏｎｔｉｎｇｅｎｔ ｅｖｅｎｔ）の設定データを開発者コンピュータ装置から受け取るようにプログラムされており、コンピュータシステムは、設定データが少なくとも１個の所定の基準を満たすか否かを決定し、設定データが少なくとも１個の所定の基準を満たしている場合は、開発者コンピュータ装置に、ユーザプリケーションにより利用されるためのアプリケーションプログラムインターフェイス（ＡＰＩ）証明書（ｃｒｅｄｅｎｔｉａｌ）を供給し、このＡＰＩ証明書は、不確定事象を決定するためにユーザプリケーションがＡＰＩにアクセスすることを可能とする。

ここに説明するいずれの実施例においても、任意的に、前記設定データが少なくとも１個の所定の基準を満たすか否かの決定は、前記設定データを、許容される不確定事象の設定のセットと比較することから構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記許容される不確定事象の設定のセットは、前記開発者ではなく前記ゲーム管理システムの実施者によって保持されたギャンブルのライセンスに関連する少なくとも１個の規制上の要件に基づいていてもよい。幾つかの実施例において、前記設定データが少なくとも１個の所定の基準を満たすか否かの決定は、前記設定データに基づき、少なくも１個の設定事象パラメータを計算することと、前記少なくとも１個の設定パラメータを、規制上の要件のうち少なくとも１個、及び、少なくとも１個の規制上の要件を事前に満たした不確定事象の形式の設定パラメータと比較すること、により構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記コンピュータシステムは更に、許容される事象の設定を計算し、前記許容される事象の設定を前記開発者コンピュータ装置に供給し、前記開発者コンピュータ装置より前記設定データの更新を受け取るようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記コンピュータシステムは更に、賭博場の資金が前記開発者から供給されるのか否かの告知を前記開発者コンピュータ装置に促し、前記賭博場の資金が前記開発者から供給されるのか否かに基づき、前記開発者への補償のレベルを設定するようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記コンピュータシステムは更に、前記開発者コンピュータ装置の支払機構から前記コンピュータシステムに対応付けられたアカウントへと金銭を転送するためのリクエストを前記開発者コンピュータ装置から受け取るようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記コンピュータシステムは更に、前記ＡＰＩ証明書により構成された前記アプリケーションを受け取るようにプログラムされていてもよい。いくつかの実施形態において前記コンピュータシステムは更に、前記アプリケーションを利用して試験的な賭けを複数実行するようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記コンピュータシステムは更に、前記ＡＰＩ証明書により構成されたアプリケーションの告知を公開するようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記不確定事象の前記設定データは更に、前記不確定事象が現実の金銭の賭けを対象とする旨の告知により構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記不確定事象の前記設定データは、賭金の最大許容値より構成されていてもよく、前記コンピュータシステムは更に、単位量の賭金あたりの推定利益を決定し、前記推定利益を前記開発者コンピュータ装置へと供給するようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記アプリケーションに関連付けられた前記不確定事象の指標は、前記不確定事象の不確定事象タイプを含んでいてもよく、前記コンピュータシステムは更に、前記不確定事象の前記設定データの少なくとも一部を受け取るためのテンプレートを前記開発者システムに提供するようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記不確定事象タイプはスロットマシン事象タイプであってもよく、前記設定データの少なくとも一部を受け取るための前記テンプレートは、リール数を受け取るためのフィールド、リール上に現れる少なくとも１個のシンボルを受け取るためのフィールド、及びリールの少なくとも１個のペイラインを受け取るためのフィールドにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記不確定事象タイプはキノ事象タイプであってもよく、前記設定データの少なくとも一部を受け取るための前記テンプレートは、少なくとも第１のチケットタイプにつき各潜在的結果（ｐｏｔｅｎｔｉａｌ ｏｕｔｃｏｍｅ）を記述するデータを受け取るためのフィールドにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記不確定事象タイプはルーレット事象タイプであってもよく、前記設定データの少なくとも一部を受け取るための前記テンプレートは、スロットの数を受け取るためのフィールドにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記設定データの少なくとも一部を受け取るための前記テンプレートは、第１の結果につき結果発生確率を受け取るためのフィールド、前記第１の結果につきペイアウト係数（ｐａｙｏｕｔ ｆａｃｔｏｒ）を受け取るためのフィールド、第２の結果につき結果発生確率を受け取るためのフィールド、及び前記第２の結果につきペイアウト係数を受け取るためのフィールドにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記不確定事象からの前記設定データは、前記不確定事象についての賭博場の取り分の指示により構成されていてもよい。

様々な実施形態が、コンピュータにより実現されるゲーム管理システムに向けられる。
前記ゲーム管理システムは、ユーザ装置により少なくとも一部が実行されるアプリケーションと連絡するコンピュータシステムを備えてもよい。前記コンピュータシステムは、前記アプリケーションから、前記アプリケーションに対応付けられた少なくとも１個の不確定事象が前記ゲーム管理システムによって承認されたことを示すアプリケーション認証を受け、前記ユーザ装置に、前記ユーザ装置のユーザを記述する情報を受け取るための認証インターフェースを供給し、前記認証インタフェースを介して、前記ユーザから、前記ユーザを記述する情報を受け取り、前記ユーザが賭けを行う資格を有するか否かを、前記ユーザを記述した情報に基づいて判定し、前記ユーザが賭けを行う資格を有することを条件として、前記アプリケーションから不確定事象リクエストを受け取り、前記不確定事象リクエストは、前記不確定事象に関し、複数の潜在的結果及び前記ユーザにより賭けられた賭金を記述するものであってもよいものであって、前記複数の潜在的結果の各々は確率に対応付けられていてもよく、前記複数の確率に基づいて、前記複数の潜在的結果から前記不確定事象の結果を選択し、前記賭金に基づいて、前記選択された結果に対応付けられる結果額を計算し、前記結果額を、前記ユーザに対応付けられているアカウントに適用するようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記ユーザが賭けを行う資格を有するか否かの判定は、前記ユーザを記述した情報を、前記ゲーム管理システムの実施者によって保持されたギャンブルのライセンスに関連する少なくとも１個の規制上の要件と比較することから構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記コンピュータシステムは更に、前記結果及び前記結果額の告知を前記ユーザ装置に送るようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記ユーザを記述する情報は、前記ユーザの生年月日及び前記ユーザの地理的位置により構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記ユーザに対応付けられているアカウントへの前記結果額の適用は、前記ユーザに対応付けられた金融口座を保持する金融機関に少なくとも１個の指示を送ることにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記不確定事象リクエストは更に、前記複数の潜在的結果のうちの少なくとも１個に対応付けられる確率を決定するための少なくとも１個のパラメータにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記コンピュータシステムは更に、賭金が金銭の賭金であるか否かの告知を前記ユーザ装置に促すようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記コンピュータシステムは更に、複数の潜在的結果を有する第１の不確定事象を記述した第１の不確定事象リクエスト及び前記不確定事象について前記ユーザが仮想通貨で賭けた第１の賭金を受け取り、前記複数の確率に基づいて、前記複数の潜在的結果から前記第１の不確定事象の結果を選択し、前記賭金に基づいて、前記選択された結果に対応付けられる第１の結果額を計算し、前記第１の結果額は前記仮想通貨によるものであり、前記結果額が非ゼロであること条件として、現実の通貨を賭金とする前記不確定事象を提供することを前記ユーザ装置に促す、ようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、ユーザを記述した情報は、前記アカウントに対応付けられたログイン情報により構成されていてもよく、前記ユーザを記述した情報に基づいた、前記ユーザが賭けを行う資格を有するか否かの判定は、前記アカウントに対応付けられた付加的な情報へのアクセスにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記コンピュータシステムは更に、前記アカウントに対応付けられた前記ユーザの残高を前記ユーザ装置に供給するようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記コンピュータシステムは更に、前記ユーザを記述する前記情報から前記ユーザの地理的位置を推定するようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記コンピュータシステムは更に、前記ユーザが賭けを行う資格を有すると判定すると前記アプリケーションにアクセストークンを供給するようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記不確定事象リクエストは前記アクセストークンにより構成されていてもよい。

様々な実施例が、ゲームアプリケーションを促進するための、コンピュータにより実現されるゲーム管理システムに向けられる。コンピュータシステムは、少なくとも１名のユーザのゲームプレイを記述する複数のゲームプレイ挙動の指標（メトリック）の値を記録し得るもので、前記複数のゲームプレイ挙動の指標のうち少なくとも１個は、ゲームアプリケーションを介して少なくとも１名のユーザによって賭けられた賭金を記述していてもよく、前記複数のゲームプレイ挙動の指標に基づいて、少なくとも１名のユーザの少なくとも１個のゲームプレイの選好を決定し、決定された前記少なくとも１名のユーザの少なくとも１個のゲームプレイの選好に基づいて、第１のユーザのゲームプレイを変更する、ようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記ユーザのゲームプレイの変更は、少なくとも１個の推奨ゲームアプリケーションを、決定された前記少なくとも１名のユーザの少なくとも１個のゲームプレイの選好に基づいて選択すること、及び前記少なくとも１個の推奨ゲームアプリケーションの告知を、前記ユーザに供給することにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記ユーザのゲームプレイの変更は、前記少なくとも１個のゲームアプリケーションの少なくとも１個の賭けのパラメータの変更により構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記少なくとも１名のユーザは前記第１のユーザにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記コンピュータシステムは更に、前記第１のユーザを記述するデータを受け取り、前記第１のユーザを記述するデータに基づいて、前記少なくとも１名のユーザを選択するようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記コンピュータシステムは更に、前記ゲームプレイの変更後の前記第１のユーザによる少なくとも１個のゲームアプリケーションの使用を記述するデータを記録し、前記ゲームプレイの変更後の前記第１のユーザによる少なくとも１個のゲームアプリケーションの使用を記述する記録された前記データを参照して、前記少なくとも１個のゲームプレイの選好の新しい値を決定する、ようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記少なくとも１個のゲームプレイの選好の決定は、少なくとも１名のユーザのリスク許容度の計算、及び前記複数のゲームプレイ挙動の指標の知覚された効用の計算により構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記複数のゲームプレイ挙動の指標の値の記録は、前記少なくとも１名のユーザにより選択された少なくとも１個のゲームアプリケーションにより許容された最大の賭金の値を記録することにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記複数のゲームプレイ挙動の指標の値の記録は、前記少なくとも１名のユーザにより選択された少なくとも１個のゲームアプリケーションにおける、賭け行為と前記賭けの結果発生との間の経過時間の値を記録することにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記複数のゲームプレイ挙動の指標の値の記録は、前記少なくとも１名のユーザにより選択された少なくとも１個のゲームアプリケーションにおいて賞金を獲得する確率の値及び当該賞金の払い出し額を記録することにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記複数のゲームプレイ挙動の指標の値の記録は、前記少なくとも１名のユーザにより選択された少なくとも１個のゲームアプリケーションにおいて少なくとも１個の賭けの結果に対して前記少なくとも１名のユーザが有する支配の程度についての値を記録することにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記複数のゲームプレイ挙動の指標の値の記録は、少なくとも１名のユーザの損失許容度の値を記録することにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記ゲームプレイは複数の決定ノードにより記述され、前記複数のゲームプレイ挙動の指標の値の記録は、前記少なくとも１名のユーザにより選択された少なくとも１個のゲームアプリケーションにおける決定ノードの頻度についての値を記録することにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記ゲームプレイは複数の決定ノードにより記述され、前記複数のゲームプレイ挙動の指標の値の記録は、前記少なくとも１名のユーザにより選択された少なくとも１個のゲームアプリケーションにおいて、前記少なくとも１名のユーザが遭遇し前記少なくとも１名のユーザが賭けを行うことを可能とする決定ノードの量を記録することにより構成されていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記コンピュータシステムは更に、前記複数のゲームプレイ挙動の指標の値が、前記第１のユーザを記述する値のしきい値により構成されているか否かを判定するようにプログラムされていてもよい。

ここに説明するいずれの実施例においても、任意的に、前記コンピュータシステムは更に、前記複数のゲームプレイ挙動の指標の値が、前記第１のユーザを記述する値のしきい値により構成されていることを条件として、前記第１のユーザの少なくとも１個のゲームプレイの選好を決定し、第１のユーザの少なくとも１個のゲームプレイの選好に基づいて、前記第１のユーザのゲームプレイを変更するようにプログラムされていてもよい。

ゲーム管理システムを実現するための環境の実施例のひとつを示す図である。 ゲームアプリケーション、及び、不確定ゲーム事象を決定するための基本的なプロセスフローを行うゲームアプリケーションのユーザと通信するゲーム管理システムの実施例のひとつを示す図である。 アプリケーションとゲーム管理システムとの間のインタラクションの例を示すプロセスフローの実施例のひとつを示すフローチャートである。 ゲーム管理システムにユーザーアカウントを設定するためにユーザに示すことができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 画面で開始されたアカウント設定処理の開始を確認するためにユーザに示すことができるインタフェース画面の実施例のひとつを示すスクリーンショットである。 ログインの情報を受け取るためにユーザに示すことができるインタフェース画面の実施例のひとつを示すスクリーンショットである。 ユーザからの資金の入金を受け取るためにユーザに表示することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 資金の入金を確認するためにユーザに表示することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 ユーザが自分のアカウント識別情報を管理できるようにするためにユーザに示すことができるインタフェース画面の実施例のひとつを示すスクリーンショットである。 アプリケーションを設定してシステムに統合するために、ゲーム管理システムによって実現され得るプロセスフローの実施例のひとつを示すフローチャートである。 設定及び承認のためアプリケーションまたはゲームの名前を受け取るために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 ゲームまたは不確定事象タイプを受け取るために開発者に提供することができる、図１１のインターフェース画面の実施例のひとつを示すスクリーンショットである。 選択された不確定事象タイプを記述するために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 「スロットマシン」タイプの不確定事象のフレームワークによる不確定事象設定の特性を受け取るために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 図１５は、追加的な不確定事象設定の特性を受け取るために開発者に提供することができる、図１４のインターフェース画面の実施例のひとつを示すスクリーンショットである。 図１５Ａは、結果タイプフィールドを含む、図１５のインターフェース画面の実施例のひとつを示すスクリーンショットである。 追加的な不確定事象設定の特性を受け取るために開発者に提供することができる、図１４のインターフェース画面の実施例のひとつを示すスクリーンショットである。 アプリケーションをコーディングするためのＡＰＩ証明書、ドキュメント、および他の情報を開発者に提供するために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 テスト環境のＡＰＩ証明書を開発者に提供し、賭博場の取り分を開発者から受け取り及び／又はテストユーザーに提供するために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 製品環境のＡＰＩ証明書及び許容不確定事象特性を開発者に提供し、不確定事象特性の変更を開発者から受け取るために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 開発者のアプリケーションを図１のゲーム管理システムに統合する適切な工程がとられたことを確認するために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 アプリケーションを実行するために必要な運転資金（例えば、「賭博場の取り分」）の概要を示すために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 運転資金を受け取るために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 付加的な開発者の支払情報フィールドを含む図２２のインターフェース画面の実施例のひとつを示すスクリーンショットである。 開発者のために支払確認情報を示すインタフェース画面の実施例のひとつを示すスクリーンショットである。 アプリケーションを記述する情報を開発者から受け取るために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 アプリケーションを記述する情報を確認しアプリケーションの承認及び公開を申請するために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 アプリケーションの承認及び公開を告知するために、開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 「キノ」事象タイプ選択された図１３のインターフェース画面の実施例のひとつを示すスクリーンショットである。 「キノ」タイプの不確定事象のフレームワークによる不確定事象設定の特性を受け取るために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 「ルーレット」事象タイプが選択された図１３のインターフェース画面の実施例のひとつを示すスクリーンショットである。 「ルーレット」タイプの不確定事象のフレームワークによる不確定事象設定の特性を受け取るために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 「ペイテーブル」事象タイプ選択された図１３のインターフェース画面の実施例のひとつを示すスクリーンショットである。 「ペイテーブル」タイプの不確定事象のフレームワークによる不確定事象設定の特性を受け取るために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 アプリケーションの名称、このアプリケーションに対応付けられた様々な不確定事象を受け取るために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 アプリケーションのタイトルが入力された図３４のインターフェース画面の実施例のひとつを示すスクリーンショットである。 ３個の不確定事象が入力された図３４のインターフェース画面の実施例のひとつを示すスクリーンショットである。 不確定事象設定の特性を潜在的結果の形で受け取るために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 不確定事象設定の特性を潜在的結果に対応付けられた確率の形で受け取るためのフィールドを含む図３７のインターフェース画面の実施例のひとつを示すスクリーンショットである。 不確定事象設定の特性を賭博場の取り分の形で開発者から受け取るために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 アプリケーションのための賭博場のアカウントを記述した不確定事象設定の特性を開発者から受け取るために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 受け取った不確定事象設定を確認するために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 支払詳細情報を受け取るために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 アプリケーションが受理されたことを開発者に告知するために開発者に提供することができるインターフェース画面の実施例のひとつを示すスクリーンショットである。 図１のゲーム管理システム（例えば、そのＡＰＩ）及びアプリケーションをＡＰＩに認証するアプリケーションによって実現され得るプロセスフローの実施例のひとつを示すフローチャートである。 推奨エンジンからなるゲーム管理システムを実現するための環境の実施例のひとつを示す図である。 ユーザの推奨ゲームアプリケーションを生成し実行するためにゲーム管理システムの推奨エンジンによって実現され得るプロセスフローの実施例のひとつを示すフローチャートである。

本明細書に記載された特徴及び利点は、すべてを包括的に含むものではなく、特に、当業者にとっては、図面、明細書、請求項の観点からみて、多くの追加的特徴、利点が明らかである。本明細書で使用される用語は、主に、読みやすさや指示説明といった目的で選択されており、開示された主題を記述し又は範囲を画定する意図で選択されたものではない。

図面及び以下の説明は、具体例としてのみ、本発明の実施例に関連する。ここで開示される構造及び手法に代わる他の実施例を、特許請求の範囲の原理から逸脱することなく採用し得る。

ゲーム及び他のアプリケーションの収益化を促進するために、開発者は、ユーザが賭金またはベットをアプリケーション内で使用できるようにする機能を採り入れてもよい。賭金やベットを公に提供する企業体はしばしば、ライセンス上あるいは規則上の重要な制約に服すべきこととなる。関係する諸規則に従うことと適切なライセンスを取得して維持することとに伴う支出と責務は、アプリケーション開発者にとって、重大な参入障壁となっている。たとえば、ギャンブル用のアプリケーションを提供する開発者又は他の企業体は、ギャンブルのライセンスが必要となる法域を特定する必要があり、各法域毎に、必要なライセンスを取得するために、厄介な支出を伴いしばしば時間も要する手続に関わらなくてはならない。適切なライセンスが取得された後でさえ、ライセンスを受けた企業体は、ゲームプレイ、会計、また銀行サービスについてさえも、関連する厳格な規定を遵守しなくてはならない。

賭金やベットを第三者のアプリケーションに組み込むことを促進するシステム及び手法が、多くの実施例により示される。たとえば、ここで記載されたシステム及び手法は、個人である開発者がギャンブルのライセンスを取得する必要性を無くすことができる。ゲーム管理システムは、促進的なビジネス企業体ないしは１個以上のギャンブルのライセンスを有する促進的な企業体によって実行されてもよい。ギャンブル管理システムは、第三者であるアプリケーション開発者に対し、賭金またはベットをそのギャンブルのアプリケーションに組み込む機能を与える。たとえば、開発者は、後に詳述するように、アプリケーションユーザが１個以上の不確定事象の結果に賭けられるようにしてもよい。不確定事象のパラメータとして許容されるもの、及び、行うことができるベットは、ゲーム管理システムにより制御される。このように、このゲーム管理システムは、行われたベットが、関係諸規則及び／又は事前に承認された不確定事象の形式を遵守することを確保できる。結果的に得られたアプリケーションが実行されると、ユーザは、このゲーム管理システムを介してベットしてもよい。たとえば、このゲーム管理システムは、それぞれの条件付きゲーム対象事象の結果を決定し、勝ち分及び負け分を決定し、ユーザにこの勝ち分及び負け分を配分する。こうしてこのアプリケーションは、促進する企業体が保持するギャンブルのライセンスを活用してもよい。従って、開発者がこのアプリケーションを開発し、配布し、ユーザを得ることができる一方、促進する企業体は、適切な規則とライセンス（たとえば、この促進する企業体が保持しているもの）にしたがって、ゲームのギャンブル的側面を運営してもよい。

ここで用いる「ギャンブルのライセンス」、「ライセンス」または「ゲームのライセンス」という用語は、ベット、賭金、または他のゲームを公衆に提供する企業体が保持するライセンスを指す。ある法域では、特定の種類のベット、賭金、または他のゲームを公衆に提供するにはギャンブルのライセンスが必要となり得る。

不確定ゲーム事象とも呼ぶ不確定事象は、ゲーム内や、未知の結果を有する他の種類のアプリケーション内の状況であってもよく、ベットや賭けの対象であってもよい。不確定事象は、少なくとも２通りの結果の可能性を有し得る。それぞれの潜在的結果は、その潜在的結果が発生する確率に対応付けられ得る。

互いに異なった潜在的結果の確率は、固定（たとえば、事前に設定）されていてもよいし、及び／又は、パラメータ化（たとえば、不確定事象をめぐるゲームプレイの状況に基づいて決定）されてもよい。ゲーム管理システムは、潜在的結果の確率に基づいて不確定事象を決定してもよい。たとえば、ゲーム管理システムは、対応付けられた確率に基づいて（たとえば、乱数発生器または他の適切な種類の手法又は装置を利用して）、潜在的結果のひとつをランダムに選択してもよい。選択された結果を、不確定事象の結果と呼んでもよい。

不確定事象は、ゲームあるいは結果が最初に未知である他の種類のアプリケーションの文脈で起こり得る任意の種類の事象であってもよい。しかしながら、異なる種類のアプリケーションは、異なる形態で不確定事象を発生させ得ることは理解されよう。たとえば、ゲームを実装したアプリケーションに関連した不確定事象を含むいくつかの利用ケースは、伝統的にスロットマシンゲーム、カードゲーム、サイコロゲームなどのギャンブルに関連している。これらのようなゲームにおいて、不確定事象は、このゲームの物理的なバージョンが行われる場合における未知の事象と同様であってもよい。たとえば、スロットマシンゲームにおいては、スロットマシンレバーを仮想的に引く行為が不確定事象である。スロットマシンのリールの潜在的な各配置は潜在的結果に対応するものであり、各結果の確率がリールの配置に対応する。サイコロゲームでは、サイコロの各面が不確定事象であり、サイコロの潜在的な各配置が潜在的結果に対応する。ポーカー、ブラックジャックなどのカードゲームでは、配札が不確定事象である。潜在的結果は、配札後にプレイヤーがもち得る潜在的な手札及び／又は手役に対応付けられていてもよい。いくつかの実施例では、不確定事象は複合的であってもよい。たとえば、ポーカーの手役の結果は、複数回のベットと複数回の配札に依存するものとしてもよい。伝統的なギャンブルの賭けを実行するゲームの例としては、 いずれもＺＹＮＧＡで利用できるＳＬＯＴＳやＰＯＫＥＲが含まれる。

不確定事象の他の利用ケースは、一般的にはギャンブルに関連付けられていないゲームに関連する。たとえば、現在のソーシャルネットワークゲームの人気ジャンルのひとつは、作物や動物の植栽や育成を含んでいる。このジャンルのゲームの例としては、いずれもＺＹＮＧＡで利用できるＦＡＲＭＶＩＬＬＥ及びＣＩＴＹＶＩＬＬＥや、ＳＬＡＳＨＬＥＹで利用できるＦＡＲＭＴＯＥＷＮなどがある。これらのゲームでユーザは、仮想的に作物を「植栽する」。作物が準備できたら、ユーザは、仮想通貨や経験値などのゲーム内報酬のためにこの作物を仮想的に「収穫」する。ここに説明した、ゲーム管理システムで実行されるゲームの例においては、作物の植栽が不確定事象である。ユーザの賭金は、作物の植栽に必要な種子又は他の資源のための支払いという形態をとることができる。ユーザの勝ち分は（もしあれば）収穫の成功に基づいて決定してもよい。不確定事象の潜在的結果は収穫の成功、収穫の不成功及び／又は成功と不成功との間の様々なグラデーションを含む。作物の植栽に対応する不確定事象は、いくつかの実施例では、パラメータ化されてもよい。たとえば、収穫に成功するという結果の確率が所定の要因に基づいていてもよいが、ユーザの挙動（たとえば、ユーザが作物に灌水したか否か、適時に収穫したか否か、動物に給餌ないし給水したか否か）に基づいていてもよい。

不確定事象の別の利用ケースは、スキルゲームに関連する。不確定事象は、特定のプレイあるいは一連のプレイ（たとえば、レベルを形成する一連のプレイ）であってもよい。不確定な各事象の潜在的結果は、プレーの可能な結果に反映されてもよい。各潜在的結果の確率は、プレイの難易度ないしレベルに基づいて決定されてもよい。いくつかの実施例では、所定の結果の確率はパラメータ化されてもよい（たとえば、ユーザのスキルレベルや過去のゲームの履歴に基づいて）。説明したような不確定事象を利用できるスキルゲームの例としては、ＲＯＶＩＯ ＥＮＴＥＲＴＡＩＮＭＥＮＴ社で入手できるＡＮＧＬＹ ＢＩＲＤの様々な繰り返しが含まれている。たとえば、不確定事象は１個あるいは一連の鳥の発射であってもよい。不確定事象の潜在的結果は、破った敵の数に関連付けられていてもよい。

利用ケースの別の例は、現在人気のあるジャンルのゲームに関係するもので、このゲームは、異なるユーザ間の対戦を含んでおり、各ユーザが対戦の当事者である個人及び／又は軍隊に対応する。このジャンルのゲームの例としては、ＺＹＮＧＡのＭＡＦＩＡ ＷＡＲＳ及びＭＡＦＩＡＷＡＲＳ ２が含まれる。このジャンルのゲームでは、プレイヤー間の対戦ないし対立が不確定事象のタイプの一例である。たとえばユーザは、彼らが対戦に勝つこと、彼らが少なくとも一定量のエネルギー残量の下で一定のターン数で対戦に勝つこと、などをベットできる。各潜在的結果は、対戦の潜在的結果に対応付けられていてもよい。いくつかの例では、各潜在的結果の確率は、関係するユーザの特性に依存していてもよい。このような特性は、不確定事象のパラメータであってもよく、たとえば、各ユーザ、各ユーザが所持するアイテム（たとえば、武器）に対応付けられたスキル及び／又は経験値を含んでいてもよい。

対戦型ゲームに限られず、いくつかの実施例においては、不確定事象は、たとえばレベルパック、仮想グッズ等の他の製品をアプリケーション内で併売するために活用されてもよい。たとえば、アプリケーションは、売り込み対象の商品を購入することによりユーザが不確定事象の賭けに勝つ確率が増大すると広告することにより、追加的なレベルパック、仮想グッズ等の購入をユーザに促すよう構成されていてもよい。このようなプロンプトは、ゲームのプレイ中にいつ提供されてもよい。いくつかの実施例では、このプロンプトはユーザは賭金を失った後に提供されてもよい。たとえば、アプリケーションは、特定の仮想グッズを所持することでユーザが勝利する可能性が増加することをユーザに通知するように構成されていてもよい。

不確定事象は、任意の種類のゲームや、ユーザがベットないし賭けを行うことができる未知の結果を伴う事象を含む他のアプリケーションに適用され得ることが理解されよう。ここで示した不確定事象の例は単なる例示である。また、不確定事象を使用した種類のゲームやその他のアプリケーションは、ユーザに直接提供されてもよいし、及び／又は中間的なアプリケーションないしゲームを介して提供されてもよいということもまた理解されよう。たとえば、中間ゲーム内のユーザのキャラクタが不確定事象のゲームをプレイしてもよい。アプリケーションは、たとえばＬＩＮＤＯＮ ＬＡＢＳのＳＥＣＯＮＤ ＬＩＦＥ及び／又は同様なゲームのアバターのための様々なギャンブルゲームからなるカジノを実行してもよい。

図１は、ゲーム管理システム１０２を実装するための環境１００の実施例を示す図である。ゲーム管理システム１０２は、任意の適切なコンピュータまたはコンピュータシステムを利用して実装されてもよく、１個以上のプロセッサと、動作可能に関連付けられているメモリとを含んでいてもよい。いくつかの実施例では、ゲーム管理システム１０２は、単一及び／又は複数の物理的位置に配置され得る１個または複数のサーバによって実現され得る。

図１はまた、アプリケーションのプレイヤーないしユーザ１０４及び開発者１０６の組を示している。ユーザ１０４は、開発者１０６によって開発されたアプリケーションにアクセスしてもよい。ユーザ１０４は、コンピュータ装置、または、携帯スマートフォンなどのハンドヘルドデバイス、タブレットコンピュータ、ラップトップコンピュータ、デスクトップコンピュータなど、任意の適切な種類の装置を利用してもよい。いくつかの実施例では、アプリケーションの実行は、ローカルであってもよいユーザのコンピュータ装置でローカルに行ってもよいし、開発者のサーバーまたはサーバー群でリモートに行ってもよいし、及び／又はその混合でもよい。支払いゲートェイ１０７は、賭金ないしベットに対応付けられた金融取引を容易にしてもよい。たとえば、支払いゲートェイ１０７は、ユーザ１０４と賭博場とに対応付けられた金融機関の口座間での勝ち分及び／又は負け分を送金するために、ゲーム管理システム１０２により利用してもよい。環境１００の様々な構成要素は、ネットワーク１１６を介して互いに連絡している。ネットワーク１１６は、有線及び／又は無線の構成要素を含んでいてもよく、及び／又は１個以上のワイドエリアネットワーク（ＷＡＮ）及び／又はローカルエリアネットワーク（ＬＡＮ）を含んでいてもよい。いくつかの実施例では、ネットワーク１１６はインターネットを含み及び／又は利用してもよい。

ゲーム管理システム１０２は、たとえばゲーム管理システム１０２によって実行されるソフトウェアコードとして実現される様々な機能コンポーネント１０８、１１０、１１２、１１４からなっていてもよい。アプリケーション・プログラム・インターフェース（ＡＰＩ）１０８は、ゲームアプリケーション１０４がゲーム管理システム１０２と通信することを可能にするインターフェースを提供する。たとえば、 ＡＰＩ１０８は、アプリケーションに不確定事象の徴表及び関連するパラメータ（存在すれば）を引き渡させるコマンド（本明細書に記載）をサポートしてもよい。ゲーム管理システム１０２によって決定された不確定事象の結果はまた、ゲーム管理システム１０２からアプリケーションへと引き渡されてもよい。乱数発生器（ＲＮＧ）１１０は、不確定事象を解決する（たとえば、複数の潜在的結果から、潜在的結果の確率に基づいて、１個の潜在的結果を選択する）ようにプログラムされていてもよい。会計層１１２は、不確定な各事象の会計上の結果を記録するためにプログラムされている。たとえば、会計層１１２は、それぞれの不確定事象の結果に基づいて、ユーザや賭博場の勝ち分または負け分を決定してもよい。各当事者の勝ち分や負け分は、ユーザによる賭金の額、アプリケーション内でユーザの持ち物といった不確定事象のパラメータに加え、不確定事象の性質に基づいていてもよい。バンキング層１１４は、不確定事象の結果を実現するための取引を実行してもよい。不確定事象に特有の取引は、たとえば、バンキング層１１４及び／又は会計層１１２によって決定される。

図２は、アプリケーション２０２との通信を行うゲーム管理システム１０２の実施例のひとつ、及び、不確定事象を決定する基本的な作業の流れを示すアプリケーション２０２のユーザ２０４を示す図である。ユーザ２０４は、ゲーム管理システム１０２の既存のアカウントを有していてもよいし、及び／又はそのようなアカウントを開設してもよい。たとえば、アカウントの開設を容易にするため、ゲーム管理システム１０２がユーザ２０４に、それを介してユーザが年齢、地理的な場所、電子メール、勝ち分の受け取りや負け分の補填を行うための銀行口座及び／またはクレジットカード情報などを記述するユーザ情報を提供できるようなインターフェイスを提供してもよい。このユーザ情報に基づいて、ゲーム管理システム１０２は、ユーザ２０４がゲーム管理システム１０２で（たとえば、アプリケーション２０２を介して）ベットを行う資格があるか否かを判定してもよい。ユーザ資格は、ユーザの法域に関連付けられた規則や、ゲーム管理システム１０２のポリシーなどに依存し得る。ユーザ２０４に資格がある場合、アカウントを開くことができる。アカウントが開かれると、ユーザ２０４は、２１０で、アカウントに入金してもよい。（ユーザ２０４がゲーム管理システム１０２の既存のアカウントを有する場合、各アプリケーション２０２はユーザ２０４が使用する新しいアカウントを開設する必要はない。）入金２１０は、ユーザの口座に資金を転送するための、ユーザ２０４からゲーム管理システム１０２への要求を含んでいてもよい。ゲーム管理システム１０２（たとえば、会計層１１２及び／又はバンキング層１１４ ）は、要求された資金を、ユーザ２０４のクレジットカードまたは銀行口座から、ゲーム管理システム１０２が管理するアカウントへと転送してもよい。会計層１１２は、この入金をユーザのアカウントに記録してもよい。

ゲームのプレイ中に、アプリケーション２０２は、不確定事象に遭遇しうる。本明細書に記すように、アプリケーション２０２はユーザ２０４に、不確定事象について賭けを行う機会を提供してもよい。 ２０６で、ユーザ２０４は、賭け金を置いたり、他のギャンブル行動をとってもよい。アプリケーション２０２は、２０８で（たとえば、ＡＰＩ１０８を介して）、不確定事象に加え、ユーザ２０４の賭金及び不確定事象を決定するための他のパラメータを引き渡すことができる。ゲーム管理システム１０２は、（たとえば、ＲＮＧ１１０を利用し）、ここに説明した不確定事象を決定してもよい。不確定事象の結果に基づいて、ゲーム管理システム１０２は、この不確定事象についてなされた１個以上のベットの結果を決定してもよい。ユーザ２０４と賭博場の勝ち分や負け分が、（たとえば、会計層１１２を利用して）割り付けられる。 ２１６で、ゲーム管理システム１０２は、たとえばバンキング層１１４を利用して、１個以上のベットの結果を実現するために送金を開始してもよい。たとえば、ユーザ２０４及び／又は賭博場のアカウントへ及び／又はから、勝ち分及び／又は負け分が転送されてもよい。不確定事象の結果及び１個以上のベットの結果は、２１２でアプリケーション２０２に通信されてもよい。アプリケーション２０２は次に、２１４で、ユーザ２０４へと事象の結果及びベットの結果を通信してもよい。

図３は、２０２などのアプリケーションとゲーム管理システム１０２との間の例示的なインタラクションを示すプロセスフロー３００の実施例のひとつを示すフローチャートである。プロセスフロー３００は、２つの列３０１及び３０３を含む。列３０１はアプリケーションがとり得る動作を含み、一方で列３０３は、様々な層やモジュールを含むゲーム管理システム１０２がとり得る動作を含む。３０２で、アプリケーションが実行できる。このアプリケーションは、ユーザのコンピュータ装置で実行できる。いくつかの実施例では、アプリケーションを全体的または部分的に、ゲームの開発者１０６に対応付けられたリモートサーバで実行してもよい。

３０４でアプリケーション２０２は、現実の金銭を賭けるよう、必要に応じてユーザに促す（たとえば、マネーゲームを促す）ことができる。たとえば、一部のアプリケーションは、ユーザが仮想の通貨や商品のみを獲得できる仮想専用モードを有していてもよい。仮想専用モードでは、不確定事象の決定及び勝ち分及び／又は負け分の分配は、（ゲーム管理システム１０２なしに）アプリケーションによって、及び／又は、ゲーム管理システム１０２によって処理されてもよい。たとえば、ゲーム管理システム１０２はまた、不確定事象についての仮想の賭金を処理するように構成されてもよい。仮想の賭金が設けられるとき、不確定事象の決定は、上述のようにＲＮＧ１１０及び会計層１１２によって処理されてもよい。仮想通貨又はその他の商品は、いくつかの実施例では、ユーザの現実の金銭の口座とは分離された仮想口座に記録されてもよい。また、仮想の賭金については、現実の金銭の移転がないため、資金の送金に必ずしも銀行モジュール１１４を利用する必要ない。３０４でのプロンプトは、様々な異なるゲーム内の事象によってトリガされてもよい。たとえば、ユーザは、アプリケーションの実行時に自動的に現実の金銭を賭けするよう促されてもよい。また、いくつかの実施例では、アプリケーションが、ユーザが仮想の賭金を得た後や、しきい値（たとえば、非ゼロの値）分の仮想通貨または商品を獲得した後に、現実の金銭を賭けるよう促すよう構成されていてもよい。また、いくつかの実施例では、仮想の商品、通貨などのための賭金は、アプリケーションそれ自体によって及び／又は、アプリケーションの開発者に関連付けられ及び／又は稼働されるサーバによって処理されてもよい。たとえば、仮想グッズの賭け金を促す場合、ギャンブルのライセンスは必要ではない。

３０６で、アプリケーションは（たとえば、ユーザがリアルマネーを賭けすることを選択したとして）ゲーム管理システム１０２へとアプリケーションの認証３０７を転送してもよい。アプリケーション認証は、たとえば、ＡＰＩ証明書、あるいはゲーム管理システム１０２に対しアプリケーションを特定して認証する他の手法であってもよい。以下に記すように、アプリケーションは、事前に構成されゲーム管理システム１０２と一体化されていてもよいことが理解されよう。たとえば図１０に関して後述するように、認証３０７は、たとえば、アプリケーションに関連する少なくとも一つの不確定事象が承認されたことを示してもよい。アプリケーション認証３０７を受け取ると、ゲーム管理システム１０２はこのアプリケーション認証を検証してもよく、こうすることにより、アプリケーションが、ゲーム管理システム１０２で動作するように構成されていることを確認してもよい。種々の実施例では、アプリケーションとゲーム管理システム１０２との間の通信を確保してもよい。通信は、たとえば公開鍵インフラストラクチャ（ＰＫＩ）を含む任意の適切な暗号化方式に従って暗号化されてもよい。いくつかの実施例では、ユーザの装置またはアプリケーションを実行する他のコンピュータ装置は、セキュア・ソケット・レイヤー（ＳＳＬ） 、トランスポート層セキュリティ（ＴＬＳ）及び／又はハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）などの安全な接続を介してゲーム管理システム１０２と通信するようにしてもよい。

３１４でゲーム管理システム１０２は、アプリケーションのユーザを認証してもよい。ユーザの認証は、ユーザがアプリケーションを介して賭けを行う資格があること、ゲーム管理システム１０２に登録されていること、及び、ユーザがアカウントを有していて賭金のための金銭を入金していること、を確認するための様々な動作を含んでいてもよい。たとえば、いくつかの実施例では、ゲーム管理システム１０２は、アプリケーション自体を介してユーザに認証インターフェースを提供してもよい。そのようなインタフェースの一例は、図４−９に関連して以下に説明する。たとえば、ユーザは、賭けに適格であるか否かの決定は、ユーザがギャンブルを行える最低年齢以上であること、ユーザがギャンブルの許された法域にいること、などを検証することを含んでいてもよい。いくつかの実施例で、ゲーム管理システムは、たとえばユーザのインターネットプロトコル（ＩＰ）アドレスに基づいて、ユーザの位置を決定してもよい。

認証時に、ゲーム管理システム１０２は、必要に応じて３１６で、ユーザのゲーミングの残高３０９をアプリケーションへと提供してもよい。ゲーミングの残高３０９は、ゲーム管理システム１０２の管理の下に寄託されていてユーザが賭けに利用可能な金額を表すものであってもよい。ゲーミングの残高３０９は、アプリケーション専用の残高であってもよいし、いくつかの実施例では、ユーザの利用可能な総残高や、当該アプリケーションを含むあるクラスのアプリケーション専用の総残高であってもよい。このアプリケーションは、ゲーミングの残高３０９を３０８で表示してもよい。これは、いくつかの法域では、ゲーミングの残高が賭けの前にユーザに表示される必要があることがあり得ることが理解されよう。ユーザがこのような法域内に存在する場合、ゲーム管理システム１０２は、バランスが表示されるまで、または表示されない限り、不確定事象への賭けを許可できない。

アプリケーションは、ゲームやユーザに向けられた他の機能を実装してもよい。不確定事象に遭遇すると、アプリケーションは３１０で、ゲーム管理システム１０２への不確定事象のリクエスト３１１を指示してもよい。不確定事象のリクエスト３１１は、不確定事象の種類や、ユーザがこの事象に対して賭けた賭金についての情報を含んでいてもよい。事象がパラメータ化されている場合、不確定事象のリクエストは、この不確定事象のパラメータを含んでいてもよい。ゲーム管理システム１０２は、 ３１８で不確定事象のリクエスト３１１を評価してもよい。不確定事象のリクエスト３１１の評価は、たとえば、ＲＧ１１０を利用して不確定事象を決定し、会計層１１２を利用して、結果からの勝ち分及び／又は負け分を決定することからなっていてもよい。不確定事象の結果により生じる資金移転を、（バンキング層１１４を利用して）３２０で開始してもよい。３２２でゲーム管理システム１０２は、不確定事象の結果３１３をアプリケーションへと送信してもよい。結果は、たとえば、不確定事象の結果、勝ち分及び／又は負け分を分散するために実行された送金を含んでいてもよい。いくつかの実施例では、結果はまた、新たな残高、ないしはゲーム管理システムにおけるユーザのアカウントの残高を含んでもよい。アプリケーション３１２は、 ３１２でユーザに結果を表示してもよい。たとえば不確定事象の結果などを含む結果は、後続するゲームプレイにおいてファクターとして反映されてもよい。

図４−９は、ゲーム管理システムユーザ１０２によって、ユーザがユーザカウントをこのゲーム管理システムに作成して維持するために提供されるインタフェースの様々な実施例を示すスクリーンショットである。図４−９に示すインタフェースは、たとえばゲーム管理システム１０２のウェブサイトを介して、ユーザに直接提供されてもよい。いくつかの実施例では、図４−９に示すインタフェースは、 たとえば３１４においてユーザ認証に関連して上述したように、アプリケーションを介してユーザに提供されてもよい。

図４は、ゲーム管理システム１０２にユーザカウントを設定するためにユーザに示されるインターフェイス画面１０００の実施例のひとつを示すスクリーンショットである。画面１０００は、ロゴ部１００２を備える。ロゴ部１００２は、たとえば画面１０００がユーザに直接提供される場合、ゲーム管理システム１０２を実現する促進企業体のロゴを含んでもよい。画面１０００が特定のアプリケーションに関連付けられ、たとえばこの特定のアプリケーションを介して画面１０００がユーザに提供される場合は、アプリケーション及び／又はアプリケーション開発者のロゴが１００２で表示されてもよい。既存のアカウントを持つユーザは、ログインボタン１００６を選択することにより、画面１０００から、図６に示す画面１０１４におけるようなログイン画面へと移動してもよい。既存のアカウントを持たないユーザは、フィールド１００４でユーザ情報を提供することにより、アカウントの設定プロセスを開始してもよい。フィールド１００４は、ユーザの年齢が合法的に賭けをできるだけ十分に高く、またユーザが諸条件を遵守することを示すユーザによってチェックされるためのボックスを含んでいてもよい。フィールド１００４で要求された情報が完了すると、ユーザは、サインアップボタン１００８を選択することにより、アカウントの設定処理を開始してもよい。

図５は、画面１０００で開始されたアカウントの設定処理の開始を確認するためにユーザに示されるインターフェース画面１０１０の実施例のひとつを示すスクリーンショットである。

画面１０１０は、確認フィールド１０１２を含む。確認フィールド１０１２は、電子メールがユーザのアカウントに送信されたこと、及びセットアッププロセスはユーザがこの電子メールを受信し、この電子メールに含まれるリンクを選択した後に続行できることを、ユーザに知らせる。ユーザに電子メールを送信し、ユーザがリンクを選択するまで電子メールでアカウントの設定処理を保留するステップは任意的なものであり、ユーザを認証するために使用してもよい。図６は、ログイン情報を受け取るためにユーザに表示し得るインターフェース画面１０１４の実施形態のひとつを示すスクリーンショットである。画面１０１４は、ユーザのログイン識別情報（たとえば、ユーザ名及び／又は電子メールアドレス）及びパスワードを受け取るためのログイン情報フィールド１０１６を有してもよい。ログイン情報フィールド１０１６で要求された情報を入力すると、ユーザは、ログインボタン１０１８を選択することによりログインを開始してもよい。画面１０００または１０１０からボタン１００６が選択されると、ユーザには画面１０１４が表示されてもよい。いくつかの実施例では、ユーザが画面１０１０に関連して上述した電子メールに含まれるリンクを選択したときにもまた、画面１０１４がユーザに表示されてもよい。この場合、フィールド１０１６によって要求されたパスワードは、電子メールで提供されてもよい。電子メールでユーザに送信されたパスワードは一時的なものであってもよく、ユーザは、たとえば図９に示すような画面１０３０を経由して、ログインの際にパスワードを変更するよう促されてもよい。

図７は、ユーザからの資金の入金を受け取るためにユーザに対し表示し得るインターフェース画面１０２０の実施形態のひとつを示すスクリーンショットである。画面は、たとえば、金額、支払方法、クレジットカード情報、課金情報など、資金の入金に関する情報を受け取るためのフィールド１０２２を含んでいてもよい。画面１０２０を介して受信された資金は、たとえばユーザのアカウント（たとえば、金融機関にあり賭博管理システム１０２が管理するもの）へと入金されてもよい。このような資金は、ここに記したように、不確定事象に関する賭けに利用可能である。なお、フィールド１０２２によって求められる情報の種類が、選択された支払手法に依存し得ることは理解されよう。たとえば、図７は、図示されているようにクレジットカードで支払いを受け取るよう構成されている。しかしながら、ゲーム管理システム１０２は、たとえば、小切手口座または他の銀行口座からの直接入金、郵便為替、電信為替など他の資金源からの支払を受け取るように旺盛されていてもよい。ユーザは、入金ボタン１０２４を選択することにより、資金の入金を開始してもよい。いくつかの実施例では、入金ボタン１０２４はまた、図示するように送金額を表示してもよい。すでに預金に資金を入金しているか、あるいは資金を提供する前にインターフェイスを閲覧したいユーザは、画面１０２０をスキップするため、後で入金する旨のボタン１０２１を選択してもよい。図８は、資金の入金を確認するためにユーザに対し表示し得るインターフェース画面１０２６の実施形態のひとつを示すスクリーンショットである。画面１０２６は、完了した入金の詳細をユーザに提示する入金確認フィールド１０２８を含む。フィールド１０２６はまた、入金額と、入金を完了するのに利用された支払手法を表示してもよい。このフィールドは、送金を確認する会計上の目的のため、任意的に、取引の識別情報を表示してもよい。

図９は、ユーザが自分のアカウント識別情報を管理できるようにするためにユーザに示し得るインターフェース画面１０３０の実施形態のひとつを示すスクリーンショットである。ユーザ名とアドレスのフィールド１０３２は、ユーザがユーザのアカウントに対応付けられている名前と電子メールアカウントの表示及び変更ができるようにするフィールドを含んでいる。更新情報ボタン１０３４を選択すると、フィールド１０３２に加えられた変更が確定されるようにしてもよい。パスワードフィールド１０３６は、ユーザが古いパスワードと新しいパスワードを入力して自分のパスワードを変更することを可能とする。新しいパスワードを保存するボタン１０３８を選択することにより、新しいパスワードが確定されるようにしてもよい。

種々の実施例では、ゲーム管理システム１０２はまた、不確定事象への賭けを提供するアプリケーションを構成してこのアプリケーションをシステム１０２と統合するための機能を有するようプログラムされる。たとえば、システムは、不確定事象を構成するためのパラメータ化された汎用的なフレームワークを提供してもよい。不確定事象の形態及び特性と許容される賭金の形式は、ゲーム管理システム１０２によって制御されてもよい。たとえば、ゲーム管理システム１０２は、ギャンブルのライセンスまたは促進事業体が保有するライセンスに固有の規制を含む、適切な規制に準拠した不確定事象や賭けの種類のみを許容するようにしてもよい。

図１０は、システム１０２にアプリケーションを構成して統合するためのゲーム管理システム１０２によって実装され得るプロセスフロー５００の実施例のひとつを示すフローチャートである。図１０は、２つの列５０１、５０３が含まれている。列５０１は、図１の１０６から選択された例示の開発者の動作に対応している。列５０３は、ゲーム管理システム１０２の動作に相当する。様々な実施形態において、ゲーム管理システム１０２は開発者に対し、たとえば、ここで説明する図１１−４３に示した例示のインタフェースなどのインタフェースを提供してもよい。プロセスフロー５００は、図１１−４３に記載された例示的なインタフェースを用いて実現してもよいし、別のインターフェイスでもよいし、及び／又はインタフェースを用いなくてもよい。

５０２において、開発者は、ゲーム管理システム１０２に、不確定事象タイプ５０３を提供してもよい。各アプリケーションまたはゲームが単一の不確定事象が不確定事象タイプを有する実施例では、不確定事象タイプ５０３はまた、ゲームタイプと呼び得る。不確定事象タイプ５０３は、ゲーム管理システム１０２によってサポートされている所定の不確定事象タイプの選択数のひとつであってもよい。所定の不確定事象タイプは、ゲーム管理システム１０２及び／又はそのプログラマーにより、関係諸規則に準拠するように構成されていてもよい。所定の不確定事象タイプの例としては、たとえば、スロットマシン事象タイプ、汎用事象タイプ、ポーカー事象タイプ、ブラックジャック事象タイプ、キノ事象タイプ、ルーレット事象タイプ、配当表事象タイプなどが含まれていてもよい。ゲーミング管理システム１０２は、５２０で、不確定事象タイプ５０３を受け取ってもよい。

５０４で開発者は、５０４における不確定事象タイプのための設定５０５を提供してもよい。ゲーム管理システム１０２は、５２２で、この設定５０５を受け取るようにしてもよい。設定５０５は、不確定事象の決定や不確定事象について行われた賭けを決済するための、不確定事象の特性を定義するものであってもよい。不確定事象の設定は、たとえば、不確定事象の各潜在的結果、それぞれの潜在的結果の確率、不確定事象への賭けのためのパラメータなどであってもよい。いくつかの実施例では、設定５０５は、不確定事象の潜在的結果の一部または全部の確率を決定するためにゲーム管理システム１０２に引き渡されるパラメータを示してもよい。このようなパラメータは、たとえば、ゲーム内のユーザの特性（スキル値、経験値、所持する武器など）を含んでいてもよい。いくつかの実施例では、所定の不確定事象タイプは、設定の特徴を受け取るためのフレームワークによってサポートされてもよい。このフレームワークによれば、ゲーム管理システム１０２は、それぞれの不確定事象タイプに対応付けられた特定の設定の特性を開発者に促すことができる。たとえば、スロットマシンの設定タイプが選択されると、開発者は、リールの数、それぞれのリール上のシンボルの位置、それぞれのリールが特定のシンボルを返す確率、などを求められてもよい。また、たとえば、ポーカーの設定タイプが選択されると、開発者は、ゲーム等のバリエーション（たとえば、ファイブカードドロー、テキサスホールデムなど）、アンティの量などを求められてもよい。上述のように、いくつかのアプリケーションは、不確定事象のタイプを複数有していてもよい。上述した５０２、５０４、５２０、５２２など、このようなアプリケーションは、このアプリケーションによって利用されるそれぞれの不確定事象タイプについて繰り返すことができる。

アプリケーション内の各不確定事象について不確定事象の設定を受け取ると、ゲーム管理システム１０２はＡＰＩ証明書５０７を開発者に提供してもよく、これは５０６で受け取られてもよい。 ＡＰＩ証明書５０７は、アプリケーションに組み込まれてもよいし、ゲームプレイ中に、アプリケーションが不確定事象のリクエストをゲーム管理システム１０２に提供する資格があることを示すために、ゲーム管理システム１０２に提供されてもよい。再び図３を参照すると、たとえばＡＰＩ証明書５０７は、３０６において、ゲーム管理システム１０２に転送されるアプリケーション認証３０７の全部または一部であってもよい。いくつかの実施例では、受信した事象の設定を分析し、ＡＰＩ資格証明５０７が開発者に提供される前にテストしてもよい。たとえば、受信した事象の設定は、プレイヤーへの配当、分散、全体の勝率などの不確定事象パラメータを決定するために分析されてもよい。これらの計算値が、許容値と比較されてもよい。許容値は、１個または複数のギャンブルのライセンス（たとえば、ゲーム管理システム１０２を実行する者が保持しているもの）の規制基準を満たし、及び／又は適切な規制当局によってすでに承認されており及び／又は規制当局の承認をクリアしている形式の不確定事象に対応付けられていてもよい。計算値が許容値を満たしているとされた場合、ＡＰＩ証明書５０７が開発者に提供されてもよい。

５２６で、ゲーム管理システム１０２は、許容事象設定特性５０９を決定し、この許容設定特性５０９を開発者に提供し、開発者が５０８でこれを受け取ってもよい。許容設定特性５０９は、関係諸規則を遵守しつつ不確定事象が有し又は有してよい特徴の限度を表すものであってもよい。たとえば、許容設定特性５０９の決定は、関係諸規則及び／又はすでに規制当局によって承認された不確定事象の形式により示された限度に対応付けられる設定の特性を計算することからなっていてもよい。開発者は、許容特性の全範囲をみたとき、５０４で示した特性を変更することを望むことがあり得ることは理解されよう。したがって、開発者は、５１０において、不確定事象特性の変更５１１を行ってもよい。この変更は、５２８において受け付けられる。なお、プロセスフロー５００の様々な動作が任意の適切な順序で実行されてもよいことは理解されよう。たとえば、動作５２６、５０８、５１０及び５２８は、いくつかの実施例では、ＡＰＩ証明書５０７が生成され５２４及び５０６で供給される前に行ってもよい。ＡＰＩ証明書５０７を受け取ると、開発者は、アプリケーションを作成してもよい。アプリケーションは、受け取ったＡＰＩ証明書を利用したＡＰＩ１０８に従ったメッセージを生成できる任意の適切な言語でコーディングされてもよい。使用できる言語の例としては、Ｏｂｊｅｃｔｉｖｅ−Ｃ、Ｊａｖａ及びＪａｖａＳｃｒｉｐｔが含まれる。図３に関して上述したように、アプリケーションは、ゲームプレイ中、ゲーム管理システム１０２に対し、たとえば３１１で不確定事象リクエストを発するように構成されてもよい。

開発者は、任意的に５１２で、ゲーム管理システム１０２によって管理されている開発者アカウントに、賭博場の資金５１３を送金してもよい。ゲーム管理システム１０２（たとえば、会計層１１２及び／又はバンキング層１１４）は５３０で資金を受け取り、この資金を開発者の開発者アカウントに送金してもよい。たとえば、開発者アカウントは、金融機関により保持され、支払ゲートェイ１０７を介して、ゲーム管理システム１０２（たとえば、バンキング層１１４）によって制御されてもよい。賭博場の資金５１３の最小量は、たとえば、システムに含まれる１個以上の不確定事象タイプの特性に基づいて、ゲーム管理システム１０２によって決定され得る。いくつかの実施例では、開発者は、賭博場の資金を提供しなくてもよい。その代わりに、促進企業体が、賭金のため賭博場の資金を提供してもよい。賭博場の資金そのものを提供する見返りに、促進企業体は、開発者への補償額を低くしてもよい。補償は、それぞれの賭金についての賭博場の取り分のパーセンテージという形態をとることができる。賭博場の資金が促進企業体によって提供される場合、たとえば、開発者は、開発者が賭博場の資金そのものを提供する場合よりも低いパーセンテージの賭博場取り分を受け取るものとしてもよい。

任意的に５１４において、開発者は、１人以上のテストユーザ５１５の同一性証明をゲーム管理システム１０２に提供してもよい。テストユーザは、アプリケーションの承認に先立ち不確定事象について賭けを行うことをゲーム管理システム１０２によって承認された、開発者に関連付けられているユーザであってもよい。たとえば、テストユーザは、開発者に関連付けられているユーザであってもよい。いくつかの実施例では、テストユーザは開発者の資金で（たとえば、開発者アカウントの資金）で賭けるよう制限されていてもよい。 ５３２でテストユーザのＩＤを受け取ると、ゲーム管理システム１０２は、アプリケーションに関連付けられた不確定事象についての賭金をテストユーザから受け取るように自身を設定してもよい。

５１６で、開発者は、アプリケーションが承認のために提出されるべきことを要求してもよい。たとえば、開発者は、アプリケーションのコピーをゲーム管理システム１０２に提供してもよい。要求を受信し、及び／又は設定プロセスを完了すると、ゲーム管理システム１０２は、 ５３４において承認申請を提出してもよい。レビューと承認は、自動的に及び／又は手動で提供されてもよい。いくつかの実施例においては、たとえば、不確定事象が関係諸規則及び／又は事前にクリアされた不確定事象の形式に準拠しているか否かを判断するために、所定のビジネスルールのセットが、この１個以上の不確定事象及びその特性に反して提出される。また、いくつかの実施例では、アプリケーション内での、特性に従った不確定事象の応答をテストするため、一連のシミュレートされた賭けが行われる。手動によるレビューと承認は、アプリケーション、その不確定事象及び関係する特性を、促進企業体の法務ないし法令遵守の適切な担当者がレビューすることからなっていてもよい。

承認の際、ゲーム管理システム１０２は、任意的に、５３６でアプリケーションを公開してもよい。アプリケーションの公開は、アプリケーションの告知を設けることと、いくつかの実施例においては、促進企業体のウェブページにダウンロードリンクを設けることとからなる。たとえば、ウェブページは、ゲーム管理システム１０２に既存のアカウントを有するユーザがアクセス可能であってもよい。同様に、ゲーム管理システム１０２は、アプリケーションのための追加の広告を提供してもよい。

図１１−３９は、ゲーム管理システム１０２が、不確定事象を含むアプリケーションの設定及び承認のために開発者に提供し得るインタフェースの様々な実施例を示すスクリーンショットで示す。図１１は、設定及び承認のためにアプリケーションないしゲームの名称を受け取るために開発者に提供し得るインターフェース画面１５００の実施形態のひとつを示すスクリーンショットである。画面１５００は、ゲームないしアプリケーション名やゲームや不確定事象タイプを提供するかどうかを開発者が選択し得るフィールド１５０２を含む。図１１では、ゲームタイトルという選択肢が選択されている。これを受けて、画面１５００は、設定されるゲームないしアプリケーションのタイトルを開発者が入力でるゲームタイトルフィールド１５０４を備えている。図１２は、ゲームまたは不確定事象のタイプを受け取るために開発者に提供され得るインターフェース画面１５００の実施形態のひとつを示すスクリーンショットである。図１２では、ゲームタイプの選択肢が１５０２から選択されている。これを受けて、ゲームタイプフィールド１５０６が表示される。ゲームタイプフィールド１５０６は、開発者はゲームないし不確定事象のタイプを選択できるようにするための、ドロップダウンメニュー１５０８又は他の適切な選択機構を含んでいてもよい。いくつかの実施例では、アプリケーションは単一の不確定事象タイプからなり、１５０６で示された不確定事象タイプがアプリケーションないしゲームの不確定事象タイプとなることが理解されよう。図１２及び図１３では、選択された不確定事象タイプは「スロットマシン」である。不確定事象タイプ「キノ」「ルーレット」及び「配当表」を示している追加の画面を図２８−３３に示す。

上述のように、フィールド１５０６及び／又はドロップメニュー１５０８で示されたそれぞれの不確定事象タイプは、設定フレームワークに関連付けることができる。たとえば図１３は、選択された不確定事象タイプを記述するために開発者に提供され得るインターフェース画面１５００の実施形態のひとつを示すスクリーンショットである。図１３に示すように、画面１５００は、たとえば、選択された不確定事象のために必要な設定の説明など、選択された不確定事象タイプについての開発者のための情報を含む不確定事象タイプフィールド１５１０からなる。

図１４は、「スロットマシン」タイプの不確定事象のためのフレームワークによる不確定事象設定の特性を受け取るために開発者に提供され得るインターフェース画面１５１２の実施形態のひとつを示すスクリーンショットである。画面１５１２は、図示するように、設定された不確定事象の統計を記述する統計フィールド１５１４からなる。フィールド１５１６は、この不確定事象についてプレーヤーへの配当（ＲＴＰ）を示す。フィールド１５１８は、不確定事象の分散を示している。フィールド１５２０は、不確定事象の全体的な勝率（たとえば、ユーザが何らかを勝ち取る回数の全体的なパーセンテージ）を示する。フィールド１５２２は、ゲームないしアプリケーションの状態（たとえば、設定及び承認のプロセスにおけるアプリケーションの状態）を示している。フィールド１５２４は、「スロットマシン」型の不確定事象タイプに対して利用可能な設定パラメータのカテゴリを示している。「シンボル」の表示が選択されている。従って、フィールド１５２６には、スロットマシンのリールに配置されるシンボルを定義する設定の特性を開発者から受け取るためのプロンプトが含まれていてもよい。フィールド１５２８は、開発者がシンボルの名前を入力することを可能にし得る。フィールド１５３０は、既に追加されている記号を示す。

図１５は、追加の不確定事象設定の特性を受け取るために開発者に提供し得るインターフェース画面１５１２の実施形態のひとつを示すスクリーンショットである。たとえば、値は「リール＆コンビネーション」をフィールド１５２４から選択してもよい。 「リール＆コンビネーション」は、「スロットマシン」タイプの不確定事象のための利用可能な設定パラメータの第２のカテゴリーであり得る。フィールド１５３３は、開発者から「リール＆コンビネーション」の値を受け取ることができる。たとえば１５３４において、開発者は、スロットマシンに含まれるリール数を入力してもよい。また、１５３４で開発者は、１５２６で入力されたそれぞれのシンボルについて、このシンボルがそれぞれのリールに現れる回数を入力してもよい。また、図示するように、１５３４では、それぞれのシンボル及びリールについて、このリールが回転後にこのシンボルを返す確率が示される。たとえば、確率は、リール上のシンボルの総数によって決定され得る。フィールド１５３６では、開発者は、1個以上のリールを横断するシンボルの組み合わせを（たとえば、ペイラインで）入力してもよい。ゲーム管理システム１０２はまた、１５３６で、入力された組み合わせが発生する確率を提供してもよい。いくつかの実施例では、開発者は、５３６で勝利倍率を入力してもよい。勝利倍率は、選択された組み合わせの発生時にユーザが「獲得」し得る、ユーザの賭金への倍率を表すものであってもよい。フィールド１５３８は、完成された組み合わせだけでなく、すべての組み合わせにわたってプレイヤーへの全体的な配当を示してもよい。図１６に示すように、フィールド１５１４は、不確定事象の設定パラメータが入力されると更新してもよい。たとえば、図１５に示す不確定事象の設定パラメータで、プレイヤーへの配当は８９．０５％、分散は＋／−３％で、全体的な勝率は８％である。

図１５Ａは、結果タイプフィールド１５３９を含む、図１５Ａのインターフェース画面１５１２の実施形態のひとつを示すスクリーンショットである。開発者は、結果タイプフィールド１５３９で、ユーザが賭けに勝った際に何を勝ち取るのかの告知を入力することができる。いくつかの実施形態では、開発者が「リアルマネー」の結果と「クレジット」の結果との間で選択する。「リアルマネー」の結果によると、ユーザは、たとえば、開発者がインターフェースを介して別途入力した額現実の金銭を賭けて勝ち取ることができる。「クレジット」の結果によれば、ユーザは「クレジット」ないし仮想通貨を賭け、獲得することができる。仮想通貨は、単にゲーム内でのユーザのパフォーマンスの尺度であってもよく、あるいはいくつかの実施形態では、たとえば、追加的なゲームプレイ、ゲーム内の仮想アイテム、予め選択された商品の購入など、現実または仮想の商品のために使用してもよい。

図１６は、追加の不確定事象設定の特性を受け取るために開発者に提供し得るインターフェース画面１５１２の実施形態のひとつを示すスクリーンショットである。図１６では、フィールド１５２４から「配当表」が選択されており、「スロットマシン」型の不確定事象のために利用可能な構成パラメータの第三のカテゴリを示す。フィールド１５４０は、配当表がシンボルの潜在的な勝利の組み合わせを示す線に対応付けられた不確定事象に対して、開発者が異なる配当表を入力できるようにする。フィールド１５４２は、すでに入力されている配当表を示している。図１１−１６は、一つの不確定事象の構成を示している。１１−１６の画面は、複数の不確定事象を利用するようにプログラムされているアプリケーションについては、追加の不確定事象を構成するために再度提供されてもよいことが理解されよう。

図１７は、ＡＰＩ証明書、ドキュメント及びアプリケーションをコーディングするための情報を開発者に提供するために開発者に提供され得るインターフェース画面１５４６の実施形態のひとつを示すスクリーンショットである。上述したように、インターフェース画面１５４６は、たとえばプロセスフロー５００の動作５２４を実行するために開発者に提供してもよい。画面１５４６は、ＡＰＩ証明書フィールド１５４８を含んでいてもよい。フィールド１５４８は、ゲームないし設定されたその他のアプリケーションの一意なキーまたは他の識別子を含み得るゲームＩＤサブフィールド１５５０からなる。ゲームＩＤは、 ＡＰＩ証明書５０７の一部であってもよく、たとえば、プロセスフロー３００に関して上述したアプリケーション認証３０７の全部または一部として、アプリケーションによってゲーム管理システム１０２に提供されてもよい。 ＡＰＩキーとＡＰＩシークレットは、サブフィールド１５５２及び１５５４でそれぞれ供給されてもよい。図１７に示した実施例では、開発者は、ＡＰＩキーとＡＰＩシークレットを受け取る前に、リダイレクトのユニバーサルリソースインジケータ（ＵＲＩ）を提供するよう求められるものとしてもよい。いくつかの実施例では、 ＡＰＩキーとＡＰＩシークレットはまた、上述のＡＰＩ証明書５０７及びアプリケーション認証３０７の一部であってもよい。

画面１５４６はまた、必要に応じて開発者に提供される追加のリソースを備えている。たとえば、 ＡＰＩドキュメント＆サポートフィールド１５５６は、ＡＰＩ１０８を記述したドキュメント、選択された不確定事象タイプ及び一般的な開発者用リソースへのリンクを含んでいる。ダウンロードＳＤＫのフィールド１５５８は、ＡＰＩ１０８と互換性のあるアプリケーションを開発するためのツールを含むソフトウェア開発キットへのリンク１５６０、１５６２、１５６４を開発者に提供してもよい。図１７に示した例では、 ＳＤＫは、Ｏｂｊｅｃｔｉｖｅ−Ｃ、Ｊａｖａ及びＪａｖａＳｃｒｉｐｔで利用可能である。なお、実施形態によっては、より多くの、より少ない及び／又は異なる言語がサポートされていてもよいことは理解されよう。

図１８は、テスト環境のＡＰＩ証明書を開発者に提供し、開発者から賭博場の資金を受け取り、及び／又はテストユーザに提供するために開発者に提供され得るインターフェース画面１５６６の実施形態のひとつを示すスクリーンショットである。様々な実施形態では、最終的なアプリケーションをテストするためにサンドボックスまたは開発環境をセットアップするのに画面１５６６を利用してもよい。画面１５６６は、サンドボックスないし開発環境のリダイレクトＵＲＩを示すフィールド１５６８を含む。リダイレクトＵＲＩは、アプリケーションが、不確定事象リクエスト３１１、及び、アプリケーションを介して容易にされるゲーム管理システム１０２とユーザとの間の通信を行うＵＲＩであってもよい。様々な実施形態では、サンドボックスまたは開発環境リダイレクトＵＲＩは、非製品開発環境で利用されているものである。上述したように、いくつかの実施例で開発者は、 上述のＡＰＩ証明書５０７の現示を得るためにも、リダイレクトＵＲＩを利用してもよい。資金追加フィールド１５７０は、開発者が開発環境に資金を追加することを可能にする。金額は、フィールド１５７０で選択できる。資金は、資金追加ボタン１５７１を選択することにより追加され得る。なお、資金追加ボタン１５７１を選択したとき、開発者から支払情報を受け取るための適切な追加画面が起動されてもよいことは理解されよう。フィールド１５７０を介して受け取られた資金は、任意の適切な目的で使用してもよい。たとえば、資金を賭博場の資金として、開発用、及び／又はテストユーザのために使用してもよい。テストユーザフィールド１５７２は、開発者が開発環境でアプリケーションを再生するために、テストユーザを招待することを可能にする。テストユーザの電子メールアドレスは、１５７２で入力されてもよい。入力されたユーザに招待状を送信するために、招待の送信ボタン１５７３が選択されてもよい。フィールド１５７２はまた、図示するように、以前に招待されたユーザや、このユーザのステータス（たとえば、アクティブまたは非アクティブ）を示す。開発者は、必要に応じ、非アクティブなテストユーザを再招待してもよい。アプリケーションは、承認及び必要に応じた公開の前に、１５４８及び１５６８で提供されるＡＰＩ証明書を使用して、告知されたテストユーザによりテストされてもよい。

図１９は、製品環境のＡＰＩ証明書と不確定事象の許容特性を開発者に提供し、開発者から不確定事象の特性変更を受け取るために開発者に提供され得るインターフェース画面１５７４の実施形態のひとつを示すスクリーンショットである。製品リダイレクトＵＲＩ１５７６は、製品環境のアプリケーションに使用されるリダイレクトＵＲＩを提供してもよい。ゲームのセットアップの詳細フィールド１５７８は、図示するように、選択された不確定事象の設定特性や、特性の許容範囲を提供する。たとえば、フィールド１５７８は、画面１５００と１５１２を介して入力された不確定事象の設定の結果としてのプレーヤーへの配当、分散及び全体的な勝利のパーセンテージを示す。フィールド１５７８はまた、賭金の最大許容量と最小運転資金とを示している。これらの値は、入力された不確定事象の特性と関係諸規則とに基づいて決定してもよい。地理的利用可能性フィールド１５８０は、不確定事象に対して現実の金銭を賭けることが法的に認められないに法域を示している。フィールド１５８０に列挙される法域は、オンラインギャンブルを許可しない法域や、不確定事象ないしその設定について両立しない規制が設けられた法域を含んでいてもよい。フィールド１５８２は、除外する法域を開発者が追加的に定めることを可能としてもよい。追加的に除外する法域は、フィールド１５８２で入力し、ボタン１５８４を選択することにより、除外する法域のセットに追加されてもよい。追加する法域は、法的な及び／又はビジネス上の目的のために開発者が選択してもよい。

図２０は、ゲーム管理システム１０２と開発者のアプリケーションとを統合するために適切な工程がとられていることを確認するために、開発者に提供され得るインターフェース画面１５８４の実施形態のひとつを示すスクリーンショットである。画面１５８４は、ゲーム管理システム１０２へのアプリケーションの統合を完了するために開発者が実行しなければならない工程を記したステータスフィールド１５８６を備えている。フィールド１５８４は、たとえば、開発者が、（ｉ）開発者が、製品リダイレクトＵＲＩを提供し及び／又は受け取ったこと（画面１５７４のフィールド１５７６を参照）、（ｉｉ）開発者、テストユーザを用いてアプリケーションをテストしたこと（画面１５６６を参照）、及び（ｉｉｉ）開発者が、十分な運転資金（たとえば、アプリケーション内の不確定事象のための賭博場の資金）を入金したこと、を確認することを要求してもよい。

すべての３つのステップが完了されていれば、開発者は「公開に移る」ボタン１５８８を選択してもよい。

図２１は、アプリケーションを実行するために必要な運転資金（たとえば、「賭博場の資金」）の概要を提供するために開発者に提供され得るインターフェース画面１５９０の実施形態のひとつを示すスクリーンショットである。運転資金フィールド１５９２は、最大許容ベットないし賭金を受け取ってもよい。いくつかの実施例では、最大許容ベットないし賭金は、関連諸規制により制限され得る。ゲーム管理システム１０２は、最大許容ベットに基づいて、最低必要入金額、ないし賭博場の資金の最低レベルを決定してもよい。最低必要入金額は、関係諸規制及び／又は促進企業体のポリシーに基づいて決定してもよい。 賭博場の資金の一部または全部が促進企業体によって提供される実施形態では、最低必要入金額は、規制で要求されている賭博上の資金の最低額、及び／又はゼロ（促進企業体が、賭博場の資金の全額を提供している場合）でよい。いくつかの実施例では、運転資金フィールド１５９２はまた、賭金ないしベット１０００あたりの見込み利益を提供する。追加の運転資金が必要な場合、開発者１５９４は、画面１５９６を起動するため、運転資金入金１５９４を選択することもできる。

図２２は、運転資金を受け取るために開発者に提供され得るインターフェース画面１５９６の実施形態のひとつを示すスクリーンショットである。画面１５９６は、開発者が預金額を提供し支払手法を選択できる支払方法選択フィールド１５９８を含む。図２３は、開発者の付加的支払情報フィールドを含むインターフェース画面１５９６の実施形態のひとつを示すスクリーンショットである。たとえば、開発者がフィールド１５９８で「クレジットカード」の支払手法を選択したとき、フィールド１６００は、選択されたクレジットカードを記述する情報を開発者から受け取ることができる。フィールド１６０２は、クレジットカードに対応付けられた課金情報を受信してもよい。図２４は、開発者のための支払確認情報を示すインターフェース画面１６０６の実施形態のひとつを示すスクリーンショットである。フィールド１６０８は、支払われた金額、支払手法及び取引の識別子すなわちＩＤを開発者に対し確認する支払確認フィールドを含む。なお、運転資金もまた、任意の他の適切な手法に従って開発者から受け取られてよいことは理解されよう。たとえば、開発者は、金融機関の口座からの直接入金、小為替、電信送金等により運転資金を提供してもよい。

図２５は、アプリケーションを記述する開発者を情報から受け取るために開発者に提供され得るインターフェース画面１６１０の実施形態のひとつを示すスクリーンショットである。画面１６１０を介して受け取られたアプリケーション情報は、たとえば、アプリケーションを公開（たとえば、プロセスフロー５００の５３６）のために記述するため、ゲーム管理システム１０２によって利用されてもよい。画面１６１０は、情報フィールド１６１２を含んでいる。表題サブフィールド１６１４は、アプリケーションの表題を受け取る。いくつかの実施例では、表題は、事前に開発者から受け取った情報に基づいて、あらかじめ設定されている。記述フィールド１６１６には、アプリケーションを記述したテキストを開発者が提供するためのテキストフィールドが設けられていてもよい。説明タグフィールド１６１８は、開発者がアプリケーションを記述するテキストタグを提供することを可能にしてもよい。フィールド１６１８は、既に選択されているタグを列挙する。説明タグは、たとえば、アプリケーションのキーワード検索を容易にするために使用してもよい。プラットフォームフィールド１６２０は、アプリケーションが互換性をもつためのプラットフォームの指標を開発者が提供することを可能とするものであってもよい。なお、ゲーム管理システム１０２は、任意の適切なプラットフォーム用に開発されたアプリケーションと互換性があってもよいことが理解されよう。フィールド１６２０で例示されたプラットフォームは、アップル社のｉＯＳ、グーグル社のＡｎｄｒｏｉｄ、ＨＴＭＬ５及びＯｐｅｎ Ｗｅｂである。開発者名フィールド１６２２は、開発者の名前を受け取ることができる。開発者ユニバーサルリソースロケータ（ＵＲＬ）フィールド１６２４は、開発者のウェブサイトのＵＲＬを受け取ることができる。

図２６は、アプリケーションを記述する情報を確認してこのアプリケーションの承認及び公開を申請するために開発者に提供され得るインターフェース画面１６２６の実施形態のひとつを示すスクリーンショットである。ゲーム情報フィールド１６２８は、画面１６１０を介して提供されるアプリケーションの情報を識別してもよい。フィールド１６２８での情報の正確性を検証すると、開発者は、ボタン１６３０を選択することにより、承認の申請（たとえば、プロセスフロー５００の５１６）を提出してもよい。ボタン１６３０を選択すると、ゲーム管理システム１０２は、たとえばプロセスフロー５００の５３４について示したように、承認の申請をレビューしてもよい。申請が承認されたとすると、たとえばプロセスフロー５００の５３６について示したように、公開されてもよい。図２７は、アプリケーションの承認及び公開を告知するために、開発者に提供され得るインターフェース画面１６３２の実施形態のひとつを示すスクリーンショットである。画面１６３２は、図１１−２６に示したアプリケーション（たとえば「Ｗｈｅｅｌｓ ｏｆ Ｓｔｅｅｌ」）が承認され、公開されていることを示す公開フィールド１６３６を含んでいる。承認されると、ユーザにより及び／又はユーザの代わりに実行されるアプリケーションのインスタンスは、たとえば図２及び３について示したように、ゲーム管理システム１０２と通信してもよい。新規ゲーム作成ボタン１６３４は開発者を画面１５５０に戻し、アプリケーション及び不確定事象設定のプロセスを再び開始することができる。

図２８−３３は、様々な追加的な事象タイプの例、及び、開発者が他の追加的な事象タイプに関する情報を入力できる画面を示すスクリーンショットである。たとえば、図２８は、フィールド１５０８で選択された「キノ」事象タイプを有する図１３のインターフェース画面１５００の実施形態のひとつを示すスクリーンショットである。不確定事象タイプフィールド１５１０は、「キノ」タイプの事象の生成され得る不確定事象の記述を含む「キノ」タイプの事象の説明を含むように示されている。図２９は、「キノ」タイプの不確定事象のフレームワークによる不確定事象設定の特性を受け取るために開発者に提供され得るインターフェース画面１６４０の実施形態のひとつを示すスクリーンショットである。「キノ」タイプの不確定事象によれば、乱数発生器１１０は一定範囲に従った所定数の乱数を生成してもよい。ユーザが、この範囲内の数字のセットを選択し及び／又は与えられてもよい。いくつかの実施形態では、ユーザの数字のセットは、カードやチケットとして表されてもよい。１個以上の乱数が、ユーザのカードまたはチケットの数字のうちの１個以上と的中するとき、ユーザは賭けに勝ったものとし、的中した数に応じた額の賞金を得る。いくつかの実施形態では、複数のユーザが、ビンゴゲームと同様の要領で、「キノ」タイプの不確定事象に一緒に賭けることができる。

画面１６４０に戻ると、開発者は、異なるチケットの種類を指定することができる。たとえば、フィールド１６４２は、単一の番号からなる一点買いのチケットの構成を示す図である。フィールド１６４２で、開発者は、一点買いチケット各々の潜在的結果の確率（たとえば、的中なしと１個的中）を入力できる。フィールド１６４４で、開発者は、二点買いチケット各々の潜在的結果の確率（たとえば、的中なし、１個的中及び２個的中）を入力できる。フィールド１６４６で、開発者は、三点買いチケット各々の潜在的結果の確率（たとえば、的中、１個的中、２個的中、等）を入力できる。追加的なチケットタイプのための追加的なフィールドが設けられてもよい。いくつかの実施形態では、「キノ」タイプの事象のために選択された乱数の数は、ゲーム管理システム１０２で事前に定義されており、ゲーム管理システム１０２は、事前に定義されたこの値に基づいて、各結果の確率を自動的に算出してもよい。また、いくつかの実施形態では、開発者はそれぞれの潜在的結果のための倍率を入力する。倍率が、それぞれの結果に対する払い出し額を決定してもよい。たとえば倍率は、それぞれの潜在的結果が発生した場合に払い出される確率の乗数を示すものであってもよい。画面１６４０が完了すると、開発者に対し、上記の図１７−２７に示した統合及び公開の画面を表示してもよい。

図３０は、フィールド１５０８で選択された「ルーレット」事象タイプを有する図１３のインターフェース画面１５００の実施形態のひとつを示すスクリーンショットである。フィールド１５１０は、「ルーレット」タイプの事象から生成され得る不確定事象の記述を含む「ルーレット」タイプの事象の記述を含むように示されている。「ルーレット」型不確定事象によれば、乱数発生器１１０は、所定の範囲内で乱数を発生させる。ユーザは、これもまた上記所定の範囲内である番号を、選択し又は割り当てられる。ユーザの番号がランダムに生成された番号に的中した場合、ユーザは賭けに勝ったものとする。そうでない場合は、ユーザは負けたものとする。図３１は、 「ルーレット」タイプの不確定事象のフレームワークによる不確定事象設定の特性を受け取るために開発者に提供され得るインターフェース画面１６４８の実施形態のひとつを示すスクリーンショットである。画面１６４８は、アメリカンスタイルまたはヨーロピアンスタイルのルーレットを開発者が選択できるフィールド１６５０からなる。いくつかの実施形態では、アメリカンスタイルのルーレットは、３７個の数字のセットを含み（たとえば、３７個のスロットを備えたホイール）、一方、ヨーロピアンスタイルのルーレットは３８個の数字のセットを用いる（たとえば、３８個のスロットを備えたホイール）。いくつかの実施形態において、フィールド１６５０は、開発者が数字のセットの任意のサイズを入力することを可能としてもよい。画面１６４８が完了すると、開発者に対し、上記の図１７−２７に示した統合及び公開の画面を表示してもよい。

図３２は、選択された「配当表」事象タイプを有する図１３のインターフェース画面１５００の実施形態のひとつを示すスクリーンショットである。フィールド１５１０は、 「配当表」タイプの事象から生成され得る不確定事象の記述など、「配当表」タイプの事象の記述を含むように示されている。 「配当表」タイプの事象によれば、開発者は、潜在的結果のセット、及び各結果の発生確率を指定してもよい。図３３は、「配当表」タイプの不確定事象のフレームワークによる不確定事象設定の特性を受け取るために開発者に提供され得るインターフェース画面１６５２の実施形態のひとつを示すスクリーンショットである。画面１６５２は、潜在的結果を記述する情報を開発者から受け取ることができるフィールド１６５６を含む。各潜在的結果について受け取られる情報は、結果の名称、倍率または他の配当率、及び結果の発生確率を含んでいてもよい。保存された結果フィールド１６５４は、「配当表」タイプの不確定事象について以前に入力された結果を示していてもよい。開発者は、 追加ボタン１６５８を選択することで、追加的な結果を追加してもよい。画面１６５２が完了すると、開発者に対し、上記の図１７−２７に示した統合及び公開の画面を表示してもよい。

図３４−４３は、不確定事象を含むアプリケーションを設定して承認のためにゲーム管理システム開発者に１０２によって開発者へと提供される代替的インターフェースの様々な実施例を示すスクリーンショットである。図３４は、アプリケーションの名称及びこのアプリケーションに対応付けられた様々な不確定事象を受け取るために開発者に提供され得るインターフェース画面１７００の実施形態のひとつを示すスクリーンショットである。フィールド１７０２は、アプリケーションの名称（たとえば、ゲームタイトル）を受け取ることができる。フィールド１７０４ （図３４においては結果セットフィールドと呼ばれる）は、アプリケーションで遭遇する可能性のある不確定事象の告知を受けることができる。たとえば、開発者はフィールド１７０４で、不確定事象を記述した情報を入力してもよい。図３４には３個の不確定事象フィールド１７０４が示されているが、ボタン１７０６を選択することによって追加的なフィールドを加えることもできる。開発者は、入力された不確定事象プロパティをボタン１７０８を選択して保存し、続行することができる。図３５は、フィールド１７０２で入力されたアプリケーションのタイトルを有するインターフェース画面１７００の実施形態のひとつを示すスクリーンショットである。図３５に示したアプリケーションの例のタイトルは「ロイヤル競馬」である。図３６は、フィールド１７０４で入力された３個の不確定事象を有するインターフェース画面１７００の実施形態のひとつを示すスクリーンショットである。この３個の不確定事象は、「グランドナショナル」、「ケンタッキーダービー」と「パリオディシエナ」と呼ばれている。 図３４−４３で示したアプリケーションの例では、不確定事象は競馬である。不確定事象タイプは、競馬に特有の事象タイプ及び／又は開発者がそれぞれの潜在的結果とそれぞれの確率とを提供する一般的な不確定事象であってもよい。また、たとえば、フィールドに不確定事象を入力することと、図１０に示すプロセスフロー５００の動作５０７とは等価であってもよい。

図３７は、不確定事象設定の特性を潜在的結果の形で受け取るために開発者に提供され得るインターフェース画面１７１０の実施形態のひとつを示すスクリーンショットである。画面１７１０は、画面１７００に示す不確定事象「グランドナショナル」に対応付けられたフィールド１７１２を含んでいる。フィールド１７１２は、サブフィールド１７１４を含む。各サブフィールド１７１４は、フィールド１７１２で示された不確定事象に対応付けられる潜在的結果を受け取ることができる。たとえば、図３７は、「グランドナショナル」と呼ばれる不確定事象の４個の潜在的結果を示す。 潜在的結果は、レースに勝ち得る馬の名前を示している。図３７に列挙されている潜在的結果は「Ａｌｙｄａｒ」「Ｂｌａｃｋ ｇｏｌｄ」「Ｒｕｆｆｉａｎ」及び「Ｓｅａｂｉｓｃｕｉｔ」である。結果追加ボタン１７１６を選択することによって、追加的な潜在的結果を受け取るための追加的な潜在的結果サブフィールドが表示されてもよい。画面１７１０は、画面１７００で「ケンタッキーダービー」と呼ばれる不確定事象に対応付けられた追加的なフィールド１７１６を含んでいてもよい。図３７は、１個の潜在的結果サブフィールド１７１８を示す。なお、追加的な潜在的成果サブフィールド１７１８及び追加的な不確定事象フィールドは、画面１７１０の一部であってもよく、矢印１７２０の方向にスクロールすることで見られるようにしてもよいことは理解されよう。

図３８は、潜在的結果に対応付けられた確率の形で不確定事象設定の特性を受け取るためのフィールドを含むインターフェース画面１７１０の実施形態のひとつを示すスクリーンショットである。フィールド１７２２は、対応付けられたフィールド１７１４に示されている潜在的結果に対応付けられてもよい。それぞれのフィールド１７２２は、それぞれの潜在的結果の確率の指標を受け取ってもよい。フィールド１７２４は、異なった潜在的結果の確率の合計を表示する。図３８において、確率はパーセンテージとして表され、異なる潜在的結果に対応付けられたすべての確率の合計は１００％である。いくつかの実施例では、各確率は、異なる潜在的結果に対応付けられた分数すべての合計が１００％であるような各分数として表されていてもよい。開発者からのフィールド１７１６で示されている不確定事象「ケンタッキーダービー」の、フィールド１７１８で示されている潜在的結果「Ｂａｒｂａｒａ」の確率を受け取るために、フィールド１７２６を使用してもよい。なお、追加的な潜在的結果と確率が、たとえば下にスクロールすることにより画面１７１０で表されていてもよいことは理解されよう。

図３９は、不確定事象設定の特性を賭博場の取り分の形で開発者から受け取るために開発者に提供され得るインターフェース画面１７３０の実施形態のひとつを示すスクリーンショットである。賭博場の取り分は、賭博場で保持されている賭金の一部分（たとえば、パーセンテージ）であってもよい。フィールド１７３２は、開発者が賭博場の取り分を修正できるようにしてもよい。いくつかの実施例では、ゲーム管理システムは、所望の賭博場の取り分に基づいて、個々の不確定事象について自動的に払い出しを設定してもよい。種々の実施例では、上述したように、開発者及び促進企業体が賭博場の取り分から収益を分割してもよい。フィールド１７３２で選択された賭博場の取り分は、前述の画面で入力した不確定事象の一部またはすべてに適用される場合がある。賭博場の取り分を選択すると、開発者は、保存＆続行ボタン１７３４を選択し処理を進めてもよい。

図４０は、アプリケーションの賭博場のアカウントを記述した開発者不確定事象設定の特性から受け取るために開発者に提供され得るインターフェース画面１７３６の実施形態のひとつを示すスクリーンショットである。なお、賭博場のアカウントのサイズが、並行して取り扱い得るベットの数を決定し得ることは理解されよう。仲介企業体がアプリケーションのために賭博場の資金を提供することを告知するため、開発者によってフィールド１７４０が選択されてもよい。いくつかの実施例で、促進企業体は、賭博場の資金を提供する見返りに、より大きな割合の賭博場の取り分を要求するようにしてもよい。開発者が賭博場の資金を負担するために資金を入金することを示すために、開発者によってフィールド１７３８が選択されてもよい。フィールド１７４２は、賭博場のアカウントへと入金される所定額の告知を開発者から受け取ってもよい。それぞれの所定額は、賭博場のアカウントで資金回転が起こるたびに、見込み配当額と併せて一覧表示されてもよい。いくつかの実施例では、フィールド１７４４は、開発者が賭博場のアカウントに、カスタムの金額を入力できるようにしてもよい。いくつかの実施例では、ユーザがフィールド１７４４のボックスをチェックし、賭博場のアカウントの残高が尽きた際にこのアカウントを自動的に再充填するようにゲーム管理システム１０２を設定してもよい。開発者は、保存＆継続ボタン１７４６を選択することにより、処理を継続できる。

図４１は、受け取った不確定事象の設定を確認するために開発者に提供され得るインターフェース画面１７４８の実施形態のひとつを示すスクリーンショットである。フィールド１７５０は、確認済みの不確定事象、確認済みの潜在的結果、確認済みの潜在的結果の確率など、以前に入力された不確定事象の設定データを含んでいてもよい。フィールド１７５０はまた、各不確定事象の各潜在的結果について、たとえば賭博場の取り分の希望額に基づき、見込み配当額を告知するものであってもよい。

画面１７４８に示されている不確定事象の設定データが受け入れ可能であるとした場合、開発者は、保存＆提出ボタン１７５１を選択し、たとえばプロセスフロー５００の５１６と同様に、承認の申請を提出してもよい。図４２は、支払詳細情報（たとえば、図４０の画面１７３６について示すように、賭博場のアカウントに資金を入金するための）を受け取るために開発者に提供され得るインターフェース画面１７５２の実施形態のひとつを示すスクリーンショットである。画面１７５２は、支払詳細情報を受け取るためのフィールド１７５４を含む。支払詳細情報は、支払形式（たとえば、クレジットカート、小為替、電信送金、ＮＥＴｅｌｌｅｒなど）を含んでいてもよい。課金額は、上記の画面１７３６ついて設定したようであってもよい。クレジットカード支払いフォームが選択された場合、受け取るべき付加情報としては、カード所有者名、クレジットカード番号、有効期限、セキュリティコードなどが含まれ得る。開発者は、入金ボタン１７５６を選択して取引を完了することができる。図４３は、アプリケーションが受理されたことを開発者に告知するために開発者に提供され得るインターフェース画面１７５８の実施形態のひとつを示すスクリーンショットである。フィールド１７６０は、アプリケーションが承認された開発者に告知するものであってもよい。承認されると、ユーザにより及び／又はユーザの代わりに実行されるアプリケーションのインスタンスは、たとえば図２及び３について示したように、ゲーム管理システム１０２と通信してもよい。

図１に戻って参照すると、ＡＰＩ１０８は、任意の適切な通信プロトコルに従う任意の適切なタイプのＡＰＩであってよい。たとえば、ＡＰＩ１０８は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）及び／又はセキュアハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）を利用するものであってもよい。ＡＰＩ１０８は、表現可能な状態の転送の原則を遵守する（ＲＥＳＴｆｕｌである）よう、及び／又はプラットフォーム間の一般性を獲得できる他の適切な手法を利用するよう構成されてもよい。様々な実施形態では、アプリケーションとＡＰＩ１０８との間の一部又は全部の通信は、たとえば、ＨＴＴＰＳ、セキュアソケットレイヤー（ＳＳＬ）、トランスポート層セキュリティ（ＴＬＳ）などのセキュア通信プロトコルを利用した安全なものであってもよい。

また、種々の実施形態において、ＡＰＩ１０８は、ＡＰＩ１０８を利用するアプリケーションを任意の適切な手法を使用して認証してもよい。いくつかの実施例では、ＡＰＩ１０８は、ＯＡｕｔｈ２.０又は同様の認証機構を利用してアプリケーションを認証してもよい。図４４は、ゲーム管理システム１０２（たとえば、そのうちのＡＰＩ１０８）、及びＡＰＩ１０８にアプリケーションを認証するアプリケーションによって実装され得るプロセスフロー１８００の実施形態のひとつを示すフローチャートである。たとえば、プロセスフロー１８００は、プロセスフロー３００の動作３０６及び３１４を表し得る。図４４において、列１８０１は、アプリケーションによって実行される動作に相当し、一方で列１８０３は、ゲーム管理システム１０２ （たとえば、そのうちのＡＰＩ１０８ ）によって実行される動作に相当する。１８０２で、アプリケーションは、ＡＰＩ１０８が提供する認証ページへとユーザをリダイレクトしてもよい。認証ページは、カスタムＵＲＩスキームと併せてアプリケーションに知られているユニバーサルリソースロケータ（ＵＲＬ）によって識別されるものであってもよい。いくつかの実施例では、ＵＲＬ及びカスタムＵＲＩスキームは、図１０−４３に関して説明した設定及び統合の間にアプリケーションに提供される認証キーあるいは他のＡＰＩ証明書を示すものであってもよい。また、いくつかの実施例では、ＵＲＩは、図１７−１９に関して上述したところをその一例とする設定及び統合プロセスの間に、アプリケーションへの包含のために開発者に提供されるＵＲＩに相当するものであってもよい。

１８０８でゲーム管理システム１０２は、たとえば、ＡＰＩキーとアプリケーションのユーザから受け取った入力とに基づいてアプリケーションを認証してもよい。ユーザは、たとえば、ゲーム管理システム１０２でアカウントを作成し及び／又はログインしてもよい。いくつかの実施例では、ユーザは、ＡＭＥＲＩＣＡ ＯＮＬＩＮＥのアカウント、ＧＯＯＧＬＥのアカウント、ＹＡＨＯＯのアカウント、ＯＰＥＮＩＤのアカウント、ＦＡＣＥＢＯＯＫのアカウント、ＴＷＩＴＴＥＲのアカウントなどの第三者方のアカウントを使用して認証されてもよい。ユーザは、たとえば、適切なボックスをチェックすることにより、将来のログインを自動化するものとしてもよい。ユーザが認証された後、 ＡＰＩ１０８は、アプリケーションを実行するコンピュータ装置をカスタムＵＲＩスキームのＵＲＩへとリダイレクトしてもよい。たとえば、リダイレクトＵＲＩは、認証リクエストに表示されてもよい。いくつかの実施例では、リダイレクトが認証コード１８１１を伴ってもよい。

１８０４において、アプリケーションは、アクセストークンを取得するために認証コードを利用してもよい。たとえば、アプリケーションは、ＡＰＩ１０８に認証コードを提供してもよい。これに応答してＡＰＩ１０８は１８１２で、アクセストークン１８０７を返してもよい。アプリケーションは、１８０６でアクセストークンを保存してもよい。このアクセストークンは、ときにＯＡＵＴＨアクセストークンと呼ばれるが、ＡＰＩ１０８にアクセスするアプリケーションによって利用されてもよい。

種々の実施例では、ＡＰＩ１０８は、数多くのコマンド／メッセージタイプを取り扱ってもよい。取り扱われ得るコマンド／メッセージの例を以下に再現する：

１. ＧｅｔＵｓｅｒＰｒｏｆｉｌｅ − このメソッドは、たとえばプロセスフロー３００の３０６において、あるいはこれと併せて、ユーザプロファイルを取得するためにアプリケーションによって使用され得る。ユーザプロファイルは、たとえば、ユーザの残高や、ゲームのプレイ中にユーザに対して表示され及び／又はアプリケーションによって利用（たとえば、ゲームに影響を与える目的でゲームプレイ中に）され得る他の情報を記述する情報からなっていればよい。いくつかの実施例において、ＧｅｔＵｓｅｒＰｒｏｆｉｌｅメソッドは、ＨＴＴＰのＧＥＴメソッドとして実装されてもよい。ＧｅｔＵｓｅｒＰｒｏｆｉｌｅメソッドのリクエストパラメーターの例を以下に示す：

ＧｅｔＵｓｅｒＰｒｏｆｉｌｅメソッドの応答データの例を以下に示す：
リクエストが成功した場合の応答データの例：

リクエストが失敗／エラーの場合の応答データ：

２． ＰｌａｃｅＢｅｔ： このメソッドは、不確定事象につきユーザから受け取ったベットないし賭けを行うためにアプリケーションによって利用され得る。いくつかの実施例において、ＰｌａｃｅＢｅｔメソッドは、いくつかの例では、プロセスフロー３００に関して説明した不確定事象リクエスト３１１に相当するものであり得る。いくつかの実施例では、ＰｌａｃｅＢｅｔメソッドは、ＨＴＴＰのＰＯＳＴメソッドとして実装されてもよい。ＧｅｔＵｓｅｒＰｒｏｆｉｌｅメソッドのリクエストパラメータの例を以下に示す。不確定事象は「ｏｕｔｃｏｍｅ ｓｅｔ」として記してある。

ＰｌａｃｅＢｅｔメソッドの応答データの例を以下に示す：
リクエストが成功した場合の応答データの例：

リクエストからのｏａｕｔｈトークンが欠けているか無効であるセキュリティエラーを説明する応答データの例：

フィールドが欠けているか無効であることを原因とするエラーを説明する応答データの例：

ベットするに十分な金銭がユーザのアカウントにないことを告知する応答データの例：

３． ＧｅｔＵｓｅｒＢｅｔ： この手法では、特定の期間内にユーザによって行われたベットを取得するためにアプリケーションによって利用され得る。いくつかの実施例では、リクエストを行ったアプリケーションを介してユーザが行ったベットのみを返すものであってもよい。ＧｅｔＵｓｅｒＢｅｔメソッドは、ＨＴＴＰのＧＥＴメソッドを利用してもよい。いくつかの実施例では、アプリケーションは、ユーザによるクエリに応答して及び／又は自動的に、ユーザが最近行ったベットについてユーザに勧告を行うためにＧｅｔＵｓｅｒＢｅｔメソッドを行ってもよい。ＧｅｔＵｓｅｒＢｅｔメソッドのリクエストパラメータの例を以下に示す。不確定事象は「ｏｕｔｃｏｍｅ ｓｅｔ」として記してある。

ＧｅｔＵｓｅｒＢｅｔメソッドの応答データの例を以下に示す：
リクエストが成功した場合の応答データの例：

リクエストからのｏａｕｔｈトークンが欠けているか無効であるセキュリティエラーを説明する応答データの例：

上記の例では、ＡＰＩ１０８は、たとえば以下に示すような、種々の構造化データ型を利用してもよい：

上記の実施例では、ＡＰＩ１０８は、様々な異なるステータスコードを利用してもよい。たとえば、コード「エラー４００」は、たとえば供給されたパラメータが原因でリクエストが許可されなかったことを示すエラーに相当するものであり得る。リクエストに際して誤ったデータセットが供給されたときにコード「エラー４００」が受け取られてもよい。誤ったデータセットの例は、たとえばアプリケーションが、空白または無効の電子メールアドレスのユーザを登録しようとしているときに起こり得る。 コード「エラー４０１」は、たとえばトークンパラメータが欠けていたことにより生じた許可上の問題で処理が許されなかったことを示すものであり得る。コード「エラー４０４」は、リクエストされたリソースがサーバ上（たとえば、ゲーム管理システム１０２）で利用可能でないことを示すものであり得る。コード「エラー５００」は、不明なエラーが発生したことを示すものであり得る。このエラーは、たとえば、リクエストクエリ文字列内のデータが破損している場合に発生し得る。

エラーコードの例を以下さらに示す：

なお、上記の例はＡＰＩ１０８のためのひとつの構文例を記述しているにすぎないことは理解されよう。実際には、任意の適切な構文を使用してもよい。

様々な実施形態において、ゲーム管理システム１０２は、ユーザまたはユーザのグループの、特定のタイプのゲーム及び／又は特定のタイプの賭けに対する親和性を決定するための機能がプログラムされていてもよい。この情報に基づいて、ゲーム管理システム１０２は、ゲームアプリケーション及び／又はゲームアプリケーションのプレゼンテーションを、ユーザまたはユーザグループの好みに合わせて変更してもよい。

図４５は、推奨エンジン１１５を含むゲーム管理システム１０２’を実現するための環境１００’の実施形態のひとつを示す図である。図４５に示すように、ゲーム管理システム１０２’は、ＡＰＩ１０８、ＲＧ１１０ 、会計層１１２、及びバンキング層１１４を上述のように備える。いくつかの実施例では、推奨エンジン１１５の機能は、ここで説明したゲーム管理システム１０２の他の機能の文脈の外で実現されてもよい。たとえば、ゲーム管理システム１０２’によって管理されるゲームアプリケーションは、開発者によって作成された上述のアプリケーション及び／又は任意の他の適切な開発者によって任意の他の適切な手法を利用して開発されたアプリケーションを含んでいてもよい。また、いくつかの実施例では、ゲームアプリケーションの全部または一部は、ゲーム管理システム１０２’によって直接実行され、ゲーム管理システム１０２の出力装置を介して及び／又はユーザデバイス１０４を介してユーザに提供される。

図４６は、ユーザへの推奨ゲームアプリケーションを生成し実現するために、ゲーム管理システム１０２’の推奨エンジン１１５によって実現され得るプロセスフロー１９００の実施例のひとつを示すフローチャートである。１９０２では、推奨エンジン１１５は、ユーザのゲームプレイの挙動を監視してもよい。たとえば、ゲーム管理システム１０２’は、上述したように（そしてゲームアプリケーションが開発された手法に関係なく）、ゲームアプリケーション内の不確定事象についての賭けを促進してもよい。ゲームプレイの挙動は、ユーザがプレイすることを選択したゲームないしゲームの種類を含んでいてもよい。いくつかの実施例では、ゲームのプレイの挙動は、個々のゲーム内でユーザが行った決定を含んでいてもよい。そのような決定は、たとえば、不確定事象に賭けるか否か、不確定事象への賭金の額を含んでいてもよい。

ゲームのプレイの挙動は、任意の適切な指標を用いて監視してもよい。

いくつかの実施例では、推奨エンジン１１５は、ユーザにより選択されたゲームで許容されている賭金の最大値または最小値を監視する。いくつかの実施例では、推奨エンジン１１５は、賭けてからこの賭けの結果が出るまでの時間量を監視する。たとえば、一部のユーザは、賭けの結果が迅速に現れるゲーム（たとえば、スロットマシンタイプのゲーム）を好み得るし、一方で他のユーザは、賭けが、結果の現れる前の期間をより長くおいて行われるゲームを好み得る。賭けてからこの賭けの結果が出るまでの時間量は、特定のゲームに、またはユーザがゲーム内で行う決定に、関係し得る。いくつかの実施例では、推奨エンジン１１５は、ユーザが行った賭けの勝率だけでなく、この賭けの配当額も監視する。いくつかの場合において、この値は、配当額に対する勝率の比として表すことができる。いくつかの実施例では、推奨エンジン１１５は、ユーザが行う賭けの結果に対してユーザがもっている支配の程度を監視する。たとえば、スロットマシンやルーレットタイプのゲームに対する賭けは、ユーザに対し、結果に対する支配をほとんど与えないものであり得る。一方、賭けが、少なくともその一部において、ユーザの技量に基づくもの（たとえば、ブラックジャックスタイルのゲーム、上述のスキルゲームなど）。いくつかの実施例では、推奨エンジン１１５は、ユーザのリスク許容度を監視する。リスク許容度は、ユーザが行った賭けに基づいて監視してもよい。たとえば、リスク許容度は、使用による賭金の額にこれに対応する潜在的な払い出し額の観点を混合した額であってもよい。いくつかの実施例では、推奨エンジン１１５は、ユーザの負け分の許容範囲を監視する。負け分の許容範囲は、たとえば、記録されたユーザの負け分及びこの負け分に対するユーザの反応に基づいて、決定されてもよい。負け分の許容範囲は、たとえば、一般的にユーザが、瞬時的に（たとえば、１個の賭けの場合）または累積的に（たとえば、 ２つ以上の賭け）一定の額を負けたことに対し、更なる賭けを切り詰めることを示すものであり得る。

いくつかの実施例では、決定ノードという観点でゲームプレイを特徴付けることによって、ゲームプレイの挙動の追加的な指標を考えられる。ゲーム内の決定ノードは、ユーザが入力を供給したり決定を行うような、ゲームプレイ中の任意の節点であり得る。たとえば、スロットマシンゲームにおいて、スロットマシンのレバーを引く行為、ないしは仮想的に引く行為が、決定ノードを表し得る。ブラックジャックのゲームでは、ユーザがカードを追加し又は追加をせず留まる各機会が、決定ノードを表し得る。ポーカーゲームでは、各アンティ、賭け、及び配札が、決定ノードを表し得る。ゲームアプリケーションによって実装されるゲームの種類に応じて、決定ノードは、固定及び／又は可変であってもよい。たとえば、スロットマシンスタイルのゲームでは、スロットマシンのレバーを引く行為に相当する決定ノードは固定されてもよい。しかしながら、他のタイプのゲームでは、決定ノードの配置と特性は、たとえばユーザが以前行ったゲームプレイの決定に基づき、ユーザによって直接又は間接に決定されてもよい。

このようなゲームの例としては、たとえばスキルゲームや、上述のＦＡＲＭＶＩＬＬＥ、ＦＡＲＭＴＯＷＮ、ＡＮＧＬＹ ＢＩＲＤＳ及びＭＡＦＩＡ ＷＡＲＳのような戦略ゲームが含まれる。

いくつかの実施例では、推奨エンジン１１５は、決定ノードを用いて特徴付けられたゲームについて、追加的なゲームプレイの指標を監視する。決定ノードの頻度は、ユーザがゲームプレイ中に決定ノードに遭遇する頻度を表し得る。決定ノードの頻度は、ゲームアプリケーションそれ自体の関数及び／又はゲームプレイ中のユーザ選択の関数であってもよい。たとえば、スロットマシンやブラックジャックのスタイルのゲームは、ユーザの意思決定にかかわらず決定ノードが比較的一定の周波数を有し得る。一方、ＦＡＲＭＶＩＬＬＥ、ＭＡＦＩＡ ＷＡＲＳなど戦略型のゲームは、少なくとも部分的にはゲームの進行状況及び／又はユーザのプレイのスタイルに基づき、決定ノードが可変的な頻度を有し得る。決定ノードを用いて特徴付けられるゲームの別のゲームプレイの指標の例は、ギャンブルをする機会のノードである決定ノードの量及び／又はパーセンテージである。ギャンブル機会ノードは、ユーザが賭けることができる不確定事象を含みまたはこれに関連するノードであってもよい。たとえば、ブラックジャックスタイルのゲームで、プレイする決定は、ギャンブル機会ノードであり得る。カードを追加し又は追加をせず留まる決定は、決定ノードであり得るが、ギャンブル機会ノードでなくてもよい。また、たとえば戦略ゲームのコンテキストで、ユーザは、ギャンブルの機会を提供するものでない決定ノード（たとえば、標準的または非プレミアムな作物を植栽するという決定や、ボード上の位置の間を移動する決定など）だけでなく、ギャンブルの機会を提供する決定ノード（たとえば、プレミアムな作物を植栽するという決定や、他のキャラクターと対戦するという決定）に遭遇し得る。

図４６に戻って参照すると、推奨エンジン１１５は、１９０４で、観察されたゲームプレイの挙動に基づいてユーザの選好を見積もってもよい。ユーザの選好は、任意の適切な手法で見積もってもよい。いくつかの実施例では、ユーザの選好は、ユーザ毎に見積もってもよい。また、いくつかの実施例では、ユーザの選好は、ユーザのグループ毎に見積もってもよい。たとえば、必ずしもすべてのユーザが、ゲームプレイの挙動の指標につき、統計的に有意なセットを生成するに十分な頻度で賭けをしたりゲームアプリケーションをプレイするわけではない。したがって、ユーザ、及びゲームプレイの挙動の指標は、ユーザの選好を決定するために一緒にグループ化されてもよい。種々の実施例では、ユーザは、共通の特性に基づいてグループ化される。たとえば、ユーザは、類似のバックグラウンド（年齢、プロファイル、ゲームの頻度など）に基づいて及び／又は、共通または類似のゲームプレイ挙動の指標に基づいて、グループ化することができる。

いくつかの実施形態では、ユーザの選好の見積もりは、知覚された効用とリスクの許容度を生成することからなっていてもよい。知覚された効用は、ゲームプレイ挙動の指標の種々の組合せの、ユーザ（またはユーザグループ）についての相対値を示すものであり得る。知覚された効用は、種々の異なる形態で見積もり及び／又は表現することができる。いくつかの実施形態では、知覚された効用は、表形式で示される。たとえば、観察された各ゲームプレイ挙動の指標は、ユーザ及び／又はグループ内のすべてのユーザのための代表値を割り当てられ得る。代表値はたとえば、平均値、中央値などであってもよい。また、種々の実施形態において、知覚される効用は、関数の形式で表されてもよい。たとえば、ゲーム管理システム１０２’は、測定された１個以上のゲームプレー挙動の指標の値と符合する最尤曲線を算出してもよい。

１９０６で、ゲーム管理システム１０２’は、１９０４で見積もったユーザの選好に基づいて、ユーザのゲームプレイを変更してもよい。ユーザがゲーム管理システム１０２’で、このユーザにつきゲーム管理システム１０２’がユーザゲームプレイ挙動の指標のしきい値である量を生成するに十分な頻度でプレイを行ってきた例においては、ゲームアプリケーションへの変更は、このユーザに特有のユーザ選好に基づいていてもよい。いくつかの実施例、及び、このユーザにつきゲーム管理システム１０２’が、このユーザにつき、このしきい値である量未満のユーザゲームプレイ挙動の指標を有している場合は、変更は、このユーザを含むユーザのクラスのユーザの選好に基づいていてもよい。たとえば、ゲーム管理システム１０２’は、ユーザを記述するデータを（たとえばこのユーザから）受け取ってもよい。この情報は、人口統計情報、地理情報などを含んでいてもよい。このユーザ情報に基づいて、ゲーム管理システム１０２’は、ユーザのグループにユーザを割り当て、割り当てられたグループのユーザの選好に基づいて、ゲームプレイを変更してもよい。

ゲーム管理システム１０２’は、任意の適切な手法でゲームプレイを変更してもよい。たとえば、いくつかの実施形態において、ゲーム管理システムは、ユーザにプレイのため提示されるゲームのセットを（たとえば、ユーザインタフェースを介して）変更してもよい。たとえば、ユーザにプレイのため提示されるゲームのセットは、ユーザの選好に近い及び／又は符合する特性を有するゲームを含むようにしてもよい。また、いくつかの実施形態では、ゲーム管理システム１０２’は、ユーザの選好に符合するようにゲームアプリケーションを修正する。たとえば、ゲーム管理システム１０２’は、賭金額の最大値または最小値、ゲームの速度などを、ユーザの選好に符合するように変更してもよい。いくつかの実施形態では、ゲームアプリケーションの変更は、ユーザ装置１０４にコードの更新を送ることにより実装される。他の実施形態では、ゲームアプリケーションへの修正は、ゲーム管理システム１０２’自体によって実現される。実施例では、特定のユーザまたはユーザグループが、賭金の最大額は、特定の量（たとえば、１.００ドル）未満でゲームをプレイすることを好むことがユーザの選好により示され得る。ゲーム管理システム１０２’は、アプリケーション及び／又は特定の量未満である最大賭金額をユーザにゲームを提示するためにアプリケーションに提供される賭金額のパラメータを変更してもよい、

１９０８では、推奨モジュール１１５は、修正されたゲームプレイのユーザの使用を監視することができ、１９１０において、修正されたゲームプレイが、利用者によるゲーム管理システム１０２’の利用の増加をもたらしたか否かを判定してもよい。そして再度、監視及び判定が、単一のユーザ及び／又はユーザのグループに基づいて行われてもよい。１９０８及び１９１０で決定されたフィードバックデータは、ユーザの選好を見積もるために１９０４で利用されてもよい。たとえば、フィードバックデータは、上述したように、ユーザの選好にユーザのゲームプレイ挙動指標を抽出するために利用してもよい。

その全体または一部が参照のためにここに組み入れられたすべての特許文献、刊行物、または他の開示資料、は、組み込まれた資料が本開示に示されている既存の定義、記述、または他の開示資料と矛盾しない限度で組み込まれている。したがって、ここに明示的に記載した開示は、必要な程度で、参照のためここに組み入れられた矛盾するすべての資料に取って代わる。参照のためここに組み入れられたがここに示されている既存の定義、記述、または他の開示資料と矛盾する資料またはその部分は、取り込まれた資料と既存の開示資料との間の矛盾を来さない限度でのみ組み入れられる。

明細書中の「実施例のひとつ」、「実施形態のひとつ」、「実施例」又は「実施形態」との記載は、の実施形態と関連づけて説明される特定の特徴、構造、または特性が本発明の少なくとも１個の実施形態に含まれることを意味する。または本明細書の様々な箇所における「実施例のひとつでは」あるいは「好ましい実施形態」という語句の出現は、必ずしもすべてが同じ実施形態を指すものではない。実施形態の参照は、請求項に係る発明の限定ではなく、むしろ具体例の開示を意図したものである。

上記のいくつかの部分は、コンピュータメモリ内のデータビットに対する手法及び動作の記号的表現に関して示されている。これらの説明及び表現は、最も効果的に他の当業者に彼らの仕事の内容を伝えるために当業者によって使用される手段である。この手法は、ここでは、そして一般に、所望の結果につながる動作（命令）の首尾一貫したシーケンスであるものと考えられる。動作は、物理量の物理的操作を必要とするものである。必ずしも必然的にではないが、通常、これらの量は、格納、転送、結合、比較及びその他の操作が可能な、電気的、磁気的又は光学的信号の形をとる。これらの信号をビット、値、要素、記号、文字、用語、数などとして指し示すことは、主として一般的な用法であるという理由から、ときには便宜である。さらに、物理量の物理的操作を要する動作の一定の取り決めをモジュール又はコードデバイスなどとして、一般性を失うことなく指し示すこともまた、ときには便宜である。

しかしながら、これら及び類似の用語は適切な物理量に対応付けられるべきものであり、単にこれらの量に適用される便宜なラベルにすぎないことには留意すべきである。具体的に言及があるか、そうでなければ従前の議論から明らかでない限り、この説明を通じて、「処理」または「計算」または「見積もり」または「決定」または「表示」又は「決定」等の用語を用いた議論は、コンピュータシステム、又は、コンピュータシステムメモリまたはレジスタまたは他のそのような情報ストレージ、伝送又は表示装置内の物理的（電子的）量として表されるデータの操作及び変換を行う同様な電子計算装置の動作及びプロセスを指す。

本発明の特定の側面は、方法の形式で説明した処理ステップ及び命令を含む。なお、本発明の処理ステップ及び命令は、ソフトウェア、ファームウェア、またはハードウェアで具現化することができ、ソフトウェアで具現化するときは、ダウンロードして常駐させたり、様々なオペレーティングシステムによって用いられる異なるプラットフォームから操作したりできることに留意すべきである。

本発明はまた、ここに説明した動作を実行するための装置に関する。この装置は、必要な目的のために特別に構築されてもよいし、あるいは、コンピュータに格納されたコンピュータプログラムによって選択的にアクティベートされ又は再構成された汎用コンピュータからなっていてもよい。このようなコンピュータプログラムは、フロッピー（登録商標）ディスク、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気または光カード、特定用途向け集積回路（ＡＳＩＣ）を含むがこれらには限定されない任意のタイプのディスクのようなコンピュータ読み取り可能な記録媒体に格納されてもよいし、あるいは、電子的命令を格納するのに適し各々がコンピュータシステムバスに結合される任意の種類の媒体に格納されてもよい。さらに、本明細書にいうコンピュータ及びコンピュータシステムは、単一のプロセッサを含んでもよく、または計算能力を増大するためにプロセッサが複合したデザインを採用するアーキテクチャであってもよい。

ここに提示した方法及びディスプレイは、本質的に特定のコンピュータないし他の装置に関連するものではない。様々な汎用システムもまた、ここに教示したところに従うプログラムと共に使用され得るし、あるいは、必要な手法の動作を実行する、より特化した装置を構築するほうが便宜であることもあり得る。様々なこれらのシステムに必要な構造は上記の説明から明らかになるであろう。また、本発明は、特定のプログラミング言語を参照して説明されるものではない。なお、上述した本発明の教示を実現するために様々なプログラミング言語が使用され得ることは理解されよう、そして特定の言語への言及は、本発明の実施可能性及びベストモードの開示のために提供される。

好適な実施形態及びいくつかの代替的な実施形態を参照して本発明を具体的に説明してきたが、当業者であれば形態及び詳細における種々の変更を本発明の精神及び範囲から逸脱することなし得ることが理解されよう。

最後に、本明細書で使用される言語は、主として読み易さ及び説明の目的で選択されており、本発明の主題を区画ないし限定するために選択されているものではないことに留意すべきである。従って、本発明の開示は説明的な意図に立つものであり、本発明の範囲を限定するものではない。

Claims (51)

1. 開発者コンピュータ装置と連絡し、少なくとも１つのプロセッサ及び動作可能に対応付けられたメモリを備えるコンピュータシステムを備える、ユーザの賭け行為を支援するアプリケーションを促進するための、コンピュータにより実現されるゲーム管理システムであって、当該システムは、
   ユーザプリケーションに対応付けられた不確定事象の設定データを前記開発者コンピュータ装置から受け取り、
   前記設定データが少なくとも１つの所定の基準を満たすか否かを決定し、
   前記設定データが前記少なくとも１つの所定の基準を満たしている場合は、前記開発者コンピュータ装置に、前記ユーザプリケーションにより利用されるためのアプリケーションプログラムインターフェイス（ＡＰＩ）証明書であって、前記不確定事象を決定するために前記ユーザプリケーションがＡＰＩにアクセスすることを可能とするＡＰＩ証明書を供給する、
   ようにプログラムされているシステム。
2. 前記設定データが少なくとも１つの所定の基準を満たすか否かの決定は、前記設定データを、許容される不確定事象の設定のセットと比較することを含む、請求項１に記載のシステム。
3. 前記許容される不確定事象の設定のセットは、前記開発者ではなく前記ゲーム管理システムの実施者によって保持されたギャンブルのライセンスに関連する少なくとも１つの規制上の要件に基づいている、請求項２に記載のシステム。
4. 前記設定データが少なくとも１つの所定の基準を満たすか否かの決定は、
   前記設定データに基づき、少なくも１つの設定パラメータを計算することと、
   前記少なくとも１つの設定パラメータを、規制上の要件のうち少なくとも１つ、及び、少なくとも１つの規制上の要件を事前に満たした不確定事象のフォームの設定パラメータと比較すること、
   を含む、請求項２に記載のシステム。
5. 前記コンピュータシステムは更に、
   許容される事象の設定を計算し、
   前記許容される事象の設定を前記開発者コンピュータ装置に供給し、
   前記開発者コンピュータ装置から前記設定データの更新を受け取る、
   ようにプログラムされている請求項１に記載のシステム。
6. 前記コンピュータシステムは更に、
   賭博場の資金が前記開発者から供給されるのか否かの告知を前記開発者コンピュータ装置に促し、
   前記賭博場の資金が前記開発者から供給されるのか否かに基づき、前記開発者への補償のレベルを設定する、
   ようにプログラムされている請求項１に記載のシステム。
7. 前記コンピュータシステムは更に、前記開発者コンピュータ装置の支払機構から前記コンピュータシステムに対応付けられたアカウントへと金銭を転送するためにリクエストを前記開発者コンピュータ装置から受け取るようにプログラムされている、請求項１に記載のシステム。
8. 前記コンピュータシステムは更に、前記ＡＰＩ証明書を含む前記アプリケーションを受け取るようにプログラムされている、請求項１に記載のシステム。
9. 前記コンピュータシステムは更に、前記アプリケーションを利用して試験的な賭けを複数実行するようにプログラムされている、請求項８に記載のシステム。
10. 前記コンピュータシステムは更に、前記ＡＰＩ証明書を含むアプリケーションの告知を公開するようにプログラムされている、請求項１に記載のシステム。
11. 前記不確定事象の前記設定データは更に、前記不確定事象が現実の金銭の賭けを対象とする旨の告知を含んでいる、請求項１に記載のシステム。
12. 前記不確定事象の前記設定データは、賭金の最大許容値を含んでおり、前記コンピュータシステムは更に、
    単位量の賭金あたりの推定利益を決定し、
    前記推定利益を前記開発者コンピュータ装置へと供給する、
    ようにプログラムされている、請求項１に記載のシステム。
13. 前記アプリケーションに対応付けられた前記不確定事象の告知は、前記不確定事象の不確定事象タイプを含み、前記コンピュータシステムは更に、前記不確定事象の前記設定データの少なくとも一部を受け取るためのテンプレートを前記開発者システムに提供するようにプログラムされている、請求項１に記載のシステム。
14. 前記不確定事象タイプはスロットマシン事象タイプであり、前記設定データの少なくとも一部を受け取るための前記テンプレートは、
    リール数を受け取るためのフィールド、
    リール上に現れる少なくとも１つのシンボルを受け取るためのフィールド、及び
    リールの少なくとも１つのペイラインを受け取るためのフィールド
    を含む、請求項１３に記載のシステム。
15. 前記不確定事象タイプはキノ事象タイプであり、前記設定データの少なくとも一部を受け取るための前記テンプレートは、少なくとも第１のチケットタイプにつき各潜在的結果を記述するデータを受け取るためのフィールドを含む、請求項１３に記載のシステム。
16. 前記不確定事象タイプはルーレット事象タイプであり、前記設定データの少なくとも一部を受け取るための前記テンプレートは、スロットの数を受け取るためのフィールドを含む、請求項１３に記載のシステム。
17. 前記設定データの少なくとも一部を受け取るための前記テンプレートは、
    第１の結果につき結果発生確率を受け取るためのフィールド、
    前記第１の結果につきペイアウト係数を受け取るためのフィールド、
    第２の結果につき結果発生確率を受け取るためのフィールド、及び
    前記第２の結果につきペイアウト係数を受け取るためのフィールド、
    を含む、請求項１３に記載のシステム。
18. 前記不確定事象からの前記設定データは、前記不確定事象についての賭博場の取り分の告知を含んでいる、請求項１３に記載のシステム。
19. ユーザの賭け行為を支援するアプリケーションを促進するための、コンピュータにより実現される方法であって、当該システムは、
    少なくとも１つのプロセッサ及び動作可能に対応付けられたメモリを備えるコンピュータシステムにより、ユーザプリケーションに対応付けられた不確定事象の設定データを前記開発者コンピュータ装置から受け取り、
    前記コンピュータシステムにより、前記設定データが少なくとも１つの所定の基準を満たすか否かを決定し、
    前記設定データが前記少なくとも１つの所定の基準を満たしている場合は、前記開発者コンピュータ装置に、前記ユーザプリケーションにより利用されるためのアプリケーションプログラムインターフェイス（ＡＰＩ）証明書を供給し、前記ＡＰＩ証明書は、前記不確定事象を決定するために前記ユーザプリケーションがＡＰＩにアクセスすることを可能とする方法。
20. 前記設定データが少なくとも１つの所定の基準を満たすか否かの決定は、前記設定データを、許容される不確定事象の設定のセットと比較することを含み、前記許容される不確定事象の設定のセットは、前記開発者ではなく前記ゲーム管理システムの実施者によって保持されるギャンブルのライセンスに関連する少なくとも１つの規制上の要件に基づいている、請求項１９に記載の方法。
21. ユーザ装置により少なくとも一部が実行されるアプリケーションと連絡する、少なくとも１つのプロセッサ及び動作可能に対応付けられたメモリを備えるコンピュータシステムを備える、コンピュータにより実現されるゲーム管理システムであって、当該システムは、
    前記アプリケーションから、前記アプリケーションに対応付けられた少なくとも１つの不確定事象が前記ゲーム管理システムによって承認されたことを示すアプリケーション認証を受け、
    前記ユーザ装置に、前記ユーザ装置のユーザを記述する情報を受け取るための認証インターフェースを供給し、
    前記認証インタフェースを介して、前記ユーザから、前記ユーザを記述する情報を受け取り、
    前記ユーザが賭けを行う資格を有するか否かを、前記ユーザを記述した情報に基づいて決定し、
    前記ユーザが賭けを行う資格を有することを条件として、前記アプリケーションから、複数の潜在的結果であって当該複数の潜在的結果の各々は確率に対応付けられている複数の潜在的結果と前記不確定事象について前記ユーザにより賭けられた賭金とを伴って不確定イベントを記述する不確定事象リクエストを受け取り、
    前記複数の確率に基づいて、前記複数の潜在的結果から前記不確定事象の結果を選択し、
    前記賭金に基づいて、前記選択された結果に対応付けられる結果金額を計算し、
    前記結果金額を、前記ユーザに対応付けられているアカウントに適用する、
    ようにプログラムされているシステム。
22. 前記ユーザが賭けを行う資格を有するか否かの決定は、前記ユーザを記述した情報を、前記ゲーム管理システムの実施者によって保持されたギャンブルのライセンスに関連する少なくとも１つの規制上の要件と比較することを含む、請求項２１に記載のシステム。
23. 前記コンピュータシステムは更に、前記結果及び前記結果金額の告知を前記ユーザ装置に送るようにプログラムされている、請求項２１に記載のシステム。
24. 前記ユーザを記述する情報は、前記ユーザの生年月日及び前記ユーザの地理的位置を含んでいる、請求項２１に記載のシステム。
25. 前記ユーザに対応付けられているアカウントへの前記結果金額の適用は、前記ユーザに対応付けられた金融口座を保持する金融機関に少なくとも１つの指示を送ることを含む、請求項２１に記載のシステム。
26. 前記不確定事象リクエストは更に、前記複数の潜在的結果のうちの少なくとも１つに対応付けられる確率を決定するための少なくとも１つのパラメータを含んでいる、請求項２１に記載のシステム。
27. 前記コンピュータシステムは更に、賭金が金銭の賭金であるか否かの告知を前記ユーザ装置に促すようにプログラムされている、請求項２１に記載のシステム。
28. 前記コンピュータシステムは更に、
    複数の潜在的結果と前記不確定事象について前記ユーザにより仮想通貨で賭けられた第１の賭金とを伴って第１の不確定事象を記述する第１の不確定事象リクエストを前記ユーザ装置から受け取り、
    複数の確率に基づいて、前記複数の潜在的結果から前記第１の不確定事象の結果を選択し、
    前記賭金に基づいて、前記選択された結果に対応付けられる、前記仮想通貨によるものである、第１の結果金額を計算し、
    前記結果金額が非ゼロであること条件として、現実の通貨を賭金とする前記不確定事象を提供するように前記ユーザ装置に促す、
    ようにプログラムされている、請求項２１に記載のシステム。
29. ユーザを記述した情報は、前記アカウントに対応付けられたログイン情報を含んでおり、前記ユーザを記述した情報に基づいた、前記ユーザが賭けを行う資格を有するか否かの決定は、前記アカウントに対応付けられた付加的な情報へのアクセスを含んでいる、請求項２１に記載のシステム。
30. 前記コンピュータシステムは更に、前記アカウントに対応付けられた前記ユーザの残高を前記ユーザ装置に供給するようにプログラムされている、請求項２１に記載のシステム。
31. 前記コンピュータシステムは更に、前記ユーザを記述する前記情報から前記ユーザの地理的位置を推定するようにプログラムされている、請求項２１に記載のシステム。
32. 前記コンピュータシステムは更に、前記ユーザが賭けを行う資格を有すると決定すると、前記アプリケーションにアクセストークンを供給するようにプログラムされている、請求項２１に記載のシステム。
33. 前記不確定事象リクエストは前記アクセストークンを含んでいる、請求項３２に記載のシステム。
34. コンピュータにより実現されるゲーム管理方法であって、前記方法は、
    ユーザ装置により少なくとも一部が実行されるアプリケーションと連絡するコンピュータシステムにより、前記アプリケーションから、前記アプリケーションに対応付けられた少なくとも１つの不確定事象が前記ゲーム管理システムによって承認されたことを示すアプリケーション認証を受け、
    前記コンピュータシステムにより、前記ユーザ装置に、前記ユーザ装置のユーザを記述する情報を受け取るための認証インターフェースを供給し、
    前記コンピュータシステムにより、前記認証インタフェースを介して、前記ユーザから、前記ユーザを記述する情報を受け取り、
    前記コンピュータシステムにより、前記ユーザが賭けを行う資格を有するか否かを、前記ユーザを記述した情報に基づいて決定し、
    前記ユーザが賭けを行う資格を有することを条件として、前記コンピュータシステムにより前記アプリケーションから、複数の潜在的結果であって当該複数の潜在的結果の各々は確率に対応付けられている複数の潜在的結果と前記不確定事象について前記ユーザにより賭けられた賭金とを伴って不確定事象を記述する不確定事象リクエストを受け取り、
    前記コンピュータシステムにより、前記複数の確率に基づいて、前記複数の潜在的結果から前記不確定事象の結果を選択し、
    前記コンピュータシステムにより、前記賭金に基づいて、前記選択された結果に対応付けられる結果金額を計算し、
    前記コンピュータシステムにより、前記結果金額を、前記ユーザに対応付けられているアカウントに適用する、
    ようにプログラムされている方法。
35. 少なくとも１つのプロセッサ及び動作可能に対応付けられたメモリを備えるコンピュータシステムを備える、ゲームアプリケーションを促進するための、コンピュータにより実現されるゲーム管理システムであって、当該システムは、
    少なくとも１名のユーザのゲームプレイを記述する複数のゲームプレイ挙動のメトリックの値を記録し、前記複数のゲームプレイ挙動のメトリックのうち少なくとも１つは、ゲームアプリケーションを介して少なくとも１名のユーザによって賭けられた賭金を記述しており、
    前記複数のゲームプレイ挙動のメトリックに基づいて、少なくとも１名のユーザの少なくとも１つのゲームプレイの選好を決定し、
    決定された前記少なくとも１名のユーザの少なくとも１つのゲームプレイの選好に基づいて、第１のユーザのゲームプレイを変更する、
    ようにプログラムされているシステム。
36. 前記ユーザのゲームプレイの変更は、
    少なくとも１つの推奨ゲームアプリケーションを、前記少なくとも１名のユーザの前記決定された少なくとも１つのゲームプレイの選好に基づいて選択すること、及び
    前記少なくとも１つの推奨ゲームアプリケーションの告知を、前記ユーザに提供すること、
    を含んでいる請求項３５に記載のシステム。
37. 前記ユーザのゲームプレイの変更は、前記少なくとも１つのゲームアプリケーションの少なくとも１つの賭けのパラメータの変更を含んでいる、請求項３５に記載のシステム。
38. 前記少なくとも１名のユーザは前記第１のユーザからなる、請求項３５に記載のシステム。
39. 前記コンピュータシステムは更に、
    前記第１のユーザを記述するデータを受け取り、
    前記第１のユーザを記述するデータに基づいて、前記少なくとも１名のユーザを選択する
    ようにプログラムされている、請求項３５に記載のシステム。
40. 前記コンピュータシステムは更に、
    前記ゲームプレイの変更後の前記第１のユーザによる少なくとも１つのゲームアプリケーションの使用を記述するデータを記録し、
    前記ゲームプレイの変更後の前記第１のユーザによる少なくとも１つのゲームアプリケーションの使用を記述する記録された前記データを参照して、前記少なくとも１つのゲームプレイの選好の新しい値を決定する、
    ようにプログラムされている、請求項３５に記載のシステム。
41. 前記少なくとも１つのゲームプレイの選好の決定は、
    前記少なくとも１名のユーザのリスク許容度の計算、及び
    前記複数のゲームプレイ挙動のメトリックの知覚された効用の計算、
    を含んでいる、請求項３５に記載のシステム。
42. 前記複数のゲームプレイ挙動のメトリックの値の記録は、前記少なくとも１名のユーザにより選択された少なくとも１つのゲームアプリケーションにより許容された最大の賭金の値を記録することを含んでいる、請求項３５に記載のシステム。
43. 前記複数のゲームプレイ挙動のメトリックの値の記録は、前記少なくとも１名のユーザにより選択された少なくとも１つのゲームアプリケーションにおける、賭け行為と前記賭けの結果発生との間の経過時間の値を記録することを含んでいる、請求項３５に記載のシステム。
44. 前記複数のゲームプレイ挙動のメトリックの値の記録は、前記少なくとも１名のユーザにより選択された少なくとも１つのゲームアプリケーションにおいて賭けに勝つ確率の値及び当該掛金の払い出し額を記録することを含んでいる、請求項３５に記載のシステム。
45. 前記複数のゲームプレイ挙動のメトリックの値の記録は、前記少なくとも１名のユーザにより選択された少なくとも１つのゲームアプリケーションにおいて少なくとも１つの賭けの結果に対して前記少なくとも１名のユーザが有する支配の程度についての値を記録することを含んでいる、請求項３５に記載のシステム。
46. 前記複数のゲームプレイ挙動のメトリックの値の記録は、少なくとも１名のユーザの損失許容度の値を記録することを含んでいる、請求項３５に記載のシステム。
47. 前記ゲームアプリケーションは複数の決定ノードにより記述され、前記複数のゲームプレイ挙動のメトリックの値の記録は、前記少なくとも１名のユーザにより選択された少なくとも１つのゲームアプリケーションにおける決定ノードの頻度についての値を記録することを含んでいる、請求項３５に記載のシステム。
48. 前記ゲームアプリケーションは複数の決定ノードにより記述され、前記複数のゲームプレイ挙動のメトリックの値の記録は、前記少なくとも１名のユーザにより選択された少なくとも１つのゲームアプリケーションにおいて、前記少なくとも１名のユーザが遭遇し前記少なくとも１名のユーザが賭けを行うことを可能とする決定ノードの量を記録することを含んでいる、請求項３５に記載のシステム。
49. 前記コンピュータシステムは更に、前記複数のゲームプレイ挙動のメトリックの値が、前記第１のユーザを記述する値のしきい値を含んでいるか否かを決定するようにプログラムされている、請求項３５に記載のシステム。
50. 前記コンピュータシステムは更に、前記複数のゲームプレイ挙動のメトリックの値が、前記第１のユーザを記述する値のしきい値を含んでいることを条件として、
    前記第１のユーザの少なくとも１つのゲームプレイの選好を決定し、
    前記第１のユーザの前記決定された少なくとも１つのゲームプレイの選好に基づいて、前記第１のユーザのゲームプレイを変更する、
    ようにプログラムされている、請求項４９に記載のシステム。
51. ゲームアプリケーションを促進するための、コンピュータにより実現される方法であって、当該方法は、
    少なくとも１つのプロセッサ及び動作可能に対応付けられたメモリを備えるコンピュータシステムにより、少なくとも１名のユーザのゲームプレイを記述する複数のゲームプレイ挙動のメトリックの値であって、当該複数のゲームプレイ挙動のメトリックのうち少なくとも１つは、ゲームアプリケーションを介して前記少なくとも１名のユーザによって賭けられた賭金を記述するメトリックの値を記録し、
    前記複数のゲームプレイ挙動のメトリックに基づいて、前記コンピュータシステムにより、前記少なくとも１名のユーザの前記決定された少なくとも１つのゲームプレイの選好を決定し、
    前記コンピュータシステムにより、前記少なくとも１名のユーザの少なくとも１つのゲームプレイの選好に基づいて、第１のユーザのゲームプレイを変更する、
    ようにプログラムされている方法。

Images