(57)【要約】  （ｉ）ユーザによって購入されたチケットを表すデータを生成することであって、前記データは、各チケットのための、１つ以上の変数のそれぞれに対する数値と、チケットがライブかデッドかを示すステータスインジケータとを含む、ことと、（ｉｉ）１つ以上の変数のうちの少なくとも１つのための数値又は数値の範囲に基づいて、ライブチケットのグループを選択することと、（ｉｉｉ）選択されたグループ内の各チケットに対して、ステータスインジケータをデッドに設定することと、（ｉｖ）ライブチケットの１つ以上の閾値数が達成されるか、及び／又は、たった１つのライブチケットが残るまで、グループ内のライブチケットの数を徐々に減少させるよう、ステップ（ｉｉ）及び（ｉｉｉ）を繰り返すことを含む、ロッタリーの当選者を決定するコンピュータで実装される方法が開示される。
2016529587.tif 000002
【特許請求の範囲】
【請求項１】
ロッタリーの当選者を決定するコンピュータで実装される方法であって、
（ｉ）ユーザによって購入されたチケットを表すデータを生成することであって、前記データは、各チケットのための、１つ以上の変数のそれぞれに対する数値と、前記チケットがライブかデッドかを示すステータスインジケータとを含む、ことと、
（ｉｉ）前記１つ以上の変数のうちの少なくとも１つのための数値又は数値の範囲に基づいて、ライブチケットのグループを選択することと、
（ｉｉｉ）前記選択されたグループ内の各チケットに対して、前記ステータスインジケータをデッドに設定することと、
（ｉｖ）ライブチケットの１つ以上の閾値数が達成されるか、及び／又は、たった１つのライブチケットが残るまで、グループ内のライブチケットの数を徐々に減少させるよう、ステップ（ｉｉ）及び（ｉｉｉ）を繰り返すことと、
を含む方法。
【請求項２】
前記変数は、カテゴリー変数を含む、請求項１に記載のコンピュータで実装される方法。
【請求項３】
各チケットのために、前記変数の前記数値から構造化チケット番号を生成することを含む、請求項１又は請求項２に記載のコンピュータで実装される方法。
【請求項４】
１つ以上のユーザ装置に、ステップ（ｉｉ）において選択されたライブチケットの前記グループを表すデータを伝送することを含む、請求項１〜３の何れか一項に記載のコンピュータで実装される方法。
【請求項５】
それぞれの前記ユーザ装置上で、ライブチケットの前記選択されたグループを表す前記データを処理することを含む、請求項４に記載のコンピュータで実装される方法。
【請求項６】
前記ユーザ装置の前記ユーザによって保持されるチケットの構造化チケット番号を表すデータを取得することと、前記構造化チケット番号から、前記チケットが前記選択されたグループに属するかどうかを判断することと、前記チケットが前記選択されたグループに属する場合、前記ユーザ装置のディスプレイを更新することとを含む、請求項５に記載のコンピュータで実装される方法。
【請求項７】
前記１つ以上の閾値の第１の閾値に到達した時に、各ライブチケットの中のシェアに対応するシェアデータを生成することを含む、請求項１〜６の何れか一項に記載のコンピュータで実装される方法。
【請求項８】
前記シェアデータは、ユーザからのゼロ以上の入札に対応する入札データを含む、請求項７に記載のコンピュータで実装される方法。
【請求項９】
シェアに対して１人以上のユーザから入札データを受信することを含む、請求項８に記載のコンピュータで実装される方法。
【請求項１０】
前記１人以上のユーザは、ユーザのシンジケートを含む、請求項９に記載のコンピュータで実装される方法。
【請求項１１】
ステップ（ｉｉ）及び（ｉｉｉ）は、開始時間後、所定の間隔で実施される、請求項１〜１０の何れか一項に記載のコンピュータで実装される方法。
【請求項１２】
前記１つ以上の閾値のうちの少なくとも１つの賞金閾値に達した後に、ユーザに賞金を支払うことを含む、請求項１〜１１の何れか一項に記載のコンピュータで実装される方法。
【請求項１３】
前記少なくとも１つの賞金閾値は、少なくとも１つの残念賞閾値を含み、１つ以上の残念賞は、前記残念賞閾値に達した時に、１つ以上のデッドチケットに関連するユーザに支払われる、請求項１２に記載のコンピュータで実装される方法。
【請求項１４】
前記残念賞閾値は、ライブチケットの数の徐々に進行する減少のうちの１つ以上の後のライブチケットの数に対応する、請求項１３に記載のコンピュータで実装される方法。
【請求項１５】
１つ以上のライブチケットに関連する少なくとも何人かのユーザのために、それぞれの前記ユーザのためのチケットデータを含むユーザページを生成することを含む、請求項１〜１４の何れか一項に記載のコンピュータで実装される方法。
【請求項１６】
前記少なくとも何人かのユーザは、ライブチケットの第２の閾値数が達成された場合のライブチケットに関連するユーザである、請求項１５に記載のコンピュータで実装される方法。
【請求項１７】
前記第２の閾値は、前記第１の閾値と同じである、請求項２又はそれに従属する何れかの請求項に追加される場合に請求項１６に記載のコンピュータで実装される方法。
【請求項１８】
前記ユーザから受信した内容を前記ユーザページに入力することを含む、請求項１６又は請求項１７に記載のコンピュータで実装される方法。
【請求項１９】
２人のユーザ間の法的合意を表す契約データを生成することを含む、請求項１〜１８の何れか一項に記載のコンピュータで実装される方法。
【請求項２０】
前記契約データは、契約有効性フラグを含む、請求項１９に記載のコンピュータで実装される方法。
【請求項２１】
前記ユーザのうちの１人が前記ロッタリーの前記当選者ではない場合、前記契約有効性フラグを偽に設定することを含む、請求項２０に記載のコンピュータで実装される方法。
【請求項２２】
請求項１〜２１の何れか一項に記載の方法を実行するよう構成される少なくとも１つのコンピュータプロセッサを含む、ロッタリーの当選者を決定するためのシステム。
【請求項２３】
ロッタリーの当選者を決定するためのシステムであって、
ユーザによって購入されたチケットを表すデータを生成する手段であって、前記データは、各チケットのための、１つ以上の変数のそれぞれに対する数値と、前記チケットがライブかデッドかを示すステータスインジケータとを含む、手段と、
繰り返し、
前記１つ以上の変数のうちの少なくとも１つのための数値又は数値の範囲に基づいて、ライブチケットのグループを選択し、そして、
前記選択されたグループ内の各チケットに対して、前記ステータスインジケータをデッドに設定し、
それによって、ライブチケットの１つ以上の閾値数が達成されるか、及び／又は、たった１つのライブチケットが残るまで、グループ内のライブチケットの数を徐々に減少させる、手段と、
を含むシステム。
【請求項２４】
前記１つ以上の閾値の第１の閾値に到達した時に、各ライブチケットの中のシェアに対応するシェアデータを生成する手段を含む、請求項２３に記載のシステム。
【請求項２５】
前記シェアデータは、ユーザからのゼロ以上の入札に対応する入札データを含む、請求項２４に記載のシステム。
【請求項２６】
シェアに対して１人以上のユーザから入札データを受信する手段を含む、請求項２５に記載のシステム。
【請求項２７】
前記１人以上のユーザは、ユーザのシンジケートを含む、請求項２６に記載のシステム。
【請求項２８】
実行された場合に、１つ以上のコンピュータプロセッサに請求項１〜２１の何れか一項に記載の方法を実行させるプログラム命令を含む、ロッタリーの当選者を決定するためのコンピュータプログラム製品。
【請求項２９】
請求項２８に記載の前記コンピュータプログラム製品を含む、コンピュータ読取可能データ記憶装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ロッタリーの当選者を決定するための方法及びシステムに関する。
【背景技術】
【０００２】
賭博の管轄官庁等の団体が、ロッタリー等の確率のゲームを実施することは公知である。ロッタリーの既知の一形態において、参加者は、チケットを購入し、２桁の数字の利用可能な組から数字の部分集合を選択する（又は、「クイックピック」システムにおいて、彼らのためにランダムに選択される）。１人以上の当選者が、次いで、参加者のチケットに割り当てられた数字に対して一致する可能性のある基準の数字の部分集合をランダムに抽選することによって、決定される。１つ以上の当選番号（又は数字の組）がランダムに抽選される他の種類のロッタリーも、公知である。
【０００３】
ランダム抽選が「ライブ」で、例えば、テレビジョンスタジオで実施され、結果が視聴者に放送されることは普通である。参加者は、それぞれが異なる数字の組と関連する多数のチケットを購入する場合があるため、参加者に対して、彼らのチケットが当選したか否かは、ランダムな数字が抽選されるため、直ぐに明らかにならないかもしれない。更に、ライブ抽選は、実際にチケットを購入した人々対してのみ興味を保持し、より広範囲の視聴者にとってはそうでもない。
【０００４】
参加者及び／又はより広範囲の大衆に対して向上したエンターテイメントを提供するロッタリーを実施する方法を提供するか、又は、少なくとも有用な代替方法を提供することが望ましい。
【発明の概要】
【課題を解決するための手段】
【０００５】
本発明の一態様により、ロッタリーの当選者を決定するコンピュータで実装される方法が提供され、
（ｉ）ユーザによって購入されたチケットに関するデータを生成することであって、前記データは、各チケットのための、１つ以上の変数のそれぞれに対する数値と、チケットがライブかデッドかを示すステータスインジケータとを含む、ことと、
（ｉｉ）１つ以上の変数のうちの少なくとも１つのための数値又は数値の範囲に基づいて、ライブチケットのグループを選択することと、
（ｉｉｉ）選択されたグループ内の各チケットに対して、ステータスインジケータをデッドに設定することと、
（ｉｖ）ライブチケットの１つ以上の閾値数が達成されるか、及び／又は、たった１つのライブチケットが残るまで、グループ内のライブチケットの数を徐々に減少させるよう、ステップ（ｉｉ）及び（ｉｉｉ）を繰り返すことと、を含んでいる。
【０００６】
本発明の別の態様において、本発明の第１の態様の方法を実行するよう構成される少なくとも１つのコンピュータプロセッサを含む、ロッタリーの当選者を決定するためのシステムが提供される。
【０００７】
第３の態様において、本発明は、ロッタリーの当選者を決定するためのシステムを提供し、
ユーザによって購入されたチケットを表すデータを生成する手段であって、前記データは、各チケットのための、１つ以上の変数のそれぞれに対する数値と、チケットがライブかデッドかを示すステータスインジケータとを含む、手段と、
繰り返し、
１つ以上の変数のうちの少なくとも１つのための数値又は数値の範囲に基づいて、ライブチケットのグループを選択し、そして、
選択されたグループ内の各チケットに対して、前記ステータスインジケータをデッドに設定し、
それによって、ライブチケットの１つ以上の閾値数が達成されるか、及び／又は、たった１つのライブチケットが残るまで、グループ内のライブチケットの数を徐々に減少させる、手段とを含んでいる。
【０００８】
本発明の第４の態様において、実行された場合に、１つ以上のコンピュータプロセッサに本発明の第１の態様の方法を実行させるプログラム命令を含む、ロッタリーの当選者を決定するためのコンピュータプログラム製品が提供される。
【０００９】
第５の態様において、本発明は、本発明の第４の態様のコンピュータプログラム製品を含む、コンピュータ読取可能データ記憶装置を提供する。
【００１０】
本発明の特定の実施形態を、非制限的な実施例のみによって、以下の添付図面を参照して以降で説明する。
【図面の簡単な説明】
【００１１】
【図１】ロッタリーの当選者を決定するためのシステムのブロック図である。
【図２】図１のシステムと共に使用するための例示的なコンピュータシステムのブロック図である。
【図３−８】図１のシステムによって実装される例示的なプロセスのステップを示すフロー図である。
【発明を実施するための形態】
【００１２】
本発明の実施形態は、ソーシャルメディア、シェア取引、融合技術、及び、ブランド及び著名人創出及び推薦を組み込んでもよいオンラインロッタリーを提供する。オンラインロッタリーは、テレビ上及び／又はインターネットを介して放送されるゲーム番組と連携して実施されてもよい。
【００１３】
一実施形態において、ロッタリーは、エントリの初期プールからたった１人の１等賞の当選者を決定するために、所定期間、例えば、６週間、放映される。初期プールは、任意の大きさに作成されてもよい。以下の実施例において、初期プールは、１，０００，０００エントリ（ライブチケット）を備えている。
【００１４】
懸賞の最初の３つの段階において、ライブチケットの数は、予選の３つの段階で１，０００，０００から８００（例えば）にまで減少される。更なる予選が次いで実施され、１等賞の当選者が、所定のサイクル（例えば、６週間のサイクル）の終わりに決定される。
【００１５】
当選チケットは、特定の数字をランダムに抽選することによって（例えば、ライブチケットの初期プールに対応する数字の組から）決定されない。また、多くの種類のロトゲームにおいて見られるような、一連の数字の抽選、及び、その後の個々のチケットに対する一致もない。本発明者らは、これらの２つのアプローチのどちらも、十分に迅速で、効率的な方法で視聴者に対して情報を提供できないと考えている。
【００１６】
本発明は、少なくとも幾つかのその実施形態において、ロッタリーの運営者（又は関係する団体）から、テレビ、ネットワーク接続上で運営者のシステムに接続されるコンピュータ、セットトップボックス、又は携帯電話装置等の遠隔装置によって接続される視聴者への更新されたチケットステータスデータの迅速な伝送を可能にするために特に設計されている。
【００１７】
システム概要
最初に図１を参照すると、ロッタリーの当選者を決定するためのシステム１００が示されている。システムは、インターネット等のデータ通信ネットワーク１１２を介してクライアントシステム１１５と通信するコンピュータシステム（サーバ）１１０を含んでいる。更に、同様のクライアントシステム１２０も、同時にサーバ１１０と通信してもよい。サーバ１１０は、本明細書中に説明するプロセス全体の制御及び調整を担当し、プロセスの一部を取り扱う様々な他のコンポーネント（ハードウェア及び／又はソフトウェア）と通信してもよい。
【００１８】
システム１００は、インターネット１１２上で放送するための放送源１３５からビデオ及び音声データを受信するテレビストリーミングサーバ１３０を含んでいる。放送源１３５は、無線周波送信機又はテレビスタジオから発信される信号を伝送する送信機等のアナログ又はデジタル源であってもよい。代替として、サーバ１１０は、それ自体、例えば、テレビスタジオから受信される第１の受信及び処理信号を有する、ストリーミングサーバ１３０のためのビデオ及び音声データの源であってもよい。幾つかの実施形態において、ストリーミングサーバ１３０によって伝送されるデータはまた、サーバ１１０と通信するデータベース１６２、１６４からのデータも組み込んでもよい。テレビストリーミングサーバ１３０は、ビデオ及び音声データをストリームに変換する１つ以上のソフトウェアモジュールを実行する標準のコンピュータシステムであってもよく、又は、ＭａｔｒｉｘＣａｓｔ  Ｔｅｃｈｎｏｌｏｇｉｅｓ，  Ｉｎｃ．（カリフォルニア）のＩＭＸ  ｉ２４１０  Ｌｉｖｅ  ＴＶ  ＭａｔｒｉｘＣａｓｔストリーミングサーバ等の専用ストリーミング装置と通信する標準のコンピュータシステムであってもよい。
【００１９】
サーバ１１０は、データベースサーバ１６０と通信し、順に、ユーザアカウント、チケット、及び、後に説明するようなチケットの中でシェアの取引に関するデータを含む、システムによって用いられるデータを格納するデータベース１６２、１６４と通信する。また、サーバ１１０がデータベース１６２、１６４と直接通信してもよいことも正しく理解されるであろう。
【００２０】
システム１００内に更に含まれるのは、サーバ１１０と通信するシェア取引サーバ１７０である。
【００２１】
説明する実施形態において、サーバ１１０は、３２ビット又は６４ビットＩｎｔｅｌアーキテクチャに基づく市販のパーソナルコンピュータ又はサーバコンピュータシステム等の標準のコンピュータシステムであり、システム１００によって実行又は実施されるプロセス及び／又は方法は、図２に示すような、コンピュータシステム１１０と関連する不揮発性（例えば、ハードディスク）コンピュータ読取可能記憶装置２０２に格納される１つ以上のソフトウェアコンポーネント又はモジュール１５０のプログラミング命令の形で実装される。少なくとも一部のソフトウェアモジュール１５０は、代替として、特定用途向け集積回路（ＡＳＩＣ）及び／又はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）等の１つ以上の専用ハードウェアコンポーネントとして実装されてもよい。
【００２２】
ソフトウェアモジュール１５０は、少なくとも以下の、参加者登録モジュール、ユーザ認証モジュール、チケット販売モジュール、チケット予選モジュール、及びシェア取引モジュールを含んでいる。
【００２３】
コンピュータシステム１１０は、バス２１４によって全て相互接続される以下の標準の市販コンピュータコンポーネント：ランダムアクセスメモリ（ＲＡＭ）２０４、少なくとも１つのコンピュータプロセッサ２０６、及び外部コンピュータインタフェースのうちの少なくとも１つ以上を含んでいる。外部コンピュータインタフェースは、コンピュータシステム１１０をインターネット１１２等のデータ通信ネットワークに接続するネットワークインタフェースコネクタ（ＮＩＣ）２１０を含んでいる。
【００２４】
コンピュータシステム１１０は、オペレーティングシステム（ＯＳ）１２４（例えば、Ｌｉｎｕｘ（登録商標）又はＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標））；ｗｅｂサーバソフトウェア１２８（例えば、ｈｔｔｐ：／／ｗｗｗ．ａｐａｃｈｅ．ｏｒｇで入手可能なＡｐａｃｈｅ）；スクリプト言語モジュール１３１（例えば、ｈｔｔｐ：／／ｗｗｗ．ｐｈｐ．ｎｅｔで入手可能なｐｅｒｓｏｎａｌ  ｈｏｍｅ  ｐａｇｅ即ちＰＨＰ、又はＭｉｃｒｏｓｏｆｔ  ＡＳＰ）；データをＳＱＬデータベース１６２、１６４に格納し、それから取得／アクセスすることを可能にする構造化照会言語（ＳＱＬ）モジュール１３２（例えば、ｈｔｔｐ：／／ｗｗｗ．ｍｙｓｑｌ．ｃｏｍから入手可能なＭｙＳＱＬ）を含む、複数の標準ソフトウェアモジュールを含んでいる。
【００２５】
ｗｅｂサーバ１２８、スクリプト言語１３１、及びＳＱＬモジュール１３２は共に、コンピュータシステム１１０に、標準ｗｅｂブラウザソフトウェアを備える標準演算装置を持つインターネット１１２のユーザがコンピュータシステム１１０にアクセスし、特に、データベース１６２、１６４にデータを提供し、そこからデータを取得することを可能にする一般能力を提供する。システム１１０によってかかるユーザに提供される特定の機能は、プロセス４００、５００、６００、７００を実装する１つ以上のソフトウェアモジュール１５０を含む、ｗｅｂサーバ１２８によってアクセス可能なスクリプトと、また、マークアップ言語（例えば、ＨＴＭＬ、ＸＭＬ）スクリプト、ＰＨＰ（又はＡＳＰ）、及び／又はＣＧＩスクリプト、画像ファイル、スタイルシート、及び同様のものを含む、何れかの他のスクリプト及び支援データ１３４によって提供されることは、当該技術に精通する者によって理解されるであろう。
【００２６】
クライアントシステム１１５は、オペレーティングシステム（ＯＳ）１２２及びｗｅｂブラウザ１１７を含む標準のソフトウェアモジュールを含んでいる。クライアントシステム１１５はまた、サーバ１１０と通信するためのクライアントアプリケーションモジュール１１８も含んでもよい。
【００２７】
プロセス概要
ロッタリーの当選者を決定するためのコンピュータ化されたプロセス３００の概要を、図３に示す。
【００２８】
プロセスは、ステップ４００において、システムのユーザ（参加者）に対して登録を許可する。チケットは、ステップ５００において、登録された参加者に対して販売される（一方で、新規参加者の進行中の登録も許可する）。所定の時点で、例えば、使用可能なチケットの全てが販売された場合、又は、１回目のランダム抽選の開始前の定刻時（何れか早い方）で、チケットの販売は終了する。
【００２９】
次いで、一連の予選がステップ６００において実施されて、以下でより詳細に説明するように、予選敗退しない（ライブ）チケットの閾値の数が達成されるまで、チケットのグループを、購入されたチケットの初期プールから徐々に予選敗退させる。この閾値の数を達成した時点で、「ライブ交換」プロセスが開始され（ステップ７００）、それによって、残りのライブチケットの所有者は、彼らのチケットの中のシェアに対して登録された参加者からの入札を受け入れてもよい。シェアは、参加者の間で取引されてもよい。
【００３０】
「ライブ交換」プロセスは、所定の時間で行われてもよく、更なる予選を組み入れてもよい（ステップ１０００）。
【００３１】
残りのライブチケットの更なる閾値の数において、又は、所定の時間において、「ライブ交換」プロセス７００は、終了し、最終予選段階１１００が、１等賞の当選者を決定するために実施される。例えば、最終予選１１００は、残りのライブチケットからたった１つの当選チケットのランダム選択を伴ってもよく、又は、ただ１つの当選チケットが残るまで、残りのライブチケットの１回につき１つ又は１回につき２、３の予選敗退を伴ってもよい。最終予選１１００は、「ライブ」で撮影され、ストリーミングサーバ１３０を介して、及び／又は、ｗｅｂサーバ１２８によって放送されてもよい。
【００３２】
プロセス詳細
図４に示すような、プロセス３００のステップ４００において、（モジュール１５０の）参加者登録モジュールは、参加者のシステム１１５のｗｅｂブラウザ１１７に対して、一連のデータエントリフィールドを含むｗｅｂページを供給することによって、参加者の登録を提供する。
【００３３】
ステップ４１０において、参加者登録モジュールは、データエントリフィールドに入力された参加者の詳細を受信し、次いで、年齢確認ステップ４２０を実行して、参加者がロッタリー及び同様のものに参加するための法定年齢要件（例えば、１８歳以上）を満たしていることを確認する。これは、一例として、彼らが法定年齢であることを確認するために、ボックスをチェックするか、ボタンをクリックするよう参加者に対するプロンプトを含むｗｅｂページを供給することと同じくらい簡単であってもよい。
【００３４】
参加者登録モジュールは、参加者の詳細をユーザデータベース１６２に格納する（ステップ４３０）。格納された参加者の詳細は、ユーザ名、暗号化されたパスワード情報、連絡先等のユーザの個人的詳細、及び、ユーザのパスワードを再設定するための確認用質問／答えを含んでもよい。また、年齢確認情報（例えば、誕生日及びユーザが年齢要件を確認したことを示すフラグ）が、格納されてもよい。
【００３５】
通常、登録プロセス４００は、賞金の払い戻し、及び／又は、後で説明するような、ライブ交換プロセス７００の間にライブチケットの中でシェアに対する資金の支払いを可能にするよう、参加者のための銀行取引詳細を記録するステップ（図示せず）を含んでいる。銀行取引詳細は、必要に応じて決済を行うために、支払い処理サーバ１２５によって用いられてもよい。
【００３６】
一旦ユーザが登録されると、プロセス４００は、ユーザのシステム１１５上にカスタムソフトウェアモジュール（プレーヤソフトウェア）１１８をインストールするようユーザにプロンプトを出してもよい（ステップ４４０）。代替として、プレーヤソフトウェアは、ブラウザベース、例えば、ｗｅｂブラウザ１１７によって実行可能又は解釈可能なｊａｖａｓｃｒｉｐｔ又は同様のもので実装されてもよい。
【００３７】
参加者登録プロセス４００は、プロセス３００全体の間のいつでも、例えば、チケットの販売が開始される前又は後の何れかで、及び、最初の予選（ステップ６００）が開始されるまで、実行されてもよい。
【００３８】
ここで図５を参照すると、チケット販売プロセス５００のステップが示されている。チケット販売モジュール実行プロセス５００は、最初に、参加者が登録されているかどうかをチェックし、そうでなければ、参加者登録プロセス４００に分岐させる。以前に登録された参加者に対しては、チケット購入ページが生成され、参加者のｗｅｂブラウザ１１７に送信される（ステップ５２０）。参加者は、希望するチケットの数、及び支払い詳細（クレジットカード詳細等）を選択する。また、支払い詳細は、参加者にとってチケット購入毎にそれらを入力しないで済むように、参加者詳細の一部としてユーザデータベース１６２内に格納されてもよいことも、正しく理解されるであろう。
【００３９】
チケットの数及び支払い詳細は、ステップ５３０においてチケット販売モジュールによって受信され、支払いは次いで、例えば、支払い詳細を表すデータを、インターネット接続１１２上で、当該技術において公知の方法で、第三者の支払い処理システム１２５と通信する支払い処理モジュールに伝送することによって処理される（ステップ５４０）。
【００４０】
支払い処理の成功時、チケット販売モジュールは次いで、一意のチケット番号をそれぞれ購入されたチケットに対して割り当てる（ステップ５５０）。プロセス５００は、参加者に対して、後で説明するように各チケットの詳細を思い出すことを容易にするため、各チケットのための名前を選択するようオプションを提供してもよい。チケット名も一意であるべきであり、これは、参加者の名前選択（単数又は複数）を受信した時にデータベース１６２に照会することによって、プロセス５００によってチェックされてもよい。プロセス５００はまた、参加者の代わりに一意のチケット名、例えば、参加者のユーザ名とランダムな数字及び、任意選択的に、販売日又は関連する抽選日との組み合わせを割り当ててもよい。
【００４１】
ステップ５６０において、チケット販売モジュールは、多くの変数のための数値を各購入チケットに割り当てる。変数は、カテゴリー変数、又は、カテゴリー及び数値（不連続又は連続）変数の混合であってもよい。一実施例において、第１の変数は「色」である一方で、４つの更なる変数は、大小様々の数値グループ識別子である。変数は、以下で説明するように、ライブチケットを徐々に予選敗退させるために用いることができるグループ識別子の階層を定義する。変数のうちの１つ以上は、「隠し」変数であってもよく−即ち、それらの値は、サーバシステム１１０に既知であり、データベース１６２に格納されているが、参加者には見えない。
【００４２】
一実施例において、利用可能なチケットの総数は１，０００，０００であり、変数／グループ識別子は、以下の表１に示されているようなものである。この実施例における各変数は、グループを表す１、２、又は３桁の数字である。
【００４３】
【表１】
2016529587.tif 000003
【００４４】
構造化チケット番号は、例えば、数値を文字に変換し、文字を単一の文字列に連結することによって、上記変数の値から生成されてもよい。そのため、例えば、色＝３、グループ化レベル１＝７７、グループ化レベル２＝２、グループ化レベル３＝９、及びグループ化レベル４＝５を有するチケットに対して、構造化チケット番号は「３０７７２０９５」となる。ハイフン等の区切り文字が、読み易さのために構造化チケット番号に導入されてもよく、例えば、「３−０７７−２−０９−５」であってもよい。
【００４５】
チェックディジットは、チケット番号のための認証対策として機能を果たし、構造化チケット番号のそれぞれの桁に関する、システム１１０のみが知っている一連の数学的演算を実行することによって生成されてもよい。例えば、桁の合計は、７を乗じ、結果を３１で割り、そして、端数部分の２桁と共に小数点以下第２位で切り捨てした除算の結果を、次いで、チェックディジットとして使用してもよい。構造化チケット番号とチェックディジットとの間の変換は、例えば、特定の一連の演算が、ロッタリーの特定の抽選、特定の購入時間、等と関連するように、定期的に変更されてもよい。チェックディジットは、それによって、入力されたチケット番号が有効か否かを検出するために用いられてもよい。
【００４６】
ステップ５６０は、参加者が各チケットの「色」を、例えば、８つの利用可能な色から選択することを可能にしてもよい。代替として、参加者は、色がランダムに割り当てられるよう要求してもよい。どちらの場合においても、チケット販売モジュールは、割り当てられた色名を色番号（１から８の間）にマッピングし、各色に割り当てられたチケットの番号の表を維持する。
【００４７】
分類の第１のレベル、色は、従って、チケットの初期プールを、最大１２５，０００枚のチケットの８つのロットに分割する（１，０００，０００枚のチケット全てが販売されたと仮定する）。
【００４８】
表１においてグループ化レベル１と呼ばれる分類の第２のレベルにおいて、各チケットは、１から１２５までの間の数字を割り当てられてもよく、即ち、チケットはここで、各色内に最大１，０００のロットにグループ化される。グループ化レベル１変数の値は、購入時に参加者によって選択されてもよく、又は、チケット販売モジュールによってランダムに割り当てられてもよい。同様の考え方は、グループ化レベル２、３、及び４に適用されるが、これらが隠し変数である場合は、当然、それらは、参加者に対して、それらの数値を選択するオプションであるべきではない。
【００４９】
色の間で、及び、他の分類のレベルの間でチケットの均等配分を維持するのが好ましい。万一非均等配分があれば、再均衡化ステップが、異なる色、レベル１グループ等の間でチケットを再分配するよう適用されてもよい。再均衡化は、チケット販売の終了時に適用されてもよい。また、チケット販売が行われている間に、例えば、グループ間のチケットの配分を定期的に監視し、配分がグループのうちの１つ以上に偏っているかどうかを検出し、これらのグループから少ない比率のグループにチケットを再割り当てすることによって、それが適用されてもよい。
【００５０】
プロセス５００は、全ての利用可能なチケットが販売されるまで、又は、所定の終了時間まで、例えば、最初の予選の開始２４時間前まで、引き続きチケットを販売してもよい。
【００５１】
図には示されていないプロセスにおいて、チケット販売モジュールは、ｗｅｂサーバ１２８に、ユーザによるリクエスト時に、その名前、構造化チケット番号、色、購入日、及び同様のものを含む、そのユーザによって購入された各チケットの詳細を包含する要約ｗｅｂページを生成及び供給させてもよい。要約ｗｅｂページは、ユーザのリクエスト時に、生成されるか、生成可能な、各チケットのための更に個別のｗｅｂページのためのＵＲＬを含んでもよい。
【００５２】
図６は、所望の閾値に達するまで、初期プールからチケットを徐々に予選敗退させるために（モジュール１５０の）チケット予選モジュールによって実行される実施例のプロセス６００を示している。この実施例において、所望の閾値は、後で説明するようなプロセス３００の「ライブ交換」部分７００に入力される閾値チケット数である。例えば、閾値の数は、（１，０００，０００枚のチケットの初期プールのうちの）８００枚のチケットであってもよい。
【００５３】
ステップ６１０において、チケット予選モジュールは、予選敗退させるチケットの１つ以上のグループを選択する。例えば、最初の予選において、「紫」色がプロセス６００によってランダムに選択される。全ての「紫」チケットのリストは、データベース１６２から取得される（ステップ６２０）。各紫チケットに対するステータスインジケータは次いで、「デッド」に設定され、データベース１６２がそれに従って更新される（ステップ６３０）。
【００５４】
通常、チケット予選モジュールは、１つ以上のユーザ装置（例えば、クライアントマシン１１５）に、ステップ６１０において選択されたライブチケットのグループを表すデータを伝送する。それぞれの前記ユーザ装置上で、ライブチケットの選択されたグループを表すデータが処理され、ユーザ装置のユーザによって保持されるチケットの構造化チケット番号を表すデータが取得される。ユーザ装置は次いで、構造化チケット番号から、チケットが選択されたグループに属するかどうかを判断し、チケットが選択されたグループに属していれば、ユーザ装置のディスプレイを更新する。
【００５５】
例えば、予選敗退したグループの通知は、ｗｅｂサーバ１２８によって書き込まれてもよく（ステップ６４０）、また、ストリーミングサーバ１３０によって伝送されるデータストリーム内に組み込まれてもよい。参加者がサインインした場合、彼らのチケットのそれぞれのステータスを示すｗｅｂページのリフレッシュにより、更新されたページが配信されて、彼らが保持する全ての「紫」チケットが現在デッドであることを参加者に表示してもよい。例えば、各ライブチケットのステータスは、心臓の鼓動を表す絶えず動く正弦波（音を含む）によって表されてもよい。予選敗退チケットは、連続的なビープ音を伴う医療用の水平線（即ち、脈拍が無い）によって表される。
【００５６】
プロセス６００は次いで、たった１つの色が残るまで、更に色を予選敗退させるそれぞれの更なる予選を継続してもよい。予選は、一定の間隔で、例えば、毎晩１回、予選が、例えば、テレビストリーミングサーバ１３０を介して、及び／又は、標準のテレビ放送技術によって、毎晩同じ時間に同時に放送することができるように行われてもよい。
【００５７】
予選の第１の段階の終了時、予選敗退しなかった色のみに属する（最大）１２５，０００枚のチケットが残る。
【００５８】
予選の第２の段階において、上で説明したような予選敗退させるための色の選択と同様の方法で、グループ化レベル１のうちの１２５グループからグループのランダム選択がチケット予選モジュールによって行われ（ステップ６１０）、それらのグループに属するチケットが取得され（ステップ６２０）、それらのチケットのステータスが「デッド」に更新される（ステップ６３０）。プロセスは、第２の段階の終了時に、１，０００枚のチケットが残るまで続けられる。
【００５９】
第３の段階において、グループ化レベル２から５グループのうちの１つのランダム選択が、チケット予選モジュールによって行われる。これにより、（上で説明したようなステップ６１０、６２０、及び６３０を介して）選択されたグループが予選敗退し、８００枚のライブチケットが残る。チェックが次いで行われて（ステップ６５０）、これが「ライブ交換」閾値であるかどうかを判断し、もしそうであれば、ライブ交換プロセス７００が次いで始まる。
【００６０】
ライブ交換
ライブ交換プロセス７００の開始において、８００枚のライブチケットは、（モジュール１５０の）シェア取引モジュールによってシェアの等しい数、例えば、チケット当たり１００シェアを割り当てられる。各ライブチケットのためのシェア取引データは、（少なくとも部分的に、シェア取引サーバ１７０によって実行されてもよい）シェア取引モジュールによって生成され、シェア取引データベース１６４に入力される。
【００６１】
シェアは、チケットが予選敗退した参加者又はチケットを購入しなかったが、システム１１０により登録された参加者を含む参加者の間で取引することができる。
【００６２】
１００シェアの潜在的価値の総計は、例えば、最大で１等賞の半分であってもよい。チケット所有者は、シェアを売らない／幾つかのシェア／又は１００シェア全てを売ることを選択してもよい。賢明な運営者は、彼らが１等に当選しようがしまいが、シェア取引から金をもうけるであろう。
【００６３】
当選チケットの中、又は、残念賞に関連するチケットの中で購入したシェアのみ、何れかの当選を共有する。１００シェアの最初の販売からの収益が、それらのシェアに対応するチケットの所有者に与えられる。幾つかの実施例において、シェアは、引き続き、交換に関する何れかの確認された購入者と取引されて、場合によっては、途中でトレーダーに利益を与える可能性がある。
【００６４】
ライブ交換プロセス７００において、シェア取引モジュールは、ステップ８００において、シェアに対する入札を処理し、ステップ９００においてシェアの取引を可能にする。シェア取引モジュールは、予選敗退閾値、例えば、ライブ交換プロセス７００の開始後の所定時間である時間閾値に到達したかどうかをチェックする。予選敗退閾値に到達していなければ、シェア取引モジュールは、ステップ８００において更なる入札の処理を許可する。予選敗退閾値に到達すると、更なる予選が、ステップ１０００において予選モジュールによって行われる。
【００６５】
シェア取引モジュールによって実行される入札処理ステップ８００を、図８により詳細に示す。ユーザによるリクエスト時に、シェア取引モジュールは、ｗｅｂサーバ１２８に、ユーザのｗｅｂブラウザに表示される（ステップ８２０）ライブチケットの一覧と共に（データベース１６２からのライブチケットのためのチケットデータを用いて）ｗｅｂページを生成させる（ステップ８１０）。一覧は、個々の「ライブチケット」ｗｅｂページを指し示すＵＲＬのリストの形態であってもよい。
【００６６】
ライブチケットページは、各ライブチケットに対して、現在の売り出し価格（ライブチケットの保有者がシェア当たりに得たいと考える価格）及び現在の入札価格（潜在的な購入者がシェア当たりに支払う気がある価格）を含んでもよい。売り出し価格及び入札価格は、チケット所有者の潜在的な当選の割合として表現されてもよい。
【００６７】
図８に示すように、ｗｅｂサーバ１２８は、登録された参加者から、例えば、参加者がステップ８３０において「ライブチケット」ＵＲＬのうちの１つをクリックした場合に、チケット選択を受信してもよい（ステップ８４０）。これにより、対応する「ライブチケット」情報ページが生成され、参加者のｗｅｂブラウザ１１７に送信され（ステップ８５０）、表示される（ステップ８６０）。
【００６８】
チケット情報ページ、並びに、選択されたライブチケットを所有する参加者によって提供された含まれる内容は、シェア取引データベース１６４からのチケットデータの取得に基づいて生成される一部を含んでもよい。例えば、チケット情報ページは、以下を含んでもよい：チケットを所有する参加者によって設定された現在の売り出し価格、及び、参加者によって発行された各入札に対する価値及びシェアの数。チケット情報ページはまた、更なるｗｅｂページへのリンク、例えば、入札した各参加者のプロフィールページへのリンクも含んでもよい。
【００６９】
チケット情報ページはまた、参加者が各シェアに対するシェア数及び入札価格を入力するためのデータエントリフィールドも含んでもよい。参加者がステップ８７０において入札を行うと、入札データがｗｅｂサーバ１２８によって受信され（ステップ８８０）、シェア取引データベース１６４におけるライブチケットのための入札データが次いで、それに従って更新される（ステップ８８５）。入札が行わなければ、ステップ８７０において、参加者は、例えば、「ライブチケット」要約ページに戻ってもよい。
【００７０】
プロセス８００はまた、ライブチケットの所有者による入力された入札の受け入れ又は拒否を処理するステップ８９０も含んでいる。一旦処理が完了すると、入札データは再度、ステップ８９５において更新される。
【００７１】
図３に戻って、予選敗退閾値が上で説明したように到達すると、プロセス３００は、更なる予選１０００に進む。チケット予選モジュールは、１から１６の間の１つ以上のランダムな数字を選択して、グループ化レベル３変数（表１）の数値に基づいてチケットのうちの１つ以上のグループを予選敗退させる。
【００７２】
各予選敗退の後に、予選敗退したチケットのうちの１つ以上に対する残念賞の支払いが任意に続いてもよい。
【００７３】
各予選敗退後、プロセス３００は、ライブ交換プロセス７００に戻り、残りのライブチケットの中でシェアの取引を許可してもよい。シェアが予選敗退したチケットの中で購入された場合、例えば、シェアが１等賞に対する残念賞の比率に基づいて計算し直された価値を有する場合において、予選敗退したチケットに関する残念賞の授与が無ければ、それらのシェアはそれらの価値の全体を失う（販売された元のシェアは、１等賞の価値に基づいていたため）ことは、正しく理解されるであろう。そのため、例えば、チケット所有者が、１００シェアの中でそれらの潜在的な当選のうちの４０％を売り、残念賞に当選した場合、チケット所有者は残念賞のうちの６０％を受け取り、各シェアは残念賞のうちの０．４％を割り当てられる。
【００７４】
予選１０００は、チケットのうちのたった１つのグループ化レベル３グループが残るまで、即ち、５０枚のライブチケットが残るまで（表１参照）、継続してもよい。この時点で、４つの更なる予選敗退が、チケット予選モジュールによって実行されてもよく、１０枚のライブチケットのみが残るまで、それぞれの連続する予選敗退の後に、ライブ交換プロセス７００への復帰が続く。
【００７５】
再度、図３を参照すると、プロセス３００は、ステップ１１００において、ロッタリーの当選者を決定することによって終了する。例えば、最終予選１１００は、１０枚の残りのライブチケットからたった１つの当選チケットのランダム選択を伴ってもよく、又は、ただ１つの当選チケットが残るまで、残りのライブチケットの１回につき１つ又は１回につき２、３の予選敗退を伴ってもよい。任意に、予選敗退したチケットは、残念賞の支払いを受けてもよい。たった１つの当選チケットは、１等賞の支払いを受ける。
【００７６】
各「ライブチケット」ｗｅｂページは、例えば、ｗｅｂサーバ１２８を介してアクセス可能な標準のソフトウェアモジュール又はプラグイン（図示せず）を用いて、対応するライブチケットに関連する参加者によって少なくとも部分的に生成されてもよい。ページは、参加者によってアップロードされた内容、例えば、ビデオ提示又はテキスト、写真、グラフィックス、及び音声の組み合わせを含んでもよい。「ライブチケット」ページは、参加者が、潜在的な購入者に対して、なぜ彼らがチケットの中でシェアを購入すべきかを宣伝することを可能にする。ライブ交換プロセスの開始時における参加者からの宣伝の一例は、以下のようなものであってもよい：
「こんにちは。私の名前はＢｉｌｌ  Ｓｍｉｔｈです。私は常に幸運に恵まれています。私のチケットは既に、８００分の１の確率で１，０００万ドルに当選するでしょう。何の保証もありませんが、私には、私のチケットが他の７９９枚のチケット所有者全てよりも、１等に当選する確率が高いことがわかっています。」
【００７７】
ライブチケットを保持する参加者は、ライブ交換プロセス７００の開始後のいつでも、最終予選１１００に至るまでのいつでも、彼らのチケット（単数又は複数）の中でシェアを売ってもよい。更に、売り出し価格は、いつでも参加者によって調整されてもよく、入札する参加者は、彼らの入札の数及び／又は価格を調整してもよい。
【００７８】
加えて、参加者によって保持されるシェアは、他の参加者に対して取引されてもよい。例えば、特定のライブチケットのためのｗｅｂページは、各承認入札に対する参加者の詳細を含む、チケット所有者によって承認された入札に関連する情報を含んでもよい。ｗｅｂサーバ１２８は、ライブチケット詳細ページに、ライブチケット詳細ページを閲覧する参加者によって、彼ら自身で承認された入札に応札することを許可させるコードを生成してもよい。承認された入札の保持者は、システム１１０上の彼らのアカウントに次にアクセスした時に、彼らのシェアに対して他の参加者（単数又は複数）からの提示（単数又は複数）の表示を見るかもしれず、ｗｅｂサーバ１２８は、保持者がかかる何れかの提示を承認又は拒否することを可能にするコードを生成してもよい。チケット所有者は、彼らが彼らのシェアを「買い戻す」ように、彼ら自身で承認された入札に関する提案を行ってもよいことは、認識されるであろう。例えば、チケット所有者は、彼らが最終的な１０人の参加者の中に残り、シェアの買戻しによる彼らの潜在的な収益を増加させることを望むように、幾つかの予選を乗り越えてもよい。
【００７９】
幾つかの実施形態において、シェア取引モジュールは、２人以上のユーザのシンジケートによる入札を可能にしてもよい。
【００８０】
競争が終了するまで（チケットが依然としてライブであれば）シェアを取引できる回数に対して、又は、ライブチケット保有者が他のチケットの中でシェアを購入することに対して制限する必要はない。ライブ交換プロセス７００は、任意のロックアウト期間、例えば、上で述べたようなロッタリーに関連する番組のライブテレビ放送時間を除いて、連続的に動作してもよい。
【００８１】
通常、ライブ交換サーバ１７０は、何らかの紛争が発生した場合に、完全な監査証跡が維持されることを可能にするよう、各チケットの中のシェアに関するそれぞれの決済のログをシェア取引データベース１６４に格納させる。
【００８２】
少なくとも幾つかの実施形態において、シェア取引モジュールは、参加者が、入札又は入札の承認等の何れかの動作を完了させるために、彼らのパスワードを入力することを必要としてもよい。シェア取引モジュールはまた、支払い処理サーバ１２５と通信して、それに信頼できるアカウント内の（入札の承認に関する）シェアのための支払いを格納するよう指示してもよく、次いで、例えば、３日から５日間の「クーリングオフ」期間の後、支払い処理サーバ１２５に、信頼できるアカウントからチケット所有者のアカウントに支払いを振り込むよう指示してもよい。
【００８３】
幾つかの実施形態において、プロセス３００は、ライブチケットの所有者が、登録された参加者との、本明細書中で「当選した場合」の契約と呼ばれる、１つ以上の契約を締結することを可能にしてもよい。それぞれの前記契約は、チケット所有者が１等賞又は残念賞に当選することを条件としている。彼らが当選しなかった場合、契約は破棄される。もし彼らが１等賞又は残念賞に当選した場合、契約が拘束される。何れのチケット所有者も、それらの潜在的な当選総額の５０％を超える価値の契約を締結することは許可されない。
【００８４】
多くの変更は、当該技術に精通する者にとって、本発明の適用範囲から逸脱することなく明らかであろう。
【００８５】
ソフトウェアモジュール１５０内のモジュールとコンポーネントとの間の境界は、例示的であり、代替実施形態は、モジュールを一体化させるか、又は、モジュールの機能の代替的な分解を課してもよい。例えば、本明細書中で検討したモジュールは、多数のコンピュータプロセスとして、そして任意に、多数のコンピュータ上で実行されるよう、サブモジュールに分解されてもよい。その上、代替実施形態は、特定のモジュール又はサブモジュールの多数のインスタンスを組み合わせてもよい。更に、動作は組み合わされてもよく、又は、動作の機能性は、本発明に従って、追加の動作において分散されてもよい。代替として、かかる作用は、複雑命令セットコンピュータ（ＣＩＳＣ）のマイクロコード、プログラマブル又は消去可能／プログラマブルデバイスにプログラムされるファームウェア、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）の構成、ゲートアレイ又はフルカスタムの特定用途向け集積回路（ＡＳＩＣ）の設計、又は同様のもの等の、かかる機能を実装する回路構造において具現化されてもよい。
【００８６】
コンピュータシステム１１０のプロセスのフロー図のブロックのそれぞれは、モジュール又はモジュールの一部によって実行されてもよい。プロセスは、方法を実行するようコンピュータシステムを構成するための機械読取可能及び／又はコンピュータ読取可能媒体において具現化されてもよい。ソフトウェアモジュールは、モジュールの機能を実行するようコンピュータシステムを構成するためにコンピュータシステムメモリ内部に格納されるか、及び／又は、それに伝送されてもよい。
【００８７】
コンピュータシステム１１０は、通常、プログラム（特定のアプリケーションプログラム及び／又はオペレーティングシステム等の内部に格納された命令のリスト）に従って情報を処理し、入力／出力（Ｉ／Ｏ）装置を介して結果としての出力情報を生成する。コンピュータプロセスは、通常、実行する（動作する）プログラム又はプログラムの一部、現在のプログラム数値及び状態情報、及び、プロセスの実行を管理するためにオペレーティングシステムによって用いられるリソースを含んでいる。親プロセスは、親プロセスの機能全体を実行することを支援するよう他の子プロセスを生成してもよい。親プロセスは、特に、親プロセスの機能全体の一部を実行するよう子プロセスを生成するため、子プロセス（及び、孫プロセス等）によって実行される機能は、時には、親プロセスによって実行されるように説明されてもよい。
【００８８】
データベース１６２、１６４の間の境界は、例示的であり、代替実施形態は、それらのデータベース内のデータを統合するか、例えば、様々な物理的データベース及び／又はデータ構造の上のデータ記録の代替的な分解を課してもよいことは正しく理解されるであろう。
【００８９】
本明細書全体を通して、特に文脈が要求しない限り、用語「備える」、及び、「備える」及び「備えている」等の変形例は、記載された整数又はステップ、又は整数又はステップのグループの包含を暗に意味するが、何れか他の整数又はステップ、又は整数又はステップのグループの除外を意味しないことは理解されるであろう。
【００９０】
何れかの先行公報（又は、それから導出される情報）に対するか、公知の何れかの事柄に対する本明細書中の引用は、その先行公報（又は、それから導出される情報）又は公知の事柄が、本明細書が関係する努力分野における共通の一般的知識の一部を形成するという承認又は容認又は提案の何れかの形態として取られず、またそれと取るべきではない。
【図１】
2016529587.tif 000004
【図２】
2016529587.tif 000005
【図３】
2016529587.tif 000006
【図４】
2016529587.tif 000007
【図５】
2016529587.tif 000008
【図６】
2016529587.tif 000009
【図７】
2016529587.tif 000010
【図８】
2016529587.tif 000011
【国際調査報告】
2016529587.tif 000012
2016529587.tif 000013
2016529587.tif 000014